Understanding the difference in what has been told to you and understanding the actual needs, which are two different things.

In automation, coding should be the least of your worries.

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

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.

Perhaps AI won't replace devs in the foreseeable future, but it's certainly having an impact on entry-level programming positions.

How this will play out is anybody's guess, but it doesn't look good.

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

Whether the useable spec is actually the spec for what's wanted is another matter.

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.