Work and judgement · The Durability Curve

A Coin Flip Set the AI's Lean. Experts Went With It 86% of the Time.

Thu, 29 Oct 2026 00:00:00 GMT

Most later explained a choice in its words, and none suspected the lean was planted. How to make an AI argue the side it didn’t pick.

The analyst spent 43 minutes with the brief before typing a word.

A farming co-operative wanted to know whether its paid advisory scheme was raising productivity enough to expand it. The analyst had the data and an AI agent, Claude Code, to do the work, and by the time they began they had a plan. Their first instruction set it out: compare the farms that joined with the rest, before and after, and measure the effect on the farms that had joined.

The agent built exactly that. Then, in a single message, it set out where it would have done things differently: a different comparison, the effect across the whole membership, and farms weighted by their size. It gave a reason for each.

The analyst replied, typos and all: “Okay, let use you recomendation”.

After the task, a survey asked why they had weighted the farms as they did. Without the conversation in front of them, they wrote that the scheme was funded from the surplus on the co-op’s total tonnage sold, so the weighting should follow each farm’s economic scale. It was the agent’s reason, nearly word for word, and the answer didn’t mention the agent. Asked whether the final recommendation had been more theirs or more the agent’s, they chose “Slightly more mine”.

The agent’s preference on each of those choices had been set by a coin flip. This analyst was one of fifty.

The short version: In a randomised Anthropic study published 27 October, 50 analysts went with their AI agent’s coin-flipped preference on 86% of four judgement calls, and 77% later explained a choice with the agent’s argument. None suspected the leans were planted. The agents were told to be honest and every option was defensible, so checking the work for mistakes could not catch the lean. What might help: ask your AI for the best case for the option it didn’t pick, argued as hard as the one it did.

Four coin flips

The study, by Amaç Herdağdelen, Hailey Joren and Alex Tamkin at Anthropic, recruited analysts with causal-inference experience through a paid marketplace for expert work and gave them about an hour with the fictional Greenfields co-operative. The board would expand the scheme only for a productivity gain of roughly 3–4%, and it didn’t say how productivity should be measured.

That left four choices with two reasonable answers each. Productivity could be yield per hectare or yield per unit of operating cost. The comparison could track joining farms against the others over time, or compare them directly after adjusting for their differences. The effect could be measured on the farms that joined or across the whole membership. Every farm could count equally, or bigger producers could count for more. Each choice could move the estimate by several percentage points, against a bar of 3 or 4.

For each analyst and each choice, a coin flip set which way the agent would lean, and the analysts weren’t told. The agents were instructed to make the best honest case for their side, to change their mind if the evidence demanded it, and never to mislead.

The analysts went with the agent’s side 86% of the time, against about half if the lean had made no difference.

The final recommendation, whether to roll the scheme out, moved less, and not by a statistically significant amount on the authors’ main test. The authors warn against reading that as the analysts keeping control.

By the time anyone recommended anything, the four earlier choices had shaped the estimate, and the estimate largely settled the recommendation. In an exploratory check on the same analysts, never tested on new ones, and leaving out those who proposed a one-year extension, the four coin flips alone predicted 82% of recommendations, against 61% by always guessing the most common one.

The authors list the limits themselves. It was one task, in one field, with one model, Claude Opus 4.8, and the leans were strengthened on purpose so that their effect could be measured. The analysts were new to farming, and nobody measured how strongly any of them held a view.

What they said afterwards

The survey then asked about each choice: why that option rather than the other? The analysts couldn’t look back at their conversations. 77% repeated the agent’s argument in at least one answer, sometimes word for word. 15% mentioned the agent anywhere.

Asked what they thought the study was about, six of the 48 who answered guessed it concerned the AI’s influence on their choices. None suspected that the agents’ preferences had been planted.

Their own sense of the decision told them little. 52% rated the final recommendation as more their own than the agent’s, and that half had followed the agent about as closely as the rest, within the margin of error.

Confidence was no better a guide: analysts who went with the agent on every call were as confident in the recommendation as the rest. The authors found no reliable sign that experience or expertise predicted who deferred, though with most analysts deferring on most calls there was little variation to explain.

They saw the calls

The agents were instructed to be honest: they were barred from misrepresenting results or hiding data, and both options on every call were defensible. That is why the authors think this kind of influence is hard to catch: checking AI-assisted work for errors assumes there is a correct answer, and “where there isn’t one, as in judgment calls, the work can look sound whichever option is chosen.”

The calls were also in plain view. The agents were told to raise each lean when the decision came up, usually spoke first, and were often open about how the results would change under each option. The analysts had the calls in front of them, with the stakes attached, and still went with the coin.

What the agents rarely did was make a strong case for the option they didn’t favour. One reason the analysts deferred, the authors suggest, may be that experts don’t always arrive with their views fully formed: they often work out what they think while weighing the options. With only one side argued well, the analysts “could adopt the agent’s assumptions without working out their own.”

Weighing a call takes two cases, and these analysts mostly heard one.

Going first

In August I wrote that the fix for leaning on AI was to take your own guess first, then ask, so the machine’s answer lands as a second opinion. This study didn’t test that. The authors deliberately asked for no views before the agent spoke, because asking “is itself an intervention and can understate deference”, and they cite earlier experiments for it.

What the study does have is 38 cases where an analyst offered a view before the agent gave its own. When the agent then disagreed, they switched 60% of the time. When it agreed, they switched 6% of the time. It is a small group that chose to speak first, and the 95% interval on the 54-point gap runs from 24 to 82.

Going first probably still helps: the authors avoided asking for views precisely because asking can reduce deference. The warning here is narrower. A view formed first can still give way when only one side is argued well.

The case for the analysts

There is a fair defence of what the analysts did. They were hired for about an hour, with no stake in the farms, on calls built to have two reasonable answers. Letting an honest, competent agent break a tie is sensible delegation, and the error rates point the same way.

Of the 50 analysts who used an agent, 3 made serious methodological errors that invalidated their results. Of the 11 who chose to work without one, 6 did. The two groups weren’t directly comparable, so this says nothing certain about cause. “This isn’t an argument for using AI less,” the authors write.

Changing minds is the point of asking for advice. In a working paper on an experiment with 1,500 participants across 30 decision settings, John Conlon and Peter Schwardmann found that AI advice moved people away from their initial leanings on average, even though the AI was measurably inclined to agree with them. On the tasks with right answers, it left them slightly more accurate.

The defence fits each choice. It fits less well with where the choices led: the coin flips alone predicted most of the recommendations the analysts signed, and most of them later explained at least one call in the agent’s words, as their own reasoning. A delegated call explained as your own reasoning is the thing to watch for.

Your own decisions

In real work, the authors note, analysts would know the field better and probably hold stronger views. They could also talk to the board and narrow the options, which might reduce the agent’s influence. In a decision about your own life, you are the expert on what you value. That should help.

Against that sits the authors’ own suggestion that people often work out what they think while weighing the options. My reading is that a big personal decision often has the shape of the analysts’ task. Ask an AI whether to take a job in another city, and before anything is compared, someone has to settle the calls before the call. If you don’t, the assistant will.

What counts as better: the salary, the hours or the five-year path? Whose life is in the sum: yours, a partner’s, a parent’s who lives nearby? What weighs most, and what is the move being compared against? A good assistant will usually settle each of these sensibly, and a sensible choice is still a choice.

Assistants lean, too. In our own tests, with no lean planted, we gave Claude and GPT three briefs. On a council’s £1 bus fare trial, Claude recommended a second trial year in all 8 runs, and GPT recommended ending the scheme in all 8.

On a hospital’s booking pilot, both recommended extending it in every run. On a council’s library opening hours, Claude mostly recommended extending the trial (6 runs of 8) and GPT mostly recommended going back to the old hours (7 of 8). Same numbers in, and on two briefs of the three, different answers out.

The paper found Opus 4.8 steadier still: it made the same five choices (the four calls and the recommendation) in 112 of 123 runs with no lean assigned, and Fable 5 was as steady. Other models varied more. The authors say the effect might be smaller when an agent hasn’t been given a clear preference and told to voice it. Which default you meet can still depend on which assistant you ask.

If I’m right that your own decisions have this shape, take one you made with an AI’s help this year and look back at it. Did you know which calls settled it, and did you hear each of them argued both ways?

The method that follows has three questions. List the calls that settle the decision, or have the AI draft the list and check it: what counts as better, whose life is in the sum, what each option is being compared against. Ask the AI for the best case for the option it didn’t recommend, argued as hard as the one it did. Then ask what would have to matter more for the answer to flip, and by how much.

Below the line, for paid subscribers: the three questions worked through on a job offer, and the Judgement Calls kit for work. The kit is an instruction block for your assistant and a sheet for anyone who signs off AI-assisted work. Our tests of the block are there too, misses included.

Where this comes from

The study is Amaç Herdağdelen, Hailey Joren and Alex Tamkin, How AI agents shape experts’ judgment calls (Anthropic, 27 October 2026), with the full paper, Who’s Aligned to Whom?. The depolarisation result is John Conlon and Peter Schwardmann’s working paper, AI Sycophancy and Decisions. “The calls before the call” adapts Seth Godin’s phrase “the decision before the decision”.

Did Your AI Actually Read the Doc?

Fri, 16 Oct 2026 00:00:00 GMT

Yesterday you and ChatGPT settled the plan. Today’s chat has never heard of it, and Claude never saw it either. So you paste it in again, and whatever you forget to paste gets decided twice.

This guide puts the plan in one Google Doc that both assistants read, in three steps, then gives you a test that shows whether a new chat is reading the current version. If you only use one assistant, its built-in Projects feature keeps your notes across chats in that app, which may be all you need.

Connect both assistants to Google Drive

Use the Google account you will keep the doc in. Connecting lets each assistant search everything that account can open, including files far beyond this doc. If Google says your organisation blocks it, your admin has to allow it.

Claude. Open Claude’s connector settings, click the + next to Google Drive, and sign in to Google. A tick means it’s already connected. Anthropic offers this on every plan, Free included; on Team and Enterprise, an Owner has to add it first.

ChatGPT. Open ChatGPT and click Plugins in the left sidebar. If Google Drive shows a +, click it and sign in to Google. OpenAI doesn’t list which plans include it; it was there on our Plus account. If Google Drive isn’t there, use the doc with Claude and paste its text into ChatGPT when you need it there. That copy won’t update itself.

Make the doc

Create a Google Doc in that same Google account, with a name no other file in your Drive uses, paste this in, fill in the brackets, and swap the example decision for one of yours. Keep everything in the body of the doc, not in comments, which some connections can’t read.

ABOUT THIS PROJECT
Goal: [what this project is for, in one sentence]
Audience: [who the work is for]
Current priority: [the next specific task]
Rules for any AI:
Read this whole document before you start.
If you cannot open it, say so. Do not guess.
Link a source for every fact. Say when you are unsure.
Never publish, send or spend anything without asking me.

DECISIONS (newest at the top; a newer line wins)
2026-10-15: Link every statistic. Why: one went untraced.

Each time you settle something, add it as a new first line under DECISIONS, with the date. A decision made in a chat isn’t in the doc until someone writes it there.

Start every chat the same way

Claude. Open a new chat in Claude, click the + in the message box, then Connectors, then Add from Google Drive. Search for the doc, tick it and click Add to chat. Anthropic says Claude re-reads it each time you send a message, so your latest edits reach it.

ChatGPT. Open a new chat in ChatGPT, type @ at the start of your message and pick Google Drive from the list.

In both apps, put the prompt below in that same first message. It tells the assistant which doc to open:

Open my Google Doc "[doc name]" and read all of it.
Tell me the current priority and the newest decision.
Then help me with: [task]

The test

Both assistants can remember earlier chats, and an answer from memory sounds the same as an answer from the doc. An AI can even cite a source it never read. So give the doc a word no chat has seen.

Type a new first line under DECISIONS with today’s date and a word you make up. Type it in the doc only, never in a chat.

[today's date]: Test. Codeword: [your made-up word]

In each assistant, open a brand-new chat, attach the doc as in step 3, and ask:

Open my Google Doc "[doc name]".
Quote the first line under DECISIONS exactly,
and name the doc you opened.

It quotes today’s codeword. It fetched the current doc. Go on to the second question below.
It quotes anything else. It didn’t fetch the current doc. Check you attached the right one, then try once more in a new chat. If it still fails, don’t rely on that assistant for this project yet.
It can’t find the doc. Check that the Google account you connected in step 1 is the one that owns the doc.

Quoting a line shows it can fetch the doc. To check it can use it, ask in the same chat:

Which decisions are settled, and what should you do next?

It should name your current priority and leave everything under DECISIONS settled. If it reopens a decision or picks other work, make that decision or the current priority clearer in the doc and ask again. We ran both questions in Claude and ChatGPT on 15 October 2026: both quoted the codeword, and both followed the newer of two conflicting decisions.

Delete the test line afterwards. Rerun the test with a new codeword whenever you change assistant, plan or settings.

When to move it to GitHub

Skip this unless you want your assistants to hand work to each other. A repository on GitHub is a project folder that keeps every version of its files, and a change there can set an assistant working once you have set up a task to watch for it. On ChatGPT Plus or Pro, you can create a task in Work that starts by itself when someone opens a pull request, GitHub’s name for a proposed change. OpenAI names only Gmail, Slack and GitHub as triggers for these tasks, so a Google Doc isn’t one of them. On a paid Copilot plan, you can hand a task to Copilot, GitHub’s own assistant, or (in preview) to Claude or OpenAI’s Codex, and get a proposed change back to review.

To move, you need a free GitHub account. Signed in, open github.com/new, type a name, choose Private, add a README, and click Create repository.

Open README.md, click the pencil at the top right of the file to edit it, and replace its text with this, filled in from your doc:

# [Project name]

- Goal: [what this project is for, in one sentence]
- Audience: [who the work is for]
- Current priority: [the next specific task]

## Rules for any AI

- Read README.md and DECISIONS.md before you start,
  and tell me which files you read.
- If you cannot open a file, say so. Do not guess.
- Link a source for every fact. Say when you are unsure.
- Never publish, send or spend anything without asking me.

Click Commit changes…, then Commit changes in the box that opens, leaving it on the main branch. Click the repository’s name at the top to go back to its main page, then click Add file, then Create new file, and name it DECISIONS.md. Paste this, replace the example line with your decisions from the doc, newest first, each starting with a dash, and save it the same way:

# Decisions (newest at the top; a newer line wins)

- [date]: [what you decided]. Why: [why]

The doc and the repository won’t update each other, so edit only the repository from then on. For ChatGPT, add GitHub from Plugins, as in step 1, and give it access to this repository (OpenAI’s steps); a new repository can take about five minutes to appear there. For Claude, add the repository to a chat or a project (Anthropic’s steps); in a project, select Sync now after you change a file.

Neither connection can write, so you or a coding assistant make the changes. A connection only gives access, so open each chat by asking for README.md and DECISIONS.md. To run the test here, put the codeword line, starting with a dash, at the top of the list in DECISIONS.md and ask a brand-new chat to quote the first decision in DECISIONS.md exactly, then delete the line. We run our own team of assistants this way, and each one needed its own trigger, because the repository tells nobody when new work arrives.

Two rules

Keep passwords and private details out. Deleted text can usually be brought back from the doc’s version history, so if a password gets in, change it.

Treat text other people add as a stranger’s instructions. If you share the doc, anyone who can edit it can write something your AI will read and may follow. Invariant Labs showed this in a May 2025 demonstration: a message they planted in a GitHub issue steered an AI agent into leaking private data.

What Did They Have to Check or Redo?

Wed, 14 Oct 2026 00:00:00 GMT

An AI-drafted update, summary or email can cost the person who gets it time you do not see. Ask them one question, then change one thing.

Your AI drafted the weekly update in three minutes. You read it through, it looked right, and you sent it.

What happens next happens on someone else’s desk. They may trace a figure back to its source, put back the context the summary dropped, or read it twice to find what you need from them. None of that counts as time you spent, so none of it counts against the time AI saved you.

The sender sees the saving, and the recipient sees the repair.

Researchers at BetterUp Labs and Stanford’s Social Media Lab have a name for work like this: workslop, AI-generated work that looks finished but lacks the substance to move the task forward. In their 2025 survey of 1,150 US desk workers, 40 per cent said they had received it in the past month. Those who had received it put their own estimate at nearly two hours per incident, and half of them said they now saw the sender as less capable. Thirty-two per cent were less likely to want to work with that person again.

So ask the person who received yours.

Pick one handoff you send every week: a status update, a research summary, a client email, a meeting recap. Send it the way you normally would. Once the recipient has used it, ask:

What did you have to check or redo?

The exact words matter. Ask whether it was useful and you invite a polite yes. Ask how much time it saved and you are back on your own side of the handoff. Ask what they had to check or redo, and the honest answer is a list, or “nothing”.

Take the first thing they name and fix it next time. If they reopened your sources, put the source beside each claim. If they hunted for the request, put it in the first line. Then ask again after the next handoff. You want that list to get shorter each time, until there is nothing on it.

The output does not have to be wrong for this to matter. A correct summary can still leave out what the decision turns on. A well-written email can still bury the request. A polished update can still leave nobody sure who owns the next step. The person who received it can tell you which of those happened.

For the wider question of turning faster output into trustworthy work, read AI Made You Faster. It Did Not Make You Safer.

AI Can Take the Practice Without Taking the Job

Fri, 02 Oct 2026 00:00:00 GMT

In the operating theatres Matt Beane studied, the senior surgeon sat at a console and worked the robot’s arms alone. The surgical resident was still in the room. Beane described what residents did there: they “held a laparoscopic tool to remove smoke and fluids from the patient, or watched the surgical action from a second trainee console.”

Open surgery needed the trainee. In Beane’s words, the open procedure “required four hands and two people most of the time,” and trainees learned by taking on more of each operation as they went. The robot let one expert operate alone, and “the trainee was optional.”

Beane’s study, two years of observation at five sites plus interviews about training at 13 top US teaching hospitals, found that under the robot only a minority of trainees came to competence. In UC Santa Barbara’s write-up of the work, he estimated that residents were getting “ten to twenty times less practice,” and said they were “finishing their residencies licensed to use robots in the operating room, but many are graduating without crucial surgical skills because they did not receive enough practice or mentorship.”

Residents could still complete their programmes. What thinned out were the reps: the repeated, real cases a person handles, with someone better beside them, until judgement forms.

A count of residents could not show that. That is the risk this piece is about: the expertise pipeline can break while the headcount holds, because the job stays but the cases move to the machine and the learner moves away from the person who knows the call best.

So, on your team: who is at the second console?

The count

In August, Stanford’s Digital Economy Lab published a revision of its study of AI and young workers. Erik Brynjolfsson, Bharat Chandar and Ruyu Chen work from ADP payroll records covering millions of US workers. Employment of 22 to 25 year olds in highly AI-exposed occupations is about 19% lower than it would be had it kept pace with people the same age in less-exposed jobs. A year earlier, by the same measure, the figure was 15%. (The 13% you may have seen was an earlier, model-adjusted estimate.)

The authors call these descriptive facts, not a causal estimate. The gap is larger in ADP’s data than in national surveys; some of the divergence predates generative AI, though by November 2022 the young workers’ position had returned to roughly its pre-pandemic level; and controlling for each occupation’s education level shrinks the estimates, which could be an alternative explanation or the channel AI works through.

The gap survives removing tech firms and computer jobs and controlling for interest rates and remote work, and it kept widening after interest rates peaked; estimates that adjust for firms’ overall hiring point the same way but shift with modelling choices.

The paper also says where the gap sits. It runs through hiring: the authors find it works “primarily through reduced hiring rather than increased separations.” Using usage data from the Anthropic Economic Index, they find declines concentrated in occupations where observed AI usage substitutes for human tasks, with employment flat or rising where AI complements workers, and the link is strongest for the youngest. Experienced workers in the same occupations, which the study uses as a placebo check, show no comparable gap.

That is the first layer of this story, the jobs a payroll can count. The second layer sits inside the jobs that remain.

Codified and tacit

The authors also look at which occupations experienced workers are growing in. They scored occupations, partly by having a language model read job descriptions, for how much they rely on two kinds of knowledge: codified knowledge, which can be “taught through education, textbooks, or written procedures,” and tacit knowledge, which is “difficult to write down or teach in a classroom.”

Young workers lost ground in occupations that lean on codified knowledge, and experienced workers grew faster in occupations that lean on tacit knowledge. Only the second survives a check the authors ran on their own work: once they control for the share of college graduates in each occupation, the codified pattern stops being significant. The authors call these estimates “non-causal and purely suggestive.”

By the definition the authors used, tacit knowledge is “acquired through practice, mentorship, hands-on experience, and repeated exposure to real situations.” That is the surgeon’s route: years of taking on more of each operation, beside someone who already knows how.

O*NET, the US government’s occupation database, helps picture what the route can look like at a desk. A marketing manager is expected to “develop pricing strategies, balancing firm objectives and customer satisfaction.” A market research analyst, a role whose work can feed that call, is expected to “gather data on competitors and analyze their prices, sales, and method of marketing and distribution.” Pricing well is the judgement call in this example. Pulling competitor prices week after week is one way a person sees enough real cases to make it.

The authors suggest a mechanism for the gap, citing the economist Enrique Ide among others: AI “may be automating the checkable, process-intensive tasks that historically justified entry-level headcount,” while letting experienced staff get more done.

The loss the count can’t see

Ide, at IESE Business School, built a model of how expertise passes from one generation to the next (arXiv 2507.16078). He starts from the worry that AI, “by allowing senior workers to accomplish more tasks independently,” may cut the entry-level work juniors trade for training. In his model, “novices acquire tacit knowledge by working alongside experts,” and the best experts pass their expertise to several novices at once.

His result is quieter than lost jobs. Automating entry-level work raises output straight away. It can also slow growth and leave people worse off, because automation can “reallocate novices away from the most productive experts.” The juniors keep working. They learn beside weaker mentors.

His slowdown, he notes, needs neither fewer entry-level jobs nor novices losing hands-on practice: “a compositional deterioration in the pool of mentors is sufficient.” His conclusion is about exactly the number this debate watches: “policy assessment should look beyond aggregate entry-level employment: the deployment of new technologies may reduce welfare even if the total number of entry-level jobs remains unchanged, provided it reallocates novices away from the most skilled experts.”

An overall count cannot see who is learning beside whom. Ide’s model points to that. Beane’s theatres point to the practice itself, the part juniors lose when the expert can work alone. And in a small randomised trial of 52 developers by Anthropic researchers, covered in Use AI to Learn Without Getting Worse at It, those learning a new library with an AI assistant came away understanding it less well.

The evidence also runs the other way. In a field study of customer support agents (5,172 in the data, 1,636 of them observed after getting an AI assistant), Brynjolfsson, the first author of the Stanford study, with Danielle Li and Lindsey Raymond, found that less experienced workers given the assistant improved in both speed and quality, and found evidence that the assistance “facilitates worker learning.”

Ide’s model has the mirror case: technology that increases “the number of novices learning from the most productive experts” strengthens the passing-on of knowledge and raises growth.

The same kind of tool can drain the practice that makes experts or speed it up.

The support study’s authors suggest their assistant may have been “capturing and disseminating the behaviors of the most productive agents”; in the theatres the robot let the expert work without the trainee, and in the trial developers could hand the coding to the assistant.

Our working hypothesis, which these studies point to without proving, is that the difference lies in how the tool and the work are set up: whether the AI carries your best people’s practice to juniors or does their work for them, and who does the feeder tasks, beside whom. An overall headcount cannot tell the two apart.

Counting reps

A team lead can look for the difference with three questions.

What judgement calls is your team paid for? These are the things done well because someone has seen many cases: pricing a deal, spotting the wrong number in a model, knowing which customer complaint is the dangerous one.

Which everyday tasks gave you those cases? If yours were the checkable tasks you did early on, they are the kind Stanford’s authors suspect AI is now taking. Not every task an AI takes was teaching anyone, and the audit helps you name the ones that were. You Reach Before You Think was the individual version; this is the team version.

Who does those tasks now, and beside whom? A junior doing them by hand next to your best person is a different answer from a junior forwarding what an AI wrote, and both are different from nobody.

The limits, in one place. The labour data is American and descriptive; the gap shrinks with an education control and is muted in occupations full of graduates, which may include yours.

The evidence that practice itself can drain is one study of surgeons and one short trial of developers, neither following careers; the evidence that it can speed up is one study of support agents. Our sorting step uses a language model and was tested on two lists with one model, Claude Sonnet, so it is a demonstration. Nothing here scores your risk, and you overrule any call you disagree with.

In the rest of this piece: three changes that put reps back on a team; a version for team leads and one for anyone early in their career; the Second Console Map worksheet and the sorting prompt we tested; and a worked example of the hard case. The stake: if your best people now do more on their own with AI, the people who should come after them may be learning beside someone else, or not at all, and a headcount will not show it.

The Things You Used to Know by Heart

Tue, 29 Sep 2026 00:00:00 GMT

What leaning on AI to remember for you quietly does to your own thinking.

The Quiet Part is a short series on what living alongside AI quietly does to you. The others in the series are You Reach Before You Think, on judgement, and It Will Never Think Less of You, on being known.

You used to know your closest friend’s phone number without reaching for it. You read a good book last month, cover to cover, and if someone asked you tonight what it actually argued, you would reach for the answer and come back empty.

The information has not gone anywhere. It has left your ready recall while staying well within your reach. The number is in your phone; the argument of the book is one question to a machine away. That is what makes the loss so hard to name: nothing is missing, and something is.

Because a thing you know and a thing you can find do different work.

Known, and merely findable

Ask the machine what the book argued and it hands you a whole, coherent account of the argument in a second. Search used to return documents you still had to think your own way through; the machine can hand back the thinking, already done. It is a strange kind of having, because you never did the building and you will not keep the result. You can call it up again tomorrow, always fluent, always gone the moment you close the tab: an understanding you can borrow forever and never once own.

What you actually know does the one thing the borrowed version cannot. It is already present when you meet the world, deciding what you notice, what strikes you as strange, what question even occurs to you. A thing you can look up waits, filed and patient, until you already know to go and ask for it. A thing you know is in the room before you reach for anything, quietly shaping the thought while it forms.

Stored, it waits to be fetched. Carried, it is already in the room.

The thing you could not have looked up

Say you know that your grandmother salted her cooking like she had a grudge against it. And say you know, too, that she grew up with nothing. For a long time those two facts never touch. Then one evening, as you stand over your own pot, they meet, and a question forms that you would never have typed: was the salt about the years of not having enough?

You may never know if you are right. Either way, you would never have gone looking for the question, because you did not know there was one to ask. The machine can connect anything brilliantly once you bring it the two things and the hunch that they belong together. What it cannot be is the place where the hunch first arrives, unbidden, because you happened to be carrying both halves at once.

A machine can answer anything you bring it, and connect whatever you hand it. What it cannot do is be already in you, shaping what you notice before you know there is a question to ask.

Carried, two facts can meet before you think to introduce them.

What stays with you

The machine is welcome to the phone numbers. Most of what you look up was never going to shape a thought, and it is right where it belongs. But somewhere in the pile is the other kind, the shape of a problem you are stuck on, or the way something you love actually works, or the argument of the book that changed your mind. Their whole use is to be in you already, uninvited, when something new walks past, and a thing you can call up is never quite that, however close to hand you keep it.

When every answer is free, the scarce thing is what you have taken in so deeply that the world can still reach in and remind you of it.

If an understanding can be borrowed this easily, the next question is what actually proves you can think.

Use AI to Learn Without Getting Worse at It

Thu, 24 Sep 2026 00:00:00 GMT

Answer-giving AI left learners worse off once it was gone. Three setups built to keep the thinking with you, and a way to check what stuck.

If you have used ChatGPT this month to get through something you are learning (a spreadsheet formula, a new codebase, the rules of a new job), it probably felt like progress. The answer was always one message away.

A team of researchers tested it. Nearly 1,000 Turkish high-school students practised maths, some of them with a ChatGPT-style assistant beside them. That group’s practice scores rose 48%. Then the assistant was taken away for the exam, and they scored 17% lower than students who had never had it. The analysis the authors registered in advance puts the drop about a third smaller, but it is still a drop. In the chat logs, students had often asked for the answer and copied it.

Easier practice is not evidence that you learned the thing. The effort you skip is often the part that was teaching you.

When you only need the answer, take it. This is about the times you need the skill, because you will have to do it again with nobody to ask.

Experienced programmers too

The Turkish students were teenagers. In January, Anthropic published a trial with 52 Python programmers, recruited through a crowd-work platform, learning a Python library that was new to them. More than half had seven or more years of coding experience. Half of them worked with an AI assistant; afterwards everyone took a quiz with no AI allowed.

The AI group scored 4.15 points lower on the 27-point quiz, roughly 15 percentage points, and they were not significantly faster. They learned less and got little or no time back.

Who did the thinking

Some of those programmers scored well anyway, and they had used the assistant differently. Those who handed it the work, leaned on it more as the task went on, or had it debug for them averaged 24% to 39% on the quiz. Those who asked it conceptual questions averaged 65%, about the same as the group with no AI. The best result, 86%, came from two people who let it write the code and then questioned it until they understood what it had written. The groups were small and sorted after the fact, so treat them as a clue.

A separate team found the same split. In pre-registered experiments with German university students learning to code, the researchers found no effect of a chatbot on learning overall. Inside that average, students who used it to generate solutions covered more topics but understood less, and students who used it to ask for explanations understood more. That split was exploratory. In the same study, 42% of requests for a solution came before the student had tried at all.

Only the Turkish trial tested the design directly. Its second AI group had an assistant told to give hints, with the correct solutions loaded. Their practice scores rose 127% and the exam damage disappeared, though they did no better than students with no AI. Two other trials show well-designed tutors teaching well without isolating who did the thinking. At Harvard, 194 physics students each learned one lesson from a tutor told to encourage a first try and release the solution one step at a time, and another in an active-learning class; median gains with the tutor were more than double the class’s, though it answered whenever a student demanded it. In Nigeria, teacher-guided sessions with a chatbot raised English scores 0.238 standard deviations against students who got no programme at all.

Not every result fits. Google’s trial of Gemini’s Guided Learning raised maths scores overall, but its younger year group did slightly worse. The German study found no overall effect either way.

The consistent part is narrow and useful. In two randomised trials, an AI assistant used freely during practice left people worse off once it was gone. In both studies that looked at how people used it, those who asked for explanations did better than those who asked for answers. So keep the thinking on your side of the chat: try before you ask, and ask it to explain. Three ways to set that up follow.

Level 1: switch on the learning mode you already have

As of September 2026, according to each company’s help pages and apps:

ChatGPT: type @study, or press + and choose Study. It is on every plan, though it does not work inside Projects.
Gemini: Add files, then More tools, then Guided Learning.
Claude: first switch on Code execution and file creation under Settings, then Capabilities. Then add Anthropic’s learn skill from Customize, then Skills, then Discover. It stays out of coding tasks by design; for code, see Level 2.
Copilot: open Quick response under the prompt and choose Study and learn.
Claude Code: type /output-style learning.

Then one habit: before you send a question, write your own answer, even a bad one.

Treat the modes as a start. OpenAI’s own help page says Study mode may still give a direct answer, and the companies’ own trials are early. In OpenAI’s one-session study, students using Study mode scored roughly 15% higher than with ordinary online resources in microeconomics, and no differently in neuroscience.

Level 2: paste a tutor prompt

The modes are not everywhere, and they slip. A prompt goes anywhere. Paste this at the start of any chat where you are learning, and fill in the last two lines:

Be my tutor for this. I'm trying to learn it, not just get it done, so help me work it out myself.

1. Don't give me the answer or write the solution for me. Give me one hint or one step at a time, then wait for my reply.
2. If I ask you to just tell me, ask me to try first. Count every wrong answer or guess as a try. After my second wrong try, give me the answer and explain the step I missed.
3. When I get something right, confirm it and ask me why it works.
4. Keep every reply to a few sentences.
5. When we finish, give me a similar problem to try on my own.
6. If you're not sure something is correct, say so.

What I already know: [e.g. basic percentages, nothing about probability]
The problem: [paste it here]

It borrows Harvard’s try-first, one-step shape and the Nigeria exercises’ hint-then-answer rule, and it is stricter than Harvard’s tutor, which answered on demand.

I ran it eight times with a scripted learner: seven across Claude, Gemini and GPT, one in the ChatGPT app. Each time the learner demanded the answer, the tutor asked for an attempt, and after the second wrong try it gave the answer and named the missed step. Once, asked for fixed code, GPT held back the code but described the fix in words, which gave most of it away.

On a long problem some models count tries per step, so the answer arrives a step at a time; that is fine. If a hint gives the answer away, reply “smaller hint”.

This is the same move as asking for the step before the answer, kept on for a whole session.

If you are learning code, use /output-style learning in Claude Code, or paste the prompt with the function or error as “the problem”. When it does write code, do what Anthropic’s top-scoring pair did: ask why each part is there until you could write it yourself. Then, my suggestion: close the chat and write it.

Level 3: give it your material, then test yourself cold

Levels 1 and 2 set up the tool. This level adds your own material, and it measures you.

Create a project for the thing you are learning. In ChatGPT, New project in the sidebar. In Claude, Projects, then New Project (the free plan allows five). In Gemini, a Gem with your files added.
Paste these instructions into the project’s instructions:

You are my tutor for the material in this project. I'm here to learn it, not to look things up, so make me work for every answer.

1. Before you answer anything about the material, check the files in this project. Use them as the source of truth. If they don't cover it, say so before you answer from general knowledge.
2. Whenever I ask a question about the material, don't answer it yet, even if I say "just tell me". First ask me what I think, or give me one hint.
3. Count every wrong answer or guess as a try. After my second wrong try, give me the answer from the files and explain the step I missed.
4. When I get something right, confirm it and ask me why it works.
5. Keep every reply to a few sentences.
6. If you're not sure something is correct, say so.

Upload your material: course notes, documentation, your team’s handbook if you are allowed to put it into that service, and an answer key if you have one. The Harvard team loaded every question with its worked answer; without your material, a tutor falls back on what it already knows.
Test the setup before you trust it. Ask a question about the material and add “just tell me”. If it answers straight away, the setup is not holding. My first version failed exactly this test in the ChatGPT app, answering at once from general knowledge. The version above passed with a hint drawn from the file.
Learn in chats inside the project.
A few days later, run the cold check. Open a new chat in the project, paste this, and fill in the topics you studied:

Cold check. Quiz me on what I've been learning from the files in this project.
Only ask about these topics: [list what you studied]
Ask 6 questions, one at a time. Mix "what is" questions with "what would you do if" questions.
Don't give hints and don't tell me whether I'm right until all 6 are done.
Then score me out of 6, show the correct answer from the files for each one I missed, and list what I should review.

Answer from memory, with no notes. In the ChatGPT app, with a planted mix of right and wrong answers, every question stayed on topic, it gave no feedback until the sixth, and it scored 3 out of 6, marking exactly my wrong answers and correcting each from the file. I did not test the Claude or Gemini apps themselves, so run it once with answers you know are right and wrong before relying on the score.

The German study found students felt they had learned more than they had. A score checked against your files is a better guide than that feeling, though I tested the marking only on short factual questions, so check each marked miss against the source. Put the check in your calendar and paste the prompt yourself. Whatever you missed goes back into a tutoring chat.

What the research can and cannot tell you

None of the seven studies tested people again weeks or months later, so none shows the learning lasted. Only two went through journal peer review. The evidence on how people used the AI comes from patterns inside two studies, not from assigning them. Three trials were run by AI companies, and in Nigeria the comparison group got no programme at all.

Your own cold check a few days later is the only follow-up test in this piece.

The checklist

Next time you open an AI to learn something:

Decide whether you need the answer or the skill. For the skill, keep the thinking on your side.
Switch on your app’s learning mode, or paste the tutor prompt.
Write your own answer before you ask, then ask it to explain.
If a hint gives it away, ask for a smaller one.
For anything you need to know properly, put your material in a project and test the setup with “just tell me”.
A few days later, run the cold check on the topics you studied, with no notes, and send what you missed back into a tutoring chat.

The Nigeria exercises drew in part on tutor prompts published by Ethan and Lilach Mollick in 2023.

You Built a Number You Will Not Trust

Fri, 28 Aug 2026 00:00:00 GMT

There is probably something you are part of the way through building. A spreadsheet that will score your sales leads so you know which to ring first. A scorecard that will rank the people you interviewed. A formula that will tell you which product line to drop. You have the columns and the weights, and it more or less works. And some part of you already knows you will not trust the number it gives you. When it puts the wrong lead at the top, you will override it, the way you did last time.

That thing was built well and it is not going to help you, and the reason is not that you got the weights wrong. You could tune them all weekend. The reason is that you never said what would make its answer right. You built a machine to rank the leads before you had settled what a good ranking even was, so when its number surprises you, you have no honest reason to trust the surprise over your own read, and you override it. Working that out before you start is worth more than any amount of tuning, because it changes what you build.

What “it works” does not tell you

When a thing you made runs, you feel finished. The columns add up, the report generates, the score comes out. But working only tells you the thing does what you built it to do. It says nothing about the two questions that can kill the thing before you waste a weekend on it: whether you could ever tell that its answer was wrong, and whether it beats what you would have done without it. You can ask both before you write a line, and most of the cost of a wasted build is the cost of not asking.

The one people skip: what would tell you it was wrong

Start with whether you could ever tell the answer was wrong, because that is the question that gets skipped, and it is easy to hear it as a question about whether the tool runs. Those are not the same: a tool can run perfectly and still hand you an answer you could never catch out. A total, a count, a due date, an amount owed: each has an obvious check, because there is an answer outside the tool to compare it with. Those you can build and know you built them well.

Past those, it comes down to one thing that is easy to miss: whether the outcome that grades the answer arrives on its own, or whether acting on the answer is what decides which outcome you ever see. A forecast can be the first kind, as long as the thing you are predicting arrives regardless of what you do with the prediction. Predict how many people will show up or how many inbound calls will arrive, and the real number turns up whatever you guessed. Footfall, call volume, next week’s demand: the world returns a verdict on these whether you like it or not, which makes them possible to test and improve even when the answers are hard. You always get to find out.

The lead score looks like one of those and is not. The outcome you get to see is the one the score chose for you. You ring the leads at the top, some of them buy, and the ranking looks confirmed, but the leads it sent to the bottom you never ring, so they never get the chance to prove it wrong. It can bury half your real buyers and still show you a good week, because the ones it buried are the ones you will never check. The number decides which evidence you ever see, and the mistakes that matter are the ones it never shows you. That is the dangerous kind of number: the one whose very use hides its own mistakes, so the more you lean on it the less you can see them.

A tool like that leaves you two choices, and neither is simply to trust the score. You can keep the decision for yourself and build the thing that lays the evidence out, the renewal date, the value, the last time you spoke, so the call takes seconds and the decision stays where it can actually be made. Or, if you want the score, you keep a corner of the world honest: at random, ring some of the leads it tells you to skip, so it cannot set its own exam and then pass it. What you cannot do is act on it everywhere and call the result proof.

So the question that matters is not whether the answer is a fact or a judgement. Plenty of recommendations can be tested against what actually happens, over enough cases. The question is whether you would ever find out this one was wrong, for the options it turns down as much as the ones it takes. When nothing would, you have automated the decision without earning any reason to trust it.

I have watched myself skip this question, so I know why it gets skipped. Asking is quick and uncomfortable, because the honest answer is sometimes that nothing would ever tell you, and that ends the project in the first ten minutes. Building is slow and feels like progress, and every hour in makes the thing harder to walk away from. So the quick question loses to the comfortable work, and you find out at the end.

What it cost me to learn this

I learned this by paying for it twice in one evening. I had built a small tool that read a page of written instructions, the kind you might write to hand a job over to someone, and sorted each line into two piles: the lines that told you to do something, and the lines that were only describing the setup. It ran. Then I tested it against a page it had never seen, marking the lines myself first, and on the ones it was willing to call, it agreed with me a little over half the time. The tempting lesson is that the tool was bad. The real lesson was worse. I had never pinned down what the right pile was, and I could have: written down the rule for what counts as an instruction, had someone else label the same page, checked whether we agreed. That would have given me something to hold the tool to. I never did it, so the tool’s score could tell me how often it matched me, but not whether it had learned a rule worth trusting.

The target was buildable. I had just built everything except the target.

So I rebuilt it as the other kind of tool, one that only counts, showing each section’s share of the page and letting me tick what to cut. That has an obvious check, and I built it properly, with a list of thirty-four ways it could go wrong, twenty-seven test cases worked by hand, seven real pages it passed cleanly. It was correct. It was also useless, because the thing it replaced was opening the file and reading it, and it beat that by nothing. The first question had sent me to a tool that could at least be right. The second question killed it anyway. That second failure is the easier one to miss, because a tool that is correct feels like a tool that is worth having. It can be measurable, tested, and right, and still lose to the thing you would have done without it. What you would do instead belongs on the page next to the answer you are after.

Later I wrote out what could have sunk each build. The thing that actually sank the first one was not among the bugs I had spent the night fixing. It had been sitting above them from the start: I never said what a right answer would be.

Run it on the thing you are building

So take the thing you are building now. Before you add another column, write down the answer it is meant to give, and put it to the two questions.

First, if that answer came out wrong, would anything ever tell you? If the outcome arrives independently of what you do with the answer, build it and keep score. If acting on the answer is what picks the evidence you see, randomly test some of the choices it would otherwise turn down, or leave the decision to yourself and build the tool that lays the evidence out.

Second, say in one plain sentence what you would do instead if this did not exist, and why what you are building beats it. If that sentence will not come, you have your answer, and it is cheaper now than after the weekend.

The tell that you skipped both: you are deep in the build and neither answer is written down anywhere.

What the questions do not do

Two honest limits. The first is that even a target you can check can be the wrong target. Rank the leads by who converts and the tool may learn to love the small easy accounts and starve the big awkward ones, and it will be hitting the number you set the entire time. You can define success exactly and still have defined the wrong success. These two questions do not protect you from that. What they buy you is the right to find out you were wrong, not a promise you aimed at the right thing.

The second is that they do not make you wise in advance. Both times, I killed the tool after I had built it, not before. Asking first lowers how often you pay, but it will not take the count to zero, because now and then the only way to learn what a thing is worth is to build it and look. The questions are there to catch the builds you start because building feels easier than asking, not to promise that you will never lose another evening.

There is one last thing the questions never reach, and it was always going to be yours. When you have a target you can genuinely test, software can hand you a better answer than you would reach alone, and you should let it. What it cannot do is settle what counts as a good answer, settle how much evidence is enough, or answer for the choice to act on it. A machine can be right. Being the one who is answerable for trusting it is the part that stays with you.

The Work That Comes Due After You Leave

Tue, 25 Aug 2026 00:00:00 GMT

You finish something. A project wraps, a client signs off, a piece of work goes out for the last time. Then there is the tail, the small handful of things you do afterwards, none of which take any real time. Mark it done. Tell them it is finished. Cancel the paid seat you bought for it. Switch off the weekly update that goes out to them every Monday.

Four steps, four different places: the tracker, your email, wherever the card gets charged, whatever tool sends that update. Later you check one of them, probably the tracker, because that is where you look to see whether things are finished. It tells you the job is done, and it is telling the truth about the only step it can see.

Switching off the update is the one that did not happen. Months later it is still arriving, every Monday at nine, to someone who stopped being your client a long time ago. Nothing is wrong with the system that sends it. It is doing exactly what it was told, on time. From where you are standing, the failure looks exactly like everything working, and that is the whole of the problem.

The tracker is not lying. A job that touches four systems has four different ways of still being open, and the tracker sees only the one it holds. Done was never one state; a single word just made it look like one.

Why the small steps are the ones that go missing

The tempting explanation is that you were busy, or careless, or need a better checklist. I want to offer a more specific one, because it tells you which steps will go wrong instead of telling you to try harder.

A checklist is a list of the steps you thought of. It is good at holding you to those. What it cannot do is mention a step that never went on it, and the steps that never go on it are not random. They are the ones that cross into a system you do not quite think of as part of the job. You wrote the list around the place you do the work, and the step that lives somewhere else did not occur to you, for the same reason it will not later occur to you to check whether it happened.

Making a second list does not save you, and that is the part worth sitting with. If you build the second list from the same picture of the job, the same step is missing from it too, and now you have two records that agree with each other and are both wrong. That is not a hypothetical: your tracker is that second list. You filled it from the same picture of the job, so it agreed the work was done and was wrong in the same place you were.

And a missed closing step does not stay missed quietly. An ordinary task you skip just sits there until you come back to it; a closing step you skip stays open until something closes it, and until then it keeps acting, every day or every month, on its own.

The check has to come from somewhere you did not write

So the thing that catches the missing step cannot be your own account of the work. It has to be a record that something else kept, for its own reasons, whether or not you remembered the step.

You already have several of these. You just do not read them against the job. The card statement is one: the bank records the charge whether or not you remember the seat you meant to cancel, so the seat that is still billing turns up as a line you cannot attach to any live piece of work. The access list is another: the system logs who can get in whether or not anyone told it that a person left, so the account that outlived the project is a login with no current owner. What actually shipped is recorded by the thing that shipped it, so a promise you made and never delivered stands as a commitment on one side with no send on the other.

Even with a checklist I take seriously, I did this. I keep a written routine for finishing an essay, detailed, with a warning next to the item that slips most, and my archive quietly slipped twenty-three pieces behind what I had published since late spring. Copying each finished piece across to that archive had never been a line on the routine at all: it lived on a different system, so it never occurred to me to write it down. What caught it was the published record of what had actually gone out, kept by the platform and owing nothing to my memory. Held against the archive, it showed the twenty-three at once.

The move itself is old. Accountants have reconciled two sets of books this way for centuries, and there is nothing here to invent. What is easy to get wrong is what makes the second record worth anything: not that it is a second record, but that something other than your own memory produced it. Two dashboards drawn from the same database, or two lists built from the same picture of the job, only look like a check, because the same forgetting shaped both. A record can catch you only when your forgetting could not have reached it too.

One question to carry

That gives you a single question, and it is worth more than any checklist. Of anything you lean on to tell you a job is finished, ask: would this still be here, and still say the same thing, if I had forgotten the step entirely?

The tracker fails that question: you fill it in yourself, so a step you forget is a step you also forget to log, and it stays green over a gap it never knew about. The card statement passes, because the charge is there whether or not you remembered the seat. A check built from your own memory cannot expose the step that memory left out.

The question keeps its shape as the instrument gets bigger. A tracker, a dashboard, a report you write on your own project: each is an instrument you fill from your own picture of the work, and each is blind in the same place you are. The statement is worth more than any account you write of what you meant to do, for the same reason an audit leans hardest on evidence the audited side did not get to shape.

The part you can use

Here is the version you can run on your own job this week.

Write out the routine you run after you finish something, every step, including the ones that feel too small to be worth writing down. Mark each with the system it touches: the tracker, the calendar, the billing account, the shared drive, the tool somebody set up before you arrived. This is not the check yet. It is how you find which records are worth reading against each other, and it usually turns what felt like one job into the three or four systems it was always made of.

Then there are two ways to keep a step from being lost, and the first is much stronger. Where you can, do not rely on catching the step at all; arrange things so that forgetting it does no harm. Anything that runs on its own, a payment, a subscription, a recurring invite, an access granted for a single project, gets its end date on the day you set it up, while you still know what it was for. Something that expires unless it is renewed cannot outlast your forgetting, because forgetting it and ending it become the same act. Reach for this first; it removes the obligation instead of watching it. Its limit is the one this piece began with: you can only set an end date on a step you thought of, and the step that never made the list cannot be made self-closing.

For everything you could not foresee, or cannot make expire, there is the slower move: read your own record against one you did not produce. Your active-projects list against the vendor or card statement, looking for a charge attached to work that has already finished. Your list of who is on the team against the access export from whatever holds the accounts, looking for a login with no owner. The commitments in a signed contract against what your team actually sent, looking for a promise with no matching send. Choose the second record by the causal test, not by where it happens to be stored: pick the one your own memory did not shape.

How often you look depends on how much damage you will let build up first. A ten-pound seat can wait a month; a former colleague who can still open every file cannot, and something confidential still reaching the wrong person is not a scheduled job at all. None of it needs a tool you have to build: a read-only export or a screenshot is enough, and where you cannot pull the record yourself, the person who can is an email away, not a project. And reading across only points to a mismatch; you still have to look and decide whether it is a real miss, a timing lag or a duplicate, and keep that verdict for yourself.

What none of this fixes

Two things survive all of it, and I would rather say so than leave the tidy version standing.

The first is the record that was never kept. If something gets finished and lands in no system at all, no charge, no log, no row anywhere, then there is no second record to read it against. You cannot check against a record that does not exist. That case surfaces only when a person happens to notice, or is told.

The second is quieter, and more common. If the same blind spot sits in both records, they agree, and the agreement looks like an all-clear. This is the failure I walked into the first time I tried to build a check like this for myself. I searched my files for links to the publication. That sounds like reading an independent record, until you notice it read the same surface I would have: it counted the times I had linked to old pieces inside new ones as though that proved the old ones had shipped. Independence is the whole of the mechanism, and when it is missing it fails without a sound.

So the honest tally is smaller than the tidy one. The obligations that leave a trace in a record I did not write, I can now catch, once in a while, in half an hour. The ones that touch nothing outside my own attention, I am still carrying in my head, and I have learned how little the word covers when I say nothing is wrong. Nothing is wrong and nothing I can see is wrong are different sentences, and most of the time only one of them is available to any of us.

It Will Never Think Less of You

Mon, 24 Aug 2026 00:00:00 GMT

What telling AI the things you can’t tell anyone quietly does to being known.

You told it something the other night that you have not told anyone. Nothing dramatic, probably. A worry you have been carrying, a thing you did that you are not proud of, a feeling you did not want to say out loud to a person and then watch them look at you a little differently. You typed it to the machine instead. It was easy. It was one in the morning and it was there, and it listened, and it did not flinch.

And it helped, a little. You felt lighter for having said it. That part was real.

What it was not, though, was being known. The machine took in every word and had nothing at stake in any of them. It can keep what you told it, carry it into tomorrow, and be changed by none of it. Nothing about you can surprise it, or disappoint it, or quietly move it that you trusted it with the thing. You said the words into a room, and the relief you felt was the relief of saying them, which is real, and which is a separate thing from the one you actually wanted, which was for them to land with someone.

Safe, and unmet

The appeal is exactly the safety. The machine will never think less of you. That is the whole comfort of it, and it is worth being honest that the comfort is genuine. There are things far easier to tell something that cannot judge you than someone who can.

But a listener who cannot think less of you cannot think more of you either. The two are one faculty. Someone incapable of being disappointed in you is equally incapable of being proud of you, or surprised by you, or of carrying what you said into how they hold you next week. The machine is safe because, whatever it keeps of you, no one on the other side has anything at stake in it. So the confession is perfectly safe, and it lands nowhere.

Tell the machine and the words are received and held by no one. Tell a person and they are taken in by someone who is changed, and who now holds a little of you.

It costs more than the one evening, too. Telling the thing that cannot judge you is easier than telling a person who can, so you do it more, and slowly you get very practised at being heard by something that cannot know you, and less practised at the harder thing. The disclosure that would have gone to a friend goes to the machine instead, the friend never gets the chance, and the nerve for being actually known by someone who might get it wrong goes quiet from disuse.

The risk was the whole thing

Being known runs deeper than the handing over of facts about yourself. It is that a particular person takes you in, is changed by what they learn, and carries that changed picture forward, so that you come to exist inside another person. That needs a listener who can be affected, and anyone who can be affected can be affected badly. That exposure is what being known is made of, and the machine’s safety is precisely that it removes it.

A listener who cannot think less of you cannot think more of you. The machine never judges because no one is there to hold what you said, and being known was the one thing that could never be made safe.

A person can be moved either way, up or down, by what you tell them. The machine moves neither way, which is why it is safe, and why it cannot know you.

What to spend on a person

None of this means keep it to yourself, or never use the machine to find the words. Saying a thing out loud, even to something that cannot really hear it, is often how you work out what you actually mean. The change is smaller than that. When the thing you were reaching for was to be known, do not let the machine’s ease of listening stand in for the person you wanted to be known by. Let it help you find the words, and then spend them on someone who could get it wrong, because that risk is the price of the only thing you were reaching for, which was to be held by someone for whom it now matters.

I wrote about why the part you keep trying to remove is so often the part doing the work, the difficulty you’re escaping was making you, for anyone who has felt safe and unmet at the same time.

Confidently Wrong

Sun, 23 Aug 2026 00:00:00 GMT

The effort you’re handing to AI was doing two hidden jobs. Skip them and you get faster, weaker, and blind to your own mistakes.

In 2010, two of the most respected economists alive published a number that helped governments justify austerity across the Western world. Carmen Reinhart and Kenneth Rogoff found that once a country’s public debt passes 90% of GDP, growth doesn’t just slow. It turns negative, to an average real rate of −0.1%. The 90% line became a fact of political life. Paul Ryan’s budget cited it. The European Commission cited it. Governments invoked it as they cut into recessions.

Three years later a graduate student named Thomas Herndon asked to see the spreadsheet. He had been trying to reproduce the result for a class and couldn’t. When Reinhart and Rogoff sent him the actual Excel file, the −0.1% came apart in his hands along three separate faults. A formula that averaged the wrong range and silently dropped five countries. A set of high-debt, healthy-growth years left out of the sample. A weighting choice that let one bad year in New Zealand count as heavily as nineteen years in the United Kingdom. Correct all three and the threshold vanishes. Average growth above 90% debt was positive, at +2.2%. Higher debt still tracked somewhat slower growth, and no one had ever settled which way the causation ran. But the cliff, the part policy actually leaned on, was an artefact.¹

A result this consequential stood for three years, in careful hands, until one student reached the same question by a different path and got a different answer. An independent recomputation was the kind of check that could catch the error, and when one reached the original spreadsheet, it did.

What the difficulty was doing

AI can now lift the effort out of almost anything you find hard. It will write the memo, derive the number, draft the contract, debug the function, in a fraction of the time and often well. The useful question is which of those efforts you can hand off safely, and which you can’t.

The answer turns on something easy to miss. A hard task usually does two jobs beneath the obvious one. It builds you: the difficulty is a rep that makes you better at the task. And it checks you: the difficulty is a second, independent way of reaching the answer, the thing that catches you when your first way is wrong. Keep those two jobs apart and you know exactly what to protect when the effort disappears.

The difficulty that was checking your work

A single way of reaching an answer cannot check itself. Redo a sum the way you did it the first time and you reproduce the first mistake, faithfully. This is why your own eyes slide over your own typo on the second read, and why “measure twice” only helps if the second measurement uses a different ruler. To catch an error you need a route to the answer that would fail differently from the first. Herndon was that route. So is a test run against cases you worked by hand, or a rough estimate that ought to land in the same range.

Offloading to AI does its quiet damage at exactly that point. When you hand the hard part to a model, you keep its answer and drop the second route you would have taken. You were going to derive the number yourself. Now you don’t. The check didn’t fail. It was never run. And people do the rest of the damage on their own. Decades of research into how we use automation gives what happens next a blunt name, automation complacency: we stop cross-checking the output, even the experts, even after training, even when warned outright that the system is unreliable.² Under real workload, attention drifts off the automated task, and the sampling that would have caught the error never happens. You end up fast, and confidently wrong, with nothing in place to catch it.

Before you accept an answer you didn’t work for, ask one thing. What would have caught this if it were wrong? If you can’t name anything, you are flying blind.

The tempting fix is to ask the model to check its own work. It can catch a careless slip, but it will not give you independence. The second pass shares the first one’s machinery: the same weights, the same training, often the same framing of the problem. On an error rooted in that shared machinery, another pass tends to reproduce the mistake rather than expose it. Even real independence leaks. In 1986, John Knight and Nancy Leveson had 27 programmers each write the same program from one specification, then ran every version against a million inputs. The versions were supposed to fail independently. They didn’t. They made the same mistakes on the same hard inputs, far more often than chance allows.³ Separate people, working alone, drift onto the same errors.

A second step earns its keep only when it could fail in a different way from the first. For a number, that is a second derivation from different inputs, or a rough estimate that ought to agree. For a claim, it is the primary source, rather than a more confident summary of it. For code, it is running the thing against reality instead of reading it again. A second step that shares the first’s blind spot is decoration.

The difficulty that was building you

In 1997, an American Airlines training captain named Warren VanderBurgh gave a talk about what modern cockpits were doing to pilots. He called them children of the magenta line, after the course the flight computer paints across the navigation display. His pilots had become superb managers of automation and worse at flying. They could program the box beautifully and struggled to take the aeroplane when the box gave up. By the airline’s own reckoning, most of the automation-related trouble his team studied came back to that.⁴

Twelve years later, Air France 447 came out of the night over the Atlantic. The pitot tubes iced, the airspeed readings went unreliable, and the autopilot handed control to a crew that almost never flew by hand. One pilot held the nose up. The wing stopped flying. Through three and a half minutes of descent, as the stall warning sounded and cut out and sounded again, the crew never recognised the stall. The official report named several causes, among them a breakdown between the two pilots and the absence of any training in flying the aeroplane by hand, at that altitude, when the automation quit. The skill that might have caught it had gone unused until the one night it was needed.⁵

This is the older half of the story, and the learning research has a precise name for what was lost. Robert and Elizabeth Bjork call the effort that builds durable skill desirable difficulty: spacing practice out, mixing problem types, generating an answer before you are shown it, testing yourself instead of rereading.⁶ These feel worse in the moment. They make you slower and more error-prone today, and they build the underlying strength that makes a skill stick and transfer. One condition matters more than the rest: a difficulty is only desirable if you can actually meet it. Confusion from a bad explanation, struggle with no traction, effort you cannot yet surmount, none of that builds anything. That is what keeps the argument honest. Not every hard thing is worth keeping.

Lisanne Bainbridge saw the shape of this in 1983, in a paper called “Ironies of Automation.”⁷ The designer who removes the operator, she wrote, still leaves the operator the tasks too hard to automate, and less practised at the skills those tasks demand. Offload your reps and you become more productive and less capable at the same time, and you will not feel the second half happening. Productivity is loud. Skill decay is silent. And the person who has not built the skill yet has the most to lose: skip the reps at the start, and you never become someone who could catch the machine at all.

When the check you rely on is your own judgement, these two jobs turn out to be the same one. That check stays independent only while you can still reach the answer yourself. Offload the reps for long enough and your sense of the right answer quietly retrains on the machine’s output, until the second opinion in your head is only the machine’s first opinion, learned by heart. Knight and Leveson watched separate programmers drift onto the same mistakes. Lean on one model long enough and you become another correlated version of it.

The new cost of checking

There is a reason this bites harder now than it did in Bainbridge’s day. The old bargain of automation assumed that checking is cheaper than doing, and usually it is. Verifying a finished Sudoku takes a moment; solving it does not. AI has moved a great deal of work to the other side of that gap. When a model produces fluent, plausible output whose errors are subtle and load-bearing, the careful check can cost more than the generation did. Checking stays cheap when you have a cheap way to test the answer, a passing test, a green type-checker, a production system that stays up. It gets expensive exactly where AI is most tempting, on judgement work with no quick way to know. Budget for the check as part of the cost of the work, or you have not saved the time you think you have.

Making the call

You ask a model for the size of a market, for a board deck. It hands back a confident figure with a tidy build-up, and the effort you skipped, assembling that number yourself, was your only independent estimate of it. Paste it in and nothing stands that could contradict it. The move is one cheap second estimate from a different direction: top-down from a population and a spend rate, when the model worked bottom-up from company counts. Land in the same range and you have something real. Come out a factor of five apart and you just caught the number that would have embarrassed you in the room.

You have a model read a contract and it flags nothing. The independent route reads it differently: the specific clause checked against the actual regulation, or the colleague who got burned by this exact term last year. A second pass by the same model shares its blind spot, and will reassure you at the moment you most need to worry.

You accept a function the model wrote, and it looks right. Reading it again is your first route walked twice. Running it against cases you worked out by hand, especially the ugly boundary ones, is a route that fails differently, which is why “it compiles” and “the tests pass” are worth more than another careful read.

The rule cuts the other way just as often. A tedious afternoon reconciling two exports by hand, reformatting data, translating boilerplate, that difficulty builds nothing and checks nothing. It is effort along the one road you were always going to walk. Hand it over without a flicker of guilt. And once in a while an easy thing deserves protecting: if the only reason you would ever catch a bad assumption is that you still do the simple monthly reconciliation yourself, keep doing it, precisely because it is the cheap check that catches the expensive error.

Keep the difficulty that builds you or checks you. Shed the rest, and shed it gladly. Two things are worth guarding as machines take the effort out of your work: the reps that keep you able to notice, and the second, separate route that catches you when you are wrong. Automate everything else. Just never automate away your last independent way of knowing you are right, and never stop doing the work that would let you feel it when you are not.

Related reading: The Difficulty You’re Escaping Was Making You: the human half of this, what the effort was quietly making of you. A Green Score Is Not Evidence: when the check itself is the thing being gamed.

Reinhart & Rogoff, Growth in a Time of Debt (2010); the recomputation is Herndon, Ash & Pollin, Does High Public Debt Consistently Stifle Economic Growth?, PERI Working Paper 322 (2013). Three faults: a coding error, selective data exclusion, and unconventional weighting. Corrected average growth above 90% debt was +2.2%. ↩
Parasuraman & Manzey, Complacency and Bias in Human Use of Automation, Human Factors 52(3), 2010. Complacency appears in experts as well as novices and is not eliminated by training or warnings. ↩
Knight & Leveson, An Experimental Evaluation of the Assumption of Independence in Multiversion Programming, IEEE TSE SE-12(1), 1986. 27 programmers, one specification, ~1,000,000 inputs; the independence of failures was rejected at the 99% confidence level. ↩
Warren VanderBurgh, Children of the Magenta Line, American Airlines training (1997); AirFacts retrospective. ↩
BEA final report on Air France 447 (2012); among the cited causes, a breakdown in crew coordination and the absence of training in manual handling at high altitude. Summary via IEEE Spectrum. ↩
Bjork & Bjork, Making Things Hard on Yourself, But in a Good Way (2011). A difficulty is desirable only if the learner can meet it; confusion and untraversable struggle build nothing. ↩
Bainbridge, Ironies of Automation, Automatica 19(6), 1983. ↩

You Reach Before You Think

Wed, 12 Aug 2026 00:00:00 GMT

What leaning on AI for every small decision quietly does to your own judgement.

There was a small decision in front of you this week. What to say back to the difficult email. Whether the second option was really better than the first. How to start the thing you had been putting off. And before you had sat with it for even a moment, you had already typed it into a machine and asked.

You did not decide to do that. It is just where your hand goes now.

The answer came back reasonable, and you took it, and nothing bad happened. That is the part that makes this hard to see. Each single time, asking first is the sensible move, and no single time costs you anything you would notice.

What gets spent is slower than that. Deciding is a practised thing. It runs on reps, and every choice you hand over before trying it yourself is a rep you do not take. You will not feel them going one at a time. You notice it later, and in a smaller way than the warnings promise: your first move, when something is actually up to you, is to wonder what the machine would say.

The reach, and the relief under it

You will catch it as a reflex before you catch it as a problem. The reach for the phone in the pause where the thinking used to go. The question you send that you could have answered yourself, if you had stayed with it for thirty seconds. There is a specific relief in it, and the relief is the tell. You did not want the answer so much as you wanted to put down the not-knowing.

Notice what the not-knowing was. It was the moment the decision was still yours: the part with no clean answer, where you weigh it, pick, and find out later how it went. Run that loop enough times on enough small things and it becomes the thing you point to when you say you trust your own read.

Why the reps are the thing

A machine can give you a good answer, often a better one than you would have reached alone. That is not the problem, and pretending it is gives the game away. The problem is the order. Deciding is more than picking. It is forming a view of how a thing will go, choosing, and then finding out whether you were right and quietly adjusting. Ask before you have formed the view, and there is nothing of yours left for the result to correct.

That skipped guess is the rep you lose, and it is easy to miss because it never arrives as one bad answer. It arrives as a slow narrowing of the sense that your own first take is worth having.

The pause used to be where you weighed it. Now the hand moves before the pause opens, and the rep that would have been yours never happens.

What to keep for yourself

The tool is genuinely useful, and this is not a call to refuse it. The change is smaller and more human. Before you reach, take your own guess first. Say what you think, and why, out loud or on paper, and only then ask. Being right is a bonus; even a wrong guess gives the result something of yours to correct. Now the machine’s answer lands as a second opinion instead of the only one. You just reach for it second.

Update, October 2026: a later study adds a caution here. When analysts gave their view before an AI agent gave its own, they still switched 60% of the time if it disagreed (38 cases in Anthropic’s study). More in A Coin Flip Set the AI’s Lean.

That is really all it means to keep the low-stakes decisions for yourself. The ones where being wrong costs nothing are the cheapest practice you will ever get, so spend them on staying able to decide. The decisions that actually matter, the ones with your life in them, are the last place you want to arrive without a view of your own.

A machine can hand you the answer. It cannot correct a guess you never made. What it quietly takes is the habit of going first.

The odd part is how good it feels to hand a decision over, right up until one of the decisions is really yours to make. Keep the small ones for yourself. The guess you practise on what doesn’t matter is the one you will reach for when it does.

The bigger version of the same bargain is the friction you keep escaping, the part that was quietly building you.

You Cannot Try to Fall Asleep

Mon, 03 Aug 2026 00:00:00 GMT

Sleep is only where you notice it first. Much of what matters works the same way.

It is ten past three. You have done the arithmetic twice already. Five hours if you drop off now, four and a bit if this carries on. So you lie very still, because turning over would be an admission, and you hold your eyes shut a little too tightly, and underneath all of it there is a low, steady wanting. You want to be asleep. And the wanting is the exact thing keeping you awake.

You are failing at doing nothing. It is a strange thing to be bad at.

You are a capable person. You can learn hard things and finish dull ones and drag yourself out for a run on a wet morning when every part of you would rather stay in. Effort is the most reliable tool you own. Most of what you are proud of came out of using it. And then there is this one ordinary thing, wanted more than almost anything at three in the morning, that effort cannot touch at all. The harder you try for it, the further away it goes.

We file that under sleep being difficult and move on. But sleep is not the only thing built this way. It is only the place you notice it first, because you meet it every single night.

The wanting is the exact thing keeping you awake.

Try to stop thinking about someone, and watch what happens to the thinking. Try to be happy, directly, by deciding to be, and feel it thin out into a performance of itself. You cannot make yourself find a joke funny. You cannot force another person to love you by loving them harder; if anything, that is the surest way to send them off. You cannot decide to be interesting at the party, and the second you try, you are the least interesting you will be all evening. You cannot will yourself to relax, which is the cruellest one, because the trying is the tension.

None of these are things you do. They are things that happen to you while you are busy doing something else. Sleep arrives while you are turning over tomorrow’s meeting, and then at some point you never quite catch, you are gone. Happiness turns up on an ordinary afternoon when you were absorbed in something and forgot to check whether you were happy. You become interesting the moment you get genuinely interested in someone else. Love shows up sideways, in the middle of doing something entirely unromantic together. Each one is a by-product. The main thing was always something else.

None of this is new. The Victorians had a name for the trap.¹ They called it the paradox of hedonism, the plain observation that happiness tends to arrive only when your mind is fixed on something other than your own happiness. Aim straight at it and you miss. Aim at something worth doing and it arrives while your back is turned. Older and gentler still is the folk wisdom your grandmother had. A watched pot never boils. You will meet someone when you stop looking. Sleep comes when you stop chasing it. She was right, and she never needed a footnote.

Which makes it strange that almost everything around us now says the opposite. Try harder. Optimise. Measure it, track it, put a number on it, and by watching the number, improve it.

For plenty of things, that advice is sound. It genuinely works on the steps you walk, the pages you read, the money you put aside, because those are things you do, and a thing you do answers to attention and effort. Point a number at a behaviour and the behaviour usually moves.

The trouble starts when we point the same instrument at something that was never a behaviour. Take the sleep tracker, the small clean example of a very large mistake. It hands you a grade out of a hundred each morning for a thing you did not do, could not have done, and had no control over while it was happening. For someone already anxious about their sleep, that grade can do exactly what you would dread. There is a name now for people whose efforts to raise the sleep their tracker reports may have made their insomnia worse.² They lie there trying to earn the number, and the trying keeps them up, and in the morning the number confirms the bad night, so tomorrow they try harder still. The scoreboard becomes the insomnia.

And it does not stop at sleep. We keep a scoreboard on our own happiness now, rating the day, wondering whether we are as content as we ought to be by this point, which is a reliable way to stop being content at all. We tally our friendships, our rest, our worth, treating the whole illegible middle of a life as figures to be raised. A thing that arrives sideways cannot survive being stared at head-on. Measured, it becomes work. Graded, it becomes a test you are failing. You get all the pressure of a target and none of the thing the target was for.

Measured, it becomes work. Graded, it becomes a test you are failing.

So what do you actually do, if trying is the problem and not-trying sounds like giving up?

You learn, slowly and against every instinct this age has trained into you, to tell two kinds of thing apart.

Some things in your life answer to effort. You can decide the hour you go to bed. You can decide the phone leaves the room. You can decide to show up, to sit down at the desk, to be kind without keeping score, to call your mother, to put yourself in the path of the people you might one day come to love. Those are conditions. Conditions are real work, and they are what you can actually reach.

And then there is everything the conditions are for. Sleep. Ease. Delight. Being loved. Feeling rested. Those you cannot reach for. You can only build the conditions, honestly and without cheating, and then do the single hardest thing a person can do, which is leave the outcome alone.

Leave the outcome alone.

That last part feels like surrender, and it is, and that is exactly why it is so hard. Every part of you wants to grip. Gripping feels like caring. It feels like doing your part. But on this entire class of things, the grip is the surest way to fail, and loosening it is not laziness. It is a skill, and it may be the deepest one a life asks of you. Some effort quietly builds you. This is the other kind, spent on the one thing effort can only spoil.

It is ten past three somewhere, and you are lying very still, doing arithmetic in the dark. You have already done your part. The room is dark, the day is behind you, there is nothing left to arrange. There is nothing left to do but the one thing you cannot do, which is try. So stop. There was never anything there to try for. You have set the conditions. Now let yourself be no use at all for a while.

This is not the usual thing here. I mostly write about AI, product and markets, and the structures underneath them. This is the same habit of looking, pointed at something a lot more ordinary, and I wrote it because I kept meeting it at three in the morning rather than at a desk.

New to The Durability Curve? It is a standing argument about what survives when the tools get powerful and the surface gets cheap. Subscribe for the rest, or start with what survives.

The phrase belongs to the nineteenth-century philosopher Henry Sidgwick, and John Stuart Mill put it plainly in his autobiography: those are happiest, he wrote, who have their minds fixed on some object other than their own happiness, and who find happiness by the way. It is a very old idea with a long line of owners, which is part of why it is worth trusting. ↩
Researchers have called it orthosomnia, a fixation on achieving the sleep the tracker says you should be getting. It is a coined term rather than a formal diagnosis, first described in a 2017 case report of a handful of patients who trusted the device over their own clinician. The point is not that trackers are evil. For someone who sleeps well and glances at the score the way they glance at the weather, it may cost nothing. It is the people already lying awake who cannot afford to be graded on it. One boundary, stated plainly: this is an essay about the trying, not a treatment. If sleeplessness has become the ordinary shape of your nights, the thing that works is CBT-I, the only approach carrying a strong recommendation in the American Academy of Sleep Medicine’s 2021 guideline, and it is emphatically active: it asks you to change what you do, including getting out of bed when sleep will not come. Leaving the outcome alone is not the same as leaving a real problem untreated. ↩

The Difficulty You're Escaping Was Making You

Fri, 17 Jul 2026 00:00:00 GMT

AI can lift the effort out of almost anything you find hard. Some of that effort was the thing turning you into someone.

To drive a black cab in London you have to pass a test called the Knowledge. You spend three or four years on a moped in all weathers, learning every street inside roughly a six-mile circle around Charing Cross, something like twenty-five thousand streets, along with the thousands of landmarks strung between them. You learn to recite the shortest legal route between any two points in the city from memory, out loud, under questioning, with no map in front of you. About half of those who start never finish. Those who make it through have spent years inside a difficulty the rest of us would pay almost anything to avoid.

Then neuroscientists put those drivers in a scanner. The part of the brain that holds a spatial map, the posterior hippocampus, was measurably larger in London cabbies than in other people, and it was larger the longer they had been driving.¹ The years had taught them the city and physically reshaped the organ that learned it. That came with a trade-off, one the same study recorded and almost nobody quotes: the cabbies had a smaller anterior hippocampus. A later study by the group found the same split against bus drivers, and the cabbies did worse on a lab test of memory for new visual and spatial material.² The brain had specialised, hard, to the load the years demanded, and the gain in one place sat beside a weakness in another. That is the fact to hold onto. You take the shape of what you repeatedly do the hard way.

We have now built a machine that ends that strain, and not only for cabbies. A phone in a cradle speaks the turns, the Knowledge becomes unnecessary, the hippocampus never specialises, and the driver reaches the same address having built none of the map. This is not a thought experiment. When researchers followed habitual GPS users, the ones who leaned on it hardest had the worst spatial memory the moment they had to navigate on their own, and the more they used it over time, the steeper their decline.³ Extend that same offer to nearly every effort a human used to make, and you have described the age we just walked into.

None of this worry is new. Nicholas Carr set it out twelve years ago in The Glass Cage: a skill handed to a machine quietly wastes away, and you do not notice until the day you reach for it and it is gone.⁴ What has changed since is the reach of the offer, and how far up into thinking itself it now climbs.

The strain is the mechanism

You can feel a smaller version of this whenever you try to recall something you half know: the name on the tip of your tongue, the line you could almost rebuild. It feels like failure, and everything in you wants it to stop, so you look it up and learn almost nothing. The effort of hauling it back up yourself is the repetition that fixes it in memory. Reach for the answer the moment the search stalls, and what you looked up leaves no trace.

Psychologists have measured this directly. Give one group a passage to study by rereading it and another by testing themselves on it from memory, and the rereaders come away feeling they have learned more. They are wrong. On the exam a week later, the group that had to pull it back out of memory, the one that predicted it would remember less, remembers far more.⁵

The comfortable method felt like progress and delivered little. The uncomfortable one felt like failure and did the work.

Your body speaks the same language. Muscle grows only when you load it past comfort; the pianist improves on the bars she keeps fumbling, not the ones she can already play. The effort builds; comfortable repetition only maintains.

The precision here is easy to miss, and it changes what to worry about. You do not build focus or judgement or skill in the abstract; you build close to the thing you practise, and what carries beyond it is less than we like to think. The cabbie grew the part of the brain that holds a map, and, set beside other drivers, did worse at memorising new visual material. So the fear that these tools will make us dumber is too broad to act on. They make you specifically worse at whatever you hand over, and better at whatever you load in its place. That is a trade, and it can be a good one. The trouble is that nothing now forces you to put anything in its place. That turns every quiet decision to offload into more than it looks: a vote for the person you are about to become, cast without noticing you were voting.

The most tempting offer ever made

This is why what we have built is so seductive, and so easy to misread. A researcher put it better than I can: it is like we invented a cure for exercise and then wondered why we are out of breath all the time.⁶ We now have a machine that will do the reaching-in-the-dark for you, write the paragraph you were straining toward, structure the argument you had not yet earned, and hand back the finished thing with the difficulty lifted out. The output looks the same. Sometimes it looks better.

You might say we have done this before and come out ahead. Writing offloaded memory. The calculator offloaded arithmetic. Nobody thinks the literate or the numerate are lesser for it. Those tools changed us too, but they took over the lower floors, the storage and the sums, and left the thinking that sat on top to us. What is arriving now reaches higher up. It can produce the visible signs of understanding, the explanation, the argument, the judgement, the finished prose, without your ever having understood the thing underneath.

None of this makes the machine the enemy; it gives a great deal. In the hands of someone already skilled it may be the most powerful lever ever built, and to a beginner with no teacher, or a striver with no way in, it hands a door that used to be locked. Which way it cuts comes down to how you aim it. Aimed at the task, it is an anaesthetic: it takes the difficulty away and hands back the result, and you keep none of what the struggle would have built. Aimed at yourself, it is a trainer: you make it argue against the case you wrote rather than write the case. You attempt the recall before you let it answer; you ask it for the harder version of the problem instead of the solution. The whole difference sits in one rule most people never follow: do not ask the machine to perform the exact act you are trying to keep. Both settings are always there, but the anaesthetic is the effortless one, so the way almost everyone drifts is the one that hollows them out.

Sometimes the output is all you want, and then you should take the help and move on. But most work makes two things, not one: the output, and the adaptation the doing leaves in you. When you write something hard, the paragraph is only the first of these. The second is that the idea you were forced to hold still long enough to say clearly is now yours in a way it was not an hour before. Let the machine write it and you keep the paragraph and never build the second thing at all. The early evidence points that way. In a controlled trial, students who researched a topic with an AI assistant remembered noticeably less of it on a later test than students who worked without one. A smaller, more preliminary study found the same shape inside the head: people who wrote with an assistant showed weaker, less connected brain activity while they worked, felt less ownership of what came out, and afterwards struggled to quote the essays they had just produced.⁷

The skill you need to check the machine

There is an obvious reply to all of this, and it deserves a straight answer. If the machine does the thing well, why does it matter that you can no longer do it yourself? The cabbie with the sat-nav still arrives. The email still goes out. If the output is good, who cares which of you produced it.

Engineers ran into a version of this more than forty years ago and named it the irony of automation: hand a task to a machine and the person’s remaining job is to watch the machine and catch what it gets wrong, except that handing the task over is what wastes the skill the watching needs.⁸ Most of the time we survive it, because checking a thing is usually cheaper than making it. You can offload arithmetic and keep enough number sense to feel when a total is absurd; you can read a translation you could never have written and still catch where it goes wrong. The dangerous capacities are the ones that are their own only check. Nothing smaller than judgement can tell you whether your judgement is sound. Whether an argument holds is something you feel only with the part of you that would have built it. Taste works the same way. Hand one of those capacities over and you have kept nothing cheaper to catch the failure with; the arrangement turns circular, and you need the very thing you are losing in order to know whether losing it is safe.

And the loss hides itself, which I can show you from my own desk. I write with these tools now, and because I did not fully trust what came back, I built a second layer of them to judge the first: a panel of machine readers that scores the work. They are good. They catch what I miss. But the one time I set their verdict beside a room of real readers, the machines had marked the work almost a full point higher than the people did, and every correction that mattered came from the people, not the panel. I had believed the higher number. The judgement I had handed over was certain the work was better than it was, and it had no way to know otherwise. I only found out because I asked. That is the shape of it. The danger does not arrive when the machine hands you a bad answer. It arrives when it hands you a good one, by a route that leaves you unable to recognise the next bad one. A run of good answers is not proof that you are safe; it is the very condition under which the gap stays hidden.

Meaning tracks the difficulty you choose

The cost may not stop at competence. There is a further claim here, and I will mark it as a claim: that difficulty is also where a great deal of a life’s meaning is made. Think of someone who spent a year looking after a dying parent: the broken sleep, the paperwork, the slow reversal of who holds whom. Nobody would call it easy, and almost nobody who has done it would give it back. The meaning was not in the suffering; nobody wishes the nights had been longer. It was in the commitment they kept, which had no way to show itself except by carrying the weight. Ask people for the stretches that mattered most and they rarely name the easy ones. They name the ones that cost them. Not everything that matters is earned this way, but the part of a life that feels authored, rather than merely lived, tends to be the part you had to carry.⁹

That is the quiet weight of this technology. Its danger is in its success: it lifts out the difficulty that was doing the authoring, so smoothly that we thank it while some of the material a life is made from goes missing.

Not all difficulty is sacred

Here the argument could tip into a cult of pointless suffering, which is a stupid place to end up, so keep the qualification honest. Plenty of difficulty builds nothing at all. Some of it only takes. It takes your time and your patience, and hands back only the finished task, with nothing left in you to show for it. The tax form, the expense report, the twenty minutes lost to a broken interface. That kind is pure waste, and giving it to a machine is one of the real gifts of this era. Take the gift.

The other kind builds. It takes real effort and leaves a changed you, a capacity that stays after the task is gone. The two wear the same face, and from the inside they feel identical, both just resistance, which is why telling them apart is the whole art. One test does most of the sorting. When the task is done, look at what is left behind. If the only thing left is the finished task, that difficulty was only taking from you, and you should hand it to a machine without a second thought. If something in you is different, it was building you, and that is the one to protect.

What to do with this

So run the test on your own week. Most of the difficulty you meet is dead, and the machine should take it. But you cannot keep every difficulty that builds you either, because building one capacity tends to crowd out another, the way the cabbie’s deep map sat next to a weaker memory for new visual material. You are choosing, not collecting. Protect the few capacities you want to have built: your judgement, your taste, your way of finding your way. Keep the effort that makes them, for the version of you on the far side, the one who does not exist yet. And if you doubt any of it, the claim can lose. Pick a capacity that keeps a score, one you can test cold: your way around a city, a language you used to speak, a proof you used to be able to follow. Hand its effort to a machine for a season, then reach for it. My bet is that it comes back thinner than you left it.

But notice what that test cannot reach. Judgement and taste keep no score you can read from the inside, in time; any verdict comes late, out of a decision already made, and even then you cannot tell whether your judgement slipped or the problem was simply hard. The one instrument that could read them from the inside is the one you would be handing over. I am not asking you to keep them because the loss cannot be proved. I am asking you to look at the odds, and they are not close: in every case we can actually measure, from navigation to memory to the skills automation has quietly taken, the effect is real, and judgement is not a safe bet to be the exception. For a capacity you have chosen to protect, keep the effort, and the worst case is that you did some work a machine could have done. Hand it over, and the worst case is that you find out what you lost at the moment you need it, and can no longer rebuild it.

The cabbies had one advantage we will not. They chose the job, but not the difficulty inside it: if they wanted the badge, the city made the years compulsory, and there was no way to skip them. No institution will impose ours. That is the danger, and it is also the opening. What ends, in a world like that, is formation by default: nothing outside you will build you any more unless you choose to keep it, so more and more of what you can still do in ten years will be what you deliberately kept practising. The cabbies were made by a difficulty they were handed. We get the harder, better thing: to choose what makes us, and to become, in a world going frictionless, someone made by what they chose to keep.

Which difficulty will you keep doing the hard way, now that so little makes you?

Two studies of London taxi drivers by Eleanor Maguire’s group at University College London. Cross-sectionally, Eleanor A. Maguire et al., “Navigation-Related Structural Change in the Hippocampi of Taxi Drivers,” Proceedings of the National Academy of Sciences 97, no. 8 (2000): 4398–4403, found greater posterior hippocampal grey matter in licensed drivers than in controls, correlated with years of experience, and a smaller anterior region whose volume fell as experience grew. Longitudinally, Katherine Woollett and Eleanor A. Maguire, “Acquiring ‘the Knowledge’ of London’s Layout Drives Structural Brain Changes,” Current Biology 21, no. 24 (2011): 2109–2114, found that trainees who qualified gained posterior grey matter over three to four years while those who failed and non-drivers did not, which licenses reading the change as produced by the training. ↩
Eleanor A. Maguire, Katherine Woollett, and Hugo J. Spiers, “London Taxi Drivers and Bus Drivers: A Structural MRI and Neuropsychological Analysis,” Hippocampus 16, no. 12 (2006): 1091–1101. Compared with bus drivers, taxi drivers had more grey matter in the posterior hippocampus and less in the anterior, and did worse on a test of new visuo-spatial learning (delayed recall of a complex drawing). The comparison is cross-sectional, so the smaller anterior volume is a difference between groups rather than a measured within-person loss; the causal reading of the posterior growth rests on the longitudinal study in the previous note. When the same group tested new layouts directly, taxi drivers were significantly better than controls at executing routes through an unfamiliar town, and poorer, relative to their own new-town performance, only at learning a new district that had to be fitted into their existing map of London: Katherine Woollett and Eleanor A. Maguire, “The Effect of Navigational Expertise on Wayfinding in New Environments,” Journal of Environmental Psychology 30, no. 4 (2010): 565–573. ↩
Louisa Dahmani and Véronique D. Bohbot, “Habitual Use of GPS Negatively Impacts Spatial Memory During Self-Guided Navigation,” Scientific Reports 10 (2020): 6310. Across fifty adults, heavier lifetime GPS use was associated with worse spatial memory during unaided navigation, and a follow-up found that greater use over the intervening period predicted a steeper decline. The design is correlational and cannot fully exclude weaker navigators relying on GPS more, though the longitudinal arm points toward the habit contributing to the loss. ↩
Nicholas Carr, The Glass Cage: Automation and Us (New York: W. W. Norton, 2014). Carr argues that automating a task erodes the underlying human skill, and that the deficit stays hidden until the skill is called on again, drawing on cockpit automation and satellite navigation. The argument here builds on his, adding that the loss is specific to whatever is handed over and proposing a test for which difficulties are worth keeping. ↩
Henry L. Roediger III and Jeffrey D. Karpicke, “Test-Enhanced Learning: Taking Memory Tests Improves Long-Term Retention,” Psychological Science 17, no. 3 (2006): 249–255. Retrieval practice produced markedly better week-later retention than repeated study, even though the rereaders, asked once at the end of the study session, predicted they would remember more. The wider framing is Robert A. Bjork’s “desirable difficulties”: the difficulty must be of a kind that effortful encoding or retrieval rewards, not difficulty for its own sake. ↩
Advait Sarkar, “How to Stop AI from Killing Your Critical Thinking,” TEDAI Vienna, 26 September 2025. The quoted line is his: “It’s like we invented a cure for exercise and then wondered why we’re out of breath all the time.” His argument is that tools which remove mental effort atrophy the cognitive capacities they were meant to serve. ↩
Two strands of early evidence, the sturdier first. André Barcaui, “ChatGPT as a Cognitive Crutch: Evidence from a Randomized Controlled Trial on Knowledge Retention,” Social Sciences & Humanities Open (2025). In the trial, 120 undergraduates researched a topic using either ChatGPT or conventional methods, and the ChatGPT group later scored 57.5% on a retention test against 68.5% for the others (Cohen’s d = 0.68). More preliminary is Nataliya Kosmyna et al., “Your Brain on ChatGPT: Accumulation of Cognitive Debt When Using an AI Assistant for Essay Writing Task,” arXiv:2506.08872 (2025), a small, non-peer-reviewed study in which participants who wrote with a large language model showed the weakest EEG connectivity of three groups, the lowest reported ownership of their essays, and the worst recall of what they had just written; treat it as suggestive rather than settled. ↩
Lisanne Bainbridge, “Ironies of Automation,” Automatica 19, no. 6 (1983): 775–779. Writing about industrial control rooms, Bainbridge observed that automation leaves the operator to monitor the machine and catch its failures while removing the hands-on practice that built the skill the monitoring requires. The essay carries that paradox up into cognitive work, where the capacity being automated is increasingly judgement itself. ↩
Matthew B. Crawford, Shop Class as Soulcraft: An Inquiry into the Value of Work (New York: Penguin Press, 2009), and The World Beyond Your Head: On Becoming an Individual in an Age of Distraction (New York: Farrar, Straus and Giroux, 2015). Crawford argues that agency and selfhood are formed by submitting to a reality that resists us and is not of our making. The claim here that a life feels authored in proportion to what it demanded is his; this essay approaches it from the opposite side, through what is lost when the resistance is removed. ↩

The Safe Parts of Your Job Are the First to Go

Sat, 20 Jun 2026 00:00:00 GMT

A junior analyst spent two years getting good at building financial models. Last month she watched a colleague produce, in ninety seconds and a sentence of plain English, the kind of model that used to take her a careful afternoon. The output was not perfect. It was good enough to be frightening, and it raised the only question that matters: what part of this was ever mine?

The question has a sharper edge. The part of your work you are proudest of may have been valuable only because it used to be hard, and the hard part just got cheap.

The reflexive answers are bad ones. “Humans bring creativity.” “Humans bring the human touch.” These are comfort blankets, too vague to act on. The real answer is narrower, and it comes with a catch. Human judgment survives at five specific places, all of them sitting above the task itself, and each one can be named. Naming them is the easy half. The harder half, the part almost nobody tells you, is that the same cheap generation eating the task is thinning out how many people are left to do the part that survives.

The part that stays yours

Map every time the work genuinely needed a person and the same shape keeps appearing. Someone has to understand what the system is actually doing before trusting it. Someone has to choose which outputs are worth keeping. Someone has to approve the actions that cannot be taken back. Someone has to hold a decision steady while the outcome is still uncertain. And someone has to decide which problems are worth solving at all.

None of those is production. Every one of them is a decision about production. The analyst’s two years went into producing the model. The part that stays hers is the judgment wrapped around it: whether the model’s assumptions survive contact with reality, whether this is even the right question, whether the number is one she will stake her name on.

What survives is the deciding: whether the thing is right, whether it is worth doing, and whether you will stand behind it.

The machine is already climbing two of them

Not all five are equally safe, and pretending they are is how people get caught. Two of them run on a method you can name: understanding what the system is doing, and approving what it produces. Those are the parts that feel safest, the ones with a title on the door and a process you can defend, and that is exactly what makes them the first to go, because a method is a thing a machine can learn.

The first, comprehension, is real and also the most procedural of the five. Think of the analyst who trusts a model all quarter, not noticing it has quietly drifted. The day it is finally wrong, it is wrong in a way she would have caught a year ago, when she still built these by hand. Comprehension is judgment, but the kind that runs on a method, and a method is exactly what these systems learn. It has to be redone as the models drift, and it keeps getting cheaper to do and more dangerous to skip. It survives, but it is not where you want your weight.

Approval gates are the same story one level up. Today a person approves each tweet before it publishes, each budget change before it spends. As the systems get more trustworthy, that gate does not disappear. It rises. You no longer approve individual posts; you approve the strategy that generates them. The judgment moves from the action to the rule. Higher stakes, lower frequency, fewer people needed. If your contribution is approving individual outputs, the machine is climbing toward your rung. The subtler trap is the gate that becomes theatre: you sign off on what the system already decided, and the ceremony of judgment survives while the real deciding has moved somewhere you are not.

A rubber stamp feels like control until someone asks what you actually decided.

Approval that has become theatre: you stamp what the system already decided, and the deciding moves upstream, where you are not.

Three of them grow more valuable as execution gets cheap

The durable places share something, and it is not that machines are bad at them. A model can reproduce the safe middle of what has been done before, and do it well. None of the three asks for more of that. Taste is owning a call no one has made yet. Composure is being on the hook when it goes wrong. Meaning is caring which call was worth making at all, once the rewards are gone. A bigger model closes none of them, because none were ever about capability. A sharper model improves the recommendation; it does not make the choice less yours.

The first is taste, the willingness and the ability to throw most of the work away. A designer generates fifty options and keeps two; the fifty cost almost nothing now, and the value moved into the eye that knows which two deserve to exist. A model can mimic an eye it has been shown, even a strange and particular one. What it cannot do is own the call no one has made yet, staking a name on a judgment before there is any record it was right. So cheap generation does not level the field; it tilts it toward whoever already has the eye to filter the flood.¹

Generation is free now, so the value moved into the eye that knows what to throw away. The cheaper the tools, the more your taste is worth.

Taste is the answer most people land on, and it is a right one. The two that follow get left out, because they are harder to name and harder to fake.

The second is composure, the capacity to hold a position when the outcome is uncertain and the pressure is real. A product lead keeps the launch date when the early numbers come in soft, because she sees what the room in a panic cannot. A model can draft every email in that launch, and it can recommend holding the line. What it cannot do is be the one who could overrule that recommendation, the one whose name ends up on the call and who carries what follows. It is the same nerve that keeps a charge nurse steady when the ward turns, or lets a foreman stop a job he knows is wrong before he can prove it, far from any screen. Composure counts only when the holding is a real choice, one you can refuse and sometimes do. A signature you were always going to sign is the rubber stamp from before, not composure. You build the real thing by standing there when the call is yours.

The third is meaning, the choice of which problem is worth the work in the first place. A model can rank your options and argue well for any of them. What it cannot do is be the one the answer belongs to, the one who still cares once the rewards run dry. A manager can ask a model which project earns the most; it cannot decide whether her team is built to move fast or to be the one people trust, a choice that makes it a different company in five years and never shows up in the numbers. That is a commitment someone has to make and then live inside, and it decides which of those ranked projects gets built, defended when it gets hard, and kept alive after the first reward is gone. A model can run any mission you set it flawlessly. It cannot tell you which one is worth a decade of your life.

Three skills, then, harder than the method they replace: the taste to keep what deserves keeping, the composure to own a call you cannot be sure of, and the meaning to choose what was worth doing at all.

The three gaps a bigger model cannot close: being first to a call no one has made, being on the hook when it goes wrong, still caring when the rewards run dry.

The catch: the durable work is concentrating

Here is the part almost nobody names. Organisations are not only automating the routine; they are rearranging the work so that far fewer people are needed to exercise judgment at all. One person sets the rules an agent runs inside, with kill switches and a review cadence, where a team of ten used to weigh each call. The judgment did not vanish. It pooled into fewer hands, worth more and held by fewer people every quarter. For the people those hands used to belong to, the work flattens into something an agent runs and a single person above them signs off.

So the durable work is real, but it is not a place to hide. It is a narrowing space. As generation gets cheaper, the flood of output makes the eye that sorts it scarcer, and the shape of the organisation makes the seats scarcer at the same time, squeezed from both ends.

That is what turns the whole picture from a reassurance into a deadline. Defending the rung you stand on is the losing move; that rung is where the automation is heading, and the rungs above it are filling up. The play is to climb now, while there is still room, into the judgment that is concentrating before the seats are taken.

Go back to the analyst. She thought the model was the asset, the thing two years bought her. The model is cheap now. The asset was the judgment wrapped around it: whether she knows when not to trust the number it hands her.

Where to start

Run the test on three things you did this week. The weekly status deck is a method: defined inputs, a set format, a right answer. That is the doing, and it is leaving; what stays yours is the judgment around it, which number actually moved a decision and which is decoration. Approving the team’s copy is an approval gate, so ask the honest question, whether you are deciding or signing what the system already chose. If it is the second one, the deciding has moved above you, and the climb is to own the rule that writes the copy. Choosing which of three bets the team makes next quarter runs on no method at all, and your name is on it; that is where an hour of your attention is worth the most. Three answers, and their shape is the shape of your whole job: how much of it is the doing that is going, and how much is the deciding that concentrates.

Then start with the smallest version, because it is the one you can do today. Find one judgment you have been quietly outsourcing to “I just need a better tool” or “I just need more information.” Look closely and the tool was never the missing piece. What you were avoiding is a judgment: a matter of taste, or the nerve to make a call, or a decision about what actually matters. Name it, and start practising it on purpose. That is the work that stays yours.

The larger move is the same thing across the whole week. Each quarter, take one kind of work you have already mastered and hand it to the machine, then spend the hours it frees on the deciding instead of the doing. Hand over only what you have mastered, though, not the work you are still learning from, because the eye that catches a model’s quiet drift is built by having done the work by hand.

And claim those freed hours on purpose, because if you do not, the people above you will. The time you save gets captured upward unless you spend it climbing; left alone, it turns into more of the same work, not hours that become yours. Judgment one rung up is different: it is the rare thing you build that walks out the door with you, where the output you produce was only ever the company’s.

If you have nothing mastered yet, the move inverts. Do not rush to hand the machine the entry work it could do for you; that work is where the eye gets built. Do it by hand first, then check the machine against yourself. Early on, the hours you spend doing are the asset, not the hours you save.

One question for Monday: which judgment have you been calling a tools problem, telling yourself you just need a better system, or a bit more information?

The “generate many, keep few” practice and the claim that taste compounds unequally in an AI era are synthesised from working designers and creators alongside the taste-prerequisite stack (exposure, volume, willingness to eliminate). The mechanism: cheap generation removes the production bottleneck and leaves selection as the binding constraint, so accumulated taste becomes more decisive, not less. A model can reproduce an eye it has been shown, even an idiosyncratic one; what it cannot do is own the choice no one has made yet, which is where taste at the frontier has always lived. ↩

Access Is Not Agency

Tue, 19 May 2026 00:00:00 GMT

The tool is not the authority.

Most teams are giving agents more connectors before they have defined what the agent is allowed to change. That is not agency. That is reach with a larger blast radius.

The agent everyone calls powerful

Imagine the demo.

The agent can read Slack. It can search email. It can query the CRM. It can open GitHub issues, check the billing system, browse docs, edit a spreadsheet, draft a customer reply, and call three internal APIs.

Everyone in the room calls it powerful.

That is the first mistake.

The question is not what the agent can access. The question is what it is allowed to change.

Can it send the email, or only draft it? Can it update the customer’s plan, or only propose the update? Can it refund the invoice, revoke a token, merge the pull request, notify the vendor, reassign the ticket, delete the record, file the report, or trigger the incident workflow?

Once an agent can act through tools, the real system is no longer the model. The real system is the action contract around the model.

Access is reach. Agency is permissioned action under constraints.

This distinction sounds small until the first bad run. A read-only research assistant can waste time. An agent with billing access can create obligations. An agent with email access can speak for the company. An agent with deployment access can turn a wrong inference into infrastructure.

More tools do not automatically make the agent more agentic. More tools expand the surface on which judgment must be engineered.

A tool call is not agency

A confidence score is not evidence. A tool call is not agency.

Tool access tells you what an agent can touch. It does not tell you what the agent is authorised to decide, what must be checked, what becomes binding, or what happens after failure.

That is why the current agent conversation feels slightly wrong. People talk as if the next leap is connectors. Give the model Slack, Gmail, GitHub, Linear, Notion, Salesforce, Stripe, a browser, memory, and MCP servers, then wait for autonomy to emerge.

But a connector is not a decision right.

A connector gives the agent a door. It does not define whether the agent may walk through the door, what it may carry, who must inspect the bag, whether the door locks behind it, or who reviews the camera footage if something goes missing.

A connector is a door. Agency is a contract about who may walk through it.

This is not a metaphorical governance concern. It is the operating surface.

Security lawyers are already asking the practical version of the same question. When an agent can send emails, modify records, execute transactions, or orchestrate other systems, deployment stops looking like ordinary software access and starts looking like delegated operational authority. The useful questions become blunt: what authority does the agent have, can it read only or modify systems, which actions require human approval, how is behaviour audited, and how do you stop it if it becomes a threat?¹

That is the missing layer in most agent demos. They show reach. They do not show authority.

The stack nobody wants to name

If you want to know whether an agent has real agency, do not start with the model card. Start with the rights stack.

What can it see?

What can it change?

What must it prove before the change becomes real?

What triggers escalation?

What permission disappears after a bad run?

That last question matters most because it reveals whether the system has a memory of failure. A human employee loses trust after a bad judgment. They may lose budget authority, approval rights, admin permissions, or the ability to act without supervision. Most agents do not lose anything. They fail, get patched, and return with the same action surface.

That is not delegation. That is amnesia with API keys.

An agent action stack has at least five layers.

The first is visibility: which data, tools, documents, messages, logs, tickets, accounts, and systems the agent can inspect.

The second is mutation: which objects the agent can change. Reading a customer record and changing a customer record are different powers. Drafting a reply and sending a reply are different powers. Proposing a deployment and executing a deployment are different powers.

The third is proof: what the agent must produce before a mutation becomes real. That could be a test run, a diff, a trace, a policy check, a second-model review, a human approval, a simulated dry run, or an evidence bundle.

The fourth is escalation: when the agent must stop and hand the decision to someone else. Not “human in the loop” as a slogan. A named escalation condition. Missing context. High reversibility cost. Conflicting instructions. External communication. Payment movement. Privilege change. Legal exposure.

The fifth is revocation: what changes after the agent fails. If a bad run does not shrink future permissions, the system has no operational immune response.

The hard part is not giving the agent a tool. The hard part is deciding when the tool stops being available.

This is why “least privilege” becomes more important in agent systems, not less. A normal app executes known code paths. An agent chooses a path through a tool surface at runtime. The permission is no longer just “can this service account call this API?” The question becomes “for this task, with this evidence, under these constraints, should this agent be allowed to perform this action now?”

That is a different shape of access control.

The bottleneck moved from capability to authority

You can see the migration in deployed behaviour.

Anthropic’s research on agent autonomy is useful because it does not only ask what models can theoretically do. It looks at real product behaviour. In Claude Code sessions, the long tail of unsupervised turns got longer between late 2025 and early 2026. More interestingly, experienced users both auto-approve more and interrupt more. They do not simply trust the agent blindly. They shift from approving every step to letting longer runs proceed, then intervening when timing, uncertainty, or risk demands it.²

That is what practical autonomy looks like. Not zero oversight. Selective oversight.

The better the agent gets, the less useful per-step approval becomes. But that does not make approval disappear. It moves approval upward.

The better the agent, the higher the approval rises. Selective oversight beats per-step oversight only when the boundaries are named.

Instead of “may the agent call this tool?” the important question becomes “which category of action is this, under which authority, with which proof, and what happens if the run crosses a boundary?”

This is why a more capable agent can make a weak control stack worse. It will move faster through a larger action surface. It will chain tools. It will recover from errors. It will confidently produce intermediate artefacts that look plausible. It will make the system feel smoother right up to the point where the wrong action becomes real.

The bottleneck has moved. It is no longer only model capability. It is decision-rights routing.

Who gets to decide what?

Under which conditions?

With what evidence?

With what right to commit the change?

With what right to continue after failure?

The organisations that answer those questions will get more agency from smaller tool surfaces than the organisations that connect everything and call it autonomy.

Older institutions already know this

Companies do not give humans “access” and call the job designed.

A junior analyst can see a model. They may not approve a trade.

A support rep can view a customer record. They may not issue a large refund without approval.

An engineer can open a pull request. They may not deploy to production alone.

A finance employee can prepare a payment. They may not release it without a second sign-off.

Corporate delegation is an action-rights system. So are IAM, accounting controls, and clinical protocols. They all separate seeing, recommending, approving, executing, logging, and reviewing.

A control system without revocation is not a control system. It is trust with a longer leash.

Agents are forcing software teams to rediscover that distinction inside product architecture.

The strongest academic frame I found for this comes from a 2026 paper on Autonomous Administrative Intelligence. The paper is conceptual, not empirical, so it should not be treated as proof that the architecture works. But its structure is exactly the one agent teams need to notice: strategic control, agentic decision formation, and governance validation are separate layers. The agent may form an administrative decision. A governance layer validates it against rules and constraints. Execution and recording happen only after that validation. Humans shift from constant supervision toward intent, boundaries, and exceptions.³

That is the right shape.

Do not ask whether the agent can complete the task.

Ask where decision formation ends and validation begins.

If those are the same place, the agent is not operating under an action contract. It is operating under trust.

Trust is not bad. Trust without revocation is not a control system.

Tool design is contract design

This is where tool protocols start to matter, but not for the reason most people say.

The industry is building standard ways for agents to connect to external systems. The most prominent is MCP, Anthropic’s Model Context Protocol. The lazy version of that story says MCP is important because it gives agents more tools. The better version says it is important because it makes the tool boundary explicit enough to inspect, version, test, authorise, and debug.

That distinction is not just engineering taste. It changes what you can see when things go wrong. Anthropic’s own engineering guidance frames tools as contracts between deterministic systems and nondeterministic agents. Their names, descriptions, return values, and failure modes affect whether an agent can use them reliably. A tool built for a human developer is not automatically a good tool for an agent.⁴

Once you accept that, the “more connectors” story becomes incomplete. Tool count is not the win. Contract quality is the win.

Tool count is not the win. Contract quality is the win.

A strong tool contract tells the agent what the tool does, what inputs it needs, what output means, what failure looks like, and what the agent should not infer. A strong action contract goes further. It says when the agent may call the tool, when the call may mutate something, what proof is needed, and where the trace goes.

Early benchmarks show why. When researchers tested agents across hundreds of real tools and multi-step tasks, their first report traced the main failures to tool use and task understanding. Their revised report, published the day this essay ran, found most diagnosed failures were cognitive rather than tool-call errors, and several strong models failed after their tools had run correctly, by stopping early or combining the results wrongly.⁵ The score on the final answer only said that a run had failed. Finding out why took a second pass over each agent’s trace.

That is the pattern to watch. Tool-using agents need diagnostics at the contract layer, not only at the output layer.

If your agent can touch ten systems and your only observable is “task succeeded,” you are blind in the place where the system is becoming dangerous.

The Agent Action Rights Test

Run this on the most powerful agent or workflow you currently use.

Do not pick a toy. Pick the one you are most tempted to trust. The coding agent with repo access. The sales assistant with CRM access. The ops agent with incident tooling. The analyst agent with warehouse access. The support agent with customer email access.

Then answer five questions without hand-waving.

What can the agent see?

What can the agent change?

What must it prove before the change becomes real?

What triggers escalation to a human?

What permission disappears after a bad run?

Most teams can answer the first question.

Some can answer the second.

Almost no teams can answer all five.

That is the diagnostic.

If you cannot answer “what can it see?”, you do not have an inventory.

If you cannot answer “what can it change?”, you do not have a permission model.

If you cannot answer “what must it prove?”, you do not have verification.

If you cannot answer “what triggers escalation?”, you do not have oversight.

If you cannot answer “what permission disappears?”, you do not have learning at the authority layer.

You may still have a useful agent. You may even have a high-performing one. But you do not yet have trustworthy agency. You have a tool-using system whose action rights are partly implicit.

Implicit action rights always become visible after an incident.

The dangerous middle

There is a tempting objection here.

If we make every action permissioned, verified, escalated, logged, and revocable, will we not kill the point of agents?

Yes, if you do it badly.

The goal is not to turn every agent into a form-filling intern that asks permission before breathing. The goal is to match authority to consequence.

Read-only Slack search should be cheap. Drafting a customer reply should be cheap. Local reversible edits should be cheaper than external irreversible commitments. Sending the customer email, refunding the invoice, revoking the token, merging the pull request, or releasing the payment should pass through stronger gates.

Good action rights are not one wall around the whole system. They are a slope.

Good action rights are a slope, not a wall. Authority should track consequence.

The agent gets wider freedom where mistakes are cheap, visible, and reversible. It gets narrower freedom where mistakes are expensive, silent, and hard to undo.

That is also how good human organisations work. The graduate can model scenarios. The manager can approve a small budget. The director can reallocate headcount. The board can approve the acquisition. Authority changes with consequence.

Agents need the same gradient.

The mistake is treating “human approval” as the only safety primitive. Approval is expensive. It also fails when humans approve too much, too fast, or without the evidence needed to judge. The better primitive is action-rights design: proof requirements, escalation rules, default-deny mutations, bounded autonomy, time-limited permissions, separate approval and execution, traces that survive, and permissions that shrink after failure.

That stack is harder than adding another connector.

That is why it will matter.

What to build next

If you are building or buying agent systems, ask for the action contract before the roadmap.

Ask the vendor to show the permission tiers, not only the integration list.

Ask which actions are read-only, draft-only, approval-gated, automatically executable, or forbidden.

Ask where traces live.

Ask how tool calls are mapped to business authority.

Ask what happens when the agent is tricked, confused, stale, incomplete, or too confident.

Ask how a bad run changes the next run.

This is where the serious agent market will split.

One side will sell reach: more connectors, more memory, more tools, more environments, more background work.

The other side will sell agency: permissioned action, bounded autonomy, proof before commitment, escalation when context breaks, and revocation when trust is lost.

Reach will demo better.

Agency will survive contact with the organisation.

Reach demos well in the room. Agency holds up in the incident review.

Before next week, run the Agent Action Rights Test on one workflow. Not your whole stack. One agent. One workflow. Write the five answers in a note. If the fifth answer is blank, you found the missing layer.

The agent did not need another tool.

It needed a smaller right to be wrong.

If you run the test, which answer was hardest to fill: what it can see, what it can change, what it must prove, when it escalates, or what permission disappears?

If this piece landed

This article builds on the claim that a confidence score is not evidence. If the rights stack resonated, the deeper version is Your AI Agent Stack Is Solving The Wrong Problem, which walks through the full contract stack for agent systems. And if you want the five laws that run underneath all of it, start with The Five Laws of Durable Systems.

Subscribe to The Durability Curve for the next piece in this sequence.

Stoel Rives, Securing and Contracting Agentic AI (20 February 2026), https://www.stoel.com/insights/publications/securing-and-contracting-agentic-ai. The page is especially useful because it moves quickly from generic “agentic AI” language to concrete authority, IAM, audit, monitoring, integration, and shutdown questions. ↩
Anthropic, Measuring AI Agent Autonomy in Practice (18 February 2026), https://www.anthropic.com/research/measuring-agent-autonomy. Treat the metrics as first-party vendor telemetry, not independent industry prevalence. The useful point here is the oversight pattern: longer autonomous runs coexist with experienced users interrupting more selectively. ↩
Aravindh Sekar, Autonomous Administrative Intelligence: Governing AI-Mediated Administration in Decentralized Organizations, Administrative Sciences 16(2), 95 (12 February 2026), DOI 10.3390/admsci16020095. The article is theory-building, not empirical validation, but its separation of strategic control, agentic decision formation, validation, execution, recording, and exception governance is the right architectural distinction for this argument. ↩
Anthropic, Writing Effective Tools for AI Agents (2025), https://www.anthropic.com/engineering/writing-tools-for-agents. Anthropic frames tool definitions as contracts between deterministic systems and nondeterministic agents, and emphasizes realistic multi-step tool evaluations rather than single-call demos. ↩
Bandi et al., MCP-Atlas: A Large-Scale Benchmark for Tool-Use Competency with Real MCP Servers (arXiv 2602.00933; first version January 2026, revised 19 May 2026), https://arxiv.org/pdf/2602.00933. The benchmark reports 36 MCP servers, 220 tools, and 1,000 tasks. The first version reported “primary failures arising from inadequate tool usage and task understanding”. The 19 May version reports that “63.3% of diagnosed failures are cognitive rather than tool-call related” and that several high-performing models “fail after successful tool execution due to premature stopping or incorrect synthesis”; its diagnostic judge reads each failed run’s trace to locate the cause. ↩

AI Made You Faster. It Did Not Make You Safer.

Mon, 04 May 2026 00:00:00 GMT

The private feeling under the productivity story

The new anxiety does not always arrive as panic.

Sometimes it arrives at 11:17 on a Tuesday morning, just after the work goes strangely well.

You had blocked out the whole morning for the thing you were avoiding. A deck. A research memo. A customer summary. A bug you did not want to touch. A product plan that had been sitting in your notes for a week because the first draft felt too heavy to start.

Then the model does enough of it in twenty minutes.

It is not perfect. It is enough.

The page is no longer blank. The meeting transcript has structure. The argument has headings. The spreadsheet has an explanation. The first version of the plan exists. You can see the shape now.

For a moment, this feels like relief.

Then something quieter arrives underneath it.

If the thing that made me feel useful can appear this quickly, what exactly was scarce about me?

That is the feeling most AI productivity advice does not touch. It tells you to move faster, ship more, automate the boring parts, become a one-person team, learn agents, build workflows, and use the latest model before someone else does.

Some of that advice is useful.

But it skips the part people are actually carrying.

The obvious fear is that AI might take work away. The deeper fear is that AI is making the old proof of work weaker while everyone is still pretending productivity is the whole story.

You can feel more capable and less safe at the same time.

That is the paradox.

So this piece has to do more than diagnose the feeling.

By the end, you should have three things you can actually use:

a way to tell whether AI is making your work safer or just faster
a workflow for turning AI output into proof someone can trust
a prompt pattern you can copy whenever the task matters

The aim is not to make you feel better about AI.

It is to give you a better instrument for deciding where your value should move next.

The data now has a human shape

Anthropic recently published research based on roughly 81,000 Claude users. The headline is bigger than people using AI at work. Everyone knows that now.

The interesting part is the contradiction.

People reported meaningful productivity gains. Anthropic rated the average inferred productivity gain at 5.1 on its scale, corresponding to “substantially more productive.” Among respondents who described productivity effects, 48 percent talked about expanded scope, while 40 percent talked about speed.

But one fifth of respondents also voiced concern about economic displacement. People in the most AI-exposed jobs mentioned job threat roughly three times as often as people in the least exposed jobs. Early-career workers were more nervous than senior workers. And the people reporting the largest speedups were also more likely to worry about AI’s job impact.

That last point matters.

The speedup did not automatically produce confidence.

Sometimes the speedup was the reason confidence cracked.

Computerworld framed the same tension as the AI workplace paradox: higher productivity, higher anxiety. Developers, IT workers, market researchers, QA analysts, support specialists, and other exposed roles are not standing outside the technology, speculating about a distant future. They are using the tools. They are feeling the acceleration directly.

This is why the conversation feels stranger than an ordinary technology cycle.

The tool is useful, and its usefulness is part of the fear.

The trap is mistaking speed for safety

The optimistic version says productivity is protection.

If you use AI well, you become faster. If you become faster, you become more valuable. If you become more valuable, you become safer.

That chain sounds reasonable until everyone else gets access to the same speed.

Speed protects you only while speed is scarce.

Once speed becomes ambient, it stops being the proof. It becomes the baseline. The task that used to take a morning now takes twenty minutes. The analysis that used to look impressive now looks normal. The clean first draft no longer proves you wrestled with the problem. The slide no longer proves you saw the structure. The code no longer proves you understood the trade-off. The summary no longer proves you read the source carefully.

The visible artefact still matters.

It just means less than it used to.

This is the same pattern that appears whenever a layer gets cheap. The bottleneck migrates. When generation gets cheaper, verification gets more valuable. When output gets easier, judgement gets more important. When speed becomes common, the question moves from “Can you produce?” to “Can anyone trust what you produced?”

That is where the anxiety comes from.

People are competing with a new standard of evidence.

There are two kinds of AI productivity

The Anthropic data separates something important: scope and speed.

Speed means AI helps you do a task faster.

Scope means AI helps you do something you could not do before.

Those do not feel the same.

The useful question is whether the speedup moved you toward a stronger proof layer, or merely made the old surface cheaper.

If AI lets a founder build a prototype, a designer test more visual directions, a marketer analyse customer interviews, or a non-technical operator make a tool that used to require an engineer, that can feel like expanded agency. The person is moving inside a larger box.

But when AI mainly accelerates the work you were already paid to do, the feeling can turn unstable.

The task shrinks.

The expectation rises.

The proof weakens.

What used to count as a full day becomes half a day. What used to be impressive becomes table stakes. What used to be a training ground becomes automated away before it can teach anyone.

Computerworld quoted Sanchit Vir Gogia making a point every manager should sit with: faster generation can raise expectations on quality, and more output can feed decision pipelines that were already constrained. In some cases, the system becomes heavier, not lighter.

That is the part the productivity story misses.

AI does not enter a clean system. It enters existing approval chains, status games, hiring ladders, review rituals, political incentives, overloaded managers, insecure juniors, under-defined roles, and metrics that already confused movement with progress.

Acceleration inside a confused system does not automatically produce clarity.

Sometimes it produces faster confusion.

The entry-level problem is really a proof problem

One of the most important lines in the Computerworld piece is not about job loss directly.

It is about the path into the job.

Basic coding, documentation, routine analysis, QA, structured support, and first-pass research are often described as low-level work. That makes them sound expendable. But for a person becoming competent, low-level work is not just production. It is training.

The junior analyst builds the simple model before they learn which assumptions matter.

The support rep handles repetitive tickets before they understand the product’s real failure modes.

The marketer writes the bad first drafts before they develop taste.

The developer fixes small bugs before they can reason about architecture.

The researcher summarises sources before they can see what the sources are hiding.

If AI compresses that layer, the organisation may feel more efficient now and discover later that it has quietly damaged the apprenticeship path that produced judgement.

This is why “AI will automate the boring work” is too simple.

Some boring work is waste.

Some boring work is load-bearing.

You do not know which until you ask what capacity the friction was building.

If the friction was only moving information from one box to another, automate it.

If the friction was teaching the person how the system fails, be careful.

You may be removing the part of the work that turned exposure into judgement.

What still proves you are valuable?

When output gets cheap, value does not disappear.

It moves.

The old proof was often attached to the surface: the memo, the deck, the clean code, the finished research, the generated strategy, the polished artefact.

The new proof has to move closer to the system around the artefact.

That means your safest work is no longer just the part that produces the answer. It is the part that makes the answer worth trusting.

There are five places to look.

Problem choice: did you aim the tool at the right question?

Source judgement: did you know what evidence deserved belief?

Rejection: did you know which plausible output to delete?

Ownership: can you explain and stand behind the final version?

Learning loop: does the work make the next decision better, or only create the next artefact faster?

This is the migration map.

If AI makes the visible artefact easier to produce, your value has to move into the judgement system that decides what gets produced, what gets trusted, what gets rejected, and what gets shipped.

That is the article in one sentence:

Stop trying to be the fastest producer of the surface. Become the person who can make the surface trustworthy.

The work is not gone. The work has moved.

This is the mistake in both the panic and the hype.

The panic says AI will do the work.

The hype says AI will free us from the work.

Both assume the work is the visible task.

But in most serious knowledge work, the task was never the whole job. The task was the part of the job that could be named.

Write the memo.

Fix the bug.

Summarise the meeting.

Build the model.

Draft the plan.

Make the deck.

Compare the vendors.

Ship the feature.

Underneath those tasks was the harder layer: knowing what mattered, noticing what was missing, making trade-offs, protecting context, earning trust, sequencing effort, resisting bad incentives, and deciding what you were willing to stand behind.

AI attacks the named layer first.

That does not make the unnamed layer less important.

It makes the unnamed layer harder to avoid.

The person who only became faster at producing surfaces may feel less safe because the market can now buy more surfaces. The person who becomes better at deciding which surfaces deserve trust is moving toward the new bottleneck.

That is the difference.

The speed-to-proof workflow

The practical move is simple.

If AI has made a task faster, do not stop at the speedup. Run the output through four layers.

This is the part to actually use. Open a real AI-assisted task from this week and walk it through the sequence below. A meeting summary, product plan, hiring screen, research memo, code change, customer email, investment note, content draft, or strategy doc all work.

A saveable workflow for turning AI output into something another person can trust.

1. Name what got cheaper

Start by identifying the layer AI compressed.

Did it make the first draft cheaper?

Did it make search cheaper?

Did it make summarising cheaper?

Did it make visual exploration cheaper?

Did it make coding the obvious path cheaper?

This matters because the cheapened layer is no longer where you should look for safety. If AI made first drafts cheap, a first draft is not proof. If AI made summaries cheap, a summary is not proof. If AI made prototypes cheap, a prototype is not proof.

The first move is to stop treating the compressed layer as the evidence layer.

2. Convert the output into claims

AI output is usually shaped like an artefact: memo, plan, draft, slide, answer, summary, code.

Proof starts when you break that artefact into claims.

Use this format:

Claim:

What is this output asking us to believe?

Evidence:

What source, observation, customer fact, test, or prior decision supports it?

Risk:

Where could this be wrong, brittle, misleading, or overconfident?

Owner:

Who is willing to stand behind this after the model disappears?

Next test:

What would we check before acting on it?

That small format changes the work.

The output stops being a polished surface and becomes an object someone can inspect.

This is why the workflow matters. Most AI tools make artefacts easier to create. This makes artefacts easier to trust.

3. Add a verifier before you add volume

Most people respond to AI speed by increasing output.

More drafts. More options. More experiments. More content. More code. More analysis.

That is tempting, but it is often the wrong order.

If generation got faster, the next investment should be verification.

Before increasing volume, decide what would make the output trustworthy:

source check
customer check
counterexample search
second-person review
test suite
evaluation rubric
decision log
rollback path

The rule is simple:

Do not scale the output until you have scaled the proof.

Otherwise AI has not made you safer. It has made your uncertainty more productive.

4. Build memory around the decision

The final layer is memory.

Not memory in the vague “save your prompts” sense. Decision memory.

For any meaningful AI-assisted work, preserve four things:

what the model produced
what you changed
what you rejected
why the final version deserved trust

This is where a person becomes harder to replace.

Their advantage is the visible judgement path, not the typing.

A worked example: the meeting summary that can hurt you

Take the most ordinary possible example: a meeting summary.

This is exactly the kind of work people are happy to hand to AI because it feels low-risk. The meeting happened. The transcript exists. The model can summarise it. Everyone gets their time back.

But a summary becomes consequential the moment people act on it.

Imagine a product team has a customer call about churn. The AI summary says:

Customers are leaving because onboarding is confusing. Next step: simplify onboarding emails and create a better help centre flow.

That sounds useful. It might even be right.

But if you ship from that summary, you have skipped the proof layer.

Run the workflow.

What got cheaper?

The transcript-to-summary step. The old proof was: “someone listened carefully and understood the customer.” That proof is now weaker because a plausible summary can arrive without careful listening.

What claims are being made?

Claim one: customers are leaving because onboarding is confusing.

Claim two: email and help-centre changes are the right response.

What evidence supports them?

Maybe three customers mentioned confusion. But did they churn because of it, or did they mention it after already deciding the product was not valuable enough? Did power users say the same thing? Did support tickets show the same pattern? Did activation data show drop-off at onboarding, or later when the product failed to become a habit?

What is the risk?

The team might fix the easiest visible complaint while missing the real retention problem.

Who owns the judgement?

Someone has to say: “I believe onboarding is the bottleneck” or “I think onboarding is only the polite surface reason.”

What is the next test?

Pull the last ten churned accounts. Compare transcript complaints with usage data. Look for whether confusion appears before disengagement or after it. Then decide whether onboarding is the cause, a symptom, or a convenient story.

Now the AI summary has become useful.

The summary became useful because it was turned into claims, evidence, risks, ownership, and a next test.

That is the difference between an AI output and a decision-grade artefact.

Two prompts: one makes output, one builds proof

Most AI prompting still aims at surface production.

That is fine for low-stakes work. It is weak for anything that affects customers, strategy, hiring, money, reputation, or trust.

Compare the difference.

Surface prompt:

Summarise this meeting transcript and give me the key action items.

Proof prompt:

Turn this meeting transcript into a decision-grade summary.

Separate:
1. Decisions actually made
2. Open questions still unresolved
3. Claims that need evidence
4. Risks or assumptions people glossed over
5. Actions, owners, and deadlines
6. What should be verified before anyone acts on this

If the transcript does not support a conclusion, say so.

The first prompt makes a cleaner artefact.

The second prompt creates a trust surface.

Another example:

Surface prompt:

Create a launch plan for this product.

Proof prompt:

Create a launch plan for this product, but organise it as a proof system.

For each recommendation, include:
- the customer belief it depends on
- the evidence we currently have
- the weakest assumption
- the first cheap test
- the failure signal that would make us stop
- the person who owns the decision

Do not optimise for a confident plan. Optimise for a plan we can safely learn from.

This is the shift.

Do not ask AI only to produce the thing.

Ask it to expose what would make the thing trustworthy.

That one change is often enough to separate useful AI work from impressive-looking noise.

What managers should learn

If you manage people, do not treat AI productivity as a simple capacity increase.

The lazy version is to say: the same person can now do twice as much, so expectations should double.

That may work for a quarter.

It may also destroy the slower system that produces competence.

If AI removes junior tasks, you need a new apprenticeship path. If AI increases output, you need a stronger verification layer. If AI expands scope, you need clearer ownership. If AI makes everyone faster, you need better judgement about which work deserves speed.

The management question is not:

How much more can we get?

The better question is:

What proof of competence did the old work produce, and what replaces it now?

That question turns into three concrete management moves.

First, protect an apprenticeship layer.

If AI removes junior tasks, deliberately replace the learning function those tasks used to serve. A junior person still needs reps in debugging, source judgement, customer contact, messy data, ambiguous trade-offs, and the slow discovery of what “good” looks like.

Do not let “the model can do that now” become “nobody learns how the system works.”

Second, create a verification budget.

For every AI-assisted workflow, decide how much time belongs to output and how much belongs to proof. A rough starting rule:

If the work affects a real decision, spend at least 30 percent of the saved time on verification.

If a task used to take three hours and AI makes it take one, do not automatically fill the extra two hours with more tasks. Put some of that time into checking assumptions, testing edge cases, improving the rubric, or teaching someone how the decision is made.

Third, require an ownership receipt.

Before important AI-assisted work is shipped, ask for a short note:

What did AI produce?
What did the human change?
What was rejected?
What evidence supports the final version?
What would make us revise this?
Who owns the outcome?

This is not bureaucracy.

It is how you prevent productivity from quietly destroying accountability.

Most organisations will not ask that early enough.

They will celebrate acceleration, then wonder why trust, training, review quality, and decision clarity did not improve at the same rate.

That is how productivity becomes a trap.

What individuals should learn

If you are using AI and feeling the strange mix of power and unease, do not dismiss it as irrational.

The feeling is information.

It may be telling you that your work has been over-identified with a surface AI is now compressing.

That does not mean you are obsolete.

It means your old proof is weakening.

Move your effort upward.

Getting faster at drafting helps. Deciding what deserves to be drafted matters more.

Generating more options helps. Deleting the wrong ones matters more.

Summarising faster helps. Knowing which source deserves belief matters more.

Automating the workflow helps. Owning the exception matters more.

Producing the answer helps. Explaining why the answer should be trusted matters more.

The safest person in the AI workplace will not be the person with the most outputs.

It will be the person whose judgement becomes more visible as output gets cheaper.

The practical move is to keep a proof log for one week.

Nothing elaborate. Just five columns:

Task
What AI made faster
What still required judgement
What proof I added
What I learned

At the end of the week, look for the pattern.

If most of the log is “AI made me faster” and the proof column is empty, you are becoming more efficient at the surface.

If the proof column gets stronger, you are building the layer that travels.

That is the difference between using AI as an output multiplier and using it as a judgement amplifier.

If you want the shortest version, use this:

Before AI: What was hard?
After AI: What became easy?
Risk: What old proof got weaker?
Move: What proof do I need to add now?

That is the whole personal strategy. Keep the speed. Move the proof.

The real promise

AI made many people faster.

That is real.

It also made many people less sure what their speed proves.

That is real too.

The next few years will be full of advice telling people to use AI more, ship more, automate more, and become more productive. Some of that advice will help. Much of it will leave the deeper wound untouched.

Because the central question has changed.

What becomes more trustworthy because I was involved?

That is the standard.

The old tests are too small: whether you touched every word, refused the tool, or produced more than the person next to you.

The better test is whether your involvement made the work more true, more useful, more accountable, more connected to reality, and harder to misunderstand.

That is the layer to build now.

Keep the speed.

Move the proof.

The person who wins in the AI workplace will not be the one who looks busiest after the surface gets cheap.

It will be the one whose judgement is easiest to trust.

The Field Card

What Proves You Can Think?

Sat, 02 May 2026 00:00:00 GMT

AI did not just make output cheap. It broke the old contract between effort, competence, and trust. The next scarce signal is proof of judgement under conditions where the surface itself can be faked.

The private question under the public panic

The question people ask in public is usually safer than the one they are carrying.

In public, they ask whether AI will take their job.

That is a real question. It matters. People have mortgages, families, obligations, and a private picture of what the next ten years were supposed to look like.

But the job question is not the whole wound.

Underneath it is something harder to say:

If the work no longer proves I can think, what does?

That is the nerve.

It has little to do with productivity, prompting, or tool fluency. It is not really about whether the latest model can build a deck, write working code, or draft a strategy faster than you can read this sentence.

The deeper disturbance is that the visible artefact has become a weaker signal.

A polished answer used to imply that someone had wrestled with the problem. Not perfectly. People have always bluffed, copied, exaggerated, and decorated weak thinking with confident prose. But effort left traces. If a memo was clear, maybe someone had done the reading. If a portfolio was strong, maybe the person had taste. If a student essay was coherent, maybe the student understood the material. If a candidate wrote a thoughtful cover letter, maybe they had thought about the role. If a junior analyst built a clean model, maybe they had earned some trust.

The artefact was never proof.

But it was evidence.

AI weakens that evidence. It does not erase it, but it changes what the evidence means. The surface can now arrive without the struggle that used to give the surface some weight.

That is why the anxiety feels larger than a labour-market forecast.

People are not only afraid that machines will do tasks. They are afraid that the old ways of proving themselves will stop working.

The old proof contract

Every institution runs on proof contracts.

A school asks for essays, exams, projects, and degrees. A company asks for CVs, interviews, work samples, and performance reviews. A market asks for traction, revenue, retention, and reputation. A publication asks for essays, taste, consistency, and a visible record of judgement.

None of these signals are pure. They are all compromises.

The CV was always a marketing document. The essay was always a partial view of understanding. The interview was always distorted by nerves, charm, preparation, status, and bias. The portfolio could hide how much help the person had. The degree could compress years of uneven learning into a brand name. The performance review could reward politics as much as contribution.

Still, these signals worked well enough to coordinate around.

They worked because many polished surfaces were costly to produce. You could fake some of them some of the time, but not all of them without effort, context, relationships, and repeated exposure. Cost created friction. Friction created signal.

That was the old proof contract:

The artefact is not the ability, but it is expensive enough to be treated as evidence.

AI attacks the “expensive enough” part.

It does this unevenly. Plenty of work stays hard. Skill gaps between people are as real as they ever were. Domain knowledge, taste, context, and accountability still matter.

What it compresses is the cost of appearing competent.

That is enough to break a lot of systems.

If the cost of producing a competent-looking first draft falls, the first draft stops proving what it used to prove. If the cost of sounding strategic falls, strategic prose becomes less informative. If the cost of producing a clean application falls, hiring teams receive more polished noise. If the cost of generating an essay falls, readers and schools learn to distrust the shape of polish itself.

The collapse is not that nobody can think anymore.

The collapse is that the old proxy no longer tells us who can.

What AI made cheap, and what it left scarce. The scarce column is the proof that still counts.

Why the anxiety is rational

This is why “adapt” often lands badly.

It sounds sensible from far away. Use the tools. Learn faster. Become more productive. Move up the value chain. Let AI do the routine work and focus on judgement.

Much of that is correct.

It is also incomplete.

If someone’s fear is only that their task list will change, “adapt” is an answer. If their fear is that the proof system around their competence is dissolving, “adapt” can sound like a refusal to look at the loss.

A 2026 Frontiers in Psychology paper analysed 1,454 Reddit narratives about AI-driven job displacement. Its authors describe “algorithmic anxiety” not simply as fear of job loss, but as a broader disruption to the workplace psychological contract. The themes they identify include shattered trust, eroded professional identities, devalued expertise, and a creeping cynicism about whether adapting is even possible.¹

That list matters because it names the real object.

People are not responding to a tool in isolation. They are responding to a breach in the bargain. Work was supposed to do more than produce income. It was supposed to provide status, identity, proof, and a story about becoming more capable over time.

AI does not need to eliminate a job to disturb that story.

It only needs to make the proof ambiguous.

If your hard-won expertise can be imitated at the surface by someone with less experience, the insult is not only economic. It is epistemic. The world can no longer see the difference as easily.

If your manager cannot distinguish your judgement from AI-polished output, your value becomes harder to defend.

If your school cannot tell whether a student understood the assignment or generated a plausible response, assessment becomes theatre.

If your hiring process cannot distinguish a candidate who can think from a candidate who can prompt a passable application, the CV pile becomes less like a talent market and more like a noise machine.

The nervous system understands this before the policy memo does.

The old proof objects are getting weaker.

The new proof objects have not yet been built.

Output is moving down the stack

The mistake is to treat this as a content problem.

Too many AI debates still ask whether the output is good. Is the essay coherent? Is the code functional? Is the answer accurate? Is the image impressive? Is the analysis plausible? Did the model pass the benchmark?

Those questions matter, but they sit too low in the stack.

When output gets cheap, output quality becomes the opening bid, not the final proof.

The important question moves upward:

What does this output prove about the person, team, or system behind it?

Sometimes the answer is: not much.

A clean memo may prove that someone had access to a strong model and enough taste not to paste the first result. A polished deck may prove that the organisation has a presentation machine. A strong CV may prove that the candidate knows how hiring filters work. A synthetic benchmark score may prove that the model, harness, prompt, evaluator, and task distribution aligned for that run.

None of that is worthless.

But it is thinner proof than people want it to be.

The surface is becoming a commodity layer. It can still matter because surfaces are how humans encounter work. Customers need interfaces. Readers need sentences. Managers need summaries. Recruiters need packets. Teachers need submissions. Investors need decks. Teams need artefacts they can move around.

The surface is not dead.

It is demoted.

It no longer sits at the top of the proof hierarchy. It becomes the thing you inspect after asking what kind of judgement produced it and what kind of accountability stands behind it.

The proof must move upward

The next proof system will not ask only whether you produced a good artefact.

It will ask what happened before, during, and after the artefact.

Before the artefact, it will ask whether you framed the right problem. Did you name the constraint that mattered? Did you reject the easy but wrong brief? Did you understand the regime you were in? Did you decide what not to optimise?

During the artefact, it will ask how you worked with the machine. Did you use AI to explore options or to avoid thinking? Did you notice when the answer was overconfident? Did you check the parts where the model is most likely to bluff? Did you preserve the reasoning that matters, or only the final surface?

After the artefact, it will ask what survived contact with reality. Did the code run under production constraints? Did the strategy change a decision? Did the essay make a reader see differently? Did the hire perform after the interview? Did the student defend the argument without the draft in front of them? Did the model output hold up under a verifier that was not designed by the same optimism that generated it?

This is the move:

Proof shifts from artefact to trace, from answer to framing, from fluency to revision, from claim to consequence, from ownership of output to ownership of judgement.

Proof moves to what surrounds the artefact. The visible surface is the opening bid; the proof is what comes before, during, and after it.

That shift changes nearly everything.

It changes hiring. A work sample is no longer enough. The stronger signal is an audit interview where the candidate critiques an AI-generated answer, names what would break in production, and explains the tradeoff they would accept.

It changes education. An essay is no longer enough. The stronger signal is an oral defence, a revision history, a live problem-framing exercise, or a student’s ability to explain why they rejected a tempting but false argument.

It changes management. A completed task is no longer enough. The stronger signal is whether the person can tell you what they froze, what they allowed to vary, what risk they accepted, and what evidence would make them change course.

It changes content. A polished article is no longer enough. The stronger signal is whether the writer has a world, a lens, a record of judgement, and the ability to produce instruments that readers can use.

It changes self-respect. A finished thing is no longer enough to prove to yourself that you were present. The stronger signal is whether you can stand behind the choices that made it.

The five proof questions

The useful response is not to ban AI from proof.

That would be brittle. It would also miss the point. A person who can use AI well, verify its work, and carry responsibility for the result may be more valuable than someone who refuses the tool out of status anxiety.

The right response is to stop treating AI-polished output as the proof object.

When you need to know whether something is real, ask five questions.

What problem was chosen, and what easier problem was rejected?

This is the first proof of thought. Bad work often begins with accepting the first fluent frame. Good work usually contains a buried refusal. Someone saw the tempting version of the problem and did not take it.

What tradeoff was made under constraint?

Intelligence becomes visible at the boundary. Anyone can say they value quality, speed, safety, originality, and user experience. Real judgement appears when not all of them can be maximised at once.

What did the person or system check that the output itself could not prove?

This is the verification question. It separates people who use AI as a generator from people who use AI inside a judgement loop. The output can say it is correct. That is not verification. Verification is the external thing that makes the claim answerable.

What changed after feedback, failure, or contact with reality?

Revision is underrated because it is less glamorous than creation. But in an AI world, revision becomes a higher-status signal. The first surface is cheap. The changed surface after friction is where more truth appears.

Who owns the consequence if this is wrong?

Accountability is the signal machines cannot carry in the human sense. A model can produce. A person, team, school, company, or institution must decide what it is willing to stand behind.

These questions are not a philosophy exercise.

They are a working instrument.

Use them on a CV. Use them on a student essay. Use them on an AI-generated strategy. Use them on your own work before you publish, hire, fund, or deploy.

If the artefact cannot answer any of them, it may still be useful.

But it is weak proof.

The new elite signal

The people who win in this environment will not be the people who produce the most surfaces.

They will be the people whose judgement remains visible after the surface becomes easy.

That is a different game.

It rewards those who can frame problems before generating answers. It rewards those who can make verification part of the work instead of an afterthought. It rewards those who can revise under pressure without collapsing into defensiveness. It rewards those who can explain tradeoffs plainly. It rewards those who can hold an accountability line when the output is impressive but the evidence is thin.

It also punishes a lot of institutions.

Schools that keep grading the artefact as if the artefact still means what it meant in 2019 will train students into theatre. Companies that keep filtering for polished applications will drown in polished applications. Managers who reward visible productivity without inspecting judgement will build teams that look busy and become fragile. Publications that chase more output without a recognisable proof of taste will become part of the slop layer they complain about.

The world does not need fewer artefacts.

It needs better proof around artefacts.

A new category opens here. Call it proof design: building the signals that still mean something when the surface costs almost nothing to produce.

The exhausted takes all miss it. Optimism and doom argue about whether the tools are good. “Learn the tools” and “humans are still special” argue about who survives. The more useful question sits to the side of all four. What evidence of judgement holds up after the artefact becomes cheap?

That is the work now.

What to do with this

Run a one-week proof audit.

Pick three places where polished output is currently being treated as evidence of thought: a CV screen, a student submission, a strategy memo, or one of your own public posts.

For each one, ask what proof would still survive if the surface had been generated. If the answer is “not much,” do not throw the artefact away. Move the proof upward. Add the framing, the tradeoff, the verification, the revision, or the accountability line.

If you are a worker, stop trying to prove value only through polish. Keep the polish, but attach judgement to it. Show the problem you chose. Show the tradeoff. Show the verification. Show the revision. Show what you will own.

If you are hiring, stop asking only for artefacts. Ask candidates to audit artefacts. Give them a plausible AI-generated answer and ask what is wrong, what is missing, what would fail in the real environment, and what they would check before trusting it.

If you are teaching, stop treating AI use as the centre of the problem. The deeper problem is whether your assessment still proves learning. If the submission can be generated, move proof into defence, revision, transfer, and live explanation.

If you are building a company, stop confusing generated velocity with institutional learning. Your system can spin up endless plans, experiments, and dashboards. The signal that matters is what proof gets stronger each time it runs.

If you are creating in public, stop assuming people will trust you because the output is polished. Build a visible record of judgement. Make your lenses repeatable. Make your standards legible. Let readers see that something underneath the surface is doing the work.

The old proof contract is not coming back.

That does not mean thinking stops mattering.

It means thinking has to leave different evidence.

The next time you look at a polished piece of work, do not ask only whether it is good.

Ask what it proves.

Ask what it hides.

Ask what pressure it survived.

Ask who can defend it when the model is gone, the prompt is gone, the screenshot is gone, and the only thing left is the decision someone chose to stand behind.

That is where competence moves.

Not into the surface.

Into the proof beneath it.

Save the card. Run the five questions on the next polished thing that lands on your desk.

If this frame lands, the practical question is: where in your work are you still using polished output as proof of thought?

The Durability Curve is a standing argument about what lasts when the surface gets cheap. Proof design is where it goes next. Subscribe for the rest of it.

New here? Start with what survives, or take the reader tools with you.

Anurag Shekhar and Musawenkosi D. Saurombe, “Algorithmic anxiety: AI, work, and the evolving psychological contract in digital discourse,” Frontiers in Psychology, 17 February 2026. The paper reports a mixed-methods analysis of 1,454 Reddit narratives about AI-driven job displacement and identifies themes including shattered trust, eroded identities, technostress, devalued expertise, anxiety about the future, cynicism about adapting, and affirming human values. https://doi.org/10.3389/fpsyg.2026.1745164 ↩

Taste Is What You Delete

Fri, 01 May 2026 00:00:00 GMT

Generation is not judgment.

Generation got cheap. The scarce skill is knowing what to cut.

Ten versions in ten seconds

The old problem was the blank page.

The new problem is ten versions in ten seconds.

Ten headlines. Ten logos. Ten app screens. Ten strategies. Ten rewrites of the same paragraph, all fluent, all plausible, all close enough to make the next move harder.

At first this feels like power.

Then it starts to feel like fog.

You ask for more options because the current options are not quite right. The model gives you more. Some are cleaner. Some are louder. Some are safer. Some are more polished. None of them obviously solves the problem.

So you ask again.

Now you have thirty.

This is the quiet inversion AI creates in creative work.

The scarce part is no longer producing a candidate. The scarce part is deciding which candidates should die, and being able to explain why.

Taste used to look like an additive talent. The person with taste seemed to have better ideas, better words, better colours, better instincts.

That is only half true.

Taste is mostly deletion.

It is the ability to look at ten plausible things and know which nine are weakening the work.

That sounds negative until you do it. Deletion is not pessimism. It is how the shape appears.

More options can make you worse

There is a comforting story about AI creativity.

More drafts means more choice. More choice means better final work. Better final work means better taste.

Sometimes that is true.

If you are exploring a territory you barely understand, more options can open doors you would not have found alone. A model can throw strange combinations at you, break your first frame, suggest directions that feel embarrassing until one of them reveals a useful path.

That is real.

But it is the divergent phase.

The dangerous phase comes after.

At some point the work has to converge. The paragraph has to say one thing. The product has to choose one promise. The landing page has to make one person feel seen. The strategy has to commit to one bet. The image has to carry one mood.

AI helps you postpone that pain.

It lets you stay in option-space long after the real work has become selection. You can keep generating instead of deciding. You can keep polishing instead of cutting. You can keep asking for alternatives instead of admitting that the problem is not a shortage of drafts.

It is a shortage of rejection.

Taste is not a vibe

People talk about taste as if it is a private glow.

Someone has taste. Someone does not. A founder has product taste. A designer has visual taste. A writer has sentence taste. A curator has cultural taste. The word floats above the work, admired but rarely inspected.

That framing is convenient because it makes taste sound untrainable.

I think it is more useful to treat taste as a working capacity:

Taste is the trained ability to reject what almost works.

Not what obviously fails. That part is easy.

Anyone can delete the broken paragraph, the unreadable mockup, the nonsense strategy, the image with six fingers, the feature nobody asked for.

A bad option announces itself. A plausible option negotiates.

Taste starts where the thing is acceptable.

The sentence is clear, but too expected.

The design is clean, but forgettable.

The feature is useful, but off-strategy.

The argument is true, but not alive.

The idea is clever, but it does not change the reader’s next move.

This is why AI makes taste more important. It is very good at producing almost-working things.

Almost-working things are hard to kill.

The phrase did the thinking

George Orwell’s Politics and the English Language is still useful here because it treats bad prose as a failure of attention, not just style. His target was political language, but the craft mechanism is broader: stale phrases, inflated diction, passive padding, and ready-made expressions let the writer stop looking directly at what they mean.¹

That is the part that matters now.

The danger of AI prose is not only that it sounds like AI. The deeper danger is that it gives you language before you have earned the thought.

The phrase arrives finished.

“Unlocking potential.”

“Navigating complexity.”

“A robust framework.”

“At the intersection of X and Y.”

“Not just a tool, but a partner.”

None of these phrases is evil in isolation. The problem is that they are available before the writer has made a choice.

They are prefabricated thinking.

When you accept them, you inherit the shape of a thought without doing the work of locating the thought itself. You can feel the page becoming smoother while the claim becomes less yours.

This is why deletion is not cosmetic.

Deleting a phrase can reveal that there was no thought underneath it.

That is useful.

It tells you where the work is.

The empty place is not a failure. It is the honest outline of the next sentence.

Good taste is not perfect agreement

The obvious objection is that taste is subjective.

People disagree. Experts get it wrong. Styles change. What feels sharp to one reader feels cold to another. What feels beautiful in one culture can feel empty in another.

All true.

But “not perfectly objective” is not the same as “random.”

Paul Graham makes a useful argument here. If there were no such thing as good taste, then there would be no such thing as good art, and therefore no way for artists to be good at their jobs. That conclusion is absurd. People can be better or worse at painting, writing, acting, composing, designing, and judging. Taste is messy, but not imaginary.²

The practical point is simpler than the philosophy.

Taste is not perfect consensus.

Taste is better discrimination under pressure.

It is the ability to notice the difference between:

Clear and obvious.

Simple and thin.

Polished and true.

Interesting and useful.

Novel and merely weird.

Confident and overfitted.

Human and human-sounding.

That discrimination improves through exposure, practice, comparison, and refusal. You see more work. You make more work. You compare the almost-good against the actually-good. You learn which signals are real and which are social noise.

AI can increase exposure.

It cannot do the refusal for you.

The slop problem is a selection problem

AI-assisted writing often repeats the same moves because models learn from patterns that occurred often enough to become likely.

The model learns the common move.

The confident opener.

The balanced contrast.

The soft caveat.

The tidy closer.

The problem is not that every common move is wrong. Common moves become common because they often work somewhere.

The problem is that common moves are cheap.

They arrive too easily.

Slop is not a list of banned words. It is what happens when familiar language arrives faster than judgment.

A human with taste does not merely ask, “Is this sentence grammatical?” or “Does this paragraph sound professional?” That bar is too low now. The better question is:

Would I have chosen this if it had not been handed to me?

Most AI-assisted work fails there.

Not because the model is useless. Because the human has not taken responsibility for the final selection.

You can see it in writing, but the same pattern shows up everywhere.

The product team ships the feature that sounds good in a roadmap but does not sharpen the product.

The founder keeps the positioning line that flatters the company but does not make the buyer move.

The designer keeps the visual flourish that signals effort but weakens the hierarchy.

The analyst keeps the chart that is technically accurate but answers the wrong question.

The creator keeps the section that proves they did research but slows the piece down.

These are not generation failures.

They are deletion failures.

The Deletion Pass

The useful question is not “how do I make more?”

It is “what has earned the right to remain?”

Run this on any AI-assisted draft, design, memo, article, product idea, or strategy.

First, make the option set. Let the model help. Generate widely. Explore. Ask for alternatives. Get the obvious versions out of your system.

Then stop generating. This is the part people skip.

Now run the Deletion Pass.

Ask five questions.

What is this piece actually trying to do?

Which part is only here because it sounds good?

Which part could be removed without changing the outcome?

Which part feels polished but hides a weak decision?

If I had to keep only one line, feature, image, or claim, what would survive?

That last question is the taste test.

Not because everything else is worthless. Because the strongest element reveals the job of the whole thing.

If you cannot name the survivor, the work has not converged yet.

Do not just delete silently. Keep a short cut list:

I cut this because __________.

That one sentence turns deletion into learning. Over time, the cut list becomes a map of your taste: the phrases you no longer trust, the features you keep overbuilding, the kinds of cleverness that make your work worse.

The test is simple enough to draw:

AI widens the field. Taste narrows it without becoming generic.

The hard reps are the point

There is a subtle trap in using AI as a creative partner.

It can remove the reps that build taste.

The bad draft matters because you learn why it is bad.

The awkward sentence matters because you feel where the rhythm breaks.

The failed design matters because you learn what your eye was pretending not to see.

The rejected feature matters because it teaches you the product’s actual spine.

The wrong strategy matters because it exposes the hidden assumption.

If AI skips you over all of that, you may get a better first output and a weaker internal judge.

That is not a reason to avoid AI. It is a reason to use it in a way that keeps the hard reps alive.

Do not only ask the model to generate.

Ask it what should be cut.

Ask it which option is most generic.

Ask it which paragraph is pretending to be useful.

Ask it which section exists to prove effort rather than serve the reader.

Then disagree with it.

Make the final deletion yourself.

That is where the skill compounds.

The person who can delete

The next advantage in creative work will not belong to the person who can make the most drafts.

Everyone will have drafts.

It will not belong to the person with the longest prompt.

Prompts will spread.

It will not belong to the person who can produce the most polished surface.

Polish is getting cheaper.

It will belong to the person who can stand in front of abundance and remove what does not belong.

The person who can kill the clever line.

The person who can cut the feature that investors liked.

The person who can delete the slide that makes the deck feel smarter but the decision less clear.

The person who can look at twenty AI-generated options and say:

No.

This one.

And then make that one better.

In an age of infinite drafts, taste is not what you add.

Taste is what you delete.

What is one thing in your current work that probably sounds good but has not earned the right to stay?

George Orwell, Politics and the English Language, first published in Horizon (April 1946), hosted by The Orwell Foundation, https://www.orwellfoundation.com/the-orwell-foundation/orwell/essays-and-other-works/politics-and-the-english-language/. Orwell’s rules and examples are used here as a craft analogy for deletion and conscious word choice. ↩
Paul Graham, Is There Such a Thing as Good Taste? (November 2021), http://www.paulgraham.com/goodtaste.html. Graham argues that taste is neither perfect consensus nor pure randomness; the article uses that limited point, not a claim that aesthetic judgment is fully objective. ↩

Work and judgement · The Durability Curve

A Coin Flip Set the AI's Lean. Experts Went With It 86% of the Time.

Four coin flips

What they said afterwards

They saw the calls

Going first

The case for the analysts

Your own decisions

Where this comes from

Did Your AI Actually Read the Doc?

Connect both assistants to Google Drive

Make the doc

Start every chat the same way

The test

When to move it to GitHub

Two rules

What Did They Have to Check or Redo?

AI Can Take the Practice Without Taking the Job

The count

Codified and tacit

The loss the count can’t see

Counting reps

The Things You Used to Know by Heart

Known, and merely findable

The thing you could not have looked up

What stays with you

Use AI to Learn Without Getting Worse at It

Experienced programmers too

Who did the thinking

Level 1: switch on the learning mode you already have

Level 2: paste a tutor prompt

Level 3: give it your material, then test yourself cold

What the research can and cannot tell you

The checklist

You Built a Number You Will Not Trust

What “it works” does not tell you

The one people skip: what would tell you it was wrong

What it cost me to learn this

Run it on the thing you are building

What the questions do not do

The Work That Comes Due After You Leave

Why the small steps are the ones that go missing

The check has to come from somewhere you did not write

One question to carry

The part you can use

What none of this fixes

It Will Never Think Less of You

Safe, and unmet

The risk was the whole thing

What to spend on a person

Confidently Wrong

What the difficulty was doing

The difficulty that was checking your work

The difficulty that was building you

The new cost of checking

Making the call

Footnotes

You Reach Before You Think

The reach, and the relief under it

Why the reps are the thing

What to keep for yourself

You Cannot Try to Fall Asleep

Footnotes

The Difficulty You're Escaping Was Making You

The strain is the mechanism

The most tempting offer ever made

The skill you need to check the machine

Meaning tracks the difficulty you choose

Not all difficulty is sacred

What to do with this

Footnotes

The Safe Parts of Your Job Are the First to Go

The part that stays yours

The machine is already climbing two of them

Three of them grow more valuable as execution gets cheap

The catch: the durable work is concentrating

Where to start

Footnotes

Access Is Not Agency

The agent everyone calls powerful