There is an in between here that developers seem to keep forgetting: Design the software architecture yourself — do some whiteboarding, figure out your abstract

There is an in between here that developers seem to keep forgetting: Design the software architecture yourself — do some whiteboarding, figure out your abstractions and your UML, then write that in your prompt for the LLM to implement through a plan. Velocity stays high. Cognitive overhead remains low. You know enough of your architecture from the “unit” level to see how the pieces work meaning you can still work fast and understand it without hating the quality it produces. This has worked wonders for my company; I’ve managed to personally write tools that are barely distinguishable from what I’d write by hand, and I’m confident enough to discuss its architecture from top to bottom. If the LLM ever produces a unit with a poor implementation, I just rewrite that unit. Basically: do the “engineering” part of software engineering instead of throwing LLMs at the wall until code sticks. It doesn’t take much time to come up with a good design, compared to repeatedly iterating on a bad design and maintaining it for years to come. LLMs suck at design, and that’s why they lead to this bad code. But if a human spends an hour to build nice SOLID abstractions, and tell the LLM each responsibility — they are pretty good at using and wiring these parts together.