Workshop
A hands-on session on your own codebase: context files, spec writing, agent workflows and review.
Practice 04 — The AI-native playbook
How we write software with agents. Now yours.
These are the working rules our engineers follow on every engagement. We publish them because they're more useful in use than in a drawer — and we teach them hands-on to teams who want to adopt them.
- 01
Write the spec before the prompt.
State the goal, constraints and acceptance criteria in a reviewable file. Agents build better against a contract, and reviewers know what "done" means.
- 02
Treat context as code.
Project context files, conventions and architecture notes live in the repo, are versioned, and get reviewed like any other change.
- 03
Make the feedback loop fast.
An agent is only as good as the signal it gets. Fast, deterministic tests and one-command builds are the highest-leverage investment you can make.
- 04
Small diffs, always.
Break work into changes a human can genuinely review in one sitting. Volume is cheap now; attention isn't.
- 05
The author owns it, whoever typed it.
The engineer who merges agent-written code is accountable for it — and should be able to explain every line.
- 06
Evals are tests. Gate on them.
Any change to a prompt, model or agent runs its eval suite in CI. A regression blocks the merge like a failing unit test.
- 07
Least privilege for agents.
Sandboxed environments, scoped credentials and explicit approval for anything irreversible. Never give an agent more access than the task needs.
- 08
Measure outcomes, not output.
Lines of code and PR counts go up on their own. Track lead time, change-failure rate and the business metric the work was for.
In the repo
Rules only work when agents can read them.
We codify the playbook into the files your agents load on every task — so the standard is applied by default, not by memory.
# AGENTS.md — excerpt ## Before you code - Read the spec in /specs for this task - Run `make test` and confirm it passes ## While you code - Keep diffs under 400 lines; split otherwise - Follow patterns in /docs/architecture.md - Never edit /migrations without approval ## Before you finish - Add or update tests for every change - Run `make evals` if prompts changed - Summarize what changed and why
Adopt the playbook
Three ways to bring it to your team
Embedded pairing
Our engineers pair with yours on real tickets until the new habits stick.
Standards package
Your tailored playbook: repo templates, context files, CI gates and review checklists.