Vibe coding works until you need to ship a feature that touches fifteen repositories. You prompt, you accept, you move on. Then the agent confidently puts the database migration in the wrong service, and you realize the problem was never code generation. It was decomposition, sequencing, and dependency ordering across a real system.
The gap between AI-assisted coding and agentic SDLC automation is not model capability. It is the orchestration layer that decides which repository owns the change, which endpoints need to exist first, and in what order twelve merge requests must land so nobody’s branch conflicts. That decomposition work is the engineering, and prompt-driven development has no answer for it.
What Agentic SDLC Automation Actually Means
An agentic SDLC system takes a blank Jira story and returns a stack of reviewed merge requests. It replaces ad-hoc prompting for work that spans multiple repositories. It automates planning, ticket decomposition, dependency ordering, test-driven implementation, code review, and MR creation.
The execution order matters:
- Database schema changes
- Backend API implementation
- Shared UI components
- Application UI integration
- End-to-end tests
- Independent model review
- Merge request creation
Human gates exist at two points: plan approval and per-ticket approval. Nothing else requires a human.
Architecture Components
The system is built from five pieces:
- Agentic CLI plugin: Orchestrates the workflow and manages state between steps
- MCP tool server: Exposes file system, git, test execution, and deployment primitives
- Prose workflow rules: Natural language instructions that define sequencing and approval gates
- On-demand skills: Reusable agent capabilities loaded when needed (test generation, code review, dependency analysis)
- Multi-model routing: Different models for planning, implementation, and review
The implementation is approximately 7,800 lines, almost entirely English prose. The system has processed 35+ stories, 500+ tickets, and generated ~11,400 tests with ~86% line coverage. It avoided an estimated ~1,650 manual hours (~90% of estimated manual effort). The longest unattended run was ~12 hours.
Orchestration Flow
The agent does not generate all code and then test it. It follows a strict sequence:
- Planning phase: Agent reads the Jira story, analyzes the codebase, and proposes a decomposition into tickets with explicit dependencies.
- Human approval gate: Engineer reviews the plan. No work proceeds without approval.
- Ticket execution: Agent processes tickets in dependency order. For each ticket:
- Generate tests first (TDD)
- Implement code to pass tests
- Run full test suite
- Submit for independent model review
- Review gate: Separate model reviews tests and code. Five failures trigger a stop.
- Per-ticket approval: Human approves or rejects the ticket. Agent does not proceed to dependent tickets without approval.
- Merge request creation: Agent creates MRs with context, test results, and review history.
The orchestration layer tracks which tickets are approved, which are blocked, and which can run in parallel. It persists this state so the agent can resume after interruption.
State Management Between Steps
The agent needs to remember:
- Which tickets are approved, blocked, or in progress
- Which human approved what, and when
- Test results for each ticket
- Review feedback from the independent model
- Dependency graph so it knows which tickets can run next
This state lives in two places:
- Workflow state file: JSON document tracking ticket status, approvals, and dependencies. The CLI plugin reads and writes this file after each step.
- Git history: Commits and branches encode the work done. The agent uses git log to understand what changed and which tests passed.
When the agent’s next iteration breaks production, you replay by resetting the workflow state file to the last approved ticket and re-running from there. The agent does not have memory of previous runs beyond what is in the state file and git history.
Tool Calls and Boundaries
The MCP tool server exposes these primitives:
read_file,write_file,list_directorygit_status,git_diff,git_commit,git_pushrun_tests,run_linter,run_type_checkercreate_branch,create_merge_requestread_jira_story,update_jira_ticket
The agent cannot:
- Deploy to production (human-only operation)
- Approve its own merge requests (requires human or separate approval bot)
- Modify the workflow state file directly (CLI plugin owns this)
- Access secrets or credentials (tool server provides scoped tokens)
The boundary between agent-driven automation and human-in-the-loop approval is enforced at the workflow state level. The CLI plugin checks the state file before allowing the agent to proceed. If a ticket is not approved, the agent cannot call tools that would modify dependent tickets.
Test Execution Orchestration
When the agent generates code that touches multiple services, it does not trigger the test suite directly. The orchestration flow is:
- Agent writes tests for the current ticket
- Agent implements code to pass those tests
- Agent calls
run_teststool with the ticket’s test scope - Tool server executes tests in the appropriate service’s test environment
- Tool server returns results (pass/fail, coverage, logs)
- Agent reads results and decides whether to iterate or submit for review
The agent does not watch for commits. The CLI plugin triggers the agent after each ticket approval. The agent is stateless between invocations. It reads the workflow state file to understand what to do next.
If tests fail, the agent iterates up to five times. After five failures, the workflow stops and requires human intervention. The human can:
- Approve the ticket anyway (if tests are flaky or irrelevant)
- Reject the ticket and provide feedback
- Modify the code manually and re-run the agent
Deployment Gates and Rollback
The agent does not deploy to production. It creates merge requests. The deployment gate is the merge request approval process. A human or approval bot reviews the MR and merges it. The CI/CD pipeline then deploys to staging, runs integration tests, and deploys to production if tests pass.
If the agent’s next iteration breaks production, you rollback by:
- Reverting the merge commit
- Resetting the workflow state file to the last known good state
- Re-running the agent from the failed ticket with additional context
The agent does not have a rollback trigger. It does not monitor production. It only knows what is in the workflow state file and git history.
Independent Model Review
A separate model reviews the agent’s tests and code before the human approval gate. This model is not the same as the implementation model. It uses a different prompt and temperature setting. Its job is to catch:
- Tests that do not actually test the requirement
- Code that passes tests but violates architectural rules
- Security issues (SQL injection, XSS, insecure deserialization)
- Performance issues (N+1 queries, unbounded loops)
The review model has access to:
- The original Jira story
- The ticket description
- The generated tests
- The generated code
- The test results
- The codebase context (via MCP tools)
It returns a pass/fail decision and a list of issues. If it fails five times, the workflow stops. The human can override the review model’s decision, but the override is logged in the workflow state file.
Failure Modes
| Failure Mode | Symptom | Recovery |
|---|---|---|
| Agent generates code in wrong repository | Tests pass locally but break integration | Human rejects ticket, provides correct repository in feedback |
| Agent creates circular dependency | Workflow cannot find next ticket to execute | Human edits workflow state file to break cycle |
| Independent model review fails five times | Workflow stops, no MR created | Human reviews code manually, approves or rejects ticket |
| Tests are flaky | Agent iterates five times, workflow stops | Human approves ticket with flaky tests disabled |
| Agent loses context after long run | Generated code drifts from original story | Human rejects ticket, re-runs agent with updated story |
| Merge conflict in dependent ticket | Agent cannot create MR | Human resolves conflict manually, re-runs agent |
The most common failure is the agent generating code in the wrong repository. This happens when the decomposition plan is ambiguous about ownership. The fix is to reject the ticket and provide explicit repository names in the feedback.
Security Boundaries
The agent runs with scoped credentials:
- Read-only access to production databases
- Write access to development branches only
- No access to secrets or API keys (tool server injects these at runtime)
- No access to deployment pipelines (human-only operation)
The MCP tool server enforces these boundaries. The agent cannot call tools that would violate the security policy. If the agent tries to write to a protected branch, the tool server returns an error.
The workflow state file is stored in a git repository with branch protection. The agent cannot modify the state file directly. The CLI plugin reads the state file, calls the agent, and writes the updated state file. This ensures the agent cannot bypass approval gates by modifying the state file.
Observability
The system logs:
- Every tool call (tool name, arguments, result)
- Every agent invocation (model, prompt, response)
- Every approval decision (human or review model)
- Every test result (pass/fail, coverage, logs)
- Every workflow state transition (ticket approved, blocked, in progress)
Logs are written to a structured JSON file. The CLI plugin can replay a workflow from the logs. This is useful for debugging when the agent produces unexpected results.
The logs do not include the full prompt or response. They include a hash of the prompt and the first 500 characters of the response. This keeps log files manageable while still providing enough context to debug issues.
Deployment Shape
The system runs as a CLI plugin on the engineer’s laptop. It does not run in a CI/CD pipeline. The engineer invokes the CLI plugin with a Jira story ID. The plugin:
- Reads the workflow state file from git
- Calls the agent with the current ticket
- Writes the updated state file to git
- Pushes the state file to the remote repository
The MCP tool server runs as a local HTTP service. The CLI plugin calls the tool server over HTTP. The tool server has access to the engineer’s git credentials and file system.
This deployment shape keeps the agent close to the engineer’s workflow. The engineer can interrupt the agent at any time, review the state file, and resume later. The agent does not run unattended in a CI/CD pipeline because the approval gates require human interaction.
When to Use This Pattern
Use agentic SDLC automation when:
- Features regularly span multiple repositories
- Decomposition and sequencing are the bottleneck, not typing code
- You have a stable architecture with clear ownership boundaries
- You can afford two human approval gates (plan and per-ticket)
- You have a test suite that runs in under 10 minutes
Avoid this pattern when:
- Features are mostly single-repository changes (vibe coding is faster)
- Your architecture is in flux (agent will generate code in the wrong place)
- You cannot tolerate 12-hour unattended runs (agent needs long context windows)
- Your test suite is slow or flaky (agent will iterate forever)
- You do not have clear ownership boundaries (agent will create circular dependencies)
Technical Verdict
Agentic SDLC automation is not a replacement for vibe coding. It is a replacement for the manual decomposition, sequencing, and coordination work that vibe coding cannot handle. The value is not in generating code faster. The value is in automating the decision of which repository owns the change, which endpoints need to exist first, and in what order twelve merge requests must land.
The orchestration layer is the hard part. You need to persist state between agent invocations, enforce approval gates programmatically, and provide enough observability to debug when the agent produces unexpected results. The agent itself is mostly prose workflow rules and tool calls. The engineering is in the CLI plugin that manages state, triggers the agent, and enforces boundaries.
If your features regularly span multiple repositories and you have a stable architecture, this pattern will save you hundreds of hours. If your features are mostly single-repository changes, stick with vibe coding.