AI coding tools are making software development faster, but not in the way most of the marketing suggests.
Developers can now generate code, explore solutions, build integrations, produce documentation, and resolve routine problems in a fraction of the time these activities once took. This can reduce both delivery time and overall cost, but it does not remove the work. It reshapes it.
In most real-world projects, we are seeing meaningful rather than extreme reductions in delivery time and budget. Faster prototyping, quicker build cycles, and reduced effort across routine development tasks are real benefits, but they are often offset by increased effort elsewhere in the project lifecycle.
The result is rarely a project that is simply “10 times faster”. It is more often a project with a different and potentially more efficient distribution of effort. Understanding where that effort has moved is now critical for organisations setting project expectations.
From Building Software to Shaping Behaviour
Traditional software development was largely about implementing rules. If one event occurred, the system performed a defined action. These systems could be complex, but their expected behaviour was generally straightforward to design, test, and validate.
AI systems change that model. Instead of only executing rules, they interpret information, summarise content, recommend actions, and generate responses. There is therefore rarely one perfectly correct output. There are instead outputs that are more or less useful, appropriate, accurate, or safe within a particular context.
As a result, the core development challenge is no longer just about building functionality. It is also about shaping behaviour.
Teams must define how the AI should respond, what it should prioritise, what it must avoid, which information it should rely on, and when human judgement must override it. This cannot be solved with a single prompt or configuration step; it requires iterative design, testing, evaluation, and refinement.
In practice, this introduces a new workstream: continually tuning AI behaviour until it is reliable enough to support real business activity. This also raises a more fundamental question about what it now means for software to “work”.
Working Software Is Not the Same as a Usable Solution
In traditional software, “working” is usually close to binary. A feature either performs its required function or it does not.
With AI, that definition becomes less clear. An AI feature can be technically correct, fully operational, and still be unsuitable for use in practice.
For example, an AI-generated proposal might be well-written, professionally structured, and grammatically correct, yet still fail in a real business setting because it:
- makes assumptions that are not valid for the customer
- uses language that does not match the organisation’s tone or risk tolerance
- omits important context a human would normally include
- produces different answers for similar inputs
- cannot clearly justify or explain its recommendation
The question is therefore no longer simply, “Does it work?” It becomes: Can we reliably act on this output in a real business context?
That is a much higher standard.
This is also where many AI initiatives slow down or stall. The problem is not necessarily that the technology has failed. Instead, the organisation discovers that “technically working” is not the same as being operationally safe, consistent, useful, and trusted.
A system that looks impressive in a demonstration is not automatically a system that will consistently improve a business outcome in production. Bridging that gap requires a different kind of effort and much deeper involvement from the people who understand the business process.
Testing and User Acceptance Become More Demanding
Because AI outputs can vary rather than following the same deterministic path every time, user acceptance testing changes significantly.
Users are no longer only checking whether the system performs an action correctly. They must also evaluate whether its outputs are accurate, complete, appropriate, consistent, and safe to act on.
This requires subject matter expertise, not just functional testing. In many cases, users are helping define what “good” looks like by reviewing real scenarios and applying professional judgement rather than following a fixed test script.
UAT therefore becomes more intensive, more subjective, and more central to the success of the project. Rather than being a final validation step performed shortly before release, it becomes part of the design and refinement process itself.
This naturally creates another challenge: adoption.
Adoption Requires More Than Training
AI systems introduce a different kind of user experience because their outputs are not always fully predictable or transparent. This creates a trust challenge for the people expected to use them.
Users may question whether the system is accurate enough to rely on, safe to use with sensitive data, consistent across different situations, or likely to reshape parts of their role. They may also worry that it will introduce additional checking and accountability rather than genuinely reducing their workload.
These concerns are not resolved through standard training materials or a short onboarding session. Users need a clear understanding of what the system is designed to do, how it produces its outputs, where its limitations sit, when human judgement is required, and how errors or concerns will be handled.
Without this clarity, adoption tends to be slower, more cautious, and more fragmented than expected, even when the underlying technology is strong. This hesitation is closely connected to another important change: the way risk is distributed across an AI project.
AI Changes Risk, Not Just Speed
AI can reduce some types of delivery risk by enabling faster prototyping and earlier validation. Teams can test ideas quickly and avoid investing in long development cycles before discovering whether a proposed approach is viable.
However, AI also introduces new categories of risk, including:
- inconsistent or incorrect outputs
- weak or incomplete underlying data
- unclear accountability for decisions
- privacy and security concerns
- over-reliance or under-trust from users
- ongoing governance and operational overhead
The project’s risk profile does not simply shrink; it shifts. The appropriate response is not to avoid AI, but to rebalance effort across the project lifecycle, with less time spent on manual development and more time allocated to validation, control, refinement, and adoption.
That change has direct implications for how software projects should be estimated and planned.
What Business Leaders Should Expect
As the nature of the work changes, the questions business leaders need to ask must also change. Rather than focusing primarily on how quickly the technology can be built, leaders should focus on the clarity and reliability of the intended outcome:
- What business problem are we actually improving?
- What does a good AI response look like in practice?
- Who will validate the outputs using realistic scenarios?
- Which decisions can the AI make, and which still require human approval?
- How will users build trust in the system?
- How will the solution be evaluated and refined after launch?
These questions will often determine success more directly than the speed at which code can be produced. In AI projects, delivery speed may no longer be the primary constraint; confidence in the outcomes often is.
Project Plans Must Reflect the New Reality
AI reduces effort in traditional coding, but it increases effort in other areas that are frequently underestimated:
- understanding and mapping business processes
- designing AI behaviour and instructions
- preparing and structuring data
- building evaluation and test scenarios
- defining governance and control mechanisms
- supporting user training and adoption
- refining the solution after its initial release
If this shift is not reflected in planning, projects will appear faster on paper than they are in reality. That mismatch often leads to systems that are technically impressive but not trusted, or systems that are delivered but never fully adopted.
Neither outcome produces the value the organisation expected.
Project estimates should therefore not be reduced simply because AI coding tools are involved. The estimate should instead be redistributed to reflect the real work required across discovery, development, validation, adoption, and ongoing improvement.
The Opportunity Is Still Significant
Despite the additional complexity, the opportunity remains substantial. AI allows organisations to build and iterate faster than before, and to deliver capabilities that may previously have been too expensive, slow, or complex to justify.
However, the main advantage is not just faster coding. It is what that speed makes possible: testing ideas earlier, involving real users sooner, refining solutions based on evidence, and concentrating effort on the business outcome rather than the mechanics of producing code.
In other words, AI shifts the opportunity from simply building software faster to learning and improving faster.
Software Is Faster. Change Still Takes Work.
AI has changed how software is built, but it has not removed the effort required to make software successful. Coding is faster, while defining behaviour, validating outputs, building trust, and enabling adoption now represent a greater share of the overall work.
The organisations that benefit most will be those that recognise this shift early and plan for it deliberately. Success will not come from building faster alone, but from building systems that work reliably in practice and are trusted by the people expected to use them.
If you are planning a build and want the estimate to reflect the full scope of work rather than coding alone that is what AI-First Development is designed to cover: behaviour design, validation, adoption and refinement, not just delivery. If the problem is still be defined, Discovery & Design is a better place to start.