The new development lifecycle: from “vibe coding” to agentic engineering

For decades, programming meant writing code: translating an idea, line by line, into a language the machine understands. That assumption is collapsing. With AI agents able to generate functions, modules, and entire systems from a description, the slowest part of the work (typing) is no longer the bottleneck. What changes when generating code becomes cheap and abundant? Everything that comes before and after it.

In its whitepaper The New SDLC With Vibe Coding, Google frames this turn as a shift “from writing code to expressing intent.” Generation, the authors argue, is essentially solved. What remains as craft (and as competitive edge) is something else: verifying, judging, and directing. This article is a synthesis of that map, generalized beyond code: it applies to anyone building agentic systems, including AI assistants in production.

Generation is solved. Verification, judgment, and direction are the new craft.Google · The New SDLC With Vibe Coding

A spectrum, not a border

It's tempting to set “vibe coding” (improvising with the AI, accepting whatever it spits out) against “real engineering.” But the document treats both as points on one spectrum, with structured AI-assisted coding in the middle. What changes along that axis is how much structure, verification, and human judgment surround what the AI produces.

• Vibe coding: fast and exploratory. You describe, the AI generates, you test by feel. Great for prototypes and throwaways; risky for anything headed to production.
• Structured AI-assisted coding: the AI generates, but on rails (rule files, defined patterns, deliberate review of every change).
• Agentic engineering: the AI operates inside a system of verification, context, and governance that you designed; the output is trustworthy because the surroundings make it so.

Neither end is “right” in the absolute. Improvisation is legitimate for discovering an idea; engineering is mandatory for keeping it alive. Maturity is knowing where on the spectrum you need to be for each task, and raising the level of rigor as risk goes up.

Verification is the great divide

If generation got easy, trusting it is the hard part. Google names verification as the biggest differentiator between playing with the AI and engineering with it, and notes that some code behaves deterministically and some does not. These are two distinct verification regimes:

• Tests verify the deterministic part: given the same input, the output should always be the same. This is the classic territory of unit and integration tests.
• Evaluations (evals) verify the non-deterministic part: the trajectory the agent took, the tools it chose, the quality of the result. When there's no single “right” answer, you evaluate instead of assert.

This distinction is the heart of agentic engineering. An agent that does the right thing for the wrong reason (or via a brittle path) will fail when context shifts. Evaluating trajectory and tool choice, not just the final output, is what separates a robust system from a demo trick.

Context engineering: the skill that truly matters

If one competency defines the professional of this era, the whitepaper is clear: it's context engineering. The model is capable; what decides output quality is the right information, in the right format, at the right time. Google organizes that context into six types:

• Instructions: what the agent should do and how to behave.
• Knowledge: the facts and documents it needs to ground answers.
• Memory: what persists across interactions and sessions.
• Examples: concrete cases that demonstrate the expected result.
• Tools: the actions it can perform in the world.
• Guardrails: the limits that constrain what it can and cannot do.

Some of that context is static (always true) and some is dynamic (loaded per task). Hence the idea of “Agent Skills”: portable packages of procedural knowledge (how to perform a specific task), loaded only when needed. This is progressive disclosure: instead of stacking everything into context, you deliver just what the task at hand requires, keeping the agent focused and cheap.

The lifecycle compresses unevenly

A common mistake is to imagine AI speeds up development evenly. It doesn't. The whitepaper shows it compresses the lifecycle unevenly: implementation, which once took days, collapses to hours; but requirements, architecture, and verification stay human-paced, because they depend on judgment, business context, and accountability. When typing disappears, the work of thinking and validating doesn't disappear with it; if anything, it grows in proportion.

Hence what the document calls the “Factory Model”: the professional's real output stops being the work itself and becomes the system that produces the work. You no longer ship just a function: you ship the prompts, the rules, the eval suites, and the skills that make the agent produce that function reliably, repeatably, and auditably. The valuable artifact has moved from the output to the machine that generates the output.

Two roles: conductor and orchestrator

Running this work calls for different postures depending on scale. Google describes two complementary modes:

• Conductor: synchronous work, inside the IDE, directing one agent in real time, reviewing, correcting, and adjusting course step by step.
• Orchestrator: asynchronous work, delegating to several agents in parallel and evaluating what comes back. Less typing, more coordination and judgment.

The career arc, in this reading, is the move from doing the execution to directing it. The value isn't in producing more lines, but in designing and governing the system that produces them.

The risks: the “80% problem” and governance

None of this is magic, and the whitepaper sells no illusion. It names the “80% problem”: AI gets fast to a nearly finished version, but the final 20% (edge cases, integration, robustness, security) still costs dearly and demands people. And it goes further in diagnosing where failures come from: most agent failures are configuration failures (poorly assembled context, ambiguous instructions, wrong tools), not model limitations.

The practical upshot is direct: prompts, rule files, eval suites, and skill libraries should be treated as infrastructure (versioned, reviewed, and owned). They aren't disposable drafts; they're the fabric that makes the system trustworthy. The numbers reinforce the caution:

• As of early 2026, about 85% of professional developers regularly use AI coding agents, and roughly 41% of new code is AI-generated.
• A METR study found experienced developers taking 19% longer on some tasks, the cost of verification, which grows when you have to check what the machine produced.
• The document's summary is uncomfortable and honest: AI is a force multiplier; it multiplies both your strengths and your weaknesses.

The same principle, beyond code: Charla

This map isn't just for people who write software. It applies to those who build and operate AI assistants, and that's exactly where Charla sits. The premise is the same as the new SDLC: generating is the easy part; the craft is surrounding the AI's output with context, verification, and governance. Charla lets you assemble and run agentic assistants without rebuilding the substrate every time.

• Per-assistant custom skills: capabilities packaged as portable instructions and resources, loaded on demand, the same progressive-disclosure idea Google describes.
• Connection via MCP: integration with external systems through MCP, an open interoperability standard, rather than ad hoc integrations locked to each case.
• Meta Charla: a reusable, already-seeded template, a starting point for new assistants instead of beginning from scratch.
• Human governance: a propose-then-approve posture and an append-only audit log keep people in command of what the AI produces.

It's the whitepaper's reading applied to operations, not just code: the AI generates; people direct, verify, and answer for the result. Charla exists to make that arrangement concrete: skills as versionable infrastructure, integration via an open standard, human approval before effect, and an auditable trail after it.

The conclusion of the new development lifecycle is, deep down, liberating. If generation is solved, what remains is what was always hardest (and most human): knowing what to build, deciding whether it's right, and owning the result. Typing stopped being the job. Directing, verifying, and judging are. That's the new craft, in code and in operations.