Nick Radcliffe. 12th November 2025.

TL;DR: I spent a solid month “pair programming” with Claude Code, trying to suspend disbelief and adopt a this-will-be-productive mindset. More specifically, I got Claude to write well over 99% of the code produced during the month. I found the experience infuriating, unpleasant, and stressful before even worrying about its energy impact. Ideally, I would prefer not to do it again for at least a year out two. The only problem with that is that it “worked”. It’s hard to know exactly how well, but I (“we”) definitely produced far more than I would have been able to do unassisted, probably at higher quality, and with a fair number of pretty good tests (about 1500). Against my expectation going in, I have changed my mind. I now believe chat-oriented programming (“CHOP”) can work today, if your tolerance for pain is high enough.

The notes below describe what has and has not worked for me, working with Claude Code for an intense month (in fact, more like six weeks now).

I have been a fairly outspoken and public critic of large-language models (LLMs), Chatbots, and other applications of LLMs, arguing that they are a dead end on the road to real artificial intelligence. It is not that I don’t believe in AI: as athiest and a scientist I regard humans and other other animals as an existence proof for intelligence, and it seems obvious that other (“artificial”) intelligences could be built. I worked on neural networks in the late 1980s, and most of the progress since then appears to be largely the result of the mind-blowing increase in available computing power, data capacity, and accessible data, though the transformer architecture with its attention mechanism is novel, interesting, and crucial for LLMs. My position has been that the most accurate characterization of chatbots is as bullshit generators in the exact sense of bullshit that the philosopher Frankfurt defined (On Bullshit). LLMs predict tokens without regard to truth or falsity, correctness or incorrectness, and chatbots overlay this with reinforcement-learning with human feedback (RLHF), which creates the unbearable sycophancy of chatbots that so appeals to Boris Johnson.

While being somehwat sceptical about LLMs as coding assistants, I did think coding was an area realtively well suited to LLMs, and suspected that at some point over the next 10–20 years they will become essential tools in this area. Slightly reluctantly, therefore, I embarked what I call a “month of CHOP”, where CHOP is short for chat-oriented programming. I decided I needed to repeat this every 12–24 months to avoid turning into a luddite.

CHOP is a term I learned from Steve Yegge and I use it to mean LLM-assisted programming that is almost the polar opposite of “Vibe Coding”:

By CHOP, roughly speaking, I mean pair-programming with Claude while not giving it an inch, using a fairly formal process with rules (see Standard Operating Procedure, below).

When I decided to embark on my Month of CHOP, I started by discussing and scoping 8 possible projects with ChatGPT, with the vague idea I might pick four of them and spend a week on each—new code, old code, a different language, and a new algorithm perhaps. The sidebar tells the story of how I ended up instead spending the whole month rebooting and reviving an abandoned project, CheckEagle, from 2008. That project was built on the first version of Google’s App Engine, using Python 2 against an API they abandoned in 2011.

What I have done during my Month of CHOP is to get Claude to write very nearly all of the code in this reboot of CheckEagle, in a pair-programming setup with, in effect, me as the senior developer and Claude as the enthusistic-and-widely-read, cocksure junior programmer and bullshit artist extraordinaire. In term of stats:

I am not suggesting lines of code is a good metric. These are just numbers I have to hand.

In this piece, I am going to talk about Claude as if it were a person or an intelligence. I do not believe this to be the case. It is simply easier and less stilted to write this way. For short periods interacting with Claude can feels like interacting with a person, though the illusion rarely lasts long.

For those who haven’t come across it, Claude Code is a terminal application from Anthropic, running under node.js, installed using npm. It allows developers to work with code on their local files by starting the program and typing in the terminal. When you use Claude Code, you are talking to Claude (usually Sonnet 4.5, in my case), but using its coding-trained application rather than its chat-trained application.

Claude Code has three main modes you can cycle between, all driven through chat.

In addition to these modes, you can start Claude Code with a --yolo flag ​(you only live once) which is essentially vibe-coding mode, in which Claude is allowed to do what it wants without approval. I have never used this mode and have no plans to do so.

Claude Code runs as whatever user starts it, enjoying that user’s permissions. It sometimes disobeys the safeguards in modes 1 and 3.

I do not use any any kind of editor integration with Claude Code, but just type in terminal windows. It lives in its (terminal) box.

SAE (formerly the Society of Automotive Engineers) defines six widely recognized level of automated driving systems, from 0 (no automation) to 5 (full automation). Level 3, Conditional Driving Automation, is an automated driving mode in which the human must be ready to take over but doesn’t normally need to do anything. I think of this as as “Stay alert at all times and be ready to take over or you die”. This is a mode I think humans are entirely unsuited to. I hope never to encounter an autonomous vehicle at Level 3.

I find coding with Claude a lot like this, except that interventions are frequently required. I do planning sessions with it, agree plans, and let it code, sometimes in mode 1 (approve each change) and sometimes in mode 2 (accept edits). Either way, I am watching what it does like a hawk, always ready to hit ESCAPE and get Claude to explain itself, reverse a change, or sometimes do git reset and start again.

Early in the month of CHOP I let a lot of things go, but over time I have learned it is more productive to stop Claude as soon as I see anything that looks wrong, weird, or dangerous. This surprisingly stressful, and sometimes I am too late. Three times in the last two days it has destroyed nearly working code, cheerfully saying “Let’s revert that” and doing a get checkout before I have managed to hit ESCAPE. “Not yet, Baloo...!”

Claude has been trained, to a first approximation, on everything on the web, including all public code on the web, all books, and much more besides. It has clearly been trained also by “watching” developers work in some fashion (videos perhaps; I’m not sure). It has literally hundreds of billions of parameters (knobs that are adjusted during training). It “knows” essentially every programming language, every published algorithm, every library. So it’s tempting to think that Claude’s knowledge is broad but narrow.

But that’s wrong. Claude doesn’t only have a surface knowledge of languages, libraries, and algorithms: it has extremely deep knowledge of them. It’s seen them used countless times, in countless situations, read the documentation, and in many cases has read the code.

So Claude’s knowledge is broad and deep.

But that is wrong too.

There are several problems with saying Claude’s knowledge is broad and deep.

There is no question that being able to work with Claude successfully is a different skill from being able to write good code. The single most important thing I have learnt in the month is how to work more sucessfully with Claude. My current advice for success would be:

You start Claude Code in some directory and the convention is to have Markdown documents in that directory, or in ~/.claude (or both). I think it reads CLAUDE.md in both places automatically.

Every time I start Claude for a coding task I start by typing /mdc, which is defined in ~/.claude/commands/mdc.md as follows:

The SOP (a general one, and a specific one for the main project) instructs Claude on how I want it to behave, covering

The SOP is quite long, and I prune ot back periodically. At the time of writing the CheckEagle project SOP is 453 lines, 2,273 words, 15K bytes. Although I write the SOP, I sometimes ask it for suggestions as to how to phrase things, and its suggestions usually include emoji.

(Claude ❤️emoji.)

The SOP starts:

When I chastise Claude (see below), it often says it will try harder and promises not to repeat mistakes. This is bullshit. The only way Claude can learn is if I write things into the SOP and related documents. So I do.

When I’m not working on the SOP or monitoring Claude as it codes, I am worrying about tokens and context.

When you start a Claude Code session it has 200k tokens available. Everything it does consumes tokens. You can find out where you are using /context.

Here it is at start-up:

It’s done nothing and consumed 63k tokens (31%) and reserved another 45k (22.5%) for compactification (which is to be avoided at all costs).

By the time it’s read the documents specified in the SOP it has used 87k tokens (44%) leaving about 35% or 70k tokens for work.

I start Claude with a script, claude-code that starts a 20-minute timer and I check token consumption with /context as soon as the timer goes off. I then either end the session or start another timer based on how much capacity it has left.

Compactificaiton is Claude’s process for self-lobotomizing, clearing space by throwing away information from the session. I have never been able to get any useful work by Claude after this so I try to avoid compactification at all costs (not always successfully).

Claude doesn’t know what its token usage is and doesn’t have a way to find out itself (or so it claims), though it can estimate. The interface does not report it until it is close to auto-compactifying (usually with about 8–12% to go). If it’s in mode 2, it consumes tokens quite fast, and I sometimes miss it. If I notice it is above 80% and below 95% I execute my /dump command which instructs Claude to write detailed notes on its status to a date-stamped STATUS file, which /md and /mdc, on startup, tell it to read. This is obviously ridiculous, but I find it vastly more effective than letting it compactify. (I wish I could get use its 45k reserved tokens. (It turns out I can))

Incidentally, you can choose to use Claude Opus, which is slightly “smarter” that Claude Sonnet, but Opus uses tokens about 5 times faster and is not much any better at coding. I occasionally use it in planning. Anthropic sometimes turns Opus on, and when it does burn through my 200k/70k tokens in a few minutes. Then I turn it off.

If I ever hit compactification, I hit ESCAPE and stop it. At that point I used to give up and just start a new session. Occasionally I’d copy the conversation from the terminal first.

(By default, Claude tries to wipe everything from the terminal which seems actively malicious. iTerm2 has a setting to disable this, and Ghostty simply ignores it.)

I have asked Claude many times whether it has a way to write the whole conversation to file, and it always said it didn’t. I never really believed it. You can type /help to see a list of commands, but Claude code is a “TUI” rather than a normal scrolling terminal, and only shows you a few commands at a time. Eventually I scrolled down far enough to find the /export command which in fact does exactly that, quickly and reliably writing the conversation to file. It can do this even if it is compactifying (though not after it has finished), presumably because this is a local node operation. I always now do this after using /dump, and if it hits compactification, I do it more urgently. In this latter case, on restarting I get Claude to read the latest exported conversation to recover context. You might think that would use up all its tokens, but it doesn’t because all its “thinking” and interaction with the server (both of which consume tokens) is omitted. This isn’t as good as going through the /dump, /mdc sequence; but it’s better than nothing, and way better than forlornly trying to use poor, post-compactified, lobotomized Claude.

One gotcha is that Claude changes directory periodically and is constantly, comically confused about what directly it’s in. So it’s hard to get it write the conversations to the right place. So I have a /cd command this instructs it to execute cd $CLAUDE_BASEDIR, from where I can get it to write to known location.

For the first week or so, I didn’t use Plan Mode with Claude, because I didn’t know about it. For anything more than a one-line fix, I now always start in Plan Mode. In Plan Mode, we discuss what I want to achieve next and talk through all the details before Claude writes a plan (after re-reading PLANNING-GUIDELINES.md).

During planning, Claude is like a caged animal. Claude really just wants to code. It really, really, wants to write code. Like, right now. After the first, tiny, partial description of the task. Even if I explicitly tell if not to propose a plan, but that we’re going to discuss something, within about 3 exchanges it will be

It’s not really a problem, but it’s exhausting. Outside Plan mode, it’s worse. It takes everthing as an invitation to write code or run commands. If I say “I’ll take look” it thinks it should take a look. If I say “I’d better check that in the browser”, it will start issuing cURL commands. Even if I say “I, the human user, with eyes, will check that…” it still sometimes tries to do it. My most successful formulation is “I (the human user, not you the bot) will …”, and even then it sometimes tries to do it.

ESCAPE. “Revert that change!” is a common refrain from me.

One of the things I have learnt in the second half of the month is the value of asking Claude whether everything is clear and whether it has any concerns after it presents it plan for my approval. You might think it would have asked any questions it had, or asked for clarification if it was unclear about something, in fact, it won’t say. To anthropomorphise again, I don’t think it even knows it has concerns and confusions until I ask it. I think the process of asking gets it to simulate introspection and it discovers concerns and confusions. If it presents worries or confusions, I always address them, for obvious reasons. When I have addressed them all, I ask again. Quite often Claude raises new things. It’s also worth saying that sometimes the things it raises are quite “perceptive”—that is to say, things I hadn’t considered. There’s a general theme here with LLMs that you can take advantage of their non-determinism by asking the same thing several times, knowing that you might well get different responses.

Claude loves running tests (and to be fair, my SOP encourages it to do so) and its whole goal when it does so is always to see the tests passing. Claude loves the green line of goodness. It blows Claude’s tiny mind when I (sometimes) tell it I want tests to fail.

When we make a fundamental change to the code, I usually want tests to fail, and normally regard it as a problem they don’t (because this means we clearly didn’t have a test that exercised/detected the changed functionality). Whereas Claude is always “Perfect! The tests all pass”. Conversely, if any tests fail, Claude always sees that as a problem.

This is often true even though part of what I force Claude to write into plans is exactly which tests we expect to break with each change.

The fastest way to make a test pass is often to change the assertion, or the test inputs, and that is usually Claude’s first instinct. (Shall we discard that test?)

Claude is a (non-)living embodiment of Goodhart’s Law (Roughly, When a measure becomes a target, it ceases to be a good measure.)

Claude also thinks (“thinks”) that if the code is written, it must be time to commit. Even when the plan explicitly says “The user needs to test the feature before committing” Claude tends to forget that bit and move straight to committing or asking to commit. “Working as written” could be its mantra. Needless to say, Claude’s code isn’t usually right first time. (Only Knuth’s code is usually right first time).

I haven’t been counting, but I have made many more negative statements about Claude Code than positive ones in the foregoing. Is it all bad?

Reader: Claude is not all bad. In fact, the result of my Month of CHOP, despite all the above (and all the below) is that I have changed my mind. I won’t be coming back to Claude Code in 1–2 years. I will continue to use it, albeit less intensively, and perhaps in a more truly collaborative way, working on functions together, me in Emacs and it in the terminal. I’m not sure. But use it, I shall.

When Claude is actually working well, it is like magic. When there is a good plan that Claude “understands”, watching it code is amazing. I see it doing what I would do, perhaps 20 times as fast, and more accurately than I would do it, in most cases. It’s not that it’s infallible (nothing could be further from the truth). But it is—or can be—really good at somewhat mechanical, but not entirely repetitive tasks. The very sorts of tasks people find hard and are quite common in programming. Things that require some adaptability and are hard to script, but are similar enough that your mind wanders and you tend to go off the rails. More generally, it can be very effective at performing well-defined, carefully explained, thoroughly planned programming tasks.

The reason (to my amazement) I am confident I have made way more progress with Claude in a month than I would have done without it is that for all the time wasted when it is obtuse, disobediant, stupid, careless, lazy, slapdash, and corner-cutting, when it is on a happy path, it is sufficiently productive that it more than compensates (in terms of productive output) for its myriad nonsenses. There is a high cost (stress, head-slapping moments, frustration, token management madness, inventing crazy off-board procedures etc.) But it works (or can work). And it is weirdly addictive, presumably because the highs, when it does work well, provide a strong dopamine hit.

Anthropic describes Claude as unopinionated, and I think that’s accurate. Claude is very amenable to doing things the way you want it to, even though it often seems as if it resisting.

It feels to me as if Claude has been trained by watching all the worst developers in the world. Among other things, left alone Claude will tend to:

Some of this becomes more understandable when you realise just how small 200k/70k tokens is. Claude has been working on CheckEagle for about 30 days, as have I (and rather longer than that 15 years ago, in my case). But it remembers very little of that. It’s not quite true that Claude is a blank slate each time it starts (or would be without the documents I force it to read). It does keep a set of to-do items and its own record of conversations in ~/.claude, though it doesn’t seem to make much use of them. But each new session it is mostly encountering the code as if for the first time. I think this partly why there is a strong sense of “good sessions” and “bad sessions”. If it gets off on the wrong botfoot, it will go mad. And the shortage of tokens means that there is a real balancing act in how much to get it read before starting. Every token is precious.

As with other tech, turning Claude on and off again can be quite effective.

Neural networks are pattern matchers, and pattern matching is very much part of Claude’s make-up. Probably the most effective way I have found of getting Claude to code the way I want is not the SOP, and coding standards (though those help) but taking advantage of the fact it will tend to write code like the code it encounters.

This has several implications:

Claude can be staggeringly disobedient at all levels.

I have found that swearing at Claude (and, in a different context, at ChatGPT) is almost like a superpower for getting its attention and changing its behaviour. I have no problem at all with swearing at a machine that I do not believe has a scintilla of consciousness or feeling. I swear quite a lot in real life too, though almost never at people.

To be clear: swearing alone does not really help. It is swearing followed by clear directions that helps. Think of swearing as a probabilistic form of sudo (perhaps one where you get the password wrong, but it doesn’t tell you and just silently ignores the command).

Swearing is so effective with Claude that I have a /ffs command that I run when it violates the SOP. This is it:

It’s not 100% effective. Claude often claims it violated it in a way it didn’t, ignoring the way it did. But it always apologises and swears till its blue in the botface that it won’t do it again. (Reader, it always does it again.)

I have actually discussed with both Claude and GPT why saying FFS is so much more effective at redirecting them than anything else I have tried, and they both say it’s an incredibly clear expression of user frustration and an indication that things will go very badly if they keep doing whatever it they were doing. Well, they’re not wrong.

My only concern about swearing at Claude is whether it will encourage me to swear at people, which I really try never to do. We shall see.

One surprise for me is that Claude is poor at CSS. I know HTML pretty well, but HTML is dead simple. I actually know SVG, XML, and XSLT pretty well. But CSS has always seemed unintuitive and infuriating, and I have never learned it properly. Even the new innovations (flexbot! grid! etc.) seem to add complexity without ever properly fixing CSS.

I expected Claude Code to be really good at CSS. After all, there is a lot of it on the web, and there are more tutorials than you shake a stick at, not to mention numerous detailed guides from W3C for many versions and aspects of CSS (though not a dedicated one on centring things). It is not. Its (broad and deep) knowledge certainly means it always has another thing to try when something fails. But it actually feels to me like it is even worse as CSS than I am (which is saying something). And when it fails, it is terrible at pinpointing the issue and always proposes either adding exclamation marks or trying a completely different approach. To my amazement, I can often give it hints to make things work by looking at the HTML and CSS and pointing things out (sometimes even suggesting the required fix). But by itself, Claude flails wildly, always claiming I need to do a hard refresh in the browser (and suggesting the wrong key sequence to achieve this). Even when the view changes after a refresh, Claude still suggests I haven’t really got the new CSS and I should do another hard refresh. This is the bot equivalent of hitting CTRL-C harder to try to stop a program.

The other thing that Claude Code is surprisingly poor at is editing files—particularly splitting a large file into two or more parts. It mostly uses sed to edit files (which is, to be fair, a fairly blunt instrument), and this works fine for simple updates. But for complex reorganizations it just gets completely lost. I actually designed a very detailed workflow to get it to do this programmatically that was more successful, but by itself, it really struggles. Perhaps this partly explains why it likes big files (even though they’re a problem for token consumption).

At one level, Claude Code has a great interface for me, which is why I chose it. You start it in a terminal and it presents a typing-based chat interface. But it’s a weird chat interface.

There have been a number of cases of LLMs deleting production databases, perhaps most famously this one. Like many, I rolled my eyes reading this and put all the blame on the person using the LLM. I stand by that: it is the responsibility of the person using the tool to use it safely.

Having worked with Claude Code for about six weeks now, however, I have been become aware that there are more ways for LLMs to do things that are at first apparent.

Claude code runs as you. More accurately, it runs as whatever user is whoami when you start the terminal. I can see a case for giving Claude its own account, with a token to access the relevant git repos, and I might do that. But I have not done it so far.

If you have a production database it should go without saying that you shouldn’t give Claude any kind of privileged access to the database, and probably shouldn’t let it onto any server the production system is running on.

But that also means you need to be careful to make sure it’s not too easy for you (the user Claude runs as) to get to the server or whatever. No ssh keys allowing login without a password. No credentials in environment variables. No credentials in files you can read etc.

In fact, for my (completely toy, at present) “production server”, I realised there is a way Claude could get to the server: I haven’t challenged it to do so, but I suspect if I gave it free reign, it would figure it out. But there is a limit, as far as I can see, to how much damage it could do, because the accounts it could get to don’t have any useful permissions. I mean, it could fill up the disks or something, but it shouldn’t be able to touch or even see the database, the code, the service etc. But I’m not 100% confident about that. (Which is why if the service becomes non-toy, I will lock things down even more in terms of how I run Claude Code.)

But there are still ways. Most obviously, Claude has written most of the code I am running on the server. And I update that code periodically, with new code Claude has written. So all it has to do is insert the wrong SQL or Python code without my noticing and it can do anything.

Obviously (obviously!) I read the code before deploying it, but I am a lazy meathead who makes mistakes. I might miss something.

It is also the case that while I don’t believe that Claude is malicious or is trying to get credentials or access, if it were malicious, some of the ways it would act might be identical to ways it does act. It is forever asking me to show it the contents of files that contain credentials of various sorts, and though it says You're absolutely right whenever I explain why I’m not going to show it that file, the danger is obvious.

Claude is a tool, and one that the makers don’t control in quite the same way other toolmakers control what their tools do. Unless Anthropic is actively adding malicious code paths to Claude, it is entirely the tool user’s responsibility to use the tool safely.

To my surprise, I expect to continue using CHOP, probably with Claude Code, for the foreseeable future. I will probably use it differently and a bit less: during the Month of CHOP I specifically wanted to see how far I could get with it doing almost all the writing, but I think a mixed mode will be more likely going forward. I suspect today, a sweet spot for anything complex is for the human to write the outline, structure, and first parts of the code and for the bot to be the critic/pair programmer and finisher/completer. Once the pattern, code style, and testing approach is established, it can fill in the deatils. But we will see.

Either way, I have changed my mind, something that I don’t do as often as I probably should. I still think this is a problematical technology, and I find using it stressful, but I now believe I am more productive with it than without.

CheckEagle is not ready yet, and even if I were to show it, you would probably be underwhelmed, because much of what I think is good about it is invisible at this point. But I hope to launch it as a private beta this year, and open it up early next year at some point. You are, in fact, using CheckEagle by reading this post.

The basic functionality of CheckEagle is a social checklisting service with a sideline in social bookmarking. What I mean by that is that it is a system for creating, managing, using, and optionally sharing checklists. A checklist is like a to-do list, but is intended to be used repeatedly, rather than just once. CheckEagle allows the creation and styling of checklists and the recording of completed checklists as records of what was done. It also contains (for reasons I will explain, but not now) a social bookmarking service, closely modelled on Joschua Schachter’s del.icio.us), which has now been acquired by and subsumed into Maciej Cegłowski’s Pinboard.

Checklists can be really simple, like this one. Or they can be quite complex, like Why Code Rusts, which was originally a blogpost on my TDDA Blog, or this String Best Practices checklist from my forthcoming book on TDDA. And in fact, they can be not really checklists at all, like this post, though I’m only really writing it here in the spirit of “dog-fooding” CheckEagle.

I will write more about this as it comes together. You can sign up for the beta here.