The Many Ends of Programming

Hi, I'm Ray Myers. I'm currently chief architect at All Hands AI, makers of the leading open source coding agent called OpenHands. But I'd like to talk about something different today, and I'm, I'm proud to be presenting at the online track for AI Engineer World's Fair.

But I feel like I've actually snuck in the back door today because this is not an AI talk. Perhaps this is not even a programming talk. This is a talk about empathy.

This is a talk about listening to each other. But if those things are uncomfortable for you, don't worry, because we will have the pleasant, comforting backdrop of AI and programming.

For starters, let me take you through a day in the life of an AI skeptic, which is the role I so often find myself in. What happens is someone will say something provocative in public, like you may have seen, uh, the CEO of Anthropic, Dario Amodei, say a few months ago at, uh, a Council on Foreign Relations

interview. Um, many interesting things in, in that interview, but a quote that we saw got shared around a lot was, "In 12 months, we may be in a world where AI is writing essentially all the code."

Right, now he's speaking to a general audience. Uh, as software engineers, we hear a little bit different, uh, when you're saying the part about writing the code 'cause we understand that, uh, the job contains, you know, other, other factors.

But regardless, um, I posted a, a friendly challenge in response to that, uh, to do with, like, could you replace the software in one mainframe? Can we kill one mainframe even?

How difficult is that right now with these, uh, AI tools that are soon to supposedly write essentially all the code, right? Um, and the specifics of my challenge are not really that, that relevant right now.

Just over the past two years, I have repeatedly said different forms of this. LLMs, large language models, break old code. I, I say that a lot because I think it is ignored.

Simply the importance of maintaining old code and keeping it alive, that already is ignored, and the extent to which, uh, these AI tools are performing much better on writing new code than in editing code that already exists, I feel like that's sort of doubly ignored as a result.

I feel like I raise pretty basic questions and point out pretty obvious limitations a lot of the time and get somewhat extreme reactions, honestly. You know, I've been called a Luddite.

I've been told I have my head in the sand. I've been told I'm missing the big picture. In the case where I posted that challenge, actually, the, the full quote was, I was completely missing the big picture, so much that it physically hurts to read my post.

Um, and you know, if my posts have hurt you, I'm, I'm sorry. Um, it- honestly, it doesn't feel good to be talked to in any of these ways, right?

So y- you may have had to feel that way at, at some point as well, or maybe you've been told this. You've been told that you'll be left behind.

Um, I struggle with this one, honestly. I, I feel that left behind is verbiage better suited for, you know, some post-apocalyptic religious prophecy in the form of a B movie franchise starring Kirk Cameron than in some sort of nuanced technical discussion.

Um, I heard this one recently from someone who, um, was saying it with a straight face and is someone whose work I, I respect, you know, goes back a long time.

They said, "Resistance is futile." Uh, again, I, I cannot comprehend what would make someone want to say things like this. For all the money in the bank, do you recall what that quote is from?

Was it from the hero of that story? No. It's a quote from the Borg from Star Trek, one of the most notorious villains in the entire science fiction genre.

If we find ourselves quoting the Borg in earnest,

maybe we should reassess what side we're on. When Picard was captured and being mind-controlled by the AI, he said, "Resistance is futile," as Locutus, but the real Picard would never say, "Resistance is futile."

Picard would say, "If you're on the side of truth, you should resist to the last breath." He embodied that again and again. Um, but we need to breathe. Um, I'm responding to emotionally charged rhetoric, and now I've just started spewing out my own emotionally charged rhetoric in response.

This is not helping me listen to these people. They're, they're... They mean well. You know, I've chosen to engage. I made the decision to engage in these conversations, and I need to be able to try to do that productively.

I need to be able to hear people out. I think we need to back up and decide what are we even talking about. It is something very important. It makes sense that a lot of us feel strongly about it, which then leads to us being in conflict with each other because we're, we're pondering what is the future

of software? What is it going to look like next? What can we make it? I mean, that, that is deeply interesting. If there's one thing I am grateful to AI for is probably, uh, even more than the technology, the opportunity for us to have all be thrown into this one conversation about the future of the craft.

It's a very difficult conversation to be in of late, and I'm gonna try to make it a little easier with this, but I think it is an important one worth having.

I've identified six scenarios that seem to be embedded in the views people have been putting out over the last few years, and I'd like to share them with you for the remainder of this talk.

Let's get started. These are extreme completion, the devocalypse, the abstraction leap, uncharted waters, the review economy, and the infinite pile of garbage. We will discuss each of these briefly.

Now, extreme completion is probably the most conservative of these views because it is, is already happening. We can just see it happen. There's no real doubt about whether this one will happen.

It is just a matter of, you know, how much with what impact, and that is simply the, um, autocomplete style editors like Cursor, like GitHub Copilot, are just going to continue to help us type more of the typing and, uh, be a great convenience, right?

So in that scenario, in extreme completion, our job doesn't fundamentally change. Even as they progress to these agents that can take a few more steps, you can still have, you know, a fairly extreme completion with it still needing to be on an engineer's leash most of the time, such that you could argue our, our role is not

changing, like, a great deal. So pretty much everyone agrees this at least is happening and, and is a somewhat significant shift, right? This is what this looks like. If you're at this conference, you've surely seen it.

This is an example of using the Cursor IDE, which is a fork of VS Code with a lot of AI, uh, features built in. So there's a function called cleanPrime to remove trailing white space, and I've prompted it here in this little pop-up thing that happens when I, uh, hit Control+K.

Make the function cleanPrimePrime to remove both leading and trailing white space, and sort of based on that example, it's going to make me another Haskell function pop out. There it is.

It's pretty cool. By the way, the reason I happened to pick the programming language Haskell for this example is that it has a very, uh, strong typing system. I think that type theory is a very promising counterbalance to add more certainty into the flow when we have the uncertainty of, of LLMs doing codegen.

Regardless, uh, here's a- another example that, that is maybe a little more, uh, where, where we think things are going, where I have, uh, delegated an entire task via Slack.

So I'm just in my work chat here, and this is a, a new experimental way of interacting with the OpenHands agent. Uh, said, "Hey, there's, uh, this pull request here where I've added this, this thing to a log statement, and probably some other things ought to have that too.

Could you just, uh, poke around and, and make a PR that's adding that where, where it ought to go," right? And a few minutes later, boom, comes back this 48-file pull request.

Like, this is really cool. You show this to me, like, a couple years ago, I would go, "This is unreal" that we have this. No- nonetheless, it is a fairly discreet, you know, uh, task.

Not a lot of, quote-unquote, you know, thinking needed to be done here. But there, there is a lot of grunt work that's, that's been taken up by being able to do stuff like this.

This sort of, you know, all-purpose tech debt dirt shoveler. Really neat. Still, I file it under extreme completion. Uh, it, it is on a, a very short leash. A lot of expertise still involved.

Much more extreme is the scenario of the devocalypse, the developer apocalypse. At least, um, that's what it is to us as software developers. If you're not a software developer, if you are dependent on software developers, actually, they don't see this as an apocalypse at all, right?

They see this as the innovator's paradise scenario because they're no longer dependent on us to bring their ideas to fruition. It sounds very nice from their point of view, and I- I'll say this.

Even, um, though we, we benefit from this not happening at the moment, um, if it actually is possible, if we can deliver it, I think it is desirable. Like, we should do that.

I think really that would be programming fulfilling its destiny. It would be finishing the project of computer science. You know, the objection to it wouldn't be, "This isn't desirable."

I think the objection would be, "It's not feasible to do." But of course, because of these different incentives, someone who sees us objecting to it can always say, "Hey, you just want to keep your job."

And, like, I do want my friends to keep our jobs, right? Of course I want that, but I just don't think that's why I'm saying the things that I'm saying about, um, how some of these, these solutions look unsustainable.

You know, I, I think we have real expertise that these critiques come from. So if you're going to predict the devocalypse, uh, you still must say how we are going to get there, right?

And abstraction leap is one of those ideas. It has a few flavors I'll talk about. But basically, if you're a believer in abstraction leap, you think that what we currently think of as code will no longer be the, uh, kind of level of abstraction, the, the substrate in which we do our main work.

Uh, doing something like Java code or, or Rust code today, you know, that, that will eventually be in the position of assembly language or JVM bytecode or LLVM bitcode or something to that effect.

Only highly specialized people would need to do that. Most of us can just live up here, uh, doing something more, uh, pleasant and, and productive, whatever that may be.

But internally, it's ultimately code-like a- as we currently understand it, right? So- How does that happen? One way people say this will happen is with the prompts-as-code flavor of the scenario, as I call it.

So natural language instead of source code becomes the main human-facing artifact that we manipulate. So how does that scale? Well, maybe it gets some kind of structure, right? Maybe there are a bunch of little requirements inside, uh, folders that are interconnected.

I don't know. It, it is structured somehow. It is tested somehow. The objection to this, other than maybe, uh, you know, vagueness, would be predictability. There is serious reason to doubt that LLM prompts constitute an abstraction, at least as far as something that you're able to really build on, because, uh, of how unpredictable it

is. Perhaps in order to build really large, long-lived projects, uh, this just is not a sturdy enough foundation. It's not a clean abstraction.

You could say that it will become one. Um, we have to see that happen. Or, you know, some people believe that it's possible to make up for that unpredictability with some sort of control.

Here's an attempt to do this, right? This is actually from, uh, a few years ago now, the Parsl paper, and you can go to this, uh, GitHub repo if you like, or you can read the, the, the paper.

And this is an example, for instance, where they've got 61 lines of just these text prompts and example input and output of all these different functions. And from these, uh, prompts and examples, it, it generates a 220-line Python program that functions as a Lisp interpreter, right?

So they've, using these structured prompts, generated an entire Lisp interpreter. Like, that, that's pretty neat, right? Um, and yet, you know, we largely don't believe structured prompts as code as a way to build real applications ha- is a solved problem still.

Uh, so you know, when you try to operationalize this, are we going to be able to make this into a, a real product that is, is better than its alternatives?

I think very much still up in the air. Another flavor of abstraction leap I think personally is a little m- more promising is domain-specific languages, or DSLs. Now, if you believe you're unfamiliar with DSLs, actually you probably are familiar with them, because in programming there, there are many of them that, that occur, right?

So, uh, CSS, right, the, uh, that you use to style web pages are an example, or SQL queries, or regular expressions, right? And these are a domain-specific language for particular programming tasks.

And then you also have ones that are made for particular business domains. Even things like Excel, uh, you know, arguably are a domain-specific language. So th- these are very prolific, very successful, uh, oftentimes.

Um, and what you do if you're operationalizing this, you know, in an inter- enterprise scenario is you ultimately are investing in creating a particular specialized programming environment that, you know, optimizes for the kinds of thoughts you usually need to express i- in your business domain, right?

And, uh, that is this upfront investment that can yield great reliability, great quality, uh, great productivity, you know, wh- when it works well. Uh, it can also backfire of course.

And over the last 20 years, the, um, kind of risk-to-reward trade-off has been steadily improving with lots of tooling that's made it easier to create these specialized environments s- such, such as language workbenches, right?

So, uh, examples of that are, uh, JetBrains MPS, right, um, one called LionWeb, one called Xtext. There's one, uh, you could call it a language workbench, they would say it is a language-oriented programming environment, called Racket, which is a very interesting Lisp dialect.

And there is every reason to believe that language models in various ways would even further improve the costs, uh, you know, risk-reward trade-off of creating these, these specialized environments.

Can they help us generate, you know, the, some of the code to process these DSLs, or can they help on the, uh, side of the editor, giving the, the, you know, business domain users suggestions to, to allow them to more quickly adapt to these languages?

So, um, I think this is a very promising area. I've actually declared it the year of DSLs on my YouTube channel, Craft vs. Craft. On the right you can see, uh, my announcement of that.

There's a recent video if you wanna dive a little deeper, or better yet, you could watch this talk called Empowerment of Subject Matter Experts by, uh, DSL aficionado Markus Voelter.

But again, an abstraction leap scenario, ultimately what's underneath that abstraction is still fundamentally code-like. It is still basically following the rules as we understand them today. Next, we have uncharted waters.

Many people argue that the future, the foundation will not even be code-like. It will be like nothing we have seen before.

So what does that mean? Um, some say that it will be direct model inference, so you will be not just using LLMs in code or using LLMs to code, but LLMs will be like the processors themselves, that model inference will simply be the new computation.

Um, or maybe the AI becomes super intelligent and it invents a new programming paradigm we can't even conceive of, right? And, um, I don't know. Uh, I think- Uncharted waters are certainly possible, but in order to plan for them, in order to take these possibilities seriously, we need to chart them.

We need to really see what works and, and what really scales, right? And I, I don't think we've, um, we've seen anything like this really prove out yet.

Getting back to the mundane, we have, uh, the next to last scenario, the review economy, right? So in this one, this is created, for instance, by the extreme completion, and we have very cheap to create all these pull requests, like the one I generated, you know, in that, in that previous slide, and we're still stuck

checking their output because they're not good enough to just completely approve. So ultimately, we are just reading pull requests from these AIs slinging them at us, you know? Many people find this to be kind of a dismal scenario.

Like, the least fun part of the job has just become our whole job. Kind of depressing. I don't see this so much as an end game, but maybe it will be a pit stop.

There are certainly companies that I've already seen. You know, this is some kind of reality, but I think it's a pit stop along to something better. I think it is a sign that you're not managing your bottlenecks well.

Pro tip, there's a body of knowledge called theory of constraints, um, introduced by Eli Goldratt starting in the, uh, novel The Goal, but there's a lot of work in its sense.

But the thinking processes in theory of constraints are really helpful whenever you're in some situation that it looks like this, right? Where everything's held back by this one choke point, like in this case, manual developer review.

Examples of what, uh, you know, improving that can look like are shifting further left. Like I mentioned with type theory, like any number of, of things, how can we reduce the error rate such that we're less bound by, uh, needing to review these?

Or maybe it's just a matter of prioritization. Maybe we need to pick and choose which of these things we're even gonna try to review and, you know, by shipping a third of those items, we get 90% of the value, 'cause we're doing a good job of picking the, the right ones, the ones that, that, that really are

going to give us something. Last scenario, and the most dismal, is the infinite pile of garbage. In this scenario, coding assistance made us feel more productive, but ultimately just exploded tech debt and dug us into a hole that even the AI could not dig us out of.

The quality of our products gets worse over time instead of better. Uh, ultimately, it's a world of hurt. We hope that this doesn't happen, of course, and there's reason to think it may already be starting to happen.

This is, for example, um, a group called Uplevel, which did some investigation in which they did this controlled trial and they found that developers who had access to a coding assistant were, uh, putting out a significantly higher bug rate and, and not even having better throughput on their issues.

That's pretty dismal. GitClear also has a white paper, and they have a number of interesting things in that, one of which is that this was the first year, 2024, this past year, was the first year they've seen where the percentage of code that was copy-pasted exceeded that which was moved in a refactoring.

If you know your way around code quality, that's a big red flag. Lots of copy and paste creates a lot of risk. Some people could argue that with these AI tools, the practices, our intuition for, for what is a good thing or not may need to change, but that needs to be borne out.

You need to prove that. Unsurprisingly, GitHub actually had the opposite finding. They did not find that their Copilot tool that they sell, um, decreases quality. They found that it increases it.

Now, they were doing a controlled experiment involving a fixed task. It was not like these other examples, um, you know, an example on, on real work code, but there's any number of factors that could impact this.

So they, uh, have a blog, uh, does GitHub Copilot improve code quality? Admittedly, much better graphic design. They say, yes, it does. So what do we make of this?

I mean, these results are obviously, you know, contradictory and ambiguous, but, you know, even more importantly, they're all from sources that have something to sell. You know, I, I have seen some more rigorous academic work start to come together.

I'd love next year to be talking about not some white papers and a blog, but, you know, uh, maybe a meta-analysis of multiple different, you know, independent academic studies of, uh, what results we have in the wild with AI coding assistance.

Will we be able to, to do that? I mean, I hope so. But one way or another, you know, um, do these make things better under certain circumstances and worse under other circumstances?

Does it matter how we use them? Does it matter what we use them on? These are all things we need to understand so that we know we're making the situation better and not worse.

People will say the models will get better, but the products we use them to build will get better only if we make them better. We need to be deliberate.

Again, these are the scenarios: extreme completion, Devocalypse, abstraction leap, uncharted waters, review economy, and infinite pile of garbage. Now, these interrelate in various ways, right?

So for example, by doing extreme completion- Many fears I just mentioned that we will try to get to Devocalypse, but actually we will over-invest in them before we're capable of dealing with their results, and we'll slide right past Devocalypse and into the infinite pile of garbage.

Some think, this is maybe the closest to my point of view, that a really promising area would be to combine abstraction leap with maybe domain-specific languages, combine that with the extreme completion.

We have a very nice, uh, DSL or say a formal methods, uh, base, you know, specification system, and then we combine that with the extreme completion to, you know, you know, help us navigate it ergonomically.

Th- this could work very well. So there are these multiple different end games, and if someone believes in a different one as you, you might both be right because many of them are gonna play out.

The industries are vast. This is going to, um, impact different areas very differently. We wouldn't expect the, uh, AI coding impact on, like, video game programming to be the same as in healthcare tech, right?

And lastly, I wanna leave us with this. We get a say. People have spoken about AI coding as though it is some meteor from outside the solar system just coming at us to hit us, and we're these, these passive observers.

We get a say on what happens. This is something that we are actively building together. So I think we need to ask ourselves, what do we want from software?

What is the goal? Do we want there to be no programmers, or do we want everyone to be a programmer? I don't think those are the same thing. Is it somewhere in between?

Where? Uh, do we want software to be better, of higher quality, or do we just need more software and we don't care about the quality? Again, not the same thing.

As the skills required to do our jobs change, what do we want to happen? Do we think it's a good idea to just let people go who have diligently learned what yesterday was the thing we needed, or are we going to figure out how to, uh, continue to develop a, a valuable relationship with those people?

I want many things from software. I want it to work well. I want it to provide value for the people who use it and for the people who build it, and I want people who work together to treat each other well.

Well, thank you very much for having me, and I look forward to your questions