From tokens to product value, after the Insitoo live
With Thomas Pierrain and Vanessa Gossent, I revisit AI costs, hiring, parallel agents and the work we have to redo after delivery.
Jump to summary ↓TL;DR
| Question from the live | What I take from it |
|---|---|
| How do we learn without exhausting the quota? | Start with a bounded need and share attempts, including failed ones |
| What belongs in the harness? | The context, tools, permissions and checks around the agent, with regular maintenance |
| How do we recognise competent AI use? | Observe how someone frames a need, verifies the work and explains decisions |
| Do thirty or forty sessions produce as much value? | I work this way, but I have also lost track and discarded results |
| How should we discuss the gain? | Connect delivery with its product effect and the work that needs doing again |
A shared quota can interrupt everyone’s work
Vanessa’s support team quickly burned through the shared quota while trying the tools. Developers stepped in to help their colleagues. It is one of the cases she describes during our November 5, 2026 Insitoo live with Thomas Pierrain. Their experiments had started blocking other people’s work.
With Damien Cavaillès moderating, we started with three questions: how to learn without burning through tokens, how to recognise someone who handles AI well, and how to tell whether the extra work we produce is useful. The chat also brought us back to terminology, local models and what we should stop delegating.
LinkedIn profiles: Florian Bruniaux · Damien Cavaillès · Thomas Pierrain · Vanessa Gossent
This article follows the discussion and comments, with answers expanded after the live. Articles by Thomas, Vanessa and Olivier Bonnefous take the discussion further. Quotations are translated from French, with punctuation adjusted for reading. The infographics were created for this article.
Vanessa describes their experiment of the week: sharing what people tried, what worked or failed and what it cost. If the feedback stays in a private agent conversation, colleagues may repeat the attempt without learning from it.
I would start by understanding what we use and watching consumption. If a small analysis eats up a large share of the quota, I want to know why before running the same thing again. We still need to work afterwards.
At Thomas’s client, quotas are individual. Someone who exhausts theirs has to wait without blocking the others. How experiments are allocated therefore also depends on the contract. Tokens consumed, quota remaining and money paid tell us different things.
For a team paying per use, the Back Market case describes another arrangement: per-person budgets and provider selection.
Vanessa explains starting with external training, then developing internal workshops on real tasks. That is what interests me about helping people learn: being able to ask a question when work gets stuck, then keeping something useful for the next colleague.
Vanessa and Olivier Bonnefous describe another way of learning in their November 26, 2025 tutorial. They tested the brief in conversation before creating the GPT. They observed managers and shortened the process. Domain expertise helped them choose the questions and decide what to change.
Explain the harness through what it does
In the chat, Laurence Poussard says harness adds confusion. She asks us to talk about context, control, security and the working framework. We can start with what goes into it.
For me, the harness is the working environment around the agent. I provide instructions and references, tools and permissions. I also prepare memory, hooks, scripts triggered at particular points in the work, and verification. On a team project, that extends to CI and observing results.
For a bug fix, this is what I would prepare. I added this example after the live.
| Part of the environment | What I prepare |
|---|---|
| Context | The issue, relevant code and expected business rule |
| Tools | Read and edit the repository, run the relevant tests |
| Permissions | Prepare a correction, with publication requiring separate authorisation |
| Verification | Reproduce the defect, exercise the correction and relevant cases |
| Stop | Ask for help when the need stays ambiguous or attempts stop making progress |

If I prohibit publishing, I want to check that the agent lacks the access to do it while still being able to prepare the correction. A written instruction is not enough. I discuss this at more length in the companion article to my IFTTD conversation.
Thomas reminds us that we already start with the environment supplied by Claude Code, Codex or Copilot. We add what is missing for our work. When the application or model improves, we need to look at what we can remove. A constraint added to fill a gap can eventually get in the way.
I enjoy tinkering with these configurations. That also means accepting that parts should be removed. The number of rules does not tell me whether the need was understood or the correction works.
In their February 27, 2026 account, Vanessa and Olivier describe an assistant inventing details when the brief was incomplete. They separate questions for the manager, recruiter analysis and production. Their prompt instructs it to stop when information is missing. I have not tested how that published instruction behaves.
To understand what the agent proposes, I often return to drawing. As I put it in the conversation, “I’m very diagram-oriented.” I ask how the blocks connect, then have it explain the one I want to challenge. I am trying to recreate the discussion we would have at a whiteboard.
My thirty or forty sessions also produced discarded work
Thomas describes a trap I know well. The agent is working, so we start something else. Then it suggests an improvement, we accept it, and the day fills with things we had not planned to do. Thomas keeps his objective in a small notebook and parks other ideas. He wants to preserve the attention needed to frame the work.
I tend to talk about thirty or forty sessions. I use the image of a chef moving between stations. I do not manage all forty at once. I move from a plan to a check, advancing one subject while another runs. To keep track, Thomas has his notebook and I have my reMarkable.
I have also lost track and thrown the work away. As I say during the conversation, “So I wasted my time and tokens.” Those abandoned results belong in the cost of how I work.
In A good harness makes /clear free, published on August 9, 2026, Thomas addresses another cost of resuming work. He proposes keeping work state in a versioned plan, updated whenever control returns. The conversation can then be replaced. I could try it for resuming my sessions. I have not measured the saving.
Damien asks whether forty agents make me forty times faster. I answer that I do many more things. I put forward a factor of two to four for my production and provoke a little by comparing myself to a squad.
That factor remains my personal assessment. I did not present a comparison of tasks, human effort and quality before and after. It gives us no basis for deciding that a team needs fewer developers. I am not producing forty times more value either.
I also do R&D, experiment and enjoy pushing the tools. On personal projects, I take more liberties than I do at work. That investment is separate from a delivery commitment or the pace we can ask of a colleague.
To work in parallel, I need to know what I expect from each task and what I will have to decide when it returns. Thomas and I described two ways of working. We did not find a number of agents to recommend. I describe the path from sessions to a verified PR in From code to merge.
In hiring, observe decisions during the exercise
Vanessa has changed her recruitment exercise: candidates take it on site and can use an agent. The team observes how they work with it, looking at the need they formulate, task breakdown, verification and ability to explain choices.
She wants to see how the person steers the work. Do they clarify the need before the first prompt? Do they reread, test, reject a proposal and explain why? The final result leaves some of this reasoning invisible.

Thomas stresses what we refuse to let the agent produce. When it works well, we can settle into a rhythm of reading and approving. His warning is specific: “We can deliver an entire feature without ever having described it in our own words.” We have a result without checking that we understood the same need.
He also mentions Slicer during the live. His October 17, 2026 article Back in the equation details the setup: understand, design, slice and define completion criteria. Initially, the agent asks and the person answers in their own words. Discussion with the PM remains part of the process.
I ask for things to be removed from the diff. The agent added a feature, which is nice, but we had not planned it, written the specification or tested it. I ask for it to go into the backlog or a separate branch. I can also ask for something simpler. Having the code already written does not give me a reason to ship it.
Sébastien asks whether AI-friendly hiring assumes candidates are already experts. In a written reply in the comments, Vanessa explains that the test is not looking for “gurus”. She looks at understanding the need, verification and explaining choices. Someone new to AI can demonstrate that approach.
In an interview, I would also ask candidates to show a decision they changed after examining the agent’s work, with the reference they used, their checks and remaining doubts. That is what I would add to this exercise.
Count what needs doing again after delivery
Thomas names three perspectives: output, outcome and rework. What we deliver, what it changes for the product and what needs doing again after delivery. Sales, onboarding, churn and support tickets can tell us about that effect. The choice depends on the problem we want to solve.

Thomas asks whether I measure rework. I mostly respond with costs to track: tokens, CI and deployment retries, then the time spent returning to check. The retry counts I mention are examples. I did not present a comparative record.
To measure this, I would take a category of tasks and keep one record through to the accepted result and its use:
| Perspective | Question to examine |
|---|---|
| Delivery | How long until the accepted result, including waiting? |
| Product effect | Does the user accomplish the intended task better? |
| Rework | What needed correcting after delivery, and why? |
| Full cost | What human effort and expenditure covered all attempts? |
I would keep abandoned attempts in the account, including those before delivery. I would record model and configuration changes when they help explain differences. Otherwise, with different tasks each time, I do not know how much to attribute to the tool.
I have already encountered this problem while measuring my own AI consumption. The tools did not count the same thing. That audit separates observed tokens, API price equivalents and money paid. It does not measure the economic return of all my work.
At Vanessa’s company, product needs to adjust to the delivery pace, support has to update documentation and customer-facing teams have to explain releases. Hiring was deferred. It is resuming to advance the technical roadmap and address accumulated debt. The need for developers has not simply disappeared.
Thomas describes a related trajectory in The hardest part begins when it works, October 11, 2026: bottlenecks move from review to support, then product. He also reports reduced business understanding in some teams. He is describing teams other than Vanessa’s.
When Damien asks whether staffing should be reduced, I talk instead about roles that may change. Product colleagues can contribute to implementation. Experienced developers still have work to do making results reliable and maintaining the checks. Thomas distinguishes a product builder coming from product and a product engineer taking on more product work. He describes one shared development environment, with checks and support adapted to the work being delegated. A new module and the company’s core business domain carry different risks.
I had also prepared cases involving queues and little-used features without discussing all of them on air. I develop them in the article about work that reaches users.
Answers to the chat questions
I wrote these answers after the live, using the discussion and comments, and expanded on the points left open. The chat capture is incomplete, including the end of Vanessa’s reply.
What have you stopped delegating to AI, and why?
Maher Jendoubi
The example I gave was an agent adding a feature we had not planned, specified or tested. I ask for it to be removed from the diff, put in the backlog or moved to a separate branch. The code is already there, but that is not enough to ship it.
I would keep decisions about the need, scope and acceptance with an identified person. The agent can propose changes and prepare a release. Permission to publish is a separate decision. We did not establish a full list of things we had stopped delegating during the live.
How do we prevent people building things disconnected from the product vision?
Simon Chaveneau
I would leave room for experiments, with a known budget and access. Before a prototype becomes a company tool, I would ask which problem it solves, for whom, who accepts the result and who will maintain it.
An idea can remain an experiment, join the backlog or be dropped. If we put it in the product, verification, documentation and maintenance are part of the work. Colleagues need to know whether they are receiving a prototype or something we intend to support.
Does AI-friendly hiring require existing expertise? How do people learn afterwards?
Sébastien Levy
Vanessa explains in the comments that her test is not looking for “gurus”. She looks at whether someone understands the need, checks proposals and explains choices. A critical beginner can receive better feedback than a prompt expert who accepts everything.
She describes colleagues learning together and internal workshops on real tasks. I would add access, quota and someone to ask when work gets stuck. In an interview, I would ask candidates to show a proposal they rejected and what they checked before accepting another one.
For practice on one case from start to finish, my Claude Code learning path and its Proofpack companion project provide configuration, coding and verification exercises.
Is a job addressing technical debt attractive to candidates?
Yann Jahier
It can be, if we explain the work and the means to do it. Vanessa prefers being open about what the role involves. She values candidates asking where things stand and what needs attention.
I would describe a concrete problem, room to make decisions and time reserved for the work. Making a workflow reliable or reducing delivery rework can be appealing if the person can act on it. Promising an overhaul without giving them room to do it risks creating a misunderstanding.
Does running a model locally remove the token problem?
Vincent Royer
Local inference can avoid a provider’s per-request bill. Tokens remain the unit of context and computation. A larger context also needs more memory, as the Ollama documentation explains.
For a comparison, I would use the same task and acceptance criteria, then look at the result, latency, time spent correcting it, hardware cost and maintenance. During the live, we shared experiments, including Vincent’s account of a slow or unstable model. We did not run that comparison.
Does prompt caching save tokens?
Maher Jendoubi
Where the provider supports it, caching can reuse an already processed prefix if it matches exactly. Generation still consumes tokens. The Claude documentation distinguishes cache reads, writes and fresh tokens. On a fixed subscription, saving quota does not necessarily lower the bill.
The comparison of token-reduction mechanisms distinguishes caching from compression and output filtering.
Which harness do you use in practice?
Maher Jendoubi
I start with Claude Code or Codex, then add what I need. For an email, that may mean my style and a few writing rules. On a shared product, the documented Aristote process goes further:
- Context: the need, business rules, architecture and repository conventions.
- Instructions and skills for research, planning, critique, coding and review.
- Tools: code, tests and authorised connections to data or issues.
- Controls: permissions, hooks, tests, static analysis and CI.
- Enough to resume: decisions, plan state and open points.
- Delivery: the examined version, check results and permission to publish.
Access rights and hook activation need checking in the environment being used. Having them in files is not enough. I describe this organisation in the shared context system.
How can “livsh” or OpenCode be used with IntelliJ IDEA?
Vincent Royer
OpenCode can run in IntelliJ’s terminal from the project directory. That is the mode described in its IDE documentation. It does not automatically give OpenCode access to the IDE index.
For a local model, I would first check the inference server, then its provider connection in OpenCode. An MCP server exposing IntelliJ’s index or tools is a separate connection. I would start by reading a file, making a bounded edit and running a test.
The name “livsh” remains unclear, and I could not access the tide repository cited in the chat. I do not have a tested configuration to offer for that particular setup.
How can we tell which agent or task uses a shared quota?
Alexandre Mikulaniec
I would connect each run to a task, client or agent, model and time period. Where the tools allow it, I would add fresh tokens, cache use, attempts and status. Abandoned work and retries stay in the count.
We can then compare that record with the quota and bill. With a subscription, exact allocation by task may remain incomplete. It can still tell us which use needs attention.
I discuss budget ownership in FinOps applied to tokens.
Why say “harness” rather than context, control, security and a working framework?
Laurence Poussard
We can explain it without the word: information given to AI, tools it can use, authorised actions and checks before accepting the work. For a bug, that means expected behaviour, relevant code, tests and a limit on publishing.
I use “harness” for that set of elements. The word names neither a standard nor a security guarantee. If everyone means something different by it, we can start by naming those things.
My guide also separates models, harnesses, instructions and permissions.
What is Thomas’s Kenjaku project?
Maher Jendoubi
Kenjaku is Thomas’s notes-based second brain, with search and sources. Its README separates local retrieval from Claude reasoning in the cloud. Local retrieval therefore does not mean everything stays on the machine. I have not audited the project.
Which tool displays Mermaid diagrams in the terminal?
Florian’s clarification after the live
I was referring to Prismantis, a Claude Code mod that renders coloured tables, syntax-highlighted code and Mermaid diagrams in the terminal.
Guillaume also suggested Termaid in the chat.
It also adds an instruction encouraging diagrams. In Nahum Litvin’s article, the author puts that instruction at roughly 630 tokens per prompt in the version he describes.
I am testing it. I like the rendering, but I do not yet know what effect it has on my token usage.
For examples, my Claude Code diagrams cover context, permissions and multi-agent workflows.
I can describe producing more, but I also need to count discarded work. Before making an organisational decision based on it, I would want to follow what was accepted, used and reworked.
At the end of the conversation, I describe myself as the more impulsive experimenter. I enjoy speeding up, testing and seeing how far things can go. I also need people like Thomas to ask whether I am sure about what I am doing. I can get things wrong, especially when I am already tempted to open the next task.
YSNK
(You should now know)
- A harness can be described through the context, tools, permissions and checks prepared around the agent
- Vanessa’s shared experiments offer an example of collective learning, including when quota becomes a constraint
- My thirty or forty sessions include abandoned results and establish no multiplier of value
- Vanessa’s recruitment exercise observes the candidate’s reasoning, verification and decisions
- Output, outcome and rework pose different questions about delivery, use and the cost of corrections
Go Further in the Claude Code Guide
Practical resources selected to help you take the next step.
Related appearances
Live appearances and podcast episodes about this article.