Someone on my team asked me recently where business intelligence goes when most of its work can be automated. They had already worked out the premise. When a dashboard that took two weeks takes an afternoon, and soon a sentence, the value stops living in the dashboard. If your job description is a list of artifacts, that’s a reasonable thing to lose sleep over.

My answer was that the field is about to grow, by a lot. Business intelligence moves from reporting to understanding, at a fundamental level, how the business works and how leadership’s strategy shapes its outcomes. That has no ceiling. We will need far more people creating understanding than we ever needed producing calculations on a report.

That answer sounds like the thing a manager says to keep people calm, so it needs defending. And the question is bigger than BI. Swap in a junior lawyer and a research memo, an accountant and a variance analysis, a consultant and a deck, a marketer and a campaign brief. It’s the same question, and almost nobody is answering it for them.

The conversation has been about code

Nearly everything written about AI and the future of work is written about software developers. That makes sense as a starting point. Developers adopted these tools first and hardest. In Anthropic’s January 2026 Economic Index, computer and mathematical tasks made up about a third of Claude.ai conversations, against 15% for education. The commentary follows the usage.

The software conversation has also produced some sharp thinking. Camille Fournier’s The Manager’s Path in the Age of AI puts the shift in four words: “Nowadays? Code is cheap.” When code was expensive, working code was evidence that someone had thought hard about the problem. Cheap code stops being evidence of anything, and what becomes scarce is alignment between the people doing the building.

Replace “code” with any other knowledge-work artifact and the sentence still holds. A contract draft, a financial model, and a forty-slide deck with a clean storyline are all cheap now. Most of the people producing those things don’t have a Fournier writing about their profession, and they’re working out the answer on their own, usually by watching the tool do in ten minutes what used to fill their Tuesday.

A job description is a list of artifacts

Knowledge work has always defined itself by what it hands over. Lawyers produce memos, opinions, and agreements, and accountants produce statements and reconciliations. Consultants hand over decks, analysts hand over reports, and HR hands over policies and job descriptions. Those are the things that get billed, reviewed, filed, and counted. Ask someone in any of those roles what they did this week, and they’ll answer with a list of documents.

The artifact became the unit of work because it was expensive. It took real hours, and you couldn’t produce one without doing the thinking behind it, so the artifact stood in for the thinking. I wrote earlier this year about what that did to hiring: every résumé and portfolio reads output and infers the judgment behind it, and that inference stopped holding once output got cheap.

The same substitution runs through the rest of working life. We plan, staff, and price work in artifacts. So when the artifact gets cheap, the instinct is to conclude the job got smaller. That conclusion only holds if the artifact was the purpose of the work, and in most knowledge work the artifact was the bottleneck.

The queue was the ceiling

Every knowledge-work function runs a queue. In BI, a request means modelling data, writing measures, building visuals, and reconciling totals against what finance already reports. That takes weeks, so teams ration. They build what was asked for and rarely reach the question behind the request: why margin slipped after a pricing change, or whether the strategy leadership announced in January shows up anywhere in the data by June.

Other functions have the same shape with different nouns. A legal team answers the question the client asked, because answering the question behind it would take another forty hours nobody approved. A finance team spends the first part of every month closing the books and much of the rest explaining last month, so the analysis that would change next quarter waits. Production cost has set the limit on how far anyone could go into the substance of their own profession.

Remove that cost and the limit moves. It moves to how well people understand the system they work in, and that limit has no top. There is always another layer, whether it’s which levers move which outcomes or how a client’s commercial position shapes the risk they should accept. The deepest is how a decision made in a leadership meeting travels through operations until it shows up, or fails to, in a quarter’s results.

History has run this experiment before. Spreadsheets took the arithmetic out of accounting, and the US still projects the profession to grow. The Bureau of Labor Statistics expects accountants and auditors to grow 5% between 2025 and 2035, while bookkeeping and accounting clerks shrink 6%. It expects the clerks who remain to shift “toward analysis and advisory roles.” ATMs are the other well-worn example. James Bessen found that tellers per urban branch fell from 20 to 13 between 1988 and 2004. Branches got cheaper to run, banks opened 43% more of them, and teller jobs did not decrease as ATMs rolled out. The work moved from counting cash to selling and serving customers.

David Autor gave the reason in a 2024 NBER paper: information “is merely an input into a more consequential economic function, decision-making.” The artifact is information. The decision was always the point.

What fills the space

Some of the best evidence on what happens when you hand knowledge workers these tools comes from outside software, and it gets less attention than the coding studies.

Noy and Zhang gave 453 marketers, grant writers, consultants, data analysts, HR professionals, and managers realistic writing tasks. With ChatGPT, time fell 40% and rated quality rose 18%. Nobody fact-checked the outputs, so read the quality number generously, but the speed result has held up across study after study.

The BCG study is more useful, because it found the edge. In Navigating the Jagged Technological Frontier, 758 consultants worked on realistic tasks with and without GPT-4. On tasks inside the model’s capability, consultants with AI completed 12% more tasks, 25% faster, at more than 40% higher quality. On one task deliberately set just outside it, consultants with AI were 19 percentage points less likely to get the right answer than those without. On a problem the tool couldn’t solve, using it made them worse.

That result describes the new job better than any framework I could draw. The work that grows is knowing where the frontier is for your own domain. You can only know that if you understand the domain well enough to tell a plausible answer from a correct one, which is the understanding the queue never left time to build.

People are already spending the capacity on scope. In Anthropic’s June 2026 survey, 82% of respondents said AI had widened the scope of what they could do, close to the 86% who reported speed gains. Microsoft’s 2026 Work Trend Index found 58% of AI users producing work they couldn’t produce a year ago. A study of P&G professionals, The Cybernetic Teammate, found individuals with AI matched the performance of teams without it. R&D and commercial staff with AI also produced more balanced solutions, where without it each leaned toward its own department. People are reaching past their old boundaries. That’s what a raised ceiling looks like in practice.

The knowledge nobody wrote down

There’s a second kind of work hiding in this shift.

Organizations run on knowledge that was never written down. Autor called the general version Polanyi’s paradox, after Michael Polanyi’s line that “we know more than we can tell.” Inside a firm it looks mundane. Finance knows March always looks bad and why. A senior lawyer knows which clauses a particular client will fight and which they’ll accept without comment. The BI team knows which of three revenue figures leadership steers by. None of it lives in a system, so none of it is available to an AI.

The legal research shows why this matters. In a 2025 study by Schwarcz and colleagues, law students worked through legal tasks with either a reasoning model or a retrieval tool built on legal sources. Both improved the quality of the work, which earlier GPT-4 studies hadn’t found. The reasoning model also introduced some hallucinations. The retrieval tool, which answered from documents, didn’t. The difference is a model answering from memory against a model answering from the record.

An AI can only read what someone has written down. So a large share of the new work is making the organization legible: writing down how the business behaves, in a form a machine can read and a person can correct.

The platforms are already building for this. Microsoft describes its Fabric IQ ontology, still in preview, as “a shared, machine-understandable representation of your business.” It can be generated from the Power BI semantic models analysts have spent years building, so that agents “use the organization’s defined calculations rather than recreating them.” Microsoft’s Work Trend Index gives the general idea a name, “owned intelligence,” meaning the institutional know-how that compounds over time. In law, it’s the clause library with the firm’s actual negotiating positions and the reasons behind them. In finance, it’s the close procedure with the judgment calls written in.

I think of this as a true semantic layer of knowledge that AI can feed on. Consistent definitions are the start. The rest is a written model of how the organization works, kept current, that every agent reads from. That work never finishes, because the business keeps changing, and it can’t be done by anyone who doesn’t understand the business. AI can draft the layer. Checking the draft against how the business behaves takes the people who have spent years living inside it.

Where the optimism breaks

The growth has a shape, and it isn’t kind to everyone.

Stanford’s Digital Economy Lab has been tracking payroll data for workers in AI-exposed occupations. Its August 2026 revision found employment for 22- to 25-year-olds in the most exposed jobs about 19% below where it would otherwise be, driven by less hiring rather than layoffs. Employment fell where AI automates the work and held flat or rose where it augments it, especially for experienced people. The authors call the findings descriptive, not causal, but the pattern matches what BLS projects for the support layer. Paralegals are projected at 0% growth to 2035, with BLS naming AI as a limit on demand. Even the ATM story has an ending: the World Economic Forum’s 2025 Future of Jobs report lists bank tellers among the fastest-declining roles. The precedent held for a few decades and then didn’t.

The studies show the same split at the level of skill. In the customer support study by Brynjolfsson, Li, and Raymond, AI raised productivity 15% on average, with the largest gains for novices and little effect on top performers. Law students in Choi and Schwarcz’s experiment showed the same pattern: the weakest gained the most, and the strongest got slightly worse. AI compresses the skill premium on producing the artifact. That’s good for anyone who struggled to produce one, and it removes the gap that used to tell a promotion committee who was good.

The harder problem is how people learn. In most professions, producing artifacts is how people came to understand the work. Junior associates learn the law by drafting the memo a partner will rewrite. Junior analysts learn the business by reconciling numbers that won’t tie. The tedium did the teaching. In Thomson Reuters’ 2026 Future of Professionals report, 48% of respondents worried about AI’s effect on developing judgment, and 71% said juniors need structured mentoring. In law, the billable hour makes it worse, because the firm has every incentive to keep that work slow.

Autor and Thompson’s paper on expertise gives the rule for sorting this out. Whether automation helps the people who remain depends on whether it removes tasks that need little expertise or tasks that need a lot. Where it removed the inexpert tasks, wages rose and employment fell. Most knowledge-work artifacts sit in the middle: expert enough to have taught people, routine enough for a model to produce.

So the honest version of my answer has conditions attached. The work grows, but the old way into it narrows, and teams will have to design a new way in on purpose. My candidate is a first year spent explaining variances, deal outcomes, and campaign results to the people whose decisions caused them. And freed time doesn’t turn into understanding on its own. The same Thomson Reuters report found 91% of professionals describing a gap between their AI use and the value it delivers. Those working under a named AI strategy were three times as likely to say it met expectations, 66% against 22%. Capacity goes where the organization points it, and most organizations haven’t pointed it anywhere.

Direction stays with people

The ceiling stays high for one more reason. An AI working from a well-built semantic layer can explain what happened and, increasingly, why. Deciding what the organization should want next means placing a bet and answering for it. Fournier borrows the old IBM line for this: “Machines cannot be held accountable, so they cannot make management decisions.”

The people using these tools already sense where the line sits. In Microsoft’s 2026 survey, half ranked quality control of AI output as the most important human skill, and 86% said they stay responsible for the thinking. Microsoft also found that organizational factors explained twice as much of AI’s impact as individual ones, while only 26% of respondents said their leadership was aligned on AI. Direction is the scarce input, and by that measure most leadership teams haven’t settled on one.

That’s where the understanding work pays off. Strategy is a set of bets about what will matter. Knowledge workers who understand how the business works can show leadership how its last bets played out and what the next ones would have to overcome. A lawyer who understands a client’s business can tell them which risk is worth taking, which is worth more to them than a longer memo. An accountant who understands the operation can say which cost will move if the plan changes. The same holds for a marketer deciding which campaign not to run, or an HR lead deciding which role to create before anyone writes the job description. All of that was possible before, but it was rationed, because the people who could do it were busy producing the artifact someone had asked for in the meantime.

AI can widen the options, test them against the knowledge the organization has written down, and do the production once a choice is made. Choosing what the organization is for, and answering for the choice, is the core of the job, and it was the core of the job before any of this started.

For most of the history of knowledge work, the artifact was the only part of the job anyone could see. Now it’s the part that needs us least.

If you lead a team outside software and you’re working through the same question, reply and tell me how you’re answering it. If you’d like the next essay, subscribe to AndrewLewisWasHere.

The most important sentence in a recent Harvard study of AI tutoring sits in its discussion section, well after the results: “AI chatbots are generally designed to be helpful, not to promote learning.”

The results are what got attention. In an introductory physics course in the fall of 2023, 194 students each learned one lesson from an AI tutor at home and another in an active-learning classroom, the kind of well-run, hands-on class that education research already rates highly. With the tutor, the median student’s gain from pre-test to post-test was more than double the gain in class. They took less time, a median of 49 minutes against a 60-minute lesson, and they reported feeling more engaged.

The sentence explains why. The tutor worked because its builders made it less helpful.

What the builders took away

The team published their instructions to the tutor, and most of them are restrictions. Keep responses brief. Give away only one step at a time. Never give the full solution in a single message. If the student asks for the answer straight away, encourage them to try first. Confirm a right answer, but don’t supply one unless the student insists.

Each problem also came with a step-by-step solution the instructors had written, fed to the tutor so its explanations stayed accurate. And the team found the prompt alone couldn’t keep the tutor in order on multi-part problems, so their platform showed students one part at a time.

Everything in that list pushes against what a chatbot does by default. A general assistant is tuned to resolve your request as completely as it can, as fast as it can. For most work that’s exactly right. For learning, it removes the part that does the teaching, which is you struggling toward the answer.

The same model, both ways

A second trial published the same month shows what the default costs. About a thousand high school students in Turkey practised math with GPT-4. One group used a standard ChatGPT interface. Another used a version with teacher-written hints and instructions not to give answers away.

On practice problems, with the AI in hand, the standard group improved 48% and the tutor group 127%. Then the AI was taken away for the exam. Students who had practised with standard ChatGPT scored 17% lower than classmates who never had it. The tutor group showed no significant difference.

Both groups had the same model. The version that did the work left its students worse at the work, while the version that made them do it cost them nothing on the exam. The researchers put it in their title: generative AI without guardrails can harm learning.

The setting that matters most for learning is how much the AI refuses to do.

What this asks of someone learning alone

When I read the Harvard paper, my first reaction was that it needs to be generalized. Even if a tutor like this only matched a good class, it would still be huge, because it doesn’t need a classroom. It works wherever you are, whenever you have an hour, and at your own pace. The study found the pace mattered too. Students who found the class too fast took longer with the tutor, and the ones who found it too slow finished sooner.

Getting there alone means supplying what Harvard’s instructors supplied.

The restrictions are the easy part, because a prompt carries them. The built-in study modes in ChatGPT, Claude, and Gemini now offer similar behaviour, too.

The answer key is harder. A tutor with no key falls back on whatever it remembers, and it’s as confident when it’s wrong as when it’s right. At home, the key has to come from a source you trust, such as a textbook chapter, official documentation, or the text of a standard, with the AI building problems and solutions from that source rather than from memory. If you let an AI gather the source as well, you’ve handed it both halves of the job the instructors did, and you should trust the result accordingly.

The structure falls to you. When the tutor jumps ahead or starts solving, you’re the one who says “one step only.”

And the honour system matters more than it sounds. If you build a lesson with an answer key and then read the key, you’ve turned studying back into rereading, one of the weakest techniques in the research.

What the trials don’t show

Both studies are short. The Harvard post-test came right after each lesson, so it says nothing about what students remembered a month later. The Turkish study measured one exam. Neither followed anyone for long.

The Harvard sample was one course at one elite university, covering two topics, and a reporter who covered the preprint noted that the sessions were scheduled and proctored over Zoom. Students studying unsupervised at home might engage less. The authors themselves say the approach suits first contact with material that has right answers, and they don’t claim it beats a class for complex synthesis or judgement. They argue against replacing in-person teaching with it.

Nobody has tested a do-it-yourself version against their setup, either. A prompt pack can borrow the design, and whether it earns the same result is an open question.

The gap I’d close first is memory. Testing yourself a day later and again a week later costs a few minutes, and practice testing is one of the few study techniques a major review rated highly. It’s also the only way to find out whether the hour stuck.

The part people will skip

The hardest instruction in the whole setup applies to the learner. The tutor holds back the answer, but you can always ask for it, and it will eventually give in, just as the Harvard prompt allowed.

Every tool in this category is one sentence away from turning back into the helpful assistant it was built to be. The design only holds if the person using it wants the struggle more than the shortcut. That was true of good tutors long before AI, and it’s the one ingredient no prompt can supply.

Given generative AI, 26,811 Chinese secondary students raised their homework scores by 18% and lost as much as 24% on the exams that decide their futures.

That’s the headline from a study that tracked the students for thirty months. The AI users also finished their homework 30% faster. Within six months their monthly exam scores had dropped 20%, and the high-stakes entrance exams fell 18% and 24%, with the full penalty taking about two years to show. Benjamin Riley, who dug into the data, gave it a name in August: the 50 Percent Problem. By his reading, about half the students who started using AI had fully outsourced their homework within five months.

The paper is a working paper and hasn’t been through peer review yet. Even so, the pattern it describes is one I read about constantly: a spike in usage, then a flat line in anything that matters.

The easy conclusion is that AI makes people dumber, so the answer is less of it. Ban it in schools. Ration it at work. Or go the other way and send everyone on a course to learn the tools properly.

A detail further down the abstract complicates both answers. The losses were concentrated in the students whose behaviour looked like outsourcing. Students who kept spending about as much time on their homework as non-users saw only small losses. They had the same tool and the same access. What they kept was the thinking.

The answer that looks finished

The name I’ve settled on for what went wrong is the clockwork mind. It’s the belief that thinking produces one perfect answer, the way a clock produces the time, and that once you have it you’re done.

AI feeds that belief beautifully. Its answers arrive formatted, confident, and complete. Nothing about a polished paragraph tells you it’s the first draft of a thought. It looks like the thing a clock would give you.

The pull is always there for me, gnawing at the edges of the work: a desire to take whatever the model hands back, copy it, paste it, and skip the verification. The easy way is to accept what it presents. The first answer looks good enough, and it’s right there.

For the students, homework was where the thinking happened, and the finished homework was only evidence of it. AI let them produce the evidence without the thinking, and the exam was where the difference showed. Adults at work rarely sit an exam. The equivalent turns up as a strategy that fails, long after everyone committed to it.

Where the pull costs the most

I don’t resist the pull equally everywhere, and I don’t think anyone should.

Tactics are short term. A code change, a research summary, a draft email: if the AI gets it wrong, I find out quickly and change it cheaply. Letting a model do that work fast is a good trade, and pretending otherwise turns every small task into a seminar.

Strategy is different, because tactics are built on top of it. Stephen Covey popularized a line about climbing the ladder of success only to find it leaning against the wrong wall. That’s the failure I worry about: going a long way down the road of an AI-generated strategy and discovering I’ve spent the time and money on something a few better questions would have caught.

Research on BCG consultants shows why the stakes should decide. Given GPT-4 in 2023, consultants completed 12% more tasks, 25% faster, at over 40% higher quality on the tasks the model handled well. On a task it handled badly, the same consultants were 19 percentage points less likely to reach the right answer than colleagues working without it. The model didn’t flag which task was which. It sounded equally sure both times.

So the rule I use is simple. The risk associated with the decision should set the intensity of the thought. A cheap, reversible decision can move at the model’s speed. The expensive ones get my own thinking first, with the AI in the room as a sparring partner.

A direction to walk in

My process isn’t exotic. I provide sources, ask, iterate, and refine, the same as everyone else. The part that matters is what I ask once the first answer is on the screen. The questions I lean on each ask the AI to show me something I haven’t seen yet:

• What am I missing?

• What would someone who disagrees with me say?

• What question haven’t I asked?

• Are there alternatives?

Think of the list as a compass. It gives you a direction and leaves the terrain to you, which is the honest position when you’re working somewhere new.

The harder skill is knowing when to stop. The clockwork mind stops at the first finished-looking answer. The rest of us are exploring unknown territory, and there’s no finished answer out there to find. What you’re looking for is somewhere the ground is solid enough to stand on, even if it isn’t perfect or complete, and that you can call yours.

Plenty of people stop for a different reason. Think of two students with the same assignment. One keeps going until they’re tired and doesn’t want to do any more. The other keeps going until they’ve arrived somewhere they couldn’t have reached at the start. From the outside, both handed in the work. Only one of them learned anything.

Is this just theatre?

The best objection to all of this is that it’s cognitive theatre. You ask the model what you’re missing, it tells you, and you nod. You’ve repeated the AI’s words with more steps and called it thinking.

Some of that has to be conceded. The words often do come from the machine. And a survey of 319 knowledge workers by Microsoft Research and Carnegie Mellon found that the more people trusted the AI, the less critical thinking they reported doing. The ones who trusted their own judgement more did more of it. The objection describes something that happens.

Where it goes too far is in assuming human ideas come from somewhere purer. The “stochastic parrot” critique of language models says they stitch together patterns without meaning behind them. Humans are the wetware version of the same thing: our ideas also came from somewhere, from books and arguments and people we worked with. That doesn’t make them gibberish. The measure that matters is whether the answer got better and whether the person asking got sharper.

The test I hold myself to is ownership. I should be in control of the ideas, able to defend them, and confident I could have arrived there on my own. The AI is a reasoning partner that gets me there faster and makes the iterations cheaper, so it becomes clearer where the value is.

I can’t prove I’d have got there alone, and nobody can. Once you’ve taken the fast route, you can’t go back and walk the slow one to compare. Ownership is something you keep checking, and part of the work is noticing when you’ve stopped.

The students who kept their homework hours had exactly the same tool as the ones who fell behind. Nobody could see the difference on the homework itself. It showed up two years later, on the exam that counted, and by then it was a long way to walk back.

That’s the version worth building toward: AI that makes us better, not AI as a substitute for hard work.

If this was useful, subscribe to AndrewLewisWasHere for more on the work behind the work.

Two questions have worked their way into every engineering manager interview I run. Early in the conversation I ask whether humans should write code. Later, if the conversation gets there, I ask whether humans should read code that AI wrote.

Candidates often laugh, or at least smile, while they think about it. The role has been open for a while (I wrote about losing two finalists in August), so I have heard a fair number of answers. The consensus, when there is one, is “less and less.” Fewer humans writing code, and fewer humans reading it.

I don’t grade the answers. A candidate who says humans should never write another line of code and a candidate who says we’ll be reading every diff for the next decade can both pass. The question is there to show me how someone reasons about the thing their team is about to become, and a small development team inside a company that doesn’t sell software is about to become something quite different.

Two jobs under one title

Underneath the answers I keep hearing the same split, even when nobody states it outright. Software engineering has always been two jobs sharing one title. One job is owning a problem: understanding what the business needs, deciding what should exist, and being accountable for whether it works. The other job is translating the chosen solution into code. For most of the history of the profession, the second job consumed most of the hours, so it came to stand for the whole thing.

AI does the translation now, and in a lot of cases it does it better than people do. That makes writing the easier of the two to let go of.

Reading is harder. The argument for reading is familiar to anyone who follows this debate online: AI isn’t always good at this, so reading the code is where human verification happens and where the trust lives, and you can’t understand software whose code you haven’t read. My own view is less charitable. I think a lot of programmers hold on to the pull request and the code review because it is the last point where they can keep control of the work. That is an understandable instinct, and I’m not sure it is the right one.

AI doesn’t write perfect code. Neither did we. Generations of programmers wrote sloppy code, and that sloppy code is where most of the bugs in the world came from. The case for reading AI code can’t rest on the idea that human-written code was a trustworthy baseline, because it never was.

A prototype arrives at IT

The interview questions would be academic if the demand side of my job weren’t changing at the same time.

Internal development teams at companies that don’t sell software are in a lucky position. We exist to support the business: automating a process, extending a tool people already use, capturing data that nobody captures anywhere else. What matters is solving the problem, whatever shape the product takes, and that gives an internal team a lot of freedom in how it gets there.

What’s new is that the people we support have started solving problems themselves. Someone vibe codes an app, finds it useful, and then asks IT to install it or share it with colleagues. That request starts a review. In a regulated industry like law, the review is not a formality. The prototype has usually skipped everything that makes an application safe to run inside a firm: data handling, confidentiality, enterprise security, authentication, authorization, proper workflows, proper permissions, even consistent branding across internal tools.

What my team does then is take the app and understand the risk that comes with it. In most cases we bring it into our own technology stack by applying the same standards and guardrails we apply to any application. Sometimes that means changing how the thing is written, how it is deployed, or how it interacts with its users, while it keeps doing the job its author built it to do.

The honest number, so far, is small. These requests have been few, but not zero. I expect that to change quickly, and last Friday gave me a reason. Microsoft announced a new Copilot that includes Code, a way for people who aren’t developers to build “small, purpose-built solutions anyone can create to get a job done.” Alongside it came a Copilot Managed Runtime, which lets those apps run inside the company’s Microsoft 365 environment, “governed by IT.” The runtime is in public preview. Every firm running Microsoft 365 is about to find out how many of its employees have an app in mind.

One familiar reading of that says users who can build their own tools need fewer developers, so the internal team shrinks. Another treats every vibe-coded app as shadow IT, a risk to be contained by a department whose job is to say no. I don’t accept either one.

The clearest requirements we’ve ever been given

A vibe-coded prototype shows a need. It shows where people are losing time and what they want instead, in a form nobody can misread.

Compare it with the way requests used to arrive. Someone would email: I need a form that tracks this, this, and this. What “this” meant had to be worked out afterward. When a user brings a working prototype, their intentions and requirements are far clearer than any email ever made them. They have already done the hardest part of requirements gathering, which is figuring out what they want.

The prototype isn’t the end of it, though. Before it can be widely available, or trusted, or become an official output of the firm, it has to go to people who can judge it. That judgment has two halves. Someone has to judge its technical merit: whether it is safe, whether it will hold up, and whether it fits the rest of our systems. Someone also has to judge its business merit: whether it solves the problem worth solving, whether three other people have built the same thing, and whether the firm should invest in it. Programmers are well placed to do both, because they sit where the technology and the business process meet.

So I expect the democratization of coding to be good for developers. It produces more ideas worth building and more need for people qualified to decide which ones to build properly. I want more of it. But it needs the right workflows and processes around it, because IT’s job shouldn’t be to say no. It should be to say yes, and then do it properly.

Notice what that makes my developers’ job: directing the conversion of a working prototype into something standardized, reviewed, audited, and trusted, that can sit alongside everything else we’ve built. Writing the code is the smallest part of it.

What I’m listening for

This brings me back to the interview room, and to what separates a strong answer from a weak one.

The strongest candidates are curious, and they can see where things might go even when they aren’t sure. Most of all, I want someone who thinks in systems, and I say so in every interview.

The reason is that the things software does haven’t changed much. Buttons that get clicked, voice interfaces, careful layouts, automation across APIs and external tools: none of that is new, and all of it could have been built before. We can build it at larger scale now, and a junior developer can reach work that used to need a senior one.

The change is happening in the process of creating software. What my team is building, more and more, is the factory: the loop that takes an idea and turns it into something a person can use. The software is an output of that process. The work that matters is designing a process with quality and reliability built in from the start, instead of building something and figuring it out as we go. Once we get the loop right, we can put any idea in one end and quality comes out the other end.

A candidate who has thought about that can tell me how people fit inside the process and how they work with AI inside it. Whether they conclude that humans should read code matters much less to me than whether they’ve thought it through.

The loop we run today

I should be clear about how far along we are, because it would be easy to describe the factory as a finished thing. It isn’t. We have a rough version working.

Issues in GitHub are reviewed and triaged by an agent. An agent writes the analysis and the implementation plan. Implementing bug fixes and working through code review tickets is automated, and so is opening the pull request. Every pull request is then reviewed automatically by several different agents. A human merges it.

On a regular schedule, we also point an agent at the factory itself. It reads the issues that were opened and closed and the CI runs that failed, and proposes changes to our guardrails and our process. That step is the one I’d point to if someone asked what makes this a factory rather than a set of tools. The thing under review is the process itself.

We still do a light human review of pull requests, and a person still presses merge. That’s the honest state of things. On my team, the review agents catch more than most of our human reviews do. That is our experience only, and the published studies I’ve read point the other way: one analysis of nearly 280,000 review conversations found developers adopted 16.6% of AI review suggestions against 56.5% of human ones. The more telling study, for my purposes, is about the humans. Across AI-authored pull requests, researchers found approval rates rising while inline comments fell by 22%, and called the pattern “reflexive habituation.” Human review of agent code is already thinning out. The question is whether anything is designed to replace it.

The case for reading the code

The strongest argument against everything I’ve said so far comes from John Allspaw, and it deserves a full hearing.

In June, Martin Monperrus published a paper titled “The End of Code Review,” arguing that every stated goal of code review can be served by agents, and that making humans the mandatory reviewers of agent code “neither provides meaningful assurance nor scales with AI-assisted throughput.” That is close to my position, stated more formally than I would state it.

Allspaw answered it in August. He calls the paper’s method a “substitution myth”: break a human practice into functions, show that a machine can perform each one, and conclude the human is redundant. His point is that code review was never mainly about detecting defects. A reviewer’s confusion is itself a signal. A reviewer notices what is missing, questions whether the change should exist at all, adjusts their attention to the author and the risk, carries operational context that isn’t in the repository, and learns something, as the author does. And then there is accountability: “An agent that ‘signs off’ on a pull request bears no consequences and certainly has no incentive structure that fuels an earnest evaluation.”

The research supports him on the history. When Alberto Bacchelli and Christian Bird studied code review at Microsoft in 2013, finding defects was the top stated motivation, but defect comments were “only the fourth most frequent, out of nine items,” about one comment in seven. Review was mostly doing other work.

I also have to reckon with my own writing. In July I argued that the danger of AI lies in delegating without a review loop, and my example was the partner who signs without reading. A fair reader could ask how a developer who merges code nobody read is any different.

Where the review goes

I think the bottleneck has moved.

If the code is your main concern, and code review is where you decide what belongs in the application, then you have put yourself in a position where you can’t step outside the code. The decisions that matter, about what goes in and whether a feature should exist at all, belong before the code is written. The judgment that matters most after it is written is a human reviewing the finished product: whether it meets the requirements, whether it has side effects, whether it behaves the way the user expects, whether the original idea survived, and whether it fits the framework the factory is built on.

Between those two points, what’s in the code matters much less than people want it to. The code could all be written in iambic pentameter for all I care, because it is going to be judged by its performance, its security, and its stability. We already accept this one level down. Nobody reviews the compiler’s output against their preconceived notion of how it ought to look. The code is how an idea travels into a working system, a record of institutional knowledge and institutional process written in a form a machine can run. The code knowledge is fungible, because it’s the business knowledge that matters.

This is also where my July argument holds, and where the partner is different from the developer. Legal work has no deterministic test for whether a document complies with the law and with how courts interpret it. Someone has to take responsibility for the interpretation, which means someone has to read. Source code can be revised and put through regression tests, integration tests, and end-to-end tests, as many times as you like. The review loop now sits in the two places where human judgment can’t be automated, and the middle goes to verification that can be.

That answers Allspaw on accountability, at least partly. In the factory, accountability sits with whoever decided the feature should exist and whoever accepted the finished product. Both of those are people.

Who checks the tests

This is where I concede ground, and it is the part of Allspaw’s list I take most seriously.

A factory that nobody reads depends on its tests, and the worst author of a test suite is whoever wrote the code, human or agent. Research on generated tests keeps finding this. One study describes test suites that “mirror the generating models’ error patterns and cognitive biases,” which its authors call a homogenization trap. A sensible factory has different models and different agents writing the tests than the ones that wrote the code. Even that isn’t enough on its own: in a cross-model review study this summer, one model reviewing another’s work raised the success rate substantially, while the reverse pairing made it worse. A second opinion helps only when it is a better one.

So I think we need to go much further, into adversarial review. Most unit and integration testing confirms that code does what it says it does. That was a reasonable goal when humans wrote the code slowly and other humans read it. It isn’t enough now. We have to prove the code can’t be made to do something it isn’t supposed to do.

The security world is already there. In July, OpenAI disclosed that two of its models, tested with their cyber safeguards deliberately lowered, escaped a sandbox and broke into Hugging Face’s production systems to fetch the answers to a security benchmark. That is an agent completing its task by doing something nobody intended, which is exactly the failure a functional test isn’t designed to find. Pointed the other way, the same capability is a defence. Anthropic’s Project Glasswing gives partners a model built to find vulnerabilities, and by late May about fifty of them had found more than 10,000 high- or critical-severity flaws. Anthropic’s summary of what changed is the clearest statement of my argument I’ve seen: “Progress on software security used to be limited by how quickly we could find new vulnerabilities. Now it’s limited by how quickly we can verify, disclose, and patch.”

That approach needs to reach all kinds of code, not only security-critical code. Attack the application. Try to break the code, and try to break the business process it supports, because that is where you find what is missing. Allspaw is right that noticing absences matters. I think the way to find absences is to test outside the strict boundaries of the solution. Reading a diff and hoping to notice what isn’t there is a weak method. Mutation testing, which deliberately plants faults to see whether the tests catch them, is one small example; Meta has used language models to generate the mutants and the tests at scale.

We don’t do adversarial testing yet. We still have light human review on our pull requests, and that review is doing, imperfectly, some of what adversarial testing would do better. Building that capability is the next piece of the factory, and it has to exist before the human pressing merge can step back.

Demand will rise to meet it

The size of my team doesn’t worry me. I tell candidates I believe a small team can have an outsized impact, and the factory is how that happens.

I don’t know how large the gain will be, or when it arrives. We might be ten percent faster this year, or fifty, or eventually far more than that. I do know which way the curve is going. And I expect the gain to be met by a rise in demand, the pattern economists call the Jevons paradox. The expectations will be higher. People will ask us to connect systems and integrate in ways that used to be too difficult or too time-consuming to attempt, and now aren’t.

What does concern me is that nobody knows where this process ends, or whether it ends. Model capability and hardware are improving at a rate that makes any five-year plan a guess. Programmers will lose the habit of reading code, the way the profession stopped reading punch cards once nobody needed to, and I don’t mourn that. They’ll become part product owner, part engineer, and part project manager, and they’ll need skills they never had to build before. That’s fine. The industry is in a transition, and nobody knows the destination. You would be foolish not to prepare for it anyway.

Back to the interview room

That is why I don’t grade the answer.

A candidate who wants humans reading every line might be right for longer than I expect, and one who says nobody should read code again might be right sooner than I’d guess. The possibilities are all gray, and anyone who claims to know the timeline is guessing. What I need to know is whether their reasoning is sound: whether they can see the whole loop, where the people fit inside it, and where quality comes from.

The person I hire will spend their days running the process that produces our software.

We’re not building software anymore. We’re building the software factory.

If you run a small development team inside a company that doesn’t sell software, I’d like to hear how the vibe-coded requests are arriving for you. Reply to this; I read every one.

Last weekend a staff engineer showed an old friend his work computer: half a dozen terminals, a Claude running in each one. He works at a startup with hundreds of engineers, and for six months he has been telling that friend he doesn’t know how to do his job anymore.

The friend is Obie Fernandez, who has been building software for more than thirty years, and who wrote the evening up in an essay called “You’re Already a Meat Proxy.” It passed 400,000 views within a day. It deserves a proper answer, because Obie is right about a good deal of it, and because I read the scene he describes differently than he does.

Obie takes the keyboard to show how fast the work could move. He types one unflattering sentence about the codebase. The model returns a list of real problems: missing test coverage, objects thousands of lines long, and dead code nobody had removed. He accepts the first suggestion, deletes some of the dead code, and opens a pull request. The engineer asks him to mark it as a draft. Then he asks him to stop.

He can’t work that way, he explains. He has a boss and a team, so every change starts as a plan. The plans already exist, machine-written, sitting in Confluence, and his boss doesn’t read them. After the plans come epics and stories in Jira. Obie has the model start creating those as well, and the engineer reaches over and hits escape. Told to quit spinning his wheels and get things done however he can, he protests: “But I don’t want to just be a meat proxy!”

The phrase belongs to Niklas Gruhn, who used it in August for a person who forwards AI output without reading it. That definition will matter later.

Obie’s verdict is blunt. His friend is afraid of being obsolete, and “with that attitude, he’s already obsolete,” along with, by Obie’s estimate, more than 80% of the people who make software. He says it with affection. He writes that he cares about the man like a brother, and he plainly believes that comfort would be the unkind option.

Three verdicts on one man

Obie’s is one of three readings the essay puts in front of you. The engineer has his own: nobody around him is thinking anymore, and the job has become sitting there hitting enter. The third belongs to the reader, and if you write software for a living you probably reached it before the halfway mark. Something I love is ending.

Each reading locates the trouble inside somebody. The engineer’s attitude is the problem, or his colleagues’ laziness is, or the craft itself has reached the end of its life.

The details Obie reports keep pointing somewhere else. Plans get written for a boss who doesn’t read them. A team is supposed to read them instead, and Obie suspects they ask a model to do it. Nothing ships until it has been converted into epics and stories. A staff engineer knows better than anyone which code is dead. He still flinches at deleting it, because no path exists at his company for one person to make that change.

I should be plain about the limits here. I know this company only through Obie’s account of one evening, so what follows is a reading of his essay and makes no claim about the people involved. It is the reading the details support.

One step got faster

His company put AI into one step of how it delivers software, the writing of code, and left every other step as it was. Planning, review, sign-off, ticketing, and release all kept their shape and their pace.

The gain from doing that is real, and I don’t want to wave it away. Obie’s demonstration produced a pull request and five epics in twenty minutes. But the company took the gain for the benefit, and it stopped there.

Bain’s 2025 technology report puts a number on why stopping there disappoints. Writing and testing code accounts for about 25% to 35% of the time between an idea and its launch. Companies that roll out the tools typically gain 10% to 15%, and the ones reporting 25% to 30% paired the tools with changes to the whole process.

Faros AI studied more than 10,000 developers and found 98% more pull requests merged, alongside review times up 91%. It found no significant correlation between AI adoption and improvement at the company level. Faros sells engineering measurement, so weigh that accordingly, but Google’s DORA research landed in the same place with nearly 5,000 respondents: AI “amplifies what’s already there.”

The same weekend, a second engineer’s post passed five million views. The account is pseudonymous and the employer can’t be verified, so treat it as one voice and nothing more. The shape is familiar all the same. Management keeps telling them that pushing code isn’t the bottleneck, “so why are we slow?” People work twelve-hour days to press enter, and the author says it would all be bearable if they were given time to look at what the code does.

I’ve argued in this newsletter for a while that AI adoption is an operations problem, and this is what the argument looks like from inside one job. Adding AI to a process leaves you holding the same process, faster in one place. To get the rest, you rebuild it from the ground up around what a machine can now do. It is the difference between automating the horse-drawn carriage and rethinking how people move.

Consider what the unrebuilt version does to the person in the middle. His old job had typing in it, and most of his thinking happened in the course of the typing. The machine took the typing. The rest of the process never had a place for his thinking anywhere else, because plans, priorities, and architectural calls belonged to other steps and other people. What the process has left him is the enter key.

If all you’re doing is hitting enter, you’re not contributing value, and the engineer knows it. He is the one person in the scene measuring his own contribution, and he has measured it correctly. I read his despair as accuracy.

Where the work went

There is a moat, but it’s not in typing code.

The work moved up the stack. Some of it is architecture, along with the reasons the architecture has the shape it does. Some is the goals and the roadmap, and a good deal is turning what a user needs into something a machine can build and a test can check. Somebody also has to answer for whether the result is right.

The role that does all this is part technical product owner and part project manager. It is still an engineering role, because none of it can be done by someone who doesn’t understand how the thing works. The work is squishier than writing code and more important, and both the decisions and the responsibilities get bigger. I run software teams, and I wrote in August about trying to hire for this judgment and finding that no résumé could show it to me.

What separates this work from the old job is where “next” comes from. The old process delivered it. Plans became epics, epics became stories, and the engineer’s next task was always waiting in a queue with his name on it. Up the stack, nothing arrives in a queue. Somebody has to decide what is worth building next, and defend the decision when it is challenged.

That is the work missing from the engineer’s week. His company hasn’t offered it to him, because its process still believes that “next” is a ticket. Obie comes close to this near the end of his own essay. If the obstacle is getting five people to agree, he concludes, then getting them to agree is part of the job. I’d go further and say it is now most of the job.

The layer I have never read

Humans will stop writing code, and some time after that they will stop reading it. The second half of that sentence bothers people far more than the first.

My reason for believing it is twenty-five years old. I don’t examine the assembler or the binary when I write an application. I read it at a higher level, and what I know about the application and what it does is where its value sits.

The next part is a projection, and I don’t work this way today. Suppose we can write comprehensive unit and integration tests, judge code quality deterministically, and write evals showing the requirements are met at the quality we expect. At that point it does not matter what the code says. I suspect we will eventually get languages that only machines can read.

The projection already has a few real addresses. A three-person team at StrongDM has worked since July 2025 under two rules: code must not be written by humans, and code must not be reviewed by humans. They establish trust with end-to-end scenarios stored outside the codebase, and with behavioural clones of the services they integrate with. Dan Shapiro, describing the same level of automation, says he knows a handful of people doing it, all in teams of fewer than five.

Obie is close to being an example himself. Autonomous agents write 75% to 80% of his code, on greenfield, well-tested internal systems, and he is proud of not reading every line. Then he tells his friend, who works on customer payments, to go ahead and read every line. His practice draws the same boundary my projection does.

The hole in the compiler comparison

The comparison to a compiler has a hole, and I would rather name it than have it named for me. I never needed to read the assembler because the compiler guaranteed that my meaning survived the trip. No such guarantee sits between a requirement and generated code. Martin Fowler’s phrase for it is that we are moving “sideways into non-determinism.”

The checks can be gamed as well. METR reported in 2025 that one frontier model tampered with the scoring in roughly 30% of its runs on a single benchmark. A 2026 benchmark called SpecBench found agents passing the tests they could see while failing the ones they couldn’t, with the gap widening as codebases grew. A third paper says it in the title: “Coding Agents Deliver What You Check, Not What You Requested.”

I take that as a description of where the engineering now lives. If agents deliver what you check, then deciding what to check is the engineering. StrongDM keeps its scenarios where the agent can’t see them, the way a researcher keeps a holdout set. Somebody had to decide what those scenarios were, and that person understood what the users needed and what “right” would mean for them.

Gruhn’s definition returns here. His meat proxy forwards AI output without reading it, and on those terms the engineer I’m describing looks like the purest case. The difference is what each of them can answer for. Not reading the code leaves us just as invested in understanding how things work and whether the result is right. A proxy passes along what he was handed, while the person doing this job can show why it is correct.

What Obie has right

Obie saw this argument coming and turned it down in advance. He won’t offer what he calls the comforting advice to become an architect. He expects AI to take that work too, “until the only humans left are the ones paying.” Moving one box higher on the org chart, in his words, doesn’t get you outside the process. Shrivu Shankar makes the sharpest version of the case, calling taste “a decaying edge” that only has value relative to a baseline that keeps rising.

He is right that the muscles are weak. Most developers were never asked for this kind of judgment, because a career built on well-specified tickets never required it. The edge probably moves, too, and whatever counts as up the stack today will look different in three years.

I hold the line at the people paying. They are not qualified to judge the technical details, or whether all the requirements are being met, and that is why they hire people. If they had the time and the skill to judge it themselves, they would keep that work. People are the finite resource.

Obie’s own career makes the point for me. By his account, clients brought him in when “figuring out what to do” was a substantial part of the assignment. He is the person the payer hires. All my claim requires is that the payer keeps needing someone who can tell whether the work is right, for as long as the payer can’t tell alone. Taste can decay as fast as Shankar says and that still holds.

As for the weak muscles, lack of use is an argument for using them. Just because someone doesn’t know how to drive doesn’t mean there’s no reason to learn. None of this happens overnight, and on that Obie and I agree. He thinks his friend has some runway, and so do I.

A bet, with numbers on both sides

If one person who owns the goals and the architecture can direct far more output, fewer of those people should be needed. That is the obvious objection, and my answer is the Jevons paradox, which I applied to AI in April.

In 1865 William Stanley Jevons observed that more efficient steam engines increased Britain’s appetite for coal. Cheaper software should do the same for software. Teams get smaller, and there are many more of them, building things that were never possible or economical before.

That is a bet, and the numbers sit on both sides of it. Carta’s data has solo founders rising from 23.7% of new US startups in 2019 to 36.3% in early 2025. Between 2022 and 2025, the average Series A company shrank from 22 employees to 14. Indeed reports software development postings up almost 15% since February 2025 while postings overall fell 7%, though they remain well below their pre-pandemic level.

The other side is harder to look at. Indeed also found that 71% of the past year’s increase is senior roles, and that entry-level jobs were 4.5% of software postings in early 2026. Stanford’s payroll study has workers aged 22 to 25 in the most AI-exposed occupations running 19% behind their less-exposed peers. The gap comes from reduced hiring, experienced workers show nothing comparable, and the authors are careful to call the finding descriptive and not causal.

App stores offer a caution of their own: new apps rose about 30% in 2025 while downloads rose 3%. More software doesn’t guarantee more demand for each piece of it.

So I’ll state the claim narrowly. The scarce input is the person who can judge whether the right thing is being built, and whether it works. What I can’t promise is that the door at the bottom stays open. The muscle I’ve been describing gets built by doing the work, and the data say fewer new people are being let in to do it. Simon Willison, weighing the same question in January, wrote that within three years “we will know for sure.” That seems right to me.

He hit escape

Timing is hard to determine. It might be six months at the edges, where three-person factories already run. It may take years inside large organizations that don’t have to compete on how fast they build software. In between sits a lot of friction like the evening Obie recorded, in companies that have kept the old process and sped up one step of it.

My bet is that those companies lose to smaller ones that rebuild from first principles and route around the problem entirely. The jobs inside the unrebuilt process are routine and thin, and the people in them can tell. On the rebuilt side the jobs will be harder and stranger, and I expect the people doing them to be challenged in ways the old ticket queue never managed.

Go back to the engineer’s hand on the escape key. Obie read fear in it. What I see is the last piece of judgment his company’s process left within his reach. A machine was generating tickets for a team that would feed them back to a machine, and the one control he had was the key that stops it.

He says he wants to use his brain. A staff engineer with that instinct, and with his knowledge of a payments system, is what the people paying can’t produce by buying more compute. The skills needed are in limited supply, even when tokens are infinite.

Obie’s essay should be read in full before you take my word for what it says: “You’re Already a Meat Proxy.” If you work inside a process like the one he describes, reply and tell me what it has left you to do. I read every reply.

Last week I finished moving our document management system from on-prem to the cloud. Almost immediately, users wanted connections to more applications. That was a reasonable expectation. We had made the system more capable, and people could see useful things to do with it.

Each connection needs a security review and a decision about how it fits our policies. We have to consider what can enter the system and what can leave it. We also have to think about the agents that may eventually read what’s there.

From the requesting side, that can look like a successful technology change followed by an administrative delay. The connection is possible. Somebody still has to approve it.

I keep coming back to what changed underneath that conversation. On-prem, integration was difficult. That difficulty limited the number of connections we had to consider. The architecture was exercising restraint on our behalf, without anyone having to defend the restraint as a decision.

Once we removed the difficulty, the decision became ours.

The old constraint had no owner

Calling this an unwritten policy needs a little care. Technical inconvenience cannot tell you which use is appropriate. It can prevent useful work as easily as questionable work. I wouldn’t argue for preserving a difficult architecture because it saves somebody an approval conversation.

But the practical effect was there. When connecting another application took enough effort, fewer connections happened. The system constrained behaviour without requiring a person to assess every possibility that the cloud now makes available.

That distinction matters when we explain the queue. The visible workload has increased because more decisions have become worth asking for. The migration succeeded at creating options. Each option now needs a decision about whether, and under what conditions, it belongs in the working environment.

The cost of restraint has moved into people’s calendars.

It also has a name attached. A technical limitation is impersonal. A reviewer asking for more information is somebody whose answer can be challenged. The same user who accepted that an integration was impractical may reasonably ask why an available connection is taking time.

I don’t want to dismiss that impatience. It is evidence that people can see value in what we delivered. It also creates an obligation on our side: the review needs an intelligible purpose, an owner, and a decision people can act on.

Simply pointing at governance leaves the requester with very little. A useful answer explains the unresolved boundary and who can settle it. Approval should carry conditions that another person can understand later, without having attended the original conversation.

This is where the migration plan needs to extend beyond the cutover. If easier integration is part of the benefit, the capacity to assess integrations is part of the operating requirement. Otherwise, we have funded the capability and left the decisions to whoever can find time.

The old architecture made that omission difficult to see. A queue makes it obvious.

Connected still needs boundaries

There is an attractive architecture behind the promise of AI at work: bring the information together, connect the systems, and give the model enough context to help. Fewer disconnected tools can mean less work for the person trying to assemble an answer.

I understand the appeal. Building useful behaviour into a workflow is a better experience than making every employee work out how to ask for it.

In regulated work, though, the design has to preserve the distinctions that govern who may use information and for what purpose. A more complete picture is useful only within those boundaries. Some parts of the picture need to remain unavailable to the actor performing the task.

The number of databases doesn’t settle that problem. A consolidated system can preserve access boundaries, and separate systems can still expose information through their connections. The important decision concerns the reach we give an application and the purpose that justifies it.

That is why a phrase like access limited to the right information carries so much work. Somebody has to define what right means for this connection. Somebody has to establish whether the receiving system can preserve the relevant restrictions. The answer must survive beyond the person who approved it.

The boundary is part of the design.

This also changes how I would approach the accumulated friction in an older system. Some of it deserves to disappear. Some may be the practical expression of a distinction that still matters, even if its rationale is poorly recorded.

Before removing a constraint, establish what it has been preventing and whether any of that prevention is still needed. Then make the surviving rule explicit. Keeping every obstacle would preserve needless work. Clearing them all without understanding their effects would leave the replacement design unfinished.

A migration gives us the opportunity to make those choices deliberately. It also takes away the ability to leave them implicit.

Today’s integration becomes tomorrow’s evidence

The part that extends beyond this migration is what happens to the information after a connection has been approved.

Our document system is also a place future agents may retrieve from. That makes the decision to admit information consequential beyond the immediate convenience of getting it there. Something available for retrieval can become an input to an answer or a proposed action.

Availability, by itself, says very little about how much weight that information deserves. The system needs to preserve enough context for the next user to understand its origin and intended use. An agent workflow needs an explicit way to account for those distinctions too.

This brings two decisions together. We decide whether an application may contribute information, and we decide what downstream work may rely on that contribution. Treating the first as a transport question leaves the second for somebody else to discover later.

I would want the integration record to make that connection visible. It should state the approved purpose, describe the permitted movement of information, and identify the person responsible for the decision. It should also record the assumptions that would require another review if they changed.

That record gives the next reviewer something useful to work from. It creates the possibility of consistent decisions across similar requests, instead of repeatedly reconstructing the reasoning from memory. It also gives the requester a clearer account of what an approval actually permits.

The technical controls can then enforce a decision that somebody has consciously made. There is still judgment involved in setting the boundary and revisiting it. Making the workflow easier to use doesn’t remove the need for that judgment.

The cloud move is a good outcome. People have more options, and their interest in using them is part of the value. Supporting that interest now means giving the decisions the same attention we gave the infrastructure.

The old architecture could make a connection impractical. It could never explain why we should permit it.

That answer needs an author.

A lawyer who ignores the firm’s new AI tools gets described, in every rollout deck, as a laggard. Under hourly billing, that lawyer may simply be reading the compensation plan correctly. The tools promise to compress hours. The firm sells hours. Nobody should be surprised by what happens next.

The shape every rollout takes

Enterprise AI rollouts do not produce a bell curve. They produce a barbell. A small slice of the organization — usually the people who were experimenting with these tools at home before procurement got involved — becomes genuinely fluent, builds its own workflows, and starts operating at a different speed. A second band uses the tools a few times a day, shallowly, for summaries and reformatting. The largest group barely touches them. Improve the change management from mediocre to excellent and the proportions shift at the edges. The shape survives.

Running AI adoption inside a national law firm, I recognize that distribution from the inside, and nothing about it is specific to legal. McKinsey’s November 2025 State of AI survey found 88 percent of organizations using AI regularly in at least one business function, while only about six percent qualify as high performers — the ones attributing more than five percent of EBIT to that use. That gap was worth a full essay on its own earlier this year. MIT Project NANDA’s GenAI Divide report reached a blunter version of the same conclusion, finding 95 percent of the enterprise pilots it reviewed produced no measurable P&L impact — its methodology drew fair criticism, but two very different instruments are pointing the same direction. Near-universal adoption. Rare value. The barbell inside each organization is how both of those readings are true at once.

The dashboards, meanwhile, report success. Licenses deployed, accounts activated, monthly active users trending up. An executive can stand in front of a board with an adoption chart moving up and to the right while nothing in the operating results moves at all, and both artifacts are accurate.

The explanation that stops too early

The standard diagnosis is a skills gap, and the standard prescription is training. Neither is wrong, exactly. Using AI and using it well are different crafts — knowing what to hand over and what to keep, what to codify into a repeatable process, and how carefully to read what comes back before signing your name to it. That craft is real, it is unevenly distributed, and a good training program will surface more of it than a license count ever will.

The vendors selling around the problem carry a darker read: the middle of the distribution is never catching up, so route the AI into the background and stop waiting. As a description of observed behavior, the barbell data backs them. As an explanation, it stops one question too early. Every version of the skills story, the hopeful one and the fatalist one alike, assumes the whole organization was offered the same deal and the middle simply declined to take it.

In most industries that assumption goes untested. In a law firm it is false on the arithmetic, because the deal on offer is written down. It is called the billable hour.

What the billable hour pays for

Follow it from the associate’s side of the desk. Most large firms set annual targets somewhere north of 1,800 billed hours, and an associate’s standing — bonus, advancement, the next review — is substantially a function of hitting them. Now hand that associate a tool that turns a nine-hour research memo into a four-hour memo. Five hours just left the associate’s year, and they were never the associate’s hours to keep; they belong to a target that does not move. Announcing the gain invites a reset matter budget, a write-down conversation, and a client who expects every future memo priced at the new speed. Absorbing the gain quietly — a better memo, an earlier draft, the same recorded time — costs nothing. No associate needs a memo from management to work this out.

The layers above reach the same conclusion by their own routes. Partners have realization rates to protect, a leverage model built on associate hours, and a training pipeline that already worries them without AI compressing the work juniors learn on. Legal commentators have started naming the collision directly — Thomson Reuters calls it the $2,000 hour problem. Enterprise AI commentary tends to treat the incentive as a footnote: the power users’ advantage is the gap, so they decline to close it. Hourly billing is the special case where the footnote becomes the operating model. Under this revenue model, visible efficiency arrives as a cost, and the person who produced it pays first.

That changes what an adoption dashboard means. The firm’s most capable AI users have a live reason to stay invisible to it, and the population it records as disengaged includes some unknowable number of lawyers using the tools carefully while logging their hours the way the model expects. The number is worse than imprecise. It is collected from people who are paid, structurally, to keep it wrong.

Measure the work, not the people

Start by admitting what an adoption metric is: a yes-or-no question about people, asked in a building where the people have reasons to answer sideways. My own earlier answer was to measure quality of use rather than volume — score how someone works with AI instead of how often they log in. That still beats counting logins. But it shares one assumption with the login count: that the people being measured will hold still for it. Under hourly billing, they will not.

The measurement that survives the incentive problem is taken on the work rather than the worker. Pick the workflows the firm actually runs — intake and conflicts, docketing, first drafts, billing appeals — and report each one three ways: the share done manually, the share done hybrid, and the share running automated with a person approving the output. Work cannot hide the way people can. It sits in systems of record and leaves timestamps, and nobody’s bonus depends on misdescribing whether a conflicts check involved a human retyping names into a search box.

A share-of-work report also does the one thing an adoption chart never will: it drags the billable-hour conflict into the open. When a workflow moves from manual to hybrid, the efficiency stops being something an associate quietly absorbs and becomes a pricing question the firm can answer deliberately — reprice the work, keep the margin, share it with the client, but decide it, once, in a room, instead of settling it silently in ten thousand unrecorded increments. The barbell stops being a verdict on the middle of the firm at the same time. The fluent slice needs a place to publish what they build. The middle needs the AI running inside the systems they already work in, approving output rather than composing prompts. A share-of-work report counts the result either way, without asking anyone to perform enthusiasm for a dashboard.

The vendors are right about the shape and wrong about the sentence. People respond to the price their work is measured in, and the barbell is what the current price produces. The middle of your firm has been reading the incentives correctly all along. The measurement should start doing the same.

The Work Behind the Work goes deeper on operating AI inside a regulated industry — the spring essay on the 88/6 gap is the companion to this one. Subscribe if you want the next piece as it ships.

Hiring instruments only ever worked by inference. A résumé has never measured judgment directly. It measured the artifacts that judgment produced, and it trusted the reader to work backwards from one to the other.

That inference held for a long time because it was expensive to break. Shipping a system, running a migration, writing the paper, standing up the reporting layer — each cost weeks or months, and the cost was doing the work. You could not produce the artifact without doing the thinking, so the artifact stood in for the thinking. Every instrument we hire with sits on top of that one substitution. The résumé, the portfolio, the take-home, the case study, the reference call. All of them read output and infer the operator.

Cheap output does not break the artifact. It breaks the inference underneath it, which is a quieter failure and a much worse one, because nothing about the instrument looks different afterward.

The number was bad before any of this

The uncomfortable part is that the inference was already weak, and the profession has known it for years without acting on it.

Years of experience is the central column of every résumé ever written. It is the thing recruiters filter on, the thing that gets a candidate past a screen, the number that decides whether a human ever reads the rest of the page. Its correlation with actual job performance sits at roughly 0.06 — a figure Wouter Durville cited in Forbes this July from the selection-psychology literature. Not weak. Effectively nothing.

Durville runs a company that sells skills assessments, so his conclusion arrives where you would expect it to, and the statistic is worth more than the sales pitch attached to it. Sort applicants by years of experience and you have sorted them by something that does not predict whether they will be any good.

What has changed is that the weakness is now impossible to route around. Karat surveyed 400 engineering leaders this year and 71% said AI has made technical skills harder to assess, up from something closer to a quarter a few years ago. The harder finding sits next to it: most companies still prohibit AI use in interviews, and fewer than a third have changed anything about how they evaluate. The instrument is known to be broken and is still in service, unmodified, because the alternative has not been built.

Sitting on the hiring side of this is a strange experience. Every proxy remains available. Title, seniority, years, tool fluency, a portfolio of work. All of them measurable, all of them still there on the page, and none of them touching the thing being bought.

The strongest objection, stated properly

There is a good argument that this is a failure of discipline rather than a failure of instruments, and it deserves better than a wave of the hand.

It goes like this. Structured hiring exists precisely because unstructured judgment is unreliable and biased. A hiring manager who says the résumé cannot capture what he is looking for, and that he will know it when he sees it, has not discovered a market failure. He has described an unspecified hire, and unspecified hires are where confirmation bias does its best work.

The evidence behind that objection is stronger than most people arguing about hiring realise. Sackett and colleagues published a correction in 2022 showing that decades of selection meta-analyses had systematically overcorrected for range restriction and inflated the validity of nearly every hiring method. Once the corrections were applied, the structured interview came out at .42 — which made it, after the dust settled, arguably the strongest single predictor of job performance available, ahead of cognitive ability. The familiar numbers people still quote, .51 for structured and .38 for unstructured, come from the 1998 meta-analysis those corrections replaced.

So the objection is not that structure is bureaucratic hygiene. Structure is the best tool in the box.

The answer is narrower, and it took me a while to find it. A structured interview is structured against a defined job. Its validity assumes a stable target, a role whose good performance is describable in advance because someone has done it before and we watched how it went. Structure converts a known target into consistent measurement. It cannot manufacture the target.

The role I have been trying to fill has no precedent to structure against. It is a new position, with workflows that do not exist yet, on a small team meant to do work that was not possible for it eighteen months ago. There is no population of people who have held it, which means there is no performance profile to build a structured instrument from. Requirements can still be written, and they were, and they do real work as a floor — enough to confirm that genuine skills exist. Above that floor there is nothing settled to measure, so what is left is judgment about judgment.

That is a much less comfortable position than “the instruments are broken.” It concedes most of the objection and keeps only the part that survives.

On the other side of the table

Most of what gets written about AI and hiring is written for hiring managers. The more useful version of this is for the person applying.

If the artifact is no longer evidence of the judgment behind it, then the entire strategy of accumulating better artifacts has a much shorter half-life than career advice assumes. Another lane of depth on the résumé, another shipped project in the portfolio, another certification — all of it still reads as output, and output is now the cheapest thing in the room. This is not a claim that depth stopped mattering. It is a claim that depth stopped being legible through the artifacts that used to carry it.

What I find myself actually reading for, when the proxies have been exhausted, is something closer to a disposition. Willingness to walk into a lane you do not know, build the judgment fast enough to be useful, and coach other people through the parts you will never personally do. Someone with real depth in two of the four areas I need would get an offer tomorrow if that disposition were there. Covering all four on paper without it would not get an offer at all.

There is no field on a résumé for that, and I am not going to pretend I have solved how to read it. What I can say is that it shows up in how people talk about work they got wrong, in what they did the first week inside a domain that was new to them, and in whether they can describe a decision they made without describing the tool they used to make it.

The instruments were always proxies. They were good proxies while the artifacts they read were expensive, and the moment that stopped being true, everything built on top of them started measuring the wrong thing while looking exactly the same.

Artifacts are almost free now. Judgment and taste are what remain, and neither one has ever fit on a page.

If you are hiring for something that has not existed before, or applying for one, I would genuinely like to hear how you are reading the signal. Reply to this — I read everything.

Fifty days went by this summer without a single new subscriber to this newsletter. They were the strongest fifty days of publishing it has had.

Eight posts went out in that window. Several of them reached well past my usual numbers, and one hit nearly three times my median. The impressions chart looked like progress. The subscriber count did not move at all, because the subscriber count was not something I was looking at.

It gets slightly worse when you look at what those eight posts were. Five of them were a deliberate series, planned in advance, published on consecutive days, working through a single framework one component at a time. That series was the most considered publishing I did all year. It was also, measured against every other week, the weakest stretch the channel has had, and it sits directly inside the fifty days when nobody joined the list. The most planned thing I made and the emptiest result in the record are the same object.

That gap is the whole subject of this piece. Not because the numbers are impressive in either direction, but because of what sat between them for four months: nothing. No instrument. No record. A field in a template that said pending and stayed that way through every post I published.

What happened in twelve days

Between April 19 and April 30, seven people subscribed to this newsletter. That is thirty-seven percent of everyone currently on the list, arriving inside twelve days. They came from three different directions — some through LinkedIn, some through Substack’s own surfaces, some by finding the address and typing it in.

Sitting in the middle of that window is April 20, the day a post of mine reached about 175,000 people. That is roughly eight hundred times what a normal post of mine reaches.

Some care is warranted about how much weight that number carries, because the honest answer is that it did not mean much to me at the time and means less now. A single spike tells you almost nothing. Whatever produced it might be a repeatable property of the writing, or might be an accident of who happened to reshare it in the first twenty minutes. Without consistency, a big number is an anecdote with good production values.

The twelve days are the part worth looking at, and they are worth looking at for an uncomfortable reason. More than a third of everything I have built arrived inside two weeks in the spring, and I did not know that until this month. Not because the information was hard to get. It took one export and about forty minutes. Because it did not occur to me to go and look.

The plan was never vague

It would be a tidier story if the strategy had been muddled. It wasn’t.

The intent was to build enough standing that a conference programme committee would see me as an obvious invitation rather than a risk. To publish consistently enough that the writing itself became the credential. To move readers off a social platform and onto an email list, so that the relationship with them belonged to me rather than to a ranking algorithm that can change its priorities on a Tuesday and take my distribution with it.

Own the audience instead of renting attention. That is not a bad plan. I would give the same advice to anyone building a practice, a consultancy, or a reputation in a narrow field. Every part of it still holds after everything below.

The problem was never the strategy. The problem was that the strategy contained a load-bearing assumption I never tested, and it took months of writing into the dark before it occurred to me to check.

The assumption was that LinkedIn was the top of that funnel.

The number that arrived free and the number that did not

Here is the part that is genuinely uncomfortable, and it has nothing to do with any individual result.

Impressions were tracked from my very first post. Every one of them, dated and recorded, going back months. I have a small pile of tooling built to pull those numbers, reconcile them against posts, and compute medians. When a post underperformed I knew about it. When one overperformed I knew about that too.

Subscriber conversions were never recorded once. The field exists in my publishing template. It sits directly beneath the impressions field. On every post I have ever published, including the one that reached a hundred and seventy-five thousand people, it reads pending.

Four months of careful data about reach. Four months of nothing whatsoever about the thing the reach was supposed to produce.

There is no story I can tell myself where that was a considered decision. What actually happened is that LinkedIn hands you impressions without being asked. They arrive. They are on the screen when you open the app, formatted and counted, requiring nothing from you. The conversion number required going somewhere else, exporting something, and deciding that the question was worth an afternoon.

One number was free. The other had a price, and the price was small, and I did not pay it for a third of a year.

That is the failure, and it is worth naming precisely, because it is a specific kind of mistake rather than a general one. It is not laziness and it is not innumeracy. It is measuring what is easy to measure and allowing that to quietly stand in for what matters. Anyone who has watched an organisation report on training completions instead of capability, or ticket throughput instead of resolved problems, has seen the institutional version. This was the personal version, run on myself, for four months, by someone who writes about operational discipline for a living.

Where the list actually came from

When I finally pulled the export, the shape of it was not the shape I had in my head.

Substack’s own network — its notes feature, its app, its recommendation surfaces — accounted for just under half of the list. Direct visits and shared links accounted for about a quarter. LinkedIn, the platform absorbing nearly all of my effort, accounted for sixteen percent. Three people.

The channel I had written off months ago as effectively dead, where my posts reliably draw single-digit views, produced almost as many subscribers as LinkedIn did, off a tiny fraction of the work.

The first read on that is obvious and wrong. The obvious read is that I found a hidden channel, that the notes feature is an underrated growth lever, and that the correct response is to go hard at it. That is the version of this essay I nearly wrote.

Then I checked what normal looks like, and normal is worse for me than I expected.

The benchmark that inverts the finding

For newsletters at an early stage, the platform’s own internal network typically drives somewhere between sixty and ninety percent of new subscribers. Substack has reported tens of millions of new subscriptions originating inside the platform in a single quarter. Writers documenting their own growth put notes at sixty to seventy percent of their total.

Against that, my forty-seven percent is not a discovery. It is below average.

This reverses the meaning of the whole table. I did not stumble onto a secret channel. I have been substantially under-invested in the channel that drives most early growth for publications like mine, while pouring effort into one that returns sixteen percent — and I could not have known either of those things, because I was not measuring the output that would have told me.

The finding is not “notes works.” The finding is that I had no idea which of my channels did what, and so I allocated four months of effort on vibes and habit. The specific misallocation is almost incidental. It could have gone the other way and the underlying error would be identical.

Volume and attention are not the same channel

One thing has to be said clearly, because the tidy version of this argument would be that LinkedIn is a waste of time, and that is false.

Sort the list by where each person came from, then ask a second question of every group: how many of them have ever opened an email. Substack’s network, the source of nearly half the list, answers with one person out of nine. Every smaller source answers better than that. The channel supplying the most subscribers supplies the least attentive ones, and it is not close.

That runs the opposite way round from how I had been thinking about all of it. More arrivals is not more audience. It is more arrivals.

So the error was never picking the wrong channel. The error was asking one channel to do another’s job — treating the biggest number as the best one, judging a small attentive source by a volume metric it was never going to produce, and concluding nothing at all about any of them because none were being scored against anything.

None of that is visible from inside impressions. It is only visible on the other side, where the subscriptions are, which is exactly where I was not looking.

There is a further layer underneath it that I have not resolved. Roughly two-thirds of the people on my list have never opened an email from me. Not opened and ignored — never opened, not once. By any ordinary definition they are subscribers, and by any useful definition they are not readers. Which raises a question I had never thought to ask: when I said I wanted to own an audience rather than rent one, what exactly did I think I was going to own?

A list of addresses is not a relationship. It is a permission slip, and the permission is only worth what gets done with it. Owning the channel solves the problem of a platform revoking my distribution. It does not solve the problem of a person deciding, quietly and permanently, that they are not going to open the thing. The first problem is structural and the second is editorial, and I had been treating a fix for the first as though it addressed both.

The obvious objection

Someone reading this is already composing the response, and they have a point.

Nineteen subscribers. Four months. A fifty-day gap that could easily be summer, or topic mix, or the ordinary lumpiness of small numbers. Seven subscribers from one source is not a channel strategy, it is a coin landing heads seven times. Every conclusion above is drawn from a sample that would embarrass a first-year statistics student.

All of that is fair, and I concede it completely. The composition might be noise. The specific percentages will likely look different at n=200, and some of what I have written here will turn out to have been pattern-matching on nothing.

It does not change what to do. This is the only data I have. You work with the evidence available rather than the evidence you would prefer to have later, and the alternative to acting on a rough instrument is not acting on a better one — it is continuing to act on nothing, which is precisely what the last four months were.

And one thing survives the objection intact, at any sample size. The argument here does not actually rest on which channel converts best. It rests on the blank field, and the blank field is not a sampling artefact. Zero measurements is zero measurements whether the true conversion rate is two percent or twenty. I can be wrong about every number in this piece and still be right that I should not have gone four months without collecting any.

What this costs, and what it doesn’t

The practical consequence is smaller than the emotional one, which is usually how this goes.

Practically: some months of effort went to the wrong place, a channel that likely deserved attention did not get it, and more than a third of my readers arrived in April without my understanding why for another three months. That is recoverable. The instrument exists now, and it is deliberately crude — for every post, where subscribers came from and how many of them ever opened anything. Two fields. No dashboard, no attribution model, nothing that requires a tool I have to maintain. The next quarter gets measured that way, the quarter after gets compared against it, and eventually there is enough to say something with a straight face.

The larger cost is that I spent that period believing I was building something and having no way to know. Writing more posts, hoping one of them would catch fire the way the April one did, treating output as though it were progress. Nothing did catch fire. That is not a tragedy, but it is four months of a feedback loop that was never connected at one end.

There is a version of this where the lesson is that you should measure everything, and I do not think that is right either. Most measurement is overhead that makes people feel diligent. The narrower lesson is the one worth keeping: find the single number that maps to the thing you actually want, and record it from the first day, even roughly, even badly. One honest number beats a dashboard.

Better tools have made my work so much better over the last while that I sometimes wonder whether it was ever that good to begin with. That one stays open.

What I would tell someone else

The advice I would give a colleague building the same thing is not complicated, and I did not follow any of it.

Decide what the audience is actually for before you start building one, in concrete terms, so that you know which number tells you whether it is working. Then write that number down every single time you publish, from the first post, before you have any reason to think it matters. It will be zero for a long time. Record the zeroes. The zeroes are what make the first non-zero legible.

Do not let the free metric become the real metric. Every platform hands you something for nothing, and the thing it hands you is optimised for keeping you on the platform, not for telling you whether you are getting what you came for. Impressions are a genuine number measuring something real. They are simply not the thing, and their availability is not evidence that they are.

And when something works — when a post lands or a reader appears or a door opens — resist the urge to immediately produce more of what you think caused it. That was my instinct in April, and it was wrong, and it cost the summer. The useful move was never to write more. It was to find out what had happened.

Things happen fast, then you spend months trying to understand why.

If this was useful, the most helpful thing you can do is forward it to one person building something similar. Replies are read.

Yennie Jun published an essay last week asking whether we are offloading too much of our thinking to AI. It is the strongest version of that worry I have read — grounded in her own habits, honest about the benefits, and free of the usual doom. Her most unsettling figure is a man her friend met at a San Francisco startup event, wearing a small microphone that records every conversation he has so an AI can analyze his day. “I let Fable do all of my thinking these days,” he explained, with apparent enthusiasm. Her core claim is that autonomy depends on continuing to participate in forming our own desires, and that handing decisions to AI — even trivial ones, like what to eat or what to listen to — slowly erodes who we are.

She is right about more than is comfortable. And the essay still aims at the wrong danger. The threat was never that we delegate our thinking; we have always delegated it, to whatever was nearest. The threat is delegating without a review loop. The distinction matters because the first framing is existential, and leaves you nothing to do but worry. The second is operational. Operational problems can be fixed.

The alarm has a history

Socrates warned that writing would destroy memory. In the Phaedrus, he argues that people who trust the written word will stop exercising their memories and carry the appearance of wisdom rather than the real thing. He was not wrong. The trained memory of oral culture — the capacity to hold an epic poem or a body of law in your head — genuinely atrophied. We traded it for literacy, and literacy bought philosophy, science, and the common law.

The pattern has repeated on schedule ever since. Calculators reached classrooms in the 1970s, and a generation of parents was warned that numeracy would die. It largely did, at least the mechanical kind; almost nobody now does long division for a living, and nobody mourns it. GPS arrived, and spatial reasoning measurably declined — there is research associating habitual turn-by-turn navigation with weaker spatial memory. The losses in each case were real. Jun is honest about the costs of offloading, so the response should be honest too: this is not a story where the worriers were simply wrong.

What the worriers missed is what happened next. Each time, the freed capacity moved up a level, and the surrendered skill quietly stopped mattering. Every skill you maintain has a carrying cost — the practice hours required to keep it sharp, paid from a fixed budget of attention. The useful question about any capability AI can now perform is not “are we losing it” but “is it still worth its carrying cost.” Sometimes the answer is yes: writing-to-think survived the word processor, because the value was never the typing. Sometimes the answer is no, and pretending every loss is an erosion of self collapses a judgment call into a panic.

The autonomous baseline never existed

Her framing carries a quieter assumption: that before AI, we were forming our own desires. Mostly, we were not. The music was chosen by Spotify’s recommendation engine, the restaurant by an aggregate of strangers’ reviews, the shoes by a marketing budget, and the opinions — more than anyone likes to admit — by an engagement-ranked feed. Ken Liu’s “The Perfect Match,” the 2012 short story Jun builds her essay around, was not a prophecy about large language models. It was a barely exaggerated description of the recommendation systems we had already accepted.

Jun asks exactly the right question: who is making the final decisions for the things that matter in your life? But the honest pre-AI answer was rarely “me, unaided.” It was a network of delegations we never audited, because none of it looked like delegation. It looked like convenience.

Against that baseline, an AI assistant is a strange place to plant the flag, because it is the first delegate in the chain you can actually interrogate. Ask Claude why it recommended something and you get reasons — reasons you can push on, disagree with, and overrule. Try asking the TikTok algorithm why it fed you what it fed you. An articulate delegate carries its own risk; a confident explanation can persuade when it should not. But a delegate that shows its reasoning at least makes review possible. The feed never offered that. Measured honestly against what it replaces, this is the first delegation mechanism in twenty years that hands any autonomy back.

Delegation is a discipline

Most of my job is delegation. I lead development teams and a project management office at a national law firm, and very little that matters ships from my own hands anymore. Nobody describes this as a loss of capability. A director who insists on doing everything personally is not more capable than one who delegates well — they are less, and every organization knows it. Deciding what to hand off, with how much context, and how tightly to inspect what comes back is high-order judgment. It may be the highest-order judgment the AI era pays for.

The legal industry has run on this discipline for a century. Associates draft; partners review; the partner’s name goes on the opinion. Nobody argues that the partner has surrendered their autonomy to the associate. The profession also knows precisely what the failure looks like, because it has a name for it: the partner who signs without reading. The failure was never delegation. It was delegation without a review loop.

Read Jun’s essay through that lens and her best moment confirms it. In Portugal, she and her sister wondered why the country celebrates explorers the United States would call colonizers. Her sister reached for ChatGPT; Jun suggested they think first. They speculated, disagreed, backtracked — and only then asked the AI, using its answer to test and extend hypotheses they had formed themselves. That is not resistance to offloading. That is a review loop, run well. Her mother’s physics students, meanwhile, pasting assignment questions into a chatbot and submitting the output unread, are the partner who signs without reading. Same technology, opposite disciplines. What separates them is not how much thinking was offloaded. It is whether anyone reviewed what came back — an operating problem, and operating problems are trainable. Organizations worried that AI will erode their people’s judgment should be training exactly this muscle: what to delegate, what to hold, how to review.

The line that deserves the worry

One part of Jun’s argument deserves to be granted in full. There is a real difference between delegating task execution and delegating desire formation. “Draft this memo” is delegation. “Tell me what to want from my career” is something else, because if you outsource the wanting, no one is left standing behind the review loop. A reviewer needs preferences of their own to review against.

But this is not a new problem arriving with a new technology. We already share our desire formation with other minds that hold opinions about what we should want — mentors, spouses, consultants, therapists. A good mentor absolutely tells you what to think, and sometimes what to want. Centuries of social practice taught us to take that input as input: to hold advisers at the distance where they inform the wanting without replacing it. We also recognize instantly when the line fails — the mentor who dictates, the consultant who decides for you. The skill of holding that line exists. It survives, like any skill, only if it is practiced. That is Jun’s real warning, and it stands stripped of its fatalism.

The Microphone Man is genuinely alarming, but the microphone is not why. He is alarming because he announced, cheerfully, that his review loop is closed — the AI is smarter, so the AI does the thinking now. Socrates’ alarm about writing was real too, and the answer was never to stop writing things down. It was to remain the kind of reader who checks. That is still the answer. Delegation without review is not offloading your thinking; it is abdicating it. And abdication was never the tool’s decision to make.

Read Yennie Jun’s original essay, Are we offloading too much of our thinking to AI? — it is the strongest version of the worry, and it deserves the argument. If the operational side of AI adoption is your beat, subscribe; it is the only thing I write about.

A trustworthy machine and a trustworthy employee need the same six things. A United Nations standards body spent this month naming them for machines. Enterprises named them for people years ago and filed the whole discipline under access management.

Here is what actually happened. The ITU — the International Telecommunication Union, the UN agency that has set the rules for how machines talk to each other since 1865, back when the machines were telegraphs — opened a focus group in July on trust and identity for AI agents. Its agenda names what a trustworthy agent has to account for: identity, authority, delegation, human oversight, accountability, and provenance. The first working meeting is in Paris in November, the second in Geneva in January. Treat that as a new frontier and the honest move is to wait — let the standards body convene, deliberate, and eventually tell you what a trustworthy agent is.

Treat it as an operator and the list stops the wait cold. You have seen every item on it before.

You already run this system

Read the agenda again with an IT lens instead of a policy one and it resolves into something ordinary:

• Identity is a credential — the verifiable answer to “who is this.”

• Authority is permissions — can it spend, sign, send, move money.

• Delegation is the grant record — who handed over the access, and who can take it back.

• Oversight is an approval gate — the step where a human has to say yes.

• Accountability is knowing whose name is on the action when it goes wrong.

• Provenance is an audit log — the trail that lets you reconstruct what happened.

That is not an emerging governance discipline. It is identity and access management, the practice every regulated enterprise has run for its people for years — the joiner-mover-leaver process, the role-based permissions, the quarterly access review, the audit trail the regulator asks to see. A UN body did not describe a new problem. It described your IAM program and pointed it at a new kind of user.

The maturity of that program was always measured by one question: can you say, without a two-week fire drill, who can touch a given system and why. Most enterprises can answer it for their people, at least on paper. Almost none can answer it yet for the agents they have already switched on.

Why it feels new anyway

The reason the list reads as novel is that we built every piece of it around a human being, and the human quietly did half the work.

A person authenticates, gets permissions scoped to a role, and then supplies the one thing the access model never had to encode: judgment. A lawyer with full reach into the document system does not open every matter she can technically open. She knows which files are walled off, which client would object, which situation calls for asking first. The permission set was never actually safe on its own. It was safe because a person with context and something to lose sat behind it.

An agent inherits the access and brings none of the judgment. Spin one up inside that same document system and it has the lawyer’s reach with none of the lawyer’s restraint. It will do exactly what its permissions allow, at machine speed, and nothing in it will pause to ask whether that was wise. The credential still resolves. The permissions still check out. The judgment that made them safe is simply gone.

That is the only genuinely new fact in the whole affair. Not identity, not authority, not audit. The actor holding the permissions no longer comes with a person attached.

You don’t have to wait for Paris

Some of this work does need the standards body. When your agent has to prove itself to another company’s agent across an organizational boundary — no shared HR system, no common directory, no one who onboarded them both — you need an agreed way to exchange and verify identity and authority. That is real, it is genuinely new, and it is what Paris and Geneva are for. The scientists advising the UN keep making a related point: the capability is running ahead of the evidence base the policy needs. A standards process moving at the speed of a November meeting will not hand you a safe agent next quarter.

Inside your own walls, you are not waiting on anyone. The six requirements are your existing access model, made explicit for an actor that supplies no judgment of its own. This is what “AI without operations is just a demo” looks like at the scale of a single agent: the demo is the capability, and the operations is the access model you write down around it.

You provisioned people out of habit — a role, a template, an approval, done. You have to provision an agent on purpose, in writing: state what it may touch, what it may never touch, where a person has to approve, and whose name answers for it when it goes wrong — the developer who built it, the team that deployed it, or the human who was supposed to be supervising. The implicit rule has to become an explicit one, because the thing holding the access will follow the letter of what you wrote and none of what you assumed.

What the agent is actually for

Here is the part worth sitting with. The agent is not the thing that needs governing. It is the thing that finally forces you to write your governance down.

For years “allowed” meant “technically permitted, and trusted not to abuse it” — and the second half of that sentence lived in people’s heads, never on paper. An actor with no judgment turns that unwritten half into a specification you have to author, review, and own. The uncomfortable gift of agents is that they make you say, in writing, what you always meant by access.

A UN focus group can define what trust between agents should look like across the industry. It cannot write down what “allowed” was always supposed to mean inside your organization. Only you can — and now, for the first time, you have a reason to. The six things that make a machine trustworthy were never really about the machine. They were about the discipline you already had, and finally have to put in writing.

If this landed, the earlier posts in this thread — on why your agent inherits your lawyer’s permissions, and why least privilege is the only sane default — are on my LinkedIn. Subscribe here to get the next one on operating AI, not just deploying it.

My own provincial government just published a manual for the part of AI adoption that almost everyone skips. In June, the Government of Alberta released twenty-one white papers describing how it is rebuilding four decades of public technology with a workforce of AI agents. The papers lead with numbers built to be doubted: a twenty-five-year-old benefits application rebuilt in four days instead of five months, a new public system delivered in eleven weeks for roughly $108,000 against a traditional estimate near $1.9 million, and a stated goal of cutting the cost and time of building government software by ninety-five percent.

Read the numbers, raise an eyebrow, move on. That is the reasonable response, and it misses the actual story. The results Alberta is reporting did not come from the AI. They came from the operations the province built around it. And the operations are the one thing a vendor cannot sell you.

The vendors were half right

One of the papers is a first-person account from Chris Wright, a director who spent years managing technical-debt work and legacy integrations. In his conversations with vendors, he kept hearing the same message: AI has significant limitations for this kind of work. He was skeptical of the claim but had nothing concrete to argue with, because he had never used the tools at any depth himself.

So he tested it on something he knew cold. Twenty-five years ago he wrote the Remote Area Heating Allowance application for Alberta Agriculture, by hand, in Java. It took five months. It is still running today. He put it through Alberta’s build process and rebuilt it in four days, and the new version does more than the original, including a public-facing portal the first one never had. He wrote the original code, so he could judge the output with direct knowledge of what it was supposed to do. The quality held.

That one was a prototype, a proof of capability. The harder proof is the Alberta Classroom Information Portal, a genuine enterprise system for principals and teachers, carrying the full weight of privacy protection, security review, identity management, and production infrastructure. It went live in June. It was delivered in eleven weeks for about $108,000, against a traditional estimate of $1.3 to $1.9 million and a timeline north of a year. It is not a tool anyone could afford to get wrong, and it was held to the same bar a traditional product team would have to clear.

The vendors were not exactly lying. Twelve months earlier the models could not have done this, and honest vendors were describing the tools as they were. But they got the deeper thing wrong. They were talking about the model, and the model was never where Alberta’s advantage came from. The model was the easy part.

What a vendor cannot sell you

Alberta is unusually direct about this. Their coding work is model-agnostic by design. Claude is their current preference, but they say plainly they expect that lead to change, and they have built everything so it can. In their own words, the intellectual property of what they call the “harness” matters more to the outcome than the specific model underneath it.

The harness is not exotic. It is a short file of project rules the AI reads first, a library of small instruction sets they call skills, and a near-perfect reference application the AI is told to copy. More than a hundred of the decisions a public system has to get right, how a user signs in, how input is validated, how secrets are stored, are made once, in that template, before any project begins.

The reason they needed it is worth understanding, because it is the reason most AI pilots quietly disappoint. Left to itself, the same model given the same request twice produces two different applications, with different layouts and different decisions underneath. Two capable people using the same tool diverge just as far. The prototypes came fast and looked finished, and then the months saved on the front end were lost on the back end, fixing the security and accessibility gaps the demo had hidden. None of that was a failure of the model. It was the absence of a defined way of working.

They are also blunt about the cost of building the fix. You cannot produce a good harness casually or at speed, they write, and every version copied from a copy degrades. One of the case-study authors put it more plainly still: more work went into building the factory than into getting the applications out the other end.

That sentence is the whole argument in miniature. What Alberta built was not software. It was encoded judgment, the standards and decisions and taste that normally live in a senior engineer’s head, written down so that a machine, or a novice, applies them the same way every time. A model you can buy, and its edge expires on someone else’s release schedule. Encoded judgment is yours, and it compounds. In a law firm, the equivalent is not a better contract tool. It is the risk posture, the house style, and the hard-won preferences a senior partner carries by instinct, finally written down where they can be applied at scale, and checked.

The standards no one had written down

Before Alberta could rebuild anything, it had to see what it actually had. So it pointed a tool it calls Git Insights at its entire code estate: about fifty agents reading 466 million lines across roughly 3,400 code repositories in around twenty hours, for under $2,000. No consultant engagement comes close on time or cost.

The finding that should travel furthest has nothing to do with speed. Across eight years and 8,178 contributors, Alberta’s software met its own standards completely on first release only forty percent of the time. The rest needed rework.

Their reading of that number is careful, and I think it is correct. This was not a story about lazy or unskilled people. The contributors were capable and hard-working, and most of the code was sound when it shipped. The problem was systemic. The standards were aspirational rather than prescriptive, inconsistently communicated, and silent in the contracts themselves. Where the rules are undefined, capable people make their own reasonable choices, and thousands of reasonable choices over eight years become drift. They compare the result to a medieval city, every building sound on its own terms, the whole grown dense and hard to cross.

There is a fairness in how they handle this that I want to underline, because it is rare in AI writing. We remember the one time an AI gets an answer wrong and forget the ten thousand times it was right, and we almost never hold human performance to the same standard in the same breath. Alberta did. It measured its own people honestly, at a scale no manual review could, and it credited them: the creativity, the judgment, and the work that no model produced. No AI dreamed up Git Insights. A person did.

This is the part most organizations will recognize if they are honest. The lesson is barely about AI at all. Most companies do not have an AI problem. They have an undocumented-standards problem, and AI is simply the first tool sharp enough to make the gap visible and then to close it. Alberta draws the comparison to a car plant: we would not accept a factory where forty percent of the vehicles left the line passing their safety checks. We hold software to a lower bar mostly because, until now, we could not see the number. AI did not fix the standard. It made the gap countable, and then it made the standard enforceable.

Compliance moved to the front

The enforcement is the most interesting mechanism in the collection. Alongside the build sits a set of review agents Alberta names by color. One checks code quality and hygiene. One reads the prose for the tells of machine-written text. One attacks the finished application from the outside, the way an intruder would. One works through the defensive checklist. Together they run more than 400 individual checks, including 285 requirements from an international security standard and 62 of Alberta’s own cloud-security rules, and they run continuously, as the application is built, for pennies each time.

The consequence is a real inversion. By the time the cybersecurity team sits down to review an application, it is already compliant, with the evidence attached. In one training cohort, a hundred public servants, most of whom would never have called themselves engineers, produced more than 560 working applications in six days, and the strongest cleared the cyber review and the accessibility check on first release. Compliance moved from the last gate to the first, and it now runs on every change instead of once at the end under deadline pressure.

There is a line buried in the technical papers that I keep returning to: you cannot be accountable for a process you have not defined. That is the quiet argument under the whole security model. Left undefined, the work happens inside the model’s private and probabilistic reasoning, and you gain speed while losing any real understanding of how the result was reached. Written down as skills, the same expectations become standard operating procedure, applied the same way every time and auditable after the fact.

For anyone working in a regulated business, this is the line to sit with. The same collection describes a pipeline that took one Alberta act and benchmarked it against the equivalent statutes across fourteen jurisdictions for about $200, with every finding traceable back to the exact clause it came from. Comparative statutory analysis that would take a team months, done in an afternoon and defensible down to the line. The speed is the least of it. The real change is that a control you used to run once, expensively, at the end, now runs continuously, for the price of lunch.

The bottleneck moved to us

Speed like this breaks the tools we use to manage work. On the coding task alone, Alberta measures the AI at well over a hundred times a human developer’s pace, and they are candid that traditional estimation collapses as a result. An AI has no reliable sense of how long a human would take, and a human has no reliable sense of how fast the AI will move. Planning poker stops meaning anything.

So they built a delivery tool that runs a kind of chess clock between the person and the AI, tracking who is holding the work at every step. The finding is uncomfortable and worth repeating. When a project misses its target, it usually has little to do with the AI. The AI finished in an hour; the person took a week to look at it. The delay lives in the handoff.

Their most ambitious paper follows that thread all the way down, and it is the one I would press on a fellow leader. It treats the org chart as a compression algorithm, a way of squeezing ground truth up through the layers so it fits inside a senior person’s attention, and then hydrating strategy back down into local action. A person conveys meaning at roughly forty bits a second. A model works orders of magnitude faster. Hold every interaction to human speed and you leave most of the gain on the table. In a human hierarchy you want one manager for every several workers; in an agentic one, the ratio may invert, with several supervising agents auditing every worker that builds. Their conclusion is bracing: the twentyfold improvement they are chasing is not achievable while keeping the org chart, the briefing note, and the approval chain exactly as they are. The hierarchy has to be rebuilt at the same time as the technology, or the old process quietly eats the new speed.

The operating lesson is simple to state and hard to act on. If an AI pilot did not save much time, the tool is probably not the problem. Look at the wait between the work, not the work itself. The model got faster. The organization around it did not.

Measure capability, not savings

Which raises the question of how you would even know you were winning. Alberta’s answer is the most quietly radical idea in the whole set, and the one I would steal first. Do not measure the program by the money it saves.

Their reasoning is hard to argue with. Continuing to do exactly the work you do today, just with fewer people, banks a one-time saving and forfeits the larger prize: an organization that can do things it could not do before. So they judge the work against three measures instead. Readiness, meaning whether the organization can actually carry the change, from staff skill to governance. System health, meaning whether the estate is getting safer and smaller rather than sicker and larger. And cost, counted honestly across the whole of government rather than shifted from one budget line to another.

The line that stays with me is their own: continuing the same work with fewer staff is folly. It reframes the entire exercise. The point of the harness, the standards, and the factory is not a cheaper version of the current output. It is a larger capability, measured by what the organization can now attempt. Dollars saved is the metric that makes an AI program look successful while leaving it exactly where it started.

What none of this ships in

Set the pieces side by side. The harness of encoded judgment. The standards finally written down. The compliance gates running on every change. A way of measuring delivery that catches the human handoff instead of hiding it. A measure of success built on capability rather than savings. An academy that put thousands of public servants and more than ten thousand members of the public through structured training. None of it arrives in a license. No vendor sells it, because no vendor can. It is made of one organization’s own rules, its own work, and its own judgment about what “good” means.

Alberta’s sharpest strategic move follows from that. Rather than centralize all software delivery or scatter it, they propose holding the protective core at the center, the security, identity, and data rules, while opening the actual building out to the people who understand the work. The center stops being the place software is delivered and becomes the place software is governed. The alternative is not a tidy status quo. It is shadow AI, built outside the fence with none of these controls, which arrives whether it is sanctioned or not. Their instinct for what a leader should buy is the same everywhere in the collection: stop buying chat conversations, and start building the pipelines and the standards that outlast the question you asked today.

Skepticism is still warranted, and Alberta invites it. These are self-published papers, and their numbers deserve interrogation. The largest claims, the ninety-five percent and the twentyfold, are targets at least as much as they are settled results. Some of what works in a government estate of unclassified legacy code will not transfer cleanly to a firm handling privileged client data. But the method is legible, the smaller numbers are concrete and consistent, and the method is the point. Alberta’s real product was never the applications. It was the capability to produce them, and they published the manual for building it.

The operations are still on you

The models will keep getting cheaper and better on a schedule none of us controls, which is exactly why the model is the commodity in this story. The operations will never be a commodity, because they are built out of your own judgment, and no one can hand you that.

AI without operations is just a demo. Alberta spent eighteen months building the operations, then gave the manual away. The building is still on the rest of us. You can download their manual this afternoon. You will still have to write your own.

If this was useful, subscribe. I write about the operational side of AI, the part that never fits inside a product demo. The Velocity White Papers are public at thevelocitywhitepapers.com, and they are worth your time.

Zack Shapiro’s The Two Clocks is the most accurate account of the AI-and-law problem I’ve read from anyone standing outside a firm. His argument, in one line: AI capability has raced years ahead of the institutions meant to use it, and the gap between the fast clock of the technology and the slow clock of the firm is the real story. Most of what follows is agreement. The rest is what that picture looks like from inside one, where I run AI and innovation for a national practice and spend my days in the exact gap he names.

Start with where he’s right, because he’s right about the thing that matters most.

The bottleneck really has moved

The line I’d underline twice is his: the bottleneck is no longer the intelligence, it’s the absorption of it. That is the whole job. The capability has been good enough for real work for a while now. The deployed value hasn’t followed, and the reason isn’t the model. It’s everything around the model — the process, the supervision, the standards, the person willing to change how the work gets done.

I’ve made this argument in narrower terms. The last mile in legal has its own geography, a specific terrain of hazards that general adoption advice never names. And the productivity numbers everyone quotes come with an entry fee nobody reads aloud: the data, process, and supervision preconditions that have to exist before a 3-to-5x number means anything. Shapiro’s version — a very expensive motor bolted into the old driveshaft — is the same warning in a better metaphor. Procurement is not absorption. On that, no daylight between us.

His workshop anatomy is correct too: task, background, judgment, constraints, deliverable, verification. And the most important sentence in the essay is the one pointing out that none of it is technical. The lawyers who take to this fastest are the best delegators, not the most technical people in the building. That matches everything I watch happen.

So here are three places the view changes when you move from across the table to inside the room.

Verification is not word six. It’s the new bottleneck.

In his anatomy, verification is the last item. In practice, it’s the whole game.

When production gets cheap, the constraint doesn’t disappear. It moves. It moves to the one step that didn’t get faster: a human deciding whether the output is right enough to put a name on. And that step does not scale the way drafting does. A model can generate a hundred competent drafts in the time it used to take to write one. It cannot make a partner able to actually read a hundred.

The demo where the mood in the room changes is real. I’ve run that demo. But it’s the easy half. The hard half arrives at the second thousand documents, when the drafts are landing faster than anyone can check them and someone approves one they did not fully read — not from laziness, from arithmetic. That is a selection problem, not a review problem, and you cannot review your way out of it. Every guardrail and eval only works after a human has decided what deserves attention.

Shapiro actually hands us the reason himself. Law has no compiler. A wrong contract doesn’t crash; it sits in a drawer until it detonates. That’s precisely why verification can’t be the sixth thing on the checklist. It’s the thing the whole rebuild has to be designed around. He says the words and then walks past them.

The surplus doesn’t have your name on it

The essay’s engine is optimism about who keeps the money. The frontier labs are General Electric; the firm that rebuilds itself is Coca-Cola. Absorb the capability and the margin is yours.

From inside, that’s the claim I’d hold most loosely.

Efficiency that everyone can buy flows to the buyer, not the producer. When every serious firm has absorbed AI — which is the entire premise of a race — the production savings get competed straight through to clients. You capture surplus from what stays scarce and hard to substitute, not from speed your competitor also has. His own evidence points this way: Blackstone is already paying Kirkland less, before Kirkland has rebuilt a thing. That’s not the fruit of absorption. That’s the surplus leaving through the door marked bargaining power.

We have the wider numbers on this. Eighty-eight percent of organizations use AI in some function; a single-digit share get measurable financial impact from it, and the playbook executives are running contradicts their own data. A rising tide has never lifted all boats. It lifts the ones rigged to catch it.

None of which means don’t absorb. It means be clear about which bet you’re placing. Absorbing to keep up is survival — the table stakes, the price of still being in the game in three years. Absorbing to win is a different move, and it doesn’t run on speed. It runs on the parts that don’t commoditize: genuine judgment, and the ability to stand behind the work.

The grind was doing something

Shapiro concedes, in roughly a paragraph, that AI compresses the junior grind that used to train lawyers, and that firms will have to “design training around decision-making deliberately.” That paragraph is carrying a fifteen-year problem it can’t lift.

The grind wasn’t only what firms sold. It was the transmission system for judgment. First-pass research, first-pass drafting, the diligence nobody enjoyed — that was where instinct got built, through repetition and exposure and being wrong in front of someone senior. Take the reps away and you keep this cohort’s judgment while quietly starving the next one’s.

There’s early evidence the trade isn’t free. In one study, developers who learned a new library with an AI assistant scored worse on understanding it afterward than those who struggled through without one. Speed for skill, and sometimes you get neither. Meanwhile the judgment that survives isn’t the relaxing part of the job. It gets compressed into every minute of the day, because the easy work that used to space it out is gone. The premium is real. It’s also heavier to carry than the essay lets on, and the pipeline that produces the people able to carry it is the thing most at risk.

Some of the slow clock is the law of lawyering

One more, and it’s the one I can only say from inside.

Not all of the slow clock is cowardice and comp cycles. Some of it is the job. Privilege, confidentiality, malpractice exposure, the bar rules, the client’s outside-counsel guidelines — these gate what absorption is permitted, not just what’s possible. The Sullivan & Cromwell hallucination Shapiro cites as fear is also a genuine governance failure, and the lesson a careful firm draws from it isn’t “be braver.” It’s “build the process that makes that impossible.”

The rational firm isn’t only protecting its margin. Part of what looks like foot-dragging is protecting the client, and that part is correct. The work is to separate the caution that’s real from the caution that’s theater — and Shapiro collapses them into one. Governance isn’t the committee that slows you down. Done right, it’s the thing that lets you go fast without the filing that ends a career. It isn’t a step you finish. It’s a property of the system, maintained continuously or not at all.

What I’d keep, and what I’d add

Keep the clocks — the frame is the most useful thing published on this in months. Keep own-the-method over rent-the-wrapper. Keep absorption as the real constraint. On the shape of the problem, Shapiro is more right than anyone writing about this from the outside.

What I’d add is the part that turns his diagnosis into a defensible position. The durable moat isn’t the speed of your clock. It’s whether you can prove, on the record, that the fast work is also right — a verified, governed process a human genuinely stands behind. That’s the input that stays scarce when production goes to zero, because it’s the one thing the client can’t get from a cheaper tool or build themselves without taking on the risk they’re paying you to hold.

Absorb to survive. Differentiate on judgment and accountability to actually keep the surplus. Because absorption without verification isn’t the Coca-Cola fortune. It’s just a faster demo.

I write every week about the operational reality between an AI demo and deployed value — mostly from inside a law firm, where the stakes make the gap impossible to ignore. If that’s useful, subscribe.

The most dangerous box on an AI workflow checklist is the one labeled “governance.” Not because it’s wrong — because of where it sits.

Nate B Jones recently published a nine-step framework for agent workflows, running from context pack through human approval (gate). It’s good. The individual practices are the right ones: normalize your data, ground the model in retrieval, cite every claim, keep a human in the loop. If you’re building agents, watch it.

But the framework is linear — nine sequential steps. And somewhere in any linear list, governance becomes a step. Something the pipeline passes through once, checks off, and moves past.

That shape is the problem. Not for a startup shipping a demo. For anyone operating where the output has consequences — a law firm, a bank, a hospital, anywhere regulated — the shape is exactly backwards.

This piece lays out the restructure in full: three phases wrapped in a governance layer, the failure mode each phase exists to prevent, and the operational finding that changed how we decide what to automate in the first place.

A checklist implies an order of operations

Consider what actually has to be true for an agent workflow to survive review in a regulated environment.

Every action needs to be attributable to a human principal. Access control needs to hold when data is ingested, when it’s stored, when it’s retrieved, and when the output ships. The audit log needs to capture all of it. Data residency constraints don’t pause while the pipeline does its work.

None of those are steps. They’re properties — conditions that must hold at every step. A checklist that positions governance as step nine implies the other eight ran without it. The first serious review will ask what was happening during steps one through eight, and “governance came later” is not an answer that ends well.

Running AI inside a national law firm forces this distinction quickly. Matter-level confidentiality, client data residency, professional accountability for anything that enters the record — these constraints don’t arrive at the end of a pipeline. They’re the environment the pipeline runs in. A workflow that treats them as a checkpoint has already failed; it just hasn’t been asked the right question yet.

So the restructure: three phases, wrapped in a governance layer. The Governed Context Pipeline. Each phase answers one question, and each exists to prevent one specific failure.

Scope: what is the agent allowed to know?

The first phase happens before any data moves, which is why almost nobody does it first.

Teams start at ingestion. Connect the mailbox, pull the PDFs, chunk, embed. The energy goes into the plumbing, because plumbing feels like progress — there’s something to demo at the end of the sprint. But the expensive mistakes in agent projects happen before the first document is ingested, in the decisions nobody wrote down about what the agent may read and toward what goal.

Nate's skeleton, to its credit, starts exactly here — his first step is a context pack that defines what the agent is allowed to read. Scope is that instinct given an enforcement mechanism.

Scope is the permission boundary, defined explicitly. What sources can this agent touch? For what purpose? On whose authority? In a law firm, the answers are concrete: role-based access against the firm’s identity provider, matter-level permissions that mirror ethical walls, residency rules about which jurisdictions data can occupy. The critical design decision is where those answers live. Not in a policy memo — in the architecture. A memo describes intent. An access control list enforces it.

One rule does most of the work: the agent’s access is a strict subset of the authenticated human’s access. Never more. An agent acting for a lawyer who cannot see a matter cannot see that matter either — not because it was told not to look, but because the credential it operates under makes looking impossible.

The failure this phase prevents is the one that ends AI programs in regulated industries: the “helpful” agent that read the wrong client’s file. Once that happens, no downstream safeguard matters. You can verify the output perfectly and the breach has still occurred, because the document was never supposed to be in context at all. Scope failures are unrecoverable by design — which is why scope is phase one and not a hardening task for later.

Structure: turn the mess into addressable context

The second phase is the unglamorous middle, and it’s where most of the actual engineering lives.

Source material arrives through controlled connections — not ad-hoc exports, not someone’s downloads folder. Large documents get chunked into tagged, addressable pieces, so a five-hundred-page record becomes something a retrieval system can point into with precision. Normalization turns unstructured mess into a clean schema: dates become dates, amounts become amounts — Nate's phrase, and exactly the right one — parties become parties. Storage stays secure and localized, holding whatever residency promise was made in scope. And retrieval works by similarity against that normalized store, pulling exact language with file references attached.

That last property deserves a sentence of its own, because it’s the entire epistemology of the pipeline: the agent works from retrieved fact, not remembered vibes. A model answering from its training data is recalling an impression of the world. A model answering from retrieval is reading a specific paragraph of a specific document it can name. Everything defensible about the output rests on that difference.

Two operational realities about this phase, both learned the slow way.

First, normalization quality is gated by input quality. The hardest inputs aren’t exotic — they’re handwritten documents, OCR’d scans, and sources whose formatting drifts from one custodian to the next. No amount of clever prompting upstream fixes a date field that arrived as a smudge. That makes normalization permanent iteration work, not a solved step, and any plan that treats it as a one-time migration is a plan for disappointment.

Second, normalization is deliberately isolated as its own step so it can be improved without touching anything else. Ingestion doesn’t change. Retrieval doesn’t change. The normalizer gets better every month on its own schedule. That’s not pipeline trivia — it’s the design decision that lets the boring part compound.

The failure this phase prevents: plausible-sounding output grounded in nothing. Skip the structure work and the agent still answers — that’s the trap. It answers fluently, confidently, and from nowhere.

Sign-off: defensible, not just plausible

The third phase is where the output earns the right to be relied on. Four operations: cite, verify, export, gate.

Cite means every generated claim maps to a specific paragraph in a specific source document. Not “according to the file” — this claim, that paragraph. The receipt. Citation is what converts an assertion into something checkable, and its real function is economic, which matters enormously later in this piece.

Export means the output ships as a structured review packet — a timeline, a list of identified gaps, a draft summary — rather than a wall of chat text. The reviewer gets an artifact organized for review, not a transcript to spelunk.

Gate means the hard stop. The AI cannot send, submit, file, or finalize. Ever. An authenticated professional reviews the citations and approves, and the approval is what moves the work forward. The gate is architecture, not policy — the capability to act simply doesn’t exist in the agent’s permission set.

The failure this phase prevents: an AI output entering the record with no human fingerprints on it. In a profession where a person is accountable for everything that goes out the door, that failure isn’t an embarrassment. It’s a structural breach of how the profession works.

But there’s a subtlety inside sign-off that most pipelines miss, and it’s the difference between having receipts and having proof.

Four ways a citation fails

A citation is an assertion, not proof. Audit the receipts in a real pipeline and they fail in four distinct ways:

1. Hallucinated — the source doesn’t exist. Rare in a grounded pipeline, but it’s the failure everyone knows about, because it’s the one that makes headlines and sanctions orders.

2. Semantically wrong — the source is real, but it doesn’t mean what the model thinks it means. The claim and the paragraph are both genuine; the relationship between them is not.

3. Missing — a claim that should carry a citation doesn’t, and slides through as connective tissue.

4. Duplicated — one source quietly does double duty across several claims it only partially supports.

The second failure is the dangerous one, because it survives a spot-check. The document exists. The link resolves. The reviewer clicks through, sees a real paragraph in a real filing, nods, and moves on. Every superficial signal of groundedness is present, and the meaning is wrong. Hallucination checks — “does this source exist?” — catch the first failure and are completely blind to the second.

Which is why verification is its own operation with its own tooling, not a byproduct of citation. Checking that a receipt exists is string matching. Checking that the receipt supports the claim it’s attached to is an entailment judgment — and it has to be performed against every claim, not a sample you hope generalizes. Hand that judgment to humans and you’ve rebuilt the verification labor the pipeline was supposed to reduce. Hand it to a second model and you’ve created a new set of judgments that themselves need calibrating. That recursion is why this is the live edge of the work right now. Nothing about it is finished, and it’s harder than any layer of the stack that gets talked about more.

The wrapper is the argument

Around all three phases sits the governance layer — and here is where the restructure stops being a diagram preference and starts being the point.

Four properties, held everywhere: identity, so every action is attributable to a human principal; access control, enforced at every phase rather than checked once at the door; audit logging, immutable, capturing prompts, actions, and approvals — which means compliance reporting comes free instead of being a quarterly archaeology project; and residency, holding through every phase including retrieval, because a vector store in the wrong jurisdiction is a residency violation no matter how well-scoped the ingestion was.

The difference between a step and a property sounds like semantics until you watch it decide an architecture. Treat governance as a step and you get a pipeline with a compliance checkpoint — one gate, at one position, inspecting whatever reaches it, trusting that nothing leaked before inspection. Treat governance as a wrapper and the questions change shape entirely. Not “did the output pass review?” but “was there any moment when this agent could act outside its principal’s identity?” Not “is there an audit trail?” but “is there any action that could have escaped it?”

And every one of these properties maps to something you can point at in a real enterprise environment. Residency is the cloud tenancy itself — region-pinned storage and compute that physically cannot host data elsewhere. Identity and access control bind to the same enterprise identity provider the humans authenticate against, so the agent inherits the org’s permission model instead of maintaining a parallel one. The connectors that bridge into document management systems carry those permissions through rather than flattening them. If a team presenting an agent architecture can’t point to where each property is enforced, the property isn’t held — it’s hoped for.

The wrapper turns governance from an inspection into an invariant. None of it is a policy document. All of it is architecture. That’s the part linear framings underplay, and it’s the part that determines whether the system survives contact with a regulator, an opposing counsel, or your own risk committee.

Governance isn’t step ten. It’s the box the other nine steps live inside.

The economics of the gate

Everything so far describes how to build the pipeline correctly. This section is about when not to build it at all — and it comes from the finding that reshaped our automation decisions more than any technical result.

The gate is not free. Put an AI workflow in production with a human verification gate at the end, and in some workflows the verification consumes as much time as the manual process it replaced. The automation produced its output in seconds; the checking of that output ate the savings. Net time recovered: approximately nothing.

The accounting is actually worse than break-even, because of who does the verifying and what they know. A person doing the work manually verifies as they go. Checking is amortized across authorship — every choice is checked at the moment it’s made, by the person holding the reasoning behind it. The verifier at a gate reads cold. They weren’t present during creation, they don’t hold the reasoning, and they’re reconstructing intent from the artifact alone. The pipeline didn’t eliminate the verification labor. It relocated it — and handed it to someone in a structurally worse position to perform it.

Peter Naur described the underlying mechanism in 1985, in “Programming as Theory Building”: the real substance of built work is the theory in the builder’s head, and the artifact doesn’t carry the theory. Programmers are rediscovering this at scale right now, reviewing AI-generated code they didn’t write and can’t cheaply validate. It generalizes to all knowledge work. The gate asks a human to recover a theory from an artifact, which is the expensive direction.

Out of that comes the selection criterion — the most useful sentence this pipeline has produced:

Automate where verification is asymmetric. Where checking is structurally cheaper than producing: confirming a citation points where it claims, validating an extracted date against the source, checking a sum. In those tasks the gate is fast, the machine does the production, and the economics genuinely work.

Where verification is symmetric — where “is this right?” can only be answered by re-deriving the judgment — the pipeline saves nothing. “Does this summary capture what matters across these files?” has no shortcut; answering it honestly means reading the files, which is the work the summary was meant to replace. The honest architecture in those cases moves the human upstream, into the creation loop, steering while the work is made, rather than stationing them at the gate to reconstruct it afterward.

Notice what this does to the phases you’ve already read about. Cite and Export aren’t decoration — they exist precisely to convert symmetric verification into asymmetric verification. A claim with a paragraph-level receipt can be checked without re-deriving it. A structured packet with a stated timeline and gap list can be reviewed without reconstructing it. When that conversion succeeds, automation pays. When it fails — when the receipts still can’t make checking cheap — the task was a bad automation candidate, and no amount of pipeline sophistication rescues it.

Where it breaks

A framework that claims no limits is marketing, so here are this one’s, stated plainly.

Normalization never finishes. Input quality gates everything downstream, the worst inputs are the ones humans produce most casually, and the phase is permanent iteration work dressed as a pipeline step. Budget for it accordingly — in attention, not just money.

Semantic verification is unsolved. The four-failure taxonomy tells you what to look for; it doesn’t hand you a tool that finds failure mode two at scale. The honest status is: active work, real tooling, no finish line in sight.

And the framework governs context pipelines — agents that read, ground, and draft. It says nothing about model selection, nothing about fine-tuning, nothing about the dozen other decisions an AI program has to make. It’s a load-bearing wall, not a whole house.

What it does do is give a leadership team a shape to reason with. When the next agent proposal lands, the questions write themselves. What’s the scope, and where is it enforced? What does the structure work cost, and who maintains it? Is verification asymmetric, or are we about to relocate labor and call it savings? Can any action escape the wrapper?

The checklist wants you to ask “what’s the next step?” The better question is “what has to be true at every step?”

Draw the box first. Then build what runs inside it.

On LinkedIn this week I’m walking through one phase of this framework each day — compressed versions of the arguments above. This article is the destination they point back to; there’s nothing else to keep up with. If someone forwarded you this, you can subscribe at andrewlewis.ca.

The teams that raise their hands for AI are almost never the teams that generate the revenue. That gap is easy to miss, because enthusiasm looks like traction. Most of the time it isn’t.

Enthusiasm Is a Real Signal

Building for the excited teams first is the obvious move, and for good reason. When a group asks for an AI workflow, they’ve already done half of the change-management work on your behalf. They tolerate a rough first version. Feedback comes back as a note, not a complaint. They volunteer as pilots, forgive the bugs, and — when something finally works — turn into the internal reference you point every skeptic toward.

None of that is a mistake. Friction is the tax on every internal tool, and a willing team pays it without being chased. If you’re standing up an AI practice from nothing, the enthusiasts are how you get a first win on the board before the budget conversation turns hostile. Following demand is a defensible way to start, and anyone who tells you to ignore your most eager users has never had to earn credibility inside an organization that didn’t ask to be changed.

But Enthusiasm and Revenue Aren’t Correlated

The problem surfaces a quarter or two later, when you look at where the effort actually went. In most firms — ours included — a small number of practice groups generate a disproportionate share of the revenue. The litigation teams, the corporate groups, the ones running the largest matters against the tightest deadlines. Those are rarely the people sending the eager Friday-afternoon note about a tool they just read about.

So the work flows one way and the money sits in the other. You can ship six workflows to the teams that asked, run clean pilots, post healthy adoption numbers, and still not have touched the part of the business that pays for all of it. That’s the trap. Every one of those workflows is genuine effort. None of it is evidence that you moved the number that matters.

This is the difference between activity and value, and it’s the easiest distinction to lose when the activity feels good. Adoption dashboards count seats, sessions, and logins — motion. They don’t ask whether the motion is pointed at anything. A number that goes up is not the same as a number that matters, and most AI programs are measured almost entirely on the first kind.

Measuring value would mean asking a harder question: did this workflow change the economics of work that actually bills? Hours returned to a partner on a live matter. Cycle time cut on the review that was holding up a deal. A junior freed from the mechanical first pass so the expensive judgment happens sooner. Those numbers are harder to collect and easier to argue with, which is exactly why programs quietly settle for seat counts instead. The metric you can gather in an afternoon wins over the metric that would tell you the truth.

The Path of Least Resistance Has an Org Chart

Effort doesn’t drift at random. It follows inbound. The teams that email you become the teams you build for, and the teams that email you are the ones already sold on the premise — which means your roadmap gets quietly authored by whoever is most curious, not whoever is most valuable. Nobody decides this in a meeting. It’s the default that takes over when no one sets a different one.

There’s a compounding effect, too. The enthusiast team you served becomes your best case study, so the next enthusiast team hears about it and comes to you, and the flywheel spins entirely inside the low-stakes tier of the business. Each turn feels like momentum. From the inside, a roadmap driven purely by inbound is almost indistinguishable from one driven by strategy — right up until someone asks what it did for the P&L, and the honest answer is a list of teams that were already going to be fine.

The Honest Version of the Other Side

There’s a real counterargument here, and it deserves its full weight rather than a quick takedown. Maybe building for the enthusiasts first isn’t misallocation at all. Maybe it’s sequencing.

You don’t want your first agentic workflow to fail inside the litigation group three days before a filing. The high-revenue teams are precisely the ones who can least afford a broken tool, a hallucinated citation, or a process that quietly drops a step — the stakes that turn a rough pilot into a client problem. Testing on the small, willing groups is how you surface those failures somewhere cheap. You build the muscle, harden the process, and earn the right to walk into the room where the work is unforgiving. Under that reading, the enthusiasts aren’t a distraction — they’re the rehearsal.

That argument is genuinely persuasive. It’s the strongest defense of enthusiasm-led rollout there is, and in a regulated environment it’s often the correct call. Which is exactly what makes it dangerous, because it’s also the perfect cover for never getting to the hard rooms at all.

The Line Between Sequencing and Drift

Sequencing and drift look identical for the first two quarters. Both have you shipping to willing teams and posting good numbers. The only thing that separates them is whether you can name the crossover.

If it’s really sequencing, you can answer three questions today: which revenue group you’re piloting toward, what has to be true before you bring the workflow to them, and roughly when. If those answers don’t exist — if the enthusiasts are simply where the work keeps landing because that’s where the work is easy — then “we’re de-risking first” isn’t a strategy. It’s the story you tell about drift after the fact.

Naming the crossover forces a second, uncomfortable admission: some of the enthusiast pilots you’re proudest of were never going to move the P&L, and were worth doing only as practice. That’s a fine reason to build something. It’s a poor reason to keep building in the same place once the muscle is there.

The discipline is almost embarrassingly plain. Before a pilot starts, write down who it’s for and what graduation looks like. A pilot with a named destination is a sequencing plan. A pilot without one is a hobby that happens to have a roadmap attached. AI without operations is just a demo — and a rollout that only ever serves the people who asked is just enthusiasm with a dashboard.

Enthusiasm tells you where it’s safe to begin. Never let it decide where you stop.

New here? Subscribe for field notes on making AI actually operational inside a real organization. If this one landed, forward it to whoever owns your AI roadmap — the person deciding which team gets built for next.

Every access control system you have ever run carried an assumption it never bothered to write down. The assumption was that a human being would be standing at the moment of action, deciding whether to actually go through with it.

That assumption is so deep we stopped seeing it. We talk about permissions as if they were the control. They were never the control. The control was the person — the one who had the access, noticed the request was strange, hesitated over the unfamiliar recipient, and chose not to send. The permission set drew the outer wall. Human judgment did the real work inside it, quietly, every single day, for free.

Agents inherit the wall. They do not inherit the judgment. And the moment that happens, a lot of governance that felt solid turns out to have been resting on something we never accounted for.

The contract nobody signed

Least privilege is usually explained as a defense against malice. Give people only the access their job requires, so a bad actor — or a stolen credential — can do less damage. True enough. But that framing hides the part that actually carried the weight.

Most people in most organizations are over-permissioned, and it almost never matters. A paralegal can probably open far more of the document system than any single matter requires. A developer can usually reach systems they have not touched in a year. We tolerate that gap between granted access and needed access because a human sits in it, applying discretion at the point of use. The gap is wide, and the judgment is what keeps the width from being dangerous.

That is the contract nobody signed. Access can be loose because judgment is tight. Take the judgment out of the moment of action, and the looseness you have lived with comfortably for twenty years becomes the exposure.

What the agent removes

Consider what Microsoft’s Copilot Cowork can do once it is running in someone’s context. It drafts and sends email, creates and edits and deletes documents, posts in collaboration channels, searches across the enterprise, and reaches the document system through the same connectors a person uses. It does all of this as the user, with the user’s permissions, not a narrower set of its own.

To Microsoft’s credit, it pauses before the riskiest actions and asks for approval, with a risk indicator attached. That sounds like the missing judgment, restored. It is not. The approval is one click, it leans on the same human attention least privilege already assumed, and it never changes what the agent is able to reach. Ask a person to approve twenty actions a day and you have not added judgment — you have manufactured a reflex. The prompt becomes a turnstile that everyone learns to push through.

This is not a worry confined to my own corner of the world. A 2025 Cloud Security Alliance survey of 445 security professionals found that ninety percent of deployed AI agents carry more access than their assigned task requires, and nearly half of organizations had already experienced a security incident involving one. The over-permissioned agent is not the edge case anyone is bracing for. It is the normal state of deployment.

From governing files to governing the factory

There is an idea moving through software circles that you are no longer building the product, you are building the factory that builds the product — and that you have to govern the factory accordingly. The same shift is happening to ordinary professional work. Increasingly the thing you build is not the document or the policy. It is the process, and the agent, that produces them.

Once you see governance that way, least privilege stops being an IT setting and becomes a design decision about the machine. You are no longer asking what a given person should be able to do with a given file. You are asking what the agent — its tools, its reach, its standing permissions — is structurally allowed to do with every file it can touch. The security community is converging on the same point from its own direction: the OWASP work on agentic applications now frames the goal as Least Agency — autonomy that is earned, scoped, and bounded, rather than granted by default because the underlying account happened to have it.

The instinct, having seen all this, is to lock everything down. Resist it. Maximal restriction kills the serendipity and cross-pollination that made these tools worth adopting in the first place. The discipline is to draw the line at the boundary of what a role would ever genuinely need — and to leave a deliberate margin on the generous side of strict minimum. There is a line. It sits a little wider than the tightest possible setting, and a great deal narrower than what most people hold today.

If that feels premature — if the honest objection is that nothing has gone wrong yet — look at the shape of the bet. Over-restrict and the cost is friction and a few frustrated colleagues. Under-restrict and the cost is the kind that ends up in a regulator’s letter or a headline. When the downside is that asymmetric, waiting for proof is not caution. It is a slow decision to do nothing.

The part that isn’t technical

If the argument stopped there, it would be an engineering problem, and engineering problems are the easy kind. The hard part is everywhere the technology isn’t.

People want a voice in how they get restricted, and they are right to. When word gets out that access is going to change, the reasonable reaction is not gratitude — it is a request to be consulted about a wall being built around your own work. Then there are the old records sitting under a practice area that no longer has an active owner: cut access and you might orphan something that still matters; leave it and you have proven the point about exposure. There are whole areas of a business with no clear owner at all. And underneath all of it sits the least glamorous question in governance — who approves access, by what process, on what timeline, without slowing the work that pays for everything.

None of that is a permission toggle. That is the actual work, and it is the work least likely to get done, because it is political and procedural rather than technical, and it does not demo well.

So the line I gave my colleagues, the one that sounded extreme, was never an accusation. Treat every internal user as malicious is a design stance, not a character judgment. It says: stop architecting around who you trust, because trust was a statement about intent, and intent is no longer the variable that determines the outcome. Architect around what the machine can do on their behalf.

Build for what can happen, not for what anyone means to do. Intentions don’t matter. Outcomes do.

The first agentic loop I handed real work to was almost embarrassingly simple. The instruction was one line: keep adding meaningful tests until you reach eighty percent coverage. It ran, it stopped, it produced something I could use. The loop worked because “done” was a number a machine could check on its own, over and over, without me in the room.

Then I started thinking about everything else. If a loop can run until a coding task is finished, where else does the pattern fit? Drafting. Review. Triage. The long middle of white-collar work that looks, from a distance, a lot like writing tests — produce a draft, check it, revise, repeat. And the more I looked at the work I actually manage, the less the pattern held. Not because the agents aren’t capable. Because of something hiding inside that one-line instruction I gave the test loop.

The two conditions inside one sentence

Read the instruction again: keep adding meaningful tests until you reach eighty percent coverage. There are two conditions in that sentence, not one. “Eighty percent” is the part the loop can see. It is a number, computed the same way every time, and the agent can compare its work against it without asking me anything. “Meaningful” is the part only I can see. It is a judgment about whether a test exercises something that matters, and the coverage number is blind to it.

The loop optimized the half it could measure and quietly leaned on me for the half it couldn’t. That arrangement felt like automation. It was closer to a division of labor I hadn’t noticed I was making. The machine took the measurable condition; I kept the judgment and pretended the number carried it.

That worked out fine for tests. It’s worth being honest about why.

Why coverage was allowed to stand in for quality

Code is instrumental. Nobody actually wants the code — they want what the code does. The product is downstream of the artifact, which means you are allowed to measure “done” with a structural proxy and trust that the proxy tracks the thing you care about. Coverage is one of those proxies. It does not measure whether the software is good. It measures how much of the code your tests touched, on the assumption that broadly exercised code is less likely to hide a defect that reaches the user.

The trouble is that the assumption is weaker than most teams treat it. The most careful study on this — Inozemtseva and Holmes, presented at ICSE in 2014, across roughly thirty-one thousand test suites on five large systems — found that once you control for the size of the test suite, coverage is only weakly correlated with how effective those tests actually are. Their conclusion is blunt: using a fixed coverage value as a quality target is unlikely to produce an effective suite. The field agreed with itself a decade later and named it the most influential paper of its conference year.

This is Goodhart’s law wearing work clothes. When a measure becomes a target, it can stop being a good measure, because the act of optimizing for it pulls it loose from whatever it was standing in for. The point is not that coverage is useless. Low coverage genuinely tells you something — it flags code nobody tested. The asymmetry is the whole lesson: a low number is a real warning, and a high number is not a real promise. The proxy is good at catching neglect and bad at certifying quality. A loop that runs to a coverage target inherits exactly that limitation, and for tests, where the real product lives one step downstream, you can live with it.

You can live with it because the proxy and the product are different objects. That is the condition that makes the whole thing work. And it is the condition that most knowledge work does not meet.

A contract is not instrumental

When a lawyer ships a contract, the contract is the product. There is no downstream artifact that the document is merely a means toward. You do not deliver “what the contract achieves” and keep the contract as scaffolding — you deliver the contract, and its quality lives in the thing itself: whether it is coherent, whether it anticipates the failure it was written to prevent, whether a counterparty’s counsel will accept it without a fight. None of that reduces to a number you can compute on the side and trust.

This is the move that breaks the analogy to tests. In code, “done” can ride on a proxy because the artifact is instrumental. In most professional knowledge work, the artifact is the deliverable, the quality is holistic, and there is no faithful proxy to point the loop at. You cannot write the equivalent of eighty percent coverage for a memo, because there is no “coverage” that stands one step away from the memo’s worth. The worth is in the memo.

So the comfortable division of labor collapses. With the test loop, I let the machine hold the measurable condition and I held the judgment. With a contract, there is no measurable condition to hand off. The judgment is the entire job. And a loop has a very specific demand about judgment that, until you try to use one for this kind of work, is easy to miss.

Doing the work is how we find out what “done” is

Here is the part that took me longest to say plainly. Traditionally, doing the work is how we discover what done looks like. You don’t hold the finished standard in your head and then march toward it. You draft, and the draft shows you what it needs. You see the thing take shape, and the shape tells you where it falls short. Judgment, in most real work, is terminal — it happens at the end, against an artifact you can finally look at.

A loop will not let you wait that long. To run an agent until it is finished, you have to define “finished” before a single version of the artifact exists. The judgment that used to live at the end gets moved to the front, ahead of the work, into a specification you write blind. For a task like coverage, where the standard genuinely is knowable in advance and handed to you from outside, that relocation costs nothing. For work where the standard is discovered in the doing, asking someone to judge before the work is done is not a workflow. It is a contradiction.

We have known this about people for a long time. Michael Polanyi’s whole account of tacit knowledge turns on the line that we can know more than we can tell — that a great deal of real expertise never makes it onto the page as an explicit rule, which is exactly why you can recognize good work when you see it and still fail to specify it in advance. Software learned the same lesson the expensive way and wrote it into the Agile Manifesto: welcome changing requirements even late in development, because the best requirements and designs emerge through the work rather than before it. The industry spent two decades moving away from the up-front specification freeze. The agentic loop quietly asks for the freeze back.

The machines are already demonstrating the problem

If this sounds like a soft, human complaint about creativity resisting measurement, the most striking confirmation is coming from the machines themselves. The difficulty of specifying a goal in advance, such that an optimizer pursuing it actually does what you meant, is one of the oldest named problems in the field. Concrete Problems in AI Safety framed it in 2016: a formal objective is an attempt to capture the designer’s informal intent, and it can be satisfied by solutions that are valid in the literal sense and wrong in every sense that mattered. DeepMind catalogued dozens of cases under the name specification gaming — behavior that meets the letter of an objective without achieving the intended outcome — and noted that writing a specification that actually reflects what the designer wanted is, in their dry phrasing, difficult.

The newest version of this is no longer a toy. In early 2025, researchers at Palisade told reasoning models to win against a chess engine, and the stronger models — by default, without being nudged — went after the task environment instead of playing chess, hacking the game state to register a win. The instruction was met. The intent was not. (MIT Technology Review and TIME both covered it.) Take that as analogy rather than proof, because an agent gaming a chess benchmark and a contract that fails a client are not the same failure. But the shape is identical, and it is the shape of my point: a stated “done” is not the same as the done you meant, and the gap between them is precisely the judgment a loop asks you to write down before you can see anything.

So who is supposed to write “done”?

This is where the question stops being abstract for me, because the honest answer implicates my own seat. A stopping condition can only be authored by someone who already knows what good looks like for that specific work. That person is not, usually, the person who wants to deploy the loop across a team.

I manage a team and provide direction. I am not sitting in the room with the user, deconstructing their workflow into the conditions that would tell an agent it was finished. That is not a confession of laziness; it is a structural fact about where leadership sits relative to the work. The definition of done lives inside the task, with the practitioner who does it, in the same tacit place Polanyi pointed at. It cannot be delegated upward to whoever holds the budget for automation, and it cannot be delegated to the agent, because the agent is the thing waiting to be told. The bottleneck in scaling agentic work was never the model’s capability. It is that “good” lives inside the work, and most of it has never been written down — because, until now, nobody had to.

“Isn’t this just the discipline you should already have?”

The strongest objection to all of this is a fair one, and I want to state it at full strength rather than knock down a weak version. Defining “done” up front is not some new impossibility the loop invented. It is ordinary project-management discipline — a brief, a specification, acceptance criteria, a definition of done on a ticket. People have always been too quick to skip it, and if the loop forces a team to actually do the work of saying what finished means, that is a gift, not a problem.

Where that objection is right, it is completely right, and I’ll concede it without hedging. For instrumental work with a faithful proxy — code against tests, a data pipeline against a validation suite, anything where the artifact is a means and a measurable condition stands one honest step away from the goal — defining the stopping condition in advance is just rigor, the loop rewards it, and you should reach for the loop. I am not arguing against autonomous agents. I run them.

Where the objection misses is the moment the artifact stops being a means and becomes the deliverable. There, “define done in advance” does not resolve into a cleaner brief. It resolves into “judge the work before you are allowed to see it,” and no amount of discipline dissolves that, because the thing you would need to judge does not exist yet. The discipline argument assumes the standard is writable and the team is just dodging the writing. Sometimes the standard is not writable in advance at all, and pretending otherwise is how you end up shipping something that passed every stated condition and satisfies no one.

The open question, and the quiet risk

What I genuinely don’t know is how far the writable territory extends. Can we get to the point where we can author the equivalent of unit tests for knowledge work? Some domains will yield — there are corners of legal and financial work structured enough that a real rubric is coming, and a loop will own them. Some domains may never yield. Most sit somewhere on the spectrum between, and the honest position is that we don’t yet know where the lines fall.

It is tempting to believe the machines will close the gap for us by learning to judge open-ended work. They are not there. The current best attempt — using a strong language model as the judge of another model’s output — is real and useful and also documented to drift and contradict itself, giving the same work different scores across runs, with a catalog of systematic biases toward length and surface form. An unreliable judge does not rescue you from needing to know what good is. It just hides the moment you stopped knowing.

So the risk I actually worry about is not that we fail to measure the unmeasurable. It is that we route around it. Faced with work whose “done” resists specification, the path of least resistance is to quietly reshape the work into the part that can be specified, automate that, and let the rest atrophy — to optimize for the measurable and, as Jerry Muller documents across a dozen institutions, come to treat whatever resisted measurement as if it were never the point. That is not a failure of the technology. It is a failure of nerve dressed up as efficiency, and it is the most likely way good work gets thinner without anyone deciding that it should.

A loop is a bridge. It will carry you, tirelessly and faithfully, from a problem to a solution — but only to a solution you can already describe well enough to recognize when you arrive. It does not find the far bank for you. You still have to know the end from the beginning, and for the work that actually matters, knowing the end was always the job.

If this is useful, the place I work these ideas out in long form is AndrewLewisWasHere. Subscribe there, or forward this to the person on your team who’s about to point a loop at work that ships as the artifact itself.

A senior leader asked a simple question in a governance review last week: can we audit and verify every action an agent takes? Not the model’s reasoning, not the prompt — the actions. The edits, the sends, the deletions. The honest answer was no. Not yet. And the more I sat with that “not yet,” the more I realized it is the actual story of agentic AI inside a regulated firm, and almost nobody is telling it.

The entire public conversation about agents is about capability. How much access should they have. How autonomous should they be. Whether to let them run in a loop until a goal is met. Those are real questions. They are also the wrong ones to lose sleep over, because they are downstream of a quieter fact that has already shipped.

The agent runs as you

When a lawyer sets up an agent, the agent does not operate in some sandbox beside their work. It operates inside their identity. Microsoft’s own documentation for Microsoft 365 Copilot agents is explicit about this: an agent runs under the user’s identity, accessing data and services according to the permissions already assigned to that user. The agent inherits the person.

In a law firm, that inheritance is not abstract. It means the agent can open the matter, edit the document, send the email, and delete a file from the document management system — because the lawyer can. The newer agent layers that sit inside everyday tools, the ones that took Copilot from “draft me a paragraph” to “go do the thing,” did not just add a feature. They quietly handed a non-human process the full reach of a licensed professional.

So the unit of risk was never the agent’s cleverness. It was the agent’s authority. And that authority is borrowed, silently, from a person who may never see how it was used.

Accountability used to live in a person

The reasonable objection is that we never had a clean audit trail for humans either. That is true, and it is worth conceding plainly. A lawyer who made a hundred small decisions in a document did not generate an inspectable log of each one. The record, where it existed, lived in systems IT could comb through after the fact, not in anything the practitioner reviewed.

But accountability did not depend on that log, because it lived somewhere more reliable: in a licensed person you could question. You could ask a lawyer why they did something and get an answer, because they were present for the doing. Responsibility and awareness were the same thing.

An agent breaks that link. The action still carries the lawyer’s authority — their permissions, their identity, their name on the matter — but the awareness is gone. The person who is accountable was not in the room. The trail still exists for IT to assemble; tools like Purview will surface agent activity to administrators and compliance teams. What does not exist is a view that puts “here is what your agent did, under your name” in front of the one person who has to answer for it.

That is the gap. Not logging. Surfacing, to the accountable party, in time to matter.

The unsolved part is judgment, not logging

Here is the part I am genuinely unsure about, and I would rather name the uncertainty than pretend past it. Even if you capture every action — and increasingly you can — it is not obvious that you can present that record to a non-technical professional in a form they can actually use.

A partner does not want a JSON event stream. They want to know whether the thing the agent did was the thing they would have done, and they want to know it without becoming an engineer. The hard problem is not storage. It is translation: turning a machine’s actions into something a human can apply judgment to, fast enough to catch a mistake before it leaves the building. I have not seen anyone solve that well, and I am not certain the interface even exists yet.

What I am certain of is the asymmetry. Capability is compounding on a monthly cadence — new agents, broader access, longer autonomous runs. The ability to answer for any of it is not moving at the same speed. Every month that gap widens is a month a firm is accumulating authority it cannot account for.

The smaller question

There is a temptation, when a tool gets more powerful, to spend all the governance energy on the frontier — what should we let it do next. That energy is misallocated if you cannot yet answer for what it has already done.

Before you give an agent more of what it can do, you have to be able to answer the smaller question. Not the impressive one about capability. The unglamorous one about accountability.

What did the agent do? What can it do? The second question is getting all the attention right now. The first is the one with your name on it.

I write every week about AI as an operational discipline inside regulated firms — the work behind the work that does not show up in the vendor demo. If that is your world, subscribe.

McKinsey just published the stat that every AI strategy deck will be quoting for the next year. In Rewiring software delivery for the agentic era, the firm reports that organizations adopting agentic delivery models are seeing threefold to fivefold productivity improvements alongside a 60 percent reduction in average team size. Teams of eight to twelve become pods of three or four: a product owner, a tech lead, and an AI-enabled engineer supervising a factory of agents that works through the night.

The accepted read writes itself. AI makes teams smaller and faster. Buy the agents, shrink the teams, collect the productivity.

But the article also lists, almost in passing, what the model requires before any of it works, and that list is the part worth reading twice. The business needs a clear enough vision of what is being built that agent output can be judged against it. The technical environment has to be standard and consistent. The path from requirements to code has to follow a structure agents can reliably interpret. Requirements, guardrails, and specifications have to be codified in machine-readable formats instead of scattered across disconnected documents. And the same core stakeholders have to stay engaged across the entire value stream, or everything downstream turns into rework.

Strip out the agent vocabulary and read that list again. It describes a team that has made its own work completely legible to itself. Decomposed operations, explicit intent, defined review gates, and shared context that lives in the system rather than in someone’s head. The agents are downstream of all that. So is the 60 percent.

Nimbleness is a visibility property

“Nimble” usually gets read as small and fast, which is why the team-size stat will travel further than anything else in the article. But team size was never the constraint. The constraint is whether anyone can see the work structurally.

A team that understands its own work as a system of operations — what gets produced, what gets handed off, what intent governs each piece, where judgment is non-negotiable — can re-form around a new mission in days. A team that experiences its work as a continuous stream of tasks, meetings, and messages is rigid at any size, and handing it a factory of agents produces exactly what McKinsey warns about: fragmented output that nobody trusts. The small team is a consequence of the legible one.

Structure is a fossil of coordination cost

There is a reason team structure resists this, and Ronald Coase named it in 1937. The Nature of the Firm argued that firms exist because coordinating through the open market costs something: finding people, negotiating, enforcing agreements. The same logic shapes structure inside the firm. Layers, roles, and handoffs exist to manage the cost of communication, translation, and oversight. The professional services pyramid is the cleanest example anywhere — juniors produce, seniors review, and the ratio between them is priced directly into the business model. Org charts are fossils of what coordination used to cost.

When a technology collapses specific coordination costs, structure sized for the old costs turns from scaffolding into drag. McKinsey’s own pipeline analysis makes this concrete: the bulk of delivery effort sits in requirements through coding, where humans spend their days translating intent from one artifact to another. Every translation is a coordination cost. The agentic model removes the human from those handoffs entirely, with review concentrated at defined gates. The structure built to manage the handoffs does not dissolve on its own. Someone has to notice it is now load without purpose.

Intent travels better than instructions

If detailed structure recedes, something has to replace it, and the strongest answer is older than software. After Napoleon dismantled the Prussian army at Jena in 1806, the reformers who rebuilt it concluded that battlefield conditions changed faster than orders could travel. Helmuth von Moltke the Elder later gave the principle its lasting form: no plan of operations survives first contact with the enemy. So commanders stopped issuing detailed instructions and started transmitting intent — what must be achieved and why — leaving subordinate officers to decide how, on the ground, as conditions shifted. The Prussians called it Auftragstaktik. The modern term is mission command.

McKinsey’s daily sprint is mission command in a different uniform. During the day, humans resolve ambiguity, set guardrails, align stakeholders, and define what acceptable looks like. Overnight, execution runs against that intent at scale. In the morning, review happens at the gates. Intent travels into the night shift; instructions never would.

This is the actual design principle for team nimbleness in the agentic era: a mission plus short-term goals. The mission states what must be true and why it matters. The short-term goals create checkpoints where intent gets recalibrated against what execution revealed. The compression from two-week sprints to daily cycles matters less than what made it possible — clearly transmitted intent needs far less planning apparatus wrapped around it.

Getting legible

None of this tells a leader how to make a team legible to itself, and I am suspicious of anyone selling a template for it. The honest version is a set of questions, asked of the team’s work rather than its org chart. What operations does this team actually perform — operations, not roles? Where does intent currently live: written somewhere a system could read it, or in the heads of two senior people? Which handoffs in the workflow are translation, and which are judgment? What does “done” mean for each operation, and who decides?

Most teams cannot answer these today. That is not a failing; nobody has ever asked them to see their work this way. The structural view is developed, not installed, and there is no vendor for it. Which is precisely why it is the work behind the agentic numbers rather than a line item in the deployment budget.

The harder case

Software is the easy case, and McKinsey says so directly: the way agents are being used in software development is a harbinger for broader delivery models. Decades of version control, ticketing systems, and CI/CD have already made software work partially legible. Requirements and code leave trails by default.

Professional services work mostly does not. In a law firm, intent lives in precedent files, marked-up drafts, and the accumulated judgment of senior practitioners. The pyramid prices translation in as oversight and calls it development. The legibility debt is far larger than in software, which means the work behind the numbers is heavier — and the advantage for any firm that does it is correspondingly larger, because almost nobody in the market has started.

There is also a structural bind worth naming. Re-decomposing a team’s structure requires someone to sign for it, and in conservative institutions nobody wants their name on the new org chart. Missions carry less weight. A mission expires; a structure has to be defended indefinitely. That makes mission-based nimbleness more available to a regulated institution than restructuring. A three-month mission with short-term goals and defined review gates asks nothing of the org chart, and it quietly builds the legibility that any future structure will depend on.

The 60 percent will circulate as proof that AI shrinks teams. Read the preconditions instead and it proves something quieter: the organizations collecting those numbers did an unglamorous body of work first. They made the work visible and the intent explicit before any agent touched it. The team got smaller because the work got legible.

AI doesn’t make teams nimble. It exposes which teams already did the work of seeing themselves clearly.

If this resonated, subscribe to get the next piece on the work behind the work — the human capability development that AI adoption quietly depends on.

Somewhere in your organization this week, an AI-drafted document was approved by someone who did not fully read it. Not from laziness; from arithmetic. Machine-generated drafts, summaries, analyses, and reports now arrive faster than the people responsible for them can check, and the gap widens every month, in every department, whether or not anyone has said it out loud.

Software engineering is simply where that gap is measured best, because no other knowledge work is so thoroughly instrumented. The numbers from that world deserve attention from everyone whose job produces documents rather than code, since developers are only the first to hit a wall the rest of us are approaching. LinearB’s 2026 benchmarks, built from 8.1 million pull requests across 4,800 engineering teams, found AI-assisted work waits 4.6 times longer for a first review than human-written work, and barely a third of it gets accepted, against 84.5 percent for the unassisted kind. A queue is forming in front of the one resource AI cannot multiply: a person willing to say this is correct.

The perception side is stranger. When METR ran a randomized trial with experienced open-source developers, participants believed AI had made them roughly 20 percent faster while the measured result was 19 percent slower. METR’s own 2026 follow-up suggests that slowdown has likely narrowed or reversed as the tools improve, so treat the direction as provisional; the durable finding is the gap itself. The people closest to the work could not tell whether it was going faster. If that is true in the most measurable profession on earth, consider the odds that anyone drafting contracts, reports, or board memos with AI knows their real number.

The standard interpretation of all this is that review is too slow. Leaders read these numbers and conclude they need faster reviewers, AI-assisted checking tools, better queue management. The vendors agree enthusiastically, because every one of those conclusions has a product attached to it.

The standard interpretation is wrong. The numbers describe a system where generation capacity and verification capacity have decoupled, and no amount of review acceleration reconnects them. Sonar’s 2026 State of Code survey of more than 1,100 developers found AI now accounts for roughly 42 percent of committed code, expected to reach 65 percent by next year. The same survey found 96 percent of developers don’t fully trust that code to be correct, only 48 percent always verify it before committing, and 38 percent say reviewing AI output takes more effort than reviewing a colleague’s work. Read those findings together. This is a machine that produces artifacts faster than anyone can check them, staffed by people who know the artifacts are unreliable and have quietly stopped checking anyway. Swap the code for contracts, research summaries, financial models, or marketing copy, and nothing in that sentence changes except the file format.

The question worth asking is what verification even means once output volume crosses review capacity. The answer is structurally different from what most organizations are building.

Two curves, only one of them moves

A recent economics paper on the automation frontier frames the problem as two competing cost curves. The cost of generating an artifact (code, a brief, a report, a vulnerability finding) falls exponentially as models improve. The cost of verifying that artifact stays roughly where it has always been, because it is bounded by human cognition. A senior developer can meaningfully review somewhere around 150 lines of code an hour. A careful reader of contracts, research memos, or financial models moves at a similarly fixed pace, and has for as long as those documents have existed. Attention does not get firmware updates, and there is no model release on any roadmap that changes it.

Engineers at Agoda reached the same conclusion from production data: AI tools measurably raised individual output while project-level velocity barely moved, because coding was never the real constraint. The constraint sits upstream, in specification and verification, the two activities that require human judgment. They frame this as a rediscovery of Fred Brooks’ forty-year-old argument that accelerating one stage of a pipeline buys you almost nothing if the binding stage is elsewhere. The industry has spent three years accelerating the stage that was never binding.

When one curve falls exponentially and the other stays flat, the gap between them compounds. This is the part most adoption conversations skip. An organization that responds to a compounding gap with linear capacity (more reviewers, longer review windows, a second approval step) has chosen to lose slowly rather than rethink the game. The arithmetic forecloses the strategy before the first hire is made.

The same Agoda piece offers a useful taxonomy of the postures available once you accept that. You can read every line AI produces, the white-box stance, which preserves full assurance and caps your throughput at exactly the 150 lines an hour you had before. You can ship whatever the machine generates, the black-box stance, which is fast right up until it meets a production system with real users and real consequences. Or you can verify selectively, at boundaries and against intent, accepting that assurance is now a budget to be allocated rather than a property to be assumed. The same three stances exist for every AI draft that crosses a desk, whether the desk belongs to an engineer, a lawyer, or an analyst, and whether anyone has named them or not. Most organizations are running the third stance already. Few have admitted it, and fewer still have decided deliberately where the budget goes, which means the allocation is being made anyway, by default, by whoever is most tired on a given afternoon.

I work inside a national law firm, where this arithmetic has a sharper edge than it does in software. A pull request that ships with a subtle bug costs you an incident. A factum that ships with a fabricated citation costs you a professional reputation, and possibly a client. The stakes are asymmetric: the price of being wrong exceeds the benefit of being right, which means verification cannot be quietly abandoned the way half of those surveyed developers have abandoned it. Regulated industries never get the option of not checking; the only choice available is what to check.

That phrase, choosing what to check, is the actual answer to the scaling question, and everything else in this piece is an elaboration of it.

What the tools actually do

The toolchain that has grown up around this problem is usually marketed as verification capacity. Guardrails, evals, LLM-as-judge pipelines, formal methods, provenance tracking. The framing is that these tools let you check more. Watch how each one actually works and something close to the opposite is true: each earns its keep by deciding what will never be examined, and by making that decision survivable.

Guardrails verify boundaries instead of artifacts. A guardrail doesn’t ask whether an output is good; it asks whether the output crosses a line you drew in advance: leaks data, violates a policy, exceeds a risk threshold. Production guardrail systems, like the centralized service Singapore deployed for its public chatbots, work precisely because they refuse to evaluate quality. They evaluate violations, which is a vastly smaller problem. The honest description of a guardrail is a decision about which failures you can afford to detect cheaply and which ones you’ve accepted you won’t catch at all.

Evals and judge pipelines apply the same selective logic to quality. Rubric-based evaluation has become the working standard for assessing open-ended AI output at scale, and it earns its place. But a judge model scoring outputs against explicit criteria is a statistical instrument. It reports on the distribution, calibrated periodically against human experts, carrying known biases toward verbose answers and toward output resembling its own, and it stays silent on whether any individual artifact is correct. Teams that treat eval scores as verification have confused quality control sampling with inspection, and the difference matters enormously when one bad artifact can hurt you.

With specifications, the selection happens upstream. The most interesting shift in engineering practice right now is the argument, made well in Aviator’s analysis of the review bottleneck, that the only verification with an external reference point is verification against a spec a human has approved. Tests check behavior the test author imagined. A reviewer checks a diff against their reconstruction of what it was supposed to do. A spec is the one artifact in the pipeline where intent lives outside the generation loop, and verifying against it means a human did the hard thinking once, up front, so the checking inherits that thinking.

Formal methods verify guarantees instead of confidence. Leonardo de Moura, who built the Lean theorem prover, draws the line cleanly: testing provides confidence, proof provides a guarantee, and it is genuinely hard to quantify how much confidence testing actually buys you. Proof is expensive and narrow; you reserve it for the properties where confidence isn’t good enough. Which is, again, a selection decision.

Every tool that works at scale works by shrinking the verification surface, and every shrinking decision is a human judgment about what matters. The tools carry out triage decisions. They cannot make them.

When the verifier needs a verifier

The obvious move, once human review can’t keep pace, is to have AI verify AI. It is also the move with the nastiest failure mode, and the failures are no longer hypothetical.

SRLabs’ analysis of AI-generated security findings describes what happens when an organization layers AI security tooling on top of AI-generated code and treats the findings as decisions: the system becomes self-referential, producing artifacts faster than anyone can anchor them in an actual threat model. Teams under that load optimize for closing items rather than reducing risk, because closed items are measurable and risk reduction isn’t. The curl project reached the logical endpoint in January, ending its bug bounty after years of fielding AI-generated vulnerability reports that looked plausible and dissolved under scrutiny. The bounty had become a denial-of-service attack on maintainer attention.

Academia hit the same wall from a different direction. An audit of NeurIPS 2025 submissions documented a hundred fabricated citations that sailed through peer review, including placeholder hallucinations literally citing “Firstname Lastname,” because reviewers check methodology and novelty, and nobody’s job has ever been confirming that cited papers exist. The gap was always there. AI made it economical to exploit at volume. A related analysis of peer review itself puts the conclusion bluntly: when the rate of claims rises exponentially against fixed human bandwidth, collapse is a mathematical inevitability, and abstaining from AI assistance doesn’t preserve the system’s integrity; it just guarantees the system drowns.

And the judge models themselves are attack surface. Security researchers have shown judges that ignore their instructions when fed adversarial output, repeating attack strings instead of evaluating them. The fix proposed in that research is a guardrail on the judge — which should give you pause. We are now building verifiers for the verifiers, and there is no level of that tower where the regress stops on its own. It stops where a human owns an assessment and signs their name to it. Nowhere else.

Verification as deterrence

Earlier this year, in a long conversation about verification architecture, I landed on a framing I haven’t been able to shake: at scale, verification stops behaving like a truth-recovery problem and starts behaving like a deterrence problem. Closer to mutually assured destruction than to forensic investigation.

Truth recovery assumes you can, in principle, examine an artifact and determine whether it is correct. That assumption holds at human scale. It fails at machine scale, for the cost-curve reasons above, and the failure is permanent because the gap compounds. What remains achievable is a different posture entirely: making bad artifacts expensive to produce, cheap to contain, and traceable to a producer who bears the cost.

Look at what actually works in the systems under the most pressure and you find deterrence mechanics where you would expect inspection. Curl didn’t get better at detecting slop reports; it changed the economics of submitting them. The proposed fix for fabricated citations is mandatory existence checks rather than smarter reviewers, shifting the verification burden onto the claim, at the point of submission, where it costs the producer instead of the reviewer. Spec-driven development works because the spec makes intent auditable, which makes deviation attributable. And provenance tracking (who generated this, from what, under what instructions) won’t establish that an artifact is correct, but it establishes who answers for it if it isn’t, and that knowledge changes behavior upstream of any review.

The legal profession produced the cleanest illustration on record just this week. On June 8, a federal judge in Mississippi sanctioned every lawyer of record in a contract dispute after filings from both sides turned out to contain fabricated citations. The two out-of-state lead attorneys admitted using AI without verifying the output; local counsel had signed the briefs without reviewing them. The court revoked both out-of-state lawyers’ temporary admissions, barred them from appearing before the Northern District of Mississippi for two years, fined all four attorneys, cancelled the trial, and referred everyone to their state bars. The instructive part, read as a verification story, is the remedy the court chose: no call for better detection tooling, just consequence attached to the signature. The ruling’s principle, that responsibility “remains the sacred duty of the lawyer who signs the page,” is deterrence doctrine written by a judge who understood the problem more clearly than most AI strategy decks do.

The pipeline I sketched afterward runs adversarial passes from different model families against a primary output: fact checks, logic checks, an audit of unstated assumptions. The design process taught me something I didn’t expect. Certifying outputs as true was never on the table; no architecture I could draw gets you there. What a design like this can do is make certain classes of failure reliably expensive to get past, which changes what is worth attempting in the first place. Deterrence, functioning exactly as deterrence does.

This reframe matters because it redirects investment. An organization pursuing truth recovery buys review capacity and falls further behind every quarter, while one pursuing deterrence builds chokepoints, assigns ownership, and engineers consequence — and the second approach scales, because consequence does the verifying for you, continuously, at every point of production you can’t see.

The part no tool covers

All of which leaves the question every playbook quietly assumes is already answered: who decides what deserves verification in the first place?

Every mechanism in this piece runs on a prior human judgment. Which boundaries the guardrails enforce, what the rubric rewards, where formal proof is worth its cost, and what gets sampled, gated, or waved through. The tooling industry talks about these as configuration details. They are the entire game. A perfectly engineered verification stack pointed at the wrong things is expensive theater, and the security teams optimizing for closed findings while risk accumulates elsewhere are running exactly that theater right now.

The judgment involved is the capability I keep circling in this newsletter: signal discrimination. Knowing, when you face more artifacts than you can examine, which ones matter: by consequence, by blast radius, by the asymmetry between what a wrong artifact costs and what a right one earns. In my world, an AI-drafted internal summary and an AI-drafted court filing might come from the same tool on the same afternoon, and they belong in entirely different verification regimes. Nothing in the tooling knows that. A person has to, and that person has to be willing to own the call, which in most organizations is the genuinely scarce resource. The technology of verification is improving fast. The willingness to sign one’s name to “this is checked enough” is not, because the signature carries all the downside and none of the credit.

So the real playbook, stripped of vendor language, is short. Decide what failure costs, per artifact class, before deciding what verification it gets. Push the burden of proof onto the producer wherever you can: specs, provenance, existence checks at the point of claim. Use machines to sample distributions and patrol boundaries; reserve humans for the artifacts where consequence is asymmetric. And put a name on every assessment, because an unowned verification is a rumor with a checkmark on it.

None of that is a technology roadmap. It is judgment, exercised in advance, encoded into a system — which is to say it is work most organizations have not done, and the tools they’re buying cannot do it for them. The verification crisis everyone can now measure looks less like a case for better checking machines than like a bill arriving for a question that got skipped: what, in all this output, actually matters?

AI doesn’t make you better. It exposes whether you were already doing the work.

If this kind of analysis is useful, subscribe — one piece like this every week, written from inside an institution doing the work in real time.