An engineer opens Copilot to help draft code for a client’s site. Within seconds, they receive code that would’ve previously taken significantly longer to write manually. For many web developers and businesses optimizing their websites, it’s normal to wonder: is that code reliable? Is it secure? Should it be reviewed before implementation? These questions all fall under the umbrella of one query: Who will be held accountable for AI-assisted coding? And, most importantly, who owns the productivity gain?
If AI allows an engineering team to complete more work in the same amount of time, then everybody can benefit more from that economic value. This could be the developer saving time, the employer getting more value from saved hours, or the client receiving what they paid for with hours to spare. Regardless of how the saved time benefits, what remains top of mind is how the work is governed and priced.
AI and Coding is Becoming Unavoidable
AI coding tools are quickly gaining traction and making headway into mainstream development. According to the 2025 Stack Overflow Developer Survey, 84% of respondents were using or planning to use AI tools in their development process.
Although implementing AI into web developers’ workflows is becoming more common, there is still hesitation about its reliability. The same survey found that 46% did not have full confidence in the accuracy of AI output, and approximately 66% cited AI solutions that were “almost right, but not quite” as a source of frustration.
The AI coding debate that is taking shape is more about its reliability than about whether that code creates more value and who is accountable for ensuring it does.
AI Is Breaking the Relationship Between Hours and Output
Compensation for software development always relied on the assumption that engineering output was closely related to engineering effort. However, generative AI now complicates that equation.
A controlled experiment involving 95 developers found that participants with access to GitHub Copilot completed a specific JavaScript HTTP server task 55.8% faster than those without access.
This highlights that AI can accelerate development, potentially without sacrificing quality. But these figures are only successful because the experiment followed a very specific programming task. Although the task was completed faster, it does not mean Copilot makes an entire engineering organization 55.8% more productive.
Another research study exemplifies this idea. A trial involving 96 full-time Google software engineers found that developers using AI completed an enterprise-grade task in about 96 minutes, compared with 114 minutes for those without it. The researchers’ adjusted estimate suggested approximately a 21% reduction in completion time. However, the study did not explore the quality of the AI code, nor did it address questions of equity regarding reliance on the technology.
There is also evidence of AI slowing down coding time. A randomized study by METR involved 16 experienced open-source developers who worked on 246 real issues in repositories they knew well. Using tools available in early 2025, including Claude Sonnet 3.5 and 3.7, as well as Cursor Pro, they took approximately 19% longer to complete their tasks, even though many assumed these tools would save time.
Together, these studies subvert the expectations that AI enables developers to work faster. Instead, it’s making developer time and value less predictable for businesses that offer web work and for the clients who receive it.
The Pricing Problem Nobody Talks About
Time & Material (T&M) is a common model in web development for purchasing software, as it addresses a recurring industry problem: an evolving project.
With this model, instead of requiring every feature or task to be defined before development begins, clients can pay for engineering time as the project progresses and changes.
However, AI is creating hiccups in that tried-and-tested model. With compensation directly tied to engineering hours, more efficient development time can result in fewer billable hours for clients. If AI supports the same results in less time, the technology can create value for clients, but the reduction in billable hours means less revenue for providers.
The solution isn’t to encourage developers to work more slowly. The T&M model now faces a structural issue with how pricing and incentives are designed. Using hourly rates to determine value can be limiting. A buyer might know exactly what each engineering hour costs yet remain uncertain about the total investment required to achieve their desired outcome.
As AI changes engineering productivity, the question may shift from:
“What does a developer hour cost?” → “What happens to the value when fewer developer hours are required?”
The METR findings complicate this question. If developers believe they can save time when, in reality, they take longer, neither AI adoption nor perceived productivity is sufficient to demonstrate financial value. That’s why organizations need governance that can measure what actually happened.
The Governance Gap Has Four Owners
Discussing governance around AI-assisted development needs to go beyond policies that govern which tools developers can use.
There are at least four types of ownership engineering organizations should define.
1. Who owns the code?
AI can generate an implementation, but it cannot become an excuse for accountability-free development. Someone still needs to be accountable for reviewing, testing and approving the code until it reaches the production stage.
2. Who owns the risk?
Faster code is only valuable if it doesn’t cause problems elsewhere. An empirical study of AI-generated code identified security weaknesses in 29.5% of the examined Python snippets and 24.2% of JavaScript snippets. The research also identified weaknesses spanning 43 Common Weakness Enumeration categories.
However, the study found that feeding static-analysis warnings back into Copilot Chat could fix up to 55.5% of the identified security issues. The research shows how AI can create and resolve coding problems, but organizations need processes in place to determine how to validate its output.
NIST’s SP 800-218A reflects this principle by extending its Secure Software Development Framework with best practices that address generative AI and dual-use foundation models.
3. Who owns the productivity gain?
Commercial agreements from the start are essential in determining who should receive the efficiency gains. AI can help clients spend less, enable teams to deliver more software, or provide no financial benefit by the end of the project.
What remains the same is the need for transparent processes and delivery of quality, agreed-upon work.
4. Who owns prioritization?
AI can make generating features cheaper and faster, but it cannot decide whether those features are required.
In fact, increasing development capacity may make prioritization more important. When teams can build and experiment faster, somebody still needs to determine which outcomes justify the available budget, and which ideas should be abandoned.
AI Governance Is Becoming a Finance Issue
These questions make AI governance increasingly relevant. Imagine two development partners charging similar hourly rates.
One has integrated AI into a strong engineering process and achieves the required outcome considerably faster, while the other takes longer. Comparing their hourly rates alone does not tell the buyer much about the processes they will perform.
Buyers will need to evaluate:
- Total expected investment
- Responsibility for overruns
- Quality controls around AI-generated work
- How efficiency gains are shared
T&M can remain useful for both parties if they knowingly accept uncertainty in the services. Fixed-price arrangements can also work when requirements and deliverables are stable.
But AI also makes alternative structures worth examining. One approach is to establish a maximum financial boundary while keeping scope flexible. Then, features can be prioritized according to business value within that model.
If engineering becomes more efficient, gains can translate into additional product capability rather than additional billable time. Commercial incentives should encourage the same outcome as engineering incentives, creating more useful software as efficiently as possible.
The Same AI Conversation
Engineering leaders need to understand how commercial incentives influence delivery. Finance and procurement teams need sufficient visibility into AI-assisted engineering to assess whether claimed efficiency is delivering measurable value.
That means mature AI governance cannot stop at approved model lists, security controls, data policies, or code review requirements. It needs to address accountability, financial risk, prioritization and ownership of productivity gains.
But there is a second ownership question that could have a much greater impact on technology budgets: Who owns the value created or lost when AI changes how quickly software gets built?
The organizations that determine whether faster engineering actually produces better products, control investment, and achieve measurable business outcomes will be the ones able to stay ahead of competitors.
If your development team adopted AI tomorrow, would your current governance and commercial model even tell you whether it had made delivery more valuable?
