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.