AI-assisted delivery: what it changes in a software estimate
When a team uses AI coding agents, the estimate lines for drafting code, tests, scripts and documentation can shrink. Discovery, integration, environments, review and acceptance shrink little or not at all, because they wait on people, other systems and evidence. Read such an estimate line by line, never as one percentage applied to everything.
Submit a project See custom product engineeringReviewed by Huy Nguyen (David), CEO · Updated 13 Nov 2026 · 9 min read
This guide is for CTOs, founders and procurement leads who receive estimates from teams that say they work with AI agents. OutsourcingVN is operated by Netbase JSC, which estimates projects this way itself, so the page is written by a supplier; the reading method applies to any estimate. What AI-assisted delivery is, and which controls it needs, is covered in the AI-assisted software delivery guide. This page is about the numbers in the estimate, and it belongs to the guide on AI-native development cost and delivery speed.
Contents
- Which estimate lines shrink when a team uses AI agents?
- Which lines do not shrink, and why?
- How does each estimate line respond?
- Why does felt speed mislead an estimate?
- How do you read an estimate from a team that uses AI agents?
- A worked example
- What should the contract say about AI-driven estimates?
- How does Netbase estimate AI-assisted work?
- How this guide is sourced
- Common questions
- Bring the estimate you want to read
Which estimate lines shrink when a team uses AI agents?
The lines that shrink share one property: the work is mostly producing text against a clear specification, and a person can check the result quickly.
- Routine feature build. Forms, CRUD screens, API endpoints and their validation, when the behaviour is already written down.
- Unit and integration test drafting. Agents produce test cases quickly; choosing what must be proven stays with the engineer.
- Migration and transformation scripts. The script, once the mapping rules are agreed.
- Refactoring with good test cover. Mechanical changes across many files, checked by an existing test suite.
- Documentation. First drafts of API references, runbooks and handover notes generated from the code.
- Reading unfamiliar code. Explaining a legacy module before changing it, which used to be a hidden line inside every estimate for an existing system.
How much these lines shrink depends on the codebase, the clarity of the specification and the team's working method. No published figure transfers from one project to another, so treat any fixed share with suspicion.
Which lines do not shrink, and why?
- Discovery. Workshops, decisions and sign-off run at the speed of your stakeholders. An agent can draft stories; it cannot decide which ones matter.
- Integration with other systems. Access requests, sandbox accounts, vendor documentation that does not match the live API, and replies from another organisation's team.
- Data work. Profiling, cleaning rules and reconciliation need people who know what the data means. The data migration planning guide lists the decisions involved.
- Environments and release. Security approvals, production access and release windows are organisational, not typing.
- Review. More generated code means more code to read. Review is the line that often grows.
- Acceptance. Your people testing increments against acceptance criteria and saying yes or no.
- Change control and coordination. Meetings, decisions and re-planning when something changes.
How does each estimate line respond?
| Estimate line | Effect of AI agents | Watch out for |
|---|---|---|
| Discovery and scope | Small: faster drafts only | Scope drafted but not decided |
| Feature build | Can shrink where specs are clear | Same cut applied to unclear features |
| Test drafting | Can shrink | Tests that check the wrong thing |
| Scripts and refactoring | Can shrink with good test cover | Changes with no tests to check them |
| Integration | Small: waits on other systems | Third-party delays left out |
| Data migration | Script work only | Cleaning and sign-off left out |
| Environments and release | Small | Access and approvals left out |
| Code review | Often grows | Review time missing from the plan |
| Acceptance | None on your side | Your team's time not counted |
| Handover | Drafting shrinks, transfer does not | Notes no one has walked through |
Why does felt speed mislead an estimate?
An estimate is a prediction, and AI assistance is easy to over-predict. In METR's randomised study of experienced open-source developers, published on 10 July 2025, "developers expected AI to speed them up by 24%, and even after experiencing the slowdown, they still believed AI had sped them up by 20%". The measured result in that study was the opposite: with AI tools allowed, developers took 19% longer to complete issues. METR has since said these early-2025 results are out of date and that developers are likely more sped up from AI tools in early 2026; the lasting lesson for estimating is the gap between how fast work feels and how fast it is.
The DORA 2025 report on AI-assisted software development points the same way from the organisation's side: it describes AI as an amplifier of existing strengths and weaknesses. A team with a clear process will see its estimate lines shrink; a team without one will see the same lines move without the delivery improving.
So an estimate that is lower "because of AI" should show where the reduction sits and on what evidence it rests: the team's own measured history on similar work, or a first increment on yours.
How do you read an estimate from a team that uses AI agents?
-
Ask for the line items
One total, or a single percentage off, is not an estimate you can test.
-
Find the human-paced lines
Discovery, integration, data work, environments, review and acceptance should look as they would without agents. If they are smaller, ask what changed.
-
Check where the reduction sits
It should sit on build, tests, scripts and documentation, and be larger where your specification is clear.
-
Look for review time
A credible estimate from an AI-native team names review effort; if it is missing, it will be taken from somewhere else later.
-
Ask for the evidence behind the reduction
Measured history on comparable work, or a first paid increment that tests the assumption on your codebase.
-
Count your own effort
Acceptance, decisions and subject-matter time are on your side and do not shrink; the total software delivery cost worksheet has rows for them.
-
Compare on the same scope
Map competing estimates to one activity list before comparing totals, and compare role mixes with the rates-by-role guide.
(opens the full-size diagram in a new tab)
A worked example
A retailer asks two teams to estimate an order-management module with a warehouse integration and a data migration from the old system. The example is illustrative and describes no client.
The first estimate takes the team's usual figure and removes the same share from every line, citing AI agents. The second keeps discovery, the warehouse integration, data cleaning, environments and acceptance close to a conventional estimate, reduces feature build, test drafting and the migration scripts, and adds an explicit line for code review. Its total is higher than the first.
In delivery, the warehouse vendor takes two weeks to issue sandbox credentials and the retailer's operations lead accepts increments once a week. The first plan slips on exactly the lines it cut, and the overrun arrives as change requests. The second plan holds because its reductions sat where agents actually help. The lower estimate was never the cheaper project.
What should the contract say about AI-driven estimates?
Nothing special about tools, and a lot about scope. Under a fixed scope, the supplier carries the estimate, so an optimistic AI assumption is the supplier's risk until it turns into change requests; under milestones, each re-estimate is a chance to test the assumption against delivered work. The fixed-scope versus milestone contracts guide compares the two. Either way, route anything added because "it was quick to generate" through change control, so cheap drafting does not become unplanned scope.
How does Netbase estimate AI-assisted work?
Netbase delivers remote-first from Hanoi in Agile increments with weekly reviews, using AI-assisted engineering under human review. An estimate therefore reflects agents where they draft and reviewers where they check, and keeps the human-paced lines at their own size.
Netbase's delivery lifecycle: discovery and strategic alignment; team assembly and architecture planning; agile execution with outcome-based milestones; modular components; training and rollout; ongoing support. The estimate follows from discovery, and each outcome-based milestone gives both sides evidence of how the reductions held. Custom product engineering is the delivery route, and what drives Vietnam software outsourcing cost covers the other drivers of the total.
How this guide is sourced
The expected, believed and measured effects of early-2025 AI tools come from METR's study post of 10 July 2025, including its note that the results are out of date. The amplifier finding comes from the DORA 2025 report page. Netbase statements are approved claim-register entries, reviewed as the methodology describes. The order-management example is illustrative.
Plan the next step for your project
Common questions
There is no fixed share. Expect reductions on build, tests, scripts and documentation, sized by the clarity of your specification, and little change elsewhere.
Often because it counts review time and keeps integration and acceptance at a realistic size. Compare line by line before reading the total.
You can ask where reductions sit and why. A line-by-line estimate answers that better than a separate discount.
Only where the critical path runs through drafting work. If the path runs through integration or acceptance, the calendar barely moves.
Measured history on similar work, or a first paid increment on your own codebase that tests the assumption.
Talk to Huy Nguyen (David), Founder and CEO of Netbase JSC: message him on WhatsApp at +84 937 869 689 or email project@netbasejsc.com. You can also send your brief through the project request form. Say which workflow or system the project concerns and what has to stay unchanged; the first step is a discovery conversation, and scope and milestones are agreed after it.
Bring the estimate you want to read
Start with the estimate you have and the scope behind it. The buyer guide to outsourcing a software project covers the wider decision.
OutsourcingVN is Netbase's own outsourcing-services platform. Submit a project with the scope and the lines you want checked, and a person will reply with the questions an estimate should answer.
Related services and solutions
Custom product engineering for a bounded release outcome
One defined release of your product, built to named outcomes and handed over with acceptance evidence.
Learn More