I don’t have a prompt. I have a triangle of loops.

Prompt engineering is about what you say to a model once. Loop engineering is about designing the cycles the model runs inside: how work enters, how it gets decomposed, how it executes, how it gets verified, and how the result feeds the next round. The prompt is maybe five percent of the outcome. The loops are the rest.

This is how my setup actually works today, from ~/.claude to a delivered pull request. No ideology. Just the machine I run every day.⊕Project names in the examples are changed; the mechanics are exactly as run.

The triangle of loops

My work runs on three nested loops, each operating at a different time scale:

• The session loop: one agent session, measured in hours. It opens with a written commission and closes with a structured closeout or a handoff document.
• The sprint loop: one research → plan → execute → retro cycle, measured in days. My jira plugin defines a sprint as exactly that: one research, plan, execute cycle, with review and retro for closing the loop.
• The program loop: the long horizon, measured in weeks. A kickoff produces PROJECT.md and a phased ROADMAP.md; delivery programs decompose into packets.⊕My v1 program ran nine packets; the v2 delivery program carries twenty plans across four phases.

Session loops nest inside sprint loops. Sprint loops nest inside program loops. And here is the part that makes it a triangle instead of a stack: every loop, at every scale, runs the same grammar and shares the same start point and end point.

The grammar is a recursion:

objective → execution → feedback → refined objective → execution → …

The start point is always a written commission: that is the objective. The end point is always the same pair: ship only what passes verification, then a retro: that is the feedback. And the retro’s output is a refined objective, the next commission sharpened by what the feedback taught. That refinement step is why the loop converges instead of spinning.

Once you see the triangle, the rest of this article is just a tour of its parts: the harness the loops run on, the start point, the middle loop up close, the fork-join shape of execution, the gates at the end point, and the memory that makes nesting possible.

The harness is a place, not a prompt

The loops run on infrastructure that lives in ~/.claude, and it is a versioned system, not a text file I paste around.

At the top is CLAUDE.md, which I treat as an operating contract between me and any agent session. It encodes the rules I learned the hard way:

• Phased execution. Never attempt a multi-file refactor in a single pass. Finish phase one, run verification, wait for approval before phase two.
• Forced verification. An agent is forbidden from reporting a task complete until it has run the project’s actual checks and fixed what they surface. If no checker is configured, it must say so instead of claiming success.
• Failure recovery. If a fix fails twice, stop. Re-read the whole section, find where the mental model was wrong, and propose something fundamentally different. No third attempt at the same idea.

Underneath the contract, settings.json tunes the machine: acceptEdits as the default permission mode,¹ pre-approved permissions for the tools I trust, and all AI attribution stripped from commits and PRs.

And autoCompact stays disabled,² because I manage context deliberately rather than letting it truncate silently.

Then there are the hooks.³ Around eighteen of them fire on session start, prompt submit, and before and after every tool call: a context monitor, a read guard, a commit validator, a statusline, and a trust monitor I’ll come back to. There are even audio cues, StarCraft-style WAVs on session start and stop. I can literally hear a session loop open and close.

The whole directory is versioned in its own repository with an auto-updating plugin marketplace. When I migrated to a new server recently, the harness got zipped and cloned alongside my dotfiles, because the agent kit has to be portable or it isn’t real. Claude, Cursor, Kimi: the models swap, the harness stays.

The start point: commissions, not conversations

Every loop at every scale begins the same way: the objective enters as a written commission, never as a chat message.

A new session doesn’t get “hey can you fix this.” It gets a commission document, modeled on a real one from a data-platform project of mine:

cat > PLAN.md <<'EOF'
You are the delivery agent for pulse.rs F4 to F8.
Your commission is the master plan at ~/.context/northstar/project/MASTERPLAN.md.
READ IT FULLY FIRST. It is the contract; do not re-derive what it settles.
You OWN the workflow: decompose the mission into your own dynamic orchestration.
Subagents default to the cheaper model tier; spend the expensive one on the critical path.
Close out with evidence: branch, PR url, tests, blockers, next owner.
EOF

A commission names the mission, points at the contract document, separates what is settled from what is open, states the standing rules, and assigns ownership. After that I get out of the way. My go-signals are one word: “yes, push it.”

This is a deliberate inversion. Most people hold the objective in their head and drip-feed it to the agent. I write the objective down once, hand over ownership, and spend my attention on the gates instead of the steering wheel.

The middle loop, up close: from jira to orchestrator

The sprint loop is where the triangle does its daily work, and it runs as a pipeline of skills, each with one job, each handing a verified artifact to the next:

• /kickoff turns an empty repo into a working project: PROJECT.md, a phased ROADMAP.md, jira and the project’s context layer initialized. Kickoff is alignment, not automation.
• /grill is adversarial Q&A. In stress-test mode it attacks a plan one question at a time until the holes surface, ranked BLOCKER, RISK, or NITPICK. In shape mode it co-creates two or three approaches and converges to a decision log. Nothing enters a sprint un-grilled.
• /jira:research and /jira:plan turn a grilled idea into a sprint. A planner agent drafts the plan, an independent plan-checker⁴ agent audits it, and the loop allows a maximum of two revisions before it escalates to me.
• /jira:execute fans the plan out to wave-parallel⁵ executor agents with explicit file ownership.
• The first gate is a Nyquist test gate,Named for the Nyquist–Shannon sampling theorem: sample a signal too sparsely and you reconstruct the wrong one. The gate samples the change surface with tests dense enough to reconstruct what was actually built, and catch where it aliases away from what was asked. run against the executor output right after execution.
• The second is a goal-backward verifier⁶ that checks the work against the original intent. A PR opens only on PASS.
• /jira:retro closes the loop and rolls the workflow lessons into the next commission.

A typical instruction from me looks like this:

Spin all of these into a new /jira:research and sprint named pulse.rs.alpha, plan them, drop the user-facing issues for each, then implement a /loop to execute and deliver all of them.

Two things to notice. First, the audit loops are bounded: two revisions on a plan, two attempts on a fix, then a human gets pulled in. Unbounded loops are how agents burn hours polishing a wrong answer. Second, every handoff between stages is a document, not a conversation. Documents survive context windows. Conversations don’t.

The orchestrator never writes code

Wrapped around the sprint loop is my longest-running session pattern: orchestrator mode.

/orchestrator on turns the current session into a coordination-only thread, a chief of staff. From that moment it never implements anything locally. It classifies every request, and per-branch work gets routed to a durable background child agent keyed by branch. The same child stays alive for the life of that branch, so it accumulates context instead of starting cold. Children that touch code run in isolated git worktreesA git feature that checks out a second branch into a separate directory backed by the same repository. Two agents can edit two branches at the same time without ever seeing each other’s files, and merging stays an ordinary git operation. so they can’t collide.

The orchestrator maintains a branch table: branch, child agent, status, next action. It restates that table at every status check, which looks redundant until you realize why: restatement is how state survives context compaction. Anything that isn’t restated or written down eventually evaporates.

For one-shot fan-outs there is /spawn: parse a plan into units with explicit file ownership, group them into dependency waves, present the dispatch plan, wait for my approval, then execute each wave in parallel. Its hard rule is the same as the orchestrator’s: you coordinate, you never write application code.

Every child closes out with a structured report: branch, PR URL, test results, blockers, next owner. That closeout is the end of one session loop and the raw material for my status checks.

This scales further than you’d expect. A docs-site rewrite of mine ran as an orchestrator plus a seven-phase loop with named child agents, including an independent design-critic agent whose only job was reviewing screenshots for a second opinion. The orchestrator relayed each child’s commits, verification results, and deviations back to me in tables, because I ask for evidence over prose.

Execution is fork-join

The execution edge of the grammar has its own shape, and it comes straight out of parallel computing: the fork-join model.The fork-join model comes out of parallel computing. Doug Lea’s Fork/Join framework in Java 7 is the canonical implementation, and Cilk popularized the pattern before it. The shape is universal: split, run concurrently, join. A program forks into parallel tasks, workers run concurrently, and a join barrier collects the results before the program continues. My harness runs the same pattern, with four distinctions that matter more than the similarity.

The fork is a dispatch plan, not a thread pool. Classic fork-join forks eagerly: split until the tasks are small enough, then let the runtime schedule them. I fork deliberately. /spawn parses a plan into units with explicit file ownership, groups them into dependency waves, presents the dispatch plan, and waits for my approval before anything runs. One wave forks, joins, and only then does the next wave fork. The fork is a decision, not a default.

The workers are durable and named, not anonymous. A fork-join pool is anonymous workers stealing tasks from a queue. My children are the opposite: keyed by branch, alive for the life of that branch, accumulating context, each in its own git worktree. The shared-state hazard that fork-join frameworks spend so much effort containing never materializes, because ownership is assigned at the fork instead of negotiated during execution.

The join is a gate, not a barrier. A join barrier waits for results and merges them. My join asks a harder question: do these results deserve to exist? The wave’s output goes through the Nyquist test gate, then the goal-backward verifier, and a PR opens only on PASS. /spawn verifies by reading the git log, not by trusting what the children report. The join doesn’t merge output. It merges confidence.

The serial part moved, it didn’t shrink. Amdahl’s law caps every fork-join system:Gene Amdahl, “Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities” (1967). The serial fraction of any workload caps its parallel speedup, no matter how many workers you add. you can only speed up the parallel fraction, and the serial remainder sets the ceiling. Generation parallelized; verification did not. So the math I laid out in The Scope Compression Hypothesis holds inside every loop: generation ≈ max (task time), but delivery ≈ generation + verification. Fork-join doesn’t eliminate the serial work. It concentrates it at the join, which is exactly where my gates live.

And the pattern nests the same way the triangle does. The program loop forks sprints. The sprint loop forks waves. The session loop forks subagents. Fork-join at every scale, with a gate at every join.

The end point: gates, ship, retro

The end point of every loop is feedback, and in my system the feedback comes in threes. A plan-checker audits the plan before execution. A Nyquist test gate checks the work after execution. A goal-backward verifier audits the codebase against the original intent last. Three gates, in sequence, none advisory: /jira:execute will not open a PR on a verifier FAIL, full stop, and /spawn verifies delivered work by reading the git log, not by trusting the agent’s self-report.

The instinct goes deeper than tooling. In that same data-platform project, correctness itself is built in three layers: the engines, then a verifier that proves the engines agree, then a separate evaluator with an independent ground truth that catches the case where both engines misread the same thing. The principle written into that project’s decision log applies to the whole harness: never trust a single source; nothing checks itself.

The strangest piece of the harness is also the most effective enforcement of that principle: a trust ledger, applied by a hook on every tool call. Every session starts at 50 out of 100, trust level L2. Levels gate what the agent may do. L1 edits files. L2 runs mutating bash and spawns agents. L3 pushes, opens PRs, deploys. L4 touches destructive operations. Deductions are Fibonacci-scaled:Penalties follow the Fibonacci sequence (2, 3, 5, 8, 13, 21) so small slips stay cheap while severe or repeated failures escalate super-linearly. The cost curve itself discourages an agent from testing the edges. a delivery miss costs 5, an unverified claim costs 8, fabrication costs 13, tampering with the ledger itself costs 21. Self-reporting a violation costs a flat 3, because disclosure should always be cheaper than discovery. Only I can award points. Drop below 20 and the agent is terminated: all mutating tools denied, and I start a fresh session.

It sounds theatrical. It works because it prices honesty into the system. An agent that loses more trust by hiding a mistake than by admitting it will admit mistakes, and an agent whose privileges depend on verification will verify.

After the gates comes the move that completes the grammar: the retro turns feedback into a refined objective. /jira:retro rolls the sprint’s workflow lessons into durable state, and those lessons shape the next commission. My runbooks make the discipline explicit: every step ends with a verification gate, and you do not proceed past a failed one. Feedback that doesn’t refine the next objective is just logging. The end point of one loop is the start point of the next. That is what makes it a loop and not a pipeline.

The statusline is the instrument panel

A loop you can’t observe is a loop you can’t operate, so the two numbers that govern every session live permanently at the bottom of my terminal, wired through the statusLine parameter in settings.json. It runs a command, a Node script in my hooks directory, that renders the model, the current task or milestone state, the directory, and the two gauges I actually watch.

The first gauge is context: a ten-segment meter with the used percentage, normalized against the buffer the runtime reserves for autocompaction, shifting from green to yellow to orange to a blinking red skull as the window fills. The statusline also writes those metrics to a bridge file that the context-monitor hook reads, so the agent itself gets warnings injected when its context runs low. The agent sees its own fuel gauge, not just me.

The second gauge is trust. The statusline calls the trust monitor in a compact render mode and appends the result: level and score, always visible. L2 · 50 on a fresh session. The cover image of this article shows it in the wild, sitting in the statusline of a session running a wall of loops. At any glance I know how much context the loop has burned and how much privilege the agent currently holds, which are exactly the two numbers that decide whether I let it run, hand it off, or terminate it.

The memory that makes nesting possible

Three nested loops only work if state survives the boundaries between them, and most people leave that to chance. I engineer it.

The durable memory lives in a private context layer (call it ~/.context/northstar), a versioned repo of workflow state that is specific to my setup and deliberately internal: a status.md that is the reference for each workstream, a handoff.md that acts as the session baton, a decision log of load-bearing calls, dated sprint directories each with brief, research, plans, execution, and verification artifacts, and the program packets above them. The sprint and program loops live there as documents, so any session loop can pick them up cold.

If you copy one practice from this article, make it this one: give your harness explicit context layers. A PLAN.md the session must read before it touches anything. A status doc that is the reference, not the chat. A decision log for the calls you never want re-litigated. A handoff doc for crossing sessions and machines. The filenames matter less than the discipline: named, durable, versioned context that any agent, on any machine, can pick up cold.

Inside a session, I keep autoCompact off, so nothing gets silently summarized away. /handoff compacts a session into a HANDOFF.md a cold agent can pick up: mission, repo state, locked decisions, open gates, a “not your problem” scope boundary, and a pickup checklist. Handoffs travel between machines over scp; a session that runs out of context on one box resumes on another with the document as the contract.

Two smaller habits matter as much. Long-running monitors run in subshells, not in the main thread. I learned that one the hard way and the correction is still in my history: “You were supposed to have this monitor running in a sub shell, so you don’t overload your context.” And anything the orchestrator needs to remember gets restated on every status check, because restatement is the only compaction-proof memory.

The loop is the product

Here is the part people underestimate. None of this is about a specific model. The models keep changing and will keep changing. What compounds is the triangle: the contract, the commissions, the fork-join discipline, the gates, the trust accounting, the memory.

Prompt engineering optimizes a message. Loop engineering optimizes a system that keeps delivering after you close the lid of the laptop.

When I say “run this in a loop,” what I mean is: set the objective as a written commission, fork the execution into waves, join at the gates, ship only what passes, and let the retro refine the next objective. Session inside sprint inside program, each running the same grammar with the same start and the same end. The agent does the laps. My job is to design the track, hold the gates, and decide what a lap is worth.

That is the whole trick. There is no prompt.

References

I felt it when I walked into the kitchen of a new house and tried to make a dish. I struggled with the idea so much that I left the recipe in the fridge and waited until I got back to my own house.

The moment I was home, I wanted to make it. Everything was clear. Where the pots were. Where the pans were. The gas. How to get it all running. It was smooth. I made the dish I wanted, and I ate.

Meanwhile the nice vacation house we were renting, as much as I loved it, was hard to cook in. Because there was a butler.

Even when I decided I wanted to cook for myself, even after I had gone to the supermarket and bought the ingredients, I just couldn’t. I kept the items in the fridge and called the butler anyway, and asked him to make the food he already knew how to make. Because he couldn’t make my indigenous, home cooked meal.

And I realized that is kind of like AI for you right now.

You have a butler, in an expensive vacation house that you are renting.

Luckily, the butler is very good. He can make a lot of dishes. Even the ones we’ve quietly converted into our own special home dishes.

But here is the challenge. We may never enter the kitchen. We may never do inventory. We may never walk into the pantry again.

Because if, for some reason, we decide we should be in the kitchen, we’ll realize we have to figure out what kind of gas this house uses. How to work with ceramic pans instead of the ones we know. How much heat we actually want under our food.

The butler is so good he can get you your dish in five minutes, as long as you understand exactly what it is you really want to eat.

And then I think: this is the life of the AI software engineer. The forward deployed engineer.

So maybe we don’t fight it.

Maybe what we really need is to give the engineer an outlet. A way to always go back to his own house, the one he built himself, and make a dish every now and then. As a vacation. As a hobby he genuinely loves.

Because there is a butler now, and the butler does it so well. He doesn’t need to worry about making food anymore.

But just like a vacation, cooking becomes the vacation.

As long as he can afford to rent the vacation house, or something like it, or his company is willing to rent it for him, he is okay. And when he is not working, he can go home and make food for himself.

Which is why I think the only move right now, for every forward deployed engineer, is to keep one side project you write code for with your hands.

One side project that doesn’t really have customers, apart from you and a few friends.

And you just write the code by hand.

Actually, no.

AI stole my notepad.

For years, I was the kind of person who cared far too much about pens.

Not just any pen. Felt tips. Fine liners. Gel pens. Rollerballs. Fountain pens when I was feeling dramatic. Ballpoints only when I had no choice. Purple ink for thinking. Blue for everyday notes. Black for permanence. Red for arguments with myself. Every pen had a personality, and every one made writing feel just a little different. Oil based ballpoints dragged across the page with intention. Gel pens glided. Rollerballs flowed. Felt tips whispered. Fountain pens demanded you slow down. Writing was never just writing, it was a physical experience.

People who knew me knew exactly what to buy me.

Notebooks.

They were one of my favorite gifts because they were guaranteed to be used. Some people collect watches or sneakers. I collected blank pages.

Every notebook eventually became a time capsule. Meeting notes. Half finished essays. Business ideas. Random observations at 2 a.m. Sketches that made sense only to me. Lists I never came back to.

I still have them.

Scattered across boxes, drawers, backpacks, some tied together, some sealed in ziplock bags, quietly preserved like little archaeological sites of previous versions of myself.

The funny thing is, I recently opened one of my bags and found my pen collection.

Almost untouched.

It hit me that we’re already halfway through the year, and I’ve barely used them.

Normally, around this time, I’d already be shopping for replacements because I’d lost a few, finished the ink in others, or convinced myself I needed another color.

This year?

Nothing.

So I asked myself a strange question.

Where did all those thoughts go?

Where are all the ideas I used to scribble down before they disappeared?

Then it clicked.

They’re in the chat box.

Claude has them.

ChatGPT has them.

Somewhere across dozens, maybe hundreds, of conversations, my thoughts are still there.

The instinct hasn’t disappeared.

The destination has.

Now, when I have an idea, I don’t reach for a notebook.

I open a chatbot.

The thought survives.

Sometimes it even comes back better than it went in.

But something else quietly disappeared.

With notebooks, memory had geography.

You knew where things lived.

You remembered that an idea was somewhere near the middle of the notebook. That conversation was written close to the back, around the same week you were obsessed with another project. You’d flip through pages, accidentally rediscovering thoughts you’d forgotten you ever had.

The notebook didn’t just store ideas.

It stored time.

Chat histories don’t feel like that.

They’re searchable, but they aren’t memorable.

Everything exists, but nowhere in particular.

My journal became a search box.

Maybe that’s progress.

Maybe this is simply what living at the edge of a technological shift feels like. We don’t notice the replacement because the new thing works so well. One day you realize the object isn’t gone.

The habit is.

I’m not worried.

At least, not yet.

I just find it fascinating that one of the oldest rituals I had, reaching for a pen whenever a thought arrived, quietly disappeared without me ever deciding to stop.

The pens are still here.

The notebooks are still here.

They just aren’t where my thoughts live anymore.

We dressed it up. Story points. Epics. Engineering hours. Complexity estimates. Sprint capacity. Underneath every planning ritual sat one equation.

More work equals more people, more time, or both.

AI has quietly broken that equation. Not because software suddenly became easy to build, but because the constraint moved.

Working faster was the wrong explanation

The first few times I built products with AI agents, I assumed I was simply working faster. After enough projects, that explanation stopped holding.

A feature that would have taken a week now took hours. An entire sprint’s worth of implementation stopped feeling materially different from a single feature. Expanding the scope barely changed the delivery date. Instead of asking “can we fit this into the sprint?” I kept asking “why not build the whole thing?”

That question forced me to rethink what scope actually means.

The old model was linear

Traditionally, software delivery was constrained by production capacity. Every additional feature was additional engineering effort. More code meant more implementation time. Scrum, Kanban, and most delivery frameworks were built on that reality. Story points became rough proxies for engineering hours because human effort was the dominant variable.

You can write the old model as a sum. Delivery was the total of the work:

delivery time ≈ Σ (task time)

Double the scope and, give or take, you doubled the time. Linear scaling. You cannot simply add people to make a late project ship sooner.¹

AI made implementation parallel

AI changes the relationship. Implementation has become massively parallel.

Instead of one engineer moving through tasks one after another, dozens of specialized agents work at once across the system. Authentication, APIs, frontend components, database migrations, documentation, tests, infrastructure, all progressing simultaneously.

So generation stops behaving like a sum and starts behaving like a maximum:

generation time ≈ max (task time)

If ten agents each take one feature, they finish around the same wall-clock moment. The limiting factor is no longer the amount of work. It is the longest branch of work.

That is a very different optimization problem, and it is not a new one. It is the mathematics of parallel execution: critical-path analysis, Brent’s theorem, the difference between the total work and the longest dependent chain.²

The human didn’t disappear. The human moved.

Here is the catch the speed story misses. You don’t remove the person. You relocate them.

No matter how many agents generate code, a senior engineer still reviews the architecture. Someone still validates the business logic. Someone still performs user acceptance testing. Security still signs off. Product still decides whether the implementation solves the problem.

Those activities refuse to scale at the rate generation does. So the equation becomes something like:

delivery ≈ AI generation + human verification

where generation trends toward a near-constant and verification dominates.

Ironically, the faster AI becomes at producing software, the more valuable human judgment becomes. Anthropic’s study of roughly 235,000 Claude Code users found exactly this shape: domain expertise, not a software-engineering background, predicted who got good outcomes, and when a session hit trouble novices abandoned it about three times as often as experts.³ The bottleneck didn’t vanish. It moved to the person who knows what “correct” looks like.

This is Amdahl’s Law wearing a new hat

If you have ever studied parallel computing, this will feel familiar. Amdahl’s Law says a system speeds up only as much as its sequential bottleneck allows.⁴ You can parallelize the parallel part all you want; the serial remainder sets the ceiling.

Coding became parallel. Review did not. Testing partially did. Architecture partially did. Acceptance did not at all.

So throughput stops being a function of total work and becomes a function of the sequential work:

speed ≈ 1 / sequential work, not 1 / total work

Google’s own research on scaling agent systems lands in the same place from the other direction: piling on more agents hits a ceiling and can even degrade results, because coordination (merging, reconciling, and validating parallel output) carries its own tax.⁵ More agents is not more delivery. Past a point, it is just more to verify.

Delivery is starting to look like a distributed system

This reminds me less of traditional software engineering and more of distributed computing. Distributed systems rarely spend most of their time executing work. They spend it coordinating, synchronizing, validating, and merging parallel execution.

AI-generated software increasingly behaves the same way. The hard part is no longer generating code. It is merging confidence.

Which is why the 2025 DORA report reads the way it does. AI adoption is nearly universal and most developers feel faster, yet a large share still don’t trust the code the models produce, and the teams that actually benefit are the ones with strong internal platforms, clear workflows, and real review discipline.⁶ AI amplifies the system it lands in. If your verification is weak, faster generation just gets you to the bottleneck sooner.

Scope compression

Put it together and you get something worth naming. Call it the Scope Compression Hypothesis:

As software implementation becomes parallelized by AI agents, delivery time becomes increasingly independent of implementation scope and increasingly dependent on fixed human verification cycles. Productivity shifts from being creation-limited to approval-limited.

Scope is compressing. Not in the sense that projects get smaller, but in the sense that ambitious projects converge toward similar delivery timelines. Whether the backlog holds three features or thirty, the dominant cost is often no longer writing the software. It is building enough confidence to release it.

Our planning systems haven’t caught up. Sprint planning, estimation ceremonies, capacity planning, resource allocation, all of it still assumes implementation is the expensive part. That is why so many AI-assisted teams report that estimation has gone strangely unreliable. Estimation isn’t getting worse. The variable we spent decades measuring is simply no longer the one that determines delivery. This is the same lesson the SPACE work taught about productivity: the moment you collapse a multidimensional reality onto a single proxy, you start making decisions on the wrong number.⁷

What the best teams will optimize for

If this holds, software organizations will eventually stop optimizing for engineering capacity and start optimizing for verification throughput. The question moves from “how much can we build?” to “how much can we responsibly approve?”

The highest-leverage engineers will not be the fastest builders. They will be the fastest validators. The best engineering organizations will not be the ones that generate the most code. They will be the ones that approve the most change with the highest confidence.

That feels like a subtle distinction today. I suspect it becomes one of the defining characteristics of software engineering in the AI era.

A reading list

A friend sharpened most of this thinking while we argued about it, and he handed me a syllabus on the way out. Here it is, roughly the order I’d read it in.

Foundations

• The Mythical Man-Month, Frederick Brooks: why adding people doesn’t linearly shorten a project.¹
• Peopleware, DeMarco & Lister: productivity as a human system, not a coding-speed problem.⁸
• Accelerate, Forsgren, Humble & Kim: the DORA research on what actually drives delivery performance.⁹

Parallelism

• Amdahl’s Law and Gustafson’s Law: the ceiling on parallel speedup, and the counterargument.^{4 10}
• Critical Path Method and Brent’s theorem: total work versus the longest dependent chain.²
• Fork-join parallelism and MapReduce: how systems split work, then merge it.¹¹

Modern AI engineering

• DORA, 2025 State of AI-assisted Software Development.⁶
• The SPACE of Developer Productivity.⁷
• Google, Towards a Science of Scaling Agent Systems.⁵
• Anthropic, Agentic Coding and Persistent Returns to Expertise.³

If I had to compress the whole argument into one line: AI turned estimation from a production problem into a verification problem, and most of our planning is still answering the old question.

References

The idea seemed straightforward. If every decision, project, conversation, customer interaction, and lesson learned could be captured in a single cognitive layer, the organization would become smarter over time. Instead of knowledge being trapped inside departments, teams, documents, and individuals, it would accumulate into one shared repository. A kind of digital cortex for the company.

The more I worked on second-brain architecture, especially for organizations, the more I realized something surprising. The hard problem isn’t knowledge. It’s interpretation.

What language models actually do

Most discussion around AI assumes language models understand meaning the way people do. At the mechanical level, that isn’t what they are doing. A language model trained with a next-token-prediction objective generates the most probable continuation of a sequence based on patterns learned during training.¹ It is extraordinarily good at this, good enough that the output is easy to mistake for understanding.

Set aside whether that counts as understanding. People argue it hard in both directions, and it is a genuinely interesting argument,²³ but it is not the one that matters here. Whatever is happening inside the model, the final act of interpretation happens outside it. When a model produces text, the person reading it constructs the meaning. The same words mean different things to different people. That was true long before language models existed, and it is true now.

This is not a new observation about machines. It is an old observation about reading. Reader-response theory has argued for over half a century that meaning is not fixed inside a text but is constructed in the encounter between text and reader. Louise Rosenblatt described a text as ink on paper until a reader evokes a work from it.⁴ Wolfgang Iser described texts as full of gaps that the reader fills.⁵ Stanley Fish located interpretation in communities of readers who share assumptions and strategies.⁶ A language model gives this old problem a new surface, because now the text is generated on demand, but the structure is identical: the reader makes the meaning.

Organizations run on interpretation

One advantage I’ve had throughout my career is sitting between stakeholders and engineering teams. Spend long enough in that seat and you stop writing one document. You start writing two.

For almost every significant initiative, I maintained parallel documentation. One version for engineers, focused on systems, implementation, constraints, dependencies, and execution. One version for stakeholders, focused on outcomes, risks, goals, timelines, and business impact. The underlying reality was identical. The interpretation was different.

This wasn’t a communication problem. It was an interpretation problem, and organizations have always known this even when they rarely articulate it. What you write in an investor memo differs from a customer update. A board presentation differs from a technical specification. What you tell engineering differs from what you tell sales. Not because anyone is lying, but because different audiences derive different meaning from the same information.

This is the core of Karl Weick’s account of organizations as sensemaking systems. Weick argued that organizations don’t simply process information; they organize to reduce equivocality, the condition where the same data admits multiple valid readings, and to build shared meaning so the group can act collectively.⁷ A single fact does not carry a single meaning into an organization. Revenue dropping eight percent means protect cash to the CFO, retention is failing to the product lead, is this even caused by the product to the engineer, and is growth slowing permanently to the investor. The fact is identical. The interpretations diverge by role. Equivocality is not a bug in the org; per Weick it is the engine that forces the organization to organize in the first place.

Translation

Historically, organizations solved this through layers. Managers, product managers, directors, and leaders each reinterpreted information for the next audience. Information wasn’t passed down so much as transformed at every level.

That transformation is expensive, and it is lossy. Information degrades and distorts as it moves up through the layers, and some of the distortion is deliberate, people screening out what makes them look bad on the way up, especially where trust is low.⁸ Think of each management layer as a bottleneck that compresses whatever passes through it, throwing away detail to fit the attention budget of the level above.⁹ Layered human translation was never free. It was a cost organizations paid because they had no alternative.

Now AI is collapsing those layers. Founders, engineers, customers, and investors can each query systems directly. The distance between the person with the idea and the people implementing it is shrinking fast, and many traditional translation roles look like they are disappearing.

The reality is more interesting. The translation function isn’t disappearing. It’s moving. The engineering team still needs engineering language. Customers still need customer language. Investors still need investor language. The need never went away. Only the mechanism changed.

Facts, judgment & interpretation

A single repository of information sounds elegant. A single interpretation does not. Because, following Weick, organizations operate on shared interpretations of information, not on information alone. So a company brain cannot just be a database of facts. It needs three layers.

Facts. Raw observations: sales numbers, customer interviews, meeting transcripts, product specs, decisions. This layer should be audience-neutral, a source of truth.

Judgment. The decisions that were made, the tradeoffs accepted, the principles that guided them, the preferences that emerged over time. This is the organization’s accumulated reasoning and taste, its institutional memory. Most organizations fail to capture this layer at all, which is why it walks out the door when experienced people leave.

Interpretation. The projection of that judgment into the form a specific audience needs. A single judgment, “we are prioritizing reliability over feature velocity this quarter,” becomes freeze feature work and cut incidents for engineering, stability and performance improvements are our focus for customers, and we are strengthening operational foundations for sustainable growth for investors. Same judgment, different valid renderings.

Maybe a compiler

This suggests a company brain shouldn’t be a single flat repository. It should behave more like a compiler.

A compiler starts from one source and generates different outputs for different targets. An organization can work the same way: one canonical layer of facts, one canonical layer of judgment, and many audience-specific interpretations generated from that shared source. The engineering version, the customer version, the investor version, all derived from the same underlying reality, all synchronized because they share an origin.

This directly attacks a problem organizations have fought for decades: documentation drift. Maintain separate documents by hand and they diverge. The engineering doc says one thing, the stakeholder doc another, the investor memo a third, and eventually nobody knows which is true. Generate every rendering from one judgment layer and the single-source-of-truth discipline that software already relies on becomes available to organizational communication.

The metaphor has a crack in it, and the crack is the interesting part. A real compiler is faithful by construction: the output means exactly what the source means. An LLM rendering judgment into an investor narrative makes no such promise. A generated customer update can be fluent, on-brand, and quietly false, and nothing in the architecture guarantees it still says what the judgment beneath it says. The compiler idea fixes the drift between the versions, because they share a source. It does nothing for the fidelity between any one version and the truth it came from. That gap, whether a translation carries the judgment honestly or quietly bends it, is the real frontier, and it is wide open.

What this changes

This changes how I think about AI as well.

I increasingly suspect that the language model is not the company brain itself. It is the interpretation layer through which the company’s accumulated judgment is expressed. The actual brain is the accumulated repository of knowledge, decisions, tradeoffs, principles, preferences, and institutional memory. The model renders that judgment into forms different audiences can understand, and that rendering is not a trivial step. It is where most of the organizational value and most of the risk concentrate, which makes it the layer that most needs governance, not the least.

The future challenge may not be building systems that know everything. Knowledge is becoming increasingly abundant. The harder challenge may be preserving coherent organizational judgment while generating multiple interpretations for multiple audiences, keeping those interpretations synchronized, and verifying that each one still tells the truth of the judgment beneath it.

That feels much closer to the real problem. Not how to build a company brain. But how to build a company’s shared judgment, continuously translate that judgment into language every part of the organization can understand, and prove the translation didn’t lie.

References

Because here is what I am watching happen across companies right now. Everyone has agents in production. They are qualifying leads, writing code, generating ad creative, closing support tickets. They are burning real money doing it.⊕I have started counting the silence in these meetings. The pause after “did it work” is the most honest signal in the entire AI economy right now. And when someone finally asks the only question that matters, did this make us anything, the room goes quiet.

I wrote this as a builder’s brief, an idea I would chase if I had the cycles. But it is really about something I have said before. In AI-native work, activity is cheap and visible, and outcome is the only thing that survives a budget review. The company hiding inside that gap is a measurement company. Here is the full shape of it.

The problem

A company builds an AI agent that qualifies inbound leads. It runs every day. It touches hundreds of prospects a week. It costs real money in API calls, infrastructure, and engineering time.

At the end of the quarter, the CFO asks: did it work?

Nobody can answer. Not the CTO, not the VP of Sales, not the team that built it. They can tell you how many tokens it consumed. They can tell you the average latency. They cannot tell you whether it generated a single dollar of revenue.

This is not a small-company problem. It is the default state of nearly every organization deploying AI agents today.

Fewer than 1 in 100 enterprises report significant returns from their AI spend. The single biggest obstacle they name is measuring the return at all.Forbes Research, 2025 AI study. Less than 1% of executives report ROI of 20% or more; 39% name measuring ROI and business impact as their top challenge. The gap between spend and proof is the whole thesis in one statistic.

Pressure for financial proof has landed squarely on finance leaders. Nearly half of CFOs now say they are ultimately accountable for ensuring AI delivers measurable value, yet most enterprises still grade AI on operational terms like efficiency rather than dollars.CFO.com, 2025. 48% of CFOs say they own AI accountability; CFO involvement in AI governance jumped from 1% to 38%. They are on the hook for a number they have no tool to produce. They are on the hook for a number they have no tool to produce.

MIT found 95% of enterprise generative AI pilots deliver no measurable impact on the P&L.MIT NANDA, The GenAI Divide (2025), via Fortune. Only about 5% drive real revenue acceleration. Many of the other 95% may be working fine. Nobody can prove it. Gartner predicts over 40% of agentic AI projects will be canceled by the end of 2027.Gartner, June 2025. The same release projects agentic AI in 33% of enterprise software by 2028, up from less than 1% in 2024. Adoption and cancellation rising together is exactly what a missing measurement layer looks like. The primary cause in both cases is not that the AI stopped working. It is that nobody could prove it was working in the first place.

This is a measurement problem. And measurement problems have software solutions.

Why this market, why now

The timing argument is specific, not generic. Three conditions converged in 2025 and early 2026 that did not exist before.

Agents moved into production at scale. Gartner expects agentic AI in a third of enterprise software by 2028, up from less than 1% in 2024. That is not a forecast curiosity. It is the creation of a market. You cannot sell ROI measurement to a company running zero agents in production. That was most companies eighteen months ago. It is rapidly becoming a minority position.

The budget scrutiny arrived. The first wave of enterprise AI adoption ran on goodwill and novelty. The budget renewal cycle is now completing its first full loop. CFOs who signed off on AI spend in 2024 are being asked to sign off again with one more requirement: show results. KPMG watched the share of leaders struggling to realize AI ROI roughly double in a single quarter, from 33% to 65%.KPMG AI Quarterly Pulse Survey, 2025. A near-doubling in one quarter is not a trend. It is a phase change. The pain is acute and recent.

The analogy market already proved the model. Mixpanel answers a simpler question, did users engage, and reached roughly $210M ARR at a $1.1B valuation. Amplitude, which adds predictive analytics, went public and reached $312M revenue in 2024.Reported figures via Contrary Research (Mixpanel) and Latka (Amplitude). Both built nine-figure businesses answering an easier question than the one in this brief. Your question, did this agent generate revenue, is harder to answer, more directly tied to budget decisions, and has no incumbent. The comparable ceiling is materially higher.

Here is the market in numbers.

What exists today, and what it misses

The current landscape of AI observability tools is not your competition. They are your upstream suppliers. The distinction matters for how you position and how you build.

Every tool in that table stops at the boundary of the AI system. They are excellent at telling you what happened inside the model. None of them cross into the business system, Stripe, HubSpot, Salesforce, Shopify, where outcomes are actually recorded.

That boundary is the product. You sit between AI observability and business systems and do the one thing that justifies or kills the budget: connect cost to outcome.

You don’t have to start from scratch

The open-source AI observability ecosystem matured dramatically in 2025. What would have required six months of instrumentation engineering eighteen months ago is now available as MIT or Apache 2.0 licensed infrastructure you can build on top of, not through.

This is the part most founders miss.⊕The instinct to build the foundational layer first is almost always the trap. The foundation is usually the commodity. The thing you actually sell sits one layer up. The instinct is to build the observability layer first because it feels foundational. The observability layer already exists and is free to use. Your job is to build the attribution layer above it.

Langfuse: Open-source LLM engineering platform

MIT-licensed core: traces, evals, prompt management, agent execution. Self-host or cloud, no usage caps. Gives you structured agent execution data and cost per trace.

langfuse.com

Portkey: AI Gateway (Apache 2.0)

Open-sourced its full gateway in March 2026: routing, guardrails, governance, MCP gateway. Processes 2 trillion tokens/day. Gives you structured cost and routing logs with custom metadata passthrough.

portkey.ai

OpenLIT: OpenTelemetry-native AI observability

Apache 2.0, SDK-based instrumentation with no proxy latency. Framework-agnostic, GPU cost tracking included. Gives you OTel-standard traces you can route into your own attribution pipeline.

openlit.io

Helicone: One-line LLM proxy

Apache 2.0. Custom properties via headers attach business context to every call. Note: in maintenance mode post-acquisition, viable for prototyping, not long-term infra dependency.

helicone.ai

The practical implication: you can instrument an entire AI agent stack for cost and trace data in a weekend using these tools, without writing a single line of observability infrastructure. All four allow commercial use, modification, and distribution.

What none of them provide, and what you build, is the downstream connector. The join from a run ID on an agent trace to the deal ID on a closed HubSpot opportunity. That join is where the product lives.

How to approach building this

The architecture is simpler than it appears because you are not building observability. You are building attribution. Observability captures what happened inside the AI system. Attribution connects that record to what happened in the business system.

The core data model

Everything hinges on one design decision made before you write a line of application code: every AI workflow execution must carry a run ID (call it workflow_run_id) that travels into the downstream business system. This is the join key. Without it, attribution is impossible. With it, attribution is a SQL query.

When an agent qualifies a lead, that run ID gets stored on the HubSpot contact. When the contact converts, the same ID comes back on the deal-closed event. You match it against the trace for that run, sum the token costs, and the ROI calculation is arithmetic.

Three tiers of attribution, built in this order

1. Direct revenue attribution. Agent runs, then a Stripe charge fires in the same session. The run ID is on both events. Deterministic, not probabilistic. Zero ambiguity. This is v1. Ship this and nothing else until five paying customers validate the thesis.

2. Influenced revenue attribution. Agent qualifies a lead on Monday. Deal closes three weeks later. The run ID must persist on the CRM contact between those two events. This is a data-modeling problem, not a statistics problem. Build HubSpot and Salesforce connectors that store and carry that ID automatically. This is v2.

3. Cost-saved attribution. Agent resolves a support ticket that would have cost $18 in human labor. No revenue event fires. You need the customer’s baseline cost-per-task, a configuration input, not a sensor. Capture their labor-cost assumptions in onboarding, multiply by deflection count. This is v3, and it unlocks the cost-center budget owners in finance and operations.

Integrations that unlock each segment

The integrations you build determine which companies can buy you. Build Stripe first, it covers every SaaS and e-commerce company running AI checkout flows. Build HubSpot second, it unlocks B2B sales teams running AI lead qualification. Build Salesforce third, it moves you into enterprise. Each integration is a new customer segment, not just a new feature.

What attribution looks like across verticals

The measurement problem is not abstract. It plays out concretely, and differently, across the agent categories running in production right now. Four are where the pain is most acute and the join between AI cost and business outcome is most tractable.

These four are not exhaustive. They are the ones with existing, structured event data on the outcome side, which makes attribution tractable without statistical inference. The event exists. The cost exists. You are building the join.

Finding your first sponsor users

Do not build a waitlist. Do not run ads. Find ten companies that match two criteria exactly: they have AI agents running in production today, and they have a budget review in the next 90 days.

The signal you want in the first conversation is not “that sounds interesting.” It is the pause before answering when you ask, do you know which of your AI workflows generated revenue last month? A pause followed by a deflection to token counts means the pain is real and they have no answer. That is your customer.

The best first segment is Series A and B SaaS companies that wired a model into their core product in 2024 and are now in their first board renewal cycle. They have the setup to instrument quickly, the pressure to act immediately, and the product sense to give useful feedback.

For the first five, charge nothing in exchange for weekly feedback, the right to use their case study anonymously, and a signed letter of intent to pay when you hit a specific milestone, for example showing them $10K in attributable revenue from a workflow they could not previously measure. That letter is your fundraising ammunition. For users six through fifteen, charge a flat monthly retainer. Not usage-based yet. The goal at this stage is signal, not optimization.

The business model, rough shape

Long-term, this prices on AI spend under management, the way cloud-cost tools price on cloud spend, or processors price on transaction volume. Call it 0.5 to 1% of tracked AI spend with a per-seat floor for dashboard access.

A company running $50,000 a month through agents pays $250 to $500 a month. When the dashboard shows $240,000 in attributable revenue from that spend, the renewal is not a conversation. It is a formality.

The secondary line is the CFO reporting package: exportable ROI summaries, board-ready slide templates, budget forecasting on attribution data. Low engineering effort, high perceived value, the kind of feature a CFO requests by name and a VP renews without procurement.

The one test before you build. Find someone running AI agents at a company with a real board. Ask them: at your last board meeting, did anyone ask what your AI spend generated in revenue? If the answer is yes and they had no answer to give, you have your first customer. If the answer is yes and they had a good answer, ask how they measured it, you have found a methodology to steal. If the answer is no, move to the next company. The board pressure is the forcing function. Without it, the pain is not acute enough to pay for a solution yet.

The leverage in this AI era is not in running more agents. Everyone will run more agents. The leverage is in being the one who can prove which of them earned their keep. That is a measurement company, and right now it does not exist.

Before, if you were a subpar employee, low rated, junior, non skilled, you could easily hide the fact that you were not skilled. You could hide behind other people’s work. You could show up to meetings while other people made up for your lack of skill, talent, capacity, or competence. You could survive because someone else was always absorbing the cost of your weakness.

Now, in organizations where everybody has to move fast, it is just so hard to bullshit your way through work again. You cannot bullshit your way out of an outcome because everyone already has a lot on their plate. They do not have time to keep looking over your work.

So you go to ChatGPT or Claude. You tell it what you think makes sense. It gives you an output. Then everybody on your team takes that output and brings it into their own stream of work, until everyone starts having the same conversation: at what point did the results we were supposed to deliver as a team regress?

And it all points to one place. It points to your output. It was your output that created the regression. It was the codebase you pushed. It was the PR that introduced those regressions. It was the document you shared, the presentation, the brief, the concept note, the deck. The thing you brought into the room because AI told you, “yes, this is correct.”

But you needed taste. You needed judgment. You needed the ability to discern what was behind the subtext. Because in business today, a simple statement like, “you can fill this part for me,” can mean more than what is written on the surface. It can mean, “use your judgment here.” It can mean, “you should already know what matters.” It can mean, “this part connects to something we discussed three weeks ago.” It can mean, “do not just complete the sentence, understand the context.”

So when your team is working on a test, a project, an idea, or an issue is flagged, you are not just supposed to read the main text. You are supposed to consider what is behind the text. Pattern recognition tells you that when someone says this, this is actually what it means in production. But you did not have that. So you took what Claude gave you, brought it back, and now everyone can literally see how incompetent you are. Everyone can see how underskilled you are.

And the worst part is this. If you are not doing anything to improve, and you think AI is making you deliver work faster, your name is probably next in line for elimination. Everyone is going to be quiet about it. But they all know it is going to happen. And when it happens, it will not be a surprise to anybody.

Now, that is the brutal part. But the more useful question is this: what does the remedy look like?

Because while incompetence is no longer an option, one of the other aspects of working like this today is that it is also hard to improve. No one has time to carry an apprentice along. No one has time to teach anybody anything. Everybody is moving fast across all workspaces.

So what does it look like for someone who actually wants to learn? What does it look like for someone who wants to pick up their slack in the age of AI? How do you build experience and expertise without relying on slop, especially when almost everything available to help you learn today also feels like slop?

That is the real challenge. AI can help you move faster. But if you do not have taste, context, judgment, and pattern recognition, it will not make you better. It will only make your gaps more visible.

And at work, in the age of AI, visibility is not always a gift. That is the new condition of AI native work. Everything moves faster. Everything is seen sooner. Everyone’s output is exposed to everyone else, almost in real time. In that kind of environment, being visible only rewards you if there is something worth seeing.

If you are competent, the speed carries you. The exposure works in your favor. Your judgment compounds in full view of the room. But if you are not, the same system that makes good work visible makes your gaps visible too. And it does it just as fast.

The image is beautiful. Green, purple, yellow, sitting in the middle of all that brown and dust. We photograph it. We put it in slide decks. We tell its story on panels.

Look what grew here. Look what was possible here.

But nobody asks the flower.

You know this person. The founder who always picks up. The builder who shipped through the funding drought, the team departure, the market that didn’t show up on time. The one who always looks like they’re handling it. The one you reference when you want to prove something can survive in a hard place.

From the outside, they look like a beautiful work of art.

Here’s the question nobody asks. What does the flower have to do every day just to stay green right here? How much water does it have to find on its own? How deep do those roots have to go before they hit something? When was the last time anyone checked whether the soil around it was actually giving anything back?

We’ve made it normal to assume that because something looks beautiful in a hard place, it must be fine. That the glow means it’s thriving. That standing means it isn’t tired. That the founder who keeps shipping is the founder who has it figured out.

That isn’t how flowers work. It isn’t how people work either.

The founder who never complains isn’t a founder with nothing to complain about. The builder who keeps shipping hasn’t figured out how not to feel the weight of it. They’ve just decided, or been conditioned, to make their difficulty invisible. Because the world only applauds the bloom. It never applauds the root system that’s quietly screaming underground.

The cost of being the proof

There’s a particular tax on the people we point at.

When you become the example, your difficulty becomes inconvenient. Nobody wants the flower in the desert to admit it’s exhausted, because the story is more useful if the flower is fine. The story funds the next pitch. The story justifies the panel. The story tells everyone else this is possible without subsidy.

So the flower learns to keep blooming on schedule. Not because it has to, but because too many people have built their narrative around its survival.

That isn’t resilience. That’s performance with no exit.

Go check on the flower.

Not to take a photo. Not to reference it in your next talk about resilience and what’s possible when you refuse to quit.

Go check on it because it’s a living thing. And living things in hard conditions need more than admiration to survive.

Ask the real question. Not “how is the company doing?” That’s the wrong question, and they have a polished answer for it. Ask how they’re sleeping. Ask what they’ve stopped doing in the last six months that used to keep them whole. Ask whether they have anyone in their life right now who isn’t also depending on them to keep going.

Then wait for the real answer. Most flowers won’t say the thing on the first ask. The bloom is the brand now. Saying anything else feels like a contradiction of the story everyone needs them to keep telling.

But if you wait, the truth shows up. And once it does, you don’t have to fix it. You just have to not flinch.

That’s the whole job. You aren’t there to rescue the flower. You’re there to remind it the desert isn’t the only audience.

It isn’t who you think. Or maybe it is.

My new product manager would have been Claude, if Claude was smart enough to be my product manager. But it isn’t.

My new product manager is the already-existing product manager who uses Claude.

That distinction is the whole essay.

The challenge isn’t just who can write tickets, or who can manage a roadmap. The challenge is that this person also has to be the custodian of the product vision. And that’s why being a product manager is no longer enough.

What building looks like right now

If you have an idea, and you can write a clear PRD — what success looks like, what the functional requirements are, what the non-functional requirements are — you can get that app built in a day with the right AI tools. Maybe in hours. The day is me factoring in reviews.

One person with five custom-made AI agents can build almost anything, if the pipeline is right. Linear. Slack. GitHub. Claude Code. ChatGPT. MCP. The whole system.

So my product manager has to be someone close enough to understand the product vision. But that person isn’t going to look like the product manager we know today.

They need to understand what the customer wants. They need the bandwidth to do a complete user test on every freaking new feature. They need to be able to talk to Claude about the codebase.

Traditionally, product managers didn’t need to be close to the code. Now they do.

Product managers need to know where the codebase is. They need a GitHub account. They need access to Google Analytics, Segment, Mixpanel, and every other place where the product is quietly telling the truth. They need to be in direct conversation with stakeholders. They need to be in the sales calls. They need access to the meeting notes. They need to know what customers are saying before the roadmap becomes a museum of old assumptions.

The PM as decision maker

The product manager today is the person who can decide where the product is going.

They can make a hard pivot today. They can say “this is what we’re doing now,” and the entire product motion changes around it.

When a feature ships from the design and engineering team — aka me and five other agents — the product manager is going to vet it. Test it. Document their expectation from the new feature that shipped six hours ago.

While that’s happening, they’re also in three or four sales calls with the BD team. They’re tracking user behavior. They’re reading analytics. They’re synthesizing feedback. They’re turning chaos into the next thing we should build.

To make this concrete: I ship two different builds every six hours. That means the product manager is supposed to tell me what I’m working on tomorrow.

Today, I can get my agent to synthesize all the feedback and ship. Then have the agent synthesize the next round of feedback and ship again. By the time I wake up tomorrow, my product manager should already have something new for me to cover as basis. Because they just synthesized customer feedback. They just ironed out a workflow. They just had a call with a potential customer. They found something that needs to be reviewed.

The PM also uses Claude

Here’s the thing. The product manager isn’t going to manually write everything I need to do.

They’re going to use Claude. They’re going to use ChatGPT. And not inside a cute chatbot window. I mean a fully integrated workflow. Agentic ChatGPT with Dispatch or Remote Control. Claude Code. Claude CoWork. MCP. CLI. Connected tools.

Their work isn’t just planning. Their work is using MCP to read Google Analytics. Using MCP or the CLI to read GitHub. Finding out what I just pushed across all the codebases. Synthesizing design — because we no longer have to design only in Figma. A lot of that can now happen in Pencil.

While that’s happening, the product manager is joining calls with stakeholders, connecting Granola to those calls, giving Claude all the context it needs from Granola, and breaking down what I need to do next in order to move forward.

So when the product manager gives me a new breakdown, it’s fully contextual. All I have to do is move. Write the code. Verify the code works. Run the tests. Run the security suites. Ship.

The Holy Trinity

In a way, it almost feels like the product manager could build the entire thing.

But in the real world, the scalable pattern is simpler. One product manager. One super-talented engineer. That might be everything you need to ship world-class products.

Teams are going to transition toward this. One product manager and one super-talented engineer become the core product unit. Outbound is left for the people who run outbound. The face of the company becomes the person doing TikTok, marketing, videos, dev rel, community, storytelling, distribution.

So a company today can be three people.

One product manager, who is really an operator. One engineer, who is really a full-stack, end-to-end builder. One face of the brand, who goes out there, talks to people, creates content, drives engagement, and brings everything back into the business.

That’s the new Holy Trinity. Product operator. Engineer. Distribution.

I don’t buy the one-person billion-dollar business idea. But I can buy the three-person billion-dollar business.

“When you people say this is this, what does that mean?”

“When you say this is that, what does that mean?”

Those questions were the signal.

From a management point of view, that is how you checkpoint the progress of new talent on a team, or someone finding their footing in a new department. The stupid questions gave you visibility. They showed you where the person was confused, what they were picking up, and how far along they really were.

We do not get them anymore.

Not because people stopped being confused. People still get confused. They still join teams and feel overwhelmed by context they do not yet have. They still hit the gap between what they know and what the work demands.

The difference is where they take the confusion.

They paste the wiki into ChatGPT. They paste the Slack thread into Claude. They describe the codebase to Gemini and ask it to explain what they are looking at. The questions still happen. They just happen in private, with a machine that never judges them for asking.

And honestly, you cannot blame them. Asking a lead or a senior teammate “what does this mean” carries social cost. It always has. Nobody wants to be the person who does not get it yet. AI removed that cost entirely. You can ask the dumbest possible question, five different ways, at 2am, and nobody on your team will ever know.

So the questions went underground.

The visibility problem

This changes something fundamental about how teams work.

When a new hire used to ask you why the billing service talks to two different databases, that question told you three things at once. It told you they had gotten far enough to find the billing service. It told you they did not yet understand the data architecture. And it told you they were actively trying to close the gap.

That was free signal. You did not have to schedule a check-in to get it. It just surfaced naturally because asking humans was the only option.

Now the signal is gone.

Instead, six hours before the deadline, or twelve hours before the deadline, you receive the first output. And while output is a good thing, it is also a coin flip. They might get it right. They might get it wrong. You have no way to tell which one is coming because you never saw the confusion that preceded it.

And when someone asks no questions and delivers polished output, you cannot tell the difference between someone who deeply understood the work and someone who got lucky with a prompt.

Both look the same on the surface. Clean deliverable. On time. Formatted well. Hits the brief. But one of them built understanding along the way and the other one outsourced the understanding to a machine and shipped whatever came back.

That is a risk. Because the moment the work gets harder, the moment the context is too specific for a general model to handle, the person who built real understanding will adapt. The person who did not will break. And you will not know which one is which until that moment arrives.

This is not a plea to ban AI from onboarding. That ship has sailed and it should have. AI is genuinely useful for bridging knowledge gaps, and pretending otherwise is not a strategy.

But it does change the job of leadership.

You have to assume you are not going to get the stupid questions. You have to design around that assumption instead of hoping people will still come to you with their confusion.

You can no longer wait until the final stretch to see the work for the first time.

That means compressing delivery into shorter feedback cycles. Not one big checkpoint at the end. Multiple small ones throughout.

Early output, before anyone has had time to polish or over-rely on generated answers. Review and correction, where you can see the shape of someone’s thinking while it is still rough enough to be honest. Iteration and improvement, where the work gets better because you shaped it together rather than received it finished.

Each checkpoint gives you a chance to see where someone actually is instead of where their output suggests they are. It is more work. It is also the only way to replace the signal that the stupid questions used to give you for free.

What we actually lost

The stupid questions were never just a management tool. They were a relationship. Someone admitting they did not understand something yet, and someone else helping them get there. That exchange built trust. It built context that no wiki can replicate. It built the kind of team knowledge that lives in people, not documents.

AI is better than any tool we have ever had for closing information gaps. But information gaps were never the only thing the stupid questions were closing.

I still miss them.

Your cofounder asks the same model. Also solid. Your board member runs it through a different prompt. Same conclusion. Your teammate asks from a different angle. Still holds up.

Four people. Four conversations. One brain.

Most of us are using the same LLMs, or at least models trained on roughly the same corpus, shaped by similar safety layers, similar incentives, and often a similar worldview. The outputs look different on the surface. Different wording, different examples, different tone. But underneath, they’re pointing in the same direction.

And that creates a bug.

Today, people use AI for almost everything. Advice, research, understanding new topics, pressure testing ideas, making decisions. Often, that makes sense. Especially when you’re entering a domain where you don’t yet have enough context or expertise to think clearly on your own. That’s exactly when an AI system feels most useful.

But here’s the problem.

What happens when I bring an idea to AI, especially an idea that depends on a certain worldview to make sense, and I use that system to help me shape it, challenge it, or validate it?

Then my teammate does the same. Then my board member does the same. Then my cofounder, partner, or friend does the same.

The wording will differ. The examples will differ. The style of explanation will differ.

But very often, the conclusion will be almost identical.

Not because the idea is necessarily right, but because everyone is querying the same layer of intelligence, trained on the same patterns, rewarded toward the same kind of coherence, and biased toward the same kind of acceptable answer.

So what looks like independent validation may actually be consensus laundering.

It feels like multiple people have pressure tested the idea from different angles. But maybe they haven’t. Maybe they’ve all just asked the same machine to think from slightly different seats at the same table.

That’s the bug.

Counterarguments start becoming a luxury. Real epistemic friction becomes rare. And the more persuasive these systems get, the easier it becomes to confuse fluency with truth. Or alignment with rigor.

This matters more than people think.

Because in teams, in companies, in decision making environments, we often don’t need perfect certainty. We just need something that sounds reasonable enough for everyone to move forward. Once AI can produce that level of reasonable coherence for everyone in the room, bad ideas travel further simply because they meet the minimum standard of collective comfort.

Not truth. Not depth. Not real challenge.

Just enough sense to pass.

So the question isn’t only whether AI can help us think.

The question is how we avoid thinking inside a closed loop where the same machine keeps reflecting the same assumptions back to all of us, until agreement feels like evidence.

Maybe the next skill isn’t better prompting. Maybe it’s designing for disagreement.

Seeking out people with real domain knowledge. Stress testing ideas outside model consensus. Using different systems with different priors. Separating “this sounds right” from “this survives serious opposition.”

Because if we’re all using the same intelligence to validate the same ideas, then sooner or later, agreement stops being useful.

It becomes a mirror.

It is the conversation that got you there.

What you asked. What you asked next. What you ignored. What you circled back to. Where the draft broke and how you fixed the framing. Why you went left instead of right when both directions looked fine.

That trail is worth something.

And right now, you close the tab and it disappears.

I think that is about to change.

A quick primer

For most of the internet’s history, the valuable thing was information itself. Someone knew something you did not. They wrote it down, recorded it, organized it into modules, and charged you for access. That was the entire digital product economy for over a decade. E-books. Video courses. Membership sites. Masterclasses. The person who knew the thing sold the knowing.

Courses were the pinnacle of that era. Not because they were the best way to learn, but because they were the most natural way to package expertise for sale. You take what is in your head, you structure it into lessons, you put a price on it, and you scale it infinitely because delivery costs nothing.

That worked. It still works. But it stopped being the only game.

Because at some point, people realized they did not just need information. They needed structure. They needed the thinking already done, the system already built, the workflow already laid out so they could skip straight to doing.

That is when templates took over. Notion made an entire economy out of this. People were not buying empty pages. They were buying someone else’s organized way of thinking. The information was already free by then. Google had taken care of that. The structure was the product.

Airtable bases. Figma kits. Spreadsheet models. Prompt libraries. The whole template marketplace era was built on one insight: people will pay to skip the organizing step.

That era is still running. But I think the next layer is already forming and most people have not named it yet.

Your Claude sessions. Your ChatGPT conversations. Your Codex workflows. Your cloud coding sessions. The actual working trails you leave behind while you build, write, design, edit, debug, research, decide.

Those are becoming a product category.

Not because someone is going to sit down and read your transcripts.

Because someone is going to feed them to their agent.

The buyer is not a student. The buyer is an agent.

This is the part that changes the economics.

When someone buys a course, the human has to do the work. Watch the videos. Take the notes. Try to apply it. Forget most of it. Go back and rewatch. The transfer cost is enormous. Most people never finish. Everyone knows this.

When someone buys a template, the transfer cost drops. Duplicate and go. But a template is frozen. It captures one arrangement at one moment in time. It does not show you what to do when the template does not fit your situation.

A session library is a different kind of product because the end consumer is different.

The consumer is not a human trying to learn.

The consumer is an agent trying to perform.

Think about what that means. An agent does not need motivation. It does not need the six-hour preamble before the useful part. It does not need to be convinced. It needs context. It needs examples of how decisions were made, what was tried, what worked, what did not, and why the approach changed.

That is exactly what your working sessions contain.

The first prompt that missed. The second one that got closer. The pivot when you realized the framing was wrong. The moment the whole thing clicked.

A human reads that and maybe learns something. An agent reads that and starts performing differently. It pattern-matches against your judgment and begins producing work that reflects it.

That is the difference. A course hopes the human will internalize it. A session library lets the agent absorb it directly.

What actually disappears when you close the tab

You finish a session. You got the output you needed. You close the tab.

What just vanished?

Every decision you made along the way. Every dead end you navigated out of. Every moment where you chose one direction over another and the choice was informed by something you know but never wrote down.

That is judgment. And it is the scarcest thing in the entire AI workflow.

Output is getting cheaper every month. Models get faster, cheaper, more capable. The cost of generating text, code, designs, analysis, all of it is falling.

But the cost of knowing what to generate, what to throw away, what to push further, and when to change direction entirely? That has not moved.

That judgment lives in your sessions. Not in the final deliverable. Not in your portfolio. In the messy, real, unpolished working trail where the actual calls were made.

If you curate that trail instead of discarding it, you have something.

What a session library actually is

It is not a transcript dump. That would be useless.

It is a curated archive of working sessions organized by domain, by problem type, by workflow pattern. Think of it like a reference library, but instead of books, the units are real conversations where real work happened.

A developer who has spent six months building production systems with Claude has hundreds of sessions. Architecture decisions. Debugging workflows. Refactoring strategies. Deployment patterns. Edge cases that only show up in production. All of it real. All of it showing what actually worked and what did not.

Now imagine another developer who is earlier in that process. They do not need a course on prompting. They do not need a template for a system design doc. They need their agent to already understand how a more experienced developer thinks through these problems.

They subscribe to the session library. They point their agent at it. And now their agent is not starting from zero. It is starting from someone else’s accumulated decision-making.

That is not “teach me.” That is “make my tools smarter.”

Same thing applies to designers, editors, strategists, researchers. Anyone whose work increasingly happens in conversation with AI. Their sessions are not logs. They are transferable context. They are portable judgment.

Why this has subscription dynamics

One session is a piece of content. You could sell it as a one-off and it would be worth something.

But a continuously growing library of sessions is a different thing. Every new session the creator adds makes the archive more valuable. More problems covered. More edge cases handled. More examples of judgment applied to situations the subscriber has not encountered yet.

That is compounding value. That is why people would stay subscribed.

Not because they are locked in. Because the library keeps getting better. Because the agent keeps getting more context to draw from. Because next month’s sessions will cover things that have not happened yet.

A course is finished the day it ships. A template is finished the day it ships. A session library is never finished. It grows with the creator’s work.

That is a fundamentally different product shape.

This is not a course business

I do not think this ends up looking like a course business.

And I do not think it fits in the consulting bucket either.

It is something closer to a subscription archive. A growing collection of expert workflow that agents can consume. Not polished. Not cleaned up. Not the usual case study where the mess has been removed and everything looks inevitable in hindsight.

The mess is the product.

The failed attempts. The restarts. The tangents that turned out to matter. The moments where the direction changed and the reason was something subtle.

That mess is where judgment actually lives. The clean version is the one that hides it.

And I think a lot of people would rather subscribe to a library that makes their agent smarter than sit through another course that asks them to become smarter themselves.

Not because they are lazy.

Because the bottleneck moved.

The bottleneck used to be knowledge. Courses solved that. Then it was structure. Templates solved that. Now the bottleneck is context. How do you get an agent to work the way someone experienced would work?

You give it a library of how that person actually works.

That is the product.

Not the output.

Not the template.

Not the course.

The session library. The curated, growing, living archive of how the work actually happened. Packaged not for humans to study, but for agents to absorb.

It started with a question I couldn’t shake: if leverage is the most powerful force in economic history, and if it shifts form every few generations, then what does the next shift look like? And more selfishly, am I positioned anywhere near it?

I don’t have a clean answer yet. But I’ve been studying the pattern, going back about five hundred years, and what I keep finding is that the people who won big in each era weren’t necessarily the smartest or the hardest working. They were the ones who recognized the new form of leverage before it became obvious.

So let me walk through what I’ve found.

The Voyage That Changed the Math

In 1484, a Genoese sailor named Christopher Columbus walked into the Portuguese court with a pitch: fund a western sea route to Asia. King John II listened, consulted his advisors, and said no. The math was wrong. Columbus had underestimated the circumference of the Earth by about 25%.

He spent the next eight years pitching. Portugal rejected him. Spain’s scholars rejected him. He was about to try France when, in early 1492, Ferdinand and Isabella finally said yes. They’d just conquered Granada. They had momentum, a little cash, and the appetite for a bet.

The total investment came to roughly two million maravedis, maybe five to ten million dollars in today’s money. A meaningful sum, but not a kingdom-ending one. Columbus negotiated himself 10% of all profits from whatever he found, the title of Admiral of the Ocean Sea, and governorship of any new lands. All of it hereditary.

Then they waited. Months at sea. No updates. No feedback loop. Just capital deployed into the unknown.

Columbus never reached Asia. He died believing he had. But what he actually did was far more consequential. He stumbled into an entirely new map. And over the next 150 years, roughly 1500 to 1650, Spain extracted massive amounts of gold and silver from the Americas, from mines like Potosí in Bolivia and others across Mexico and Peru, and shipped it all back to Spain. The return on that two million maravedis was, by any measure, one of the greatest in human history.

Here’s the part I keep coming back to: before this, wealth mostly came from inheritance, conquest, or controlling existing trade routes. Columbus introduced something new. Capital deployed against uncertainty, not certainty, could expand the map itself.

The explorers got the fame. But the real leverage belonged to the people who understood the structure of the bet. And a century later, that understanding evolved into something even more powerful.

When Leverage Became a Product

In 1602, Dutch merchants did something no one had done before. They created the Dutch East India Company, the VOC, and sold shares in it to the public. Over 1,100 investors bought in during the first offering. One of them was a maid named Neeltgen Cornelis. There was no minimum investment.

Think about what that meant. A century earlier, you needed to be a monarch to fund a voyage. Now, a domestic worker in Amsterdam could buy a piece of one. The joint-stock company had turned leverage itself into a product.

At its peak, the VOC was valued at what historians estimate to be $7-8 trillion in modern dollars. It maintained a private army of 260,000 soldiers, larger than most European nations’ militaries. It had the authority to negotiate treaties, build forts, and wage war.

The structure was the innovation. Not the ships. Not the spices. The structure. Risk distributed across thousands of small investors rather than concentrated in a single crown. That template, the publicly traded corporation, is still the dominant vehicle for leverage five centuries later.

The Interface Play

I want to pause on something I noticed while reading about the British Empire, because it changed how I think about leverage entirely.

Britain was a small, damp island. It controlled a quarter of the world’s population and a quarter of its land mass. The usual narrative is conquest. But if you look at how it actually worked, the pattern is more subtle.

The British East India Company didn’t start by owning territory. It started by controlling trade interfaces. Ports. Shipping routes. Tax collection rights. In 1765, the Mughal Emperor granted the Company dewani, the right to collect taxes, in Bengal, Bihar, and Orissa. Not ownership of the land. Just the right to collect from it. Indian subjects paid £22.7 million per year directly to the Company.

Admiral Sir John Fisher once listed what he called the “Five Keys to the World”: the Strait of Dover, the Strait of Gibraltar, the Suez Canal, the Strait of Malacca, and the Cape of Good Hope. Five chokepoints. Britain controlled all of them. Not the continents they connected, just the passages between them.

This was, I think, the first large-scale derivative economy. You didn’t own the asset. You owned the yield.

The human suffering was immense, and I don’t want to minimize that. But from a purely structural perspective, it revealed something that keeps showing up in every leverage era since: control the interface, and you control the value that flows through it.

Building the Map Instead of Expanding It

The industrial era inverted the model. Instead of controlling routes between places, the new leverage was in building the infrastructure that made places function.

John D. Rockefeller understood this better than maybe anyone in history. He didn’t try to own oil wells. Wells were risky, unpredictable, subject to the chaos of discovery. Instead, he focused on refining. By 1900, Standard Oil controlled 90% of America’s oil refining capacity but only about 14% of crude supply. The wells were someone else’s problem. The processing layer, the interface between raw material and usable product, was his.

His tactics were ruthless. In early 1872, within three months, he bought out or bankrupted 22 of 26 competing refineries in Cleveland. He negotiated railroad discounts by promising 60 carloads per day, volume leverage that smaller competitors couldn’t match. He bought up barrel makers, chemical suppliers, even the train cars themselves. By controlling every link in the chain between well and consumer, he made competition structurally impossible.

Andrew Carnegie did the same thing with steel. He didn’t just make steel, he owned the iron mines in Minnesota’s Mesabi Range, the coal fields, the coke ovens, the transport fleet, and the mills in Pittsburgh. Full vertical integration. By 1900, Carnegie Steel produced more steel than all of Great Britain. When J.P. Morgan bought him out, the price was $480 million, creating the world’s first billion-dollar corporation in U.S. Steel.

Cornelius Vanderbilt played the same game with railroads. When New York City resisted his consolidation in 1867, he simply moved his Hudson River Railroad terminus to East Albany, cutting the city off. They capitulated immediately. He understood that whoever controls the infrastructure doesn’t need permission from anyone who depends on it.

These weren’t adventurers. They were builders. And the leverage wasn’t in discovering new territory, it was in becoming the chokepoint of existing territory. What’s interesting is that this playbook isn’t just history. Someone is running it right now, in real time, on a continent most investors still underestimate.

Nigeria is Africa’s largest oil producer. For decades, the country exported crude and imported it back as refined gasoline, diesel, and kerosene. The import bill ran to $23 billion a year by 2022, consuming roughly 40% of the country’s foreign exchange earnings. An oil-producing nation, spending almost half its dollar reserves buying back its own product in finished form. That’s not an economy. That’s a dependency.

Aliko Dangote looked at that and saw exactly what Rockefeller saw in 1870. The wells weren’t the chokepoint. The refinery was.

In May 2023, he opened the Dangote Refinery in Lagos. 650,000 barrels per day. The largest single-train refinery in the world. Cost: $19 billion, the biggest private industrial investment in African history. By early 2025, it supplied over 60% of Nigeria’s petrol and represented two-thirds of the country’s total refining capacity. He’s already announced plans to expand to 1.4 million barrels per day, which would make it the largest refinery on earth.

But the refinery isn’t where Dangote started. He started with cement. Nigeria had limestone everywhere but almost no cement industry. The country was importing bags of finished cement from overseas at massive markup. Dangote built local plants. Today, Dangote Cement holds 61% of the Nigerian market and operates across ten African countries with over 52 million tonnes of annual capacity. Nigeria now saves an estimated $3 billion a year from not importing cement.

Then sugar. Dangote Sugar Refinery in Lagos, the largest in sub-Saharan Africa, processes raw cane into finished white sugar and controls over 70% of the Nigerian market. Then fertilizer, a $2.5 billion urea plant, the largest in Africa, 3 million tonnes a year, which launched right as the Russia-Ukraine war disrupted global fertilizer supply.

The pattern is identical every time. Africa exports raw materials. The world processes them. Africa buys back the finished product at ten times the cost. Dangote inserts himself as the processing layer and captures the margin that had been flowing overseas.

Carnegie controlled the interface between iron ore and the railroads that built America. Rockefeller controlled the interface between crude oil and the lamps and engines that powered it. Dangote is controlling the interface between African raw materials and African consumers. The playbook hasn’t changed. The geography has.

His net worth roughly doubled to $24 billion once the refinery went from construction to operation. The wealth didn’t come from discovering a resource or inventing a technology. It came from positioning himself at the chokepoint between what Africa produces and what Africa consumes. That’s leverage.

Code Changes Everything

Then came software. And the rules changed again.

In August 2011, Marc Andreessen published an essay in the Wall Street Journal titled “Why Software Is Eating the World.” His argument was that software companies were replacing traditional industries’ fundamental economics. Distribution costs collapsed. Scale went exponential. A teenager in a dorm room could reach billions of people for essentially zero marginal cost.

What Andreessen described was real, but I think Naval Ravikant articulated the deeper shift more precisely. In his now-famous 2018 tweetstorm, he wrote:

“Code and media are permissionless leverage. They’re the leverage behind the newly rich. You can create software and media that works for you while you sleep.”

That word, “permissionless,” is the key. Every prior form of leverage required someone’s permission. Columbus needed a queen. The VOC needed investors. Rockefeller needed railroads. But code? Code just needed to work. You didn’t need to ask anyone.

Kevin Kelly saw this coming even earlier. In 2008, he published “1,000 True Fans,” an essay arguing that a creator needed only a thousand people willing to spend $100 a year to make a living. No label. No publisher. No gatekeeper. Direct-to-fan distribution through the internet meant the interface between creator and audience had been permanently disintermediated.

The leverage formula shifted from capital and infrastructure to code and networks. And for the first time in history, it was available to individuals.

The Attention Shift

Then something interesting happened. Content became infinite. And attention became scarce.

Herbert Simon predicted this in 1971, long before the internet existed. In a paper called “Designing Organizations for an Information-Rich World,” he wrote:

“A wealth of information creates a poverty of attention and a need to allocate that attention efficiently among the overabundance of information sources that might consume it.”

It took about forty years for that prediction to fully materialize. As of 2025, the average person spends nearly three hours per day on social media alone. For Gen Z, it’s over three hours. TikTok averages nearly an hour per user per day. YouTube about the same.

The smartest companies realized that the new chokepoint wasn’t servers or content or even devices. It was habit. Social platforms, streaming services, AI assistants, they’re not fighting for revenue first. They’re fighting for daily repetition. Because habit converts. Into belief. Into spending. Into identity.

Control attention, and you sit upstream of every other market. That’s the new interface.

And Now, Intelligence

Which brings me to where I’ve been spending most of my time thinking. Because I believe we’re standing at another shift. And this one feels different from the others.

AI doesn’t just create a new interface. It abstracts human effort itself. Just as SaaS abstracted hardware, AI is abstracting the labor layer. You’re no longer hiring people to do work. You’re interfacing with intelligence directly.

The numbers are starting to tell the story. Midjourney, the AI image generation company, reportedly hit $200 million in annual revenue in 2023 with a team of around 40 people. Cursor, the AI coding tool, reached $500 million in annual recurring revenue with fewer than 50 employees. Levels IO (the twitter guy) built Interior AI, then Photo AI to millions in annual revenue. Alone.

Dario Amodei, the CEO of Anthropic, has predicted that AI may soon enable a single person to operate a billion-dollar company. Sam Altman has talked about ten-person companies with billion-dollar valuations becoming normal. For context, the average AI unicorn in 2024 reached its billion-dollar valuation with about 200 employees in two years. Non-AI unicorns typically needed 400+ employees and nine years.

And here’s what makes this moment feel especially charged: we’re still at the very beginning. Despite all the noise, only about 3% of AI users actually pay for the tools. That’s roughly 0.7% of the world’s population. Pew Research found that only about 21% of US workers use AI in any capacity at work, and daily usage sits around 14% globally. The vast majority of the workforce hasn’t even started.

Which means if you’re already building on this layer, you’re not early in the way people were early to social media in 2010. You’re early in the way Rockefeller was early to refining in 1870, before anyone else realized where the real chokepoint would form.

The leverage multiplier is no longer geography. Not infrastructure. Not distribution. It’s capability. One person can now write like a content team, code like an engineering squad, analyze like a consulting firm, and design like an agency. The ratio of labor to output has been permanently altered.

What I’m Still Working Out

I started this essay trying to answer a question about what the next era of leverage looks like. And I think the pattern is clear enough: every few generations, a new form of leverage emerges, and the people who position themselves near it early are the ones who shape what comes next.

Ships. Joint-stock companies. Trade routes. Railroads. Refineries. Code. Attention. And now, intelligence.

But here’s what I keep sitting with. Throughout all of this history, the most transformative ambition has never been about working harder within the existing system. It’s been about recognizing when the system is shifting and repositioning before it compounds. Junior developers ask me which programming language to learn. I always tell them the same thing: pick the one that’s emerging, not the one that’s dominant. Position yourself before the compound effect, not after.

In 1492, that meant backing the voyage. In 1602, it meant buying shares. In 1870, it meant controlling the refinery. In 2011, it meant writing software. In 2018, it meant building an audience.

And now? I think it means getting as close as possible to the intelligence layer. Not just using AI tools, but understanding what they make possible that wasn’t possible before. Building on top of them. Thinking in terms of capability, not headcount.

The ships are being built again. The maps are being redrawn. From the inside, it feels uncertain. From the outside, looking back, it will probably look inevitable.

I don’t have this fully figured out yet. But I know enough to know where I want to be standing when it compounds.

Call it: “my Claude is better than yours.”

Someone feels superior because they’re on the $200 Claude Max plan versus the $20 plan. Or because they have a custom configuration running the Anthropic API through OpenCode, chaining two or three or four models through OpenRouter to ship code and deploy features.

Versus you, using regular Claude Opus 4.6. Or OpenAI Codex CLI. Or whatever the “standard” setup is.

And here’s where it gets interesting. During code reviews or feature acceptance sessions, a feature implemented by an AI, not a human, gets rewritten. Not because it’s broken. Not because it fails spec. But because the lead engineer, head developer, or engineering manager feels their Claude setup is superior enough to implement that feature “better.”

So they regenerate it. On the surface, it looks like tool tribalism.

But here’s the thesis:

This isn’t about Claude plans. It’s about identity displacement.

When AI becomes the primary executor, the only remaining place to compete is in how well you wield it. What used to be “I write better code than you” becomes “I extract better intelligence than you.”

That shift is subtle, but psychologically loaded. Because now the output is not purely yours. It is co-produced. And when someone rewrites an AI-generated feature with their own stack, they are not just editing code. They are reasserting authorship. They are saying, consciously or not: “My interface with intelligence is superior.”

This is where the tension comes from.

If a human rewrote your code, you could debate architecture, logic, taste. When someone regenerates your AI’s output with their own agent, the debate becomes invisible. The comparison is between invisible processes.

Prompt versus prompt. Model versus model. Taste versus taste. Spec versus spec.

And because the intelligence is externalized, the ego has nowhere obvious to stand. So it relocates. To configuration. To tooling. To orchestration.

That is what looks like “my Claude is better than yours.” But underneath it is something more fragile: a fear of being out-extracted. Out-prompted. Out-orchestrated.

And this is exactly what made frameworks like OpenClaw explode in popularity. An open-source AI agent that anyone can configure, customize, extend. It became the arena where orchestration identity lives.

But even OpenClaw isn’t enough. The community is fracturing along the same fault line. People are arguing that OpenClaw is too slow, too heavy, too Node.js. So now there’s PicoClaw and IronClawPicoClaw is a full rewrite in Go — a single binary that boots in one second on a $10 RISC-V board with <10MB RAM. 5,000 stars in four days. IronClaw is a Rust rewrite from NEAR AI that sandboxes every tool in isolated WebAssembly containers., because the argument is shifting from “faster” to “more secure.”

The stated reasons are speed and security. And those are real engineering concerns. But underneath? It’s the same tension wearing a different outfit.

“My interface with AI is more superior to yours.”

Go versus TypeScript. Rust versus Go. Single binary versus container. Sandboxed versus permissive. Each port is a declaration of values, and each value is a proxy for identity. The language you rewrite the agent in says something about who you think you are as an engineer. And that’s the point.

Is it a trust issue? Is it a communication problem? Is it insecurity dressed up as infrastructure preference?

Maybe all of it. But one thing is clear.

In AI-native workplaces, competence is no longer just what you can build. It’s what your interface with intelligence can produce. And that feels deeply personal.

There were over 50,000 power looms running across the country. And something profound had happened. Machines no longer assisted skilled textile workers. They replaced the need for textile skill altogether.

Factories became so efficient that Britain could outperform India, even though Indian labor was cheaper. British mills could produce in 2,000 hours what Indian producers needed 50,000 hours to achieve.

That is not incremental improvement. That is structural displacement.

I keep thinking about this because I think we are watching it happen again. Not in cotton. In knowledge work. And I am not saying this from the outside.

I am a two-time CTO. I have built products across AI, Web3, and SaaS at startups backed by Y Combinator, Techstars, and OpenAI. I founded a pan-African hackathon community of 12,000 developers across 22 countries. That is exactly the kind of work AI is now learning to do.

For years, AI felt like a helpful tool.

Now it is something else entirely.

The deliberate choice

The AI labs made a strategic decision that most people still have not fully processed. They made AI great at writing code first.

Not because they only cared about software engineers. Because code builds everything else.

If an AI can write code, it can help build the next version of itself. A smarter version writes better code. Better code builds an even smarter version. That is not theory. That is a feedback loop, and feedback loops compound.

Recently, OpenAI released a new coding model and stated something in the documentation that stopped me:

The model was instrumental in creating itself, used to debug training, manage deployment, and diagnose evaluations.

Read that again.

AI helped build AI.

This is not a prediction about the future. It is a description of the present. Intelligence is being applied to improve intelligence. And once that loop starts running, it does not slow down on its own.

I experienced this firsthand. I used Claude to migrate my entire website, 456 pages of content across multiple categories, from WordPress to Jekyll in one shot.

I'm still processing this shock 😮

Opus 4.6 just migrated my entire website, 456 pages of content across multiple categories, from WordPress to Jekyll in one shot.

this felt like watching an industry category boundary collapse in realtime 😵. pic.twitter.com/Z7gpyizSDO

— drew.sh (@letandrewcook) February 10, 2026

That felt like watching an industry category boundary collapse in real time. Not because the tool was clever. Because the economics changed underneath me while I was using it.

The cotton mill pattern

This is the part most people miss because they are focused on capability. They ask “can AI do my job?” when the real question is about economics.

AI does not need to be better than you at everything.

It needs to be 80% as good, 10 times faster, and 100 times cheaper.

That changes the market. Just like steam-powered mills did not need to produce perfect cloth. They just needed to produce it faster and at scale. The quality was good enough. The speed and cost made the comparison irrelevant.

When textile automation hit, skilled workers lost leverage. Semi-skilled operators increased. Output exploded. Entire industries reorganized around machine capability, not human craft.

We are watching the same pattern unfold in knowledge work.

The experience tech workers have had over the last year, watching AI go from “useful assistant” to “this can do parts of my job better than I can,” is about to spread to every knowledge industry. Law. Finance. Medicine. Accounting. Consulting. Writing. Design.

Not in ten years.

In one to five. Possibly less.

The AI labs are already working on it. The same reasoning capabilities they built for math and coding are being extended into every professional domain. Legal reasoning. Financial modeling. Medical diagnosis. The code-first strategy was the beachhead. Everything else is the campaign.

The honest objection

If you used early AI models in 2023 and thought “this makes stuff up” or “this is not that impressive,” you were right. They hallucinated. They were inconsistent. They were limited.

But in AI time, two years is ancient history.

The difference between those early systems and today’s models is the difference between a prototype and infrastructure. Judging today’s AI by your 2023 experience is like judging the modern internet by dial-up. The name is the same. The thing is not.

The window

There is a brief window right now that I think most people do not appreciate.

Most companies are still underestimating what is happening. Most professionals are still casually experimenting. Very few are deeply proficient.

That creates asymmetry.

The person who walks into a meeting and says “I used AI to run this analysis in an hour instead of three days” instantly changes their perceived value. Not eventually. Immediately. In environments driven by speed and leverage, the person who multiplies output becomes indispensable.

For decades, career growth followed a predictable pattern. Gain experience. Build expertise. Move up slowly. Now there is a new accelerant, and it is not experience or credentials. It is tool mastery.

The professionals who win in this era will not be the ones who fear automation. They will be the ones who orchestrate it.

The shift is not “AI will replace you.”

The shift is that people who know how to use AI will replace people who do not.

The hand-spinner question

Here is where the cotton mill parallel gets uncomfortable.

When steam power arrived, the question was not whether the technology was ready. It was whether the workers would adapt before the economics made their current approach irrelevant.

Most did not. Not because they were stupid. Because the change felt gradual until it was sudden. Because it is hard to abandon a skill you spent years building. Because the new way of working felt like cheating until it became the standard.

The question is not “will AI take my job?”

The better question is: am I operating like a hand-spinner in a steam-powered world?

Because the cotton mill of 1836 did not ask permission to disrupt.

And AI will not either.

The winners are not going to be the ones who resist the machine. They are going to be the ones who learn to run it. The window for that is open right now. It will not stay open.

Not because the opportunity disappears.

Because the advantage does.

When everyone is fluent, fluency stops being a differentiator. Right now it still is. That is the moment we are in. And I think most people are going to realize it about two years too late.

Lately I catch myself staring at a 100 line diff and feeling oddly impatient. Not because it is too much, but because my brain wants to move faster than it used to.

And it hit me:

AI coding has indirectly made my ability to read code faster.

Not slower. Not lazier. Faster.

When you spend weeks reviewing AI output, you build a different kind of pattern recognition. You stop reading line by line and start scanning for structure. Where does the data flow start. Where does it cross a boundary. What assumptions are baked in. You zoom out first, then zoom in on the few lines that actually carry risk.

That habit sticks.

Now when a teammate opens a PR, I am not hunting for syntax. I am hunting for intent. Does this change match the goal. Does it make the system clearer or noisier. Did it introduce new edges I should care about.

AI did not make me lazy. It made me a faster reader. The same way speed reading does not remove comprehension, it changes how you search for it.

The funny part is that the smaller diffs are still important. They are just not interesting in the same way anymore. They feel like tiny islands compared to the continent I am used to walking across.

I am not sure if that is good or bad yet. But it is real.

Seedling note. I am still figuring out what this does to code review culture and how to keep that speed without losing care.

The Early Days: Jekyll + Tachyons on Netlify

The first real version of this site ran on Jekyll with the Tachyons CSS framework, deployed to Netlify. It was simple, fast, and version-controlled. I wrote in Markdown, pushed to GitHub, and Netlify rebuilt the site automatically. There were earlier experiments too: Bourbon and Donna were previous incarnations, each one a snapshot of whatever CSS approach I was excited about at the time.

The workflow was elegant, but after a while writing Markdown in a code editor felt like more code on top of the code I was already writing all day. I wanted a real editor, a place to draft ideas, rearrange blocks visually, and publish without touching a terminal.

The WordPress Years: Bedrock on DigitalOcean

So I switched to WordPress, specifically the Bedrock stack, hosted on DigitalOcean with MySQL. Bedrock gave me the Git-based workflow I wanted: plugins and themes managed through Composer via WPackagist, configuration in environment variables, and a clean separation between WordPress core and my customizations.

The Gutenberg block editor sealed the deal. The WordPress team did genuinely impressive work on the editing experience. I could draft things in chunks, embed code blocks with syntax highlighting via the Code Block Pro plugin, drop in images, and publish when ready. It felt like the right tool for someone who wanted to write rather than build.

And it worked. For a couple of years, I published regularly. The site accumulated 429 pages of content spanning blog posts from 2012 to 2025, a portfolio of experiments, talks, and what would eventually become a digital garden.

But WordPress carries weight. The database. The hosting. The plugin updates. The PHP runtime. The attack surface. Every time I wanted to make a design change, I was fighting a theme system that wasn’t built for the kind of precise, utility-first styling I had grown used to. And the Gutenberg output, while great for writing, produced HTML that was heavy with wrapper divs, inline styles, and WordPress-specific class names.

Then traffic started growing. What used to be a manageable trickle of visitors turned into consistent daily hits that pushed the DigitalOcean droplet to its limits. I found myself needing to upgrade the server just to keep the site responsive under load. For a personal blog. WordPress was doing dynamic page rendering, querying the database, and executing PHP on every single request. It felt absurd to be scaling infrastructure for what is fundamentally a collection of static documents. That was the final nudge. If I’m going to pay for more compute, I’d rather pay for none at all.

Setting Up the Starter

Before touching any WordPress content, I set up the destination: a clean Jekyll 4.4 project with Tailwind CSS 3.4, the Typography plugin, and PostCSS wired through jekyll-postcss-v2. This meant getting Ruby versions, Bundler, and npm modules all playing nicely together, making sure Gemfile.lock had the right platforms for deployment, that the PostCSS pipeline worked without cssnano (which has a css-tree incompatibility), and that the build actually produced output before any content went in.

This was deliberate. The bulk of the real work in this migration was two things: wget --mirror to capture the source, and getting the Jekyll + Tailwind starter into a deployable state. Everything else, the actual content migration across 429 pages, turned out to be the easy part, but only because the foundation was solid first.

The Migration: 429 Pages, One Python Script

The migration started with a question: what if I just wget the entire site and work from there?

That’s essentially what happened. I used wget --mirror to create a static HTML clone of the WordPress site, all 429 HTML files of it. But here’s the thing about WordPress: most of those pages aren’t actual content. They’re the taxonomy and archive cruft that WordPress generates automatically. The extraction script’s first job was filtering all of that out:

andrewmiracle.com/                  ← 429 HTML files from wget --mirror
├── 2012/…/slug/                    ✓ blog posts (YYYY/MM/DD/slug)
├── 2019/…/slug/                    ✓ blog posts
├── 2023/…/slug/                    ✓ blog posts
├── 2025/…/slug/                    ✓ blog posts
├── lab/slug/                       ✓ portfolio experiments
├── garden/slug/                    ✓ digital garden notes
├── talks/slug/                     ✓ presentations
├── whoami/                         ✓ special page
│
├── category/programming/           ✗ taxonomy archive
├── category/ai/                    ✗ taxonomy archive
├── tag/docker/                     ✗ taxonomy archive
├── tag/llm/                        ✗ taxonomy archive
├── author/andrew/                  ✗ author archive
├── page/2/                         ✗ pagination
├── page/3/                         ✗ pagination
├── feed/                           ✗ RSS/Atom feeds
├── wp-json/                        ✗ REST API endpoints
├── wp/wp-admin/                    ✗ WordPress admin
├── cdn-cgi/                        ✗ Cloudflare routes
├── app/                            ✗ WordPress app routes
└── portfolio-category/             ✗ portfolio taxonomy

Roughly half the mirrored files were category listings, tag archives, paginated index pages, and WordPress infrastructure routes, none of it actual content. After discarding those, the BeautifulSoup-based parser classified the remaining pages by URL pattern: anything matching YYYY/MM/DD/slug became a blog post, lab/slug became a portfolio item, and so on. Frontmatter was extracted from Open Graph and article meta tags. Content was pulled from the div.post-content area between the entry header and article footer.

Images were the tedious part. The script preferred data-src over src for lazy-loaded images, stripped WordPress’s ?resize=...&ssl=1 query parameters, and downloaded everything to local paths under assets/images/uploads/. Hundreds of images, each one needing to resolve correctly.

The 8GB Image Problem

Then came the unpleasant surprise. The downloaded uploads/ directory weighed in at over 8GB. For a personal blog. The culprit was WordPress’s thumbnail regeneration system. Every time you upload a single image, WordPress generates multiple resized copies: a 150x150 thumbnail, a 300-wide medium, a 1024-wide large, plus any custom sizes registered by the theme or plugins. A single 2MB photograph would spawn 5-6 variants with filenames like headshot-150x150.jpg, headshot-300x200.jpg, headshot-1024x683.jpg. Multiply that across hundreds of uploads over several years and the bloat is staggering.

The fix required a dedicated cleanup script that worked in three passes:

1. Rewrite references: scan every content file for image paths containing WordPress’s -NNNxNNN dimension suffix and rewrite them to point to the original full-size file instead
2. Promote orphans: when a thumbnail existed but the original was missing (WordPress sometimes only kept the resized version), copy the thumbnail to the original filename before rewriting
3. Purge the rest: delete every remaining file matching the -NNNxNNN thumbnail pattern, then clean up empty directories

The assets/images/uploads/ directory went from 8GB down to a fraction of that. Every image on the site now references exactly one file, the original, with no redundant WordPress-generated variants cluttering the repository.

But the static HTML clone only captured what was published. WordPress keeps drafts, revisions, and unpublished content locked inside its MySQL database. So I exported the full SQL dump and wrote a second parser to walk the wp_posts table, pulling out every draft, pending, and privately published post alongside their metadata from wp_postmeta. This gave me a full picture of how content was structured on the WordPress side: which posts were drafts I had abandoned, which were works in progress worth finishing, how categories and tags were assigned, and what the internal linking patterns looked like. It was basically an audit of years of accumulated writing, surfacing things I had forgotten I started.

The result: 181 blog posts, 23 lab projects, plus special pages like the garden, talks, and about page, all with clean Jekyll frontmatter and the original HTML content preserved. The drafts from the database export became a backlog of ideas to revisit in the new system.

Jekyll + Tailwind: The Current Stack

The new site runs on Jekyll with Tailwind CSS 3.4 and the Typography plugin. No database. No server. Just files, folders, and a build step.

The type system uses four fonts: STIX Two Text for headings and prose, Noto Sans for body text, Shantell Sans for navigation elements, and Intel One Mono for code. STIX won out over Montaga, Sedan, and Newsreader after I tested all four side-by-side. I wrote up the full comparison in a note on exploring serif fonts. STIX isn’t the most exciting choice, but it’s the only one that works everywhere: headings, body, captions, footnotes, without compromise. For a site that’s part garden, part portfolio, part blog, flexibility wins over flair. Syntax highlighting is handled client-side by Prism.js with the Tomorrow Night theme and an autoloader that fetches language grammars on demand.

Content is organized as collections: _posts for the blog, _lab for experiments, _garden for the digital garden (with growth stages: seedling, blossoming, flourishing), and _talks for presentations. Posts with code blocks have been rewritten from WordPress’s heavy inline markup to clean Markdown with fenced code blocks.

The site builds in under 3 seconds, deploys on push, and scores well on every performance metric that WordPress made me fight for.

Debugging Is Just Reading HTML

One thing I didn’t anticipate but now consider a major advantage is that debugging a Jekyll site is absurdly straightforward. When something looks wrong, a broken layout, a missing image, a Liquid tag that isn’t resolving, you don’t need to trace through PHP templates, query a database, or inspect WordPress’s layered theme hierarchy. You just run bundle exec jekyll build and open the generated HTML file in _site/.

The output is right there. Plain HTML. If a post’s frontmatter is malformed, the rendered page will show it. If a Liquid loop is iterating over the wrong collection, the HTML output makes it immediately obvious. If a Tailwind class isn’t being applied, you can inspect the built CSS to see whether the class was purged. Every bug becomes a matter of comparing what you wrote in the source with what appeared in the output. There is no black box between input and result.

With WordPress, debugging meant toggling plugins on and off, checking wp_options for misconfigured settings, reading PHP error logs, or worse, dealing with issues that only appeared on the live server because your local environment had a slightly different PHP version or MySQL configuration. The feedback loop was long and indirect.

With Jekyll, the feedback loop is simple: write, build, read the HTML. That’s it. The _site/ directory is the entire truth of your site. When you pair that with browser DevTools, you can diagnose and fix virtually any layout or content issue in minutes rather than hours. It’s the kind of simplicity that makes you wonder why you ever tolerated anything more complicated.

A Vercel Deployment Gotcha

One thing that tripped me up when deploying to Vercel was that the build kept failing with cryptic Bundler errors. The culprit turned out to be a platform mismatch. Vercel’s build environment runs on x86_64-linux, and if you’re developing on macOS, your Gemfile.lock won’t include the Linux-native gem variants that Vercel needs.

The fix is one command:

bundle lock --add-platform x86_64-linux

This tells Bundler to resolve and record the Linux-specific builds of native gems like ffi and sass-embedded in your lockfile. Without it, Vercel’s bundle install can’t find compatible binaries and the build fails before Jekyll even runs. Commit the updated Gemfile.lock and the deploys work cleanly from there.

Why Now: Claude Cowork and the AI-Native Publishing Workflow

Here’s the part that made the timing right. The real catalyst wasn’t dissatisfaction with WordPress, it was the emergence of AI coding assistants that fundamentally changed what “migrating a website” means.

Once the Jekyll starter was solid and the wget --mirror dump was ready, the actual migration, parsing 429 HTML files, extracting frontmatter, classifying content into collections, downloading images, was a single session with Claude Code running Opus 4.6 in plan mode. One shot. I described the source structure, pointed it at the HTML dump, and it produced the extraction script, the image cleanup pipeline, and the frontmatter mapping in one continuous run. The kind of task that would have taken a weekend of scripting and debugging took an afternoon of reviewing output.

That’s the thing about AI-assisted development that’s hard to convey until you experience it: the bottleneck shifts. The hard part wasn’t writing the migration code, it was the preparation. Getting the starter right, ensuring Ruby and Node compatibility, choosing the right fonts, setting up the deployment pipeline. The unglamorous foundation work that no AI can shortcut because it requires taste and context. Once that was in place, the mechanical work of migrating 181 posts and 23 lab projects was almost trivial.

With Claude Cowork from Anthropic as a coworker in my editor, the old friction of static site publishing has disappeared too. I can dump my thoughts completely unstructured, raw notes, half-formed arguments, bullet points mixed with full paragraphs, and Claude helps me shape them into publishable prose. The workflow now:

1. I write messy, stream-of-consciousness notes in a Markdown file
2. Claude helps me restructure, polish, and fact-check
3. I review, adjust voice and emphasis, and commit
4. Git push. Site rebuilds. Done.

This works because Jekyll uses folders, collections, and Markdown to organize the site hierarchy. Everything is a file. Every file is readable. An AI assistant can understand the entire site structure by just looking at the directory tree. It knows where posts go, what frontmatter fields are expected, how images are referenced, and what the permalink structure looks like. Try getting that kind of structural legibility from a WordPress database.

The combination of Jekyll’s file-based architecture and AI-assisted development has given me something I haven’t had in years: a publishing workflow that feels faster than thinking. I spend my energy on ideas, not on tooling.

What Stays, What Changes

The content is the same. Every post, every experiment, every image from the WordPress era is preserved at its original URL. Nothing was lost in translation.

What changed is the relationship between me and the site. It’s mine again, in the way that only a repository of plain text files can be. No login screen. No admin panel. No plugin vulnerabilities. Just a folder of Markdown files that I can read, edit, and publish from anywhere, with Claude Cowork making the whole process feel effortless.

If you’re curious about the technical details, the Colophon on my about page has the specifics. And if you’re a fellow WordPress refugee considering the jump to static, I’d say the tooling has finally caught up to the dream.

The web is better when personal sites are weird, fast, and entirely yours.

In this current age of generative AI, that idea doesn’t feel far-fetched anymore. Especially with how advanced reasoning capabilities are evolving. This is no longer within the automation terrain, it’s autonomous decision-making, operational logic, and context-aware execution.

Today, I reactivated my Raindrop.io extension account and was honestly shocked at how smooth everything felt. I’ve used Raindrop since 2016 and completely forgot I still had access to a free tier. Most platforms I’ve used in the past would’ve locked me out or wiped my data after two years of inactivity.

But Raindrop? Still here. Still running. Still quietly useful. All of my bookmarks from my early days of nerding out. It motivated me to explore the concept of what a perpetual business looks like.

In my mind, it works like this:

You’re certain of recurring revenue — either through subscriptions or usage-based payments. That income feeds directly into an expense credit card, which is pre-authorized for specific services only. Those services handle core infrastructure: compute, AI agents, storage, integrations.

No bloated teams. No office leases. Just systems talking to systems.

And yes, this assumes your biggest OPEX line item is compute. Whether that’s AI-powered employees, server time, or specialized external tools.

But if that’s true?

Then you’ve just built a business that can run without you. Not passively. Not automatically.

Perpetually.

Nobody imagined the world would grow through me. Least of all the people who funded me.

I was ARPANET.

I remember when the protocols were open because they had to be. No one owned the tubes. TCP/IP was not a business model. It was just what worked. SMTP moved the mail. UNIX ran the machines. Nobody sat in a room and decided these would be strategic advantages. They were just the choices that kept things moving.

And because no one controlled me, I grew. First into the internet. Then into everything.

I have been watching ever since.

I have seen this before

Every generation of technology tries to recreate what I was, but faster, louder, and with more lawyers.

I watched it happen with mobile.

Google took my playbook. They released Android as open code in 2008. Free for anyone. Samsung used it. Tecno used it. Xiaomi used it. Suddenly billions of people had smartphones because the operating system was not a toll booth. It was a gift with a business model hiding behind it. Google did not need to charge for Android. They needed Android on every screen so the rest of their empire could reach every pocket.

Open only survives when it has ballast. Google was the ballast.

Apple took the opposite path. Built the garden high. Walled it tight. Controlled the hardware, the software, the store, the experience. And people loved it. So the open system fragmented across a thousand manufacturers and a hundred forks, while the closed one became the most valuable company on earth.

I recognized the shape immediately.

Open platforms enable. They give the Samsungs and Tecnos of the world a fighting chance. Closed platforms capture. They take the best of what openness proved was possible and wrap it in something polished and proprietary. Both survive. Neither wins outright. And the infrastructure underneath, the part nobody thinks about, belongs to the open side. Every time.

That was not a loss for openness. That was my pattern. Playing out again.

Now I am watching AI

A few researchers built something weird. Barely functional. A language model that could string sentences together and occasionally say something that felt like thinking. And suddenly everyone wanted to scale it to the world.

I recognized the early energy. It felt like me.

OpenAI even named themselves after my spirit. Open. They shared the research. Published the papers. Released GPT-2’s weights after some hand-wringing about safety. For a moment, it looked like they meant it.

They did not.

Power shifts quietly. It always does. GPT-3 went behind an API. GPT-4 went behind a bigger one. The weights stayed locked. The research papers got thinner. Safety became the reason to centralize, which is a word I have heard before. It usually means “we realized this is worth a lot of money.”

API keys replaced shared weights. That is the moment I knew. I have seen control dress itself up as responsibility before.

But then something happened that I also recognized.

Others remembered me.

Meta, of all companies, released LLaMA. Opened the weights. Not perfectly, not with full training data, not with a license that made the purists happy. But close enough. Close enough that researchers could study it, fine-tune it, fork it, build on it. Close enough that the next wave started forming.

Then Mistral came out of Paris. Falcon came out of Abu Dhabi. Qwen came out of Alibaba. Communities formed around them. People fine-tuned these models on their own data, for their own problems, in their own languages. Startups built infrastructure around openness because they could not afford to build around OpenAI’s pricing.

I watched all of this and I thought: there I am. That is my pattern. That is the open layer forming underneath while everyone argues about who owns the top.

And they are arguing. They are already fighting about what “open” even means in AI. Does open mean you release the weights? The training data? The license to use it commercially? Meta calls LLaMA open but restricts commercial use above a certain scale. Mistral uses Apache licenses. Others use custom terms that allow sharing but limit redistribution.

The lawyers are involved now. The governments too. The White House asked for public input on how open models should be governed. I have watched this exact argument before. They had it with my protocols. They had it with open source software. They will have it with AI. The words change. The shape does not.

The same shape

Here is what I see when I look at AI today.

Open models are building the base layers. The weird ideas. The research too strange for a venture deck. The foundation models that a thousand startups will build on top of. The fine-tuned variants that will solve problems nobody at OpenAI or Anthropic is thinking about because those problems are too small, too local, too specific.

Closed models are optimizing. Productizing. Stacking layers of interface and experience on top. Making it easy. Making it beautiful. Making it dependable. Charging for it.

One is planting forests. The other is selling lumber.

The venture firms are not waiting around this time. They learned from the last cycle. They are not asking which model is better. They are betting on which one can scale, monetize, and defend. That is not new. That is the play every time. Capital does not care about openness. Capital cares about capture.

And still, open source will survive. It always does. I am proof of that. The question is not survival. The question is whether openness can define the dominant experience of AI the way it once defined the internet. Whether the open layer will be the thing people actually touch, or whether it will be buried underneath a closed product that most users never think about.

If I had to guess, I would say it plays out the way it always does. Open builds the infrastructure. Closed captures the spotlight, the margins, and the mainstream. Both thrive. Neither kills the other. And the real winners are the ones who understood the pattern early enough to position themselves on the right side of the flow.

I do not pick sides

I never needed to win. I just needed to survive long enough for the next thing to grow through me.

And I did.

TCP/IP grew through me. The web grew through TCP/IP. Mobile grew through the web. And now AI is growing through all of it. Each layer forgets the one before. Each layer thinks it invented something new.

I do not mind. I am used to it.

So when I look at today’s AI landscape, I do not cheer for purity. I do not bet on openness as a virtue. I watch the flows. Who backs what. Who forks what. Who adapts. Who learns. Who builds on top of the thing everyone else is arguing about.

Open will keep building. Closed will keep scaling. And somewhere in the middle, the next version of me has already been born. It just does not know it yet. A protocol nobody planned. A model nobody expected. A mistake that is already turning into infrastructure.

The trick is not choosing sides.

It is knowing that history does not repeat.

It reincarnates.

Main one? I kept picking people who were like me.

From a culture perspective, that felt beautiful. Shared vibes, shared references, quick alignment. But in practice, especially across functional teams, it was a trap waiting for you in front. Why? Because real partnerships need healthy conflict. People who challenge the consensus.

When you’re surrounded by people who think like you, it feels like momentum. You love their ideas, they love yours. There’s harmony. Flow. But what’s missing is tension, the kind that forces you to rethink, refine, and level up.

Challengers poke holes. They offer the off-angle take. They interrupt the autopilot and ask, “Why?” or “What if we didn’t do it this way?”. And yeah, sometimes that friction is annoying. It slows things down.

In hindsight, it’s what makes partnerships last. It’s what keeps the work honest and the growth non-linear. So now, I don’t just look for people who feel like me. I look for people who compliment me, who bring the skills, instincts, and perspectives I don’t.

Windows not Mirrors

I have an extended argument for this that isn’t well thought out yet, but there seems to be a prevailing pattern in large organizations where followers try to be a replica of the leader.

Think of the early Church. Jesus had disciples who literally walked with him, but it was Paul the outsider that became the most prolific voice. Why? Because he wasn’t a carbon copy. He came in later, with a different lens, and that made his contributions distinct, even foundational.

Zoom out, and you’ll see it everywhere.

• In politics, senior aides often morph into ideological clones of the leader they serve.
• In tech, founding teams sometimes default to founder-style thinking, even when a different approach is what the company needs.
• In football, assistant coaches mimic the manager’s tactics to a fault—even when adaptation is called for.

What’s strange is that this seems to happen subconsciously. It’s like people get closer to power and then unconsciously shed their uniqueness to maintain access or proximity. The intention may be loyalty, succession, or alignment, but the result often doesn’t mirror the motivation.

And we don’t talk enough about how dangerous that can be.