Today a few lines of description are enough for an AI tool to build an API, design a sign-up form or add a feature to your project. Work that used to take an afternoon now reaches a first draft in minutes.
The real question starts right after those minutes: is that draft actually ready to ship? Does it fit the project's architecture? Does it hide bugs? Will anyone be able to change it six months from now?
AI-assisted software development has made writing code faster, but the speed of producing code and the speed of delivering reliable software are two different measures. This article is about the gap between them: why it exists, what the research says about it, and how to build software with AI coding assistants that actually holds up.
Code generation is not software engineering
The two are easy to confuse:
- Code generation: writing a piece of code or implementing a specific feature.
- Software engineering: understanding the problem, designing a solution, choosing an architecture, managing dependencies, testing, deploying and maintaining; everything that turns a piece of code into part of a system people can rely on.
Ask an AI tool to build a sign-up system. You'll probably get a form, a data model and an endpoint within seconds, and they'll probably work on the happy path. But what about these?
- If a user double-clicks the button, are two accounts created?
- If the database connection drops mid-sign-up, is half a record left behind?
- Can a user see someone else's data by changing a number in the URL?
- Where are business rules, like "one account per phone number", enforced?
None of these were in the original request, so no tool was obliged to answer them. A piece of code running correctly does not mean the whole system works correctly.
Five challenges that automatic code generation doesn't remove
1. Architecture and technical decisions
Building a feature is rarely the hardest part; the hard part is how it connects to everything else. A tool that only sees the file in front of it may rewrite validation logic in a new file while the original lives two folders away. Every time that happens, the cost of the next change goes up.
2. Hidden bugs and edge cases
Code tends to be right on the normal path and break at the edges: empty input, concurrent requests, network failures, invalid data. I've seen this on my own website: the backend and the frontend were each perfectly healthy, but because the frontend fetched its data through the site's public address, the day the server lost its internet connection the entire site returned errors. No single piece of code had a bug; the bug lived on the boundary between two parts. Only someone holding the whole system in their head finds that kind of failure.
3. Testing and proving correctness
A model's convincing explanation of its own code, or one successful run, is not a test. Code that looks right is more dangerous than code that is visibly broken, because nobody goes looking for its flaws. Automated tests, especially for failure scenarios, are the only reliable way to know.
4. Security and privacy
Generated code repeats the patterns it saw most often in its training data, including insecure ones: incomplete input validation, returning data without checking who owns it, an API key written straight into the code, or logs that store sensitive user data. Any output that touches user data or permissions deserves a separate security review.
5. Maintainability
Code that works today may be hard to change tomorrow. When generating code costs almost nothing, the temptation to add more of it grows, but every line is a line someone has to read, understand and maintain. Good naming, removing duplication and following the project's conventions matter more than before.
What does the research say?
This is where the argument moves from opinion to evidence. Three credible studies paint three different pictures:
Higher productivity, under specific conditions. A paper in Management Science pools three randomized field experiments at Microsoft, Accenture and another large company, covering 4,867 developers. Developers with access to an AI code-completion tool (GitHub Copilot) completed about 26% more tasks on average, and less experienced developers gained the most. The experiments ran between 2022 and 2024, with the tools of that period.
Slower, while believing they were faster. In METR's randomized trial (2025), 16 experienced developers worked on 246 real tasks in open-source projects they had contributed to for years. When early-2025 AI tools were allowed, tasks took 19% longer on average, while the participants believed afterwards that they had been about 20% faster.
An amplifier, not a fix. Google's DORA 2025 report, based on a survey of nearly 5,000 technology professionals, concludes that AI acts mainly as an amplifier: it strengthens teams with good processes and platforms, and magnifies the problems of struggling ones.
These results don't contradict each other; together they say something specific:
- Lines of code or tasks closed are not a complete measure of productivity. Finishing a task fast is not the same as product quality and stability.
- The kind of work matters. Getting help in a familiar, complex codebase is different from getting help to start something new.
- Feeling faster is not being faster. The gap between perception and measurement in the METR study is a good reason to measure instead of trusting the feeling.
- One experiment doesn't generalize by itself. The tools also change fast; today's number may not hold next year.
A workflow for building software with AI
Instead of the vague advice "review the code", here is a process that works in practice:
- Define the problem. Write down requirements, constraints and acceptance criteria before the first prompt: "when do we call this done?"
- Plan first, then code. Ask the tool to explain its approach and steps, and review that. Fixing a wrong plan is far cheaper than fixing a thousand lines of wrong code.
- Small changes. Break the feature into steps that can each be reviewed and tested on their own.
- Read the changes, not just the result. Which files changed? Which new dependencies appeared? Which technical decision was made silently?
- Test, especially the failure paths. Run the existing tests and write scenarios for the edge cases.
- Before shipping, check security and rollback. Sensitive settings, permissions, error logging, and how you'd return to the previous version if something goes wrong.
This doesn't mean writing or reading every line yourself. The goal is to control the outcome and the risky decisions, not to give up automation. The riskier the work (money, user data, permissions), the closer the review.
The developer's role is changing
A software engineer's value was never in typing speed or memorizing syntax, but while writing code was slow, the two were easy to mistake for each other. Now that generating code is cheap, what always mattered is easier to see: understanding the real problem, spotting where the output is wrong, prioritizing, choosing between solutions that each have a cost, and owning the result.
The right conclusion is not "you no longer need to know how to code". The opposite: to evaluate a tool's output you have to read code, debug it and understand how the system behaves. Without that, you can't tell where the tool went wrong; you just ship mistakes faster.
Conclusion: more code is not necessarily better software
Building software is still hard because writing code was only ever part of solving the problem. AI has made that part dramatically faster, and that is exactly why the rest (design, integration, testing, security, maintenance) is more visible than ever.
A developer's edge in the coming years won't be using AI; everyone does. It will be the ability to steer it toward a result that is correct, reliable and maintainable.