Code Is Craft

I've been reading several posts on Dev.to lately that struck a chord with me, confirming that I’m not alone in my perspective. IT professionals have long been viewed as purely rational beings, relying solely on logic and reason as their only tools-and often carrying that same mindset into their daily lives. I would like to challenge this belief, at least from my perspective and for those who share it.

After 40 years in IT, analyzing problems and writing software, I have come to a conclusion that no framework, no language, and no AI has changed: building something that truly works-simple or complex-is not just about technical skill. It is craftsmanship. And craftsmanship is art.

Beyond the Syntax

An artisan and a technician can both build a chair. The technician follows the manual. The artisan understands why each joint is cut at that specific angle, feels when the wood requires a different approach, and leaves a part of themselves in the finished object. Software is no different.

Syntax can be learned in a week. Design patterns can be memorized in a month. But knowing when to break a pattern, why a certain abstraction fits a specific problem, and making a system elegant rather than merely functional-this is the part that isn't taught in a course. This is the touch of the artist and the artisan. I have always believed that the best code reads like well-written prose: clear, intentional, with nothing wasted.

Forty Years of Learning: From Mentors to Machine Intelligence

Tools and technology have changed more radically than the craft itself. When I started in 1985, knowledge came from people-true mentors, colleagues who had already made every mistake worth making. Then came books and manuals, almost exclusively in English, as that was the language of computing. If you couldn't read and understand English, you were lost.

Then came the internet. Google and Stack Overflow became the collective memory of every developer on the planet. Suddenly, the answer to almost any technical question was a search away. Our ability to find answers increased significantly.

Today, we have AI. And with AI came "Vibe Coding"-a phenomenon where the barrier to entry has lowered to the point where almost anyone can generate working code by describing what they want in natural language. Everyone is a developer now. Or so it seems.

The Only Thing AI Cannot Replace

In music, two musicians can play the same score note for note. One executes it. The other interprets it. The difference isn't in the notes-it's in what the performer brings from within. Those who, like me, love the guitar know very well that David Gilmour, Mark Knopfler, John Mayer, and Jimi Hendrix don't just "play"; they express themselves through the instrument.

The same applies to software. Two developers given the same brief will build two completely different systems. One will be technically correct. The other will be elegant, extensible, and a pleasure to maintain ten years later. The difference isn't in the requirements-it's in the mind (the feeling) that shapes the solution.

Creativity cannot be automated. The ability to look at an existing solution and see how it could be improved, to invent a new abstraction that simplifies everything, to know when the right answer is less code rather than more lines-these are human qualities. The "machine" works from what already exists. The human works from what could exist.

Vibe Coding: Everyone is a Developer Now. Or Maybe Not?

I don't dismiss Vibe Coding. It is a genuine evolution, just like Google was. It has broken down a barrier that has always existed in IT: the wall between an idea and a functional solution. Today, you no longer need a specialized intermediary; any person can perform this transformation. This is fantastic for those who don't want to make programming their profession.

To these individuals, I would offer a suggestion, and I invite my colleagues, instructors, and mentors to share this thought if they agree: "Questions are more important than answers." Ask why that code was written in that specific way. You don't need to understand every detail, but you should strive to grasp the big picture.

For those who want to make this a profession, there is a fundamental difference between generating code and understanding it. A generated solution that you cannot read, test, or extend is not a solution-it is a dependency. You haven't built something; you’ve borrowed something that doesn't belong to you.

An artisan using a tool is still an artisan. Someone who uses the tool but doesn't understand the "wood" is not. The instrument doesn't make the artist or the artisan. Knowledge, experience, and judgment do.

The programmer is not disappearing. The role is splitting in two: the AI generates, the human validates and designs. The latter requires a deeper level of understanding.

My Workflow: AI as a Thought Partner

As I have written on my blog in the Code Is Craft series, I use AI in my work every day. But not as a ghostwriter. Not as a code generator from which I blindly copy and paste. I use AI because I want it to think like me. I want it to follow my mental processes in designing a solution, to use my architectural patterns, and to reflect my way of tackling problems.

When I ask it to generate something, I read every line. I challenge every choice. I make it my own before moving forward. If there is a technique or concept I don't yet know, I use AI to understand it-not to bypass the learning process. The goal is always that by the next session, that knowledge belongs to me.

AI has helped me grow; it hasn't helped me avoid growing. That distinction is everything. AI is not here to replace what I don't know. It is here to help me become someone who knows more. This is the only workflow I trust.

If you are interested in how I have lived my work over these many years, visit my website at https://www.nospace.net.

And you, colleagues-both the "old-school" like me and the newcomers-what do you think? Leave a comment below. Critical reflection is what we need most right now.

🇮🇹 Nota di Trasparenza dell'Autore
Ho concepito e scritto l'intero pezzo nella mia lingua madre, l'italiano. Ho utilizzato un LLM esclusivamente come mero strumento di traduzione verso l'inglese, per rendere il contenuto accessibile alla community internazionale.

🇬🇧 Author's Transparency Note
I conceptualized and wrote the entire piece in my native language, Italian. I used an LLM strictly as a translation tool to adapt the content into English, to make it accessible to the global community.