Questions to ask a nearshore software provider about AI (2026)

In 2026, asking whether a provider's engineers 'use AI' is like asking whether they use version control. The answer is almost always yes — and the answer tells you very little. The questions that matter are about how: which tools, under what data policy, with what review process, and assessed how.

The following checklist is organized into three groups. Each question includes why it matters and what a thoughtful answer looks like. A provider who has genuinely worked through these questions will welcome them.

Q: Which AI tools do your engineers use on client code, and are those tools on our approved list? Why it matters: different tools have different data handling policies — consumer-grade tools may use inputs for model training; enterprise plans typically do not. A good answer: 'Our engineers use the tools you've approved. If you don't have a list, we'll propose one before the engagement starts and won't use any tool outside it without your approval.' A red flag: 'Engineers use whatever works best.'

Q: Under what account type do engineers use AI tools on client work? Why it matters: model training exclusions are typically tied to enterprise accounts, not personal accounts. A good answer: 'Enterprise accounts or plans with data processing agreements that exclude customer data from training.' A red flag: personal or free-tier accounts.

Q: Do engineers ever paste client secrets, credentials, or PII into AI tools? Why it matters: even if training is disabled, prompts may be logged and visible to the provider's trust and safety teams. A good answer: 'Never. Engineers are assessed on this. Deliberately including secrets in a prompt is grounds for immediate removal.' A red flag: 'We ask them not to, but we can't monitor every prompt.'

Q: Who is responsible for code written with AI assistance? Why it matters: some teams treat AI-generated code as a black box, making bugs harder to trace and own. A good answer: 'The engineer who submits the code is accountable for it, regardless of how it was written. All code goes through peer review and automated tests.' A red flag: 'AI just writes drafts; we review before shipping' — if review is not systematic, this is a liability.

Q: What is your review process for AI-generated pull requests? Why it matters: AI often produces plausible but subtly wrong code, especially in edge cases and security-sensitive paths. A good answer: a described process with specific gates (tests must pass, peer review required, security checklist for sensitive paths). A red flag: 'We trust our engineers to use it responsibly.'

Q: Can you provide a log of AI-assisted actions on my codebase for compliance? Why it matters: some regulated industries require audit trails for how code was written. A good answer: 'Yes, we can maintain and provide that log. The format is defined in the contract.' A red flag: surprise or inability to answer.

Q: How do you assess whether a candidate actually uses AI tools effectively — not just that they own a subscription? Why it matters: tool ownership is not the same as effective use. An engineer who accepts AI output uncritically creates more risk than one who doesn't use AI at all. A good answer: a described assessment process involving observed delivery on real code. A red flag: 'We check their GitHub' or 'We ask about AI experience in the interview.'

Q: Do your engineers know when not to use AI? Why it matters: delegating security-sensitive code, PII handling, or complex legacy logic to an AI agent without careful review is a known risk. OWASP's GenAI Top 10 for 2026 lists prompt injection as #1 and excessive agency as #3. GitHub's own guidance recommends keeping security-, PII-, and auth-critical work with human authors. A good answer: evidence that engineers are assessed on this judgment. A red flag: 'Our engineers are highly experienced' without a specific answer.

Kuboo's AI usage policy defines which tools engineers use, how client data is handled, who reviews AI-generated code, and what is available for audit. Our engineer verification process tests the behavioral habits described above — not through a survey or a certification, but through an observed, screen-shared work sample scored against a written rubric.

We are transparent about what the assessment does not cover: your domain knowledge, sustained performance over time, and team dynamics. Those are your interviews to run. What the report confirms is that the engineer demonstrates the habits that separate effective AI use from risky AI use.