Hook: Vibe coding works beautifully right up until it doesn't. You prompt, you skim, you accept, you move on — and it's genuinely faster, for a while. Then you hit a feature that spans fifteen repositories, and the model confidently puts the table in the wrong service.
The problem was never the model's code. It's that nobody decided which repository owned the change, which endpoints were needed, or in what order twelve tickets had to merge so nobody's branch conflicted. That decomposition work is the engineering — and it's the part vibe coding has no answer for.
Note: This describes the architecture of an internal engineering tool. Product specifics, repository names, and proprietary conventions are generalized. The patterns transfer; our config files wouldn't.
| What it is | An AI development agent that takes a blank Jira story and returns a stack of reviewed merge requests | | What it replaces | Ad-hoc prompting (vibe coding) for work that spans multiple repositories | | What it automates | Planning, ticket decomposition, dependency ordering, TDD implementation, code review, MR creation | | Execution order | DB → Backend → Shared UI → App UI → E2E → Review → MR | | Human gates | 2 — plan approval, and per-ticket approval. Nothing else requires a human | | Architecture | Agentic CLI plugin + MCP tool server + prose workflow rules + on-demand skills + multi-model routing | | Guardrail model | Independent model review of tests and code; 5-failure stop; no work on unapproved tickets | | Implementation size | ~7,800 lines, almost entirely English prose | | Scale measured | 35+ stories · 500+ tickets · ~11,400 tests · ~86% line coverage | | Impact measured | ~1,650 manual hours avoided (~90% of estimated manual effort) | | Longest unattended run | ~12 hours |
Agentic SDLC automation is the practice of giving an AI system ownership of a complete software delivery workflow — requirement intake, planning, task decomposition, implementation, testing, and code review — under deterministic orchestration and explicit verification gates, rather than generating code on request. The distinction from vibe coding is scope and accountability: a prompt answers "write this function," an agentic system answers "deliver this story, in the right repositories, in the right order, with tests someone reviewed."
Ours takes a blank Jira story key plus context and returns a stack of reviewed merge requests. It fetches the latest code from every affected repository, drafts a plan, writes one markdown file per proposed ticket for local review, publishes the plan to the wiki, and stops. You say LGTM. It creates the child tickets as a single linear dependency chain and stops again. You approve tickets. It then develops each in strict order — DB → Backend → Shared UI → App UI → E2E — writing tests first, getting them reviewed, implementing, getting the code reviewed, and opening one merge request per ticket on stacked branches.
Two human gates. Everything between them is autonomous.
These are three points on one progression, not three competing tools. Each solves the bottleneck the previous one exposed.
| Dimension | Vibe coding | AI coding assistant | Agentic SDLC automation |
|---|---|---|---|
| Unit of work | A prompt | A function, file, or diff | A story, decomposed into tickets |
| Who decomposes | Nobody — you improvise | You do, before prompting | The agent proposes; you approve |
| Task ordering | None | None — you sequence it | Dependency-aware execution chain |
| State across steps | Chat history | Conversation context | Ticket board + branches + MRs as durable state |
| Repository awareness | Whatever's open | The open file or workspace | Explicit repo map, module ownership, shared-library rules |
| Verification | Vibes — you skim and accept | You run the tests | Tests written first, reviewed by a second model, gated |
| Failure behavior | Silently wrong, found later | Returns a wrong answer confidently | Stops after 5 consecutive failures, posts a blocker |
| Output | Code in your editor | Code you paste | Stacked merge requests with test evidence |
| Human role | Accept or re-prompt | Prompt and review each output | Approve at two gates; review MRs |
| Scales to | One repo, one developer | One repo, one task at a time | A story spanning many repositories |
Vibe coding removed the friction of typing code. Assistants removed the friction of writing correct code for a scoped task. Neither touched the part that actually consumes a sprint: deciding what the tickets are, which repository each belongs to, what order they merge in, and whether the result is trustworthy.
Definition — Agentic SDLC automation: A software delivery workflow in which an AI system executes planning, decomposition, implementation, testing, and review under deterministic orchestration, with explicit human approval gates and automated verification — as opposed to ad-hoc prompting with human-only review.
Definition — Autonomous development loop: A control loop that polls a ticket system for the next ready task, executes a full development workflow against it, and repeats without human input until every task is complete or a guardrail halts it.
Vibe coding has a real domain where it wins. One repository, one developer, a task you could have scoped in your head anyway — prompt, skim, accept, move on. The loop is fast because the coordination cost is zero.
That cost is not zero in a microservices monorepo, where one feature is never one change. A single story routinely means:
Each of these lives in an independent Git repository — its own main, its own CI, its own merge queue. Landing them in the right order without merge conflicts or half-integrated states is a coordination problem long before it's a coding problem.
Give a coding assistant the ticket "Add crop planning" and it will confidently start writing something. The question it can't answer alone is which repository, which module, which order, and what does this depend on.
This is where the vibe-coding loop inverts. Accepting a plausible diff is cheap; discovering three days later that the migration landed in the wrong service is not. The faster you generate unverified code across repository boundaries, the more expensive the correction becomes — you're not saving time, you're borrowing it at interest.
Every under-specified ticket you hand an agent is a ticket where it guesses — and a guess in ticket #3 propagates through tickets #4 through #12.
Before building anything, we looked at where the hours went. Across the ticket types the agent now generates, the distribution is lopsided in a useful way:
| Ticket type | Count | Share | Character of the work |
|---|---|---|---|
| UI (incl. shared components) | 128 | 43% | Highly patterned — forms, tables, modals, API wiring |
| Backend endpoints | 105 | 35% | Highly patterned — controller, service, DTO, validation |
| Database migrations | 42 | 14% | Convention-heavy, high blast radius if wrong |
| E2E journeys | 24 | 8% | Scenario design, then mechanical execution |
Roughly 78% of tickets are backend endpoints and their frontend integration. That's repetitive, convention-bound work where the decision space is narrow and the right answer is largely determined by what the codebase already does.
That's precisely the shape of work an agent handles well — if it's given a tight enough specification. Which brings us back to decomposition.
The most common misconception is that the model is the system. It isn't. In our experience the LLM is one of seven components, and it's not the one that determines whether you can trust the output.
| Component | Role | What breaks without it |
|---|---|---|
| LLM reasoning | Planning, decomposition, implementation, review judgment | Nothing works at all |
| Deterministic orchestration | Fixed step order, dependency chain, state machine | Non-reproducible runs; conflicting concurrent work |
| Curated context | Repo map, latest code fetched before planning | Confident placement of code in the wrong service |
| Skills | Stack conventions loaded on demand | Output that passes tests but violates house style |
| Rules | The workflow contract, read fresh every run | Behavior drifts from what the team agreed |
| Tools (MCP) | Typed access to ticketing, wiki, git hosting | Malformed API calls; no audit boundary |
| Verification | Independent review of tests and code, hard gates | Plausible code with worthless tests |
Definition — Agent orchestration: The deterministic layer that decides what runs next and in what order, leaving the LLM to decide how each step is performed. Orchestration is ordinary code and configuration — not model output — which is what makes agent behavior reproducible.
The split that matters: deterministic workflow, LLM reasoning. Step order, dependency resolution, branch topology, gate enforcement, and stop conditions are all deterministic. Design judgment, code, tests, and review opinions come from the model. We never let the model decide whether to run a gate — only what it concludes inside one.
The agent ships as a plugin for an agentic coding CLI. This was the single highest-leverage decision.
It inherits, for free: filesystem access, shell execution, git, a permissions model, session management, and model routing. We wrote zero infrastructure code.
dev-agent/
├── commands/ # slash commands — the entry points
├── rules/ # the workflow contract (authoritative)
├── skills/ # stack conventions, loaded on demand
├── dev-tools-mcp/ # MCP server — ticketing, wiki, git hosting
└── Plans/ # generated artifacts, reviewed by humans
The whole thing is roughly 7,800 lines — and almost all of it is English. The only real code is a ~1,200-line MCP server wrapping three REST APIs.
In an agentic architecture, your business logic is prose. Leverage comes from the precision of your contract, not the cleverness of your implementation.
The agent reaches external systems through a single Model Context Protocol server exposing 44 tools.
| Domain | Tools | Responsibility |
|---|---|---|
| Ticketing | 22 | Read/update stories, create children, link dependencies, poll status, transition, comment |
| Wiki | 12 | Search, read requirement docs, publish approved plans |
| Git hosting | 7 | Branch existence, branch creation, MR create/get/list |
Why not just let the model shell out to curl?
Git is the deliberate exception — it runs through the shell, because git is already a precise CLI and the agent must operate inside whichever submodule it's working in.
rules/ holds the workflow specification, and the agent reads it at the start of every single run. Not fine-tuned. Not buried in a system prompt. Read fresh.
| Rule file | Role |
|---|---|
workflow.md (644 lines) |
The full contract — step order, both gates, TDD discipline, the 5-consecutive-failure stop, the 30-minute re-read rule, status flow |
repositories.md (206 lines) |
Repo map, in-scope submodules, domain-module discovery, chain order, stacked-branch mechanics, MR targeting |
review-tests.md |
Test-review checklist — the gate before any implementation is written |
review-code.md |
Code-review checklist — the gate before a ticket reaches In Review |
wiki-template.md (332 lines) |
Required structure of the published requirement doc |
Rules are layered and overridable: the agent checks for a project-level override before falling back to the plugin default. A team with stricter conventions overrides one file instead of forking the agent.
Rereading the contract every run sounds wasteful. It's the opposite. Changing agent behavior becomes a pull request against a markdown file — reviewable, diffable, revertible. No retraining, no redeploy, and no version skew between what the agent believes and what the team agreed.
Stack conventions live in skills that load only when the agent touches matching files.
| Skill | Loads when | Covers |
|---|---|---|
db |
editing .sql migrations |
Naming, UUID v7 keys, mandatory per-tenant partitioning, tenant-leading indexes, Flyway, rollback discipline |
java |
editing .java |
Package layout, REST resources, DTOs/mappers, CDI, exception handling, red-green-refactor |
java-test |
writing JUnit | One behaviour per test, given/when/then, mocking strategy, naming format |
react |
editing .tsx |
Component structure, hooks, state, forms, accessibility, shared-component placement |
react-test |
writing RTL tests | Strategy by component type, query hierarchy, mocking, async patterns |
jira |
any ticket operation | Search, create, update, transition, comment |
This is progressive disclosure applied to context. The DB ticket never loads React conventions. The E2E ticket never loads migration rules. Context relevance, not context volume, is what degrades over a long run.
Our platform is multi-tenant on a single database, so every table must be partitioned by tenant. That one rule cascades into consequences that are not obvious:
That's a chain a new engineer gets wrong on their first migration, every time. Written down once, it's enforced across all 42 DB tickets without anyone remembering to check.
Not every step deserves the same model.
| Stage | Model tier | Rationale |
|---|---|---|
| Planning & decomposition | Frontier / reasoning | Highest-leverage step; an error here propagates through every downstream ticket |
| Test review | Frontier / reasoning | Adversarial judgment — is this test real or tautological? |
| Code review | Frontier / reasoning | Same |
| Implementation (all types) | Fast / balanced | Constrained by tests already written and reviewed |
The insight: implementation is the cheap part when the specification is tight. Once tests exist and a strong model has reviewed them, writing code that passes is comparatively mechanical. Spend your reasoning budget where judgment compounds.
Every generated ticket is blocked by exactly one predecessor and blocks exactly one successor.
DB1 → DB2 → BE1 → BE2 → BE3 → UI-C1 → UI-C2 → FE1 → FE2 → E2E1
No fan-out. Ever.
Definition — Dependency-aware execution: Ordering generated tasks so each begins only after the work it builds on is complete, so the agent never implements against code that doesn't exist yet.
A dependency DAG would be more "correct" — plenty of these tickets could genuinely run in parallel. We chose the chain anyway, because it guarantees one property worth more than theoretical throughput:
At most one ticket is ready at any moment.
That single invariant eliminates a whole class of failures: no two agents editing the same file, no duplicated shared components, no conflicts between sibling branches, no "which of these three branches has the migration?" archaeology. The loop that picks the next ticket becomes trivially correct — find the one approved ticket whose single predecessor is done.
Parallelism is a tempting optimization. Determinism is what makes an autonomous system trustworthy enough to leave running for twelve hours.
Within each repository, every ticket branches from its same-repo predecessor.
main
└── STORY-100 (integration branch)
└── TICKET-101 MR → STORY-100
└── TICKET-102 MR → TICKET-101
└── TICKET-103 MR → TICKET-102
Each ticket's MR targets its predecessor's branch. When all child MRs merge into the integration branch, one final MR takes STORY-100 → main.
The payoff is reviewability. A reviewer opening TICKET-102 sees only that ticket's diff — not the migration from TICKET-101 underneath it. Without stacking, the last MR in a chain of twelve shows the cumulative diff of all twelve, and review collapses into rubber-stamping.
Generating code faster than humans can meaningfully review it isn't a throughput gain. It's risk, relocated downstream.
Autonomy without verification is just vibe coding at machine speed. That's the trap worth naming: an agent that plans, decomposes, and implements without gates doesn't fix the accept-and-move-on problem — it industrializes it. Every ticket runs strict TDD with two mandatory review gates:
Write tests → [GATE] → Implement → Tests pass → [GATE] → MR
The reviewing model emits either APPROVED or CHANGES REQUESTED: with a numbered, file-referenced list, and the implementing agent revises and resubmits.
The test-review checklist carries most of the value. It explicitly hunts the failure mode that makes AI-generated tests worthless:
sleep(N)
"abc" / 123
The code-review checklist adds scope discipline (no unrelated changes, no opportunistic refactoring) and a security pass (no sensitive data logged, no internal errors leaked, server-side validation, auth on every endpoint, tenant isolation preserved).
| Guardrail | Behavior |
|---|---|
| Test gate | No implementation begins until a second model approves the tests |
| Code gate | No MR opens until a second model approves the implementation |
| Approval gate | The agent never touches a ticket a human hasn't moved to approved status |
| 5-failure stop | Five consecutive failing test runs halts the ticket and posts a blocker comment |
| 30-minute re-read | Long-running tickets trigger a re-read of the original requirement before continuing |
| Scope discipline | Review rejects changes outside the ticket's stated scope |
| Local-first artifacts | Plans and tickets are markdown files before they're board state |
A model that writes both the tests and the code will happily write tests its code passes. Independent review is the only thing that breaks that loop — and it's why the test numbers below mean something instead of being coverage theater.
From production use on a real microservices platform (~15 active repositories, Java/Quarkus backends, React frontends):
| Metric | Value |
|---|---|
| Feature stories planned end-to-end | 35+ |
| Child tickets generated & developed | 500+ |
| Manual development hours avoided | ~1,650 hrs |
| Manual estimate vs. agent time | ~2,480 hrs → ~835 hrs |
| Share of manual effort removed | ~90% |
| Tests written | ~11,400 |
| Line coverage across services (sampled) | ~86% |
| REST endpoints shipped | 156 |
| DB tables shipped | 92 |
| E2E user journeys | 19 |
| Longest unattended run | ~12 hours |
Test breakdown, counted directly from the test suites: ~5,325 backend unit tests (405 test classes) and ~6,052 frontend unit/component tests (591 test files), plus 19 E2E journey suites running against the real stack — real database, real backend, real UI, no mocks.
Benchmark sections are usually where rigor goes to die. Four caveats worth stating plainly:
The test count and coverage are counted, the hours are extrapolated. Test cases (~11,400) and file/line counts came directly from the test suites and source trees. Line coverage (~86%) is a weighted average from JaCoCo reports that exist for a sample of backend modules, not a full-suite run across all 19 repositories — real data, partial coverage of the estate.
The 1,650 hours is a scaled comparison against estimates, not a controlled trial. The underlying ratio — roughly 90% of estimated manual effort removed, i.e. manual time running about 3x agent time — was established on an earlier, smaller slice of delivered work and held steady as ticket volume grew past 500. Applying that same ratio to the current scale gives ~2,480 estimated manual hours against ~835 hours of actual agent time. The manual side is an engineering estimate, defensible because these are ticket types the team has sized for years, but nobody built the same 500+ tickets twice to confirm it.
The ~90% figure measures effort removed, not effort eliminated. Those ~835 agent hours aren't free — they include human review at both gates, MR review, and intervention when a run stalls. What shrank is the manual writing of migrations, endpoints, components, and tests.
~86% line coverage is a floor claim, not a quality claim. Coverage measures execution, not assertion quality. What makes it meaningful here is the review gate: every test set was reviewed for tautologies and weak assertions before implementation existed.
Each of these looked reasonable and quietly made the system worse.
Letting the agent create the parent story. It now receives a blank story key to populate. Humans decide what gets built; the agent decides how it decomposes. That boundary turned out to be load-bearing — for trust as much as correctness.
Parallelizing development. Our first version modeled dependencies as a DAG and ran ready tickets concurrently. Merge conflicts and duplicated shared components ate the entire speedup and then some. The linear chain is slower on paper and faster in practice.
Writing tickets straight into the tracker. Wrong decomposition meant deleting tickets, unlinking dependencies, and cleaning up a polluted board. Now the plan and every proposed ticket are written as local markdown first, iterated with the developer, and pushed only after approval. Iterating on a file is free; iterating on a ticket board is not.
Bundling tickets to reduce count. "One ticket for the CRUD API" seems efficient. It produces an enormous diff, an unreviewable MR, and a ticket that's half-done for three days. The rule is now aggressively granular: one ticket per schema, per endpoint, per page, per integration, per journey.
Assuming the model would infer repository layout. It doesn't, reliably. The repo map, module conventions, and shared-component rules are written down explicitly — and the agent re-fetches the latest code from every affected repository before planning, so it plans against what's actually there rather than what it remembers.
Here's what a typical run looks like from the outside.
The half-day unattended stretch happens between steps 7 and 8 — polling, developing, and opening MRs with nobody watching.
Strip out the domain specifics and this applies to any team doing multi-repo development against a ticketing system:
What is vibe coding, and when does it stop working?
Vibe coding is prompting an AI for code and accepting it on plausibility rather than verification. It works well for one repository, one developer, and tasks you could have scoped yourself. It stops working when a change spans repositories — because the hard part is no longer writing the code, it's deciding where the code belongs and in what order pieces must land.
What is agentic SDLC automation?
A delivery workflow where an AI system executes planning, decomposition, implementation, testing, and review under deterministic orchestration, with explicit human approval gates and automated verification. The defining trait is accountability for a story, not a diff.
How is an AI development agent different from an AI coding assistant?
An assistant makes you faster at a task you've already scoped. An agent does the scoping: it decides which repository and module each change belongs in, generates the ticket breakdown, orders the work by dependency, and produces reviewable merge requests. See the comparison table above.
Is an agentic SDLC just vibe coding with more steps?
No — the difference is what happens to unverified output. Vibe coding accepts code on plausibility. An agentic system cannot: tests are written and reviewed by an independent model before implementation exists, code is reviewed before an MR opens, and no ticket is touched until a human approves it. Remove those gates and you do get vibe coding at higher volume, which is worse than doing it by hand.
Does this replace developers?
No. It removes the manual writing of highly-patterned code and stops decomposition from being the thing that gets cut when a sprint is tight. Humans still decide what gets built, review every plan, and approve every ticket and merge request.
Why a linear dependency chain instead of parallel execution?
Because the invariant "exactly one ticket is ready at a time" eliminates merge conflicts, duplicated shared components, and concurrent edits to the same file. We tried parallel first. The conflicts cost more than the parallelism saved.
How do you stop an AI agent from writing tests that pass trivially?
A different model reviews the tests before any implementation exists, against a checklist targeting tautological assertions, vague "no exception thrown" checks, sleep() calls, and unrealistic test data. The implementing model never reviews its own tests.
What happens when the agent gets stuck?
It stops. Five consecutive test failures halts the ticket and posts a blocker comment rather than thrashing. Tickets running long trigger a re-read of the original requirement before continuing.
Isn't 7,800 lines of prose harder to maintain than code?
It's easier. It diffs, it reviews in a pull request, and any engineer can read a proposed workflow change without knowing the implementation. There's no retraining step and no gap between what the team agreed and what the agent does.
How much context does an agent like this need?
Less than you'd expect, if you're deliberate. Conventions load only when relevant — the DB ticket never loads frontend rules. Curated context beats large context: the repo map and freshly-fetched code prevent far more errors than a bigger window would.
Can this work outside a monorepo?
The decomposition, review-gate, and model-routing patterns are repo-agnostic. The stacked-branch and single-chain mechanics assume multiple coordinated repositories — in a single-repo project they simplify considerably but still help reviewability.
What's the minimum viable version of this?
A written workflow contract, one typed tool boundary to your ticket system, and an independent review gate before code is accepted. Dependency chaining and stacked branches matter once a story spans more than a couple of repositories.
The most surprising thing about building this was how little of it is code. The agent is ~7,800 lines, and the meaningful part is a workflow contract written in English — precise enough to execute, readable enough that any engineer can review a change to it in a pull request.
We didn't build a system that writes code. We built a system that holds a specification precisely enough that writing the code becomes the easy part — then put a human at each end of it.
The twelve-hour unattended run is the part people react to. But that isn't a claim about model capability. It's a claim about specification quality: the agent ran that long without help because the contract was tight enough that there was nothing left to ask.
The path from vibe coding to an agentic SDLC isn't a better model or a longer context window. It's the unglamorous work of writing down what your team already knows — which service owns what, what a good test looks like, what order things merge in — precisely enough that a machine can execute it and a human can review the execution.
Autonomous development isn't an AI capability problem. It's an information architecture problem — and that one you can actually solve.
Questions about the architecture are welcome in the comments — happy to go deeper on the dependency chain or the review-gate checklists.