Tag: payments infrastructure

Categories
Banking Markets

The Honesty of the Long Bond

Treasury Bond

There is a particular sound a fraud model makes right before someone silences it. Not an alarm, not a siren — a score. A number ticking upward on a screen, quietly, the way a fever climbs before anyone thinks to take the temperature. At Visa, in the years when the network was still teaching itself to smell trouble before trouble arrived, the worst mistake wasn’t missing the signal. It was seeing the signal and deciding, for reasons that felt reasonable in the room, to turn the threshold down. To make the number stop being inconvenient. The fraud didn’t go away when you did that. It just went un-priced for a while, and un-priced things have a way of arriving all at once, later, with interest.

I thought about that instinct — the turned-down threshold — reading Stanley Druckenmiller’s account of what the Treasury Department did on Aug. 19. The 30-year yield had touched a nineteen-year high. Within hours, Treasury announced it would double its long-dated bond buybacks, from two billion dollars a operation to at least four, running through early November. Yields fell. By the next afternoon they’d round-tripped back above where they started. The market had said its piece and gone back to saying it.

Druckenmiller’s point is not really about buybacks. Four billion dollars against a marketable debt stock nearing thirty trillion is a rounding error, and he says so. His point is about what a price is for. The long Treasury yield is the closest thing this country has to an incorruptible witness — a number nobody in Washington controls, that aggregates what millions of lenders actually believe about a borrower’s arithmetic, and reports back without spin. Inflation running above target since 2021. Unemployment low enough to call full employment by any definition. A deficit near six percent of GDP in peacetime, at full employment, which is not a thing this country has produced before. Interest payments outrunning the defense budget. The debt crossing forty trillion the same week Treasury decided the honest price of borrowing against all of that was too loud, and needed managing.

Continue reading “The Honesty of the Long Bond”
Categories
AI Aviation

Buffer Overflow

There is a moment in a stall, before the airplane actually stalls, when the controls go soft. The yoke stops talking back. You can still pull it toward you, and the nose will still come up, but the airplane is no longer answering in the language it used thirty seconds earlier, and if you do not recognize the change in dialect you will keep asking questions in a tongue the airplane has stopped speaking. Pilots have a phrase for the general condition this belongs to, which is broader than stalls and covers weather, traffic, radio calls, checklists, an unfamiliar airport with three runways and no tower: getting behind the airplane. The airplane is still flying. It is you who have stopped keeping pace with what it is doing.

I flew a Cherokee 235 for years, a airplane with enough useful load to make it forgiving and enough control weight to make it honest, and I only got behind it twice that I can remember with any precision, both times on approach, both times because I let a secondary task — a frequency change, a passenger question, a glance at a chart — eat the attention that the airplane needed at exactly the moment it needed it most. What is strange, looking back, is that the airplane never sped up. The airplane was doing what it always does on a three-degree glide path. I was the one who fell behind a constant.

I have started to notice the same falling-behind, unrelated to constants, in conversations with a language model.

It happens on the good days, which is the part that took me a while to understand. It is not the model being slow or confused. It is the model being unusually generative — pulling a thread from something I said four exchanges ago, connecting it to a domain I had not mentioned, offering three candidate framings where I had expected one — and somewhere in the second or third of these, I notice that I have stopped actually absorbing and started merely receiving. The words are still arriving. I have quietly stopped being the kind of reader who can do anything with them.

The name I have for this, mostly because I spent some years around fraud systems and payments infrastructure and the vocabulary never entirely leaves you, is buffer overflow. In a computer, a buffer is a fixed patch of memory set aside to hold data until a program is ready to process it — a loading dock, essentially, sized for a delivery truck of a known dimension. A buffer overflow is what happens when the truck backs in and keeps unloading past the edge of the dock. The classic and dangerous version of this is not that the extra data spills onto the floor and is lost. It is that the extra data lands on the memory sitting just past the dock, and overwrites whatever was stored there — a return address, a variable, something the program needed intact to know where to go next. The failure is not loss. It is corruption. The fifth insight does not politely fall away; it lands on top of the second insight and changes what the second insight was.

This is, I think, the more accurate complaint than “overwhelm,” which is the word I would have reached for a few years ago and which suggests simple excess, more water than the glass can hold. What I am describing is not excess. It is a rate mismatch between generation and integration, and the damage happens specifically at the boundary — not in the ideas that never arrived, but in the ones that arrived and were still being turned over when the next one came in and knocked them loose.

Aviation, as it turns out, has more than one name for this family of failure, and the names are not redundant, because they describe different mechanisms. Task saturation is the CRM term — Crew Resource Management, the discipline built in the seventies and eighties largely in response to accidents where a competent, rested, well-trained crew flew a functioning airplane into terrain because attention had been consumed by something lower priority than staying alive. Task saturation is measured, in training, less by how much is happening and more by whether the pilot can still prioritize — whether they know which thing to drop. Channelized attention is the adjacent and opposite failure: not too many things competing for a narrow channel, but one thing filling it entirely, a fixation on the landing gear light while the airplane, unflown, descends into the Everglades. And John Boyd’s OODA loop, developed for fighter pilots and stolen since by nearly every field that has ever needed a name for out-thinking someone under time pressure, describes what it feels like structurally to fall behind: you are not reacting to what the situation is, you are reacting to what the situation was, one iteration back, and every loop after that the gap does not close on its own.

I suspect what I am calling buffer overflow is closest to task saturation, with the wrinkle that in a cockpit the incoming data is at least all real-time and load-bearing — the runway is where the runway is — whereas a model in full flow is producing a mix of load-bearing insight and elaboration that only sounds load-bearing, and no light comes on to tell you which is which. Sweller’s cognitive load theory gives this a cleaner anatomy than aviation does: intrinsic load, which is the actual difficulty of the idea; extraneous load, which is how badly or well the idea is presented; and germane load, which is the effort of building the new idea into the structure of what you already know. My buffer does not overflow on intrinsic load — the ideas themselves are usually not hard. It overflows on germane load. The model can generate connections faster than I can lay the track that would let each new connection actually attach to something.

None of the aviation solutions to task saturation involve asking the airplane to slow down, and this is the part I keep returning to, because slowing down is the intervention that occurs to me first and is also, I think, the least aviation-like response available. A pilot who is task-saturated on approach does not usually ask the tower to widen the pattern. He drops something. He un-couples the autopilot from one axis and flies it by hand so the workload becomes tactile instead of cognitive, or he tells the passenger the question will have to wait, or he reads back only the clearance and lets the weather advisory go unacknowledged for ninety seconds because the weather advisory is not what is going to kill him in the next ninety seconds. The skill is not deceleration. It is triage performed at full speed, which looks, from outside the cockpit, indistinguishable from calm.

I do not yet know what the triage move is for a conversation with a model that is generating faster than I can integrate. I have a guess, which is that it looks less like asking the model to slow down and more like periodically stepping outside the exchange entirely — not to catch up on what was said, but to write down, in my own words, the one thing from the last five minutes I actually want to keep, before asking it to continue. That would make the move not deceleration but discard: choosing, the way the saturated pilot chooses, which incoming data does not get processed at all, on the theory that a buffer with something deliberately thrown out of it still holds its shape, and a buffer that tries to keep everything is the one that overflows.

Or maybe the real answer is the one the checkride examiner gave me in Springfield, on a September morning in 1978, when I came in too fast and too high and asked, afterward, what I should have done differently. He said the airplane had told me everything I needed to know about forty seconds before I noticed, and that the only skill that mattered was noticing forty seconds earlier next time. Not slower. Earlier.

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.