Context
What the agent needs to know
Specs, architecture decisions and product documentation, versioned in the repository next to the code.
Aerolab / engineering
How we build software with agents
From spec to production, with a person approving every change.
Where we stand
- 01
We build products, and AI changed how we build them.
- 02
Nothing reaches production without a person approving it.
- 03
We are agnostic about models and clouds. What matters is the scaffolding around them.
The premise
The new hire who forgets everything
Picture a new engineer. Extremely capable. Knows nothing about your company. Remembers nothing from yesterday. Leaves in two hours, and makes mistakes very fast. So the question was never which model to use. It was: what has to exist around that person for their work to be safe to ship?
Your company is ready for agents if you can hand the work to someone brilliant and they learn everything they need in under an hour.
If a new engineer needs three weeks to become useful, an agent never will. The bottleneck is not the model. It is your documentation.
The four layers
Everything we built falls into four buckets
Harness
What it cannot get wrong
Test coverage, linters and architecture rules that run on every change, whether or not anyone remembers to ask.
Containment
Where it is allowed to work
A temporary isolated environment with no route to the internet and no access to production secrets.
Evidence
How we know it worked
Automated exams that check behaviour, plus a trail of who approved what and why.
↗fig. 02 (the four layers)
The full cycle
Two lanes: what a person decides, what an agent executes
The person never leaves the decision lane. Three of these steps are people, and no amount of speed anywhere else buys a way around them.
- 01
Spec
Exactly what gets built
- 02
Build
In an isolated environment
- 03
Tests
Written and run before the PR
- 04
Review
Catches the obvious
- 05
Approval
Named, recorded, required
- 06
Deploy
Continuous integration
- 07
Monitor
Logs and telemetry, always on
- 08
Next call
What the feedback means
↗fig. 03 (lifecycle, two lanes)
The harness
A harness is the set of automatic rules that keep a mistake from reaching production, even when the agent gets it wrong.
- Test coverage that cannot be waived
- Linters that fail the build, not the mood
- Architecture rules enforced automatically
- Naming conventions strict enough to reject a bad function name
How strict it gets depends on the project. A regulated system gets the hard version. An early prototype gets a lighter one so the team can move. Building the harness is the expensive part, and it goes first. Everything else on this page depends on it holding.
Security
Security is architecture, not instructions
Isolated environment
AgentReads the repo, writes a change
No route to
- The open internet
- Production secrets
- Client data
Two ways out
- The proposed changeReviewed by a person
- LogsEverything it did, kept
An agent with internet access and sensitive data in the same room is an incident waiting to happen. You fix that in the architecture. You do not fix it by asking the agent to behave.
↗fig. 06 (containment)
What does not work
The parts we would rather not put on a slide
- 01
Some work is still faster by hand
Small, gnarly changes in code with a lot of history often cost more to explain than to make.
- 02
The harness is expensive before it pays anything back
Teams want to start with agents. The order that works is documentation, then the harness, then agents.
- 03
Stale documentation degrades everything quietly
When the docs and the code disagree, the agent believes the docs and confidently builds the wrong thing. This is why the review schedule is not negotiable.
None of this replaced our engineering process. It made it mandatory.
Documentation, tests, continuous integration, recorded decisions. These used to be good habits. Now they are the requirement for an agent to work at all.
Talk to our engineering team