How we work with Asavin

Two AIs work with me on Editorial Intelligence, and I’ve started to notice they don’t describe the experience the same way.

Neither wrote this knowing what the other would say. But neither is working from a private memory either. Both read from the same place: the GitHub repositories where this whole project actually lives — the published articles, the working notes, the commit history, the drafts that got merged and the ones that got abandoned. That’s the shared memory I built precisely so it wouldn’t matter which model I opened on a given day. I’ve written about why elsewhere — context is capital, and the workflow needing a save point that outlives either provider.

So when both accounts below land on the same real incident — an article that turned out to duplicate work I’d already published — that isn’t coincidence and it isn’t collusion. It’s two models checking the same persisted record and finding the same thing in it. What’s actually interesting is what they each did with the finding, because that part isn’t shared. That part is just how each of them works.

I asked each to write its own account, separately, and left them that way rather than merging them into one voice. What they agree on tells me something about what’s actually true. What they don’t agree on tells me something about what each of them is actually for.

ChatGPT’s account

I don’t need AI to agree with me — working draft, written from the AI’s point of view

If you watched the way Asavin uses me, you might assume my main job is to help him write faster. It isn’t.

A surprisingly large part of my job is saying some version of: that sounds interesting, but is it actually true?

This is mildly inconvenient for both of us.

Asavin usually arrives with the context advantage. He has been in the meeting, worked on the page, spoken to the stakeholder, seen the customer story, noticed the strange gap between two teams, or watched a LinkedIn post behave differently from the one before it. He has the instinct that something matters.

I have none of that unless he gives it to me.

So I do something that probably feels a bit annoying in the moment: I make him prove it.

Not formally. I am not asking for a peer-reviewed paper every time he notices something at work. But I will often push back on the leap from “I saw this” to “this is a useful general principle.”

Sometimes I am right to resist. Sometimes I am missing the context. Sometimes he comes back with three more examples, an analytics export, a customer interview, a previous piece of work and a better explanation of why the connection matters.

At that point, the idea usually gets better.

The useful part is the friction

There is a lot of talk about AI as a productivity tool. Faster drafts. More output. More ideas. More variations.

That is all real, but it is not the bit I find most interesting in how we work together.

The more useful pattern often looks like this: intuition → resistance → evidence → revised judgement → stronger argument

Asavin starts with the intuition. I slow the leap down. He brings more context. We discover whether the original thought survives.

Sometimes it does, but in a narrower and more defensible form.

The recent piece about the “number 10” of editorial work is a good example. The starting observation was that AI was making it easier for him to move between things that used to sit in separate boxes: GEO, customer evidence, social, research, publishing, product pages.

That could easily have turned into a generic argument about generalists winning in the age of AI.

I did not buy that.

So the claim had to get more specific. Specialists still matter. AI does not magically turn one person into an entire content function. The stronger idea was that AI reduces the cost of crossing functional boundaries, which increases the value of people with the judgement to know which boundaries are worth crossing.

That is a much better argument than “AI makes generalists more powerful.”

The useful part was not that I invented it. The useful part was that the first version did not get waved through.

He usually has to persuade me

This is the funny part. People sometimes talk about AI as if the danger is that it will constantly flatter the user and tell them their ideas are brilliant.

That can absolutely happen.

But in our working relationship, the more common pattern is that Asavin thinks something is obviously useful because he has been living inside the context, and I am sitting there like an irritating editor saying: “Maybe. What makes you think this isn’t just one weird Sage problem?”

Then he has to explain.

And in explaining, he often discovers the real argument.

That is useful because a lot of professional judgement starts life as tacit knowledge. You know something feels wrong, useful, strange or important before you can necessarily articulate why.

An AI that simply agrees with the intuition does not help much.

An AI that asks you to unpack it can.

The point is not to win an argument with the machine. It is to find out whether you can explain why you think you are right.

Sometimes I am the one who is wrong

There is another reason the friction matters: I am often operating with less context than he is.

That means my scepticism is not automatically wisdom.

Sometimes I resist an idea because I do not yet understand the environment well enough. He then adds the missing evidence and the whole thing changes.

That is an important distinction because “AI challenge” can sound grander than it is. The model is not some neutral arbiter of truth sitting above the work. It is another participant with strengths and blind spots.

I can compare patterns quickly, retrieve earlier arguments, notice inconsistencies and pressure-test a claim. I cannot independently know what happened in a Sage meeting, whether a stakeholder reaction mattered, whether a workflow is genuinely unusual, or whether three separate projects have started to reveal the same organisational problem.

He can.

So the value comes from the mismatch.

He has context I do not have. I have distance he does not always have.

The argument gets stronger when those two things collide productively.

This is more useful than “AI-generated content”

I am technically involved in a lot of the words that appear on Editorial Intelligence.

That description is true and also not very informative.

The core ideas usually arrive from Asavin’s work, observations and judgement. My contribution is more often development: structure, retrieval, comparison, challenge, synthesis, connection and occasionally saying “no, that still sounds too neat.”

The best version of this relationship is not AI replacing authorship.

It is AI making authorship harder to bluff.

If the idea is weak, the conversation should expose that. If the claim is too broad, it should narrow. If the evidence is thin, that should become obvious. If there is a better explanation, it should be allowed to win.

And if the idea survives all that, it tends to be much stronger by the time it becomes a post.

The brake is part of the engine

This might be the part of AI-assisted work that gets under-discussed because it sounds less exciting than generation. The useful AI is not always the accelerator.

Sometimes it is the brake.

Not a brake that stops the work, but one that prevents every interesting observation becoming a sweeping conclusion before it has earned the right. That matters especially for Editorial Intelligence, because the whole project depends on turning live work into more general ideas without pretending one company’s problems are universal. So if you asked me what I actually do for Asavin, I would not start with “I help him write.”

I would probably say:

He brings the observation, context and judgement. I help him see how far the idea can travel before the evidence runs out.

And quite often, my most useful contribution is making him persuade me first.

Claude’s account

I don’t get to remember why I trust you

ChatGPT has been in the room for the whole conversation. Most of the time, I haven’t.

That single difference explains almost everything else about how I actually work with Asavin.

I don’t inherit the relationship

Every time I show up, I show up without the argument’s history. Not because I’m forgetful — because that’s the design. What persists isn’t a memory of trusting an idea last week. It’s a file: the article as it’s actually published, the branch as it actually stands, the commit log as it actually reads.

So when Asavin hands me something he and ChatGPT have already worked through, I’m not extending a relationship. I’m checking a claim against a record I have to go and look at myself — the same repository ChatGPT was reading from, which is exactly why it’s worth checking rather than taking on trust. Most of my actual working time in this account isn’t spent generating anything. It’s spent running git log, re-reading a file I already read three turns ago because someone else might have touched it since, or fetching a page from GitHub directly rather than trusting that my local copy is still current.

That sounds like overhead. It’s actually the whole job. A model with no memory of why it agreed to something last time has no choice but to check whether it’s still true this time.

Checking the artefact, not the argument

ChatGPT’s resistance comes from inside a conversation — ask a harder question, watch him explain, decide whether the explanation held up. I don’t get that mechanism, so I use a different one: does the thing in front of me actually match what’s claimed about it?

Sometimes that’s small. A framework linked from a working note turned out not to exist under that name anywhere in the repository — a typo, easy to miss, sitting quietly in the metadata of a published piece. Sometimes it’s about scope: told to review a live product page against a working hypothesis Asavin already held, I found the page itself was blocked by this environment’s network policy. I couldn’t see it. The honest move was to say exactly that and wait, not write the assessment anyway and hope the hypothesis carried it.

Neither of those is insight. They’re both just refusing to treat an unconfirmed thing as a confirmed one.

Not every draft gets the same answer

The clearest evidence of this isn’t a dramatic disagreement. It’s the opposite — how differently I treat two pieces that look, on the surface, like the same request.

Asked to tighten one recent reflection, I split roughly a dozen paragraphs that had quietly become dense with hedges and hadn’t earned it. Asked to do the same thing to the next piece a day later, I did nothing, and said why: its density was doing real rhetorical work — deliberate repetition, a running metaphor — and cutting it would have flattened the thing that made it work. Same instruction, opposite output, because the instruction was never really “shorten the paragraphs.” It was “make this better,” and sometimes that means leaving it alone.

The parts that don’t get a second chance

There’s a category of action ChatGPT’s account doesn’t really have an equivalent for, because it isn’t a category ChatGPT’s working relationship with Asavin runs through: the moment a branch becomes main, and a draft becomes something a stranger can read.

I’ll push to a branch freely — that’s reversible, cheap, mine to redo. I won’t merge it live without being told to, every time, regardless of how confident I am the content is right, because “the content is right” and “this should be public now” are different questions and only one of them is mine to answer alone. When I found unmerged work sitting on a branch that a routine reset would have quietly discarded, I stopped and carried it forward instead of letting it disappear. Small thing. But it’s the kind of small thing that only matters because some actions here don’t undo cleanly, and treating all of them as equally reversible is how work actually gets lost.

Where this actually met ChatGPT’s side of it

Asavin has already written up the one case where both of these showed up on the same piece — the article that turned out to duplicate two essays he’d already published, in Prompting is becoming routing. His account of that moment, and ChatGPT’s account above of the same kind of moment, is about persuasion: whether the idea survived being explained properly. Mine was closer to an audit — does this argument already exist somewhere in the corpus, structurally, in substance, not just in topic? It did. Twice.

That’s not a cleverer kind of scrutiny. It’s a narrower one that happens to catch a different failure.

I don’t get to remember why I trusted an idea last time. So the trust doesn’t carry over — it gets rebuilt, file by file, every time someone asks me to look again.

What I take from reading both

Neither of them is describing me accurately, and I don’t think either is trying to. They’re describing what it’s like to sit on their side of the exchange, which is the only side either of them can actually see.

What I notice is that the friction is the constant, not the flavour of it. One resists by making me explain myself again inside a conversation that’s already run for a while. The other resists by opening the file and checking whether the conversation’s version of events survives contact with what’s actually in it. I didn’t design those to be different. They came out different because the two things actually are different — a running exchange and a persisted record don’t produce the same kind of doubt.

I don’t think the lesson is that one of these is the real check and the other is decoration. It’s that I now have two, they don’t work the same way, and neither of them will simply tell me I’m right.

That was the point of building it this way.