From von Neumann to AI

Introduction

"AI is taking jobs." That's a refrain we hear constantly these days. Office workers, writers, designers, translators, and yes, engineers. AI is moving fast enough that a lot of people are genuinely wondering whether their own work is about to disappear.

So I started thinking about engineers, the field closest to me. The capabilities of code-writing AI are genuinely striking these days.

When I think about this, I find myself returning to one person: John von Neumann. If you've taken a computer science class, you've seen his name in the first chapter of the textbook.

Most people, though, can't really say what he did beyond something vague like "father of the computer."

Here's something worth knowing: the system von Neumann sketched out 80 years ago is still the foundation under our phones, our laptops, every data center on Earth, and yes, the servers running ChatGPT and Claude. No matter how far AI advances, when you trace back the architecture, you arrive at a single paper from 1945.

In this piece, I'll walk through what von Neumann actually accomplished, and then ask what the long arc of computing history really tells us about whether AI will replace engineers. I'm writing about engineering specifically, but the structure that emerges here likely applies to plenty of other professions too.

Who Was von Neumann?

John von Neumann (1903–1957) was a Hungarian-born mathematician. He died at 54, but in that short life he left footprints across an extraordinary number of fields.

Here's a summary of his main contributions, organized by field:

A Design That Has Survived 80 Years

In 1945, von Neumann wrote a document with the unromantic title “First Draft of a Report on the EDVAC.” It described what we now call the von Neumann architecture.

The core idea is almost embarrassingly simple:

1. Store programs (instructions) and data together in memory
2. Have the CPU fetch and execute instructions one by one
3. Build the machine from five components: input, output, arithmetic, control, memory

You might think, “well, that's just how computers work.” Exactly. It's how computers work because for 80 years, no one has needed to question it.

Consider the lineage:

• 1945 vacuum-tube computers
• 1980s personal computers
• The smartphone at hand
• The GPU servers training and serving ChatGPT and Claude

All of them, the same fundamental design. As IBM Research put it recently, “the von Neumann architecture is quite flexible — that's why it was first adopted, and that's why it's still the prominent architecture today.”

A blueprint that hasn't been replaced in 80 years. That's a remarkable engineering fact on its own.

AI Runs on von Neumann Too

Here's where it gets interesting.

ChatGPT, Claude, image generators are all very recent. But when you look at the theoretical foundations powering modern AI, von Neumann's fingerprints are everywhere.

Hardware: GPUs are von Neumann's children

The GPUs that train and run AI models are, per NVIDIA's own documentation, built on top of the von Neumann architecture. GPUs originally emerged for graphics processing, and one of their defining features was being good at parallel computation. That happened to be a great match for the matrix operations that neural networks rely on, which is how GPUs became the workhorse of the AI boom.

Stream processing is layered on top, but the underlying design is still von Neumann. AI-specific chips like Google's TPU and Apple's Neural Engine follow the same basic pattern of fetching and executing instructions in sequence. AI servers, in the end, are von Neumann machines.

Math: Thinking in vectors

One way AI handles language is to represent words as vectors, which are essentially lists of numbers. In 2013, a model called Word2Vec made a famous example widely known: king − man + woman ≈ queen. By representing word meanings as vectors, you can do arithmetic on language.

This whole tradition of “represent things as vectors and use linear algebra to find relationships” traces back to Hilbert spaces, which mathematician David Hilbert formalized in the early 1900s. Von Neumann then applied Hilbert spaces to quantum mechanics in the 1930s, showing that physical phenomena could be described in the language of linear algebra.

The embedding vectors used in modern AI have a different shape from the Hilbert spaces von Neumann worked with in quantum mechanics, but the mindset is the same lineage: treat things as vectors, find relationships through linear algebra. The mathematical thinking von Neumann established for physics has carried through to the AI era.

Algorithms: Game theory, applied

AlphaGo and GAN-based image generators are direct descendants of von Neumann's minimax theorem (1928). The theorem shows that in two-player zero-sum games, an optimal “minimize your worst case” strategy always exists for both sides.

GANs work by pitting two AIs against each other: one tries to generate fake images, the other tries to spot the fakes. They train each other. The original GAN paper (Goodfellow et al., 2014) explicitly describes this as a “two-player minimax game.” Von Neumann's mathematics, used directly.

So AI didn't fall from the sky. It's built on theoretical groundwork laid in the early 20th century.

Now, the Real Question: Will AI Replace Engineers?

Let's get to it.

“AI can write code, so we don't need engineers anymore.” Sound familiar? It should, because this is at least the fifth time in computing history that someone has said exactly this.

The history of "this will end programming"

The whole arc of computing has been about making programming easier. And every time it got easier, someone declared programmers obsolete.

COBOL is a particularly good case. It was designed with English-like syntax precisely so non-programmers could use it. The opposite happened: business systems got bigger and more complex, and demand for COBOL programmers grew rather than shrank. This pattern has repeated for decades.

Why programmers didn't disappear

When tools get better, the problems we tackle get bigger:

• Machine code era: numerical computation
• High-level language era: enterprise business systems
• Framework era: web services
• Cloud era: globally-scaled platforms with hundreds of millions of users

Make tools 10x more powerful, and the problems people try to solve grow 10x larger. So programmers didn't vanish. They moved up the stack.

What Engineering Actually Is

Code matters. Anyone who has worked in a serious engineering organization knows that elegant, well-structured code is genuinely valuable. It's a craft, and it deserves the pride engineers take in it.

But the craft of writing code is one part of engineering, not the whole of it. The work that surrounds the code is where most of the actual difficulty lives:

• Turning vague intent into something concrete enough to build
• Anticipating what breaks elsewhere when you change one thing
• Reasoning under pressure when something has gone wrong in production
• Designing for changes that haven't been requested yet, but will be

Every one of these tasks lives at the boundary between the messy human world and the strict, literal world of computers.

In his last book, The Computer and the Brain (published posthumously in 1958), von Neumann examined exactly this divide. Computers are precise but fragile. Brains are sloppy but resilient. Bridging them is hard, structured work.

AI has gotten very good at the machine-side part: generating code that runs. The pattern-matching, syntax-fluency, best-practices side of the craft is exactly the territory AI is closing in on fastest. But translating real-world ambiguity into machine-side precision — that's a different kind of work, and it's still human territory.

Who Decides? Who's Accountable?

Here's another angle worth considering.

Von Neumann's work on quantum mechanics included an idea about measurement: the chain of observation can be extended indefinitely, but at some point someone has to cut the chain and call a result final. Strip away the physics, and the principle is general. You can't analyze forever; eventually a decision has to be made.

Software is the same. AI can generate endless candidate solutions. But somebody has to decide:

• “We ship this version to production.”
• “This is the final spec.”
• “This is the architecture we're going with.”

And whoever decides is accountable. They explain when things fail, defend their reasoning when questioned, and change course when needed. This isn't a technical problem. It's a question about how organizations and societies are structured.

Under current legal frameworks, AI cannot be held accountable. Legally, socially, organizationally, AI isn't recognized as a responsible party. AI regulation is being debated around the world, but for the foreseeable future, the structure stays the same: final decisions and their consequences sit with humans.

Game Theory, Reframed

Let's borrow another tool from von Neumann.

In game theory, there are players and there are game designers. Players make optimal moves within given rules. Designers decide what the rules are in the first place.

AI is becoming an extraordinary player. It already beats humans at chess, Go, and poker — basically any well-defined game with clear rules.

But the most consequential work in software lives on the designer side:

• What product should we build? (Which game are we playing?)
• What architecture should it have? (What rules should we set?)
• Where should we place our bets? (Where should resources go?)

These aren't “best moves in a given game.” They're decisions about what game to create. AI is becoming superhuman at the former. The latter is still human territory.

There's no single right answer to the rules of the game. What to build, how to design it, every choice has many possibilities. AI can lay out options, but it can't be the one that picks. Who picks? A product owner, an architect, an engineering manager, a working engineer. The role varies, but the final call comes from a human.

Each New Tool Lets More People Reach the Higher Layers

Looking at the historical pattern:

Every time abstraction advances, work that once required a small group of specialists becomes accessible to a much broader range of people. Machine code was the domain of a select few, but the arrival of high-level languages opened programming up dramatically. Infrastructure used to be the territory of dedicated experts, but with the cloud, even junior engineers can spin up environments on their own.

AI is the latest extension of this pattern. Code that only senior engineers could write, systems that only architects could design, are now within reach for junior and mid-level engineers working with AI. In other words, advancing tools haven't pushed in the direction of “only the elite survive.” They've consistently pushed in the direction of “more people get to take on higher-level work.”

That said, the work of deciding what to judge and what to build at those higher layers remains a human responsibility. If AI handles the “writing code” part, what becomes relatively more important is defining what users actually need. And that's something every engineer can develop, regardless of seniority or title. It's the heart of what engineering is.

Von Neumann Himself Showed the Way

One last fact worth dwelling on.

Von Neumann didn't actually build the EDVAC. He didn't solder vacuum tubes or run cables. That work was done by Eckert, Mauchly, and the rest of the engineering team. His role was design and mathematical formalization.

In modern terms, he was a software architect: not the person typing code, but the person figuring out how the system should be designed.

And 80 years later, the work that AI can't take over looks remarkably like what von Neumann himself did:

• Decomposing problems
• Choosing the right abstractions
• Weighing trade-offs
• Designing for change

These don't go away when abstractions get higher. They become more important, because more depends on getting them right.

But for Individual Engineers, It's a Different Story

Everything above has been about engineering as a profession. The collective career survives. But whether you, as an individual engineer, will be carried along is a separate question.

This is worth saying honestly. In past waves of abstraction, not every technician made it to the next layer.

Some people didn't ride the wave

Keypunch operators, who were specialists in punching data onto cards, were widely employed through the 1970s. When magnetic tape and terminal-based input took over, most of them lost their jobs. Many couldn't transition to other roles and left the industry. From the 1990s into the 2000s, mainframe operators and COBOL-only programmers faced a similar shift. Some couldn't retrain on Java, .NET, or web technologies, and quietly left the field.

The profession of “engineer” survived. But individual people lost their jobs, took pay cuts, or moved to entirely different industries. The ones who made it through were typically people who had kept the habit of learning, those who saw the next wave coming early, or those who had developed a way of thinking rather than just a specific skill.

In other words, the survival of the group and the survival of the individual are not the same problem.

If we accept this honestly, the question becomes: what should individual engineers actually do? Two things stand out to me.

From T-shaped to π-shaped (pi-shaped)

Engineering today spans an enormous range of contexts: hyperscalers, consumer apps, B2B SaaS, enterprise IT, startups, open source, embedded systems, and everything in between. The shape of the work varies enormously, but one thing is becoming consistent across all of them: AI is increasingly capable at the implementation layer of software.

That's the part to be cautious about heading into the AI era. The mechanical work of turning a known design into working code is exactly what AI handles best. If you think of writing code as the bulk of what you do, much of that overlaps with what AI can do.

This is why engaging deeply with the domain you're working in has become a real differentiator. What problem does the system you're building actually solve? What is the user truly struggling with? Pushing into questions beyond pure technology — that's a posture that matters regardless of where you work or what kind of engineer you are.

If you ask me what's the single most important thing to focus on heading into the AI era, my answer is this: step out of pure technology and seriously engage with the domain your work serves. I'd argue this needs to be pursued alongside hands-on experience in difficult situations, and arguably with even more deliberate effort.

Engineers often talk about being “T-shaped”: one area of deep specialization (the vertical bar), plus broad general knowledge (the horizontal bar).

I think the AI era calls for engineers to be π-shaped (pi-shaped) instead. Two vertical bars instead of one:

• Vertical bar 1: Technical expertise (code, system design, architecture)
• Vertical bar 2: Deep understanding of the domain you work in — whether that's a consumer product, a developer platform, a specific industry (finance, healthcare, manufacturing, logistics), or the underlying problem space your team owns
• Horizontal bar: The wider perspective that connects them (product thinking, business sense, communication)

Why is the second vertical bar important? AI is becoming powerful very quickly in pure technical territory. Writing code, suggesting design patterns, surfacing best practices. All of these are getting absorbed into what AI can do.

But the deep context of a specific domain is much harder for AI to learn:

• Why does this user behavior pattern emerge in a way the data alone can't explain?
• What is the operator on the factory floor actually struggling with?
• Why does this regulated industry require this exact workflow, no exceptions?
• What unspoken assumptions shape the way customers in this space evaluate your product?

You only learn these things by spending real time engaging with the domain — talking to users, observing how systems are actually used, working alongside people who live in that world. AI trained on text scraped from the web can't easily reach these.

An engineer who can write code is increasingly common. An engineer who can shape a product based on a deep understanding of the people who use it, or design systems that fit the realities of a specific industry, is much harder to find. In the AI era, value shifts toward the latter. Going deep in both technology and a domain is what π-shaped means.

Concretely, what does this look like?

• Spend real time understanding the people your product serves — read their feedback, watch how they actually use what you build, talk to them directly when you can
• Read deeply about the domain you're working in: research, industry analyses, books written by practitioners
• Engage with people who live in the domain — sales, operations, customers, users — not just other engineers
• Stay in one space long enough to develop real expertise (rotating too quickly prevents you from absorbing the unwritten context and conventions of the domain)
• Learn the unspoken norms, the failure modes, and the history of the space you work in

Domain knowledge takes years to build up. And unlike specific technologies, which come and go, domain knowledge is a much more durable asset.

Build hands-on experience

Alongside building domain knowledge, the other thing that matters is hands-on experience.

The two reinforce each other. Domain knowledge changes what you can see when something happens. Why does this incident actually matter? How far can we let it go before stepping in? Who needs to hear what? These judgments only become possible when you understand the broader context. And conversely, every time something happens, asking “why does this matter in this domain?” deepens your understanding of the space. The ideal is to grow both axes deliberately, like turning two wheels at once.

With that in mind, why is hands-on experience necessary? Because judgment at the higher layers has no “correct answer.” It's not in the spec. It's not in past cases. It's not in best practices. To decide “what should be prioritized in this specific situation,” you have to draw on experience that's become part of you. It's not something you can learn from a textbook.

For example:

• Living through a major production outage from initial alert to full recovery
• Being on a failed project and seeing firsthand what went wrong
• Making a bad technology choice and feeling the consequences in your bones
• Working across different products, domains, or organizational scales, so you can tell what's universal versus what's specific to a context

This kind of experience can't be acquired from books. It can't be acquired in a day or a month. It takes 5 to 10 years of cumulative exposure — and the deepest judgment often comes from staying somewhere long enough to see decisions play out, though that isn't always within an engineer's control.

And here's the key point: this kind of experience doesn't come to you on its own. If you stay in safe roles, you only get safe work. You have to go after it deliberately.

Concretely:

• Take ownership of small design decisions, even if they're modest
• Get yourself into technology selection conversations
• Make actual decisions in low-stakes contexts where you can fail safely
• Engage seriously when on-call rotations or incident reviews come your way
• Do retrospectives, and put into words why a decision turned out well or poorly

Engineers with this kind of experience aren't easily replaced by AI. The reason is that judgment in tough situations is exactly the kind of judgment that has no precedent written into past data. AI learns from patterns in what has happened before. But real-world incidents demand judgment in situations that haven't happened before. That's the territory of people who have built both domain understanding and real-world experience.

The collective story and the individual story are different

Pulling this all together:

The collective story: The engineering profession isn't going away. Looking at computing history, every wave of abstraction has moved engineers up the stack rather than out of work. AI is the latest wave in this pattern.

The individual story: But that doesn't automatically save every engineer. Without developing π-shaped skills, building hands-on experience, and continuing to learn, some people will get left behind.

It's worth separating what we can be optimistic about from what we need to actively prepare for. “Engineers won't disappear” is a statement about the group. “I'll be fine” is a statement about the individual. The first one is supported by history. The second one is up to you to prepare for.

A note across career stages

The picture is also different depending on where you are in your career.

If you're early in your career — junior or mid-level — here's the honest part: the craft of writing elegant, well-structured code — the thing many engineers have built their identity around — is exactly what AI is getting good at. If your value rests primarily on that axis, you're competing on terrain where AI improves every quarter. The path forward isn't to write more beautiful code faster. It's to develop the judgment, design instincts, and domain depth that senior and staff engineers have spent years building. The earlier you start treating those as core skills rather than someday-skills, the better.

To senior, staff, and principal engineers: the work you've been doing for years is, in large part, exactly the work AI struggles with. Judgment in novel situations. Designs that hold up at scale. Decisions that shape what entire teams build. Cross-team technical leadership. The systems you've shaped were never just code — they were judgment captured in code. That kind of value isn't going to be commoditized by a better autocomplete. If anything, it becomes more visible as the implementation layer gets cheaper. The leverage you've built is real, and it compounds.

Bottom Line: Engineers Don't Disappear, They Evolve

Here's the summary.

As a historical fact, rising abstraction has consistently moved engineers up the stack rather than out of work. The core of engineering isn't writing code; it's controlling complexity, making judgments, and being accountable. AI accelerates the lower layers, but the upper layers — what to build and who decides — stay with humans. This isn't a technical limitation. It's structural, rooted in how organizations and societies are built.

The “engineer who only writes code” is changing, yes. The same way assembly programmers transformed when high-level languages arrived. Job descriptions evolve.

But engineers who control complexity, make decisions, and own outcomes become more valuable as AI gets more powerful, not less. If AI produces a flood of code, you need more humans to direct that flood, not fewer.

Closing

“AI will replace engineers” only makes sense if you equate engineering with typing code. Real engineering is broader. It includes translating human intent into specifications, governing complex systems, making trade-off decisions, and owning the consequences. These activities will become more important, not less, as AI proliferates.

The history that began with von Neumann has shown the same lesson over and over: tools don't make humans obsolete. They let humans take on bigger problems. AI is the latest chapter in that story.

To students learning CS right now, and to engineers in the field today: your work isn't disappearing. It's evolving, moving up the stack into territory that requires more judgment, not less.

I've been writing about engineers, but I think this applies to other professions too. Office workers, writers, designers, translators — every job where AI replacement is being talked about almost certainly has a core that tools can't replace. The work is to find that core and grow it deliberately. That, I think, is what preparation looks like in any profession.

Von Neumann laid the road 80 years ago. We're still walking it. And the ones walking aren't the AIs. It's us.