Two Doors, One Gate: Navigating Governance Beyond EDD

Karl-Heinz Reichel of Calyntro distinguishes between awareness tools and governance tools in AI-assisted development, arguing that a single onboarding document cannot serve both functions for a team of forty developers. The team found that experienced developers ignored shared rules designed for newcomers, leading to a separation of governance (repository-bound, identical for all) from awareness (skill-dependent guidance).

Onboarding guardrails and power-user friction look like the same problem. They aren't. June 2026 · 7 min · Karl-Heinz Reichel Table of Contents A few weeks ago we wrote about why we run AI coding sessions with two developers instead of one https://calyntro.com/blog/posts/programming in threes/ . Triplet programming works well as a transitional structure — a way to build shared fluency while the risk of agent-driven, codebase-wide changes is still high. It does not survive contact with forty developers. At team scale, you cannot put everyone in a triplet indefinitely, and you should not want to. Some developers arrived at agentic coding only recently. Others are already running skills and multi-agent setups solo and have been for months. The instinct, reasonably, is to write it all down: a CLAUDE.md , a copilot-instructions.md , a shared set of rules — plan before you change code , do not touch files outside the task scope , explain your reasoning before you act . We tried exactly that. The result was a document that newer developers needed and barely noticed, and that experienced developers read once, in detail, and immediately wanted to relax. That reaction was not impatience. It was the predictable result of asking one document to do two jobs that don't actually fit together. We have actually run into this shape of problem before — just at a different point in the pipeline. In The Last Mile Problem https://calyntro.com/blog/posts/2026-05-31-last mile problem/ and again in EDD Closes the Loop — But Only Half of It https://calyntro.com/blog/posts/2026-06-20-edd-closes-half-the-loop/ , we drew a distinction between two kinds of tools that get conflated constantly in AI-assisted development: Awareness tools change what someone knows . A linting warning, an AI review comment, a suggestion to loop in another team — these work only if the person on the receiving end cares to act on them. We called this the receptionist: it notices, it says something, and whether anyone stops depends entirely on whether they were listening. Governance tools change what someone can do . Branch protection, required reviewers, a merge gate that simply will not open. This is the turnstile. It does not negotiate. The mistake worth reaching for here is a receptionist when the situation actually calls for a turnstile — an AI review that correctly flagged a risky interface change, and a developer who merged anyway, because a correct recommendation with no teeth is still just a recommendation. Writing a single onboarding document for forty developers repeats the same pattern, mirrored. A planning requirement is, by nature, a receptionist: it asks a developer to pause and think before acting. That is exactly the right amount of friction for someone two weeks into agentic coding. For a developer who has been doing this — internalized, automatic, several skills deep — the same instruction is a receptionist stopping someone who already has full clearance, every single time, for no reason connected to actual risk. Conversely, treating onboarding guardrails as if they were optional — something a confident developer can simply choose to skip — quietly turns governance into awareness for everyone, the moment the most senior person in the room decides the rule doesn't apply to them today. One document was being asked to do two jobs it cannot do at the same time. Once you see it this way, the fix follows the same shape we landed on for the merge gate: keep awareness and governance as genuinely separate layers, not as two paragraphs in the same file. The governance layer stays small, repository-bound, and identical for everyone. No direct pushes to protected branches. No changes outside the declared task scope. Mandatory review before merge. This layer is not calibrated to skill — it is calibrated to blast radius, and an agent's blast radius does not shrink because the developer steering it is experienced. It lives in version control, travels with the repository regardless of whose machine it runs on, and is enforced structurally — branch protection, CI gates, CODEOWNERS — not just requested in a prompt. A senior developer cannot read past it any more than a new one can, and that is the point: it was never about trust in the first place. The scaffolding layer is personal, and it is allowed to shrink. Explicit planning before a change. A second person in the loop. Verbose reasoning at every step. This is the receptionist, deliberately turned up high for someone still building judgment, and deliberately turned down for someone who has already demonstrated it. It belongs to the individual, not the repository — closer to a personal coding profile than a project rule. The honest reframing for the team is this: the planning step was never really a rule about code. It was an externalized form of judgment a developer hadn't built yet — standing in for the second person in our triplet setup. Once that judgment exists, on its own, the scaffolding has done its job and can step back. That is not an exception being granted. It is the scaffolding successfully making itself unnecessary, which was the actual goal the whole time. What makes this credible rather than arbitrary is that the path is visible and earnable, not asserted by title or tenure: a developer's track record across actual sessions — no scope violations, sound judgment under review, demonstrated fluency — is what shrinks their scaffolding, not how senior they happen to be on paper. There is a version of this that goes one step further, and it connects back to something we have written about from the other direction. Skill-level is one axis. It is not the only one that matters. A confident, fast-graduated developer touching a file that has never been part of anything risky is a low-stakes event regardless of who they are. The same developer touching a file that — according to the repository's own history — has repeatedly co-changed with code three other teams depend on is a different situation entirely, independent of their tier. This is exactly the signal we described in the last-mile and EDD pieces: change coupling derived from actual commit history, not from someone's static opinion about which files are "important." A newcomer editing an isolated utility function does not need the full weight of scaffolding just because their tier says so. An experienced developer touching a highly coupled interface should not sail through frictionless just because their tier says so either. In other words, the threshold for how much governance or scaffolding applies to a given change can be informed by two inputs at once — who is making the change, and what the change actually touches, according to the codebase's own coupling history — rather than skill-level alone. That keeps the gate honest in both directions: it does not punish a careful newcomer working in a quiet corner of the code, and it does not wave through a confident developer standing at a boundary the repository's history says has never been a purely local decision. This integration is not built yet. It is the natural next step once you accept that "who is this developer" and "what does this change actually risk" are two different questions, and that only one of them is about the person. There is a way to sidestep the tiering problem almost entirely — and it starts from a different question. Instead of asking how skilled is this developer , ask who owns this change . The answer doesn't change because an agent wrote the diff. "The AI did it" is not a defense for a bug any more than "the linter passed" ever was. The developer opening the pull request owns what's in it, and there is a simple test for whether that ownership is real: can they explain, in review, what the change does and why — without falling back on the agent's own explanation of itself? If they can't, the patch doesn't merge. Not as a verdict on the developer's general competence, but as confirmation that the editor role EDD describes has actually been exercised for this specific change, not merely rubber-stamped. This works precisely because it requires no advance categorization of anyone. It is the same rule for the new hire and the ten-year veteran, applied after the fact to the change itself rather than in advance to the person. Combined with approval-required branch protection already in place via CI/CD, it is a turnstile in the proper sense — not a suggestion that explainability would be nice, but a condition the change cannot pass without. What this rule doesn't do is tell a developer how to get to the point of being able to explain a change with confidence when they're not yet sure. That is where scaffolding still earns its place — just offered differently than a tier assigned at onboarding. Rather than the system deciding in advance who needs the planning ritual and who doesn't, the developer decides, per task, whether to invoke it: a "safer mode" — a skill or flag that constrains the agent to the explicitly declared scope and asks before touching anything adjacent — that anyone can reach for, for a single task, without it being a statement about their standing. That reframing matters more than it looks. A tier assigned at onboarding is a status. A safer mode invoked for one afternoon because today's change touches unfamiliar territory is a tool. The first labels a person. The second describes a moment — and senior developers reach for it too, on the parts of the codebase they don't know well, which is exactly when they should. The design work from the earlier sections doesn't disappear — someone still has to define what "safer mode" actually constrains, and what change-coupling risk should trigger heavier review regardless of who's making the change. What shifts is who decides when to use it, and the explainability gate at the end makes that choice consequential either way: skip the safer mode on an unfamiliar change, and the gap shows up in review, not three weeks later in production. The pattern underneath both of these stories — the merge gate and the onboarding document — is the same one: awareness and governance solve different problems, and a tool built for one quietly fails when asked to do the job of the other, often without announcing that it has failed. We caught it once at the point where code meets the repository. It was waiting at the point where a developer meets the agent for the first time, too. The fix in both places turns out to be the same shape: keep the governance layer small, universal, and non-negotiable — ownership and explainability, enforced at merge, regardless of who you are — and let the awareness layer be something people choose for themselves, task by task, rather than something assigned to them once and carried as a label. This post extends earlier pieces on the last mile problem in AI-assisted development and why EDD closes only half the loop, and follows on from why we structure development in threes.