I’ve written before about working inside Claude Code most of the day, and about the time it gives me back. Today I want to talk about a piece of work that went in entirely the other direction.
We’ve just finished rebuilding the Lucie Admin Portal, the internal tool we use to configure how the system behaves and see what it is doing. Coming out of that project was a pile of outstanding items: small fixes, gaps, things I noticed while building v2.0 that hadn’t been dealt with, that sort of thing. I’d agreed with Claude that we would defer each one and asked that a brief record be created. A dozen or so, I thought.
My next step was to turn them into a backlog of tickets, one per item, each describing what had to be done.
So I asked Claude to draft them. And 25 came back.
Normally when I initiate a job like this, what comes back is drafted reasonably well, so the effort I have to put in afterwards is less than it would have been from a blank page. That has been true nearly every time.
Not this time
I started reviewing the tickets one by one. I don’t remember exactly when I knew. Two or three, maybe four tickets?. It was quick.
They weren’t wrong in the way you’d expect, where a detail is off and you correct it and move on. One had a premise that didn’t survive being checked against the actual code. A couple described one-line changes as though they were pieces of build work. And one had misidentified what the thing even was: it treated a component as one kind of object when it is a different kind entirely, so the ticket described a problem that wasn’t a problem.
Let me be clear: each of the tickets read perfectly well at first glance. They were all based on the records Claude had made of prior conversations. They were all contextually relevant. They were all constructed in the standard format I have devised and were written in a professional tone.
But a pattern was emerging and it was clear… they needed re-writing. And not just superficially.
And then I glanced down and watched the list scroll off the bottom of the page, and thought about the 22 I hadn’t read yet.
The arithmetic went backwards
I wouldn’t say it was distressing. It was more than sobering, though, and it was a bit depressing, because it changed the mental arithmetic about the benefits of using Claude for this work.
I had to rebuild a lot of what Claude had constructed. And by the time I’d worked through the whole set and got them right, I had spent about as long as I would have spent writing 25 tickets myself. Possibly longer.
I think that’s a fair claim and it is not the usual whinge about AI being wrong. Everybody knows it can be wrong. The productivity case rests entirely on the idea that the AI draft is generally good enough that checking it costs less than doing it. When that stops being true the whole arrangement inverts. And what’s worse is that you don’t get alerted to an inversion. 25 plausible tickets look exactly like 25 good ones.
Why it happened
So why did it all go so wrong and what have I done about it?
The thing is that Claude drafted the tickets from my own notes. Those notes contained a record of what occurred to me at the time including my guesses about why things needed to be done, written at speed, as working notes, never intended as findings.
It turns out that Claude read the guesses as facts and built on them. It never went and looked at the code to check whether the reason I’d jotted down was the actual reason.
And that is the part that really bothers me. I have an elaborate governance framework in place that defines the way Claude is supposed to work so that it is fine-tuned to my circumstances. And of all the things my governance framework insists on, this is the one it insists on hardest: don’t assert what you haven’t checked. Gather the evidence first. Cite the source. Say you don’t know rather than fill the gap with something plausible. It runs through three separate rule documents, and I have automated checks that stop Claude mid-sentence and make it start again when it looks like it’s guessing.
But here’s the thing: when I went back and looked at why the automated checks hadn’t activated, the answer was that they couldn’t have. One of them only triggers when Claude says something like “I’m not sure” or “shall I check”, and Claude wasn’t unsure about any of this; it was confident and wrong. The other requires each response to declare what evidence it relied on, and a statement naming my notes satisfies it perfectly well. So both checks came up fine. The problem is that neither can tell whether the thinking behind everything was any good.
Which leads to a second fault that was sitting underneath the whole time. Nothing in the process asked which of those notes were worth raising at all. A dozen items I had thought worth deferring came back as 25 worth ticketing, because nothing was judging them; every jotting was treated as equally deserving of a place on the board.
I don’t think there is anything wrong with the notes; that’s what they’re for. The uncomfortable part, for someone who keeps as many records as I do, is that a document which is perfectly sound as a note becomes something else when it turns into an input for an AI agent that generates things at volume without first triaging them. In a sense, the better the records, the more confidently the wrong thing gets built on them.
How I’m fixing it
One response might be to say “always check the output”, which is both true and useless. I fixed this particular problem by reading all 25, one at a time, with Claude, and arguing about each ticket. Then we changed some, deleted some and added a few more.
But I can’t do this every time and it’s not scalable. Using Claude to draft these things is the operating model, and I set it up that way deliberately. A detailed review of half a dozen critical things is manageable; in-depth re-writing of 25, or tomorrow 250, is not.
So I’m trying to fix it by changing the way Claude works with me.
My governance framework already includes contextual documentation, behaviour standards, guidelines, guardrails, sub-agents, hooks, skills and a bunch of other things. It specifically includes guidelines on research, problem solving and response construction.
Despite this, the incident I’ve just described occurred. The thing is, the tickets were the final straw rather than the whole story. This had been smouldering for a while: a pattern where I would get a great deal of material back, correctly formatted, in the right shape, and a good part not worth the room it took up. Responses where 19 points would come back and six of them matter. Analyses where one important item would sit alongside a spelling correction, at the same weight, and I’d have to do the triaging.
So today we did two things.
First, we pulled the governance framework apart and rewrote a chunk of how Claude and I work, around judging what is worth saying and how much prominence it gets. As a result I have a new guideline document defining eight tests that Claude is meant to apply before writing any response. Things like ranking before writing, grouping smaller items, and not presenting flat lists of unequal things.
Second, we built a new check for the case where the evidence being cited isn’t really evidence at all. The existing checks ask whether Claude has declared that it gathered its evidence. The new one asks it to produce the evidence. If a response asserts why some part of the system behaves as it does, it has to cite the file it actually read, or it gets stopped and sent back to go and read it.
Before switching it on we ran it across 1,233 of Claude’s past responses to me, to see how often it would have stopped something perfectly innocent: 1.3% of the time. Pretty low. Then we ran it over the day the tickets were written: 7.6%, nearly six times more often. And every response it stopped that day cited ‘evidence’ that turned out to not be really evidence at all.
Will it work? I don’t know, but fingers crossed.