What happens to software development when AI writes most of the code?
AI can now write extraordinary amounts of software. As someone who has spent around 15 years building for the web, I don't think that makes software development less important. I think it changes where the important bit is.
For most of my career, if I wanted software to do something, somebody had to write the code. Often that was me. You worked out what needed to happen.
Decided how to structure it. Wrote the code. Tested it.
Found the thing you'd broken. Fixed it. Tested it again.
Looked up why something wasn't behaving as expected. Lost an unreasonable amount of time to a missing character. Eventually, you had working software.
AI has changed that process more quickly than almost anything I've seen in technology. I can now describe something I want to build and have AI produce substantial amounts of working code. It can create components.
Write database queries. Build APIs. Find bugs.
Explain unfamiliar code. Write tests. Refactor things.
Read documentation. Suggest architecture. And help connect systems together.
That is a huge change. But I think we're sometimes drawing the wrong conclusion from it. The interesting question isn't:
Will we still need people who can type code? It's: What becomes valuable when typing the code is no longer the difficult part?
Writing code was never the whole job
This is obvious to anyone who has built software professionally. A customer doesn't really want code. They want:
an ecommerce site that takes orders, a membership platform that manages subscriptions, an app that solves a particular problem,
a CRM that supports the sales process, a system that removes repetitive administration, or a website that actually generates business.
Code is how we make that happen. It isn't the outcome. AI is dramatically reducing the effort required for parts of that translation.
That doesn't remove the need to understand what should be built.
AI can be astonishingly good at coding
This is worth saying clearly. Modern AI coding tools aren't just autocomplete. You can give them a problem and they can often:
inspect an existing codebase, work out which files are relevant, write new functionality,
modify existing functionality, run tests, read the errors,
fix problems, and repeat the process. Increasingly, AI agents can work on larger pieces of software with much less hand-holding than earlier coding assistants required.
That means the unit of work is changing. We moved from: complete this line
to: write this function to:
build this feature and increasingly towards: here's the problem, work through it.
That's significant.
But generating code isn't the same as building software
Imagine I ask AI: Build me a customer portal. It can produce one.
That doesn't tell us whether it's the customer portal the business actually needs. Should customers see every order? Who can create accounts?
What happens when an employee leaves a customer organisation? Can one customer have multiple users? Which information can they edit?
Which information is read-only? How does authentication work? What happens if they forget their password?
Where does the data come from? Which system is authoritative? What should happen when that system is unavailable?
What needs logging? What information is sensitive? Those aren't really coding questions.
They're system questions. And someone still needs to answer them.
The bottleneck is moving
Historically, you might have had a brilliant idea for a small piece of software and decided it wasn't worth building. Not because the idea was bad. Because development was expensive.
A developer might need days or weeks to create it. That made the economics fairly simple. The problem had to be valuable enough to justify the development cost.
AI changes that calculation. If something that previously required two weeks of development can be prototyped in a day, a much larger number of ideas become worth testing. The bottleneck starts moving away from:
Can we build this? towards: Should we build this?
That's a very different problem.
This is already changing how I build
I've spent around 15 years working in web development and digital. AI hasn't made that experience redundant. I find I'm using more of it.
Because when AI produces code quickly, I spend more time thinking about: how the system should work, what should happen next,
how data moves, what the user actually needs, which services should connect,
what permissions are required, what happens when something fails, and whether the thing we're building solves the original problem.
The implementation can move faster. The decisions don't disappear.
You can build much more before you know whether it was a good idea
There is a slightly dangerous side to cheaper development. Bad ideas have become cheaper to build too. Previously, the cost of development created friction.
You might spend time validating whether something was actually worth building because committing several months and thousands of pounds focused the mind. Now you can create a surprisingly convincing application over a weekend. That's brilliant for experimentation.
But it also means we can build an enormous amount of software nobody needs. The ability to build quickly makes product judgement more important, not less.
"It works" is becoming a dangerously low bar
AI can generate something that looks finished remarkably quickly. There's the interface. The buttons work.
The database saves something. The login screen appears. You click around.
Brilliant. But production software has a much higher standard. What happens when two people do something at the same time?
What happens when an API fails? What happens when the database is unavailable? Can one user access another user's information?
Are passwords handled correctly? Are permissions enforced on the server or merely hidden in the interface? Can somebody manipulate the request?
What gets logged? Are there backups? Can we recover?
What happens when usage grows? Is personal data being handled appropriately? That last part of development doesn't disappear because AI wrote the first version quickly.
AI can create bugs much faster too
This is the other side of productivity. If AI allows someone to write five times as much code, they can potentially create five times as much code that needs understanding. More code isn't automatically more progress.
The AI may: make assumptions you didn't notice, use an inappropriate library,
duplicate functionality that already exists, introduce a security problem, solve the symptom rather than the cause,
or produce something that works beautifully for the example you gave it and fails everywhere else. The output can look extremely convincing. That's precisely why it needs judgement.
The person directing the AI needs to understand consequences
There is a big difference between: Make this button blue. and:
Change the authentication system. Both can be typed into the same AI tool. The consequences are completely different.
This is where some of the "anyone can now build software" narrative becomes more complicated. More people absolutely can build software. I think that's brilliant.
Someone with an idea can now get much further without a traditional development team. But the easier software becomes to create, the easier it also becomes to create software without understanding what sits underneath it. That matters when the system starts holding:
customer information, payments, health information,
business data, authentication credentials, or anything else somebody cares about.
Vibe coding is fantastic until the vibe breaks
There's now a term for building software largely by describing what you want and allowing AI to produce the code: vibe coding. For prototypes, experiments and small tools, it can be extraordinary.
You can stay focused on the outcome instead of every implementation detail. But there is a point where: Make this work.
needs to become: Why does this work? If the application matters to a business, somebody needs to understand enough of the system to maintain it.
Because eventually something will go wrong. A service changes. An API is deprecated.
Usage increases. A dependency breaks. A security issue appears.
A customer finds an edge case nobody considered. The AI will help fix those things too. But somebody still needs to understand what the system is supposed to do.
The junior developer question is interesting
One concern around AI coding is what happens to junior developers. Historically, a lot of learning happened through smaller tasks. Fix this bug.
Build this component. Write this query. Update this page.
Those are exactly the kinds of tasks AI can now do extremely well. That creates a genuine question for the industry. If AI performs more of the entry-level implementation work, how do new developers acquire the experience that eventually makes them good at architecture, debugging and technical judgement?
I don't think the answer is that nobody learns development anymore. But the learning path may need to change. Understanding code may become more important than manually producing every line of it.
Reading may become more important than writing
This sounds counterintuitive. If AI writes more code, developers may need to become extremely good at reading it. What did the AI actually build?
Why did it choose this approach? What assumptions did it make? What else does this change affect?
Is this secure? Is there already another implementation elsewhere? Will another developer understand it six months from now?
The ability to review AI-generated code is going to matter enormously. You can't meaningfully approve something you don't understand.
Testing becomes more important, not less
If code becomes cheaper to produce, proving that it works becomes a larger part of the job. Fortunately, AI can help here too. It can write tests.
Generate unusual cases. Run them. Analyse failures.
Look for regressions. Test interfaces. And potentially act as another pair of eyes over the system.
This is one of the interesting characteristics of AI-assisted development. AI can create more code. But it can also help us test more code.
The question becomes whether the verification keeps pace with the generation.
Security becomes particularly important
AI-generated software can be secure. It can also contain vulnerabilities. The fact that code was generated by a sophisticated model doesn't make it automatically safe.
And AI development encourages speed. That's where I think teams need discipline. Authentication.
Permissions. Input validation. Secrets.
Database access. Dependencies. Logging.
Personal data. Payment handling. These things don't become less important because the feature appeared in ten minutes.
If anything, the speed at which software can now be produced makes it easier to move past them without noticing.
Architecture matters when the prototype grows up
A lot of AI-built software starts with: I just need a quick tool that does this. Then it works.
People use it. Someone asks for another feature. Then another.
Six months later, the quick internal tool has become business-critical. This isn't new. Software has always grown like this.
AI simply makes the first stage much faster. So we need to get better at recognising when the prototype has become a product. That's the point where questions about:
architecture, maintainability, security,
monitoring, backups, documentation,
and ownership stop being optional.
This could be enormous for small businesses
This is the bit I find particularly exciting. Custom software used to be difficult for small companies to justify. Suppose your business had an annoying internal process that wasted five hours a week.
Building a bespoke system to fix it might have cost more than simply living with the problem. AI-assisted development changes those economics. Smaller internal tools.
Customer portals. Reporting systems. Admin interfaces.
Integrations. Workflow tools. Things that previously sat in the category:
Would be nice, but not worth developing. may increasingly become worth building. That opens up custom software to businesses that previously had to adapt their processes around whatever off-the-shelf software was available.
Which also changes build versus buy
For years, the sensible advice was often: Don't build software if a good product already exists. That remains sensible.
Buying mature software gives you: support, security work,
updates, infrastructure, documentation,
and years of product development you don't have to reproduce. But AI is changing the calculation at the edges. Imagine you pay for four different software products primarily because you need one small feature from each.
Or your team spends hours working around a SaaS product because it doesn't quite match your process. Previously, custom development might have been prohibitively expensive. Increasingly, it may not be.
That doesn't mean everyone should build everything. It means the build-versus-buy calculation has changed. And I think it will continue changing.
Software may become much more personal to the business
We've spent years adapting businesses to software. The CRM expects the process to work this way. The project-management platform expects that structure.
The ecommerce system gives you these options. So businesses adjust. If custom development becomes dramatically cheaper, we may see more software adapting to the business instead.
Small, purpose-built applications sitting between larger platforms. Interfaces designed around one team's actual workflow. Automations built around how the company really operates.
AI helping create and maintain those systems. That could be one of the less flashy but more important consequences of AI coding.
Does this mean developers disappear?
I wouldn't frame it that way. The work changes. Some implementation becomes dramatically faster.
Some tasks that previously justified a developer's time may be handled almost entirely by AI. People without traditional development backgrounds will be able to build much more themselves. At the same time, businesses will still need people who can understand:
systems, architecture, data,
security, users, processes,
trade-offs, and what should be built in the first place. The valuable skill moves upwards.
From: How do I write this code? towards:
How should this system work?
That's a familiar technological shift
Developers already work at much higher levels of abstraction than developers did decades ago. We don't normally write machine code. We use programming languages.
Frameworks. Libraries. Cloud platforms.
APIs. Databases. Services built by other people.
Each layer lets us describe more of what we want without manually constructing everything underneath it. AI may be another enormous abstraction layer. Instead of telling the computer exactly how to create something, we increasingly describe what we need it to achieve.
But somebody still has to understand whether the result makes sense.
The ability to build is becoming less scarce
This is the part I think businesses should really pay attention to. Software development has historically been constrained by access to people who can build software. That constraint is weakening.
Not disappearing. Weakening. That means more ideas can be tested.
More internal processes can justify custom solutions. Smaller businesses can build things previously available mainly to larger organisations. And individuals can create products that would once have required teams.
That's a very significant shift. But if the ability to build becomes abundant, something else becomes scarce. Knowing what is worth building.
Understanding the problem. Understanding the customer. Understanding the business.
Designing the system. Knowing which compromises are acceptable. Recognising when something isn't safe.
And deciding when the software is actually good enough to depend on. AI can help with all of those things. But they're increasingly where the value sits.
So what happens when AI writes most of the code?
We spend less time obsessing over the act of producing code. And more time thinking about the system the code creates. That doesn't make technical knowledge irrelevant.
It makes technical judgement more valuable. Because producing software is becoming easier. Producing good software that solves the right problem and can be trusted is still difficult.
After 15 years building for the web, I find that genuinely exciting. The barrier between: I have an idea
and I have something working has never been lower.
But perhaps that means we need to become better at the question that comes before either of them: Is this actually worth building?
Where to go next
- Why your AI demo worked and your AI implementation didn't Getting something working is increasingly easy. Getting it working reliably inside a real business is a different challenge.
- AI has changed the build-versus-buy calculation When does cheaper AI-assisted development make custom software worth considering?
- AI is changing how much one technical person can build What happens when a small technical team gains capabilities that previously required considerably more people?
- Don't start with AI. Start with the work. Before building anything, find the process or problem actually worth improving.
It may be considerably more practical to build now than it was a couple of years ago.
Book a quick chat →Related: Why your AI demo worked and your AI implementation didn't.
Common questions
Will AI replace software developers?
I wouldn't frame it that way. Some implementation becomes dramatically faster, and some tasks that previously justified a developer's time may be handled almost entirely by AI. But businesses will still need people who understand systems, architecture, data, security, users, processes, trade-offs and what should be built in the first place. The valuable skill moves upwards, from how do I write this code to how should this system work.
If AI can write the code, what still needs a human?
The system questions. Whether it is the right thing to build, how authentication and permissions work, where the data comes from, what happens when something fails, what is sensitive and what needs logging. Reading and reviewing AI-generated code, testing it, securing it and recognising when a prototype has quietly become a product all still need judgement.
Does cheaper AI-assisted development mean we should build our own software?
Sometimes. AI is changing the build-versus-buy calculation at the edges, so custom internal tools, integrations and small applications that were never worth weeks of development may now be worth testing. But buying mature software still gives you support, security work, updates and years of product development you don't have to reproduce. It doesn't mean everyone should build everything.