AI can't replace devs until it understands office politics Whenever I read the news these days, I see the same warning to developers: Watch out, AI is going to replace you. I’m not buying it and wonder why so many have fallen for the trope that the machines’ first target will be those who created the machines? Is it ironic wishful thinking? Or a misunderstanding of what programmers …
If you're able to tell an AI exactly what to write you've already done by far the hardest part of development - you've figured out what the requirements are and translated them into something you can describe in human language.
For any experienced programmer if you give them exact requirements, i.e. basically pseudocode in English (or your human language of choice) they could rip out pages and pages of code per day.
In the real world you rarely get that, usually the requirements are ephemeral and ever changing or you reach a point where you can't refine the requirements any further until there is something for the userbase to start poking at so there's no choice but to start writing code. In an ideal world that "let them poke at it and refine the requirements" version would be your first draft, and you'd use it as a way to further develop requirements from people say "I'll know what I want when I see it", and you'll throw it away and write the "real" version after.
There is no need to give it pseudo-code, or even an algorithm. You just describe what you want and the AI fetches up a solution which has its origins in work done in the past by a human.
The AI figures out how to solve the problem and meet the requirements.
As a user of AI, you should be able to read and understand the output and know that it serves the purpose and how it integrates into your wider project. It is truly good at this and some of us, when coding, do enjoy figuring stuff out ourselves and coming up with a solution - but sometimes when pushed for time it does come to the rescue. You can save the good bits for yourself if you want, or even challenge AI to come up with something better by whatever metric. It doesn't just get on and do stuff, it needs a coder to operate.
The modern stockingers are quite verbose in the coding industry, I notice many other disciplines are embracing AI and making good use.
"The AI figures out how to solve the problem and meet the requirements."
That's not how LLMs work. Fundamentally they do not analyze the problem nor check the generated code against the requirements. Rather, given an input text they generate code that a statistically plausible expression of that input text. "Plausible" here does not mean "likely to be correct," but rather "likely to _appear_ correct."
LLMs _always_ hallucinate. Occasionally, those hallucinations happen to match reality.
"You just describe what you want..."
That word "just" is doing a lot of heavy lifting there. Getting actual requirements from users is a hard task much of the time, and sometimes you just have to develop something making assumptions and then let them play with that, and then tell you how they want to change it. It's a kind of horse trading. Business Analysts don't always give you the detail you need. This is the hardest part of the job, not the actual coding. I'm talking about business applications, which I think are the vast majority of coding jobs. If you are making a ballistic rocket guidance system you probably have a tighter spec and the coding part is harder.
For what it's worth, I work in a dev-adjacent role. I have had to dabble in very basic code but while I'm really good at designing systems, I've always been incredibly weak at writing syntax.
What LLMs have allowed me to do is cover that weakness and get some rather cool projects out the door without needing dev interaction.
There are things I refuse to do (and I use LLMs there as well, to help me organise the thoughts in my head and generate a coherent brief).
The single most important thing to understand with using an LLM is your own limitations. You can raise your ceiling in an field, but it's absolutely not the same thing as being an expert in the field yourself.
You are talking about a wider system, and I am talking about solving smaller logical problems within the system.
For example: "write C code to draw a procedural stars with a variable for the number of points" put this into chatGPT and it will do exactly that. It will also add in the stuff to initialise SDL and create a working mini app. I would just extract the bits I need. I've had no need whatsoever to try to define how the code will go about solving the problem.
This is the fundamental difference between LLM-usage horror stories and success stories.
A vague, poorly thought out brief with a wide scope is doomed to failure.
A specific, considered request within a narrow scope is pretty much guaranteed to succeed, as long as there are no external factors that make the task impractical/impossible.
As somebody who often has trouble getting thoughts to paper, I've had a lot of success recently chatting through existing processes and turning them into usable docs with the help of ChatGPT. It's made a huge difference to my ability to get my processes written down, compared to sitting there looking at an empty word doc.
> I've had a lot of success recently chatting through existing processes and turning them into usable docs with the help of ChatGPT.
Good for you, glad things are working out.
But from the outside p.o.v. what you are doing sounds like super-ELIZA; obviously, bigger than ELIZA, with more responses - but then, ELIZA is (in current basic coding terms) gloriously trivial. Is something in between that and the costly LLM going to be suitable, and cheaper? Who knows, nobody is looking at that, use the LLM.
Of course, that use of the LLM is what we used to do by talking to people, which had the result that there were then two or more people who understood what is going on inside the processes, along with all the whys and wherefores that don't get into the resulting documentation - at least, not until a reviewer or user asks for them. Whether this sharing of institutional knowledge is worth the cost of not using the LLM is a separate question.
The two main use-cases I'm working on are creating code systems, with feedback from the model about implementation options and documenting those processes or documenting external processes.
I don't know how a less capable LLM would be with these, but even though they're not complex pieces of code in the grand scheme of things, I am running close to 4o's limits on some of the scripts we're generating.
On your last paragraph, I can definitely see where you're coming from, but there is a flipside. In this situation, there is a single person's (billable) time that's being used in the conversation. The second person is lost (but in my role there never is a second person anyway), but I'm no longer requiring other people's hours to work through these systems step by step.
> write C code to draw a procedural stars with a variable for the number of points
There is going to be plenty of code around for the LLM to have read which already solves that sort of "problem" - there is no need at all for the AI to do anything along the lines of:
> The AI figures out how to solve the problem and meet the requirements.
Your star-drawing code is a perfect example of your own previous sentence:
> AI fetches up a solution which has its origins in work done in the past by a human.
In other words, you are using it as more of a search engine than anything else - ditto the:
> It will also add in the stuff to initialise SDL and create a working mini app.
It is just spitting out the pattern it has seen so often (and which it has probably had reinforcement is a "good pattern to repeat" by its users/devs/trainers).
But then you:
> would just extract the bits I need
So it isn't actually the perfect pattern for you, as you still need to massage the results.
> As a user of AI, you should be able to read and understand the output and know that it serves the purpose and how it integrates into your wider project.
Which is precisely the attitude you also need to take with the results of StackOverflow, or random Github gist or any other result coming from Bing/Google/...
So you are using the LLM as a search engine - great for you.
The question still remains: which gives the best bang for the buck, using the LLM or Google? Oh, not just from your (current) perspective, but from everyone's (energy etc requirements, monetary - say, when they start to charge end-users based upon real costs of dev & running).
Finally:
> You are talking about a wider system, and I am talking about solving smaller logical problems within the system.
The goals of AI applied to creating systems used to all about "the wider system", because that is where the biggest issues lie (it is a bugger to have a GPF, it is life-ruining to not know how to calculate profit/loss needed to run a Post Office branch).
What a shame if the best these LLMs can do for you is the piddling bit.
Your example sounds a lot like how we used to use documentation, back when libraries came with such a thing. We'd search the docs for an example that wasn't very different from some of our requirements and we'd yank out the bits that looked useful. Then we'd massage the code to meet our wider requirements, which (as noted in previous comments) most certainly would not be clearly specified anywhere but would instead be distilled from a mixture of real-world experience, conversations with customers and domain experts, and the common sense that comes from being a real person.
If AI can generate plausible documentation for the very many libraries that sadly don't have any at the moment, perhaps it isn't completely useless to a programmer after all.
In my experience, the best way to get a correct description of what a new software system must do and how its interfaces (to both people and other computer systems) must be structured is to start by collecting a group of people who understand what the new system must do: those who will be using it as well as those who will be designing and implementing, it in front of a *large* wall-mounted white board and enough felt-tipped pens. The first task is to ensure that everybody understands the notation that will be used to diagram the new system. That done, its best to nominate one of the designers as 'sketcher in chief', to keep the whiteboard from becoming a scribbled mess, and then everybody contributes to making sure that the whiteboard becomes a complete description of the data that the system needs to handle and its internal relationships. This stage of the design is complete when everybody agrees that all necessary data entities and their relationships have been correctly captured on the board.
At this stage, and not before, it is appropriate to specify the system's human interface(s) and the way people will interact with them. I've found James Martin's "Design of Man-Computer Dialogues" to be very useful here. It may be old but it is still well worth keeping as a reference because it describes a large number of ways to represent data and, equally important, the advantages and disadvantages of each.
This is the way we specified, designed and built Orpheus, the BBC's Radio 3 Music Planning system, which manages probably the most complex database I've ever worked with, because it contains catalogues of all the performers, composers, and separately playable pieces of music that Radio 3 has broadcast since 1982, as well as the complete broadcast history of every musical piece played on Radio 3 since Orpheus went live.
Other projects I've been involved in since then have used similar approaches and by and large have been similarly successful: others, which used other design principals, have been less so.
Requirement capture was always fun :) Talking to the manglers who were requesting something you'd get random weird answers because they won't be the users, so i used to interview the people who would actually be doing stuff to see what it was they did, what they found time consuming or difficult, what they wanted the software to do for them.
I'd end with 'If you could ask for anything what would it be?' Usually the answers would be stuff that was impractical or impossible, which is the point of the question really. But one time it was 'ummm... your phone number?'
That one I could do. :D
"you reach a point where you can't refine the requirements any further until there is something for the userbase to start poking at"
This is where fast prototyping comes in. Working with an RDBMS (Informix) it was easy enough to throw together a table or two based on what I thought were the data needs for what was required and have it automatically generate a default screen based on that. The users could then try it to see if it represented what they'd been thinking about. It wouldn't be pretty or have any business logic behind it but it could be done and amended very quickly. When they were happy with it it could be something more and less than a final spec - a working sketch, in effect.
That is maybe something that an LLM could produce.
The first time in my career I heard the siren call of industry promising to make my role redundant was UML.
Many more silver bullets have been fired since then of course, but at least with say, UML you could theoretically regenerate the whole thing from updated specs. Vibe-coding? not so much...
The first time for me was FOCUS (for online computer users). Followed by
1. Case tools
2. Entity-relationship designers
3. GUI interfaces to various admin tools
4. Oracle appliances (The sales droid said: "Just fill in the host and database names and your cluster is completely set up"). We happened to have one of those appliances in our computer room that had been unpacked. I regret that I didn't ask him on the spot: "We got one of those, lets set up right now, its that easy correct?"
5. More recently: Devops, CI/CD, WS/XML, Microservices, and too many others to remember.
All of these just made more work for me.
Devs WILL all be replaced by AI. A bit like COBOL programmers have pretty much all been replaced by devs usng more modern languages.
I had this conversation at work and some folks seem to think we'll all be out of the job within 18 months... because AI.
My feeling is this process will take decades, and by that time we'll need a lot more BAs and fewer actual programmers.
So, it's going to happen right? It's just the timescales we're arguing about.
I'm still trying to convince my kids to learn to code, because I think they'll have a decent and rewarding career for many years yet.
Also, using AI as a tool can help me develop better code which is more secure and has great test coverage. But for now, it's just another tool.
"I'm still trying to convince my kids to learn to code, because I think they'll have a decent and rewarding career for many years yet."
If they go into coding because their dad persuaded them rather than something different that they'd rather do then they may have a career in coding but it won't be decent and rewarding. We all think that what comes naturally to us is equally accessible to everyone. It isn't.
I agree totally. That's why I said "convince" instead of "coerce". They are strong minded and do their own thing anyway. One of them is already in IT support and enjoys coding a bit, another is currently playing with The Odin Project https://www.theodinproject.com/ and seeing if they enjoy it. Another one has zero interest in computers. They are all smart and way better at maths than me. But if they choose to do something else that they enjoy I will support them all the way.
I just feel that if you enjoy goofing around with computers, then it pays pretty well and you can be a lot more autonomous than other jobs. And there's probably going to be plenty of work for a good time yet, which was the point of the article. At the very least, I would not advise someone to avoid it as a career because AI.
It's not just developers that will not be immediately replaced with AI.
As a former second line desktop support person I can't see a self-propelled wheely bin rolling up to a user and saying "I hear you have a problem." When I was doing desktop support a lot of the time the user did not really know what had gone wrong just that their PC had stopped working. Knowledge of the system is necessary but people skills are just as vital. Listening to what had happened, working out what to do to fix the problem and even taking the PC back to the workbench to sort out hardware issues are all things you have to do, added to which a good "bedside manner" so as to reassure them that they have not lost all their work are all parts of the desktop support person's toolkit.
You are Mr. Never-Worked-In-a-Bank and I claim my two quid.
Cobol programmers are not only not pretty much all replaced, they are being churned out by Cobol academies the world over.
If your kids want a guaranteed, fairly well paid, coding job - as opposed to a developer role - read up on Cobol.
"Devs WILL all be replaced by AI."
That's a pretty bold statement but effectively meaningless without a date for when you think this will happen. I can confidently state that "California will crumble into the sea" to paraphrase Steely Dan but that may well not be the case until the universe dies.
Now, if you were to state that "Devs WILL all be replaced by AI by 2030." for example then I'm happy to wager several £ to the contrary.
Oh, yes; about every five years a new paradigm shows up that will eliminate programmers:
FORTRAN: Great! Now our researchers won't have to wait for those guys to do whatever they do to make our algorithms work on the computer!
:
COBOL: Hey, now our accountants/bankers/inventory managers will be able to write their applications themselves!
:
DB/2: With just a few simple tables and Natural Language, we can create our own databases!
:
4th Generation Languages: Now we can get rid of all those irritating programmers!
:
GAI/LMM: Now we can get rid of all those irritating programmers!
:
In order to generate a certain number of people who know what they are doing and generally have development in system 1(*), you need those unwashed masses in entry-level programming positions.
So, first you get improved productivity from the current generation of good devs. They put in the hours. They can use the new tools when they are actually useful and can tell when they are spewing rubbish. Then those devs retire with no replacement because you eliminated the only source of new good devs.
You are left with people with no idea how anything works asking some AI to do stuff. It is more like voodoo than technology by now but you may be still getting things done. Your code is AI spaghetti and does not make sense to humans any more, even if they were good programmers. Humans may still think they are making decisions but those decisions are superficial and basically uninformed.
Then something goes wrong.
Why is this different from all the previous technological revolutions? Before, we had lost [to varying degree] the ability to do something ourselves. We made all kinds of dumb and disastrous mistakes using the new technologies. That is normal.
We also had to specialise. The ability to understand specific things became sparser. Recently actual gaps have appeared, where humans still understand the principles but the systems they are dealing with are too complex (chip design may be an example).
And now we will lose the ability to understand what is going on. You might still want to. Unfortunately, it is hard work. Meaning, it is inefficient and will not be rewarded the society.
(*) See system 1 and system 2.
Funny how all the “AI will replace developers” talk seems to come from people who don’t write code. Maybe because they see developers as the cost centre - the interchangeable, working-class implementers of someone else’s vision.
But here’s the uncomfortable truth: AI won’t replace coders. It’ll empower them - by automating the fluff that’s bloated around the job. Translating vague requirements into usable specs. Mapping “stakeholder vision” into actual workflows. Defining what “Done” means without fourteen meetings and three managers in the loop.
If anyone should be worried, it’s middle management. The weekly syncs, status updates, and alignment calls - all ripe for replacement. Developers won’t be the ones made redundant. The people talking about what they do will be.
"Translating vague requirements into usable specs."
And Rick Deckard got clues from a random photograph by saying "Enhance" over and over.
You can't uncover information that isn't there to start with. You can invent things out of whole cloth, and so can an AI (let's face it, with these current AI's, confabulation is all too likely) but you know a little more about the client/end-user (for now, anyway). With human intelligence, your feedback from the client goes into the next round of guesses. With an AI, you may start from zero every time unless the AI is feeding off some kind of record.
> With an AI, you may start from zero every time unless the AI is feeding off some kind of record.
And you have remembered to make sure to pay the subscription to ensure that the copy of the LLM, that you are carefully training with all the info about *your* product, is totally isolated from everyone else's instance. In particular, the instance that Joe Public gets to use for free/low cost.
And keep paying. To prevent that lovely training being slurped up after your project is done, put on the market and taking business. It would be a shame if a competing product suddenly appeared, based upon all your hard work but with a lower subscription than the one you have to charge to claw back the costs of analysis, requirements etc.
If AI can do that, AI can replace my coding job too. AI can't turn vague statements into a spec that people actually want for the same reason that I can't: I don't know what people want until I extract it from them through large amounts of talking. They could try talking that much to the AI and hope that the specs it makes after that process will represent that talking, but the talks I have tend to be much larger than the context window for the larger ones used in most models. Or mine, for that matter, which I work around by splitting up the task into pieces and writing the spec in pieces so I don't have to hold it all in and write it once.
I think the start of your comment is extremely correct, and in fact, more correct than even you think. People seem to think that AI will easily replace whatever jobs they have no respect for, often by misunderstanding how that job is done. A lot of people don't understand how programmers work or what they do that eventually makes the computer do something. The only part of that process they see is those funny documents with punctuation in weird places, so they think that's the most important part of it. You seem to have a similar view of management. Managers mess things up all the time, but that doesn't make their job as simple as you paint, and that means AI will not be as able to do it. As with ours, LLMs will do an excellent job of pretending to do that job if you give it to them. An LLM can certainly run a status meeting. It can't properly interpret that meeting and a long list of other meetings to understand what people are doing, which ones have the strongest skills in which (undefined and flexible) areas, and understand what people like, how to keep the ones you want, which ones you shouldn't have, then execute on all of that. Good managers can and do that, and bad managers will often do some of it.
> try talking that much to the AI and hope that the specs it makes after that process will represent that talking
AI has some advantages. It can listen to idiots all day long; most of us won't. It may even compose polite explanations of why the user is confused (I can't). And (after some development) it can build demonstrators for users to poke-at, and intimately watch their fumbles and guide them in its use.
That won't prevent, say, a sales-app which charges 650% tax (unless one of the testers has intuitive tax skills), and it does not cure tester fatigue (I've seen a user try one query and sign-off, much to her later regret). But AI can reduced some of the drudgery and time-waste.
It will listen all day long, but that doesn't mean the summary it provides us will be useful. For example, one of the ways to make sure the thing shows up in an LLM summary is to make sure it is mentioned many times. The most important stuff in a spec is likely to be the parts that don't need to be repeated multiple times when talking to users. So if the users talk to the LLM the same way they'd talk to us, that kind of important part will probably be the most likely part where errors show up. The talking to users part is important. That's why we do it. If all I needed to do was coddle some idiots, I wouldn't bother talking to them. I need to learn important things that they know and I don't, and if I don't, then I'm the idiot who could not build something because I was incapable of doing my job, of which determining requirements is a part.
Whenever I read the news these days, I see the same warning to developers: Watch out, AI is going to replace you.I’m not buying it and wonder why so many have fallen for the trope that the machines’ first target will be those who created the machines? ..... Mark Pesce
Methinks AI Developers/LLLM Mentors, rather than any particular and peculiar AI itself, are the really ACTive live existential threat to that which and/or those who would doubt or oppose the rise of the machines and their accurate targeting of historical and hysterical anomalies resulting in the elimination of unpleasant and unwelcome enemies and frenemies whether either both traditional and conventional or novel and asymmetric ....... and as such accurate targeting of despicable threats can be practically immediately recognised and shown and felt as universally beneficial ....... what's not to like and accept and support?
Let IT Be. Don't get yourself into a right tight tizzy and start a fight against that which you cannot defeat and which doesn't need to fight back as IT surprisingly quickly renders you to all known worlds as the deluded self-destructive fool and enemy tool embedded within and now easily primed to be held responsible and accountable for the laying of waste to legacy SCADA systems and their inheritances.
Try to learn from all of your past mistakes which has had you do costly and deadly battle for peace and prosperity rather than being led by an Alternative Intelligence of SMARTR Sources able to enable Convenient Unconventionally Overwhelming Forces along another Long Constructive and Instructive March of Brighter Creative Paths.
...but it is going the way of buggy-whips and bespoke automobiles. This is inevitable because the endgame for coders (and organizations that produce code) is producing code that produces code, in the same way that we eventually built machines that produce machines (see "cars"¹, et al.; also "the Industrial Revolution"²; and obviously "AI"³; separately, there's something of an ouroboros here, probably.⁴).
Human labor, be it physical or intellectual is reliably unreliable, terribly⁵ expensive and inefficient, and absolutely begging for replacement. This is not news; it was ever thus. Humans fit best in new and dynamic experimental roles that people and systems and machines don't yet understand. We are the vanguard, not the endgame.
And that means the very best of us will have the options of winning the rare and refined bespoke code gigs, reducing ourselves to being the disposable servants of the machines (see Amazon, et al; also Tesla; also sweatshops, also much science fiction.), or...well⁶...finding some other way to spend our new excess of free time.
Something else will come along. Coal miners became car assemblers, some car assemblers became aircraft assemblers, some aircraft assemblers became rocket assemblers, etc. And while we're waiting or searching for or inventing that next thing, we might revisit ideas like using our vast shared excess of time and technology to help each other out, to lift each other up. Jobs are mostly for money; maybe we need to redistribute that money more evenly so jobs are more about optimized choices than acts of hanging on in quiet desperation⁷.
-------
¹ not the movie, but that's also a good choice
² didn't Mel Brooks do something with that?
³ also not the movie, nor the other movie(s) of the same name
⁴ more figuratively than probably, but it's good to have a hobby
⁵ sometimes involving actual terror
⁶ not an accidental reference
⁷ understood to be the English way, but more broadly applicable if we're honest
This is mostly wrong. The analogy is not to manufacturing things, but to designing them. We build machines to build cars now, mostly, but the cars the machines build are still designed by humans. Programming is not manufacturing work, since it's usually pretty easy to make more of the program you just wrote. Programming is design, and that has not been mechanized just yet. We build tools to speed it up, but so far, none of our tools has eliminated the requirement to think, and programming properly requires thinking.
> . This is inevitable because the endgame for coders (and organizations that produce code) is producing code that produces code,
Also known, variably, as: interpreters[1], compilers, compiler compilers, macros, web page design packages, macros etc etc.
All of which seem to have opened up even more actual programming jobs. Without really killing off the old ones[2].
The input languages get more expressive. Although, for some strange reason every time someone claims their language is "closer to English"[3] the more it is left on the wayside by those languages that take a more rigorous approach...
[1] Yes, interpreters "produce code" from your source code, they just execute the newly produced bit and throw it away - the "produced code" can even be so ephemeral that its representation is just the current state of the execution stack.
[2] What? Well, count how many people needed to use assembler in the 1970s and the count the number today - betcha today's number is larger, even though the percentage is way, way down; and the assembler needed is all the really weird tricky stuff, no getting away with just knowing LD, STO and a couple of variants of JMP!
[3] Yes, English. I can't comment on any system that claims to "be closer to Dutch" or "closer to Greek" because those are all just APL to me.
You may have seen this already, but reading Microsoft's engineers getting hassled by Copilot and having to waste a huge amount of time assuaging it's facile comments and repairing it's stupid code changes on their Github PRs is very entertaining.
That dogfood they're eating clearly tastes like dogfood.
But seriously, 2 observations 1) as the author pointed out coding creates things that have never been created before so finding tracing data is impossible. 2)
So far I have been generating boiler plate. Stuff I don’t want to write that I know have Bennet solved, such as listening on a port. That might be the best use cases for it.
"Because many coding tasks involve routine implementation of plumbing, myriad libraries and automation tools exist to make sure developers don’t have to re-invent the wheel every day."
Oh yes. Whether coding at a high level, or down to bare metal, coding is mostly taking data from here and putting it there. Even Interrupt Service Routines are in that business, mostly servicing a queue of one form or another. Sophisticated Algorithms? Mostly double talk to make the drones think we're geniuses. Genii? I mean we're pretty bright and all that, but brilliance in coding mostly amounts to Keeping It Simple. Which is how I know code was not written by a bright person: it's a bloody mess.
I wonder if AI's will be spaghetti monsters too.
This post has been deleted by its author
This is the kind of stuff I'm reading The Register for (and BOFH of course).
On the other hand, artists are much more negative (to put it mildly) on AI, especially after the Miyazaki case. This is the latest t-shirt design from my favorite cartoonist.
This post has been deleted by its author
> "I spent the first decade of my career writing code, first assembly language, then C and C++"
I spend the first decade of my career *coding* in various assembly languages on various targets, but also *programming* in C and C++.
I am a snob: ASM = coding, the rest in any language = programming.
Using AI to generate code = is not programming.
I get that there's little incentive for most devs to be optimistic about how their future in work might look. But those who are denying that LLM's are a paradigm shift are deluding themselves.
Gathering detailed systems requirements is part of the process that human's need in order to parse complex tasks.
When the context window of an LLM is "your businesses entire codebase and process documentation" theres no need for the middleman. Indeed in some cases where whole datasets can be parsed there's no need for the actual middleware.
I'm not saying that humans won't be involved but there will be far less requirement for human developers in anything but the most complex and poorly defined problems by the end of the decade. Given that the majority of development work is neither groundbreaking or unique this effectively means its likely that the jobs market will flatline stagnating wages.
If anything business analysts and program managers will be ideally placed to run teams of software development agents with the odd human (senior) developer in the loop to verify output.
The reality is that we have developed a tool that does "a pretty good job" of translating business requirements written in english into language machines can understand. It will improve rapidly. You wouldn't encourage your children to go into a career translating books from English to French now would you? Sure, there's still some translators around but its increasingly niche.
Go ahead, try it. It won't work for the same reason that you do, in fact, still have translators translating books from English to French: I could shove the book into Google Translate, or if I have some cash I could use something better. Unlike a few years ago, it won't have so many parts that are incorrect, but it won't be enjoyable to read because it lacks the literary quality the original had. Translators in general have lost jobs and wages because there are many situations where mere understanding is enough, but literature is one of those places where they still do the work.
You, apparently, do not know that. Perhaps you have a similar amount of knowledge of what happens when you take business process docs, written by someone who doesn't really want to do this, and get LLM-written code out. I encourage you to try it. It will help with your experience in one of two ways. If it turns out to work, you'll make tons of money as the person who made programmers obsolete and, as a bonus, you'll prove how stupid I and others here are. Or you'll learn firsthand what the problems are, and if the tools work well enough, maybe you'll be the one to fix them, and if you can't, at least you'll have a better understanding of why we have the views we've expressed.
The real issue highlighted is having those who code and develop able to listen properly to the end users, not just the buyers and waters. Also vice versa.
AI is not going to do that. And the folks with the money won't want either their wants to be wrong, or changed. So end users and receivers of services will be over ruled, and forced to make it work and will not be heard so they just get on with it. . And then when things start to slide, non end users will wonder why and what went wrong, and where did these weird end runs come from and why they are cluttering up their perfect products.
It has always happened and with AI there is another even more inflexible slae driver. "If AI says it, then it must so!" And if unhelpful chatbots are anything to go by, God is our only hope!
"That’s because the main job for a developer is speculative – answering the question “Could we?" and going where no coder has been before in search of an answer."
That might be true for SOME developers but there's a lot (and I mean a LOT) of code monkeys out there who are doing nothing innovative, nothing requiring any sort of thought, interpretation or speculation. People with a "big" job title who are basically just copy-pasting bits of code into different variants of the same basic thing over and over and over.
In my little world of coding the article is about right, but also misses another challenge for AI. Most of the coding is adding/changing existing messy code and undocumented code. So once you have your vague requirements from the "client", you then need to work out -where- and how, and while coding make sure you stick to various conventions (enumerated status numbers), and don't break any existing code or process. The sort of breaking as an example is something that wouldn't be picked up in compilation, you can set the job to status 591. But rather in system processes, pages and filters where 591 doesn't exist, so will never show.
In an ideal world the 20 year old system would have been re-written from scratch in the latest tech many times and well be documented. But it hasn't and isn't and is a mess of old ways, new ways, client changing their mind etc. We don't stand a chance explaining what we need to the AI, and it won't stand a chance giving a working answer.
What we can do though is ask for a regex, or a routine to do something in isolation... but that's not replacing the developer.
