Software engineer Sean Goedecke argues that writing code has stopped being the scarce skill, which means engineers now have to identify, specifically, what they still do better than a model. The stakes are direct: if you cannot name that thing, he writes, you cannot justify the gap between your salary and a subscription that costs roughly a hundred dollars a month. His answer, laid out in a personal essay, is that the durable edges are not technical at all in the usual sense. They are organizational.
Goedecke’s framing starts from a metric he calls “value over replacement”: not what an engineer shipped, but how much better they performed than whoever would have filled the seat instead. He says that bar used to be easy to clear because writing code carried a high fixed cost. Now that cost has collapsed, and he is blunt that pretending otherwise, in either direction, is a mistake. He rejects both the claim that models cannot really code and the claim that AI-written code will sink companies that rely on it.
Where he lands is narrower than most “AI won’t replace me” arguments. He does not think engineers can retreat into harder technical territory and stay ahead indefinitely, because that territory keeps shrinking. Tasks that were out of reach for models at the start of 2026, in his account, were not out of reach for long. His bet is that two things resist automation for structural reasons rather than temporary capability gaps: familiarity with a specific codebase, and the ability to communicate about technical work in plain language.
On the first point, Goedecke says that in his own use, the coding mistakes models make have shifted. He reports that outright hallucinations and simple logic errors have become rare. What remains, in his assessment, are errors of ignorance (not knowing a module already exists, or which system owns a piece of functionality) and errors of paranoia (building elaborate safeguards around risks that a person with context on the system would simply accept). He argues that catching those errors requires exactly the context a model lacks: history with the codebase, and the willingness to tell an agent its cautious, verbose solution is wrong.
On the second point, he makes an observation about writing quality that is also drawn from his own experience of using different models rather than a formal test: that newer systems are getting better at coding while getting worse at plain prose, and he coins the term “Claudish” for what he hears as Anthropic’s models’ dense, semi-compressed style. His explanation is that good writing is harder to grade automatically than code or math, so labs training for capability have less signal to optimize communication, and some of what a reader receives may be a rough translation of a model’s internal reasoning rather than writing aimed at a human.
Goedecke’s own framing stops short of a harder truth his argument implies. Naming a thing you are better at than the model is only useful advice if the thing is actually nameable and actually yours to hold. Deep codebase familiarity and the standing to override an agent both depend on tenure, trust, and a manager who lets you slow a project down to disagree with a confident tool. Those are organizational conditions, not skills you can practice alone, which is an uncomfortable place to land for engineers who picked the job specifically because it rewarded individual technical output over office politics.
His closing warning is about the alternative: he calls someone who forwards AI output as their own work a “meat proxy,” and says that role disappears the moment the workflow around it gets productized. The practical test for any engineer reading this is whether they could describe, in one sentence, what a model would still get wrong on their own team’s codebase today.
Sean Goedecke, in an essay on his personal blog, seangoedecke.com, titled “You have to beat the models at something.”
