Three Claude Code sessions are running while I write this. One is developing a module for our internal system. One is building a new open source library. One is processing feedback on a bug report.
I switch between terminals, reading and approving. Sometimes I intervene. Mostly I don't.
A year ago, I would have written all of this myself. Now I describe what I want, review what comes back, and approve or adjust. The code is technically mine. I'm responsible for it. But I didn't type it.
The question that lingers: if I'm not writing code anymore, what am I actually doing?
The identity question
In 2024, GitHub interviewed 22 developers who use AI intensively. One question kept coming up: "If I'm not writing the code, what am I doing?"[1]
For thirty years, "developer" was my identity. Not project manager, not architect, not consultant. Developer. Someone who writes code.
Writing code was a craft. You had to know the syntax. Recognize the patterns. Know when a for-loop is better than a while, when to split a class, when recursion is elegant and when it's unnecessarily complex. That was craftsmanship.
Now I describe what I want to build. Review the generated code. Approve or adjust. The GitHub researchers call it the shift from "code producer" to "creative director of code." It sounds great.
What some miss
Not everyone experiences this shift the same way. Some developers miss the ownership over every line. The pride in an elegant solution that no one else will ever see. The refactor that cut the code in half and made it faster. Your fingerprints in the system.
They miss how it felt to type it yourself, line by line, in a kind of flow.
Others, myself included, were always more results-oriented. It wasn't writing code that gave satisfaction, but what you built with it. For us, AI feels like a liberation. Finally we can focus on the what, without spending too much time on the how.
Opinions on this are divided. And that makes sense. It touches on something fundamental: where do you get your satisfaction from?
The old definition
In 2009, a group of developers published the Manifesto for Software Craftsmanship.[2] It was a reaction to how Agile had devolved in practice into processes and sprints, with too little attention to the code itself. The movement said: making software is a craft. Clean code. Test-driven development. Refactoring as discipline. We're not factory workers. We're craftspeople.
I still believe in that. Clean code, quality, discipline. But the manifesto was based on an assumption that nobody questioned at the time: that craftsmen wrote the code themselves.
What if that's no longer the case?
What are you?
Architects don't lay bricks. Directors don't act in their own films. Conductors don't play instruments. Yet we call them craftspeople. Their craftsmanship lies in the vision they have, and the choices they make. And ultimately the end result.
There's a saying in the industry: "Engineers are not paid to write code. Code is a means to an end." Developers aren't paid to type. They're paid to solve problems. Code is the means, not the goal.
I still solve those problems. Every day. With every review, every approval, every adjustment. The principles remain the same. Only the path has changed.
The flip side
In February 2025, Andrej Karpathy, co-founder of OpenAI, introduced a new term: vibe coding.[3] Writing code by leaving it entirely to AI. No longer reading what gets generated. Clicking "Accept All" without looking at the diff. When an error message appears, copying it to the AI without comment.
Karpathy meant it half-ironically, but the term stuck. And for a hobby project on the weekend, or for experiments, there's nothing wrong with it. But for professional software used in production, it can be dangerous. Technical debt that accumulates until someone has to look at it.
In a world where producing has become easy, the bar for quality should be higher. Not lower.
The new responsibility
The real shift is ownership over code you didn't write yourself.
That's harder than it sounds. It's easy to approve something that works. It's hard to see what could potentially go wrong. To recognize the subtle design flaws. To say no to code that's technically correct but strategically wrong.
Reviews feel different now. More like editing than proofreading. More like directing than checking. I don't read to find typos. I read to understand if this is the right direction.
A tentative answer
Do I still feel like a craftsman?
Yes. I make decisions that matter. I recognize quality and the lack of it. I build things that work, that keep working, and that solve real problems.
Craftsmanship hasn't disappeared. It's now in different things: in the questions you ask, the choices you make, and the quality you demand. The form is different. The essence remains.
Andrej Karpathy on X about vibe coding, February 2025. ↩︎
