Preview

It would be useful to know the shape of future AI demand, and many are attempting to predict that. Since this is a long piece I’ll give you my predictions up front. My overall prediction is that localized corrections, from the imposition of usage controls and consistent pricing, will ultimately be less important than the big trends. Value, so far hard to measure, will become more clear, first through incremental gains at the core of software development, and next, from the innovation that takes longer to accumulate and organize.

Read on to learn how I add my experience in cloud computing and software engineering to my deep interest in economics to extend responses from two of my favorite writers. Along the way, I’ll recast the bubble analogy, explain recent trends that have hit the news, explain trends hidden deep in the development lifecycle, and provide a model, “Ingenuity Matrix”, for mapping usage intent to expected outcomes.

We love good stories, especially those with a villain. But we should be careful about our stories, knowing how powerful they can be.

Three stories have hit a crescendo at about the same time. Tokenmaxxing — companies turning token usage into a goal, metering it, and the waste that incentivizes. Subsidized tokens — questions on the relationship today between AI costs and pricing. And under both, the doubt about whether spending is producing value for AI customers.

Stack them together and a tidy narrative falls out. If these are what’s driving token usage, and they all adjust at once, the readjustment will ripple through AI industry economics — including Anthropic’s recently skyrocketing revenues. That narrative extends across all model providers, culminating as a cascading failure of the whole AI industry. Call it the token bubble, brought on by a revaluation of tokens and their utility.

It’s a neat story, but the framing is off, even before we get to evidence. “Bubble” as metaphor smuggles in two assumptions: that we’re looking at one structure, full of only hot air, and that it ends by popping. In reality, industrial bubbles deflate, running out of air. There is an inflated shell, inside of which a structure is being built, and its collapse while deflating halts construction within, and damages unfinished construction. But something remains.

Inflating the shell is not folly, but the simplest path to enable construction. It’s still calamitous when it deflates, but the goal is the structure, not the air. So the question I’m interested in isn’t “are we in a bubble?” It’s: which of these dynamics is air, which is structure, and how would you tell them apart?

The story has been covered by two of my favorite writers, Derek Thompson, in The AI Boom Has Entered Its ‘Wait, Is This Worth It?’ Era and Noah Smith, in How much more software do we really need?. Both play speculatively with the idea that spending and rationality may have split from each other, but retain optimism that something worthwhile is being built.

Thompson concludes his summary of an interview with SemiAnalysis’s Doug O’Laughlin:

Every new technology requires an extended period of trial and error, as organizations toggle between (a) not enough experimentation or spending, followed by (b) too much experimentation and spending, followed by (c) too dramatic a pullback, followed by (d) the repetition of steps (a) through (c), until firms figure out a long-term balance between labor spending and tech spending. Whether AI skeptics like Marcus are right that the bubble is about to pop depends entirely on a question that, as of today, nobody can definitively answer: Is the bill worth it?

Smith considers the period before a smarter than human in all ways artificial general intelligence:

But until we reach that point, it’s a nontrivial task to think of business models that could be fully automated even with an AI that can’t yet do everything. That’s going to be hard! If I had any good ideas for how to do that, I’d go become a billionaire myself.

At some point, though — maybe in the very near future — people (assisted by AI) will come up with those revolutionary new business models. At that point, tokenmaxxing will suddenly become a lot more economical, and Anthropic — or whoever has good coding agents by that time — will stand to make untold amounts of money.

These are good perspectives, but I can improve upon them to help understand the dynamics of AI usage. First, I’m from the software industry, which is at the center of the maelstrom — coding is now the single largest category of token usage. I can describe in more detail what developers are actually doing with these tokens, and their motivations. These details are important. Without them, a lot of valuable work remains mysterious, which invites doubts, such as “is this worth it”, or “do we need more software”?

Second, I’ve spent a while thinking about the adversarial dynamics of some AI usage, since first writing about it last year. Those dynamics are key to the questions both writers leave us with. Adversarial usage doesn’t produce the social value we all seek. It is not the only driver of AI usage, but when it is a driver, we should be asking, “is this worth it”?

Both writers are aware of an important detail, timing, which explains many misleading observations. With the addition of a deeper understanding of software development, and that model for separating zero-sum jockeying from the creation of social value, we can recognize events along the timeline with more accuracy.

Token usage, like human labor, can’t tell you progress. Its best analogy is effort. If you want to understand the effectiveness of effort, you want to know how it’s being applied. Different applications correlate with different outcomes. Since you can’t fast-forward to the results, this is the best immediate categorization you can add. I call this categorization, the Ingenuity Matrix, describing the scope and social alignment of token usage.

Some token usage goes nowhere by design, some burns down a backlog of long-deferred work, some is zero-sum jockeying. A slower, quieter share is the significant work that actually changes lives. Sort the usage that way and the “is it a bubble” question dissolves into a more useful one — what’s being built, what events can we expect along the path, and what risks and opportunities come with each set of events?

Background

Before we start into the model, understanding the two terms behind the narratives is useful. This will also be useful when reading general news on the topics. The narratives on these conflate multiple meanings, and smuggle assumptions. That ambiguity can support misleading narratives1.

Why Bubble as an analogy is over extended

I said in the opening that using “bubble” as a metaphor for the AI industry smuggles in two assumptions. A bubble is so commonly used to analogize industrial revolutions, that we fail to reflect on the limits it has as an analogy. One mistake it leads us to, is the belief that there’s a soap bubble floating in air, and when we prick it with a pin it will pop, and evaporate. This does a poor job of explaining reality though.

We might limit our imagination more effectively by replacing the soap bubble with an inflatable dome. Whether this stays inflated depends upon the balance of air entering and exiting. Inside this dome, we’re constructing something durable, but it would be a challenge to do so with the dome weighing on top of us. We need the air to keep the dome’s ceiling from impeding our construction, and if it deflates it will probably ruin any half constructed structures. The stronger completed structures can sustain the weight of a deflated dome, but will struggle to conduct any additional construction.

If you want to think of the social support for a system, which supplies the air to keep the shell inflated, as a bubble, that’d be fair. This can evaporate with a bad news story, or some other form of social contagion. That social support is what replaces the air that leaks out. We’ll discuss the leaks later. Some are necessary, some are not. But replenishing the loss is unavoidable.

It’s useful to remember that in this analogy, deflation isn’t free. Something will remain, but the damage to unfinished construction is real. Careers are an obvious example of the consequences. When companies downsize the skills, connections and tacit knowledge built to support growth get stranded. If people move on, they may never come back. And besides, they are people and the disruption to their lives matters too. Projects also take a hit. Some projects may be zombies, shambling along with an unsound structure that will never be completed. But the forces of deflation aren’t so selective, and promising work is wiped away as well. Many projects that stop work during periods of tightening never start again.

A second flaw in the analogy is as a singular structure. Not only are there independent structures being built within, there’s not a single dome. There is a primary dome, where the model providers, GPU manufacturers and designers, and much else reside. But AI is also working to serve many different industries, and we shouldn’t assume a shared fate between all those efforts. We do want to pay attention to software development, because it represents such a large fraction of current usage. But software development itself isn’t an end of its own, it serves other industries. If AI is effective at helping some of those, and less-effective in others, this doesn’t establish a shared fate. It is only those cross-cutting effects that affect all software development that would carry that risk.

For the most part, those outside of software development aren’t going to understand those cross-cutting effects. I’ll highlight some of those details here, as they should be relevant to anyone interested in the immediate future implications of AI.

Why the public has a poor understanding of software development

The wider world has never shown broad interest in learning what software developers do. Compared to other professions like police, soldiers, doctors, lawyers, musicians, writers, journalists or even criminals. Without that interest it’s unlikely to learn the inner workings of the profession.

Media portrayals of software developers are rare and rarely accurate. The most common portrayal is the “hacker” who mysteriously takes control of computer systems in a few minutes with no preparation. Not only is that a poor representation of a real hacker, it tells you nothing about software development overall.

When software is “done”

If you come from outside the software world, you’d be excused from thinking of software development as building new software. In reality, this is a modest part of software development. Maintaining software, deploying software, and operating deployed software all represent larger segments than new software. All said, new software could be as small as 20%.

Noah makes a tentative argument that “The world may already have most of the traditional software that it needs.”. Noah’s aware he might be getting this wrong, and indeed he does. It does take an immense amount of work to keep sites running. AI is being used here, but it started later than its use to create new software. It’s not too hard to guess why. Creating new software is low risk comparatively. Like everyone, trust of AI has been a process. Software maintenance and operations themselves rely on significant “tech-stacks”, which have to be modified before you can even attempt to use AI to make a site more reliable in a meaningful way.

The number of software releases for security, operational, monitoring and development oriented features has been significant over the past year. Many use AI. Probably many others were built using AI.

Should you expect faster load times and higher reliability? First, would you really know? These have been improving for years, yet the general public rarely comments upon it. Mostly the only comments are those times when something does fail.

I’m not holding this data above as proof that AI has improved reliability. These improvements are more likely the result of conventional engineering, some started years before the results. The results that are “AI” based, are the result of the “machine learning” form that predated the architectures for Claude, Gemini and ChatGPT.

The point is, Noah (and you too) probably aren’t a sound judge of whether improvements are occurring unless you take the time to gather data. From my own knowledge, I know most AI based improvements are still in the early phases of adoption. But the average person shouldn’t expect to have an intuitive grasp on this. We’re bad intuitive judges of background effects like this, where we have to compare changes over time of non-continuous events. We can recall the last event, and the last change, but we are just as likely to draw a pattern from a recent reaction, than from an accurate history.

Why “tech-debt” comes first

You’ll find an interesting pattern that I’ll get into later. The first work to be done is the “shovel-ready” work. It’s easy to generate a prototype for some random idea, but rarer to have a great idea that can go from ideation to production quickly. AI does speed that up. But it doesn’t speed all work up.

With that in mind, provide a tool to a software developer, and they’ll have a long list of things they wanted to do, but haven’t had time for. Our general term for this is “tech-debt”, but realistically, it also includes half-baked feature ideas, or features that were sound but never made the cost-effectiveness cut. This list predictably contains a lot of non-amazing things. If they were amazing, they would have made the cost-effectiveness cut the first time. But AI does give you a reason to go deeper into that marginal backlog.

Security as a priority

I should also mention security here. Security is extremely important to the operation of software. Failures of security are nearly the worst thing you can imagine. This applies to all phases of software: development, deployment, and operations. It’s tempting to think of security as something you simply develop. But in reality that’s just the first step. A significant failure in development is likely to lead to a significant failure later, but it’s not destiny. You can layer protections to mitigate a development failure during operations. You have to do this because there are development failures you don’t know about. And more importantly, even a soundly designed and developed system can fail if not operated properly.

A lot of time and money is already spent on security. It’s never been the case that it hasn’t been a priority. You can find cases where it wasn’t a high enough priority. But it’d be a stretch to suggest there was a case no one cared. Whatever the priority, there is a limit, a cost-effectiveness barrier where one of the stages of development could have achieved more with more inputs. The introduction of AI changes the math on that barrier and makes many things practical that were impractical.

Security has another dimension too, which is that in addition to AI altering the developer’s cost-effectiveness equation, it does so for attackers too. This creates another incentive to burn down the security backlog. Security can’t wait. And so a lot with good cause, a lot of AI based productivity is going into security efforts.

This isn’t an effort that’s particularly visible to the outside world. What the outside world knows about it comes mostly from stories, not direct experience. When developers patch security holes, their intent almost always is to not change the user-experience. When that is the intent, it’s a slower process, because it requires educating users about new security mechanisms they need to participate in. Because that’s such a difficult thing to do, security teams have a very strong preference toward solving problems themselves without involving the users. It’s not always possible, but 90% of security efforts are invisible to users, and the next 9% are delivered as patches users see installed, but don’t pay any attention to.

The ingenuity matrix

I said in the opening that token usage is like effort: it tells you activity, not progress. To get from effort to expected outcome, you have to ask what the effort is for. Two questions do most of the work, and together they form a grid.

The first question is social alignment. Does the work create value the world didn’t have (positive-sum, pro-social)? Does it merely move value from one party to another (zero-sum, non-social)? Or does it destroy value — burn resources, or actively harm (negative-sum, anti-social)?

Alignment can be informed by our guesses of actors’ intent, but it’s not dependent on it. Our best bet is to act as an outside observer, guessing at outcomes. I don’t want to overcomplicate this though, this is estimation after all. Some significant pro-social value sometimes arrives from someone tinkering purely for fun. The social alignment is still recognizable from the outside, even when the actor wasn’t aiming at it.

The second question is scope, how far the work is reaching. Significant work aims at a real leap. Simple work aims at something bounded and modest. Naive work isn’t aimed at a productive outcome at all. Here “naive” describes the absence of a useful target, not the absence of a motive. Intentional waste is naive in this sense, it produces nothing of value, even though the person doing it has a very clear motive.

What you’ve just toured, security patches, reliability work, performance and cost tuning, is real value, almost all of it invisible to the people who benefit. Nearly all of it lands in a single cell: simple, positive-sum. It’s illustrative that so much of what is immediate is within simple or naive ingenuity. The first things individuals use AI for aren’t the significant ones. It’s the modest, shovel-ready, often-unseen things.

Map the rest against those two axes and you get an ingenuity matrix:

Negative-sum is not hypothetical, it connects back to security. The same drop in cost-of-effort that lets defenders finally burn down the security backlog also lowers the attacker’s cost. AI-assisted cybercrime is simple, negative-sum ingenuity, and the prospect of AI-scale biological or infrastructure attacks is the significant version. A large share of the invisible defensive work isn’t optional improvement, it’s the response to an adversary. The result is effort that is no longer avoidable, but also hidden, which delays the visible gains we’re watching for.

Significant non-social ingenuity ends empty. Non-social work can seem significant when under development. But one of two things happens. Either the work ends up leaking into pro-social, or anti-social accidentally, or it is copied and becomes trivial. Significance and neutrality are generally unstable.

Naive ingenuity is where the most visible tokens are burning right now and the least is being built. Failed experiments and aimless prototypes aren’t worthless — they build skills and occasionally surface something real, which is the option value the leaderboard bet was buying — but as a category they go nowhere by design. Because naive usage is so voluminous, and personal, it’s the most visible to the simplest forms of observation. That helps it dominate the “is this all a sham?” narrative.

Simple ingenuity has significant usage, but is quickly forgotten. The high volume usage is generally operationalized, contributing to security, reliability or operational efficiency. It’s soon forgotten, as it becomes a background effect. It doesn’t have the humorous, villainous story of tokenmaxxing. It doesn’t receive the personal promotion of the latest experiment.

One of the hallmarks of simple ingenuity, is it could be described as a backlog. The work may have been identified as desirable a long time ago, but with other competing priorities, it wasn’t prioritized. It may also not have been cost effective. One of the changes that AI brings is a change in cost-effectiveness. This activates this backlog, and you should expect early effects to burn this backlog down.

Simple ingenuity comes early and makes existing work more efficient. Sometimes this will show up as measurable revenues, but much is internal to companies. In that case it’s the token usage, the lower labor costs, or the higher quality that are the observations.

When AI enabled workers have a clear backlog, efficiency gains will flow into simple ingenuity to burn down the backlog. If the backlog results in priced or measured output, you’ll know.

Significant ingenuity will take longer to be identified, developed and deployed, especially the pro-social variety. The economy will reuse freed labor to create more value. That won’t happen immediately, as it may wait on hiring processes, training processes, or even the formation of new companies pursuing new products or business models.

Timing

While the development process is accelerated, the identification process retains most of its bottlenecks. Optimism may accelerate it. Idleness may accelerate it. But optimism and idleness may also flow into naive ingenuity, pursuing trivial goals without positive utility. There is a blurry area where naive ingenuity is experimentation. It may fail, but its failure may be necessary to build skills or discover significant opportunities.

At some point, a few things start to coincide. Naive and simple ingenuity will have built skills, ready to be exploited for realizing significant ingenuity. The backlog’s distraction fades as it burns down, and a new equilibrium raises the incentive to chase significant work — significance always carried more reward, but also more risk. But as cost-effectiveness decreases deeper into the backlog, avoiding risk becomes less attractive. All of these, in addition to the passage of time, predict a future wave of significant ingenuity that direct observation of measurements would fail to predict.

New output

Most of what we’d recognize as new output is significant, pro-social, and lagged. These are the life-changing things, and they’re the hardest to forecast. Your best guide might be a science-fiction novel, but of all the futures sci-fi writers have imagined, which do you bet on? Like flying cars, some things that look a step away stay out of reach far longer than expected.

It would be a mistake, though, to generalize from the failed predictions to all predictions. In many ways today’s information world already outruns older sci-fi imagination — the 1987 Star Trek: TNG depicted computers far beyond the 1966 version, and on the information front we’ve roughly met the standard it set for the 24th century already. The significant wave is hard to time and easy to underestimate at the same time.

What to expect

We should expect the AI industry to experience some pullbacks, then continue on. Whether this ever meets the bubble narrative is uncertain. I’m skeptical. Many pullbacks will be met by other accelerations. One experiment fails, another scales.

There isn’t one bubble, ready to pop, but multiple domes. Each industry, each set of users finds their value. While software remains so dominant, a failure in the software use case could be dramatic, but much of it is boring simple work that will continue to be automated for some time yet.

Much of the immediate term work is going to focus on the simplest, most invisible aspects. We shouldn’t discount the value there. Where it’s defensive, answering the negative-sum, like security, it has to be done. Where it’s part of more normal systems, it’s freeing resources, and developing skills and experience that will fuel more significant ingenuity in the future.

You do have to wait to see world changing effects. Software, as a model for implementing a workflow, will remain, and the general skills of software developers will be critical to this. Lines will blur, people will cross-over the lines, but ultimately the concept of software will continue to exist.

If the software dome does collapse, it will create structural damage, like all such events. Failed companies, layoffs, abandoned projects. Resources for naive experimentation would evaporate, and companies would proceed more cautiously. But a structure will remain. The burned-down backlogs that don’t un-burn, the skills that accumulated, the efficiency that keeps paying out, and the significant work just beginning to grow.

So, are we in a bubble? Will users and companies pull back on token usage, looking for value, discouraging wasteful tokenmaxxing? Will they react to pricing changes from model providers that close subscription loopholes that allow token usage in excess of what the same money would have bought per token via API? Yes, they will, but will that cause revenue drops that deflate the dome?

I don’t think so, there’s enough pending and developing work to fill the gap. Even if the significant ingenuity is still developing, the simple work is sufficiently valuable and important. But maybe those dynamics will return next year. If compute providers continue yet more expansions, they still might find them getting ahead of demand. There’s a lot of history to be written here. I’d just be careful about writing the ending first.

Sources

• Representation of professions in entertainment media: Insights into frequency and sentiment trends through computational text analysis; Baruah S, Somandepalli K, Narayanan S..

• State of AI, An Empirical 100 Trillion Token Study with OpenRouter; Malika Aubakirova, Alex Atallah, Chris Clark, Justin Summerville, Anjney Midha

• The AI Boom Has Entered Its 'Wait, Is This Worth It?' Era; Derek Thompson

• How much more software do we really need?; Noah Smith

• State of AI in the Enterprise The untapped edge; Deloitte

Related Articles

Avoidable Adversarialism

A job search is inherently adversarial within groups. Applicants compete against other applicants. Employers compete against other employers. But the relationship between an applicant and an employer is not inherently adversarial. There is a perfect match and those two matched pairs should want to discover each other.

When we talk about the adversarial nature of the modern job search, we should separate the inherent part from the avoidable part. The growing hostility between applicants and employers is avoidable. If we can avoid that we’ll collaborate. Job searches will resolve more quickly, saving money and pain. Workers will be happier and positioned to do the most good for themselves and their employers.

The devolution into adversarialism is clearly a consequence of limits to information exchange and processing. Employers started filtering resumes to minimize what they spent on hiring. Filters create something to defeat. If an applicant has a reasonable expectation that they’re a match for a role and they want it, they want to pass the filter. And since they may need to do this many times over, they have every incentive to do it efficiently.

The Historical Devolution of Hiring

Filtering predates computing. Long before anyone wrote a regex against a resume, recruitment teams read resumes by hand and made decisions from them. By necessity, those filters worked only with what appeared on the page, so candidates learned to structure a resume to pass them.

When resumes were reviewed by hand, there was some benefit to keyword matching. But there was a secondary method of passing the filter, weaving a story. A recruiter could lean on a strict rubric, or they could read for character, for an arc, for something that spoke to who the applicant was in a way that keyword matching couldn’t capture. That second channel encouraged investing in each application. Read the full job description, get to know the company, and write a cover letter specific to the role.

Human readers were also susceptible to word choice, which explains a lot of the fads in resume writing over the decades. Recruiters responded to certain modes of expression. “Synergistic” is the classic example, but the pattern runs deeper than any single buzzword. Applicants would notice an opening, exploit it. When recruiters realized they were being exploited a countertrend would set in.

The thing about that system, for all its gamesmanship, is that it evolved slowly. Trends and countertrends took hold one recruiter at a time. They might spread through HR conferences, trade publications, networks, but every update was individual. The arms race was real, but it moved at human speed.

Computerized Filters and Keyword Stuffing

Computerizing the filter degraded two things. First, the depth of processing collapsed. Matching became keyword-driven. Stories, arcs, and the patterns that needed a human to understand were no longer assessed.

Second, the motivation to invest in each application diminished because that investment was demoted to the second tier. If you passed the filter, then someone might read that and you’d benefit. But it was only rarely worth the effort with that extra distance.

This second part triggered an adversarial response. It became obvious to applicants that they were in a game, and that the game was everywhere. Callback rates fell from 10+% in the early 2010’s to 2% in the 2020’s. The decisions weren’t fair and weren’t optimal, so playing the game to its fullest felt like fair play. Resumes filled with keywords. Applications per candidate increased.

At first, human reviewers reacted by turning away obviously stuffed resumes forcing custom resumes per job with just the right keywords. Applicants had to balance to make these custom resumes not read like keyword-stuffed garbage to a person. This ate enormous amounts of applicant effort.

One page norms were initially strongly enforced. But then they gave out. The keyword filter wants more, because keywords need room to slide in while still appearing natural. Mainstream career advice shifted to two pages to leave room for the terms automated systems scan for.

The human reader, conventional wisdom holds, wants less, a clean document that doesn’t read as stuffed. But when a resume-writing firm ran a hiring simulation, recruiters preferred the two-page version by better than two to one.

Candidates were in a bind. Some filled resumes with 1-pt invisible white text, to please keyword filters and avoid reviewer reactions.

Then generative AI arrived and solved the bind. Applicants could generate a distinct resume for each role, loaded with exactly the right keywords, with acceptable writing quality, in seconds. But the story route was never revived, because there was no longer anyone reading for a story. Recruitment’s early stages became a machine with no room to absorb narrative.

Goodhart’s Law

There is a common description for that process, Goodhart’s Law. When a measure becomes a target, it stops being a good measure. Hiring teams have continued looking for targets to measure, but each has receded in usefulness.

Generative AI didn’t introduce Goodhart’s Law to hiring. It did remove the final exceptions. The cost of optimizing acted as a natural brake. Producing a tailored, plausible resume took effort, so people did it selectively. Now it costs nothing.

A single posting now draws hundreds or thousands of applications, because every applicant is applying to hundreds of postings. That drives employer response rates toward zero, which removes any reason for an applicant to invest care in a particular application, which pushes them to apply to even more roles, which raises volume again.

Detectors to the Rescue?

Instead of looking to solve the root problems, many hiring managers suggest they’d use another filter: automatically rejecting AI generated resumes. This is almost certain to turn away many qualified candidates. At best, it leaves behind those who invested the most time into the process. That’s a poor predictor of candidate quality. It entrenches gamesmanship too. If you’re tempted to make the argument that candidates investing more time have more confidence, consider the counter; your job may not matter to the most rational candidates. You may just be selecting for the candidates not smart enough to figure out the game.

Even the detector is suspect. Initially tools could hide the AI provenance, at the cost of quality degradation. Initially this was easy, then detectors got better. But even now, I can say, it’s not too hard to modify AI written text to not be recognized though. It would slow candidates down, but what’s the value in that to an individual employer?

While there’s some good advice to applicants to worry about accuracy with AI and resumes, this filter is low value. Turning away a quality candidate that used AI does not improve hiring quality. It won’t change candidate norms. At best it’s a guess that AI resumes are less accurate. That’s a questionable assumption due to the pressure on non-AI resumes to inflate.

More Requirements

So people propose fixes. But almost all of them share the flaw that they inflate candidate costs and arbitrarily filter qualified candidates out.

Consider degree requirements, which I wrote about separately in Or Equivalent Experience. Employers routinely demand credentials more restrictive than what their existing workforce holds, and automated screening makes that mistake worse, not better.

GitHub portfolios are a common suggestion. But building something good or great takes time. Most paid work ends up in confidential repositories. Those few jobs that produce public GitHub history benefit. For everyone else, it’s a free labor requirement.

You can spot an amazing GitHub a mile away, but the supply of engineers with that will be low. Categorizing good/average/bad is harder. Are you going to assess generally, or be tech specific? Most hiring focuses on tech specific skills. While I think first principles lead to more actual job success, they are harder to spot. If a candidate has a beautiful data-analysis project in Python, but an employer demands a message-processing stack in Rust, the candidate costs go up further. Any self-made project is about more than engineering skill, it’s also about ideas and time.

None of that is fatal, but the later gaming will be. If the signal is genuinely valuable and engineers are desperate enough, people will pay the tax. But what happens after it becomes standard?

Every standard encourages gaming. Simple things first, like using an underground agent to generate a unique, reasonable-looking GitHub project on demand. The escalation is next; hiring teams create a detector. Don’t expect the adversarial dynamics to stop at Level 1.

Any tool you hand to one side becomes a weapon in the arms race rather than a resolution to it. A new filter for employers invites better evasion from applicants. A better evasion tool for applicants invites better filtering from employers. One-sided solutions, however clever, pull toward competitive dynamics, because the other side never agreed to it and has every reason to defeat it.

My Experiences in Interviewing

Early in my time at Amazon (2015), I was active in the hiring process, conducting around 60 interviews in the first 2 years. I was surprised at how quickly I was pulled in. But AWS was hiring fast, and Chicago was a new office. The process had promising ideals. One favorite was the idea that your job was to draw positive proofs out of the candidate, not search out flaws. You wanted to hear them describe their approach to a problem or challenge that demonstrated their understanding of the right path forward.

I’ve found Steve Yegge’s writing compelling, and there is shared Amazon experience, so I was drawn to his recent The Last Technical Interview. Yegge was engaged deeper than I was. I avoided the bar raiser path. Imposter syndrome is one reason. I am proud of a number of people who I was part of their hiring loop, or mentored. If there’s anything that should give you good impressions of your ability to interview, it should be those. But I wasn’t feeling it at the time, and so when I found a technical problem to focus on, I latched on to that, and pulled away from hiring, doing a handful per year.

A less optimistic viewpoint was noticing interviewers that took pride in turning down +90% of candidates. If I approved 25% and they turned out well, what are the chances that those turning down two to three times as many weren’t turning down qualified candidates? There wasn’t any data to show their 10% was better than my 25%.

So I had to chuckle at the reflection where his team of interviewers voted not to hire 2/3rds of themselves. Made me feel a bit better about those nagging doubts that should be part of any difficult decision like this.

Interview Stages

The Last Technical Interview does get at something real though. His diagnosis: the interview has been broken for fifty years, even Google’s best interviewers couldn’t agree with each other or with their own past judgments. The whole apparatus is an elaborate attempt to generate signal, but consistently falls short. His prescription, the “campfire” model, is to bring people in to do paid, real work for a few days, then decide.

What makes his version more interesting than GitHub is a detail he calls counting the work twice: the candidate walks away with a permanent, portable record of what they did, stamped by the employer, whether or not they get an offer. If I get the concept, the employer would be doing a service for the candidate, and for all other potential employers. Both want the information a “stamp” would provide. Well done, this could counterbalance unnecessary adversarial tendencies that have accumulated.

Because it’s employer-certified rather than self-reported, it is harder to fake than a repo an agent can spin up. You’d have to find employers who hand out stamps to everyone, and Yegge is right that failure mode is self-correcting: a company whose stamps mean nothing has stamps worth nothing.

The network effect here is not one-sided. Both sides care about credibility. Gaming still exists, but if your stamp comes from a company vulnerable to gaming, its value diminishes. The signal lives or dies on credibility. Also, the more personal process offers fewer structural approaches to gaming.

There’s definitely some details left unspecified. I worry that some liability concerns could kill it. You still need to screen those invited to a “campfire”. You still have to scale.

An instinct of mine is that this requires some collaboration across the employer space. The campfire with credential stamp would do this, if it scaled. It would be challenging for every employer to create this credibility though if it’s by word of mouth.

An idea here is a company that does this as a service for an industry or multiple industries. This could solve the scaling challenge, if this is a passthrough. In some sense, this is what universities are: a 4-year campfire you pay tens of thousands of dollars to attend. I think the flaw is obvious, they are too expensive and too inflexible. In a sense though, they might have the best infrastructure for this impossible mission, should they choose to accept it.

The Shared Road Out

Which finally points at the answer to the question I opened with. If you want a solution that doesn’t just escalate the war, it has to be something both sides are actually happy with, or one side will fight it. One-sided efficiency tools breed counter-tools. A solution has to be a collaborative tunnel from the start, or it gets pulled back into the field of competitive options.

The trouble is we’re stuck in a bad equilibrium that’s individually rational. It’s a coordination trap, structurally a prisoner’s dilemma. A better equilibrium exists, where applicants apply selectively to roles they fit and employers actually read what comes in, and everyone would be better off there. But reaching it requires someone to move first and trust that the other side won’t simply exploit the opening. Right now nobody trusts that, for good reason. Applicants won’t invest in a tailored application when the expected response is silence. Employers won’t slow down to read carefully when they’re drowning. Both behaviors are sensible. Both perpetuate the trap.

So who moves first? Probably the employer, for an unsentimental reason: the employer is the scarcer and concentrated resource. A small show of goodwill from the side holding the scarce thing tends to get reciprocated. A well-known employer with a reputation can start something new. When candidates learn of it, they would opt-in. But it has to be something that builds collaboratively, rather than whittles away negatively.

I don’t have a clean answer. But I think the shape of the answer is clear enough, and it’s not a better resume or a better filter. It’s changing what each side gets from honest engagement, so that participating sincerely beats gaming.

Yegge’s instinct toward “gravity” is the right one, even if the mechanism is unfinished: make your rejection valuable, and candidates stop treating you as an adversary to defeat. A few partial paths point the same direction. Employer-certified, portable records of real work, if their credibility can be established. Skills-based hiring done deliberately rather than as language stripped from a posting. Two-sided interest signals like Greenhouse’s MyGreenhouse “dream job” feature, where a candidate can mark one application as special, though even that is still half a handshake until the employer offers something reciprocal. Something as basic as committing to send a real response.

None of these escapes the adversarial dynamic completely. Each one can be gamed at some level, and you should assume someone will try.

But that’s the wrong bar. The question isn’t whether a solution is immune to gaming. Nothing is. The question is whether it moves the incentives so that honesty is worth more than evasion to both sides at once. The inherent competition, applicant against applicant, employer against employer, isn’t going anywhere, and that’s fine. The unnecessary war, applicant against employer, is a failure to generate signal collaboratively.

Related articles

With that in mind, I have a reaction to seeing so many job postings in the software industry that look like this:

• Bachelors degree or equivalent experience

• 10+ years of experience building software

The first line is the requirement. The second line is a fig leaf — a way of technically not lying while still signaling what the process actually rewards. It was always a questionable practice, but AI is supercharging the impacts of this mistake.

The Logical Problem

Let’s start with the plain English issue, which is almost embarrassing once you see it.

From a logical point of view, these statements are redundant. 10+ years of experience will always be equivalent experience. There is no interpretation under which a decade of real-world engineering doesn’t constitute equivalent experience to a four-year degree.

The problem runs deeper than embarrassing logic. The reality is that equivalence is probably fiction. Most hiring managers, I’d wager, didn’t author this language and don’t think about it. But it activates biases in recruitment teams, offering a lazy shortcut, and sending the wrong message.

Automation and AI are Supercharging this Mistake

This was always a mistake, but it’s becoming more critical. Recruitment teams scanning resumes will be drawn toward an education section more readily than to calculating the equivalent experience. Automated tools in applicant tracking systems (ATS), including AI, have the same weakness, often more so.

How is a typical large language model (LLM) going to process these statements? The degree is a binary, well-defined data point with a clear answer. “Equivalent experience” is the opposite: fuzzy, context-dependent, requiring judgment. Even if the LLM evaluates the two statements correctly, it could make another mistake, treating the “or” as an “and”, or treating the two statements as components of an overall “closest match”.

These mistakes could cause a filter to fail, or it could cause a lower score. If the three clauses are processed independently, the degree holder gets 3 points, other candidates 2. If qualifications aren’t scored equally, one earlier in the list will usually get more weight. Even if a system doesn’t intentionally add a scoring system, a reasoning model could create one on its own.

More advanced systems are less likely to make these mistakes, but recruitment teams may not use the most advanced systems. This might be motivated by cost, or adoption started before systems advanced. They may even be non-AI, simple text analysis.

In this environment where job postings get hundreds of applicants, because every applicant is applying for hundreds of positions, a naive filter or scoring system can have a dramatic impact. The more nuanced aspects of a resume that should make you a top candidate, may never get processed. That means fewer interviews, dramatically reducing the probability of a successful interview.

What should you do?

The simplest thing to do is remove any such text from job descriptions. Since they are duplicative, and creating unintended effects, just delete them. And it’s not just those “or equivalents”. You should rethink degree requirements in general.

That’s not enough though.

If you’re not deliberate about this when working with your recruitment team, you may get no change or the wrong change. If they remove “or equivalent experience”, keep an internal filter or priority ranking, or just act on their own biases, you may get no change at all.

Should that be your intent? You might ask if you’re better off with the filter. There’s a couple things you can do to validate that this isn’t sensible. First, you might want to familiarize yourself with the actual rates of postings and workers. In many cases, the postings are more restrictive than the workers. Something seems wrong if it is true that if you had to rehire the entire workforce, 20% would be excluded. If 66% of those without a degree already doing the job wouldn’t get a job, you have to wonder.

Is that not enough? Then ask yourself, do you know something about the other 20% that makes you want to exclude them? I suspect you don’t. Once on a job, no one asks, but most assume.

Here’s the test: which of these has happened for you more often when working with professionals in their field?

• You learn someone doesn’t have a degree, and say, hmm, would have never guessed that! Bob is so smart.

• You learn someone doesn’t have a degree, and say, oh, now that explains it, I always wondered why Bob was so dumb.

It’s possible you have little data to work with, because people working on solving a hard problem don’t ask that kind of question. It does come up socially on occasion. If you do have a data gap, it’s not hard to close, just ask a few people. You’ll have to ask 50 people if they have a degree to find 10 that don’t. Because both the affirmative (no degree = smarter), and null hypothesis (no predictive power from degree), are on the same side, it doesn’t take a large same size to disprove the implied assumption.

The strongest case to put a degree on a qualification list is early in careers. This is where “or equivalent experience” actually makes sense. A candidate who just spent four years studying, 2 of it on practical development work is reasonably comparable to one who spent 4 years building products

But AI is hurting college grads. Should we give them an advantage?

There’s a pair of stories circulating about how bad recent grads have it in the job market. Should we give them an advantage, ensuring their expensive degree doesn’t come without rewards? There’s two data points cited on this topic, unemployment and underemployment. Both have flaws in their representation.

Underemployment

The underemployment data point is weakest, and generally just demonstrates a blind spot for those circulating it. The recent number is 41.5%, which does sound horrible without context. But all data should have context. This is not news, it’s a failure to understand the data. If I heard a number like that, I’d ask.. Well what is underemployment.. And what was it like in the past? It’s not hard to find the original source.

What you can see below is that 41.5% is lower than most historical periods. Is that worth freaking out over? No.

If you read the explanation, you understand why the number is this high. It asks people, working in the job, if a college degree is necessary. If you polled me about any software engineering, I’d answer no. I’m sure it is on the list, because probably the majority of the 80% of software engineers who do have a degree are answering yes.

While software engineering is likely on the list1 I can think of a lot of other things people commonly go to college for that even the college grads would likely answer no. Went to school to study art or music? Would you classify that as requiring a degree? Filmmaking? Social worker? What about some that might be on the list but are debatable? Journalist? Newswriter?

There’s also some majors on this list that appear because it’s tracking recent bachelor grads, but these majors usually go on to higher degrees (JD), law, business (MBA).

Unemployment

The unemployment story is more nuanced, but still represented as more than it is. It does show a change, but is it worth the reaction it has received?

What news stories highlight is that the light blue line (recent college graduates), has never been above (all workers) in the past. But is this a fair comparison? After all, a recent college graduate by definition starts unemployed. At some point in that 5 year span, they graduated, and started job seeking. It’s an apples to oranges comparison. All workers are the incumbents. Some of those workers may have been working the same job for the last 10 or 20 years. Since unemployment rates are based upon those “seeking” jobs, what you’re comparing here is first a fraction of all workers who lost a job recently, and then a sub-fraction of those who had difficulty finding a new job, vs. all college graduates, a fraction of which had difficulty finding their first job.

Shouldn’t “recent college graduates” be compared against “young workers”? There’s still a story there, in that the gap has shrunk, but the story isn’t that college graduates are getting a raw deal, but that there’s more equity between with/without. That’s a lot harder to make a decision about. How big a gap do we expect here? Don’t we want employment opportunities for those without a degree?

The Blind Spot

Partly I’m calling this out because it’s a current story that people are getting wrong, but partly I’m also demonstrating a general blindness that seems pervasive in what I’ll assume are mostly college grads discussing this story. They assume that the worlds of college grads and non-college grads are so universally distinct that there would be no overlap here. They assume that the only way you could be prepared for a job fit for a college grad is the same path.

The reality is that in terms of learning, college is just a convenient path, with a lot of resources laid out in front of you, no other responsibilities, and encouragement to follow a plan. College is many other things, a credentialing mechanism and an opportunity to build social networks, for example. But in terms of learning it’s not magical. You learn by consuming information and solving problems related to what you’re learning, and that opportunity has a lot of entry points.

Conclusion

College should be valuable to those that go. But its value should always stem from the learning it enables. Learning comes from many sources, the college experience is simply a well-resourced and well-structured source. Job experience is valuable in its unique way. In both cases, you have to make those experiences count. Your curiosity, your interest, and your hard work are what translate experiences to learning. A college experience, when done well, should be able to do this more effectively than a job. This is because enabling learning is its primary objective, whereas job experience has to compete with other objectives.

All that said, laziness will make any experience intellectually unrewarding. It’s worrying the degree of laziness applied to the hiring process and the data behind recent news stories. We should do better. We shouldn’t blame this on AI, that would be lazy too. Lazy slop was a problem before AI. It has a deeper cause. Maybe it’s growing, or maybe it’s always been with us. Whatever the case, honesty will get us farther than scapegoats.

Barriers, like degree requirements, enacted out of laziness or to create a condition of privilege are a mistake. We shouldn’t use them. In my opinion, degrees shouldn’t matter if you’ve already successfully done the job. This is doubly true if the job is more complex than anything schooling would have covered. In theory, it seems many employers agree, as the terminology, “or equivalent experience” has been common. But words are one thing, practice is another. A lazy translation of intent to practice that fails to meet the goal is harmful. This is but one of many, but hopefully I’ve made it clear how this one is a mistake.

Sources:

• Dismissed by Degrees: How degree inflation is undermining U.S. competitiveness and hurting America’s middle class; Joseph B. Fuller, Manjari Raman; Harvard Business School; 2017.

• Underemployment in the Early Careers of College Graduates following the Great Recession; Jaison R. Abel and Richard Deitz; National Bureau of Economic Research; 2018.

• Skills-Based Hiring: The Long Road from Pronouncements to Practice; Sigelman, M., Fuller, J., Martin, A.; Burning Glass Institute; (February 2024).

• The Labor Market for Recent College Graduates; Federal Reserve Bank of New York; 2026

Related articles

In general, market actors do not have great incentives to protect against catastrophic risks. They are massive negative externalities, often dwarfing the balance sheet of any individual firm. Say Anthropic releases a model that a malicious actor uses to conduct a cyberattack that does $5 trillion dollars in damage. Anthropic is only worth $800 billion, so if they get sued for $5 trillion, they are already well past the point of insolvency. A catastrophic harm may well already be “lights out” for Anthropic, or any other company, so there is little incentive to avoid them, if doing so entails real costs in the present day.

He’s right about the structure of the problem — but “little incentive” understates the precision available here. AI companies do have incentive to avoid catastrophic outcomes, just systematically less than society needs them to. That gap can be quantified, and quantifying it points toward what a corrective policy should actually look like.

The concerns he’s talking about — catastrophic risks — share a structural feature that distinguishes them from others: they are lumpy. A single catastrophic event, rather than a diffuse trend. The incentive is quite large, but not as large as it should be. These dynamics are worth exploring, as those ultimately shape if and how we structure a response.

Consider a hypothetical AI company, worth $800 billion. Now consider a hypothetical event causing $5 trillion in damages. If this event happened, that AI company would be out of business, so they have an incentive to prevent it. But how much incentive? The most they can lose is the whole company, so $800 billion. Since a lot of that is goodwill, in reality, losses become irrelevant earlier. For the sake of example, we’ll say $400 billion. If you had to pay half your market cap, you’re not worth $400 billion, you’re bankrupt, and worth $0. All claims greater than $400 billion have equal impact, since each produces the same outcome, a total loss.

This creates an imbalance between societal goals and the AI company’s goals. That imbalance could lead to underinvestment in safety, or risk taking that is out of alignment with societal goals.

We can quantify this imbalance, by modeling a damage cap in expected value calculations. If our $5 trillion event has a 1 in 10,000 chance of occurring, the uncapped expected value of avoidance is $500 million. With a damage cap of $400 billion, it’s only $40 million. Society should want that other $460 million in incentive to be shared by the AI company, but without an arrangement, it’s not.

Refinements

I used a simple model above, with linear effectiveness of investment in safety. It isn’t linear. In a linear model, spending $500 million reduces risk to zero, and $40 million reduces it to 1/12th of that, or one 1 in 9,166. But we could imagine, in fact we should expect, that the first $40 million does more than the next $40 million. Maybe the first reduces the risk to 1 in 100,000, and the next to 1 in million. It’s the same proportional improvement — 10x. But in the first case it reduces the risk from 100/million to 10/million for a total reduction of 90/million. The second case reduces from 10/million to 1/million, for a total of 9/million reduction.

To illustrate, I constructed a model that used logarithmic decay from the initial 1 in 10,000. In this model, under their default incentives, the AI company would want to spend $13.3 million to reduce their expected risk from $40 million to $8.7 million. But the societal risk is still $122 million at this point.

The goal of a corrective policy would be for the AI company to act upon the societal risk, which justifies spending $35.2 million to reduce the societal risk to $8.7 million.

Further refinement considers whether organic spending is more efficient than regulatory-induced spending. For example, if regulatory-induced spending had half the effect per dollar as organic spending, not only would the spending go up, but the residual damage would be higher.

In Scenario 1, all spending is equally valuable. In Scenario 2, the company spends efficiently up to its capped motivation, after which each real dollar buys only $0.50 of effective safety. And finally in Scenario 3, all spending is at 50% effectiveness.

You can explore other scenarios in the linked single page app (GitHub Repo). You can experiment with different decay functions, damage sizes and company sizes.

Organic Forces

We’d also be doing ourselves a disservice if we didn’t recognize the outstanding work that AI companies have done — Anthropic most of all. Commercial incentives alone aren’t sufficient. The stories about the founding of DeepMind and OpenAI make clear that good intent has played a positive role. But in a commercial world, you can’t depend on good intent to reliably show up or win internal contests. The pressure to go off track is substantial. For something this important, that’s a lot of trust. We want to use these forces, because they are efficient, but must not be naive either.

We don’t want to take organic forces for granted. If we assume they don’t need support, they might disappear. If we don’t acknowledge their value, we might strangle them.

Small Firms

The alignment problem becomes more acute for smaller companies. What if a smaller startup, with none of the weight of a larger company — little to lose, and everything to gain — rushes ahead, and skips best practices that avoid harm?

The leading labs are large (Anthropic, OpenAI and Google), but we shouldn’t take that for granted. Frontier model training costs keep going up, but the costs for a particular level of capability keep going down. DeepSeek proved that moats are much shallower than assumed.

You do want to avoid locking out startups, but also need a baseline that ensures safety isn’t skipped. A first step here is ensuring safety practices are shared. That lowers their costs in pursuing safety.

The current voluntary norm — leading labs sharing safety methodology despite having competitive reasons not to — is a favorable state of affairs that formal structure can preserve and extend. It will take organization to make it work at a deeper level. Sharing details of some safety practices publicly can add risk, so a well-trusted network for sharing enables more than just the public domain approach. Formalizing sharing as a condition of operating at the frontier, both preserves what already occurs, and can extend it more deeply.

Regulatory Shape

The model makes the policy objective concrete: close the gap between what the company is motivated to spend and the societal expected value, without crowding out the organic safety investment that’s already happening.

A naive response assumes insurance is enough, and the challenge is finding a large enough reinsurer to pay out. An even more naive response assumes this challenge can be fixed by inserting the federal government as a backstop to the insurance. The flaw in this thinking is that it makes society responsible for paying itself back for harm done to it. This won’t work. The harm would have been done. Society would pay for the majority of the consequences of the gamble the AI companies made.

These dynamics suggest that effective regulation needs balance, in order to use organic forces, and yet also not leave a gap. Dean is right that it improves the case for government involvement. If there’s a gap between the company’s incentives and the societal incentives on a topic so important, we should align those.

An industry body that both shares security practices and sets standards is a start. Shared excess liability amongst all AI companies would add to existing incentives. If one fails to prevent harm in a small way, that company fails alone. If one fails in a big way, they all fail. Expanding the pool in this way is better than involving the government, as these are the players with the ability to influence the risk. Those incentives will encourage maintaining quality standards, but keep the standards moored to efficiency and effectiveness.

That’s still not enough though, so a government body above that respects the value of organic forces, would be a second step. The challenge here is how to prevent this body from losing interest in efficiency. It’s natural for them to be interested in effectiveness, but efficiency comes with more difficulty. If standards ignore efficiency, you undermine the organic forces and risk taking a step backwards instead of forwards.

What doesn’t work?

The framework I’m discussing, can appear to be a compromise between two points of view. That’s not the intent. There is no intent to choose a middle point, in order to satisfy two points of view. I think the merits of this model fit without any politics.

The model does however balance multiple forces, and is not aligned with any maximal plan. That type of balance only makes sense if the maximal plans aren’t reasonable. To make it clear, I don’t support any maximal plans. It will take additional posts to flesh out why, and others have defended these points independently. But in the light of outlining my thinking, the basic is:

• AI bans: You have no chance. You have no global solution. It’s not a good idea in the first place, as AI will be very useful, but that’s not the biggest flaw. The biggest flaw is all of the partial wins - company X refuses to use AI, country Y bans AI - they all fail in the end and don’t contribute to any goal aligned with the best case for a ban.

• No regulations: Clearly something is needed here. This group is somewhat of a strawman though, as even people like Dean Ball see a role for regulation. The better critique is that there are many people who are implicitly “no regulationists”, because they oppose everything proposed and don’t put together enough to actually do something.

• Top-down regulations: Strangling organic safety efforts in top-down paperwork is a surefire way to fail. That doesn’t mean there isn’t a top, but it does mean, it can’t be total, and since it’s starting later, it should expect to start small and iteratively find its fit.

Clearly, there are more details to cover here. I’ve only touched on one dynamic that sets an overall tone, but you’d eventually need a list of initial best practices, and an expert-led group to maintain them. You’ll need a mechanism to choose that group, and a list of powers and limitations that define how they work together, and resolve conflicts. I’ll leave those questions for a future post though.

Today I wanted to talk about some challenges that complicate preventing malicious use.

Jurisdictions

A first failure of existing law is jurisdictions. The world has rogue states, lawless states, and aggressor states. These either turn a blind-eye toward harmful activity, lack the capability to enforce laws, or actively create targeted harm themselves. Existing laws cannot reliably reach actors that hide in these jurisdictions. There is a justified effort to close those gaps. There is slow progress. Sometimes gaps reopen. Because it’s a long running effort, we shouldn’t expect a near-term resolution, and treat it as a reality we must mitigate.

If we can’t target the originator of malicious acts, we can try to deny them tools. We should recognize the efforts of AI companies here, which have been substantial. But, these efforts are hindered by two background stories: open models and privacy. To deny tools for malicious use, you must first detect malicious use, or intent; open models and privacy complicate both of these.

Open Models

Open models are models released openly. Without going into too much detail, the key quality is users can run these anywhere. Closed models don’t give users that ability, and users have to interact with them as a managed service. That layer of management provides the key capabilities that enable monitoring and denial.

Open models once openly published, have no or limited ability to monitor. There is very limited ability left to control them, mostly centered around denying access to sufficient compute resources.

The largest collections of compute are at cloud providers, but there are still ample compute resources outside of cloud providers — in private data centers, colocation facilities, sovereign national infrastructure, and increasingly, distributed consumer hardware. Even for cloud resources, the nature of providing compute, rather than a managed service obscure the most effective means of monitoring. By design, cloud providers give customers using compute a heavy dose of privacy.

While open models have their justifications, from the realm of preventing malicious use, they are a challenge. It’s of some comfort then that open models are less capable than closed ones. This reduces the capability harmful users have access to. Since some aspects are adversarial, the advantage of closed models provides defenders an advantage too. This applies most significantly to cybersecurity.

Will open models stay less capable than closed ones? We could, across cooperative jurisdictions, enact regulation to ensure that — but if a non-cooperative jurisdiction has the capability to create more powerful models, we’d lose that control. China is the jurisdiction most likely to both have that capability, and make independent decisions.

Privacy

The second background story is privacy. The default state of anonymity on the Internet has costs. Privacy advocates attempt to maintain this state. I, like some others, believe the costs of this anonymity as a policy are too high. This isn’t specific to AI, but it does relate.

We have tied the hands of security teams and mostly delivered theoretical privacy. Where privacy matters most, such as totalitarian countries, the privacy is undermined by local realities. Privacy advocates don’t have a voice here. They win political contests where there is the least need for them, and lose where there is the most. It’s a tough choice, but I think we’re not making the right choices.

We should be pragmatic, but we’re idealistic. In some cases, privacy measures accelerated accumulation of data for malicious purposes. When countermeasures can’t be due to obscuring the lowest layers of a technical stack, we fail to achieve privacy and prevent harm. When formal data-sharing is prohibited, informal systems take their place, and predictably result in harmful breaches.

If service providers always knew who was using their service, they’d be able to deny access to anyone detected acting maliciously in the past. But the internet offers too much anonymity. Providers can shut down an account, but without accounts tied to a real identity, a new one can be created. The current standard among AI companies is too lax about this. We could make it more costly for attackers to maintain access.

Conclusion

Jurisdictions, open models, and privacy are features of the world we must work within — but they are also policy choices we can influence. The uncomfortable reality is that these three forces compound each other. Open models place powerful tools in jurisdictions beyond legal reach, while anonymity makes it difficult to detect or deny access to bad actors even where laws do apply. Treating any one of these in isolation understates the problem.

The path forward requires accepting some hard tradeoffs. Meaningful identity verification will feel like a concession on privacy — because it is one. Regulatory constraints on open model releases will frustrate researchers and developers who have legitimate reasons to want them — because the benefits of openness are real. Coordinating across jurisdictions will be slow and incomplete. None of these are reasons to avoid acting, but they are reasons to be honest about what any given measure can and cannot achieve.

What’s not acceptable is the current default: deferring hard choices while treating anonymity as an unqualified good and open access as costless. The tools for harm are improving. The window for shaping how they’re governed is open, but it won’t stay that way.

Now, Trump and Republicans also try to just directly lie, suggesting gas prices aren’t high, won’t be high for long, and hey, this was all necessary. That type of lie only works directly with the most deceivable. It may help keep some of them from waking up, but the real purpose of that type of lie is to make the more subtle lie less obvious.

The more subtle lie, equating price spikes under Biden and Trump, doesn’t try to convince the public not to blame Trump and the Republicans for this spike, it tries to convince them to ignore it, suggesting, you still need to vote for us, price spikes would be worse with Democrats.

The reason no one should accept that argument is Biden didn’t cause those spikes. The simplest way to understand how poor the argument is, ask how much oil did the Biden presidency remove from the market? I can tell you, it wasn’t 15% of global supply. Probably not even 1%. I think you’d remember that story if it happened. It didn’t. Instead a different story happened.

When the pandemic occurred, global oil consumption dropped, and prices with it. Producers stopped prioritizing new supply. Later consumers started to return to prior patterns, and producers lagged behind the re-emergence of that demand. The price spike was a simple reflection of that, not a result of any US government policy that removed production.

The two major reductions in production since 2010 occurred under Trump. I wouldn’t blame Trump for the first production drop in 2020. It’s stupid to try and blame presidents for everything. But it also clearly isn’t Biden’s fault.The spike in prices during the rapid period of demand recovery shouldn’t be either.

Having some awareness of who made what choices and why is a better method than just direct association of prices to current governments. Instead it’s obvious the production drop was producers responding to the consumption drop.

Coming back to today, another ounce of blame that is deserved, is the destruction of the US electric vehicle industry, and more generally the entire clean energy industry by Republicans. EV Sales increased by five-fold under Biden, and have stalled/declined under Trump. If you want low gas prices, it helps a lot if your neighbors aren’t using much. Eliminating the $7,500 point of sale credit for these vehicles was a strategic and tactical mistake.

The on-off engagement with renewables is another strategic mistake that’s related. While renewables direct impact on gasoline prices are small, the impacts on batteries flows over into diesel generators and the EV industry. The big strategic failure of on-off engagement has been to fail to develop a valuable industry, allowing China to dominate.

Ultimately, the primary determinant of today’s prices is obvious. Trump’s war and its repercussions.

Last year, I started a series of posts on trust, with Money: More Than Just Stuff, It’s Trust as the focal point. I felt 1-year was a good time to update this account, and extend it.

If you ask an economist what money is, they will likely give you a functional, three-part definition: it is a unit of account, a store of value, and a medium of exchange. If you ask a dictionary, it will tell you that money is “something generally accepted as a medium of exchange, a measure of value, or a means of payment”.

These definitions are perfectly workable for daily life, but they contain a loophole. Defining money as “something generally accepted” describes a symptom, not a cause. It relies on the word “something,” anchoring our minds to physical objects—gold, silver, paper, or digital ledgers. But the link between an object and its status as money would be severed by a loss of acceptance.

The basic definition is useful, but it’s clear economists do not consider it sufficient. Just this week Stephen Dubner of Freakonomics, released Part 1 of a two-part series, What is Money?, covering an adaptation to an oratorio of Adam Smith’s The Wealth of Nations. Money must be something of a higher order than temporary objects we attach it to.

To understand what money is, we must look past coins and paper. Trust is not merely a social feeling; it is a vital component of cooperation that requires immense social energy to build and maintain. While trust can theoretically be extended freely, reliably creating it at scale carries a real, limiting cost. Money is humanity’s greatest collaborative technology—an accidental invention that survived and spread precisely because it lowered the cost of trust.

The High Cost of Trust

To understand why money is a technology of trust, we have to look at the world before it existed. How do human beings coordinate the exchange of goods and labor without it? Historically, humanity relied on two deeply flawed workarounds: Barter and Kinship.

The Barter Evasion

It’s common to think of barter as a primitive ancestor of money, but it is better to think of it as an attempt to trade without trust.

Imagine you have a surplus of hay, and you need milk. You find a farmer with milk, but he doesn’t need hay; he needs firewood. To make a successful trade, you are forced into a complex puzzle. You must find the person who has firewood and needs hay, trade for the wood, and then return to the dairy farmer. Economists call this the “double coincidence of wants.”

Because there is no trust carrying value across time—no mechanism that says “I gave you milk today, I owe you value tomorrow”—every transaction must be settled immediately, item-for-item. In a physical sense, barter avoids the need for trust, but the friction of searching for perfect matches makes it impossible to scale.

There is also the problem that the neat and tidy view of trust in barter being solved by the direct physical transfer of goods, is a bit of a myth. Anthropological studies of societies without money show trust issues relating to trust on fairness of exchange, both during and after negotiation.

The Kinship Tax

Because barter is so inefficient, early societies rarely relied on it for daily survival. Instead, they relied on kinship networks. Barter was used mostly outside kinship networks.

Early societies solved the trust deficit through deep, interpersonal relationships. You do not barter with your brother, your cousin, or your tribemate. You give them your surplus milk today, trusting implicitly that they will provide you with firewood next winter.

This creates a high-trust environment, but it comes with a fatal flaw: it is unscalable and exclusive. Maintaining deep, bilateral trust requires immense social energy. You can only maintain it with a small, localized group of people—a single-layer network naturally capping around Dunbar’s number of roughly 150 individuals. While societies can attempt to force kinship to scale by creating additional layers of hierarchy, each new layer adds complexity, instability, inefficiency, and immense human costs. This dynamic imposes what writer David Oks has called a “Kinship Tax.” It crowds out the ability to trust strangers, trapping economic coordination and human development at a deeply local, tribal scale.

The Technological Leap

Before money, humanity was trapped between two dead ends. We could choose barter, which offered zero trust and infinite friction. Or we could choose kinship, which offered high trust but severely limited scale.

Bilateral trust—knowing and trusting the specific person you are trading with—simply became too expensive to produce as societies grew.

Money was the technological breakthrough that bridged this gap. It allowed humans to substitute the expensive, unscalable trust of kinship for a cheap, highly scalable institutional trust. When you accept a dollar bill, a gold coin, or a digital transfer from a stranger, you do not need to trust the stranger. You only need to trust the token.

But how did this leap actually happen? It wasn’t designed by a visionary or decreed by a king’s master plan. Instead, money was an accidental invention. It emerged from the bottom up, sustained by stable local equilibriums where substituting a token became easier than finding a perfect barter match. Once stumbled upon, this system spread through evolutionary fitness at a societal level. Societies that adopted this scalable trust out-cooperated, out-traded, and out-grew those that remained trapped by the limits of the Kinship Tax.

Follow-up

This post has focused on why money is as useful as it is to humans, and why that usefulness is best described as an extension of trust. This falls into the Technologies of Trust series. While this first post updates on the value and concept, others will deal with history and deeper meaning.

This choice carries commercial, security, and community implications. However, as technology evolves, traditional arguments for both models require a second look.

Security Implications

Advanced security scanning, like Mythos, will create new motivations for keeping software closed source.

Historically, the “million eyeballs” effect ensured that open-source security defects were quickly found. But in an era of AI-driven scanning, the equivalent of a billion eyeballs can simply be purchased as compute tokens.

Consequently, the primary security benefit of open source declines, while the advantage of closed source—forcing attackers to probe a compiled “black box” rather than reading a blueprint—remains. We should expect the security balance to shift accordingly.

Commercial Implications

Conversely, AI tools capable of reverse-engineering software from specifications weaken the commercial moat of closed source. If a replica can be generated from behavior alone, the protection of hidden code diminishes.

We should be careful not to overstate those capabilities. While advanced AI tools can create working replicas in many cases, a simple approach to this will produce a less capable, less secure and less maintainable replica. And an advanced approach will require a lot of tokens (which you must pay for), and the efforts of someone who knows what software needs to be good software.

Still, even with those qualifiers, a shift occurs, and developers are left with a little less commercial motivation toward closed source. An open source software package that binds a community to it could be a more stable commercial decision.

The Background Shift

While both of these implications are interesting, they are both watered down by the shift toward managed software that’s progressed over the last decade. Software as a Service, and its variants (Platform as a Service, Infrastructure as a Service) involve a third-party taking responsibility for some part of the managing running software. Management provides a way to offer value beyond the observable parts of the software. In the realm of security, the privilege of management can be used to layer protections. In the realm of commercial implications, value may derive from the efficiency and organizational capabilities to operate the software well.

Those security protections allow providers to rely heavily on open-source repositories for foundational logic, but wrap those deployed software in managed, closed-source service layers. This intermediary role is crucial. It creates a secure boundary where security teams can insert active, AI-driven monitoring and take an adversarial role against attackers with the advantage of obscurity. By funneling interactions through this managed layer, threats can be caught and mitigated before they ever touch the raw, open-source code underneath.

In a sense, open-source both won and lost, as the dominant shift was not from closed-source executables to open-source repositories, but from close-source executables, to managed service deployments based on open-source repositories. The managed service layer provides many of the security benefits of closed-source executables, by allowing security teams to take an active adversarial role, with an obscurity advantage. By having some private tools and techniques, they could often have proactive responses to attacks, rather than only reactive ones. This overall mix, millions of eyeballs on the source, with additional managed layers has been a potent one, and will remain so. That said, we should expect some change in the balance here, with a greater part of the managed layers as closed source.

Conclusion

In the realm of managed services, I’d expect the net result to encourage doubling down on the trend. Proprietary layers to create well managed services will proliferate. Competition with open-source software will not be a priority, but proprietary forks and extensions that improve performance, manageability or security will be.

One question is, who will donate the tokens for scanning open-source repositories? You can’t expect open source developers to buy and donate tokens for scanning the same way they donated their time. Industry cooperation, sponsorship and coordination will be needed here.

The shift from traditional software to AI is a shift from deterministic systems (where a specific input leads to a specific output) to indeterministic systems (where outputs are probabilistic and fluid). Almost every magical capability of AI is downstream of this indeterminism. But crucially, so are its most frustrating limitations.

If there is one fatal misunderstanding of AI today, it’s that we are engaging with this shift inadequately. “Indeterminism” has entered the lexicon, but usually only at a surface level. And because we are stuck on the surface, the loudest debates about AI have become incredibly boring.

Why the Extremes are Boring

Let’s look at the three loudest factions in the AI debate.

First, the AI doubters. They look at the unpredictable, indeterministic nature of large language models and declare it a failure. To them, a system that hallucinates cannot be trusted, and therefore cannot be useful. This is a boringly misguided example of confirmation bias. Humans are highly indeterministic—we forget things, we make math errors, we have bad days—yet we’ve muddled along reasonably well. How? By inventing deterministic tools to anchor us: long multiplication, checklists, standard operating procedures, etc. The doubter assumes you can’t extract value from an unpredictable system when you need reliability. History proves otherwise.

Second, the AI doomers. They also view indeterminism as a critical failure, but in the opposite direction. They are painfully aware of the immense power of AI systems and assume that this power is inherently uncontrollable. While this makes for a more gripping narrative than the doubters’ view, it strips away human agency. We’d have only one option left, don’t create powerful AI. Setting aside whether it is even possible to perpetually prevent its creation, this fatalism leaves no room for a practical conversation about how to retain control.

Finally, the radical accelerationists. They acknowledge the wild nature of AI but fall prey to a blind optimism, assuming a purely indeterministic system will somehow self-regulate and perfectly align with our needs. This is just as boring. The need for control is not irrational, nor is control a given. If control is achievable, it will demand a deliberate, concerted effort, requiring understanding every tool to engineer that control.

If you want to find interesting conversations, look for the solution seekers.

The Solution Seekers: Layers and Workflows

The most compelling builders today are those who reject both absolute pessimism and absolute optimism. They recognize that solutions aren’t singular or total. The most promising path is layers and workflows that mix and join determinism and indeterminism.

Think about how we manage high-stakes reasoning in the physical world—like in an intensive care unit or the cockpit of a commercial jet. We don’t rely entirely on the raw, in-the-moment reasoning of a doctor or pilot; human reasoning is brilliant but fluid, prone to fatigue, distraction, and variance. But we also don’t rely entirely on rigid, unyielding flowcharts, because a flowchart cannot reason through a novel, complex anomaly.

Instead, we design workflows that rely on both. We build strict, deterministic protocols—mandatory checklists, hard limits on medication dosages, automated collision warnings—to create a safe, predictable framework. Inside that framework, we rely on the judgement of a doctor or pilot to handle context, nuance, and problem-solving. Protocols enforce absolute boundaries; experts provide reasoning. Frameworks change, doctors update their own based on their learning, with debate and review, inside another layered framework.

This is the architecture of the AI future. AI will dominate the next generation of software, but it will not render deterministic code obsolete. Instead, code is how protocols are encoded. Those route, authorize, evaluate, and constrain indeterministic AI actors. Control points written in deterministic code will provide the necessary mechanisms to enforce rules, isolate agency, and supply safety. AI will be called upon within those specific boundaries to reason, interpret intent, and adapt to the messy reality of the user.

The Myth of the Developers Demise

This need for control has profound implications for how software is built. Recently, the term “vibe coding” has emerged to describe the practice of building software through natural language interactions with AI. A maximalist subgroup makes an extreme claim that with vibe coding, developers are obsolete and users will prompt their own custom software into existence on the fly.

This misses the fundamental purpose of a developer. A developer’s job is not to write code; a developer’s job is to remove effort for the user. Developing is ultimately not about producing code, but about producing reusable, accessible capabilities for users. An accessible capability is one that requires the least effort to access, and a reusable one is one that can be applied to multiple situations. Code is just the mechanism.

When developers create software, they establish guardrails, conventions, and reusable patterns. Sometimes, a user wants absolute flexibility, and a fluid AI companion is perfect. But often, a user wants rigid reliability. They want to press a button and know exactly what will happen. It’s easy to forget, amidst the explosion of AI capabilities, that rigidness has immense value.

It’s tempting to view recent advancements as a single evolutionary timeline—assuming we are moving from hand-written code, to AI-assisted code, to a future where code is entirely replaced by just in time reasoning of AI agents. That is a mistake, over-extending a trend. Committed code, generated, reviewed, tested and committed as stable will exist in abundance. Just in time generated code, executed in a protected sandbox will also be used abundantly.

The use of models and instructions, reasoned upon just in time, shifts the balance point between flexibility and rigidity, but it won’t abandon code nor the developer.

A Shared Experience: Taming the Machine

For users, future software interfaces will be a mix of structured and natural. Learning to navigate the difference between them will be a vital modern skill.

Structured interfaces (buttons, menus, traditional apps) sit atop deterministic systems. You can trust them to follow a plan. However, that plan was written by a developer. If the developer didn’t anticipate your specific need, the software becomes frustrating. You are forced to learn its non-intuitive logic.

Natural interfaces (chatbots, voice agents) sit on top of indeterministic systems. They can do things developers never anticipated and can interpret your unique intent. But they make assumptions. Using an AI interface is like ordering from a waiter at a restaurant. You need to develop an instinct for how your communication might be misinterpreted. You need to know when the system will ask a clarifying follow-up question (”soup or salad?”), and when you need to be proactively rigid and structured in your commands (”hold the mustard”). Make a mistake here, and you end up with a mustard-covered sandwich. Everyone then has to start over from scratch, and someone has to pay for the waste.

Interestingly, the people building the software are going through the exact same transition.

Developers are increasingly using natural language to write code. For a brief moment, this felt like magic without rules—just type what you want, and the machine builds it. But developers are quickly realizing that an AI coding assistant is just as indeterministic as a chatbot. If they aren’t careful, they end up with the equivalent of a “mustard-covered sandwich” deep in their codebase.

Because of this, we are watching a new kind of structure reemerge in software development. Developers aren’t abandoning natural language, but they are scaffolding it. They are learning when to let the AI riff creatively, and when to enforce strict, deterministic tests to verify the AI’s output. The developer’s job is evolving from writing rigid rules by hand to managing the chaotic intelligence that writes them, locking its best outputs into place so they can be relied upon tomorrow.

Conclusion

For decades, our relationship with computers was fundamentally one-sided: humans had to learn to speak like machines. We memorized menus, learned strict syntax, and clicked exact sequences of buttons. We were forced to be rigid operators of deterministic systems.

AI flips this dynamic, but it introduces a new burden. The era of the comprehensive user manual is over, because you cannot write a complete manual for a probabilistic system. Its capabilities are discovered through interaction, not documented in a spec sheet.

This is why understanding the architecture beneath your feet is no longer just a concern for software engineers. It is a vital literacy for everyone.

If you are an everyday user, recognizing whether you are interacting with a deterministic system or an AI agent changes how you engage. The caution you apply to inputs and outputs should shift. For deterministic systems you should provide what is required and just what is required. For AI systems consider where elaboration yields better results, and vagueness leads to guesswork. Unless you need guesswork, avoid triggering that path.

If you are trying to predict where the industry is going, looking for these architectural layers is the only way to cut through the boring extremes of blind hype and cynical doom.

And if you are a builder—whether you are writing thousands of lines of code or just stringing together a few tools to solve a daily problem—understanding this duality is your ultimate advantage. The future of technology isn’t about choosing between the rigid reliability of the past and the creative chaos of the future. It’s about learning to bolt them together.

One thing that is still being missed, is why the long term favors the defenders. One of the reasons is that fewer defects is good for defenders in a generally absolute way. But another one relates to costs and benefits. Read that economist article linked and the final statements, suggesting that defenders will have to pay highly to discover defects.

Now reflect, that this isn’t new, it has always been expensive to discover defects. The risk that products like Mythos bring is that they lower the cost of discovering defects to exploit. The solution is to raise that cost. That might tempt you to suggest you should rewind the clock, and never invent Mythos. That’s not a solution though as eventually attackers would invent something similar, and you would then lose any control and advantage from the defenders being the first with access.

Instead the solution is that you find as many easy defects as you can and fix them. The first 100 defects might cost $20,000 / defect to discover. The next 100 might be $40,000 per, etc. Along the way you end up with defensive layers that are more and more reinforcing, and the cost for attackers to discover defects goes up, especially if they have less sophisticated tools, and/or have to spend a lot to first illicitly gain access to tools. When Mythos is publicly released you can generally assume providers will increase their attempts to find and ban users with ill intent. Those protections create costs for attackers, such that if a defender can find a defect for $20,000, an attacker might need $100,000. The attacker’s main advantage is they just need one, but as unpatched defects become more rare and harder to find that advantage tends to shift toward favoring the larger aggregate budgets of defenders.

The defenders have a strong advantage in terms of money. Where they struggle is in organization, because they have a much harder organizational problem to solve. The hard part about being a defender is getting changes deployed everywhere quickly. Once attackers find a defect, they can try and use it everywhere. If they find it first, that works in a lot of places. If they find it second, it’s dependent on how organized the deployment process is.

And this is why the long term economics favor the defender. Statistically, most defects are found first by defenders, due to larger budgets. As the period between discoveries gets longer, the chances that attackers have really good targets declines. That lowers their cost/benefit, which probably also lowers their actual budget. Criminals invest in things that make (them) money, not ones that lose it.

In Part 1 of this series, we explored how AI is fundamentally altering software control through the lenses of determinism and scope. We traced the journey from passive, strictly bounded chatbots to the threshold of active agents—AI systems capable of autonomous, multi-step planning. But what happens when these indeterminate systems are given broader scope and powerful tools? The consequences ripple outward, reshaping not just the security of our infrastructure, but the shape of our workflows and emotional relationship to work. To understand the recursive systems of tomorrow, we must dive into the agent ecosystem itself.

The Agent Ecosystem

Agents represent a significant shift in control, trading linear human prompting for continuous indeterministic planning.

To understand how these agents operate, we must briefly consider tools. Agents use tools to accomplish their plans. Tools can be anything, and which tools an agent is provided with define its constraints. You can provide an agent instructions, cautions, and directives through its prompt and context, but like anything in an agent, it’s indeterminate.

A tool might be as basic and low-risk as retrieving a specific account balance, where the boundaries are tight and predictable. It might be as broad as searching gigantic repositories like the entire internet or an organization’s internal files, which escalates risk by exposing the agent to untrusted data or sensitive information.

A broader path still is the ability to create and execute computer code, introducing severe risk if left unchecked. That might initially seem like it loses all constraints, allowing the agent to perform unanticipated or dangerous actions. However, code can be executed in a sandbox that limits how it communicates and what data it can access. Assuming the sandbox is secure—which requires careful planning, inspection, and testing—restricting communication to untrusted sites prevents data exfiltration or external control. Just as critical is controlling the credentials provided to the sandbox. Strictly limiting credentials restricts the agent’s ability to update records or access systems outside the purview of its current authorized activity. Together, these boundaries provide the necessary mechanism to constrain this high-risk capability.

Tool use isn’t restricted to retrieving information, either; it can allow changing information, which can trigger further actions. This is an area that requires much more caution, doubly so for writes and actions that are irreversible. Beyond that obvious observation, two other dimensions enter in. First, since an agent’s plan is indeterminate, the ability for a designer to remove the risk that it performs actions in unanticipated ways is vastly more complex than when working with a deterministic plan. Second, we must account for prompt-injection—the risk that something an agent has read can influence its choices, resulting in actions desired by an attacker rather than the user or designer. There are protections against this type of attack, but it would be foolish to consider them foolproof.

With that foundational understanding of how agents act on the world, we can observe this frontier opening up across escalating levels of scope:

Standalone AI Agents

Unlike a chatbot that waits for a prompt, a standalone agent is given a high-level objective, allowed to indeterministically generate its own step-by-step plan, and execute it using available tools (like searching the web or scraping data). While the planning is continuous and autonomous, the agent still typically operates within a relatively bounded scope, restricted by specific APIs to prevent runaway consequences.

Like chatbots, there are standalone agents from OpenAI, Claude, Google, and others. In fact, most chatbots have silently become agents1, though still with many constraints.

In time, these standalone agents may have more and more autonomy. But from the perspective of this framework, the fundamental aspect of taking user input, deriving a plan through an indeterministic process, and executing that plan won’t re-enter the realm of determinism until it invokes a tool2.

Agents Embedded in Applications

Moving beyond the simple “embedded AI node” discussed in Part 1 involves agents operating continuously alongside users within a shared software environment. Consider a complex data analysis platform: the human user might explicitly invoke deterministic tools to filter data, while an embedded agent operates in the background, autonomously invoking its own set of analytical tools to highlight anomalies. The application becomes a hybrid ecosystem where human indeterminism and agent indeterminism collaborate in real-time bounded by the application’s guardrails.

Agents embedded in applications have an advantage over agents called by other agents: the input data is controlled by the calling application. Still, remember that the applications agents are embedded in may themselves be working with dynamic data. A data analysis platform has many data sources; are they all vetted and invulnerable to an injection attack?

Another common example today is agents embedded into development workflows. They can reason about code, look for security issues or defects, generate fixes, and submit them as pull-requests for developers to review, effectively combining the code-generation function with the embedding function.

Agents Using Agents

An agent can become a tool used by other agents. To think about why this is valuable, you want to first understand that agents generally have a few components. At their core, they create plans via the GenAI model. They generally have some sort of instruction (or persona) file. They’ll also have access rights or boundaries associated with a tool list.

The instruction file is the interesting part here, as it provides the reason for a distinct agent. In the simplest version, it might describe a persona (“you are an insurance adjuster”), but this relies on the GenAI model to blindly decide how an adjuster behaves. If you’re building an agent, you want more control. A detailed instruction file can’t shift you to a fully deterministic world (if you want that, you should write code), but it can reduce variability.

Another aspect that can remove ambiguity is placing restrictions on inputs and input sources. If an agent expects to receive user input, it has to be fully prepared for anything. If it’s called from an application, those expectations are more constrained.

Agent input expectations fall into two categories: expectations formed around successfully fulfilling its goal under valid usage, and expectations formed around avoiding taking action on behalf of an attack. These two have some non-overlapping aspects. If an input is suspected of being for the purpose of an attack, there’s no need to try to do anything other than quit and refuse action. But the consequences of allowing an attack are generally far more severe. On the other hand, failing to successfully complete an action is less severe, but it’s less acceptable to give up because of uncertainty.

If we had wanted certainty, and accepted inaction for uncertainty, we should have written a traditional application, not an agent. In many ways, the creation of agents with sophisticated instruction files is a type of meta-programming that never coalesces into a deterministic form. While we could use vibe-coding to generate an application, creating an instruction file for an agent has a similar outcome, except designers never get the chance to validate the plan for each agent execution. We might restore some of that validation through a human-in-the-loop workflow, but the agent designer won’t be in the loop unless they are also the user.

Furthermore, when input comes from another agent, the expectations on input are not very clear. It’s not as unclear as coming from an untrusted user, but since the user of the calling agent might be less than fully trusted, we have to consider the possibility that a malicious user could cause the calling agent to pass dangerous inputs to the called agent. Depending on the design, that might be difficult, but proving it’s impossible is a high bar without some deterministic system in the path.

Agents Building Applications

At the apex of the framework we have agents building applications. Instead of a human using an AI tool to write code, an autonomous agent—or a multi-agent framework—is given the broad scope to architect, write, test, and deploy entire applications. Operating within bleeding-edge, emerging ecosystems like Steve Yegge’s concept of Gas Town, an overarching agent might autonomously spawn specialized “code worker” sub-agents to solve specific architectural problems. This introduces the reality of deep recursion: AI systems dynamically writing, testing, and deploying new AI systems at machine speed.

Agents Building Agents

An alternate apex is agents building other agents. While both scenarios rely on deep recursion where at least one level is indeterminate, the agents-building-agents path stores its recursive plans in natural language, rather than a programming language. Tools like Claude Cowork and Claude Code are bordering on this. Technically, they’ve always been capable of it, as a developer can create recursion somewhat trivially.

The barrier here has generally been security. It’s rather easy to say, “Agent A calls Agent B to create Agent C, which can call Agent B” (look, I just did it!). The hard part is whether that’s a good idea. Projects like OpenClaw push this further. When agents build other agent skills or update through tools like Moltbook, they are acting at this highly complex, deeply recursive layer. OpenClaw has some security controls, but not enough to prevent many users from making significant mistakes.

Another example here that illustrates the movement from applications to agents, is Gas Town in Gas City. Gas Town, the original multi-agent orchestration system for Claude Code, GitHub Copilot, and other AI agents, was an application. When Yegge wrote Gas City, a “orchestration-builder SDK for multi-agent systems”, Gas Town became “code free”, and instead a bundle of prompts and skills.

Ripple Effects: Cybersecurity

One constant that comes from more complex systems is greater challenges at securing them. All else being equal, indeterministic systems, either fully or wholly, are more complicated than fully deterministic ones. Security is traditionally about protecting deterministic plans from indeterminate actors (human hackers). Each layer adds complexity as well. Attackers will have new tools and will use them against the highest value targets that have weak points.

Fortunately, all this does not come without some benefits, both inside and outside the realm of security. Inside the realm of security, access to dynamic systems like agents allow for faster responses. As I’ve explored previously, this means security can’t wait—it will force not just an overdue commitment to defense, but complete organizational changes.

The highest value targets know this. They will rapidly adopt new defensive techniques, patching weak points faster than ever before. Where we will see more successful attacks is against more moderate value targets. Some operate efficiently and will adapt, but others will face an “adapt or fail” pressure cooker. They will suddenly find themselves defending against highly sophisticated, indeterminate automated attacks.

Overall, however, this is a narrative of optimism. As Dario Amodei notes, “the offense-defense balance may be more tractable in cyber, where there is at least some hope that defense could keep up with (and even ideally outpace) AI attack if we invest in it properly.” Security must simply shift toward robust bounding and sandboxing of environments, rather than assuming the predictability of the software operating within them.

Automation and Workflow Change

This shift in control—from human-driven applications to autonomous, recursive agents—isn’t happening just for the sake of technological novelty. Ultimately, the goal is, and has always been, automation. AI changes opportunities for automation by lowering automation costs that were previously prohibitive.

Classification and ML

Machine Learning (ML) is an AI technique that achieved broad use earlier than Generative AI. Classification and prediction tasks were the core use cases. It’s generally less well known than Generative AI because those use cases fit into embedded AI workflows that have less direct user interaction. But that doesn’t mean they haven’t been effective. Generative AI has some overlap, but it’s useful to note ML is not obsolete—it will continue to dominate specific classification tasks where the trade-offs favor highly optimized, low-compute execution.

But GenAI is shifting the math for automation’s long tail where engineering effort is the limiting factor. Traditional ML models require a significant engineering investment to train. While that engineering could theoretically be automated, doing so would bring you back to using GenAI to generate the code. When a general-purpose GenAI model can perform a task at equal quality without that upfront engineering time, it opens up a new option for countless use cases that were never practical to tackle with traditional ML. AI provides the structure to finally capture and automate the tacit knowledge we previously had to rely on humans to execute.

Workflow Change

This, and the other uses of Generative AI, allows a deeper decomposition of workflows. In prior methodologies, it was too expensive to capture the output of specific, granular steps. Those steps were done “in the head” of human workers, existing only as “tacit knowledge.” A workflow that may have produced better results might have been avoided because the human cost of data preparation or classification was too high.

While it’s possible to replicate the same workflows, trade-offs have shifted. Consider a nurse who has learned a new symptom for a patient. That nurse may lack the depth of medical knowledge or the patient’s full history, so may not be able to do more than record that information until the patient’s doctor can review it. But an AI system can reanalyze a patient’s information nearly instantly. It can recategorize data, make new recommendations, or provide the nurse with the relevant medical information and patient history. This could allow next steps that both improve efficiency, but also improve outcomes. Maybe it’s an extra test, or an extra question, or a life-saving reaction.

Because AI lowers the cost of executing small, indeterminate tasks, we can now decompose workflows further. What workflow is optimal depends heavily on hand-off costs. In the example of the nurse, the hand-off costs to the doctor were the impediment. Human to human or human to machine hand-offs are expensive compared to machine-to-machine. When tasks shift from human dependent to machine dependent, a reorganization of workflow makes sense. A particular flow which was used to avoid handoffs may no longer be necessary. More importantly, those handoffs that remain, will have higher relevance than before, and optimizing for them, rather than those that are no longer needed, takes priority.

Initially, we should expect to see pilots, trials, and first iterations operate within existing workflows. Changing workflows requires planning, training, and is hard to reverse or do incrementally. As such, it follows in later iterations. But many of the largest gains are realized with those iterations.

The Human Side

Workflow change can also have a significant impact on satisfaction amongst workers. Hand-offs can be the most frustrating type of work, depending on your personality type. Human to machine hand-offs become frustrating when flexibility is lacking, and you feel like your task is to fit a round-peg into a square hole. Human to human hand-offs can sometimes be enriched by the personal interaction, but they also expose you to misaligned goals, competing priorities and personality conflicts. Personal interactions are a lot more reliably fun when you get to pick the individuals and circumstances.

Worst of all, machine to human hand-offs can create the impression that you’re serving the machine, not the inverse. All hand-offs can have that effect somewhat, but it’s especially hard if there’s an endless list of machine generated work. It helps to detach from the “end” and focus on the progress here, but when an organization turns that into a metric, ruthlessly gamifies it, and fails to consider the impacts, it requires extreme stoicism to avoid burnout.

It’s important to remember the human side with workflow change. Ruthless metrics fail in the long term. Leaders should watch for that, and avoid allowing short-term goals to overwhelm long-term health. It’s not always clear that this fulfills the “bottom-line” if that’s financial performance. It’s always clear it’s better for broader goals than financial, but even for financial goals, the benefits are likely there, though harder to see.

Conclusion

The era of software as purely rigid, deterministic planning is ending. In its place is the rapidly expanding Agent Ecosystem. By integrating indeterministic models into our autonomous systems, and allowing agents to build other agents, we are trading perfect predictability for unprecedented scale and capability.

As the scope of these systems increases, our primary job shifts from writing static instructions to managing boundaries. We must build robust technical sandboxes to protect our cybersecurity, and we must build equally robust organizational boundaries to protect human workers from the burnout of endless machine-to-human hand-offs. We have to design systems that serve humans, not the other way around.

The question is no longer just “What can the chatbot say?” The real questions are: How much scope are we willing to give to indeterminate plans? How will we effectively bound the recursive systems of tomorrow? And, ultimately, how do we bound ourselves?

To the earlier question, you wouldn’t be alone if your first answer was a user-facing chat application—ChatGPT, Gemini, or Claude. Hundreds of millions, maybe billions of users have tried one of these1. It’s a great starting point to understand the current state of AI. You can probe with questions, get answers, and evaluate the output. 30 minutes of that will demonstrate more than any other 30-minute investment. That said, forming your entire impression of AI based solely on chatbots misses deeper shifts.

A second common answer is a robot from a science fiction movie—a human-like, but fundamentally alien, being. While creative, this vision represents what AI might be, not what it is today. Thinking about Sci-Fi AI often does more to help us understand human nature than actual machine learning. Take any part of it too literally, and it will make you less informed.

Understanding AI’s true impact requires closing the gap between simple chatbots and science fiction robots. We can do that by looking at AI through the lens of software engineering and control. Specifically, we can treat the control mechanism of software as a system of planning, governed by two critical axes: Determinism and Scope.

The Mechanics of Control: Determinism and Scope

Historically, software has been built on predictability. When a human developer writes traditional code, they are creating a deterministic plan. Once it passes through quality checks, validations, and testing, it becomes a solid, rigid set of instructions. While bugs exist, the system is fundamentally designed to execute the same way every time.

Humans, on the other hand, are inherently indeterministic; you never know exactly how a user will approach a problem, what strategies they will employ, or how they might adapt their plans on the fly. Generative AI models2—the underlying engines powering the familiar chat tools like ChatGPT and Gemini mentioned earlier—share this indeterminism. When a GenAI model creates a plan or a response, it is probabilistic. It will not necessarily produce the same output twice. That said, if there is a single correct answer that has been heavily reinforced during its training, the model will predominantly provide that specific answer. This consistency occurs because the statistical weight leans overwhelmingly in that direction, not because the system’s inherent flexibility has been mechanically removed.

The second axis of control is the execution environment, or its scope. An environment can be strictly bounded, meaning the actor (human or AI) has very limited tools and access. A user in a simple data-entry application cannot do much other than enter data. Conversely, an environment can have broad scope, featuring wide-ranging access to tools with compounding effects, such as command-line execution, file system access, or the ability to write and deploy new code outside of a sandbox.

By analyzing AI through these axes—how predictable a plan is, and how bounded its environment is—a clear narrative of evolution emerges.

What is Indeterminism?

What you identify as the “AI” in these applications is called a foundation model. This model generates responses to your inputs based on its “training.” Training is a process where the model is incrementally updated to make its responses match an ideal. You can think of the first training pass as an attempt to create a model that could rewrite the entire internet with as little inconsistency as possible. Initially, the model might predict a word because it looks like a piece of content it just saw. But as it processes more information, it encounters conflicts. By forcing the model to resolve millions of overlapping conflicts, it learns the underlying rules of how concepts connect. Later, a second training pass is applied to be much more specific about what is considered a “good” or “bad” way to respond to a human user.

Output from AI models is indeterminate. There are two factors that cause this. The first, unconquerable aspect is that the relationship between input and output is too complex to reason through. You actually can get a model to produce the exact same output for the exact same input if you adjust its “temperature” to zero. However, this doesn’t mean the model is truly predictable, because even minute changes in the input can put the model on completely different paths, even at zero temperature. The second factor is that when you see a model used in practice, the temperature is generally set greater than zero. Zero temperature tends to be boring, less creative, and less insightful without necessarily being more accurate—it just enforces a stronger consistency between input and output. But since the complexity of that relationship makes strict prediction impossible anyway, the value of zero temperature is limited, and the output remains, in all practical senses, indeterminate.

But indeterminate isn’t the same as random; it has a direction. With evaluation you can find a probability, and those probabilities can be high. But indeterminate also entails the chance for novelty, including surprise. To some degree, we might say indeterminism reflects a limitation of the user or designer’s ability to predict outcomes. But it’s not a limitation reflective of a lazy user or designer; it reflects a level of complexity no amount of attention can fully address. You can fight it a bit, gain some control and understanding, but if your expectation is full control, you’re using the wrong toolbox, wasting your time, and will ultimately fail.

Indeterminism is something you tame, not control. A tame agent is something that works with you. Tame things have many benefits, but also bear caution. A tame horse has advantages a car does not. If you fall asleep on a horse (and don’t fall off), the horse is very unlikely to jump off a cliff. A traditional, non-autonomous car doesn’t behave that way—it’s very deterministic at driving straight, whether that straight path leads down the road, into a wall, or over a cliff.

But a tame horse can still kick you. It’s far less likely than a wild horse, but if you approach it wrong or scare it, there’s no horse so well-trained that a kick becomes impossible. That’s part of the tradeoff of working with something indeterminate. A car with its engine off is going to behave like any other 2,000+ lb. hunk of metal on wheels, governed entirely by physics. Even in motion, while there are a few exceptions like engine or brake failures, it’s all just physics in the end.

Most software applications are designed to be determinate. A developer reasoned out what output a particular input should create, and planned this carefully. The plan of these applications is encoded into a language, and translated into machine code.

Understanding this shift to a probabilistic nature is crucial, because many choices we make will be founded on the seeking of a balance between dynamism and trust that intersects with that fundamental property of models.

The Thin Layer: AI as an Application

Most users have started to understand what GenAI is, and what its capabilities are, by using it as an application. What’s interesting about this is that these first applications started as very thin layers over the core internal generative AI model, so users have experienced the technology at nearly its most basic. It’s been a while since a novel computing technique has been exposed with so few extra layers.

In a formal sense, “AI as an application” means the primary interface is directly to a GenAI model. There are a few wrapper elements—identifying who you are, moving data back and forth, and providing some presentation of returned data—but mostly, it’s a wrapper. You send inputs, it sends outputs, and you directly converse back and forth.

In our framework, this is an indeterminate system operating within a strictly bounded scope. The user and the model are primarily in control. The text, images, or files you provide get fed to the AI, and its probabilistic responses are safely constrained by the application’s sandbox. Safeguards exist that neither can override, but within those boundaries, the direction of the interaction is controlled linearly by the human and the AI model.

Embedded Intelligence: AI within Applications

As software evolves, we are seeing a shift toward embedding AI directly into applications. While technically a chatbot is an example of this, it is highly useful to differentiate the two.

When a developer embeds GenAI into an existing application—for example, a GenAI-powered A/B testing engine that automatically generates and tests multiple variations of marketing copy to identify the best performer—the control dynamics shift. The overarching application remains a rigid, deterministic plan, but the AI represents a small, contained pocket of indeterminism.

With AI embedded in an application, the application is primarily still in control. When it uses an AI for a specific function, it cedes a small amount of control, but it has strict boundaries. The traditional software dictates exactly when the AI is called and where its output goes, strictly bounding its influence to specific micro-outcomes. There is immense potential left in this domain that the general public doesn’t recognize, simply because its precise use is entirely dependent on the creativity of application developers.

Prompt Engineering

An interesting detail about embedding is that prompt engineering becomes a critical function. Embedded GenAI needs a goal. With chatbots, the user can provide the goal. With embedded GenAI, if the input is from the user, it’s through things like filling forms or uploading documents. The embedded function should reliably reach a result that allows the application workflow to proceed.

Prompt engineering is the process of creating inputs to a GenAI model that perform better at achieving a goal than other inputs. Some parts of this are intuitive to anyone fluent in a language, like if you were instructing an actual assistant. Some parts are more particular to GenAI models, or even particular to specific GenAI models.

Technically, you can use prompt engineering when you use a chatbot, and you’ll get better results if you do. But there’s also an overhead in doing so, as you’re no longer expressing your simple intent, but working to make it fit a pattern. Model builders work to try and make prompt engineering less necessary for general user interactions, so some tricks are less important than they were in 2023. The most obvious parts will probably always be useful, like avoiding ambiguity when you have a clear intent in mind.

For embedding, the overhead of prompt engineering has a higher payback, so it makes sense to engage with it more deeply, and so developers do. Prompt-engineering is also used when creating custom chatbots3.

Another goal of prompt engineering is to constrain the output. Stronger, more consistent instructions produce more consistent outputs.

Embedding and Value

You might have noted that the A/B testing example earlier was a marketing example, and thus falls into the adversarial category of use I’ve talked about before. Marketing is often an early adopter of these embedded systems because the industry is driven by adversarial motives—constantly competing against others for user attention and clicks. But the true potential is much more inspiring. Consider an adaptive educational platform. The overarching application rigidly tracks a student’s progress, curriculum, and test scores (the deterministic plan). However, when the system detects a student struggling with a specific concept, it calls upon an embedded GenAI model to instantly generate a custom, interactive story explaining that exact concept using the student’s favorite hobbies as an analogy. The application remains fully in control, but it uses the AI’s indeterminate flexibility to provide a deeply personalized learning experience that hardcoded software never could.

Building Systems with a Life of Their Own

The control dynamic fundamentally fractures with the next pattern: using AI as a tool to build applications. So far, experiences with this have revolved around coding assistants and “vibe coding.” In some cases, it’s immediately clear this is different from the chatbot model because the AI is embedded within complex Integrated Development Environments (IDEs).

But what truly distinguishes this pattern isn’t the interface. Rather, it’s the output and how it is used. Business-focused tools like Claude Cowork or Amazon Quick are increasingly managing different inputs and outputs to help end-users pursue task-oriented goals, generating artifacts like documents, summaries, and presentations. But if that output is ephemeral—a static artifact used only to accomplish a quick, singular objective—it’s not building an application.

Building applications means building something that has a life of its own. It is the indeterministic generation of deterministic plans. The AI indeterministically generates a code script, which is then refined through human review, automated reasoning, and testing. Once committed, it becomes a static, deterministic plan.

The topic of control highlights the profound nature of this shift. When an application is built this way, there are two distinct phases of control. In the first phase, the developer is in control, sharing control with the generative AI model by delegating, authorizing, and reviewing. But the developer does not retain persistent control during the second phase. Once deployed, the built application itself takes control. If it runs on a server, the developer can turn it off or replace it, but that is supervisory control at best.

By building something with a life of its own, we take a foundational recursive step in software: using indeterminate AI to architect and generate the very deterministic logic that will govern computing moving forward.

From Chatbot to Agent

The user-facing AI chat application you engage with has already evolved to be more than a simple interface. Designers try to make this seamless for you, so you shouldn’t feel bad if you missed the change, but to understand the systems of tomorrow, we need to distinguish between a passive chatbot and an active agent.

When you interact with a standard chatbot, the control dynamic is strictly conversational and reactive. You provide a prompt, the underlying generative AI model probabilistically calculates a response, and then it stops. It relies entirely on you to drive the interaction forward step-by-step.

An agent, on the other hand, is an AI system designed to pursue a broader goal autonomously. Instead of just answering a single prompt, an agent takes an objective, indeterministically breaks it down into a multi-step plan, and uses available tools to execute that plan. It can observe the results of its own actions, correct its course, and continue working until the goal is met.

Understanding this shift from passive generation to active execution is crucial. By combining the probabilistic reasoning of foundation models with the ability to take independent action, we are actively moving away from simple chatbots and into the era of agents.

We have traced the evolution of AI from simple chat interfaces to embedded intelligence, and finally to the threshold of these autonomous agents. But recognizing this shift is only the first step. To truly understand where software is heading, we must examine the wild frontier of the agent ecosystem itself—how these agents use tools, how they interact with each other, and the cybersecurity implications of granting them broad scope. In Part 2 of this essay, we will dive into this ecosystem, exploring the deep recursion of agents building agents, and what this shift means for the ultimate goal of automation.

It is common to hear people argue that “technology creates new jobs,” usually pointing out that despite centuries of technological advancement, nearly everyone is employed today. Therefore, they argue, the fear that technology destroys jobs must be wrong. While it is true that technologies can both create and eliminate specific roles, framing the debate entirely around the technology misses the underlying engine. The real topic is the economy itself, which naturally seeks to create new jobs from available resources—the most limited of which is labor. Whether ATMs create more or less demand for bank tellers is simply not as important as we think.

Debates about automation often get stuck here. One side correctly argues that economies have historically created new jobs, but incorrectly attempts to prove this by claiming technologies always create new jobs. These are two different arguments. This minor framing issue does a lot of heavy lifting in keeping both sides from understanding each other. Once you look past the technology and focus on the economic engine, you can discuss the future of jobs in far more effective ways than debating the fate of bank tellers.

Why Does an Economy Create New Jobs?

It is easy to misunderstand how economies work if you view them through a lens of strict limits rather than dynamic balance. A certain mindset approaches every economic issue as a zero-sum game of apportionment—assuming there is a fixed number of jobs in the world, and introducing a new technology either adds to or subtracts from that finite pool.

It is not hard to see why this mindset takes hold; in a moment-to-moment sense, it appears true. At any given second, there are a fixed number of jobs. Eliminate 500,000 of them instantly, and you have 500,000 unemployed people. But economies are not static moments; they are moving systems that perpetually seek equilibrium. While external limits exist, the internal machinery of an economy is entirely dedicated to finding a balance between those limits and the limitless preferences and desires of the people within it.

That is why, in their default state, economies always create new jobs out of available labor. If there is an unmet desire among the population, and there is labor available to fulfill it, the economy will generate an opportunity to put that labor to work. This balancing act isn’t instantaneous. There is a “seeking” process to find a new equilibrium. Sometimes this process stalls, the economy malfunctions, and we experience high unemployment. But high unemployment is not the result of an absolute limit on total possible jobs; it is a breakdown in how quickly the economy adjusts to new parameters.

Will AI Create New Jobs?

Yes, it will. Will it create more than it eliminates? Probably not. But the economy will still create new jobs, and it isn’t dependent on AI to do so.

Consider software engineering. The number of computer programmers necessary to write and maintain a specific piece of software will likely go down due to AI. However, that doesn’t extinguish the societal desire for more software or better software. AI didn’t create those desires, but those human desires will inevitably create new jobs focused on building that better software.

Economies do not constrain the matching of human desire and available labor to a specific job description. Often, one job type is entirely replaced by another. As farming became more efficient with the advent of tractors and fertilizers, freed-up labor initially went back into farming to manage more land. Eventually, agricultural limits were reached, a different source of balance was invoked, and that freed-up labor transitioned into industry and manufacturing.

The same principle applies to AI. Until every need and desire of the human population is met, there will be pressure on the economy’s balancing forces to create jobs to meet them. The only absolute barrier to meeting that pressure is a lack of available labor. If AI ever becomes so universally capable that humanity literally has no more unmet needs or desires, we will have reached an incredibly unprecedented state. While I have previously explored how the economy might actually function if that AGI future arrives, history tells us that this kind of post-scarcity utopia is always further away than we imagine. In the meantime, the world gets more efficient without flipping into a topsy-turvy reality where the fundamental economic force of putting available labor to work ceases to exist.

What About the Short Term?

These macroeconomic forces dictate our long-term expectations: the economy will eventually balance out. But we live in the present, making it entirely reasonable to ask how the job market is changing right now and what to expect in the short-to-medium term.

Currently, I find the evidence of broad job market changes already caused by AI to be very weak. Conversely, I find the probability of broad future changes to be very strong. Most informed observers without ulterior motives tend to agree with this assessment. However, the prevailing public narrative has settled on the exact opposite amalgamation.

To the casual observer, the dominant narrative is that AI has already triggered widespread job losses and restructuring, but will ultimately fail to live up to its long-term hype due to inherent technical limitations. While this is just a prevailing vibe—and conversations often reveal more nuance—it is worth examining how illogical this combination of opinions is, and why it is so easily adopted.

Weighing the Evidence for Changes Already Occurred

The belief that AI has already upended the job market is easy to support because countless articles have delivered it as a concrete conclusion.

One form of article takes real statistics about a weakening job market—or specific sectors like tech—and correlates them directly with the release of AI products like ChatGPT. As a hypothesis, this is fine; as a conclusion, it is incredibly poor. It fails for two main reasons: it ignores major alternative economic forces, and it assumes a timeline of corporate reaction that defies reality.

Because an economy is about balance, if other substantial forces can explain job market shifts, the “AI did it” correlation becomes incredibly weak. When looking at the period since ChatGPT’s release in late 2022, we are swimming in alternate economic forces.

First, the COVID-19 pandemic created a profound shock. In-person jobs vanished and slowly recovered, while tech firms over-hired to meet the surging demand for remote work, supply chain management, and digital education. Executives extrapolated that temporary surge into permanent future demand. While some of that expected permanent shift was indeed realized, the world largely returned to a physical “normal.” As the most extreme growth expectations evaporated, it triggered a sharp, ongoing correction in tech employment.

Second, we experienced a severe inflation surge. While the exact interplay is complex, the relationship between inflation, interest rate hikes, and employment cooling is a foundational and uncontroversial economic reality. Finally, we are running the radical experiment of applying 1930s-style tariffs to a modern, globalized economy. Disentangling these three major, structural forces from the data to pinpoint AI as the primary culprit for recent layoffs is nearly impossible.

Furthermore, the timeline required for these correlation theories is implausibly fast. ChatGPT is released, and supposedly, jobs immediately begin to decline. No economic theory predicts immediate structural decline from a new tool. At a minimum, users must adopt the tool and prove its efficiency. Then, managers must recognize this efficiency, rewrite staffing plans, get approval, and execute layoffs. This takes quarters, if not years. Yet, the main correlational narratives point to tech job losses that actually began months before ChatGPT was even released.

This exact flawed logic was perfectly encapsulated in a viral graph that circulated widely, which Derek Thompson observed was often being shared with commentary declaring it the "scariest chart in the world". The chart accurately shows the S&P 500 rising while total job openings fall, with an ominous vertical line marking ChatGPT’s release right at the inflection point.

Derek Thompson

Is This the New ‘Scariest Chart in the World’?

In the last few days, I’ve seen the following chart bounce around my corner of the Internet, often with some commentary declaring it the scariest chart in the world. The graph seems to show that the release of ChatGPT and the ensuing AI boom cracked the US economy in two, crushing the workforce while lifting the stock market…

Read more

8 months ago · 496 likes · 22 comments · Derek Thompson

While the data points themselves are factually accurate, the suggested correlation is a classic case of confusing coincidence with causality. As a piece of media narrative, it is highly persuasive; as an economic argument, it is entirely unsupportable, especially considering the downward trend in job openings clearly begins before the AI tool was even available to the public.

It is entirely possible that some executives are acting on the ‘vibes’ of AI, restructuring their companies in anticipation of future gains we can’t yet see in the data. But in the present moment, those ‘vibes’ serve as the perfect smokescreen. Whether an executive is genuinely anticipating an AI revolution or simply needs to fix a bloated balance sheet, the public narrative sounds exactly the same. In reality, managers claiming AI-driven layoffs rarely have the data to back it up; rather, they have ulterior motives for cutting staff that they prefer to keep hidden.

Hyperscalers and major tech firms do not want to discuss how their cash flow is being squeezed by the massive capital expenditures required to build data centers and hoard Nvidia chips. Highlighting that reality invites investor scrutiny regarding the ultimate return on those investments. It is much easier to feed the market a narrative of “AI efficiency.”

Then you have executives who simply mismanaged their companies and need a convenient scapegoat for the necessary corrections. Add to this the universal motivation of any executive looking for a short-term stock boost: announcing headcount reductions under the guise of “doing more with less” is a brilliant Wall Street narrative. This practice of “AI-washing” layoffs—as seen with Jack Dorsey’s recent cuts at Block—avoids calamitous explanations like “we are losing customers” or “we are running out of money,” and actively excites investors in the short term, even if the cuts hollow out the company’s long-term capabilities.

Whether a company can actually do more with less will be tested in the future, not the present. The popular narrative assumes that newfound efficiency naturally dictates layoffs, but for a healthy company with opportunities to grow, turning efficiency into layoffs is hugely damaging. If a company suddenly needs fewer resources to maintain its current output, the logical move is to redeploy those resources to capture more market share or build new products. Layoffs generally only make sense if a company is correcting a past mistake (like rampant over-hiring) or if it has exhausted its growth options.

This reality exposes two fundamental flaws in the current public discourse. First, extrapolating the actions of these shrinking companies to the entire economy leaves no room for the story of companies that will use AI to expand. Second, it means these opportunistic, short-term cuts will eventually have to be reversed for companies that actually do have future potential. If they cut too deep today, service quality will degrade, feature releases will slow down, and competitors will steal market share. Eventually, they will be forced to reverse course and re-hire to regain their footing—having needlessly sacrificed their growth momentum for a temporary Wall Street bump. By then, however, the executive will have likely kept their job, exercised their stock options, and enjoyed the short-term bump from the AI narrative.

Another form of article driving the public narrative simply repeats these executives’ statements verbatim. They do so without examining the underlying data or considering the obvious financial incentives for executives to spin bad news (over-hiring or cash flow issues) into a forward-looking story of AI-driven efficiency.

The Delusion of Immediate Efficiency

Accepting these narratives uncritically builds a dangerous delusion: that AI has already unlocked massive efficiency gains, that the best use of those gains is shrinking the labor force, and that companies failing to do so are falling behind.

In reality, while AI has added efficiencies in specific pockets, we are mostly still in the learning and adoption phase. Any hours saved are frequently counterbalanced by training, integration, and implementation costs. Where true, systemic efficiency has been achieved, it is very recent and far from pervasive.

Because this shift is so nascent, we don’t yet have stories of mature firms using AI to successfully expand. Aside from new startups or companies explicitly selling AI infrastructure, the narrative is entirely dominated by contractionary stories—which, as established, are largely misdirection. Accepting these false contractionary tales severely distorts our perception of what the technology is actually doing to the economy.

Non-Linear Transitions

Furthermore, we must remember that stories about the impact of a specific technology are not comprehensive stories about the entire economy. If employment in a field like insurance claims processing genuinely contracts due to AI, the compensating job expansion will not necessarily be AI-related at all.

Freed-up labor might allow housing construction to expand, making homes more accessible and lowering costs. While expanding the housing industry requires more than just available labor (like zoning reform or lower interest rates), if those external limits are removed, the economy will naturally funnel available labor toward that unmet demand. This kind of non-linear adjustment is exactly what dynamic economies do. It is rarely instantaneous, and it is never without friction, but in its default state, the economy makes the adjustment.

A common objection here is the “skills mismatch”—the idea that a laid-off insurance claims processor isn’t going to suddenly start swinging a hammer. But an economy does not rely on perfect one-to-one transitions. Labor markets are highly dynamic, and indirect shifts do most of the heavy lifting. While some claims processors might actually enjoy learning a trade or already have prior experience in one, it is far more likely that their existing skills shift adjacently. An insurance adjuster might transition to a construction firm as a project manager, which in turn frees up the multitasking owner to spend more time actually building.

Even if only a small proportion of the labor force makes these types of lateral moves, the cascading effect absorbs vast amounts of economic change when all the different pathways are added up.

Conclusion

Ultimately, the story about the future of jobs is incomplete without an understanding of this economic dynamism. AI is a profound technological shift, and when the really significant changes it promises do start happening, that dynamic adjustment process will become more obvious.

But right now, separating the noise of the current moment from the signal of long-term economic behavior is crucial. If we believe media narratives driven by ulterior corporate motives, we will confuse ourselves with expectations that are neither complete nor correct. We must remember that AI is just a tool; the economy is the engine. As long as human desires remain unmet, the economic engine will continue to do what it has always done: take available labor and put it to work.

While these are undeniably critical issues, this focus has created a strategic void. The AI industry is aware of enterprise cybersecurity, and they are actively building tools to address it. However, the problem is being approached tactically, rather than strategically. Because they are not treating the defense of our digital infrastructure as a core, existential mission, a cohesive, industry-wide narrative has failed to materialize.

The hard truth for technology executives—CTOs, CISOs, and business leaders driving technology strategy—is this: the AI cavalry isn’t coming. At best you can hope for the AI industry, and the security industry, to work to sell tools. But for gaps that aren’t tool-shaped, it’s up to IT organizations to make this a strategic priority.

As I argued in Security Can’t Wait, advances in AI are drastically accelerating the attacker-defender cycle. Threat actors are already utilizing AI to automate vulnerability discovery and weaponize exploits at unprecedented speeds. Without an equally aggressive response, the segments of our defense lifecycle that remain manual and sluggish will fall hopelessly behind, handing attackers a permanent, dangerous advantage.

And right now, the weakest, most sluggish point of the defense lifecycle isn’t vulnerability identification. It is deployment.

Untangling the Past

The ability to deploy quickly is an element of great variance across the industry. Those variances have always been of importance, but the acceleration of AI-driven threats makes them a critical crux point. It’s tempting to assume this variance is simply the fault of the organizations that lag behind. But not only is that unhelpful, it’s also untrue. History often offers a better explanation, with only a moderate amount of fault left to place on the organizations suffering the ill effects. In my experience leading organizations through such changes, I find it’s best to leave that be and move on.

You might be unwilling to do so without understanding that past, so it helps to examine it. Additionally, even if you are ready to move forward, your organization may not be able to unless you can explain it to them. Some members of an organization lived through previous efforts to change, bear scars, and understand the reality. Others may have joined more recently and fail to understand why things are the way they are. A shared understanding is critical for an organization to work as one.

The most recent crux point for deployment was the adoption of “DevOps,” “Continuous Integration” (CI), and “Continuous Deployment” (CD). These paradigms are real, and their value is immense. Understanding them, however, is often clouded by layers of marketing jargon that have saturated software development for the last decade.

Make no mistake: the advent of DevOps, CI, and CD has been incredibly important. Even half-implementations, aligned with marketing that sold success before completion, have moved the needle. And the organizations that implemented them fully are now industry leaders in far more than just technology.

To appreciate why these changes left scars—and why implementations varied so wildly—we must look at the mechanical baseline they aimed to improve. Historically, software development and IT operations were strictly isolated. Development teams created software, generally working independently for months or even years, before handing the code off to the operations team to support and run in production. Because these teams had opposing incentives—developers were measured by feature delivery (progress), while operations were measured by system stability—introducing change was treated as an inherent threat. As a result, deployments were often massive, infrequent, and high-risk events.

DevOps emerged as a pragmatic and cultural approach to resolve this dysfunction. At its core, DevOps isn’t just a set of tools; it is a commitment to teamwork, communication, and shared goals. In its full realization, it requires unifying leadership to keep the two disciplines from pulling apart and devolving into political, rather than technical, management.

The Mechanics of Modernization

To support this cultural shift, the industry developed specific pipeline tooling designed to automate away the friction and reduce the stress that leads to organizational divergence:

• Automated Builds: In software development, code changes must be “packaged” into a build. Depending on the platform, this involves compiling human-readable code into machine-readable formats, resolving third-party dependencies, and packaging it into a deployable format.

• Validation and Testing: Beyond just compiling, a mature pipeline validates the code’s quality and executes automated tests. To make testing efficient, engineers test the smallest possible units of code (unit tests). This limits the scope of failures and uses less compute time. Inadequate testing can cause a pipeline that otherwise looks complete to produce poor results. Errors that reach production cause costly rollbacks, and the fear of repeating those errors slows everything else down.

• Continuous Integration (CI): Integration is the process of reconciling the simultaneous contributions of multiple developers into a cohesive system. CI extends the build process by making this integration a frequent, if not constant, event. By merging developers’ working copies several times a day, the complexity and risk associated with a final, massive merge are dramatically reduced. In the context of security, CI serves as a crucial enforcement point for the unified system. It is here that dependencies from multiple contributors are brought together, making it the primary stage for running deep, automated scanning tools against the combined application.

• Automated Deployments (CD): Once integrated, software cannot simply be pushed to users; safety constraints require it to be deployed to isolated test environments first. A true pipeline requires test environments that accurately simulate production. However, creating and supporting these duplicate environments is highly complex and the costs often become prohibitive.

Together, the premise of these mechanics was straightforward: mitigate risk by moving faster with tiny, highly automated, and easily reversible changes caught early by continuous feedback loops.

Deployment Divergence

However, as these concepts gained mainstream traction, a clear divergence emerged across the industry. It is tempting to think of organizations making the same technological choices simply by nature of being in the same industry—surely all banks are similarly modernized? In reality, there are significant deviations even within the same sectors. These divergences are shaped heavily by a company’s specific history: when they were formed, or when they attempted a prior wave of modernization.

Generally, organizations fell into one of three paths:

1. True Adoption: Many organizations successfully navigated this transformation. They did the hard work of aligning incentives under unified leadership and invested in comprehensive test environments, proving that modern, automated deployment is a highly achievable goal when backed by genuine commitment.

2. Watered-Down Adoption: Driven by vendor sales cycles and a management desire for painless wins, many organizations adopted the terminology without the substance. The genuinely far-reaching concepts were distorted to justify incremental tool purchases. Crucial but non-mandatory steps—like rigorous unit testing or maintaining accurate test environments—were skipped or done poorly in the name of expediency. Without true CI, integration remained sporadic. Teams bought the tools and declared victory, but failed to fundamentally change their deployment process or speed.

3. Stalled Implementation: Other organizations simply struggled to get momentum at all, weighed down by the sheer complexity and cost of entrenched legacy systems, such as monolithic applications and mainframes, which are notoriously difficult to integrate into modern CI/CD pipelines.

Why did so many organizations fall into the latter two camps? The root causes are deeply embedded in organizational dynamics. For years, technology teams have been caught in a tug-of-war between competing priorities. There is an unrelenting push to deliver short-term wins and new features, which inevitably drives the accumulation of technical debt. This is compounded by coordination issues between siloed teams, cost-cutting mandates, and general corporate politics.

The result of this divergence is that while excellent pipelines certainly exist, a significant portion of enterprises still grapple with brittle, sporadic deployment processes. They have automated the easy parts (like compiling) but left the hard parts (comprehensive testing and security scanning) as manual roadblocks. Without continuous, reliable feedback, deployments are batched, delayed, and risky.

This isn’t an indictment of current leadership; it is simply a realistic accounting of the accumulated friction of technical debt and conflicting priorities. But it is a reality we must acknowledge before we can move forward.

Clouded Perceptions: Restarting from Stalled and Watered-Down Adoptions takes additional effort to rebuild momentum because of terminology drift. It’s too easy to assume a shared commitment which turns out to represent different expectations. While you can’t erase the effect of the past, you can take the extra effort to communicate what is meant at each opportunity.

The Widening Gap and the Irony of Regulation

When an organization’s deployment pipeline is insufficient, the time it takes to patch a newly discovered vulnerability stretches from hours to weeks or months. Attackers have delays too, but depending on their delays—which might be accelerated by AI—is a risk.

We often look to regulation to force improvements in these areas, hoping compliance mandates will motivate continuous improvement. But here lies a painful irony: for the organization that has already fallen behind, regulation often creates extra friction. It introduces new audit gates and reporting requirements that further slow down the deployment process. Until the pressure is redirected toward a truly dramatic overhaul—with all the costs and commitment that entails—the effect of regulation is to slow defenders, leaving a wider gap attackers can exploit.

Assessing the Battlefield and Avoiding the Blame Game

If the mandate is to unblock these pipelines, technology executives must first assess their own relationship to the organization before demanding changes. Are you a new leader brought in with an explicit mandate to improve? Are you an established leader leveraging newly acquired influence? Or are you new to an organization where continuity, rather than disruption, was the stated goal?

Understanding this positioning is critical because diagnosing a lagging deployment pipeline often delivers bad news to teams who believe they are already doing their best. If delivered poorly, it forces the organization into a “fight or flight” response.

Crucially, executives must actively suppress the “blame game.” Blame is a destructive concept when fixing technical debt. Technical systems do not care who is at fault; they will succeed or fail independently. Seeking blame causes internal information sharing to become strategic and self-preserving, rather than solution-oriented. While identifying failures is necessary for strategic leadership changes, day-to-day technical modernization requires actively discouraging the blame game so teams can focus entirely on the fix.

Turning AI Inward

If current pipelines are too encumbered by historical debt to move at the speed of modern threats, they need priority. Yet, that priority is lacking and must be built. The AI and security industries are offering tools, but not implementation.

Technology-focused executives must take the driver’s seat. The DevOps playbook is well documented. But so are the impediments. New efforts and commitments are difficult. Past failures create inertia that needs unblocking.

Tools can’t solve this alone. What they can do is modify the impediments that held back implementation in the past. Those modifications create a compelling narrative to overcome inertia, and start new efforts and commitments to modernize deployment pipelines.

Consider the new opportunities to improve modernization efficiency and effectiveness faster using AI:

The Testing Burden

A robust deployment pipeline requires comprehensive automated testing, but developers notoriously loathe writing and maintaining tests. AI fundamentally changes this dynamic. If you have no tests, AI can scale up baseline coverage rapidly. If you have some tests, AI can identify and fill the gaps. More importantly, AI can monitor existing tests for brittleness, automatically suggesting refactoring or updates when underlying code changes. By removing the maintenance overhead, AI removes a primary excuse for failing pipelines.

Accelerating Legacy Transformation

Many deployment bottlenecks are rooted in legacy systems—like mainframes and monolithic applications—that were previously deemed too complex, expensive, or risky to modernize. AI transformation software is changing this calculus.

One methodology here is to reverse engineer specifications from an existing codebase. One significant challenge to modernizing any legacy system is understanding how that system should behave. There may be documentation, but it very likely has drift and inaccuracies that would undermine a transformation. A reverse engineering process is not likely to be hands-free, but a combination of AI and operators complement each other. That should make it possible to reverse engineer any existing codebase sufficiently to perform a quality transformation.

Testing comes into focus here again. Tests can be generated and employed on both the old and new source. Specifications assist in test generation. Tests assist in mechanical code transformation for core functions and methods. Tests and specifications also assist in larger-scale structural changes. Transformation strategies have traditionally relied on both of these, preferring small incremental updates when practical, and resorting to larger-scale rewrites strategically.

AI-driven transformation tools not only reduce effort via these steps, but improve accuracy and probability of success.

Resources:

• Gartner AI Augmented Code Modernization Tool Peer Insights

Shift-Left Security

AI-powered static analysis can be integrated directly into the developer workflow. This ensures that the code (and the AI-generated tests themselves) adhere to established security and quality standards before they ever reach the integration phase. Not only can this help avoid introducing new security issues, but it can raise confidence in the process of deploying fixes to known issues and newly discovered issues.

The quality of the tools you can integrate may be influenced by how modern and mainstream other parts of the stack are. COBOL and FORTRAN code won’t have the same level of support as Rust, Python, TypeScript, .NET, C or C++ code. While static analysis tools have existed for some time, the most developed tools in this space have evolved past simply flagging potential errors; they now utilize AI to drastically reduce false positives, understand the context of the codebase, and suggest specific, workable auto-fixes.

Resources:

• Gartner Application Security Testing Peer Insights

• G2 Best Static Application Security Testing Software

Securing the Pipeline

As pipelines become the engine of the enterprise, they become prime targets for attackers. Implementing highly effective but difficult security practices—such as least-privilege access for the pipeline itself—is complex to manage manually.

How this is done will depend on where your pipeline is implemented. AI tools can analyze code for access requirements, avoiding the admin needing to guess developers’ requirements. AI and conventional tools can analyze deployment patterns to determine used and unused privileges, which create a signal where to limit privileges.

Resources:

• Do Your CI/CD Pipelines Need Identities? Yes. (Cloud Security Alliance, 2025)

Disrupting Active Exploitation: An Essential Stopgap

While modernizing the deployment pipeline is the ultimate cure, technology executives must manage the immediate reality: vulnerabilities will exist in production while fixes navigate a sluggish pipeline. It would be irresponsible to omit AI’s capability as an ameliorative control during this window. AI-driven behavioral analytics and dynamic anomaly detection can be deployed defensively to disrupt the control and exploitation phases of an attack in real time. By identifying and isolating threat actors attempting to leverage unpatched systems, these tools buy the organization the critical time needed for pipeline improvements to take effect.

Implementation

AI tooling isn’t enough in the same way that DevOps tooling wasn’t enough. A plan is necessary, and that plan must engage with the culture of your organization. What type of modernization is needed? Why hasn’t it happened already? Will it require a full-scale transformation (mainframes/monoliths)? Is it about completing a watered-down adoption?

There are good sources on DevOps adoption (i.e., The DevOps Handbook), so I won’t try and repeat these in their entirety. Committing to completing adoption, and taking advantage of new opportunities that shorten or de-risk challenging aspects, is how to create your plan.

Conclusion: The Call to Arms

The acceleration of the cyber battlefield is a reality. The mandate for technology executives is clear: we must stop viewing AI solely as a threat to be mitigated or a product to be purchased, and start wielding it as an operational imperative. Accelerating our defenses requires accelerating our deployments. The tools are in our hands; it is time to use them.

Anthropic’s recent labor market analysis has improved understanding by analyzing “observed exposure”—shifting from theoretical feasibility to measuring how AI is actually being used across different occupations. This is a crucial step in understanding AI’s real-world footprint. However, a core assumption remains: if a task can be done twice as fast by AI, the required human labor spent on that task will decrease.

I suggest a deeper framework that confronts that assumption. A significant reason why AI capabilities will not translate into reduced working hours is that observed exposure fails to account for the dynamics of economic demand for tasks. Demand for tasks is not static. As a task progresses from theoretical capability, to observed exposure, to full exposure, dynamic responses should be expected.

The impact of AI does not depend solely on whether a machine can and is used effectively to do work, but on whether the demand for that work is Bounded, Unbounded, or Adversarial. How work is divided between those categories, how it’s packaged into jobs, and the dynamic interplay are critical to accurately predicting how AI adoption will change demand for work.

While I am only presenting the conceptual framework here, extending this to a quantitative analysis via task classification and applying it to datasets like the Anthropic Economic Index is the logical next step.

Tasks, Jobs, Outcomes, and Demand Dynamics

To understand labor impacts, I must separate the elements of work into tasks, outcomes, and jobs:

• Tasks are individual units of work executed to achieve a specific result.

• Outcomes are the overarching goals or results that a job seeks to achieve through the execution of tasks.

• Jobs are bundles of tasks organized and executed to deliver specific outcomes.

To this, I also add three categories of demand:

• Bounded Demand: Demand that has finite usefulness within related outcomes, and does not itself enable demand for new outcomes.

• Unbounded Demand: Demand with the potential for self-expansion by enabling demand for new outcomes. When scaled, efficiency completes entirely new outcomes with positive value. (Practically speaking, this does not demand a true lack of boundaries, just incredibly distant ones).

• Adversarial Demand: A non-bounded state1 driven by a zero-sum competition. When scaled, efficiency drives volume and complexity within the same adversarial outcome.

These three categories of demand are most readily applied to classify tasks, but we’ll find we also think of jobs in this way based on the type of tasks they hold. We can also see how outcomes are key to this, in differentiating unbounded and adversarial demand—separated by whether scaling them generates new outcomes or inflates existing outcomes.

The Dynamics of Efficiency Reallocation

Jobs tend to have a primary outcome (e.g., producing a car, solving a medical issue, resolving legal disputes). When that overarching outcome is adversarial, the underlying adversarial tasks act as an “efficiency sink.”

When AI automates routine, bounded tasks within that job, the worker does not simply work fewer hours. Instead, the time saved is reallocated into the adversarial tasks to maximize the overarching outcome. This dynamic maintains stable human labor hours despite high overall observed AI exposure.

Crucially, if all adversarial tasks are fully automated, the efficiency sink effect moves from labor hours to automation (compute/API) costs. But as long as a single adversarial task is left unautomated, it retains a significant portion of the efficiency sink effect, and total labor hours remain mostly unchanged.

Three Part Demand Framework

Occupational tasks can be categorized into three distinct economic demand buckets. Because jobs are organized to achieve specific outcomes, we observe task-level dynamics manifesting at the job level. When AI introduces efficiency gains, each bucket reacts differently:

Bounded (Satiated Demand)

• Reallocation Dynamic: There is no new work to reallocate. Faster outcome completion means work is finished earlier. Fewer workers are needed to maintain the same pace. Unless an unbounded or adversarial outcome indirectly generates new work, available jobs attached to these bounded outcomes will decline.

• Job Examples: Payroll Clerks, Data Entry Operators, and Technical Writers. Demand for Payroll Clerks is bounded by the number of companies, workers, and efficiency of the payroll process.

Unbounded Utility (The Infinite Backlog)

• Reallocation Dynamic: Faster production lowers costs. A backlog of demand reuses freed resources. Cost efficiencies sustain or expand fulfillment of potential demand. Time saved is used to produce more output, higher-quality outputs, or both.

• Reallocation Friction: Reallocation is not immediate. The demand backlog can become stuck for organizational, training, research, finance, or any other coordination issue.

• Job Examples: Computer Programmers, Scientific Researchers, and Healthcare Professionals. The backlog of desirable software, scientific discoveries, and medical care is never fully satiated.

True Adversarial (Zero-Sum Escalation)

• Reallocation Dynamic: Efficiency gains are weaponized to win adversarial outcomes. Time saved is reinvested into performing the task at a higher volume or complexity to maintain an edge over an opponent, scaling effort within the same outcome.

• Reallocation Friction: Escalation between parties can take time to emerge, and can be delayed or deferred by agreement, law, or practical obstacles.

• Escalation Attrition: Adversarial escalation eventually hits diminishing marginal returns. If AI allows lawyers to draft 10x the claims and counterclaims, they will do so to maintain an advantage. These claims and counterclaims add little or no extra utility to the justice system. If any, it was such fractional quantities that they would not have been pursued outside an adversarial system. Those dynamics don’t mean escalation isn’t subject to its own attrition where the next escalation not only fails to create social value, but fails to yield individual value.

• Attrition and Friction: The combination of escalation attrition and friction is another factor in delayed reallocation. The last layers of escalation yield the least individual value, which lowers any incentive to bypass frictions created by time, happenstance, law, agreement, ethical standards, or other factors.

• Job Examples: Lawyers (maximizing legal strategy), Salespeople (maximizing competitive wins), Marketers (battling for attention), and Cybersecurity Analysts (offensive vs. defensive escalation).

Note on Transitions: Tasks and jobs can shift categories. Customer Service Representatives are currently Bounded (dealing with a finite number of human interactions). However, if AI agents drop the cost of interacting with customer service to near zero, these outcomes could transition into Adversarial territory. While a customer-obsessed company does not view legitimate customers as adversaries, an open, zero-friction channel inevitably attracts malicious actors, automated fraud rings, and algorithmic social engineering at scale. Companies will be forced to deploy defensive corporate AI to filter this malicious volume, reallocating human CSRs to investigate and manage these complex, escalated algorithmic attacks.

The AI Labor Impact Matrix: “Three Sextants and One Half”

By mapping AI Exposure (High vs. Low) against the 3-Part Demand Framework, I create a 3x2 matrix for describing expected labor market behavior.

The Bottom Half (The Control Group)

• Low AI Exposure (across all demand types): Protected by physical friction, manual dexterity requirements, or strict regulatory roadblocks. This represents the status quo (e.g., physical trades, nursing).

The Top Three Sextants (High AI Exposure)

The highly exposed segment of the economy splits into three distinct zones, driven by different adoption incentives:

Sextant 1: The Efficiency Transition (High Exposure + Bounded)

• Early Influences: Early adoption is driven top-down by organizations seeking to realize the benefits of automation to reduce labor costs.

• Labor Impact: Measurable job displacement and hiring slowdowns. While this creates disruption for current workers, it represents an efficiency gain for the broader economy by freeing human capital from bounded tasks.

• Social Impact: Managing this shift requires robust social infrastructure. Social programs like unemployment insurance, retraining initiatives, and general social support must be central to navigating these impacts.

While disruption occurs across all sextants to some degree, societal resources and attention must be most heavily directed toward transitioning workers. Without support you lose both pre-disruption stability and the productive use of freed human capital. There is no social value in structural optimization if it doesn’t lead to new, more productive employment.

Sextant 2: The Infinite Frontier (High Exposure + Unbounded)

• Early Influences: Early adoption is driven by closeness to the technology industry.

• Labor Impact: Minimal displacement (subject to reallocation frictions), accompanied by productivity and objective output growth.

Sextant 3: The Arms Race (High Exposure + Adversarial)

• Early Influences: Early adoption is driven bottom-up by individuals with an aggressive, advantage-seeking demeanor, and others who are forced to adopt to survive a zero-sum game.

• Labor Impact: Minimal displacement (subject to reallocation frictions), task inflation, and potential for worker burnout.

Predicting Adoption Velocity: The Role of Worker Demeanor

While exposure metrics predict where AI can be used, analyzing worker demeanor helps predict how fast and by whom it will be adopted. Adoption is not solely a function of technological capability; it is deeply tied to the behavioral incentives and natural disposition of the workers in these roles.

• Status Quo Bias and Corporate Mandates (Top-Down): In Bounded roles, workers have little incentive to adopt a tool that finishes their workload faster, as doing so threatens their job security. Consequently, organic worker adoption in this sextant is heavily muted. AI integration here is almost entirely top-down, driven by management seeking cost reductions.

• Curiosity and Tech-Affinity (Bottom-Up): In Unbounded roles, early adoption has been driven by domain proximity and natural curiosity. Workers in these fields inherently value systems that reduce friction to build, solve, and create more efficiently. Top-down influences are secondary, but as a complement, create the fastest adoption.

• Advantage-Seeking Demeanor (Bottom-Up): In Adversarial jobs, workers are structurally incentivized to seek an edge. They actively test and implement AI independently because failing to do so means losing a deal or a case. Adoption is organic and aggressive. Top-down influences are secondary, and more about approval than directives.

The Prediction: AI tooling will proliferate fastest and most smoothly in Unbounded and Adversarial jobs (Sextants 2 and 3), driven by eager, self-motivated workers. In contrast, Bounded jobs (Sextant 1) will experience a delayed adoption curve, followed by an abrupt, disruptive shock as corporate mandates are enforced.

Societal Impact: Disruption and Outcome Completion

From a macroeconomic and social perspective, society will primarily be concerned with two consequences of this framework: the friction of job disruption and the new value generated from outcome completion.

The Reality of Job Disruption and Reallocation

Job disruption will occur most acutely within highly exposed, bounded jobs. It is important to clarify that absolute “zero displacement” in Unbounded and Adversarial jobs is merely a theoretical equilibrium. In reality, frictions in reallocating time and learning new AI-augmented workflows cause some temporary displacement in Unbounded and Adversarial jobs. The key difference is in Unbounded and Adversarial jobs final equilibrium is resistant to durable reduction.

Furthermore, as acute displacement occurs in the Bounded sextant, the freed human capital will likely reallocate toward Adversarial or Unbounded work, shifting the composition of the broader labor market.

Value Creation and Outcome Completion

For society to realize net-new value from AI, it must look primarily to the unbounded domain. This is where efficiency translates directly into outcome completion rather than zero-sum escalation. While early tech discourse heavily features Computer Programmers, the most profound societal benefits will emerge from fields like Science and Healthcare. The demand for scientific discovery, novel treatments, and improved patient care is effectively infinite. Scaling these tasks generates profound, concrete new outcomes for human well-being.

Conversely, AI usage in adversarial jobs toward adversarial outcomes, is largely irrelevant to net-new social value. Because it consumes resources that might have been put to better use in another domain, adversarial adoption can sometimes be a net negative, though it often balances out to neutral or slightly positive. For starters, existing human labor usage was a drag of its own.

Additionally deeper task completion within adversarial roles can result in slightly positive effects, but this is far from guaranteed. Adversarial roles are usually composed of a very valuable social good (justice for example), with an adversarial layer on top. The most significant realization of that social good comes at the first layers of engagement, and at most incrementally improves with more engagement. Even this is not a guaranteed conclusion though, there is no inherent reason additional investment cannot become extractive while failing to produce more social goods.

Critically, good planning around critical systems (like finance and law), can improve their social outputs and avoid their adversarial aspects amounting to net losses, but the opposite can be said of poor planning.

The Complex Social Dynamic of Art

Society will have a more complex relationship with certain adversarial domains, most notably the Arts. While the economic dynamic of art is highly adversarial—creators are engaged in a zero-sum competition for finite human attention—society does not view this escalation in the same way it views the “deadweight loss” of legal paperwork. The resulting explosion of media, storytelling, and design may be born from competitive escalation, but it yields cultural artifacts that society inherently values and consumes differently than pure corporate friction.

Crucially, art is often valued not simply for its outputs, but for its process. In a sense, you could attribute the same to any other field where the participants care about their own work, but society has always given a special place to art in this way.

For those reasons, it’s reasonable to not expect the domain of art to follow all the same dynamics of other adversarial domains. That said, it is clearly an early adopter, like other adversarial domains.

About Real-World Tests

The world is looking at real-world jobs data trying to find confirmations of early AI labor and other predictions. It is not wrong to look, but the expectation of finding confirmation here is unrealistic. Jobs data itself is messy, takes time to become accurate, and has some other recent large scale influences.

Anthropic goes so far as to compare a prediction to another prediction, in search of such confirmation. In their defense, they are clearly aware of the risks there and don’t tout their results heavily.

I look forward to putting my predictions to the test, and seeing the results of other tests. But I would also continue to suggest that we should expect null results and should not force data that only supports a null result into a definitive conclusion about AI’s ultimate labor impact.

Conclusion

When macroeconomic studies aggregate these three top sextants into a single “Highly Exposed” bucket, the stable employment driven by the Arms Race and the Infinite Frontier completely masks the real, acute job losses occurring within the Efficiency Transition. By evaluating occupations through the primary lens of Bounded vs. Non-Bounded (Unbounded/Adversarial) demand, we can isolate the exact sectors where AI will cause job displacement versus where it will merely fuel outcome generation or task escalation.

However, the underlying mechanics of both fields can feel frustratingly inaccessible. By design, cybersecurity is meant to be an invisible shield. Unless you are deeply involved in computing, you usually only notice it when it fails, or when it creates daily friction—like remembering a complex password. The inner workings of how your data stays safe remain mostly opaque, exactly as the engineers intended.

A similar dynamic applies to Artificial Intelligence. Today, it’s easy to experience AI through chatbots. You can ask questions, spiral into deep conversations, or generate images in seconds. But as impressive as that is, talking to a chatbot is just the tip of the iceberg. Behind the scenes, by some estimates, over half of all AI usage today is dedicated to a single task: writing computer code. It is an invisible shift of significant scale.

To understand why applying AI to cybersecurity is so critical right now, we first have to confront a widespread misunderstanding about what software actually is, and why it breaks.

The Myth of Perfect Software

If you don’t have programming experience, it is natural to assume that building software is like publishing a newspaper: you plan the layout, write the articles, print the edition, and the final product is permanently finished. In reality, writing software is much more like writing and maintaining Wikipedia.

When a printed newspaper hits the stands, it cannot be changed; tomorrow brings an entirely new edition, sharing little other than a layout, typeface, and name. But Wikipedia is an ongoing, living document. A single event sparks the first version of an article, but editors will argue over, revise, and correct it for years. Software engineers do the same thing. They write code, users report that something doesn’t work the way they expected, and the engineers go back and revise it.

Because fixing one piece of software often accidentally breaks another, they don’t stop there. They write entirely separate scripts—automated tests—whose only job is to constantly check the original code and ensure that older features keep working as the software evolves.

Testing exists because programmers are human. We misunderstand what users want. We misunderstand the limits of our computer hardware. We mistakenly rely on flawed code written by someone else. Testing protects programmers from their own fallibility.

Historically, programmers wanted their software to be deterministic. That means for every specific action, there is one specific, predictable reaction. If you move $100 from your savings to your checking account, savings goes down exactly $100, and checking goes up exactly $100. It sounds simple. Simple rules like this allow simple tests.

But users are highly unpredictable. They click buttons in the wrong order, type words into boxes meant for numbers, and combine features in ways the engineers never imagined. Add to this the physical realities of computing—hardware inevitably degrades, and surges in user traffic can consume all available memory—and the environment becomes chaotic.

Resilience

This dynamic chaos is difficult enough to manage when users are innocently fumbling around. To manage it, engineers must add another layer of complexity to their work: resilience. They don’t just program what happens when things go right; they have to spend countless hours programming exactly what happens when things go wrong, trying to ensure small failures don’t add up to large failures. This relentless pursuit of perfection makes building software exponentially harder.

Enter the Attacker

Attackers live in the gaps of a programmer’s incomplete plan. They look for the scenarios the engineer forgot to test. Sometimes, this looks like extreme user behavior: What happens if I type 10,000 characters into a password field meant for 20? What if I send thousands of requests at the exact same millisecond?

This doesn’t stop by “acting like a user”. Software has internal communication channels, invisible to users, and attackers will do their best to access and utilize these too.

An attacker is entirely happy with chaos as an outcome. They only need to find one weak spot, one forgotten variable, to force the software to do something it shouldn’t.

The AI Magnifying Glass

How does AI interact with this cat-and-mouse game? Fundamentally, AI is a magnifying glass. For attackers, it is a tool to scan for weak spots faster and more comprehensively than manual reviews allow.

The most obvious response is for defenders to use similar tools. If an attacker is using AI to find the cracks in your walls, you need AI to find—and patch—those cracks first. In the long run, the ability of AI to rapidly spot human errors in code will be a substantial advantage to defenders. But where this was useful before, it’s critical today. As the cat-and-mouse game accelerates, staying ahead is more critical than ever.

But this brings us to another major misconception about cybersecurity: finding the vulnerability isn’t actually the hardest part. Neither is fixing the vulnerability.

To an outside observer, fixing a security flaw sounds highly complex. Often, it isn’t. The majority of security vulnerabilities are born from tiny, simple mistakes: a list that is one item too short, a user granted one permission too many, or a line of code that says “and” when it should have said “or.” In a vacuum, a programmer could fix these errors in five minutes.

There is a worry that a little change might have a bigger impact. Other code may have tried to compensate for the mistake and now breaks after the fix. This is always a worry, and automated testing was a tool to minimize that worry. So fixes aren’t always easy, but they still aren’t the core challenge.

The real challenge is deploying that fix. Modern software is woven into complex corporate environments. A simple five-minute fix might have to pass through multiple testing environments, bureaucratic approvals, and compliance checks before it ever reaches the user. The quality of different companies’ deployment processes varies greatly. The best companies can deploy thousands of small fixes a day. Many other businesses struggle to deploy one update a month.

There are over 40,000 known vulnerabilities, with over 100 more discovered each day. And those numbers only cover known software and libraries. Code a company develops for itself can introduce unique vulnerabilities that aren’t part of vulnerability databases. While these won’t all apply to any particular company’s environments, enough will that one update a month, or even one per day, is not sufficient.

Attackers act as relentless inspectors who will punish a company for any delay. If AI helps an attacker find a flaw today, but your company’s approval process takes three weeks to deploy the fix, you are at a serious disadvantage.

The Economics of Cyber Warfare

This might sound like a losing battle, but the defenders actually have a distinct advantage: economics.

Cyber attackers generally fall into two categories: people who just want to cause random destruction (who are thankfully rare and usually lack the focus to execute complex plans), and people who want to make money.

That second group is large, but they are doing math. If the payoff is too low, or the effort required to break in is too high, they will give up and look for an easier target. You don’t need a perfectly impenetrable wall to stay safe. You just need a wall that is sufficiently expensive for a hacker to penetrate.

This is where AI will shift the landscape. High-value targets (like major banks or tech giants) are already rapidly adopting AI to patch their weak points faster than ever. Attackers will likely find these targets too expensive to hack, assuming they avoid the deployment trap. The security organizations meant to protect are sometimes the impediment, creating the delays that bring risk.

This varies significantly between organizations. All organizations realize the importance of security, but only some have been able to turn that knowledge into reality and bring about the changes that allow for rapid deployment.

Efficient deployment is part of the design of many organizations. Newer organizations with a tech focus usually started out this way, as the template has been demonstrated many times. Older organizations have sometimes moved up, but many older or non-tech-focused organizations sit in an uncomfortable gap here.

For those that have failed to keep up, their fallback is often more layers of security—which carries high costs, but remains effective in raising the barrier to entry for attackers.

The real danger zone will be moderate-value targets—companies that have something worth stealing but may operate with slow, outdated security practices, and lack the justification for the most expensive layered capabilities. AI will turn a harsh lens on organizations that have managed to scrape by unnoticed in the past. These companies will face a strict ultimatum: modernize their security, or risk severe breaches.

Again, there is significant variability. Those with efficient deployment will stay ahead. Those that don’t are at risk, unable to match the expensive high-value protections, but also behind their peers.

Ironically, the lowest-value targets—everyday individuals and small businesses—might actually see an immediate benefit. Because their core reliance is on outsourced platforms (like cloud email providers), they will instantly inherit the new AI-driven spam and scam detection tools built by the tech giants, without having to lift a finger. While outsourcing has its weaknesses, when it comes to core functionality with a broad user base, it’s hard to beat.

A Brief Aside: Adversarial Revenue

This mandatory modernization creates an interesting, somewhat circular side-effect in the tech industry: a concept known as “adversarial revenue.“

Because attackers are rapidly adopting AI, every potential target is forced to buy AI-driven defensive tools just to keep pace. Who sells those tools? Often, it is the broader tech industry that is developing these AI capabilities in the first place. For the companies providing AI security platforms, the rising tide of empowered hackers guarantees a sustained, highly motivated market. The threat itself creates the demand for the cure, making AI defense a uniquely lucrative sector of the economy.

Security revenue is a bit different than other adversarial roles. Here there’s a clear bad guy. In fields like laws and finance, two sides exist, but neither is clearly creating the inefficiency. It’s theoretically possible we might improve the ratio between productive and adversarial revenue here by self-policing or regulatory efforts, though that requires convincing those industries to give up some potential revenue.

Setting aside the financial balance sheets and returning to the mechanics of the conflict, a much simpler question often arises about these adversarial dynamics: why not just prevent attackers from accessing AI to begin with?

Why Not Just Ban the Bad Guys?

Unfortunately, it’s a deeply complex challenge. The best success leverages lesser amounts of privacy, but it would be naive to think a loss of privacy can provide a total solution.

There are two main ways people access AI. One approach is through “open-source” models, which are freely available for anyone to download and use privately on their own computers. Protections here are limited. Creators train them to refuse malicious requests, but determined attackers consistently figure out how to bypass those guardrails (“jailbreak” them). The best protection here is that, so far, open-source models are less capable, and degrade a bit more after being jailbroken.

A more common method is through “controlled hosting”—the major platforms where you must log in to use the AI. Here, the AI companies actually do fight back every day. This isn’t just a theoretical threat; companies like Anthropic and OpenAI routinely detect and disrupt coordinated attackers attempting to use their networks.

But their expectation isn’t to build a flawless barrier. Instead, they use the mechanics of bureaucracy to drive up the attacker’s costs. They require an email to create an account. They monitor activity for suspicious patterns. When they see something shady, they issue a “soft-block,” refusing the prompt. When an attacker repeatedly tries to bypass that block, the company bans the account entirely, forcing the hacker to create a new account. And then they block account creation patterns that look shady.

Even with controlled hosting, stopping malicious actors entirely is difficult. “Shady” is a judgment call, and the other side has the option of changing tactics. They’ll try to look like regular users. They can’t hide forever in this way, but the provider risks harming regular users if they react too quickly by blocking patterns that describe regular users.

The AI Apprentice

AI companies seem highly capable, so why can’t they stop this, even though it’s difficult? You might ask, if they are motivated enough. If you doubt the AI companies are sufficiently motivated, consider the story of “distillation” attacks, which demonstrates the limits of their control.

To understand distillation, imagine a hacker who knows they will eventually get caught on the major, guarded platforms. Instead of using the heavily guarded AI to find vulnerabilities directly, they use it as a master tutor. They feed the secure AI complex coding problems, record its brilliant answers, and use that data to train their own private, open-source AI models.

Think of it like sneaking a camera into a master locksmith’s workshop. You don’t need to steal the locksmith’s tools; you just record how they work, go home, and teach your own apprentice. Once the attacker’s private AI learns enough, they no longer need the major platforms. They have their own unrestricted hacking assistant, operating entirely under the radar.

Distillation attacks also come from rival attempts to improve their own AI model, using outputs from a better model. It should be obvious that the leading AI companies want to retain their lead, and stopping distillation attacks would help. That said, all have reported activity of this type, and while they’ve had partial success in detecting it, it’s only partial. Anthropic reported millions of requests it believes were distillation attacks. Google reports hundreds of thousands of requests too.

Major AI providers are highly motivated to prevent this. Distillation isn’t just a security threat; it’s the outright theft of their multi-billion-dollar intellectual property. The fact that tech giants actively try—and often struggle—to stop distillation proves that preventing misuse isn’t a matter of lacking the desire or financial motivation to build a flawless barrier. They desperately want to build that barrier, but the technical reality makes absolute control nearly impossible.

Privacy and Security

Placing the best models in controlled environments provides some improvements. It does then place some of our privacy in the trust of those controlling those environments. Such environments are designed to preserve privacy in a balanced way. Your requests do go through automated review, but there are internal guardrails on how those are maintained, and who and when someone sees violations. But we have to place some trust elsewhere that’s significantly different from the type of validation we’d need regarding the privacy of a locally run model.

What’s Your Role?

Knowing that this massive contest is occurring behind the scenes, what can you, as an everyday user, actually do?

While the tech giants fight over deploying complex code fixes, attackers will still try to go after the easiest target: you. AI allows hackers to create highly personalized, perfectly spelled scam emails and incredibly realistic fake websites. To stay safe, a few standard pieces of advice are more important than ever:

1. Enable Multi-Factor Authentication (MFA)

With just a username and password, your security depends entirely on no one ever guessing or stealing your password. If you reuse a password, or accidentally type it into a fake “phishing” site created by AI, it’s compromised. MFA, while occasionally annoying, ties your access to something physical that you have—like a phone that receives a prompt or an authentication app. Even if an attacker steals your password, they can’t get in without your phone.

2. Learn to Read a Web Address (and Spot a Fake Browser)

Attackers frequently build fake login pages designed to steal passwords. Because AI makes it easy to perfectly clone the look of a legitimate site, attackers have escalated to a new trick: the “browser within a browser.”

A web browser displays content from the sites it loads. As a side effect, malicious sites can draw a fake window inside the webpage that looks exactly like your browser’s top bar, complete with a perfectly secure-looking—but entirely fake—web address. To protect yourself, you must be familiar with the normal layout of your browser. The real address bar is part of the secure surface of your browser at the very top of your screen, not nested down inside the web page’s content.

Once you are certain you are looking at the real address bar, the URL can look like a long string of gibberish, but there is a simple rule of thumb: find the very first single slash (/) after the https://. Then, look at the word immediately to the left of the .com, .gov, or .org.

• If the address is consumer.ftc.gov/articles/..., the controlling word is ftc. You are on a government site.

• If an attacker tries to trick you with ftc.security-update.com/login, the controlling word is security-update. You are not on a government site; you are on an attacker’s site.

3. When in Doubt, Search

If reading the URL feels confusing, use a search engine instead of clicking a link in an email. Type the company name into Google. It is incredibly difficult for an attacker to manipulate search algorithms enough to place their fake website higher than the real company’s official site. Just be sure to skip past the first few results if they are explicitly labeled as “Sponsored” or “Ad,” as attackers sometimes buy ad space.

4. Be Wary of Voice Calls and Texts

You should never give out your MFA codes or passwords by email or by phone call. However, verifying who is actually on the other end of the line has become much harder. AI makes it trivially easy for scammers to clone voices or generate convincing, conversational text messages. If you get a call from your bank—or even a panicked loved one—asking for money or a security code, hang up. Look up their official phone number yourself, and call them back.

5. Keep Things Updated

You should get to know your computer’s operating system and web browser. Both have built-in mechanisms to install updates automatically. Don’t delay or avoid these updates. As we discussed earlier, deploying fixes is the hardest part of cybersecurity. When you see an update ready to install on your phone or computer, you are often receiving the exact “five-minute fixes” software engineers just wrote to patch a vulnerability. Install them.

What are AI Companies Doing to Protect You?

While your personal vigilance is the last line of defense, the tech industry isn’t sitting idle. AI companies are actively deploying countermeasures:

• Limiting Access by Attackers: When an attacker is identified, their accounts are deactivated. AI companies use complex pattern recognition—analyzing the content and origin of requests—to hunt down malicious users. It is a constant cat and mouse game. While it doesn’t stop all access, it raises the cost significantly. Every moment an attacker spends trying to defeat these protections is a moment they can’t spend conducting destructive attacks.

• Utilizing Guardrails and Training: AI models are trained with guardrails that inspect incoming and outgoing traffic, automatically refusing or modifying prompts that appear intended to facilitate harmful activity. Again, these techniques are not foolproof, but they disrupt access and diminish the utility of the AI for hackers.

• Scanning for Vulnerabilities and Orchestrating Remediation: Vulnerability scanning isn’t new, but AI enables broader and deeper results. AI companies (Google CodeMender, Claude Code Security, OpenAI Aardvark) are working directly with the cybersecurity industry to execute massive scans, instantly generate remediations, and orchestrate campaigns to deploy those fixes before attackers can act.

Securing AI Itself

It is worth noting that protecting traditional software from AI-empowered attackers is only one slice of the overall security story. A complete view of AI security must also engage with other massive topics: how to deploy AI safely within an organization, how to manage how your private data is used by an AI model, and how to manage “agentic” systems (AI that can take actions on its own).

There are also vital, high-level theoretical debates about preventing AI from being used for massively destructive weapons, authoritarian surveillance, or sci-fi “AI overlord” scenarios.

But every conversation needs a focus, and right now, the most immediate, practical threat to the average user and business is the invisible arms race occurring in everyday software.

A Reason for Optimism

Ultimately, the integration of AI into cybersecurity is a narrative of optimism.

Yes, the equilibrium will shift. There will be chaotic periods as attackers test new AI tools. But relying only on defense means attackers get to choose the time and place of the next battle. By using AI to significantly speed up how we write, test, and fix software, we take the initiative away from the attackers. We make the cost of doing bad business too high.

As Dario Amodei, CEO of Anthropic, has noted, the balance between offense and defense is actually tractable in cybersecurity. There is real hope that defense can outpace attacks—but only if we actively invest in it. The tools are here. Someone must do the hard work of putting them to use for good, lest they only be put to use for harm.

Related Articles

In my last post, I mapped the architecture of the AI industry. Today, we are diving into the top of that stack to answer the industry’s most critical question: how do we separate the technological hype from real, sustainable economic value?

While all layers are important, I’d argue that at this point in time, the application layer is the most critical of all. The first reason is this is where theoretical value becomes real value. If social value isn’t created, why should anyone care about AI?

A second and related reason is this is where financial value is realized. Social value and financial value can be unaligned. When they are unaligned, society can miss opportunities and experience waste. This cuts both directions.

A third and also related reason is that as individuals we care about our own financial positions, and this layer’s financial performance will set limits on the financials of every other layer. If revenues can’t be generated here, they cannot pay off the investments already made and planned for model training, nor investments made and planned for data centers filled with AI compute capable chips.

The goal of this post is to understand those aspects. Where does (or could) revenue come from? How large are these flows, and what motivates or justifies them? In the process, we’ll learn more about how AI is changing the world today and in the future.

Who are the providers in the Application Layer?

The way I define it, the application layer will seem like it includes almost the entire industry. I’ll explain a model to differentiate the application layers of these organizations from their contributions to other layers.

At the forefront, we have the foundational model builders like OpenAI (with ChatGPT), Anthropic (with Claude), and Google (with Gemini). While they provide the underlying “Intelligence Layer,” they also act as direct-to-user application providers. Everyone wants to—and needs to—be in the application layer. All the core providers want to enable diverse users within the application layer, but cannot entrust their future solely to a developing ecosystem. They are thus both enablers and active participants.

Alongside them are the massive cloud platforms—most notably Microsoft and AWS. While it’s tempting to look at their packaged applications (like Microsoft Copilot), their true gravity in the enterprise space lies in platforms like Azure AI Foundry and Amazon Bedrock. These platforms provide the crucial API infrastructure that allows other businesses to build their own custom AI applications. Because of their sheer scale and their role in hosting these APIs, their movements dictate much of the financial reality of this layer.

This reliance on API infrastructure is perhaps the most common blind spot in the current AI discourse. Media pundits, the general public, and basically anyone not actively involved in building AI-enabled applications consistently overlook it. It’s easy to fixate on what is visible—the chat interfaces and packaged consumer tools. The enterprise API layer, however, operates quietly behind the scenes, routing data and powering internal corporate workflows. This infrastructure isn’t a secret; the documentation for Bedrock and Azure AI is entirely public. But because the average person has no reason to read it or interact with it, this critical financial and operational engine remains largely hidden from view, and will likely remain so.

Finally, beyond these hyperscalers and hidden API layers, there is a rapidly expanding ecosystem of AI applications. While pure-play startups (like Cursor, Midjourney, or Harvey) provide early examples of entirely new workflows built from the ground up, they represent just a fraction of what is possible. Ultimately, this layer is about embedding AI into existing processes and tools, making it generally pervasive over time, with many of the most transformative use cases yet to be realized.

The Consumer vs. Enterprise Split

A key starting point to making sense of the application layer—and where its revenue comes from—is to categorize usage into two segments: consumer and enterprise.

The consumer segment encompasses personal usage, while the enterprise segment encompasses usage contracted for by a business. The lines can be blurry with self-employed businesses, gig work, and shadow enterprise usage. Imperfect as the distinction is, it still serves a purpose. The consumer segment shares dynamics regarding free usage and subscriptions that are important to understand potential growth. The enterprise segment is very diverse; while it has leading workload types, those workloads share pressures to demonstrate return on investment (ROI) and are challenged by implementation and integration.

Revenues for consumer usage are generally subscription-based. Conversion from free to paid is not straightforward; while limits on free usage create pressure, they can also alienate users. In this segment, usage isn’t measured by ROI but by “vibes”—does the user feel the tool is worth the monthly fee?

Conversely, the enterprise segment defaults to metered API usage (pay-per-token). This is exactly why the API platforms mentioned above (Bedrock, Azure AI) are so critical—they form the backbone of this enterprise business model. This metered structure creates a more predictable future by correlating revenue and costs directly. However, forecasting enterprise revenue depends on how capable organizations are at closing implementation and integration gaps. In a fully rational market, metered usage would create significant profit, but if the market deploys more capacity than the demand can satisfy, we may see usage sold at a loss just to recoup sunk costs.

The Activity Value Matrix

To truly answer the core questions of this article regarding social value, financial value, and financial performance, we need another framing tool alongside the consumer/enterprise split. This is where the Activity Value Matrix comes in.

The Activity Value Matrix is crucial because it establishes a reasoning model for what type of AI activity actually brings net-positive value back to society, versus activity that merely burns compute to propel the industry forward without creating real benefit. Furthermore, it helps us identify precarious gaps: cases where AI could create immense social value, but because we lack a sustainable revenue model to support it, that value will fail to materialize sustainably. By analyzing the relationship between Value (economic/social utility), Revenue (monetization), and Usage (active consumption), we can map the true health of the application layer:

From a social perspective, we have a few rows we prefer, but the most important is productive revenue. Free goods are enjoyable, but unsustainable, and so at a society level, we should expect to eventually pay. Public goods are likewise excellent, but the arrangements are complex and apply to fewer situations. While we might wish for an endless supply of free or public goods, it is via activities with productive revenue that we’ve moved forward.

Likewise, there are some rows we should fear. Waste is clear. The exploitative patent rent is clear. General patent rent is less clear. From a simple preference, we should dislike it. But patent rent is often a useful tool to promise as a privilege. When managed well, that promise encourages investment that subsidizes activity that creates growth that could not occur from productive revenue alone.

Moving Bottlenecks and Remnants

With these tools—the consumer/enterprise split and the Activity Value Matrix—we can start to examine individual use cases. Whether driven by consumer subscriptions or the pressure to recoup enterprise sunk costs, the operational reality is that actual AI adoption is heavily challenged by implementation and integration. As this adoption progresses, we will repeatedly encounter new bottlenecks.

Many bottlenecks are simply standard operational hurdles—like migrating legacy data, reorganizing teams, or passing compliance reviews—that get addressed one by one. While solvable, they still create significant diffusion delays that push the realization of productivity gains further into the future. Another type “remnants”, on the other hand, are the most resistant bottlenecks. They are the stubborn areas left behind after the easy problems are solved.

One of the most stubborn types of remnants is adversarial. As the matrix highlights under “Compelled / Adversarial Revenue,” these actions create a continuous loop of demand for intermediate outputs just to maintain existing outcomes—like AI generating better spam, which requires better AI to filter that spam. This burns energy and resources, generating revenue and usage, without creating net-new social or financial value.

To see how these bottlenecks and remnants shape an industry, consider Coding—arguably the leading edge of the application layer. Software developers are culturally accustomed to disruption, which reduces the organizational friction and diffusion delays seen elsewhere. Yet, their use cases perfectly map to our frameworks:

• Responding to the Adversarial First: A wave of security related investment is underway, and I expect will accelerate. This early adoption is driven by compelled security needs—using AI to find vulnerabilities and harden systems before attackers can use AI to exploit them.

• Paying Down Debt: AI is being deployed to clear existing bottlenecks by paying down technical debt—modernizing deprecated platforms and freeing up locked capital.

• An Engine for Change: Because software underlies modern business, increasing developer productivity acts as an engine for change across all other industries, eventually translating to new productive revenues.

However, if development capacity isn’t solved first, consider how a bottleneck might manifest as an increasing “Proposal-to-Product” ratio. If AI halved the time needed to create software feature proposals of twice the quality, we might describe it as a 400% efficiency improvement. We might also see twice as many proposals. However, if the capacity to actually write the software hasn’t increased proportionally, that 400% internal productivity boost might only translate to a 10% increase in final value.

If we’re not careful, we might incorrectly diagnose the proposal process as the problem. We might even blame AI and suggest all of those new proposals were “AI slop”. While it’s possible for tools to be misused, it would be ironically sloppy to jump to that conclusion. The overuse of AI slop is already a problem, so we should not add to it. If users decrease their effort by 10x, and get half the quality, then yes, we can call their output slop. But that would have been true if they decreased their effort by half without tools.

The real story here is of the bottleneck. The unused proposals aren’t necessarily low-quality slop; they are simply piling up behind a bottleneck further down the line.

Conclusion: The Reality Check

The Application Layer is the industry’s “Reality Check.” While the lower layers (Compute and Intelligence) have seen massive investment and technical breakthroughs, the Application Layer is where those breakthroughs are forced to justify their existence.

The distinction between the Consumer and Enterprise segments is vital to this justification, as it dictates the very survival of business models. In the consumer world, the value is personal and often ephemeral, driven by individual preferences and “vibes.” Here, adoption can be viral and instantaneous, but loyalty is fickle and valuations are tied to user engagement. In the enterprise world, value is rigorous and must survive the gauntlet of organizational change and ROI calculations. While adoption is slower due to integration hurdles, the resulting business models are often more durable and command higher valuations based on proven efficiency gains. While many use cases—like coding or creative generation—will exist in both segments, they will take on different “shapes” and adoption velocities based on these divergent preferences.

As we look forward, the specific tasks—the “Use Cases”—will define which segment wins and how much of that massive investment in lower layers can actually be recouped. In my next post, we will dive deeper into the Activity Value Matrix to see exactly where this “productive revenue” is hiding, how the shapes of use cases shift between consumer and enterprise, and where energy is simply being burned as “waste.”

Introduction

If you look solely at the headlines in 2025, the artificial intelligence industry appears like a single coordinated effort with unprecedented wealth. We see trillions of dollars in valuation, feverish construction of data centers, and a frantic race for silicon. But to view AI as a single, unified industry is to miss the mechanics of how capital flows, and how that creates stability in some places, and precariousness elsewhere.

The reality is a stack—four distinct layers of value, each operating under different laws of physics and economics. At the bottom is the concrete reality of energy and silicon. At the top is the promise of productivity through software. Between them lies a complex web of subsidies, speculative bets, and “soft dependencies” that are challenging the laws of traditional business.

At the base, capital is being aggressively spent on lower layers of the stack, to both meet current and expected future demands from higher layers. Higher layers are operating speculatively, bringing in capital through speculative investments and running at a loss, in expectation of unprecedented future revenue growth.

This creates a commercial stability gradient that decreases as you move up the stack, where revenue covers less of investment and depends more on future growth.

• The Compute Supply Chain (Layer 1) is paid first. While future demand, and thus revenues cannot avoid a dependence on the higher layers, they are also selling hard product today, and being paid well for it. As businesses, they are more stable, though you should be careful about translating that commercial stability into assumptions of stock price stability, which assume both high demand and high margins, neither of which is certain.

• The Operational Infrastructure (Layer 2) is mixing revenue from higher layers and cash flows from existing business to fund purchases from Layer 1. This layer is competitive even before AI, and AI’s influence may make it more commodity-like and more competitive. Investment is speculative, but structured for stability.

• The Intelligence (Layer 3) is precarious. Only a fraction of spending is covered by revenue; the remainder is funded by investment capital and debt, driven by high optimism. While capital costs are not as high as Layer 2, they are still high, and so are operational costs. Almost all this goes to Layer 2 as current revenues. Cash flow is negative and dependent on ongoing investment, while also being highly competitive.

• The Application (Layer 4) is diverse, and where value is realized. Other layers depend upon this to bring the revenues that pay for capital and operational costs. The risk here is an Attribution Gap. Real value is created, but measurement it is difficult. This leaves uncertainty if users will pay enough to justify the massive investments at lower layers.

This structure creates an unstable relationship. If spending in the Application layer doesn’t expand rapidly, the investment optimism funding the Intelligence layer could dry up, leaving a critical gap in the revenues needed to pay back investors and meet the ROI expectations of the infrastructure below.

An interesting exception to this structure is application layer companies can be more commercially stable than Layer 3 companies. If they demonstrate their own value to customers, and decouple via negotiation with Layer 3, they could reach profitability before Layer 3.

As a diverse layer, many different outcomes should be expected, with some companies successfully navigating their own path and others failing. Also, while this shifts more everyday, a reasonably significant part of this layer (25%) is direct OpenAI/Gemini/Anthropic user subscriptions, coupling that revenue to Layer 3.

Layer 1: The Compute Supply Chain

The foundation of the AI stack is not code, but the “hard” reality of atoms: the physical and logical inputs required to create intelligence. This layer is dominated by the high capital cost and expansion timelines of chip manufacturing, which feeds into the economics of the entire industry.

Foundries, such as TSMC, represent the hardest constraint and the largest capital commitment. TSMC alone is projecting $40-42 billion in CapEx for 2025. This creates a “pervasive price” because chip manufacturing costs factor into most other costs. Training needs chips, and inference needs chips.

While foundries deal with the brute force of fabrication, chip designers like Nvidia and AMD operate the Efficiency Lever. Their economic role is to maximize the usage of scarce foundry capacity. However, the lines here are blurring. Hyperscalers like Amazon and Google are increasingly designing their own silicon—Trainium and TPUs—to optimize their own costs, effectively internalizing the supply chain.

Surrounding this is the often-overlooked constraint of utility inputs: energy and real estate. All compute requires reliable power, making grid access a key determinant of land value.

One of the advantages for NVidia and TSMC’s is that chips are being sold today. TSMC may have high CapEx, but for 2025 has $120 billion in revenues, and $40 billion net income. NVidia has an even more appealing 2025 forecast of $115 billion net income and revenue of $200 billion, with only $6 billion in capital expense.

$115 billion in income doesn’t justify a $5 trillion market capitalization, it has to grow to support that, but as a business there’s no lack of commercial stability. It’s also a mistake to look at NVidia’s favorable position, and imply stability for the entire AI industry. That just means the rest of the industry is paying for NVidia, it doesn’t mean the rest of the industry can afford to.

If demand continues to grow this layer’s hard constraints—manufacturing capacity and power availability—will give it pricing power. If it flatlines, that’s lost, but investments will still be repaid. Demand would have to pull back significantly to translate into internalized losses. Stock prices could be volatile, and bad choices there could cause individual investors to experience losses, but that’s partly the nature of stock markets in general.

Layer 2: The Operational Infrastructure

Disclaimer

Now is a good time to remind you that while I work at AWS, this is a personal Substack. Opinions are my own.

Sitting directly above the supply chain is the Operational Infrastructure, defined by the delivered compute. This layer efficiently deploys chips using existing cash flows, and keeps them operational. Very CapEx dependent, but so far, self-financing. The primary examples are the hyperscalers: AWS, GCP and Azure. These companies are absorbing the massive AI infrastructure costs using cash flows from mature, non-AI businesses like search and retail. A full accounting must consider smaller providers and private deployments.

We are witnessing a classic Installation Period: a rapid infrastructure overbuilding driven by FOMO and strategic necessity. Similar to the fiber-optic boom of 1999-2001, physical assets are being deployed ahead of proven demand. While this typically leads to a capacity glut, such a glut is eventually beneficial for the economy, as excess capacity drives costs down and subsidizes the next wave of innovation.

In my follow-up, I’ll dive into

1. The CapEx numbers from each entity

2. The CapEx breakdown by type (chips, land, buildings, etc.)

3. The differences between projected CapEx, announced CapEx, commitments, and actual spending.

4. The revenues from supporting training, inference.

Layer 3: The Intelligence

The third layer is the speculative core of model providers. The current core are those with frontier model programs, such as OpenAI, Anthropic, Google, Amazon, Meta. While this layer captures the public imagination, its economic footing is far more slippery than the infrastructure below it.

These companies face a brutal paradox: they provide the cognitive engine for the entire ecosystem, yet “intelligence” itself is trending toward a commodity.

In this high-velocity environment, legacy advantages are fleeting. A leader can be dethroned by a single release cycle from a competitor. Unlike the infrastructure layer, where assets have a useful life of years to decades, a frontier model can depreciate in months.

Changes in position happen often. At the moment of writing, December 2025, OpenAI is not the leader, and it’s open to debate between Google Gemini and Anthropic Claude Opus/Sonnet as the momentary leader. You’re only as good as your latest model on the frontier. Niches are developing, on a cost basis and use case basis. But even here, a niche can be swallowed by the new frontier release, or lost to a new release targeting the niche.

A long term advantage here would have to be founded on execution: creating effective models cost-efficiently. The most optimistic view is that a recursive feedback loop emerges. If AI improves model architecture via an algorithm loop, or AI improves chip design, these create novel impacts.

A chip design loop would be slow and shared, as a new chip design would have to go next to manufacturing, and dependent on chip designer intellectual property. An algorithm loop could be faster, and self-contained. While this area is fairly speculative, it’s a foundational one to how many model providers think, at least at the fringes.

Financially, this layer is precarious. Revenues are not large enough to pay for past training costs, so companies are still unprofitable. Internally they face a revenue gap where growth projections often presume exponential conversion of free users to paid users, without a proven reason for that assumption. They also are dependent on the realization of many other revenue sources from the application layer.

In my follow-up, I’ll dive into the revenues and expenses at this layer.

Layer 4: The Application

The most critical disconnect in the modern AI economy sits at the very top: The Application Layer (Layer 4). This is where the rubber meets the road—where enterprises and consumers actually use AI to solve problems.

In a healthy market, the revenue from this top layer would cascade down, paying for the models, the servers, and the chips. Today, however, that flow is a trickle compared to the flood of investment rising from the bottom. We are facing an attribution gap. While AI creates real value—writing code, summarizing documents, speeding up research—measuring that value is notoriously difficult.

Besides the attribution gap, there are other frictions, an implementation gap, an integration gap, and an adoption gap.

Before users can make use of the potential capability of a model, for a specific purpose, they often need an implementation. Consider coding and coding tools as an example. Before coding tools, like Kiro, supported spec driven development, the ability to use models for this purpose was challenging. The same goes for earlier advancements, such as generating tests. Sure, you could in theory have done this with a chatbot and a lot of copy and paste, but that’s not good enough to make it practical. The implementation takes theory to practical. The number of implementation gaps, between what the best models could in theory do, and what users have good tools to do, is growing faster than it’s shrinking.

Even with an implementation, another type of gap is an integration gap. Intelligent decisions depend upon access to relevant and current data. Data does not automatically become integrated. For good reason, data has to go through the process of integration, where security, quality and structure have to be resolved. And it’s not just data, but also actions, which quite reasonably have a yet higher bar for proper integration.

Finally, there’s the adoption gap. Even when a tool or process is available, and integrated, skepticism, awareness, and habits often mean it’s not used. There’s a relation back to the attribution gap here too, as the inability to attribute value helps fuel skepticism.

The attribution gap, and the other frictions slow down both the actual implementation, and the creation of revenue. This results in a lag effect. The industry is currently in a race to see if revenue can expand fast enough to justify the valuations before the Installation Period speculation cools.

In my first follow-up (The AI Application Layer), I dive into:

1. Two types of revenue, consumer and enterprise, and their different frictions. A preview here; this is changing rapidly and the enterprise is becoming more important.

2. Different types of value-revenue relationships, and their importance to delivering social value from usage.

A future follow-up, will dive into tasks that can create revenue, and their relationship to value.

Macro-Economic Effects

I’ve written about this a bit in the past…

In my follow-up I’ll dive into:

1. How the current state of the AI industry feeds into the overall economy

2. How different types of revenue have different effects on the economy separate from the effects on the AI industry.

Conclusion

The bottom of the stack is being paid for by upper layers. The largest contribution comes from the internal investment by the infrastructure layer. But this is reaching its limits. Some additional capital is being supplied by the intelligence layer, in the form of external investment spent on training and inference in excess of their own revenues. Finally, the application layer is bringing in revenues. Those revenues wouldn’t be less than enough to pay back CapEx to date, and would be trivial in comparison what would be needed to pay back projected CapEx.

Thus, the current internal and external investment is absorbing the costs of infrastructure in the belief that the application layer will eventually catch up. If projected CapEx is to occur, new sources of investment will be necessary, likely through debt and larger amounts of equity financing. A drop in optimism could cut these plans short and create market volatility.

This is not necessarily a disaster; it is a historical pattern. We are deep in what economists call an Installation Period. Much like the fiber-optic boom of the late 1990s, we are overbuilding infrastructure ahead of proven demand. This is a feature, not a bug, of technological revolutions. This overbuilding is inflationary and chaotic, driven by Fear of Missing Out (FOMO) and strategic necessity.

The eventual result is almost always a capacity glut. It’s not a foregone conclusion, and pinpointing the timing is a much harder prediction than the simple occurrence. If you forecast on potential value only, and ignore the attribution, implementation, integration and adoption gaps, it’s almost certain to occur.

In theory, good forecasting can forestall or avoid a glut. In practice, there’s usually at least one market participant that’s constitutionally inclined to pursue the most optimistic interpretation, and FOMO pulls others behind this wave. Lagging behind too much when optimism prevails risks being left out with a struggle to regain position. In other words, playing it safe isn’t always safe.

When optimism finds its failing point stock valuations correct violently. But for the economy at large, this is the “turning point.” A crash in the cost of intelligence would reduce the barriers of an attribution gap, spawning a burst in adoption that needed to unlock a Deployment Phase. With past revolutions this is where the technology becomes cheap and reliable enough to be woven into the fabric of everyday life.

With AI, we might wonder if the model of the railroads, which experienced serial corrections, could fit better as one correction is not enough to close all of the potential gaps.

For now, the AI economy is a structure supported by massive financial scaffolding. The heavy lifting is being done by legacy profits and speculative investment, all betting on a future where the friction of adoption disappears. The question is not whether AI adds value, but whether the application layer can expand quickly enough to catch the weight of the massive infrastructure being built to support it.

Next in this Series

In the coming posts, we will peel back the layers of this stack one by one, examining the specific data and market dynamics driving the Compute Supply Chain, the precarious economics of Model Providers, and the reality of Enterprise Adoption.

Currently, if I want to read just one specific essay from a writer I don’t subscribe to, I usually can’t. I hit the paywall and leave. That’s a loss for me, and it’s money left on the table for the writer.

I think there is a middle ground that would help readers explore more independent work while putting more money in writers’ pockets: The Reader Pass.

How It Could Work

The idea is simple: a way to support writers individually without committing to a marriage. It acts like a pre-paid tab for the whole platform with volume discounts built in.

1. Set a Budget: I set a monthly limit I’m comfortable with—say, $10.

2. Pay-Per-Post: When I want to read a paywalled post from a writer I don’t subscribe to, I can “unlock” it. This deducts from my budget.

3. Bonus Tiers: Once I hit my limit (e.g. 10 articles for $10), I don’t just get cut off. I unlock a “bonus” set of free articles.

4. Scaling Up: If I exhaust my bonus articles, I can approve the next tier. Each subsequent tier offers significantly better value (more articles for the same price), plus its own set of bonus free reads.

Here is how the value could scale as a reader spends more:

This structure incentivizes heavier reading. The deeper you go into the ecosystem, the cheaper it becomes to explore, removing the hesitation of “is this one article worth it?”

Why This Helps Writers

The biggest worry writers might have is, “Will my subscribers downgrade to this?”

I honestly don’t think so. True fans want the community, the archives, and the direct connection of a full subscription. The Reader Pass is for everyone else—the casual readers who are currently paying $0.

• Earn from Casuals: Instead of bouncing off the paywall, a casual reader pays $1. That adds up.

• Find New Subscribers: This is a great way for readers to “date” a writer before marrying them. If I find myself spending $5 a month unlocking a specific writer’s posts, it becomes an easy decision to just switch to a full subscription.

Why It’s Good for the Community

Right now, Substack can feel a bit siloed—we stick to the writers we already know. A Reader Pass turns the platform into a library where we can wander the stacks. It encourages us to take a chance on a new voice or a niche topic we wouldn’t normally pay for.

Respecting Independence

Of course, independence is the whole point of Substack. This shouldn’t be forced on anyone. If a writer wants to keep their work exclusive to full subscribers, they should absolutely be able to opt out.

Conclusion

The subscription model is amazing for supporting our favorite writers, but it creates a wall for everyone else. A Reader Pass would smooth that out, helping curious readers support more independent voices without the pressure of a full annual commitment.

Let’s Make It Happen

If you agree that a Reader Pass would make Substack better for everyone, let’s make some noise. Share this idea with your favorite writers, or tag Substack to let them know we’re ready for a middle ground between “all or nothing.” We want to support more writers—give us the tools to do it.

Democratic Leadership has been taking flak for the outcome of the shutdown standoff. While that’s not too surprising, I think it should find a different conclusion. To frame that context here, I’ve been unsure about engaging in the shutdown from the start. I’ve been a bit more supportive this time around, as there was a clear outcome the Democrats were seeking here, and it did seem worth a stand. All that said, as recently as Sunday I was saying, if I was in congress, I’m not sure what I’d do. My reason for that is that the shutdown was causing real impacts to people, and it was getting worse.

It’s one thing to make a stand, and put your political reputation on the line, it’s another to do it when people you’re trying to protect are being hurt. I’d want to be sure it was going to succeed, and ideally, I’d want to know those that were at risk, were willing to take the risk themselves. If I had been a senator and broken ranks, that would have been the reason, and would have been how I explained it.

When you look at the explanations of those that broke ranks, their explanations aren’t very dissimilar.

“We have airport controllers. And we were seeing lines to our food banks in northern Nevada. These were lines that I hadn’t seen since the pandemic.”

I’m going to suggest that Democrats shouldn’t be spending their time attacking each other right now. Yes, there is a reason to want the group to act as one, and so I understand the impression that this is a failure. But on the other hand, giving in because you care, that’s something you should consider forgiving. More than that, the real story here should be, the Republicans were willing to throw America under the bus to take away healthcare. The separation between Democrats that were willing to take a stand to protect people’s healthcare and those that were willing to take a drubbing from their own party to protect people harmed by the shutdown, shouldn’t be a division you can’t get past. It’s two sets of good intentions, with a hard choice.

Besides being true, that statement is also one every member of the Democratic party should want to reinforce amongst the public, who were largely on their side throughout the shutdown, so reasonably could be expected to understand how terrible the Republican position is. Additionally, if you value unity as a party, I think this is just the moment to take the initiative. Punitive statements and in-party fighting aren’t necessarily more useful for developing party discipline than recognizing the common cause and acting accordingly.