The craftsmen are losing their magic, and the amateurs are finally building. Nobody asked for this, but here we are — and it looks like there’s no going back.
~
Manuel, a software developer from Spain, described his relationship with programming the way some might describe a long relationship. Not the honeymoon phase (that was long over) but the mature kind, the one where you’ve built a life together. “I am mortgaged to software engineering,” he told me, laughing. To Manuel, this job was binding, a commitment, and something more than just a paycheck.
Then came the AI tools. And now?
“Relief,” he said, when I asked how he’d feel if they disappeared tomorrow. Here was a man who had spent his whole career in code, who had found meaning in building software, now admitting that the tools promising to make his life easier had instead drained something essential from it.
“The joy has gone completely,” Manuel said. “I see myself like I’m in a factory production line now, checking next, next, next, next. I am now that guy when I used to be another.”
Over the past several weeks, I’ve spoken with software engineers across industries, timezones, and experience levels about what AI coding tools have done to their profession. What I heard wasn’t a straightforward story about jobs disappearing or people adapting to change. It was messier than that: a crisis of personal and professional meaning, happening in real time, where the same technology that’s gutting some’s sense of purpose is handing it to others on a silver platter.
And the question at the center of it all:
Is software engineering still a craft?
The craft argument has deep roots in the software world. In 2008, a movement called ″Software Craftsmanship″ emerged as a response to what its adherents saw as the industrialization of programming. They drew explicit parallels to medieval guilds, spoke of apprenticeships and mastery, and signed a manifesto pledging allegiance to “well-crafted software” over “merely working software.”
The movement was always somewhat aspirational, a pushback against the pressure to ship fast and fix later. But it gave language to something many programmers felt: that writing good code, beautiful code, was more than a technical exercise. It was a form of creative expression, a way of thinking made tangible. Not everyone bought in — critics called the movement elitist, disconnected from the messy realities of commercial software development. But the feeling it captured was real, and widespread.
I spoke with Matheus Lima, an engineering manager who writes about AI and software development at terriblesoftware.org, who offered a more pragmatic take.
“I’ve definitely seen the argument that programming is a craft or an art form,” he told me. “And I get it. But here’s the thing: someone is paying you to ship value to users as fast as possible.”
His opinion was pretty straightforward: “If you think coding is art, by all means, create art. But probably as a hobby, outside of working hours?”
But that’s exactly what programmers have been doing. For decades, engineers have built side projects on weekends, stayed up all night coding, contributed to open source for free, and learned new languages just because they were curious. How many other professions inspire that kind of after-hours devotion? You don’t often see accountants doing spreadsheets for fun. Project managers aren’t running volunteer Gantt charts.
The list of jobs people do for work and for pleasure is pretty short: painters, musicians, writers, woodworkers, chefs. Crafters.
Julius, a software engineer here at Swarmia, put it in terms of magic. “There’s this quote by Arthur C. Clarke that any sufficiently advanced technology is indistinguishable from magic,” he told me. For years, programmers felt they possessed something rare — a skill that gave them superpowers. “Not a lot of people could do what we do,” he said. “But anybody with an LLM can get there now. The magic is fading away very quickly.”
Maybe the question isn’t whether software engineering is still a craft. Maybe it’s whether it even matters anymore.
Lada Kesseler, a technical coach and lead software developer, thinks it does. On a recent episode of Engineering Unblocked, she described herself, without hesitation, as “a crafter”: someone trying to build systems that work well, solve the right problem, and delight users. Her roots are in what she calls “deep agile” (test-driven development, refactoring, domain-driven design).
When AI coding tools arrived, she asked herself a hard question. “Does software craftsmanship even matter if we just generate all the code?”
Her answer: “A resolute yes. Because those agents — what I see them doing is they basically code themselves into a wall at super speeds.” And teams that don’t understand proper system design, she explained, “will code themselves into a hole faster” with AI. The tools don’t eliminate the need for craft, and they sure do punish its absence.
“When you put AI on a good codebase, it actually replicates good practices,” Lada said. “It will still degrade, but if you start from good, it’s more likely to not make messes. You need to learn good engineering practices if you want to write software, because the rules didn’t change. It’s still software.”
For Lada, the old binary — you either write code by hand or you don’t — has been replaced by a spectrum. “The manual work where you know every line of code is a dimension now,” she said. “Previously, that was the only way to do things. Now there’s a range, and vibe coding is at the other edge of that dimension.”
Vibe coding has its place, she argued. Personal tools, quick prototypes, experiments. “I see people not vibe coding sometimes where they should be,” she said. “They should be coding little tools, custom things that give them answers about the problem space. You can empower yourself like crazy.”
But production systems are different.
“Please don’t do this,” she said about vibe-coding production systems. “You’re going to shoot yourself in the leg. You’re going to lose the trust of people. You’re going to code yourself into a situation where you can’t code yourself out, because you need engineering skills. At some point, the complexity is such that you just can’t get away with vibe coding.”
Julius has a theory about why this feels different. “I was spoiled,” he said, reflecting on when he started his career. “I started my career already working with high abstraction level programming languages. It was still easy compared to how it was for the programmers before me.”
There was a generation before him who knew how to write machine code, who understood what was happening under the hood. They probably watched with relief and loss as higher-level languages abstracted away that complexity. “So it’s just a case of technology going forward,” he said.
But the previous abstractions (from machine code to assembly to C to Python) still required programmers to think like programmers. They were tools that amplified human thinking, not replaced it.
At least, that’s how it feels from the inside. It’s worth noting that every generation of programmers has said something similar about the one that followed. Assembly programmers mourned the loss of hardware-level control when C arrived. C programmers questioned whether the Python generation really understood what their code was doing. The ″this time is different″ argument has a long history of being wrong.
And yet — what’s happening now feels less like another rung on the ladder of abstraction and more like the ladder being kicked away entirely, leaving programmers hanging on to the gutters.
“I think it’s funny that we as software engineers decided the first career we are going to ruin is our own,” Julius said. “Because the writers and the painters and the artists of this world are always going to survive. But a lot of us engineers may not have such a certain future because nobody else loved code. Nobody outside of the software field has a favorite programmer.”
″Software is a safe place where you can fail repeatedly,″ he explained. “If we compare it to woodworking, there’s some similarity, but if I buy expensive wood and use it for my first hobby project, I’d be pretty upset when I break things. With software, you can always just go back a couple of commits and you get to the reward pretty quickly.”
But something has changed in what brings him satisfaction. I asked where he gets the dopamine hit now, the feeling of pride in his work.
Before, he could lean back after writing a particularly elegant module and bask in what he’d created. Now, he has to wait longer for that rewarding moment. The satisfaction comes from the feature working well, from the user experience, from seeing the whole product come together. “It pushes you towards a more product-minded approach,” he said.
It’s a form of adaptation, but it requires waiting longer for reward and finding meaning in different places. Whether that’s sustainable — whether engineers can maintain their passion when the craft itself has been abstracted away — remains an open question. ″I think its one of those things where we won’t know for a while,″ Julius admitted.
There’s a more optimistic reading of Julius’ shift, though: if the real skill was always the thinking — the architecture, the trade-offs, the understanding of what to build and why — then AI hasn’t taken the craft away. It’s stripped out the incidental work and left the essential work. The question is whether engineers can find the same satisfaction in the essential work when the incidental work was what felt most tangible.
When you write code, you’re encoding your own thinking, right there in print, for others to scrutinize when code review time rolls around. Every variable name, every architectural decision, every elegant solution (and every ugly hack) carries the fingerprint of the person who wrote it.
“When you read a colleague’s code, you’re engaging with a person,” one person commented in a discussion I noticed on LinkedIn. “Their thinking, their choices. When you approve it, you’re saying ‘I trust you’ as much as ‘I trust this code.’”
So what happens when the code stops carrying that fingerprint?
Julius has noticed this most acutely in code reviews too. Before AI, reviewing a colleague’s code meant engaging with their thinking, their choices, their growth as an engineer. It was a delicate dance of giving feedback skillfully, considering whether criticism would help, thinking about how to phrase suggestions.
“When you do that with AI-generated code,” he said, “I think I’m more harsh to the AI because there’s not a lot of humanity in it. It’s a dumb robot that didn’t fulfill its purpose, and it’s frustrating.”
The learning opportunity (both in receiving feedback on your own code and developing the skill to give it well) risks being replaced by a quality control checkpoint for machine output.
When I asked Manuel how AI had changed his workflow, he was candid about the bargain he’d struck.
“Now the AI creates the first 90% almost instantly. And then you have the last 10%, and that part still takes 90% of the time.”
There’s a common saying in programming that captures this: the first 90% of the project takes 90% of the time, and the last 10% takes the other 90%. AI, it seems, has only intensified this phenomenon.
“That fine-tuning, that’s the part you are getting paid for now,” Manuel said. “Before you would get paid for everything, for the whole thing. Now I’m getting paid for that last 10%.”
He came up with a historical analogy to make sense of the change. “Imagine a cleric in the 14th century,” he said, “spending his entire life copying a single book by hand. Each page was a piece of jewelry, with hand-drawn illustrations in the margins. And today we have books, mass-produced, at scale. They’re different. They’re not as precious.”
He paused. “I think it’s the same with software now. We used to create everything manually. Now we have the option to create at scale. And I am frightened. Not of losing my job; I know I’ll have work for a long time to come. But for software as a whole, I don’t think it’s going to make it better overall.”
Lassi, an engineer at Databricks, explained it to me in terms of incentives: “There seems to be a lot of bias to lower the standards,” he said. “Because if you don’t lower the standards, then you don’t gain the performance boost from AI.” He’s not the only one who sees it this way either — others have called AI ″a revolution in accepting lower standards″.
To make AI-assisted development ″work,″ something has to give — often the attention to detail that once distinguished excellent code from merely functional code.
Manuel identified one area where he thinks handcrafted code still makes sense: testing. “The tests are code in charge of checking that everything is fine,” he explained. “If everything else has been AI-generated, this might be the last bastion of handcrafted code.”
But there’s something else in that last 10%: a rewiring of how the work feels.
Dylan Martin, an engineer at PostHog, described it aptly in his recent article, Spinning the Wheel: “There’s a moment after you send a prompt where you’re just… waiting. The agent is running. You can see it thinking, reading files, making decisions. And there’s this little hit of anticipation: what’s it going to do? It’s the same dopamine loop as pulling a slot machine lever.”
The satisfaction used to come from solving the problem. Now it comes from watching the machine solve it. And the unsettling question Dylan poses: “What if I’m slowly trading away the thing that made me good at this — the deep, hard-won understanding — for speed and fun? What if the speed is the bribe?”
And yet, for a growing population of people who never considered themselves programmers, this isn’t a loss at all. In fact, they’re feeling the dopamine hit of building something from nothing for the first time.
This is the strange inversion at the heart of the AI coding moment: the same tools that are draining joy from the craftsmen are creating it for people who never had access to the craft in the first place.
The experienced developer who spent years mastering syntax and patterns watches that knowledge become less valuable by the month. But the designer, the product manager, the marketer with an idea — people like me — are building things we never could have before, and feeling the same rush that drew so many engineers to coding in the first place.
Whether what we’re building is good, whether it lasts, whether it’s ″real″ software... that's still open for discussion.
For engineers who have lost the joy, Julius offered this: “We probably all need to review our reward mechanisms. Consider taking some time to write code the old way. I do what I call luomukoodi” (organic code, in Finnish) “and unplug myself from the crazy pace of the AI world. I think it can be therapeutic sometimes to just sit down and do it the old-fashioned way.”
It’s not a solution exactly, but it’s a path. A way to remember why you started doing this in the first place, before the magic became mechanized.
Matheus eventually found his way back to enjoying the work, but only after finding a setup that fit his style. “I’m a Neovim guy, I’m a terminal guy,” he told me. “Being able to use Claude Code made me come back to my natural habitat, inside the terminal.” Instead of rejecting the tools, he found a way to use them that still felt like home.
Kesseler, despite her concerns, remains optimistic. “I still love my work,” she said. She doesn’t write code manually anymore, but she insists the craft remains. It’s just expressed differently: in the architecture, in the taste, in knowing when to go deep and when to let the machine handle it.
Manuel, near the end of our conversation, offered a kind of resignation. “You used to have an incredibly well-paid job that you loved,” he said. “Now you have a well-paid job that you don’t love. This is your nine-to-five.”
He paused, then added: ″I haven’t found a replacement for the joy. Not yet.″
That ″not yet″ is doing a lot of work. It’s the difference between a eulogy and a story that’s still being written.
Software engineering is a craft — I’m still sure about that. But the version of it that Manuel fell in love with, the one that Julius felt like magic, may not be the version that survives. Something else is taking its place, and whether it’s better or worse probably depends on who you ask.
Subscribe to our newsletter
Get the latest product updates and #goodreads delivered to your inbox once a month.
