A team of AI specialists, run the way a good engineering team is run.
If you want to know how the software gets built and why it is safe to run your business on, this is the long version. It is the same process that builds and runs BLAQ every week, and the same one we set up for client development teams.
Twenty-two specialists in four groups, one owner per area.
A generalist model prompted at random is a contractor who has never seen your codebase. A specialist with a brief is a team member who knows where the bodies are.
Planning writes the spec: a product manager, a systems architect and a full-stack lead. Nothing is built until the plan is approved by a person.
Build is a backend and a frontend engineer plus thirteen domain specialists, each owning one area of the product. A fixed ownership table routes every task to the right one.
Quality reviews the diff against the spec, writes the tests, hunts the bug and measures the slow path. Three of the four cannot edit code at all. That is by design.
Release is one role. It is the only one that can touch a server, and it only moves on a human's approval.
Every role has a written brief. New hires read the handbook. So do agents.
A brief is not a prompt. It is the standing document a role works from every time, and it is maintained like code.
- 01Ownership
- The exact area this role owns, and where it stops. A fixed table routes work, so two roles never fight over one file.
- 02Rules of the area
- The conventions, patterns and non-negotiables of that part of the product, written down once.
- 03Known gotchas
- The mistakes earlier work made in this area, stated plainly, so they are made once and not twice.
- 04What it may not do
- Build, deploy, write to production, change its own brief. The limits are in the text and enforced by the hooks.
When something goes wrong twice, the lesson goes into the brief of the role that owns that area. The team gets smarter without anyone having to remember.
Seventeen hooks check every action before it runs.
Trust is not a control. A hook is. Agents work faster than people and never get tired, so the rails matter more, not less.
A hook sits between the intention and the action. It reads what is about to happen, compares it with the rules, and either lets it through or stops it with a message that says why. The agent cannot argue with it and cannot switch it off. Some of what gets stopped:
- A deploy from a coding sessionOnly the release role may touch a server, and only through its own process.
- A change without its testsNew logic ships with a test in the same change. A fix ships with the test that would have caught it.
- A secret in sourceCredentials and keys never enter a commit. Scanned on every pull request as well.
- A branch switch in a shared working copyParallel sessions work in isolated copies, so one cannot clobber another.
- A database migration that cannot be re-runMigrations are additive and idempotent. Nothing destructive, nothing that breaks on a second run.
- A merge done by handMerging and promotion happen through pull requests and the release role, with the review gate in front.
- A feature without its documentationThe in-app help guide and the support assistant knowledge update in the same change, or the change is not done.
- A production write without confirmationConnectors to live data are read-only by default. Writes are confirmed. Deletes are not possible.
Idea to production in eleven stages. The same eleven, every time.
Three environments on three branches. Two code-review gates. A human approves every promotion. Tests and documentation ship in the same change as the code.
What CI checks
Compile. Tests. Migration validation. Secret scan. Static analysis. A red check blocks the merge; nobody overrides it.
What a review gate is
A code review of the whole change against its spec, run before staging and again before production. Blocking findings halt the promotion until they are fixed.
What production looks like
Blue/green. The new version starts beside the old, passes a health check, then takes traffic. The old one stays warm for a fast switch back. Migrations are additive and re-runnable, so data never blocks a rollback.
People go on leave. Agents run out of context. Both need a written handover.
Every working session ends with notes: what was done, what is in flight, what is owed, what to watch. The next session, by any role, starts from those notes rather than from zero.
Lessons are not left in the notes. When something bites, the fix goes into the code and the lesson goes into the brief of the role that owns that area. That is how a team of agents gets better over time instead of repeating itself.
The same discipline covers the product. The in-app help guide, the knowledge the support assistant answers from, and the release note the user sees all update in the same change as the feature. Documentation that ships later never ships.
A handover, in outline
- 01 done this session
- 02 in flight, with the branch it lives on
- 03 owed: deploys, reviews, decisions waiting on a person
- 04 lessons, and which brief they were written into
- 05 what to check first next time
Connectors are the badge and the keycard.
An agent reaches data and services through connectors, and each connector carries exactly the access its role needs.
Read-only
Where reading is enough, the connector cannot write. Most roles only ever read.
Writes confirmed
Where a role must write, each write is confirmed before it runs, and it is logged.
Deletes impossible
No connector can delete or change structure. Those stay with a person, by hand, on purpose.
07One build, one deployer
Specialists change code. One role touches servers.
No specialist can build the product or deploy it, and the hooks make sure of it. There is one release role. It merges, builds on the server, runs the migrations and switches traffic, and it does each of those things only after a person has said yes.
08A human leads
The AI team proposes and executes. It does not decide to ship.
Direction, release approval and production judgement stay with a person. That is not a limitation we are waiting to remove. It is the design. Safety first, AI second, and the result is software a business can run on for years.
The questions people ask before they trust it.
Is my software written by AI?
Much of the code is produced by AI specialists. All of it is directed by a person, reviewed against a written spec, covered by tests, checked by automated gates and approved by a human before it reaches staging or production. The question that matters is not who typed it but what it had to pass. Our answer is: more than most software passes.
What happens when it is wrong?
It is caught early, or it is caught safely. Two code-review gates and a human smoke test sit before production. Production is blue/green: the new version comes up beside the old one, is health-checked, and only then takes traffic. If something slips through, the previous version is still there and we switch back. Migrations are additive, so data is never in the way of a rollback.
Can you set this up for my team?
Yes. That is our second service. We bring the roles, the briefs, the guardrails, the pipeline and the handover discipline, and we tailor them to your product and your people. See services.
Do you still need developers?
Yes, and they do more. People set direction, write and approve specs, review, test on staging and make the production call. The team gets a lot more built per person, and the person stays accountable.
What does the human actually decide?
What to build and why. Whether the plan is right. Whether it works on staging. Whether it ships. Everything with consequences stays with a person.
Contact
Want this for your team?
We set up the roles, the briefs, the guardrails and the pipeline, then work alongside your developers until it is theirs.