Going back to coding by hand is a fix for one person, not for a team

It is, and that is the whole problem with it. A developer on Hacker News abandoned six months of agent-written work on their own app last week and went back to typing. One person can still do that. A team of thirty cannot type its way back to a system it stopped understanding.

Backthread exists for the team version of that problem: agents write the code, and someone still has to hold the reasoning behind each merged change and know which parts of the system anyone actually understands.

The line in the thread that was not about the side project

Most of the post is personal. A solo maintainer with a successful app decides they would rather own the thing than ship it faster, abandons the branch, and spends a satisfying night renaming variables by hand. The comments are warm about it. But the sentence worth stopping on is the one about the day job, stated flatly and then dropped:

In work we use LLMs exclusively. Nobody writes code anymore. It's all hands off and we have a high level understanding of how things work but no more than that.

That is trencedamp, writing on Hacker News on 9 September 2026. The thread ran past fifty comments and nobody argued with that sentence. They argued about the remedy.

Why the remedy does not travel

The author's fix works, and it works for reasons that are specific to one person holding one codebase.

  • It restores a model that one head can contain. Chasing a rename through every call site rebuilds a map of the code as a side effect. That is real learning, and it is bounded by how fast a person reads.
  • It pays for that with the speed the agents were there for. A maintainer of a side project can make that trade on a Tuesday evening. A team with a roadmap will not make it, and the people asking them to would not accept the result.
  • It leaves everyone else exactly where they were. Understanding recovered by hand lives in the hands it was recovered by. The colleague who reviews that area next week gets none of it.

At team scale the third point is the fatal one. Even if a thirty-person team did slow down to hand-write everything, you would have thirty private models of the parts each person typed and no shared model of the system. That is roughly the state the quote describes, arrived at by a more expensive route.

What the team version has to solve instead

"A high level understanding of how things work but no more than that" is not a personal failing. It is what happens when the code arrives faster than anyone reads it and the only record of a change is the diff. A merged pull request used to carry a floor of comprehension in whoever wrote it. It does not any more, which is the argument in why a merge is not evidence that anyone understood it.

Three things work at team scale, and none of them is a retreat from agents.

  1. Capture the reasoning while the session is still open. The alternative that was weighed and the trade-off that was accepted exist for about as long as the session does. Written down at the moment of the change, they survive the squash merge. Reconstructed a month later, they are a guess with good grammar.
  2. Measure understanding by area, not by person. The useful question is not who is productive but which parts of the system have nobody holding them. Those are different lists, and only the second one predicts the next bad week.
  3. Spend the hand-coding instinct where it pays. The instinct behind the thread is right, it is just aimed at the whole codebase. Aim it at the two or three areas where the record shows everything was merged and nothing was read, and route a person through them deliberately.

The honest version of our own position: a tool can keep the record and show the gaps, and Backthread's map of who understands what is our attempt at it, but nothing removes the need for a person to sit with an area until they hold it. What changes is that you get to choose which areas, on evidence, instead of finding out during an incident.

Connect one repo and the first per-area picture of where the reasoning was captured and where it is blank is there the same day; the trial runs fourteen days.

In short

One developer's return to hand-coding is a real fix at one-person scale
Typing the code rebuilds the author's model of it. That works because a solo maintainer can hold one codebase and can afford to trade speed for ownership. Both conditions fail on a team with a roadmap.
Understanding recovered by hand does not reach anyone else
A model rebuilt by chasing renames lives in the person who chased them. Thirty engineers hand-writing their own areas produces thirty private models and no shared one.
The team problem is the record, not the typing
When the only artefact of a change is the diff, "a high level understanding of how things work" is the ceiling. Capturing the alternative and the trade-off while the session is open is what raises it.

Sources

  1. I'm going back to coding by hand — trencedamp, Hacker News, 9 September 2026
  2. The Substrate Collapse: AI Code Generation Invalidates Authorship-Based Knowledge Metrics — Brett Wheeler, arXiv, June 2026
  3. Comprehension Debt: The Hidden Cost of AI-Generated Code — Addy Osmani, O'Reilly Radar, April 2026

Backthread shows how much of what your agents built your team really understands. See how it works