Idea

Handing an ancillary task to a tooled system shifts the work towards framing and supervision

Info

Originally written in French. Translated by AI — the meaning has been preserved, not the prose.

Main idea

An intelligence system built with Claude Code collects videos, articles and newsletters, translates them, classifies them, archives them and keeps them current. What a Product Manager used to do for hours happens without him. But the work doesn't fall to zero: it changes nature.

You have to say what you're looking for and what you rule out, check that the system hasn't silently missed a source, review what it produced, test after every change, and take back the wheel when it gets something badly wrong — which happens, sometimes right after it has done something brilliant.

The balance stays largely favorable, but it counts in nature of work as much as in hours: you trade a long, predictable execution for a short, irregular supervision.

Layer added by "Quality belongs to those who ship" (2026-06-03). The same shift shows up in the QA job, and takes a sharper form there. What leaves is repetitive execution: manual tests replayed, regressions redone screen by screen at every release. What remains is framing — defining what to verify, against which risks, with which criteria and at which level of automation. The shift is therefore not only quantitative: it changes the function's position in the chain, since framing has to be written before the code exists whereas execution could only come after.

Layer added by "Four Days of Vibe Coding as a Rusty PM" (2026-07-28). The shift takes a third form when what is delegated is no longer an ancillary task but the building itself. More than one hundred and eighty commits in four days, without writing a line: what remains is steering, reviewing, testing, correcting, deciding, reworking, monitoring, re-explaining. The load doesn't drop, it changes rhythm — instead of a long, steady execution, a continuous supervision paced by the tool's speed. This is the part missing from euphoric accounts: the power isn't free, and whoever steers becomes at once proximity architect, tester, reviewer and guardrail.

Why it matters

This avoids two symmetrical errors when assessing an automation: counting the gain as if the task disappeared entirely, and concluding it changed nothing because something remains.

It also says which skill becomes necessary: knowing how to frame a request and spot a wrong output, rather than knowing how to execute the task quickly.

Nuances and limits

Supervision is irregular, and therefore badly estimated: it costs almost nothing for weeks, then a lot the day a wrong output goes unnoticed and serves as the basis for a decision.

And it can't be delegated to someone who has never done the task by hand: recognizing an intelligence report that missed the essentials assumes you know what a correct one looks like.

Open questions

  • Which signals reveal that an automated output is wrong, precisely when you have stopped producing the material yourself?