From Vibe Coding to AI SDLC: Building Production-Ready Software with AI

During a recent business meeting for AWS AI Day, I noticed one idea appearing across several sessions: AI is becoming remarkably good at writing code, but turning that code into a system that can run reliably in production is still a very different challenge.

Opening Claude Code or another coding agent and asking it to implement a feature is now easy. Producing a working prototype in a few minutes is no longer unusual.

However, the situation changes when the codebase grows, multiple developers become involved, requirements keep evolving, and the system must be maintained for years. This is where an informal approach such as vibe coding begins to reveal its limitations.

The issue is not simply whether AI can generate code. The real issue is that we often give AI too much decision-making authority without establishing a clear way to control and verify its work:

• How does the AI understand the requirement?
• What assumptions is it making?
• How do we know the implementation is correct?
• When a requirement changes, what should be updated first?
• Who is ultimately responsible for the code being merged?

One practical answer is to move from vibe coding toward an AI SDLC built around spec-driven development, verification and harness engineering.

What Is AI SDLC?

AI SDLC is an approach that integrates AI throughout the software development lifecycle, from requirement analysis and system design to implementation, testing, deployment and operations.

This does not mean allowing AI to run the entire development process independently. Instead, AI assists at each stage while working within clear specifications, engineering controls and human oversight.

A simplified AI SDLC framework might look like this:

Business Intent → Specification → Design and Architecture → AI Construction → Verification → Production

Each stage produces information that guides the next one. This reduces the risk of AI filling requirement gaps with assumptions or generating code that works in isolation but does not fit the wider system.

Moving from Prompt-Driven to Spec-Driven Development

Many people still think working with AI means writing a prompt and waiting for code to appear.

This may work for small experiments, but software projects involve more than implementation. Information must move between business analysts, architects, developers, QA engineers and operations teams. When that information is incomplete or interpreted differently, problems appear later in development or production.

Spec-driven development provides a more reliable foundation for using AI in the SDLC.

Instead of asking an AI coding agent to start implementing immediately, humans and AI first establish a technical specification. This specification acts as a behavioral contract for the feature.

The specification does not need to be a long Word document. It can consist of structured Markdown files stored directly in the repository, such as:

spec.md

design.md

api-contract.md

acceptance-criteria.md

The important point is that the specification captures information that might otherwise remain scattered across meetings, tickets, conversations or individual team members’ knowledge.

A useful specification should answer questions such as:

• What business problem does this feature solve?
• What are the expected inputs and outputs?
• What is the API contract?
• What data schema should be used?
• Which validation rules must be applied?
• What security constraints exist?
• What level of performance is expected?
• Which edge cases must be handled?
• What conditions define success or failure?

The spec becomes a shared point for both humans and AI. The flow can be visualized simply as follows:

How AI SDLC Works Across the Development Lifecycle

An effective AI SDLC does not introduce AI only at the coding stage. AI can support requirement review, implementation, testing and operations, provided that each stage has clear boundaries.

1. Inception: Clarify the Requirement Before Coding

At the beginning of a feature, AI can act as a requirement reviewer.

Instead of immediately asking it to write code, the team can ask the agent to identify:

• Ambiguous requirements
• Missing business rules
• Conflicting conditions
• Undefined edge cases
• Assumptions the implementation would otherwise need to make

This may sound simple, but it can produce more value than generating hundreds of lines of code.

Many production bugs are not caused by incorrect syntax. They happen because different people understand the same requirement differently. If AI can help expose those gaps before implementation begins, the team can prevent expensive rework later.

2. Construction: Implement Against the Specification

Once the specification is sufficiently clear, the AI coding agent can begin implementation.

At this stage, it may be allowed to:

• Read the relevant specification
• Analyse the existing codebase
• Break the feature into smaller tasks
• Propose a technical design
• Implement the code
• Write database migrations
• Update APIs
• Generate tests

The difference from vibe coding is that AI is no longer deciding the objective by itself. It has a clear contract to follow.

Instead of using a broad prompt such as:

• Implement user registration.
• The team could provide a more controlled instruction:
• Implement the user registration flow described in
• specs/user-registration.md.

Before coding:

• Identify the affected components.
• List any assumptions.
• Generate test cases from the acceptance criteria.
• Implement the feature.
• Run the tests.
• Report any deviations from the specification.

The agent still has enough freedom to complete the task, but the scope of its decisions is better controlled.

3. Operations and Observability: Give AI a Way to Verify Its Work

Harness engineering is another important part of an AI-first software delivery process.

Rather than giving an agent permission only to read and write code, we should provide an environment in which it can execute and verify its own output.

Depending on the project, the agent may be able to run:

• Unit tests
• Integration tests
• Type checking
• Linting
• Builds
• Security scans

The workflow then becomes:

Specification → AI writes code → Tests run → Failure detected → AI analyses the error → Code is corrected → Tests run again

This is an important shift.

If AI only generates code and a developer must manually test every output, then AI is still functioning mainly as a code generator.

When the agent can implement, execute, observe and fix, it begins to operate more like an engineering agent. However, it still works within boundaries established by the development team.

Why Test-Driven Development Works Well with AI Coding Agents

Test-driven development becomes particularly useful when combined with AI coding agents.

The tests can be generated from the specification before the implementation is written. This helps keep the requirement, tests and code aligned.

For example, imagine a specification containing the following discount rules:

Discount rules:

- Minimum discount: 0%

- Maximum discount: 50%

- GOLD users receive an additional 10%

- The total discount must never exceed 50%

Before writing the implementation, the agent could generate test cases for:

0%

10%

50%

51%

Negative values

A GOLD user

A GOLD user already receiving a 50% discount

Only after these conditions have been translated into tests should implementation begin.

The key advantage is that the tests are not derived from the code. The tests and the code are both derived from the same specification.

This reduces the chance that the implementation technically works while behaving differently from the original requirement.

Property-Based Testing Can Add Another Verification Layer

Property-based testing may also work well in an AI SDLC.

Traditional tests often validate a few specific inputs:

add(1, 2) = 3
add(10, 20) = 30

Property-based testing defines a general rule instead:

For any integers a and b:

add(a, b) = add(b, a)

The testing framework then generates many different inputs to verify that the rule continues to hold.

This is useful because AI coding agents are often effective at handling the expected path but may still overlook unusual combinations or edge cases. Property-based testing introduces another verification layer that can expose cases neither the developer nor the agent initially considered.

Four AI Coding Anti-Patterns to Avoid

Teams sometimes find that the more they use AI, the more time they spend reviewing and correcting its output. This often happens because of the way AI coding agents are configured and used.

Anti-Pattern 1: Filling the Context Window with Irrelevant Information

When an AI agent produces an incorrect answer, a common reaction is to assume that it needs more context.

The team then adds:

README
architecture docs
database schema
50 source files
API docs
meeting notes
Slack conversation

However, more context does not automatically create better understanding.

When important information is buried among many unrelated files, the model must still determine which information matters to the current task.

A better principle is minimum sufficient context.

For example, fixing an authentication issue might require only:

auth spec
auth middleware
user model
relevant tests
API contract

The agent should receive enough information to complete the task, but not the entire repository by default.

Anti-Pattern 2: Skipping Harness Engineering and TDD

If an agent can only

read code
write code

Then, developers still have to act as manual test runners. A more useful AI development environment should allow the agent to:

Read
Write
Execute
Observe
Verify

The agent needs more than tools for creating output. It also needs tools that help determine whether the output is correct.

Without that verification loop, teams can generate code faster while also increasing the amount of review and rework required.

Anti-Pattern 3: Giving One Agent Too Many Tools and Skills

When teams begin working with AI agents, it is easy to assume:

More tools = a smarter agent

The agent is then equipped with:

• GitHub MCP
• Jira MCP
• Slack MCP
• Database MCP
• AWS MCP
• Browser
• Docs
• 20 custom tools…

However, an agent with 30 tools is not necessarily more effective than an agent with five tools selected for a specific task. Too many tools create another decision problem: the agent must determine which tool to use and when.

A better approach is to assign tools according to a role or workflow.

For example:

Coding Agent
├── File system
├── Git
├── Test runner
└── Documentation

Operations Agent
├── AWS
├── Kubernetes
├── Logs
└── Monitoring

This is generally safer and easier to control than creating one super-agent with access to every system.

Anti-Pattern 4: Measuring Productivity by Lines of Code

Lines of code will become an increasingly weak productivity metric.

An AI coding agent can generate thousands of lines in a few minutes. The more important questions are:

• Does the feature behave correctly?
• Has the regression rate changed?
• Has lead time decreased?
• Have production incidents increased?
• Do developers understand the code being merged?
• Can the system be maintained safely?

If AI triples the amount of code but also triples the review time, the team may not have improved productivity at all.

A more meaningful measure is:

Working software delivered end to end.

Developers Must Remain the Owners and Verifiers

I don’t think a coding agent should be viewed as an independent senior engineer. While it can write code very quickly, it bears no responsibility for architectural decisions, trade-offs, or production incidents. Therefore, the developer must remain the ultimate owner, who understanding requirements, overseeing the design, and verifying the output before merging.

Frequently Asked Questions