AI in Software Development: What It Changes for the Business Paying for It

Does AI make software cheaper or faster to build?

AI in software development has become hard to ignore. Coding assistants can finish a function, draft a test, explain an unfamiliar file or turn a short description into a working screen in seconds. If you are about to commission software, it is fair to ask what that changes for you: is it cheaper, is it faster, and is it safe?

The honest answer is that it changes some things and leaves most of the important ones where they were. This guide is written for the business owner or founder who is paying for software, not for the engineers building it. It explains what AI tools actually help with, what still needs a person, who owns the result, what can go wrong and the questions to put to any agency, including us.

A note on what we are not going to do. We are not going to quote productivity percentages. Most figures you see about AI and developer speed come from narrow experiments, vendor surveys or opinion, and they say little about a business system with real users and real data. Where evidence exists, we point to it, and where it is mixed, we say so.

Which parts of building software does AI help with?

AI tools are good at work that is repetitive, well understood and easy to check. In practice that means:

• Boilerplate. Standard forms, data models, admin screens and the glue code that connects services.
• First drafts of tests. Generating a set of test cases that a developer then reads, corrects and extends.
• Explaining and searching code. Summarising what an unfamiliar module does, or finding where a behaviour lives.
• Documentation. Drafting comments, setup notes and change summaries from the code.
• Translating between formats. Converting a spreadsheet layout into a data structure, or one framework's syntax into another's.
• Rough prototypes. Getting something clickable in front of users early so the real design conversation starts sooner.

Notice what these have in common. A person can look at the output and tell quickly whether it is right. The tools save typing, not thinking. That is a real benefit, and it is much smaller than the claim that software can now be produced by describing it.

Does it actually reduce cost and time?

For the narrow tasks above, often yes. For a whole project, the picture is less clear, because typing code was never the biggest part of the cost.

On a typical business system, most of the effort goes into understanding the workflow, deciding what to build and what to leave out, designing the data and permissions, reviewing and testing, connecting to other systems, migrating data and keeping it running afterwards. Our guide to the software development life cycle lays out these stages and what you do at each. AI helps a little in a few of them and not at all in others, such as agreeing with your team what the rules of the business actually are.

Research reflects this mixed picture. The Google Cloud team behind the DevOps Research and Assessment programme studies software delivery each year, and its 2024 report on AI examined AI adoption alongside delivery performance. Read it for yourself rather than relying on a summary, but one fair reading of that body of work is that tools which speed up individual tasks do not automatically make a team deliver better software, and may create problems if reviews and testing do not keep up.

The practical conclusion for a buyer: be wary of two opposite claims. One says AI makes software nearly free, so a quote should be a fraction of what it was. The other says AI changes nothing. The truth is that the cost of discovery, design, review, testing and maintenance has not gone away, while some construction effort has shrunk. Compare quotes by scope, process and handover, as in our guide to comparing software development quotes, not by whether the vendor mentions AI.

What still needs a human?

Quite a lot, and it is the part you are really paying for.

• Understanding the problem. AI does not know how your business works, where the awkward exceptions are or why a rule exists. Someone has to ask, watch and decide.
• Deciding what to build. Choosing the smallest useful version, saying no to features and sequencing the work are judgement calls.
• Architecture. How the pieces fit, how data is stored, how it scales and how it will be changed in two years. Poor early choices are costly to reverse.
• Review. Every line a tool produces still needs to be read by someone who understands it. Code that runs is not the same as code that is correct.
• Security. Deciding who can see what, protecting data and handling secrets, covered in our buyer's checklist for secure software development.
• Testing and acceptance. Checking that the software does the job under realistic conditions.
• Accountability. When something breaks at night, a person has to be responsible for fixing it, and for telling you what happened.

A useful way to think about it: AI can make a good developer faster at certain tasks and can make a careless process produce more mistakes faster. The difference is the discipline around it, which is what you should ask about.

Who owns code written with AI assistance?

This is the question buyers ask least and should ask first.

Ownership of software you commission is normally settled by your contract with the developer: you pay, and the agreement says you own the deliverables. AI tools add two complications.

The first is the legal status of generated material. In the United States, the Copyright Office has published guidance on copyright and artificial intelligence which says, in summary, that human authorship is required for copyright protection, and that material generated by AI without sufficient human creative control is not protected in the same way. Rules in India and elsewhere are still developing and differ by country. This is not legal advice, and you should ask a lawyer how it applies to your situation. The practical point is that you should not assume that every line of a system is protectable just because you paid for it.

The second is provenance. Tools can produce code that resembles existing code, including code under licences with conditions. A careful team checks and records what third-party code is in the project.

What to do about it, in contract terms:

1. State that you own the deliverables on payment, including the source code.
2. Have the developer warrant that they have the right to hand them over.
3. Require disclosure of third-party code and licences included.
4. Settle what may be sent to outside AI services, because prompts can include your code, data or business rules.
5. Keep the accounts and repository in your name, as covered in who owns your website after a developer builds it.

What are the quality and security risks?

AI-written code carries the same risks as code from any fast, confident contributor who does not know your system.

• Plausible but wrong. The code compiles, looks tidy and handles the common case, then fails on an edge case your business meets weekly.
• Insecure patterns. Tools may reproduce common weaknesses, such as trusting user input or checking permissions in the wrong place.
• Outdated or invented dependencies. Tools sometimes suggest libraries that are old, unmaintained or do not exist, which attackers can exploit by publishing a malicious package under the invented name.
• Hidden bloat and duplication. Large amounts of generated code can be harder to maintain than a smaller, deliberately designed codebase.
• Gaps in understanding. If nobody on the team understands why a piece of code works, nobody can safely change it later.
• Data leaving your control. Pasting real customer data into an outside tool to debug a problem may break your own privacy commitments.

None of these is a reason to refuse AI tools. They are reasons to expect review, testing and dependency checks to be done properly, and to ask how. If you are adding AI features to your product, not just using AI to build it, a separate set of risks applies, and the OWASP Top 10 for large language model applications is a good starting vocabulary. The UK National Cyber Security Centre also publishes guidelines for secure AI system development.

Using AI to build software is not the same as building AI into software

These two get mixed up in proposals, and the difference matters for cost and risk.

Using AI to build means developers use coding assistants while writing a conventional product. You, the customer, may never see it. The risks are about quality, ownership and confidentiality, as above.

Building AI into the product means the software itself includes a feature powered by a model: a chatbot, a document reader, a summary, a recommendation. This adds running costs, data handling questions and behaviour that is harder to test, because the same input can produce different outputs. Before you add one, read our notes on which AI features are worth adding to a product and how your data is handled when you add AI features. Our AI integrations service covers this kind of work.

A good proposal says clearly which of the two it means.

What should you ask your agency about its use of AI?

You do not need to be technical to ask these. The quality and specificity of the answers tells you more than any claim on a sales page.

1. Which AI tools do your developers use on my project?
2. What of my code, data or documents is sent to outside services, and under what terms?
3. Can I tell you that no real customer data may be pasted into AI tools?
4. Who reviews AI-generated code before it is merged?
5. How is it tested, and what do automated tests cover?
6. How do you check the libraries and licences in the project?
7. What does the contract say about ownership and about your right to hand the code over?
8. Will the code be documented so another team can maintain it?
9. How do you decide what not to use AI for?
10. Does using AI change my price, my timeline or my risks, and how?

Watch for two kinds of bad answer. One is vagueness: "we use the latest AI" says nothing about control. The other is overselling: "AI lets us deliver in a fraction of the time" without explaining what has been removed from the process. If speed has been gained, you should be told where it came from and what is still being checked.

How should AI change the way you buy software?

Not much about the basics, and a few things at the edges.

• Keep buying outcomes and process. Scope, milestones, acceptance criteria and handover matter as much as before.
• Insist on testing and review. The more code is produced quickly, the more checking it needs.
• Put ownership and confidentiality in writing. Cover generated code, outside services and your data.
• Expect honesty about limits. A team should tell you where AI helps and where it does not.
• Stay ready to ask for the source. You should hold the repository and accounts from the start so you can have anything reviewed independently.
• Plan maintenance. Software that was quick to generate still needs updates, because libraries and platforms keep changing.

The short version

AI tools are making some parts of building software quicker, especially routine code, drafts and explanation. They have not removed the work that decides whether software is good: understanding the business, designing the system, reviewing and testing it, securing it and maintaining it. For you as the buyer, that means three things. Compare quotes on scope, process and handover. Write ownership and confidentiality terms into the contract. And ask your agency the ten questions above, listening for specific answers about review and testing.

If a vendor can explain where AI saves effort, where a person still checks and what happens to your code and data, you are probably dealing with a team that uses the tools well. If it can only tell you that AI makes everything faster, keep asking.