ReadyCIO
Menu

Playbook

Before you hire someone to build with AI

The questions to ask an AI-assisted developer or agency before work starts, what a good answer sounds like, and the red flags. About the people building your software, not the AI product you might buy.

For companies Updated October 3, 2026 ai strategysmall business softwarereviewing ai codesecurity

A developer with an AI coding tool can build in a week what used to take a quarter, and the quote will reflect it. That is good news, but it moves the risk. The code is the cheap part now. What you are really hiring is everything around it: whether anyone read it, whether you own it, whether it is safe, and whether anyone can keep it running after the person who built it moves on.

This is the list of questions to ask before work starts. It is for a freelancer, an agency, or the contractor a friend recommended. It is not about buying an AI product; for that, see seven questions to ask anyone selling you AI. If the builder is one of your own staff, use the inside version: the same moment with no contract, and three tiers so saying yes stays cheap. Each question here has what a good answer sounds like and a red flag. Click any question for the detail.

The rule underneath all of it: ask for something you can see. A file in the repository, a schedule, an account in your company’s name, a dated note. “We take quality seriously” is not an answer.

1. The problem, before the price

"What did you learn about how we work before you quoted?"

Good answer: they name a specific workflow, the person who does it, and what changes for that person.

Red flag: a list of features or technologies. If nobody looked at the work, the quote is for something, not for your problem. One services business had three quotes for “an AI system” and no way to compare them; two weeks of looking showed the biggest win was a quote follow-up that none of the three had proposed. Finding where AI actually pays off is the method.

"How will you make sure the AI builds what we meant?"

Good answer: before any code, the plan is interrogated question by question, with the business rules written down and agreed. The cheapest review happens before the code exists (make the tool interview you).

Red flag: “we’ll have something for you to look at by Friday” with no written scope. A fast demo built on a wrong assumption is the most expensive thing on this page.

"What will this save us, as a range?"

Good answer: how often the task happens, how long it takes, and how much of it the software actually removes, given as a low-to-high band. Coverage is the honest part: a person still reviewing the output means the task did not vanish.

Red flag: one precise number, or none.

2. How they build with AI

"Which AI tools write the code, and who reads it before it is merged?"

Good answer: named tools, and a named person who reads every change, helped by an automated reviewer on every pull request. Reading is the job now that typing is nearly free.

Red flag: “the AI is very good” or “we test it”. Neither is reading. AI-written code is rewritten within weeks at twice the old rate (instant legacy code); the review is what stops it.

"Where does your coding standard live?"

Good answer: a short instructions file in the repository that the tool reads at the start of every session, plus a linter that runs on every change (the coding standard is a file the tool reads).

Why it matters: a 2026 study of 441 repositories (RAMP, arXiv 2608.25241) found that code complexity rose about 53% where agents worked without a committed instructions file, against about 27% where one existed. It is a correlation, not proof, but it is the cheapest control on the list.

Red flag: “it’s in my head” or a wiki page.

"What has to pass before you call a change done?"

Good answer: type checks, lint, tests and a build that run automatically and block the change if they fail, and a second person who checks the app against what you asked for, not what the builder thinks it does.

Red flag: tests “when there’s time”, or a builder who is also the only tester.

"What can your AI tools see of our data and passwords?"

Good answer: the tools work on code and test data, not your live customer records. Passwords and keys stay in the hosting platform’s secret store, and the tool is blocked from reading them. Personal information goes into an AI tool only where you have authorised it, which is what Canada’s privacy regulators ask of any business using generative AI (the privacy rules that are about you).

Red flag: “I’ll need the production database password to get started”, or customer data pasted into a chat to “show the AI an example”.

"Which plan are your AI tools on, and does it train on our code?"

Good answer: a business or commercial plan, named. The difference is real. Anthropic’s commercial terms say it “may not train models on Customer Content”, while its consumer plans (Free, Pro and Max, including when used for Claude Code) train on data when the setting is on, and keep it for five years. GitHub’s Copilot Free, Pro and Pro+ plans use “inputs, outputs, code snippets” for training unless the user opts out, from April 2026; Business and Enterprise are not affected. OpenAI’s API does not train on what is sent to it unless the customer opts in.

Red flag: a freelancer using a personal plan for client work. Your code may be training someone’s model, and none of the vendors’ legal protections (below) apply to personal plans.

"What add-ons and plugins does your tool install, and who checks them?"

Good answer: the coding tool and its plugins are kept on a list and updated like any other dependency, because they run with access to your code. In September 2026, a flaw named Plugin4Shell showed that several AI coding agents would install plugin code that a version “pin” did not actually protect (your coding tool is part of your supply chain).

Red flag: blank look.

3. What you own

"Whose name is on the accounts?"

Good answer: the code repository, hosting, database, domain and every third-party service sit under your company’s accounts from day one, with the builder invited in. Billing comes to you. Section 1 of the infrastructure around the app is the list.

Red flag: “I’ll transfer it all at the end.” Things not transferred on day one are often never transferred.

"Who owns the code if the AI wrote most of it?"

Why it is not a silly question: copyright protects human authorship, and code produced from prompts alone may have none. The US Copyright Office said in January 2025 that copyright “does not extend to purely AI-generated material” and that “prompts do not alone provide sufficient control”; human-written parts, and human selection, arrangement and changes to AI output, are protected. The US Supreme Court declined to revisit the human-authorship rule in March 2026. In Canada, it is “an open legal question” (Osler, 2025): the Copyright Act does not define “author”, the case law points to a natural person, and the one court challenge to an AI co-authored registration has not been decided.

What that means for you: a standard clause assigning “all copyright” to you may transfer less than it appears to, because there may be no copyright in parts of the code to assign. The contract has to do the work instead (see “Put it in the contract” below), along with what you control in practice: the repository in your account, and the confidentiality of the code.

Good answer: “You own the repository from day one, the contract assigns you every right in the work including the AI-generated parts, and we keep the history of what people wrote and changed.” Version history that separates what the tool produced from what a person edited is the evidence of human authorship Canadian lawyers are now recommending clients keep.

Red flag: the builder keeps the repository, or licenses the code to you rather than assigning it.

"Could any of it be someone else's code?"

Why it is a fair question: AI tools occasionally reproduce existing open-source code nearly word for word, and open-source code comes with licence terms. GitHub says matches to public code typically occur in “less than one percent” of Copilot suggestions; an independent study of 14 models (LiCoEval, 2025) put it at 0.88% to 2.01%, and found most models “fail to provide accurate license information”. Small, but across a whole application, not zero. The lawsuit over it is not finished either: in September 2026 the US Ninth Circuit dismissed one claim against GitHub Copilot but left two breach-of-licence claims pending.

Good answer: three things. The tool’s public-code filter is switched on (Copilot’s setting reads “Block”). The build includes a licence scan and a list of every third-party component (a software bill of materials; ScanCode, FOSSA and Syft are common tools). And the builder is on a plan that carries the vendor’s IP indemnity: Copilot Business and Enterprise (only with the filter blocked), Anthropic’s commercial terms, OpenAI’s enterprise and API platform. Indemnities have conditions, so ask which ones apply.

Red flag: “it’s all original, the AI wrote it.”

"Where is the reasoning written down, not just the code?"

Good answer: a decisions file in the repository saying what was chosen and why, and a running set of notes on the gotchas found along the way. Git keeps the code; the reasoning leaves with the coder unless someone writes it down (what a company keeps when the coder leaves).

Red flag: “the code is self-documenting”.

4. How it runs safely

"When do you check security, and how?"

Good answer: a schedule, not a promise. A review at design, on every change, before the first real users, then automated scans on a timer, with findings turned into tickets (a security pass that runs anyway). Independent human testing at least once a year for anything that touches money or personal data.

Red flag: “we take security seriously”, or one test the week before launch.

"Where is the rule about who can see what enforced?"

Good answer: in one place, as close to the data as possible, so a new screen inherits it (where the rule lives).

Red flag: “each page checks”. The next feature will forget.

"How will we know it is broken before a customer tells us?"

Good answer: checks that run on real data and state what must always be true (“every paid invoice has a payment”), errors that record which release caused them, and a named person who gets the alert.

Red flag: “you’ll have a dashboard”, or “nobody has complained”.

"How do we undo a bad release, and when did you last restore a backup?"

Good answer: a described way to put the previous version back in minutes, database changes made so that old and new code both work for a while, and a dated note of a backup actually restored to a test copy. A backup nobody has restored from is a hope.

Red flag: “the hosting company backs everything up”.

5. What it costs after launch

"What counts as a bug, and who pays for it?"

Good answer: a written definition before you sign. A bug is behaviour that does not match what was agreed, or that breaks on ordinary input; that is theirs to fix within a warranty. A change of mind is a change request; a small preference tweak is polish; something that stopped working because a third-party service changed is maintenance. Four labels, each with who pays.

Red flag: no definition. Every post-launch conversation becomes an argument about which side of the line a request falls.

"What will it cost to keep running each year?"

Good answer: a yearly figure covering hosting, the AI and third-party services, updates, and a maintenance budget. The build has long been quoted at about a fifth of what software costs over its life, and AI shrinks that fifth, not the rest (the build is the cheap part).

Red flag: the quote ends at launch.

"How did you size this?"

Good answer: broken into pieces, each sized against past work, with a range. An AI estimate can be a useful second opinion (a 2026 study found ordinary language models sized tickets as well as purpose-trained models), but the correlation was moderate, and nobody should quote from the model’s number alone.

Red flag: a fixed price for a vague scope. Someone loses, and it is usually the scope.

6. If they leave

"If you disappeared tomorrow, what would the next developer open first?"

Good answer: a two-page handover document (what it does, where everything is, how to change it safely, what the alerts mean), the instructions file from section 2, and an offer to prove it: a second developer makes a small change using only those documents.

Red flag: “I’m not going anywhere”. Nobody plans to.

"Is your work covered by insurance?"

Why it matters now: insurers are rewriting policies around AI. In the US, Verisk’s standard generative AI exclusions for general liability became available in January 2026 and their definition names code; W. R. Berkley introduced an exclusion for E&O covering “any actual or alleged use, deployment, or development of Artificial Intelligence”. Canadian brokers describe three approaches in today’s E&O wordings: silent, affirmative, or exclusions, and one warned in September 2026 that an AI endorsement “does not necessarily mean better” coverage.

Good answer: a certificate for professional liability (errors and omissions) and cyber insurance, and a straight answer, ideally from their broker, on whether the policy wording excludes or caps work produced with AI tools.

Red flag: “I don’t need insurance, it’s a small job”, or a certificate nobody has read for AI wording.

Red flags in one place

  • Speed is the headline of the pitch.
  • Accounts in the builder’s name, “transferred at the end”.
  • “The AI handles the testing”, or no second person who checks.
  • No written definition of a bug.
  • A request for live customer data or production passwords to get started.
  • No answer to “where is the who-sees-what rule enforced?”
  • A quote that ends at launch.
  • Client work done on a personal AI plan.
  • No public-code filter, licence scan or component list.
  • No insurance certificate, or nobody has read it for AI wording.

Put it in the contract

Most published checklists are about buying AI products or off-the-shelf software: the US Secure by Demand guide asks software makers about default passwords, logs and component lists, and Canada’s federal guidance is written for public servants. Almost none cover who owns AI-written code or whether someone else can maintain it. So the contract has to. A short list to give your lawyer, not a substitute for one:

Ownership that does not depend on copyright.

An assignment that covers AI-generated output on its own terms. US firm Venable warned in July 2025 that labelling AI-generated work “works made for hire” “may be ineffective”, and recommended an assignment of AI tool-generated works “independent from the works-made-for-hire doctrine”. The same caution applies to a clause that assigns only “all copyright”, since some of the code may have none. Pair it with a confidentiality clause, because keeping the code secret protects it whether or not copyright does.

The repository and accounts are yours.

Repository, hosting, database, domain and third-party services in the company’s name from day one, with the builder’s access removable.

Disclosure of the AI tools and the plan they are on.

Named tools, business or commercial plans only, no training on your code, and no live customer data in any tool without written approval.

Warranties and indemnities that name the AI output.

The builder warrants the work does not knowingly include third-party code in breach of its licence, and keeps the vendor protections that depend on settings (such as Copilot’s filter) switched on. Canadian counsel suggest allocating this risk explicitly, separating the system from its outputs.

A written bug definition and a warranty period.

The four labels from section 5, who pays for each, and how long the builder fixes bugs at no cost.

Handover as a deliverable.

The handover document, the instructions file, the decisions file and a successful restore are part of “done”, with the final payment tied to them.

Insurance.

Professional liability and cyber certificates, with any AI exclusion or sublimit disclosed.

This playbook is a buyer’s checklist, not legal advice. The law on AI and copyright is moving; check the current position with a lawyer before you sign anything large.

If they can answer all of these

You are probably talking to a good builder, and you are a better-prepared buyer than most. Keep the answers. They become the first page of the handover document, and the checklist for the infrastructure around the app when the build is done.

Changelog

  • 2026-10-03: first version.
  • 2026-10-03: quotes checked against the original pages; Venable’s point narrowed to “work made for hire” wording; published.