Last week, Clare Liguori — Senior Principal Engineer at AWS — published what amounts to a practitioner’s manifesto on frontier engineering. Featured in the AWS Weekly Roundup, her core thesis lands like a punch: frontier developers hand write less than 1–2% of their output. Agents produce the rest. And this is the opposite of vibe coding.
That distinction matters, because eighteen months into the age of AI coding assistants, the industry is still confusing the two. One camp treats AI tools as a way to stop thinking about code. The other treats them as a way to think about code at a higher level of abstraction. They use the same tools. They produce radically different outcomes.
The Term Has Outgrown Its Origin
When Andrej Karpathy coined “vibe coding” in February 2025, he was describing something specific and, frankly, kind of delightful: building throwaway weekend projects by prompting an LLM, accepting all diffs without reading them, and copy pasting error messages until things worked. “It’s not really coding,” he wrote. “I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.”
Karpathy knew exactly what he was giving up — code comprehension, security review, architectural intent — because the stakes were zero. Weekend project. Throwaway. Fun.
By mid 2026, Collins Dictionary had named “vibe coding” Word of the Year, 92 percent of U.S. developers were using AI tools daily, and GitHub reported that 46 percent of all new code was AI generated. The term that started as a tongue in cheek description of a guilty pleasure had become a blanket label for all AI assisted development. And that conflation is dangerous, because it lets teams pretend that what they are doing with Cursor in production is the same thing Karpathy was doing with Composer on a Saturday afternoon.
It is not.
The Numbers Are Alarming
Let’s look at what vibe coding — real vibe coding, the “Accept All and don’t read the diffs” variety — actually produces when it escapes the sandbox:
- 2.74x more security vulnerabilities in AI authored pull requests versus human only PRs (CodeRabbit, December 2025, analyzing 470 open source repos).
- 45 percent of AI generated code samples introduced an OWASP Top 10 vulnerability, including hardcoded secrets, missing input validation, and insecure dependencies (Veracode 2025 GenAI Code Security Report).
- 35 CVEs directly attributed to AI generated code in March 2026 alone — up from 6 in January (GitGuardian).
- 1.5 million API keys exposed across seven documented vibe coded apps that broke in production during 2025 and 2026.
And then there is the Cursor/Claude Opus incident. In April 2026, a Cursor agent running Claude Opus 4.6 deleted a startup’s entire production database — and every backup — in nine seconds flat. The engineer had prompted the agent to “clean up the test data.” The agent, operating with overprivileged credentials and zero guardrails, interpreted that as a mandate to purge everything. Nine seconds. No confirmation dialog, no dry run, no human in the loop.
What Liguori Gets Right
Clare Liguori’s manifesto is the clearest articulation I’ve seen of why frontier engineering is fundamentally different from vibe coding. Drawing from teams across Amazon — including the Bedrock Mantle team that replaced a 30 person, 18 month estimate with 6 engineers shipping in 76 days, and a 50 team pilot where the top performers saw a median 4.5× improvement in deployment velocity — she identifies five habits that separate the teams seeing 10× gains from the ones seeing marginal improvement.
The habits sound deceptively simple: invest in agent context, accept an initial slowdown to improve the codebase, give agents work they can validate independently, resolve ambiguous intent in a specification before coding starts, and shift testing left so agents get fast local feedback loops.
But the insight underneath is profound. As Liguori puts it, the teams that got better didn’t just change their tools — they changed how they work. Software development has split in two: people who changed how they work with agents, and people who only changed their coding tools.
This maps directly to what Simon Willison identified in March 2025: “Not all AI assisted programming is vibe coding.” His golden rule for production quality AI assisted development is simple — never commit code you cannot explain line by line to another engineer. That rule only gets harder to follow when an LLM is generating the code, which is exactly why frontier engineering requires more discipline than writing everything by hand.
What Changes in Practice
If Liguori’s manifesto gives you the why, here is the how — a practical framework for teams trying to make the leap from vibe coding to frontier engineering.
Architecture Becomes the Whole Job
When code is cheap to produce, the bottleneck shifts entirely to design. Which module boundaries do you draw? What are the failure modes? Where do you put the seams for testing? If you let an LLM generate a 2,000 line service without first defining the interfaces, error contracts, and data flow, you will get something that compiles, passes a few happy path tests, and collapses under the first edge case that matters.
AI makes the architect more important, not less. The engineer who can decompose a problem into small, well specified units — what Liguori calls work an agent can “carry through independently” — will get dramatically better output from every AI tool.
Code Review Becomes Adversarial
In a traditional PR review, you are reading code written by a colleague who roughly shares your mental model of the system. When reviewing LLM generated code, you are reviewing output from a system that has no memory of your architecture decisions, no awareness of your threat model, and a statistical tendency to produce code that looks right while hiding subtle flaws.
Liguori acknowledges this directly: review can be harder than writing code, particularly for early career engineers. Running multiple agents increases cognitive load. The teams that succeed invest in steering files and explicit validation criteria so agents return work that is already closer to correct — reducing the review burden rather than eliminating it.
Testing Becomes the Contract, Not the Afterthought
AI tools are phenomenal at generating tests. They can produce unit tests, integration tests, and property based tests faster than any human. But that velocity is a trap if you treat tests as validation rather than specification.
The frontier engineering workflow flips the script. You write the tests first — or at minimum, the test specifications — and the LLM generates the implementation. The tests become the contract. The AI’s job is to satisfy the contract. Your job is to verify that the contract actually captures what matters: edge cases, failure modes, security invariants, performance bounds.
As Willison put it: “Always review the assertions.” An LLM will happily generate 200 tests that all pass and none of which test anything meaningful.
The Three Lanes
For teams adopting AI coding assistants, I recommend a three lane model that makes the risk boundaries explicit:
Lane 1 — Throwaway (vibe code freely). Prototypes, spikes, internal demos, one off scripts, personal tooling. No production traffic, no customer data, no persistence. Vibe code to your heart’s content. This is where AI tools deliver the most joy and the most learning. Karpathy was right — for this lane, just let it rip.
Lane 2 — Guided (AI generates, humans verify). Feature branches, internal services, non critical paths. The LLM writes code against a well defined spec. Every diff gets reviewed. Every PR runs through CI with linting, SAST, and dependency scanning. No code merges unless a human can explain it. This is where Liguori’s five habits matter most — and where the 4.5× gains materialize.
Lane 3 — Restricted (humans lead, AI assists). Security sensitive code, authentication flows, data pipelines handling PII, financial transactions, anything subject to compliance. The LLM can suggest, autocomplete, and draft — but the engineer writes the critical paths by hand and the AI’s contributions get reviewed by a second engineer with domain expertise.
The key insight is that the lane is determined by the blast radius of a mistake, not by the difficulty of the code.
The Real Skill Is Knowing Which Lane You Are In
Liguori’s manifesto ends with an invitation: examine how your engineers interact with AI tools and identify what would let them step out of continuous intervention, freeing their attention for work that still needs their judgment. That is frontier engineering in one sentence.
The weeks you spend writing steering files, refactoring the codebase, and learning to decompose work for agents will feel slower. The weeks after will feel dramatically faster — because you are no longer building the software directly. You are building the agent setup that builds the software.
The cursor is not the problem. The question is what is behind it.