Will AI replace developers? A grounded answer from someone who ships software

Short answer: AI will change the work a lot and is unlikely to remove the need for people who can turn a vague business problem into working, maintained software. The typing part of programming is getting cheaper. The parts around it, such as deciding what to build, checking that it is right, operating it and taking responsibility, are not.

What has actually changed?

I use coding assistants every day to build and maintain business software. They are very good at boilerplate, at translating between languages and frameworks, at writing a first version of a test, at explaining unfamiliar code, and at repetitive edits across many files. A task that used to take an afternoon can take an hour.

They are weaker at knowing why your system is the way it is, at spotting a requirement nobody wrote down, and at saying "this is a bad idea". They will confidently build the wrong thing if the instruction is wrong.

Which tasks shrink?

• Writing CRUD screens and glue code.
• First drafts of tests and documentation.
• Looking up syntax and library usage.
• Simple scripts and data conversions.

Which tasks grow?

• Specifying. Turning a fuzzy request into precise behaviour, with edge cases.
• Reviewing. More code is produced per person, so more has to be read.
• Testing and verification. Generated code needs a safety net.
• Integration and operations. Deploys, migrations, backups, incidents.
• Security and data integrity. Mistakes here are expensive and invisible until they are not.
• Talking to the people who use the software. See what forward deployed engineering involves.

Why does demand not simply vanish?

When something gets cheaper, people usually want more of it. Software that was too expensive to build for a small clinic or a single shop becomes affordable, and each of those still needs someone to understand the clinic or the shop. Past waves of tooling, from compilers to frameworks to cloud, made each programmer more productive and the profession grew anyway.

I cannot promise this pattern continues. Nobody can. What I can say is that the narrow claim, that a model alone will take a business requirement to a secure, maintained system, does not match what I see when I use these tools on real systems.

What about junior developers?

The hardest part is the first rung. Tasks that used to train juniors are the ones assistants do well. If you are starting, you need to build judgment faster: read a lot of code, debug without handing every error to a model, and ship something small that real people use. Employers still need people who can reason about a failure.

What should you practise?

• Fundamentals: data structures, SQL, networking basics, how an HTTP request travels.
• Reading code and diffs critically.
• Writing a clear specification in plain English.
• Testing, especially knowing what a good test is.
• Operating software: logs, backups, deploys. The restore drill is the kind of habit no assistant will do for you.
• A domain. Knowing accounting, logistics, healthcare or retail makes you much more than a code generator.

What is the honest uncertainty?

Tools keep improving, and the jobs people do will shift. Anyone who tells you exactly what happens in five years is guessing. The sensible response is to keep learning, keep shipping, and stay close to real problems. That advice was good before AI and it still is.