Ask this in 2024 and you got speculation. Ask it now and there is enough evidence to answer properly. The short answer is no. The useful answer is that the job has changed shape, and if you pay other people to build software, it is worth understanding how.
What AI genuinely does well
This is not a small list, and pretending otherwise helps nobody.
It writes competent first drafts of well-defined code quickly. It is good at the repetitive layer of software: forms, data plumbing, converting between formats, the fourth version of something you have already built three times. It writes tests, which is work most developers avoid. It explains unfamiliar code, which makes inheriting someone else’s system far less painful than it used to be. It catches a certain class of mistake on review.
For a working developer, this removes a meaningful amount of mechanical effort. That is a real change and it has already happened.
What it still cannot do
The limits are not where people expected.
It does not know what to build. Your business has rules nobody wrote down: how a discount is approved, which customer gets credit, what happens when a delivery is refused at the door. Those rules live in people’s heads. Extracting them is the hard part of the job, and it requires sitting with the people who do the work.
It is confident when it is wrong. A tool that produces plausible code for an edge case it has misunderstood is more dangerous than one that produces nothing, because the mistake looks finished. Someone has to know enough to catch it.
It does not carry consequence. When a payment is taken twice, or a customer’s data is exposed, the question is not which tool produced the code. The question is who is responsible. Software is a liability as much as an asset, and liability does not transfer to a tool.
It is weakest where systems meet reality. A local payment gateway’s actual behaviour under a timeout, a courier’s undocumented API quirk, a bank’s file format that changes without notice: these are not in the training data, because they are not written down anywhere. They are learned by building and breaking things in the market you work in.
What has actually changed for developers
The valuable skills have shifted, and they have shifted upward.
Writing code fluently used to be most of the job. It is now the part most easily assisted. What has become more valuable is the ability to specify precisely, to review critically, to know what good looks like, and to decide what should not be built at all.
That is uncomfortable for people entering the profession, because those skills were traditionally earned by doing the mechanical work that is now assisted. The answer is not to avoid the tools. It is to use them while deliberately building the judgement they cannot supply, which means reading a great deal of code, and staying close to production systems where consequences are visible.
Developers who understand a business domain deeply have become more valuable, not less. Developers who only translated specifications into syntax have a harder position, and honestly did before this.
What this means if you are paying for software
This is the part that matters if you run a business rather than write code.
You were never paying for keystrokes. You were paying for someone to understand your operation, decide what should exist, build it so it survives contact with real customers, and remain responsible for it afterwards. None of that has been automated.
What has changed is the ratio. Less of a project’s cost sits in mechanical production, and more of it sits in the thinking, the integration and the testing. That is why a proposal that is only a list of features and a number tells you very little. What tells you something is whether the people quoting have understood how your business actually runs, and whether they will still be there when something breaks.
Two questions are worth asking anyone who quotes for software now:
- Who reviews what is produced, and what are they accountable for?
- What happens in eighteen months, when the platform changes and something stops working?
A tool cannot answer either.
How we use it
We use AI tools where they earn their place: first drafts, repetitive code, tests, and checking our own work. It makes us faster on the parts that were always mechanical.
We do not delegate architecture, security decisions, or anything touching money or personal data to a tool without review. Every line we ship is read by a person who is accountable for it, and every system we build is one we expect to still be supporting years later. That has not changed, and we do not expect it to.