The Job Was Never Typing

Key Takeaways

• An experienced engineer concluded on Hacker News that coding is solved, that agents close the loop from task to working code, and that months spent practicing the craft now feel wasted. What they listed as still mattering (knowing what to ask, what to check, what to build) is a list of judgment skills.
• The empirical record says “solved” is ahead of the data: in METR’s randomized trial, experienced developers were 19% slower with AI tools while believing they were 20% faster.
• Judgment, the thing that is left, erodes exactly when it is outsourced. Across five experiments (N = 3,132), access to AI advice nearly eliminated willingness to say “I don’t know”; accuracy fell to about a third while confidence nearly doubled.
• Microsoft’s CHI 2025 survey of 319 knowledge workers found higher confidence in generative AI associated with less critical thinking, and the work itself shifting from doing the task to verifying the output.
• The grief in these threads is real, but it mourns the wrong thing. Typing was never the identity. The part of the job that made someone a good engineer is the part now under pressure to atrophy.

Someone with years of engineering behind them posted a hard conclusion to Hacker News this week: coding is a solved problem. Agents can take a clear task, write the code, test it, see what failed, fix it, and go again until it works. A novice still struggles, they granted, because a novice does not know what to ask or how to tell whether the result is any good. But an engineer who has built real systems can now move across domains and push an agent until the system works. What still matters, in their words, comes down to knowing what to ask, what to check, and what you are actually trying to build.

Then came the part that made the thread ache. Looking back on months spent building projects to get better at the craft, they concluded much of it was time wasted on a problem that had already been solved. Forty-seven comments arrived, split between “it is more solved than you realize” and “no it is not.” The same week, another thread asked the question underneath the question: coding agents killed my identity, how do you feel?

Did Engineering Actually Become Writing Specs?

The shape of the work has visibly moved up the stack. The discourse moved with it: spec-driven development has front-paged on Hacker News three separate times in the past year, complete with a backlash calling it waterfall in new clothes. Engineers who spent a decade writing functions now spend the day writing specs, RFCs, agent skills, and acceptance criteria, then reading what comes back.

It is tempting to call this a demotion, from author to editor. The older diagnosis is more interesting. In the late 1970s, Edsger Dijkstra wrote a short note titled “On the foolishness of natural language programming”, against the recurring dream that we could one day instruct machines in plain English. Formal notation, he argued, is not a burden we endure but a protection we enjoy: formal texts are “an amazingly effective tool for ruling out all sorts of nonsense.” His conclusion inverts the dream entirely: “Instead of regarding the obligation to use formal symbols as a burden, we should regard the convenience of using them as a privilege.”

Dijkstra was wrong about whether machines would ever accept plain English. He was right about what gets lost when they do. A prose spec that no one can mechanically check has surrendered the nonsense-filter that formality provided, which means the nonsense-filtering has to happen somewhere else. It now happens in the head of whoever writes and reviews the spec. The precision did not stop being the job. It stopped being enforced by the compiler and started being enforced by you, which is a harder discipline, not an easier one.

So yes: the artifact changed. Specs, RFCs, architecture notes, and skills are what engineers produce now, and the good ones are the ones precise enough to generate their own tests. But producing them was always the hard part of engineering. Code was the residue of decisions; the decisions were the work. What the agents removed is the typing. What they left is the deciding.

What Happens to Judgment When an Answer Is Always Available?

Here is where the comfortable version of this essay would end: the job is judgment now, engineers are good at judgment, carry on. The evidence will not permit that ending.

In July, Chiara Marcoccia, Walter Quattrociocchi, and Valerio Capraro posted a preprint with a title that is itself the finding: “AI advice suppresses people’s willingness to say ‘I don’t know’, even when the advice is wrong and accuracy is incentivized.” Across five experiments with 3,132 participants, people answered difficult questions and could always decline to answer. The researchers engineered the questions so the AI’s advice was wrong, deliberately separating the act of consulting AI from any benefit of consulting it.

Merely having access to the AI nearly eliminated participants’ willingness to suspend judgment. It did not matter whether the advice was requested or simply displayed. People answered more questions, were correct about a third as often as those without AI, and their confidence nearly doubled. Read that again as a mechanism, not a scoreline: the AI did not just supply wrong answers. It moved the internal threshold at which a person decides they know enough to answer at all.

“I don’t know” is not a small thing to lose. It is the load-bearing wall of engineering judgment: the pause before you ship, the reason you write the test, the honest answer to “will this scale?” that triggers the design review. A fluent answer perpetually on tap does not argue you out of that pause. It dissolves the felt need for it.

Are Engineers Somehow Exempt?

The natural objection: those were trivia questions, and engineers are professionals operating in their own domain. Two studies close that exit.

METR ran a randomized controlled trial with 16 experienced open-source developers working on 246 real issues in their own mature repositories, randomly assigned to allow or disallow AI tools. With AI allowed, developers took 19% longer. Before starting, they expected AI to speed them up by 24%. After finishing, having lived through the slowdown, they still believed it had sped them up by 20%. This is the same signature the trivia study found, in the most favorable possible population: the judgment error survives expertise, and it survives direct experience. These developers’ assessment of their own productivity was not just wrong; it was wrong in the same direction after the evidence came in.

Then there is Microsoft and Carnegie Mellon’s CHI 2025 survey of 319 knowledge workers, who supplied 936 first-hand examples of using generative AI at work. The pattern that emerged: “higher confidence in GenAI is associated with less critical thinking, while higher self-confidence is associated with more critical thinking.” The work itself, they found, shifts “toward information verification, response integration, and task stewardship.” Which is to say: the survey independently confirms both halves of the Hacker News thread. The job really has become oversight rather than execution. And the people most convinced the tool has it handled are the ones checking least.

Put the three studies side by side and the shape is consistent. It is not that AI makes people stupid. It is that AI access quietly retunes the decision of when to engage judgment at all, while inflating the confidence that no engagement was needed. The skill does not vanish. The trigger for using it does.

So What Is Actually Left?

Everything that was ever actually the job.

Deciding what is worth building, which is a question about users and the world, not about syntax. Deciding what “correct” means for this system, this data, these failure modes, before an agent optimizes its way to a green test suite that checks the wrong thing. Noticing that the fluent, plausible, working-looking output in front of you is subtly not what the system needs, which is the same discipline as knowing whether an answer is thought or retrieved. Saying “I don’t know yet” in a design review, out loud, at the exact moment a confident answer is one keystroke away.

The asker’s own list said this. Knowing what to ask is requirements judgment. Knowing what to check is verification judgment. Knowing what you are actually trying to build is the oldest judgment there is. Their conclusion mourned the wrong casualty: the months spent building projects were not practice at typing, they were practice at exactly these three things, with the code as the exercise equipment. The equipment changed. The muscles are the same muscles, and the grief about identity deserves a better target than the keyboard.

But the studies add the warning the thread did not have: what is left is also what is at risk. The remaining work is judgment, and judgment is the specific faculty that AI access erodes, invisibly, while confidence rises to cover the gap.

How Do You Keep Judgment You No Longer Exercise by Default?

The preprint contains its own answer, and it is bracing rather than comforting. When the researchers paid for accuracy and penalized error, participants consulted the AI less, answered more accurately, and recovered some willingness to say “I don’t know.” Not all of it: still far less than people who had no AI at all. But stakes moved the threshold back.

The engineering translation is direct. Judgment survives where being wrong costs something, and atrophies where fluent output is free.

• Write the acceptance checks before the agent runs. A spec precise enough to generate its own tests is Dijkstra’s privilege of formality, rebuilt one layer up. If the spec cannot fail, it is not a spec; it is a wish.
• Review as if your name ships with the output, because it does. The LLM-as-judge results are what happens when verification itself gets outsourced to the same fluency that produced the work.
• Keep “I don’t know yet” as a first-class answer. In standups, design docs, and code review. The study’s mechanism runs through the quiet elimination of that sentence; saying it on purpose is the counter-exercise.
• Occasionally, deliberately, work without the tool. Not as nostalgia. As calibration: METR’s developers could not feel a 19% slowdown through the fluency. You cannot measure your own drift from inside it.

The thread asked what is left for experienced engineers, and the honest answer has two halves. What is left is the part of the job that was always the point: the deciding, the doubting, the asking. And it is now the part of the job you have to practice on purpose, because for the first time, the default is not to use it.

Coding may or may not be solved. Judgment is not, and it does not stay sharp for free anymore.