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.
Agentic SDLC at a Glance
| 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 |
Key Takeaways
- Vibe coding doesn't scale past a single repository. It optimizes the step that was never the bottleneck: typing the code. Decomposition, sequencing, and verification are what actually consume the calendar.
- Decomposition, not code generation, is the bottleneck in multi-repo development. An AI coding assistant that only writes code solves the easy half.
- An AI development agent is not just an LLM. It's LLM reasoning + deterministic orchestration + curated context + skills + rules + tools + verification. Remove any one and it stops being trustworthy.
- Your agent's business logic should be prose, not code — a workflow contract read fresh at the start of every run, changed via pull request.
- Choose determinism over parallelism. A single linear dependency chain guarantees exactly one ticket is ready at a time, which makes an autonomous loop trivially correct.
- Stacked branches keep AI output reviewable. One MR per ticket, each targeting its predecessor's branch. Reviewability — not generation speed — is the real bottleneck.
- A model that writes both the tests and the code will write tests its code passes. Independent review by a different model is what breaks that loop.
- Measured results: 35+ stories, 500+ tickets, ~1,650 manual hours avoided, ~11,400 tests at ~91% line coverage, longest unattended run ~12 hours.
Quick Answer: What Is Agentic SDLC Automation?
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.
Vibe Coding vs AI Coding Assistant vs Agentic SDLC
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.
Why Vibe Coding Stalls at the Repository Boundary
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:
- 2–3 database migrations across different services
- 8–10 backend endpoints in two or three repositories
- Several new shared UI components, plus the pages consuming them
- API integration work per endpoint on the frontend
- End-to-end coverage per user journey
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.
Where the Work Actually Goes
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 Anatomy of an AI Development Agent
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.
Architecture Layer 1: An Agentic CLI Plugin, Not a Service
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.
Architecture Layer 2: MCP as the Tool Boundary
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?
- Typed contracts. Each tool has a schema. The model cannot mis-shape a payload.
- A real audit boundary. Every external mutation flows through one surface you can log, permission, and rate-limit.
- Failure containment. An API change breaks one Python function, not a hundred lines of prompt.
- Least privilege. The server exposes exactly the operations the workflow needs. There is no generic "make an HTTP request" escape hatch.
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.
Architecture Layer 3: Rules as a Contract, Read Fresh Every Run
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.
Architecture Layer 4: Skills Loaded on Demand
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.
Why On-Demand Conventions Matter More Than They Sound
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:
- Partitioned tables can't carry a simple primary key — so identity is a single UUID v7 column with no primary key constraint
- Uniqueness becomes a unique index that must lead with the tenant column
- There's no default partition, so writes for an unprovisioned tenant fail loudly instead of silently landing in a catch-all
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.
Architecture Layer 5: Model Routing by Cognitive Load
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.
Dependency-Aware Execution: One Chain, Not a Tree
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.
The Execution Order, and Why It's That Order
- DB — migrations first, because every layer above depends on the schema existing
- Backend — endpoints against the committed schema, one ticket per endpoint
- Shared UI — common components land in the shared library before anything consumes them
- App UI — pages and API integration, consuming those components rather than rebuilding them
- E2E — user journeys against the real stack, once there's a stack to test
- Review — independent model review at the test gate and the code gate, per ticket
- MR — one merge request per ticket, stacked on its predecessor's branch
Stacked Branches: One MR Per Ticket
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.
Verification and Guardrails Instead of Blind Autonomy
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:
- No tautological tests — asserting a mock returned what it was told to return proves nothing
- Specific assertions — not "no exception thrown" but actual value checks
-
No flaky waits — no
sleep(N) -
Realistic test data — not
"abc"/123 - Explicit coverage of validation, authorization, edge cases, and state transitions
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).
The Full Guardrail Set
| 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.
Measuring the Impact
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.
Reading These Numbers Honestly
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.
Lessons Learned: Mistakes That Cost Us Time
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.
Walkthrough: One Story, End to End
Here's what a typical run looks like from the outside.
- Input — a blank story key plus context: an existing repo, a PRD, some design notes.
- Plan — the agent fetches latest code across affected submodules, asks clarifying questions, and drafts a plan plus one markdown file per proposed ticket. Each records its target repo, target module, dependency, acceptance criteria, and verification scenarios.
- Publish — the plan goes to the wiki. Cheap and reversible.
- Gate 1 — you read the markdown locally and iterate. Nothing has touched the ticket board yet.
- Create — on approval, ~12 child tickets are created in Triage and linked as one linear chain.
- Gate 2 — you validate each ticket and approve it. The agent will not touch an unapproved ticket.
- Develop — the loop polls for the one ready ticket, runs the matching workflow (DB / Backend / UI / E2E), and repeats. Each ticket: tests → review → implement → tests pass → review → stacked MR.
- Integrate — once all tickets are in review, one integration MR per repository lands the stack.
The half-day unattended stretch happens between steps 7 and 8 — polling, developing, and opening MRs with nobody watching.
The Pattern, Generalized
Strip out the domain specifics and this applies to any team doing multi-repo development against a ticketing system:
- Build on an agentic runtime, not from scratch. Filesystem, shell, git, permissions, model routing — already solved.
- Put external integrations behind MCP. Typed, auditable, least-privilege, independently fixable.
- Write the contract in prose; read it fresh every run. Behavior changes become pull requests.
- Layer rules so projects override without forking.
- Load stack conventions on demand. Context relevance beats context volume.
- Route models by cognitive load. Reasoning for planning and review; fast models for constrained implementation.
- Choose determinism over parallelism. A linear chain makes an autonomous loop trivially correct.
- Stack your branches. Reviewability is the real bottleneck.
- Make review gates hard blocks — reviewed by a different model than the one implementing.
- Keep humans at the decomposition gate and the approval gate. Autonomy between, judgment at the boundaries.
FAQ
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.
Key Takeaways (Recap)
- Vibe coding optimizes typing speed — never the actual bottleneck past one repository
- Decomposition is the bottleneck in multi-repo development, not code generation
- An AI development agent is LLM + orchestration + context + skills + rules + tools + verification — not a model alone
- Deterministic orchestration decides what runs next; the LLM decides how
- Determinism beats parallelism when you want to leave a system running unattended
- Stacked branches keep AI output reviewable; reviewability is the real constraint
- A different model must review the tests, or the tests are worthless
- ~1,650 hours avoided across 500+ tickets, ~11,400 tests at ~86% coverage, ~12 hours unattended
Conclusion
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.
Further Reading
- Model Context Protocol — the open standard behind the typed tool boundary
- Claude Code documentation — plugins, skills, and slash commands
- Claude Agent SDK — for building agents outside a CLI plugin
- GitLab merge request docs — the branch and MR model referenced above
Questions about the architecture are welcome in the comments — happy to go deeper on the dependency chain or the review-gate checklists.
Top comments (0)