Code is getting cheaper. Good software isn’t.

That is good news for anyone buying software. It should mean faster experimentation, less time spent on repetitive implementation and, in some cases, lower build costs.

But it also changes what you should look for when choosing who builds your software.

When implementation gets easier, the value shifts towards the decisions around it: what gets built, how data is structured, who can access what, what happens when something fails, and how difficult the system will be to change a year from now.

The code matters. It just tells you less about the quality of the final system than it used to.

The implementation layer is getting cheaper

This is no longer a niche way of working.

JetBrains’ 2025 Developer Ecosystem Survey, which ran from April to June 2025 and included 24,534 developers across 194 countries, found that 85% of developers regularly use AI tools for coding and development. It also found that 62% rely on at least one AI coding assistant, agent or code editor.

That does not mean 85% of software is now being written by AI. It does show that AI-assisted development has moved into normal engineering practice.

The useful distinction for a buyer is what these tools are good at.

Give an agent a sufficiently clear task inside an existing codebase and it can often produce an implementation quickly. It can create interfaces, write database queries, modify APIs, generate tests, trace errors and handle work that previously consumed a meaningful amount of developer time.

That is genuine leverage. The harder question is whether the task it was given was the right task in the first place.

A working feature can still be the wrong solution

Suppose you ask for document uploads.

The visible requirement seems simple: a user selects a document, uploads it and can access it later.

You can build that surprisingly quickly.

A feature can satisfy the requirement exactly as written while getting several of those decisions wrong.

That is the distinction between implementation and engineering judgment.

Both can produce a convincing demo.

The demo has become a weaker test

A good demo still matters. You should be able to see the software working before you pay for a finished product.

But the existence of a polished interface is less evidence of what sits underneath it than it once was.

Consider four systems that all look fine during a demonstration.

• An admin dashboard works perfectly with 50 records, but its queries become painfully slow with 500,000.
• An integration successfully sends data to another platform, but nobody has handled retries, duplicate events or an outage at the other end.
• A customer portal has authentication, but the permissions underneath it are broad enough that one account can request data belonging to another.
• An automated workflow completes perfectly when everything succeeds, but a failure halfway through leaves two systems disagreeing about what happened.

These are not obscure edge cases. They are ordinary software decisions, and they are difficult to see by clicking around a demo.

A decision we made in something we built

The difficult part was not generating the email or ranking potential tutors. Those are implementation problems.

The more important decision was deciding where automation should stop.

There is an understandable tendency with new technology to ask how much of a process can be automated. A better engineering question is often which parts should remain deliberately manual.

That is not something better code generation resolves for you.

More code creates another problem: more code to own

Faster implementation also changes the economics of adding things.

When a feature takes weeks to build, there is natural pressure to decide whether it is worth having. If the same feature can be produced in an afternoon, the easiest answer becomes: build it and see.

That is useful for experimentation. It is less useful if every experiment quietly becomes permanent production software.

Every new feature can bring additional tables, permissions, dependencies, APIs, background jobs, states and interactions with the rest of the system. Even if each piece was inexpensive to create, someone still has to understand and maintain the combined result.

There is some early evidence of this maintenance problem in AI-assisted development.

The 2026 preprint Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild analysed 302.6k verified AI-authored commits across 6,299 GitHub repositories.

The researchers used static analysis before and after each commit to identify issues introduced by the change, including code smells, correctness issues and security issues. They identified 484,366 issues.

Importantly, 89.3% were code smells — maintainability concerns flagged by static analysis, not bugs. The researchers then followed introduced issues through later revisions and found that 22.7% were still present in the latest version they tracked. Those figures are from version 2 of the paper, revised 26 April 2026.

That should not be read as “AI code is bad”. Static-analysis issues are not the same thing as production failures, and the study does not establish that AI-assisted development is worse overall than an equivalent human-only process.

The useful point is narrower: generating code faster does not make the cost of understanding and maintaining that code disappear. It can simply move the bottleneck.

A cheap quote tells you less than it used to

We have written separately about the AI discount in What actually drives the cost of custom software.

AI should reduce the effort required for some development work. If a supplier can complete the same implementation safely in less time, it is reasonable for buyers to ask where that efficiency goes.

But price alone is becoming an even weaker proxy for quality.

Two developers can have access to the same models, frameworks and infrastructure while making very different decisions.

One receives a requirement and implements it.

The other asks who should be able to perform the action, what happens if it fails halfway through, whether another system should own that data, whether the feature is needed at all and what will happen when the business process changes.

They may both show you something that works.

The software you own six months later can be very different.

How to test for judgment before you hire someone

You do not need to be technical to test this.

Give the developer or supplier a real requirement from your project and see what they do with it.

1. “What would you need to know before building this?”

You are looking for questions, not instant confidence.

For the upload example, somebody should want to know what is being uploaded, who owns it, who needs access and whether there are any retention or security requirements.

The exact technical questions will vary. What matters is whether they recognise that the sentence you gave them is not a complete specification.

2. “What do you think could go wrong?”

A good answer should be specific to your system.

That might mean an unreliable third-party integration, messy historical data, unclear permissions or a process where two people can update the same thing at once.

“Nothing major, it is pretty straightforward” can be true. But if that is the answer to every part of the project, very little investigation has probably happened.

3. “What would you deliberately leave out of version one?”

Software becomes more expensive and harder to maintain as it accumulates behaviour.

Someone who understands the problem should normally be able to tell you which parts do not need to exist yet.

Being able to build something is not a reason to build it.

4. “What happens when this fails halfway through?”

This is particularly useful for integrations and automation.

If your system creates an invoice, updates a CRM and sends a customer message, what happens if the first two actions succeed and the third fails?

The answer does not need to be technically elaborate. You are checking whether failure has been designed for at all.

5. “How difficult will this be for another developer to change?”

Software usually outlives the first version of the requirement.

A reasonable answer should touch on keeping the system understandable, avoiding unnecessary complexity, documenting the important parts and not tying ordinary business logic to something that is difficult to replace.

“We can build that” and “we should build that” are different answers

One of the best consequences of AI-assisted development is that trying an idea can cost far less than it did before.

That should lead to more experimentation, faster prototypes and fewer hours spent on repetitive work.

But it makes one distinction more important:

“We can build that quickly” is a statement about implementation.

“This is how we should build it” is a statement about judgment.

When code was harder to produce, those capabilities were often bundled together because you needed significant technical ability simply to achieve the first one.

They are becoming easier to separate, and buyers should learn to separate them too.

Common questions

The question buyers should ask has changed

For a long time, one of the main questions when choosing a software developer was:

Can they build this?

You should still ask it.

But as producing code becomes easier, another question carries more weight:

Do I trust the decisions they will make while building it?

You are not only buying the code that exists on launch day. You are inheriting hundreds of decisions about your data, permissions, integrations, failures, dependencies and how easily the system can change.

AI can make those decisions much faster to implement.

It does not make them less important.

Building is the easy part. Deciding where it goes is the job.

Related: What actually drives the cost of custom software, particularly the section on the AI discount. Service: Custom Software Builds.