The AI SDLC — Why Everything Has to Change, and Yet Stay the Same

Part 1 of a 3-part series on the AI-driven software development lifecycle.

Overview

We are in the middle of one of humanity’s major transitions. We had the Industrial Revolution. We had the information revolution. We are now at the beginning of the AI revolution. Each revolution changed how we live. Each one arrived faster than the previous one. The software industry was the engine of the last revolution, and it is the first to feel the brunt of this one. We must evolve — and quickly — and adapt how we work, soon.

At ZioNet, we work with many customers, from small shops to large organizations with hundreds of developers and millions of lines of code. We work on both brownfield and greenfield projects. Over the past several months, I have helped multiple organizations deploy a new AI-integrated SDLC process. I call it a deployment, not a training program, because we don’t just teach — we analyze the customer’s systems, code, git history, DevOps, dev teams, lifecycle, technology, and organizational structure. We chose the AI toolbox. We help set up the AI code-agent environment: specs, skills, hooks, instructions at three levels — the individual developer, the team, and the organization. We set up AI-usage traceability, guardrails, and security boundaries. We handle hard cases like air-gapped systems and non-mainstream programming languages and frameworks.

AI SDLC trends, problems, and emerging solutions

There are many trends in AI-agentic code solutions, emerging from both major vendors and the community. Two trends stand out as the most important: vibe coding is not enough, and a single agent, however strong, does not provide what we need.

Vibe coding and its limits

Vibe coding is an approach that enables a developer to guide and accelerate the AI-assisted development process. The developer begins by analyzing the requirements, translating them into a structured sequence of AI prompts, managing the interaction with the AI agent, and reviewing the output at each stage until the feature is complete.

The quality of AI-generated code must be actively governed by the developer in two primary ways: by providing clear, precise, and context-aware instructions, and by challenging or correcting the AI agent when its output does not meet the required standards. As a result, the overall quality of the generated code is directly influenced by the developer's skill, judgment, and diligence in operating the AI agent.

The developer remains responsible for reviewing the generated code, understanding its design and implementation, validating its correctness, and ensuring that it satisfies the functional, technical, and quality requirements. Ultimately, accountability for the final result rests with the developer who directs the AI-assisted development process.

Vibe coding has real problems:

Prompt granularity. The developer can ask the AI to implement an entire feature in one go, only to face a lengthy process of understanding what changed and instructing the AI to fix each issue. Working in smaller baby steps makes control easier — but development velocity suffers.

We lose the intent. Vibe coding produces a solution backed by source code, but the code is just one manifestation of the actual intent. The requirements carry far more information than any single feature’s user story. We need the design decisions, the technology choices, the security model, the cross-cutting concerns — tracing, logging, error handling. These rarely fit within a specific feature’s requirements and often aren’t written down at all.

The first method to overcome vibe coding problems is to use a software specification, or spec in short.

A short time travel through abstractions

Let’s travel back through time.

The first analog computing machines had almost no abstraction. You could watch the system tick, the wheels rotate. The “program” was literally the machine’s static structure.

The first programmable mechanical machines — think of a music box where each pin in the cylinder strikes a different chime — introduced the lightest possible abstraction. Change the cylinder, get a different melody.

An assembler on a von Neumann machine moved the abstraction inside the CPU. Each assembler instruction is a pointer into a microcode table; each entry dictates which gates open in the CPU. The sequence of microcode operations moves information between memory, registers, the opcode translation unit, and the arithmetic logic unit (ALU). It’s a strong abstraction over the hardware — we ask the CPU to move a value into a register, and the CPU finds the right “pin wheel” and plays the melody. We can write assembler without peering into the silicon.

An Apple II Snake Game in 6502 Assembler

The C language changed everything again. Instead of running low-level assembly with manual loop counters (DEC to decrement a register, BNE to branch if not zero), we got while and for loops.

Productivity skyrocketed. Code became readable. Structured programming and, eventually, functional programming were born. One of C’s greatest features is that you can trace exactly how each construct is compiled down to assembler. A good developer knows at least one level of abstraction below the tool they use — and that habit makes them a better C developer too. (I wrote my first assembler programs on paper, debugged them on paper, then entered hex numbers into the machine. It was fun, but hard.)

Higher-level languages — C++, Java, C#, Python, JavaScript, TypeScript — further raised the level of abstraction. (Fun aside: the first C++ compiler, CFront, translated C++ to C — much like TypeScript compiles to JavaScript today. The argument was simple: we already knew how to compile C, so we only had to prove the new translation step.)

Alongside, we built low-code and no-code tools — Magic, Access, Excel, and Power Apps. They raised the level of abstraction even further and narrowed the kinds of applications they could build — but for the right problem, they are excellent.

Each advance traded control and visibility for productivity. We trust the abstraction to be efficient, secure, and not bite us. Take coroutines (async/await) for example: the compiler breaks a function into a state machine, yet our code reads sequentially. It works beautifully — until you hit a deadlock and have to open the engine hood. Good developers still need to understand the abstraction below the one they use.

We are now facing the next major jump in abstraction. We have a powerful new tool, fluent in all the deeper abstractions, that can do the programming for us — but we need a good way to tell it what to do. That is why Spec and Spec-Driven Development matter so much.

Attention, in the right places

The paper that made today’s AI so capable is titled “Attention Is All You Need” (Vaswani et al., 2017). But the principle applies to us too: we have to pay attention to the right places. The first place is the spec. The spec captures intent and the boundaries around it. In the old waterfall world, we wrote UML user stories up front. This was tedious work, and Agile has taught us not to write specs long before they are implemented. YAGNI — you ain’t gonna need it, and you ain’t gonna read it. The idea of a spec is to capture the important fact and provide precise information of one or more user stories, but we (the AI agent) write it just in time before the implementation.

What goes into a spec

A spec is more than a user story. It captures the intent of the feature, the design decisions that shape the implementation, the non-functional attributes — performance, security, observability — and the contracts and data shapes the code must honor.

In practice, these don’t live in a single document; they live as a small constellation of files, each with a clear job: a spec.md for the intent and acceptance scenarios, a plan.md for the implementation strategy, a tasks.md for the broken-down work, and a contracts/ folder for the interfaces and data models. Open-source toolkits like Spec Kit have begun codifying this shape so that any AI agent that follows the convention can pick up the work without bespoke instruction. The AI reads these files at session start, generates code against them, and updates them when the intent changes. Validators check that the code and the spec stay aligned. This is the bidirectional contract that makes Spec-Driven Development scale: humans steer the intent through the spec; the AI steers the implementation through the same spec.

Just-in-time spec — or “Vibe Specing.”

We don’t want to write the spec too far in advance of the AI implementing it. And we want to shape the spec by discussing it with the AI agent. I call this state Vibe Specing. You can vibe-spec with Copilot, Gemini, ChatGPT, Claude, or any AI chat agent. You can do it in context with GitHub Copilot, Claude Code, Codex, or Anti Gravity. But the state of mind matters more than the tool: no matter what I ask the AI to do, even when providing a ‘vibe’ instruction, it must first either update an existing spec or create a new one before implementing. The spec carries the intent — the recipe for building the code. The spec drives the code, tests, test coverage, and validation. And the spec must stay aligned with the code over time.

A spec captures intent in a way that embraces future change. With it, we can either recreate the system, migrate to new technology, or hand the spec to a future version of an AI code agent that will surely create a better solution.

How come a single agent isn’t enough — even with the best LLM we have?

The second important trend is to use sub-agents and to coordinate teams of AI code agents. There are many reasons why a single mighty agent doesn’t suffice.

An agentic system is built around an LLM that acts as the CPU of the agentic loop. We pass a context (text and images) to the LLM; the LLM’s first stage tokenizes everything, passes the tokens through its inference layers, and produces a sequence of output tokens, which are then translated back into text.

But what is in the context we send and receive? A set of instructions and data. The instructions are the intent — extracted from the user’s query or the spec — plus the environmental context the AI agent code injects. For example, the list of skills, the available MCP servers and their descriptions, and the system prompts that tell the LLM what to do when it can’t answer directly: it can ask the framework to use one of the tools in the provided list and then receive the result. Tools aren’t just for better context; they let the agent fulfill its goal — edit a text file, run a shell command, query a database.

Using an LLM as a stateless CPU — where each call recreates the context — scales beautifully from the LLM’s perspective. Requests wait in a queue and get served one by one. It is also a clean abstraction: as long as the model can handle the input format and was trained to call tools, we can swap models in and out.

Swapping models is one reason to use multiple agents. Any LLM is biased and opinionated. Its architecture shapes its capabilities, and it was trained with an opinionated dataset and instructions. Its existing knowledge is a blessing — and, in many cases, a curse. Smaller language models know less, so sometimes they follow instructions more cleanly, without baked-in presumptions about the context. We once built a legal evidence system that had to extract evidence from all kinds of media. The LLM decided that whenever it saw a yellow cab, the scene must be in New York City.

Having dedicated agents, each with its own language model, skill set, MCP servers, and instructions, can improve quality and control usage costs. Having a large model-based agent coordinate small model-based agents significantly reduces costs. The combination of an agent team coordinator and multiple specialized AI agents — each with distinct expertise and tools — is the foundation of the new AI agentic team. As a result, we increase productivity, reduce costs, and increase quality.

AI code agents such as Claude Code, Codex, and Copilot are the operating system for the agentic team. They provide the ability to read instruction files, to run scripts on specific events (hooks), and to add skills and the MCP server to the context. A new kind of AI agentic tool is emerging — tools to control context and tools to control the agent teams.

The developer’s new role: plan, steer, control, take responsibility

With the emergence of AI code agents and these two major trends — Spec-Driven Development and agent teams — the developer’s role has changed. We are no longer the doers; we are the thinkers and the rulers.

For a small pet project, vibe coding or simple SDD can be easy to manage. For a large project — sometimes a brownfield with millions of lines of code — that isn’t enough. When we have a team of human developers, each running their own team of AI agents, the programming velocity becomes so high that it is very easy to break the system. We need a structured, firm SDLC — without losing the agile advantage or slowing AI down.

Why SDD + agent teams are still not enough

We have seen why Spec-Driven Development beats vibe coding, and why Just-in-Time Specs leverage the power of specification without losing agile’s strengths. But when we look at Agile — particularly at SCRUM practices — it isn’t mainly about requirements or how to write the code. Agile is about how to drive the development process — the lifecycle. And that lifecycle management is the missing link between specs, agent teams, human developers, and a genuinely high-quality solution.

AI agent tools today offer some level of process management — they have /plan, they follow steps. But the out-of-the-box solution is rudimentary. The good news is that these AI tools also expose the means to build a governance and process layer on top: prompt files, hooks, skills, MCP servers, and other primitives we can compose into real frameworks.

The solution: a governance layer

As a developer, architect, or team lead, ask yourself what you need to know before work begins, during development, and when a feature is ready. At which points should the system stop and wait for your approval?

This governance layer is the missing piece in combining Spec-Driven Development with agent teams. It assigns management roles to different agents, drives the SDLC, and enforces guardrails and quality gates.

In Part 2 of this series, I’ll show what this governance layer looks like in practice — the layer that connects specs, agent teams, human developers, and software discipline. I’ll also introduce Specrew, the meta-framework I’ve been building and testing to bridge that gap.