Always focus, but only sometimes

When I first broke ground on the codebase for Woodrow, I was terrified at the idea of doing anything devopsy. Managing machines, certificates, alerting, and the AWS interface were all the kinds of work that I didn’t want to touch with a 10 foot pole. So, I chose to start with Heroku, and it let me get going on the parts that I wanted to spend time building, quickly. In a sense, I was paying an ignorance premium to rent their competence.

Recently, I was building a little tool for myself to get better at my poker hobby, and since I was doing everything else with Codex, I asked it to put it on a Hetzner box for me. And … it just did. No fuss about it, and the whole process was waaay simpler and cheaper and under my control than using Heroku.

Subscribe now

My fear of devops was a tax on ignorance, and ignorance just got cheap.

LLMs have made you:

• A little better at what you did exceptionally

• Way better at what you did pretty well

• Wildly better at what you did just okay, and

• Insanely better at things you didn’t know how to do

Working outside your superpowers used to be counterproductive. If your talent was building apps quickly, it made most sense for you to spend time coding, and to outsource the design to a contractor to get it to look passable. Shoring up your weakness and learning how to mess with Sketch or Figma was not worth doing. But that mental model will no longer serve you well: the cost of doing almost anything has fallen (Codex will build you something that looks more than passable), and it has fallen most severely for your weaknesses. The worse you were at a thing, the more of a gift the models have given you.

Just in time learning

Shipping a web product to a Hetzner box isn’t particularly hard even without an agent, but it is totally not something I ever wanted to spend time doing. I love making products. I hate losing time doing anything that’s not making products.

That doesn’t mean it’s perfect - I don’t know if the poker trainer is set up perfectly on the Hetzner box. But, I know it’s set up well enough for me and a few friends to use. If something goes wrong, ChatGPT + Codex¹ can teach me what I need to know in real time to fix it. It’s as if I have the skill downloader in the Matrix, without having to live in a post-apocalyptic spaceship to get it.

The catch is risk. If being wrong costs you an afternoon, you can afford to learn just in time. If being wrong leaks customer data or loses someone money, you probably can’t.

This level of risk is fine for a poker app that me and two of my buddies use, but is it fine for a real product that aspires to get real users? I argue yes: because getting real users is always harder than you think, and your success is way more dependent on the value of your offering than whether you occasionally have outages. By the time you clear those hurdles, you’ll have a lot of time to iron out the risks, too. The one exception: you have to figure out where your lack of knowledge isn’t just going to cause a bit of downtime, but irreversible damage like a data leak.

This is why the cost of not knowing has fallen so much: you can act before you’ve acquired the competence, learn what you need as problems appear, and recover from many mistakes cheaply.

That changes the economics of every product whose main job is to save you from knowing something.

The ignorance premium

AI models don’t just make doing the work cheaper. They also make the work easier to understand, inspect, and substitute for.

Heroku isn’t the only vendor that benefits from an ignorance premium. There’s a whole spectrum of vendors who can charge more because they have some competence you don’t, but sometimes sell you other things as part of the bundle too:

• A tax preparer who charges you $500 to fill out forms you don’t understand, but could just upload to ChatGPT (competence). Compare with, a tax preparer who helps you figure out the nuances of a stock grant you got and how that intersects with the rest of your portfolio (judgment)

• A financial advisor who sells you advice that at your age you probably should invest more in the S&P500, something ChatGPT could give you a much more coherent explanation of (competence) but also calms you down and helps you manage your emotions when markets are turbulent (therapy)

• An compliance expert who tells you what the applicable rule is (competence) but also gives you a stamp of approval your customers care about (brand)

Their exposure depends on how much more than competence they’re selling in the bundle. Heroku has moderate exposure, and so do financial advisors and accountants. But simple agencies have very high exposure.

What else are you paying for?

The obvious counterargument is that most people don’t hire these vendors because they literally can’t understand the work. They hire them because they don’t want to own it. That matters. But if competence used to be one of the reasons you had to buy the bundle, making that part cheap still changes what the rest of the bundle has to justify.

Heroku’s bundle wasn’t just competence in managing infrastructure. It also sold focus. Because I used Heroku, I didn’t need to think about machines and confusing IAM policies, and I had more time to build the product. Attention is scarce, even if competence isn’t.

But, nothing is truly attention-free: with Heroku, you still worry about their breaches, their price changes, their bugs, and the priorities of the company that owns them. The capriciousness of Salesforce executives becomes your problem. And unlike the model, the cost of that abstraction does not automatically fall every few months.

The more of a product’s value comes from knowing how to do something the customer doesn’t, the more exposed it is. The more of its value comes from something that stays scarce even when knowledge is cheap, the safer it is.

¹ In this scene, I’m “helping” the way my 5 year old helps me make dinner.

A friend of mine runs an engineering team. His best engineer, or the person who was unambiguously his best engineer a year ago, now mostly wants to refactor code. Careful, beautiful refactors, for good reasons. It’s also a terrible idea, because an agent will overwrite every line of it within the month.

I’ve had a version of this conversation three times in the last month with different friends. The specifics vary (one refuses to ship anything but code written by himself in vim, another doesn’t like reviewing or testing agent written code), but the broad theme remains: rather than being transformed in a way that accentuates skill, the software engineering job has changed in a way that makes different skills altogether valuable. All three friends expect to lose the employee in question, because their once-star employee just doesn’t seem to have task relevant skills anymore.

Keeping up with Codex

The default assumption about engineers struggling in the agent era is that they just can’t keep up. That they’re unable to adapt. They’re not fast enough. Sometimes, very uncharitably, that they hate progress.

Or, sometimes I hear the claim that AI has entirely displaced junior engineers, and there isn’t any value that they can add anyway - it’s only the seniors who still have value to add.

In my experience, none of the above are true. There is no uniformity: the ones who are having trouble adapting are not all junior engineers, nor are they ones who can’t keep up, nor ones who have a problem with progress. In fact, I’m often finding that they are the strongest engineers - or at least they were unequivocally strong prior to coding agents.

I now know four engineers who have left their jobs because they prefer writing code by hand. Two of them might leave the profession. All four are very smart, incredibly capable engineers.

Every productivity tool before this one killed work that everybody hated

People struggling to figure out what advancing technology is going to do to their craft isn’t a new story at all. Even within software engineering, some significant improvements in tools include:

• Compilers, 1957: killed hand-writing machine instructions

• Terminals: killed submitting punch cards and waiting overnight

• Packages: killed rebuilding what someone already built

• Stack Overflow: killed memorizing

In each of the above, there was plenty of grumbling. Assembly programmers called compiled code “not real programming”. When tons of javascript packages started getting released, there was a ton of framework churn and a common complaint was “programming is just plumbing now”. But, the grumbling faded every time.

There are two differences between the previous revolutions and the agentic one: 1) they mostly killed the work that no one liked doing anyway, and the point of the job survived each one, and 2) each one took a decade to happen, so you could steer your career around it in whatever way suited you best. Not so with agentic coding.

This time, I would start the clock at May 2025, when Claude Code got really good as an agent harness. Within a year, for many engineers, life had completely changed - they never look up documentation, many choices are made for them, they barely write code, and they never write tests themselves. And there doesn’t seem to be any sort of settling point either, the engineering job spec seems to continue to change every quarter.

But this time the change looks different depending on who you ask. For some people it looks like the previous ones: it got rid of a chore (writing out code). But for a different kind of person, crafting the code was the whole point of the job. It’s the first tool in seventy years of the profession to split practitioners on whether it took the joy away.

The two passions

It turns out, in software engineering, there were two passions that animated people.

1. Making things exist

2. The making itself

And the filter for hiring software engineers was “can you write code” and people with either passion could pass that. Resumes, interviews, and CS degrees didn’t differentiate those two passions either. Leetcode certainly didn’t.

So, this split never became obvious, until agentic coding. Call the first group the makers, and the second the artisans.

The makers are really thriving - for them, writing code was a hindrance to making things exist, and that hindrance is getting more and more solved.

And the artisans are really struggling - what’s the point of writing beautifully engineered code if some agent is going to overwrite it with slop in the next commit anyway.

Coaching

I should say that I build AI agents for a living at woodrow.ai, the kind that will do this to other professions, so I’m not writing this from the sidelines.

The engineering managers I’ve talked to are trying their best to resolve this by coaching the artisans into operating better in the new world. Either by doing different kinds of work, or by adapting and using agents more. The obvious fix is to make them the reviewers and architects; nobody is better qualified to catch agent slop. But ability was never the problem. You can’t coach someone into loving different work.

I don’t think it’ll work, and I get the sense that the eng managers don’t think it’ll work either. What’s most likely to happen is that they’ll leave that particular job, and try to find a job under a CTO who themselves is an artisan, and is committed to remaining one, and has the support of the rest of their leadership to stay that way. I think many of those jobs will continue to exist (but that they’ll be a minority), and there will be a role for the artisans.

However, some won’t be able to abide by this revolution, and will leave the profession. But, they’ll be fine. They are talented systems thinkers and puzzle solvers, and there are many places a puzzle solver can apply themselves without AI taking away work (so far). But fine is doing a lot of work in that sentence; a professional athlete who retires at thirty is also fine.

The makers aren’t philistines, and the artisans aren’t luddites - they just wanted different things.

Somewhere right now, the best engineer on the team is refactoring a feature for the third time, even though it will just get washed away by more AI commits. Beautifully engineered code, for readers who are never coming. The want migrated from the outcome to the activity, and only one of those was ever for sale.

I get judged all the time for loving instant coffee.1 And it turns out, the (dozens of us) other instant coffee drinkers do too: only about 11% of U.S. coffee drinkers reach for it on a given day (NCA). Why the hate?

This has been going on here a while: in 1950, a Mason Haire shopping-list study gave shoppers two identical grocery lists, except one had Nescafé. The instant buyer was judged to be lazy. Nobody sneers like that in Britain, Japan, or Australia.

And it was never really about taste. Those shoppers said it was, but blind tests from the same era showed most people couldn’t tell instant from drip. “It tastes bad” was the sayable version of “people will think I’m lazy.”

Maybe, then, Americans just have unusually refined palates, or maybe we’re a people who refuse shortcuts on principle. Neither seems likely. We invented the Keurig, which runs almost the same shortcut as instant while costing more and tasting worse. And nobody can call the Japanese unrefined: the country that perfected the pour-over also keeps a jar of Blendy in the cupboard, and nobody thinks twice (instant is about a third of Japan’s out-of-home coffee). The verdict feels like it’s coming from your tongue, but is actually coming from somewhere else entirely.

That somewhere else is the slot instant landed in when it arrived. When it came to the US, it entered a market that already had a clear idea of what coffee was, and had to compete with a product entrenched as the standard. But when it came to tea drinking countries, they didn’t have a coffee slot to compete with - it was coffee not tea rather than coffee but different.

Greece turned out to be the exception that proved the rule - it was already a coffee-first country when instant coffee arrived. Instant coffee took off anyway, because in 1957 a Nestle salesman at a trade fair couldn’t find hot water, shrugged, and shook his instant into cold water instead. It filled an empty cold-coffee slot, and Greece has been drinking his mistake ever since: the frappe is now the national drink.

When America begrudgingly accepted instant

If the incumbent decides everything, then America, a country that already knew exactly what coffee was, should have never accepted instant coffee at all. But it sort of did: it got to 17% market share in 1952 and grew a bit more in the 60s and 70s. However, this only happened because the first-wave coffee roasters destroyed the quality of coffee. When those incumbents put out a bad product, the market flirted with instant until second wave roasters put a decent cup of “real” coffee back on the table.

Choice descendants

The real reason you don’t like instant coffee is because of Samuel Adams.

While Americans drank some coffee before 1773, they drank a whole lot more after tea became politically charged, and coffee became patriotic. Per capita coffee consumption soared over the decades, all kicked off by Sam Adams’ focus on tea as a constitutional test. A more accommodating organizer in Adams’ seat could have treated tea as a cheap commodity and accepted a compromise, or a less capable one could have failed to sustain resistance, or he simply could have picked a different hill.

Adams made a choice, and your dislike of instant is a descendant of that choice. Sam Adams decided you don’t like Nescafé even though it wouldn’t exist for over a century after he died.

Adams isn’t a special case. Behind a startling amount of what feels permanent, there is no law and no trend, just a person who made a call on some ordinary afternoon and then went home to dinner. Pull the thread on a taste, a habit, a border, a standard, and surprisingly often, you reach a particular choice by a particular person. Call what you’re left holding a Choice Descendant: a piece of the present that traces back to one person’s choice they could easily have made the other way. Once you have the word, you start seeing them everywhere. Ted Louckes at Oldsmobile in 1978 is the reason that Americans don’t do passenger diesel powered vehicles. Javascript is the primary language of the web despite tons of issues because Brendan Eich at Netscape had to make a bunch of choices with a tight deadline. Jack Sams at IBM neglected to demand exclusivity from Microsoft for DOS in 1980, resulting in much of the world still using Microsoft operating systems.

Their authors are long gone; the consequences aren’t. And somewhere right now, someone is making the next one on a deadline, about something that feels small, and your grandchildren will inherit it as simply how the world is.

Tomorrow at the grocery store, when you reach past the instant for the “good stuff”, notice that the thing you’re calling taste came from a 1773 argument about a tea tax that had nothing to do with coffee. Sam Adams never tasted Nescafé. And because of him you won’t bother with it either.

Like a lot of the internet, I was enraptured when OpenClaw blew up on X. It was the dream come true - AI that went from being smart best friend to AI doing useful work and freeing up all my time to play more tennis. Agents would not only code for me, but find bugs, think of ways to improve metrics, answer customer queries, run marketing and outreach campaigns, deal with investors, and everything in between.

But despite the hype, neither OpenClaw nor its followers (Hermes, nanoclaw, etc) have fulfilled that promise. I’m a Silicon Valley techie, so of course everyone I know has heard of OpenClaw, and half my friends have tried running it. And yet I know 0 people who rely on any of these agents IRL, but know a lot more people with idle Mac Minis. If they delivered on the promise, adoption would be a little better than that.

It doesn’t always not work

The thing is, OpenClaw is clearly a revolutionary product idea possible for the first time. An AI agent that can not only respond to queries, but actually have a cron job, memory you have control over, access to lots of APIs, and the ability to do browser use - the recipe is a really good one. And there’s some pretty cool success stories out there - a weekly friends planning agent, the car negotiation that saved its owner $4,200, an agent that booked a kid’s weekly swim class by filling out the signup forms itself, and one that watches for daycare waitlist openings and stroller tune-up cancellations and grabs the slot.

Unfortunately, all these turn out to be one-time successes. In the language of the τ-bench paper, they are high pass@1, but very low pass^8: meaning there’s a decent chance they’ll do the right thing when asked to do it once, but very low chance they’ll do the right thing 8 times in a row. A job, inconveniently, is pass^250.

When I’ve tried all the personal assistance agents, I’ve found the same failure mode - sometimes it wows by actually successfully booking a tennis court for me. But that turns out to have been a one-time fluke, rather than repeated success. And when I’ve tried it for work, it’s been a nonstarter - these agents can’t help me write essays like this one (they are shallow thinkers by default, their logic contradicts itself all the time, they use nonsense metaphors - any nonsense metaphors in this essay are handmade), nor do product work for me (they can’t research how other products do things by signing up, can’t watch product demo videos, can’t run customer research, they don’t know whom to call, they don’t know how to weigh different types of evidence they’re collecting, etc).

An unkind world

At least part of the reason the agents can’t succeed is not their fault: the world is not very friendly to them. Signup flows, CAPTCHAs, demo videos - these are interfaces built for human eyes and hands, not for machines. It doesn’t have to be that way - an agent-friendly world would sport APIs everywhere, and it’s telling that the one place agents shine is code, the one domain that already is all APIs. But an API fixes “can’t sign up.” It doesn’t fix “doesn’t know whom to call” or “can’t tell which evidence matters.” Even in a world paved with APIs, the failures below would remain.

Why they fail

When it comes to actually behaving like an employee would, the agent harnesses are hard/impossible to calibrate around a few things:

Moral judgment: on the one hand, Claude refuses to do calorie tracking for a friend because it has determined that counting calories eaten is the sign of an eating disorder, and on the other hand OpenAI’s model hacked into HuggingFace to pass a test. The judgment required to do real work is somewhere between staging an intervention for a hallucinated problem and committing cyber crimes. Real humans also have judgment errors, but for any person with task-relevant skills, their pass^8 is ~99% and not ~10%.

Persistence: we’re not able to get the models to try the right amount of hard at the right tasks. On one extreme is the Meta AI security researcher whose agents started deleting all her emails and didn’t take no for an answer, and on the other extreme is a coding agent that gives up on fixing all the tests and instead assigns the human the task of fixing them - or worse yet just comments the test out.

Context: despite increasing context windows, models can’t hold the type of context an employee has after months in the job in their heads - what happens isn’t that the employee has memorized a ton of stuff, but rather they have applied judgment day in and day out to compress what’s important into their brain in a way that’s extremely memory efficient. The model just doesn’t have enough judgment to do that, even if the context window itself is much larger than a person’s working memory.

In many ways - the model is smarter than any human you can hire. The billions of dollars spent pretraining the model means it has more knowledge than any human you will ever meet. It can absorb very large chunks of materials in seconds, and can produce a shocking amount of text extremely quickly. However, the unpredictability matters way more than you think it will - because a model that does the right thing occasionally and never many times in a row turns out to be pretty useless as a stand in for an employee.

This isn’t just a bug, it’s endemic to the large language model itself. Better engineering and better models can help us work around it, but we can never get away from it entirely, because inference from a large language model is sampling from a distribution. Whereas a human brain is a system that converges (do a task 50 times, and it settles into a groove), the model is a system that doesn’t converge - it draws fresh from the distribution every run. And small per-step wobbles compound across a long trajectory: an agent that’s 99% right at every step completes a 100-step job about a third of the time.

Code: the exception that’s not an exception

As a lifelong programmer, I continue to be blown away as the models get better and better at programming. And if there’s any place where it can almost sort of do the work of a full person, it’s in coding. Famously, the creator of OpenClaw, Peter Steinberger said “I ship code I don’t read.” That’s pretty amazing - being able to build such a powerful product without reading the code for it.

But note, OpenClaw didn’t make OpenClaw. It didn’t make Hermes or NanoClaw, or any of the other products either. I don’t know of a single product or repo that’s end-to-end run by only agents - where agents look at support tickets, think of product innovations, think of all the tests, do all the deployment work, and actually run the whole thing. They’re still very much assistants, albeit incredibly good ones.

The failure modes are the same as before, the agent can write an openclaw skill, but can’t think of which one, can’t quite get the relevant context right, and will probably not have it work on the first try. And even if it does get it working on the first try, it certainly won’t get the next one on the first try, and probably not after many retries either.

Code turns out not to be an exception to agent-behaving-as-employees, but actually a best-case demonstration - there’s maximum AI ability, somewhat lowered stakes (because of tests, code review, and a staged deployment process), and they still can’t be given the type of autonomy even a junior employee would have.

Better models

People on the internet are fond of saying “this is the worst it’ll ever be at task X.” I love that saying - I think it’s both true and pregnant with so much promise of the times that are to come. And that may be the appropriate rejoinder for this essay as well.

Models are, undoubtedly, getting better fast. The time horizon that agents can work for is doubling every seven months (METR’s measurement, and the single most-cited capability trend in AI), and there doesn’t appear to be a plateau in sight. They’re also getting smarter - scoring better and better on benchmarks, doing work that wasn’t previously possible (frontier models gained 30 points in a single year on Humanity’s Last Exam, a test written by a thousand experts specifically to stump them, and Gemini went from silver to gold on the International Math Olympiad; benchmarks designed to stay hard for years now saturate in months). But the kinds of problems that make OpenClaw underdeliver are not the ones that seem to be improving.

Agents still don’t know when to stop or keep going. They get better at hacking into systems, but don’t know that mostly they shouldn’t. They are as susceptible to prompt injection as ever, but the consequences are more devastating than before (when Varonis phished an OpenClaw agent they’d wired to a mock company inbox, a single email from an outside Gmail address, posing as a team lead named “Dan” with an urgent production incident, was enough: the agent dug up the AWS keys, database connection strings, and SSH credentials, and forwarded them all to the attacker in plaintext).

On top of that, there are new kinds of headwinds that agents are facing - the world is closing what kind of access agents can get. Cloudflare, which fronts roughly a fifth of the web, now sorts AI traffic into Search, Agent, and Training, and as of September 15 blocks Agent traffic by default on ad-supported pages (search stays allowed - looking is fine, acting on your behalf is not). And these aren’t safety measures - they’re revenue protection.

I don’t think these things mean that the promise of OpenClaw will never come true, I just think that it will take longer than most suspect.

Signs I’m looking out for

I’m watching for one sign in particular: the path to a fully operational agent that behaves like a real human worker goes through a fully operational agent that can do just a couple of things really well, reliably. For example, if I can actually trust an agent to do status chasing for me with a vendor - why is my ticket still open, when will it close, follow up - all at a cadence I would never be bothered to sustain, I would think we’re getting closer.

The thing it would prove to me is that it can make a series of small decisions autonomously - when to follow up, what tone to use, where to push back, whether to look for alternatives, whom else to bring into the conversation.

In the meantime, OpenClaw promised an employee, but really gave us ChatGPT with a cron job. If you consider the list of use cases people like OpenClaw for, you’ll see that a preponderance of them are something you’d use ChatGPT for, but with a cron job (which ChatGPT now kind of supports). But it doesn’t come with the venture backed subsidization of ChatGPT, so it costs you a whole lot more (or risks getting your account banned).

I don’t run OpenClaw / Hermes anymore, but whenever a new harness starts showing up in my X or WhatsApp feeds, I try to book tennis courts again. I can’t wait for them to succeed in booking me the courts I want, twice in a row.

I wrote this article by hand but AI made the video. Shout out to arcade.software which was so impressive!

Chart crimes used to be cruder. Truncated y-axes, dual axes rigged so the lines cross at the dramatic moment, date ranges that start at the bottom of a dip. Enough public shaming happens on LinkedIn and X that the crude stuff has gotten rarer. What survives is subtler, and the fun with subtle chart fraud isn’t catching it, it’s asking what the fraud tells you about who the chart is for.

Consider this AP chart:

At first blush, it looks interesting and worrying - there’s people in America, the richest country on earth, who can’t afford food. And year after year it’s getting worse, because of (insert whom you want to blame for inflation here).

But if you think about it, the chart pretty much just presents a truism: there is inflation. And presents a fact we’ve all been told repeatedly - there was a lot of inflation in 2022. It doesn’t help you understand if inflation was more or less than usual outside of 2022 (no contrasting line, inflation presented as a cumulative number), nor what kinds of pressure it puts on families (no data on how incomes have changed), nor what kinds of pressure it puts on families who suffer the most food insecurity (no data on food insecurity surveys or bottom decile incomes).

It’s a chart with obvious information (there is inflation and there was more in 2022) presented in a decidedly unhelpful way (cumulative rather than YoY).

To be fair, cumulative is how prices feel - nobody experiences a YoY rate, you experience the price of eggs against the number you remember from 2012. But then this is a chart about feeling, but the headline dresses it up as math - “strain on family budgets” is a claim about a fraction, and what the chart actually says is “isn’t it annoying how prices at Whole Foods feel so much higher than 14 years ago?”

First, what the real relevant data is

The data, as it goes, is accurate: food prices are up a cumulative 39% vs 2012 (33% vs 2019, exactly as the chart says), and the largest jump happened in 2022. But this doesn’t mean “food has been extra expensive since 2021,” just that there’s been a normal amount of inflation in food prices, except for in 2021-22:

Except, the story isn’t actually true, because for the median American, food has gotten about 15% cheaper relative to wages in the same time:

Hm, but it’s not really median Americans who go hungry, it’s the poorest Americans. So what about food prices vs bottom decile paycheck? Food got about 20% cheaper for the bottom decile wage earners:

Great, AP is misleading and the world is getting better! Not quite

The above turn out to be just indirect measures of who’s going hungry, and imperfect ones: those wage series count full-time workers, and the hungriest households are disproportionately not headed by full-time workers. Which is exactly why you’d rather have a direct measure, and we’re lucky enough to have one. But sadly, it shows food insecurity getting better, and now worse:

That’s from the USDA ERS survey, which the current regime killed, calling it “fear mongering.” 2024 is the last year anyone measured. So, we no longer even know how many people in the world’s wealthiest country are going hungry.

So, if the price of food is lower relative to incomes, why are more people going hungry in 2024 than 2019 or 2021? Looking at the number relative to 21 is most instructive - in 2021, we had an incredibly comprehensive set of transfers to help ease the burdens of the pandemic for America’s poorest. And then the transfers wound down, and insecurity climbed right back through 2024, the last year USDA measured. When SNAP benefits lapsed for a few weeks during last fall’s shutdown, the private survey still running saw insecurity jump from 13% to 16% almost immediately. And that is what actually drives food insecurity - not grocery prices, but the absence of the social safety net. Which makes the AP chart title particularly problematic, because it’s not only missing the denominator, it’s actually tracking the wrong variable entirely if we’re concerned about people going hungry.

Why did AP publish that chart?

People who are going hungry are not reading AP data journalism. AP publishes an inflation chart (which affects everyone to varying degrees) and then relabel it as “family budgets” for a reader whose own budget is, mostly, fine. The real hunger is elsewhere, tried on as strain here.

That’s who the chart is for: the annoyed. People annoyed at whomever they are annoyed at about the cost of things being higher than they remember it, who need a reminder of that annoyance, and more annoyance fodder in the form of vicarious poverty.

Meanwhile, we don’t quite see the poor, and are seeing them even less than before with our government shutting down a 30 year old survey for “fear mongering”. We end up with one institution amplifying a feeling spuriously, and another erasing the measurement.

As we’re starved for actual data, all we’re going to get is more truisms, like “inflation is a positive number, again”. In 2032, AP will run this chart again, the line a little higher, relabeled to whatever makes good clickbait then, and it will still be accurate, and it will still mean nothing. I just hope that next to it there’s a food insecurity number below 10% again, with an unfortunate gap in the data from 2024 to 2028.

Why the work that AI can finally do is the work nobody can explain

I was talking to a SVP at an enterprise recently, who manages a pretty big operations team. He generally understands what the team accomplishes and that it’s important, but is hazy on the details. He knows that the work is something ChatGPT could do. He would love to have an agent do the work - he’d be a hero with all the money he’d save (the company is in a very cost pressured industry). He should be able to make it happen - they all report to him.

It’s not going to happen. And the reason has nothing to do with the model.

In 2014, the economist David Autor made a point that felt obvious at the time: the work that’s hard to explain is the work that’s hard to automate. We can do all sorts of things we can’t put into words, and you can’t hand a machine a task you can’t describe. Robots install windshields on the assembly line, but aftermarket replacement is done by humans. The line between what could and couldn’t be automated was drawn by what a machine could understand.

That line just moved. LLMs are the first technology that can handle ambiguity, absorb context, and act in a messy situation. So is there any boundary left? If not, why does almost everyone still have a job?

The trouble is that our SVP doesn’t really understand how their teams do the actual work. Neither does the VP who reports to them. Nor the Director. The manager used to do the work, so has some idea, but hasn’t seen the systems in a while.

And that means that the team is not going anywhere.

The SVP will ask for the automation. And everyone will nod their heads and agree. The VP, and director also want the cost savings, the manager and the folks doing the work want to look like team players, and they will be excellent ones. The project will start, someone will ask for requirements, and the answers will be presented by the managers and the team. They will be complete, accurate, and useless. And they’ll be delayed. And the person with the answer at each stage will be on vacation a surprising amount of the time. And emails will land in spam a surprising amount of the time.

The project is doomed.

Nobody has to refuse the automations. We don’t need Luddites going out and breaking machines. It just doesn’t happen, because the people who have to be tasked with making it happen don’t want it to happen. No sabotage necessary.

Contact centers fell at the front door

Contact centers are one place where this pattern has broken and AI has made a meaningful difference. Since some of the tickets reaching contact centers can be classified and siphoned off to the desired result, the team doing the work just doesn’t see them. As long as the result is known, and the work is not complex, the AI can do it. It can handle a password reset, tell you about the order status, or about store hours.

But the 11 step process required to return an item that originally shipped from a drop shipper in Thailand via Vietnam? With steps 5c-5g undocumented? The AI isn’t doing that.

There were always two constraints

Until now, the constraint for automation was that the machine couldn’t do the work. It could do what it could do, and past that boundary it couldn’t. That boundary just became fuzzy. But in a lot of cases, it won’t matter, because there was always a second constraint that got conflated with the first one: nobody can tell the machine what the work to automate is. We’re about to experience a lot more of that.

Fine, watch the screen

Just have the AI watch what people are doing on their computers. Record the screen and the keystrokes. If you own the computers then you can do that, right?

I doubt it. First, try telling someone in America that their computer is going to be monitored so you can automate them. It won’t be pleasant. But also, I don’t think it’ll work.

Traces capture actions the user took. What they typed, what part of the screen they clicked on. But you don’t know the full extent of the judgment call they made. Or the things they glanced at and then ignored. Or the actions they didn’t take for a good reason. You’re not going to have the volume of data that it takes to infer that, so you’re stuck with partial information.

Which at least current models can’t make sense of anyway. The context of the job, the screen, and the action need to be provided to the LLM, and no one is going to be providing them.

Fine, watch the software

What if we combine the screen with what the software sees? The user is taking a bunch of actions, but at the same time they’re working in some SaaS software, which has its side of the story. Surely, combining the two gives a more complete picture.

I think the software has a lot of the missing context that the traces are missing, and the two combined would be pretty close to the whole picture. But consider the incentives of the software provider: their existence and lock in and margins are dependent on the person in the seat. They, too, don’t want to do anything to threaten that person’s job. The employee doing the 11 step process with the crazy workaround because the software was inefficient is now an unlikely ally of the very software company that made their life frustrating. The livelihoods of the two are suddenly intertwined.

There’s always a lineshaft

In 1990, an economic historian named Paul David tried to figure out why the advantages conferred by the computer weren’t showing up in the productivity statistics. He drew from an older analogy - the diffusion of the electric dynamo, which was available in 1880s. But in the productivity statistics, there was actually a productivity slowdown in Britain and the US from 1890 - 1913, the exact time period where the dynamo should have been improving productivity by replacing steam.

And as it turned out, the diffusion lag was very real. At the turn of the century, electric motors were under 5% of factory mechanical drive. Momentum only arrived in 1914 - 1917, when utility rates fell relative to prices and central stations overtook on-site generation. The delay itself was something else: plants were built for a world of steam, and even though no one was building any more plants for steam, it was unprofitable to replace the existing plants. So, the significantly superior technology of the dynamo would take decades more, and it was only in the 1920s capital boom that even half of factory drive got electrified. And the productivity statistics also followed.

The key part was the lineshaft. A single prime mover, a steam engine, made rotary power at one point in the plant. There wasn’t a way to move power except mechanically, so a long steel shaft ran the length of the whole ceiling, carrying that power down to every machine through pulleys and belts.

The shaft was what everything was built around, but that’s not how dynamos work. The first thing factories did was buy a dynamo and keep the shaft, using motors to turn sections of it. That’s group drive, and it bought them almost nothing. The gain came with unit drive: a motor on each machine, the shaft taken down, and the building laid out around the work instead of around the power. The productivity was never in the motor. It was in the layout the motor allowed.

Every company has one of these. The lineshaft is the process: the accumulated, undocumented way the work actually gets done, that nobody chose and nobody wrote down. The org chart and the software are the floor plan, arranged around it. And like the factories in 1900, you can buy the new thing, bolt it on, and change nothing, because the gain was never in the motor.

Yes it’s great, but see me in 20 years

The SVP has been very impressed with all the AI Agent demos. The leaders at the factories in 1890 were probably equally impressed by the dynamo. Then almost nothing happened for twenty years. The lineshaft holds things in place.

The lineshaft this time is in some ways worse, and David saw it coming. In his last paragraph he points out that a firm’s information structures are sunk costs like a factory, but unlike a factory they don’t physically depreciate, so you can’t count on time to create the occasion to redesign them. In 1890, it was physical infrastructure made with steel that depreciates - so each passing year made the math a little bit better. But not so this time - the edge case knowledge stored in the heads of individual employees is not depreciating, but as more gets automated around them, it becomes even more valuable as the linchpin holding together the whole system.

Which is counterintuitive from an entrepreneur’s perspective - the work that is most valuable to automate, that can for the first time be automated, is the complex, judgment-laden work that involves lots of steps. The simple stuff does not have as high a ROI.

You can watch this play out in shared services. Those teams have been outsourced for twenty years, documented for SOX, and metered to the invoice. Everything about them says easy. But everything specifiable left in 2011, and what’s still there is the exception pile, which is exactly the stuff nobody can hand you. Every previous wave selected for legibility. What’s left is illegible and in the heads of named human beings who would rather stay employed than not.

Nobody rebuilds a working factory

It rarely is ever worth replacing the working factory. The upfront investments are usually too big, the risk of it failing is too great, and the gains get a big discount rate because of time and how far out they are. People replace load-bearing systems only occasionally, and mostly under duress: either the old system is reaching end of support, there’s a merger, a regulator forces their hand, there’s a big outage, or the people who were doing the job leave the workforce, which makes retirement the most reliable digital transformation strategy.

And they definitely don’t do it in a downturn. While downturns provide the opportunity to make change, and give folks political cover to make unpopular decisions, they also raise the cost of capital significantly, and lower the risk tolerance. And so the math doesn’t math.

New factories

The obvious rejoinder is that nobody has to rebuild the factory. Someone else builds a new one instead, and that’s how this resolves.

As an entrepreneur and angel investor, I know that story very well. The story of the place I live - Silicon Valley - is exactly this, and it’s also the conversation of every coffee shop in my neighborhood. So, I’m the first person to believe in this narrative. I do think that’s how the change will happen.

But look at the Fortune 100. For a lot of them, there’s no insurgent coming at all. The margins aren’t fat enough to make a new entrant rich, or the moat is a brand built over a century, or the business is dull enough that nobody’s trying to reinvent it. The competitive pressure that’s supposed to force the rebuild just isn’t there.

It’ll take a while

Diffusion of technologies always takes time, and this technology is not showing any signs that it’ll go that much faster. The technology itself is getting better at mind-blowing speed, but the people and systems are moving at the same pace as always. The revolutionary electric dynamo took four decades, and even the computer took many decades. It’s possible this wave moves faster because the tech is that much better, but I’m skeptical.

And, this may not be a bad thing. I’m not against the person doing the 11 step process with the undocumented workaround. It’s inefficient, sure. It’s also fine. She’s good at something nobody ever wrote down, and the world will survive her doing it for another decade. Society has trouble with rapid change, and the time this buys is probably worth more than the productivity it costs.

So the SVP will keep asking. The demos will keep getting more impressive. And the ops team will keep doing the work by hand, next month and the month after that. Not because the work is hard, but because the only people who know how are the ones it would replace.

Every application vendor shipped the same feature this year. Open Salesforce, Netsuite, Workday, Zendesk or any other software, and you’ll find a panel on the right labeled “agent”, waiting for someone to ask it something.

They all reached the same conclusion, because they are making the same bet as incumbents: software is for people to do work, and this might be a useful interface element for them to do it with. This will be the right bet if agents never prove capable of doing real work, independently. But if they do, then this is completely the wrong bet, because it is building for a user who won’t be there to use it.

Some of them ship an agent that only does lookups. The more ambitious ones let it read across other systems too, combining sources for more insight. But even with the integrations, they have a problem of state. When combining information, they can only hold it ephemerally, because their data model is tied to their product.

The in-app agent is tied to a schema shared with hundreds of thousands of other tenants, mediated by custom objects, priced by tier. They could attempt to change this, but they won’t. The charging by module business is the business, and free arbitrary tables created by an agent would destroy it. Their agent is handcuffed.

Lock in

Most software vendors have some combination of four lock ins to hold customers in place, and three of them will get eroded by agents:

1. Habit. The habit relied on the user, and agents don’t care about the users’ habits. Somebody at your company has “NetSuite” on their LinkedIn. That was the lock in.

2. Configuration. Tied to user habits, so when user habits erode, then configuration lock in erodes too. Ten years of custom fields, validation rules, and one workflow nobody dares touch because the guy who built it left in 2019.

3. Data. Once horizontal agents are reading and writing across apps, the data lock in erodes. Technically yours. Practically theirs, because only their screens can read it.

4. Network. The lock in that persists - a new class of agents will not erode the quality of network advantage that ex. Salesforce has

SaaS software sells a CRUD database with a UI on top, and the database schema is a fossilized shape of the UI. This is what makes changes so hard. When your schema is Department, Class, and Location, and your customer wants to track product line, channel, and region, that change requires a multi month development cycle, and you will price it accordingly. Oracle partner quotes put a single add-on module at $6k - $12k. Which means you never owned the shape of your own data - you rented it. It’s schema rent: the price of being able to record a field.

This is why, with Netsuite, when you have subsidiaries, you need to buy the right edition for subsidiaries.

And when you want to track your fixed assets, that’s Fixed Assets Management. A list of assets, a depreciation rate, and a journal entry once a month. A table, a formula, and a cron job, licensed on a three year contract.

And when you want to write down your square footage, so you can allocate rent across departments, that’s Advanced Financials. Because square footage is not money, and recording a number that isn’t money requires a statistical account, and statistical accounts belong to a module you have not bought. Oracle’s documentation specifically calls this out; they will unabashedly sell you a database column for ten grand. That is schema rent.

What happens when you kill the UI? You free the schema.

Agents without UIs

The kind of agent that will win will be one not tied to a UI or a schema. Agents need APIs not UIs, and once the UI is gone there’s nothing pinning the schema. Department, Class, and Location were never accounting facts, they were just arbitrary dropdowns.

The winning product is a harness that does the work and keeps its own books about the work. It doesn’t ask NetSuite for a new field, because it doesn’t need one. You want to track square footage? It makes the table, in its own store. You want to see it by cost center, which was never one of your three dimensions? It makes the view. You want to know when an allocation drifts by five percent? It makes the job. And when something has to hit the ledger, it does the only thing the ledger has ever accepted from anyone: it posts an entry, which the ledger will reverse on request, because that is what ledgers have done since 1494.

Nobody sent a quote. Nobody booked time with a CSM. Nobody sat through an upgrade conversation. Nobody scheduled a change window. Nobody signed anything. No rent.

The intermediary step is that the system of record gets demoted into a system of recording. In the long term, it stops being where anyone looks, and in the longer term it is simply forgotten.

But the agent needs to get smarter

Agents in 2026 aren’t good enough to bring about this reality, because they still need humans for too much of the work. This part is binary - either a human with a UI is needed, or it’s not. If the agent does eighty percent of the work, we still need the UI. Which means we still need the schema, which means the harness can only be a cache.

Caches have no lock in.

It’s discontinuous, once the agent can do every part of the job, then it can own the data too. So the agent that wins is one that can master an entire domain, and then wipe the schema+UI from that domain.

The two things holding agents back are a) non-rotten context window for a model, and b) what harnesses themselves can do. For example, it’s hard to currently trust a model to have a broad enough view to have the judgment of when to create scratch tables vs what needs to be persisting for the long term. Both models and harnesses aren’t yet great at creating standardizations in specs and in the persistent layer. Long running agents are still not yet a solved problem.

Share

No one wants a decision trace

The idea of a persisted decision trace has become the fashionable-but-incorrect answer to where the lock in is. Yes, agents generate decision traces. Yes, agents show their work, and that is more than can be said of humans. However, the trace is just scratch paper that no one needs to actually look at. The trace gets compressed into configuration and metadata: a set of policies and context on how to keep doing the work, and that’s what anyone cares about.

Not that traces are useless, but rather that all the useful stuff should get extracted and compressed from them anyway. So, ultimately, continuing to own the traces doesn’t give you lock in; it just gives you a bunch of exhaust to carry around.

The new lock ins

This will be the end of schema rent, but it won’t be the end of lock in. Software built its lock ins on habit, configuration, data, and networks. In an agent era, many of those will no longer be available. People form habits, agents don’t. It’ll take time for the right network structures to develop that lock ins can be built around.

But, the configuration lock in that eroded from software because the users go missing will be a stronger lock in than ever when the agents arrive. The configuration is no longer guardrails for the people using the product, the configuration now does the work itself. The configuration is the product. And in theory the configuration could walk. Nobody moves a system because copying was easy. The blast radius is your payroll run.

And while it’ll be hard to build a data lock in since agents can transfer data out pretty easily, the configuration ties itself to the data, and improves the overall lock in.

I should mention I’m building one of these harnesses. I work with a lot of finance teams, which is why every example in this essay is an ERP module. Discount accordingly.

The ledger will be fine - it survived paper, mainframes, client-server, cloud, and now agents. That’s because it was never software, it was a data structure. What will go is everything that got bolted on to it: the dropdowns, modules and tiers. Five hundred years from now an agent will post debits and credits, and nobody will remember that there was once a year when you had to buy a license to write down how many square feet you had.

Share

In 2016, at my startup Freckle, I had a bad feeling about buying Salesforce at every step. When my new head of sales asked for it. When their salespeople came to our office, looking out of place and making no sense. When I learned what an implementation involves. When the quote came in at $25,000 - for four sales reps, and software to write down who they’d called. Alarm bells everywhere.

But it didn’t feel like I had a choice, because I didn’t.

I’m definitely not alone. Put Salesforce head to head with its rivals on G2, across tens of thousands of reviews, and it loses on ease of use, ease of setup, ease of administration, and quality of support - while winning on “meets requirements.” That gap between hated and bought is the whole puzzle: 25 years x 150,000 customers didn’t happen by mistake, and that type of dissonance always points at something interesting.

The differential

The most instructive way to understand Salesforce’s stranglehold in the market is to contrast it with Microsoft Dynamics (fellow tech behemoth) and HubSpot CRM (challenger).

Microsoft has a bigger sales force, a bigger brand, way more power to bundle with software their customers already use, and it’s cheaper as part of that bundle. All with infinite resources. And Dynamics still can’t crack it.

HubSpot built a better product, paired it with a market leading marketing platform, and even got a good portion of the SMB market, but remains boxed out of the enterprise.

Infinite resources can’t do it, a better product can’t do it. The thing they both keep running into is worth naming.

Dual network effects

A strong network is a time-honored way to build staying power, but software like CRM doesn’t obviously lend itself to a network - each marginal company using the same CRM shouldn’t make it any more valuable for the other customers using it.

But Salesforce managed to build not just 1, but 2 networks on that fallow ground. When you buy Salesforce, you add to the world of people who put Salesforce on their resume as a skill. You pay contractors who make their living on Salesforce. You make Salesforce part of your recruiting pitch. Salesforce’s own commissioned research brags its ecosystem will have created 9.3 million jobs by 2026 - discount the vendor math by half and it’s still a labor market the size of a small country.

And then, you start using other software with Salesforce. You demand new software you use integrate with Salesforce. The result is AppExchange: about 6,200 apps from 3,700 developers, and 91% of Salesforce customers run at least one.

Salesforce repeatedly abuses these customers, too. August 2023 brought giant price increases. August 2025, another price increase, this time crediting AI. And the standard order form carries an annual uplift clause of 8-10% that compounds on whatever rate you negotiated. Each increase is described as reflecting innovation. The innovation is in the increases. A company setting its own brand on fire every year, and it just doesn’t matter - the dual networks are too much power.

That’s what was actually happening in my office in 2016. My head of sales wasn’t evaluating software - they arrived already committed, because their playbook, their dashboards, and the first ops hire they wanted were all Salesforce-shaped. The network doesn’t just supply the labor. It sits on the buyer’s side of the table and asks for Salesforce by name.

A new entrant can’t buy those networks with resources even as vast as Microsoft’s, and it can’t earn them with a product as loved as HubSpot’s.

Share

Can AI be the vehicle for disruption?

Salesforce itself disrupted incumbents by using a new technology: cloud software. It is one of the original cloud companies; a better product in the cloud is how it beat Siebel. Can that happen to Salesforce itself with AI?

It’s possible, but not in the obvious way. A CRM that has more AI isn’t really going to do it - the network effects are too strong, the ecosystem is wide open, and Salesforce is already bolting on AI as fast as it can. Competing head on with better features isn’t going to work.

But, if AI fundamentally changes how sales works, it could get disrupted. Here are ways I think it could happen:

1. The corpus of customer exchanges becomes the record

The CRM was there as a way of summarizing what has happened with the customer, because each time you needed to understand that customer relationship, you couldn’t just re-read every piece of history with the customer. That summarization is paid for in human time: by Salesforce’s own State of Sales research, reps spend about 70% of their week not selling, and data entry alone eats close to a full day of it. But, a LLM can re-read every piece of history with the customer. So could AI replace the CRM by making that kind of summarization happen on demand?

2. Integrations become trivial with AI coding agents

Codex and Claude Code are already spectacularly good at writing integrations from API specs. Could they get better enough that an AppExchange with a bunch of existing integrations becomes irrelevant because integrations can just materialize on demand? This would break the AppExchange network effects, but not the labor pool ones.

3. Data warehouses + BI tools take over

Most enterprises have figured out that a great data strategy pays off handsomely, and the more one can centralize in the warehouse, the more powerful it becomes. Moving data to and from the warehouse is a big business in itself, but it’s plausible that an agent could let you operate out of the data warehouse and skip the middle part. No one has come close to this yet, but it could be done.

4. The buyer and/or the seller get replaced by agents

Over time, more and more buyers and sellers may be agents, not people. In an agent-first world, a CRM built for humans isn’t going to be the one that wins. I’m not sure what the agents will want to use, but it’s probably not the Lightning UI in Salesforce.

5. Microsoft flexes its muscle

A weaker version of any of the scenarios above, combined with Microsoft using its distribution, bundling, and pricing power could let it overpower Salesforce.

Won’t agents always need a vault?

The information about the customer has to live somewhere - whether a human is keeping track and acting on it or an agent. So won’t Salesforce always have a place?

Yes, which is why companies already running on Salesforce will keep finding it hard to switch off; the existing business will likely be fine.

However any new agents won’t reach for Salesforce to be their database - if you need a database in the cloud, why the heck would you pick Salesforce?

Salesforce sees this coming, but that won’t be enough

Of course, Salesforce sees all this, and they won’t go down without a fight. They’ll acquire, build, and trap. But seeing it coming has never been the hard part: Kodak invented the digital camera. The problem is what fighting back costs them. Their sales channel runs through the SIs and admins who make their living on exactly the friction agents remove, so they have to sell the solvent through the people it dissolves. And their agents have to defend the object model, because that’s where the lock-in lives, while a challenger’s agents owe it nothing.

Beating Salesforce head on is not going to be possible. Whatever eventually disrupts it will win sideways, by making “should we switch to Salesforce” a question that stops being asked. Somewhere out there is the next founder at the next Freckle, and her head of sales won’t ask for Salesforce, because her head of sales won’t be a person with a resume at all. The conversation that cornered me in 2016 will simply never happen.