Last updated: October 2026
How We Vet AI-First Engineers
Kuboo's verification process is designed to show whether a nearshore engineer builds software with AI coding agents with engineering discipline: planning the work, checking it with tests, reviewing what the agent wrote, and knowing what not to delegate. It ends in a one-page report with a line of evidence for each dimension, designed to stay valid for 12 months.
- Fundamentals
- Tested without AI assistance
- Work sample
- Observed, screen-shared, recorded with consent
- Identity
- Designed to be checked at each live session
- Second evaluator
- Scores the work sample recording separately
- Report
- One page, evidence for each dimension
- Validity
- Designed for 12 months from the assessment
- Certifications
- Not required
- AI Engineer level
- On request
Context
What 'AI-first' should mean
About nine in ten surveyed tech professionals already use AI at work, so “our engineers use AI” tells you little. We think what matters is whether they check what the agent produces, can explain and debug it, and know which work to keep in their own hands. Outside research points the same way:
~90% of tech professionals use AI at work; only ~25% say they trust its output a lot.
48% of developers trust AI output only when they can easily validate it.
AI-generated code for security-sensitive tasks introduced vulnerabilities in 45% of cases.
Experienced open-source maintainers were ~19% slower with early-2025 AI tools, while believing they were faster.
Among the 21 nearshore firms whose public pages we reviewed in October 2026, most show AI course certificates, partner badges or tool lists, and few explain how they test the skill. We think buyers should be able to see the method. This page sets out how ours is designed, so that each engineer comes with a report you can read before the engagement starts. For AI use on client code, we propose a baseline to be agreed in each contract. Our AI usage policy sets it out.
Process
How the assessment works
The assessment is designed as a short intake and two live sessions. The second, longer session happens only if the first one goes well, so the process can stop early.
- 1
Intake and declared toolchain
A short conversation about fit and English, where the engineer also lists the AI tools they use. The report later shows both the declared tools and the tools used in the session.
- 2
Identity check at each live session
Each live session is designed to open with a check that the person on camera matches their ID document, including simple live-video authenticity checks. Sessions are designed to be recorded, with the engineer's written consent.
- 3
Session 1: fundamentals without AI
With AI tools switched off, the engineer reads unfamiliar code, finds a bug, explains it and proposes tests. We write our own exercises instead of using public question banks.
- 4
Session 1: review a pull request from an AI agent
Still without AI, the engineer reviews the agent's pull request in our test repository. It contains planted bugs, one of them a security issue, and the engineer explains why each one fails. We plan to rotate the planted bugs and tickets from time to time.
- 5
Session 2: agentic work sample
A ticket with acceptance criteria in our own multi-file repository. The engineer uses their own editor and AI agent, screen-shared and recorded, and leaves a plan, an agent rules file, tests and a pull request. One evaluator watches live, and a second scores the recording separately.
- 6
Session 2: debrief
A structured conversation about the work sample: what they handed to the agent and what they kept, where they stopped trusting its output, and which trade-offs they made. The two evaluators score separately, then compare and agree on a final result.
Rubric
What the rubric looks at
The rubric is designed to score eight dimensions, plus cost awareness, which is noted for information only. The four dimensions marked eliminatory are judged on their own, so a strong result elsewhere can't make up for a weak one.
| Dimension | What it tests | Eliminatory |
|---|---|---|
| Fundamentals | Reads unfamiliar code, finds and explains a bug, and proposes useful tests, all without AI. | Eliminatory |
| Agentic workflow | Explores, plans, then implements. Writes tasks with acceptance criteria and knows when a change is too small to need a plan. | — |
| Context engineering | Gives the agent the right context: a concise, versioned rules file (such as AGENTS.md) and sessions scoped to one task. | — |
| Verification with evidence | Treats tests, build and lint as proof that a change works, and asks for evidence instead of taking the agent's word for it. | Eliminatory |
| Review and debugging of AI output | Questions AI-written code, finds the planted bugs, and can explain and fix what the agent produced. | Eliminatory |
| Security | Limits what the agent can access, keeps secrets and personal data out of prompts, and spots the planted vulnerability. | Eliminatory |
| Tool-agnostic standards | Works through open conventions such as MCP and AGENTS.md and turns a repeated correction into a reusable hook or skill. The report lists experience with your specific tools as declared. | — |
| Knowing what not to delegate | Decides what to hand to the agent and what to keep, such as authentication, personal data, complex refactors and legacy code, and explains why. | — |
| Cost awareness | Checks whether model choice and session scope fit the task. Informational only. | — |
Each dimension is designed to be scored on four levels: Not acceptable, Capable, Adoptive, Transformative. We plan to publish the full rubric, including how results are scored, once it has been tested.
Scope
What the report does not verify
A report is designed to cover specific behaviors observed in a controlled session. These are its limits:
- Your domain and business context. The work sample uses our test repository, not your product.
- Sustained performance over time. The report is a snapshot of one assessment, designed to stay valid for 12 months.
- How they work within your team. Your own interviews cover that.
- Hands-on use of your exact tools. The engineer works with their own toolchain, and the report lists experience with yours as declared.
- Performance without AI. The no-AI stage checks fundamentals and unassisted review, not whether someone works as well without AI tools.
- Whether a result predicts on-the-job performance. As of October 2026, we found no provider of AI-use scoring that publishes that evidence. We plan to compare each report with how the placement goes.
Certifications
Why we don't rely on AI certifications
This is Kuboo's own assessment as of October 2026, based on reviewing available certification objectives. Providers may update their formats.
| Format | What it measures | Observed delivery? |
|---|---|---|
| Multiple-choice exam (e.g., GH-300)Kuboo's assessment of the GH-300 objectives, Oct 2026 | Knowledge of tool features and UI | No |
| Course certificate | Completion of training material | No |
| Proctored lab | Controlled exercises with guided instructions | Partially |
| Kuboo work sample | Unguided delivery on a multi-file real codebase, screen-shared and recorded | Yes |
Most AI coding certifications show tool knowledge. A candidate's certifications can still appear on the report as extra context.
Frequently Asked Questions
See what a verification report looks like
Read a sample report for a fictitious candidate to see the format, the dimensions and the kind of evidence a report contains.