For a generation the scarcity assumption that shaped enterprise technology was basically correct - at least on the large-enterprise path many of us lived. Building software was expensive, slow and capacity-constrained. Demand usually exceeded supply. Backlogs felt permanent. Major initiatives waited on headcount, budget or scarce specialist skills. Much of the operating system we still use - prioritization processes, stage gates, justification rituals, offshore delivery, low-code platforms, agile transformations - grew up as ways to stretch and allocate limited engineering capacity. Those mechanisms were rational responses to a real bottleneck.

The culture that grew up around them was rational too. When resources are visibly limited, people learn to protect their slice. They hoard headcount, defend their roadmaps and compete internally for the next available slot. That is what sustained scarcity teaches organizations to do - protective habits, not a moral failure of the people inside them.

AI has changed the cost side of the equation. Code generation, testing, documentation, analysis and even early architectural work are becoming faster and cheaper at a speed those processes were never designed for. Tiyyagura calls this the "Great Enterprise Cost Reset." Making software is less often the hard part; deciding what is worth making, whether it will deliver business outcomes and whether it can be run safely at scale is harder. Teams can already generate far more prototypes, automations and experiments than they can usefully absorb. That is what abundance means here: a structural shift in which creation is cheap enough that the scarce resources become selection, prioritization, alignment, safe operation and the judgment that holds them together - still finite capacity, still real risk, and still no free pass on outcomes.

Stack leans on a metaphor from Adam Jacob - co-founder of Chef, later System Initiative, co-founder of Swamp with Stack. Picture an organisation as a set of pipes sized for a certain flow of change. Throughput - how fast work and software can be produced - has risen sharply. Jacob puts the rise at roughly an order of magnitude. The old pipes cannot carry that flow. They burst at the joints. Patching leaks buys time; rebuilding how work is encoded is the real fix. Teams that already rebuilt are not waiting for everyone else to finish evaluating tools. In my experience, earlier platform shifts often left years before the gap was obvious; Stack argues this feedback loop is measured in months. Scarcity language lands under that pressure.

Budget, headcount and permission constraints can still be material. The live question is whether the same scarcity cues we used when creation was the bottleneck still fit - or whether they misdescribe the capacity now available and train people for the wrong habits.

The Roux paper is something I learned in this stretch of reading that has immediately applicable lessons, and it resonates with what I have seen. My takeaway is this: reminders of resource scarcity activate a competitive orientation - people become more focused on advancing their own welfare. That does not always look like classic selfishness. It can show up as keeping resources when that helps the individual directly, or as generous-looking behaviour when giving (or appearing generous) helps indirectly - status, reputation, future favours, social signalling. The studies were done with consumers, not engineering organisations. I am not treating the paper as a proof about enterprise. I am treating it as a useful lens: if leadership language is one of the main ways a system reminds people that resources are limited, then those reminders can shape behaviour as well as describe the budget. That is why the phrases in planning sessions are worth examining as inputs to how people act, not only as reports of the numbers.

When that kind of reminder lands while creation capacity is rising, the familiar protective habits have more room to do damage. Picture a quarterly planning session - the kind many large organisations still run under labels such as programme-increment or PI planning - where two teams both want agent-assisted automation for adjacent problems. Capacity language still frames headcount and budget as the scarce goods, so each side protects its roadmap slot, sits on what it learned from a pilot, and waits for a committee to allocate "AI spend." Six months later both have half-finished prototypes, neither can reuse the other's work, and a competitor that encoded the same class of problem once is already shipping the next iteration. Knowledge got hoarded; the experiment became political; local optimization beat the enterprise outcome - and the faster creation gets, the more expensive that pattern becomes.

If the whole industry were still moving at roughly the same pace, over-using scarcity language might only be a cultural hangover - annoying, but shared. My own experience, both inside Ticketmaster and outside it, tells me we are not in that world. The gap between teams using AI effectively and teams still evaluating it already behaves like a different way of working. The sides are separating in method, not just in tooling scorecards, and each encoded workflow widens that separation. Against that backdrop, the language leaders use carries operational weight: it is one of the ways people get trained for caution and delay, or for the work of encoding automation so the next build is cheaper.

Stack's map of three groups matches what I have been seeing.

One group compounds. They encode automation so the next build is cheaper than the last. They hit slop, untrustworthy agent runs and bad judgment about where AI fits - and treat those as engineering problems: conventions, adversarial review, design context that loads into the system, trust boundaries the machine enforces rather than a stricter prompt that freezes the agent. Stack's report from that frontier is blunt: the models have been good enough for serious engineering for months already; the teams that started early are not merely further along a linear path. Every workflow they encoded compounds.

A second group moves the other way. Loud distrust. Domain exceptionalism. Cost skepticism. In some cases outright bans. Stack points to public reporting of widespread avoidance or rejection of employer AI tools, and describes at least one mid-size tech CEO who banned AI entirely after concluding people could not make the right judgment calls on where it made sense - removing the option rather than building the judgment. The symptoms they cite are often real. Unstructured AI use does produce slop. Agents without conventions, without review pipelines, without verifiable trails do produce unreliable output. Stack and his collaborators hit the same problems early. The difference is they treated failure as something to engineer around.

The largest group sits in the middle: pilots that never graduate, committees evaluating tools competitors already ship with, perpetual "not yet." Stack puts them on the fault line. Their caution is real; so is the cost of freezing on scarcity-era prudence when throughput has already jumped and the default sentence is still some version of "let's not get ahead of ourselves."

In a divergence, scarcity cues staff the freeze and the middle while the compounding side keeps encoding. They function as allocation decisions about which side people rehearse for.

Agent outputs are probabilistic, often plausible and sometimes wrong. Hallucination, drift and overconfident wrong answers come with the territory. The real question is whether guardrails become a major focus of engineering, or remain a side note after the demo.

What Stack calls treating failure as an engineering problem is the same shape as my understanding of Skelton's idea for agentic systems more generally: deliberate boundaries around permissions, process and evidence. Call it bounded abundance. Treat the increased creation capacity as real, and put durable constraints on how it is used so teams can move faster inside a known envelope - rather than competing for every experiment through scarcity-era approval machinery, or hoping unstructured agent use will sort itself out.

That is ordinary operating judgment under different assumptions about cost and speed. Engineering teams already have partial strategies (reviews, evals, human-in-the-loop). The compounding side's lesson is that those strategies have to live in the system: conventions, adversarial review, and trust boundaries the workflow enforces as infrastructure - a longer system prompt alone is not enough.

Technology is only part of this. How people cooperate matters when incentives pull toward self-protection. Reading the Roux paper reminded me of a related set of ideas from Prosocial World. Prosocial is built around a set of organisational design principles for groups under competing incentives - shared purpose, equitable participation, transparent monitoring, conflict resolution, adaptation among them. I have used these ideas effectively in several contexts. They are a design vocabulary for cooperation that matches the competitive pull scarcity reminders can set off - worth trying here, though I am not running a formal Prosocial programme right now.

On the technical side, I have been looking at Swamp - which Stack and Jacob co-founded - as one concrete way to put the machine side into engineering practice. Swamp is open-source tooling for AI-native automation: real-world things become typed resources (with schemas - Zod is the validation layer the system is built around), methods act on those resources, and multi-step work is composed as workflows declared as YAML DAGs. Process and quality guardrails sit in the graph that runs. Method and workflow runs produce versioned data; evidence and decisions can be persisted immutably on disk so there is an audit trail and material for later decisions, not only a chat scrollback. Stack's "put the guardrails in the machine" is the same instinct.

The practical questions change. Instead of defaulting to "Can we afford to try this?", which form of intelligence - human, rule-based, agentic or some combination - fits this work, and what boundaries around permissions, spend, audit and rollback make sense for it?

Many problems are still better served by deterministic rules, existing workflow engines or straightforward human judgment. Frontier models and autonomous agents fit some jobs; they are defaults for none. Raw creation capacity is less scarce than it was. Judgment about matching the right form of intelligence to the job, and putting the right boundaries around it, is where the constraint has moved. Stack puts the valuable work in the same place: problem definition, system design and judgment calls - the work automation cannot yet turn into commodity implementation time.

Stack also argues that competitive advantages - "moats" in the strategy sense: the hard-to-copy edges that used to keep rivals out - built on hand-written integrations, bespoke scripts and one-off process are shrinking for the same reason. Expertise still matters; the time it takes to turn expertise into code is becoming commodity. Hiring contracts, seniority ladders and team shapes designed for the old throughput are lagging that shift. Organizations that ban AI or freeze on scarcity language make the later correction harder: people who want the new way leave for it, and people who stay keep rehearsing freeze and middle habits while the compounding side rebuilds how work gets done.

The difference that will matter is not how much AI output an organisation generates, but how well it turns that output into outcomes while keeping risk within bounds.

Whether most organizations treat abundance as real, rebuild the pipes, and stop treating scarcity talk as the only prudent voice is still open - and the cost of leaving it open is rising. For myself, I am paying attention to how I talk about capacity day to day: whether I still default to creation as the scarce thing, or whether I am talking about judgment, alignment and safe execution instead.

• Paul Stack (HashiCorp → Joyent → Pulumi → founder of Swamp Club), The Great Divergence in Software Engineering (9 July 2026). Provides the three-group map, Jacob pressure analogy (including the order-of-magnitude throughput framing as Stack presents it), months-scale feedback loop, machine-enforced guardrails, moats, and the reverse/ban examples Stack reports.
• Satish Chander Reddy Tiyyagura (Operations Solutions Architect, Southwest Airlines), "The Great Enterprise Cost Reset" (Substack, 2026)
• Matthew Skelton (Team Topologies), "Bounded Agency: The Missing Operating Layer for Enterprise AI" (Holistic Innovation, 2026)
• Adam Jacob (co-founder of Chef; System Initiative; co-founder of Swamp with Stack) - pressure/pipes metaphor as Stack presents it
• Caroline Roux, Kelly Goldsmith and Andrea Bonezzi, "On the Psychology of Scarcity" (Journal of Consumer Research, 2015) - shared by the CTO with my SVP, then with me
• Prosocial (Atkins, Wilson and Hayes; Prosocial World) - builds on Eleanor Ostrom's design principles for governing the commons
• Marc Benioff / Salesforce hiring remarks - IT Pro, 23 Jan 2025, reporting Benioff on engineering seriously debating whether to hire anybody that year amid AI-agent gains
• M. Frantzen, AI Didn't Replace Engineers. It Replaced the Excuse to Hire (June 2026)
• Usman Sheikh (LinkedIn) on pause-hiring / freeze-budgets framed as AI efficiency - LinkedIn post
• Uber CTO AI tooling budget remarks, summarized in Citadel Securities, The Economics of Intelligence (April 2026)

Back to main page