Our AI Dev Workflow Died Twice. Here's the Autopsy.

TL;DR

One day in June 2026 we shipped the second generation of our AI development workflow to the whole team. It had validation gates at every step, a set of orchestration scripts, and months of accumulated rules behind it. Backend, frontend and edge each ran it once that day. It burned more time than working by hand, blew the main context, and produced output that plainly didn’t meet the spec. We pulled it the same day.

The third generation was built on the corpse the next morning. It is a single slash command, /develop, a shared entry point after dozens of skills had come and gone. The root CLAUDE.md is now 30 lines, and every engineer on the team starts development through /develop. The rebuild took a day.

This post is the autopsy of the two generations that died, because the deaths taught us more than the survivor. Both died of the same disease: rules exploding past the point where anyone could say which ones mattered. Only the root cause differed.

Context

One monorepo, multiple projects. Backend, frontend and edge engineers all work in the same repo, and all of them use Claude Code.

The goal, from the start, was one workflow the whole team shares, versioned in git. A personal setup is easy; you tune it to yourself and nobody else has to live with it. A shared one has to survive contact with three stacks and every engineer’s habits, which is exactly what killed the first two generations.

Generation one died of role accumulation

The first design was the obvious one: a skill per role. The one that writes code is coder, the one that writes tests is tester, plus reviewer, syncer for docs, team-lead to coordinate. There were more.

The three stacks need different knowledge in a different order (frontend reads UI specs, backend designs schemas, edge handles protocol logic), so every role got a per-stack prefix: be-coder, fe-tester, edge-team-lead. A backend engineer would call /be-team-lead, describe the feature, and it would coordinate the rest.

It worked. It was also three of everything. At its peak the system was twenty-six skills alive at once, out of forty that existed over the five months, and any improvement to a role had to be applied three times, drifting a little each time. Nothing was broken, which is what made it dangerous: the maintenance cost just ratcheted up with every fix.

Generation two died of process accumulation, in one day

In late May, Claude Code shipped workflows: a script that orchestrates a fleet of subagents, with schema checks between steps, no human in the loop. This looked like the answer to everything above. I distilled generation one into a fully automatic track: /super-plan to investigate requirements, /super-develop to run code, tests and review end to end, /super-doc to file the documentation.

I ran it myself a few times. It looked good, and I believed the rules were tight enough by then. So it went to the whole team, and that launch day is the incident at the top of this post.

The failure modes, as an incident report:

• Context exhaustion. Every step lived in one flow, so the main context died before the code did.
• No proportionality. A ten-line change ran the same giant track as a full feature.
• No escalation path. When a run drifted midway it had no mechanism to stop and ask a human. It just kept going, wrong, to the end.
• Wrong maintenance surface. Every project in the monorepo had to define its own dispatch logic, so every fix was a patch to workflow definitions instead of to code.

Generation one accumulated roles; this one accumulated process. A workflow turned out to be a good container for one fully determined step and a terrible container for judgment.

The rebuild took one day, and only because after months of maintaining everything in triplicate, I knew exactly which rules were load-bearing and which were packaging.

Root cause: nobody re-reads process prose

Here’s how the bloat actually happens. Someone imagines a failure and adds a rule against it, “be careful not to break existing features”, a sentence that has never once changed an outcome. Someone else, after a bad run, pastes an example from one module into a shared description, one line of which literally said “today only”. Both survive review, because nobody re-reads process prose at that resolution inside a PR that runs several thousand lines. From then on the agent reasons over them, run after run, spending tokens on noise.

Is a given sentence load-bearing? Nobody knows. Unless a run feels obviously wrong, nobody audits a workflow description word by word, which is precisely how generations one and two swelled.

What died, what survived

Across both generations, the rules that died fall into three categories:

• Knowledge snapshots. Copy today’s project layout into a rule, and tomorrow’s commit makes the rule lie.
• Model pinning. Hardcode which model handles which job, and the next model release makes the choice wrong.
• Process ritual. Paragraphs asking the agent to honor a ceremony. Requiring evidence before changing a phase gave us something concrete to check.

What survived, almost without exception, is a single type of rule: where the boundaries are. The coder owns production code; the tester owns tests. The orchestrator coordinates rather than implements. Each subagent loads the rules for its assigned role. Boundaries age well because they describe responsibilities, not the code or the model, both of which keep changing.

Above all of it sits one meta-rule: the whole company runs on the same rules, and a rule that isn’t in git doesn’t exist. Everything else is flexible: model choice, how heavy a run should be, how the conversation goes. The shared workflow defines the review and test gates for both small fixes and full features.

Rules have to be allowed to die

The fix that stuck is a retro step. At the end of a run, the agent analyzes its own friction: where the human stepped in, which gate retried, which instruction it ignored. The findings go into a report for the next cleanup pass. Reports accumulate; periodically we harvest. Lessons worth keeping get promoted into rules and sunk into the layer where they belong, and the reports get deleted. The biggest single harvest so far digested 29 reports, drawn from real runs rather than imagined failures.

In progress: 22 Friction Reports Taught Us Which Rules to Kill

What a run looks like now

Generation three was built by subtraction: knowledge placed only where it’s needed instead of everywhere. The model decides whether a change deserves the full apparatus or a light touch. The orchestrator coordinates and never edits; subagents do the work and bring back evidence, which keeps the main context thin.

A recent run, concretely: an engineer typed /develop, described the feature, answered a few rounds of questions, confirmed, and left to do other things. The run covered a requirements interview grounded in the existing code and business docs, a cross-stack plan file so the other stacks could pick the feature up mid-flight, implementation, tests, review, docs for QA, the retro, then commit, PR and ticket report.

The 17 review agents caught one critical issue and the run fixed it before reporting back. After confirming requirements, the human still decides on scope changes, review suggestions and final delivery, and confirms that the change solves the original need.

To be honest about the trade: a full run takes half an hour to a few hours, and a large feature takes longer. You type less and read more. Review is the job now, and the gates exist to make the reading tractable: every claim a subagent makes comes back attached to evidence instead of a description of what it thinks it did.

Further reading: Every Phase Gate in /develop Wants an Artifact, Not a Sentence

Why not BMAD, spec-kit or claude-flow

After two rebuilds, I was reluctant to take on another process to maintain. Our own experience had made me cautious about duplicating roles and removing human decisions from a run. I wanted to know what adopting a framework would change about those problems.

Adopting a framework means adopting its process worldview, and the processes actually worth money to us are all our own: the plan file three stacks relay across sessions, the ticket reports our PM will accept without a meeting, commits written so an agent can compile a sprint into release notes. We would still have to build and maintain those parts, whichever framework we chose.

There’s a sharper version of the problem. When something breaks, our retro can ask “missing rule, not followed, or not needed” because every rule is ours. Under someone else’s framework there’s a fourth kind of friction, “their rule doesn’t fit us”, and we would have another layer to investigate before deciding what to change.

Building it yourself is slow, and the tuition was real. What it bought was familiarity with every rule we had kept, which helped us rebuild quickly. If some piece of this ever becomes small enough and pure enough that an off-the-shelf part fits exactly, swapping it in is the obvious move. The precondition is that you can still swap.

In progress: How This Workflow Dies

In July, a bug ticket landed on a frontend engineer. It turned out to be a small backend problem. He ran /develop anyway, and half an hour later the backend team had a PR: fix and tests in their architecture and style. They looked it over and merged it as-is.

A personal workflow raises one engineer's ceiling.
A shared one raises the floor under everything the team ships.