The Engineering Workflow Playbook

Context

My team suddenly started producing far more code. And, as time went by, I wrote less and less code myself. None of this had a methodology behind it yet.

The tell was in shipping time. Quality went up. Approvals kept coming. The team spent more time contemplating architectural decisions. And the code got produced way faster than our review culture could keep up with it.

Lin et al. (opens in a new tab) name the failure: the Capability–Comprehension Gap. It is what happens when everything looks fine, so we leave the pilot’s seat and go have a coffee. It widens invisibly, because the output keeps looking fine right up until a bug sneaks up and demands the understanding that eroded while nobody was measuring it. Shen & Tamkin ran a randomized trial (opens in a new tab) and found the same thing from the other end: comprehension, code reading, and debugging all degraded, and there was no average speed gain to pay for the loss.

What we are losing is a floor, and we have raised one before. Assembly (opens in a new tab) used to be everybody’s job. We wrote enough of it, and understood it well enough, to build compilers we could trust to be deterministic — and once something mechanical guaranteed the layer beneath us, we stopped reading it and stood on it instead. The floor didn’t disappear when we rose above it. It got trustworthy, and then it moved up.

AI tools are offering us the same bargain, and I don’t think it has closed yet. A compiler earns the right to go unread by being deterministic. A model doesn’t. So until we build something mechanical to hold that layer, the only thing holding it is whether we still understand the work — which is why I think you build the mechanical part on purpose instead of waiting for it to arrive.

The problem was never how to get more leverage. It was how to take the leverage without the atrophy. What I built is what a team does about that on a Tuesday.

What I built

We encoded our tribal and tacit knowledge into layers, using our prompt engineering skills, and created personas — a skeptical principal engineer, an adversarial security reviewer — that help us protect the review gates between stages while keeping human judgment in the loop.

The layers were made to be company-wide by design. The philosophy layer sits in the middle, with a leadership layer above it and an engineering layer below it for execution. That is what makes the work, and the gates, interchangeable depending on each team’s workflow.

The vocabulary is what we teach, because knowing is half the battle. The Cognitive Integrity Threshold is the floor an owner has to stay above; Passenger Syndrome is what falling below it looks like from the outside; and Proof of Ownership is how a gate tests for it — Lin et al.’s three capacities turned into a question a reviewer can actually ask: can you verify the output, reconstruct the reasoning when it breaks, and recognize where the work should have stopped?

Design decisions

The design was made to be a human philosophy — one you could drop into any workflow, as a skeleton or a baseline.

When it came to engineering, we had six stages governed by four moves. The moves are what tell us how to work: sense the work before you process it, do the thinking before the doing, checkpoint the seams, stay the owner. None of them mention code, which is what lets the philosophy be carried to any other team that wants to protect its own business rules and constitution — whether they are coders, designers, or marketers.

Human judgment gets applied at the gates, and it gets augmented by AI agents that never arbitrate each other. Personas run isolated, and their findings reach human judgment intact — each carrying its own severity, never merged into a verdict. Pappu et al. (opens in a new tab) found that agent teams which negotiate their way to consensus land up to 41% below their own best member: the pressure to integrate averages the expert against the non-expert instead of weighting them. Anyone who has watched agents agree with each other will recognize the shape of it. Geng & Liu’s legal-agent framework (opens in a new tab) advocates the same separation, making sure review and scoring happen in a fresh context. Defend Your Architecture turns that inward: before a plan reaches review, its author has to survive an adversarial persona first.

A methodology only sticks if you can actually operate it. So we made every concept resolve to something an engineer can open: a Confluence page, a persona invoked at a gate, a calibration audit against a real feature. It is also why we held back on putting a number to the Cognitive Integrity Threshold. Nothing we have can measure one yet, and a governance idea you can’t measure is a good way to build theater.

Impact

I prepared an executive proposal and pitched it to the C-suite and the company’s leadership. It was approved, and I get to watch it roll out while still being there as an advisor and experimenter.

When I went to analyze what the changes had done to our GitHub repository, the numbers were not what I expected. Pull requests per active author went from around 2.8 a week to 4.4. Time to merge went down, despite most PRs being five times the size they were before. And the repository grew three times as much as it had at baseline, on the same gross volume of editing. Same amount of work, sliced into more independent units that merge faster, and more of which sticks.

One of them didn’t hold up, and I want to say what happened to it. My first pass had median ticket cycle time falling 32%, from 11.9 days down to 8.1. Then I truncated the window so every ticket had the same amount of time to finish, and it came out at 14.7 days — worse than where we started. The 8.1 was fast recent work hiding slow work that hadn’t finished yet. The number came off the page.

The team has been consistently able to deliver bigger changes with fewer defects, to the point that the product team almost ran out of features to give us. You may wonder whether all that production was slop. Our bug numbers say otherwise, and so does the code: comparing the standards we hold now against the ones we held before, ours got stricter. Instead of asking which corners we could skip to get the product good enough, we started asking whether we were overengineering it.

I want to be clear about what this isn’t. One team of four, before and after, with no control arm, and the models kept improving underneath us the whole time. Some of what we measured was already trending before we started, which is why the pre-trend check mattered more than the headline did.

But let’s be honest. This experiment started only a few months ago, and even seeing three times the production, it is too early to tell. If you want to know where your own team stands, the Pre-Flight Checklist is twelve questions scoring an organization across ownership, review integrity, skill trajectory, and guardrails: the self-serve version of the audit I would otherwise run in a room. Until we can measure this properly, it is something we believe rather than something we know. Even if it is working.

Sources

The methodology is a synthesis, so I name what I borrowed. Everything else — the stages, the gates, the personas, and the practice built on top of them — is mine.

• Lin, Ge, Xu, Li, Gao, Xing, Yamada, Zhang, Zhang & Tu, “Position: Human-Centric AI Requires a Minimum Viable Level of Human Understanding” (opens in a new tab) (2026) — the Capability–Comprehension Gap, the Cognitive Integrity Threshold, and the three capacities under Proof of Ownership.
• Shen & Tamkin, “How AI Impacts Skill Formation” (opens in a new tab) (2026) — the randomized evidence that comprehension erodes under delegation, with no average speed gain to pay for it.
• Pappu, El, Cao, di Nolfo, Sun, Cao & Zou, “Multi-Agent Teams Hold Experts Back” (opens in a new tab) (ICML 2026) — why persona findings cross to a human unmerged.
• Geng & Liu, “Parthenon Law: A Self-Evolving Legal-Agent Framework” (opens in a new tab) (2026) — the scorer is never the editor, borrowed across domains.