Does Yegge really think that building production software this way is a good idea?

Let's assume that managing context well is a problem and that this kind of orchestration solves it. But I see another problem with agents:

When designing a system or a component we have ideas that form invariants. Sometimes the invariant is big, like a certain grand architecture, and sometimes it's small, like the selection of a data structure. Eventually, though, you want to add a feature that clashes with that invariant. At that point there are usually three choices:

* Don't add the feature. The invariant is a useful simplifying principle and it's more important than the feature; it will pay dividends in other ways.

* Add the feature inelegantly or inefficiently on top of the invariant. Hey, not every feature has to be elegant or efficient.

* Go back and change the invariant. You've just learnt something new that you hadn't considered and puts things in a new light, and it turns out there's a better approach.

Often, only one of these is right. Usually, one of these is very, very wrong, and with bad consequences.

But picking among them isn't a matter of context. It's a matter of judgment and the models - not the harnesses - get this judgment wrong far too often (they go with what they know - the "average" of their training - or they just don't get it). So often, in fact, that mistakes quickly accumulate and compound, and after a few bad decisions like this the codebase is unsalvageable. Today's models are just not good enough (yet) to create a complete sustainable product on their own. You just can't trust them to make wise decisions. Study after study and experiement after experiment show this.

Now, perhaps we make better judgment calls because we have context that the agent doesn't. But we can't really dump everything we know, from facts to lessons, and that pertains to every abstraction layer of the software, into documents. Even if we could, today's models couldn't handle them. So even if it is a matter of context, it is not something that can be solved with better context management. Having an audit trail is nice, but not if it's a trail of one bad decision after another.

I think a lot of it comes down to the training objective, which is to fulfill the user’s request.

They have knowledge about how programs can be structured in ways that improve overall maintainability, but little room to exercise that knowledge over the course of fulfilling the user’s request to add X feature.

They can make changes which lead to an improvement to the code base itself (without adding features); they just need to be asked explicitly to do so.

I’d argue the training objective should be tweaked. Before implementing, stop to consider the absolutely best way to approach it - potentially making other refactors to accommodate the feature first.

[flagged]

Some people care about the craft, most care about the output...

Hang in there, there will be a lot of slop to fix in contract work...