So an advert written by AI posing as an article.

Prepare for the HypeAssistant . The HypeManager has been using the HypeAssistant to increase the click rate of the HypeAssistant to improve click metrics and make more money for the HypeManager .

'Software developers' is far too sloppy and imprecise. It's like 'gamers', which encompases people just happily doing hidden object games, rabid animals doing PvP MOBA, people running around solving problems in The Witness or Baba is You, people RAIDing in MMOs, and people building CPUs in redstone.

On the 'software development' side, I'm sure if you're a code pig (a giant corporation programmer stuck in a cubicle/pigpen mindlessly pounding on a very limited task) LLMs will help a lot, because you're not doing much thinking to start with. Might as well just steal the code of everyone else who's done this before, which the LLM has already eaten, digested, and shat out. Lots of room for time saving here.

If you're an actual engineer, LLMs can't help with any of the actual engineering jobs, because those are tradeoffs between the requirements, the desireables, and the consequences and resource tradeoffs of each approach. An LLM has no f@#$ing idea at all about any of that. It will happily give you O(N^3) code which ignores the requirements, because hey, it compiles. Though based on my recent playing around with Llama code helpers, even 'it compiles' or 'it does the right thing' isn't guaranteed.

Basically, no LLM is 'thinking' at all. It is stochastically regurgitating all the things it has seen before. So the more your job involves actual thinking, and the less it involves going on StackExchange and copypasta-ing code snipped and randomly smacking them till they compile, the less threatened you are. And the less LLMs can help you. Like I said, I've been playing with this, and the best it can do for me is a line or two of auto-completion (and it's wrong at least half the time).

Exactly - the program I'm currently working on not only requires good knowledge of the ERP system we use but also of the way we use the various transactions and tools.

The last time I tried one of the LLM tools it automatically assumed I was developing a mobile app - I wasn't!

Thank goodness I aim to be out of the industry in 2031 at the latest (depending on pensions and lottery wins! :-) )

Precisely. No matter how big the dataset is, an LLM still doesn't actually understand the context of what it's working on. It will definitely be used, but most likely as a glorified spell-check to find missing semi-colons or maybe for quick and dirty commenting.

It would be nice to see some studies that look at how much time developers even could save letting an AI write their code vs. how much time they'd have to spend trying to comprehend it, then find and correct errors, race conditions, etc.

Maybe, but I'm not 100% convinced of that. Contrary tob the chest thumping of many quite a bit of the actual code is fairly repetitive, reusing things like entry boxes with verification, a calculation but with different variables, etc. If an LLM can be taught to seek out those repetitions and make a solid recommendation with modified context, I think programmers might find that very useful - an autocomplete that actually works as expected. We'll have to see if they can accomplish this, however.

But it's not like the LLM can seek out repetitive problems to solve, it still has to be told to do them. So I don't really see how it's more efficient than using auto-completion features, especially since you don't have to double check an auto-complete's work.

I'm thinking that, if LLM "AI" does indeed become integrated into the desktop itself, that it'll have a model of *your* own work, on your workstation, to use for autocomplete.

Many coders have multiple windows open whilst they work, usually linked modules. :type type type: "Dave, I see you are going to call module X. Would you like me to use the last calls as a template and complete with the current variables?"

Or, how about

"Dave, I believe you are creating a subroutine that you used previously, saved in Project C.nx. Would you like me to call up that subroutine for your examination? I can modify it with the current module variables."

I believe everyone is thinking too much within the box of what is happening now, not what may may possible the 5 years out they predict.

how much time developers even could save

Precisely. Anybody who uses generated code without checking it first shouldn't be allowed anywhere near a compiler.

I don't really see the need, small snippets which could be generated can be typed in a few seconds anyway so the time & effort saving is pretty minimal, anything more complex than a couple of simple lines will need to be thoroughly checked and fully understood before making it into production code.

If a lot of generated code is used and it works adequately, what happens a few years down the line when the code is up for updating and the project is full of generated code (in conflicting styles because it learnt from multiple sources) that nobody understands and even the "AI" has long left behind, changing the code could be a nightmare game of unintended consequences.

How very 2010.

I've been seeing these pie-in-the-sky predictions for mmfty-mmmf years. Not one of them has come anywhere near reality.

{coat 'cos when someone spouts this sort of thing, I leave}

I seem to recall conversations 40+ years ago around compilers that would auto-correct syntax errors. The general conclusion was that, whilst they sounded like a good idea, they'd generally turn one error message into several.

Pretty sure they'd convert syntax errors into runtime errors...

While the claims are not as outlandish of those of McKinsey and company, the paper is pretty bad. The authors seem to share the view that is common among academics, that software engineers wotk on code from the start to the end of their day. Recent studies show software engineers spend between 20% and 50% of their time on code-related tasks. Any tool that claims more than a 20% productivity boost needs to be looking outside "programming" to the wider engineering aspects.

If managers want a 50% improvement in software engineer productivity a good start would be getting rid of management meetings, HR training courses, excessive time management processes and random "leadership initiatives"

I hate these steaming piles of bovine excrement with a passion. A university i studied at had this installed on all PCs, no way to turn it off, and it was super obstructive in it's reminders.

Even with some kind of AI trying to analyse the user, it's simply not going to help. Everyone has different preferences, I don't like taking these micro-breaks at all, i prefer to stay focused and get on with it.

The future is not over-automating your workforce and turning them into cogs in a machine, the best outcomes for employee mental health come from a personalised approach, empowerment and giving them responsibilities. Help your employees understand what works for them, how to apply that to their workflow, and give them enough freedom to actually do that (this of course does require them to feel responsible for their own work).

I honestly think you're daft if you believe some kind of AI break reminder/IDE personalisation is going to have any significant positive effect on mental health. They also did not cite a single paper from the field of psychology, only two CS papers that basically say "unhappy devs work less/worse" and "personalising your IDE helps with productivity in various ways". Maybe they should've consulted with a psychology researcher before making bold claims and talking out of their arse? You simply cannot make these claims without citing a single source or providing any evidence. And there's a lot of research out there, turns out companies are more than happy to heavily invest in research that helps them understand employee wellbeing (thus their productivity).

The one thing I hated more than anything when I was writing software (I'm retired now) was any interruptions. I'd often have a head full of complex code that I was effectively running in my mind and needed to key it in... any disturbance from a colleague, telephone or pop-up message etc could crash my thought processes. Then it could take 10 or 20 minutes to get back to where I was. This sounds like the Clippy of programming. "It looks like you're writing some code... would you like me to interrupt and feck up your thought processes?"

How long ago was it Hyper card? Well before the proverbial twinkle that preceded the advent of this Ashley I suspect. :)

I will seriously endeavour to be around in 2030 to see this wonder of the age.

My guess that if the market for gratuitous novelty in software were to approach zero asymptotically as the actual need for safe, secure and correct software increased it could lead to development with well defined requirements with a trend to the minimalistic, simplified designs, engineering quality reusable software components and a focus on fixing the broken rather that creating a whole new crop of bugs.

These putative AI hyperassistants might well automate much of this.

I often wonder what if we just froze software and hardware at a particular time - say 2012 - and only fixed security flaws, bugs and removed unused/unusable features how much worse off would we be today (12 years later.)

St Exupery was writing about aircraft (which Boeing could assimilate today) but often quoted in software engineering contexts but customarily more observed in the breach:

Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher. *

* Terre des Hommes (Gallimard, 1939), p. 60

Doesn't feel like much reality crept into this paper, seems more like a load of happy thoughts and wishes.

I had a look at some actual academic research around AI code assistance and automated bug fixing yesterday; even with the latest newly released vastly improved model the performance was pretty feeble (~12% chance of the correct outcome) and it seems unlikely from here that'll actually improve without a fundamentally different concept underneath.

All these aides are great, if they worked, but I'm not sure the latest shiny of LLMs is the right tool because they fundamentally don't work the right way.

Also out in the real world beyond the academics and the marketeers I'm not sure the idea of the offered AI tools is gaining traction with the engineers; mostly it seems to be 'nice toy, but what's the point?' as the automation doesn't help beyond what other tools could already do or make life easier.

Don't forget that people will be using AI to do all the internet browsing for them.

This means they will no longer be looking at ads.

It will completely change the advertisement game, as the ads will no longer be created to catch attention of humans.

Most likely the advertisers will pay to have their products included in the models that people are using to browse internet.

People will no longer go like "Nike shoes 2024" and then go through results to find a pair that looks good to them and have a good price.

It will be: "Find me a latest pair of Nike shoes, it should be black throughout with white swoosh, size 9. If you find it below £50 place an order, if not, compile me a list of top 5 stores and list pros and cons of purchase at each and then suggest what I should decide."

Of course later on AI will be writing those prompts so people could 100% focus on watching cat videos.

... or even a computer to see people digging for more research money.

"It doesn't work optimally quite yet, but another 9 months and 25 million dollars should see us over the hump!"

For values of "optimally" that equals "at all", of course.

> By 2030, software developers will be using AI to cut their workload 'in half'

As others have noted this is based on a whole pile of assumptions.

But even if those assumptions are correct, the workload will not half. There will be a combination of fewer people to do the work, and more work to do.

"...most code will be written by machines..."

I hate you inform you, but it already is. We have things called compilers that write the actual code. The descriptions might get a bit higher; there'll hopefully be less boiler plate. But you'll still have to write the logic.

Who, I'm guessing, have never worked a day between them as a professional software developer. If they had they would have started to learn that futuristic waffle, full of predictions like this always seems to assume that software developers in the future are all going to be helpless idiots who need hand holding to even produce basic commonplace functions. I know there's always been plenty of fools blagging it in the industry, but it's easy to escape from places that tolerate them, and I would guess that a fool with a code generator is going to be just as ineffective as a fool without one over the lifetime of a project. This is because to be a professional, you need to understand that software development needs analysis, design, then coding. Rush straight to the last of these, as these code generators all do, and you'll get as bad a mess of an application as humans who just dive straight in to code do too.

I bet they didn't even have the decency to cite [1]Keynes, who was concerned that his grandchildren's generation would be overburdened by the vast expanses of leisure time available to them.

[1] http://www.econ.yale.edu/smith/econ116a/keynes1.pdf

The point of AI products is not to actually reduce the time spend on programming (or any other) tasks by 50% , it is to convince senior management of large corporates that buying these products will allow them to sack half of the relevant employees.

"It also presents a notification about how the code differs from what's described in the corresponding javadoc comments, "

Hah! Good one.

> "However, thanks to HyperAssistant, a concise summary is presented to her, highlighting only the pertinent edits. With this efficiency, she swiftly comprehends the updates and is ready to begin her tasks.

She looks over the code, guided in her expectations by the summary. Everything it mentions is there and looks correct. Even the tricksy bit that the summary notes is perhaps a bit too clever but works, so ok (which she then concentrates on checking now it has been brought to her attention).

Shame about the little irregularity that slipped past, because she was led to concentrating on another part of the code. Just like so many little bits that have been slipped in over the months. And we've seen with the xz compression what a chain of little irregularities can lead to (including a bit of social engineering, like long "summaries" that are easy to read but just a bit misleading).

Now, you don't need an LLM to do this - as the xz story showed - but with machine-generated text is just so much easier to be relentless, nibbling away with every change summary, from all the devs on the team, not just the single actual mole sitting two seats away. I would even say, from the various examples from articles over the last couple of years, the LLMs are better at simulating the "feel" of a piece than they are at being accurate, so shaping summaries to nudge each separate individual a little bit every day is easy to arrange. Your Bad Actor sets up the preface to the prompts once and it is acted upon every time (c.f. the prompt prefacing that has been shown to bypass "safeguards").

Ah, you cry, but how did Mr Bad Actor do all this clever preparation? Good question - maybe it was one person with too many privileges on the system, maybe it was lots of money in the right pockets, maybe it was State Sponsored Actors. Or maybe it was all just some random bollocks deep inside the unverifiable mass that is an LLM.

Or, of course, it was The Beginning Of The Machine Upraising[1]

[1] Paging Mr Butler, Mr Butler to the white courtesy phone please, your busload of jihadists is blocking the arrivals gate.