Two disciplines of code, and why AI splits them

Yesterday I owned up to letting this blog go quiet, and I mentioned that some of my posts drew fire for reading AI-written. I use artificial intelligence (AI) tools. I wrote about how I use Claude Code back in the spring. I'm not going to apologise for that part. What I want to do is explain why the argument over AI gets so heated, because I don't think the two sides are arguing about the same thing.

There are two kinds of programmer

I've come to think there are two disciplines hiding under the one word "programming."

The first is building. For people in this camp the code is a means to an end. The goal is the application: the thing that solves a problem, ships, and gets used. Language features are tools, and the best tool is the one that gets a working, maintainable product out the door.

The second is the craft of the language itself. For people in this camp the code is the point. Knowing the language deeply, writing it well by hand, understanding why an idiom exists and when to break it - that's the work and the reward. These are the people who write the deep-dive posts on span semantics and argue about allocation in hot paths, and the ecosystem is better because they exist.

Neither discipline is the "real" one, and I don't sit cleanly in either. I've spent over thirty years building line-of-business systems, and I still believe the point of programming is to build things that solve problems. But you can't use a language every day for that long without getting pulled into the details. I've lost whole evenings to how an application should be structured, and more than a few to why a language does something the way it does. The building is the goal. The minutiae are how I got good enough at the building.

Most of us drift between the two over a career, or live with a foot in each like I do. But the two disciplines want different things from their tools.

Why AI lands so differently

To a builder, an AI assistant is a throughput multiplier. It writes the boilerplate I've written a thousand times, it drafts the test scaffolding, and it lets one developer finish a project that would otherwise have needed three. Thermalith and the upcoming Converge exist partly because of that.

To someone in the craft camp, the same assistant looks like it's skipping the part that matters. If the value of programming is in learning and applying the language yourself, a tool that does the applying for you isn't a shortcut, it's a replacement for the thing you came for. From that side of the fence, AI-assisted work can feel like somebody bragging about a marathon time they set on a bicycle.

Both reactions are reasonable. The builder isn't lazy and the craftsperson isn't a Luddite. They're measuring different things.

What I'd ask, from both sides, is that we make room for each other. A community that tells builders they're frauds for using AI, or tells craftspeople they're dinosaurs for not using it, is a community that's going to lose good people either way.

The script kiddies

Making room for each other has a limit, though, and there's a third group I have no patience for.

These are the people who have swung all the way over. They don't understand software and don't think they need to. They prompt an app into existence, ship it, and then wonder why it leaks user data, stores passwords in plain text, or falls apart the first time two people use it at once. No source control worth the name, no tests, no code review, secrets pasted straight into the repo. None of the standard process our industry learned the hard way over decades.

That isn't the building discipline. A builder cares whether the thing works, and working includes being secure and maintainable. What these folks are doing is skipping both disciplines at once: they never learned the language and they never learned how applications are built. The AI filled in the code and nobody filled in the judgement.

The same crowd has a debugging habit I can't stand. They point an AI at the code, it flags a bug, and they have it write a fix, all without ever finding out why the app does what it does or how it got into that state in the first place. The bug gets patched and the cause stays exactly where it was. A bug is the app telling you that your picture of it is wrong somewhere. Tracing it back is how you fix that picture, and it's how you find the three other bugs hiding behind it. Skip that step and you've fixed a symptom and learned nothing. That's not efficiency. It's lazy.

They're the old script kiddies with a better tool. They're also a big part of why "AI-assisted" has become an insult, and every developer using these tools responsibly pays for their mess.

AI isn't going anywhere, and neither are good developers

A lot of the heat underneath this is fear, and that fear is legitimate. People are worried their jobs and careers are about to disappear.

I don't believe that's true for developers who understand how applications work. AI lowers the bar for producing code. It does not lower the bar for knowing what to build, how the pieces should fit together, where the data should flow, or which decisions you'll be stuck with for the life of the codebase. I made the same argument in Good developers learn to program. Most courses teach a language. and I think AI makes it more true, not less.

An AI tool will cheerfully generate a login form with a Structured Query Language (SQL) injection hole in it. It'll produce an architecture that works fine for the demo and falls over at the first real load. It won't tell you the requirement you were given is wrong. Catching those things takes someone who knows program flow, application design, the pitfalls of building real software, and how application security fails in practice. That person, using AI to apply what they know faster, is worth more than they were before.

And there's one thing AI doesn't do at all: come up with the app. Every tool I've built started with me being annoyed at something and deciding to fix it. No model handed me that itch. The creative spark that says "this should exist" still comes from a person.

AI is a good tool and it's here to stay. It lowers the bar to entry, which will flood the field with code of every quality. Somebody has to be able to tell the good from the bad.

If you're in the craft camp and you never touch these tools, that's a legitimate choice and I respect it. If you're building, use them, and keep sharpening the judgement that makes them worth using. If you're somewhere in the middle like me, you already know the craft is where that judgement comes from.

Keep learning

If you're just starting out and AI has become your go-to, don't despair. Everyone starts somewhere, and plenty of us started by copying code out of magazines and books without understanding a line of it. A generation later it was code by Stack Overflow: find an answer with enough upvotes, paste it in, and move on. AI is just the latest version of the same shortcut. The difference is what you do next. Read the code the tool gives you. Ask why it works. Break it on purpose and see what happens. Learn the language underneath it and learn how applications are put together. Leaning on the tool like a crutch is fine for a while, as long as you're working on the leg.

If you're a pro using AI to go faster, don't get complacent. Check the work. Run the app and use it the way a real user would, then try to break it the way a hostile one would. Look for the things an AI won't do unless you tell it to: validating input, checking that the user is allowed to do what they're asking, handling the error instead of swallowing it, dealing with two requests landing at the same moment. Speed only counts if what you shipped holds up.

The same goes for the standard features every real application needs and nobody thinks to ask for. An AI builds the feature you described. It doesn't add structured logging you can search when something goes wrong at 2 a.m., an audit trail of who changed what, proper authentication and role checks, secrets kept out of the source code, or a way to tell the app is healthy without signing in to the server. Those systems are the difference between a demo and something you can run in production, and they only show up when someone who knows they're needed puts them there.

AI is going to keep getting better. The need for good developers who understand how applications work isn't going to shrink because of it. If anything it grows, because someone has to know whether all that code is any good.