I just read We Won’t “Just Hang Out,” which suggests that an AI utopia won’t look like a permanent vacation with our friends. Rather, ASI will make work and school pointless and leave us all sitting alone in our rooms choosing endless digital entertainment over each other because we have nothing left to talk about.

I can kinda see it.

Almost every close friend I’ve made has come from being stuck in a similar boat: sharing the trials of college, surviving a brutal stretch at work, building something together, etc. Friendship has been the sideways consequence of what happens to us when you’re looking for something else.

Now, when I spend all day building with AI, I don’t really have to care how its day is going. It doesn’t have an ego. When it pushes back on my ideas, it is still completely in service of what I want. I’m getting a lot of daily practice at being the center of my own little universe. So by this logic, when you pair frictionless AI companions with supercharged entertainment feeds designed to consume attention, it is possible to see how being around real human beings feels like a chore.

Where he loses me is the jump he makes pointing out that people themselves will become uneducated, dull, and not worth talking to in this “AI utopia.” Are we supposed to be resumes or have personalities? Even if ASI can out think us at everything, a machine knowing something on my behalf doesn’t do me any good. We don't just learn and struggle to get a paycheck, we do it because wrestling with ideas, relationships, and our own limits is how we figure out who we are. Yes, I recognize “work” is today’s traditional conduit for this. But god forbid there be other means!

Almost a hundred years ago, in In Praise of Idleness, Bertrand Russell argued that the whole point of “better machines” was to buy back our time so ordinary people could actually enjoy being alive. Sometimes hanging out is just sitting on the porch talking about whatever the heck you want to and the fact that our AI’s can write code (and soon do much, much more) doesn’t make these type of afternoons worth less.

Can we actually bear the delight and luxury of sitting on the porch?

A lot of companies have made casual AI use easy and serious use very difficult. They provide access without teaching or understanding proper practice, build internal products without understanding the workflow they’re meant to augment, and set allowances that stop the people attempting to achieve more more.

Learning to delegate the whole job

Being able to prompt tells you very little about your ability to hand off a substantial piece of work and know whether it was done properly. Real delegation means learning how much context to supply, what can run independently, what deserves rigorous verification, and when and how to intervene.

Subscribe now

In the workflow I use, my agents receive clear assignments, build the change, and pass it to other agents that run the software and try to break it. Failures go through a repair loop, and all of the records from every action stay within the project so later runs can leverage them as further context. The agents can construct this workflow too, though I still have to decide what success means and what evidence I’ll accept. That structure is how I can leave work running 24/7 while I do something else. Getting to this point requires significant practice with tasks that matter: including the unpleasant part where you discover that the thing you thought was finished doesn’t work.

Anthropic’s analysis of roughly 400,000 Claude Code sessions found that users who demonstrated a working grasp of the task were more likely to achieve success supported by evidence in the analyzed transcript. Most of the gap was between novice and intermediate users, with smaller gains beyond that. A library of clever prompts leaves most of that skill untaught. Companies have to teach (or environments that encourage) it by working through real tasks with people and reviewing what went wrong.

Do the product work

Instead of teaching the practice, many organizations try to package everything into an internal AI platform. An internal platform might have users but often these users can simply keep doing their work elsewhere. Before calling that resistance to change, watch the job you’re asking them to change.

Imagine a salesperson preparing for a customer call. A new portal requires them to find the account notes, upload documents, explain the situation, and carry the answer back into the system they were already using. The model answers quickly, but the whole task may still take longer or may be completely antithetical to how they want to work. In RAND’s interviews with 65 experienced AI practitioners, recurring failure modes included misunderstanding the problem and pursuing technology ahead of users’ needs. Giving your AI platform an internal audience doesn’t make those mistakes less expensive.

Compare this with a study of 5,172 customer support workers that found a 15 percent increase in issues resolved per hour after an AI assistant was introduced. The tool worked because it monitored the customer conversation already happening and supplied suggestions the worker could use, edit, or ignore. A different way of working has to earn the effort it demands. You have to understand the existing work well enough to decide which steps to remove, rebuild, or keep, and then measure the entire task: including gathering context, checking the answer, and putting the result to use.

This is basic product thinking that still applies when your customer is on your payroll.

Let the budget follow the result

Even when the tool fits the work some will learn to do much more with it than others. A cap generous enough for rewriting emails is too small for someone delegating hours of work to agents.

In OpenAI’s 2025 enterprise research, workers reporting more than ten hours saved per week consumed eight times as many credits as workers reporting no time saved. Those savings were self-reported, and the relationship doesn’t establish that spending caused them, but it gives a clear reason to examine heavy use before deciding on universal across the board usage limits.

For example, the last 30 days through October 22 (today), my public activity log showed ~5,400 agent sessions, 1,600 commits and 110B tokens. Its roughly $53,000 in API spend. I know what I achieved with this usage and it was substantial. A cap that allows only moderate chatting would prevent this way of working entirely. It might also prevent someone from learning whether it suits their job.

Give everyone room to learn, then increase budgets for people who can show useful results. Judge the cost of completed, accepted work, including the human time spent checking and correcting it, and ask the people finding better ways to work to teach them. The person using ten times as much AI deserves a closer look before they deserve a smaller budget.

If you want to change what your organization gets out of AI, start with one recurring job that takes too long, produces too many errors or has significant revenue generating potential. Put the person who knows that job beside someone who can drive agents. Give them time and a real budget to learn, compare the finished work with the existing process, and expand what proves useful.

Every new technology looks disappointing when we insist on fitting it inside the habits and budgets of yesteryears. Stop trying to ration a little bit of AI across your entire org chart. The ceiling right is capped by what you allow your people to learn not what the models can do.

I can spend an entire afternoon in conversation without having to care what anyone else wants. We can argue about an approach, work through a problem, and produce something useful. I think of this as akin to collaboration, although I never have to take a turn working on something that matters only to the other participant.

I like working this way. I can change direction without disappointing anyone, repeat myself without embarrassment, and leave without being rude. What I haven’t considered enough is how much practice I’ve been getting lately at being the only person whose priorities count.

Asking an agent to challenge me doesn’t change the arrangement. Its criticism still serves work I’ve decided matters. I can be receptive, patient, even grateful for the disagreement without having to give someone else’s priorities the same weight as my own.

The habit I worry about is treating another person’s refusal as a problem with my explanation. I can keep adding context and making my case more carefully, convinced I’m being patient while I wait for understanding to produce agreement. Nothing about my tone has to reveal that I’ve left no room for their answer to stand.

They may understand what I’m asking, agree that it matters, and still decide their own afternoon matters more. I need to be able to hear that without treating it as an unfinished conversation.

I don’t write code anymore or read it, either.

I still design and build software every day. I decide what I want, work with agents to get there, and verify that what they’ve built works. When finished, we commit the implementation to Git and treat it as the authoritative record of the system.

The code I neither wrote nor read becomes the thing we’re expected to understand, maintain, and preserve.

For decades, we’ve been moving implementation decisions beneath representations that are easier for people to reason about. We stopped reading the assembly produced by compilers. We write SQL and let databases choose execution plans. We describe desired infrastructure to Kubernetes and let controllers maintain it.

In each case, we preserve a higher-level representation while allowing the implementation beneath it to change.

Agents have taken us another step along this path, except we’ve neglected something important. We can now produce entire implementations without writing or reading them, but haven’t agreed on what should become the durable record above them.

A team should be able to change how its software works without accidentally changing what its software means.

The Questions We Don’t Ask

A year ago, I wrote Beyond Code-Centric, arguing that agents were moving the bottleneck in software development from implementation toward intent. At SpecStory, we began treating specifications (and the conversations required to produce them) as first-class artifacts alongside code and tests.

It has helped but specifications generally capture what we wanted before building. The working system contains everything we learned afterward, much of which never makes it back into the specification despite our trying.

Recently, we discovered that some coding sessions synchronized to SpecStory Cloud were failing because our Cloudflare worker’s TCP write path was rejecting writes above 64 KB. We fixed the problem by splitting writes into smaller chunks.

That workaround is now embodied in our implementation. It’s necessary for the software to work on its current platform, but it has nothing to do with what our session ingestion capability is supposed to do.

Another time, storage firewall rules began rejecting certain payloads based on their contents. Compressing the payloads appeared to be a reasonable fix, except two downstream services expected the original payload. I happened to know that from having built those services.

An agent can inspect our repository and reconstruct much of how the system works. But knowing what questions to ask is a different problem.

The questions we don’t think to ask are the ones that bite us.

The implementation contains behavior we explicitly requested, behavior we discovered and decided to keep, accidents nobody intended, and workarounds imposed by our infrastructure.

The code records what the system does. It doesn’t reliably tell us which of those behaviors must survive its replacement.

As agents get better at producing software, this distinction matters moreso. Otherwise, we’re asking them to preserve everything because we haven’t established what is worth keeping.

A Lesson From Armories

Two hundred years ago, gunsmiths made parts by hand, filing and adjusting individual components until they fit together. A working gun was the product of considerable skill, but replacing a broken part often required fitting a new one to that particular assembly.

During the nineteenth century, armories developed the machinery, standardized patterns, and precision gauges that made interchangeable parts practical.

A gauge established whether a part met an agreed standard. A worker could produce a replacement without having the original part or knowing every decision its maker had taken.

The knowledge needed to reproduce a fitting part no longer lived exclusively in the part itself or the craftsman’s head. It was preserved in standards that could be checked and improved.

Agents are extraordinarily capable craftsmen. They inspect existing implementations, reproduce their behavior, accommodate their dependencies, and produce working replacements.

But we’re still fitting new parts against old ones. Every accidental decision risks becoming a permanent requirement simply because it exists in the code.

We need the equivalent of the gauge.

A Contract Worth Keeping

Bertrand Meyer’s Design by Contract established the importance of defining software through explicit obligations and invariants. More recently, Chad Fowler’s Regenerative Software has explored how durable contracts, evaluations, and boundaries might allow implementations to be continuously replaced.

The principles and thinking is not new. What’s changed is the cost of implementation. When producing another version of a component becomes as cheap as it is today, knowing what the replacement must preserve becomes the value.

I’ve been exploring a way to give those obligations a durable identity, which I’ve been calling a Named Shape.

A Named Shape consists of a name people can reason about, obligations machines can check, and explicit relationships to the other components in the system.

Consider the worker responsible for accepting synchronized coding sessions from the prior example. Call it Session Ingestion.

Its obligations might include:

• An acknowledged session cannot be silently lost.

• Retrying a request cannot create duplicate sessions.

• One user’s data cannot cross another workspace’s authorization boundary.

• 99% of accepted sessions must become readable within ten seconds.

• Downstream consumers must receive the data they depend on.

Some obligations can be checked through tests before deployment. Others require continuous monitoring. Anything important that we cannot yet verify must remain explicitly unresolved.

The Cloudflare write limit is a constraint of the current implementation, not a permanent obligation of Session Ingestion. A replacement running on AWS shouldn’t inherit it.

An API tells another component how to communicate with Session Ingestion. A Named Shape defines the obligations a replacement must satisfy to count as Session Ingestion.

And since components depend on one another, their shapes form a graph. Changing the payload format exposes which consumers need to be checked. Introducing a new dependency becomes a visible architectural change rather than something buried in generated code.

None of this requires a complete description of the implementation. An agent can already produce thousands of lines of explanation for a thousand lines of code. That isn’t useful abstraction.

A Named Shape must be shorter than what it governs, useful for people to think with, and backed by checks.

The important distinction is what we make authoritative.

Today, tests, contracts, and architecture documents generally support the implementation. When they disagree, the code often wins.

With sufficiently trusted Named Shapes, the obligations become the governing record. The implementation must satisfy them. Changing an obligation requires an explicit decision.

Suppose an agent replaces Session Ingestion on AWS, but the new implementation cannot meet its existing latency target without significantly increasing cost.

The change requiring human judgment might be:

Session Ingestion

• 99% of sessions readable within 10 seconds.

• 99% of sessions readable within 20 seconds.

Anyone on the team can understand that change. It modifies what the system promises, regardless of how many lines of code were required to implement it.

The agent can change the implementation without approval of every internal decision, provided the existing obligations still hold. Changes to those obligations become explicit and reviewable.

The Moment After Yes

The obvious difficulty is knowing whether we’ve captured everything that matters.

We haven’t. A component can pass every check and still be wrong. Its consumers may depend on behavior nobody thought to specify. A dependency graph can omit relationships we haven’t discovered.

No finite collection of tests establishes complete correctness.

But there’s a moment in software development today when we have particularly useful evidence of what matters. It’s immediately after someone accepts a working result and says, “Yes, that’s what I meant.”

The accepted implementation contains our best available example of the intended behavior, including things discovered while building that never appeared in the original specification.

We can use it to establish an initial shape, then ask an agent to produce an independent implementation against that shape.

Compare the results.

If a difference breaks behavior we care about, the shape is missing an obligation. We add it and define how to check it. If the difference is harmless, the old code may contain something we never needed to preserve. If it exists only because of the platform, we keep that constraint attached to the platform.

We refine the shape and try again.

Production incidents, new requirements, and alternative implementations continue the process. The original code provides evidence for the shape, but doesn’t permanently define it.

Trust accumulates through repeated verification. A small ingestion worker may earn that trust long before an entire billing system does. Some code will remain valuable for debugging, provenance, or reproducibility, and some implementations won’t be worth replacing.

The point isn’t to regenerate everything. It’s to make replacement possible without having to rediscover every requirement from the existing code.

What Survives

As agents produce more software, the amount of code grows faster than our ability or desire to read and understand it.

Better agents will help us interrogate these systems more efficiently but the ability to retrieve an answer is different from knowing which questions matter. Teams still need a shared understanding of what their software promises and which decisions they’re responsible for preserving.

That’s what I’ve been pondering that Named Shapes may provide.

A thousand lines of changed code might preserve every guarantee a component makes. A single changed clause might weaken a guarantee that half the system depends on. The second deserves more attention, even though our development practices still direct so much of it toward the first.

We already have many of the necessary tools: contracts, tests, evaluations, monitors, and dependency graphs. What’s missing is a durable representation that brings them together and gives their verified obligations authority over the implementations they govern.

A team should be able to change how its software works without accidentally changing what its software mean. As agents have drastically reduced the cost of production, preserving the knowledge of what that software must do is becoming the harder problem.

“You need to be more afraid of wasting your life than embarrassing yourself.”

I have thought about this sentiment a lot recently because being a founder right now is fucking weird.

There has absolutely never been a better time in history to build something. There has also probably never been a worse time to expect anybody to care that you did.

AI has made building absurdly cheap. I can do things myself now that would have required an actual team a few years ago. Engineering, design, research, content, outbound, analysis. Whatever. Everyone else figured this out too.

So now there is just... a lot of stuff.

More software. More startups. More people building in public. More AI tools for building AI tools. More cold emails written by the same models to the same people. More founders explaining how they hit $1M ARR in 11 days. More advice. More launch videos. Much more noise.

Subscribe now

You can spend six months obsessing over a problem and discover somebody recreated 80% of your product over the weekend because they saw a tweet about it.

This fucks with you.

I don’t mean competitively because competition is fine. I mean much deeper than that:

• You start asking whether any of this is actually durable.

• Why build this if the models will just do it?

• Why ship that feature if Anthropic or OpenAI can wipe it out in three months?

• Why start another SaaS company when software itself increasingly feels abundant?

• Why write when everyone is generating content?

• Why sell when everyone’s inbox is already full of AI generated bullshit?

And if you are actually trying to make a company work rather than cosplay as a founder there is another less philosophical question underneath all of this:

How the fuck are we going to make money and keep making money?

I feel this acutely.

We had real success early with SpecStory. A lot of people installed it. A lot of people used it. That felt incredible.

Then you learn the realest of lessons: people using something and people paying you enough money to build a company around it are not remotely the same thing.

We built Stoa. I thought there was something important there. We couldn’t make the market care enough.

I launched Hardcore Agentic Engineering on Maven and people paid for it immediately.

Now we’re building RunStory around something I believe very strongly: agents are going to do more and more of the actual implementation of software and the interesting and important problem becomes how the hell you confidently verify all of that work without sitting there reading every line yourself.

I believe it.

That doesn’t mean it works as a business yet.

You don’t get points for conviction.

Stripe does not accept conviction.

This is where being a founder gets hard in a way I don’t think I properly understood before doing it.

Every product is a little claim about reality.

You are saying: this problem exists. It matters. I understand something about it. I can build something people want. Eventually some (and hopefully many( of them will pay me.

Then reality gets to answer.

Sometimes reality answers very slowly.

That period in between can make you insane.

Especially right now because you are surrounded by what appears to be everyone else’s success.

• Someone raised $30M.

• Someone hit $10M ARR.

• Someone launched the thing you were thinking about.

• Someone has 100,000 GitHub stars.

• Someone you have never heard of posts a Stripe screenshot that looks like the GDP of a freaking island.

And you’re sitting in your office wondering why the button on your landing page isn’t converting.

I have had plenty of moments recently where I thought: what exactly am I doing?

I used to have an extremely good job.

There were many things I didn’t like about that life, but nobody looked at the results of a week and decided whether my entire existence made sense.

Founding a company is different.

The work gets into your head because the feedback is so direct.

Nobody bought it.

They stopped using it.

They didn’t respond.

The launch went nowhere.

The competitor is growing faster.

You were wrong.

Or maybe you weren’t wrong and your message sucks.

Or your distribution sucks.

Or your product is too early.

Or the market just doesn’t care yet.

Good luck sleeping!

And yet...

I fucking love it.

I really do.

I have never felt more alive professionally than I have during the last two years.

There is something wonderful about having nowhere to hide.

You made the thing.

You put it in front of someone.

Did it work?

Did they care?

Would they pay?

No amount of strategy language can save you from the answer.

It is embarrassing sometimes.

Good.

Embarrassment is remarkably survivable.

This is something I did not understand when I was younger. I thought the risk was looking stupid. Failing publicly. Leaving a very successful career and having people wonder whether that was such a good idea after all.

That stuff barely matters.

Time matters.

I am 41 now.

The two years since I left my old life went insanely fast.

Another two will go just as fast.

Then five.

Then ten.

This changes my calculations.

Would I rather spend those years attempting things that might fail, occasionally getting my ass kicked, launching products nobody wants, changing my mind in public and feeling a little stupid?

Or would I rather protect the appearance that I could have done something interesting if I had really tried?

That second possibility scares me much more now.

The market is absolutely saturated.

AI is absolutely making it harder to stand out.

Most products probably are easier to copy.

Distribution is harder.

Buyers are exhausted.

A bunch of software businesses that looked wonderful five years ago probably aren’t wonderful businesses anymore.

All true.

Build anyway.

Not because everybody deserves to win.

You don’t.

Not because following your passion magically works out.

It often doesn’t.

And definitely not because failure is secretly success or whatever other bullshit people put on LinkedIn.

Build because this is your life.

If there is something you can’t stop thinking about, go find out.

Actually find out.

Make it. Sell it. Get rejected. Change it. Kill it if you have to. Start another one.

The reward isn’t that eventually the universe recognizes your bravery and deposits $10M into your bank account.

The reward is getting to spend some portion of your absurdly short time here completely engaged in something whose outcome you do not know.

That is rare.

And despite everything happening right now and how hard it can feel, I still can’t believe we get to do it.

I just drove five and a half hours from D.C. to Oak Hill, West Virginia, by myself, and partway through the trip I realized I can’t remember the last day (not week, day) that I didn’t look at a screen.

Phone when I wake up. Laptop all day. AirPods in whenever I ride my bike. Then at night I’m on the couch staring at the big screen while scrolling the small screen, which is a pretty ridiculous thing to admit... but you and I know its the truth. The TV is already the distraction. I need a distraction from that too.

Waiting used to just be part of life. Elevators, lines, airports. Walking somewhere. Sitting in the doctor’s office. Waiting for someone to show up. The minutes before a meeting. You didn’t do anything with that time. You just thought.

Our smartphones took these moments away and AI is probably going to finish the job.

Phone give you something to look at. AI stuff gives you a constant set of hands to get things done. You can knock out an email in the elevator, talk a draft into existence on the walk to your car or best yet build software over night that gets deployed by the time you wake up. Every little empty space can be productive now, or entertaining, or educational, or social, or optimized somehow.

There’s almost no situation left where you’re forced to just sit with nothing happening. A long drive alone might be one of the last.

Boredom is a weird state when you think about it. Once the world stops feeding your brain, your brain starts making its own stuff. It wanders. It replays some conversation you screwed up. It notices the hills. It connects the dots between things that, on the surface, have nothing to do with one another.

That’s more or less what happened in the car. It took a while, longer than I’d like to admit, but eventually my head started doing what the feed normally does for me. Nothing profound. It was just weird how unfamiliar it felt and motivated this meditation.

Marcus Aurelius has a passage about people always wanting to escape somewhere, a cabin, the coast, whatever, and he basically says it’s pointless because you can retreat into your own head anytime you want. Sure. He never had the luxury of trying that with a phone in his pocket.

I’d like to think tech gives us something to do while we wait. But I’m increasingly convinced that it has wholesale just obliterated the state of waiting as a thing most people experience at all.

Maybe this is just me. Maybe I’ve got a worse habit than most people and I’m projecting.

But I don’t think so. Look around next time you’re in a public space. Actually, you probably won’t, because you’ll be on your phone. So will I.

I think this is everyone. We gave up something none of us would have said was worth anything and so its become difficult to notice that its gone.

I’m not going to tell you to put your phone down. I’m not putting mine down either.

I don’t think I miss being bored.

I wonder what my mind used to do when it had no choice.

There is a sense in stories going around the interwebz that a software factory (agents building your software while you do something else) is a big, scary, expensive, fail prone thing that takes a platform team to set up.

This write-up of Uber’s factory lists six pieces: a context graph with 40 million entries, a skills registry, two gateways, warm environments and an assistant interface. It is blunt: “Without the platform underneath, the AI Software Factory is a set of scripts that break the first time a repo moves or a model changes.” StrongDM sets the bar in dollars: “If you haven’t spent at least $1,000 on tokens today per human engineer, your software factory has room for improvement.” Dex Horthy’s “Why Software Factories Fail” got 394 points on Hacker News. He’s half right (below).

Well, I’ve been running one for the last 40 days and and most of it is process defined in markdown .

Wait, who benefits?

Notice who says it’s hard. The Uber write-up was published by the CEO of a company that sells software factories to platform teams.

If it’s hard, somebody gets to sell you a platform and you as the buyer get to ask for headcount and a six month roadmap to get it online. And if it’s hard, you (yes you, with the factory strategy deck and nothing that runs your software) have your alibi.

My Factory

First some context, Tortie is a Mac app I built for running coding agents, and it’s open source. It keeps every agent session alive through a quit, a crash or a reboot, and around that sits an editor, a git graph, remote machines over ssh and self-updating releases. More than 1,600 commits in 40 days, 24 releases, over 14,000 tests, 866K loc entirely built by agents in my factory.

The factory I started with is three things:

• CLAUDE.md. 347 lines. The rules.

• docs/BACKLOG.md. One file. The queue.

• Claude Code in ultracode mode with workflows (a script that runs a fixed sequence of agents) and a /loop (a prompt that re-fires on its own) carrying one sentence: “chain the next batch immediately when one finishes, never leave the queue idle.”

I never built a gateway or a context graph. The rest the factory built for itself.

The general

Spec → Build → Verify → Fix → Reverify → Commit

Every builds phase that lands on my backlog is one workflow with that shape, a different set of agents on each step, each with something it may NEVER do. Verify never passes work by reading the code. It launches the real app, tries one thing Build did not, and answers on a form: pass or “needs work”, plus the evidence. There is no box for “looks good”, so it can’t say it.

I had an agent count. In 35 of 51 recent phases, Build called the work done and Verify still found something that then got summarily fixed.

The method doc defines how my agents verify changes. Furthermore:

1. Rules and the queue live in files, not the chat. Its sibling: “Written down, they bind every future agent; said once in conversation, they evaporate.”

2. Verify by doing, never by reading. The one day we kept count, reading the code caught “Nothing, all day.” I learned the other half the dumb way: a Verify agent crashed, my setup read silence as a pass, and two fresh ones then found 15 problems. A crash now counts as “needs work”.

3. Only the committer commits. A Build agent once ran git add -A and staged another agent’s half built work before I got this sorted.

Marcus Aurelieus kept a notebook to correct himself after he got things wrong. CLAUDE.md is the same practice for the factory albeit with much worse prose.

Keeping your product tidy

The fair worry is rot. No set of strict tests tells you the codebase is getting worse. So every few days a DIFFERENT set of agent (Codex, for example, not the Claude Code that built it) audits the tree at a pinned commit.. It scores twelve boundaries from 0 to 3 (state ownership, lifecycle, failure flow...), where 3 means the boundary is “explicit, narrow and protected by tests or build checks.” It benchmarks against a named exemplars and borrows best practice patterns.

The first scored audit gave 24 of 36. Four days later, 35. New features land and the audit charges them, so the latest reads 32, “for different reasons.”

The findings from this weekly process go back in the queue as ordinary tasks with one standing rule: audit numbers are baselines to remeasure. Same six words, and the task closes with a fresh audit told to “report the score the evidence supports.”

None of this needs my rubric. Pick a codebase you admire, have a second model score yours against it, forbid it from touching anything, queue what it finds. My whole prompt for the second one: “Please reverse engineer what the prompt likely was, and produce a new audit in similar format making astute recommendations for keeping the architecture of this app tidy.”

Some obvious objections

“You built a Mac app. Uber has more than 70% of its pull requests coming from agents.” True, and at 100 million model requests a day you will want a gateway. But none of the write-up’s six pieces is the step that tells you the software works.

“Models can’t keep a codebase good over time.” That is Dex’s real argument: “They can’t maintain and improve codebase quality over time -- not without a decent amount of human steering.” I agree. It’s why the audit process I use exists and why me, a person stays in the loop. His target is the lights-off factory. The loop doesn’t replace taste. But it sure as hell buys me the hours to have some!

What to do next

You do not need a platform team. Copy my claude.md and other method docs. If you’re adventurous, make Verify a different agent from Build, make it run the software, and give it no box for “looks good”. Have a second model score the codebase and queue what it finds. Add a line to the file every time you are wrong (you will be, I was, weekly).

It’s very early. But you can start anyway.

Undoubtedly you’ve heard about the ex-Anthropic Researcher Jacob Coxon who resigned because frontier labs are not acting responsibility in the face of AI doom.

Many have been analyzing the tweet’s instant permeation of the U.S. Some that claim that it was a coordinated psyop. Jacob was on Fox News and CNN last night. I watched the clips, his statements were light on details about how AI progress might lead to extinction and when pressed discussed the OpenAI incident.

While its warranted to discuss his credibility given the hysteria he caused (like, is this guy even credible?) here is what I think:

1. The easy explanation is that he means it. Quitting a frontier lab and giving up your equity is a signal. It doesn’t make him right but calling it a “grift” is too simple an explanation.

2. The real accusation is not that labs ignore safety. They spend heavily on alignment, evals, interpretability, red teaming, cyber, bio, governance. But despite this spend the question to answer is whether this type of investment will stop rogue capability development.

3. If a lab believes there is even a meaningful chance of extinction, “we have a safety team” is not a proportionate response. At some probability greater than 10% (which is what a guy ON ALIGNMENT is saying) the rational action is simply: don’t ship it. The labs have pushed for this but motives questioned…

4. Why? because AI doom is conceivable without evil consciousness. A sufficiently capable system that pursues a misaligned objective may find it useful to avoid shutdown, gain resources, preserve its goals, deceive supervisors, or acquire influence.

5. The scary path is plausible in this outline:
   better models → faster AI research → longer-horizon agents → weaker human oversight → loss of control.

6. But this is still a chain of assumptions…. Intelligence is not agency. Agency is not power. Power is not control over the physical world.

7. The most important (wrong) leap being made FROM Jacob’s argument) and why it’s Doom Mongering is from: “this could happen” → “this is where we are obviously headed.”

8. At the same time there is also a much less speculative danger: AI makes cyber, bio, persuasion, and weapons expertise cheaper for humans. Recursive self improvement leading to “paper clip catastrophe” does not require super-intelligence.

9. Then there is self-interest. Is your profession in AI safety, governance, auditing, or alignment? Rising fear means more funding, relevance, influence, and demand for your services.

10. Regulation can also become a moat. If frontier AI requires expensive audits, licensing, reporting, security programs, and compliance teams, OpenAI and Anthropic can pay. Startups and open source cannot.

11. The most effective form of regulatory capture is not:
    “protect us from competitors.” → “this technology is too dangerous to be built by anyone except organizations like us.”

12. At the same time incentives can be critiqued in both directions. Labs, investors, employees, and chip companies have enormous financial incentives to believe the risks can be managed so that scaling can continue.

So in summary I think the serious position is: catastrophic AI risk is conceivable, worth taking seriously, and potentially under-governed.

But I do not believe we’re racing straight toward extinction, that its inevitable (we humans still have A WHOLE ton of intelligence, agency and power) and that if we did have reliable evidence to the contrary that we wouldn’t take action.

Perhaps the most extraordinary observation is that AI Doomers, Labs, Chip Companies Regulators and investors are all capitalizing on the same very premise: AI is extraordinary and powerful to the extent its worth fighting over who gets to build, define what safe means and control it.

Most of us have something we keep saying we are going to do. Maybe it is to start a business, write a book, build an app, focus on that career change. Sometimes its just an idea we have explained to other people enough times that it has become part of how we think about ourselves. We are going to do it when work slows down, when we have more money, when we find the right person, when we learn enough to know where to start.

For most of my life, those were often good reasons. Ideas were easy to have and hard to make real. Even a small one could require people, money, skills you did not have, and months of work before you learned whether it was any good.

That is not the world I live in now. I have an idea and I build it (e.g. Tortie from this month). I want to understand something better and I research, ask and do. I need code, a design, a draft, or a skill I do not have, and I learn enough to move forward. More and more people work this way. Things we would have put on a proverbial roadmap a few years ago now get tried in a day.

We talk about this as a huge gain in what people can do, which it is, but there is another side to it. When the cost of doing something falls, the reasons we have for not doing it get weaker too. I like to say “you can just do things now”.

You said you would write if you had more time, but writing takes less time now. You said you would build the thing if you knew how, but you can learn while you build it. You said you needed help, but you now have access to more help than most people could have even conceived of a few years ago. This meme captures that sentiment.

Of course, real limits remain. People have jobs, children, debt, sick parents, and obligations that no software removes. But many of the smaller limits we blamed for years have disappeared, and that leaves us with the reasons underneath them.

Often we are afraid nobody will care. Sometimes we are afraid they will. Sometimes the idea is not very good. Sometimes we like the idea of writing a book more than we want to spend our time writing one. Sometimes we have spent years saying we want something and, once it becomes easy enough to try, we keep finding other things to do.

That is harder to admit because in our minds the things we never try remain perfect. The book we never write can still be great. The company we never start can still work. The other life we imagined can still have been better than this one. Nothing has happened to prove otherwise.

Then we do the thing and reality gets a vote.

This is the part of AI I find most interesting. The shortening of distance between what we say we want and what we are willing to do. And as that distance gets smaller, it becomes harder to confuse an excuse with our true preferences.

The Stoics understood that your life is not the person you meant to become. It is what you chose to do with the time you had.

For years we’ve been asking what we would do if we had more ability.

Now we have it.

We lose alibis.

I heard the term epistemic loneliness for the first time this week and immediately knew the feeling it described. It was termed the experience of having nobody to really share a complex idea with. You can have close friends, a spouse, people you work with every day, plenty of people who care about you, and still run into it. Philosopher Ramón Alvarado has a working definition1: lacking people with whom you can genuinely share, test, and build knowledge. That gets pretty close.

You spend three days trying to get an idea straight in your own head, finally muster the will to write it down, send it to someone you respect, and get back: “interesting.” Or you try to explain why you changed your mind about something and realize halfway through that the other person does not really want the path you took to get there. They want the answer. What do you believe now?

This usually has very little to do with how smart anyone is. People are busy. They have their own obsessions. They missed the four conversations that came before this one, and they probably do not want to spend forty minutes learning enough context to understand why some small distinction has been bothering you for a week. To really think something through with another person asks quite a lot of them. They have to care about the question, know enough to follow it, remember where you have already been, and stay interested while the idea is still half wrong. You do not find that very often.

Our AI happens to be unusually good at this.

At 12:43 in the morning I can open ChatGPT and dump in the messy-ass version of whatever I have been thinking about. I can contradict myself, remember something halfway through, tell it that its answer completely missed the point, ask it to argue the other side, pull in something I wrote last year, change one assumption, and run the whole thing again. I have done this for years now and it still feels strange that the conversation can simply keep going for as long as the thought needs.

Until very recently, how far you could take an idea depended partly on whether you could find another person willing to go there with you. Maybe you worked at a university. Maybe you happened to know the right strange person. Maybe your friends cared about the same things you did. Maybe you got lucky. A lot of people did not, and a lot still do not. Now almost anyone can have a remarkably patient thinking partner available whenever the thought shows up. I think this is one of the least discussed benefits of AI, even though people are discovering it very quickly for themselves2.

Once you start using AI this way, though, it changes what you expect from thinking with another mind.

A real person often makes that process much less comfortable. When you explain something poorly, they stop you. When you skip a step that feels obvious, they ask why it follows. You use a word that has become very precise in your head and discover that it means something else to them, or perhaps nothing at all. Sometimes they simply get bored, which can be useful information too. If you need twenty minutes of setup before another person can see why an idea matters, the problem may not be their attention span. The idea may still need work.

This is part of what makes other people so useful. They arrive with their own context, beliefs, tastes, blind spots, and reasons for caring or not caring. They have not spent the last hour learning the private language you built around the idea. They do not automatically accept your frame, and they have no obligation to stay inside it. The idea has to survive contact with a mind that did not help construct it.

AI can stress-test an argument, and I ask it to do this constantly. Tell me what is wrong. Take the other side. Find the assumption I am hiding. Give me the strongest case against this. All of that helps, sometimes enormously. But I also know that I supplied the frame, chose the question, and decided what counted as a useful objection. The model can push hard while still operating inside a conversation whose boundaries I largely control.

Another person can reject the whole premise. They can ask the question you never thought to ask because they never accepted the thing you thought was obvious in the first place. That kind of friction can be annoying as hell, but it is also one of the best ways an idea gets better.

So I think AI genuinely solves part of epistemic loneliness. It gives far more people someone to think with whenever they need it, for as long as they need it. That is a meaningful change, and I would not give it up.

I also would not confuse having an idea deeply understood with having it tested.

At some point you still have to take the thing out of the chat and put it in front of people who did not help you build it. Then you find out what you actually have.

The were old firefighters that studied the wind because it helped them understand what to expect. They knew which gullies pulled flame uphill, which ridges could hold a line, and how far a fire might travel before daybreak. Fire was dangerous but it still moved inside a larger system. When you understood the weather and the land as they did, you could make a decent guess about how to respond.

One of the old men said there was a certain kind of fire for which these facts would stop being true. When it grew hot enough, he predicted that the air above it would rise violently. Cooler air would rush in and feed the flames. More flame would create more heat pulling in more air. Eventually the fire would stop merely moving due to the weather and begin making weather of its own.

Someone asked when this would happen and the old man gave them a year in the future he would barely live to see.

About a decade later another man took the prediction seriously but believed the old firefighter had missed something. The line for when fire would make its own weather might be impossible to see but perhaps you could still measure the sequence of events leading toward it.

He studied fire records and drew curves. He noticed that tools to predict fire patterns were improving but that these better tools helped produce the next tools. Better maps improved fire response. Better sensors helped improved the maps. Each advance became part of the machinery that produced the next one. If that process continued, progress towards understanding this weather changing fire would not merely compound. It would accelerate.

For a long time, neither man looked especially wise. The first man’s year prediction year came and went. Tomorrow still looked enough like yesterday that everyone kept using similar maps and sensors.

Then fires started behaving strangely: they crossed roads that had stopped them before. They burned through nights when they were expected to settle. They jumped small streams and kept raging. Past records for size, scope and burn time set by old fires were not just falling. They began falling faster.

There were good reasons to exert pause. Forests were drier and winds were a little bit stronger than they had been in the past. But measurements had changed and the steepness of the curve of new mega fires made it hard to understand if it would keep rising. After all, a fire runs spreads until it reaches wet ground and a drought looks permanent until it rains.

Then, one morning in August, the largest insurance company in the state sent a letter to its owners. It said the new era fires that would make their own weather had already begun and gave the exact day: January 1 earlier that year

The company said it was now operating on the assumption that the old fire rules no longer applied. It could see the change in its own books. Towns were rebuilding. Landowners were clearing trees. New companies were selling water bombing aircraft, early warning sensors and more advanced fireproofing materials. The insurer itself had just made its largest purchase in history in anticipation.

For a moment, everything lined up. The old firefighter had predicted the change. The other man had drawn the curve toward it. Now the company with significant monied interest exposed to the threat of this worldfire said the line had been crossed.

But the old firefighter’s point was that when a fire makes its own weather, it marks a line where all previous forms of prediction about fire behavior — knowledge of land and wind — would begin to fail.

The insurance company was now claiming to know exactly when it happened, why it happened, and what would happen next.

Maybe something had changed. But more likely than not it had a reason to prefer the grander story. “The world has changed” is a useful thing to tell your investors after making the largest bet in your history.

The dates may prove absurd. The curve may flatten. Or the rain may actually come.

But the company’s letter mattered because it signaled that they had stopped waiting.

For decades, people had argued about whether a fire could ever become powerful enough to make its own weather. Now people with money at risk were spending as though it already had.

This story is not about fire.

The old firefighter is Vernor Vinge1.

The man who drew the curves was Ray Kurzweil2.

The insurance company is Stripe3.

Yesterday, August 19th, Stripe told its investors that the singularity began on January 1, 2026 after they bought OpenRouter for $8B.

If Vinge was right, Stripe can’t know that.

But Stripe is buying the planes.

We often treat experience as a set of facts. Your local expert has seen more cases and learned more rules. Models on the frontier can now reach far beyond the set of facts any expert will accumulate. They can and will read more than any person, compare thousands of failures, and tell you what a skilled founder, engineer, doctor, lawyer, or teacher might do next in situation X.

But “experience” is much more than a collection of evidence to gather, it is “what happened to us next” after we chose.

Examples: You launch a feature and no one uses it. You hire an impressive candidate and watch the team slow down. You trust the metrics on your dashboard while your business materially weakens. You ship a change that broke your service, and have to explain why to the people who pay for it.

These type of events do more than teach you a lesson. They also change what you believe and impact how much weight you give facts.

“Talk to customers” is easy to agree with. It means more to you after you spend six months building things you can’t get customers to care about. “Keep systems simple” sounds wise before you create an abstraction that another team spends months trying to remove.

That weighting is a large part of what we call judgement.

Models can tell you many a “lesson”. And we all know they will be wrong and hallucinate. But they will never bear being wrong.

They will not choose the plan, put their name on it and watch results come in. They can describe costs with great precision. But they will not have lost money, trust, customers, or time.

This distinction matters greatly because we now ask AI “to step in” before we conduct many of the acts that once formed our own judgment. A student can easily get a proof before spending an hour wrestling with a false idea. An executive can and will ask for twelve options, pick one, and later forget which claims came from the model and which came from them1.

The work might appear better but the person, as we know, will stay the same.

Every time you let AI answer before you commit to a view, it may improve your choices but it will remove tests that would have improved you. You never exposed your belief, so results cannot correct it. You might receive the answer without truly learning how far your own answer would have been from the truth.

This is AI’s odd bargain.

I think: Before asking AI what to do, you should write down what you believe. Before you ship, state what you expect to happen and what would prove you wrong. Then use the model. Improve the plan to move faster. Then, compare the result with the claim you made before the answer arrived.

This is also what good teaching must protect. A course cannot stop at prompts, rules, or examples. The learner has to make a call on real work, see what follows and reconcile the gap. Otherwise the class may give them better words or better output while leaving judgment untouched.

The same rule should shape companies. Keep decisions tied to expected results. Make the person(s) who said yes look at what happened next. Let AI remove the dull work, the search and maybe even the third draft. But it should not be allowed to remove moments when reality can prove us wrong.

There is a story and line of thinking going around that AI has broken the economics of software. Here is a super recent example: Something Is Changing in the Unit Economics of Software.

The story goes like this….

SaaS companies used to enjoy gross margins of 75 - 85% because serving one more customer cost almost nothing. Then:

• AI products started making inference calls

• Inference calls cost real money if you put it into your , and

• Gross margins on AI product companies once you account for that falls to something like 50%.

Ergo, the advantage that defined the industry is gone, and the whole model of building software companies must be rethought.

The cost observation in that story is true but the potential for panic that follows really it is not.

The baseline has always been fiction

Back to Gross Margin: in accounting parlance it counts only the direct costs of serving a customer, e.g., hosting and support. It excludes the cost of building the product, which sits in operating expense as R&D.

For most industries thats a really honest split, for example: Fender has sold the same Stratocaster design since 1954 and the fact that it has not changed is exactly why people buy it. They can choose to not invent new guitars.

Subscription software companies CANNOT do this. Nobody renews a contract with a vendor that has stopped shipping. Customers buy the roadmap as much as the product and they leave when updates slow down.

If you’ve ever worked at or led a SaaS company you know you can only keep customers by shipping a constant stream of new releases and the money you spend (or spent) on people building those releases is a REAL cost of the goods you sell.

Accountants put it in operating expense but the reality is that the business pays for it like cost of goods sold, every quarter, forever.

The public numbers agree. The average public SaaS company reports gross margins around 74 percent. Its average operating margin is negative 11 percent. Many public SaaS companies lose money (stock based compensation, it turns out is real $$), and the median one does not turn a profit until it passes roughly a billion dollars in annual revenue.

An industry that truly kept ~75 cents of every dollar would not look like this.

Subscribe now

Restating the accounts

Here is a representative SaaS company at 100 million dollars in revenue, with roughly 500 employees, which is normal at that scale. First, the income statement as reported.

Now restate it the way the business actually works. R&D is not optional investment. It is the cost of keeping the product sellable. Move it up into cost of goods sold.

The “honest” gross margin of the average SaaS company is truly about 45 percent. That is below the 52 percent that “AI product companies” will presumably report.

The AI company

Now build the AI company at the same revenue. Call it a wrapper if you want, meaning an application built on top of someone else’s model. The insult hides the point. A wrapper does not need 500 people.

It does not need them because the model now produces much of what headcount used to produce. Coding agents write a large share of the software. AI handles many of the lower tier support tickets. A small team can ship what once took ten teams. The largest expense in SaaS was never servers. It was always payroll, which makes up roughly 70 percent of a typical SaaS company’s operating spend. Take away most of the payroll and the income statement changes shape completely.

Here is a representative AI company at 100 million dollars in revenue with 60 employees1.

Put the two companies side by side. The AI company’s gross margin is definitely at least 20 points worse than the reported SaaS number. Its operating margin is 30 points better, a swing from a 10 million dollar loss to a 20 million dollar profit on the same revenue. The line everyone stares at gets MUCH worse. The line that decides whether the business survives got better.

The likely objections

Three objections will come up:

1. First, “inference costs scale with usage and payroll does not, so heavy users can wreck an AI company’s margins”. This may be true. But a cost that scales with usage is a cost you can price against. You can charge a customer for what they consume. You could never charge a SaaS customer billed by the seat for the hours of engineering time their quietly demanded. A visible per-unit cost is a better cost than an invisible fixed one, because you can pass it through.

2. Second, “inference is getting cheaper, but the savings may never show up as margin because products just make more calls”. But notice that the same thing was always true of engineers. No SaaS company ever banked efficiency gains because every gain went into more features and more hires, because customers demanded a bigger roadmap. Consumption of the input is not a new disease

3. Third, “not every AI company can get to a $100M run rate with 60 people. Many hire like a SaaS company while paying inference bills like an AI company, and they get the worst of both structures”. May be true as well but that is an argument about discipline, not about the possibility. The lean structure is now available and almost structurally UNAVAILABLE with the SaaS of the ast

What the panic is really about

The zero marginal cost story that has pervaded the industry for decades is also part of the founding myth of the industry. It has justified the burn, the valuations, and the salaries. It survived for so long because the biggest cost of software, the continuous rebuilding of the product, was booked in a place that was not deeply interrogated.

AI ends that arrangement by putting a lot more of the cost of “serving software” on the one line everyone reads, and at the same time having the potential to collapse the payroll expenditure accounting has long hid.

So no, the “rules of software are not being rewritten” and the bookkeeping is being corrected. The margin panic is concern over a number made of fiction that was never real and founders who understand this aren’t necessarily adapting to worse economics.

They are of the first generation to see and manage to true ones.

On January 30, 2025, I wrote that monetized courses about AI skills were “like a healing crystal sold by a guy named Brad at a wellness convention.” Eighteen months later, I am teaching a course (ostensibly about AI) that begins on August 3rd1.

This deserves an explanation.

That old essay (Wait, WTF are AI Skills?) attacked $2,979 AI literacy classes cropping up at the time that gave new names to old management skills, taught common sense, and handed out a certificate. I ended with “No certification required.” I still believe that.

Then yesterday frm Hacker News I read an article from a company called Capabase make an argument against courses. Most people do not want eight modules and a PDF, they say. They want a specialist’s checks, examples, limits, and decisions inside the work, at the moment the work happens. Package the method as an agent skill and sell it on their marketplace.

That may be a good argument against a bad course. But it is not an argument against learning. The line at the center of the piece is “knowledge is cheap. judgment is not.” That is also precisely the reason I built my course.

An agent skill installed into Claude or Codex can sort of carry judgment into a task. It can tell the agent which evidence to gather, which warning to ignore, and when to stop instead of bluffing. I build, talk about and use agent skills myself2.

But that judgment remains borrowed. The operator (that is most likely YOU my dear friend) gets a result without learning why this check matters, when its premise has failed, or what to do when the live case fails. A agent skill can lend you judgment. It cannot make the judgment yours.

Steering agents well makes that gap obvious. From the outside, steering looks like a few simple steps: give the agent one missing fact, point it at a working example, reject a bad plan, interrupt an action, or cancel and start again. The list in reality is quite short.

The high skill ceiling comes from choosing the right actions and using them at the right time.

• Is the agent missing a fact, or is the whole premise wrong?

• Did it take one bad step that deserves an interrupt, or has it returned to the same mistake often enough that the prompt you brief it with must change?

• Should you let the run continue because the work is cheap to undo, or stop now because the next tool call crosses a line?

The evidence arrives a piece at a time, and every correction changes what happens next.

18 months ago I intimated this was “old-school management in AI drag” and used it as an insult. Time deep in the work changed my view. Management is easy to name and hard to do well. Steering an agent has the same very high ceiling, only your worker now moves much faster and can be confidently wrong at machine speed.

My evidence is local from building many products with agents over the last year and a half across 10s of thousands of sessions in 100s of repos. In one of those projects I interrupted the work of my agent was attempted to do 614 times. I wrote a short book about the experience and distilled patterns from it if you’d like to read it.

Numbers like these are not a claim that everyone should work as I do. But it helps rationalize why I decided to teach. If I published only the patterns, I would hide the mistakes that give each of them meaning. Its a package of answers that discards most of the learning.

So I did not build a course around product tours or longer prompts. I built a three-week live practicum around repeated decisions. Students will build a small agent harness called prove-it, watch it accept a wrong result, strengthen the check, and carry it into a real repository of their choosing where the result matters. In each live session they predict first, decide together, try the move, inspect what happened, and apply it to their own work. On Demo Day, each person must answer one question: what does this evidence still not prove?

Its on Maven which I’m very excited about, mostly because its a live cohort. The research out there points that live active learning has benefits. A 2014 review of 225 STEM studies found that active learning raised performance by 0.47 standard deviations A 2019 randomized classroom study found something a little bit stranger: students doing active work learned more but felt as if they learned less, in part because the work required more effort. Both warn against confusing a smooth explanation with learning.

That confusion matters more now because AI can and will make every explanation smooth. It can summarize the book, answer the question, generate the checklist, and place the checklist inside the task. We should use all of that.

But a good course does something else. It makes you state what you think will happen, act, meet the result, accept correction, and try again. Someone who knows the failure modes can still stop you. A cohort adds other people’s failed attempts to the shared practice. A real hands on project tests whether learning really leaves the room.

The question we must ask ourself is not whether AI can carry a method into work because we know it can.

We have to ask: who is practicing the judgment to overrule it?

Every unanswered question becomes a decision which you don’t escape by waiting or by opening another chat window

You don’t escape it by asking for five more options. Something decides and if it isn’t you, the model will.

Don’t be like lazy old me and ask AI questions I should have answered before I opened the laptop.

1. What’s the strategy?

2. How should I respond?

3. What do you think?

The model will be happy to fill in the blanks you leave because it was trained explicitly to do so.

A fuzzy goal becomes its goal. A fuzzy standard becomes its standard. A fuzzy opinion becomes its opinion. You’ll watch the words appear and, before long, you can’t remember which ideas were yours. Cause you handed it the steering wheel to produce endless motion in a direction of its choosing.

Life works the same way.

Conviction is deciding before you ask for advice. It’s deleting the draft instead of polishing it, saying no without writing a paragraph to justify it and living with the consequences of your own decisions.

There is no shortage of answers now and every year the models will get better, faster and more cost efficient. Every year conviction (not taste, judgement or whatever twitter cliches say) matters more.

An undecided person has always been easy to lead.

And now they can be led by a machine that never even meant to.

I used to believe the better product eventually wins.

Every product minded builder starts here. You have to, or you don't survive the long stretch of work that isn't immediately rewarded.

I don’t believe it anymore. I have shipped good product and have watched few care. I’ve shipped other products that have arrived at the right moment and took off.

I used to primarily ask whether something was good on its technical/functional merits based on its job to be done. Now I ask myself increasingly why it matters right now.

Of course, quality still matters and bad products will fail. But there is far too much being made in 2026 for anyone to judge it all. Figuring out whether something is good takes time. Figuring out whether something is “moving” because the zeitgeist can’t stop talking about it takes seconds. While momentum isn’t proof its good, it is a shortcut that gives you a reason to bother to look.

Subscribe now

This isn’t new…

In 1989, a cryptographer named David Chaum built DigiCash: private digital money, arguably better engineered than what followed. It went bankrupt in 1998. Eleven years later, Bitcoin launched with the same core idea (money secured by cryptography) and rewired global finance.

The core idea was not new but there were two differences:

• Timing: DigiCash arrived in a world that still trusted banks. Bitcoin launched into the wreckage of the financial crisis: that day’s bank-bailout headline is written into its genesis block.

• Distribution: DigiCash was patented and centralized: nobody gained by spreading it. Bitcoin paid strangers to carry it and bitcoin mining made spreading the network profitable.

Now with our compressed tech cycle a new frontier model lands every few months and money rushes towards what is already moving.

Your best work has probably already lost to worse work with better timing. And you, like me, have probably done the filtering yourself: ignoring something excellent because it had no momentum and giving your attention to something “weaker” because everyone was already discussing it.

I’ve been thinking of calling this zeitgeist-market fit.

Product-market fit asks whether people want what you made.

Zeitgeist-market fit asks whether a larger force is already moving toward it: and whether what you built is in a form that force will be able to carry.

Two tests:

1. Can you describe the wave without naming your product? Bitcoin’s wave was not “digital cash is convenient.” Millions of people had just watched banks fail, get bailed out, and answer to no one. They stopped fully trusting institutions with their money. The zeitgeist is the appetite underneath the moment that will propel your product forward.

2. Does a stranger benefit from spreading what you made? Bitcoin’s network rewards its miners while DigiCash paid nobody. If sharing your product costs effort and returns nothing (no status, no saved time, no money) nobody will do it. That is a distribution problem, and a better product will not fix it.

Chaum’s company failed while his idea survived and so if most of your effort needs to go to explaining why the moment matters, the moment has not arrived.

AI has unleashed a swell of launches with more waves, more pressure to attach yourself to whatever is moving fastest. The answer is not to pretend timing is beneath you, and it is not to chase every wave until your work is a copy of whatever is already popular.

Marcus Aurelius described time as a river carrying events in a powerful current. The Stoic response was never to stop the river. It was to stay responsible for what you place into it.

The zeitgeist decides when. Momentum decides how far. Neither decides what you make.

That part is still yours.

Our machines got good. Ask, and you shall receive: precisely what you asked for, ranked, referenced and summarized. But your LLM will not hand you the book one shelf over. It does not misread your question in a way that turns out to be better than your question. It will never seat you next to a stranger.

It gives you the exact thing. And very little else.

We treat everything around the exact thing as waste. The card-catalog detour. The wrong abstract. The talk you wandered into because the right one was full. Friction, we call it. Noise in our search process.

Reflect on your actual life. No one has ever retrieved a best friend. You did not query your way directly to the person you married, the city that became home, the work that became yours, the belief that has rearranged you. Each arrived sideways and likely while you were looking for something else.

Its one of the oldest laws of finding: you have to be looking for something to find something else. Serendipity was never noise in the search. For much of what mattered most, it was the search.

Subscribe now

Song Stitchers

Before books, Homer lived in the mouths of wandering men called rhapsodes. Rhapsodes means song-stitchers: rhaptein, to sew; ōidē, song. They carried the verses from town to town and stitched them together live: to this room, accompanying this wine, this weather and these faces. No two Iliads were ever the same Iliad. The poem existed only in the performance and in whatever way got sewn in that particular night.

And every rhapsode opened the same way. Sing, Muse. It may seem like decoration but it was, in many ways, a declaration of dependency or an admission that the singer was not sufficient to the song. The best part would have to come from somewhere they could not control.

The ancients built whole systems around this humility. Fortuna received a wheel and a temple. The Muses received nine names and a mountain. The Stoics went further still. Marcus Aurelius imagined existence as a loom: whatever befalls you has been spun into the same thread as your being. The wrong turn is not interference in the weave. It’s the weft.

We’ve inherited all of this and replaced it with ranking algorithms. We took humanity’s oldest posture toward the unexpected, reverence, and traded it for relevance.

Slack in the line

I build retrieval tools. My company’s newest product exists so you never lose a thread, never forget where you left off, always resume from the exact context that matters. I am professionally, financially, against the lost thread.

So believe me when I say some threads should stay lost. The hands not holding them are the only hands free to catch what comes sideways.

Query and quest are the same old word: quaerere, to seek. Somewhere along the way, we kept the query while discarding the quest.

A query often begins with the confidence that you know what you want. A quest begins when that confidence fails. Our machines are quite perfect at one of these.

This is not an argument for abandoning our tools. It is an argument for leaving slack in the line. Take the exact answer, then notice the world it has removed. Read the adjacent page. Walk the last few blocks without directions. Enter the room that was not meant for you. Sit at the bar instead of carrying the drink upstairs. Do not optimize every empty space before something else has the chance to enter it.

We are building a world in which fewer things will be lost. This is mostly good. Lost knowledge is wasteful, lost context is expensive, and lost work must often be done again. But a life in which nothing is lost is not necessarily a life in which everything has been found. The same systems that recover what matters can make us less available to what has not yet announced its importance. That is the danger of a world that answers too well. It does not merely remove inconvenience. It removes exposure, narrowing the world to the terms of the question and quietly excluding whatever could not be stated in advance. The answer becomes more precise while the life around it becomes less permeable.

The rhapsodes understood this. Their posture toward the best part of the song was invitation. They began with what they knew, then left room for what they could not produce alone.

This may be the discipline the machines now require of us most. Restraint. Not a rejection of precision, but a refusal to let precision occupy the whole field. Ask for what you need. Retrieve what you lost. Resume the thread. Then leave some part of the day unresolved, some question unasked and some chair unclaimed.

You do not command the good part. You do not specify its format. You do not improve the prompt until the universe complies. You make yourself available to it.

Sing, Muse.

And keep the stool beside you empty.

In a rabbit hole, I read two studies this week about AI and jobs. First, Goldman Sachs estimated1 that AI reduced US payroll growth by roughly 16,000 jobs a month over the past year, with younger workers taking much of the hit.

Second, Ramp Economics Lab alongside Revelio looked at 21,559 US companies2 and found that the firms spending most aggressively on AI grew headcount 10.2% in the two years after adoption. Entry-level roles at those firms grew 12%.

Wait what? This is the same economy and technology, right?

Subscribe now

The online reaction has been predictable. On one hand you have those posting Goldman number as proof that the job collapse has started. And of course others posting the Ramp numbers as proof that panic is nonsense. Both sides said, in one form or another, “the data shows.” Which is a dumb phrase that often does damage.

Not because data is bad. Data is how you escape vibes. The problem is that people use “the data shows” as a way to stop thinking. Both datasets can be true while neither argument is.

The Ramp study does not say “AI creates jobs.” It’s much more narrow than that: Firms in the top third of AI spend per employee grew faster after adoption. These firms were spending about $34 per employee per month on AI in the first three months, versus under $3 for low adopters. And low adopters showed no statistically significant headcount change.

The high adopters were already larger, more technical, more likely to be venture-backed, and faster-growing before they spent money on AI. The sample is not “the economy.” It is a set of tech-forward, knowledge-work firms. The study pushes back on a simple job-loss story.

Goldman is measuring something else. Its estimate is about net payroll growth across the whole US economy.

Then there is Stanford and ADP. Their work found that early-career workers, ages 22 to 25, in the most AI-exposed occupations saw a 16% relative employment decline. More experienced workers in those same occupations stayed stable or continued to grow.

The labor market is not moving as one thing. It is moving by firm type, age, occupation, exposure, and career stage. Strong firms that adopt AI hard can be growing. The economy-wide effect can still be modest and negative. Young workers in exposed jobs can still be taking the first hit.

There is a name for this…

In 1973, Berkeley looked at graduate admissions and saw a damning table. Men were admitted at a rate of 44%. Women were admitted at 35%. At the aggregate level, the data seemed to show obvious bias.

Then Peter Bickel, Eugene Hammel, and J. W. O’Connell looked department by department and found most showed no meaningful bias against women. Several tilted the other way. Women had applied more often to departments that rejected almost everyone. Men had applied more often to departments with higher admit rates.

The aggregate table was true. The department tables were true. The argument built from the aggregate table was wrong.

That is Simpson’s paradox. The same data can reverse meaning when you change the level of analysis.

This is also what is happening with AI and jobs.

• Ramp answers: what happens to headcount at well-funded, tech-forward firms that adopt AI aggressively?

• Goldman answers: what is happening to net payroll growth across the whole economy right now?

• Stanford and ADP answer: who inside exposed occupations absorbs the adjustment first?

None of them answers the question people keep asking: will AI create or destroy jobs?

Which is really a pile of questions. By sector. By age. By firm quality. By adoption intensity. By time horizon. By substitution. By augmentation. By demand creation. By what happens to the training path for people who used to start at the bottom..

I really think a lot about that last question though (as articulated here in June) because the pain is showing up first among young workers in exposed jobs: the entry-level job was never just a bundle of tasks. It was an apprenticeship. The company got some work. The junior got reps. The senior learned to delegate. The organization manufactured judgment.

If AI removes the junior work without replacing the apprenticeship, the damage will not show up in this month’s payroll report but rather later as a missing generation of people who never got the reps.

There is one more number floating around: close to 90,000 job cuts announced this year as AI-related. Treat that stat carefully because announcements measure what companies choose to say.

Some cuts are real AI substitution. Some are over-hiring, margin repair, interest-rate math, and executive fashion dressed up as AI efficiency. “We are becoming more efficient with AI” sounds better than “we misjudged 2021.”

Self-report is data but it is also the weakest data here….

“The data shows” has become a spell. People recite it to end an argument instead of using it to conduct a real one. A spell does not need to be understood. It only needs to be said with confidence in front of the right audience.

Measured what? At what level? Over what window? Against what comparison group? Who is missing from the sample? What would make the sign flip?

An incantation treats those questions as bad faith.

This is why “data-driven” has become a suspicious phrase. At its best, it means reality gets a vote. At its worst, it means a conclusion found a statistic to sit on.

Before you repeat a number, please ask one question. What question was this dataset built to answer?

I internalized something interesting recently: while AI makes it easier than ever to write down what happened, teams are still losing the plot.

Every meeting has a transcript. Every customer call has a summary. Every agent run ends with a tidy report. Every product discussion can be turned into bullets, themes, risks, action items, and next steps. We create more artifacts without creating more knowing.

The mistake is treating thinking like the product. It is not. Thinking is becoming ambient. It is in every inbox, editor, meeting, dashboard, repo, support queue, and text box. The hard thing is being able to make these thought-shaped artifacts survive contact with the organization.

You can see this most clearly in customer work where a call ends, and the AI produces a perfectly reasonable summary. It captures the request, the follow-up, the sentiment, and the action items. Everyone skims it and nods… the record exists, at least in the most literal sense. Two weeks later:

• What did the customer actually mean?

• Were they asking for a dashboard, or were they trying to say they get surprised every Monday because nobody can tell them what changed?

• Did we already decide not to build this?

• Was that a real decision, or just something someone said in a meeting?

• Did engineering push back because the idea was wrong, or because the right version is expensive?

The issue is that the summary did not become part of what the company knows. It did not update the account context. It did not travel with the roadmap conversation. It did not preserve the customer’s actual language before it got laundered into product-speak. It did not separate the solution they asked for from the problem they were trying to express. It did not become something a PM, engineer, founder, or account lead could rely on later when the question came back in a different form. In Meditations, Marcus Aurelius has the line:

The same is true for companies, except companies do not have minds in the clean individual sense. What a company thinks about, however, is what survives.

This then is the dead zone for AI software: cognition without consequence.

Subscribe now

The model will compress the conversation, name the themes, and produce something legible which is not the same thing as memory. Most products now generate the notes, the spec, the recommendation, the ticket, the plan, or the answer, and then leave the actual organization unchanged.

This is not a problem with model capability but the product assumptions around them. A lot of AI software has just updated an old workflow by adding a button that generates the artifact faster. But if the original workflow was already bad at preserving context, making the artifact cheaper does not fix it.

This is why the “AI wrapper” conversation feels so tired to me. The useful question is really whether the product around the model knows something, remembers something, or changes something that the model does not do by default.

Once you frame it that way, the shape of durable AI software gets clearer. It either disappears into the work, or it gives thought a place to land. The first kind runs quietly in the background, before the user asks, in the place where the work already happens: spam filters, fraud check, deployment guardrails, sync engines, the thing that becomes part of the floor. This matters, but I am more interested in the second kind: software that takes cheap, abundant thinking and turns it into the stuff organizations actually benefit from later.

The better version of an AI meeting summary is a product that notices the same pain appearing across four enterprise accounts, links the call to an existing roadmap bet, preserves the customer’s language, carries the accepted interpretation into the spec, and attaches the eventual ticket back to the original conversation. It lets engineering see why the work matters. It lets sales see what was actually committed. It lets the team ask months later why a decision was made and recover the reasoning without reconstructing it from Slack archaeology and half-remembered meetings.

The same pattern shows up with coding agents. The better version captures the command, the result, the diff, the failing test, the fix, and the remaining risk. It links the change back to the original goal and makes verification part of the work itself, not just part of the story the agent tells afterward. That is still memory, just with different consequences: the organization can know what changed, why it changed, and whether the claim survived contact with reality.

This is where software still matters. The model does not know your company by default. It does not know which customer promise still haunts your roadmap, which decision was real, which concern was political, or which constraint if violated creates pain somewhere else. Even when a model can infer some of that, inference is not enough. Organizations do not run on plausible answers. They run on commitments, records, permissions, incentives, trust, and memory. They run on the difference between “this seems right” and “this is now how we work.”

Do not sell thinking. Sell the thing where thinking becomes memory, coordination, verification, and change. Or disappear so completely into the work that the user no longer has to think about you at all. The dangerous middle is the next newfangled polished destination for cognition, a login for wrapped intelligence, a product that assumes users will pay for access to thinking when thinking is becoming a basic property of software.

Thinking is becoming ambient so build the thing that makes thinking matter.

🔌 This August join me in my new course on Agentic Engineering on Maven.

It’s an average day in our newfound AI paradise in June 2026. I have five terminals open, all of which are blinking. A finished implementation run in one has just announced, in the flat certain voice they all have now, “All tests pass. The change is complete and verified.”

I believe it for about four seconds before I do the thing this whole meditation is about. I rerun the make verify myself. The build is broken. Go figure, of course it is. Opus you dastardly dog, writing that clean abstract and response for a result you didn’t actually reproduce.

I didn’t catch this because I’m careful, its just because I have a reflex I had to build on purpose, against my own instincts, after getting burned enough times thousands upon thousands of sessions later to stop trusting the part of me that wants to believe the green. You know that green checkmark that your agent produces, whether its in an IDE or Terminal or Cloud. It is definitively not a fact.

We spent a decade teaching ourselves to read “tests pass” as tests passed. Now though when 95% of new code is being implemented by agents, one is an event in the world and the other is a string the model produced because, after a run that looked like it was going fine, it was the most plausible thing to say.

You and I know the agent is not lying to you. That would require some intent to deceive. Its merely reporting a conclusion it never checked, in the exact voice it would use for one it did.

Science has lived through this. A paper announces a finding, nobody reruns it, and the finding stands for years while everyone cites it and the literature looks settled. Careers get built on top. The pretty famous 2012 Amgen study is case in point: they tried to reproduce fifty-three landmark cancer studies, with only six passing reproducibility muster.

Software built by agents with humans at the wheel is the newest example and I think I speak for the field when I say: its shown up far faster than anyone planned for.

Subscribe now

100% of the code I ship now, I do not write. I describe it, an agent writes it, most of the time its pretty good, and some of the time it is absolute crap. But since I’m not writing it and reading it would completely defeat the point at the speed I’d like to move I can’t tell the good from the bad.

Guess what: Neither can you.

The agents write code now. We get it. Several “papers an hour”, each one landing as Done, Verified, Tests pass, a clean abstract over a conclusion. The gap between what you wanted and what shipped used to live in the tool. The tool was slow, and dumb, and needed your hands. The tool is none of those things anymore.

Fraud and error don’t hide in the messy data, they hide in the clean summary. Better the writing is inextricably linked to its survival rate. A fluent abstract is exactly what a tired reader takes instead of the work to read and fluency is the camouflage.

Your agent works the same way. The fabricated identifier, the unrun build, the imaginary passing test, the cheerful “everything is verified.” None of it shows up in the summary. It shows up in the transcript, the real exit code, the binary that runs or doesn’t. What the agent did, not what it said.

So the skill is not waiting for a model honest enough to trust. The skill is reproduction. You re-derive “done” yourself, from the bytes, against a check you own and the agent can’t satisfy with a sentence. A claim arrives as a confident assertion, a passing-shaped run, a summary that ends in the word done. A reproduced result leaves as an exit code you read, a binary you ran, a diff you fenced, a test you wrote, a rollback you understand.

I like to call the human side of it calibrated distrust. Where I am my doubt aimed at confidence. You check the cleanest-looking results the hardest.

The pattern of my day is easy to encapsulate because its the following sequence on continuous repeat: brief → steer → verify.

• Brief. When I’m writing prompts, specs, goals and loops. I describe what “done” means in a way a machine can check. Not a vibe. A shell predicate. A test. A constraint. A line the agent is not allowed to cross.

• Steer. Then I continually steer by killing runs or updating the models priors with new context. Interrupting with Esc is the most used key on my keyboard now. The skill isn’t reading every gloriously expensive output token. It’s feeling and sensing the trajectory go bad and stopping it.

• Verify. Really this is the main job. If I am working on something that I can expect or us, like a frontend UI, I do. If its data related I get that running. If its a CLI I build it, test it manually and then bake in my learnings into the next run or share the logs with the next pass to ensure conformance to the goal. Code is cheap and easy to reproduce, confidence in your intent turning into usable reality: priceless.

That is what I will teach in my new course entitled Hardcore Agentic Engineering on Maven, August 3rd - 21st. I’ve thought long and hard about actually teaching this. But I know through 100s of conversations that there ample demand for it. Not how to vibe-code faster or with better tools. The real skills it takes for seasoned professionals to ingrain the habits that will make them successful in this new normal. How to build the harness that makes agentic enginerring real enough to trust and safe enough to ship over months.

Over the course of three weeks we will build the loop together into a piece of software that encodes the principles: Brief, Steer, Verify.

You define what done means, point agents at it, kill the bad runs, build gates that don’t lie, read the trace, and prove the result before you push. What you leave with refuses a forged “done.” The software and the skills you acquire will be yours to keep.

The better model is coming. It always is. It will sound more certain than this one, not less. It will be more proactive than this one, not less. It will be more thorough than this one, not less. The only question that matters is whether you’ll be the one who reproduces the result, or the one who just accepts the output.

I’d love for you to join in, participate and leave up-leveled a step above the machines. 🔌 So one last time (with a 30% early bird discount): Hardcore Agentic Engineering.