What does "Good Code" even mean now?
https://testdouble.com/insights/what-does-good-code-even-mean-now
Understanding has always been the primary constraint. Do we know what problem we’re solving? Do we know if our solution is actually solving it? Are we building the right thing? Developer speed compounded that constraint by slowing down the feedback loops we depend on to learn. Slower development meant slower delivery, which meant slower validation, which meant slower understanding. The two constraints were entangled.
Now the developer speed piece is evaporating. Which means understanding is exposed, nakedly, as the thing that actually limits us. And agentic coding makes it faster and cheaper than ever to build the wrong thing at scale. That changes the risk profile considerably. The answer isn’t to slow down. The answer is to stay disciplined about incrementalism at the product level: releasing smaller, validating more often, treating assumptions about what users need as hypotheses to test rather than requirements to build.
I still want teams creating simple things in small steps. The “simple things” part is unchanged. Unnecessary complexity is still unnecessary complexity, regardless of how fast you can generate it. But the emphasis of “small steps” is shifting from breaking down code problems into smaller chunks toward breaking down the problem space into smaller deliveries that each teach us something.