Can you list these optimizations?

RLHF is one that comes to mind

Well, this is an entirely other category of optimizations - not program performance but model performance.

Yes, in "runtime optimization" the model is just a computation graph so we can use a lot of well known tricks from compilation like dead code elimination and co..

We are getting closer!

What other optimizations are there that can be used than what explicitly falls into the 4 categories that the top commenter here listed out?

For inference assorted categories may include vectorization, register allocation, scheduling, lock elision, better algos, changing complexity, better data structures, profile guided specialization, layout/alignment changes, compression, quantization/mixed precision, fused kernels (goes beyond inlining), low rank adapters, sparsity, speculative decoding, parallel/multi token decoding, better sampling, prefill/decode separation, analog computation (why not) etc etc.

There is more to it, mentioned 4 categories are not the only ones, they are not even broad categories.

If somebody likes broad categories here is good one: "1s and 0s" and you can compute anything you want, there you go – single category for everything. Is it meaningful? Not really.

Thanks!

It seems like the 100% vibe coded is an exaggeration given that Claude fails at certain tasks.

The new generation of code assistants are great. But when I dogmatically try to only let the AI work on a project it usually fails and shots itself in its proverbial feet.

If this is indeed 100% vibe coded, then there is some magic I would love to learn!

I think by 100% vibe coded most people on hn mean that 100% of the code is written not by hand. The hand only does the delete key and prompting. We're mostly not talking about amateurs with no CS background just prompting and shitting out software with all sorts of bugs they would never be able to see.

My last two projects have been 100% coded using Claude, and one has certain complexity. I don't think there is coming back for me.

What is your secret sauce? How do you organize your project?

I decided to really learn what is going on, started with: https://karpathy.ai/zero-to-hero.html That give a useful background into understanding what the tool can do, what context is, and how models are post trained. Context management is an important concept. Then I gave a shot to several tools, including copilot and gemini, but followed the general advice to use Claude Code. It's way better that the rest at the moment. And then I dive deep into Claude Code documentation and different youtube videos, there is plenty of good content out there. There are some ways to customize and increase the determinism of the process by using the tools properly.

Overall my process is, define a broad spec, including architecture. Heavy usage of standard libraries and frameworks is very helpful, also typed languages. Create skills according to your needs, and use MCP to give CC a feedback mechanism, playwright is a must for web development.

After the environment and initial seed is in place in the form of a clear spec, it's process of iteration via conversation. My session tend to go "Lets implement X, plan it", CC offers a few route, I pick what makes most sense, or on occasions I need to explain the route I want to take. After the feature is implemented we go into a cleanup phase, we check if anything might be going out of hand, recheck security stuff, and create testing. Repeat. Pick small battles, instead of huge features. I'm doing quite a lot of hand handling at the moment, saying a lots of "no", but the process is on another level with what I was doing before, and the speed I can get features out is insane.

Thanks! Very valuable insights.

I have been through Karpathy's work - however, I don't find that it helps with large scale development.

Your tactics work successfully for me at smalle scale (at around 10klocs, etc) and starts to break down - especially when refactorings are involved.

Refactoring happens when I see that the LLM is stumbling over it's own decisions _and_ when I get a new idea. So the ability to refactor is a hard requirement.

Alternatively refactoring could be achieved by starting over? But I do have a hard time accepting that idea for projects > 100klocs.

It is until it's not. That's the problem. The AI gets tripped up at some point, starts frigging tests instead of actually fixing bugs, starts looping then after several hours says it's not possible. If you're lucky.

Then on average your velocity is little better than if you just did it all by hand.

The AI gets tripped phenomenon is something I've experienced, and I think it's again related to context usage. Using more agents and skills will reduce the pollution on the main context, and delay the moment where things go weird. /clear after each small mission. As said above, CC needs heavy guidance, but even with these issues, I'm way faster.

> Purpose 1: Minimize Costs of Change

The cost of change is radically increased using micro services.

With microservices you scatter the business complexity across multiple services and lift a considerable amount of complexity from the easily testable code base and into the infrastructure.

IMHO doing a micro service architecture for this reason is horrible.

You are right but from a different context. In a well thought out microservice architecture, you will not have business logic scattered across multiple services.

We have had instances of microservice architecture where doing one change required changes in 4 different microservices defeating the whole point. Obviously this is bad.

“ In a well thought out microservice architecture, you will not have business logic scattered across multiple services.”

A “well thought out” architecture that holds up over years is a pipe dream. There will always be changes that require a rethinking of the whole system.

As the sibling say, the changes of the future are not predictable. The perimeter for business logic or bundled changes change.

Having a monolith much nicer allows to make these types of changes.

Yes that's the tradeoff. Over time your architecture degrades and you need to rethink the services. But good part is that migration is simpler and less risky when you are just making changes to few microservices.

I am curious, how is this the case?

Is that because a failure of a service would only affect a single flow?

IMHO time estimation for software development is a legacy way of thinking. A result of industrial processes.

At my team we think in terms of deliverables and commitments: "I can commit til deliver this by that date under these circumstances".

This mitigated the diverse nature Og thinking.

The time argument is countered in roughly the same manner as when you do home improvement.

Yiu don't pay taxes on the time spent on your own projects.

There is no alternate I've cost, as the time would usually have been spent watching television if not doing these projects.

This argument is brought up a lot against using opportunity cost for private projects, but I don't buy it

If you are dedicating a considerable amount of time on a project, there is of cause opportunity cost, since that's time

- not spend on improving health - not spend on improving skills - not spend on improving other projects

Seldom one decides between a side project and starring into the void

What makes you believe that are easy to identify?

One could require DOIs for each reference. That's both realistic to achieve and easy to verify.

Although then why not just cite existing papers for bogus reasons?

Isn't that what GPTZero does?

Would this also have been the case had the housing price gone down for you? Or if the housing price had just been flat?

These single use tricks make sure that the housing market will go up for yet another couple of year. But every time a trick like this is applied, it will increase the risk in the system. There are also the issue that there are only that many tricks one can use.

I can't seem to find in the repo what optimizes this language for LLMs and benchmarks for why it works?

The author's answers are toward the bottom of the README, https://github.com/jordanhubbard/nanolang?tab=readme-ov-file...

I understand the effort and it seems like a nice little language but wouldn't it make more sense to target already existing C--, QBE, LLVMIR or similar? There must be "simpler C" languages already which sounds more useful given that LLMs must've been trained on them.

The university should push the maintainance to the holder of the phone? That seems unreasonable.

As mentioned in another comment. Universities already have in house it services. Being able to fix the phone right there with spare parts is likely very cost efficient.

I think the alternative was to contract it out to an IT company rather than push it to the holder. Same as company phones in corporate environments

Likely not.

I am also building some agents. It is almost hands off at this point.