Ask how AI touched your code, then write the answer into the contract.

Ask the question nobody's proposal answers

A proposal arrives. It covers the stack, the timeline, the team, the hourly rate and the support plan. What it almost never covers is how the code will actually get written, and these days that usually involves AI tools somewhere along the way.

That isn't a scandal. Used well, AI tools help good developers move through routine work faster and spend more of their attention on the parts that need judgment. Used carelessly, they produce code nobody on the team fully understands, pull in libraries nobody chose on purpose, and leave you unsure what you own.

You can't tell which kind of team you're hiring from the proposal. You can tell from a twenty-minute conversation. What follows is the script we'd use if we were on your side of the table: four questions, what a reassuring answer sounds like, what should make you lean in, and what to write down afterwards.

One caveat before we start. This is practical buying advice from people who build software. It isn't legal advice, and the contract language at the end is something to take to your lawyer, not a substitute for one.

Question one: where does AI show up in your work?

You're listening for specifics. A reassuring answer names tools and tasks. "We use an assistant in the editor for completions and small refactors. We use a chat tool to explain unfamiliar legacy code and to draft tests. We don't let it write database migrations or anything touching payments without a senior developer driving." Some of that may be different from what you'd choose, and that's fine. The point is that they've thought about it.

Two answers deserve a follow-up. The first is "we don't use AI at all." It might be true. It's also hard to verify, and it sometimes means individual developers use whatever they like without a team rule. Ask whether there's a policy and what it says.

The second is the sales pitch: "AI writes most of the code now, which is why we're so fast and so cheap." Speed is good. But a team that leads with how little human time goes into your code is telling you where it plans to save money. Ask what the humans spend their time on instead.

Question two: who reads the code before it reaches us?

This is the question that matters most, and it's the same question you should have asked before AI tools existed. Every change should be read by someone other than its author, someone who could explain what it does and why, before it's merged. Tests should run automatically. The standard shouldn't depend on whether a person or a tool typed the first draft.

A good answer describes the actual process. Pull requests, a named reviewer, automated tests, a check on new third-party packages. Ask them to walk you through a recent review on a project they're allowed to show. You'll learn more from five minutes of that than from any slide. The question isn't whether your developer uses AI. It's whether a person who can explain the code stands behind every line of it.

One AI-specific thing to ask about is dependencies. Coding assistants sometimes suggest a library that doesn't exist, or one whose name is close to a popular package. A careful team checks that every new package is real, maintained and the one they meant to add. A team that has never thought about this probably hasn't been bitten yet.

Question three: what goes into the tools?

Your code, your data and your secrets can all end up in a prompt. Ask which tools the team uses under company accounts, whether those accounts are set so your code isn't used to train the provider's models, and how long the provider keeps it. You don't need to read the terms yourself, but you should hear that someone on their side has.

Then ask about data. Production customer data should never be pasted into a general-purpose tool to "see what's wrong." Passwords, keys and access tokens should never be in a prompt at all. A reassuring answer is boring: "We work with test data, our accounts have training turned off, and secrets live in a vault that the tools can't see."

If your business handles health, payment or other regulated data, this question gets sharper, and your own compliance people should hear the answer directly.

Question four: what will we own when you're done?

Most clients assume the answer is "everything." It's worth checking, because AI adds a wrinkle.

In January 2025, the U.S. Copyright Office published its report on the copyrightability of AI-generated output. Its conclusions, in plain terms: material generated purely by AI, or without enough human control over its expressive elements, isn't protected by copyright. Prompts alone don't count as enough control. Human work that selects, arranges or modifies AI output can be protected, and the question is decided case by case. You can read it at copyright.gov/ai.

For most business software, the practical consequence isn't dramatic. What protects you is mainly the contract: the developer assigns you every right they have in the work, promises they had the right to deliver it, and promises the code was reviewed and is theirs to hand over. Meaningful human authorship, the kind that comes from real review and real design, also helps.

Two more things belong in this conversation. AI tools can occasionally reproduce code that carries an open-source license, so ask how the team checks licenses on what they ship. And ask what happens if a claim does arise. Who is responsible is a question for the contract and your lawyer, but you want to know it was discussed.

Write the answers down

A good call is worth very little if the answers live only in your memory. Turn them into a short appendix to the contract, in plain language:

• Tools. The AI tools the team may use, under which accounts, with which settings.
• Review. Every change is reviewed by a qualified person other than its author before it's merged, and tests run automatically.
• Data. No production personal data and no credentials go into AI tools. Test data only, unless you agree otherwise in writing.
• Ownership. Assignment of all rights in the deliverables, a warranty that the developer has the right to deliver them, and a license check on third-party and open-source code.
• Notice. The developer tells you before any of the above changes.

None of this is exotic. It's the same discipline good teams already follow, written where both sides can see it. If a developer pushes back on writing down what they say they already do, that tells you something too.

We build custom web applications this way: AI where it helps, a person who can explain every change, and a handover you can trust. If you're comparing proposals and want a second opinion on what you're being told, tell us what you're weighing.

Related work: Howcast.