On 24 July 2026, ptrchm catalogued a week of software humiliation: a banking app that needs three FaceID logins before 3D Secure shows up, Slack on macOS stealing focus and sending git pull into a group chat, an LG warranty form that fails at the last step, a car update that adds input lag and random reboots. The useful detail is his guess about the teams behind those bugs. Many probably already have the latest models and generous token budgets.
That detail is the whole argument.
Stronger models raise the value of local engineering judgement. They make code generation cheap, so the scarce thing becomes knowing which invariants matter in this codebase, which helpers encode the boundary, and which failure mode from six months ago is waiting to come back. Senior engineers get more leverage from coding agents for exactly that reason.
Teams only capture that leverage when the mental model leaves one person's head. If subsystem invariants, failure modes, and review heuristics stay private, the agent reaches for generic priors and the reviewer spends their time reconstructing hidden policy from a diff.
Cheap generation raises the price of local judgement
Sean Goedecke makes the same point from a cleaner angle. He compares his own LLM use with Terence Tao's ChatGPT conversation about a counterexample to the Jacobian Conjecture. The surface details matter. Tao's messages are short. The model replies more concisely. Tao pushes back when something looks wrong. He proposes directions himself.
Goedecke's conclusion is the one engineers should keep: expertise in the domain changes what the model can do for you. If you have a good theory of your codebase, you can push the LLM much harder. You can say don't we already do X?, this abstraction is too big, or why does this retry sit outside the idempotency wrapper? The model does not learn your subsystem during that conversation. You bring the subsystem into the conversation.
That is why senior engineers often look disproportionately good with the same coding agent everyone else has. They can kill a plausible patch with two questions. They know which existing pattern the model should have reused. They know when a compact diff hides a large blast radius.
The model has plenty of implementation patterns. Expertise supplies selection pressure.
Private mental models starve the agent
Goedecke also says system design problems are dominated by concrete specifics. That line lands hardest in production systems. Agents usually see repository text, an issue, some tests, maybe a design doc. They rarely see the private rulebook a senior reviewer carries around.
That rulebook usually covers a small set of things:
what the subsystem protects
invariants that must keep holding
failure modes that already hurt once
patterns and helpers the codebase already trusts
questions a reviewer asks before approving
Without that rulebook, the agent falls back to generic software advice. Generic advice can write decent code. It can also add a retry in the wrong layer, bypass the tenancy boundary by caching on the wrong key, or open a migration path that works in staging and deadlocks under real traffic. The dangerous combination here is a property of your wiring: cheap generation on one side, private local knowledge on the other.
Goedecke says the human is often the bottleneck because the hard part is communicating the exact solution shape the human wants. I believe that diagnosis. In many codebases, the missing information is not syntax, framework API knowledge, or even algorithm choice. The missing information is local policy. Which helper exists for a reason. Which error deserves a retry. Which timeout means the remote side may already have accepted the side effect. Which test failure tells you the boundary moved.
Write one page per subsystem
Teams keep spending energy on prompt recipes. I would spend it on subsystem playbooks.
The practical move is boring: write down the subsystem rulebook in a form small enough to sit inside the daily agent loop. I would make it one page, close to the code, for one subsystem. A good playbook covers:
what the subsystem protects
invariants
known failure modes
approved helpers or patterns
review questions
rollout and observability checks
Small matters. Long architecture documents rarely shape a code generation session or a five-minute review. Short playbooks often do, because people will keep them open and agents can keep them in context. Tao's advantage in Goedecke's example comes from highly specific pressure, questions like does X work here? and given Y and Z, why A? A subsystem playbook turns that pressure into a reusable artifact. What matters in the picture is the shared artifact in the middle.
flowchart LR
S[Senior engineer] --> P[Subsystem playbook]
I[Issue] --> A[Coding agent]
C[Relevant code] --> A
P --> A
A --> PR[Proposed change]
P --> R[Reviewer]
PR --> R
R --> U[Edge case found]
U --> P
One file shapes generation and constrains review. The loop matters because it gives the agent the same local policy the reviewer will use later, and it gives the reviewer a place to record new edge cases instead of repeating folklore in comment threads. That is how senior knowledge becomes multiplicative.
Shared playbooks change review economics
Shared playbooks change the economics of review. Without them, a senior engineer reads an agent-produced diff and reconstructs the hidden rules by hand. Why does this write happen before that ack? Why did the model skip the existing helper? Does this retry make duplicate money movement possible? The reviewer can still catch the problem, but the team experiences seniority as a tax. Every PR asks the same person to reload the same private context.
With a playbook, the reviewer spends that effort once and then keeps tightening the policy. The review conversation gets shorter and sharper. You can point to an invariant instead of re-explaining it. You can reject a change because it violates a named rule instead of because it feels off. You can update the playbook when you find a new edge case, which means the next agent run and the next reviewer both inherit the fix.
This is where ptrchm lands for me. The Agentic Era raises expectations for team output. Teams feel pressure to ship more. A quarter spent fixing stability bugs still looks dull in a slide deck, so the boring work gets postponed. Then the same teams act surprised when faster generation produces faster regressions. ptrchm calls the result AI debt. I buy the label. The playbook work will never headline a launch post, and it still changes product quality.
Start with scar tissue
This advice has a boundary. I would start where the subsystem already has scars and the constraints barely move: auth, payments, retry policy, migrations, tenancy boundaries, data export, audit logging. Those areas have stable invariants and expensive failure modes. That makes them good candidates for a short rulebook.
I would skip the first week of a new product idea. In that phase, the team is still discovering the constraints, and a playbook will read like aspiration. Goedecke makes the same point in softer form when he says most people will use a mix of approaches. In familiar areas, domain knowledge lets you steer hard. In unfamiliar areas, the model can still get you something useful. Keep the blast radius small there, and save the playbook habit for places where the rules have hardened.
Ask each senior engineer to pick one subsystem they own and publish one page this week. Feed that file to the coding agent. Require reviewers to use the same file. If the artifact reads like onboarding prose, it is too vague to matter. If it cannot reject a bad PR, rewrite it until it can. Senior engineers become more valuable around coding agents when their mental model becomes visible.
Steal this
Save this as subsystems/<name>/PLAYBOOK.md, then tell the agent to use it before proposing a change and tell reviewers to use it before approving one. This is a template, not a standard. Replace the placeholders with the ugly details from your codebase.
# Subsystem playbook: <name>
## What this subsystem protects
- <money movement / tenant isolation / auth state / regulated data / etc.>
## Invariants
- <Condition that must always hold>
- <Condition that must always hold>
- <Condition that must always hold>
## Failure modes we already know about
- <Timeout after remote side accepted the request>
- <Retry creates a duplicate side effect>
- <Out of order event arrival>
- <Migration breaks older readers or writers>
## Approved patterns and helpers
- Use <existing helper / module / wrapper> for <boundary>
- Keep writes behind <service / repository / transaction helper>
- Emit <metric / log / trace> on every externally visible failure
## Review questions
- Which invariant could this change break?
- Where does the boundary live in this diff?
- Did the change reuse the approved helper?
- What happens on timeout, retry, replay, and partial failure?
- Which test proves the failure mode stays closed?
## Rollout and observability
- Add or verify: <metric>
- Add or verify: <structured log>
- Define rollback trigger: <condition>
## Agent instructions
Before proposing code:
1. Restate the invariants this task must preserve.
2. Name the existing helper or pattern you will reuse.
3. Call out one likely failure mode and how the code handles it.
4. List the tests or checks that should fail if the change is wrong.
If a reviewer cannot answer the review questions from the diff and this file, the playbook is still too soft.