How I Set Up a Team of Agents for a Lean AI-Powered SDLC

Software development has always been a team sport. Planning, coding, testing, deploying, monitoring — each phase demands focus, context-switching, and a different kind of thinking. What if you could give each of those phases its own dedicated specialist, one that never sleeps, never loses context, and gets better with every iteration? That is exactly what I set out to do when I assembled a team of AI agents to power a Lean Software Development Life Cycle (SDLC).

This is not a story about replacing engineers. It is a story about removing waste — the Lean principle at the heart of everything — and letting humans do what humans do best: think, decide, and create.

Why Lean + AI?

Lean Software Development, inspired by the Toyota Production System, is built on seven principles: eliminate waste, amplify learning, decide as late as possible, deliver as fast as possible, empower the team, build integrity in, and see the whole.

The moment I started working with agentic AI tools seriously, I noticed something striking: many of the time-consuming, low-value tasks that engineers routinely handle — triaging feedback, writing boilerplate, reviewing PRs for style, generating test cases, catching security issues — are exactly the kind of waste Lean wants to eliminate.

AI agents are not just faster at these tasks. They are always on, consistent, and increasingly capable of multi-step reasoning. The natural next step was to compose them into a pipeline that mirrors the SDLC itself. Here is the team I landed on.

The Team

Claude — Feedback to Ticket

Every SDLC starts with a problem to solve. Ours start in the form of user feedback: support messages, survey responses, app store reviews, Slack threads. Left unstructured, this is noise. Organised and prioritised, it is a product roadmap.

Claude reads incoming user feedback and turns it into well-formed Jira tickets. It extracts the core problem, infers the scope, suggests a priority, links related issues, and writes the acceptance criteria. What used to take a product manager or engineer thirty minutes of interpretation and typing now takes seconds — and the output is consistent every time.

This is waste elimination in its purest form. The human still decides what to build. Claude makes sure the decision is based on clearly articulated, actionable information rather than a pile of raw text.

Claude Code — Ticket to Pull Request

Once a ticket is ready and prioritised, Claude Code picks it up. It reads the Jira ticket, checks out the repository, understands the existing codebase, and implements the fix or feature — following the project’s conventions, patterns, and style guides.

This is not generic code generation. Claude Code works inside your repository, reads the context of surrounding files, and produces code that looks like it was written by a developer who has been on the project for months. It opens a pull request with a clear description linking back to the Jira ticket.

The Lean principle at play here is delivering as fast as possible. The gap between a ticket being created and a PR being opened used to be measured in days. Now it can be measured in minutes.

CodeRabbit — Automated Code Review

Before any human engineer looks at the pull request, CodeRabbit has already reviewed it. It checks for correctness, potential bugs, adherence to coding standards, missing test coverage, documentation gaps, and architectural inconsistencies.

CodeRabbit leaves structured, line-level comments on the PR — just like a senior engineer would. Claude Code can then address those comments in a follow-up commit before a human ever opens the diff.

This is pure waste elimination for the review process. Senior engineers are expensive, scarce, and cognitively loaded. Having CodeRabbit handle the mechanical layer of review — style, naming, missing edge cases — means human reviewers can spend their time on what actually requires human judgment: business logic, product decisions, and architectural trade-offs.

Aikido — Continuous Security Scanning

Security reviews used to be something that happened at the end of a release cycle, if they happened at all. With Aikido in the pipeline, they happen continuously.

Aikido scans the codebase, dependencies, containers, and infrastructure-as-code on every change. It flags vulnerabilities, licence risks, and misconfigurations — and creates actionable issues automatically. It does not wait for a quarterly audit or a penetration test. It is always watching.

This directly supports building integrity in — one of Lean’s most important, and most neglected, principles. Security is not a gate at the end of the process. It is a property that is maintained throughout.

Maestro — End-to-End Testing

Unit tests and integration tests tell you whether the code is correct in isolation. Maestro tells you whether the product actually works for a user. It runs E2E tests against the running application — simulating real user flows, catching regressions that only appear when the full stack is assembled.

Maestro runs automatically on every PR. If a user flow breaks, the PR does not merge. There is no debate about whether it is a real issue; Maestro has a recording and a failure report.

This closes the quality loop at the right level of abstraction. Unit tests catch logic errors. CodeRabbit catches code quality issues. Maestro catches product failures. Together, they form layers of safety that make it possible to ship fast without shipping broken.

The Team — Final Call

All of the above is in service of one thing: giving the engineering team the information and confidence they need to make great decisions quickly.

Every PR has CodeRabbit’s review, Aikido’s security scan, and Maestro’s test results before a human opens it. The human reviewer is not starting from zero. They are looking at a PR that has already been scrutinised from multiple angles, with the mechanical concerns already resolved.

The team makes the final call — on architecture, on trade-offs, on whether the solution is actually right for the user. That is not something an agent should decide. That is where human judgment is irreplaceable.

This is the Lean principle of empowering the team in action. When engineers are freed from mechanical tasks, they have more cognitive bandwidth for the creative and strategic work that actually moves a product forward. The agents do not diminish the team; they amplify it.

What the Pipeline Looks Like

User Feedback
     ↓
  Claude → Jira Ticket
     ↓
  Claude Code → Pull Request
     ↓
  CodeRabbit → Review Comments → Claude Code → Updated PR
     ↓
  Aikido → Security Report
     ↓
  Maestro → E2E Test Results
     ↓
  The Team → Approve & Merge

Each step feeds the next. The agents hand off to each other through the same artefacts the team already uses — Jira tickets, pull requests, CI checks. Nothing exotic. Nothing that requires a new tool for the humans to learn.

What I Learned

Specialisation beats generalisation. A single “do everything” agent is less effective than a focused team. Claude is optimised for language and reasoning. Claude Code is optimised for reading and writing code in context. CodeRabbit is trained specifically on code review patterns. Aikido focuses entirely on security. Maestro focuses entirely on user-facing correctness. Each agent is great at one thing, and that is what makes the team great at everything.

The handoff artefacts matter. The quality of the pipeline depends on the quality of what each agent passes to the next. A vague Jira ticket produces a vague PR. A clearly scoped ticket with explicit acceptance criteria produces code that is much easier to review. Investing in the structure of handoff artefacts pays dividends at every subsequent stage.

Humans set the bar, agents maintain it. The coding standards CodeRabbit enforces, the user flows Maestro tests, the security policies Aikido flags against — all of these are defined by the team. The agents do not decide what “good” looks like. They consistently apply the team’s definition of good at machine speed.

Feedback loops must be tight. The agents work best when they receive fast, structured feedback. A Maestro failure is information for the engineer. A CodeRabbit comment is information for Claude Code. Wiring these signals together is what turns a collection of tools into a pipeline.

The Road Ahead

We are still early. The agents occasionally miss context, misread a constraint, or flag a false positive. The human checkpoints exist precisely to catch those moments — and to close the feedback loop so the system improves over time.

But the trajectory is clear. Each generation of models is more capable. The tooling is maturing fast. And the Lean principle of seeing the whole — understanding the system end-to-end rather than optimising a single part — is exactly what separates a well-designed agent team from a bag of disconnected AI features.

The future of software development is not humans vs. AI. It is a Lean pipeline where each agent owns its phase, hands off cleanly to the next, and gives the team the information it needs to make great decisions fast.

The sprint never sleeps. But now, neither does the team.