Categories
Computers IBM

The Day the Last Mainframe Went Dark

Note: I literally grew up during the heyday of the IBM mainframe era. My first real job was working for IBM in San Francisco beginning in 1968. Iโ€™m a โ€œbig ironโ€ kind of guy. But this post was imagined after reading the following in a July 14, 2026 announcement from IBM: When we discussed our expectations with you in April, we noted that we would be wrapping on the launch of z17 in the second quarter. Given this was the strongest start to a mainframe program in our history, we expected Infrastructure revenue to decline low-single digits for the year, beginning this quarter. What played out was worse than our expectations, driven by a shortfall in our Z performance and the associated software stack, primarily in Transaction Processing. In the last few weeks of June, we saw clients shift their quarterly capex spend toward servers, storage, and memory purchases to secure supply-constrained infrastructure ahead of expected price increases. This dynamic impacted client buying patterns. While we anticipated some supply chain related impact in our expectations, we did not anticipate the magnitude of the capex reprioritization.


It won’t arrive with fanfare. No countdown, no viral video of engineers raising a glass. One morningโ€”sometime in the 2040s, perhaps laterโ€”a small team in a climate-controlled data center will complete the final cutover. They’ll flip the switches, watch the lights dim, and listen as the hum of the last production IBM mainframe fades to silence. An era that began with the System/360 in 1964 will end. Not with a crash. With the soft click of obsolescence.

We’ve been predicting the mainframe’s death for decades. In the early 1990s, pundits declared it doomed. They were wrong. Those systemsโ€”reliable, secure, capable of staggering transaction volumes with near-perfect uptimeโ€”became the invisible backbone of modern life. Your last bank transfer, airline reservation, insurance claim, or government benefit likely touched one. They endured because they solved hard problems well: high-volume, mission-critical processing where failure was never an option.

The path to that final power-down was never a rupture. It was a long, uneven evolutionโ€”driven by economics, technology, talent shifts, and the patient work of modernization. AI tools accelerated the transition. They didn’t cause it.

Lessons from Earlier Transitions

Steam engines dominated railroads for generationsโ€”powerful, reliable, deeply integrated into the industrial economy. Diesel won through incremental advantages: better efficiency, lower maintenance, longer trains with less labor. Railroads rebuilt infrastructure and retired the old iron as the economics aligned, route by route.

Prop planes opened the skies to mass travel. Jets brought speed and range that transformed global connectivityโ€”but airlines didn’t scrap fleets overnight. They ran hybrids during the overlap, invested in new airports and training, and retired props as jet economics and passenger demand made the case irresistible.

The mainframe followed this pattern. AI coding agentsโ€”Claude Code, Cursor, OpenAI models, AWS Transform, IBM watsonxโ€”transformed the brutal manual work of understanding undocumented COBOL, extracting buried business logic, generating tests, refactoring safely. What once demanded scarce veteran experts for months or years could now be accelerated, with rigorous human oversight and equivalence testing.

Platforms like Visa’s Pismo showed a smarter path: incremental modernization. Cloud-native microservices layered alongside legacy cores, rather than rip-and-replace. Banks demonstrated real progress. Hybrid strategies wonโ€”AI inference running close to sensitive data on evolved mainframes (IBM’s z17 and successors, with on-chip accelerators), while new applications and analytics moved to elastic cloud environments.

IBM positioned the platform as an “AI factory” for low-latency, secure workloads. But pricing pressure was constant. High, capacity-based software licensing made the economics harder to defend as cloud offered predictable, usage-driven costs and younger talent gravitated toward modern stacks. For CFOs weighing rising maintenance against retiring COBOL expertise and AI-assisted migration, the scales tipped.

By the mid-2030s, competitive and regulatory forces intensified. Fujitsu’s exit from mainframes created a cliff in affected markets. Skills shortages accelerated. Even the most conservative holdoutsโ€”ultra-high-volume, regulated systems in finance, government, specialized industriesโ€”began serious moves, as simulation environments and exhaustive parallel testing brought the risk down to manageable size.

The Final Act

The last systems to go were the stubborn ones, where disruption carried outsized consequences. When the final cutover succeededโ€”after months of flawless parallel runningโ€”the team powered down the machine. A global bank, a payments processor, a government entity. Maybe a small ceremony: engineers who’d kept it alive for decades, trading stories of the iron that never failed when the world needed it most.

Picture the aircraft boneyards outside Tucson or Victorville, retired 747s sitting in rows under the sun, giving up parts to new generations before they’re recycled. Mainframes will meet a similar fate, more climate-controlled. Some linger in warehouses as insurance, still humming faintly in test or archival roles. Others get dismantled by IT asset disposition teamsโ€”data wiped to standard, processors and I/O cards harvested for niche markets. The bulk gets recycled, metal and circuitry returning to the supply chain. Like the jets, the iron won’t vanish in disgrace. Its lessons in reliability and disciplined engineering at scale live on, embedded in whatever comes next.

The world didn’t stop. Transactions kept flowing, now on distributed, elastic, AI-augmented platforms that had absorbed the best of what came before. The mainframe era didn’t end in failure. It ended because better options finally existed for every workload.

What Endures

We’ll look back with respect and nostalgia. The mainframe wasn’t flashy, but it taught something durable: some problems reward obsessive focus on reliability and scale; disciplined engineering outlasts hype cycles; the wisest transitions are rarely clean breaks. They’re patient evolutions that carry forward what matters.

IBM will have completed its own transformation by thenโ€”software, services, hybrid orchestration, AI tools that work across environments. The company that built the platform helps close the book on it.

The last mainframe going dark won’t feel like loss. It will feel like the natural close of a chapter that powered the digital economy through its most formative decades. The iron did its job. Now the next architecture takes the stage, standing on shoulders built to last.

Categories
AI

The Quiet Setup: MacSparkyโ€™s Robot Assistant and the Unfair Advantage Still Available

A single X post caught my attention this week. It described something quietly happening among a small group of solo professionals. They arenโ€™t working longer hours or grinding harder. Instead, theyโ€™ve built a particular kind of setup around AI that carries much of the load.

While most of us still treat powerful models as clever search barsโ€”typing questions and copying answersโ€”these folks have given the AI a rich folder of context, a briefing file that orients it to their world, connections to their tools, and routines that let it produce real work on its own. The result can look like the output of a small team. From the outside it reads as talent or luck. Up close, itโ€™s mostly architecture.0

The post (from @zephyr_hg) emphasized that this advantage remains available because most people havenโ€™t yet made the shift from one-off prompting to building persistent systems. It landed with me because it echoes so closely the practical territory David Sparks (MacSparky) has been mapping for months in his Robot Assistant Field Guide.

MacSparkyโ€™s Approach: From Chatbot to Persistent Colleague

Davidโ€™s work centers on building a true personal assistant using Obsidian (for a local, plain-text knowledge base) and Claude (in its file-aware โ€œCoworkโ€ or project capabilities). The system isnโ€™t a chatbot that forgets everything between conversations. Itโ€™s designed to remember your projects, preferences, and people; triage email in your voice; handle morning briefings; track tasks; process documents; and support weekly reviewsโ€”freeing you from what David calls the โ€œdonkey work.โ€

The key ingredients will sound familiar to anyone who read that X post:

  • A dedicated context layer (your Obsidian vault or structured folder) holding the details of how you work.
  • Briefing/instruction files that tell the model who you are and what good looks like.
  • Integrations that connect it to email, calendar, files, and other tools.
  • Skills and routines that turn one-time intentions into repeatable, low-friction action.

David has been refreshingly transparent about the journey. He experimented earlier with more fully autonomous agents and even shut one down after learning what felt reliable and aligned. The Robot Assistant Field Guide distills those lessons into videos, workshops, templates, and a starter kit that lets people build without needing to code.

Why This Matters Now

Both perspectives point to the same shift in stance: moving from โ€œHow do I prompt better today?โ€ to โ€œWhat kind of system do I want running alongside me every day?โ€

For me, at this stage of life, that question carries weight. Iโ€™m not chasing maximum output for its own sake. I want arrangements that protect attention and energy for what actually mattersโ€”deep reflection, family history work, thoughtful investing, writing that might be useful to others, and simply being present. A well-designed AI setup doesnโ€™t just save minutes; it changes the texture of the day by reducing context-switching and repeated explanations.

It feels like finding a productive seam in the current moment of AI evolutionโ€”one of those hidden transitions where leverage quietly compounds if youโ€™re willing to build the architecture.

The Door Remains Open

The encouraging message in both the X post and Davidโ€™s teaching is that this isnโ€™t locked behind rare talent or expensive infrastructure. The models are accessible. The patterns are becoming clearer. Whatโ€™s required is the decision to treat AI less like a toy and more like a colleague youโ€™re willing to orient and trust with real work.

I donโ€™t have my own โ€œrobot assistantโ€ fully built yet. Iโ€™ve been experimenting with custom agents, structured daily scans, and ideas like โ€œThe Observatoryโ€ for signal synthesis. Reading these sources side-by-side sharpened my sense of the next layer: giving the system a proper home, clear instructions, and meaningful recurring work.

If youโ€™re a solo professional, creator, or lifelong learner feeling the press of too many small tasks, this is worth exploring. Start small. Build a modest context folder. Write a briefing file that captures how you think. Experiment with one routine. Iterate from there.

The setup that outworks the grind isnโ€™t magic. Itโ€™s deliberate, learnable, and still wide open.


What setups are you experimenting with these days? Iโ€™d love to hear in the comments or on X.


Categories
AI Programming Software Work

The Scarcest Thing

Garry Tan woke up at 8 a.m. after sleeping at 4. Not because he had to. Because he wanted to see what his workers had done overnight.

The workers are AI agents. Ten of them, running in parallel across three projects. And something about that sentence โ€” wanted to see what theyโ€™d done โ€” keeps stopping me. Thatโ€™s not the language of someone using a tool. Thatโ€™s the language of someone managing a team.

Tan gave a name to the state this puts him in: โ€œcyber psychosis.โ€ He said it as a joke. But the joke has an insight in it. Heโ€™s not describing addiction to a productivity app. Heโ€™s describing a shift in what it means to do creative work โ€” the strange vertigo of becoming a director when youโ€™d always been a laborer.

Iโ€™m retired. I watch this from the outside now, which is its own kind of vantage point. For most of my career, the path from idea to working product ran through people โ€” through hiring and managing and the slow accretion of execution capacity. You had the vision or you didnโ€™t, but either way you needed the team. The idea and the means of making it real were, structurally, separate things. The gap between them was where companies lived.

What Tan is describing is that gap closing.

The thing he built โ€” gstack, his open-sourced Claude Code configuration โ€” got dismissed in some quarters as โ€œjust prompts.โ€ And it is just prompts, in the same way that a conductorโ€™s score is just notation. The abstraction is the invention. What he encoded is a model of how a startup team thinks: the CEO who interrogates the why before a line of code gets written, the engineer who builds, the paranoid staff reviewer who looks for what breaks. Each role blocks a different failure mode. Blurring them together produces, as his documentation puts it, โ€œa mediocre blend of all four.โ€

Thatโ€™s an organizational insight. It has nothing to do with code.

Tan described being a โ€œtime billionaireโ€ โ€” not because his biological clock had slowed, but because he can now purchase machine-consciousness-hours. The bottleneck of implementation, which has governed every creative project since the beginning of creative projects, is dissolving for those who know how to direct.

The scarcest thing is shifting. Itโ€™s no longer the hours of execution. Itโ€™s the clarity of intent โ€” knowing what you want to build and why the journey matters, before any of the workers start moving. Thatโ€™s harder than it sounds. For decades, most of us could muddle through in the making of it. The act of building taught you what you were building. Now the making is cheap, and that shortcut is gone.

For someone watching from retirement, thatโ€™s not a small thing to absorb. The model I internalized over a long career โ€” that ideas become real through sustained organizational effort, through teams and timelines and the grinding work of execution โ€” is being revised faster than I expected. Not invalidated. Revised. The judgment still matters. The taste still matters. The why matters more than ever.

Itโ€™s just that the how has found new hands. Many of them. More than any team I ever assembled, available the moment the intent is clear enough to direct them, gone when the work is done. The constraint was always the hands. It turns out it was always the knowing.

Categories
Micropayments

The Wrong Who

I was in the room for most of the early micropayments conversations. The working-level conversations, where people were genuinely convinced they had finally solved the problem. The demos were always compelling. The unit economics made sense on a whiteboard. And then they died.

They died so many times, and in so many similar ways, that the failure started to feel like a law of nature.

Clay Shirky wrote the autopsy that most people remember: micropayments fail because every transaction requires a decision, and decisions have a cognitive cost that swamps any payment below some psychological threshold. A dollar feels like real money. A dime feels like a question you have to answer. A fraction of a cent feels like being nickeled-and-dimed at sub-human speeds. The advertising model won because it asked users to consent once, peripherally, and then never bother them again.

So I noticed something when I read the transcript of Cloudflare CEO Matthew Princeโ€™s earnings call remarks this afternoon.

Heโ€™s predicting that the internetโ€™s business model โ€” advertising and subscriptions, the twin structures that have governed everything since the late nineties โ€” is about to change. He thinks some part of what replaces it will be micropayments for agentic traffic. Fractions of pennies. Fractions of fractions. At volumes that dwarf anything existing financial infrastructure can handle.

My first instinct was the old skepticism. Weโ€™ve been here before.

But I kept reading, and I think something is actually different this time. And the difference is the one thing all the earlier schemes never had.

The payer isnโ€™t human.

This sounds obvious once you say it, but it collapses most of the objections that killed every prior attempt. Cognitive load isnโ€™t a factor when thereโ€™s no cognition happening. Decision fatigue doesnโ€™t apply to a process with no feelings about fatigue. The agent making the request doesnโ€™t hesitate at a fraction of a penny, doesnโ€™t resent the transaction, doesnโ€™t abandon the session because itโ€™s annoyed at being charged.

All the early micropayments architectures were built on an implicit assumption: that humans could be trained to behave like rational microeconomic actors at browsing speed. They canโ€™t. Nobody does. But agents are rational microeconomic actors by design. Thatโ€™s not a metaphor โ€” itโ€™s literally what they are.

The schemes we watched fail in the early 2000s werenโ€™t wrong about the destination. They were wrong about the who. The internet of human readers and human attention was never a natural fit for per-transaction pricing. The internet of autonomous agents โ€” making API calls, scraping data, assembling answers from dozens of sources in a single second โ€” is a different thing entirely. And itโ€™s arriving faster than most people realize.

Prince mentioned that Cloudflare thinks non-human traffic will surpass human traffic somewhere around 2027. That number stopped me. We are, apparently, closer to a majority-machine internet than to the one we think weโ€™re living in.

The hard part isnโ€™t the concept anymore. Itโ€™s the infrastructure. Prince was candid about this: the transaction volumes the industry gets excited about โ€” a million per second โ€” arenโ€™t remotely sufficient for whatโ€™s actually coming. Cloudflare needs something an order of magnitude larger, and theyโ€™re looking for partners because nothing that fits the spec exists yet.

This is where it gets interesting for those of us who watched the earlier rounds. The original micropayments failures were partly psychological, but they were also partly infrastructural โ€” the payment rails of the early internet werenโ€™t built for high-frequency small transactions either. Whatโ€™s different now is that the need is undeniable and imminent in a way it never quite was before. The traffic is real. The scale is measurable. The pressure to figure this out is coming from something other than optimism.

I donโ€™t know what the solution looks like. Probably not one thing. Prince doesnโ€™t know either โ€” he said as much. Crypto infrastructure is an obvious candidate for parts of it, though cryptoโ€™s history of promising to solve problems and then creating different ones deserves some respect. Whatever emerges will probably be unrecognizable from here.

What I keep coming back to is the simpler observation. We were right that micropayments were the future. We just imagined the wrong future, populated by the wrong kind of payer.

The agents were always going to solve this. We just had to wait for the them to arrive.

Categories
AI Business Work

The Tipping Point Was Last November

Matthew Prince, Cloudflareโ€™s CEO, said something on todayโ€™s earnings call that I keep turning over. He didnโ€™t bury it or soften it. He named a date.

โ€œInternally, the tipping point was last November.โ€

Thatโ€™s a specific thing to say. Not โ€œweโ€™ve been on a journeyโ€ or โ€œAI has been transforming our industry.โ€ A month. A moment. The thing changed, and he knows when.

What changed, by his account, is that Cloudflareโ€™s teams began seeing productivity gains so dramatic they were hard to describe โ€” people who were two times more productive, ten times, in some cases a hundred times. โ€œIt was like going from a manual to an electric screwdriver.โ€ Usage of AI tools internally is up more than 600% in just the last three months. Every line of production code is now reviewed by an autonomous AI agent.

And then he said goodbye to 1,100 people โ€” about 20% of the company.


Today wasnโ€™t just Cloudflare. Earnings season has become something like a drumbeat. Meta is cutting 8,000 employees this month. Amazon cut 16,000 in Q1. Oracle eliminated roughly 30,000 to fund AI infrastructure. Block cut almost half its workforce. PayPal is reportedly planning to cut 20% of its staff over the next few years. Coinbase cut 14%. Snap cut 16%. As of this week, more than 92,000 tech workers have been laid off in 2026 alone.

The scale is striking. But what strikes me more is the framing โ€” the specific language being used to describe whatโ€™s happening. These arenโ€™t being announced as cost-cutting moves or post-pandemic corrections, the way they might have been in 2022. Theyโ€™re being announced as architectural decisions. Structural adaptations. Evolution.

Prince was careful to be explicit: โ€œThis isnโ€™t a cost-cutting exercise or an assessment of individualsโ€™ performance. Itโ€™s about defining how a world-class, high-growth company operates and creates value in the agentic AI era.โ€ Thatโ€™s not empty corporate language, or at least not only empty corporate language. The distinction heโ€™s drawing โ€” between trimming fat and reimagining how a company is built โ€” maps to something real about what AI agents can now actually do.

Thereโ€™s a legitimate version of this argument and a convenient one, and theyโ€™re being delivered in the same sentence by the same people, which makes them hard to separate. Some analysts suspect companies are using AI as cover for cuts they wanted to make for other reasons โ€” rightsizing from pandemic-era overhiring, funding massive infrastructure buildouts, chasing margin. Oxford Economics flagged this: maybe some firms are โ€œdressing up layoffs as a good news story.โ€ The cynicism is warranted.

But then thereโ€™s the Cloudflare number: 600% increase in AI usage in three months. Thatโ€™s not a narrative. Thatโ€™s a measurement.


Whatโ€™s different about this moment โ€” what makes Princeโ€™s โ€œtipping pointโ€ language feel accurate rather than convenient โ€” is that the people making these decisions are themselves users of the tools. Theyโ€™ve seen the productivity numbers internally before anyone else has. Theyโ€™re not theorizing about what AI might do to their workforce; theyโ€™re describing what it already did.

Thatโ€™s the thing that changed. For years, AIโ€™s labor impact was a future tense conversation. Economists studied it, think pieces warned about it, conferences debated the timeline. Then, somewhere around last November apparently, a cohort of technology companies crossed from hypothetical to empirical. The future tense became past.

Whether you read that as tragedy, as transformation, or as both depends on where youโ€™re standing. 1,100 people at Cloudflare today are standing somewhere very specific. Prince acknowledged this with what felt like genuine difficulty: โ€œA number of friends will no longer be colleagues.โ€ Whether that difficulty changes anything material for the people leaving is a fair question.

But the acceleration itself โ€” the thing he named โ€” is real. The tipping point was last November. And if it was last November for Cloudflare, it was some nearby month for Amazon, for Meta, for Block, for all of them. Whatever these companies learned that changed everything, they all seem to have learned it around the same time.

Thatโ€™s what I find myself sitting with today: not just the scale of the disruption, but the synchrony of it. The realization arrived, and then the decisions followed. Quietly at first, then all at once.