A short follow-up to my series on context engineering: the diagnosis (long sessions produce bugs), the harness that makes /clear free, then the question of no longer having to type it. Here, the harness types it by itself.

Don’t block for no reason

Right now, I am working on an agentic software factory. My guiding principle: humans should only have to step in on tasks that add value, and everyone should be as efficient as possible. Every manual intervention costs twice: the time to do it, and all the time the agent stays blocked, waiting for a human to unblock it.

For a few months now, I have been hunting these interventions one by one, to make them disappear. One stubborn one was left: the /clear. In a previous article, I explained how to make it free: the state of the work lives in a plan, not in the conversation, so you can empty the conversation and resume without losing anything. It works very well. But a human still has to think about it, type /clear, then “let’s resume”.

“What about auto-compaction?” It does avoid the intervention, but it does not give good results. It starts at the worst moment, when the agent is the most tired, sometimes in the middle of a task. Its summary is generic, and you do not choose what survives: a decision forgotten along the way comes back later as a bug. Reducing the window size (article in French) makes it start earlier, but then you just get it more often, and each run blocks the agent and costs one more call to the model.

So the choice was: stay in front of the screen to type /clear at the right moment, or let the agent degrade. I wanted neither.

Greg’s idea: a “relay” mod that types for you

I like to run my experiments at home, in the evening. Tonight, I tried an idea from Grégory, our QA lead, who is passionate about AI and further ahead on the subject than most people: use a Claude mod to trigger the /clear from outside the conversation, instead of waiting for a human to type it. What follows is my own experiment of the evening: a mod written from the official documentation, measured, and the traps I found along the way.

A mod is a plugin that contains TypeScript code run by Claude Code itself. It can listen to what happens (the end of an answer, for example) and do what you would do at the keyboard: read the size of the conversation, send a message, run a command… like /clear.

The relay takes four steps:

1. at the end of each answer, the mod reads the size of the conversation;
2. above the threshold, it asks Claude to update `state.md`: what is settled, what was tried and failed, and the next step;
3. when that turn is over, it runs /clear;
4. then it sends “let’s resume”, and the fresh conversation reads state.md again (one line in CLAUDE.md tells it to).

The mod fits in three files:

• .claude-plugin/plugin.json: its name;
• hooks/hooks.json: { "modules": ["./register.ts"] }, which tells Claude Code which code to load;
• hooks/register.ts: the code, below.

import type { Register } from 'claude-code'

const MARGIN = 40_000 // relay once the conversation grew 40k tokens past its starting size
type State = { phase: 'armed' | 'writing' | 'clearing' | 'resumed'; base?: number; held?: string[] }

const HANDOVER =
  'The conversation is getting long. Update state.md in ten lines at most: ' +
  'what is settled, what was tried and failed, and the exact next step. ' +
  'Then answer "state.md updated" and nothing else.'

export const register: Register = on => {
  on('turn.complete', async ($, e, next) => {
    const result = await next(e)
    if (e.agentId) return result // main conversation only, not subagents
    const key = `relay:${await $.session.root()}`
    const s = ((await $.store.get(key)) as State | undefined) ?? { phase: 'armed' }
    const tokens = (await $.session.usage()).context.tokens ?? 0

    if (s.phase === 'writing') {
      // state.md is written: clear, then resume, right after this hook returns
      await $.store.set(key, { ...s, phase: 'clearing' })
      $.clock.after(0, async () => {
        await $.command.run({ command: 'clear' })
        await $.store.set(key, { ...s, phase: 'resumed' })
        await $.prompt.submit({ text: "let's resume", asUser: true })
      })
    } else if (s.phase === 'resumed' || s.base === undefined) {
      // first turn of a conversation: measure its starting size, then send back what was held
      await $.store.set(key, { phase: 'armed', base: tokens })
      for (const text of s.held ?? []) $.clock.after(0, () => void $.prompt.submit({ text, asUser: true }))
    } else if (s.phase === 'armed' && tokens >= s.base + MARGIN) {
      await $.store.set(key, { ...s, phase: 'writing' })
      $.clock.after(0, () => void $.prompt.submit({ text: HANDOVER }))
    }
    return result
  })

  // While the relay runs, hold what the person types, and send it again after the resume
  on('prompt.submit', async ($, e, next) => {
    if (e.origin.kind === 'plugin' || e.command) return next(e)
    const key = `relay:${await $.session.root()}`
    const s = ((await $.store.get(key)) as State | undefined) ?? { phase: 'armed' }
    if (s.phase !== 'writing' && s.phase !== 'clearing') return next(e)
    await $.store.set(key, { ...s, held: [...(s.held ?? []), e.text] })
    return { drop: 'Relay in progress: your message will be sent again right after the resume.' }
  })
}

To try it: claude --plugin-dir ./relay. And claude plugin validate ./relay tells you what the mod listens to and calls.

The three traps

1. Don’t set the threshold too low, to avoid livelocks. Before the first message, a conversation already weighs a few tens of thousands of tokens, more depending on the plugins you have loaded, and even more in Claude Desktop. If your threshold for relaying to a new session is below this starting base, the conversation is still too big right after the /clear, and the answer to “let’s resume” immediately starts another relay, then another, then another… The mod then runs on its own, forever, and the work stops moving: that is a livelock (everyone is busy, nobody makes progress). This is why the mod measures the size at the first turn of each conversation, and adds a margin.
2. Don’t run /clear from inside the hook. The documentation of $.command.run says so: the command is refused if it comes from a hook that the turn is waiting on. So the mod hands it to $.clock.after, to run once the hook is finished. This is not a bad Thread.Sleep that bets on a delay: the duration plays no role, it is just a way to get out of the hook. Claude Code guarantees the order, because it queues /clear and "let's resume" and only runs them when the session is idle.
3. Let nothing through during the relay. A message typed while Claude writes state.md would go in just before the /clear, and its answer would be wiped out with the rest. So the mod also listens to prompt.submit: during the relay, it puts aside what the person types, shows "relay in progress", then sends it again, unchanged, once the fresh conversation has started. Nothing is lost.

What a good handoff note keeps

The prompt in the mod is short on purpose. But the whole relay depends on this note. Here are the rules that work:

• One line per entry, as few words as possible. The note is read by a fresh agent, not by a human.
• Keep what is still open: each goal not met yet, with its next step; the branch, and whether it is committed; each dead end, with what was tried and what happened; the human’s instructions that still apply.
• Keep only what is verified. A claim that no run has confirmed goes on its own line, with the check that will settle it. Anything vague is removed.
• Remove what is done: goals met, dead ends solved, claims verified, instructions that no longer apply.
• Leave out what can be found elsewhere: reasoning, finished work, numbers, quotes, tips. The code, the plan and git already hold them.
• Keep a question for the human only if no run can answer it.

Free, then automatic

It works, in Claude CLI as well as in Claude Desktop, including on a TEAM account. The first episode made /clear free. This one makes it automatic. One interruption less, and nobody will miss it.

This relay is only one piece of a bigger whole. My next article, the third and last of my series on the agentic software factory, will tell the story of this software factory itself: the factory in which this small mod is just one small part.

Addendum for loop engineering

When I shared this with Greg, he immediately went one step further: add a notion of “goals” to state.md, and a sentence like “until you meet your goals” to the message the mod sends after the /clear , and you get loop engineering. The agent no longer stops at the end of a session: it relays, again and again, until the work is done. He is right, and the relay is exactly the piece that makes it possible. I don’t do it at work yet, because the token bill is not the same at all: for now, I keep it for my personal projects at home.

Going further

• Same model — so why do some devs ship more bugs?: the diagnosis, why long sessions produce bugs.
• A good harness makes /clear free: the state of the work lives in the repo, so that /clear costs nothing.
• What if /clear was no longer our job?: cutting in time and in space, with loop and graph engineering.
• Comment éviter de devenir zinzin (votre IA, et vous un peu aussi) (in French): seeing the size of your context, and setting the auto-compaction window.
• The hardest part begins when it works: the first episode of my series on the agentic software factory.
• The official documentation of Claude Code mods.

[French version here]

Today, almost everyone has Claude or an equivalent. Everyone produces a lot more code. And yet, more and more companies say the same thing, quietly: we are not getting anywhere. No more value delivered, tired people, and the feeling of running in place, on steroids. It does not have to be this way. Since the start of the year, I have been guiding the agentic transformation of an incredibly talented scale-up of more than 70 developers, and what I see there, and elsewhere, fits in one sentence. The difference between what works and what does not has nothing to do with the model or the tool.

Here are 8 traps almost all of us fall into.

1. We get distracted too easily

Everything is within reach, and everything takes only a few minutes. The AI keeps suggesting: “it would be nice to do this too, wouldn’t it?” And it is true. So we say yes, and we squeeze lots of non-urgent, non-priority things into our days. Lots of small details, but the total time can be surprising. With AI, the last one who spoke is right, and the last one who spoke is almost always the AI. We drift away from what matters without noticing, several times a day, every day. Keeping your eyes on the expected value, the way an experienced product manager does, can be learned, but it does not come naturally to everyone.

2. We do too many things in parallel

Since the agent works while we wait, we start a second topic. Then a third. I saw a developer with five agent windows open. He was not going five times faster: quite the opposite. We start more things, each one waits longer, and cycle time gets worse. Donald Reinertsen wrote it long before AI: every piece of work in progress that waits has a cost of delay, and nobody puts it on the bill. AI does not change this rule, it just makes work in progress (WIP) much easier to start. Unfortunately.

3. We become too passive, and we lose our grip

When the agent works well, the day changes nature: we read, we approve, we click the recommended option… we read, we approve, we click the recommended option (and so on). We are still in the room, but no longer in the equation. And what we no longer understand, we frame badly: teams losing their grip on their own business domain, and mechanically more slop, so more rework. The real risk is not bugs. It is the comprehension debt, and the disengagement that comes with it. That is the subject of the article drawn from my keynote.

4. We optimize the wrong things

The textbook case: human code review 🤦‍♂️. At an AI conference recently, I was shocked by how many people still spend time and money having humans review AI-generated code. It is one of the first things we do when we start with agents, and it is not an interesting thing to invest in: it is like putting a Formula 1 engine in a carriage and keeping the wooden wheels. The human becomes the bottleneck, and above all the human burns out. Doing the same as before, only faster, is not the answer: it gives you a gain, then a plateau.

5. Our tools and practices become brakes with every new model release

Our first harness was about ten specialized agents: an architect, a tech lead, a reviewer. We moved to a single agent and to scripts that check the rules instead of the prompt (which Anthropic now recommends too), because every new version of the model absorbs what we used to do on the side, and our homemade setup was slowing us down instead of helping. Without understanding the fundamentals, we copy someone else’s tooling, and it ends up holding us back.

6. We become AI mechanics

This trap looks like work. We spend our days under the hood: a new skill, one more hook, a harness to polish. All of it is fascinating, and all of it shows up in commits. Meanwhile, the product we owe our customers stops moving. Tooling is a means: the day it becomes the subject, we have changed jobs without noticing.

7. We burn out

Before, a developer was expected to know their area by heart. With agents, people cover more and more areas, move from topic to topic much faster, and no longer have time to let anything sink in. Some are in real distress, not because they cannot keep up with the tool, but because they can no longer consolidate their mental models. Cognitive load has become the bottleneck of teams. We need to work differently: accept that we will not remember everything, and be able to get a topic back into our heads in a few minutes, for example with an agent that asks us questions instead of answering them, as in the design harness I described recently.

8. We measure speed, rarely impact (and never rework)

This is the trap that makes all the others invisible. Dashboards show code produced, PRs merged, tickets closed: output, not outcome. A green test is output too: it is not a product that someone has launched and used. Many developers ship to production without ever having opened the application, and the defects are found later, by others. Nobody counts the rework, and nobody puts velocity next to business impact. So we can be going flat out and getting nowhere, and nobody notices. Full speed, zero distance.

The good news

There are plenty of solutions to all these problems, and none of them involves switching to another AI model. I will tell you about them in my next article. Stay tuned!

I am VP of Technology at Shodo, where we help teams succeed in their agentic transformation without losing either their grip on the business domain (Domain-Driven Design) or their impact (Product & Flow). If these traps sound familiar, let’s talk.

[English version here]

Aujourd’hui, presque tout le monde a Claude ou équivalent. Tout le monde produit beaucoup plus de code. Et pourtant, de plus en plus d’entreprises disent la même chose à voix basse : on ne s’y retrouve pas. Pas plus de valeur livrée, des gens fatigués, et l’impression de faire du surplace sous stéroïdes. Ce n’est pas une fatalité : j’accompagne depuis le début d’année la transformation agentique d’une scale-up incroyablement talentueuse de plus de 70 devs, et ce que je vois là-bas comme ailleurs tient en une phrase. La différence entre ce qui fonctionne (ou pas) ne tient ni au modèle ni à l’outil.

Voici 8 pièges qu’on rencontre presque toutes et tous.

1. On se laisse distraire trop facilement

Tout est à portée de main et tout coûte quelques minutes seulement. L’IA propose sans arrêt : « ce serait pas mal de faire ça aussi, non ? » Et c’est vrai. Alors on dit oui, et on intercale plein de choses non urgentes et non prioritaires dans nos journées. Plein de petits détails, mais le temps cumulé peut être surprenant. Avec l’IA, c’est le dernier qui a parlé qui a raison, et c’est presque toujours elle. On s’éloigne de l’essentiel sans le voir, plusieurs fois par jour, tous les jours. Garder le cap sur la valeur attendue comme un·e product manager expérimenté·e, ça s’apprend, mais ce n’est pas donné à tout le monde.

2. On fait trop de choses en parallèle

Comme l’agent travaille pendant qu’on attend, on lance un deuxième sujet. Puis un troisième. J’ai vu un dev avec cinq fenêtres d’agent ouvertes. Il n’allait pas cinq fois plus vite : au contraire. On commence plus de choses, chacune attend plus longtemps, et le cycle time se dégrade. Donald Reinertsen l’a écrit bien avant l’IA : tout travail en cours qui attend a un coût du retard (le cost of delay), que personne ne facture. L’IA ne change pas cette règle, elle rend juste le travail en cours (WIP) beaucoup plus facile à démarrer. Malheureusement.

3. On devient trop passif·ve, et on perd en maîtrise

Quand l’agent travaille bien, la journée change de nature : on lit, on valide, on clique sur l’option recommandée… on lit, on valide, on clique sur l’option recommandée (et ainsi de suite). On est encore dans la pièce, plus dans l’équation. Et ce qu’on ne comprend plus, on le cadre mal : des équipes qui perdent la main sur leur propre métier, et mécaniquement plus de slop, donc plus de rework. Le vrai risque n’est pas les bugs. C’est la dette de compréhension, et le désengagement qui vient avec. C’est le sujet de l’article tiré de ma keynote.

4. On optimise les mauvais sujets

Le cas d’école : la revue de code humaine 🤦‍♂️. À une conférence sur l’IA récemment, j’ai été choqué par le nombre de personnes qui consacrent encore du temps et de l’argent à faire relire du code généré par l’IA à des humains. C’est un des premiers trucs qu’on fait quand on commence l’agentique, et ce n’est pas un sujet intéressant à investir : c’est comme mettre un moteur de Formule 1 dans une calèche en gardant les roues en bois. L’humain devient le goulot, et surtout il s’épuise. Faire comme avant, mais en plus vite, n’est pas la solution : ça donne un gain, puis un palier.

5. Nos outils et nos pratiques deviennent des freins à chaque nouvelle version des modèles

Notre premier harnais, c’était une dizaine d’agents spécialisés : architecte, tech lead, reviewer. On est passés à un seul agent et à des scripts qui vérifient les règles à la place du prompt (ce qu’Anthropic recommande aussi désormais), parce que chaque nouvelle version du modèle intègre ce qu’on faisait à côté, et que notre bricolage freinait au lieu d’aider. Sans comprendre les fondamentaux, on copie l’outillage de quelqu’un d’autre, et il finit par nous ralentir.

6. On devient des garagistes de l’IA

Ce piège ressemble à du travail. On passe ses journées sous le capot : un nouveau skill, un hook de plus, un harnais qu’on polit. Tout ça est passionnant, et tout ça se mesure en commits. Pendant ce temps, le produit qu’on doit livrer à nos clients n’avance plus. L’outillage est un moyen : le jour où il devient le sujet, on a changé de métier sans s’en rendre compte.

7. On se crame

Avant, on attendait d’un·e dev qu’iel connaisse son périmètre par cœur. Avec l’agentique, les gens couvrent de plus en plus de périmètres, enchaînent beaucoup plus vite, et n’ont plus le temps d’imprimer. Certain·es sont en détresse, pas parce qu’iels ne suivent pas l’outil, mais parce qu’iels n’arrivent plus à consolider leurs modèles mentaux. La charge cognitive est devenue le goulot des équipes. Il faut fonctionner autrement : accepter de ne plus tout retenir, et pouvoir remettre un sujet en tête en quelques minutes, par exemple avec un agent qui nous interroge au lieu de nous répondre, comme dans le harnais de conception que j’ai décrit récemment.

8. On mesure la vitesse, rarement l’impact (et jamais le rework)

C’est le piège qui rend tous les autres invisibles. Les tableaux de bord affichent du code produit, des PR fusionnées, des tickets fermés : de l’output, pas de l’outcome. Un test vert aussi : c’est de l’output, pas un produit que quelqu’un a lancé et utilisé. Beaucoup de devs livrent en prod sans avoir jamais ouvert l’application, et les défauts sont trouvés plus tard, par d’autres. Personne ne compte le rework, ni ne rapproche la vélocité de l’impact métier. Alors on peut être à fond et faire du surplace sans que personne ne s’en aperçoive. À pleine vitesse, zéro distance.

La bonne nouvelle

Il y a plein de solutions à tous ces problèmes, et aucune ne consiste à changer de modèle d’IA. Je vous en parlerai dans mon prochain article. Stay tuned!

Je suis VP of Technology chez Shodo, où l’on aide les équipes à réussir leur transformation agentique sans perdre ni la maîtrise du métier (Domain-Driven Design) ni l’impact (Product & Flow). Si ces pièges vous parlent, parlons-en.

A few weeks ago, I lost a whole afternoon. Not because of a bug, and not because of too many meetings. I lost it while working, with Claude, head down. And around 6 pm, when I finally looked up: wait, wait, wait. What was my goal, at 2 pm?

I knew it very well. It was even written down. I am currently building an agentic software factory for my client, and we have just opened it in beta to a handful of volunteers. The goal of the afternoon was one of the big, deep pieces of work on that factory, the kind you do not finish in one hour. I did not touch it. Not one line.

Here is what happened instead. A first piece of feedback from one of the beta users arrives on Slack: “it would be nice if…”. Ten minutes, fixed, and I am happy: he can see that her feedback is taken seriously, he will come back. While I am there, Claude slips in: “by the way, while we are at it, we could also…”. True, it would be nice. And it will not take long. Done. A second piece of feedback comes in. Then a small optimization of my own, because it is convenient, I am already in there and ideas keep coming. Then a third piece of feedback. And so on until the evening: five or six small things delivered, all useful, all appreciated, and none of them was the one I had come to do.

The worst part is that every detour had a good reason. I wanted the people testing the factory to feel that their feedback was handled fast, so that they would want to use it more often and earlier. That is change management, and it is right. But it was not the goal of the afternoon. I spend my days explaining to teams how to stay in control of their AI, and I got caught like a complete noob. And I do not think I am an isolated case. In the companies I visit, everyone has the feeling of going faster, and the projects that matter are not moving forward any more than before: AI mostly speeds up tasks that probably should not have been done at all.

Getting sidetracked

You know the mechanism. You are working on a topic. Claude answers, and on the way it adds: “it would be nice to do this too, what do you think?” And it is true, it would be nice. Then another idea bounces off the previous one. Then a third. Topics pile up like a stack you never climb back down. With AI, the last one who spoke wins. And the last one who spoke is almost always the AI.

Nobody forces you. You just get led around, gently, from good idea to good idea, far from what you came to do. A colleague gave me the right image: it is a thread, and you do not control the thread you are pulling, because it is infinite.

This is not new. What is new is that everything is now a few minutes away. Nothing costs enough anymore to make you hesitate. And time flies when things happen: with an AI, something happens every thirty seconds. That day, my afternoon beat to the rhythm of Claude’s suggestions and Slack notifications, not to mine. The young Thomas I used to be would have been eaten alive.

And it has a price. Too much information, too many details, too many decisions, too many questions: like in boxing, when you take too many hits, you end up getting beaten more often, and you lose track of what needs to be done. And once you have lost track, you stop leading. You just approve whatever comes through. It is exhausting, and it is exactly how you end up producing slop: mushy code that you approved without reading it. Every “good idea” you accept is also one more topic open in parallel. Since we launched AI at my client, I keep repeating the same rule: two topics in progress per person, no more. I have seen a developer running with five Claude Code windows open. He was not going five times faster. And on that famous afternoon, I was no better.

Notebook against the machines

After that afternoon, I brought back an old friend: my small notebook. A worn lavender cover, an erasable Legami pen (very important) slipped between the pages. A few euros. It has not left my desk since, and it is what keeps me focused, and in control.

The principle fits in one line. Before I start, I write down the goal for the next two hours, or for the morning, and I keep it in front of my eyes, next to the keyboard. Not a list: one line. On today’s page, for example, it says: “Detect when the developer proposes to implement something that already exists elsewhere on the platform”. It is my captain’s log.

When Claude offers me a great idea that is not in my goal, I answer: “Good idea. Keep it on the side, but not now.” And Claude is the one who writes it down. My notebook is not there to store Claude’s ideas: Claude is very good at filing them away by itself. My notebook is for my own direction. My steps, what I want to do, and what I expect from it.

And this is where it works: as long as an idea is not written anywhere, a small voice keeps running in the background, “whatever you do, do not forget”. Once it is written down, the voice goes quiet. My head is free for what I had decided to do.

It feels a bit old school, I know. A notebook and a pen, facing agents that write code on their own. But Romain, the colleague who told me about the infinite thread, is much younger than me, and he keeps the same kind of notebook, “to stay on the critical path”. Another one closes Slack, writes down what he is going to do in his notebook, holds on for two hours, then reopens Slack. Small, simple things that have much more leverage than you would imagine.

So next time you look up at the end of the day, ask yourself the question: did I work on what matters, or on the extras?

If you are not sure, buy yourself a notebook.

This small story sits next to a longer series on the agentic software factory: The hardest part begins when it works and Back in the equation, with a third article to come.

Second of three articles taken from my keynote “The hardest part begins when it works”. The first one set the diagnosis: when agentic AI works, we become passive. This one tells my first answer, a design harness. The third one will go one level up, to the software factory in an agentic world, and the new role developers can play in that world.

The teams that do great with AI know their domain and avoid passivity

In the first article, I told what happened to us the day agentic AI worked: reading and approving all day long, still in the room, no longer in the equation. And one observation that has been my compass ever since: the teams that do great with AI are the ones that master their craft and their business domain.

What I had not said is that the two are connected. Everything that makes us passive disengages us, and when we disengage, we lose mastery. Some of the people who had lost their grip on their domain were exactly the ones who had automated as much as they could. Including what they should never have automated: understanding what is asked of them, deciding where the code will live, saying what “done” means. Passivity makes us lose mastery, and mastery is exactly what makes the difference later, when we frame the work of AIs. If we are bad at this, we can optimize execution as much as we want: we will just produce slop faster.

The solution: a conversational DESIGN harness

Two things to fix at once, then:

• get us active again,
• and get us back in control of the domain and the product we work on.

My answer is a DESIGN harness. A harness, as in the harness maker’s craft, is everything the agent re-reads before working for us: rules, plans, guardrails, skills. Most harnesses are implementation harnesses: they help the agent write good code. A design harness sits upstream. In the keynote, I define it as everything between the feature the product team hands us and the Definition of Done tests of each slice.

A harness for the humans, not for the agents

It flips the usual role: it does not frame the agent, it guides us, the humans, forcing us to ask the right questions at the right moment, precisely in the activities we should never have automated:

• understanding the domain and the business,
• designing the architecture and the product.

One move, two effects: active again, and back in touch with our product.

Slicer is my design harness, with 4 moments and 2 tempos. The moments: understand, design, slice, set the Definition of Done. Nothing new, this is the job. We already did it before AI, and we even did it better. What changes is who holds the pen.

The first two moments are Kairos, the time to understand, yours. The tool asks, you think, and you write in your own words. It takes the time it takes, and it is the only place where a mistake still costs nothing.

The next two are Chronos, the time that flies, its own. The tool proposes, writes, counts, re-reads, and wakes you up to decide. You no longer write: you decide.

And the meetings between humans stay, with no agent in the room: event storming when there are still gaps, refinement with the PM, always. Slicer does not replace them. It makes sure we get there with something to say, rather than with a summary to approve.

The “Understand” moment

Understand is done solo, no exception: each person on their own, and we then compare the restatements and the perspectives of everyone who did it. So you open Slicer with the product ticket. It does not summarize it for you. It asks: “Tell me in two sentences what you think this feature does, and for whom.” And it waits.

You write, it follows up, and the boxes turn green one by one. When only one is left in yellow, the vocabulary, comes the last test: it asks you to retell the whole feature, from memory, without reopening the ticket.

I restated by voice (Superwhisper) everything I had kept in mind. Here is what it detects: it compares my words with what the PM wrote, and for each gap, it decides: the ticket says the same thing as you / you drift away from the ticket on this… / you propose something new (to be clarified if relevant). In the fictional upsell case I show you here, one single word gave me away.

“Subscription” four times in my mouth, and the ticket never says it. And yes, the one who got it wrong was me, again.

A wrong word at the Understand moment becomes logic in the wrong place at the Design moment.

The “Design” moment

Design is the same conversation on another question: now that we know what to do, where do we do it, and how (business architecture and technical architecture)? This one, on the contrary, is better done together: we sketch the solution and the architecture as a team. The tool has access to the code and to the whole system, and it asks. You are the one who chooses, and above all, you are the one who writes down what you rule out, and why. And since everything we weighed is in the conversation, the agent suggests and writes the matching ADRs (Architecture Decision Records) when it is relevant.

An ADR is for the decisions that would be costly to question again: no need to write one for everything, even if AIs love to generate text.

A Domain-Driven Design moment, rather

Under the hood, Design draws on all the wisdom of strategic Domain-Driven Design, so dear to my heart, without ever using its jargon: it simply forces us to ask ourselves the right questions. Who is responsible for what, which subdomains talk to each other and how, which model depends on which other one. And when we move to technical architecture, it draws the same way on all the know-how we have built up: when a modular monolith (in Hive mode) is the right choice, when it makes sense to extract a service, when a worker is what you need.

The whole challenge of Understand and Design is in this balance: ask enough questions to be relevant, but not too many either, so that it stays acceptable. We want to avoid sessions as long and tedious as the ones we sometimes go through with Matt Pocock’s /grill-me.

Then the tempo changes

Once we have done the “Understand” and “Design” phases, which will have kept us busy, the AI speeds up and does a bit more of the work for us.

The third moment is slicing: cutting the feature into several increments of value (at least to go and get feedback), that is, user stories for which it creates the tickets. For this, it only asks us to choose between several go-to-market options, each with its arguments, to be validated together with the Product Manager.

The fourth moment is when it suggests Definition of Done (DoD) tests for each user story. This moment matters, because the DoD tests will be the working base of the implementation harness agents (back or front) we then use to write the code. Once we have iterated with it on the list of tests, written in natural language but as concise as possible, Slicer’s last deliverable is to generate the code of these DoD tests, and the contracts or walking skeletons of the code to come.

Preparing the ground for slop-free implementation

One last word about these Definition of Done tests, because everything rests on them. AIs are now very good at writing clean code, at least the frontier models like Opus 5.5, but they are still incredibly bad at writing tests. They always tend to cut corners: rephrasing and changing the tests to make them pass, rather than doing the work needed for the implementation to turn them green. They also love to write what we call tautological tests: tests that only describe what the code already does, so they are always green, and completely useless when the code does not do exactly what we want it to do.

This is why the Definition of Done tests written by Slicer must be protected: the implementation harnesses (back and front) that write the code for us must never be able to change them.

But we will see that in the third and last article, about the agentic software factory, of which the design harness is only one element.

The first article: The hardest part begins when it works (October 11, 2026). To date the thread: Your agent gives you Chronos. It cannot give you Kairos. (August 26, 2026).

Keynote given at Thales’ cortAIx Club on October 1, 2026 and at Naboo on October 6, 2026.

TL;DR. This is the first of three short articles based on my keynote “The hardest part begins when it works”: more than six months of agentic transformation in a scale-up, with very experienced people. Sudden adoption, incredible results, bottlenecks moving one after the other until they reach the product team, and then the backlash for everyone: the passivity trap, which AI pushes us into a little too easily. To face this, my first answer is a design harness that reverses the relationship. It works as a conversation, where the AI asks the questions (Socratic style) and the humans propose, actively.

This article introduces the problem. The second one details the principles of this design harness. The third and last one will talk about the logical next step: the agentic software factory we are building right now.

“You have a few days to get used to it. Starting next Monday, you no longer use your IDE: you will work in agentic mode with Claude Code in the command line (CLI), as we saw together in these two sessions. This applies to everyone and to every team.”

This is how our second mob programming session with the whole tech team of my client ended, in late March 2026. The person who said this was Hossam, the CTO at the time, with me at his side. Who am I? Thirty years as a developer and consultant, VP of Technology at Shodo and, since February 2026, part-time Head of Engineering at this fast-growing fintech in accounting and tax, with nearly 75 very senior developers.

Late March: everybody in the pool

At this client, the adoption of agentic AI was not gradual. It was sudden. Everyone at the same time, in the command line, outside the IDE. No volunteers-first, no trial period: so that each person would drop their habits and not miss the experience. One single, mandatory life jacket, our very first agentic harness, designed with the former CTO, me and a few engineering managers and tech leads, and we all jump into the pool together. The goal was to force everyone to focus on discovering what agentic development really is, without losing weeks comparing models or letting each person pick their own tools and approach. We are in a fintech, a scale-up, and delivery does not wait.

The results were incredible. In early May, one month after the kick-off: 27% more user stories delivered per developer. And contrary to what I was reading on social networks, going faster with AI did not make bugs explode. Quite the opposite: 49% fewer bugs. Six months later, in September, we are at 75% more user stories delivered per developer, and 40% fewer bugs. Almost x2.

From one bottleneck to the next

Very early, the bottleneck was no longer writing the code. It was reading it. Then the bottleneck moved again, twice.

Pull request reviews without end, handed over to agents, and then, on July 1st, the end of blocking cross-team reviews: with Michael, the new CTO, we want teams to be as autonomous as possible. As I told them: “No more gated code reviews. Long live code reviews after the fact, like when you do continuous delivery the advanced way.” So the code goes to production reviewed by Claude and by the harness, and a quality watch or humans read it afterwards, in batches, and only when it is really useful. We also ask people to let go of the code a little:

if the review shows no problem of architecture, scalability or performance, or security, then it is “good enough” to ship. No more endless code review debates about cosmetic details.

Reading the code was no longer the only problem; production support became one. One of our talented developers built a tool that, from a simple message like “something is wrong on this screen”, reads the APM, the logs, the database and the code, and proposes a pull request. A team working on large business flows used to spend 40% of its time on run and support. It now spends 5%. That leaves even more time to ship value.

Production support was no longer the main problem, so the product became one. Backlogs empty out, developers wait: when tech speeds up, the wave hits the product team. So in July, we help our friends in product build their own agentic harness. It covers everything from discovery to writing PRDs for initiatives, and epics and features ready for the squads.

You could think we were done accelerating.

Running very fast. And going nowhere.

This is when the difficulties come back on the tech side, and they do not look like the previous ones. Some teams do great, others struggle. The product team is the one telling us: in some teams, people are no longer very involved in understanding the business. Refinements happen by proxy and lose their value, because the developers’ Claudes are asking questions to the product team’s Claudes. Splitting features into user stories happens all by itself, and when it does, we become AI mechanics, not developers who are more involved in the product and the business, as we wanted at the start.

Meanwhile, former colleagues tell me it is the same in their company. Everyone feels they are going faster, but not always with more impact for customers. And very often, this leaves the C-level puzzled…

The cause is built into working with LLMs, and with Claude in particular. Read and confirm. Read and confirm. Read and confirm. Over time, you become passive, and it wears you out. Our agents give us Chronos. Too often, they take our Kairos away. Accepting Claude’s recommended solutions becomes too tempting, and disengaging.

Lisanne Bainbridge wrote it in 1983: we automate the easy tasks, and we leave the hardest one to the human, which is monitoring. But monitoring a system that works is the worst task you can give to a brain. You are still in the room. You are just no longer in the equation.

Some teams felt disengaged, and much less effective. It produces slop, and it reworks more than others. Business knowledge is not always there. The real risk is not the bugs: it is the understanding debt, and the disengagement. The real trap is becoming more and more passive.

AI asks the questions, humans decide

One observation: the teams that really do great here are the ones whose developers master the domain and the product. You can only frame well what you understand. So here is a question I now force myself to ask about every tool we adopt or build: does this tool make me produce and rephrase, or just validate? A tool that makes you produce the decision keeps you in the equation. A tool that makes you validate a result takes you out of it.

To fight passivity, I proposed a design harness to our teams: Slicer. It was born after a conversation, fruitful as always, with my colleague Jordan Nourry, managing director at Shodo Studio (they deliver fixed-price projects and are true specialists of agentic work): “At our place, AI asks the questions, humans decide.” Slicer was born from this inspiring sentence. The goal of Slicer? To get people back on the path of mastering the product and the business. The means: a conversational mode where everything is designed so that the AI questions us, and we have to contribute.

Contribute to what? First, to explain what we understood from the initiative or the feature, in our own words, without rereading the ticket, but by talking with a great coach. I played the developer in a hurry who had not read it: the tool did not let me through, and one single word gave me away. I said “subscription” four times in my rephrasing; the PM’s ticket talked about an “expression of interest”. With my word, we would write into the offers repository. With hers, we send an email. It is not the same feature. Slicer forces us to ask ourselves the right questions, and even to practice Domain-Driven Design (DDD), which is so dear to me, without noticing, and without jargon.

Four crucial moments

This harness has four moments:

1. Understand the feature or the initiative.
2. Design the architecture (functional and technical).
3. Slice into value increments, for a good go-to-market and early feedback.
4. Define the Definition of Done tests of each slice, and have them generated.

We have been experimenting with it here and there at my client for about a month, and it will be the subject of the second article.

Stop validating!

The hardest part begins when it works. Because when it works, we stop looking. We validate. We leave the equation without noticing.

So starting tomorrow, let the AI question you (Socratic mode), instead of spending your time reading its proposals and validating them.

The second article details Slicer, the design harness, and its four moments. The third will take one step back: the software factory in an agentic world. To date the thread: Your agent gives you Chronos. It cannot give you Kairos. (August 26, 2026). Keynote first given at Thales on October 1st (early draft 🙂), 2026, and at Naboo on October 6th, 2026.

The scouts never got the memo

Claude Code now spawns sub-agents on its own. Two of them, Explore and Plan, fire constantly: every time the agent looks around the codebase, every time plan mode gathers context.

These two do not load your CLAUDE.md. By design, and no setting changes that. Every other agent, the implementer, the general-purpose sub-agent, your custom reviewer, loads it.

So the agents that write and judge code see your rules. The agents that search the codebase never will.

Rules for builders, not tour guides

Most CLAUDE.md files I have seen, mine included until recently, are guided tours: directory layout, where each module lives, how to run the build. That is content for explorers. And explorers, now delegated to sub-agents, are precisely the ones who will never read it. The implementer, meanwhile, rebuilds that map in a few seconds of grep.

What the implementer and the reviewer cannot rebuild is your judgment: what “done” means here, what a good test looks like, which patterns get refused in review, which invariants must never move. That content has nowhere else to live.

So: what helps an agent act and evaluate goes in CLAUDE.md; what helps it orient itself goes elsewhere. Build and test commands stay, not for the explorer but because producer and judge need to know how to reach green.

Same rule for nested CLAUDE.md files in your modules: local rules, not a local map. What you want an explorer to discover belongs in a README or an ADR. Those are plain files, Explore will find them. And if a rule absolutely must reach Explore, there is exactly one channel: the prompt you give when delegating.

Reason why Anthropic quietly rewrote /init

The original /init generated a map: commands, key directories, detected conventions. The new interactive flow (behind CLAUDE_CODE_NEW_INIT=1) runs on one rule: only include what Claude would get wrong without it. It even ships /init-verifiers, scaffolding skills dedicated to checking changes. Feeding the judges, again.

Time for us to change too

Your CLAUDE.md is not onboarding documentation. It is a contract for those who produce and those who judge.

So, what is in yours that only an explorer should have read?

I’ve been posting a lot about Loop Mode and Graph Mode lately. Framing a choice is not the same as recommending one, so let me be explicit about what I’d actually do today.

Two Modes, Two Bills

1. In Interactive Mode, you stay behind the agent and steer as it goes. What it burns is your context window and your token quota, and it holds your attention.
2. In Loop and Graph Mode, you let go: you define the harness for your loop (or your graph of agents) and the verification criteria up front, then you let it run. What it saves is your attention. What it burns is everything else.

That’s the whole trade. Neither mode is more advanced than the other. They optimize different scarce things.

Where I actually am

Still digging. So far I haven’t found the conditions that make Loop Mode reliable and efficient for me. Three walls, every time.

• The token bill, and it’s the wall I hit first. A loop burns quota at a rate interactive work never comes close to. I’m in the red far more often than I used to be, and I’ve started hitting my weekly limits, not just the daily ones. The quota runs out long before the night does, so the run I set up to work while I sleep stops somewhere around 3am.
• Letting go is not free. A loop only pays off on work that is loop-shaped: a large stock, well specified, mechanically verifiable. Producing that backlog is real work, and today it’s work only a human does. The new job isn’t watching the loop, it’s building the thing the loop can chew on before you go to bed.
• Green doesn’t mean done, let alone done well. On my own runs, three review passes over work the loop had declared finished, green and mutation-tested, still surfaced 45 findings, one of them a release blocker. The blocker is the scary one; the other 44 are the expensive one. A loop that trusts its own verdict compounds the wrong thing overnight.

Last time I wrote that your agent hands you chronos and can never hand you kairos, the moments you have to be present for, and that reviewing is a passive posture: the more you invest in the agent, the more you drift out of the work without anyone ever deciding it. A loop is that posture taken to its limit, since by construction everything reaches you downstream and finished. So a loop spends all of your kairos up front, before you go to bed. Which is exactly why the verification has to be something you built, and never something the loop declares about its own copy.

Put the three together, and the cost/benefit isn’t there yet, for me.

Disclaimer

Occam’s razor: between “the mode isn’t ready” and “I’m holding it wrong”, the second is by far the simpler explanation, and it’s the one I’d bet on today. I’m a few nights and a few days in, on my own repo, with my own harness. So read all of this as a report on my own runs, not as a verdict on Loop Mode.

Nights & Days

By day, I optimize Interactive Mode, or try to. That’s the work that pays now, on real projects, with real teams. At night and on weekends, I explore Loop Mode and Graph Mode. Right now I’m collecting data, not conclusions. The findings, takeaways and learnings from those runs are coming, and that’s the context they’ll arrive in: experiments, not recommendations.

My advice

Secure and optimize Interactive Mode. That’s where the momentum and the leverage are right now, and that’s where most teams still have a lot of easy ground to take: sharper context, a harness that makes a fresh session cheap, verification you actually trust.

Good News

Everything you invest in your harness serves both modes. The harness is the shared asset: it’s what makes Interactive Mode fast today, and it’s the prerequisite for Loop Mode ever paying off at all. There’s no wasted step, and no order to skip.

So: Loop Mode is worth digging into, for what’s coming. It just isn’t where your return is this month. Don’t read my enthusiasm as a suggestion to jump.

Links

• Your agent gives you chronos. It cannot give you kairos.: why speed got cheap and presence did not, and why reviewing is the posture that quietly moves you out of your own work.
• What if /clear was no longer our job?: where Loop Mode and Graph Mode come from. A context boundary can be drawn in time or in space; the two modes are what happens when you stop drawing it by hand.
• Knowing when to capitalize instead of just fixing — the harness-maker’s craft: why the harness is capital and not maintenance, which is the whole reason investing in it is never a wasted step.

TL;DR: AI made almost everyone faster. Effectiveness does not come automatically. When a team loses its grip on the business it is building for, it produces slop, and slop does not only land in the code: it lands in our heads and in our human interactions. The scarce resource is no longer time as a quantity, it is knowing which moments you have to be present for. The Greeks had a word for those moments — kairos.

Chronos is cheap now. Kairos is not.

Chronos is quantitative and linear: hours, sprints, commits, tokens. Kairos is qualitative: the opportune moment, the critical point where acting actually changes the outcome.

Every number your agent improves is chronos. Kairos stays entirely on our side.

A team can be faster and less effective at the same time

Talking with former colleagues and with friends in other companies, I keep hearing the same shape: entire engineering groups where everybody feels fast, and where very little impact comes out at the other end. Full speed, zero distance.

Less mastery of the business, more slop

It shows up even where things are going well. I have been inside one such successful transformation for six months now, in a French SaaS scale-up, and, though they remain a small minority, some teams are starting to struggle more than others. The discriminating factor is not tooling, and it is not talent. It is domain and business awareness. Teams that have less mastery of their business domain mechanically produce more slop, and therefore more rework. It is still incredibly faster than it was before AI, but far less effective than the teams that understand their domain well.

The slop is not only in the code

Slop is mush, and we usually talk about it as mush in the codebase. That is only where it becomes visible.

Very often, the output of AI is verbose, so we skim it. We skim it, so we no longer really understand what we shipped, or why. A weaker understanding produces vaguer framing: vaguer instructions, vaguer acceptance, vaguer decisions. And vaguer framing produces more slop.

When you are inside this loop, nothing looks like a failure. Every day feels productive. It is a treadmill: full speed, but you never move.

Passivity is the number one enemy

Underneath that loop runs a quieter mechanism, and it is the one that worries me most. Reviewing is a passive posture. If your whole contribution becomes reading what the agent produced, its plans, its summaries, its questions, its code, then you have been moved out of the work without anyone ever deciding it.

You are still in the room. You are just no longer in the equation. And the more you invest in the agent, the more systematically it happens: nobody writes you out, you drift out.

Indigestible output makes that drift much faster. A wall of verbose prose does not invite you in, it invites you to nod. Verbosity and passivity feed each other, and we are badly equipped for that fight.

An asymmetric war on slop

Dex Horthy, one of the most generous and clear-headed voices on agentic coding right now, describes himself as fighting “an asymmetric war on slop”. Asymmetric is the important word. Producing a hundred lines of plausible mush now takes seconds. Noticing that those hundred lines solve the wrong problem takes a human being, with context, paying attention.

Where to spend your kairos

The useful question is not “how do I use less AI?”. It is: which moments do I refuse to be absent from? Four answers from the field, and they are certainly not the only ones:

• work on the digestibility of what the AI sends back to you: the shape of its plans, the shape of its explanations, and the shape of the questions it asks you. We set the terms of that exchange and its verbosity, not the tool;
• human workshops with no agent in the room, event storming sessions for instance, whose only purpose is to align our mental models: with the business, and within the team that will steer the machines afterwards;
• product refinement sessions led by people, not by the agent’s questions: everyone states in their own words what they understood and what they did not. It ends only when those who will do the work can explain it back to the team and to the product manager (otherwise: rinse and repeat). It is human-based back-pressure;
• deliberate sessions on the business and the domain, ideally with the team running the demos themselves, which anchors both the knowledge and the engagement. Domain understanding is a performance variable now, not a comfort.

Caution: None of this is a brake!

None of these four slows the machine down. None of them asks you to generate less, or to read more. Go as fast as your agent lets you go in execution: what these 4 protect is the thinking that happens around execution, before it starts, while it runs, and after it lands.

Producing keeps you in the work

Now look at what they have in common. In each one of them you produce something — a shared mental model, a story someone can explain back, a demo you ran yourself, the shape of a plan — you do not review something. Reviewing puts you downstream of the work. Producing keeps you inside it. That is the difference between being present and being kept informed.

And that is why the first of the four, digestibility, is the one worth engineering. The other three cost you meetings; that one costs you a harness. The whole job of a good harness is to make the lucid mode cheap — cheap enough that you still choose it on a Tuesday afternoon, when you are tired and the fast path is right there.

Digestibility

This is the one I want to end on. It sounds like a comfort item, and it is not: a verbose tool quietly eats into your kairos, a little more each day. A user story, a ticket or a plan that is exhausting to read will not be read, and the decision it was meant to inform gets taken blind.

Nodding at a plan you could not restate is not approval. We need to avoid what I call the uh-huh syndrome: the exact moment the slop stops living in the codebase and starts living in your head.

I am not the only one digging here. Dex Horthy’s /show-me skill makes the agent explain itself with concise visuals instead of walls of prose, and it pays most on program design: discussing the shape of the code before the agent writes any of it. That is a kairos, made cheaper to attend. His reasoning was partly inspired by a Coda Hale talk on intuition and attention: analysing information exhausts us, while our visual cortex handles rich images effortlessly. Or, as Coda Hale puts it: software has to fit the human mind the way an axe has to fit the human hand.

Rework is your silent alarm

Nobody is beaten by a lack of speed any more. We are beaten by our own detours. Building the wrong thing quickly is one. Shipping code nobody understands, six months before it has to change, is the most expensive of all, and it shows up on no dashboard this quarter.

So: measure our rework, alongside our business impact. Not to blame anyone, and not as a quality metric. It is the cheapest signal we have, nobody counts it, and it is the one thing that tells us we are running on the treadmill. A rework rate that climbs is rarely a coding problem: it means the moments that decided what to build happened without us.

The machines will keep handing us chronos. They cannot hand us kairos. Measuring our detours is how we notice we stopped spending it.

Slop is speed. Mastery is velocity.

Links

• Dex Horthy, the /show-me skill: “make your agent converse visually instead of in walls of prose”
• ayghri, the i-have-adhd skill: ten rules that make an agent lead with the next action instead of burying it in prose. Its own line: "ADHD-friendly outputs. No ADHD diagnosis needed!"
• Coda Hale, his talk on intuition and attention: why analysing information exhausts us and visuals do not.
• Thomas Pierrain, What if /clear was no longer our job?: episode 3 of Work smaller, ship fewer bugs with AI.
• My two modes today: Interactive to ship, Loop to explore

A few days ago, I joked online: given the time I spend on the harness of my AI agents (the rules, the plans and the written guardrails they re-read at every session), I should change my LinkedIn title to “harness maker” (“bourrelier” in French) — the craftsman who made and fitted the harnesses of draft horses, so that the animal would pull straight. The job of the future, established 1850.

Since then, I have come to believe the joke describes a real craft, and that it fits in one sentence: knowing when to capitalize instead of just fixing.

Three situations I lived through, all in the same weekend, to show the difference.

One thing to know before we start, because everything else follows from it: an agent restarts amnesiac. From one session to the next, it only knows what the files tell it.

Night freight

The incident. I am currently exploring “loop engineering”: framing the work of a coding agent well enough to let it run in a loop, autonomously, including at night. It works alone, cycle after cycle, and each cycle ends by scheduling the next one, like winding up an alarm clock; I review in the morning. One morning, a surprise: the session had stopped at 3 a.m. No crash, no error: the last iteration had simply forgotten to wind the alarm.

The fix. Restart it that same evening (if I had been in front of my screen or my phone). Ten seconds, perfectly legitimate. And nothing prevents the same silent night from happening again next week.

The asset. Three lines carved into the plan (the Markdown file that drives the agent, the one it re-reads at every iteration): “re-arming the alarm is the last action of every iteration”. Cost: three minutes, once. Since then: not one more night lost this way.

That is the whole difference. Fixing is an expense: the value dies with the incident. Capitalizing is an investment: the same incident produces an asset (a rule, a guardrail, an instrument) that pays you back every time the problem does not come back. And the cost is almost the same: in an incident, the expensive part is the diagnosis.

Fixing without capitalizing means buying the diagnosis at full price and throwing away the receipt.

My agent is called Dory

The incident. One morning, my agent asks me a question we had settled the day before. I snap at it: “it is as if you learned nothing and remembered nothing”. Its diagnosis was worth more than my anger: my answer was indeed written in the plan. But the progress summary at the top of the file, three hundred lines above it, still said “decision pending”. A fresh, amnesiac session reads that summary first: the answer was on the disk, and invisible.

The fix. Answer again. Thirty seconds, and the question would have come back at every session.

The asset. Repairing the mechanism itself: the state of a piece of work now lives in one single place, and everything else points to it. Measured gain: resuming work used to require opening eight files, each repeating a piece of the state; it is now one.

Note that this incident was not a breakdown: it was a friction, something you suffer again and again. The best signals for capitalization rarely look like bugs. One guardrail, though: not everything deserves to be capitalized. One question filters: does this failure belong to a class, can it happen again? If not, fix it and move on. Capitalizing on one-off events means building yourself a cathedral of guardrails: an impressive pile of rules, costly to maintain, that protects against accidents that will never happen again, and that ends up slowing down every session. The asset becomes a liability.

Kill the Hydra, not its heads

The incident. A recurring problem (the state of my plans going stale in silence) had already received five mechanisms: a rule, an amendment to the rule, a guardrail (a script that blocks the end of a session until the relevant files have been re-read), an exception to the guardrail, a variant of the exception. And the problem kept coming back.

The fix. A sixth mechanism to prevent the n-th consequence of the root cause, proposed by Claude.

The asset. A study, not a mechanism: I asked the agent to count instead of arguing. The verdict, counted over three weeks of plans: 84% of the progress information was written as free prose, outside the checkboxes and the slots designed for it. My five mechanisms were treating symptoms; the cause was the very format of my plans. Changing it (state now has only two allowed forms, a checkbox or a line in the progress summary; everything else is narrative) made three of the five mechanisms useless.

Notice the progression across the three stories: the first incident produced a rule; the second repaired a structure; the third removed mechanisms by fixing the cause. Capitalizing does not always mean adding something.

3 pitfalls to avoid

This story taught me that capitalization has failures of its own. Three ways to stagnate, worth watching:

1. forgetting the product: the harness gets polished while the thing you have to ship stops moving — the meta-work is comfortable, because in it you are always right;
2. treating symptoms instead of the root cause: failures keep coming back, always from the same class as the ones already covered; each new mechanism covers one more consequence, never the cause;
3. letting the harness ossify: rules whose reason has been forgotten, guardrails that raise false alarms and end up ignored.

A job of the future, established 1850

With a coding agent, incidents happen every day. Two postures: fix as you go, and pay for the same diagnosis again and again; or treat each incident as raw material. The diagnosis is already paid for anyway; the only question is what you buy with it.

Anyone can stitch a broken strap. The harness-maker’s job is to make sure it never breaks the same way twice. This is craft.

Links

• Your agent gives you chronos. It cannot give you kairos. — what AI keeps making cheaper, what it never will, and the one number I would like us to start watching.
• My two modes today: Interactive to ship, Loop to explore