Everyone's quietly asking this. The answer isn't as obvious as it used to be.
An agent writes 400 lines. Tests pass. Lint clean. I can't tell whether the decisions in it are good or just plausible. And if nobody's reading this line-by-line anymore — what does "quality" even mean here?
A note: this is where my thinking is today — June 2026. The tooling is moving fast. Some of what follows might look different in six months.
In software engineering, cognitive load refers to the total amount of mental effort being used in a developer's working memory to complete a task. Think of it like the RAM in a computer: if you try to run too many heavy applications at once, the system slows down, glitches, or crashes.
When a developer's cognitive load exceeds their mental capacity, productivity drops, the quality of code suffers, and the risk of burnout increases.
Somewhere in your organisation right now, an engineer wants to use a tool. It's open source. It's battle-tested. Half the Fortune 500 runs it in production. But first, they need to fill out a vendor assessment form, get InfoSec sign-off, wait for procurement to confirm there's a contract in place, and then — maybe, in four to six months — they'll get a "yes" or a "no" from a committee that's optimised for risk avoidance, not risk management.
This isn't an argument against governance. Governance matters — especially in regulated industries. This is an argument that the way most enterprises do governance today is broken: optimised for the appearance of control rather than the reality of it. The question isn't whether to govern. It's whether your governance framework is actually reducing risk — or just reducing speed.
Meanwhile, the startup down the road shipped the feature last Tuesday.
But hey, at least you've got a contract. You can sue them if things go wrong. Right?