DEV Community: Akhil Kalra

What Comes After Agile?

Akhil Kalra — Mon, 27 Apr 2026 13:59:28 +0000

TL;DR — AI-augmented Agile is where most teams are today: same sprints, same standups, just faster. But when agents start executing entire implementations from specs, the Agile framework — not its values — stops making sense. What emerges is a new paradigm: Intent-Driven Development. Small teams of 3–4 experts focused on what to build, while agents handle the how. Iteration shifts from code to specs. Cycles compress from weeks to hours. The spec becomes the primary artifact — not documentation, but the input to the machine.

Humans own intent. Agents own execution. Specs are the contract between them.

For 25 years, Agile has been the dominant way we build software. It replaced Waterfall's rigid plans with iteration, feedback, and small empowered teams. It worked — because the bottleneck was clear: skilled humans translating requirements into code is slow, expensive, and error-prone. Every Agile practice exists to manage that constraint.

Now AI is changing the constraint itself. And the industry is responding in two distinct phases. But first, a key nuance: Agile was born as a reaction to Big Design Up Front. Spec-driven development with agents seems to swing back toward specs — but agent-era specs aren't the heavyweight, static documents of the Waterfall era. They're lightweight, living, executable artifacts. You're taking the user stories and acceptance criteria that Agile teams already write and making them precise enough for an agent to execute. The spec isn't documentation anymore — it's the input to the machine. That changes everything.

Phase 1: Where We Are Today — AI Inside the Agile Box

Most teams right now are doing the sensible thing: plugging AI into their existing Agile workflows. And it's genuinely useful.

Backlog cleanup. AI summarizes stale tickets, groups duplicates, flags high-risk stories based on past delivery patterns. Teams report saving 5–6 hours per sprint just on backlog hygiene.
First-draft artifacts. AI generates acceptance criteria from vague feature requests, rewrites tickets for clarity, suggests test cases. Developers review and refine.
Flow visibility. Early adopters are starting to move beyond velocity, using AI-generated bottleneck summaries to track cycle time and flow efficiency. This isn't mainstream yet, but the teams experimenting with it report sharper retro conversations almost immediately.
Emerging hybrid roles. We're beginning to see developers pick up prompt engineering as a side skill. Scrum Masters experimenting with training AI agents. Product Owners exploring AI-generated insights for backlog prioritization. The roles haven't formally changed yet — but the boundaries are starting to blur.

This is real. Productivity gains of 20–50% on routine tasks are well-documented. The Agile container — sprints, standups, retros, story points — stays intact. AI just makes everything inside it faster.

But making Agile faster doesn't change what Agile is. The team is still 5–7 people. The iteration is still 2 weeks. The bottleneck is still human coding throughput. It's a better engine in the same car.

The question is: what happens when the engine changes so fundamentally that the car doesn't make sense anymore?

Phase 2: Where We're Headed — Intent-Driven Development

Here's what I'm starting to see in practice: AI agents that don't just assist with coding but execute entire implementations from specifications. You give them a well-written spec — with constraints, edge cases, acceptance criteria — and they produce working code, tests, and infrastructure.

When that works reliably, the assumptions Agile was built on stop holding:

If agents write the code, I don't need three backend developers on my team.
If agents generate tests, I don't need a dedicated QA engineer.
If execution takes hours instead of weeks, two-week sprints are an artificial constraint.
If the spec is the input to the machine, story points measuring human effort are meaningless.

This isn't a tweak to Agile. It's a different paradigm. I've been calling it Intent-Driven Development — because the core activity shifts from writing code to expressing intent.

The Core Loop

The traditional Agile cycle — Plan → Design → Develop → Test → Review → Deploy — compresses into five steps:

Discover — Understand the problem deeply. Talk to users, map the domain, identify constraints. This is pure human work, and it's where the real value starts.
Specify — Translate that understanding into precise, executable specs. This is the hardest step — and the one most teams underestimate. A vague spec produces vague code, no matter how good the agent is.
Generate — Agents produce code, tests, and infrastructure from the spec. This is where the machine takes over.
Evaluate — Review the output against intent. This isn't a code review — it's an intent review. Did the spec produce the right thing? If not, you don't debug. You refine the spec.
Integrate — Ship, observe in production, learn. Part human judgment on what goes live, part agent-driven CI/CD.

That inner loop between Evaluate and Specify — refine the spec, regenerate, evaluate again — is where the real iteration happens. And it takes hours, not weeks.

The loop: Discover → Specify → Generate → Evaluate → Integrate → repeat. Three human steps, one agent step, one hybrid. When the output doesn't match intent, you don't debug code — you refine the spec and regenerate.

The Team I'd Build Today

If I were staffing a product team from scratch right now — knowing where this is headed — I wouldn't build a classic Agile team of 5–7. I'd build a team of 3–4 experts:

Role	Focus
Domain Expert	The Why — understands users, the business, and asks the hard "what if?" questions
System Architect	The Boundaries — defines integrations, constraints, non-functional requirements, and the guardrails agents work within
Spec Engineer	The What — translates intent into precise, executable specifications that agents can act on
Quality Thinker	The What-If — edge cases, failure modes, security implications, observability

Notice what's missing: nobody on this team writes code as their primary job. Everyone works on what to build and why. The how is delegated to agents. This isn't downsizing — it's a fundamentally different kind of team, and every person on it needs to be senior enough to think in systems.

What Survives, What Doesn't

✓ Survives	✕ Doesn't Survive
Iteration and feedback loops	2-week sprints
Retrospectives (as "spec quality reviews")	Story points and velocity
Continuous delivery	Daily standups about code
Cross-functional ownership	Dedicated QA roles
	The 5–7 person team

The Questions That Keep Me Up

I'd be dishonest if I presented this as pure upside. There are real risks here, and as an architect, they're the ones I think about most:

How do we grow the next generation?

We've seen this before. When cloud replaced on-premise infrastructure, an entire generation of engineers never learned to rack servers or configure physical switches. That skill became irrelevant — and that was fine. New entry points emerged around cloud-native thinking, IaC, and DevOps. The industry adapted.

Writing code by hand may follow the same path. The real concern isn't that juniors won't learn to code — it's that they won't learn to think in systems. Understanding how components interact, where failure modes hide, what trade-offs matter — that's the skill that matters, and it's harder to teach without getting your hands dirty. We'll need to deliberately design new apprenticeship paths around spec writing, system reasoning, and evaluating agent output. That won't emerge on its own.

Spec debt will be worse than tech debt.

I've seen what happens when teams accumulate bad code. Now imagine accumulating bad specs — except each one generates bad code at machine speed. The discipline of precise specification becomes the single most important skill in software engineering.

Speed is not the same as correctness.

I've watched teams celebrate shipping fast while building the wrong thing. Agents amplify this risk. Garbage specs produce garbage at scale. The teams that were already bad at writing clear requirements will be bad at this too — just faster.

Who debugs production at 3 AM?

This is the one that worries me most. If nobody on the team wrote the code, does anyone truly understand the system well enough to diagnose a cascading failure under pressure? There's a real risk of building systems that nobody fully comprehends. Isn't that terrifying for a DevOps team?

Where This Leaves Us

Agile's values — iteration, feedback, collaboration, responding to change — are more relevant than ever. Agile's framework — sprints, points, standups, the 7-person team — was built for a world where humans write code. That world is ending.

What comes next might be closer to what architecture was always supposed to be: small teams of experts, thinking deeply about the right thing to build, and letting the machines handle the rest.

Humans own intent. Agents own execution. Specs are the contract between them.

Stop Vibing. Start Specifying.

Akhil Kalra — Sun, 19 Apr 2026 13:18:00 +0000

Vibe coding got you here fast. Spec-Driven Development keeps you from rebuilding everything in 18 months. Here's the honest case for making the switch — and how tools like Kiro and Claude make it practical.

~3 min read · Senior Architect's Perspective

TL;DR

Vibe coding (prompt → code) is great for prototypes and solo work — but doesn't scale to production teams or long-lived systems.
Its core flaw: the AI has no memory of your architectural decisions, so every session risks contradicting the last.
Spec-Driven Development (SDD) fixes this by making a machine-readable spec the persistent context for every AI code generation call.
The spec encodes your domain boundaries, layer rules, and security requirements — so the AI executes a plan, not a guess.
Kiro manages specs as repo artefacts; Claude authors and reasons over them. Together they cover the full workflow.
Start with three files: a domain model spec, an ADR set, and a security NFR catalogue. One sprint is enough to begin.

Velocity without direction is just fast drift

Vibe coding works. Until it doesn't. The inflection point is usually around the time you need your second engineer, your first compliance audit, or your third refactor of the same module.

Describing what you want in plain language and watching an AI build it is genuinely powerful. Prototypes that took days now take hours. That is real. But an LLM generating code has no memory of the architectural decisions you made last week, no awareness of the security boundary your team agreed to, and no stake in the codebase's health six months from now. It optimises for the prompt. Every time.

The result is not bad code, exactly. It's code that makes local sense but accumulates global incoherence — business logic bleeding into HTTP handlers, no consistent layering, security rules applied in some places but not others. Technical debt at machine speed.

	🟠 Vibe Coding	🟢 Spec-Driven Development
Approach	Prompt → code, right now	Spec → constrained code
Strengths	Extremely fast first draft	Slower start, faster long term
	Great for PoCs and solo work	Built for team + production
	Low barrier to entry	Architectural rules enforced
	AI fills architectural gaps	AI executes a human-authored plan
Risks	⚠️ No persistent design intent	✅ Security as a first-class input
	⚠️ Compounds into mixed concerns	✅ Spec is the persistent memory

What Spec-Driven Development actually means

SDD is not a framework, a tool, or a process overhaul. It is one discipline: write a machine-readable specification before you prompt the AI to generate code — and feed that spec as context on every generation call.

The insight is simple: an AI model is only as good as the context it receives. Give it a well-formed specification encoding your domain boundaries, your layering rules, your security requirements, and your acceptance criteria, and it generates code that actually belongs in your system. Give it a vague prompt and you get plausible-looking code that may or may not fit.

⚠️ The Specification Vacuum

Every AI code generation call is stateless. The model does not remember that you chose event sourcing for your order service, or that your team banned direct DB access from the HTTP layer. Without a persistent spec the AI can read, every session risks contradicting a previous one.

The spec-first workflow

The difference between a vibe prompt and a spec-grounded prompt is the difference between "build me a login endpoint" and this:

Context: @requirements.spec.md  @domain-model.spec.md  @architecture.spec.md

Task: Implement LoginUseCase in the Application layer.
- Must satisfy NFR-SEC-01 (bcrypt ≥12), NFR-SEC-02 (rate limit 5/min)
- Must emit AuthenticationAttempted domain event
- Must NOT import infrastructure — use IUserRepository port only
- Write unit tests alongside implementation

Do NOT generate controllers, routes, or HTTP types.

The AI is no longer free-forming. It is executing a plan written by engineers who understand the system. Security rules are constraints, not afterthoughts. Layer boundaries are instructions, not suggestions.

Kiro and Claude as spec-first partners

These two tools approach SDD from complementary angles. Used together, they cover the full workflow from spec authoring to code generation.

	Kiro (IDE-Native)	Claude (AI Reasoning)
What	Amazon's agentic IDE treats specs as first-class project artefacts that live in the repo alongside code — not in a chat history that disappears.	Claude's large context window and instruction-following make it the ideal spec authoring and code generation partner when specs are supplied as context.
Key features	Spec files committed to version control	200k context — full spec sets fit in one session
	Agents reference specs on every task	Strong domain modelling from natural language
	Steering docs enforce architectural rules	Generates ADRs and spec docs from discussions
	Hook system for spec-compliance checks	Enforces layer rules when explicitly stated
	Built for multi-session continuity	Claude Code integrates spec files as project context

✅ Recommended Pairing

Use Claude to author specs — domain model discussions, ADR drafting, security NFR catalogues. Commit those files to your repo. Use Kiro's agent to execute code generation tasks against that persistent spec. Each tool does what it does best.

When to vibe, when to spec

This is not a case against vibe coding everywhere. It is a case for knowing when structure earns its cost.

Context	Approach	Why
Hackathon / throwaway PoC	🟠 Vibe	Code gets discarded. Speed wins.
Solo project, no compliance risk	🟠 Vibe	No team alignment needed.
Early MVP, shape still unknown	🔵 Lightweight spec	Domain model only, skip full arch spec until stable.
Production service, team of 3+	🟢 Spec-Driven	Multi-session continuity requires persistent context.
Regulated domain (finance / health)	🟢 Spec-Driven	Compliance requirements must be first-class spec citizens.
Greenfield platform, 2+ year horizon	🟢 Spec-Driven	Best time for discipline is before debt accumulates.

Your first spec-driven sprint

You do not need to rewrite your codebase. You need three artefacts and a habit.

Artefact 1 — Domain model spec. Open a Claude session and describe your system's problem domain in plain language. Ask it to produce a domain model — entities, boundaries, events, rules. Review it with your team. Commit it as docs/specs/domain-model.md.

Artefact 2 — Architecture Decision Records. For each significant architectural decision — your database, your auth mechanism, your service boundaries — write a one-page ADR using Claude. Store them in docs/adr/. These become standing instructions for every future AI prompt in that area.

Artefact 3 — Security NFR catalogue. Add your security non-functional requirements as numbered, referenceable statements. Tie them to specific modules. Reference them in every AI task prompt that touches authentication, data handling, or external integrations.

✅ One Sprint Is Enough to Start

Dedicate one sprint to these three artefacts before writing new feature code. Teams that do this report dramatically more predictable AI-assisted development — and code reviews shrink because the spec handles the architectural discussion before the PR exists.

The vibe was never the problem

Vibe coding gave developers something real: the ability to translate intent into implementation at a speed that was previously impossible. Dismissing it would be a mistake.

But velocity without direction is not progress — it's drift. The AI can only execute, at enormous speed, whatever you point it at. A spec is what you point it at. That is the entire argument.

References: Andrej Karpathy — "Vibe Coding" (2023) · Amazon Kiro Documentation (2025) · Anthropic Claude Docs (2025) · McKinsey Technology — Developer Productivity & AI Report (2024) · Michael Nygard — Documenting Architecture Decisions (2011)