How We Built a CRM Using AI Coding Agents (and Governed Them Too)
There is something fitting about a CRM designed for accountable agents being built with the help of accountable coding agents. This is how the process works, in enough detail to copy.
The constraint
A small team, AI coding tools, and a determination not to let speed turn into sprawl. The tools write a lot of the code; people own the decisions.
The method: bounded work packages
Every unit of work is a package with a written brief: scope, non-goals, acceptance evidence, and what the implementer may and may not read. Implementers work from the current specification, architecture decisions and interface contracts rather than old drafts and abandoned ideas, which keeps rejected approaches from creeping back in.
Independent review
Each package is reviewed by someone, or something, other than its implementer, working from the same brief and the evidence the implementer produced. Disagreements go to a human who makes the call. Independent review catches confident mistakes that the author will not see.
Gates, not deadlines
Work moves on evidence. The database foundation package, for example, had to show its migrations, roles and grants, row-level security policies and tenant context handling, with tests, before later packages could build on it. If the evidence is weak, the answer is no-go, not “fix it later”.
Keeping the coding agents in bounds
- Each works to a defined brief with a bounded scope.
- Every change is reviewed before merge.
- Tests run under the least-privileged database role, so a pass means something.
- The specification changes only by a recorded decision; scope creep is simply refused.
This is a development process, not a product feature. The CRM itself does not review or approve agent changes; it limits agents to reading data and adding internal notes.
What we learned
- Writing the brief is most of the work. Ambiguity in, ambiguity out.
- A reviewer who did not write the code disagrees in useful ways.
- Time-boxes with review triggers beat fixed deadlines.
- Say what you will not build, early and in writing.
FAQ
Does this produce maintainable code?
Only with strict briefs, tests under realistic roles and human review of the architecture. The process is the safeguard, not the tool.
How much human time does it take?
Most of it goes to writing briefs, reviewing evidence and making decisions. Much less goes to typing code.