This recent @latentspacepod pod was a good one (they usually all are).

One specific piece resonated: They were talking about AI agents writing code, and the line was basically that without caution / diligence, your codebase can regress to your worst engineer.

Bad AI-generated code does not just create a one-time cleanup problem. Once it gets into the repo, it becomes part of the context for the next change. The agent sees the bad pattern, assumes it is part of how the system works, and then builds on top of it.

So if you let bad architecture, bad code, or code slop leak into your repo, you are not just making the codebase messier. You are changing the inputs that guide future agent decisions.

This is the failure mode I worry about with coding agents - particularly on larger teams. I get a ton of value out of coding agents, but you need real mechanisms in place to keep them from amplifying the worst parts of your system.

Some of that is technical. You need a system around the agents: better planning, review steps, adversarial agents, fresh-context reviews, tests, checks, and small changes that limit the blast radius. Basically, a team-aligned process around compound engineering.

But that is not enough by itself. You also need experienced people at the wheel.

Especially on a broad team where lots of people have access to these tools, someone still needs to read the code. Someone needs to understand the architecture. Someone needs to know when a change is technically working but pulling the system in the wrong direction.

Bad code in the repo becomes precedent. And once it becomes precedent, the agent can keep building on it until the codebase no longer accurately reflects what you are trying to build - and is hard to move forward, with or without AI agents.