The last post left the engineering station with a one-line test: if the reasoning behind a decision would be useful to the engineer who touches this code in six months, write it down. That test tells you what deserves an entry, but it does not tell you how to recognize the moment, in the middle of a session, when you have crossed from accepting a suggestion into making a decision. Those are different skills, and the second one is a skill nobody ever had to develop before.
A developer working with Cursor, Claude Code, or any other coding agent makes dozens of accept, reject, and modify calls in a single session. Before AI, writing code took long enough that judgment and typing were hard to tell apart. Now the typing is nearly free, and what is left, underneath all of it, is a small number of moments where you actually chose something. Everything else is motion. The engineering station’s whole problem is that motion and choice now look identical on screen, and the Judgment Log is worthless if it cannot tell them apart.
What Autocomplete Actually Covers
Not every accepted suggestion needs to be logged. Doing that will turn the log into noise that nobody will ever open. You should skip anything that a competent engineer, looking at the same context, would have written. A null check on a parameter that obviously needs one, import statements, variable names: these are not decisions. The model is pattern-matching against an existing convention, and accepting the match is not judgment. It is recognition. You can also skip any suggestions you reject for purely mechanical reasons: wrong variable name, missing import, inconsistent formatting.
The test underneath all of these: could you explain the choice in one word? “Convention.” “Typo.” “Style.” If the honest explanation is a single word, it is autocomplete, whatever the tool called it when it offered the suggestion.
What Crosses the Line
A judgment moment has a different shape. There were at least two paths a reasonable engineer could have taken, and you picked one, and the reason you picked it is not visible anywhere else, not in the code, not in the ticket, not in the PR title.
The clearest signal that a judgment needs to be logged is when you have disagreed with the model. When you reject what the AI proposed and do something else. That gap is the most valuable data in the entire log because it is direct evidence that your judgment overrode a plausible alternative.
The second signal is a decision to trade one thing for another. Performance against readability. A quick fix against the correct fix, taken deliberately, with the corner acknowledged. A security or data-handling choice in which you granted a process broader access than the immediate task required because narrowing it would have cost you an afternoon, or worse, a weekend. Every one of these is a real tradeoff, made under real constraints, and every one of them looks completely invisible in the diff. The code shows what you built. It never shows what you weighed.
The third signal, and the easiest to miss, is a gap you are knowingly leaving open. Not a bug. A known absence, deliberately left, because the scope decided elsewhere does not require you to close it yet. The design entry in the last post flagged the missing error state for expired codes. The engineering entry has to make the same gap visible from the code side, or the two entries do not actually connect, and the chain breaks exactly where it matters.
If any of these three are present: disagreement with the model, a real tradeoff, or a deliberate gap, write the entry. If none of them are present, you are looking at autocomplete with better formatting.
The Threshold at Industry Scale
This month, the same question showed up in a much more serious context. Sysdig researchers documented what they described as the first fully autonomous ransomware attack. A human chose the target and set up the infrastructure. After that, the AI agent handled the attack itself: reconnaissance, credential theft, lateral movement, privilege escalation, and encryption. When it hit obstacles, it adapted without waiting for someone to tell it what to do next.
TechCrunch put it well: the attack still needed a human, just not for the part that caused the damage.
A few days later, Anthropic changed Claude Code’s default permission model. Sensitive actions that could previously run automatically now require explicit approval.
That change matters because Anthropic did not leave the decision to individual developers. It drew the line in the product itself. Some actions are safe enough to automate. Others have enough risk, or are hard enough to undo, that a person needs to stop and make the call.
That is the real lesson: every team already has a line between “the model can do this” and “a human needs to decide.” The problem is that the line usually lives in each engineer’s head and moves from one session to the next.
Anthropic was forced to make that line explicit. Your team should do it before an incident forces the decision for you.
The Expanded Engineering Entry
The version from the last post was compressed for the chain. Here is the same decision, written at the level of detail that should actually exist in your log when you are the one writing it, not summarizing it for a reader:
AI-generated validation logic accepted for the active promo code path. Checked against the two most recent similar features in the codebase; the pattern matched, no changes needed. Rejected the AI’s proposed expiry-handling branch. The model defaulted to assuming expiry windows are always present, which is the more defensive assumption and the one I would normally take. Overrode it because the PM scope decision [link] explicitly excludes expiry for this campaign, and adding the handling anyway would mean shipping dead code against a decision someone else already made. Took the simpler, unguarded path instead. Left a comment at the validation entry point naming the gap directly: no expiry check exists; this is deliberate. See the PM entry before removing or bypassing this comment. Did not add rate limiting on the validation endpoint. The AI did not suggest it either. Flagging here because campaign traffic could make this worth revisiting before the next promotion, not because anyone decided against it.
Five sentences longer than the compressed version, and every added sentence is doing work: naming the model’s default so a future reader knows what was overridden, and surfacing a gap that nobody asked about, because nobody having asked is itself worth recording.
The Actual Practice
Before you accept or reject the next non-trivial suggestion, ask one question: would explaining this choice out loud take one word, or would it take a sentence?
One word, move on. A sentence, that sentence is the entry. Write it in the time it takes to write it, at the PR, not reconstructed later from memory that will not hold the reasoning by then.
That is the whole discipline. Not a new tool, not a new ceremony. A habit of noticing the handful of moments per session that were never autocomplete to begin with, and refusing to let them pass as if they were.