Skip to main content
[email protected]
Mon–Sat: 9:00–18:15, Sun: closed
91 Nguyen Chi Thanh, Hanoi
Facebook X (Twitter) LinkedIn YouTube

What are you looking for?

Explore our services and discover how we can help you achieve your goals

AI-assisted software delivery: what changes for the buyer, and what must not

AI-assisted software delivery means engineers use AI tools to draft code, tests and documentation, and a named person reviews and owns every change before it ships. For the buyer, the contract, acceptance tests and ownership of the code stay the same. What changes is where review effort goes, which evidence you should ask for, and how you measure progress.

Submit a project See custom product engineering

Reviewed by David Nguyen (CEO) · Updated 28 Sep 2026 · 9 min read

star

OutsourcingVN is operated by Netbase JSC, which uses AI-assisted engineering in its own delivery and would like to deliver your project, so read this as a supplier explaining its own practice. The questions apply to any supplier.

Contents

What is AI-assisted engineering under human review?

It is a working practice, not a product. An engineer asks an AI coding assistant to propose a function, a test, a migration or a summary of an unfamiliar module. The engineer reads, edits and runs the proposal, and it enters the codebase only through the same review and version control as any other change. The accountable author is the person, not the tool.

Netbase delivers remote-first from Hanoi in Agile increments with weekly reviews, using AI-assisted engineering under human review. The project delivery page describes that process end to end; this guide looks at it from the buyer's chair.

This is different from automating your own business processes with AI, which the AI workflow automation guide covers, and different from the editorial rules for this site, which live on the methodology page.

What changes for the buyer, and what stays the same?

Area What stays the same What changes with AI assistance Evidence to request
Scope and contract Scope, milestones and acceptance are agreed as before Nothing in the contract should depend on which tools engineers use A clause naming who owns deliverables regardless of tooling
Code review Every change is reviewed before merge Reviewers read more generated code, so review needs time budgeted, not squeezed Merge history showing a named reviewer on each change
Ownership and IP Deliverables are assigned to the client as agreed Human authorship and review matter for how some jurisdictions treat protection of generated material Written confirmation of assignment and of tool terms that do not claim your code
Confidentiality Your code and data stay under NDA Prompts may carry code or data to a tool provider A list of approved tools and what may and may not be pasted into them
Security Secure coding practice applies Generated code can include plausible but unsafe patterns or invented dependencies Dependency checks, static analysis results and security review notes
Quality Tests and acceptance criteria decide "done" Tests are faster to draft, so coverage can rise, but generated tests can assert the wrong thing Test results tied to acceptance criteria, not only a coverage number
Measurement Progress is measured against milestones Lines of code and commit counts become even less meaningful Accepted stories, escaped defects and cycle time per milestone

Your acceptance criteria are the anchor. If acceptance is specific and tested, the tools used to reach it matter far less.

Which evidence should the supplier show during delivery?

  1. A tool register

    Which AI tools are approved, under which account terms, and whether prompts or code are retained by the provider.

  2. A data rule

    What may be pasted into a tool: typically no production data, secrets or personal data, and client code only under tools the client has accepted.

  3. Review on every merge

    A named reviewer approves each change; generated code gets no fast lane.

  4. Automated checks

    Tests, static analysis and dependency scanning run on every change, so an invented or vulnerable package is caught before merge.

  5. Weekly demonstration

    Working software shown against the stories agreed for that increment, not a list of files touched.

  6. Change records

    When a demonstration shows something outside scope, it goes through change control rather than being absorbed because it was quick to generate.

  7. Handover package

    Documentation, architecture notes and test instructions that a new team could follow without the original engineers or their tools.

NIST SP 800-218A, a community profile that extends the Secure Software Development Framework to generative AI, is a useful checklist for comparing a supplier's secure-development practice.

How does AI assistance affect IP and code ownership?

Contracts should assign ownership of deliverables to the client in the usual way, and the supplier should confirm that its AI tools' terms do not claim rights over the output or reuse your code for training. Separately, copyright protection for AI-generated material depends on human authorship in some jurisdictions; the US Copyright Office's 2025 report on copyrightability, published as part of its AI initiative, discusses this question. Human review, editing and integration of each change are part of how an engineering team keeps authorship with people.

This is a legal question for your advisers, not for a supplier's marketing. The IP ownership guide lists the clauses and handover items to check whatever the tooling.

Worked scenario: one two-week increment

A founder commissions a booking feature for an existing web product. The increment covers a calendar view, a booking form and email confirmation.

  • Day 1. The team agrees the stories and acceptance criteria. The tool register and data rule are already part of the project start pack.
  • Days 2-6. Engineers use an AI assistant to draft the form validation, the email templates and a first set of unit tests. Each merge request names a reviewer, who rejects one generated test because it checked the wrong time zone.
  • Day 7. Dependency scanning flags a suggested date library that is unmaintained. The engineer replaces it with the library already in the codebase.
  • Day 8. The mid-increment review shows the calendar. The founder asks for recurring bookings; the team logs it as a change request for the next increment rather than slipping it in.
  • Days 9-10. Acceptance tests pass on staging. The weekly review demonstrates the feature, and the handover notes are updated.

What the founder sees is ordinary delivery evidence. The AI assistance shows up as faster drafting and a busier review queue, not as a different contract.

How does this fit Netbase's delivery lifecycle?

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. AI assistance sits inside the execution stage; it does not remove discovery, milestones or support.

Netbase applies the ISO/IEC 42001 AI management system framework to its own AI delivery practice. That governs how Netbase teams run their own AI-assisted work; it is an applied practice rather than a certification, and it does not extend to a client's system. Netbase works with commercial and open-source AI models chosen per project, and no vendor partnership is implied.

A published record of milestone delivery is the classifieds platform with AI moderation. For a founder (not named), Netbase delivered a bilingual English and Nepali classifieds platform: requirements, design, Laravel backend with REST APIs, OTP accounts, paid ads, search, ratings, messaging, event ticket ads, blog and forum, payments, multi-language SEO and AWS deployment. The classifieds platform was delivered in six milestones over four months with training and six months of support.

Which questions should you ask a supplier?

  • Which AI tools do your engineers use, under which terms? Expect a short list and a clear answer on retention and training use.
  • What may never be pasted into a tool? Secrets, production data and personal data should be the minimum answer.
  • Who reviews generated code, and how is that recorded? Look for a named reviewer on each merge.
  • How do you catch invented or vulnerable dependencies? Automated scanning on every change is the expected answer.
  • What do you measure per milestone? Accepted stories and escaped defects, not lines of code.
  • Does anything in our contract change because of AI tools? Ownership, confidentiality and acceptance should not.
  • Could another team maintain the code without your tools? The handover package should make the answer yes.

What goes wrong with AI-assisted delivery?

  • Review squeezed by volume. Signal: large merge requests approved within minutes. Owner: the technical lead, who caps merge size and budgets review time.
  • Plausible but wrong tests. Signal: coverage rises while defects escape. Owner: QA, who ties tests to acceptance criteria.
  • Confidential material in prompts. Signal: no written data rule. Owner: the supplier's project manager, who publishes the rule at project start.
  • Scope creep because it was quick. Signal: features appear that no one requested. Owner: the product owner, who routes them through change control.
  • Knowledge held by the tool. Signal: engineers cannot explain a module without regenerating it. Owner: the technical lead, who requires design notes for every significant component.

Plan the next step for your project

Submit a project See custom product engineering

Common questions

It can shorten drafting of code, tests and documentation, but review, integration and acceptance still take time. Judge a supplier on accepted milestones rather than on claims about speed.

It should not be. Ask which tools are approved and confirm in writing that their terms do not retain or train on your code.

The supplier, exactly as for any other code it delivers. The reviewer who approved the change is accountable inside the team.

Yes. State it in the contract and expect the plan to reflect it. Some teams instead restrict tools to specific tasks such as tests or documentation.

No. The framework applies to the supplier's own management of AI work, not to the client's product, which needs its own assessment where regulation applies.

Bring your project and your questions about tooling

Start with the scope you have and any rules your organisation sets for AI tools. Custom product engineering is the delivery route. OutsourcingVN is Netbase's own outsourcing-services platform. Submit a project, and a person will reply with a delivery approach and the tool register that would apply.

Custom product engineering for a bounded release outcome 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
line

91 Nguyen Chi Thanh, Hanoi

+84 937 869 689

Tell us what you want to build or automate.

Submit a project