Most software teams are still debating how AI fits into their workflows. The real question is whether they can afford to keep building the way they always have.
The moment I stopped reviewing every line of code
A few weeks ago, I caught myself doing something I would have called irresponsible two years ago.
I had asked an AI coding agent to build a JSON API endpoint, wire up the SQL query, add automated tests, and generate documentation. It came back clean. I reviewed the structure, checked the test coverage, and shipped it.
I did not read the code.
That moment sat with me. Not because I had done something wrong, but because I realised the rules of the game had quietly changed, and most organisations have not caught up.
Simon Willison, one of the most thoughtful practitioners in this space, put it well in a recent podcast: “The problem is that as the coding agents get more reliable, I’m not reviewing every line of code that they write anymore, even for my production level stuff.” He called it uncomfortable. I call it inevitable, and the organisations that learn to work with that discomfort will outpace those that resist it.
Vibe coding and agentic engineering are not the same thing
There is a distinction worth making clearly, because conflating the two is costing teams real money and credibility.
Vibe coding is what happens when someone, often a non engineer, asks an AI to build something, accepts whatever comes back, and ships it without understanding what is underneath. It is fast. It is sometimes useful for throwaway tools. It is grossly irresponsible when other people’s data, money, or trust is involved.
Agentic engineering is something different. It is what happens when an experienced engineer, someone who understands security, performance, maintainability, and system design, uses AI agents as a force multiplier. The expertise does not disappear. It gets applied at a higher level of abstraction.
The Hacker News thread on Willison’s article surfaced a comment that I think captures this well: “The volume of people successfully adopting agentic engineering practices suggests this stuff isn’t rocket science, but it is a learned skill and takes setup.” That is exactly right. It is a craft, not a shortcut.
The bottleneck has moved, and most organisations have not noticed
Here is what changes when a team goes from producing 200 lines of code a day to 2,000: everything upstream and downstream of the code itself becomes the constraint.
Design processes built around expensive engineering cycles become over-engineered. Code review workflows designed for human-paced output collapse under volume. Onboarding assumptions about how long features take get invalidated. Sprint planning, estimation, and capacity models all need rethinking.
Jenny Wen, design leader at Anthropic, made a point that stuck with me: the entire design process was built on the assumption that getting it wrong is catastrophic because building the wrong thing takes months. When the cost of a wrong turn drops by an order of magnitude, the design process itself can afford to be more experimental.
This is not just a developer productivity story. It is a product strategy story. It is an operating model story. Organisations that treat agentic engineering as a tool for individual engineers will achieve incremental gains. The ones that redesign their entire delivery model around it will get something closer to a structural advantage.
What actually breaks when you scale AI assisted development
The honest answer is: trust and verification.
When a GitHub repository can be generated in half an hour, complete with a hundred commits, a polished readme, and comprehensive test coverage, the traditional signals of quality become unreliable. Willison noted this directly: “Even for my own projects, I can’t tell” whether the care and attention is real or generated.
What replaces those signals? Usage. Real-world exercise. The question shifts from “does this look well-built?” to “has someone actually run this in anger?”
For enterprise software organisations, this has a direct implication. The bar for proof of concept is lower. The bar for production trust is not. The gap between the two is where most AI-assisted projects currently live, and closing it requires deliberate engineering culture, not just better prompts.
One practitioner in the Hacker News discussion described their approach: set up linters, test frameworks, and static analysis before the agent writes a single line. Treat the agent like a capable but unsupervised junior engineer. Review the architecture, not just the output. That is agentic engineering done properly.
What this means for product and technology leaders
If you are running a product or engineering organisation right now, here is where I would focus your attention.
First, separate the signal from the noise on productivity claims. Teams reporting 40-55% output increases are real, but the metric that matters is not lines of code or tickets closed. It is whether the system you are building is becoming easier or harder to change over time. AI-generated code that accumulates technical debt faster than it ships features is not a productivity gain.
Second, invest in your verification infrastructure before you scale your generation capacity. Tests, linters, integration checks, and architectural guardrails are not overhead in an agentic world. These help agentic development run safely at speed. The teams getting the best results are the ones who built the harness first.
Third, rethink how you evaluate software from external teams and vendors. The traditional signals, commit history, documentation quality, test coverage, are no longer reliable proxies for care and craftsmanship. Ask instead: who has used this, for how long, and under what conditions?
Fourth, treat agentic engineering as a senior skill, not a junior one. The practitioners who get the most out of these tools are those with the deepest domain knowledge. They know what to ask for, when the output is wrong, and how to set up the environment so the agent can succeed. This is not a path to replacing experienced engineers. It is a path to making them dramatically more effective.
The organisations that will benefit most
Vibe coding did not create undisciplined engineering organisations. It exposed and accelerated them.
That is the real risk. AI does not fix weak engineering culture. It amplifies whatever is already there. Teams with strong practices, clear ownership, and good verification habits will find agentic engineering genuinely transformative. Teams without those foundations will generate more code, faster, and understand it less.
The opportunity is real. The productivity gains are real. But they accrue to organisations that approach this as an engineering discipline, not a prompt-and-ship workflow.
What to do
Start with an honest audit of your current delivery model. Where are the actual bottlenecks? If your engineers are spending significant time on boilerplate, integration glue, and documentation, that is the highest-value target for agentic tooling.
Then build the verification layer before you scale the generation layer. Define what “done” looks like in a way that an agent can be held to. Linters, test coverage thresholds, and architectural constraints are not bureaucracy. They are the thing that makes speed safe.
Finally, invest in the skill of directing agents well. This is not prompt engineering in the superficial sense. It is the ability to decompose a problem clearly, set up the right context, and evaluate the output with the same rigour you would apply to a pull request from a talented but inexperienced engineer.
The organisations that build this capability now will have a structural advantage that compounds over time. Those who wait for the technology to mature further will find it harder to close the gap.
The bottom line
Agentic engineering is not a trend to watch. It is an operating model shift that is already underway.
The question is not whether your organisation will adopt it. It is whether you will adopt it with the discipline and intentionality that makes it genuinely valuable, or whether you will let it become a faster way to accumulate problems you do not yet understand.
Twenty-five years of building software across industries has taught me one thing consistently: the tools change, but the fundamentals of good engineering do not. Agentic engineering does not replace those fundamentals. It raises the stakes for having them.
What is your experience with agentic engineering in your organisation? Are you seeing the productivity gains, and more importantly, are you seeing the quality hold? I would genuinely like to know what is working and what is not.
Follow me for more on the intersection of product strategy, engineering execution, and the operating models that make both work at scale.
Sources: Simon Willison, “Vibe coding and agentic engineering are getting closer than I’d like” (simonwillison.net, May 2026); Hacker News discussion thread