A human being in the loop does not guarantee meaningful human oversight.
During long AI-assisted development sessions, the agent can continue producing coherent work, passing tests, and proposing reasonable next steps after the architect’s attention has started to decline. The change is difficult to detect from inside the session because nothing necessarily looks broken.
The answer is not perfect vigilance. It is a workflow with structural interruptions: bounded assignments, hard completion stops, early real-operator evidence, and an independent reread before the next slice is authorized.
I know the architect’s trance by a specific moment.
I stop reading Claude’s visible reasoning and start pressing Enter.
Nothing dramatic changes. The work still sounds intelligent. The tests still pass. Each next step appears to follow naturally from the last one. I remain present, and I still make every final click.
But I am no longer directing the work with the same level of judgment.
That is what makes the trance dangerous.
I approved a sequence, not one bad decision
I can see the pattern most clearly in the Client Operating Manifest.
The original product need was legitimate. Marketing OS needed a governed way to represent durable client context: priorities, constraints, canonical references, unresolved questions, and the operating assumptions downstream workflows were permitted to use.
The work began with contracts. Contracts led to persistence. Persistence led to lifecycle rules, approval, current-version selection, seeding, readiness evaluation, an operator interface, legacy importing, field confirmation, and increasingly deep hardening.
Each slice was locally reasonable.
By the time I exercised the real operator path, the manifest page had 12 expanded sections, 28 forms, 22 textareas, 22 Save buttons, and several per-entry confirmation actions.
I wanted humans to review the system’s work.
I had built a system that required humans to produce it.
The real artifact exposed an even deeper problem. The importer had been designed and tested against a simplified structured fixture. The actual Angstrom manifest was an 11,152-byte mixed document containing a YAML-like header, Markdown headings, comments, dotted keys, and a fenced, nested strategy block.
The system had become highly capable at processing the artifact I had imagined.
It could not process the artifact I actually had.
I did not approve one obviously bad decision. I approved a sequence of reasonable decisions until the accumulated system no longer served the original product intent.
The project record proves the accumulated drift. It does not prove that fatigue caused it.
I know what the sessions felt like because I was there.
I know the point where critical reading becomes following. I know how easy it is to accept one more intelligent suggestion because it appears to complete the thought already in motion.
That is the architect’s trance.
The trance does not announce itself
I still try to read Claude’s visible reasoning while it works.
It helps me catch misunderstood requirements, unsupported assumptions, and unnecessary architecture before they become code. It also teaches me how the agent interprets contracts, evidence, tests, and ambiguity.
But sustained attention has a limit.
The agent does not become less willing to continue because I have been working for hours. It can inspect another file, propose another abstraction, run another test, and explain another improvement with the same apparent confidence.
My ability to evaluate those steps does not remain equally steady.
At the beginning of a session, I know exactly what has been authorized, what remains outside the slice, and what evidence should prove completion. Later, I may still be reading, but I challenge less. Eventually, the interaction becomes a rhythm:
Read → Continue → Approve → Continue
The human remains technically in the loop while becoming cognitively less present within it.
This is not primarily a character flaw. It is what happens when a workflow treats human attention as an inexhaustible control.
A serious operating discipline has to account for the tired architect, not only the ideal one.
Coherent work weakens the warning signal
The trance is harder to detect because AI-assisted mistakes no longer have to look careless.
An agent can build a clean implementation around a reasonable assumption. It can document the assumption, write tests that inherit it, and explain why the result is correct. Every part of the work may agree because every part descends from the same interpretation.
I once wrote a compatibility test that compared the current serializer with another call to the current serializer:
f(x) == f(x)
The test passed.
It proved determinism. It did not prove backward compatibility.
It would have remained green even if the change had altered every content hash produced by the previous version. The test never compared the new behavior with the earlier behavior it claimed to preserve.
In another case, I called a status-document regeneration canonical. Its parser reported clean lifecycle buckets, no warnings, and no conflicting decision states. The same document still contained a section saying a service had been built and another saying it did not exist.
The checks had verified shape.
They had not verified truth.
These incidents are not proof of depleted attention. They explain why depleted attention is so dangerous. Coherent output and green checks remove the obvious signals that would normally tell the architect to stop.
When plausible work becomes cheap and nearly unlimited, “this looks unfinished” can no longer be the primary trigger for scrutiny.
Momentum starts making product decisions
AI can almost always suggest another useful improvement.
Another abstraction may be cleaner. Another validation may close an edge case. Another refactor may prepare the system for future scale.
Many of those ideas are good.
They are not automatically decisions.
The fact that something is logically next does not mean it has been authorized. A roadmap may identify it. A reviewer may recommend it. A completion summary may describe it as the immediate follow-up.
None of those grants authority to build it.
This became an explicit rule in my workflow:
Priority language is not authorization.
Without that separation, momentum begins making product decisions. One successful task flows directly into another, then another, until the architect is approving the continuation of the conversation rather than the needs of the product.
That is also how the trance connects to overengineering. Before unnecessary architecture accumulates, someone has to keep approving reasonable additions that the current problem did not require.
Sometimes that person is me.
The workflow has to interrupt itself
I cannot depend on recognizing the exact moment when active direction becomes passive continuation.
By the time I notice, I may already be inside it.
The protections therefore have to be chosen before the session and fire regardless of my condition. They are contracts made by my alert self that continue binding my tired self.
The assignment begins as a bounded slice
The prompt establishes what is changing, what is excluded, which decisions govern the work, and what evidence should demonstrate completion.
The agent receives autonomy inside that boundary. It does not receive standing authority to continue beyond it.
Completion creates a hard stop
When the acceptance criteria are met, the sequence ends.
Suggested improvements remain suggestions. They may be recorded with an owner and a reason to revisit them, but they do not quietly expand the active task because the context is already loaded.
Real operator evidence comes before deeper hardening
The manifest failure produced a new rule: a user-facing slice cannot continue through prolonged adversarial hardening until the exact real artifact and ordinary authenticated operator path have been exercised.
Synthetic fixtures and broad green suites remain useful. They are not substitutes for the real workflow.
The exact client, artifact shape, filename, interface, and human sequence must be tested early enough to influence the architecture. Moving faster does not mean weakening proof. It means moving contact with reality earlier.
The next prompt begins with an independent reread
OpenAI Codex remains outside the production-writing path. Before compiling the next substantial task, it rereads the governing decisions, current state, affected implementation, tests, migrations, routes, and relevant failure history.
It does not treat Claude Code’s completion summary as authority.
This is not a second human decision-maker. Codex can still misunderstand the system, and it does not decide what the product means. Its value is that the next slice does not depend entirely on the builder’s momentum or my memory of the previous session.
I still retain final authority, but I am no longer the only mechanism responsible for noticing that the work has drifted.
What I still have to decide
I continue reading Claude’s reasoning because catching drift early is cheaper than diagnosing it after implementation.
What has changed is that I no longer treat uninterrupted attention as the safeguard.
I reserve human judgment for questions the deterministic environment cannot answer: what the system is supposed to mean, which source owns a decision, which tradeoff is acceptable, whether the proof supports the claim, and whether the work should continue at all.
Autonomy is not authority, but authority is not merely the presence of a human approval step. It requires someone to exercise judgment over product meaning and consequence.
The controls can constrain that judgment.
They cannot derive it.
Ratchet Development is not an algorithm
Ratchet Development is an operating discipline, not an algorithm for eliminating judgment.
A contract can refuse invalid structure. A test can prove a defined property. A permission boundary can restrict an action. A checkpoint can stop one task from silently becoming another.
None of them can calculate the correct product decision.
The methodology does not deterministically tell me which failure deserves a permanent control, which architecture is proportionate, or when the product is good enough to move forward. Those remain judgment calls informed by evidence.
That is a limitation, but pretending otherwise would be worse.
The system can make my decisions more explicit, bounded, and reviewable. It cannot make them for me.
This has not solved shared authority
My current workflow has one architect and one final decision-maker: me.
I have not proven how the same model works when the person defining the boundary differs from the person approving the work, when authority is delegated across a team, or when several architects disagree about what the system should become.
Permissions can define who may act.
They cannot resolve conflicting interpretations of product intent.
A broader version of Ratchet Development will need a clearer model for decision ownership, delegated authority, disagreement, and supersession before I can claim that the workflow transfers cleanly to a larger development organization.
For now, that remains an untested edge.
Designing for the tired architect
I still read Claude’s reasoning. It remains one of the best ways to understand where the agent is taking the work.
But my ability to keep reading is no longer the control I trust most.
The slice has a boundary. Completion stops the sequence. Real operator evidence arrives before another hardening cascade. The next prompt begins from a fresh, independent reading of the system rather than the builder’s momentum.
Those mechanisms exist for the version of me who is tired, impressed by the work, and ready to press Enter again.
A governed workflow cannot assume the architect will remain fully alert forever.
It has to return the decision to the architect before another continuation becomes another layer of architecture.