Vibe Coding and Agentic Engineering Are Blurring

Simon Willison says AI coding tools are making vibe coding and agentic engineering harder to separate in real software work.

Simon Willison says the line between casual AI-assisted coding and careful professional use is getting harder to draw. In a post dated 6 May 2026, he explains why tools like Claude Code now feel reliable enough to change how he reviews code, ships features, and judges software quality.

The shift matters because Willison is not talking about toy projects. He is talking about production systems, engineering judgment, and the uncomfortable feeling that an agent can now write code he no longer inspects line by line.

Where vibe coding ends and professional use begins

Willison has been one of the clearest public voices on the difference between “vibe coding” and what he calls agentic engineering. In his earlier writing on Not all AI-assisted programming is vibe coding, he argued that vibe coding is fine for personal projects and risky for software that affects other people.

That distinction used to feel crisp. Vibe coding meant you asked for something, got something back, and cared mostly about whether it worked. Agentic engineering meant you were still acting like a software engineer, with security, maintainability, operations, and performance in mind.

Now the tools are good enough that the boundary is getting fuzzy. Willison says he still wants higher-quality software faster, but the agents are making it easier to stop checking every line. That is a practical change, not a philosophical one.

• Vibe coding is acceptable when the bug only hurts you.
• Agentic engineering is aimed at production software with real users.
• As agents improve, the review process starts to change even for experienced engineers.

The trust problem is the real story

The most interesting part of Willison’s post is not speed. It is trust. Once an agent reliably writes a JSON API endpoint, adds tests, and documents the result, the temptation is to stop looking too closely. That works until it does not.

He compares this to how engineers treat another team’s service inside a larger company. You do not read every line of the image resize service before using it. You read the docs, ship your feature, and inspect the implementation only if something breaks. Willison says he is beginning to treat coding agents the same way.

“Claude Code does not have a professional reputation!” — Simon Willison

That line captures the tension well. Human teams build reputations over time. Models do not. They can still produce code that looks polished, complete, and tested, which makes the trust decision harder than it used to be.

Willison also points to a subtle risk: normalization of deviance. If a model keeps getting the answer right when you barely supervise it, you may start trusting it in situations where the cost of failure is much higher.

Why software quality is harder to judge now

One of Willison’s sharpest observations is that AI has made surface signals less useful. A GitHub repo with a hundred commits, a polished README, and a full test suite used to suggest serious effort. Now someone can generate something that looks the same in half an hour.

That means reviewers need better signals. Willison says he now values actual use more than presentation. If a vibe-coded project has been used every day for two weeks, that tells him more than a gorgeous README ever could.

• Hundreds of commits no longer imply long effort.
• Automated tests no longer prove human care by themselves.
• Real daily use matters more than polished packaging.
• Production history matters more than generated artifacts.

This is a big shift for anyone who evaluates software by reading repositories. The old heuristics still matter, but they are weaker now. A repo can look mature while hiding a very short creation cycle.

That also changes how teams should present internal tools. If a service is meant to be trusted, it needs usage history, clear docs, and evidence that someone has depended on it for real work. The badge of quality is now experience, not just output.

The bottlenecks moved upstream and downstream

Willison argues that if engineers can jump from 200 lines of code a day to 2,000, the rest of the software process has to adapt. Design, testing, review, and deployment were all built around slower code production.

He cites a talk by Anthropic design leader Jenny Wen, who described how design processes were built for a world where shipping the wrong thing was expensive because engineering work took months. If the build cycle shrinks, the design process can take more risks too.

That is a useful way to think about the broader effect of AI coding tools. They do not just speed up implementation. They change the cost of being wrong, which changes how teams should think about design reviews, prototyping, and iteration.

For teams using tools like Claude Code, the question is no longer whether the tool can write code. It can. The question is how much of the surrounding workflow still assumes code is expensive to produce.

Why Willison still is not worried about his job

Willison is clear that he does not think his career is over because computers can write code. His reason is simple: these tools amplify existing skill. If you already know what you are doing, you can move much faster. If you do not, the tools still leave you with a hard problem.

He also says software development remains ferociously difficult. AI does not erase the complexity of building reliable systems for real users. It just changes which parts of the job take the most time.

That is why he likes Matthew Yglesias’s framing: he does not want to “vibecode,” he wants professionally managed software companies to use AI assistance to build better products. That is a more grounded expectation than the fantasy that everyone should ship software alone from a prompt box.

The same logic applies to SaaS adoption. Willison says he would rather use a CRM that two giant enterprises have already run for six months than a fresh internal clone built in a weekend. Proven systems still matter.

For developers, the takeaway is practical. AI coding tools are getting good enough that the old mental split between “real engineering” and “prompt-and-pray coding” is breaking down. The next test is not whether agents can write code, but whether teams can build review, trust, and accountability around code that arrives much faster than before.

If you are using these tools today, the question to ask is simple: what proof do you require before you trust generated code in production, and has that bar changed without you noticing?

Related: Want concrete examples of how workflow plugins shape agentic coding? See Superpowers vs Everything Claude Code — two different takes on the same problem.