Two weeks ago I proudly wrote about 880 commits in twelve days. Then I read a post about developers who stop thinking, and recognised myself in it a little too well. So not less AI, but rethinking where I let it do the thinking.
In Het bleef niet saai (Dutch, “It didn’t stay boring”) I wrote about twelve days in which my homelab and a handful of apps got turned upside down. 880 commits, my own issue board, a finances app, my own webmail. I typed very little of it myself, and I ended with “More automation is more better, right?”. That was half a joke. By now I find it a little less funny.
Bobs and Johns
Freek van der Herten shared a link on Twitter to a post by Nick Bevers: Developers are getting rAIded. It stuck. He splits developers who work with AI into two kinds. The Bobs, after Bob the Builder, love building and are happy when it works and looks right. The Johns, after John Watson, use AI as an assistant: they think for themselves, know how their code works and keep the overview.
What stayed with me most was his picture of developers who spend the whole day pressing arrow keys and enter. The AI asks a question, offers option A, B or C, and you pick one. Typing “other” yourself takes effort, so you do it less and less.
I’d like to say I’m a John.
I was Bob
Looking back honestly at those twelve days, I was mostly Bob. I got used to how easy and simple AI makes things very quickly, and to be honest I also abused it. Shipping and building fast, without really thinking about architecture after the initial brainstorm. Especially not when I let agents run through the night and merged ten pull requests in the morning.
I went back through my own Claude Code history to check. Since mid-October I sent 385 messages, and 59 of them were one to three words long. The most common one: “ja doe maar”, Dutch for “yeah, go ahead”. When Claude gave me a multiple-choice question, I mostly just picked the option marked “(Recommended)”. Including the one about which IMAP library my webmail is built on. Nick’s arrow keys and enter, but with numbers. All of that kept Claude busy for 11.2 billion tokens since 12 October, 1.16 billion of them on the day of the night agent.
The most honest test I could think of: can I debug it myself? For the board, the finances app and the webmail, the answer is no. I could build them myself, but in the codebases as they stand now, I don’t know where everything is. The webmail has around 2,700 tests, and I couldn’t tell you how the sync works.
I really noticed it when the finances app went down. A migration assigned every existing user to the owner “rick”, while the second account already existed. A unique index failed and the app was down for about forty minutes. I ended up fixing it by hand in SQL, and that one command cost me a lot of work, because I first had to explore the whole codebase on the fly. I knew SQL. I didn’t know my own app.
There were worse ones. The board trusted a header that let you, in principle, decide which domain the links in the app pointed to. And while setting up monitoring, the list of everything I monitor was public for a few minutes. Both were working code, and I didn’t catch either of them. I was full Bob at that point: ship, ship, ship! For a homelab project the damage is limited. But imagine this had been an enterprise client, with sensitive data out in the open. In the worst case, that’s a trip to the Dutch Data Protection Authority.
In that earlier post I wrote that my work was “mostly in the brief, the mockups and saying no”. That’s true, but saying no to something you don’t understand is just pressing enter too.
Easier to do more, harder to stop
Around the same time I came across a piece in Forbes about AI burnout. It covers research by Aruna Ranganathan and Xingqi Maggie Ye in Harvard Business Review, with a conclusion I can’t get out of my head: AI makes it easier to do more, but harder to stop.
According to that research, the people who embrace AI most eagerly don’t end up with less work, but with more. Things that used to feel too technical are suddenly things you can do yourself. Projects are easy to start and hard to finish, because they grow as soon as you see what else is possible. And there’s the “one more prompt” reflex, which lets a session quietly run into your lunch break or your evening.
That read like a summary of my October. On the 21st, just after eleven at night, I gave Claude this:
At 7:47 the next morning I wrote “push and PR the night features”, with ten features listed in the right merge order. I didn’t ask what any of them did. A few days later: “merge & deploy the whole lot (no need to wait for CI every time, it only costs a lot of time)”.
And it didn’t stop after those twelve days. The two busiest days after that were 3 and 4 November: workdays, on which I spent my evenings experimenting with Revideo.
Single sign-on sits in the backlog as twelve issues, my family is still on Nextcloud because the webmail isn’t ready for them, and there are still no backups running. All fun projects, all half done.
When Bob, when John?
I don’t think being Bob is always wrong. There’s room for it in experimenting, prototypes and fun projects at home. A script you run once doesn’t need to be known inside and out. But where the line is, I find one of the hardest trade-offs in working with AI.
For me the line is other people depending on it. Software that people have to work with every day, whether that’s a client or my mum reading her email. If they paid a lot for it, that only makes it heavier. If you give or sell someone software, they can reasonably expect it to work. Bugs are fine, every piece of software has them. But if you don’t even know or understand the architecture yourself, where does it end? You can’t keep burning millions of tokens on sticking plasters onto a mediocre application that you barely put any thought into.
So maybe Nick’s names fit even better than he intended. The AI is the builder. John is the architect. He comes up with the architecture and the structure and chews on them until they’re right, and the AI does the actual typing. And John checks what comes back, through pull requests or something like it. However good the builder is, someone who understands the drawings still has to look at the work.
Which means my webmail crossed that line long ago. The prototype was basically done after the first hundred commits, and my family was always going to use it. That was the moment to step in and get more hands-on myself. Instead I let it keep going until the codebase got out of hand.
What I changed
I work with Claude Code, which reads an instruction file at the start of every session describing how I want it to work. That file already said a lot about working carefully: find the cause first, never claim something works without checking, don’t make things up. But all of that was about how Claude works, not about how I stay involved. Part of it was even built around me walking away while the work carried on.
It now has a section called “Rick stays the John” (translated, mine is in Dutch):
The goal is that Rick keeps a mental model of his own code and keeps thinking
for himself. Speed does not come at the cost of understanding.
The yardstick is Rick himself: bachelor's in ICT, medior developer, ~7 years of
experience. What someone at that level understands without thinking, just do.
Anything above that, discuss.Below it are a few rules. After a non-trivial change, Claude explains how it works and which two or three places in the code I should read myself. For design decisions I no longer get an A/B/C menu, but a trade-off in plain text that I respond to in my own words. With a tricky bug, Claude first asks what I think. And if my approach is weaker, or I seem to accept something without reading it, Claude has to say so.
Homelab work and one-off scripts are exempt. There I’m allowed to be Bob, except for the apps other people use, like the webmail, the finances app and the board.
I’ll let it run like this for a while and adjust where needed. Whether it works, I’ll only know when I find the next bug in the webmail myself.
This post is the first result, by the way. I asked Claude to write it, and was first told that a post about “don’t let AI think for you” written by AI kind of undermines itself. Then I got questions instead of text. In the end we wrote it together, one section at a time. The thoughts, the examples and the opinions are mine, and Claude asked the follow-up questions and turned my Dutch half-sentences into English. Which, now that I think of it, is exactly the architect and the builder.
Not less AI
Less AI is too simple an answer. Let’s be honest: how boring is churning out code? Boilerplate, migrations, a test for every edge case, the same form validation for the hundredth time. AI is incredibly useful for that, and I don’t want to give it up.
I also think I’m faster with AI, and in the short term I probably am. You can get something off the ground ridiculously fast. But the research makes me less sure about the rest. In a study by METR, experienced open-source developers working on large, mature codebases took 19% longer with AI tools, while afterwards they believed they’d been about 20% faster. That was with early-2025 tools, and METR now thinks later tools probably do speed developers up. But the gap between feeling and measuring is what stuck with me. And a study by Anthropic itself found that developers who learned a new library with AI scored clearly lower on a comprehension test afterwards, with the biggest gap on debugging. Which is exactly where I got stuck. The ones who used AI to ask conceptual questions did much better than the ones who let it write the code.
So where will I run into the bill? Next week? Next month? Next year? With a data leak? Who knows.
I already notice it when there’s an outage. When Claude is down, my productivity drops drastically. Is that terrible? Not necessarily. But not knowing where to start because your AI best friend isn’t working, or has become far too expensive, doesn’t seem healthy or sustainable to me.
But shipping faster and just going for it isn’t always the answer. The HBR research recommends an “AI practice”: deliberate agreements about when you use AI and when you stop. That’s really what the new section is trying to be.
Bob or John?
And yet. At 23:49 that same night, one minute before “okay, now I’m really going to sleep”, I found a security issue myself: the app let anyone add any address on the domain as a sender, including another family member’s login. Claude had built it, and I caught it. So I was Bob and John in the same night. Maybe that’s the point: it’s not who you are, it’s which one you choose to be at a given moment.
I don’t think there’s a right or wrong way to use AI. Are you a John, or do you want to be one? Great. Would you rather be a Bob? Also fine. Who am I to stop you? There’s something to be said for both, and software development is going through such a huge shift in what’s possible right now. Sky’s the limit, as we love to say. I’m not here to play police officer and point out what you’re doing “wrong”.
Just keep in mind who’s depending on what you build. As long as that’s only you, be as much of a Bob as you like. As soon as it’s someone else, it’s not only your choice anymore.