For a long time, artificial intelligence in software development meant the development environment completing the next line. Today, coding agents such as Claude Code, GitHub Copilot or Cursor read an entire repository, change several files, run tests and propose finished pull requests.
This leads to two common fallacies. The first: software is now almost free. The second: AI code is shoddy by definition. Neither is true. Written from the perspective of a team that develops bespoke software for SMEs, this article shows where AI helps and where it doesn’t, how to safeguard quality and what it means for costs and contracts.
What has changed and what hasn’t
What has changed is the price of simply writing code. A task that is clearly described and can be checked automatically is now done much faster by an agent than by a person alone. That lowers the threshold for projects that didn’t pay off before. Why this tends to increase rather than reduce demand for software is explained in the article on the Jevons paradox of software.
What hasn’t changed is what makes software projects difficult: unclear requirements, business rules that aren’t written down anywhere, system landscapes that have grown over the years and the question of who answers for a result. A language model doesn’t know your business. It only knows what is in the code, the tickets and the prompt.
Where AI assistants really help in a project
The following tasks have two things in common: they are easy to describe, and the result can be checked quickly. That is exactly where AI plays to its strengths.
Boilerplate and scaffolding
Data models, forms, API endpoints following an existing pattern, configuration files, migration scripts: much of a project is craft work to a template. Here, an assistant quickly delivers a usable draft that a developer then adapts. The time saved goes into the parts that need real thought.
Tests
Tests tend to get postponed in projects. With AI, the hurdle drops considerably: the assistant suggests test cases, including edge cases nobody thinks of in day-to-day work. But a test that only confirms what the code does anyway checks nothing. Which cases are correct from a business point of view is decided by someone who knows the requirements.
Refactoring and upgrades
Framework updates, renamed interfaces, outdated libraries: mechanical changes across many files are a typical task for an agent. The prerequisite is tests that show the behaviour hasn’t changed. Our wiki explains exactly what refactoring is. With legacy systems, agents also help to analyse dependencies and document processes, as described in the article Modernising legacy software.
Documentation and understanding code
An assistant can explain unfamiliar or old code, summarise processes and write drafts of technical documentation. That noticeably speeds up onboarding for new team members. Someone still has to check the documentation, though, because even a well-worded explanation can be wrong.
Code review as a second opinion
AI-assisted reviews find swapped conditions, forgotten error handling or inconsistent naming. They are a useful additional check before the human review, but no replacement for it. Whether a change is correct in business terms and fits the architecture is for a person to judge.
Where AI doesn’t help or even does harm
Architecture decisions
Whether an application is built as a monolith or as services, where data lives and how systems are coupled depends on goals, team, budget and operations. A model can list options and name pros and cons. The trade-off for your case and the responsibility for the consequences over the years remain with people. More on this on our page on system architecture and design.
Business logic that isn’t written down anywhere
The most expensive mistakes arise from rules that exist only in people’s heads: a special condition for a key account, an exception in the approval of certain orders, a status field that means something different in practice than in the manual. A model often fills such gaps with a plausible assumption instead of asking. That is why requirements analysis and conversations with the business department still come at the start of every project.
Security responsibility
AI-generated code can contain security vulnerabilities just like any other code: missing permission checks, unvalidated input, insecure default settings. On top of that come new risks. Models occasionally suggest packages that don’t even exist, and attackers can deliberately register such names. Agents that read web pages or tickets can be manipulated through hidden instructions, known as prompt injection. No tool can take on responsibility for security. Why “it runs” is not the same as “it’s good” is shown in the article Vibe coding vs. good code.
Code nobody understands
The faster code is produced, the greater the temptation to accept it unread. Code that nobody on the team understands is technical debt with interest: at the next change or the next production incident, the analysis starts from scratch.
Quality gates: how AI code gets into production safely
The most important rule is simple: AI-generated code is subject to the same gates as any other code, without exception.
- Human review. Every change is read by someone who understands it. Whoever approves a pull request is responsible for it, no matter who wrote it.
- Small changes. Agents quickly produce large diffs. Small, cleanly scoped pull requests can be reviewed; huge ones can’t.
- Automated tests in the pipeline. Unit, integration and end-to-end tests run on every change. No green pipeline, no merge.
- Static analysis. Type checking, linters and security scanners find whole classes of errors before a person even looks.
- Check dependencies and credentials. New packages are checked for existence, maintenance and licence. Credentials never belong in the code and never in a prompt.
- Document decisions. Why something was built the way it was belongs in tickets, commit messages or architecture decision records, not just in a chat history.
These gates are not new. What is new is that without them a great deal of unchecked code can be produced in a very short time.
Data protection, trade secrets and copyright
GDPR and confidential data
Source code itself usually contains no personal data. Test data, log extracts, database dumps and error messages from production, on the other hand, often do. For working with AI tools, this means: use business editions with a data processing agreement under Art. 28 GDPR, exclude training on your own inputs, keep production data out of prompts and limit the agents’ access to what is necessary. Trade secrets such as pricing logic also belong only in tools whose terms you know. How to set up AI tools in your company in compliance with data protection rules is covered in the article GDPR and AI.
Who owns AI-generated code?
German copyright law only protects personal intellectual creations (Section 2(2) UrhG, the German Copyright Act). Code that an AI generates without any significant human contribution may therefore not be protected by copyright. For you as a client, what the contract says matters more: you should receive the rights of use to the entire result and access to the source code, regardless of which tools were used to create it.
A second risk is licences. An assistant can reproduce passages from open source projects almost verbatim, along with the obligations of the licence in question. Some tools offer filters that detect suggestions matching public code. A licence check of the dependencies belongs in every project anyway. This section is not legal advice. For high-value contracts, it is worth having a specialist IT lawyer take a look.
AI literacy in the team
The EU AI Act obliges companies that deploy AI systems to take measures to ensure the AI literacy of their staff (Article 4). This also applies to development teams working with coding assistants. What else the AI Act means for SMEs is summarised in the article on the EU AI Act.
What AI means for the cost of your project
Nobody can seriously say today how much cheaper AI will make a particular project. That depends on how much routine work it contains and how good the requirements and tests are. What can be said is this: the effort shifts.
Implementing clearly described tasks gets cheaper. Everything around it stays the same or becomes more important: clarifying requirements, deciding on the architecture, reviewing, testing, integrating, operating. In projects with lots of forms, standard processes and rework, the effect is greater than in projects whose effort lies in business rules and interfaces to legacy systems.
For clients, this has two consequences. First, projects that used to fail on budget become realistic, such as a dedicated business application instead of yet another Excel sheet. Second, the maintenance equation shifts: updates and rework that used to be left undone become affordable. What this means for the choice between open source, SaaS and in-house development is covered in the article Open source revolution.
If a provider advertises AI discounts, ask where exactly the time is saved and who does the review. If the savings come from review and testing, that is not a discount but a risk. Which factors actually determine the price of a software project is shown in the guide How much does software development cost?
What to look out for as a client
Whether your provider uses AI tools is hardly the question any more. What’s interesting is how. These questions help in the selection meeting:
- Which AI tools do you use, and in which edition, i.e. with a data processing agreement and without training on our data?
- Does data from our operations end up in prompts, and if so, which data?
- Who reviews AI-generated code, and by which rules is it merged?
- Which automated tests and checks run on every change?
- Who owns the source code and the rights of use, including for AI-generated parts?
- How is documentation handled so that another team could also continue developing the software?
Good answers are specific and match what you can later see for yourself in the repository and the pipeline.
AI in the development process and AI in the product
This article covers AI as a tool for building software. Separate from that is AI as a feature in your software, such as an assistant that analyses documents or an agent that pre-sorts enquiries. Different questions apply there, about data flow, running costs and control. If you want to integrate AI features into existing systems, you’ll find our approach under AI system integration and AI agents as digital employees. If your own development team wants to learn how to work with coding assistants, our AI workshops for teams are a good fit.
How we handle it at nextlevels
We use AI assistants where the result can be checked: for scaffolding, tests, upgrades, documentation and as an additional check before review. Every change goes through a human review and an automated pipeline with type checking, linting and tests. Real customer data doesn’t belong in prompts. Architecture, business logic and acceptance are the responsibility of people in the project team, with contacts you know. We would rather put the time AI saves on routine work into requirements, testing and operations than into more unchecked code.
Conclusion
AI has changed software development, but it hasn’t done away with it. It makes writing code faster and cheaper, especially for routine work, tests and rework. It does not take the decisions on architecture, the understanding of business logic or the responsibility for security off anyone’s hands. For clients, this means: pay less attention to whether a provider uses AI and more to how they assure quality.
If you are planning a software project, you’ll find our approach on the page on custom software development. The project calculator gives you a first cost range for your project.
Frequently asked questions about AI in software development
How is AI used in software development?
Mainly as a coding assistant and coding agent. The tools write drafts of code, tests and documentation, explain existing code, carry out mechanical changes across many files and provide an additional assessment in code review. Developers check the results and decide what is adopted.
Will AI replace software developers?
No. AI takes over part of the writing. Understanding requirements, deciding on architecture, checking business logic, taking responsibility for results and operating systems remain human tasks. The role shifts from writing to specifying, reviewing and deciding.
Is AI-generated code secure?
Not automatically. It can contain the same vulnerabilities as code written by people, plus new risks such as invented package names or injected instructions. It becomes secure through the same quality gates as any other code: human review, automated tests, static analysis and vetted dependencies.
Who owns the rights to AI-generated code?
Purely AI-generated code may not be protected under German copyright law, because the law requires a personal intellectual creation. What matters for you is the contract: make sure you are granted the rights of use to the entire result and access to the source code, regardless of the tools used. If in doubt, a specialist IT lawyer can help.
Does AI make custom software cheaper?
Implementing clearly described tasks gets cheaper. Requirements, architecture, review, integration and operation still take effort. How strong the effect is depends on the project: a lot of routine work saves more than many business rules and interfaces to legacy systems. The project calculator gives you a range for your project.