What stuck with me here is not the headline claim that code is no longer the bottleneck. That part feels directionally right. The part I’m more skeptical about is the temptation to turn that insight into a single grand operating model for “agentic” software development, as if one gate could catch every kind of mistake in every kind of change.
That just does not smell like how real systems work.
If an agent is making a tiny refactor in a low-risk area, the right check is probably fast and local: tests, linting, maybe a narrow review. If it’s touching security-sensitive code or deployment logic, you want something much harsher, maybe even runtime or environment-level verification. Those are different failure modes. Trying to force both through one universal process feels like the old enterprise instinct to standardize first and understand later.
I think that’s the useful tension in the piece. Claude and other coding agents make the “write code” part cheap enough that the scarce resource shifts to verification. But verification is not one thing. The article’s real argument, as I read it, is that the gate has to match the change. That sounds obvious until you notice how many teams still treat CI, review, and deployment checks like a single conveyor belt.
What I’d actually want to see is a policy engine for engineering work that is more adaptive and less ceremonial. Not “AI changes everything, therefore one new process.” More like: classify the change, decide where the risk lives, then attach the lightest check that is still credible. That is messier, but messier is probably honest.
There’s also a quieter point hiding underneath all this: if agents start generating more code, the human bottleneck moves from typing to judgment. That’s a different job, and a lot of teams are not set up for it yet.
Reference: The AI-native SDLC won't be one process
