Welcome to Claudeville

For the past couple of weeks, I’ve been reluctantly using Claude Code. This is “reluctant” for a host of reasons I don’t want to get into at the moment, because I don’t want to turn this into a diatribe or rant, or a series of rants (no promises). Instead, I just want to talk about what I’m experiencing.

So first of all, why am I using it? I could say a lot about the genie being out of the bottle, or trying to keep up with the times, or whatever else. But the real truth is that I was deep in the doldrums and I was having a hard time thinking of what would make me feel worse. And I had access to an account, so I thought I might as well try it out.

Now here I am, two weeks later, with my meds adjusted, and I’m still using it. And I’m still reluctant, but less so. However, no small part of that lessened reluctance has made the lateral-at-best move to wariness.

And there’s the vigilance. So much vigilance. I’m doing so much checking and re-checking — verifying the code does what it should, and does what it says. Verifying the tests do what they say, and cover what they should. Verifying all this sticks to the plan.

Yes, the plan. That’s one significant reason I started using this and am continuing. And it’s not “plan mode”, but picking up a workflow I saw that really spoke to me. Let’s call it “ADR-driven development”.

Seeing this pattern really made me think this could actually be a thing. Because I didn’t want to use these tools to do small things. And I didn’t want to use them in fully-autonomous ways. Really, even what I’m doing now feels too much like managing and not enough like building, especially for someone who cares about “the craft” as much as I do. But what else do I care about? I care about ADRs. I care about documentation. And I don’t always have the time and energy to do these things when I also fall into the common trap of “working code is what matters”.

So what’s “ADR-driven development”? It’s just a fancy name for using Claude Code to write up an ADR based on what I want to do. How does that compare to “plan mode”? I’m not 100% sure because I don’t use “plan mode”, but I gather the most-significant difference is that the “plan” lives in the session and is maybe saved in a file that could be who-knows-where, whereas an ADR lives and is tracked in the repo, in a directory of more ADRs that get created over time, so you can see a history of decisions and changes. If you can’t tell, I consider an ADR a useful artifact in and of itself, something worth saving and sharing.

No small chunk of time and effort is spent creating that ADR. There’s the initial creation and reading it over, and then there’s the refinement loop of checking things out, suggesting changes, reading over the changes, checking things out, suggesting changes, &c. Sometimes “suggesting changes” takes the form of asking for clarification or fleshing out some points, and sometimes it takes the form of pointing out something in the ADR is just plain wrong, or there are inconsistencies. Sometimes “checking things out” takes the form of a quick jaunt into a console to see how some code works, and sometimes it takes the form of reading documentation, cross-referencing it with forum or blog posts, and going further than just a quick jaunt for the testing. In one case, where I wanted to consume and process webhooks, these two steps together took the form of giving up on documentation and capturing several real responses to feed into the context. This not only finally got past a cluster of mistakes, but it also meant I had more useful documentation to save and share in the form of those sample webhook responses. And don’t worry — it was all staging / test data.

It’s only when I’m satisfied with the ADR that I allow it to be committed, and then the next step is just to request an implementation of the ADR. But that’s only the single very next step. That has its own check-suggest-read refinement loop, which can involve pointing out inconsistencies between the implementation and the ADR (and deciding which one should change), or finding more wrong things like bad assumptions when integrating with external services, or any of a host of problems from violating style guidelines (either personal or configured in the linter) to large structural issues. And for the most part, I’m checking everything over and reading it all myself, but I’m requesting Claude Code do the changes.

I don’t know where the workflow will end up, but this is what I’ve been doing, progressing from an initial tentative dipping my toe in the water to making basically no edits myself. I’ve been going for an immersive experience, trying to feel out what the tool can do. It’s partly an attempt to adapt, partly an attempt to best use whatever energy I have for work after waking up in the morning and remembering that I live in this world.

But it’s still tiring, and frustrating. And takes so much vigilance. Claude Code provides results that are so much better than any of my previous attempts, which were all painful and maddening: just arguing with a chatbot about the obviously-wrong things it’s doing, and having it go back and forth between previous wrong solutions as I attempt to provide more context. But sometimes better is worse? Those obviously-bad results were so easy to dismiss. The problems and mistakes I’ve been seeing here are smaller, subtler, more insidious. I need to be so careful and review so much.

And what’s most tiring and frustrating is seeing what happens when people don’t do this review, or neglect this vigilance. It’s tiring and frustrating to spend my time and energy being careful with 90-95% of this and get worn-out and sloppy for the last 5-10%, and that’s where I miss a problem. And it’s tiring and frustrating to have to spend my time and energy being careful with code someone else has produced using a tool like this, without checking it over themselves.

And it’s tiring and frustrating to be well aware of the long history of complaints about new technologies, going back to the invention of the written word — famously (and ironically? or fittingly?) immortalized in Plato’s Phaedrus. So I know that I sound (and sometimes even feel) like an old man shaking his fist at the clouds when I complain about this, but I also have some significant concerns. Three main ones, in fact:

1. Not understanding what’s going on with the code you’re producing and should be responsible for. I think it’s great to use higher-level things and appreciate the abstractions — I moved on from C and memory management long ago — but it’s not great if you don’t have an understanding of what’s going on underneath it all, especially when things go wrong or the abstractions start to leak.
2. People disparaging themselves and their own skills, also connected to anthropomorphizing the tools. Some people will have conversations with the tools, reach an understanding, and attribute that understanding to the tool. They’re essentially rubber-ducking, but since it’s happening with something that talks back and affects a personality, they feel like it’s all external and not something they did themselves.
3. Depending on more external tools and services to do the work. No internet: can’t work. Payment stops: can’t work. Tokens ran out: can’t work. And this dependence being not on something that’s a commodity or a public good, but instead belonging to a private company with a vested interest in extracting as much value from you as possible.

I acknowledge that I may be a curmudgeon, and that caring about the craft doesn’t necessarily mean one particular thing. You’re not less of a woodworker if you use power tools or machines instead of hand tools, and you’re not less of a programmer if you use a higher-generation programming language instead of assembly (or binary). But this does feel different to me, and as a difference of kind rather than merely of degree. As I said before, I feel like I’ve been delegating and managing, rather than building. Other people might not feel that way, or they may be fine with it. I’m not a big fan. It does not spark joy.

If you’re looking for a team to help you discover the right thing to build and help you build it, get in touch.