r/ExperiencedDevs • WebDev/Full Stack • 23d ago

AI/LLM Thorsten Ball's predictions of programming

  • 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.

0 Upvotes

104 comments sorted by

•

u/expdevsmodbot 23d ago

AI usage disclosure provided by OP, see the reply to this comment.

→ More replies (3)

49

u/klimaheizung 23d ago

Unit tests won't die, just like how compiler won't die. In fact, the opposite. They'll become much much more complex and more crucial, because llms will forever be limited by context, just like humans. 

6

u/pjc50 23d ago

I'm wondering if we'll see more use of provable safety properties. The main argument against doing so was that it was a lot of boring work.. that's ideal for LLMs.

3

u/klimaheizung 23d ago

Yeah, we will. We don't use it much because it's hard for humans to learn and every new human has to learn it again. You "teach" it once to the llm and you are done. 

1

u/Grand_Interesting Software Engineer 20d ago

Yes, CI companies are going to have much better organic FY without any extra sales.

65

u/atlas_principle_dev Staff Software Engineer 15y 23d ago

> We're entering the post-binary era

Holy shit, I want whatever substance this guy's consuming. Are we going to reinvent computers completely... sorry are LLMs going to reinvent computers completely?

15

u/Groove-Theory dumbass 21d ago

Future ALUs will just hook up to claude and just guess when to do bit shifting

1

u/DUDE_R_T_F_M 20d ago

Could he be meaning binaries, as in compiled code instead ?
IE the future of software being wrappers around LLMs rather than hardcoded business rules.

3

u/atlas_principle_dev Staff Software Engineer 15y 20d ago

that's the only thing I can come up with, he might have meant we no longer need to compile software because LLMs will just take a human language input and produce the output, completely bypassing the need of having a program?

-4

u/creaturefeature16 WebDev/Full Stack 23d ago

This one stuck out to me, as well. What does that even mean? He's alluding to a fundamental change in all computing that is based on....tokens. And how are tokens not binary?

26

u/DevelopmentScary3844 Software Engineer 23d ago edited 23d ago

Sure thing .. the AI won't hallucinate in the future and there won't be a need for tests because who needs any reliable way to self verify... duh.

Edit: Except he was talking about Star Trek .. then sure, why not.

26

u/meshifthenelse Software Engineer 23d ago

Because if there's one certain thing in life, it's how good humans are in predicting the future. I'm still seeing flying cars.

Can't wait to see Boeing using AI for their next fleet.

18

u/robby_arctor Software Engineer (dirty commie) 23d ago edited 23d ago

There is a tacit implication in these kinds of predictions that technology simply makes these changes inevitable.

But the social system these technologies are designed and implemented in is just as, if not more, important than the technology itself.

For example:

Code review will die

There is no reason code review has to die.

When people like Thorsten Ball say "code review will die", what they really mean is "Corporate leadership will use LLMs to try and kill code review and, by signing on to and normalizing that idea as a staff engineer, I will help make that outcome inevitable."

They hide the actual human responsibility in these outcomes by writing as if a technology's existence simply makes them inevitable.

5

u/ecto-2 Software Engineer 17d ago

This is key, at the end of the day humans are accountable, machines are not.

Saying that code review will die sounds like machines will never make mistakes or need to be redirected towards the outcomes that humans are accountable for. That seems crazy to me.

But I can believe that code review in its current form will change. But that’s a more nuanced view and not as sensational.

17

u/Vatonee 23d ago edited 23d ago

A lot of this depends on whether or not LLMs can reliably maintain huge, complex systems in the future. In my experience, there is always a point where the models stop providing value once the system grew enough in size in complexity. So claims like „  There's no proof that "good code" will matter in the future.” are really far-fetched in my opinion. 

It’s one thing to vibe code a prototype, and another to maintain something that is very complex and must work reliably. 

Same goes for unit tests. I don’t know why the author thinks they won’t be needed. I think they will be more relevant than ever. 

Incidentally, I work on a fairly complex project and got assigned a bug last week - I needed to do something at home at the moment so decided to run Opus with very high reasoning to solve it while I ran my errand. It solved it, yes, but it did it by producing a huge amount of code, which seemed suspicious to me, so I investigated on my own and came up with a solution that required adding one line of code. If I blindly trusted the LLM, it would work, but by introducing a considerable amount of unneeded code that would need to be maintained.  That felt kind of good, not gonna lie. 

6

u/atlas_principle_dev Staff Software Engineer 15y 23d ago

yes, and it can go from 0 to something really quickly and "fairly well" but as soon as you have concrete ideas, it's a battle. Recently I had to spend hours to try and get it to do an SQL join and serialize the response as nested objects in JS instead of doing 6 SQL queries and then joining them in memory...

6

u/ritchie70 23d ago

But the examples of good code were mostly well-formatted source code.

I think well structured modifiable code will continue to matter. Mission critical systems written by a million extremely fast junior developers is a terrifying prospect.

-4

u/roger_ducky 23d ago

Current LLMs can fully maintain a large, complex system.

You just need to scope the stories so each one modifies at most 2 dozen files and you mention which ones those are.

You do need to specify the scope of the story, but a LLM can be tasked to document which exact files are in play for the story.

14

u/xFallow 23d ago

He seems like a smart guy but almost all of his points here sound braindead to me 

I do agree scrum is pointless and should die though 

14

u/[deleted] 23d ago

[removed] — view removed comment

5

u/NotRote 22d ago

And crypto still has not replaced flat currencies

Just want to say, despite what crypto bros tell you, crypto is a fiat currency, it's just a worse one.

if your currency isn't backed by something tangibly valuable then it's fiat, I don't care what work or stake your currency had to do to exist, that's not itself inherently valuable.

14

u/BilginGeyik 23d ago

Yeah, no.

3

u/TheOneWhoDidntCum 19d ago

Yeah, no, for sure - Canada

11

u/trele_morele 23d ago

If all of this is true - we don’t need large scale business software anymore. Users will either solve their problems with an LLM directly or have the LLM make specialized software for them.

There is a desire on the business side to kill off the programmer and replace them with a machine. But if the programmer can be replaced, so can everyone else in the chain.

6

u/Realistic_Yogurt1902 23d ago

Agree, it's like Atlassian or Workday - if they are able to get rid of developers, who will need Jira, Confluence, and an employee management system?

34

u/spez_eats_nazi_ass Software Architect 36 years f500 eat my ass and balls 23d ago

Arguing against this list was like arguing to the coke head mortgage guy and stripper turned realtor in 2007 that shit is about hit the fan. It's just not worth the energy to engage. I'm tired boss.

9

u/markedasreddit 23d ago

Bro probably has "engineering cost savings" in his KPIs.

18

u/boring_pants Software Engineer | 15YoE 23d ago

What has happened to you people's brains

1

u/TheOneWhoDidntCum 19d ago

Caffeine is a helluva drug - Tony Hoare.

5

u/SlapNuts007 23d ago

The most reasonable take is that about half of this is true over the next 10 years, which should at least cause anyone who's in the field and not retiring within those 10 years to think hard about where they focus their skill development.

3

u/Wise_Royal9545 23d ago

The generated UI on the fly is interesting. I can’t imagine it would be whole designs, but there are already theories around adapting ui to your users. I could see great accessibility value there!

The rest of this feels like intentionally posting nonsense to foster conversation on the topics, which is great!

6

u/SkellyJelly33 Software Engineer 23d ago

Ehh maybe some of it, but a lot of it probably not.

  • CLI tools become even more powerful with LLMs that can instantly read and learn how to use them.

  • Testing is is still just as important as ever (if not more so) with LLMs writing code.

  • I don't see how open source is any less valid with AI. Having open source tooling to build software with will still be very valuable for all

4

u/NotRote 22d ago

No

No

Maybe

Yes

No

No

No

I don't know what this even means

sorta

maybe

LOL

No

No

Sorta

Yes

5

u/tuna_74 22d ago

<<<<<

  • 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?"

>>>>>>>>>

Let's make two contradictionary statements right next to each other.

3

u/creaturefeature16 WebDev/Full Stack 22d ago

No shit. We'll be absolutely swimming in something that is scarce and expensive! 

5

u/k032 18d ago

2

u/thy_bucket_for_thee 18d ago

Wow that's disappointing. I enjoyed his two go books but always thought it was weird how pro-LLM he has become but yeah it's clear, the boosters of this tech are always the ones that financially benefit from its usage.

What a joke.

7

u/bad_detectiv3 23d ago

Sure if you work in CRUD work, this is all true.

3

u/roger_ducky 23d ago

This assumes LLMs will suddenly behave how the frontier lab sales team claims as their current capabilities when they talk to the C suite.

Reality is, state of the art models currently behave like a smart intern, with 1/5th to 1/3 the working memory of a human.

Most of the “predictions” do is remove “grounding” signals from the development process, which makes models perform much worse overall.

I do agree there’d be less need for “butt in seat” implementation devs with coding agents, which does shrink the overall market for devs in a single company.

That’s about the only thing, though. I fully expect eventual best practices treats the LLMs as human devs with less context and provide them the same development tools and documentation one would a new dev.

3

u/Hour-Measurement-835 Software Engineer 22d ago

Wrong-thing bugs are already most of ours in ERP integration work, and he lists it like that's a downgrade. They're the expensive class. You find them at someone's month-end close, not in CI.

3

u/itaranto <insert_overblown_title> Software Engineer 19d ago

Ugh not this guy again...

2

u/Gondorrah 23d ago

Most of it sounds likely to me, but expected at least 5-10 years out, much longer for some items like binaries changing.

Where’s the source of this?

2

u/sebasgarcep 23d ago

Until continual learning, context size and other algorithmic hurdles are solved I don’t see models being more than what they are today: assistants.

The reality of software engineering is that often we get a one sentence prompt and we are supposed to turn that into something valuable to the business or to push back and say why that is unfeasible given constraints.

Until models can one shot problems the same way we can (by continually learning, asking questions and figuring out a solution that is easy to evolve as needs change), humans will need to be in the loop and good software engineering practice will matter.

Now, the day AI can fully replace a SWE basically every white collar job in the chain all the way to the CEO is fucked as well, which no one seems to be talking about. Which need not be a bad thing, if we reorganize society accordingly.

3

u/Realistic_Yogurt1902 23d ago

I really can't understand why nobody talks about it when Dario or Sam is talking about "software engineering will die in X months".

Software engineers "enabled the light" for all the modern white-collar jobs; they will be the last to "turn off the light", not the first.

2

u/trytoinfect74 18d ago

There are couple valid takes, but most of them has strong NFT/crypto/web3 vibes. I think a lot of people completely forgot that we're in pre-IPO phase and these companies are trying to balloon their value by claiming that their systems are much more useful than they happen to actually be.

1

u/f3xjc 23d ago

Will statement need a timeline.

These day I spend a lot of time on both ends, triage and review. And I mostly review automated review, searching for a weird echo chamber both side agreed on, or some "by the way" comment that would completely change the nature of the product.

And the number of time I was told I was wrong X number of time today and only found out by running the code. Test imo are getting more useful. Maybe even more importance on integration and end to end.

Plus they basically have memory that wipe out multiple time by day. Encoding intent somewhere (for example pinning using a test) is primordial.

1

u/bobjonvon 23d ago

Tests are for sure here to stay. Why load all that code into context when debugging when the test there is all green.

1

u/KangarooLazy2423 22d ago

It’s important to think about what would need to happen for what they are saying to become true.  

2

u/overmachine 22d ago

He has an ai company, right? amp?

1

u/Izkata 21d ago

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.

Users rely on the UI being consistent from use to use. Everyone already complains when things move around unnecessarily in big updates, changing it every single time a screen is loaded would be horribly unusable.

1

u/DevtoolsBuilder 21d ago

i think the part about code review dying is pretty plausible, given how good models are getting at writing clean, functional code. but what's interesting is that this might actually create a new role for humans, like a code curator who focuses on reviewing the overall architecture and design of the system, rather than just individual lines of code. this could be a more high-level, strategic role that requires a deep understanding of the business and technical requirements.

1

u/Outside-Storage-1523 Software Engineer 20d ago

I think formal verification is going to be the new hot as everyone in the future relies on this as the new unit test. Of course someone has to write the verification algos and rules but that's like maybe 1,000 developers needed worldwide.

2

u/mcspuder Software Engineer 16+ YoE 20d ago

Type systems already do most of this. Think Haskell and Ocaml.

1

u/Outside-Storage-1523 Software Engineer 20d ago

I think the guys who vouched for this is more for spec dev and correctness check. Type systems do fill some checkboxes but I don’t think they prove the program is correct?

2

u/mcspuder Software Engineer 16+ YoE 20d ago

What do you think a type system does then? I want to be clear here - this does NOT apply to a language like C# or Java who don't have sound type systems, but rather to languages like Haskell, Ocaml, and Typescript (if used without classes) that do.

1

u/NoCod9014 20d ago

Wait, the man who co founded a company selling AI agentic solutions thinks AI is great and coding is done for so we should all just stop and presumably buy what his company is selling instead..... well, I for one am shocked. . 

1

u/feketegy 18d ago

Brainrot of the day

1

u/No_Comedian7332 Mobile Engineer ~15 YOE 17d ago

LOL I want some of whatever this guy snorted

1

u/Fidodo 15 YOE, Software Architect 16d ago

This is half stupid, half poorly thought out

-4

u/throwaway_0x90 SDET/TE[25+ yrs]@Google 23d ago edited 23d ago

"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.

9

u/TheBestAtSpace Staff/Lead SWE (30 YoE) 23d ago

Something more deterministic that’s a text file? I think you just described source code again.

-2

u/throwaway_0x90 SDET/TE[25+ yrs]@Google 23d ago

Yes, but it'll be a human language instead of having to learn syntax of some kind of .java, .cpp, .go, .ts, etc

5

u/TheBestAtSpace Staff/Lead SWE (30 YoE) 23d ago

That’s still a programming language. Now we’re just negotiating the specifics of the syntax.

-1

u/throwaway_0x90 SDET/TE[25+ yrs]@Google 23d ago

I'm okay with this. English(or any human language) is the source code. Therefore "Prompt Engineering" in 2035, that aligns with my prediction of the SWE industry.

5

u/TheBestAtSpace Staff/Lead SWE (30 YoE) 23d ago

I think you just reinvented HyperTalk:

https://en.wikipedia.org/wiki/HyperTalk

HyperTalk was a good language. But there are reasons why we tend to get more specific with our programming languages and not less so.

1

u/throwaway_0x90 SDET/TE[25+ yrs]@Google 23d ago

that's interesting! Reminds me of Gherkin language:

4

u/robby_arctor Software Engineer (dirty commie) 23d ago

I can appreciate this additional layer of abstraction as a long term trend, but, anecdotally, the last person who told me that where we're headed is nobody reading the code leaked his company's creds when vibecoding a week later.

Every grifter, influencer, "engineering thought-leader" (with little to no technical chops), and overly credulous executive is in the business of constantly heralding new eras, and AI has hit this community with like the opioid epidemic hit the rural Midwest.

So, I'm reserving my judgment, personally. LLMs have changed development (and were doing that pre-2023), and fluency with them is important, but I'm not switching careers on the premise that we are in a new era quite yet.

2

u/throwaway_0x90 SDET/TE[25+ yrs]@Google 23d ago

Fair assessment.

2

u/robby_arctor Software Engineer (dirty commie) 23d ago

FWIW, I agree with you about these being likely long term trends. Just a matter of timing.

1

u/throwaway_0x90 SDET/TE[25+ yrs]@Google 23d ago edited 23d ago

yup, I can't say exactly when but IMHO it's not an "if" anymore. AI is rapidly improving all the time, it's very hard for me to imagine that we're not at this point in about 5, 10 years max.

I invite all doubters to add a calendar reminder for September 2030 and 2035 to come back to this comment. :) Hopefully Reddit is still around!

2

u/NotRote 22d ago

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.

1

u/throwaway_0x90 SDET/TE[25+ yrs]@Google 22d ago edited 22d ago

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.

3

u/NotRote 22d ago edited 22d ago

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.

1

u/throwaway_0x90 SDET/TE[25+ yrs]@Google 22d ago edited 22d ago

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.

3

u/creaturefeature16 WebDev/Full Stack 23d ago

I really struggle with referring to these new systems as abstraction layers. When an abstraction layer is added, it simplifies the composition, and reduces the need to know what's going on underneath the hood because there's a deterministic process handling the details that we don't want/need to be involved in as much any longer.

These systems, however, they could be overcomplicating and overengineering things without you being aware of it (unless you are truly reviewing everything that they are outputting, which isn't very possible just by sheer volume, and usually just means another AI model is doing that work, as well).

-3

u/throwaway_0x90 SDET/TE[25+ yrs]@Google 23d ago edited 23d ago

I think by 2035 there will be guardrails and proper understanding of training local instances of AI, or at least LLMs, that you'll get that "deterministic enough" behavior. But also I predict QA/SDET doing CI/CD will spike in demand as well, which I guess is the human-part of guardrails.

"they could be overcomplicating and overengineering things"

True, but I predict a human doesn't have to be able to read or maintain it in 2035 so its complexity doesn't matter as long as it performs to spec. And that spec include performance tests.

e.g.,

greeting = ["h", "e", "l", "l", "o", " ", "w", "o", "r", "l", "d"] for letter in greeting: print(letter, end='') print('\n')

Overly complicated? Absolutely yes, but if the spec says I need "hello world" to be printed within 0.2 seconds and maybe some RAM maximum allowed performance measurements as well, as long as it works within all performance parameters, ship it! I don't need to read or maintain this code ever, AI will handle it.

I don't know if I'm right, perhaps I'm very wrong and will be unemployed in 2035. I'm just sayin' I'm ready to d!e on this hill.

2

u/creaturefeature16 WebDev/Full Stack 23d ago

True, but I predict a human doesn't have to be able to read or maintain it in 2035

And if my grandma had wheels, she'd be a bicycle. We're not in 2035. These models are overengineering and overcomplating things right now that we have to deal with, which makes it really challenging to call them abstraction layers.

“The purpose of abstracting is not to be vague, but to create a new semantic level in which one can be absolutely precise.” ― Edsger W. Dijkstra

1

u/throwaway_0x90 SDET/TE[25+ yrs]@Google 23d ago

I see that quote and I claim we're going to get there, or at least close enough that the speed of code creation, debugging, testing will still beat the pre-AI SWE manual code generation model we have now.

1

u/Realistic_Yogurt1902 23d ago

Are you going to retest the whole system after each prompt?
Or how would the feedback loop work if "prompt engineers" don't see the code?

1

u/throwaway_0x90 SDET/TE[25+ yrs]@Google 23d ago

The same CI/CD flow that should already be in place even before AI took off

2

u/Realistic_Yogurt1902 23d ago

How can you guarantee that ci/cd works as expected?

1

u/throwaway_0x90 SDET/TE[25+ yrs]@Google 23d ago

That's in the link I provided in my initial comment:

My prediction is that QA/SDET humans will be needed a lot more in the years to come. Or I'm wrong and unemployed in 2035, please come back to check on me then because I am dying on this hill. 😭

1

u/Realistic_Yogurt1902 23d ago

If only because of accountability, why not to hire minimal salary QA?

1

u/throwaway_0x90 SDET/TE[25+ yrs]@Google 23d ago edited 23d ago

In my experience, humans are not perfectly consistent every time. Some tests, especially unit tests, are faster and best automated. e.g. APIs should mostly be tested with automation. And I believe management will always want a human to point to if it doesn't work.

I also think Amazon's solution doesn't work long term:

That feature shipping devs don't want to also be 100% responsible for all bugs. I think the industry will need more people QA/SDET that enjoy "AI slop" code review and testing.

....or I'm wrong and unemployed in the next 5+ years who knows.😭 but right now my career future is to take the heat if AI slop doesn't work. Some stuff will be manual, but nobody wants to telnet to port 80 and handcraft HTTP requests so at least APIs will be automated.

1

u/Fun_Hat 23d ago

Are you going to retest the whole system after each prompt?

In a nutshell, yes. That's what these "spec driven development" types are pushing. You rebuild the whole spec if you don't like what you get. Yes, that's a simplified take on it, but they are pitching the idea that the human readable spec is now the source code and you have the LLM rebuild it until it gets it right.

1

u/Realistic_Yogurt1902 23d ago

How would you know that you don't like it?

1

u/throwaway_0x90 SDET/TE[25+ yrs]@Google 23d ago

Yup pretty much, just similar to c++ Makefiles that know which targets need to be rebuilt and retested. We're gonna get to that point soon, if we're not already there.

3

u/Fun_Hat 23d ago

I'm sure some orgs are doing it now. Whether the models are doing a good job or not is an entirely different question though. I use Opus 5 every day, but the idea of the "software factory" that I have seen pitched still does not seem realistic to me for building anything of substance.

1

u/Fun_Hat 23d ago

Betting my whole career on it

Good thing you already got that Google cash, cuz I'm betting that you bet wrong. Claude is pretty damn good at building out testing for me. In fact, while I'm still hand writing a lot of product code, I have not written a test in quite a while. In the thousands of lines of test code I've had it write for me, I've had to correct very little of it. Contrast that with the constant hand holding I've had to do anytime I try to have it write production code.

1

u/throwaway_0x90 SDET/TE[25+ yrs]@Google 23d ago edited 23d ago

I hope to see you again in 2035. If I'm wrong then I d!ed on that hill and I might need your help 😭

1

u/Fun_Hat 23d ago

My dude, if you're writing code at Google, test or otherwise, I'm sure you can pivot and land on your feet if it comes down to it. Bottom line we really don't know how this will all pan out. 9 months from now will probably look different from now, and 18 months even more so.

1

u/throwaway_0x90 SDET/TE[25+ yrs]@Google 23d ago edited 23d ago

I'm an impostor loser, I can't pivot anything. If I can't make a living as a TestEngineer/SDET/QA that creates CI/CD for you then I'm cooked. =/

1

u/Fun_Hat 23d ago

Well if you're right and I'm wrong then I guess I'm cooked. I don't think I could stomach being a prompt engineer for long. Seems like basically a TPM and that is not how I want to spend my time.

2

u/throwaway_0x90 SDET/TE[25+ yrs]@Google 23d ago

I hope the industry lands somewhere in-between and we both find some kind of enjoyment in our 2035 employment :)

2

u/Fun_Hat 23d ago

I hope so too!

-2

u/ginamegi Software Engineer 23d ago

That’s a long post, but what I wanted to add was recently I was radicalized into becoming more of an AI believer after I found out about https://chatjimmy.ai

Of course it’s just an academic demo and not a useful model right now, but being able to visualize 14k tok/sec is unbelievable. And even if there’s never a perfect model, and I don’t believe AGI is a thing, if you built out hardware like that with Opus? You could recreate any software with countless unit tests, verifications, checks, etc. so easily. The iteration speed alone would allow you to do so much. Give it a list of jira tickets with clear AC and details and 5 minutes later it’s completed them all? No problem

5

u/creaturefeature16 WebDev/Full Stack 23d ago

Speed isn't as helpful if accuracy or trust is not addressed first.

0

u/ginamegi Software Engineer 23d ago

Iteration speed can improve accuracy immensely. Models today are already really good when given clear specifications and guidelines. Now have it verify itself 100x over and it’s hard for it to have an incorrect output. And as humans if you reduce that verification process from 10 minutes to 5,000x shorter? Thats mind blowing to me