Skip to content
← All work
03ProductionSoftware Engineering / Multi-Agent

Autonomous SDLC Pipeline

Three cooperating agents — Coder, Reviewer, Deployment — that let one consultant carry a client's entire production computer vision service without hand-running every fix, test and deploy.

Engagement

Client engagement — computer vision application

hours → minutes

feature-to-deploy turnaround

The problem

What this replaced

The manual process, before

  1. 01Read the ticket. Pull the repo. Install packages.
  2. 02Write the fix.
  3. 03Build the Docker container locally.
  4. 04Run regression tests by hand.
  5. 05Push the image and redeploy.
  6. 06Watch the logs to confirm it came up clean.

Who has this problem

Independent consultants and small teams who own a client's entire production service with no larger team to absorb routine work.

Why it costs money

As the only person responsible for the application, every hour spent on mechanical build-and-deploy chores is an hour not spent on work that actually pays. The chores do not scale, and they do not stop.

The build

What I built

A feature request or bug report enters a three-agent pipeline. A Coder agent implements the change. A Reviewer agent reviews it and runs the test suite, including Playwright end-to-end tests when the UI is touched. A Deployment agent — running from inside the GitHub repo — builds, verifies and deploys to AWS, then confirms a clean startup from the logs.

Automate the full lifecycle from issue intake to verified cloud deployment for a client's coffee-bean quality grading and defect detection application, so routine engineering does not have to be handled one item at a time.

Capabilities

  • Codebase context retrieval and dependency analysis
  • Automated implementation and patching
  • Independent review agent with test execution
  • Playwright end-to-end UI regression testing
  • Docker build verification and AWS deployment
  • Post-deploy log verification

How it runs

The workflow

Trigger

A feature request or bug report, with repo path and branch.

  1. 01Pull the latest commit; load repository context, analyze the dependency tree, install packages
  2. 02Coder agent implements the change
  3. 03Reviewer agent reviews the diff and runs the test suite — Playwright included when the UI is affected
  4. 04Deployment agent builds and verifies the Docker container, then deploys to AWS
  5. 05Monitor AWS logs and metrics to confirm healthy operation

Output

A reviewed, tested, deployed change — with a confirmed clean startup in the target environment.

Architecture

How it fits together

Components

  • Issue intake (feature request / bug report)
  • Coder agent — Claude Sonnet 4.5
  • Reviewer agent — review + test execution + Playwright
  • Deployment agent — runs from within the GitHub repo
  • Docker build and staging
  • AWS deployment target + log verification

Data flow

01

Issue → git pull → context load → Coder agent patches

02

Reviewer agent reviews, builds, runs tests and Playwright

03

Deployment agent deploys to AWS

04

Log verification confirms clean startup

The guardrail

What it is not allowed to do

A separate agent has to agree.

The agent that writes the code is not the agent that approves it, and neither is the agent that ships it. Review and deployment are separated deliberately — a single agent marking its own work as correct is the exact failure mode this architecture exists to avoid. Playwright sits inside the Reviewer stage specifically to catch visual regressions that cannot be reasoned about from the diff alone.

Stack

What it is built on

Model
Claude Sonnet 4.5
Architecture
Multi-agent — Coder / Reviewer / Deployment
Testing
Playwright end-to-endAutomated test suite
Build & deploy
DockerGitHubAWS
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

    Catching UI regressions that are invisible in a diff — which is why Playwright runs inside the review stage, not after deploy.

Outcome

What changed

Hours → minutes

feature-to-deploy turnaround

  • Feature-to-deploy turnaround dropped from multiple hours to minutes.

  • Package installs, local builds and repetitive test runs are fully automated — decisive when one person maintains the whole application.

  • The Reviewer agent's Playwright integration catches UI visual regressions before they reach deployment.

Limited availability

Tell me the problem.
I’ll tell you if an agent is the answer.

A 30-minute call, no pitch. Describe the manual loop that hurts and I’ll give you a straight read on whether this is worth building — including when the honest answer is a script, not an agent.