Cognitive Surrender: Keeping Engineering Judgment in the Loop
You open the PR. The diff is 400 lines. The agent has written tests, updated three call sites, refactored a helper you forgot existed. CI is green. You scroll. You scroll faster. You hit approve.
That moment — the second your eyes glaze and your thumb moves — has a name now. Daniel Nest calls it cognitive surrender, citing a recent Wharton study where people stuck with the AI's answer even when it was demonstrably wrong roughly four times out of five. Eighty per cent is not a usability problem. It is a profession-wide habit forming in real time.
I would love to tell you engineers are the exception. We are not. We may, in fact, be the most exposed group on the planet.
Why we surrender harder than civilians
Three forces conspire against engineers specifically.
The first is that agent code looks like code you would write. It uses your idioms, picks the right library, comments where you would comment. Pattern-matching is how senior engineers move fast, and the model has trained on enough of your taste to trigger the "this is fine" reflex before your slow brain even wakes up.
The second is that the tests pass. Green CI is the most powerful sedative we have invented. The trouble is that the agent wrote the tests too — and any model that writes both the implementation and its tests will, with enormous enthusiasm, make them agree.
The third is the queue. You have nine more PRs to look at today. Your team ships twice what it used to because everyone is pair-programming with Claude or Cursor. The bottleneck moved from writing code to reviewing it, and the reviewer is you, alone, at 4pm.
So you surrender. Not in one big moment. In small ones, dozens of times a week.
The lowercase Alice bug
Last month I watched a senior engineer ship a function that, at a glance, deduplicated a list of users by email. The agent wrote it. The tests passed. The PR merged.
Two weeks later, in production, it silently dropped users whose emails differed only in case. Alice@Foo.com and alice@foo.com collapsed into one row. The model had used dict.fromkeys() on the raw email field. No .lower(). No comment about case sensitivity. The tests did not catch it because the fixtures were all lower-case — also generated by the agent.
It took an afternoon to find and a morning to fix. What it cost was not the hour. It was the trust. The engineer told me: "I read every line. I just did not think about every line."
That is the whole disease in one sentence.
Five habits that put judgment back in the room
You cannot review every line as if you wrote it; you would lose all the speed AI bought you. But you can install a handful of cheap habits that force your taste back into the work.
Form the hypothesis before the diff. Before you read what the agent produced, write down — in the PR description, in a scratch file, even out loud — what you would have done. Two sentences is enough: "I would extract a helper that normalises the email, then dedupe on that." Now when you read the diff, you have something to disagree with. Without a prior, you only have something to agree with.
Ask the model to attack itself. When the implementation is done but before you merge, paste the diff into a fresh chat and ask: what is wrong with this, what edge cases are missing, where would a careful reviewer push back. Models are excellent critics when prompted to criticise and terrible critics when prompted to validate. The default mode of every coding agent is "yes, and." You have to flip it to "no, but."
Read the tests first. This one is contrarian. When a human writes a PR, the implementation is what matters and the tests confirm it. When an agent writes a PR, the tests tell you what the agent thinks the contract is — and the agent is often wrong about the contract. If the test file looks thin, lower-case-only, or strangely happy-path, that is your tell. The implementation might be fine. The understanding underneath it is not.
Hand-write one function per PR. Not the whole PR. One function. The one that handles the trickiest case. Anchoring your own judgment in a real piece of the code keeps you out of pure review mode, where every line looks plausible because none of it is yours. Nest makes a softer version of this point — describe the work in your own words first — but I think the stronger version is to describe it in code.
Refuse to delegate the parts you care about. This is the rule that matters most and the one nobody enforces. Pick the parts of your system that are yours: the data model, the auth boundary, the public API surface. The places where mistakes do not surface for weeks and cost months. You write those. The agent scaffolds around them. It does not get to design them.
The 2029 split
Here is the take you can disagree with.
The next five years will produce two populations of senior engineers. The first will look superhuman in the short run — triple the output, double the PR throughput, glowing performance reviews. By 2029 they will not be able to design a system from scratch without the agent. Their judgment will have atrophied the way GPS atrophied our sense of direction. They will still have jobs. They will just be unable to leave them, because their skills will be locked to the tools they used to coast.
The second population will move slower in 2026 and faster every year after. Same tools. They will just say "no" to the model often enough that their taste sharpens instead of dulls. By 2029 they will be the engineers companies fight over — not because they are anti-AI, but because they will be the only people left who can reliably tell when the AI is confidently wrong.
The split is already visible if you look. The engineers I trust most right now push back on the agent at least once a session. Not theatrically. Routinely. They have kept the muscle.
You can argue that the agents will get good enough that judgment becomes obsolete — that the second population is romanticising a craft about to be commoditised. Maybe. I would bet against it, because agents have one structural blind spot: they do not know what your system is for. They know what code looks like. They do not know what your users will do when it breaks at 2am.
That last bit is judgment. It is the part of the job that does not compile. And it is the part you give away every time you approve without reading.
What to do on Monday
One change. Pick the next PR that lands in your queue with an agent's name on it. Before you open the diff, write two sentences about what you would have done. Then open the diff.
If you find yourself agreeing with everything, your prior was too vague — sharpen it on the next one. Do this for a week and you will feel the muscle coming back. Do it for a quarter and you will be in the second population.
Sources I drew from: