Summary
From the article:
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.
[...]
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.
[...]
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.
[...]
The simple advice for now, given the state of current models, is not to let AI do anything. You only let it critique what you’ve done, and you implement its suggestions if you agree. The best metaphor, again, is that of a code review by a senior programmer.
[...]
This means that in the age of AI, hand-written code is simply not safe. It will contain problems that we will never spot and that an AI-powered attacker can exploit effortlessly. Programmers need to loop AI in somewhere, somehow, or the game becomes laughably asymmetric.
[...]
Development speeds up. Again, compared to vibe-coding, craft-coding is still very slow. Compared to hand-coding, however, what you lose are those bugs that stop development in its tracks for weeks. The bugs that require whole new scripts and scaffolding to track down. For me, that’s still a meaningful saving. It means that with a few afternoons blocked per week I can still do meaningful work.
[...]
It stops you from self-delusions about being able to out-think the AI. It keeps you aligned with frontier AI abilities. Most of the people I interact with on social media are AI critics. On balance, I find them a healthier, more agreeable crowd than the Kool-Aid gang on Twitter. Still, being an AI researcher on Mastodon or Bluesky is not without frustrations. Not to put too fine a point on it, but most AI critics seem under-informed about how AI really works, and what frontier models can really do. Most criticism of the actual abilities is based on silly examples like the AI summaries above Google searches or the free version of ChatGPT from three years ago.
[...]
In this sense, craft coding keeps you honest. You still write your own code, one character at a time. It is still entirely yours, and you still understand every detail. But there is always that step of copy-pasting it into the Claude chat window and asking it if it can spot any problems.
Ask yourself—if it really is just a parlor trick—why you don’t want to do that, at least every now and then?