From Punch Cards to Claude Code

The Cost of Better · Part One

I spent a career paying for progress. Here is what I learned about the half of the bill nobody accounts for.

In 1978, in a high school in New Philadelphia, Ohio, a patient man named Mr. Bud Winn taught me to make a machine do what I wanted. The procedure went like this. You shaded the punch cards by hand. You fed them to be punched and sorted. You ran them through a reader, cut a ticker tape, recorded the tape onto a cassette, and loaded the cassette into a machine called a Wang. Then, finally, you ran the program.

And when it failed, there was no cursor to click back to. You went back to the cards, found the mistake, reshaded, repunched, resorted, recut, re-recorded, reloaded. An afternoon could vanish into a single missing instruction. I wrote about that ritual years ago and called those the Dark Ages — no internet, no phones, just landlines and patience. I was being nostalgic. I had not yet understood what the ritual was actually teaching me.

What it was teaching me was the price of being wrong. Every mistake had a cost I could hold in my hands — a stack of cards, an afternoon, a turn in the queue I would now have to wait for all over again. The cost was not hidden. It was the whole experience.

Forty-eight years later, I describe my work to a piece of software in plain English and watch it write, test, and commit the code while I supervise.— Sumir Nagar

Anthropic’s own engineers say the majority of their code is now written this way. The human has moved up a layer, into architecture and orchestration. We have travelled from shading cards by hand to instructing a machine that instructs itself. By every measure the industry uses to congratulate itself, this is progress of an almost incomprehensible kind.

And yet. Underneath the bank where your salary lands, underneath the ATM that dispenses your cash, underneath the tax system that takes its share, there is a very good chance the money is still being moved by COBOL — a language older than I am, designed the year before I could walk. Roughly $3 trillion in commerce still flows through it every day. Around 95% of ATM transactions touch it. More than 40% of US banking systems run on it. The Treasury runs on it. The IRS runs on it. Social Security runs on it. If COBOL stopped tomorrow, large parts of the American economy would go dark within hours.

This is the whole essay in a single fact. We have spent half a century in a frenzy of reinvention — new languages, new frameworks, new chip-sets, new hardware. New paradigms arriving and dying faster than anyone can master them — and the part of the system that actually moves the money was never replaced. We did not modernize the foundation. We built new floors on top of it, and billed each floor as a revolution.

We did not modernize the foundation. We built new floors on top of it, and billed each floor as a revolution.— Sumir Nagar

The Foundation That Fought Back

I should tell you a story here, because I watched this happen and it has stayed with me for years. It is my own recollection of events inside an institution I worked for. You will not find it in any public filing, because no one issues a press release to announce that they spent a fortune and gave up. Take it, then, as testimony rather than citation — but it is the truest illustration I have of what this essay is about.

The institution ran its core — the system that held the accounts, moved the money, was in every meaningful sense the institution — on an in-house platform built and refined over many years. It was written on COBOL. It worked. It had always worked.

The trouble was not the software. The trouble was that it ran on hardware, and the manufacturer had announced it would wind down support for the platform the system depended on.

Nobody at the institution had woken up wanting to replace a system that worked perfectly well. The decision was made for them, in a product-lifecycle memo written somewhere else entirely, by people who would never see the consequences. The clock had been started by someone with no stake in the building.

So the institution did the responsible thing. It went to market. The leading names you would expect — the largest consulting and technology firms in the world, the ones with the best credentials — were brought in to scope the transition, to evergreen the critical system before the ground gave way beneath it. And after a great deal of money, and a great deal of time, and the involvement of some of the most capable engineers available for hire, the project was quietly shelved.

The system was too deeply woven into the institution, too full of three decades of undocumented exceptions and hard-won logic, to be lifted out and set down again on modern foundations without unacceptable risk. They had spent millions to arrive at the conclusion that they could not safely do the thing they had been forced to attempt.

They had spent millions to arrive at the conclusion that they could not safely do the thing they had been forced to attempt.— Sumir Nagar

Hold the two stories side by side, because together they are the argument. COBOL is the foundation that was never replaced and quietly kept running. The core I watched was the foundation that someone was compelled to replace, by a decision made elsewhere, and that defeated every attempt and every budget thrown at it. One survived by being left alone, the other consumed a fortune and surrendered. Neither outcome was progress.

Both were churn. The first avoided, the second forced and failed — and in both cases the cost was real, large, and entirely unrecovered. This is the texture of advancement that the roadmaps never show you. Not a clean march forward, but an expensive struggle to stay in roughly the same place, set in motion by people who had already moved on.

The hardware was only the most visible layer of this. The same churn ran through everything stacked on top of it — the languages, the frameworks, the databases — each arriving announced as the destination the whole industry was finally heading toward, each in time revealed as a way-station we had mistaken for the terminus. I learned to code in an age of punch cards and BASIC; I have since watched a long parade of supposedly permanent futures arrive and quietly depart, from the client-server tools that ran the world’s banks to the database movements that declared the old order dead and were themselves overtaken within a decade. I have written about that, Graveyard of Sure Things separately, because it deserves its own telling. What matters here is only this: the pattern is always the same, and the bill is always largest for whoever believed the prophecy most sincerely.

The Diligence I Bragged About Was Never a Virtue

When I wrote about the punch-card years, I told a flattering story. I said that because rework was expensive, my generation was careful — we got things right the first time — while the delete-and-recompile generation had grown careless. It is the kind of thing men of my vintage say at dinners, and it always earns a knowing nod.

I was wrong, and it took a $6 billion annual technology budget to show me how wrong.

The diligence was not character. It was a constraint. The punch card made the cost of a mistake visible and immediate, so I behaved as anyone behaves when the bill arrives at once, carefully. Remove the constraint, make rework instant and apparently free — and the same human being behaves differently. Not because he has become lazy or worse, but because the cost has moved somewhere he can no longer see it.

The younger coder is not less diligent than I was. He is working in a system that has hidden the price tag. That is not a moral failing on his part. It is a design choice on ours.

This is the thing I missed for most of my career, and it is the spine of everything that follows in this series.

The cost of advancement never left. We simply got very good at moving it to where it cannot be seen, and then mistook its disappearance for progress.— Sumir Nagar

What the Churn Actually Costs

I was a major player in the team that was responsible for the optimization of a $6 billion annual IT budget. In other lives, I have approved migrations that were sold as leaps and turned out, in hindsight, to be lateral moves in better packaging.

So when I say that a great deal of what the industry calls progress is motion — expensive, exhausting, perpetual motion — I am not theorizing, I was in it.— Sumir Nagar

The honest difficulty is that nobody books “churn” as a line item. There is no figure anywhere for the global cost of reinventing things that already worked, because the cost hides inside migration budgets, retraining, rewrites, and quietly abandoned platforms.

So let me do something more useful than quote a number I cannot defend. Let me build an estimate in the open, show you every input, and mark clearly where I am measuring and where I am inferring. You can disagree with the arithmetic — I would rather you argue with a visible estimate than swallow an invisible one.

Start with what we know. Worldwide IT spending is forecast at $6.31 trillion in 2026. That is the pool. Now, the portions of it that represent cost relocation rather than genuine advance:

An open estimate of the annual “churn tax” — global, 2026

  • Total worldwide IT spend (measured — Gartner): $6.31 trillion
  • Technical-debt drag: 10–20% of IT budgets diverted to servicing past decisions (McKinsey-cited range, applied to spend): ~$630B – $1.26T
  • Migration & modernization waste: most such projects run materially over budget; Gartner has cited ~83% of data-migration projects failing or overrunning (inferred share of modernization spend): hundreds of billions
  • Retraining and skill-obsolescence: the recurring cost of teaching the workforce each new stack (not separately measured — acknowledged, not counted): unquantified

Defensible order of magnitude: $1 trillion+ / year

I want to be precise about what that figure is and is not. It is not a measured total; no such total exists. It is a Fermi estimate — a deliberately rough calculation built from verified components — and its honest claim is only this.

The annual cost of servicing and replacing what we already built plausibly runs past a trillion dollars a year, worldwide, and no one adds it up because no one is responsible for the sum.

The technical-debt figure rests on a percentage range, not a precise measure. The migration figure is an inference from documented failure rates, not a booked number. The retraining cost I have left uncounted entirely, because I would rather show you a gap than fill it with a guess. Even with that gap, the order of magnitude is staggering. That is the point. The bill is enormous, and it is invisible precisely because it is everywhere.

Here is the part that should unsettle anyone who has ever sat in the meeting.

Much of that trillion did not buy new capability. It bought the same capability, re-expressed in a newer idiom, because the old idiom had gone out of fashion or out of support or out of people who understood it.— Sumir Nagar

We rewrote the working thing so we could keep employing the people who rewrite working things. The treadmill calls itself a roadmap.

The Newest Miracle Inherits the Oldest Problem

Which brings me back to the machine that now writes my code, and to the reason I am not simply cheering.

The dream is that AI finally lets us replace the COBOL, or some legacy system — that we can point it at 220 billion lines of code no living person fully understands and have it produce a clean, modern equivalent. But consider what that actually requires. An AI-generated rewrite of a complex legacy system is unverifiable without precisely the understanding of the business logic that made the old system opaque in the first place. If you do not know what the original did in its thousand strange corner cases — the regulatory exception from 1991, the rounding rule that exists because of a lawsuit nobody remembers — you cannot confirm the new version handles them. You have not removed the black box. You have traded it for a black box that now speaks English.

This is the punch card again, wearing a far more expensive suit. In 1978 the cost of my mistake sat visibly in my hands. In 2026 the cost of a mistake sits inside a confident paragraph of generated code, a token bill, and a system that nobody fully read. The cost did not shrink. It went quiet. And an industry that cannot see its costs will pay them forever, and call each payment innovation.

The cost did not shrink. It went quiet. And an industry that cannot see its costs will pay them forever, and call each payment innovation.— Sumir Nagar

I am not against the new tools. I use them; they are genuinely remarkable, and some of the advances across my lifetime were real, load-bearing, civilisational. The leap from the Wang to the laptop was not motion — it was progress. But I have learned to distrust my own applause. The question I have started asking, in every room where someone proposes to replace a working thing, is the one the room least wants to hear.

Is this advancement, or is this relocation? Are we making something better, or are we moving the cost to a place on the balance sheet, or in someone’s future — where we will not have to look at it?— Sumir Nagar

I began my life in technology hand-feeding instructions to a machine, one card at a time. I will likely end it watching a machine feed instructions to itself. Somewhere in between, we convinced ourselves that the bill had disappeared. It hadn’t. It never does. It only moves — and over the next two essays I want to follow it to the two places we have hidden it best. First, out of the future and into the physical world, where the weightless cloud turns out to weigh a great deal. And finally, out of sight altogether — into the one question an industry built on “can we” has quietly stopped funding: should we?


The Series

Part 1. From Punch Cards to Claude Code (this essay)

Part 2. There Is No Cloud

Part 3. The Question Nobody Funds

Sources

  1. Worldwide IT spending forecast of $6.31 trillion for 2026 — Gartner, April 2026. gartner.com
  2. COBOL processing ~$3 trillion in daily commerce; ~95% of ATM transactions; 40%+ of US banking systems; Treasury, IRS, Social Security dependence — reporting drawing on Reuters / Communications of the ACM figures. maketecheasier.com; thenewstack.io
  3. 220 billion lines of COBOL in active production use — Reuters, via The New Stack. thenewstack.io
  4. Technical debt consuming 10–20% of IT budgets — McKinsey research, as cited across industry reporting. treatysoftware.com
  5. US technical-debt principal estimated at ~$1.52 trillion; cost of poor software quality ~$2.41 trillion — Consortium for Information & Software Quality (CISQ), 2022 Report. it-cisq.org
  6. ~83% of data-migration projects fail or materially exceed budget; verification problem in AI-assisted legacy rewrites — Gartner figure, via Indium. indium.tech
  7. Majority of Anthropic’s code now written by Claude Code; engineers shifting to architecture and orchestration — Anthropic. anthropic.com

A note on the core-banking account in this essay: it is the author’s own recollection of events within an institution he worked for, and is offered as first-hand testimony rather than as a publicly documented case. Specific organizations and vendors are deliberately left unnamed; the AS/400 hardware platform is named as recalled.


Comments

3 responses to “From Punch Cards to Claude Code”

  1. […] Part 1. From Punch Cards to Claude Code […]

  2. […] — about the way each advance arrives with a price tag we have become expert at relocating. The first essay followed the cost into the future, into the debt we quietly book against tomorrow. This one follows […]

  3. […] Part 1. From Punch Cards to Claude Code […]

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Discover more from Sumir Nagar

Subscribe now to keep reading and get access to the full archive.

Continue reading