Todd Stuvé ‹ all explainers

Google whitepaper · plain-English guide

From writing code to expressing intent

The software lifecycle is being rebuilt around AI. You describe what to build; intelligent systems turn that intent into working software. Here is the whole picture, made simple.

An abstract crystalline wave in cobalt and violet that breaks apart into small glass cubes, evoking the shift in how software gets built.
The biggest shift in software is not a new language or framework. It is moving from writing code to expressing intent, and trusting AI to turn that intent into working software.
85%
of professional developers use AI coding agents
51%
use them every day
~41%
of all new code is AI-generated

As of early 2026, per the paper. The change is already here, not coming.

How we got here

Four steps, from autocomplete to autonomy

It crept up one capability at a time, until the machine could do the whole job.

A left-to-right timeline: Autocomplete around 2021, Inline code suggestions 2022, Chat-based generation 2023, Coding agents 2024 to 2025, and Autonomous agents 2025 to 2026. An arrow below runs from Syntax and more human effort to Intent and more machine autonomy.
Figure 1. Each generation kept what came before and raised the ceiling on what one engineer could do, sliding from syntax toward intent.

The core idea

Vibe coding to agentic engineering: a spectrum

These are not two camps. They are two ends of one line. The real question is not whether you use AI. It is how much structure, verification, and human judgment surround its output.

A red-to-blue gradient bar. Left end labeled Vibe Coding, casual prompts, does it seem to work, disposable code. Middle labeled Structured AI-Assisted, detailed prompts plus constraints, manual testing, features in established codebases. Right end labeled Agentic Engineering, formal specs plus architecture docs, automated evals plus CI/CD gates, production systems at scale. Left to right runs from less structure more speed to more structure more reliability.
Figure 3. The differentiator is not whether you use AI. It is how outputs get verified.

Vibe coding

Describe it in plain words, accept what comes back, paste the error in when it breaks. Fast, loose, often you do not read the code.

prototypes · scripts · hackathons

high risk, fine for disposable code

Structured AI-assisted

Detailed prompts with constraints, manual testing, selective review of the critical paths. Human judgment at the key checkpoints.

features in an existing codebase

moderate risk, the everyday middle

Agentic engineering

Formal specs, architecture docs, memory files. Automated test and eval suites, CI/CD gates. AI implements inside human-designed limits.

production · team scale

low risk, verified at every stage

What actually separates the two ends: verification. Tests check the deterministic parts (this input gives that output). Evals check the judgment parts (did the agent take the right steps and meet the quality bar). Without both, it is vibe coding, no matter how clever the prompts.

What is doing the work

The agent, and the skill of feeding it

An agent is not a chatbot. It runs its own loop. And the quality of what it builds depends less on clever prompts than on the context you give it.

The engine

An agent runs a loop

Give it a goal at the top, and it decides each next move on its own.

A circular loop diagram: perceive the goal, plan the steps, act through tools, observe the results, then iterate, repeating until the goal is met or a stopping condition is hit.
Figure 2. Perceive, plan, act, observe, iterate. Every agent is a variation on this loop, built from five parts: the model (reasoning), tools (its reach into the world), memory (state), orchestration (the code running the loop), and deployment (what makes it a real service).

The real skill

Context engineering beats prompt engineering

Models do not need clever wording. They need what a good new teammate would need to do the work.

A diagram splitting context into two columns. Static context, always loaded: system instructions, rule files like AGENTS.md and CLAUDE.md, global memory, persona. Dynamic context, loaded on demand: skill instructions, tool results, retrieved documents, windowed session history.
Figure 4. Static context is always loaded and costs tokens every time. Dynamic context loads only when a task needs it. Deciding what goes where is a real engineering trade-off.

Six kinds of context every agent needs: instructions (its role and limits), knowledge (docs and data), memory (what just happened and what the project is), examples, tools, and guardrails. The pattern that scales this is Skills: portable packages the agent loads only when the task calls for it, so it stays a lightweight generalist that flexes into a specialist on demand.

The lifecycle, reshaped

Every phase changes, but not evenly

Implementation that took weeks now takes hours. Requirements, architecture, and verification stay stubbornly human-paced. The result is not a faster old SDLC. It is a different workflow.

A side-by-side comparison of the traditional sequential SDLC against the AI-driven SDLC, where phase boundaries blur, iteration cycles shorten from weeks to minutes, and the developer shifts from implementor to system designer and quality arbiter.
Figure 5. Traditional SDLC versus AI-driven SDLC. Boundaries between phases blur and cycles shrink from weeks to minutes.

Requirements

From a document handed between teams to a conversation with AI that produces the spec and a working prototype at the same time.

Design & architecture

The most human phase. AI implements decisions fast, but the trade-offs stay yours to make and document.

Implementation

Real 25 to 39% gains, but one study found experts took 19% longer on some tasks. The work shifts from writing to reviewing and guiding.

Testing & QA

Check the result and the path it took. Tests and evals become the main way you tell the AI what "correct" means.

Review & deploy

AI is the first-pass reviewer for bugs, style, and security. Pipelines get AI-aware: monitor health, predict risk, auto-roll-back.

Maintenance

The most underrated shift. Code "too risky to touch" can now be read, refactored, and migrated. Old technical debt finally gets paid.

The mental model

Build the system that builds the software

Your main output stops being code. It becomes the factory that produces code: the specs, the agents, the tests, the feedback loops, the guardrails.

A factory diagram. A Developer Zone on top: define specs, design guardrails, review and approve. An Agent Factory Floor below: specs and requirements feed a Planning Agent, then a Coding Agent, then Tests and Verification, which either pass to Verified Output or send failure feedback back to the agents. Guardrails of token limits, security policies, style rules, and architectural constraints run underneath.
Figure 6. You design the line and own quality control. Agents produce the code; tests verify it; failures route back automatically. Give agents success criteria, not step-by-step instructions.

The machine on the floor

Agent = model + harness

The model is just the raw engine. The harness is everything wrapped around it that lets it finish the job.

A diagram of the harness around a central model: instructions and rule files, tools, sandboxes and execution environments, orchestration logic, guardrails and hooks, and observability. Together the model plus the harness make an agent.
Figure 7. The harness is the rules, tools, sandboxes, orchestration, guardrails, and observability around the model. It belongs to your team, not the model provider.

How much the harness matters: one team moved a coding agent from outside the Top 30 to the Top 5 on a public benchmark by changing only the harness, with no model change at all. The everyday lesson: when an agent does something wrong, you blame the model first, but most agent failures are configuration failures, a missing tool, a vague rule, an absent guardrail, or a context window stuffed with noise.

Your evolving role

Conductor and orchestrator

Two modes you move between. Hands-on the keys, or directing a team of agents working in the background.

A two-mode comparison. Conductor: a developer in the IDE directing an AI pair-programmer in real time, watching code appear. Orchestrator: a developer at a higher level defining goals and assigning them to multiple agents working in parallel in the background, then reviewing results.
Figure 8. Conductor versus orchestrator: two modes of working with AI agents.

Conductor: hands-on, real-time

In the IDE, guiding the AI keystroke by keystroke. Natural for complex logic, tricky debugging, and unfamiliar code where you need to understand each change. The risk: you become the bottleneck.

Orchestrator: async, delegated

Define goals, hand them to agents working in parallel, review the output. Fits well-specified work: bug fixes, migrations, test generation. Demands new skills: specification, decomposition, evaluation, system design.

The 80% problem: agents quickly produce about 80% of a feature. The last 20%, the edge cases, error handling, and subtle correctness, needs deep context the model often lacks. The errors are sneaky because the code "looks right." The winning posture: use AI for what it is good at, and spend your attention where it struggles.

The money

Low cost to start is not low cost to own

For leaders, velocity is the wrong headline. Total cost of ownership is the real one, and the bill shows up later.

A diagram contrasting the economics of vibe coding, low capital expenditure but high operational expenditure, against agentic engineering, high capital expenditure but low operational expenditure, with the token economy driving ongoing cost.
Figure 9. The economics flip depending on how much you invest upfront.

Vibe coding: low CapEx, high OpEx

Nearly free to start. But it hides a compounding bill: token burn from unstructured prompt-and-fix loops, a maintenance tax when humans reverse-engineer the "spaghetti" months later, and costly security fixes in production.

the hidden debt

Agentic engineering: high CapEx, low OpEx

A deliberate upfront investment: API schemas, test suites, structured context. The marginal cost of shipping and maintaining each feature then drops sharply, because output is structurally sound and pre-tested.

the investment

Context engineering is a financial lever. A dense, high-signal payload raises the agent's first-pass success rate and avoids expensive trial-and-error. Model routing compounds it: big models for hard work, cheap fast models for test generation, review, and CI monitoring.

Where to start

The move that turns vibes into engineering

You do not need a transformation program. You need a few habits, starting this week.

Do this

  • Write a 10-line AGENTS.md: stack, conventions, hard rules, workflow
  • Write the tests and evals before the code. They are your contract with the AI
  • Pick one repetitive workflow and make it your first agent
  • Review every line that ships. Be skeptical of anything that looks clever
  • Keep your own debugging and design skills sharp

Not this

  • Vibe coding your payment processing or anything in production
  • Accepting whatever the AI returns without reading it
  • Shipping with no eval suite and no clear rubric
  • Blaming the model before checking the harness
  • Letting prototype and production work blur together
1

Structure scales, vibes don't

Vibes are fine for exploring. For software people depend on, the discipline is not optional.

2

AI amplifies your culture

It multiplies strong testing and clear standards, and it multiplies their absence just as fast.

3

Your role is evolving, not ending

The skill shifts from writing code to judgment: specs, evaluation, and designing the system.

Generation is solved. Verification, judgment, and direction are the new craft.

From "The New SDLC With Vibe Coding" · Osmani, Saboo & Kartakis · Google, May 2026