Comment by embedding-shape
Comment by embedding-shape a day ago
> but I can tell you that producing "good" code is another layer altogether.
I feel like it isn't. If the fundamental approach is good, "good" code should be created as a necessity and because there wouldn't be another way. If it's already a mess with leaking abstractions and architecture that doesn't actually enforce any design, then it feels unlikely you'll be able to stack anything on top of below it to actually fix that.
And then you end up with some spaghetti that the agent takes longer and longer to edit as things get more and more messy.
Here is my view after putting in my 10,000+ hours learning to code pre-llm days, while also building a pretty complex design + contract manufacturing company, with a lot of processes in place for that to happen. If you have a bunch of human junior devs and even a senior dev or two that join your org to help you build an app, and you don't have any dev/ops structure in place for them, then you will end up with "spaghetti" throughout all your code/systems, from those relatively bright humans. Its the same managing agents. It cannot be expected to build a complex system from simple "one shot me a <x> feature" from a bunch of different agents, each with a finite ~150k token context limit. It must be done in context of the system you have in place. If you have a poor/no system structure, you'll end up with garbage for code. Everything that I said I had to guide the agents, is also useful for human devs. I'm sure that all the FANGS and various advanced software companies also use custom linters, etc., for every code check in. It's just now become easier to have these advanced code quality structures in place, and it is absolutely necessary when managing/coordinating agents to build a complex application.