The Future Programming Language Is a Conversation

The Mythology of Going Deep

Growing up, John Carmack was my hero. The story of him tearing off the "shim layer" of human-readable C, diving into raw assembly, and hand-optimizing a rendering engine so that Doom could actually run, that's the stuff of legend. Then came the Jeff Dean mythology at Google, which reinforced an idea that stuck with a whole generation of engineers: the lower the level you operate at, the better the engineer you are.

That worldview pulled me toward Microsoft. I worked on Internet Explorer's layout engine and the rendering engine. I introduced subpixel rendering to IE on Windows Phone. I fixed a Windows boot time regression. I built Android on Windows - the project that introduced a new Linux subsystem to the OS.

Pretty deep, right?

But eventually I had to reckon with something: there isn't that much magic under the hood. Layers of abstraction exist for a reason, so we don't keep solving the same problems over and over. The real point of good engineering is to free smart people to work on new problems. So I joined Uber, where a whole new class of real-time distributed systems problems was waiting.

This Isn't the End of Software Engineering

Fast forward to today. Vibe coding is everywhere, and with it comes a wave of hot takes about the death of software engineering. Meta's Peter made waves saying software organizations need to be rebuilt from the ground up, that coding agents shouldn't be copilots, and that the new bottleneck is the spec. That aligns closely with what we've been seeing at Otto, where we've been practicing AI-driven development, autonomous debugging, and unsupervised self-evolving systems for almost a year now.

And yet the idea that this is the end of software engineering is flat-out wrong. (Yes, I'm biased.)

This is the object-oriented programming moment for everyone still writing procedural C. It's the big data moment for those stuck in the client-server era. A paradigm shift doesn't kill the field, it raises the floor and redraws the map.

What Does a Software Engineer Actually Have?

Here's a thought experiment I keep coming back to. Imagine a software engineer time-travels to medieval times. No computers, obviously. Their knowledge of compilers and memory allocation isn't going to help them survive a single winter. A history student, a chemistry student, a pre-med, any of them would have a clearer shot at thriving in that environment.

So what does the engineer actually have?

Problem decomposition. Timeline estimation. Modularization. Feedback loops. Requirements gathering. Test-driven thinking. The 80/20 rule. The flywheel. The quick prototype. Product-market fit.

Software is magical not just because it automates repetitive tasks, but because it gave us a methodology for breaking complex problems into manageable, solvable pieces and tackling them one at a time.

That methodology doesn't disappear when the syntax changes. But where it lives does.

In every prior shift - assembly to C, C to OOP, monolith to microservices - the methodology moved up a layer. It got captured in new abstractions, new patterns, new tooling. The decisions that used to live in raw memory management got encoded into language features. The decisions that used to live in language features got encoded into frameworks.

The conversation is that next layer.

What Vibe Coding Actually Is

So let's talk about what vibe coding actually is when you strip away the hype.

It's a person - someone with a specific, hard-won understanding of a problem and its pain points - riffing with a coding agent on plans, architectures, design tradeoffs, and quick prototypes. Then iterating: generate code → verify the experience → modify the design → generate again. Repeat until the outcome clears the bar.

Then ship.

Throughout this process, a cascade of artifacts gets produced. Some are permanent. Some are ephemeral. Chat messages. Design docs. Code diffs. Logs and traces. If you recorded every interaction and replayed it from scratch, would you get the exact same output? Probably not. But if the same person - with the same purpose and the same bar for quality - started over, the resulting product would achieve the same goal, even if the code looked different.

Now remove the AI from the picture and replace it with the Mechanical Turk, a human pretending to be a machine. Would that engineer always write the exact same code? No. Does that matter?

No.

What matters are the questions being asked. If you know what to ask, there's almost always a good default answer available, or at least a handful of reasonable options, most of which are two-way doors anyway.

To me, that conversation - the questions, the decisions, the context that shaped them, the verification, and the iteration across all of it - is the engineering process now.

The Future Programming Language

This matters more than it might seem, because the structure of engineering organizations should be built around the actual process.

Agile development gave us small, cross-functional teams with embedded QA, product, and data, so we could ship weekly instead of annually. "Move fast and break things" made A/B testing a default. Site reliability engineering made observability and scalability first-class citizens. "Every team is a platform team" elevated the API contract. "We're a logging company that happens to stream video" put data science at the center of product decisions.

Each of those movements restructured how organizations operate because the underlying process changed.

This one is no different.

So what does the future programming language look like? To me, it's the conversation itself: the context, the persisted session-level state, the back-and-forth that encodes intent and decision-making. The generated code files become less and less relevant to humans and start sinking down to the runtime layer, closer to bytecode than to source.

From that lens, the current repository structure is already showing its age:

1. Only static context files (AGENT.md, various docs) live in git. The conversation and session-level state, where the real decisions happen, aren't under version control at all.
2. There's no established way to review what questions were asked or what tradeoffs were weighed during a session.
3. There's no consensus on the basic unit of a commit in this new world. Should it be a feature? A phase of a feature? How big is too big? How do you decompose a task across agent sessions in a meaningful way?

At Otto, we're starting to tackle this pragmatically, always committing the docs that record decisions alongside the code, keeping pull requests associated with the agent conversation that produced them. But it's early and ad hoc.

The industry needs more than workarounds. It needs an established set of tooling and process conventions to formalize what AI-native engineering actually looks like, the way Agile, SRE, and platform thinking each formalized a prior shift in how software gets made.

We're in the middle of that moment right now.

The question isn't whether software engineering survives. It's who shapes what it becomes.