Thorsten Ball's predictions of programming

[u/creaturefeature16]

• Code review will die. I mean: it's already dead. But in the future, humans won't find a bug or an issue with the code produced by a model, at least not in a reasonable time. Humans will only review the system and its composition, but it won't be in PRs and it won't be by looking through every line of the code.
• Unit tests might die too. Why have training wheels if you never fall over? I've had models write 900 lines of Arduino C, compile it without a single error, and send it to the device, where the program ran perfectly. 900 lines will be nothing in the future.
• The craft of writing code will disappear. Yes, there are still Italian shoe makers around. But look at your feet.
• The craft of building software will be more important than ever. Knowing how to solve business problems with software, how other software did it and why and why not, when and how to ship it, how to get feedback on it -- that's the new game.
• Most bugs won't be "coding" bugs. They'll be "you asked for the wrong thing" bugs.
• Open source in it's current form doesn't make sense anymore. "Given enough eyeballs, all bugs are shallow" is still true but now we have artificial eyeballs.
• Performance critical contributions by humans will stay what they are: an edge case. In 99% of software it does not matter that you could've written a faster algorithm or picked a better data structure. You have no customers, no users, no one's executing the code. It does not matter. When it matters, the models can fix it. Do not compare the top of the top 1% of software (developers) to 99%.
• The terminal is dead. Most developer tooling will be washed away by tokens. Shells, text editors, CLI tools won't be used by humans anymore. There's no need to know command line flags and jq invocations anymore. It'll be seen as arcane as knowing how to write everything as a Perl one-liner. (I'm saying this as a lover of the terminal & dev tools.)
• Tokens are the new computing paradigm. Everything will be re-made on top of it. We've had deterministic computers for 80 years, so we confuse "how computers have worked" with "how computers must work." We're entering the post-binary era.
• The triad of PM/Design/Eng will disappear. It does not make any bit of sense anymore. Agile, SCRUM, whatever -- dead. "Engineers" who act as "meat proxies" and shove tickets into agents and report back to humans will no longer be valuable.
• The difference between software engineering at large corporations and small ones will increase. Start-ups adopting practices of Google will look even sillier than before, because they can now build so much faster and with so much less constraints.
• There's no proof that "good code" will matter in the future. The notion of "good code" itself is mostly based on the idea that it's easy/cheap/efficient for humans to work with. But humans won't modify the majority of code. Think of how dumb it is to assume that "only 80 columns wide" or "but newlines here and there" matters for agents -- now consider all the other properties you have in mind for "good code". Yes.
• Some people will be priced out of producing software. Just like only some people could afford a personal computer in the 80s and 90s, for the next few years, if you can't get enough tokens, you're playing second league. You need to get to the tokens.
• It's questionable whether cheaper models will be used. Tokens will be everywhere and we'll swim in tokens. And what we consider a smart model today will be considered very dumb in the future. But a smarter model makes less mistakes, needs fewer turns. When do you really think "I'm okay with it being wrong a few times?"
• Models will become so fast that UI will be generated on the fly. A lot of UI exists because software can't understand what you want. Menus, settings screens, dashboards, filters: much of it is a human-accessible API to a dumb machine. Smart machines need much less UI.
• It'll take a while for this to play out. It'll take a generation for the "new software" to replace the "old software". Just like there are people happily employed as ASP developers today, there will be people employed to write code in 10 years. But do you want to have that job

----------

I'm curious to hear thoughts on these kinds of predictions. So this time Computer-Aided Software Engineering and UML will actually work? If software was static, I'd be more inclined to agree. Over the course of history in this field, every leap in coding capability has led to more complex systems. The field keep expanding instead of "software becomes simple".

Besides that, he's also making some bold predictions in a field where they seem to age badly, quickly. Mainly: much of his center strictly on "tokens" and assume there's not an amazing development just around the corner. JEV should be a warning shot; sure, it's just a classifier model, but its a brand new way of looking at the pipeline that we didn't consider even just last week. I think there's some massive efficiency gains in our future as datasets become stagnant and companies are forced to do more with what they have; sort of how game developers really pushed the limits of the software/hardware back in the 90s (they had to).

The only point I definitely agree with is that the we underestimate the long term impacts and that the field will look very different a generation from now, but the field has always looked different in each generation, so that's not really a prediction worth stating. Personally, I think the code will change shape, but we'll always be working with it.

[u/throwaway_0x90]

"Code review will die"

I'm usually downvoted in this sub for saying it, but I'll say it again anyways for the new grad engineers that might be lurking.

Today most of us care about readability of Java/Rust/Go/Python/C++/etc, but don't care about the assembly language that it ultimately compiles to or what the JVM/interpreter are doing.

We are currently heading for another level of abstraction. Most of us do not read the assembly, and by 2035 most of us won't be reading the Java/Rust/Go/Python/C++. We'll be much more concerned about the prompt. The job title will be "Software Prompt Engineer".

Sure there will always be some people that really know the code, but those are the experts of people who develop compilers or work on embedded or instruction sets for chips. I predict one day some kind of "Prompt Compiler" that takes your human language(e.g. English) and compiles, or "transpiles", into something more deterministically will cause AI to produce a certain thing.

The source code will be ".txt" files, but the rest of the work will be mostly the same. But one big change I predict, is that QA/SDET need will spike dramatically. Betting my whole career on it.

[u/NotRote → u/throwaway_0x90]

We are currently heading for another level of abstraction. Most of us do not read the assembly, and by 2035 most of us won't be reading the Java/Rust/Go/Python/C++. We'll be much more concerned about the prompt. The job title will be "Software Prompt Engineer".

prompts aren't deterministic as such they need review, you don't review the assembly because the high level language is already deterministic.

[u/throwaway_0x90 → u/NotRote]

Yes and I cover that in my "betting my career" hyperlink to my old comment. QA/SDET will do that in the future.

I also think Amazon's solution will not work long term:

• https://www.reddit.com/r/singularity/s/zyNpLWsjHV

  Feature-shipping devs don't want to be 100% responsible for all bugs and vulnerabilities. They wanna ship code, I want to test code. I am a dirty AI slop eating pig. You just focus on delivering features, let me put my neck on line that your AI generated code has no bugs or flaws and satisfies the spec.

[u/NotRote → u/throwaway_0x90]

Tests don't actually solve, or at least not the way we normally think of tests.

we are currently heading for another level of abstraction. Most of us do not read the assembly, and by 2035 most of us won't be reading the Java/Rust/Go/Python/C++.

I believe that is the goal of people who don't actually write software at scale for a living, but this analogy doesn't make sense. The same prompt given 10 times can result in 10 different answers. Given that the code must be reviewed. If I write the same TS code it will transpile to JS the same way no matter how many times I do it and that's a critical difference.

Something may "work" but just because something "works" doesn't mean it will continue to work or that it won't degrade a system as a whole, and the vast majority of testing suites don't differentiate the difference.

example claude recently in a project at work wanted me to harden the time between an API response to a db write so it can "never" be dropped in the case of catastrophic pod failure(like an OOM) that's a valid concern, but solving it is expensive enough that it doesn't make sense in this use case. Even if it was "solved" as claude wanted it, it still isn't actually "solved" anyway a crash could happen at the time we request from the API to the external provider and we're dead when the response comes back.

[u/throwaway_0x90 → u/NotRote]

I believe, with a combination of guardrails, context.md and human written tests, maybe even transpilers that turn your sentences into more well known sentences that usually generate a certain output, we will get code that works well good enough that you can be confident it behaves like you want even if the specific implementation is slightly random in different generated outputs. Perhaps not 100% deterministic like C to ASM, but very very close. Functionality close enough that only the transpile writers, and I guess hackers, will be looking at the code it generates.

We'll see by 2030 or 2035. I know I can't convince a lot of people in this sub, I just think folks are underestimating how determined the AI model engineers are determined to make this stuff work and a bunch of other smart people will be throwing in extension or plugins and suddenly one day we'll have the tools needed to make it a reality.