Hacker News Reader

> Unless you are really on top of your agents, they inevitably end up writing an absolute mess.

It's like the magic broomsticks from Fantasia's Sorceror's Apprentice sequence. Great at hauling buckets but if you don't keep a close eye on them they will fill your workshop with water.

Does it matter if it's great code?

Like what matters is: - Does it do the thing it's supposed to do - Does it do it with a reasonable amount of resources - Does it do it without any obvious security flaws

Yeah, if they were nuclear codes you'd want to be really really sure and you'd probably want to check every line yourself. But if you're making a habit tracker or 95% of apps out there, it really doesn't matter.

There is definitely some skill in piloting the LLM, where you have an advantage if you understand what "good" is - but I'd argue it really isn't that necessary in most cases. McDonald's has had a lot of success selling food that most chefs would say isn't that great, but it fills that need at that moment.

I don't think we have data yet on how it matters, all I know is that I am confused by the meme, as it does not match my experience.

> they inevitably end up writing an absolute mess

I don't think this is inevitable. How do you define an absolute mess? Whatever you come up with, give the agent instructions to not do that. Then audit the code to make sure it's not happening.

> Not only does the code become impossible for humans to reason about very quickly,

What makes it actually impossible? It's using logic that is beyond human comprehension? It's using the programming language in a clever way no human would expect? Have you tried instructing it to code in a way that's more comprehensible to humans, e.g. literate programs?

> it actually becomes difficult for agents to reason about it.

This I have not seen. Do you have an example?

> Whatever you come up with, give the agent instructions to not do that. Then audit the code to make sure it's not happening.

Yes, this is what I mean by saying you need to stay on top of the agents

> What makes it actually impossible?

A combination of wrong abstractions, lack of abstractions, assuming some key requirements were just implementation details and thus are safe to refactor, assuming some implementation details were key requirements and thus must be protected at all costs, etc etc.

In practical terms, it's just volume of code that is spread extremely wide, duplicated with subtle differences, and just organized extremely confusingly.

> This I have not seen. Do you have an example?

If you try to vibe code longer term projects, you very often start getting completely nonsensical explanations from agents about why they are doing things. They reference requirements which are not real (based on what they interpret from the messy code), they write thousands of test cases that are redundant, or test things which are implementation details. Eventually even trivial changes become extremely slow due to lack of structure, due to fresh agents being confused by contradictions introduced by previous sessions, and due to test suites that take hours to run.

> "Opus writes better code than me"

Probably true for some definitions of me. :)

Almost all definitions of 'me', actually.

Yes. A project I am working on now the code quality it is producing I would put at less than ten people I have ever met could do, and they would struggle with the OCD tedium induced.

There is clearly a trick to coaxing these results, and a major factor is to treat the model like it is something you fully expect to get it right because it knows how to do it, not you micromanaging it into compliance.

> Not only does the code become impossible for humans to reason about very quickly, it actually becomes difficult for agents to reason about it.

Story of many enterprise applications built only by humans. There is a good reason that frequently devs either refactor their codebase or do a complete rewrite.

True. In human built applications, the problems really start manifesting when the original code owners/maintainers leave, effectively turning their work into legacy code.

But vibe coded projects are effectively instant legacy code, due to lack of real ownership. So it's kind of a bigger problem.