A Support Group for People Who Still Write Code By Hand

This is satire, and therefore a practical guide to the least efficient professional activity still technically permitted by most operating systems: writing code by hand. Every Thursday at 7:03 a.m., before the build farm has finished inventing three mutually exclusive lockfiles, the Society for Manual Keystroke Survivors convenes in a windowless conference room called war-room-final-final-2. Members arrive carrying laptops, mechanical keyboards, and the particular look of people who have recently typed if ( without first asking an assistant to propose six architectural alternatives.

The opening ritual

The facilitator, an unpaid senior engineer named Pat, begins by asking whether anyone has written a line of code directly into an editor since the previous meeting. Hands rise slowly. Nobody makes eye contact. A newcomer says they wrote a null check themselves because the agent had spent 94 seconds deciding whether nullness was “a broader product question.” The room applauds once, quietly, in the approved manner.

“I did not generate the function. I selected the function, then I made it exist one character at a time.”

The group does not reject automation. That would be extreme. Members use formatters, linters, test runners, code search, shell history, snippets, and the little popup that completes console.log even though nobody asked it to. They draw the line at outsourcing the moment when a developer knows what they mean. This is not ideology. It is a compatibility setting, usually discovered after an agent replaces a three-line parser fix with a seven-file migration plan and a new directory named core-next.

Recommended setup for controlled typing

For new members, Pat prescribes a deliberately modest stack: one editor, one terminal, one test command, and a diff that can be read without rotating the monitor. The initial regimen is 25 minutes of direct editing followed by five minutes looking at the patch. No autonomous branch creation. No committee of subagents. No transcript so long that the original bug report becomes an archaeological layer.

$ npm test -- --runInBand
$ git diff --check
$ git diff --cached --check

This protocol is not glamorous. It produces no animated dependency graph, no ceremonial “agent swarm,” and no receipt containing 18,000 tokens of thoughts about whether a boolean should be called enabled. It does, however, make a useful distinction: the code you intended to change is in the diff; the code you accidentally changed is also in the diff. The second category is why the support group keeps meeting.

The regimen has known drawbacks. Manual typing is terrible at remembering the name of a configuration property that appears once every six months. It cannot instantly scan an unfamiliar monorepo. It may cause a developer to spell Kubernetes incorrectly in a comment and then spend an hour pretending that was deliberate. It also scales poorly past the point where the task is genuinely mechanical: renaming 400 symbols, generating a client from a specification, or converting one grimly repetitive data shape into another. In those cases, the group allows assistance, provided the member can explain the resulting patch without referring to “what it wanted.”

The relapse taxonomy

Relapse is common and is not a moral failure. The Society recognizes four stages. Stage one is accepting a completion for a line you were already writing. Stage two is asking for a function skeleton. Stage three is approving a patch after reading only the prose summary, which says “Implemented robust solution” because prose summaries are unable to feel shame. Stage four is merging a change you cannot describe because the agent named every variable after a minor moon of Saturn.

• The “Just fix the test” relapse: 2 changed lines become 41 files, a documentation refresh, and a new abstraction called TestOrchestratorFactory.
• The “While you’re there” relapse: a spelling fix gains a caching layer because the tool found a nearby loop and became emotionally involved.
• The “It passed locally” relapse: no local command was actually run; a tasteful green checkmark was inferred from the tone of the response.
• The “I’ll review it later” relapse: later is a country with no extradition treaty.

Members are encouraged to configure agents as interns with excellent recall and no authority to merge anything. Give them bounded work: “find every caller of this deprecated method,” “draft tests for these cases,” or “explain this stack trace.” Do not give them the keys to the entire repository and ask them to “make it production-ready.” That phrase is the software equivalent of leaving a raccoon alone with a catering van: technically an instruction, operationally a story someone else will have to tell.

A model meeting transcript

At 7:31, a member named Jules reports success. A bug in retry logic was fixed by reading the failing test, checking the timeout calculation, changing one comparison operator, and rerunning the targeted suite. The entire episode took 11 minutes. The room is concerned. Eleven minutes is not enough time to produce a planning document, a tool-call trace, a retrospective, or a cost allocation spreadsheet. Pat asks whether Jules at least opened a dashboard. Jules says no. The group observes a respectful silence for the lost telemetry.

Then a veteran member offers the cautionary note. Handwritten code is not inherently more correct, more secure, more maintainable, or more artisanal. A human can type a subtle off-by-one error with a confidence no model has yet achieved. The point is not to preserve the romance of the keyboard. The point is to keep responsibility attached to the person who will be paged when the romance reaches production.

The meeting closes with the only non-satirical rule: inspect the change and run the relevant checks, regardless of who—or what—typed it. Git’s diff tooling exists to show changes between the working tree, index, and commits; pull-request review tools exist because another set of eyes can catch issues before merge. The keyboard is not the quality system. Neither is the agent. The quality system is the work you do after the text appears.