Fluency Lives in Your Fingers  🔗 **Source:** [Fluency Lives in Your Fingers](https://www.therepository.email/fluency-lives-in-your-fingers) Hands typing on a keyboard with music sheets and code symbols flowing out. Over the past 50 years, programming required a fluent coordination of the programmer’s hands and mind. Now they’re being separated again. *“All skills, even the more abstract, begin as bodily practices.” — Richard Sennett, The Craftsman* On December 30, 1780, Mozart was in Munich composing *Idomeneo*, the work that would establish his mature operatic voice. Some parts (and people) were challenging for Mozart, and he wrestled with them. By late December, he was racing to commit the music to paper. He dashed off a quick letter to his father and former teacher, noting at the end: > *“Nun muß ich schliessen, den ich muß über hals und kopf schreiben — komponirt ist schon alles — aber geschrieben noch nicht —”* > > *“I must close now, because I’ve got to write this thing at break-neck speed — it’s all composed already — but not yet written down —”* > > (Mozart to Leopold Mozart, Munich, 30 December 1780. BD 573. [Internationale Stiftung Mozarteum, Mozart Letters and Documents – Online Edition](https://dme.mozarteum.at/DME/briefe/letter.php?mid=1139&cat=3).) > > Getting the music out of his head was a bottleneck. It had to travel through his hands onto a keyboard. It had to emerge on paper through a pen and ink for other minds and hands to absorb. This was a necessary part of composing — and of being Mozart. Lately, I’ve noticed many developers confessing on their blogs that they aren’t writing code anymore. Usually, they reflect on their feelings about AI taking over that composition bottleneck. They use words like “manual” or “hand-coding” to describe what they’ve stopped doing. Often, there is a sense of loss, uneasiness, and even guilt beneath a question: *Why am I still here?* [](https://www.therepository.email/linkout/8724)[WP Engine ad.](https://www.therepository.email/linkout/8724) No one loves raw data entry, but that’s a reductive way to describe what a developer’s hands are doing. For a fluent developer, writing code isn’t transcription. It’s the activity of a physical, tactile, hand-brain ensemble. A dynamic environment is that’s what’s in jeopardy and being registered as a physically felt loss today. But what if keeping your hands in some amount of line-by-line code creation remains essential? Many people accept this as a tradeoff: humans will move upward into design, planning, testing, review, and delivery. Employers under cost pressure may be tempted to take that bargain too far. It’s critical to hold onto the visioning, planning, testing, optimizing, and polished delivery of human-crafted work fit for human use. But is this enough? For a long time, the work of “manual coding” in digital computing has lived many layers of abstraction above the earliest machine-input methods that were truly close to the metal: plugboards, switches, paper tape, and punched cards. The teletype keyboard inherited a typewriter design born in the 1870s and eventually standardized by Remington. The familiar QWERTY layout that became programming’s most durable hand-to-machine interface began as something else entirely. An 1867 *Scientific American* article describing an early typewriter prototype called it a “literary piano.” A Wisconsin printer, Christopher Latham Sholes, read that article and built a working version that took the piano concept literally. His first model had a keybed with two rows of ivory and ebony in alphabetical order. Mozart would have recognized this layout that had been stable for nearly two centuries. If you want to imagine truly manual programming, think of the women at Raytheon weaving wire through magnetic cores for the Apollo Guidance Computer’s core memory rope. They implemented the code planned and designed at the MIT Instrumentation Lab (now Draper) by Margaret Hamilton’s team. The weavers were skilled industrial workers following detailed wiring diagrams. They understood what they were doing mechanically, even if they weren’t reading the code as code. Between then and now, the designing minds and weaving hands merged at the keyboard. Now they’re being separated again. What if manual coding is not an acceptable or sustainable loss in every context? What if it eliminates an essential path for students and junior developers? What if it diminishes even the most experienced people? Jason Gorman of Codemanship insists it’s essential to keep coding manually, *without* AI, to avoid losing (or never gaining) fluency: “The effect of AI use on code comprehension is well-documented. The more we use it, the less we understand the code that’s being generated. And not just because we didn’t write it, it transpires – our ability to understand code generally atrophies. Use it or lose it.” [](https://www.therepository.email/linkout/6707)[Patchstack ad](https://www.therepository.email/linkout/6707) Put more cautiously, passive reliance on AI-generated code (or work of any kind) can reduce mastery and create “comprehension debt,” especially when no human effort is made to build a mental model of the generated code. When people become fluent in an interface — which is what all languages are — we think and create through them. The language enters a kind of muscle memory. It feels like part of us, because it is. It can be a spoken or written fluency. It can be both. Specialized additional interfaces with higher levels of abstraction can be added: poetry, philosophy, law, or Python, Haskell, and Lisp. If we’re not speaking or writing our mental vision into existence anymore — if we’re prompting an LLM to take over all the intermediate processes between our minds and the finished product — we will eventually lose the language because we’ve physically removed ourselves from it. Gorman says, “It’s essential, therefore, to keep your hand in. Write code every day. Read, understand, copy (don’t paste) and keep *learning*.” In practice, this means students and junior developers need regular unaided coding, reading, copying, debugging, and refactoring. Senior developers should preserve some line-level work in high-risk systems and architectural seams. Teams using AI should treat generated code as material to be understood, not output to be accepted. Most of all, mix people up. Juniors learn from seniors by watching them work; seniors keep their fluency by teaching it. Reserve key manual work for the most experienced hands, but make it visible as they lead and teach a larger team. In his book, *The Craftsman*, Richard Sennett gives Gorman’s argument a broad and historical frame: even abstract skills begin as bodily practices. Sennett’s own career as a cellist ended with a hand injury — a biographical fact that gives his treatment of craft and the hand a quiet personal stake. He covers Stradivari’s violin workshop and Cellini’s goldsmithing. As an example of what he calls ‘public craft,’ he digs into the Linux community. Across all of them, he finds a principle of tacit knowledge that lives in the hands and reasons to believe “making is thinking.” Sennett argues that Linux developers are not just abstract thinkers but modern artisans who use their hands to engage in a slow, iterative, and communal process of crafting digital tools, embodying the same dedication as traditional physical craftsmen. Other historical examples come to mind that Sennett doesn’t cover. Old Masters like Rembrandt didn’t do all their paintings completely by themselves — they led a team of assistants and apprentices while keeping control of the essential features. Rembrandt’s Amsterdam workshop produced paintings through collaboration, but decades of technical study by the Rembrandt Research Project have shown that the master’s hand can be identified most reliably in faces, in expressive details, and in the thick impasto highlights. His idiosyncratic paint chemistry (recently identified by synchrotron analysis) has become a kind of fingerprint. As a painter, Michelangelo was similar — he didn’t paint the Sistine Ceiling alone. He appears to have kept the most important figures and expressive passages under his own hand, while assistants handled preparation, logistics, and the decorative work, like architecture, ornamental borders, and secondary elements. [](https://www.therepository.email/linkout/7863)[Pressable ad.](https://www.therepository.email/linkout/7863) For sculpture, Michelangelo was unusually hands-on and may have done even the rough-hewing himself in some cases. Unfinished work in the Accademia Gallery in Florence exemplifies his *non-finito* (intentionally unfinished) technique, where the figures of slaves or prisoners appear to be emerging from the stone. They preserve his chisel marks at every stage from rough-out to near-completion within a single piece of stone. Where he did delegate was on the supply side: marble extraction, transport, scaffolding, and studio support. Make no mistake, there have been no solitary geniuses in history: everyone stands on others’ shoulders and benefits from teams and cultures that enable great work. But when you look at the standout greats, you also find they kept a very manual hand in the process. Their signature is how they brought a vision composed in their minds into a public reality with their hands. With or without AI, keeping your hands in your work may remain one of the most important and meaningful parts of it. Employers and educators, take note., Fluency Lives in Your Fingers, therepository.email, 01kqk0cvd9wvkdcmncdxvtnpp9.