AI coding without the vibes

We spend a lot of effort these days trying to figure out how to stop students cheating with AI. It’s necessary, but it’s not the most satisfying part of the job. Students that want shortcuts around learning are going to find them anyway. A more worthwhile and interesting question to spend our energy on is what to tell those students (including PhD students) who aren’t looking for shortcuts. The ones that genuinely want to learn and are happy to devote hours each day to developing themselves. The ones who want to be here. This question—what we should tell students to do with AI—is a good trigger to think about what we ourselves should be doing (which is what this essay is really about). Your initial instinct may be to tell students to pretend AI doesn’t exist. Learn everything the old-fashioned way. Never did me any harm and so on. But that would be like telling a student in the 70s to pretend that calculators or computers don’t exist. Students today need to prepare themselves for a world in which AI is going to be a major presence. They need to have the skills to navigate that world, whatever it will look like. Alternatively, you may think that we should tell them to embrace AI fully. Sign up to the highest tier of Claude and burn tokens like there’s no tomorrow. Defer absolutely everything to the machine. This is also bad advice. It’s a surefire way to learn absolutely nothing at all. Not only that, it’s the perfect way to make sure that you’ll never learn what it feels like to learn something. This is something that is not made explicit often enough: one of the most important things you learn in university is to gauge whether you really understand an idea. You will find yourself in situations where you could have sworn you really understood something, and then you get just the right question, and you have no idea how to answer it. Eventually, you learn to ask yourself these questions. And then, slowly, you’ll develop an accurate sense of whether you have really reached a state of understanding. Deferring everything to AI means that that machinery never develops. You will not just be knowingly taking shortcuts, you will be deceiving yourself into thinking that you’ve mastered something. When the bill comes due, and you suddenly realize that you don’t have any worthwhile skills at all, it may be too late to fix the problem. And, again, this applies to ourselves as well, even if we were lucky enough to get to develop this machinery before AI came along. Cognitive skills are like muscles: hard to gain, easy to lose. So what is the answer then? My best advice so far is that most things you do consist of two stages: doing and checking. You write some code, and you check it for bugs. You write some text and you fact-check it and proofread it. Current AI is not good enough to do both. It will work for a while, but eventually, there’s a real chance it goes off the rails. Sometimes in a big way, like deleting your database, but more often in more subtle ways, shifting the codebase slowly into an unmaintainable mess. More importantly, even if it does both flawlessly, can you really hand it in as “your work”? You have to ask what you are contributing. And, whether you’re a student or not, what you are learning. So, if you decide to use AI in some part of your project: let it do the thing while you check its work, or you do the thing, and it checks your work. When you put the options like this, it’s really no choice at all. Having the AI write the code is what most people do. It’s what we call “vibe-coding”. If you hold to the above rule, you can only do this if you check everything the AI writes and does. It’s clear this is a fiction. The human brain was not made for this. Even if you resolve to really check, deeply, every line of code produced by the bot, your attention would wander in under an hour. The failure cases are rare enough that you can’t help but start to trust the machine. More importantly, it wouldn’t be fun. Checking other people’s code is a grind. Writing your own is fun. So let’s do it the other way around. You code and you have the AI check your work. Treat it like a reviewer. That’s my advice in a sentence. It can still save you time, it will catch bugs that would have taken weeks to figure out the old-fashioned way. It will tell you about tricks you missed and technology that you were unaware of. But, a lot of the incentives that point the wrong way in vibe-coding are turned around if you do it this way. In the rest of this essay, we’ll dig into the details. How do you do this in practice? What does it buy you, what doesn’t it buy you? How long will this remain a feasible approach? But first, let’s see if we can come up with a catchy name. Craft coding Imagine three bakers. Hanna, Vivian and Cara. Hanna is a home baker. She’s fanatical: she goes to great lengths to let her sourdough starter mature, checking the temperature obsessively. She follows complicated rising processes: turning, retarding and shaping the dough very precisely. This leads to great bread, and she has more skill than many professional bakers. However, because she does everything by hand, including kneading the dough, it will never scale. She knows this, and she’s happy to create a few loaves of perfect bread in her own unique way. Vivian is a commercial baker. Her bakery creates vast amounts of bread to fill the supermarket shelves. She defers most decisions about the baking process to food scientists she’s hired. She monitors aggregate statistics. Chief among them, how well the bread sells and how much it costs to make. She doesn’t care about the quality of the bread. Or rather, she cares about the quality to the extent that her customers care, but no more. She will happily use cheap flour to cut costs and reduce rising times to make production more robust. The main thing she’s worried about is getting undercut by another baker who figures out how to make bread that sells just as well, but a little bit cheaper. She’s not a bad person, she just cares about other things than Hanna, and if she didn’t, she wouldn’t last long in her job. In between these two extremes, we find Cara. Cara runs a commercial operation. She knows that she can’t bake bread the way Hanna does. No commercial bakery kneads dough by hand: it’s hugely inefficient and quite unhygienic. However, Cara is not like Vivian either. She cares about the way the bread gets made. Good bread has intrinsic value to her. Even if her customers didn’t care, she still would. She’s on top of every part of the process, and this is what gives her satisfaction in her work. This maps onto modern coding practices as follows. Hanna is a hand-coder. She abhors AI and is happy to be the one to keep an ancient craft alive, whether it’s commercially viable or not. Even if AI code is better in some ways, she’s happy to keep doing it by hand. Vivian is a vibe-coder. This is a little counter-intuitive, because “vibe-coding” suggests a kind of laissez-faire attitude where you don’t really care about the outcome and you’re just having fun. That’s what the phrase meant when it was coined, but the world has moved on. In many companies professional programmers are using AI in such a way that it’s impossible to imagine that they are also reading the resulting code in detail. This is what modern vibe-coding is. Deferring to the AI, not worrying about the individual lines of code, and keeping an eye on whether the code passes its tests and throws up any problems in production. Cara is what we would call a craft baker, so the equivalent coding style could be called craft coding: a coding style that revolves around the inherent quality of the product, down to the details. One where the programmer commits to understanding, in detail, every aspect of the code base. Tools like AI are allowed, but only when they benefit that ideal, and only in a way that benefits that ideal. Like craft baking, craft coding may not hold up under all the stresses of a modern multinational corporation, but there are niches for it. Where craft matters One such niche, I believe, is scientific code. In science, the code is not normally the product. The thing we produce is an idea, captured in a paper. The code implements that idea, to prove it right. This means that scientific code has slightly different rules than production code. It doesn’t need to be robust to many different use-cases. It really only needs to run the experiments in the paper. That means that you can usually make it a lot simpler than production code. What’s more important than in production code, however, is that it’s correct. It absolutely needs to do exactly what the paper says it does. If your production code doesn’t quite do what you thought it did, but the customers don’t notice, it may not really matter. It’s not great, and you want your code to be correct, but if the incorrectness is harmless, you may get away with it. If it happens in science, it invalidates the paper. I could write a whole essay about how this affects coding styles in science, but we’ll save that for another time. For now, it means that science is one strong niche for craft coding. As the author of a paper, you are vouching that the code exactly implements the ideas of the paper. You can only do that if you know the code intimately, line by line. Vibe-coding won’t get you there. Until recently, my conclusion was that therefore, scientists should be hand-coders. Then, I started taking my own code and asking Claude whether it could spot any problems. So far, I have never shown it a snippet of code that it couldn’t spot a serious issue withg. The code usually runs, and I can’t see anything wrong with it. But the problems are there. When I was a PhD student I wrote code by hand and I would eventually, in the course of my experiments, come across these bugs. I would get frustrated and spend weeks writing test suites to get rid of them. It took me years to develop that kind of