One workspace for engineers and their agents

If AI agents write part of your code, their instructions are part of your engineering standards. They deserve the same treatment as code: one copy, under version control, changed by review.

At Buy Nothing, where I am fractional CTO, work on the mobile app, the web app and the backend services runs through AI coding agents every day. By the summer of 2026 the useful prompts and skills had multiplied, and each lived in someone's local configuration. Everyone was running a slightly different copy of the rules, and nobody could see where the copies differed.

One reviewed home

The fix was a workspace repository. It holds the skills, the agent definitions and the shared protocol, and it sits beside the code repositories rather than inside any of them. Nothing changes there except by pull request. Each machine links to the repository instead of keeping a copy, so updating is a pull and there is nothing to fall out of step.

The more important habit is writing back. The skills that build and ship the mobile apps began life as a runbook nobody had versioned. Nearly every release since has found something it did not know: a setting that a clean rebuild silently wipes, a signing key that had to be traced, a build step that only matters when the native project is out of date. Each finding went back into the skill through review, usually the same day. The next build starts from what the last one learned.

How much should an agent decide on its own?

The workspace defines a small set of agent roles: architect, frontend developer, backend developer, auditor and product owner. They share one protocol. Observe first: read the ticket, the earlier decisions and the standards. Then plan. Only then implement, and record what was done against the ticket.

Two gates keep people in charge. Anything that qualifies as an epic, because it spans services, changes the architecture or introduces a new pattern, stops until a written decision record is approved. And no agent starts another: at the end of each step, a person decides whether the next role runs. The agents do the work; the loop stays under human control.

Not every task needs the ceremony. A quick fix or a question goes straight to a prompt, with no roles and no paperwork. The coding standards apply either way.

Documents that serve people and agents

Three kinds of document can describe the same thing, so each has one owner. The standards say how we agree to write code. Each repository's instructions file states facts about what that repository currently is. The runbook records history: what happened on a given ticket and why. When two of them disagree, everyone knows which one to fix.

The same material onboards people. A new frontend contributor gets a short bundle to load into Claude as project knowledge, with a rule of thumb: think in the chat app, build in the coding tool. They ask the bundle questions instead of reading it end to end, and the coding agent already knows the house rules from the repository.

What carries over

• Treat prompts, skills and agent instructions as code: one copy, version control, review.
• Link every machine to the shared copy instead of copying it, so drift cannot start.
• Write each hard-won lesson back into the skill that will run next time.
• Give agents roles and a protocol, and leave the decision to start the next step with a person.
• Give each kind of document one owner, and brief people and agents from the same material.

The tools will keep changing. A team that keeps its practices in one reviewed place can change tools without losing what it has learned.