Autonomous SDLC Pipeline
An issue-to-production loop run by cooperating agents. A Coder agent writes and checks the change, a Reviewer agent validates the PR, a person merges, GitHub Actions deploys to AWS — and when a deploy fails or production misbehaves, a Deployment or Production agent picks it up and feeds the fix back in.
← Swipe to follow the flow →
- Trigger
- Agent
- Tool / data
- Guardrail
- Human
⊘ Agents write and check. People merge.
The problem
What this replaced
- 01Read the ticket. Pull the repo. Install packages.
- 02Write the fix.
- 03Build the Docker container locally.
- 04Run regression tests by hand.
- 05Push the image and redeploy.
- 06Watch the logs to confirm it came up clean.
Who has this problem
Solo engineers and small teams who own an entire production service with no larger team to absorb routine work.
What it costs
As the only person responsible for the application, every hour spent on mechanical build-and-deploy chores is an hour not spent on the engineering that matters. The chores do not scale, and they do not stop.
The build
What I built
Every change starts as a GitHub issue. A Coder agent pulls the repo context, implements the change, runs the checks and opens a PR. A separate Reviewer agent validates that PR — reviewing the diff and running the test suite, with Playwright end-to-end tests when the UI is touched — and either approves it or sends it back. A person merges approved work into dev, and later raises the dev → main PR by hand. A push to main triggers a GitHub Action that builds and deploys to AWS. If that deploy fails, a Deployment agent is invoked on the failed run, fixes it and redeploys. If something goes wrong in production, the Production agent is tagged: it pulls the logs and metrics, works out what happened, and files a new issue — which the Coder agent picks up, closing the loop.
Let one engineer own a production computer vision service end to end, with agents doing the mechanical work and a person holding both merge gates.
Capabilities
- 01Issue → code → checks → PR, by the Coder agent
- 02Independent PR validation with tests and Playwright
- 03Human merge gates: into dev, and dev → main
- 04GitHub Actions build and deploy to AWS on main
- 05Deployment agent that repairs and re-runs a failed deploy
- 06Production agent that turns logs and metrics into a new issue
How it runs
The workflow
- in
Trigger
A GitHub issue — a feature, a bug, or one filed by the Production agent.
- 01
Coder agent loads the repo context, implements the change, runs the checks and opens a PR
- 02
Reviewer agent validates the PR — diff review, test suite, Playwright when the UI changes — and approves or requests changes
- 03
A person merges the approved PR into dev
- 04
A person raises the dev → main PR; the push to main triggers the GitHub Action that deploys to AWS
- 05
If the deploy fails, the Deployment agent diagnoses the failed run, fixes it and redeploys
- 06
If production misbehaves, the tagged Production agent reads logs and metrics and files a new issue for the Coder agent
- out
Output
A change that has been written, independently validated, merged by a person and deployed — with failures routed back into the same loop instead of to a pager.
Components
- GitHub issues — the single intake for features, bugs and incidents
- Coder agent — Claude Sonnet 4.5
- Reviewer agent — review, test suite, Playwright
- Human merge gates — into dev, and dev → main
- GitHub Actions — build and deploy on main
- AWS — production target
- Deployment agent — repairs failed deploys
- Production agent — logs and metrics → new issue
The guardrail
What it is not allowed to do
⊘ Boundary
Agents write and check. People merge.
The agent that writes the code is never the agent that approves it — a single agent marking its own work as correct is the exact failure mode this design exists to avoid. And no agent can move code between branches: a person merges into dev, and a person raises the PR to main. The Deployment agent is scoped to repairing a run that has already been approved for production; the Production agent can only read logs and metrics and file an issue, which then goes through the whole loop again.
Stack
What it is built on
- Model
- Claude Sonnet 4.5
- Agents
- CoderReviewerDeploymentProduction
- Testing
- Playwright end-to-endAutomated test suite
- CI/CD
- GitHub IssuesGitHub ActionsDockerAWS
- Domain
- Computer vision — quality grading and defect detection
Hard parts
What made it difficult
- 01
Giving the Coder agent enough repository context to make a correct change without flooding it with the entire codebase.
- 02
Making the Reviewer agent a genuine check rather than a rubber stamp on the Coder agent's work.
- 03
Letting the Deployment agent fix a failed run without letting it become a back door around the merge gates.
- 04
Turning noisy production logs and metrics into an issue specific enough for the Coder agent to act on.
Outcome
What changed
Hours → minutes
feature-to-deploy turnaround
Feature-to-deploy turnaround dropped from multiple hours to minutes.
Package installs, builds, test runs and redeploys are handled by agents — decisive when one person maintains the whole application.
Failed deploys and production issues re-enter the same issue → PR loop instead of becoming manual firefighting.
Get in touch
Building an agent that has to survive production?
I write about MCP design, evals and guardrails on LinkedIn most days. If you're working on something similar, I'm happy to talk shop.