Two things landed on Hacker News this week that look unrelated and are not. First, an essay called "The death of web development education" made the front page with a hundred-plus comments arguing about whether anyone should still learn HTML and CSS properly. Second, DHH's keynote went around again, where he said 37signals is "done writing code by hand as a normal course of business." One says we cannot teach fast enough, the other says we should stop typing altogether.
I have been on the uncomfortable side of this for a while. My own repos are increasingly written by agents, and last month I caught a subtle bug in an agent-written OAuth check that I would have missed if I had never learned how the code worked. Before picking skills from vibes, I measured something: I went through the last month of commits on my three active projects and split the changed lines into agent-generated (committed from agent sessions) versus hand-written. Here is the actual script I used, in case you want to run it on your own log:
How much of my code do I still write myself?
# Split last month's commits by author field (tformat keeps entries newline-separated)
git log --since="30 days ago" --numstat --pretty=tformat:"%an|%s" > month.txt
# Agent sessions commit as the agent name, I commit as myself
grep -c "^kiell" month.txt || true
awk '/^[0-9]+/ {files++; added+=$1} END {print "files:", files, "added:", added}' month.txt
# Rough ratio: lines touching my commits vs total (numstat-only lines = pure file stats)
awk '/^[0-9]+\t[0-9]+\t/ {total+=$1} END {print "total added lines:", total}' month.txt
The result surprised me: roughly 80% of added lines came from agent sessions. But here is the part that matters. The commits I had to redo, revert, or debug late at night were almost entirely in that 80%. The 20% I wrote myself, mostly interfaces, security checks, and test fixtures, survived review almost untouched. Volume is not the skill. Being able to judge the 80% is.
Let me be honest about the limits here: this is one developer, three repos, one month. It is not a study. But it told me where my learning time should go, and that is what the rest of this list is.
That incident sent me down this question: if typing code is dying as a job, what is still worth learning by hand? Here are the five skills that survived my experiment, and where I think the education debate is wrong.
Is web development education actually dying?
Reading the essay and the comment thread, the honest answer is: the market for "learn to recall syntax" education is shrinking, but the author conflates that with education itself dying. The Boot.dev founder showed up in the comments and said their revenue is actually up this year, mostly because they doubled down on interactive content you cannot get from a chat window. That tracks with what I have felt personally. I learn less from reading generated explanations and more from breaking things and watching what happens.
So no, I do not buy the obituary. What is dying is a specific product: passive course catalogs built on "here is the API, memorize it." That is also, not coincidentally, what agents are best at replacing.
Which 5 skills survived the experiment?
These are the five I still practice deliberately, roughly in order of how often they save me.
1. Reading diffs fast. The new core loop of the job is reviewing code you did not write, at a volume that makes line-by-line reading impossible. Learning to scan a diff for the dangerous patterns, unchecked input, state mutation in unexpected places, missing error paths, is the closest thing to a superpower left. This is exactly how I caught the OAuth issuer bug I wrote about in my audit of the MCP SDK OAuth fix.
2. Decomposing work into small, testable units. Agents are dramatically better on small, well-specified units than on large vague ones. Every hour I spend making a task smaller and more testable multiplies the agent's success rate. This is a design skill, and it is learned by doing architecture by hand, badly, a few times.
Can you learn decomposition without building systems yourself?
I do not think so, and this is where I push back on the "skip the fundamentals" crowd. Agents will happily hand you a 400-line module that works. Deciding that it should have been three modules is a judgment you only get from having built the 400-line version yourself, once, and felt the pain. I learned more about boundaries from one badly structured side project than from any course.
3. Debugging from first principles. When the agent's fix does not work and its next three suggestions also do not work, someone has to read logs, bisect, and form a hypothesis. I practiced this with a read-only MCP bypass last month, described in my Postgres MCP writeup, and the debugging habit was the whole difference between an hour and an afternoon.
Does context management count as a skill?
Yes, and I would fold it into number 3. Knowing what an agent can see, and what it is silently missing, determines whether its output is trustworthy. The 72% context-tax problem I covered in MCP Costs 72% of Your Context is at heart a judgment problem: what does the model not know right now?
4. Security fundamentals. Agents reproduce the vulnerable patterns in their training data, confidently. The recent CVE wave I track weekly, buffer overflows, missing auth checks, path traversals, is exactly what an unreviewed agent commit looks like. You cannot review for security if you have never written an insecure thing yourself and understood why it was insecure.
Is security the skill most likely to save you?
Probably yes, and it is the least discussed. Two NetScaler zero-days were being actively exploited this week, with tens of thousands of exposed instances, and the pattern in every advisory is the same: a missing input check an agent would happily reproduce. The people who catch these in review are the people who have written the vulnerable version themselves at least once. That is my strongest argument for keeping some hand-writing in your practice.
5. Writing precise specs and tests. This is the new syntax. The old skill was remembering the method name; the new skill is writing a specification so unambiguous that an agent cannot satisfy it while doing the wrong thing. Tests are how you make that checkable. I treat my test suite now as the contract the agent must pass, and my fluency in writing tests is directly proportional to agent output quality.
Should juniors still grind syntax, or skip straight to steering?
Here is the debate hook, and where I will probably lose arguments. The education essay's comment section is full of "there is no point learning TypeScript anymore," and DHH's keynote gives that position respectability. I disagree, with a trade-off stated plainly: grinding syntax is no longer the job, but it is still the fastest way I know to build the mental model that numbers 1 through 5 all depend on. I cannot debug what I cannot read, and I cannot read what I never wrote.
The risk I see is a generation that can steer agents brilliantly and cannot tell when the agent is confidently wrong. The anonymous engineer letter circulating this week, describing everyone "pressing enter" for 12 hours a day, is what that failure mode looks like at scale. I do not think that letter is representative data, but I recognize the dynamic.
What will I be tracking for the rest of 2026?
Three things. Whether the "human content" education businesses keep growing, because that is the market voting on this question. Whether companies like 37signals report any change in defect rates now that hand-coding is the exception. And my own ratio from the git-log experiment above, which I plan to rerun monthly. If the agent share of my commits goes up while my rework rate also goes up, the "stop learning by hand" advice will have been wrong, and I will write that up here too.
What is your ratio? And honestly: do you still write code by hand on purpose, or have you stopped?
Further reading from my own tracking: I publish weekly writeups on agent security and developer tooling. The three linked above are good starting points, and the MCP context-tax one has the numbers if you like measuring things.
Top comments (0)