Watch, Then Do: The Apprenticeship Model for AI Adoption

The fastest way to learn how AI fits into your practice is not a course or a certification. It is watching a specialist do it on your own work, beside you, for a few weeks. Expertise transfers through observation more efficiently than through instruction.

The myth of the self-taught operator

A senior practitioner who has decided AI matters tends to reach, first, for instruction. A course. A certification. A weekend with documentation. The instinct is reasonable: most of the general-purpose tools that ever mattered in professional life — spreadsheets, word processors, citation managers — were learned this way. Once you held the keyboard, you held the tool.

That instinct misfires for domain AI systems. The tools that rewarded direct, individual mastery were standardised across users. The same Excel sits on every desk; the value comes from the user's control over it. A domain AI system is structurally different. It is partly software, partly a corpus of your own material, partly an evolving set of rules about what counts as a good output in your field. No part of that combination is standardised, and no single user is supposed to hold all the controls.

A surgeon does not service the imaging suite personally. The division of labour with biomedical engineering is not a failure of ambition; it is what allows the surgeon to keep being a surgeon. With a domain AI system, the same division applies. Permanent delegation of the infrastructure layer is not a temporary weakness. It is the design.

How professions actually transmit knowledge

Every serious profession transmits its hardest knowledge through apprenticeship, not through textbooks. The senior associate at a Korean law firm does not learn how a senior partner reads a case by reading a manual on how a senior partner reads a case. They sit in on the partner's review, they watch which sentences the partner pauses on, they notice which precedents are dismissed without comment and which are flagged for closer reading. The instruction is mostly implicit. Most of it could not be written down without losing what made it instruction.

Medicine handles its high-stakes knowledge through ward rounds, where a junior watches a senior physician form a working diagnosis in real time. Laboratories do the same: a postdoc learns how a principal investigator reads a Western blot by looking over the shoulder, not by re-reading the protocol. None of these professions believes that watching is a weaker form of learning than reading. The opposite: watching is reserved for the parts of the craft that reading cannot reach.

There is no good reason for AI to be the exception. The hardest parts of working with a domain system — deciding what counts as a clean ingest, where to draw a de-identification rule, when an output is structurally wrong rather than merely stylistically off — are exactly the kind of thing that resists being put into a curriculum.

What “watching” looks like in an AI engagement

In practice, the apprenticeship phase of an engagement is short and concrete. For the first several weeks, the integrator works on the client's actual material, in the client's presence, and narrates the choices being made. We do this deliberately. The point is not to demonstrate that the system works. The point is to expose, in slow motion, what kinds of decisions the system requires.

The senior watching this is not learning to operate the system. They are learning two things. First: where the decision points are. Which document goes into the corpus and which is set aside, which de-identification rule needs a domain-specific exception, which retrieval result is plausible but actually wrong. Second: the standards by which those decisions are evaluated. Which signal indicates a good retrieval, which output pattern suggests the axiom document is missing a constraint, which kind of error is acceptable in a first draft and which is not.

Neither of these can be transferred through a slide deck. They require a real case, in front of a real expert, with the system actually running. That is what the engagement is for in its early weeks. The deliverable of that period is not code. It is a senior practitioner who can now tell a competent output from a flawed one at a glance, and who knows which lever to ask the integrator to pull.

What you learn that no course teaches

The vocabulary a course teaches you — embeddings, retrieval, prompt engineering — is shallow knowledge. It tells you roughly what the parts of the system are called. It does not tell you which output to trust on a given Wednesday. The competence that matters is at the interface between the system and the domain, and it has a different shape:

• Calibration. Which outputs deserve a glance, which deserve a careful read, which deserve to be returned to the integrator with a note that the axiom document needs a new line.
• Failure recognition. The class of plausible-looking outputs that are wrong in a way only an expert in your field would catch. Recognising them on the first reading rather than the third.
• Knowing when to ask for a second opinion. From a colleague, from the integrator, from a re-run with a different retrieval. This judgement is not in any documentation.

The clients who acquire this judgement fastest are not the ones who learn to code. They are the ones who treat the first two months of an engagement as a seat at the work, and protect that seat from being eaten by other meetings. The senior who shows up for the apprenticeship is the senior who, six months later, runs the system rather than the other way round.

Where the apprenticeship ends — and yours begins

The apprenticeship is finite. At a certain point, usually three to five months in, the senior takes over the judgement layer of the system completely. They decide which outputs pass review. They propose new axioms when a class of errors recurs. They direct which corpora are expanded, which workflows are absorbed by the system, which remain manual. The integrator continues to run the infrastructure layer — the retrieval pipelines, the embedding refreshes, the model updates — but no longer participates in domain judgement.

This is the answer to the worry that haunts senior practitioners considering an engagement of this kind: that delegating infrastructure means becoming dependent. It does not. Dependence would be a system where you cannot tell whether the output is right. What we are describing is the opposite: a system where the standards of correctness live with you, are enforced by you, and evolve at your direction. The infrastructure work that surrounds that judgement is permanently somebody else's job, and that is the point.

Watching is the path into that arrangement. Doing — the kind of doing that matters at your level — is what comes after.