Taken one by one, none of them is new. Augmentation over automation goes back to the 1950s, systems thinking to the 1960s, knowledge as an asset to the 1990s. What is mine is not the idea: it is executing all three together, and writing down how.
The target is the craft, not the process.
Open any consulting AI roadmap and the sequence is the same: map the processes, pick high-value use cases, automate, count the savings. That reflex is old. In 1990 Michael Hammer was already writing "don't automate, obliterate" - and reengineering ended up delivering headcount cuts rather than the promised performance. He later conceded he had underestimated the human dimension.
Human-first moves the target. Transformation applies to the craft of experts and leaders - deciding, arbitrating, negotiating, designing, convincing - not to the company's processes. That craft rests on tacit knowledge: we know more than we can tell. It is exactly what rule-based automation never reached, and it is where the value sits.
Automation still happens. It shows up as a consequence: manual checks and reconciliations start to disappear on their own, without ever having been the objective.
The honest objection: measured on generic copilots, AI lifts novices far more than seasoned experts. Which is why the work is not to hand out a copilot. It is to capture how the best operate, amplify it for them, and spread it across the team.
The whole value chain, from day one.
95% of organizations report no measurable return from their generative AI deployments (MIT, 2025). The usual explanations - data, skills, governance - miss the root cause, which is methodological: the use case.
Value sits in the connections between steps, not in the fragments. Optimise each part in isolation and the whole does not improve - a principle as old as systems thinking. Split a transformation into independent use cases and you get pilots that work at home and produce nothing at company scale, because the value was in what you left out: the links.
End-to-end-first refuses both cuts, the functional one (a portfolio of use cases) and the operational one (a minimal product you grow). The complete scope is thought and built from the start, then converted progressively along the chain. What made cutting necessary was cost: you could not afford to build the whole thing. AI as a build tool removes that constraint.
This is not big bang - very large all-at-once programmes succeed about 6% of the time. Scope is total immediately; delivery stays incremental, and moves towards continuous.
The application is replaceable. The knowledge is not.
The durable deliverable is not the platform or the copilot. It is the business knowledge captured and structured while building it. Knowledge management promised this in the 1990s and failed, for one reason: nobody codifies. Writing down what you know takes time, pays nothing, and gives away power.
AI collapses the cost of capture. Knowledge is no longer written by the expert: it is picked up in the flow of the work - decisions, trade-offs, interactions - in natural language, with no form and no taxonomy. And the implicit part comes out when the expert reacts to something concrete: put a prototype in front of them and they reveal the rule, the exception, the arbitration.
Once that knowledge exists as a structured asset, the application becomes interchangeable. You can unplug it, connect another intelligence, and rebuild the full experience in days.
Captured knowledge is only an asset once it is grounded in verifiable sources and validated by the expert. Specialised AI tools still get it wrong in a significant share of cases. Ungrounded, unvalidated knowledge is a hidden liability.
Each principle is developed in a long-form article, published on LinkedIn, in French: Human-first, End-to-end-first, Knowledge-first.
The founding shift: with today's tools you can aim very early for a solution that executes in a real environment, on real, connected data, instead of going through long specification cycles. You no longer describe a need for someone else to build. You build, and you make it react. Everything below follows from that.
Framing builds a box you then have to work inside. Immersion goes the other way: weak signals first - recurring irritants, real usage and the workarounds, data already available - from which a value proposition is derived. Then contact with the craft itself. Use cases are identified, and accepted as provisional: some will be wrong the next day. That is a feature of the method, not a defect.
A prototype and a pilot are built in parallel on short increments, around three weeks, slightly offset. The prototype runs on stubs and pseudo-real data: it reassures, and lets business users check that the target is right. The pilot is the same thing converted to a real environment - connected, real data, usable. They are not two sequential phases; they converge at delivery.
The minimal frame imposed on a vibe-coding environment: enough structure not to compromise the move into production, not enough to block experimentation. Three things to describe, and no more: execution environment, packaging and deployment, integration interfaces. Its cost never appears while building - it appears brutally on the day you have to reach the real environment. So it goes in on day one.
Once building stops being the constraint, the limiting factor becomes data integration and release to production - and those are human and organisational subjects, not technical ones. The time lost is spent finding who holds the data and under which protocol. A rigorous release process is a quality, but it is designed to operate an application, not to experiment with one: lowering the requirement does not make it faster. Connect production from the start, and consider a release path dedicated to experimentation.
The central deliverable. Business knowledge captured and structured, with a target: a specialised agent that holds the knowledge, rules, data and methods of one domain, and assists the teams and the experts themselves. How it gets built: record everything, store it properly, retro-document only when needed, then exploit that corpus with AI - vault, vectorisation, graphs. A classic agile cycle, which formalises a specification up front, works against this: it would remove the point of collecting knowledge continuously.
An AI Product Builder, who prototypes in depth and goes down to the smallest detail - the particular rule, the display convention, the edge case. An AI Delivery Builder, focused on end-to-end, integration and interaction, who makes the object live and connected. Both share the same base: product owner and vibe coder. One person can hold both. The third role, AI Programme Direction, is different in nature and does not merge: it keeps the whole ecosystem coherent and keeps re-injecting altitude.
The standard objection to end-to-end is that a use case has an isolable return and a whole chain does not. The isolable figure is precise, and usually measures a pilot that will never scale. The discipline sits elsewhere.
The first predictor of a demonstrable return is not the size of the model. It is whether the zero state of the complete craft was documented before anything was deployed. Without a baseline, no ROI is provable. With one, end-to-end becomes measurable.
The effects that count only show up end-to-end: a whole step that disappears, a cycle that goes from weeks to days, teams released from a manual reconciliation. An isolated use case does not produce them, so it never measures them.
Under a frozen budget, the workable lever is not a single cheque against a promise. The savings from the first increments fund the next ones. It keeps the programme honest and the sponsor free.
Internal gains are structurally harder to isolate than a supplier's invoice - released time is not monetised. And accounting rules keep internally generated knowledge off the balance sheet: its value is real and quantifiable otherwise, through avoided rebuild cost, retained expertise and reduced vendor dependency, but it is a strategic asset, not a P&L line. Saying so is part of the argument.
The list I go through when a programme starts. Nothing here is optional, and none of it costs anything at that stage - the cost comes from discovering these points at deployment.
Everything above describes how to run one programme. Turning it into a capability of the organisation means replicating the approach past the first success, with multidisciplinary business, product and tech teams - and one shared layer underneath.
Explore and initiate: irritants and opportunities, existing usage, available data, fast internal prototypes, value estimated before going further.
Industrialise: turn high-value usage into robust solutions, connect them to the data platform and the IT landscape, structure reusable standards and components.
Operate and evolve: supervise usage and output quality, measure business impact, adjust workflows over time, hold governance, compliance and cost.
The shared layer is what stops every project from starting from zero: reusable resources and components, standards and playbooks, business AI relays who spread the practice and feed it back, transverse governance, and continuous capitalisation. It is built alongside the first projects, not after them. And it only holds if the internal teams learn the practice themselves - the point is that they own the knowledge asset, starting with the digital twin of their craft.