GET /api/work/agent-fleet
Running a dozen AI coding sessions on one repo
Live · · sole engineer
I use AI helpers to write much of the code, like a chef running a fast kitchen. This is the system of rules and checks that keeps the plates right.How I use AI coding agents at scale without vibe-coding, auto-loading rules, hooks that block the dangerous operations, and review triggered by consequence.
- Claude Code
- Node.js
- Git hooks
- GitHub Actions
- Jest
- Markdown
- commits in 6 months
- 14K
- parallel sessions
- 10+
- operating docs
- 300+
- models cross-reviewing
- 2
Parameters
Request
curl "https://portfolio.dylansg0318.workers.dev/api/ work/ agent-fleet"
Response200 OK · 3.1 KB
{ "id": "agent-fleet", "title": "Running a dozen AI coding sessions on one repo", "status": "live", "year": 2026, "category": "work", "role": "sole engineer", "summary": "How I use AI coding agents at scale without vibe-coding, auto-loading rules, hooks that block the dangerous operations, and review triggered by consequence.", "summary_plain": "I use AI helpers to write much of the code, like a chef running a fast kitchen. This is the system of rules and checks that keeps the plates right.", "stack": [ "Claude Code", "Node.js", "Git hooks", "GitHub Actions", "Jest", "Markdown" ], "metrics": { "commits_in_6_months": "14K", "parallel_sessions": "10+", "operating_docs": "300+", "models_cross_reviewing": "2" }, "problem": "One engineer, an ERP-sized scope. AI coding agents made that possible, but running several at once against one repository has very specific failure modes: one session sweeps another's staged files into its commit, a broad test run melts the shared machine, a plausible-looking number ships because nobody checked it, and every new session starts with no memory of the rules the last one learned the hard way.", "unique": "Guardrails as code, not advice. Hooks run before every tool call and block the operations that can't be undone: broad git adds, skipping the pre-commit gate, full-tree test runs. A coordination layer registers every live session and locks the shared git index while another session is mid-commit. Rule files auto-load when a session touches a matching path. And second-model review is triggered by consequence, not diff size: a 20-line ledger change gets reviewed, a 500-line UI change ships on sight.", "ai": "This one is about the AI. Honest framing: agents write most of the code in the ERP. I write the rules, decide the architecture, pick what gets reviewed, and verify the result with queries, curl and screenshots before anything is called done. What follows is the system that makes that division of labour safe rather than reckless.", "learned": [ "A gate that can't fail hasn't passed. Early reviews were rubber stamps. The fix was a different model with a different vantage point, and treating \"looks fine\" as a failed review.", "The model isn't the risk, the process is. Every incident in the ledger came from a missing constraint, not a bad suggestion, and every one became a hook or a rule the same day.", "Documentation is the multiplier. The 300-plus operating docs are what let a fresh session be useful in its first minute instead of its first hour, and what make my own decisions readable to me six months later." ], "subsystems": [ { "id": "agent-fleet/tooling", "title": "The guardrails, extracted", "summary": "The session-lock layer, fleet scripts, context tooling and review-agent configs behind the fleet write-up, lifted out of the private repo and sanitized.", "page": "https://portfolio.dylansg0318.workers.dev/projects/agent-fleet/tooling" } ], "page": "https://portfolio.dylansg0318.workers.dev/projects/agent-fleet" }
Live: this is the answer from this site’s API, not a mock. Send re-runs the request with your parameters; if the answer names a page, it opens.
The problem
One engineer, an ERP-sized scope. AI coding agents made that possible, but running several at once against one repository has very specific failure modes: one session sweeps another's staged files into its commit, a broad test run melts the shared machine, a plausible-looking number ships because nobody checked it, and every new session starts with no memory of the rules the last one learned the hard way.
What was unique
Guardrails as code, not advice. Hooks run before every tool call and block the operations that can't be undone: broad git adds, skipping the pre-commit gate, full-tree test runs. A coordination layer registers every live session and locks the shared git index while another session is mid-commit. Rule files auto-load when a session touches a matching path. And second-model review is triggered by consequence, not diff size: a 20-line ledger change gets reviewed, a 500-line UI change ships on sight.
Where AI fit in
This one is about the AI. Honest framing: agents write most of the code in the ERP. I write the rules, decide the architecture, pick what gets reviewed, and verify the result with queries, curl and screenshots before anything is called done. What follows is the system that makes that division of labour safe rather than reckless.
Parameters
Request
curl "https://portfolio.dylansg0318.workers.dev/api/ work/ agent-fleet? fields=problem%2Cunique%2Cai"
Response200 OK · 1.3 KB
{ "problem": "One engineer, an ERP-sized scope. AI coding agents made that possible, but running several at once against one repository has very specific failure modes: one session sweeps another's staged files into its commit, a broad test run melts the shared machine, a plausible-looking number ships because nobody checked it, and every new session starts with no memory of the rules the last one learned the hard way.", "unique": "Guardrails as code, not advice. Hooks run before every tool call and block the operations that can't be undone: broad git adds, skipping the pre-commit gate, full-tree test runs. A coordination layer registers every live session and locks the shared git index while another session is mid-commit. Rule files auto-load when a session touches a matching path. And second-model review is triggered by consequence, not diff size: a 20-line ledger change gets reviewed, a 500-line UI change ships on sight.", "ai": "This one is about the AI. Honest framing: agents write most of the code in the ERP. I write the rules, decide the architecture, pick what gets reviewed, and verify the result with queries, curl and screenshots before anything is called done. What follows is the system that makes that division of labour safe rather than reckless.", "page": "https://portfolio.dylansg0318.workers.dev/projects/agent-fleet" }
Live: this is the answer from this site’s API, not a mock. Send re-runs the request with your parameters; if the answer names a page, it opens.
Inside it
- The guardrails, extracted
The safety system I describe in the fleet write-up, pulled out on its own and stripped of everything company-specific — the actual traffic-cop code, cleaned up and published.The session-lock layer, fleet scripts, context tooling and review-agent configs behind the fleet write-up, lifted out of the private repo and sanitized.
Parameters
Request
curl "https://portfolio.dylansg0318.workers.dev/api/ work/ agent-fleet? fields=subsystems"
Response200 OK · 452 B
{ "subsystems": [ { "id": "agent-fleet/tooling", "title": "The guardrails, extracted", "summary": "The session-lock layer, fleet scripts, context tooling and review-agent configs behind the fleet write-up, lifted out of the private repo and sanitized.", "page": "https://portfolio.dylansg0318.workers.dev/projects/agent-fleet/tooling" } ], "page": "https://portfolio.dylansg0318.workers.dev/projects/agent-fleet" }
Live: this is the answer from this site’s API, not a mock. Send re-runs the request with your parameters; if the answer names a page, it opens.
The story
Fair question: how does one person build and run a system this size? I use AI coding assistants, heavily, several at once, like a kitchen with multiple line cooks. They’re fast. They’re also confidently wrong sometimes, and if you just accept whatever they produce you’re not an engineer, you’re a spectator.
So the real work is the kitchen, not the cooking. I decide what gets built and how it should behave. Written house rules load on their own so every helper knows things like “never let a website overwrite the product catalog.” The dangerous actions aren’t discouraged, they’re blocked, the way a fryer has a guard rail. Anything touching money or the books gets a second set of eyes before it runs. And nothing gets called done until I’ve watched it work: run the numbers, clicked the buttons, seen the result.
Every time something went wrong, it became a new guard rail the same day. The helpers make me fast, the rules keep it safe, and I own everything that ships.
Vibe coding versus engineering
The difference isn’t whether a model wrote the code. It’s whether anyone can say why the code is the way it is, what was checked before it shipped, and what would’ve stopped it if it were wrong. Everything below exists so one person can own the output at a speed they couldn’t otherwise keep up.
Rules that load themselves
The repo carries a top-level rules file every session reads, plus path-scoped rules that load when a session opens a matching file: touch channel code and the “master is sacred” rule shows up; open a deploy workflow and the pipeline’s gotchas do. Area docs for inventory, shipping, finance and jobs hold the invariants and the incident ledger for that area. A session doesn’t have to remember to read the rules.
Hooks that say no
Advice gets ignored under time pressure, by humans and agents both. So the operations that have caused incidents are blocked, not discouraged:
git add -A,git commit -a,--no-verify: blocked by a pre-tool hook. Staging by explicit path is the only path, because the index is shared and a broad add sweeps another session’s work into your commit.- Broad Jest runs: blocked. Scoped suites only. The full lanes run in CI on every push, where they can’t take down the machine ten sessions share.
- A commit while another session is mid-commit in the same checkout: blocked until they finish.
Each block prints the reason and the sanctioned alternative. A subagent that never read the rules gets stopped the same way, which is the point.
Knowing who else is here
A coordination layer registers every session at start, tells it who else is live and whether any of them share the same checkout, and lets a session broadcast a finding to the others. By default a session works in its own git worktree, branched fresh from the integration branch, so parallel work never touches the same index at all. The failure ledger is public inside the repo — every incident, its cost, and the constraint it produced — and reading it is how a new session, or a new engineer, learns why the rules are shaped the way they are.
Review by consequence
Reviewing everything trains everyone to skim. So a second-model review is triggered by what a mistake would cost, not by how many lines changed. Money, books, bulk writes to production data, writes to a vendor’s API, migrations, permissions, and anything that can be silently wrong get reviewed before executing, by a different model than the one that wrote it. UI, copy, layout and read-only reports ship on sight.
Verify before you assert
The one rule I’d keep if I could only keep one. Nothing is “done”, “fixed” or “passing” without the output behind it. Run the query, curl the endpoint, screenshot the page. “It’s probably fine” after five minutes of reasoning is worth less than one command that shows what it really is. That applies to me as much as to the agents.
What I learned
- A gate that can't fail hasn't passed. Early reviews were rubber stamps. The fix was a different model with a different vantage point, and treating "looks fine" as a failed review.
- The model isn't the risk, the process is. Every incident in the ledger came from a missing constraint, not a bad suggestion, and every one became a hook or a rule the same day.
- Documentation is the multiplier. The 300-plus operating docs are what let a fresh session be useful in its first minute instead of its first hour, and what make my own decisions readable to me six months later.
Parameters
Request
curl "https://portfolio.dylansg0318.workers.dev/api/ work/ agent-fleet? fields=learned"
Response200 OK · 688 B
{ "learned": [ "A gate that can't fail hasn't passed. Early reviews were rubber stamps. The fix was a different model with a different vantage point, and treating \"looks fine\" as a failed review.", "The model isn't the risk, the process is. Every incident in the ledger came from a missing constraint, not a bad suggestion, and every one became a hook or a rule the same day.", "Documentation is the multiplier. The 300-plus operating docs are what let a fresh session be useful in its first minute instead of its first hour, and what make my own decisions readable to me six months later." ], "page": "https://portfolio.dylansg0318.workers.dev/projects/agent-fleet" }
Live: this is the answer from this site’s API, not a mock. Send re-runs the request with your parameters; if the answer names a page, it opens.