The light turns green and you still can’t move. The car in front of you edged into the intersection on the last yellow and then stopped because cross traffic had done the same thing from the left, and that traffic stopped because someone had nosed out from the right. Four lines of cars now sit inside the box, each one parked across the exact lane it’s waiting to use. No one can pull forward until someone backs up, and no one can back up, because there’s a bumper behind every car too. Everyone is frozen, and every driver did the ordinary, sensible thing on the way in.

Computer scientists call this a deadlock, and it carries an older, grimmer name that’s more fun to say: the deadly embrace. It happens when a group of parties each hold something the next one needs while waiting for something the next one holds, around a closed loop, so that nobody can move until someone else moves first, and nobody ever does. The gridlocked intersection is the pure form. So is the moment on the phone when neither of you will hang up, each holding the line open and waiting for the other to go first.

This is the darker cousin of the race condition. A race condition hands you a wrong answer and rushes on, cheerful and broken. A deadly embrace hands you no answer at all and simply stops, with everyone still politely waiting. Nothing crashes, nothing errors out. The machine sits there in perfect health, spending no effort and finishing nothing, because every part is patiently waiting its turn and the turn is never going to come.

The phrase earns its keep because the situation is so easy to walk into and so invisible from the inside. Each party feels completely reasonable. Nobody is being greedy or careless. They’re all just holding what they have until they get what they need, which is the most natural instinct in the world, and it’s the exact instinct that bolts the door.

Five philosophers, five forks

The name comes from the same tradition that gave us the last two ideas, and its origin is oddly charming. In 1965 the Dutch computer scientist Edsger Dijkstra, working on one of the first operating systems, invented a little parable to show his students the danger. Five philosophers sit around a table. Between each pair of them lies a single fork, five forks in all, and to eat his spaghetti a philosopher needs the two forks on either side of him. Each one picks up the fork on his left, then reaches for the one on his right. If all five reach left at the same instant, every fork is now in a left hand, every right hand is grasping at air, and all five philosophers sit there holding one fork apiece, starving, each waiting on a neighbor who is also waiting. Dijkstra had a name for that frozen table: the deadly embrace.

Four locks, and one key

Six years later, in 1971, the computer scientist Edward Coffman pinned down exactly what a deadly embrace requires, and his answer is the most useful part of the whole story. Four things all have to be true at the same time. The thing being fought over has to be something only one party can hold at once, like a fork or a lane. Each party has to be holding what it already grabbed while it reaches for the next thing. No one can force anyone to let go. And the waiting has to bend into a full circle, where the first waits on the second, the second on the third, and the chain eventually loops back home.

All four are required, and that’s the gift buried inside the grim name. Knock out any single one and the deadly embrace becomes impossible to form. You don’t have to untangle the whole knot. You only have to cut one strand.

Watch it work on the philosophers. The classic fix breaks the circle: number the forks one through five, and make every philosopher pick up his lower-numbered fork first. Four of them still reach left, but the fifth, sitting where the numbers wrap around, has to reach right first, and that one change means the chain can never close on itself. Somebody always ends up with both forks, eats, and sets them down for the next. A different fix breaks the hold-and-wait link instead: a philosopher must take both forks together or neither, so no one sits clutching a lone fork while he starves. A third adds a timeout: hold a fork too long without eating and you’re required to put it back and try again.

Back at your desk

You’ve been caught in deadly embraces that had nothing to do with forks. Marketing won’t launch until Legal signs off; Legal won’t sign off until they see the final copy; Marketing won’t lock the copy until they know the launch date. Round and round it goes, each team holding its piece hostage to the piece it’s waiting on, everyone certain they’re the responsible one. Or the quieter domestic version, where neither of you will apologize until the other does, so a small argument sits fully preserved on the shelf for three days, going nowhere.

The same knot appears the instant you’re coordinating with AI instead of a spouse. You wait for the model to ask what it needs, and the model, trained to be agreeable, waits for you to tell it, so the two of you stall in a courteous hush, each expecting the other to lead. Or you keep a file open in your editor while an agent needs to write to it, and the agent’s next step depends on a result sitting in your unsaved buffer, so you’re each holding the thing the other one is waiting for. Run several agents at once and it compounds, because each is waiting on an output from another, and not one of them will volunteer to go first.

The way out never changes, whether it’s forks or teams or a marriage or a stalled agent. Someone has to let go of something they had every right to keep. The philosophers escape only when one of them agrees to reach for the far fork first or to set down the one already in his hand. The teams come unstuck only when somebody says, I’ll commit my part before I’ve seen yours. It feels like losing because you’re loosening your grip while the other side keeps theirs, and the instinct that built the embrace, hold on to what you’ve got until you’re safe, is screaming at you not to. That instinct is the lock itself. So the next time you’re waiting on someone who’s waiting on you, look for the one strand you can cut and cut it. Put down the fork you were entitled to keep. The whole circle opens the moment a single hand comes free.

Subscribe now

You text your partner: we’re out of milk, can you grab some on the way home?. No reply comes back because they’re already standing in the checkout line with a gallon in hand, having opened the same empty carton that morning. That night the refrigerator holds two gallons, and neither of you did a single thing wrong. You both noticed. You both acted. The only trouble was that you acted at the same time, each of you certain you were the only one moving.

Engineers have a name for this, borrowed from the machines they build, and once you have it you start seeing it in places that have nothing to do with milk. A race condition is what you get when the outcome of a situation depends less on what each party does than on the order and timing in which they do it, with nobody in charge of the order. Two actions, each correct on its own, collide because they reached for the same thing at the same moment. The failure lives in the gap between them. Each action, examined alone, is flawless.

Three things have to line up for a race. There has to be something shared, a fridge or a bank balance, that more than one party can change. There have to be at least two of them acting. And there has to be a gap, however small, between the moment someone checks the shared thing and the moment they act on what they saw. In that gap, the world can move. You glance at the carton, see it’s empty, and head for the store. Between your glance and your purchase, your partner’s glance and purchase have already happened. You acted on a fact that had quietly gone stale.

Most of us walk around with a silent assumption that we’re the only one touching whatever we’re looking at. Almost always it’s close enough to true, and life proceeds. The value of the phrase is that it names the exact circumstance where the assumption breaks, so you can feel the little flicker of danger before it costs you.

Born in the wiring

The term came from people who build circuits. In his 1954 doctoral thesis on sequential switching circuits, the engineer David Huffman was already using it for a specific hazard inside logic gates. Picture one electrical signal that splits and travels to a gate along two different paths, one a little longer than the other. The gate’s answer is supposed to depend only on the values of the signals, never on when they show up. But the two copies don’t arrive together, and for a few billionths of a second the gate sees a combination that should never exist and throws off a brief, wrong flicker. The signals are, quite literally, racing, and the circuit’s correctness hangs on which one wins.

When computers began doing many things at once, the same hazard climbed up out of the wires into the software, and the name climbed with it. Two programs, or two parts of one program, would both read a value, both decide what to do based on it, and both write back, and each one erased the other’s work. The textbook case is a bank account. Two withdrawals of a hundred dollars land at nearly the same instant. Each reads the balance, sees five hundred, subtracts a hundred, and writes back four hundred. Two hundred dollars left the account and the ledger recorded only one of the withdrawals. The account is now wrong, and no single line of code is to blame.

When the gap turns deadly

This stayed an abstraction you could file under engineering problems until the stakes got real. Between 1985 and 1987, a radiation-therapy machine called the Therac-25 delivered massive overdoses to cancer patients, and the software-safety researcher Nancy Leveson, who spent years reconstructing what went wrong, traced the core failure to a race condition. When an operator typed the treatment settings fast enough, two parts of the software fell out of step: a safety check ran against data that a quick edit had already changed, and the machine fired an unshielded beam hundreds of times stronger than intended. At least three people died. The individual pieces of that program mostly worked. What killed patients was the timing between them.

The same shape took down the power grid. On an August afternoon in 2003, a race condition in the alarm software running FirstEnergy’s Ohio control room, a system built by General Electric, silently stalled. Operators lost their warnings without knowing they’d lost them, a local line failure they couldn’t see cascaded outward, and by nightfall fifty-five million people across the American Northeast and parts of Canada had no electricity. The bug had probably been sitting in that code for years, harmless, waiting for two events to line up in exactly the wrong order.

The lesson underneath these disasters is an uncomfortable one because it undercuts how we usually decide whether something works. We check the parts. We make sure each function and each person does the right thing in isolation, and we conclude the whole is sound. Race conditions are the proof that this isn’t enough. You can bolt correct parts into a broken system because the correctness of the pieces tells you nothing about what happens when two of them grab the same thing at the same time. Timing is a hidden input, and most of the time we forget to test it.

Back at your desk

You don’t run a power grid, but you live inside small races all day. Two people on a team reply to the same customer, each assuming the other hadn’t gotten to it. A colleague and you both edit the same shared doc in the same five minutes, and one save quietly swallows the other’s paragraph. Worst is the inverse race, where a task falls through the floor because each of you checked, figured the other might be on it, and stepped back. “I thought you had it.” “I thought you did.” Nobody acted, for the very same reason that, with the milk, both of you did.

It gets sharper the moment you start working with AI because now you’re spinning up actors faster than you can keep track of them. You open two chats and point both at the same file. You set an agent running in the background while you keep working in the foreground, and both reach for the same document. You drop a half-finished draft into a model, get pulled away, and later paste it into a fresh session, and now two versions of the same piece are drifting apart in two tabs. Each session is doing exactly what you told it. The collision comes from the fact that you lost count of how many were running. This is the concurrent twin of the problem that makes idempotency matter: there, one actor sends the same instruction twice; here, two actors send correct instructions at once.

The engineers who tamed this didn’t do it by making each actor smarter. They did it by controlling the one thing that actually causes the damage: access to the shared object. Sometimes that means a lock, a way of saying “I’m working on this, everyone else wait,” so the actions line up in a queue instead of a pileup. Sometimes it means naming a single owner, so there’s only ever one hand on the thing at a time. The human version costs nothing and works the same way. Before you act on something more than one person can touch, say out loud who’s got it. “I’ll take the customer reply.” “I’m grabbing milk on the way home.” “I’ve got the doc for the next hour.” A sentence like that turns a race into a line, and the double gallon and the erased paragraph stop happening. You were never going to control the timing. What you can settle, in advance, is who goes first.

Subscribe now

Press the button for the elevator and it lights up. Press it again, harder, four more times because you’re late. The elevator arrives exactly once, exactly when it would have anyway. Your extra jabs changed nothing, and that’s the whole point. The button was built so that hitting it once and hitting it ten times mean the same thing.

There’s a word for this, and it’s one of my favorites in the English language. Idempotent. An action is idempotent when doing it repeatedly has the same effect as doing it a single time. Setting a light switch to “on” is idempotent; it’s already on, and flipping it toward “on” again does nothing. Adding salt to soup is not; the tenth pinch ruins dinner. Most of the machinery that keeps modern life from collapsing into chaos runs on the first kind of action, and almost nobody outside a few technical trades knows the word for it.

I want to make the case that you should. Not because you’ll use it at parties, but because the idea underneath it is one of those rare mental tools that reorganizes how you see ordinary things. Once you have it, you start noticing which of your own habits, requests, and systems are safe to repeat and which ones quietly punish you for repeating them.

A word born in algebra

The word comes from a strange and specific place. In 1870 an American mathematician named Benjamin Peirce circulated a dense little book called Linear Associative Algebra. Peirce was Harvard’s leading mathematician, a founder of the field in America, and the father of the logician Charles Sanders Peirce. In that book he needed names for two kinds of mathematical objects that behaved oddly when multiplied by themselves. One kind, multiplied by itself, collapsed to nothing; he called it nilpotent, from the Latin for “zero power.” The other kind, multiplied by itself, gave back exactly itself; he called it idempotent, from idem and potens, roughly “the same power.”

That second name described a number, or an operation, where doing it again lands you right back where you already were. In the plainest arithmetic you know it too. One times one is one. Zero times zero is zero. Square those and nothing moves. Peirce was after something more abstract, but the flavor is identical: apply the thing to itself and it holds still.

For about a century the word stayed home in mathematics, useful mostly to people who studied logic and abstract algebra. It turns up in Boolean logic, the algebra of true and false that George Boole built in the 1850s and that every computer now runs on. In Boole’s system, “true AND true” is just “true.” “True OR true” is just “true.” Stack the same truth on itself and it doesn’t compound; it repeats. Idempotent, again, though Boole didn’t have Peirce’s word for it yet.

None of this sounds like it should matter to anyone with a to-do list and a job. And for a hundred years, it didn’t much. Then we built a world out of unreliable messages, and the word came roaring back.

The unreliable world made it essential

Here’s the problem that resurrected it. When your phone sends a request across the internet, say, to pay for something, the message can get lost on the way there, or the reply can get lost on the way back. Your phone can’t tell those two failures apart. From where you’re sitting, “the payment didn’t go through” and “the payment went through but the confirmation vanished” look exactly the same: a spinner, then nothing.

So you do what any of us do. You tap “Pay” again.

If the payment system treats each tap as a fresh command, you just paid twice. Multiply that across millions of anxious taps a day and you have a catastrophe. The fix is to make the payment idempotent. The company Stripe, which processes payments for a large slice of the internet, built exactly this and named it after the idea: an idempotency key. Your phone stamps the payment with a unique ticket number. The first time Stripe sees that ticket, it charges you. Every later time it sees the same ticket, it shrugs, says “already handled,” and returns the original result. You can tap “Pay” until your thumb is sore. You get charged once.

That single design choice is why online commerce works at all, and it’s a direct descendant of Peirce’s algebra word. The engineers who built the web baked the same idea into its grammar. When your browser fetches a page or updates a saved setting, those actions are meant to be idempotent: ask for the same page twice, get the same page, no harm done. Submitting a new comment or placing a new order is deliberately not idempotent, which is why your bank warns you not to hit refresh on the confirmation screen. The whole system is sorted, quietly, into actions that are safe to repeat and actions that aren’t.

The deep reason this matters is almost philosophical. In a world of unreliable messengers, you can never be fully certain your instruction arrived. Certainty isn’t on the menu. So instead of chasing it, good engineers design for the opposite: they make repetition harmless. If you can’t know whether the thing happened, build it so that doing it again costs nothing. That’s not a workaround. It’s a wiser stance toward an uncertain world than insisting on perfect knowledge you’re never going to get.

Why you’d want this word

Now bring it back to your desk. You send a colleague a message: “Can you add me to the budget meeting?” You hear nothing. Two days later you send it again. If they’d already done it, you’ve just created a small mess: two calendar invites, a confused exchange, a “wait, didn’t I already?” Your request wasn’t idempotent, and the cost of your reasonable follow-up was friction.

Compare that with how you’d phrase it if you thought like Stripe. “Please make sure I’m on the invite list for the budget meeting.” Now the ask describes an end-state, not an action to perform. Whether they do it once, or you nudge them three times, the target is the same: you, on the list, once. Send that message a dozen times and the world it’s asking for never changes. You’ve made your own request safe to repeat.

This is the move, and it generalizes. Increments are dangerous to repeat; declarations of a desired end-state are safe. “Add a paragraph about pricing” run twice gives you two paragraphs. “The pricing section should cover our three tiers” run twice gives you one correct section. The first tells someone to do something. The second tells them what should be true. Only one of those is safe when you’re not sure if it landed the first time.

Which is precisely where working with AI gets interesting, because you’re now sending instructions into exactly the kind of uncertain channel that made this word necessary in the first place. A model doesn’t remember your last session. A long chat drifts. You re-run prompts constantly: the wifi hiccups, the answer disappoints, you tweak one word and go again. If your prompt is written as an increment (“add three more examples”), running it four times buries you in examples. If it’s written as an end-state (“the piece should include four short examples, one per section”), you can re-run it all afternoon and keep landing in the same clean place. You’ve made your instruction idempotent, and the model’s forgetfulness stops being your problem.

That reframe is worth more than the vocabulary word. Most of us design our commitments and our asks as one-shot actions and then suffer when reality forces a retry, which it always does. The people who build systems that don’t break learned long ago to ask a different question. Not “how do I make sure this happens exactly once?” but “how do I make it safe for this to happen again?”

Subscribe now

The taste you think of as your own, for hot salty wings and a cold beer on a Sunday afternoon, was manufactured upstream of you: in a slaughterhouse and a cable-television control room, years before you ordered your first dozen. We tell ourselves we eat what we love. Mostly we love what the system had too much of.

Start with the story everyone knows, because it’s a good one.

On the night of March 4, 1964, Teressa Bellissimo was running the kitchen at the Anchor Bar, a neighborhood joint on Main Street in Buffalo, New York. Her son Dominic was tending bar, and a group of his friends turned up hungry after the kitchen had all but closed. What Teressa had on hand was a crate of chicken wings. In 1964, a chicken wing was not bar food. It was a soup bone, the scrap you tossed in a stockpot with the necks and backs and simmered for hours into broth. She dropped the wings in the deep fryer until the skin blistered, tossed them in melted margarine and Frank’s RedHot, and sent them out with celery from the salad station and a bowl of blue cheese. The boys inhaled the plate and asked for more.

For sixty years that’s the story we’ve repeated, and it flatters us. It’s a story about one clever person having one brilliant idea on a slow night, individual genius turning garbage into gold. It fits the shape we like our history to take: the lone inventor, the eureka moment, the recipe that conquered the world because it was simply that good.

There’s a problem. The story keeps having other authors.

Ask around Buffalo and the origin splinters. The Bellissimos themselves gave more than one version; in one telling the wings showed up mistakenly, a delivery of wings instead of the necks and backs Frank had ordered, and Teressa fried them so they wouldn’t go to waste. A few blocks away, a Black restaurateur named John Young had been selling wings before the Anchor Bar was, breaded and drenched in a sauce he called mambo, moving 5,000 pounds a week by his own account in 1962. The writer Calvin Trillin chased down both claims for a 1980 New Yorker piece and came away unable to crown a single inventor. Buffalo was full of people cooking wings at the same moment, and the city has spent the decades since arguing about which of them counts.

That’s the tell. When a dozen people invent the same thing within a few years of each other, the thing wasn’t waiting on a genius. It was waiting on a condition, and the condition arrived in the early 1960s whether Teressa Bellissimo showed up for work or not.

The cheapest meat in America

To see the condition, leave the kitchen and look at the whole bird.

Through the 1950s and into the 1960s, the way Americans bought chicken changed. We stopped bringing home whole birds and started buying parts, and the part we wanted was the breast: lean, boneless, mild, the meat that fit the decade’s idea of modern eating. Every breast sold to a suburban family created a problem two feet down the assembly line. A chicken carries two wings and one breast, and nobody was asking for the wings. By the early 1960s, processors were sitting on a mounting surplus of a product with almost no market. Wings went for pennies a pound when they sold at all. In the plainest accounting sense, they were waste.

When a system produces a high-volume byproduct that the market prices at near zero, it leaves a standing bounty for anyone who can find a use for it. The value isn’t in the recipe. It lives in the gap between what the input costs (nothing) and what a hungry person will pay once it’s hot and salted (quite a lot). Teressa Bellissimo didn’t get rich because her sauce was magic. She got rich because she happened to be standing in a pocket of economic history where her main ingredient was free and her competitors hadn’t noticed yet. Every wing joint in Buffalo was harvesting the same arbitrage without naming it, which is naturally why so many of them surfaced at once.

Era What America bought The wing’s status What a wing was worth 1960s whole birds, then breasts stockpot scrap pennies a pound 1980s nuggets, strips, drive-through bar snack that sold beer a cheap draw 2020s wings as their own category seasonal delicacy priced into shortage

A food that sells beer

Cheap input is only half the machine. Cheap food gets invented and forgotten all the time. Something has to pull it into a habit, and for the wing that something showed up about fifteen years after Teressa’s fryer.

On September 7, 1979, a new cable channel called ESPN went on the air to roughly 1.4 million subscribers. Its largest early advertiser was Anheuser-Busch, which signed the biggest cable-ad deal to that point in the medium’s history. Read that pairing again: an all-day sports channel, bankrolled by a brewer. Within a few years, cable sports had done something to American leisure that nobody had drawn up. It gave people a reason to sit in a bar for three and four hours on a Sunday, watching games that used to be over in the time it took to drink two beers. The modern sports bar is a child of that programming, and a bar that keeps you in a seat for four hours has exactly one job: keep you ordering.

The wing turned out to be a precision instrument for that job. Look at what it asks of you. You eat it with your hands, one at a time, slowly, across a whole game. It comes off a shared platter, so it pulls a table together. And it’s built out of salt, cayenne, and grease, which is to say it’s built to make you thirsty. A plate of wings is a pump for beer sales, and the bar’s margin was never in the chicken; it was in the pint. The whole little ecosystem, the free scrap and the four-hour game and the tap within reach, quietly pointed in one direction.

None of it was a plot. Nobody at the brewery or the network or the Anchor Bar sat down to engineer your Sunday. The wing simply fit every slot the environment had opened: free to make, easy to eat with your eyes on a screen, and chemically tuned to sell the high-margin drink beside it.

The scrap becomes the prize

Run the tape forward and the strangest thing happens. The garbage turns into the most expensive meat on the bird.

Buffalo Wild Wings opened in 1982, a national chain built entirely on the part Teressa used to throw out; Wingstop and a dozen imitators followed. Demand ran so far past the two-wings-per-bird ceiling that wings now climb in price every winter and tip into genuine shortage around the Super Bowl. By the National Chicken Council’s count, Americans ate about 1.47 billion wings over the 2025 Super Bowl weekend alone. The byproduct is now the product.

Then the chains pulled a move that’s almost too neat. When wing prices climbed too high, they needed a cheaper stand-in, so they invented the “boneless wing”: a lump of breast meat, breaded and fried and sauced to taste like the real thing. Buffalo Wild Wings rolled them out in 2003. A customer in Ohio got annoyed enough at the name to sue in 2023, on the reasonable ground that a boneless wing is neither boneless nor a wing.

Sit with the loop for a second. The breast was the desirable cut whose popularity created the wing surplus in the first place. The wing, once revalued, got so expensive that we now grind up the breast, shape it into a nugget, and sell it back to ourselves under the wing’s name. The scrap became the prize, and the prize learned to impersonate the scrap. That’s what a fully matured food economy looks like: the meat we threw away teaching the meat we prized how to dress up as it.

What you can actually do with this

We look back at 1964, and we praise the chef, because a chef is a person and a person is easy to love. It’s harder to fall for a poultry surplus or an ad contract. But the honest account of the buffalo wing has almost nothing to do with Teressa Bellissimo’s talent and almost everything to do with two forces she never saw: a mountain of near-free wings looking for a use and a new way of drinking in front of a screen that needed a food to sell. She was standing where those two rivers met. So was John Young. So was everyone in Buffalo who owned a fryer.

It doesn’t stop at chicken. A large share of what you consider your taste is the residue of what some system had too much of and needed to move. Lobster was prison food in colonial New England, so common that servants wrote clauses into their contracts capping how often they could be fed it, until rail and refrigeration turned it into a luxury. Oysters were what the poor ate when they couldn’t afford beef. Both got narrated into desire only after supply and story caught up with each other.

One thing to try this week

Pick an industry you know something about, ideally your own, and ask one question: what does it throw away? Not what it sells. What it discards, flares off, writes down, or treats as an unavoidable cost of making the thing it actually means to sell. Every mature system generates a high-volume byproduct and prices it at near zero because it hasn’t yet imagined a buyer. That gap is the discarded arbitrage, and an outsized share of new businesses and whole product categories are quietly hiding inside it.

Write down three of those byproducts before the week is out. The data exhaust from a process nobody reviews. The offcuts of a manufacturing run. The two hours of expertise you give away free on every sales call. You’re not hunting for the next brilliant recipe; you’re hunting for the next crate of wings in the cooler, the worthless thing sitting in plain sight, waiting for the context that will make it precious. For each one, write a single sentence naming the context that would revalue it. That sentence is the whole game. The chef gets remembered; the person who spots the surplus early is the one who eats.

AI doesn’t hide the quality of your thinking. It exposes it.

That is the strange thing about these tools: they rarely fail in isolation. They fail by completing the pattern you gave them. If your premise is muddy, if your prompt is vague, if you haven’t decided what good would look like, the model gives you a polished version of that confusion. It doesn’t argue with the mess. It formats it.

That’s why AI is an honesty machine. It tells you, faster than any colleague would, whether you came to the work with a point of view. A clear thinker gets more reach, more speed, more chances to test an idea against resistance. A sloppy thinker gets pages of fluent nothing and a false sense of motion. The tool doesn’t make you sharper. It shows you how sharp you already are.

What survives automation

That’s an uncomfortable thing to hear, because it reaches past your workflow and into your sense of who you are at work. Many of us have quietly fused our worth to a task: the elegant spreadsheet, the analysis assembled from a dozen systems by Friday. When the task you built your confidence on starts getting automated, the threat feels existential, even while the paycheck is still there. The way through is to be precise about what’s actually being automated, and what isn’t.

What isn’t is judgment. An AI is a prediction engine. It surveys everything it has absorbed from the past and predicts the most reasonable average next step. More computing power doesn’t change the nature of the thing; it can recombine what already exists and, given a direction, optimize toward it, but the direction has to come from a person. And it can’t decide on your behalf. Ask it what to do about a hard call and you’ll get a clean list of pros and cons. What you won’t get is a machine that knows what’s right for you, in your situation, given what you actually value. That part is still yours.

Atrophy feels like progress

Which would be reassuring, except that judgment is exactly the thing we’re quietly handing over. The erosion is self-inflicted, and it feels like progress the whole way down. Hand a document to a model for a summary and you’ve outsourced more than typing. You’ve outsourced your read of what matters in it, your sense of which three sentences change the decision, your private argument with the author. The summary comes back clean and plausible, you nod, and you move on having never formed your own view. Do that fifty times a quarter and something goes slack. Judgment works like a muscle. The reps you skip are gone.

Pick a fight with the machine

The people who stay sharp use the same tool the opposite way. They make it argue. Instead of “summarize this,” they write their own read first, then tell the model to attack it: find every hole, surface the data that kills the idea, make the strongest case for the option I dismissed. Picture a pricing decision. The lazy version asks the AI what to charge and ships the number it returns. The sharp version writes down a price and the reasoning behind it, then says: here’s my logic, now tear it apart, tell me what a competitor would do to undercut this, show me the customer segment I’m quietly ignoring. The thinking still happens in the human. The machine becomes a sparring partner that never tires and never flatters you. That’s slower than asking for the answer, and the friction is the entire point, because the friction is where the judgment gets built. A person working this way can reach the quality of a small team, having manufactured the disagreement a good team would have supplied.

When good enough costs nothing

It matters more than it used to, because the cheap stuff is now everywhere. AI is flooding the world with competent, average output: a thousand passable posts, decks, and films, all fine, all forgettable. When the average is free and instant, the premium moves to the two things the machine can’t manufacture. A genuinely original idea is one. The judgment to know which idea is worth backing is the other. Both live in the person, not the tool, and both get rarer every time someone lets the model think for them.

Give it something good to report

The conditions aren’t going to calm down. The tools will keep getting better at the work you used to be paid for, and they’ll keep offering to do your thinking too, convincingly, for free. The advantage goes to the people who take that offer for the drudgery and decline it for the judgment, who use the most revealing instrument ever built to sharpen their own read instead of retire it. The machine will tell on you either way. Worth making sure it has something good to report.

If this gives you something to think about, consider subscribing to Intellectual Capital — a newsletter for people who want to think more clearly, create more freely, and stay curious.

Your fear is almost never coming from the thing you think it’s coming from. A bad email lands, your stomach drops, and the explanation writes itself: the email is the problem, so of course you feel sick. That explanation is incomplete. Something moved first, a half-second before the feeling, and most people go their whole lives without once catching it in the act.

The rain test

Say it’s a clear afternoon and someone walks up and tells you, with total conviction, that it’s pouring outside. You don’t get anxious. You get mildly curious, maybe a little amused, because the claim doesn’t match what you can plainly see. Now put the same words under a black sky you haven’t looked at yet. Different body entirely. The information never changed. What changed was the meaning you assigned to it before you’d finished hearing it.

That gap, between the input and the meaning, is where almost everything lives. Your anxiety isn’t manufactured by events. It’s manufactured by whatever assigns those events their meaning, and that machinery runs in the dark.

Name the program that’s running

Borrow a word for it: a program. It runs underneath conscious thought, faster than you can deliberate, and when something threatening shows up it supplies the interpretation before you’ve had a vote. The program is what murmurs that you won’t figure this one out, that the people who would are smarter than you, that losing the job would erase the person you’ve spent years being. You don’t hear this as a murmur. You hear it as a sober read of your actual situation. That’s the whole trap. The program hands you its interpretation dressed as fact, and a fact is not something you think to argue with.

So the first move, when the dread shows up before a meeting or three minutes after a Slack message, is to stop treating the feeling as a verdict and start treating it as output. Something produced this. Ask what it’s actually saying underneath. The answer is usually old, weirdly specific, and a little embarrassing once it’s in the open. If this goes badly I’m done. Eventually they’ll figure out I don’t belong in the room. Write it down in those plain words. A surprising amount of a program’s authority comes from having never been looked at directly, and it loses some the moment you can see it sitting there as a program instead of as the truth.

You can’t think your way out

Here is the part that decides where your effort should go. You cannot reason your way out of one of these, and most people waste years trying. We assume understanding the problem better will dissolve the fear, that clearer thinking produces calmer behavior. The sequence runs backward. You act differently first, and the acting rewrites the thinking.

A program is a worn groove, a neural pathway your mind drops into without being asked. You don’t sand a groove out. You cut a deeper one next to it and use it until the traffic reroutes. The groove that says losing my job means I won’t be okay gets crowded out by one that says I’m someone who lands on his feet every time so far. You build the new one through repetition, and then reality starts helping: every time you do in fact land on your feet, the new groove gets a little deeper. Researchers who study this put the average somewhere around two months of steady practice before the new path becomes the default. After that the same threatening email routes down the new groove and comes out the other side as that can’t be right, I’ve handled worse. The alarm never fires because the thing that would have fired it got rerouted upstream.

You’ll know by how you act under pressure

You don’t measure progress by how serene you feel on a quiet Tuesday. You measure it in the moment that actually counts, when the stakes are real and there’s no time to manage yourself. Under pressure the brain grabs whichever groove is most worn, and that grab is where you find out who you actually are right now. Slip back into the old reaction and the new groove just isn’t dominant yet. That’s not failure. That’s the readout. Keep cutting.

This is also why it isn’t positive thinking, and why repeating affirmations at the mirror does so little. You’re not coaching the conscious mind. You’re changing the thing that decides how you feel before the conscious mind is even invited.

Thirty seconds, one question

There’s a smaller version you can run right now. Grab paper, give yourself thirty seconds, and answer one question: who am I? Watch how long the pen hovers, how specific you can actually get, and whether what you wrote matches the person you’d want to be. Most people produce something generic. A dad. A title. Whatever project is currently on fire. The vagueness is the diagnosis. With no firm sense of who you are, you second-guess, you poll other people about decisions that are yours, your stomach knots before ordinary meetings, because the mind is steering with no fixed point to steer toward.

The surrounding noise isn’t going to quiet down. That’s the argument for cutting these grooves now, while it’s merely hard instead of urgent. You can keep drifting on whatever meaning the old programs assign, or you can pick up the pen. Thirty seconds. Who am I, and did I actually choose it?

Subscribe now

Modern work happens in an environment built for interruption. Notifications surface all day, priorities shift before the first coffee is finished, meetings multiply, and every device competes for your attention. Staying focused under those conditions can feel like swimming against a tide while someone keeps throwing beach balls at your head. The reassuring part is that the difficulty is mostly situational rather than personal, and a set of tested, practical habits can pull focus back. None of what follows is theory dressed up as advice; it’s a working toolbox, assembled over a decade of software work and years of trial and error, that you can borrow from as heavily or as lightly as suits you.

Why attention has become so scarce

Before reaching for tools, it helps to understand why attention has become so scarce. Compared with thirty or forty years ago, the world has grown vastly more complicated, and it has done so at a speed our biology never anticipated. Life before the smartphone was simpler: walking the dog meant walking the dog, not also being reachable by everyone at once. We now absorb information at a volume and pace never seen before, and even ordinary decisions have multiplied, with twenty or thirty kinds of cereal on a shelf that once held three. There’s nothing wrong with us. The human brain is roughly a fifty-thousand-year-old piece of equipment, and it simply hasn’t kept pace with the environment it now has to operate in.

How focus works in the brain

That mismatch shows up most clearly in how focus actually works. We tend to imagine attention as a switch we can flip on demand, but it behaves more like a balance among competing systems in the brain. Four of them do most of the work. The prefrontal cortex acts as the chief executive: it handles planning, decision-making, and impulse control. The anterior cingulate cortex serves as a traffic controller, helping you move between tasks and judge which ones are worth switching for. The striatum is the reward center, dispensing dopamine — a chemical messenger tied to motivation and pleasure — each time you tick something off a list or ship a piece of code. The amygdala is the alarm system, and it’s the one to watch, because under moderate but prolonged stress it floods the brain with cortisol, a stress hormone that, given enough time, lets the amygdala seize control away from the prefrontal cortex. As that happens, your capacity for planning, judgment, and self-control steadily erodes.

The cost of every interruption

The practical cost of this design becomes obvious the moment you’re interrupted. Your best work happens in a state of deep focus, and the trouble with the current environment is how little uninterrupted time it allows. Picture working on a detailed report. A tap on the shoulder or a single email notification is enough to scatter that fragile mental model, and rebuilding it afterward is largely from-scratch work. Everything the prefrontal cortex does is expensive in literal terms (oxygen, glucose) which is why it tires quickly and why a day of constant switching can leave the brain with nothing left to give. The sensation of being context-switched to death is not a metaphor so much as a description of depleted fuel.

How AI intensifies the problem

Artificial intelligence, for all it promises, tends to intensify this rather than relieve it. The pitch is more output in less time, but the output still has to be read, validated, and often re-prompted, and reviewing work you didn’t write yourself is itself cognitively demanding. There’s also a tempting failure mode in which you set one agent — an AI system working semi-autonomously on a task — running on one problem, then a second on another, then a third, multiplying context switches far beyond anything a single human workflow would generate. Layer rising expectations on top, where everyone is now meant to deliver more, faster, at the same quality, and you arrive at AI burnout, which has become a real and named phenomenon. Since rolling back decades of progress isn’t an option, the only durable answer is to find ways of working that keep human beings from burning out while still getting things done.

Manage your time

The most basic of those ways is deliberate time management. Blocking focus time on a calendar so it’s formally scheduled is a sturdy starting point; ninety minutes three times a week works well as a default, and you can stretch or shrink it to fit your own rhythm. Code reviews deserve their own protected slots, because they’ve become a genuine bottleneck: a colleague’s task can stall for two days while their review sits in your queue, and batching reviews twice a day — first thing in the morning when mental energy is highest, and again after lunch — keeps that work moving without forcing anyone to review code for hours on end. The companion technique is what you might call ramping in and ramping out: rather than slamming from deep focus straight into a meeting, you give the brain five or ten minutes to make the switch gently, leaving yourself a breadcrumb or even a deliberately broken line of code so that when you return, you instantly recall where you were. The same easing applies at the start and end of the day, around lunch, and between tasks, and after enough practice it becomes instinct, formally blocked on the calendar only when the day is unusually crowded.

Manage your energy

Managing time is one lever; managing energy is the other, and for that the traffic-light method earns its place. The aim is to recharge before you’ve run yourself completely dry. For a week or two you write down each task as you do it and sort it into one of three buckets — draining (red), neutral (yellow), and energizing (green) — then look at the pattern. Some days will tilt heavily red, which is simply life, but if half your time consistently lands in the red, that’s a signal to act: hand a task off, find a less draining way to approach it, or deliberately thread small green tasks between the red ones so your battery recharges steadily instead of bottoming out. Tracking your personal time the same way gives you a second source of balance, so that a stretch of unavoidable red at work can be offset by green at home. The goal isn’t to hit precise percentages every day; it’s to keep the overall balance from collapsing.

Clear your space and your screen

Your physical surroundings feed into the same energy budget. Visual clutter in your workspace quietly taxes the brain whether or not you notice it, and so does a desk that faces a corridor where people stream past all day. The fix isn’t to become spotless overnight but to remove what you can from your direct line of sight — into a drawer, off to the side, anywhere out of immediate view. For anyone working from home, the couch is a particular trap; carving out even a small dedicated zone, a rug with a desk and a chair and nothing else, trains the brain to associate that spot with work and the rest of the home with rest. It sounds almost too simple to matter, yet stepping into a defined work space and out of it again does a surprising amount to mark the boundary between focus and free time.

The same principle of reducing clutter applies to the screen, where open browser tabs tend to breed. By the end of a day it’s easy to have several windows crammed with tabs you can no longer even read, so that finding anything costs five minutes and sometimes you forget what you were looking for in the first place. Two rules tame this: if you don’t need a tab right now, close it; if you do, drop it into a tab group — a labeled cluster of related tabs, also called tab stacks or tab islands depending on the browser. Grouping tabs by task makes moving between tasks far easier, and in browsers like Chrome the groups persist after you shut the laptop down, so if a production outage forces you to drop everything and help elsewhere, you can later return to exactly where you left off.

Get started on hard tasks

Even with the environment in order, some tasks resist starting simply because they loom too large, like a mountain you’d rather not begin to climb. One well-worn answer is to eat the frog: identify the hardest, most unpleasant task of the day and do it first, while your mental bandwidth is at its peak. Because we reliably underestimate how long things take — the one-hour frog is usually ninety minutes — front-loading it also leaves room for everything else. When the frog turns out to be a month-long refactor rather than a morning’s work, the real first task is to turn one big frog into several smaller ones, breaking it down until a piece of it is startable. On days when even that fails, the snowball method helps: knocking out a few small, easy items earns each its little hit of dopamine, and since dopamine builds motivation, that momentum can carry you into the larger task you’d been avoiding. And when starting is the entire battle, a timer is remarkably effective; you tell yourself you only have to work for five minutes, which is easy to agree to, and more often than not you simply keep going once you’ve begun. Preparing the slides behind this very material started as a two-hour timer on a free Sunday and turned into five hours of unbroken flow, which is exactly the point: the obstacle was beginning, not doing.

Work with procrastination, not against it

Procrastination deserves a closer look, because we usually misdiagnose it. We treat it as laziness or weak willpower and tell ourselves to grow a spine, but it has little to do with willpower. What’s really happening is that the brain is trying to protect you from an unpleasant feeling — boredom, anxiety, fear of failure — by steering you toward something more comfortable. It means well; it just isn’t helpful. The first counter-strategy is to make the escape route as hard to take as possible: if you procrastinate by color-sorting Lego, move the Lego out of the office; if the phone is the culprit, keep it somewhere you have to physically get up to reach. When the distraction was news sites, developer blogs, and social feeds, willpower did nothing, so the answer was a website blocker — Cold Turkey, a tool that’s simple to install and deliberately hard to bypass — which after a few years had quietly retired the habit it was built to stop.

When you can’t simply remove the temptation, the second strategy is to make the task you’re avoiding more pleasant: put on music you love, make a favorite drink, turn the work into a small game. Most important, celebrate whatever progress you make, even if it’s nothing more than opening the codebase in your editor, because that’s still further along than you were a moment ago. The third strategy works on the level of thought itself. We tend to attach negative labels to tasks we dislike, and phrasing a task negatively actually raises cortisol, which weakens impulse control; repeated often enough, that aversion hardens into a habit, and habits fire before the prefrontal cortex can intervene. The remedy is to catch the moment and reframe it — telling yourself that reviewing an AI-written pull request will sharpen your reviewing skills, for instance. It feels absurd at first, but the brain is adaptable, and consistently thinking better of a task will gradually rewrite the habit, until those tasks stop registering as threats and become far easier to begin.

Survive meetings

Meetings are their own particular ordeal, because they demand sitting still for long stretches while somehow absorbing what’s said, and most of us leave them more drained than when we arrived. The strategies that help aren’t about becoming a star participant; they’re about getting out the other side less exhausted. Start by stripping away distractions: if you don’t need your phone or laptop in the room, leave them out, at least where you have the choice. Then work to keep your brain in an active rather than passive listening state, because passive attention tends to drift after five or ten minutes into daydreams about pancakes and grocery lists. Asking a few genuine questions — three or four across an hour, not a barrage — forces you to process what you’re hearing, and taking notes by hand, especially rephrasing the content in your own words rather than copying the slides, triggers the same effect. For listen-only meetings where questions aren’t possible, a little gamification does the trick: a long-running contest with colleagues over who could collect the most stars each time someone said the word “agile,” with a candy bar as the prize, sounds ridiculous but genuinely keeps you listening. Keeping your hands busy in any small way, a fidget toy or a squishy ball or even quiet knitting on a video call where no one can tell, helps you take in what’s being said.

Stop storing everything in your head

Once focus, energy, and meetings are reasonably under control, the next move is to stop using working memory as a storage device for everything you have to do. Working memory is precious, and it should be reserved for the thinking you actually want to spend it on. The simplest way to offload is a to-do list, which sounds trivial but is genuinely powerful; the specific tool barely matters — ClickUp and Todoist both work well, and a free tier or a sheet of paper is plenty — so long as the things you need to do live somewhere outside your head, where you won’t forget them and your brain can stop spending energy tracking them. The companion tool is a prioritization matrix, useful because deciding what matters most gets hard under stress, especially in cultures where everything is urgent and asking someone to prioritize just gets you “all of it.” The Eisenhower matrix, which sorts tasks by urgency against importance, cuts through this on a whiteboard at home or a scrap of paper at work, forcing you to weigh tasks against one another and exposing the things that feel urgent but aren’t. Naming your real priorities frees the brain from running its anxious background process of trying to keep track of them all.

Tame the smartphone

That leaves the hardest case of all, the smartphone, which has a fair claim to being a weapon of mass distraction. Three forces make it so difficult to put down. The first is what you might call the magical maybe: because notifications arrive on no fixed schedule, the phone behaves like a slot machine, and after a while it’s the anticipation of a notification, not the notification itself, that releases dopamine, leaving the brain running a constant background check on whether something’s happening. Studies bear this out — put a group’s phones in a box across the room, and people keep spending mental energy monitoring for alerts simply because the devices are present. The second force is the cost of the switch itself: every time an alert pulls you over to reply, your brain performs another expensive task switch, and doing this all day drains resources you’d rather spend elsewhere. The third is habit, captured in the saying that neurons which fire together wire together; once your brain links picking up the phone to a feeling like boredom, the action runs automatically, before the prefrontal cortex can object, so you find yourself holding the phone again having resolved minutes earlier to use it less.

The countermeasures escalate in proportion to how much trouble you’re in. The obvious first step, which helps far more than it seems it should, is to turn off nearly all notifications — banners, vibrations, sounds — leaving only the genuinely important ones, like calls from your mother. Most things can wait an hour or two without the world ending, and once the alerts go quiet, the brain’s constant background check begins to ease and the pull weakens. Beyond that lies deliberate screen-free time, enforced rather than willed: a drawer isn’t enough, since the brain will retrieve the phone before you’ve registered the decision, so the stronger move is a lockable box that holds the phone, the laptop, the game controllers, the TV remote, and anything else used for distraction, sealed away for an hour. The first week of this can be genuinely awful, a near crawling-out-of-your-skin discomfort that leaves you wandering the apartment unable to settle, even drifting into the room where the locked box sits without knowing why. It eases after that first week, and after about six months the box becomes unnecessary, the phone manageable in a mere drawer, with the full lockdown reserved for moments when the device starts to feel like it’s running you.

Keeping the phone physically distant matters as much as locking it away. Moving it out of the bedroom, or at least off the bedside table and into a holder by the door where it can still charge and serve as an alarm, removes it from arm’s reach; the result was trading thirty to sixty minutes of nightly aimless googling for half an hour of reading, and a marked improvement in sleep quality that feeds straight back into focus. The same out-of-reach principle works at the desk during the day. And because most of us still need the phone for real tasks, a friction app earns its keep — one that either blocks specific apps or inserts enough resistance that an automatic habit becomes a conscious choice. One Sec is a strong example: opening a chosen app first triggers a “take a deep breath” pause of about eight seconds, then asks whether you really want to open it, and if you do, makes you commit to a time limit, capped at fifteen minutes, after which it stops you and asks again. Chrome usage that had quietly reached three hours a day, a genuinely shocking number for someone who assumed they were disciplined, fell to roughly forty-five minutes through friction alone, freeing more than two hours daily and restoring a real sense of control.

Expect to fail, and keep living

Whatever you take from all this, expect to fail at some point, because this is hard; entire libraries exist on the subject for good reason, and AI and the smartphone have only raised the difficulty. Failure is just information. Get back to it, adjust what you’re doing to fit how you actually function, and try again. It’s worth remembering, too, that the people who seem effortlessly productive and perpetually focused aren’t; we’re human beings rather than robots, and the state of the world, the shape of our tasks, and what’s happening with our families all bear on how effective we can be on any given day. If small children have woken you five times a night for two months, no productivity app will save you, and that’s fine. Nobody has to be fully productive every single day.

If there’s a single thing worth holding onto, it’s this: hack your own life. If you want to change or improve something, be inventive about it and find the path that fits you. Take exercise, which is good for focus and health and yet, for someone who finds the gym unbearably boring and quits every sport within a few months, a chore reliably abandoned. The fix was to connect exercise to something already enjoyed consistently — gaming — by buying a foldable exercise bike that tucks under the couch, and now an hour on the bike five or six times a week, played alongside a video game, requires no willpower at all because it’s genuinely fun. It’s an embarrassingly simple solution, overlooked for years only because exercise was assumed to mean going somewhere specific. So be creative, try different things, and keep what works for you.

The last word is a caution against the whole enterprise tipping over into excess. Go outside, relax, and actually live your life, because a life isn’t meant to be optimized to death and you’re not meant to be productive every waking second. Leave room for the things that make you happy, including the ones that look like a waste of time, whether that’s building Lego in the basement or sorting a pen collection by color. Keeping up with this industry, especially now, is close to a full-time job on its own, so the discipline that matters most in the end is making sure you still take the time to live.

There are two ways to make something better, and they don’t get along.

The first one is patient. You take the thing in front of you, study where it leaks, and tighten it. A lesson plan that used to lose half the class by the second example now carries them to the end. A deploy that took twenty minutes takes twelve. The clinic that backed up every afternoon is empty by five. This is refinement, and it’s honest work. Most of the progress in the world happens this way, one small adjustment at a time.

The second way is rude by comparison. It doesn’t ask how to do the thing better. It asks why you’re doing it at all. Not how to make the weekly report clearer, but whether anyone reads it. Not how to speed up the approval step, but whether anything should need approving. The second question doesn’t tune the machine; it asks whether the machine should exist. People who ask it tend to make the room uncomfortable.

Both cost more than doing nothing. But they’re not the same kind of risk, and treating them as if they were is one of the more expensive mistakes a person or a company can make.

The refiner and the rebuilder

You already know which one you are.

Some people get real satisfaction from incremental improvement. They like the feedback loop, the measurable gain, the feel of a system getting tighter under their hands. Give them a process and they’ll find the friction in it. They are the reason most things that work keep working.

Other people can’t sit still inside a system they suspect is wrong. They look at that steadily tightening machine and feel a low hum of frustration, because all the careful tuning is making a flawed thing slightly less flawed. They want to tear it down and build the right thing. They’re often correct, and they’re exhausting to work with, because they reopen settled questions and treat consensus as the opening bid in an argument rather than the end of one.

Neither type is better than the other. A company full of refiners gets very good at the wrong thing. A company full of rebuilders never ships anything, because nothing holds still long enough to compound. Most organizations are built almost entirely for the first type, and then they act surprised when they can’t innovate.

Why the rebuilder looks reckless

The damage comes from an asymmetry in the risk.

Incremental improvement has a clean profile. Try a new format for the Monday review and it flops? You’re out a week and a little patience from your team. The downside is small and the whole thing is reversible. Nobody’s job is on the line. So organizations wave this kind of risk through; it barely registers as risk at all.

Transformation has a different shape. To rebuild something you usually have to break it first, and there’s a valley in the middle where the old thing is gone and the new thing doesn’t work yet. Performance drops before it recovers. The people who ran the old way are suddenly unsettled, or redundant. And you can’t prove in advance that you’ll come out the far side higher than you went in. The bet is real.

So a refiner proposes a test and the organization says go. A rebuilder proposes a rebuild and the organization says let’s make sure we understand the downside. Both are taking a risk. Only one gets called reckless. The label has nothing to do with the odds of failure; it tracks how much the idea threatens what’s already in place, and the people whose standing depends on it.

That’s why a genuinely good transformative idea gets its author’s hand slapped while a safe tweak almost guaranteed to move a number by a rounding error sails through. The system isn’t trying to get the best outcome. It’s trying to absorb only the kind of change it already knows how to absorb.

The question that actually matters

If both mindsets are valuable and both carry risk, the skill that matters is neither refining nor rebuilding. It’s reading the moment well enough to know which one a given situation calls for. That judgment is what most people skip, and it’s where refiners and rebuilders both go wrong.

Refiners go wrong by tuning what should be scrapped. You can spend two years making a process thirty percent more efficient and still lose, because it was the wrong process and someone else found a way to skip it. The worst place to be is highly optimized at something nobody needs anymore. By then the optimization itself argues for keeping the thing alive: all that invested effort, a sunk cost wearing the costume of progress.

Rebuilders go wrong the other way. They tear down things that worked, mistaking restlessness for insight. Not every system is broken. Sometimes the boring incremental path really is the right one, and the itch to transform is just an allergy to maintenance. A rebuilder who can’t tell the two apart burns a fortune reinventing wheels that rolled fine.

So before you decide, sit with one question: is the thing in front of you basically sound and merely imperfect, or basically wrong and merely familiar? The two need opposite responses. One wants patience and a thousand small corrections. The other wants the nerve to stop, even when stopping looks like failure and feels like waste.

There’s a test for it. Picture the incremental path working perfectly. If the thing runs flawlessly and you still don’t get where you need to go, you don’t have an improvement problem. You have a structural one, and no amount of tuning fixes a structural problem. That’s the case for rebuilding, not tightening.

Finding the right room

Underneath all of this is an uncomfortable fact: your disposition and your environment have to match, or you’ll be miserable and ineffective no matter how right you happen to be.

A rebuilder inside a refiner’s company is someone whose best ideas keep dying in committee. Every ambitious proposal gets relabeled reckless, studied until the energy drains out of it, and quietly shelved. The rebuilder decides the company is cowardly. The company decides the rebuilder is a pain. They’re both a little right, and neither can fix it, because the mismatch is structural. The place is built to absorb small change and reject the large kind, and one frustrated person doesn’t rewire that.

A refiner in a chaotic, rebuild-everything startup has the opposite problem. Nothing holds still long enough to improve. They start tightening a process and someone blows it up and starts over. Their gift for compounding small gains has nothing to compound, because there’s no stable ground to stand on. In a room that worships reinvention, they look slow and timid.

The fix is rarely to change yourself; it’s to find or build the room where your disposition is an asset instead of a liability, and to be honest about which room that actually is. A rebuilder needs a place that can eat the cost of a failed bet, that funds the learning instead of punishing the dip in the middle, that asks whether you understood the problem and not only whether you hit this quarter’s number. A refiner needs a stable system worth improving and the patience to let small gains stack up.

A lot of people spend years fighting their environment instead of moving, reading a structural mismatch as a personal flaw. The refiner thinks the problem is that he isn’t bold enough. The rebuilder thinks the problem is that she isn’t disciplined enough. Usually neither is true. They’re just in the wrong room.

What this costs

None of this comes free. The rebuilder’s path means more public failure and more friction, more standing there having fallen flat in front of the people who told you to play it safe. The refiner’s path carries a quieter danger: you wake up one day an expert in something the world has stopped needing. No version of meaningful work removes the risk; there’s only the choice of which one suits you.

What you can do is stop pretending the two questions are the same. Next time someone calls an idea reckless, find out what they mean. Do they mean the risk-reward is genuinely bad, or just that it threatens something already standing? Next time you reach for a quick fix, ask whether you’re improving the right thing or polishing the wrong one.

Start smaller than the big decision. Before your next real push, write a single sentence naming which kind of better you’re chasing and why this moment deserves it. Refine or rebuild, on purpose, on paper. Do it for a month and you’ll have a quiet record of your own defaults: whether you keep grabbing the sander when the job called for a crowbar, or knocking down walls that were holding up the roof.

Two people sit down with the same model open in the same browser tab. One turns a vague assignment into something sharp and useful by Thursday. The other ships a slower, blander version of the same idea two weeks later. The software didn’t make the difference. The operator did.

The model the person next to you types into is the model you type into. No premium tier thinks better thoughts for whoever pays more. What separates the two is the person at the keyboard: someone who knows what to ask for, what to throw away, and the specific places the tool will lie to your face.

Fluency is unglamorous and weirdly specific. It’s knowing the first draft a model hands you is a starting point, not an answer, and having the taste to spot which paragraph is alive and which three are padding. It’s knowing which jobs the model is genuinely good at and which it will botch while sounding completely sure of itself. (In 2023 a New York lawyer learned this the expensive way, filing a federal brief that cited several court cases his chatbot had invented, then having to explain the invention to the judge.) It’s knowing how to break a messy task into the four prompts that get you somewhere instead of the one that gets you mush. None of that lives in the product. It lives in the reps you put in, most of them the ones where the model let you down and you worked out why.

You can watch the gap open in any real workflow. The fluent operator turns a half-formed question into eight angles before the meeting starts, kills six, and walks in with two worth arguing about. The other one is still fighting the blank page. Or worse, pasting the model’s first suggestion into the doc because it sounded fine and the meeting was in ten minutes. Same tool, wildly different output, and across a few months that gap compounds into one person who moves faster than everyone around them.

So the edge is real. It’s also a window, and it’s already sliding shut.

Fluency spreads, and it spreads fast, because the techniques are cheap to copy and nobody can patent a good prompt. The move you’re early on this month, the one that feels like a private trick, is a LinkedIn post next month and a default habit the month after. Once everyone understands a technique, it stops being an edge and becomes the baseline everyone works from. You don’t get to keep the lift. You get to keep climbing, which is a tireder and less heroic job than the word “moat” makes it sound.

Climbing is also the trap, because fluency feels like a moat while you’re building it. You go up the learning curve, you pull ahead, and the urge is to bank the lead. Don’t. The gap closes behind you while you’re enjoying the view, because everyone else is on the same curve, and the curve gets gentler every month as the tools improve and somebody writes the playbook down. Being early to AI is real the way knowing how to actually search the web was real in 2004, or the way the one person who could drive a spreadsheet was, for a few years, the most valuable body in the room. Those edges were genuine. They also evaporated, and the people who mistook them for permanent got caught flat-footed when everyone caught up.

The honest version of “AI gives you an edge,” then, is narrower than the sales deck wants. It’s a speed advantage with an expiration date, and it belongs to whoever climbs first and keeps climbing after the crowd arrives. That’s a worse story than the pitch, and a more useful one, because it tells you what to actually do.

Treat fluency as a practice, not a purchase. Test each new model on your real work the week it ships, while the case studies are still being written. Write down what works. Throw it out when it stops working. Assume every technique you lean on will be ordinary inside a year, and start building the next one before you need it. The advantage was never a single trick; it’s how fast you can find the next one, use it, and let it go. My money is on the operator who replaces their best move fastest.

The window won’t announce that it’s closing. It just narrows, a little every month, while everyone keeps climbing. The only thing you control is whether you’re still moving when it shuts.

The people most certain that AI is about to replace everyone tend to be the ones who’ve never watched it fail at something they cared about. That isn’t a coincidence. It’s the mechanism.

Aaron Levie (Box) has a name for the state they’re in. He calls it AI psychosis, and he thinks executives are the most exposed to it, for a reason that has nothing to do with intelligence or temperament. They catch it because of where they sit. Levie sells AI software to 68% of the Fortune 500 and uses it all day, so he’s watched the onset up close, including in the mirror. You prototype a product over a weekend. You ask for market research and get back in ninety seconds what used to take an analyst a week. The floor tilts. For a few minutes, sometimes a few weeks, you live inside one thought: this does everything, so what are the rest of us for.

Levie’s framing is the useful part. He said CEOs are “sufficiently distant from the last mile of work that still has to happen to generate most value with AI.” The claim isn’t that executives are gullible. It’s that distance itself is the disease. The further you stand from the actual work, the more complete the automation looks, because everything you can see from up there is the part AI does well, and none of what you can’t see is the part it botches.

What the demo hides

Think about what a demo actually is. A demo is the eighty percent that comes easy, staged so the twenty percent that’s brutal never appears. An executive’s whole day is built out of demos: the polished deck, the thing someone already de-risked before it reached the calendar. So when AI hands an executive a flawless-looking first pass, it slots into a worldview already made of first passes. The dread feels like clear sight, when it’s the opposite. It’s the view from the plane, where the city has no traffic and every roof is intact.

Come down to the ground and the opposite is true. The last mile is the whole job. Levie describes the ordinary texture of it: the agent wrote bugs, and it pulled from the wrong spreadsheet, so if you hadn’t read the report yourself you’d have walked into a meeting and argued for exactly the wrong thing with total confidence. The output looked finished and wasn’t. Engineers can run a test and catch this; a contract or a hiring call can’t be unit-tested, so a human has to sit there and verify by hand. None of that friction is visible from altitude. All of it is the work.

The cure is contact

Which is why the cure isn’t reassurance. You can’t talk someone out of AI psychosis with a calming essay about how the robots aren’t ready. The only thing that resolves it is contact. Levie’s prescription is almost rude in its simplicity: use the technology so much that the awe wears off. Run it past the demo, into the part where you have to fix what it gave you, and the spell breaks on its own. It took him a couple of weeks. On the far side isn’t disappointment; it’s a working relationship, where you know what the tool is great at and where you still have to stand over it.

There’s a subtler failure on the same axis, and it’s the one to fear. The danger isn’t the executive who refuses to touch AI; that person is merely behind, and the market will educate them soon enough. The danger is the one who tries it once, gets dazzled, and stops looking. They saw the demo, mistook it for the territory, and built a strategy on the eighty percent while the twenty percent waited to surface in production. The convert got close enough for one look, then backed off before the lesson landed. That decision is cut from distance too, and it falls apart on contact with the work.

Where the value moved

The point Levie keeps circling is where value concentrates now. Not in generation; generation has gotten cheap and will get cheaper. It concentrates in the last mile, in the judgment that catches the wrong spreadsheet and the taste to know a plausible draft is still wrong. That’s not a sentimental claim about the human spirit. It’s structural. The work left after the easy eighty percent gets automated is the work that was always hardest, and it decides whether any of the rest was worth doing.

So if you feel the dread, or the high, treat it as a symptom of where you’re standing rather than a forecast about the world. Then close the distance on purpose. Pick one task you genuinely own, something you’ll have to defend to a real person on a real date, and do the whole thing with AI: not the demo version, the shipped version. Push it until it breaks, fix what broke, and count how many times you had to step in. That number is your real read on the technology, and it’s one no demo will ever show you. Levie got his in a couple of weeks. You can start on yours this week.

This essay was inspired by Aaron Levie, Box CEO: Advice for CIOs on AI Agents - YouTube

In the late 1970s, Apple Computer was facing a crisis of maturity. The company was no longer a scrappy startup operating out of a garage. It was a massive corporation with hundreds of employees, a board of directors, and a burning need to prove that it could build serious machines for serious professionals.

To solve this problem, Apple launched the Lisa project.

The Perfectly Managed Failure

If you were to walk into the Lisa development building in 1980, you would have seen a marvel of modern corporate management. The team was highly structured. They had clear organizational charts, meticulous daily schedules, and deeply defined roles. Every software feature was documented in thick, perfectly formatted binders. The managers tracked exactly how many lines of code were written each day. They implemented regular status meetings. They optimized every single process.

The Apple Lisa didn’t just fail. It failed spectacularly.

It was bloated, sluggish, and entirely devoid of magic. It was a commercial disaster that nearly bankrupted the company.

The Chaos of Creation

Meanwhile, in a separate building known as Bandley 3, another team was working on a different computer. They hoisted a literal pirate flag over their office roof. There were no thick binders. Engineers slept under their desks, played video games in the middle of the afternoon, and routinely engaged in screaming matches. It was an environment of absolute, unapologetic chaos.

That team was building the Macintosh. And the Macintosh changed the world.

The Myth of Efficiency

We have a deep, almost biological assumption about how work gets done. We believe in a strictly linear relationship between organization and output. If a messy process produces ten widgets, we assume a perfectly clean process will produce twenty. We send our managers to expensive seminars to learn about workflow optimization. We obsess over inbox zero. We believe that efficiency is the ultimate corporate virtue.

That assumption is wrong. Past a certain point, more order produces less.

The Apex and the Order Trap

To understand why the disorganized pirates defeated the meticulous managers, you have to picture a very specific graph. On the vertical axis, you have productivity. On the horizontal axis, you have order.

At the absolute origin of this graph, you have pure chaos. You have zero rules, zero processes, and consequently, zero productivity. Nothing gets done.

As you move along the horizontal axis, you begin to add structure. You introduce a morning meeting. You write a basic manual. You define a few key roles. And as you add this order, your productivity shoots upward. The engineers get better at communicating. The machinery starts to hum. The entire organization moves with a sudden, thrilling velocity.

But then, you reach the apex. You hit the peak of the curve. And this is where something truly bizarre happens.

If you continue to add order after the apex, your productivity does not flatten out. It does not stabilize. It plummets. You enter an order trap. Too much process, and the entire system grinds to a devastating halt.

The Addiction to Order

Any rational observer can look at this graph and see the obvious solution. You simply stop at the peak. You maintain just enough order to be effective, but not a single rule more. You stay balanced on the razor’s edge.

So why can’t we do it? Why do smart, rational people inevitably slide down the wrong side of the curve?

Because once order takes root in an organization, it is entirely unstoppable.

Order is not just a tool. It is a psychological addiction. It possesses a remarkable aura of moral virtue. Think about the language we use to describe highly structured things. We say they are “pure.” We say they are “efficient.” When you clear your desk, you feel inherently good. When a manager institutes a new time-tracking system, it feels like tangible progress.

It is exactly like alcohol.

The first drink feels incredibly right. It relaxes you. It makes the conversation flow. The second drink feels okay. The third drink is a terrible mistake. But you keep taking that third drink because your brain vividly remembers the euphoric rush of the first.

Organizations do the same thing with management. The first rule saved the company from chaos. So they write a hundred more. They get even better at doing exactly what they are doing. They micromanage their time with terrifying precision.

And then, the trap snaps shut.

The Sickness of Perfection

When an organization becomes perfectly orderly, a whole host of invisible diseases take hold. The company becomes completely closed off to change. The margins for error become so thin that there is no room left for experimentation. But the most fatal consequence is what happens to the people.

Every successful company relies on a handful of deeply disorderly people. These are the weirdos. The malcontents. The people who look at a perfectly functioning system and want to tear it apart just to see how it works. These people are essential for innovation.

But a perfectly ordered system views a disorderly person as an infection. The system protects itself. It writes new rules to govern their behavior. And eventually, it shuts them out entirely. The organization becomes beautiful, peaceful, and entirely dead.

The Human Counter Force

How do you survive the sickness of perfection? How do you fight against a force that feels so morally righteous?

You need a human counter force.

We tend to look back at Steve Jobs and assume his success was simply a matter of having brilliant ideas. We think of him as an artist who painted beautiful visions of the future.

But that is fundamentally misunderstanding his role. Lots of people have brilliant ideas. Jobs was successful because he acted as a violent, relentless counter force to order.

Jobs was up in the middle of the night. He was calling engineers at 3:00 AM to complain about the curvature of a plastic bezel. He was famous for walking into a room, looking at months of carefully planned, highly organized work, and throwing it in the garbage.

The Necessity of Disagreement

We have a massive misconception about the creative process. We imagine that creativity is purely about generating things. We assume it is driven by the psychological trait of openness. We picture a room full of happy people brainstorming on a whiteboard.

But the creative process actually requires two distinct components. It requires a productive component, yes. But it also requires a culling component. It requires a mechanism to kill the things that are merely good in order to make room for the things that are great.

Psychologists measure human personality using the Big Five traits. One of those traits is Agreeableness. Highly agreeable people value social harmony. They want everyone to get along. They want the meeting to end on time. They want the schedule to be met.

The culling component of creativity requires the opposite. It requires Low Agreeableness.

It requires the ability to look a team of exhausted engineers in the eye and say, “No.” It requires a complete disregard for the comfort of the organizational chart. Both Steve Jobs and Elon Musk possess this trait in staggering quantities. They are notoriously difficult. They are uncompromising. They actively introduce chaos into systems that are desperate to become peaceful.

They do this because they instinctively understand the danger of the curve. They know that if they allow the company to become perfectly comfortable, the company will die.

The Mirage of Perfection

We spend billions of dollars every year trying to optimize our lives. We download apps to track our sleep. We color-code our digital calendars. We seek out the warm, comforting blanket of total predictability. We desperately want to believe that if we just find the right system, everything will be perfect.

But perfection is a mirage. The very friction we are trying to eliminate is the exact thing keeping us alive.

The next time you find yourself frustrated by a messy desk, a disorganized project, or a deeply difficult colleague, take a moment to pause. You might be looking at the only thing standing between you and the inevitable, quiet death of order.

I learned to program by counting.

Not counting lines of code, or features, or hours. Counting cycles. On the Atari 2600, the machine I cut my teeth on, there was no frame buffer. There was no place to draw a picture and let the hardware show it to you. There was only the raster beam, sweeping left to right across the television sixty times a second, and a chip called the TIA that knew how to paint exactly one scanline at a time. If you wanted graphics, you generated them live, in real time, while the beam was moving. The beam did not wait for you. The beam did not care about your intentions. You had 76 machine cycles per scanline, and every instruction you wrote had a known, fixed cost. A load from page zero was three cycles. A branch taken was three, a branch not taken was two, and if your branch crossed a page boundary it cost you one more, and that one extra cycle could tear your playfield in half on national television, or at least on the Zenith in your living room.

So you counted. You sat there with the 6502 reference card and a legal pad and you added up cycles like a bookkeeper because the program counter and the electron beam were locked in a dance and you were the choreographer. Three color clocks ticked by for every cycle the processor burned. The beam moved whether your code was ready or not. Writing a game for that machine meant writing a program whose execution time was the display. Your code didn’t produce the picture. Your code, running, was the picture.

This is worth dwelling on because it has become almost impossible to see. Every layer of computing built since then has labored to hide it. At the bottom of every machine there is only timing, only the clock, only events chasing events. We who wrote games for the 2600, and later for the Atari 400 and 800 with their more genteel video hardware, lived at that bottom. The 800’s ANTIC chip would fetch screen data on the programmer’s behalf, a courtesy bordering on decadence, but the tricks that mattered, the smooth scrolls and impossible colors, still came down to interrupts fired at a particular scanline and a handful of cycles in which to act before the beam arrived. One learned to feel where the beam was, the way a sailor feels the tide. It was a strange intimacy, and it bred a strange joy: the deep, almost somatic pleasure of a routine that consumed exactly its budget of microseconds, not one more, a piece of clockwork seated perfectly inside a larger clock.

We Had Evidence, and the Evidence Expired

It also bred a priesthood, and priesthoods come with doctrine. Ours was simple. The machine could not write its own code. We had evidence. Compilers existed, and their output was a form of low comedy: bloated, meandering, and above all temporally innocent. The compiled code did not know what time it was. It carried no timing signature, and timing was the whole art. A compiler could no more write a video game kernel than a typewriter could write a sonnet. The gap between machine-generated code and the handmade kind seemed not merely wide but constitutional, a fact about the nature of machines.

We were not the first to believe this. In the early 1950s, when Grace Hopper proposed that a computer might translate human-readable notation into machine instructions, the programming priesthood of her day, men who composed in raw octal and were proud of it, dismissed the idea as fantasy. Computers did arithmetic; they did not write programs. When FORTRAN appeared in 1957, its creators understood that the entire project would live or die on a single question, the same question, always the same question: could the machine’s code rival a human expert’s? For a while it could not. Then it could. The hand-coders did not surrender their doctrine gradually. Each one held it absolutely, right up until the afternoon he didn’t.

The Argument That Ended the Moment I Lost It

My afternoon came on the 68000.

By then the processors had grown spacious. Registers in abundance, memory in megabytes, time itself no longer rationed by the scanline. I had sketched a routine in C, intending, naturally, to rewrite it by hand because this was a routine I knew the compiler could not handle. I had the assembly half-composed in my head, the way you carry a tune. Then I read the output of the optimizing compiler, and the tune died.

The compiler had restructured the problem. It avoided branches I would have taken. It held values in registers across spans where I would have spilled them to memory. It found an ordering of operations that I had not seen and, I slowly understood, would not have seen, and the result would run faster than anything I would have written. Not nearly as fast. Faster. I read that disassembly the way one plays through a chess game by a superior player, admiration shading into vertigo, and somewhere in the middle of it my doctrine quietly expired. I never wrote another line of assembly. There was no transition period, no hybrid workflow, no mourning. The argument ended, and I had lost it.

Here is the paradox that took me longer to see: losing felt like wealth. All the attention I had spent on cycle counts and register allocation. This required bookkeeping so consuming it had felt like the craft itself. What still remained was the actual work. What should the program do? What should the game feel like? The compiler had not taken the craft. It had taken the counting, and the craft, it turned out, had been hiding under the counting all along.

Another Level of Indirection, All the Way Up

There is a line every programmer eventually hears, usually credited to David Wheeler, the man who wrote the first subroutine: every problem in computer science can be solved by another level of indirection. It gets told as a joke and meant as a law. The whole field is a stack of indirections, each one a bargain struck with complexity: I will stop thinking about what is beneath me so I can think about what is above me. Wheeler’s punchline, the half nobody quotes, is that this creates the one problem indirection cannot solve, which is too much indirection. The tower we keep building to get away from the details is made entirely of details we agreed to stop seeing.

This is the oldest story in computing, told over and over at ascending altitudes. Machine code disappeared beneath assembly. Assembly disappeared beneath compilers. Memory management disappeared beneath garbage collectors, the disk beneath the file system, and the network beneath the protocol stack. Each layer begins as an absurdity, an improvement only a fool would pay for, then becomes a curiosity, then a convenience, then a floor: a surface so solid that the people standing on it forget it was ever contested, forget there is anything underneath at all. The machine does not vanish. It descends.

Here’s the unexpected good news. Each time a layer hardens into a floor, the person standing on it is not put out of work; she is moved up a story. The programmer who stopped toggling switches did not retire, she started writing assembly. The one who stopped hand-assembling started designing systems. Every floor is poured so that someone can stand on it and turn to the next problem up, the one that was invisible from below because the floor beneath it had not been laid yet. Indirection does not take the human out of the loop. It keeps lifting the loop to a higher altitude, and at every altitude the work that remains is the same kind of work: deciding what the thing on this floor is supposed to do. The counting goes downward. The deciding goes up.

The Crisis We Used to Call Compilation

Which brings us to the present and to a generation of senior engineers having my afternoon all at once.

I know these people. They came up the hard way, and they held the modern form of the old doctrine: machine-generated code will never match the handmade kind, because for years it visibly didn’t, in precisely the way 1982 compiler output visibly didn’t. Then came December, the holidays, when Opus 4.5 and 4.6 arrived, and ChatGPT 5.4, and the coding agents took one of those discontinuous leaps that appear on no roadmap, and I began to hear the same sentence from people who would never have uttered it a year before. I haven’t looked at a line of code in six months. Not spoken in shame. Spoken in the flat tone of someone reporting a fact about the weather.

Their agents now generate code faster than any human could review it, and this is described, in the present anxiety, as a crisis. But consider: my compiler has generated machine code faster than I could review it for forty years, and no one has ever called that a crisis. We called it compilation. We called it progress. We stopped looking because looking was no longer where the information was.

The objection writes itself, and it deserves a hearing. A compiler is deterministic, formally specified, the same input yielding the same output until the lights go out, while an agent is a stochastic process in a vest. True. But the trust we extend to compilers was never granted by the formal semantics. It was earned empirically, bug report by bug report, test suite by test suite, across decades of afternoons exactly like mine. The agents are earning it the same way, only compressed, and part of the new craft is building the instruments that check the work while no one is looking. Editors never worked alone either. They had fact-checkers.

That is what is happening now. Source code, the great artifact of the software century, the thing we versioned and reviewed and argued over in pull requests, is becoming what assembly became: an intermediate representation, a target language, the machine’s business. The human’s business is migrating upward, to intent, to architecture, to judgment, to taste, to the shape of the problem itself, which is to say, to the things that were always the job, obscured beneath the bookkeeping of the day.

The Blank Page Stopped Being the Job

And this time the story is leaving software. For most of a century the disappearing machine was something programmers told each other in a dialect only programmers spoke; the layers that descended were our layers. But the same leap that lets an agent write code it won’t show you also lets it write the brief, the memo, the market analysis, the lesson plan, and the contract. The lawyer who believed the machine could not argue, the analyst who believed it could not reason across the numbers, the consultant, and the strategist: each carries his own edition of the doctrine, and each has an afternoon coming.

I can speak to what waits on the other side because I have held the job that everyone is about to inherit. This is not a metaphor I am borrowing. For a stretch of my life I was a magazine technical editor, with a chair and a stack of other people’s manuscripts, and the work was never to produce the sentences. It was to read what someone else had produced and know, fast and often without being able to say why, whether it was alive. Where the argument went slack. Which paragraph was structural and which was throat-clearing? What the piece was reaching for and how far short it fell. I seldom wrote the line. I decided whether the line stayed.

That is the posture the machine has handed back to me. The draft now arrives faster than I could have made it and frequently better than I would have made it, and my real work starts where the draft lands: reading it, weighing it, cutting it, and handing it back with a note in the margin. The blank page, the thing writers dread and romanticize in equal measure, has quietly stopped being the job. The full page is the job. What I bring to it is no longer the act of generating words but the judgment of which words deserve to live, the same verdict I once passed on other people’s manuscripts, now passed on a machine’s.

And the chair is about to get crowded. The whole knowledge economy is becoming an editing economy. Not because writing stopped mattering, but because the drafting, the patient assembly of words and numbers that felt like the work because it ate the day, has slid down to the machine the way cycle counting once did. What it leaves on our side of the line is the part that was always the hard part and never looked like labor: knowing what the thing is for and whether it is worth making at all.

The Difficulty Was the Tax, Never the Love

There is grief in this, and I won’t wave it away, because I felt a version of it and have watched it land harder on others. When a thing you suffered to master becomes a thing a machine does in the time it takes to describe it, what you lose is not only a skill. It is a self. You spent years earning fluency, and the years were the proof that the fluency was worth having. The standing, the quiet authority of being the one who could do the hard thing, was collateralized by the difficulty. Remove the difficulty and the collateral is gone, and the feeling that follows is not relief. It is closer to mourning.

The conclusion people draw from it is usually wrong. The mistake is the one I nearly made on the 68000, reading that disassembly: confusing the cost of the work for the worth of it. Counting cycles was expensive, and because it was expensive it felt like the craft itself. But expense is not value. I thought I loved hand-assembly; what I loved was making the thing work, and the hand-assembly was the toll I paid at the gate. When the toll fell to nothing, I did not lose what I loved. I got more of it.

I won’t pretend it lands the same for everyone. Some people loved the counting itself, the closed and masterable world of it, and for them the floor giving way is a real loss and not a disguised gift. But for most of us the slaving was never the love. It was the tax on the love, and the machine has only stopped collecting it.

The Question at the Top of the Stack

The beam never waited. That was the first lesson, learned with a legal pad and a reference card, counting cycles against the sweep of an electron gun. Every abstraction built since was a way of letting the machine do the counting, and at every layer the same thing survived the handoff. Not the counting. The verdict.

When I sat in the editor’s chair, the verdict was wordless. I could not always say why a paragraph was dead; I only knew that it was, and the knowing was enough, because verdicts were rare and human and expensive, and mine was trusted on its record. That arrangement does not scale to what is coming. The drafts now arrive faster than anyone can read them, in every trade at once, and everyone is the editor now, and a wordless verdict passed at machine speed is just a mood with a deadline. The instinct has to become a discipline. The taste has to learn to show its work.

The machine has taken the counting, the way it took my cycles and my registers and my afternoons with the legal pad, and it is welcome to all of it. What it hands back is older than software, the question the editor asks of every page, the one the whole economy must now ask of everything it makes, faster than it has ever had to ask it, with less excuse than ever for getting it wrong:

Is this good, and how do you know?

There’s a skill almost everyone reading this has, and almost nobody thinks to use on their software. You learned it the first time you handed a piece of your work to another person and didn’t hover. You described what “done” looked like, you let them figure out the middle, and you judged the result instead of policing every step. That’s delegation. It’s the quiet competence that separates people who are merely busy from people who actually multiply what they can do.

For most of the AI era so far, that skill was useless. You typed, it answered, you typed again. You operated a very clever vending machine: insert prompt, receive output, repeat. The whole interaction lived inside your hands. Step away and nothing happened, because nothing was happening without you.

That’s the part that’s changing. The clever vending machine is starting to behave like a colleague. And the people who’ll get the most out of it won’t be the ones with the cleverest prompts. They’ll be the ones who already know how to hand off a goal and trust it to come back done.

Assistant or agent

The difference is easy to feel once you’ve named it. An assistant responds to a request, does one task, and waits for the next instruction. It’s reactive by design. You’re the engine; it’s the tool you’re holding.

An agent works toward a goal. Instead of reacting once, it takes a big objective, breaks it into steps, and carries those steps out over time, without you guiding each stage. You’re no longer holding a tool. You’re describing an outcome and getting out of the way.

That second sentence is the whole shift. “Get out of the way” is what good delegation feels like with a person, and exactly what felt impossible with software until recently. The reason it’s possible now comes down to four capabilities that, on their own, are unremarkable. Together, they’re the difference between a tool and a teammate.

It remembers. An assistant forgets you the moment the window closes. An agent holds context: what you asked for earlier, what it already tried, and where to find the documents, notes, and records it needs to do the job. This is the colleague who’s been around long enough to know where things are kept, instead of the temp you have to re-brief every morning.

It plans. Hand a person a vague goal and they’ll quietly turn it into a sequence: first this, then that, check, adjust. An agent does the same. It takes “draft a competitive teardown of these three products” and decomposes it into the steps you’d have written on a sticky note, then works through them in order. You supplied the destination; it drew the route.

It acts. This is the one that surprises people. An assistant talks about the work. An agent does the work in the actual systems where the work lives. It can pull the data, fill the spreadsheet, send the email, and kick off the next process. The talking stops being the product. The talking becomes the means to a finished thing.

It keeps going. A vending machine gives you one item and stops. An agent continues to work until it reaches the goal: tracking its own progress, noticing when something breaks, and adjusting when the first attempt doesn’t hold. That persistence is what lets you say “handle this” instead of “do this one step, now wait.”

Memory, planning, action, persistence. None of them is impressive in isolation. Stack them and you get something you can hand a real piece of work to, which is the only thing delegation has ever required.

What actually changed

We’ve been told the skill of the moment is prompt-craft: the right phrasing, the magic words, the secret formatting that unlocks a better answer. There’s a small industry built on the idea that the better you operate the machine, the better your results.

That was true when the machine was a vending machine. It’s less true now and getting less true by the month. When the thing in front of you can plan and persist, the bottleneck stops being how well you push its buttons. It becomes how clearly you can say what you want. The constraint moves from the tool to you, and specifically to the part of you that knows what “good” looks like and can describe it to someone else.

Which means the valuable skill was never prompting. It was the older, less glamorous thing underneath: getting precise about outcomes. What does done look like? What should this avoid? What would make me reject the result? Anyone who has managed people has been practicing this for years. The surprise is that it now transfers to software, and that the transfer is where the real gains are hiding.

The failure is also familiar

Here’s the honest part, because pretending otherwise helps no one. Delegating to a person who doesn’t actually understand the goal produces confident garbage, delivered on time, looking finished. Agents do the same thing. They will pursue the wrong objective with total commitment and hand you something polished and wrong.

So the skill isn’t blind trust. It’s the same judgment a good manager already runs. Write a clear brief. Define “done” before you start. Then spot-check the result rather than the steps, because checking every step is just doing the work yourself with extra anxiety. If you can’t tell good output from bad in a given domain, you can’t delegate it yet. Not to a person, and not to an agent. That’s not a limit of the technology. That’s a limit of your own taste, and the fix is to develop the taste, not to write a longer prompt.

This is the quiet reason delegation compounds. Every time you force yourself to write down what you actually want, the brief gets reusable and your own thinking gets sharper. The clarity outlasts the task. You’re not accumulating prompts; you’re accumulating a clearer sense of what good work looks like, which pays forward into everything else you do. That clarity is intellectual capital in the most literal sense: it grows the more you’re made to spell it out.

One thing to try this week

Pick one recurring task you’d normally grind through yourself: the weekly summary, the first draft of a recurring report, or the research you do before a decision. This week, don’t prompt it step by step. Write it a brief instead, the way you’d write one for a sharp new hire on their first day:

• The goal, in one sentence.

• What “done” looks like, concretely.

• What to avoid and any constraints that matter.

• Where to find what it needs.

Hand the whole thing over at once and let it run. Then judge only the result against the “done” you defined before you started.

You’ll learn two things fast. You’ll find out whether the tool can carry that kind of work yet. And you’ll find out something more useful: how clearly you actually understand what you want. The first answer changes monthly. The second one is yours to keep.

David Allen (Getting Things Done or GTD) changed my life, and for years I had no idea why his system worked. I ran it like a cargo cult: inbox emptied to zero, every loose thing captured and tagged because the book said to capture it. I built the runway and the control tower out of straw and waited for the planes. Some of it landed. Most of it didn’t, and I couldn’t have told you why. I was performing the rituals without grasping the thing underneath them, and a practice you don’t understand slowly curdles into one more chore. This is the part I missed for years: the rules were never the point.

The point isn’t your to-do list

The line that finally cracked it open for me is this: “Getting things done is not about getting things done. It’s about being appropriately engaged with your life and work so you can be fully present with whatever you’re doing.” That’s the piece my cargo-cult years never had. Productivity isn’t the goal; it’s what’s left over when the engagement is right. Do the work of engagement well and the output follows. Chase the output directly and you just spin faster.

He has a test for it. If “I need cat food” pops into your head more than once, you’re inappropriately engaged with your cat. A thought that recurs isn’t a sign of diligence; it’s a tax. There’s an inverse relationship between how much sits on your mind and how much actually gets done. As David fondly says: “Your head is for having ideas, not holding them.” Everything else in GTD exists to move commitments out of your skull and into a place you trust, so your attention is free for the one thing it’s good at: being here now.

When to write it down and when not to

GTD has a reputation for capturing everything, which gets it slightly wrong. David’s real rule is leaner. You write something down for one of two reasons: the world won’t remind you, or it will but at the wrong moment. He doesn’t track “do laundry”; no underwear handles that. He barely keeps a grocery list, because walking the market aisles cues the food itself.

So the universal question, the one he says he’d ask any person about almost anything, is this: what would you need to do to get that off your mind? Sometimes the answer is a reminder you’ll see at the right time. Sometimes it’s nothing because the trigger already exists. Do as little as you can get away with, and get the rest out of your head.

The habit takes about two years to set, seriously. This is roughly what it takes to learn the tango or to cook a decent meal. But the value lands on day one. Keep a pen by the bed and you’ll sleep better tonight.

Your head is a terrible office

Your brain is brilliant at pattern recognition and terrible at holding commitments. You walk into a room and instantly read the lighting, people, and furniture and process it instantly and astutely. Then you go to the store for lemons and come home with six things and no lemons.

Research puts our working memory at about four things at once. Four. Tiger over there, storm coming, build a fire, baby crying. Add a fifth and I lose perspective on the whole game. So my head felt like the natural place to keep my commitments, and it was the worst possible one. The principle underneath every technique that follows: my mind is for having ideas, not for holding them.

You don’t need more time. You need space.

Everyone believes the fix is two more hours. David’s answer is that two more hours just buys you two more hours of the same noise. Leonardo had 24 hours. Bach had 24 hours and twenty kids and still got a fair amount done. What a good idea actually costs in time is zero; the same goes for being creative or being genuinely present with the people in front of you. None of it runs on the clock. All of it runs on clear space, and a head full of half-decided commitments is exactly what burns that space down.

David’s metaphor for the state you’re after is: mind like water. It’s a concept from the martial arts. Water meets the world exactly as it is, no overreaction, no underreaction, no residue dragging on the system. You can’t move like that while two thousand unprocessed emails sit in your skull. The room you want isn’t on your calendar; it’s in your attention.

The mind sweep and the door trick

The first move is almost embarrassingly simple: get everything out of your head and into a trusted place outside it. Warning: Doing it properly takes most people one to six hours, because the moment you start writing, you realize how much was rattling around up there. Cat food. Call the doctor. New tires. Mom’s birthday.

The best capture tool isn’t the slickest app; it’s the one already in your hand. Pen and paper, no Wi-Fi, no batteries. David even offers the oldest hack you already use: put a folder in front of your door at night so your half-asleep morning self physically can’t ignore it. You trip over it before you leave, and suddenly everything inside is dealt with before your day scatters. That’s the whole game in miniature. Be smart once, park the result where you’ll trip over it, and you don’t have to be smart again.

Clarify: what is it, and what’s the next action?

A captured list isn’t a clear list. Most to-do lists are still a pile of unmade decisions, which is why looking at one creates almost as much pressure as it relieves. David’s drill on each item is two questions. First: is this actionable, yes or no? If no, it’s trash, reference, or someday. If yes, the question that should be set in thousand-point type: what’s the very next physical, visible action? Not “deal with mom’s birthday” but the call, the website, and the conversation you’d actually do next.

Then the two-minute rule: if the next action takes less than two minutes, do it now, because filing it costs more than finishing it. If it’s longer and it isn’t yours, hand it off; in his line, things constipate uphill, not down, and the executive is usually the bottleneck. And if one action won’t close it out, you’ve got a project, which just means naming what “done” looks like.

Organize: put it where it goes

Organizing is nothing fancier than putting each thing where that kind of thing lives. Date-specific actions go on the calendar and nowhere else. Everything else goes on lists sorted by context, the tool or place an action needs, so your “at home” items don’t nag you mid-flight to Moscow. One project list, reviewed weekly, keeps you honest. A waiting-for list tracks what you’ve handed off, so you follow up before it blows up instead of after.

Peter Drucker warned knowledge workers that their hardest job would be defining what the work is; capture, clarify, and organize are just how you do that on the front end instead of under the heat. Decide it when it lands, park it where you’ll see it, and the work stops chasing you around your own head.

One thing you can try this week

Keep a single capture tool within arm’s reach for the next seven days—a pen and index card, the notes app on your phone, or whatever you’ll actually use. Don’t overthink the format. The moment a thought surfaces that’s trying to live in your head rent-free, write it down and move on. Cat food, call the dentist, check that link, whatever. Don’t organize it yet. Don’t decide if it matters. Just get it out.

By day three, you’ll notice the noise. By day seven, you’ll feel the difference: your attention has air in it again. That’s the whole game. The system doesn’t matter half as much as the shift from “my head is my filing cabinet” to “my head is for right now.” David’s right that it takes two years to build the habit. But the relief lands on day one.

For most of my adult life, I thought I was bad at productivity. I read the books, tried the systems, built the lists, and still felt like something fundamental was broken. I could sit down to work with the best of intentions and end the day feeling scattered, behind, and vaguely ashamed. The diagnosis was always the same: I needed better planning, clearer priorities, and more discipline.

But over time, I noticed something that didn’t fit that story. When I actually started working—when I truly got into something—I was fine. More than fine. I could focus deeply for an hour, sometimes longer. I could think clearly, write, design, reason, and build. The problem wasn’t doing the work. The problem was everything that happened around it.

What finally clicked for me was this realization: my productivity didn’t fail at the beginning of work. It failed at the seams. It failed in the moments between tasks, especially at the end of a good focus session. That’s where momentum collapsed, attention scattered, and email mysteriously took over my day.

Once I saw that, everything else began to make sense.

The lie i believed about productivity

Like most people, I was taught that productivity is about choosing the right things to do and then executing them efficiently. Mornings were for planning. Lists were for clarity. Schedules were for control. If I was struggling, the explanation was always that I hadn’t planned well enough or followed the plan with sufficient discipline.

This model never fit my experience. Planning felt heavy and abstract. Lists felt accusatory. Schedules collapsed the moment reality intruded. Worse, the more carefully I planned, the more brittle the system became. One interruption or energy dip and the whole thing unraveled.

For a long time, I assumed this was a personal failing. Only later did I realize that the systems I was using were designed for a kind of attention I didn’t have. They assumed steady, linear focus and low transition costs. My attention wasn’t like that. It was immersive, state-based, and fragile at boundaries.

The real mismatch wasn’t between me and productivity. It was between me and systems that didn’t understand transitions.

The Moment That Finally Made It Obvious

The turning point came when I started paying attention to when my day actually went off the rails. It wasn’t when I sat down to work. It was after I’d already done something well.

I would finish a solid 60–90 minute stretch of focused work and then… stall. I’d check email. I’d scroll. I’d wander. The energy that had carried me through the previous block evaporated almost instantly. And then I’d spend the next hour doing things that looked like work but didn’t move anything forward.

This was deeply confusing at first. Why would I derail after being productive?

The answer, I eventually realized, was that finishing a focus block dumped me back into an undifferentiated world. Context dissolved. Time became vague. A dozen possible next steps appeared all at once, none of them clearly more important than the others. The emotional cost of choosing what to do next felt surprisingly high.

In that moment, email wasn’t a distraction. It was relief. It gave me structure when nothing else did.

That was the insight that changed everything: my problem wasn’t focus. It was transition.

Why Endings Were Harder Than Beginnings

Once I started looking at my work this way, I saw a consistent pattern. While I was inside a task, everything felt “ready-to-hand.” I didn’t have to think about what I was doing; I was simply doing it. But the moment the task ended, the world reappeared all at once. Obligations, ideas, and anxieties flooded back in without hierarchy.

That moment was emotionally expensive. It demanded reorientation, prioritization, and decision-making all at once, precisely when my energy was dropping. No wonder I avoided it.

Traditional productivity advice never addressed this. It treated transitions as neutral, almost invisible. In my experience, they were the most dangerous moments of the day.

Once I accepted that, I stopped trying to fix my productivity by optimizing beginnings. I started designing endings instead.

The Shift That Changed My Work

The single most important change I made was this: I stopped ending work without deciding what came next.

Instead of planning my day in advance, I began planning the next step at the end of whatever I was working on. I would stop a few minutes early, while context was still alive, and ask myself a simple question: if I were to continue, what would I do next?

Then I wrote that down—not as a project or a vague intention, but as a concrete, bounded action I could pick up later without thinking.

This did something remarkable. It allowed me to borrow energy from the present to support the future. When I returned to work, I didn’t face a blank slate. I faced a clear on-ramp.

Over time, this became a rule for me: I don’t get to stop without handing off momentum.

Why I Needed a Small, Disposable System

As I experimented with this approach, I noticed another important constraint. Whatever system I used had to be small and disposable. Large, comprehensive systems failed me for the same reason they always had: they required too much maintenance.

What I needed was not a perfect map of everything I had to do. I needed a baton—a simple artifact that answered one question: what do I do next?

I settled on a short list, usually no more than three items, each one sized to fit a single deep focus block. I stopped worrying about whether the list was complete or correct. Its job was not to represent my entire workload. Its job was to preserve continuity.

If it got messy, that was fine. If I abandoned it for a day, that was fine too. I could always create a new one. The system worked because it didn’t punish neglect.

That was a revelation for me. I had spent years building systems that collapsed the moment I stopped tending them. This one survived precisely because it expected imperfection.

Rethinking Time and Energy

Another shift followed naturally. I stopped treating time as something to allocate and started treating it as something to contain. Schedules never worked for me because time didn’t feel linear or predictable. What did work was recognizing that my best work happened in long, immersive stretches.

Instead of trying to chop my day into small pieces, I began thinking in terms of 60–90 minute blocks. I didn’t schedule them rigidly. I let them emerge. What mattered was that once a block started, it had a natural size, and once it ended, it triggered a handoff.

This made time feel safer. Work no longer threatened to expand infinitely. I wasn’t committing to “work on X today.” I was committing to one block.

That subtle shift reduced resistance more than any scheduling trick ever had.

Email Stopped Being the Villain

As my system changed, my relationship with email changed too. I stopped treating it as an enemy to be vanquished and started treating it as a signal.

When I noticed myself opening email compulsively, it was almost always because I had ended a focus block without a clear next step. Email rushed in to fill the gap. That wasn’t a moral failure. It was feedback.

Once I stopped ending blocks blindly, email lost much of its power over me. It became something I used intentionally, often as a recovery activity, rather than something that hijacked my transitions.

Letting Go of the Need to Be Organized

Perhaps the hardest lesson for me was letting go of the idea that a good productivity system should feel organized. For a long time, I equated order with control and control with competence. Messiness felt like failure.

What I eventually learned is that for me, messiness was often a sign that the system was doing its job. A slightly chaotic backlog was better than a pristine system that I didn’t trust. A disposable list was better than a carefully curated one I was afraid to break.

Once I stopped optimizing for neatness and started optimizing for continuity, my work became more consistent almost overnight.

Ending the Day Without Closing It

The final piece fell into place when I realized that days, like focus blocks, also need handoffs. If I ended the day without deciding what I would work on next, the following morning was almost guaranteed to dissolve into email and indecision.

So I began ending my days the same way I ended my blocks: by choosing one clear, bounded first step for tomorrow. Not a plan. Not a review. Just a baton.

This small ritual dramatically reduced morning friction. I stopped needing motivation to start. I simply continued.

What I Finally Understood About Productivity

What I eventually came to understand is that my productivity was never about doing more or trying harder. It was about not dropping momentum. Work didn’t fail because I was disorganized or undisciplined. It failed because I was asking myself to reorient too often, with too little support.

By designing for transitions rather than tasks, I stopped fighting my attention and started working with it. I stopped blaming myself and started engineering better handoffs.

I no longer think of productivity as control. I think of it as continuity.

If I can end one thing well, the next thing almost always takes care of itself.

One thing to try this week

Here is one thing you can try this week.

When you finish a task or a block of focused work, don’t just stop. Before you get up, check your email, or switch contexts, take one minute to decide on the very next concrete action you’ll take when you return.

Write down a single, small, and specific task. For example, instead of writing “work on the report,” write “review the Q3 sales data for the introduction.” This creates a clear starting point for later, making it much easier to dive back in and maintain your momentum.

If you have what we now call Attention-Deficit/Hyperactivity Disorder (ADHD), your attention isn’t absent. It’s simply unbounded. It’s a high-gain antenna sweeping across the spectrum of reality, picking up the chaotic static of the room: the hum of the fluorescent lights, the shifting weight of a colleague, the cascade of a dozen unformed thoughts. The problem isn’t a lack of bandwidth. The problem is turbulence. Your internal state is a continuous, exhausting search for a signal that refuses to resolve from the noise.

Unless, of course, the signal is perfect.

When the environment gives you the right frequency, the turbulence vanishes. Your mind’s erratic oscillation snaps into a sleek, laminar torrent. Time evaporates. The ego, with its anxieties and physical restlessness, dissolves into the task. The psychologist Mihaly Csikszentmihalyi called this frictionless state flow. For a mind that spends its days drowning in a shallow sea of under-stimulation, it isn’t merely productive; it’s a profound, almost biochemical relief. The clinical term is hyperfocus. It’s the sudden, terrifying efficiency of a hunting engine that has finally found its prey.

A well-designed video game is a masterclass in inducing flow. One of its secrets is managing prediction errors: the gap between what your brain expects and what actually happens. That gap is the signal your brain learns from most readily and the jolt it quietly craves. The game doesn’t demand your attention; it captures it through the rigorous application of information theory. To a mind starved of dopamine—the neuromodulator that shapes your sense of anticipation and value—a video game is a perfect, enclosed loop of anticipation and reward. It presents a world covered in an artificial fog of war, a literal manifestation of the unknown waiting to be mapped. It gives you clear, unambiguous goals, stripping away the paralyzing ambiguity of the real world.

Most crucially, the game adjusts its difficulty to hover exactly at the limit of your skill. It rides the razor’s edge between the stagnant valley of boredom and the chaotic spike of anxiety. If you improve, the game accelerates. The challenge scales perfectly with your capacity. Defeat a boss or explore a digital ruin and the game delivers a burst of variable rewards: maybe a rare item, maybe a mundane one. This uncertainty acts as a potent accelerant. It locks your hunting machinery in a state of hyper-vigilance. The feedback loop is instantaneous. The system never starves.

This is also the danger. The machinery that locks onto a worthy problem locks onto an unworthy one with the same grip. Hyperfocus isn’t attention obeying you; it’s attention captured, and the system rarely asks what has captured it. The same engine that produces a week of brilliant work produces the 3 a.m. gaming binge and the rabbit hole that swallows a day. Flow and compulsion run on one mechanism. The skill isn’t summoning the state; it’s choosing what gets to trigger it.

The tragedy of the modern era is that we’ve handed this design over to the machines, and they’ve aimed it at their own ends rather than ours. The architecture is elegant; we just don’t own it. Medication can lower the noise floor, quieting the static enough that a signal becomes findable; for many it’s the thing that makes everything else possible. But it clears the ground without drawing the blueprint. The rest you still have to build, and too often you’re left building it with sheer, agonizing willpower, forcing your high-octane engine to idle in traffic. Willpower is a finite resource. It decays.

To overcome the chaotic scattering of attention in the physical world, you can’t simply try harder. You have to become the architect of your own cognitive environment. The trick is to reverse-engineer the video game.

You learn to look at the messy, uncurated reality of your work and impose the mechanics of flow on it. That means ruthlessly eliminating ambiguity. The sprawling, terrifying specter of a “project” gets broken down into a localized, immediate puzzle. The long, silent void of a distant deadline gets replaced with artificial, immediate consequences. You trick the mind into seeing the fog of war.

You modulate the difficulty deliberately. If a task is too mundane, your brain refuses to engage, reading the zero-prediction-error state as a kind of cognitive death. So you gamify it, subject it to arbitrary constraints. Can this be written in half the time? Can this code be optimized with fewer lines? You manufacture your own friction. You introduce variable reward into the mundane: the thrill of synthesizing two disparate ideas into a single unexpected insight.

To live with a mind that refuses to idle is a dangerous, exhausting inheritance. It’s a life lived at the extremes, alternating between the paralyzing noise of the mundane and the exhilarating, frictionless acceleration of the hyper-focused dive. Yet if you treat your mind not as a broken machine but as a high-fidelity instrument, and if you build your own architecture of challenge, feedback, and reward, the chaos begins to recede.

You find the signal.

You enter the flow.

One thing to try this week

Pick the one task you’ve been avoiding. Before you touch it, write down the single next move, not the project, just the move, and set a visible timer for a deliberately short window. Then add one arbitrary constraint: half the time, or half the words.

You’ve just handed the task the two things it was missing: a hard edge and a puzzle small enough to grip. Notice that the focus, when it comes, arrived because you engineered it, not because you waited for it.

AI can either save you hours or quietly hand you mediocre work dressed up as finished. The difference rarely comes down to the tool. It comes down to how you work with it. What follows are eleven habits that separate people who get real leverage out of AI from those who just get faster at producing average output. None of them are technical. All of them compound: get them right, and every session makes the next one sharper.

Tip 0 — It starts with mindset

The single biggest predictor of whether AI helps you isn’t the tool, it’s how you approach it. You have a choice: be lazy (fire off a prompt, accept whatever comes back) or be collaborative (bring your taste, judgment, and market knowledge to sharpen the output). The collaborative approach is where the quality jump happens.

Aim for a compounding effect: every working session should make the next one better. When AI gets something wrong — misreads your brand voice, botches a segment definition — don’t just fix it and move on. Capture the lesson so you never fight that battle twice.

And recalibrate what you think is possible, often. What AI couldn’t do well six months ago, it may do easily now. When something seems out of reach, don’t write it off — make a note and try again in a month. The best trick of all: just ask the AI. “How can we work together better? Give me 10 ways I could get more out of you as a marketing partner.” The first answers will be mediocre — tell it which ones you liked, ask for 10 more, and watch the quality climb.

Tip 1 — Context is king

Most bad output is your fault, not the model’s. AI is built to fill in blanks — give it too little and it’ll confidently invent the rest (the equivalent of a generic, lifeless draft).

• Point, don’t make it wander. If you know which audience, product, or past campaign matters, say so. Don’t make it guess across your whole world.

• Feed it reference material. Keep living documents — brand voice guide, positioning, ICP profiles, past high-performers — and point the AI at them instead of re-explaining every time.

• Use images. A screenshot of a competitor’s landing page, an annotated ad, a circled chart — sometimes showing beats describing. The models read images well.

• Mind the “glass.” Every conversation has a finite working memory, and it fills up. As it fills, quality drops and the model gets confused. Bigger isn’t always better. When you finish a task — or when a thread gets bloated — start fresh. A clean slate with the right context beats a long, muddy one.

Tip 2 — Build a “house rules” doc (and keep it alive)

Create one reference document that tells the AI how you work: your brand voice, your audience, the tools and channels you use, your common gotchas (”we never say X,” “always include a CTA,” “our tone is dry, not peppy”). This is the highest-leverage asset you can build.

Don’t copy someone else’s template off the internet — the best version is one built around your work. And don’t write it from scratch yourself; have the AI draft it, then refine it with your preferences over time. When the AI makes a mistake, tell it: “Let’s learn from this — update our house rules.” Treat it as a living document, not a one-off.

A favorite move: have the AI interview you. “Ask me five questions before you start — what context are you missing to nail this?” You’ll get better results without having to anticipate everything yourself. (Lazy bonus: ask it to give you multiple-choice options for each question.)

Tip 3 — Codify your repeatable workflows

This is the most important habit to build. Anything you do more than once — a weekly newsletter, a campaign brief, a competitor teardown, a launch checklist, repurposing a webinar into five assets — deserves to be turned into a reusable, documented process the AI can follow the same way every time.

Best way to create one: do the work with the AI once, manually, until you’re happy with the result. Then say: “Turn this into a repeatable workflow I can trigger any time.” That beats trying to design the process in the abstract.

Think in two buckets:

1. Encoding your judgment — your voice, your standards, your way of structuring a brief.

2. Extending your reach — giving the AI a capability it doesn’t have on its own (pulling in fresh data, generating images, formatting for a specific channel).

What capability do you wish you had? You can probably build a workflow for it — or ask the AI to build it for you.

Tip 4 — Always make a plan first

Marketers don’t love writing detailed briefs. Good news: AI is great at it. Describe what you want and your constraints, then let it flesh out the plan before any real work happens. Time spent up front on scope and strategy pays back many times over in the final result.

One subtle but crucial point: don’t lead with your opinion. AI is eager to agree with you. If you open with “I think we should do a nostalgia angle, what do you think?” it’ll tell you that’s brilliant. Instead, describe the problem and ask for approaches first — then weigh in. You’ll often discover an angle or framework you’d never have considered. Invite it into the thinking, don’t just steer it.

Tip 5 — Give the AI a way to check its own work

The most underrated tip. If you’re the only one who can catch errors, you become the bottleneck. Wherever possible, build in a self-check so the AI catches its own mistakes before they reach you.

Concretely: have it fact-check its own claims against your source docs, run a draft against your brand-voice rules, score its own headline options before presenting them, or sanity-check numbers in a report. “Before you show me this, verify every stat against the source and flag anything you can’t confirm.” The goal is to stop being the manual QA layer.

Tip 6 — Use the best model, not the cheapest

It’s tempting to economize. But the smarter models produce dramatically better work, and the time you save not fixing weak output usually outweighs the extra cost and the slightly slower response. For anything that matters — strategy, positioning, customer-facing copy — use maximum effort. (A useful pattern: let a top model act as the “editor” reviewing and directing faster, cheaper models on the grunt work.)

Tip 7 — Run work in parallel with helper agents

You don’t have to do everything in one linear thread. Spin off independent helpers to work simultaneously: “Analyze these 10 competitor pages, one summary each.” “Draft this campaign for three different segments at once.” Each helper works with its own clean context, which means you effectively get unlimited working memory and parallel throughput.

You can also define specialized roles — a “research analyst,” a “copy editor,” a “brand-voice reviewer” — and chain them: research first, then draft, then critique. Build the assembly line once, reuse it forever.

Tip 8 — Automate the things that must happen every time

For checks you want enforced without fail — not just “usually” — set up automatic triggers that fire around your workflow rather than relying on the AI to remember. Examples: every draft automatically gets run through your brand-voice checker; every report automatically gets its figures validated; whenever a piece is “done,” it’s automatically formatted to your channel’s spec.

These run outside the AI’s reasoning, so they cost nothing extra and guarantee consistency. The trade-off is they add a step — which is often exactly what you want when quality control is non-negotiable.

Related trick: if the AI keeps stopping to ask “should I continue?” when you just want it to finish a multi-step job, set it to keep going until the whole task is genuinely done — just be clear about the stopping criteria.

Tip 9 — Learn from every rabbit hole (compound your knowledge)

This is the habit that makes everything else compound. Every time you and the AI pull your hair out solving something, capture the lesson so it never recurs: “Now that we’ve sorted this, I never want to hit this again — record what we learned.”

Build a reflection step into your routine: “Looking back at this project — what would you do differently? What mistakes can we learn from?” Then capture the answer in a notes file, not just the chat window where it vanishes on the next reset. Branch your reference docs by topic (a “content learnings” file, an “ad copy learnings” file) and pull each in only when relevant, so you don’t bloat the working memory.

Even better, periodically ask the AI to analyze your own working patterns across past sessions: “What do I keep doing the slow way? Where do you keep making the same mistakes? What should I turn into a reusable process or an automation?” It can be a little humbling — and extremely useful.

Tip 10 — Connect your tools, scale up carefully, and stay in the loop

• Hook the AI into your stack where it adds real value — analytics, your CMS, design files, up-to-date references — so it’s working with live information, not guessing. Favor read-only access for anything sensitive; be deliberate about what you let it change.

• Scale gradually. Running several AI sessions at once feels powerful, but there’s a real cognitive-load ceiling — you can only meaningfully supervise so many at a time. Don’t burn out chasing throughput.

• You can work from anywhere now — kick off and steer work from your phone between meetings.

• Schedule recurring jobs — “every Monday, pull last week’s campaign performance and draft the summary.”

• For genuinely big efforts, larger multi-agent setups exist, but they’re expensive — reserve them for the heavy lifting; most work doesn’t need them.

• Keep asking for more. Capabilities you assume don’t exist often already do. Ask the AI to build the tool or process you wish you had.

And above all — be the human in the loop. The models are good and getting better, but they make mistakes. Don’t let everything sail by unchecked. Be smart about it: have the AI review its own work before you spend your time on it. A genuinely effective prompt is simply “make it better” — it forces another pass that weeds out the most common mistakes. “Are you sure?” does the same. Use them liberally — then apply your own judgment, because that’s still the part only you can do.

There’s a kind of wealth that doesn’t show up on any balance sheet. You can’t spend it, but it compounds. You can’t lose it in a market crash, but you can let it rot from neglect. It’s the only asset that grows the more you give it away.

It’s what you know, how you think, what you notice, and what you make of all of it.

I call this intellectual capital — and I’ve come to believe that building it deliberately is one of the highest-leverage things a person can do. So I’m starting a newsletter about exactly that.

What this is

Intellectual Capital sits at the intersection of four things I can’t stop thinking about:

• Productivity — not the grind-harder kind. The kind that’s really about doing what matters with your full attention and protecting the energy to do it.

• Curiosity — the engine underneath everything good. Learning how to learn and giving yourself permission to fall down the right rabbit holes.

• Creativity — curiosity put to work. The craft of actually making things and getting past the part where you stare at the blank page.

• Ideas — the connective tissue. The frameworks and mental models that let all of the above stack into something durable.

Most newsletters pick one of these. I think the interesting stuff lives in the overlap — where a question you couldn’t shake becomes a thing you build, which changes how you spend your days.

And running through all four, like current through a wire, is the thing reshaping every one of them right now: AI.

On using AI — unabashedly

Let me be clear about where I stand, because it colors everything here.

I use AI constantly, openly, and without apology. Not as a gimmick and not as a crutch — as an amplifier for the four things above. It is the single biggest lever on intellectual capital to come along in my lifetime, and I’m not going to be coy about reaching for it.

The hand-wringing crowd has this backwards. The worry isn’t that AI will think for you. The worry is that you’ll use it to avoid thinking — to outsource the struggle that actually builds the muscle. Those are entirely different things. Used badly, AI makes you duller. Used well, it lets you ask bigger questions, chase more rabbit holes in an afternoon than you used to in a month, and ship things you’d never have finished alone.

The skill — and it is a skill — is knowing which parts to hand off and which parts are the whole point. You don’t let it write the sentence you most need to think through. You do let it kill the blank page, pressure-test your logic, summarize the thing you’d never have read, and play the tireless sparring partner at 2am.

So expect a lot of this newsletter to be about doing exactly that, in the open:

• Prompts and workflows that actually move the needle, not party tricks.

• Where AI fails — the tasks where reaching for it costs you more than it gives.

• Taste over output — how to stay the editor, the curator, the one with the point of view, when generating a thousand words costs nothing.

Building intellectual capital in 2026 without using AI well is like doing arithmetic by hand to prove a point. Admirable, maybe. But you’re leaving the compounding on the table.

What you’ll actually get

Every issue is built to respect your attention because that’s the whole point. In most issues, you’ll get:

• One big idea worth chewing on — drawn from one of the four themes above.

• One thing to try this week — concrete, not theoretical. Often an AI workflow you can steal in five minutes.

• A few things worth your curiosity — links, quotes, and objects I think are worth your time, each with a reason.

A few minutes out of your day, then I get out of your way. No hustle-porn, no link dumps, no manufactured urgency.

Every so often, though, I’ll break the format. When a topic deserves room to breathe, you’ll get a longer-form piece instead — a deep dive into a single idea, a how-to I’ve actually stress-tested (think “10 Ways to Level Up Your AI-Assisted Work”), or an opinion piece I couldn’t fit into a few hundred words. Those will take more than a few minutes. They’ll be worth it.

Why I’m writing it

Honestly? Partly selfish. Writing forces me to actually finish a thought instead of letting it dissolve back into the noise. The best way I know to build intellectual capital is to put ideas into the world and see which ones survive contact with other people.

But also: I think a lot of us feel stretched thin and weirdly dull at the same time — busy without being curious, productive without making anything. I don’t think that’s a personal failing. I think it’s what happens by default, and it takes a little deliberate practice to climb out of. This newsletter is me doing that practice in public and inviting you to do it alongside me.

One thing to try this week

Keep a “spark file.” A single note — on your phone, in a notebook, wherever — where you write down every question that genuinely interests you. Don’t answer them. Don’t organize them. Just catch them before they evaporate.

In a month, read it back. The patterns in what you’re curious about will tell you more about where to point your time than any productivity system ever will.

Come along

If any of this resonates, the best thing you can do is reply and tell me what you’re curious about right now. I read everything, and your answers will shape where this goes.

Thanks for being here at the start.