the agile monkeys · our approach to ai sdlc
We give agents the context and environment to implement a change. The team reviews the code and running product before accepting it. This page explains that workflow and what we learned from our internal projects.
the approach
Decide what is worth building
A request needs an owner, a reason to exist, and a result someone can check. Writing the code is only part of that work.
Give the agent a working environment
The repository, dependencies, services, and tests belong together. An agent needs to run the product to check its assumptions.
Make review part of the workflow
Keep the conversation, running change, checks, and pull request within reach of the person deciding whether to accept it.
Follow one change through the workflow.
The example below follows a report of missing rows in an export. Scroll through it, read the steps here, or continue to the results from our internal projects.
Read all steps
Start with what went wrong.
Attach the report, the expected result, and enough context to reproduce the problem. An agent can help turn that information into an issue the team can act on.
Someone owns the outcome.
An engineer decides whether the export problem needs fixing now and what a successful fix would look like. The issue gives the work a shared starting point.
Check the plan against the product.
The agent reads the relevant code and tries to reproduce the missing rows in the development environment. It proposes a fix, tests, and any questions it cannot resolve.
Review the approach before coding.
In this workflow, an engineer reviews the plan before implementation. A change to export permissions, for example, deserves a conversation before it becomes code.
Implement and test the fix.
The builder changes the code, adds a regression test, and runs the repository's checks. With Facility, the files and conversation remain in the story's workspace for the next turn.
Try the change while it is running.
Open the export in the running product and check the result. Facility provides authenticated access to services declared by the repository, using the same workspace the agent is working in.
Check what can be checked in code.
Types, tests, and repository-specific rules catch problems before review. An agent reviewer can examine the diff and raise questions; required CI checks enforce the rules configured for the repository.
Decide whether the change can merge.
A person reviews the diff, checks, and running result. GitHub branch protection, required checks, and reviews turn the team's merge policy into an enforced part of delivery.
Deliver through the release process.
Once merged, the fix follows the team's deployment process. Check the export after release and watch for regressions. Facility tracks the GitHub delivery state; the repository defines how code reaches production.
Keep the work and its record.
Facility records agent turns, Git changes, checks, and usage. Merge suspends compute and keeps the story available. Files and native engine sessions are removed only by explicit workspace deletion.
Use the next change to improve the process.
The export now has a regression test. The team can inspect where the work stalled, what needed correction, and what it cost. Those findings shape the checks and instructions for the next task.
the ai sdlc
One change, end to end.
A user reports missing rows in an export. This example follows the work from that report to a reviewed change. Teams choose where to require human approval.
00 / 11 · scroll
in practice · internal projects
Results from our internal work.
We tested this approach on our internal projects with a small team. These figures come from a sample of agent work the team reviewed on one of those projects.
- Accepted by human reviewers
- 90%
- Agent pull requests reviewed and merged by the team.
- Delivered in one shot
- 57%
- Merged with no change requests or human fixup commits.
- From issue to merge
- 22h
- Median delivery time across the measured agent work.
The work behind the numbers
The acceptance figure covers 30 completed agent pull requests in the Claude Code and Codex workflows: 27 merged after human review.
One-shot means a merged pull request with zero change requests and zero human fixup commits. Delivery time runs from the issue being opened to the pull request being merged. These are the results recorded in our original internal report.
When evaluating agents on your own repository, check which changes they attempted and how much review each needed. That context helps explain the results.
open source
Put it to work with Facility.
Facility gives each story a persistent workspace with its conversation and work history. You can run Claude Code or Codex and continue the same story with another agent. Open the running product when you need to review a change. Facility is open source and runs on your own infrastructure.
Your team defines the agents and their triggers in the repository. GitHub reviews, required checks, and branch protection control what can merge.
We build and use Facility at The Agile Monkeys. It is early-stage software, so APIs and data structures may change between releases. Start with one repository to see how it fits your team.
Want to walk through it with us?
Request a demo. We'll show you the current build and discuss a useful first project for your team.