The Machine Didn't Take Your Craft — You Gave It Up

The Essay Everyone Is Sharing — And Why It's Not About You

The argument goes roughly like this: AI coding tools arrived, and experienced developers stopped caring. They stopped reading docs. Stopped thinking carefully about architecture. Stopped caring if the code was good, because the AI would generate more code anyway. The craft of software development — the pride of making something clean and maintainable and right — got quietly left on the table in exchange for shipping fast.

If you've been building software for fifteen years, that argument probably stings because there's truth in it.

But here's the thing: that essay isn't about you.

It's written for people who already had the craft and chose to put it down. People who knew the old way and decided the new way wasn't worth their attention. That's a real and valid critique of a specific group of people making a specific choice.

You're not that person. You came to coding through AI tools. You didn't abandon craft — you never started from the same place. And that means you're working with a completely different question: not "did you give up your craft?" but "what does craft even look like when AI is your primary coding partner?"

The answer is more interesting than the original essay gives credit for.

What Craft Actually Is — And What It Isn't

Before we can argue about whether craft is dead, we need to agree on what it is. Because a lot of the people talking about "developer craft" are using a definition tied to a specific era — one that assumed you wrote every line yourself, in a text editor, from scratch.

That's like saying a carpenter has no craft unless they cut every board by hand with a manual saw. It confuses the tool with the skill.

Here's a better definition: craft is the gap between what you could ship and what you choose to ship.

Think about it in terms of a trade you might know better. Two framers can both use a nail gun. One frames walls that are plumb, level, and square — nails set at the right angle, blocking in the right places. The other frames fast, corners are close enough, and they'll figure out the rest later. Same tool. Different craft.

The difference isn't the nail gun. It's the standard the builder holds themselves to. It's the knowledge to know when something is right versus when it just looks right. It's caring enough to go back and fix the thing that isn't quite square even when no one would notice.

That definition of craft has nothing to do with whether AI wrote your code. It has everything to do with what you do with what the AI gives you.

Craft in Terms You Can Actually Use

For a vibe coder, craft looks like this:

• You read the code your AI generates before you ship it. Not every line, but enough to understand what it's doing. You could explain it to someone else at a high level.
• You test it before it hits real users. You know the difference between "it ran without crashing" and "it works correctly."
• You understand what breaks and why. When something goes wrong, you form a hypothesis before you ask the AI to fix it.
• You make deliberate decisions about quality. You know when "good enough" is actually good enough, and when you're cutting corners you'll regret later.
• You learn from what goes wrong. Each bug you debug teaches you something you carry forward. The knowledge compounds.

None of that requires a CS degree. None of it requires understanding every line of generated code. But all of it requires being present — actively engaged with what you're building, not just hitting send and hoping for the best.

That's the craft available to you right now, regardless of your background. And it's worth protecting.

The Real Danger Isn't AI — It's Shipping Without Understanding

Here's where we need to be honest with each other, because this is the part of the conversation that usually gets avoided.

The original "AI killed craft" essay is wrong about the cause. But it's pointing at a real symptom. There are people building things with AI tools and shipping code they don't understand at all — to real users, with real data, with no idea what happens when it breaks.

That's not a craft problem. That's a safety problem.

Imagine a contractor who builds a deck by copying a design they found online, without checking whether the ledger board attachment will hold the weight, without knowing what kind of wood is structural versus decorative, without understanding the load path. The deck looks fine. Until it doesn't.

Now imagine them scaling that approach to fifty decks before anything goes wrong. That's the scenario we're trying to avoid.

When you ship code without understanding it, a few specific things become dangerous:

You can't fix what you don't understand. When your app breaks at 2am and users are stuck, knowing where to look is half the battle. If you've never read the code, you have no map. You're looking for a leak in a building you've never been inside.

You can't make good decisions about your users' data. If you don't know how your app stores passwords, what happens to form submissions, or how your database is exposed — you can't protect the people trusting you with that information. That's not a small thing. That's a responsibility.

You can't improve what you can't evaluate. If the AI generates something and you ship it without reading it, you have no way of knowing if it was the best solution or a mediocre one. You can't get better at guiding the AI toward quality outputs if you never see the quality of the current ones.

The good news: the fix for all of this isn't a CS degree. It's a habit. The habit of reading before shipping. We'll come back to what that looks like in practice.

What the Old Guard Gets Wrong About Vibe Coders

There's a version of the "craft is dead" argument that slides into something uglier: the idea that people who use AI to build are somehow less than. That they're not real developers. That they're playing pretend.

This is worth addressing directly, because you've probably felt the sting of it — in comment sections, in forum threads, in the way people say "vibe coding" like it's an insult.

Let's look at what vibe coders are actually doing.

Someone leaves a decade on a construction site, learns to read the room, manage a project, keep a job on schedule, and deliver something clients are proud of. They pick up AI coding tools. Within six months they're building web apps that make money. Within a year some of them are running SaaS businesses.

That's not a story about someone cheating. That's a story about transferable skills meeting powerful new tools. The project management instincts, the client communication, the sense of when something is "done right" versus "done fast" — all of that carries over. The only thing that's new is the syntax.

What experienced developers who criticize vibe coders often miss is this: knowing how to code has never been the hard part of building software. The hard part is knowing what to build, who it's for, how to validate the idea, how to keep users happy, how to handle the money, how to prioritize when everything feels urgent. Plenty of people with CS degrees are terrible at all of that. Plenty of people without them are excellent at it.

If you've been in a trade, you know how to get things built. You know that perfect is the enemy of done. You know how to scope a job, manage a timeline, and deliver something that works. Those skills are not less valuable than knowing how a hash table works. They're just different — and they transfer.

That said: the reverse of the snobbery is also a trap. There's a version of vibe coder culture that celebrates shipping fast without ever looking back, where not understanding your code is treated as a feature. That's not craft either. That's recklessness dressed up as confidence.

The answer lives between the extremes. Build fast. But know what you're building.

Craft in Practice: What It Looks Like Day to Day

Enough philosophy. Here's what practicing craft actually looks like when you're building with AI tools — concrete habits you can start today.

Habit 1: The Five-Minute Read

Before you ship any significant chunk of AI-generated code, spend five minutes reading it the way you'd read a contract before signing. You're not looking for every detail. You're looking for:

• What is this doing at a high level?
• Are there any parts I genuinely don't understand at all?
• Does anything look off — something that doesn't match what I asked for?

If you find something you don't understand at all, that's your signal to ask the AI to explain it before you ship it — not after it breaks. "Walk me through this function like I'm someone who doesn't code full-time" is a completely valid prompt. Use it.

The five-minute read is the single highest-leverage habit you can build as a vibe coder. It takes almost no time and it catches a surprising number of issues before they become problems.

Habit 2: Debug Before You Re-Prompt

When something breaks, your instinct is probably to paste the error into the AI and ask it to fix the problem. That works. But every time you do it without trying to understand the error yourself first, you miss a learning opportunity.

Before you re-prompt, spend two minutes with the error message. Ask yourself: what part of the code does this error seem to be coming from? Is this a network error, a logic error, a data format error? Can I guess what the AI was trying to do that didn't work?

You don't need to get it right. You just need to form a hypothesis. Then see if the AI's fix matches your guess. Over time, your guesses get better. That's how you build the mental model. That's what separates someone who uses AI as a tool from someone who depends on it as a crutch.

For more on this habit, we've written a dedicated guide on how to debug AI-generated code — including what to look for in common error types and how to make the AI's explanation actually useful.

Habit 3: Know Your Data Path

You don't need to understand every function in your app. But you should be able to trace the path of your most important data — the thing your app actually does.

If you're building a form that collects emails: where does the email go when someone submits? Does it go to a database? Which one? Who has access to it? Is it going to a third-party service? Which one? What happens if the submission fails — does the user get an error, or does it silently fail?

If you can answer those questions, you have enough understanding to be responsible for what you've built. If you can't, spend thirty minutes with the AI walking you through the data path in plain language. It's one of the best uses of AI in this whole workflow — not generating code, but explaining how the code that already exists actually works.

Habit 4: Hold a Standard

The most important craft habit is the hardest to teach: care about the quality of what you ship. Not obsessively — perfectionism is its own trap — but enough to feel the difference between "this is solid" and "this is held together with tape."

In construction, that instinct comes from experience and from mentors who made you redo things until they were right. In vibe coding, you have to develop it yourself, because there's no one standing over your shoulder checking your work.

One way to build it: before you ship a feature, ask yourself "would I be comfortable if an experienced developer read this code?" Not because you need their approval — but as a forcing function to notice the corners you've been cutting.

If the answer is "no, there are things in here I don't understand and haven't tested," that's your list. Fix it or document it. Don't pretend it isn't there.

The Builders Who Will Last

Look at the people who are actually thriving with AI coding tools right now — not the ones who got a tweet thread out of it, but the ones who are building real products with real users and improving month over month.

They share a common profile. They use AI aggressively to go fast. But they've also built enough understanding of what the AI generates that they can maintain and improve it without starting over. They know what their tools are good at. They know what their tools get wrong. They've debugged enough AI-generated bugs that they've developed intuition for where to look first.

That's not a CS degree. That's experience. And it's available to anyone who builds consistently and pays attention.

The builders who won't last are the ones who treat AI like a magic output machine — prompt in, ship out, never look at the middle. That approach works for a while. Then it doesn't. The debt accumulates. The bugs compound. The feature that seemed simple to add turns into a week of untangling because no one ever understood the code that was already there.

We've talked about this pattern before in the context of what nobody tells you before you start vibe coding — the early wins are real, but the way you build in the first few months sets habits that determine whether you're still building a year later.

The difference between those two profiles isn't talent. It's the craft habits they built early on.

The Data Point That Matters

Here's something worth sitting with: most vibe-coded apps that reach real users — not just demos, but things people actually pay for — are maintained by someone who has read enough of the codebase to find where things are when they break.

That's not an accident. The ones built purely by prompt-and-pray either never ship or die on contact with real users. The ones that survive are the ones where the builder paid attention.

Craft isn't a thing you either have or don't. It's a habit you either build or don't. And the good news is: building with AI tools doesn't prevent you from developing it. If anything, AI gives you faster feedback loops. You can build more things, break more things, and learn from more failures in a year than the generation before you did in five.

That's an advantage if you use it right. It's a liability if you use it to avoid ever engaging with the work.

Redefining Craft for This Era

Let's land this plane with something concrete.

The old definition of developer craft was: you understand every line you write, you know why each architectural decision was made, you maintain clean and well-commented code, you never take shortcuts that create future problems.

That definition was always aspirational — most real-world code doesn't live up to it. But it was the north star.

Here's the updated north star for the AI-enabled builder:

You understand what your product does and why. Not every implementation detail — but the whole shape of it. What it does for users. What it does with their data. What happens when something goes wrong.

You can maintain what you ship. Not just today. In three months, when you've forgotten the details, you can re-orient yourself in the codebase and figure out where the problem is.

You hold a standard for your users. You test things before real people touch them. You treat your users' data with care even when they can't see it. You fix bugs that matter even when shipping new features would be more exciting.

You keep learning from what the AI generates. Every time you read a function and understand it, that's a deposit into your mental model. Over time, that model grows. You get better at prompting, better at debugging, better at recognizing when the AI is giving you something solid versus something that just looks solid.

That's the craft. It's different from what a CS graduate learns in school. It's not lesser. It's adapted to the tools you're actually using, the background you're actually coming from, and the problems you're actually solving.

To go deeper on what this looks like in a real workflow, the AI coding workflow guide covers how to structure your build sessions so you're moving fast without losing track of what you've built. And if you're newer to this world, the complete guide to vibe coding is the foundation — what it actually is, where it works, and how to do it with your eyes open.

What to Do With This

If you've been building with AI tools and you're feeling uncertain about whether you're doing it "right" — take a breath. You're in a transition period where the rules are genuinely being rewritten. Nobody has the complete playbook.

But here are a few things that are clearly true regardless of how the tools evolve:

• Understanding what you ship will always matter. Whatever the AI can generate, you're the one responsible for what it does in the world. Understanding it isn't optional — it's the baseline.
• Debugging skills compound. Every bug you understand — not just fix, but understand — makes you better at all of this. It's slow at first. It accelerates over time.
• Your non-coding background is an asset, not a liability. The judgment about what to build and how to treat the people using it — that comes from experience in the real world. The AI doesn't have it. You do.
• Craft is available to you. You don't have to earn it by suffering through the old way. You can build it right now, in the tools you're already using, by choosing to be present with your work instead of just shipping output.

The machine didn't take your craft. You can't give away something you're still building. The question is just whether you're building it.

Frequently Asked Questions

Related Reading