AI in software development is already part of the daily routine of anyone who builds systems. Assistants write chunks of code, generate tests, suggest fixes and explain old code. The gain is real on repetitive tasks. Deciding what to build, how the system is organized and what can go to production still belongs to experienced people, and that is where a project succeeds or fails.
In this article we show where AI fits into the development cycle, where it still fails, what changes in a developer's work and what all of this means for anyone about to hire a custom system.
Where AI fits into the development cycle
Software goes through similar stages in every project: understand the problem, design the solution, write the code, test, release and maintain. AI helps in different ways at each one.
Requirements and design
Before writing code, someone has to turn conversations with the client into business rules. A language model helps organize meeting notes, flag contradictory requirements and list questions that were left unanswered. It does not know how the client's operation works. The person who mapped the process does.
Writing code
This is the best known use. Tools such as GitHub Copilot, Cursor and Claude Code complete snippets, generate functions from a description and make changes across several files at once. They pay off most on predictable code: registration forms, list screens, integration with a documented API, data format conversion.
Testing
Writing tests is the work many teams postpone. AI generates test cases from the code and the described rule, including edge cases nobody remembered. A developer still needs to check that the test measures what matters, because a test that always passes is also very easy to produce.
Review and security
Review assistants read every change before it enters the main codebase and flag logic errors, exposed sensitive data and outdated dependencies. This is the idea of shift left: catching the problem early, when fixing it is cheap. Static analysis tools were already part of this. AI widens the kind of problem that can be caught at this stage.
Documentation and maintenance
An old system with no documentation is one of the most hidden costs a company carries. AI reads the code, explains what each part does, produces a first round of documentation and helps plan a migration. That shortens the time a newcomer needs to understand a system nobody else knows anymore.
Where AI still fails
The same tool that speeds things up also produces errors with a lot of confidence. The most common ones:
- Code that works in the example and breaks in the real case. The model solves the request it received, without knowing the exceptions of the operation.
- A library or function that does not exist. The assistant suggests something plausible and wrong. Whoever does not check finds out at build time or, worse, in production.
- Silent security flaws. Unprotected database queries, an API key inside the code, permissions that are too broad. The code runs, and the problem only shows up when someone exploits it.
- Client data sent outside. Pasting code or a database into an assistant without a clear policy can expose information protected by contract or by data protection law.
- Architecture nobody decided. Each generated piece makes sense on its own. Put together, they become a system without a pattern, hard to maintain and expensive to evolve.
This is the risk we find in apps built only with AI and no technical review, the subject of our article on vibecoding and AI-built apps in production. The tool is the same. What changes the outcome is who reviews and who decides.
What changes in the developer role
With AI writing a good share of the predictable code, a senior developer's time goes elsewhere:
- Understanding the business. Translating what the client needs into clear rules is the part no tool does alone.
- Designing the architecture. Where each piece of data lives, how modules talk to each other, what needs to scale and what can stay simple.
- Reviewing what AI produced. Reading generated code with the same rigor as code written by a person, and rejecting what does not fit.
- Choosing where to use AI. Not every task benefits from an assistant. For critical business rules, careful writing and solid testing are still usually the safest path.
In practice, developers orchestrate more and type less. Experience matters more, because it is what recognizes a wrong suggestion before the error reaches the client.
Software with AI inside
There is a second form of AI in development, tied to the product more than the process: the delivered system is born with AI inside it.
A few examples of what that means:
- An order system that reads customer emails and creates a draft order for someone to approve.
- A support screen that summarizes the customer's history before the agent replies.
- An industrial maintenance dashboard that combines sensor data and warns when a machine starts behaving outside its normal pattern, before it stops.
- An online store that ranks products according to the behavior of whoever is browsing.
In these cases, AI is one component of the system, with an input, an output and a rule for when a person reviews. The care is the same as with any other component: test, measure, monitor and plan for what happens when the model is wrong.
What this changes for buyers
For a mid-sized company about to hire a custom system, AI in development changes some of the math.
| Aspect | Before | With AI used well |
|---|---|---|
| Repetitive code | A large share of project hours | Faster, with review |
| Tests | Often cut to meet deadlines | More coverage for the same effort |
| Documentation | Left for the end, or never done | Produced along with the code |
| Business understanding | Essential | Still essential, and weighs more in the price |
| Technical review | Recommended | Mandatory |
What stays the same: a poorly specified system comes out wrong, only faster. AI speeds up execution. Clarity about what needs to be built still comes from conversation, mapping and decisions.
Timeline and price
The question we hear most is whether the system gets cheaper. Partly, yes: the hours spent on repetitive code, tests and documentation go down. But those hours were never the whole project. Gathering requirements, designing the architecture, validating with the people who will use it, reviewing and putting it into production still take time, and those are the stages that decide whether the system works for the business.
In practice, the most common effect is delivering more within the same timeline: more tests, more documentation, more adjustments requested by users before launch. A proposal that cuts the price in half by citing AI deserves a simple question: which stage was left out?
Questions to ask your vendor
When choosing who will build it, ask directly. These questions complement what we listed in how to choose a software house:
- Do you use AI in development? At which stages?
- Who reviews generated code before it goes to production?
- How do you handle security in code written with an assistant?
- Do the code and documentation stay with us at the end of the project?
- If the system has AI inside, how do you measure whether it is getting things right?
A vendor who answers clearly knows how to use the tool. A vendor who promises a much shorter timeline just because "AI does it" is selling speed without talking about risk.
How we use AI at Devvo
We use coding assistants every day, for predictable code, tests, review and documentation. All generated code goes through review by a senior person before it enters the project, and architecture and business rule decisions stay with the team.
The reason is simple. AI makes the team faster on the parts that do not require judgment, and the time left over goes into understanding the client's operation better. That is the part where a custom system pays for itself, or becomes one more system nobody uses.
