I am a programmer. A coder. A keyboard cowboy. A hacker. My day is spent punching keys; catalyzing code. It’s fun; it’s my identity. The editor, Vim, is my workshop, my sanctum1. Here, I hone my craft, sharpen my tools, expand my capabilities through curiosity, and for a while, escape into a trance-like flow. A full-screen terminal window with nothing between me and thought but INSERT mode. At the altar of Bram2, I spin reality’s yarn out of thin air into bits beaming through silicon. A completely imagined, non-tangible world with IRL ramifications. A place in which I find comfort in craft and creativity. Time disappears into puzzle-solving. Where connecting pieces matters more than completing a picture. Craft springs from fingers to buffer. I program and fade away into flow and composition.
In the late 1950s at MIT, a new and electrifying culture was emerging. Hands-on, experimental, and anti-establishment. I like to imagine myself there, sitting at the slate-blue L-shaped console. Typing away at the Flexowriter3 as it spits out punched paper tape programs to be fed to the nearby wall of metal uprights, tangled wire, and early transistors; the “Tixo”4. Waiting with bated breath, as enthralling beeps emanate from the machinery while it runs the program: will it succeed? I imagine the Hackers—as they came to be known—around me, pointing at code and offering advice on how to achieve “The Right Thing”5: the perfect program, pristine, elegant, and succinct. I can sense the original culture of programming pouring out of them as they passionately embody “The Hacker Ethic” while sharing stubs of their own paper programs to guide me on my quest.
It was there—in the computing crucible of building 26—that the craft of coding was cast. Nearly 70 years ago, members of the Tech Model Railroad Club immersed themselves in the language of machines to pursue a mastery of digital wizardry. The sublime magic of manipulating formal languages to solve increasingly challenging cryptic conundrums and—core to the culture—sharing findings with other students of the dark arts of software sorcery.
The ghosts of ancient Hackers past still roam the machines and—through the culture they established—our minds. Their legacy of the forging of craft lingers. A deep and kinetic craft we’ve extended and built a passionate industry on. We are driven by the same wonder, sense of achievement, and elegance of puzzle-solving as they were. Still driven by “The Right Thing.” These constitutional ideas, the very identity of programmers, are increasingly imperiled. Under threat. The future of programming, once so bright and apparent, is now cloaked in foreboding darkness, grifts, and uncertainty.
In fact, if we are to trust the billion-dollar AI industry, the denizens of Hacker News (and its overlords), and the LinkedIn legions of LLM lunatics, the future of software development has little resemblance to programming. Vibe-coding—what seemed like a meme a year ago—is becoming a mainstay.
Presently (though this changes constantly), the court of vibe fanatics would have us write specifications in Markdown instead of code. Gone is the deep engagement and the depth of craft we are so fluent in: time spent in the corners of codebases, solving puzzles, and uncovering well-kept secrets. Instead, we are to embrace scattered cognition and context switching between a swarm of Agents that are doing our thinking for us. Creative puzzle-solving is left to the machines, and we become mere operators disassociated from our craft.
Some—more than I imagined—seem to welcome this change, this new identity: “Specification Engineering.” Excited to be an operator and cosplaying as Steve Jobs to “Play the Orchestra”. One could only wonder why they became a programmer in the first place, given their seeming disinterest in coding. Did they confuse Woz with Jobs?
I can’t imagine (though perhaps I’m not very imaginative) that Prompt, Context, or Specification “Engineering”6 would lead to a bright and prosperous profession for programmers. It reeks of a devaluation of craft, skill, and labor. A new identity where our unique set of abstract thinking skills isn’t really required; moving us into a realm already occupied by product managers and designers.
Inside companies, power dynamics are shifting as this new identity is pushed. In a mad dash to increase productivity in the wrong place7, developers are forced to use LLMs in increasingly specific ways. Conform or be cast out. Use the products that herald our obsolescence, or resign. Scarcely has management mandated such specifics of our tools before. Tools, like those of a chef or carpenter, that we’ve taken great pride in curating and honing ourselves: careful configuration of our editor, tinkering with dot files, and dev environments. As part of the craft, we’ve been dedicated and devoted to personalizing our toolsets to match our thinking. It feels like a violation to have this be decreed by management, who have little to no connection to the day-to-day, and who should instead be concerned with outcomes, process, and facilitating creativity. For decades, programmers have been pampered within companies. These narratives offer a new way for management to tip the balance back in their favor.
Some—with glee and anticipation—liken LLMs and their impact to the transition from low-level to high-level languages: from Assembly to Fortran. This, I think, is wrong in a couple of ways: firstly, because the leap we made with Fortran was rooted in programming, Fortran didn’t try to eliminate a craft but built on top of it. Fortran didn’t remove the precision and expressibility of programmatic formalisms, but expanded them. Secondly, Fortran was always successful in producing the right outcome given its input. None of these things is true in the world of LLMs. I can practically hear the cultists cry out: “You’re just using it wrong” as they move the goalposts to fit an ever-changing narrative. But we can’t expect AI tools to have the same outcomes as programming languages. They are designed based on a different set of rules and parameters.
... continue reading