Category: Programming

Categories
Business History IBM Infrastructure Nvidia Programming Semiconductors

The Half-Life of Moats

Prompted by an article on X by @magicsilicon on the CUDA moat. Research and drafting assistance from my AI intern assistant Clark.

The NVIDIA H100 looks, in retrospect, like an inevitability. It wasn’t.

What Jensen Huang built is more accurately understood as a sixteen-year accumulation of optionality — a platform investment made in 2006 for a market that wouldn’t fully materialize until 2022. NVIDIA intros the G80 architecture in November 2006, laying the groundwork for CUDA’s release a few months later. The stated ambition was to let scientists write C++ that ran on GPU cores without needing to understand 3D graphics pipelines. The unstated bet was that parallel computation would eventually matter for something bigger than rendering shadows in video games.

For sixteen years, it mostly didn’t. Not at scale. Not commercially. CUDA lived in research labs and HPC clusters. It attracted a small, devoted, and economically marginal user base — the kind that papers cite but investors ignore. NVIDIA kept investing in it anyway: cuDNN for deep learning operations, cuBLAS for linear algebra, a layered ecosystem of libraries that made CUDA not just accessible but nearly irreplaceable for anyone doing serious numerical computation. When TensorFlow and PyTorch emerged as the standard frameworks for neural network research, they didn’t adopt CUDA because it was the only option. They adopted it because CUDA was where the optimized kernels already lived.

AlexNet won the ImageNet competition in 2012 and did it on two NVIDIA GPUs. The deep learning community noticed immediately. The financial community largely did not.

Then ChatGPT launched in November 2022, and suddenly everyone needed H100s they couldn’t get.

The parallel to Intel is instructive and also undersells how strange this kind of story looks while you’re living through it. Intel was founded in 1968 as a memory company. DRAM. The founders — Noyce, Moore, Grove — were materials scientists and engineers who believed the future was in silicon memory chips. They were right, briefly: in the early 1970s Intel dominated the DRAM market. By 1984, that share had collapsed to 1.3%, ceded almost entirely to Japanese manufacturers who had commoditized the product.

What saved Intel wasn’t a pivot so much as a realization that a stopgap had become a foundation. The 8086, conceived in 1976 as an internal hedge and launched in 1978 was never supposed to matter. It was a 16-bit processor designed to hold off Zilog while Intel finished its ambitious 32-bit iAPX 432 architecture. The 8086 was assigned to a single engineer. “If management had any inkling that this architecture would live on through many generations,” its designer Stephen Morse later recalled, “they never would have trusted this task to a single person.”

IBM chose the 8088 — a cost-reduced variant — for the original IBM PC in 1981. That decision wasn’t destiny, it was simply a procurement. And yet from that accident of selection, Intel’s x86 line became the backbone of personal computing for four decades. The Pentium in 1993 was Intel’s Wintel moment — the flag bearer the @magicsilicon tweet gestures at — but the flag had been quietly sewn since 1978.

What these histories share is not just a pattern of “slow build, explosive payoff.” The structural similarity is subtler: in both cases, the moat was a software abstraction layer built on top of hardware. Intel’s real lock-in wasn’t transistor count or clock speed. It was backward compatibility — the commitment, formalized with the 80386 in 1985, that every future Intel chip would run software written for older ones. That promise created a flywheel that trapped developers and buyers in a virtuous (for Intel) dependency loop for decades.

CUDA is the same architecture at a different layer. The lock-in isn’t the H100’s 80 gigabytes of HBM3. It’s that switching to an AMD MI300X or Google TPU means potentially rewriting training pipelines that have been optimized against CUDA kernels for years. AMD’s ROCm platform exists. It is, by most accounts, maturing. Engineers who have tried the migration report that it costs months and hundreds of thousands of dollars. The moat isn’t a wall. It’s accumulated friction — the switching cost of a decade of engineering decisions baked into codebases that no one wants to touch.

But to find the actual origin of this pattern, you have to go back further than Intel. To 1964, and to a decision IBM made that Fred Brooks — its project manager — called a bet-the-business move.

The IBM System/360 was announced on April 7, 1964, after five years of turbulent internal development. What it introduced wasn’t just a new computer. It was a new concept: the separation of architecture from implementation. Before the 360, IBM ran five incompatible product lines simultaneously. A customer who outgrew their machine had to scrap all existing software and start over. The 360 replaced all five lines with a single unified architecture — six models covering a fiftyfold performance range, all running the same operating system, all sharing the same instruction set. The name itself encoded the ambition: 360 degrees, all directions, all users.

Gene Amdahl, the 360’s chief architect, had a precise formulation for what this meant: the architecture was “an interface for which software is written, independent of any implementation.” The Principles of Operation manual described what the machine did; separate Functional Characteristics documents described how each model did it. This distinction — separating the contract from the execution — was genuinely new. It’s the conceptual root of everything that came after.

The 360 generated over $100 billion in revenue for IBM and established the first platform business model in computing. Jim Collins would later rank it alongside the Model T and the Boeing 707 as one of the three greatest business achievements of the twentieth century. But its deepest legacy was architectural: the insight that if you make your abstraction layer the standard, the hardware underneath becomes fungible. Customers didn’t buy specific IBM machines. They bought into OS/360. The machines were an implementation detail.

Intel understood this by the 1980s, even if implicitly. The 80386’s backward compatibility commitment in 1985 was IBM’s 360 insight applied to microprocessors — the architecture is the product, the silicon is the vehicle. CUDA is the same insight applied to GPU compute. What NVIDIA sold researchers in 2006 wasn’t the G80 card. It was the abstraction: write parallel code in C++, run it on any NVIDIA hardware, trust that the next generation will be faster and compatible.

The pattern is now sixty years old. It has reproduced in every major platform transition. And it keeps working for the same reason it worked in 1964: when you own the layer that developers write to, your customers’ switching costs compound every year they stay.

There’s something worth sitting with here. Neither Jensen Huang in 2006 nor Gordon Moore in 1968 could have specified exactly what the payoff would look like. What they shared was a willingness to build infrastructure for a demand they could sense but not yet see — and the discipline to keep investing in it through the long years when it looked like a research project rather than a business.

The question that doesn’t resolve cleanly is whether that kind of patience is a strategy or a personality. And whether, in an industry that now moves faster than the cycles it’s lived through, sixteen-year moats are still the kind that get built.

Which raises the uncomfortable corollary: the same AI tools that CUDA enabled may be what ultimately erodes it.

The attack on CUDA’s moat is now structurally different from anything AMD or Intel could mount before. OpenAI’s Triton compiler lets developers write GPU kernels in Python without touching CUDA at all, and generates optimized machine code that often matches hand-tuned CUDA performance. MLIR — Multi-Level Intermediate Representation, originally from Google — provides a compiler infrastructure that can target any hardware backend from a single codebase. AMD’s ROCm has historically been dismissed as immature; ROCm 7, released this year, delivers meaningfully better inference performance than its predecessors. And perhaps most directly: Claude Code reportedly ported a CUDA codebase to AMD’s ROCm in thirty minutes — work that previously took months of engineering time.

The irony is almost too neat. CUDA’s moat was built on accumulated switching costs: the friction of rewriting code, the library dependencies, the tribal knowledge encoded in a decade of kernel optimizations. AI coding tools are specifically good at exactly that kind of mechanical, high-context translation. The weapon is attacking the wall it was built behind.

That said, it’s worth being careful about the speed of this. Abstraction layers that “should” erode moats often take far longer than expected, because the moat isn’t just the code — it’s the ecosystem of tooling, documentation, community knowledge, and hardware-software co-optimization that took eighteen years to compound. Triton and MLIR are real. They’re also early. The question isn’t whether the moat is vulnerable; it’s whether it erodes before NVIDIA’s next generation of chips makes it irrelevant to argue about.

As for what comes next — which company is building the IBM 360 of this decade — the honest answer is that it’s too early to call with confidence. But there’s a candidate worth watching.

Anthropic’s Model Context Protocol, launched in late 2024, has the structural fingerprint of a platform play. MCP is a standard for how AI agents connect to external tools and data sources — a common interface layer, hardware-agnostic (or rather, model-agnostic), that any system can implement. By late 2025 it had been donated to the Linux Foundation, adopted by OpenAI and Google, and was tracking 97 million monthly SDK downloads. There are now over 10,000 MCP servers. It is becoming the way agents talk to the world.

The parallel to OS/360 is imprecise but instructive. What IBM built in 1964 was a standard interface between software and hardware that decoupled what you wrote from what you ran it on. MCP is attempting something similar one abstraction layer higher: decoupling what an agent does from the specific models, tools, and data sources it does it with. If it becomes the standard — the layer that developers write to — then whoever owns or most deeply shapes that standard controls the integration tax of an industry whose applications we can’t fully specify yet.

The counterargument is that open standards, once donated to foundations and broadly adopted, don’t generate the same lock-in as proprietary platforms. OS/360 was IBM’s. CUDA is NVIDIA’s. MCP is now the Linux Foundation’s, with OpenAI and Google as co-stewards. The historical pattern suggests the moat accrues to whoever owns the layer, not whoever invented it.

Which may mean the next great platform play is still being assembled in a room we haven’t seen yet — the way IBM’s System/360 was being architected in a Connecticut motor lodge in 1961, three years before anyone else knew what was coming.

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
AI AI: Large Language Models Programming

The Era of the Synthesizer: How AI Is Liberating the Coder

For decades, being a programmer meant being a translator.

You stood in the gap between what someone wanted and what a machine could understand. You learned the syntax. You memorized the libraries. You once spent three hours hunting a missing semicolon that turned out to be hiding in line 847 of a file you were sure you’d already checked.

The New York Times Magazine recently ran a piece by Clive Thompson on what AI coding assistants — models like Claude and ChatGPT — are doing to that job. The anxiety in the piece is real. When you sit down with a modern AI assistant and watch it generate in seconds what used to take you days, it’s genuinely disorienting. Hard-won expertise suddenly feels less like a moat and more like a speed bump.

That reaction is honest. I’d be suspicious of anyone who didn’t feel it.

But here’s what I keep coming back to: what we’re losing is the translation layer. The boilerplate. The muscle memory of syntax. What we’re not losing is the part that was always the actual job — figuring out what to build and why it matters.

The soul of software was never in the code itself. The code was always just a means to an end.

Think about what happens when the mechanical friction of a craft disappears. Photographers stopped having to mix their own chemicals in the dark and started spending that time making better images. Musicians stopped having to hand-copy scores and started composing more. The freed-up capacity doesn’t evaporate — it gets redirected upward, toward the work that actually required a human all along.

The same shift is underway in software. When the AI handles the loops and the boilerplate and the database queries, what’s left is everything that required judgment in the first place. The architecture. The user experience. The question of whether this thing should exist at all, and in what form, and for whom.

We’re moving from the how to the why. That’s not a demotion.

It does ask something of us, though. The old identity — programmer as master of arcane syntax — has to be relinquished. And letting go of a hard-earned identity is genuinely hard, even when what’s replacing it is better. That quiet grief the Times piece captures is worth sitting with, not dismissing.

But after you sit with it for a minute: we are entering the era of the synthesizer.

The synthesizer’s job is to hold the vision, curate the logic, and direct the output toward something that actually resonates with another human being. Empathy. Intuition. The ability to sense when something is almost right and know which direction to push it. These aren’t soft skills. They’re the whole game now.

The clatter of keyboards is fading. But the music we’re about to make — with AI doing the heavy lifting on the mechanics — has a lot more room to breathe.

Categories
AI Creativity Programming Writing

We Are All Painters Now: The Era of Vibe Coding

For decades, the act of creating software was exactly that: writing. It was a distinctly left-brained, agonizingly precise discipline.

Programmers were typists of logic, translating human intent into a rigid, unforgiving syntax that a machine could understand. A single misplaced semicolon, an unclosed bracket, or a misspelled variable could bring an entire system crashing down.

Building software meant placing one brick after another, working meticulously from the ground up.

In this traditional paradigm, coders were the ultimate embodiment of Annie Dillard’s writer. As she noted in The Writing Life, “Writers… work from left to right. The discardable chapters are on the left.”

When you wrote code, your mistakes, your refactoring, and your discarded logic were all part of a linear, grueling journey. If a feature didn’t work, you had to physically wade back into the text, debugging, reading line by line, and rewriting the narrative of the application. The discarded chapters were the endless hours spent wrestling with a single broken dependency.

But recently, a profound paradigm shift has quietly taken over our screens. We are transitioning out of the era of writing software and into the era of “vibe coding.”

Vibe coding fundamentally changes our relationship with the machine. With the rise of advanced AI coding assistants, we are no longer placing the bricks ourselves; we have become the architects and the creative directors. You don’t write the loop or manually construct the database query. Instead, you describe the feeling, the function, and the outcome. You tell the AI, “Make this dashboard feel more modern,” or “The logic here is too clunky, make it flow faster and handle edge cases gracefully.” You are coding by intuition. You are steering by the “vibe” of the output rather than the mechanics of the input.

Suddenly, Dillard’s other metaphor takes center stage. In the age of vibe coding, we have become painters.

“A painting covers its tracks. Painters work from the ground up. The latest version of a painting overlays earlier versions, and obliterates them.”

When we vibe code, we ask an AI for a functional prototype, and it gives us a canvas. We look at it, test it, and sense whether it aligns with our vision. If it doesn’t quite hit the mark, we don’t necessarily rewrite the code from scratch. We simply prompt the AI to try again, adding a new layer of instruction. The AI paints a new layer of code directly over the old one. The awkward, underlying iterations—the messy attempts at styling, the inefficient logic of the first draft—are obliterated by the newest prompt.

The machine covers our tracks for us. We don’t need to know exactly how the underlying pixels were rearranged or how the syntax was refactored. The final application emerges as a stunning obliteration of its own clumsy past.

As someone who has spent time wrestling with the rigid demands of syntax, there is a strange, quiet grief in letting go of that left-to-right process. There is a deeply earned, tactile satisfaction in building something manually, understanding the precise weight and placement of every line of code. Relinquishing that control can feel like a loss of craftsmanship.

Yet, there is also a breathtaking liberation in this new medium. We are moving from a world of manual construction to a world of artistic curation. The barrier to entry is no longer fluency in a specific, arcane language; it is simply the clarity of your imagination and your ability to articulate your intent.

The next time you sit down to build something digital, notice the shift in your own posture. You no longer have to carry the heavy burden of the writer, agonizing over every word and leaving your discardable chapters on the left. You can step back, look at the whole canvas, and trust your intuition. Let the AI cover the tracks. Embrace the obliteration of the early drafts.

We are all painters now, coaxing the future into existence one brushstroke at a time.

Categories
AI Programming Work

The Currency of Restlessness

There is a specific kind of vertigo that comes from watching a machine effortlessly perform your life’s work. For Aditya Agarwal, an early Facebook engineer and former CTO of Dropbox, that vertigo hit after a weekend of coding with an AI assistant. His realization was absolute: we will never write code by hand again.

When the specialized skills we have spent decades mastering become free and abundant, the foundation of our professional identity inevitably trembles. Agarwal captures the duality of this moment perfectly, describing it as a mixture of “wonder with a profound sadness.”

“There’s something deeply disorienting about watching the pillars of your professional identity, what you built and how you built it, get reproduced in a weekend by a tool that doesn’t need to eat or sleep.”

The conversation around AI tends to flatten this emotional reality into two distinct camps: the doomers who foresee total replacement, and the boosters who promise a frictionless utopia.

But lived experience is messier. We are capable of holding grief and wonder in the same hand.

We can mourn the craftsmen we were, even as we sprint toward the architects we are about to become.

Because here is the secret about the disorientation of progress: it passes.

Once the initial shock fades, what replaces it is a wild, unconstrained energy.

When the mechanical friction of creation vanishes—when a week’s worth of coding can be accomplished in an afternoon—the scope of our ambition expands. We are no longer limited by the keystrokes we can manage in a day, but by the edges of our imagination. We aren’t watching ourselves become obsolete; we are watching our lifelong constraints dissolve.

This shift is rewriting the social contract of knowledge work, starting with how we evaluate human potential. For decades, the corporate world has relied on a calcified heuristic for hiring: brand-name universities, FAANG experience, and years of tenure. We worshipped the resume.

Now, that playbook is breaking down. In evaluating engineers and founders navigating this transition, Agarwal notes that traditional pedigrees predict almost nothing about a person’s ability to thrive. The new dividing line isn’t generational, and it certainly isn’t educational. It is entirely dispositional.

“The trait that matters most isn’t intelligence, or credentials or years of experience. It’s someone’s relationship with change—not whether they’ve seen change before, but whether they run toward it.”

The new currency of the working world is restlessness.

Restlessness is the refusal to settle into the comfort of the way things used to be. It is the constitution of a builder who cannot stop tinkering, who treats every new AI tool as a puzzle to be solved before the day is out. In an economy where the “how” of knowledge work is increasingly automated, the premium shifts entirely to adaptability, curiosity, and vision.

This democratization of capability forces a deeply uncomfortable, deeply human reckoning. We have to let go of the identities we forged under old paradigms to become whatever comes next.

The technology didn’t create this human challenge—it merely made it impossible to ignore.

Categories
Computers FORTH IBM Programming

The Architecture of the Stack

Back in the early 1980’s when I worked for IBM, I was able to acquire my own IBM PC and experience my own form digital frontierism. Today I really wish I had a logbook at hand with a record of everything I did as my ability to recall those details has faded with age. A couple of those memories that still do remain with me involve two obscure languages: APL and FORTH. And then there was Borland Turbo Pascal.

In those early days of the 1980’s, memory wasn’t an infinite field; it was a precious, finite resource. While most of us were content living with the structured guardrails of BASIC, there was a subset of us drawn to the elegant, stripped-back world of FORTH.

Learning FORTH felt less like coding and more like learning a new way to breathe. It was lean. It was efficient. It stripped away the overhead of high-level syntax until it was just you, the dictionary, and the stack. There was an honesty to it—no hidden abstractions, just a direct conversation with the hardware.

Then, of course, there was the hurdle of Reverse Polish Notation (RPN). Grokking the stack meant rewiring your brain. You couldn’t just state an operation; you had to prepare the world for it first. You pushed your data onto the stack, one piece at a time, and only then did you call the action. It was a rhythmic, almost percussive way of thinking: Input, input, act.

“In FORTH, you don’t just write programs; you build a language to solve the problem.”

This “bottom-up” philosophy changed the relationship between the creator and the machine. You weren’t just a user; you were an architect of your own vocabulary. To define a new “word” in FORTH was to permanently expand the capabilities of your environment. It was a recursive journey where every small success became a building block for the next complexity.

Looking back, those days with the IBM PC and the stack weren’t just about efficiency. They were about the discipline of clarity. When resources are limited, your thinking must be precise. The difficulty of RPN wasn’t a bug—it was a feature that forced you to understand the flow of data at its most fundamental level.

Categories
AI Programming Prompt Engineering Software Work

The Great Inversion

For twenty years, the “Developer Experience” was a war against distraction. We treated the engineer’s focus like a fragile glass sculpture. The goal was simple: maximize the number of minutes a human spent with their fingers on a keyboard.

But as Michael Bloch (@michaelxbloch) recently pointed out, that playbook is officially obsolete.

Bloch shared a story of a startup that reached a breaking point. With the introduction of Claude Code, their old way of working broke. They realized that when the machine can write code faster than a human can think it, the bottleneck is no longer “typing speed.” The bottleneck is clarity of intent.

They called a war room and emerged with a radical new rule: No coding before 10 AM.

From Peer Programming to Peer Prompting

In the old world, this would be heresy. In the new world, it is the only way to survive. The morning is for what Bloch describes as the “Peer Prompt.” Engineers sit together, not to debug, but to define the objective function.

“Agents, not engineers, now do the work. Engineers make sure the agents can do the work well.” — Michael Bloch

Agent-First Engineering Playbook

What Bloch witnessed is the clearest version of the future of engineering. Here is the core of that “Agent-First” philosophy:

  • Agents Are the Primary User: Every system and naming convention is designed for an AI agent as the primary consumer.
  • Code is Context: We optimize for agent comprehensibility. Code itself is the documentation.
  • Data is the Interface: Clean data artifacts allow agents to compose systems without being told how.
  • Maximize Utilization: The most expensive thing in the system is an agent sitting idle while it waits for a human.

Spec the Outcome, Not the Process

When you shift to an agent-led workflow, you stop writing implementation plans and start writing objective functions.

“Review the output, not the code. Don’t read every line an agent writes. Test code against the objective. If it passes, ship it.” — Michael Bloch

The Six-Month Horizon

Six months from now, there will be two kinds of engineering teams: ones that rebuilt how they work from first principles, and ones still trying to make agents fit into their old playbook.

If you haven’t had your version of the Michael Bloch “war room” yet, have the meeting. Throw out the playbook. Write the new one.