How to hire a developer who uses AI coding tools: questions to ask
Almost every developer now uses an AI coding tool, so the tool is no longer the thing to hire on. What matters is the process around it: who reads each change, what stops a bad one reaching production, who owns the result and where your data goes. This article gives you ten questions with what a good answer sounds like, a way to review a proposal, a list of things to ask to see, the contract points that matter and a shape for a paid pilot. Skofi sells this kind of work. We have written it so that it is useful if you are comparing any provider, including us.
By Saveez IrfanUpdated
In short
- Hire on the process, not the tool. Using Claude Code, Cursor or Copilot is not a qualification; the same tool in careful and careless hands produces very different software.
- The good sign is a named person accountable for every merged change, tests whose expected outcomes a person wrote for money and permission paths, and a repository in your name from the first commit.
- The red flag is a speed claim with no mention of review, tests or handover, or a reluctance to show any of them.
- Put four things in the contract: you own the code and accounts, a defined handover, a clear line on who pays for tooling and runtime API usage, and a written limit on what data goes to model providers.
- Run a short paid pilot on a real, bounded slice, with the repository in your organisation and acceptance tests written first. It tells you more than any proposal.
- We sell this work, so test us with the same ten questions. Two of our case studies are relevant: the school ERP, built with Claude Code, and the materials marketplace, which began on an AI app builder. Read both and ask us anything they leave out.
What should you hire on when everyone uses AI tools?
Hire on accountability. AI tools change how quickly code is drafted, not who is responsible for it. Anthropic's security guidance for Claude Code says that you, the user, are responsible for reviewing proposed code and commands before approving them. A developer who takes that seriously will have a process you can inspect. One who does not will have a speed claim.
Three things separate good from risky. First, review: a named person reads every change before it merges, and can show you evidence of it. Second, checks that do not depend on the tool: tests and a continuous integration run on a clean machine, with expected outcomes that a person wrote for the parts that move money or enforce permissions. Third, ownership: the repository, hosting and keys are in your name, and another engineer could take over without calling the original. Everything below is a way of testing those three.
A disclosure before we go on. Skofi sells Claude Code development, custom software and AI-built app rescue, so we have a direct interest. We use Claude Code ourselves and build on Claude through its API. We are not an Anthropic partner and nothing here is endorsed by Anthropic. This article names no other provider, and the questions work on any of them.
| Area | Good sign | Red flag |
|---|---|---|
| Role of the AI | It drafts, explains and writes tests. A named person is accountable for each merged change | 'The AI does it' offered as the reason the work is fast and cheap, with no mention of who checks it |
| Speed claims | Says where the tool saves time (boilerplate, first drafts, reading old code) and where it does not (design, business rules, review) | A dramatic speed-up promised in general terms, with no evidence from comparable work |
| Tests | A person states the expected outcomes for billing, permissions and deletion before the code is written | Tests written by the tool to match its own code, and a coverage number offered as proof |
| Secrets and data | Production credentials never reach the tool; keys are separate for test and live | Pasting keys or production data into a chat is described as normal |
| Ownership | Repository and hosting accounts created in your name at the start | Code lives in the developer's account 'for now', or in the AI tool's own workspace only |
| Honesty about limits | Can name a job they would not give to an AI tool, and a time the tool was wrong | The tool can do anything, and nothing has ever needed correcting |
| Handover | Describes the runbook, the deploy and rollback path and how a second engineer takes over | Handover is mentioned only as 'we can walk you through it' |
| Price | Tied to scope and acceptance criteria, and explained either way | A price that cannot be explained, whether it is high or low. Use of AI is not a reason for either on its own |
What are the ten questions, and what does a good answer sound like?
Ask these in a call and again in writing, since a proposal should answer them. A good answer is specific to your project. A weak one could have been given to anyone.
| Question | A good answer sounds like | A warning sign |
|---|---|---|
| 1. Which AI tools do you use, for what, and what do you not let them do? | Names the tools, the jobs (drafting, tests, reading legacy code) and the exclusions (production access, unreviewed migrations, business rules nobody wrote down) | Lists tools and nothing else. Or says the tools do everything |
| 2. Who reads every change before it merges, and can I see a recent pull request? | A named reviewer who is not the author; shows a pull request with comments or changes requested | Reviews are 'on the roadmap'. Nothing can be shown, even redacted |
| 3. What tests will exist on my project, and who writes the expected outcomes for money and permission logic? | A person writes or approves the expected outcomes in plain English first; tests run on every change in CI | 'The AI writes the tests.' A coverage figure is the only evidence offered |
| 4. How do you keep secrets and production credentials away from the tool? | Separate keys for test and live, secrets never committed, environment files denied to the tool, production never connected | Not a question they have thought about, or the answer is 'we are careful' |
| 5. What leaves my systems? Which model providers see my code or data, under what plan and terms? | Names the provider and the plan, says what is never sent (production data, credentials, personal data) and offers it in the contract | 'It's all private.' No awareness of the difference between consumer and commercial terms |
| 6. Where will the code and accounts live, and who owns them from day one? | A repository in your organisation and hosting, database and domain accounts in your name from the first commit | The code sits in their account until final payment |
| 7. Tell me about a time the AI tool got something wrong that you caught. | A concrete example: a loosened database rule, an invented package, a test changed to pass, and what they did about it | 'It rarely gets anything wrong.' No example |
| 8. How do you price this, and who pays for tools and runtime AI usage? | Explains the basis (fixed for defined outcomes, or time and materials with visible work). Their own tooling is their cost of doing business, runtime API usage runs on your account under a spend cap | Vague on both. Or tool and usage costs appear later as a surprise |
| 9. What will I receive at the end, and could another engineer take over without calling you? | Repository, tests, README, deploy and rollback steps, a rotated-key procedure, a restore procedure and a list of known gaps | 'Documentation' with no detail. The answer depends on them being available |
| 10. What would make you tell me not to build this, or to buy something instead? | Gives real conditions: a product already fits, the process is not written down, the data needs specialist assessment | Nothing would. Every problem is a build |
Question 10 tells you more than it appears to. Our own build-or-buy article starts from 'buy by default', and a provider who cannot say when they would advise against building has a conflict they have not mentioned.
How do you review a proposal?
Read a proposal for the sentences that could not have been written without hearing about your business. A proposal made of general claims about speed and modern tooling tells you about the template, not the team. Then check it contains each of the following.
- Your problem restated in your words, and what is out of scope as well as what is in.
- Acceptance criteria you could test yourself, such as 'a branch manager cannot read another branch's records', not 'a secure system'.
- How AI tools are used and not used, and who reviews the output. A named person, not a department.
- The test and CI approach, and the staging environment where you can try changes before they go live.
- Who does the work. If a subcontractor or a second team is involved, they are named.
- What you must supply: access, decisions, sample data, a person who can answer questions in a day.
- Milestones tied to something you can see working, not to elapsed time alone.
- Handover contents, ownership of the repository and accounts, and what happens after launch (who fixes what, on what basis).
- A data-handling statement covering what goes to model providers.
- Assumptions and risks, including what would change the price.
Be wary of two opposite mistakes. Do not assume AI use makes a quote too high or too low. Compare quotes on scope, acceptance and evidence of review. And do not let a long list of tool names stand in for any of the above.
What should you ask to see?
Ask for evidence from a previous project or from the provider's own product. Client work is often under confidentiality, so accept a redacted sample or a screen-share instead of nothing, and expect a serious provider to have something they can show. If they have nothing at all to show, that is information too.
| Ask to see | What a good sign looks like | Why it matters |
|---|---|---|
| Tests and a CI run | A passing run on a clean machine that includes tests on money and permission paths, and a failing run that someone fixed | The check that does not depend on anyone's laptop or on the tool's own account of its work |
| A pull request with review history | A different person approved it. Comments, requested changes, small diffs. Tests that changed alongside code, with a reason | Shows that review happens and has teeth |
| Branch protection settings | The main branch accepts changes only through an approved pull request with required checks | Stops an unreviewed change, human or AI, reaching live |
| Repository and account ownership | A sample set-up in which the client is the owner or administrator and the developer a collaborator | You cannot be locked out of your own system |
| Secrets handling | No secrets in the repository history, secret scanning turned on where the host offers it, separate keys per environment | A key pasted into a chat or committed to version control should be treated as burned |
| Project rules for the AI tool | A committed instruction file and shared permission settings. For Claude Code these are CLAUDE.md and .claude/settings.json, shared through version control | Shows the safe way of working is written down, though a rules file is context, not enforcement |
| Deployment and rollback | Separate staging and live, deploys from version control, a rehearsed way back | You can recover from a bad change at night |
| A previous handover pack | A README, a runbook covering deploy, rollback, key rotation and backup restore, and a list of known gaps | Tells you what you will receive in place of a promise |
What belongs in the contract?
These are the points worth agreeing in writing. They are prompts for a conversation with a lawyer, not legal advice, and the right wording depends on where you and the developer are based.
| Point | What to ask for |
|---|---|
| Code ownership | Assignment of the rights in the deliverables to you, covering AI-assisted parts, with a clearly listed carve-out for the developer's pre-existing tools, licensed to you for continued use. A list of the open-source licences of direct dependencies. Whether AI-generated output can be owned at all depends on the law where you are and on each tool's terms; for example, Anthropic's commercial terms say that, to the extent the law permits, the customer owns the outputs. Ask about every tool used, since we have read only that vendor's terms for this article |
| Repository and accounts | Repository created in your organisation from the first commit. Hosting, database, domain and third-party accounts in your name, with the developer added as a collaborator |
| Handover | A defined list: repository, README, schema notes, a list of environment variable names (not values), how to deploy, roll back, rotate a key and restore a backup, and known gaps. Final payment tied to receiving it, and a walkthrough with a second engineer if you have one |
| Who pays for AI tooling | The developer's own subscriptions and usage are normally their cost of doing business, unless the contract says otherwise. Say so explicitly. Do not accept tooling charges that appear later without agreement |
| Who pays for runtime AI usage | If the finished app calls a model, its API usage belongs on an account in your name, with a spend cap and an alert. Anthropic's documentation says Claude Code usage on the API is charged by token consumption, that per-developer cost varies widely, and that a small pilot group is the way to establish a baseline. The same logic holds for your app: estimate its usage from a pilot, not from a promise |
| Data sent to model providers | A written list of what may be sent (source code, perhaps) and what may not (production data, personal data, credentials). The provider and the plan type named. A duty to tell you before that changes. Plan type matters: Anthropic's documentation says consumer plans let the user choose whether data is used to improve future models, while data under commercial terms is not used for training unless the customer opts in. Check each tool's current terms, which change |
| Confidentiality and subcontractors | A confidentiality agreement that covers what the AI tools process. Any subcontractor named, and bound by the same terms |
| Defects and support | A period in which defects in delivered work are fixed at no charge, and a stated basis for work after that |
| Termination and exit | On ending the contract, you receive the work to date, in your repository, with the accounts already yours |
If personal data is involved, data-protection law in your market applies to what is sent to model providers as it does to any other processor. Get advice on that before you sign, not after.
How do you run a paid pilot?
A paid pilot is a small, real piece of the project done first, with the same terms as the whole. It costs something and it is worth it, because you learn how the provider actually works rather than how the proposal says they work. An unpaid pilot tests only their willingness to work for nothing.
- 01Choose a bounded slice that is genuinely part of the job and touches the things that go wrong: one screen or workflow, one permission rule, one integration and one failure case. Avoid a trivial task that proves nothing.
- 02Write the acceptance criteria together before any code. Include at least one that a wrong implementation would fail, such as 'a user from branch B cannot open a branch A record by pasting its address'.
- 03Set it up as the real project will run: repository in your organisation from the start, a staging environment, required checks and an approved pull request for every change.
- 04Time-box it so that you can read all of what it produces. The time-box is yours to choose; the point is that you can review everything, not that it is short.
- 05Ask for a short note at the end listing what was done, what was run and what was not checked. An honest 'not checked' list is a good sign.
- 06Get a second engineer to read the result, if you can. A paid, read-only review of the repository by someone independent is cheap compared with the cost of a full build on the wrong foundation.
- 07Decide using the scorecard below, and keep the pilot's output whichever way you decide.
| What to judge | Good | Concerning |
|---|---|---|
| Reading the pull requests | Small, clear, with a reason for each change; tests alongside | Large and hard to follow; the description restates the diff |
| Your acceptance test | Passes, and they can explain why it would fail if broken | Passes, but nobody can say what it proves |
| Breaking it on purpose | Replaying another user's request fails; bad input is rejected; errors are visible to a person | Works on the happy path only |
| A surprise | They tell you early, with options | You find out from the demo |
| Explaining a merged change | They can explain it without notes | The explanation is the tool's output, read back |
| Handover | Another person can run, deploy and roll back from the README | It only works on their machine or account |
Where does this approach fall short, and how should you treat us?
Questions and evidence cannot guarantee quality. A skilled provider can give polished answers, and an honest small team may have little to show if most of its work is confidential. Treat the pilot as the real test and the ten questions as a way to decide who is worth piloting.
Everything we cite about Claude Code comes from Anthropic's documentation as we read it on 10 October 2026, and the product and its terms change. We have not read the current terms for Cursor, GitHub Copilot or other tools for this article, so where we mention them we have not cited them and you should check each one yourself.
Please ask us the same ten questions. Our published case studies are of custom systems, such as the trading ERP and the fleet order automation, and the controls described there (an audit trail, shadow mode before go-live) are the kind of evidence this article tells you to look for. Two published projects are relevant here: the school ERP, built with Claude Code under review, and the materials marketplace, which began on an AI app builder and was moved onto its own database. Our Claude Code development page describes what we offer, and our vibe-coding-to-production page describes the review we offer for an app you have already built.
Common questions
No, and you should not prefer one who does for that reason alone. Judge on review, tests, ownership and handover. A developer who avoids the tools can deliver well, and one who uses them without review can deliver something you cannot maintain. The tool matters less than the process around it.
Not automatically, and we will not put a figure on it. Drafting code may be quicker, but design, business rules, review, testing and handover remain. Ask the provider to show where a saving comes from, and compare quotes on scope and acceptance criteria, not on hours.
It depends on the tool, the plan and what is sent. Agree in writing what may be sent to a model provider and what may not, and keep production data and credentials out. Anthropic's documentation distinguishes consumer plans, where users choose whether data improves future models, from commercial terms, where it is not used for training unless the customer opts in. Check the same for any other tool.
It depends on the law where you are and on the tool's terms, so take advice if it matters. In the contract, ask for assignment of the deliverables to you, and keep the repository and accounts in your own name from the start. Anthropic's commercial terms, for one, say that to the extent the law permits the customer owns the outputs.
Decide business rules nobody has written down, hold production credentials, edit applied migrations, or write the only tests for billing and permission logic. Those are jobs where a wrong answer looks like a right one, so a person states the expected outcome first and reads the result.
Look at the pull request history. A different person approving, comments, requested changes, small diffs and tests that changed with a stated reason are good signs. Then pick a merged change at random and ask the developer to explain it without notes. Approvals with no comments, ever, are worth a question.
Sources
Statements about what a platform does are checked against the vendor’s own documentation as of 2026-10-10. Vendors change things, so check the current page before you rely on a limit or a price.
- Security · Anthropic
- How Claude remembers your project · Anthropic
- Settings files and precedence · Anthropic
- Data usage · Anthropic
- Manage costs effectively · Anthropic
- Commercial Terms of Service · Anthropic
Drafted with AI assistance (Claude). Published under Saveez Irfan’s name, who is accountable for it. Editorial policy