Job ai-pairing-practice-with-a-private-score-for-each-developer · revised 12 October 2026
Train developers to work with an AI coding assistant, with a private score for each person
Developers do six invented coding tasks with their usual AI assistant. A script scores them, each person sees their own score first, and no score reaches a manager without their agreement.
You might be seeing
- Nobody knows which assistant mistakes your team lets through
- Training sessions on AI tools prove only that people attended
No passwords, keys, card details or admin invites needed to start.
What usually happened
Assistants produce fluent code that can name packages that do not exist, drop tests or paste in a key. Attending a session proves nothing, and a score that goes to a manager can feel like monitoring and be misused for pay or promotion. The practice has to be checkable by script, private to the person and voluntary.
Who it’s for: Engineering lead whose developers all use AI coding assistants and who wants to know which habits help and which let mistakes through, without turning it into surveillance.
Usually starts when: Assistant use has grown, a plausible but wrong change reached production, or you are about to give assistants to less experienced developers.
The result: Up to eight developers each do six invented coding tasks in their own time, using their usual assistant, and hand in only the finished branch. A script scores hidden tests and twelve planted traps, and each person sees their own result and a guide to missed traps before anyone else sees anything. Scores go to a manager only if that person agrees in writing, never for hiring, pay, promotion or discipline.
Check whether this job fits
Answer these without sending files, tickets, code or logins. Nothing is submitted unless you choose to contact us.
What you get
- The six tasks, hidden tests and the answer key (released after the practice)
- The scoring script
- A private result and guide for each person
- The no-names team summary, if five or more took part
- The release log showing who saw what, and when
Included
- Six invented coding tasks in your main language, each with hidden tests and two planted traps (12 in all) that an assistant tends to fall into
- Up to eight volunteers, working alone in their own time with their usual assistant and tools
- Scoring by script from the finished branch only: hidden tests, invented packages, weakened tests, a planted fake key copied into code, removed error handling
- A private result and guide for each person, sent to them first
- A team summary with no names, made only if at least five people took part
- Deletion of any person's result on request
Not included
- Recording screens, keystrokes or prompts: only the finished branch is handed in
- Any use of scores for hiring, pay, promotion, discipline or ranking
- Sending a person's score to a manager without that person's written agreement
- A claim that anyone is or is not a good developer
- Review of your real code or pull requests
- A live trainer unless your agreement names a person
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
The scoring script scores all 24 trap outcomes correctly on our careful and trap-filled reference branches, then all 24 on two mixed branches your lead keeps from us until the test run. All hidden-test outcomes match the answer key; one wrong trap or hidden-test score fails the whole test, and these are code smoke tests, not a rate claim.
Evidence: The scoring script, answer key, four branches and all 48 trap outcomes, with hidden-test results.
Running the script twice on every handed-in branch gives identical scores.
Evidence: Both outputs compared.
The release log shows every person received their own result before anyone else, including your lead, received anything, and that a score reached a manager only where the person agreed in writing.
Evidence: The release log and the written agreements.
The summary has only per-task team totals, no names, participant codes, individual rows, individual scores or per-person breakdowns. It is not made if fewer than five took part; one forbidden field or a summary below that count fails the test.
Evidence: The summary and the participant count.
A test participant who asks to withdraw has their result deleted, and the deletion is confirmed in the log.
Evidence: The deletion test log.
Sign-off. You re-run the acceptance checks with the steps we hand over, read the results and sign off in writing. Payment follows sign-off.
If it fails. If an agreed check fails, you do not pay for this scope. We hand over what we found and agree whether to stop or re-quote; no surprise work.
When it fits, and when we stop
It fits when
- Volunteers who agree to take part and can withdraw at any time
- A lead who agrees in writing that scores are for learning and are private to each person
- A main language we can write invented tasks in
- A way to send each person their result directly
We stop and tell you if
- The lead intends to use individual scores for hiring, pay, promotion or discipline
- Taking part is required rather than voluntary
- You want the lead to see individual scores by default
- Fewer than three people want to take part
What could go wrong
Nothing in your systems changes. Any person can withdraw and have their result deleted, and the written terms say when we delete the rest.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| Scores are used to judge people. | Scores are private to each person, a manager sees one only with that person's written agreement, and a lead who intends to use them for pay or promotion cannot buy this. |
| Scoring is unfair to someone. | Scoring is by script on hidden tests and listed traps, the key is released afterwards and anyone can ask for a re-score. |
| A small team makes a summary identify someone. | No team summary is made for fewer than five people. |
| People feel monitored. | Only the finished branch is handed in. No screens, keystrokes or prompts are recorded. |
A separate automated reviewer checks the work and test results before hand-over. Each volunteer receives their result first and controls any later release to a named manager; the lead receives the no-names summary only when at least five took part. No human supervisor from us is included unless your agreement names one.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Agree language, volunteers, privacy statement and release rules
- Write six invented tasks with hidden tests and twelve planted traps
- Write the scoring script; run it on two reference solutions
- Each volunteer does the tasks and hands in a branch
- Score by script; independent automated review of the results
- Send each person their result first; release only what they allow
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, price, start window and delivery date in writing before you accept, and work starts only after the agreed inputs are in place. An enquiry creates no charge or booking.
Need to keep it working?
Discuss a repeat practice in three months, with new tasks, if volunteers ask for one.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Run a pairing session with a senior developer and discuss the habits openly, with no scores.
- Buy the scored review drill, which tests whether reviewers catch planted agent mistakes.
Questions
Will my manager see my score?
Only if you agree in writing for that release. You can say no, and you can ask us to delete your result.
Is anything recorded while I work?
No. You hand in only the finished branch of the invented repository.
How is this different from the review drill?
The drill tests whether reviewers spot planted mistakes in pull requests. This one tests how developers work with an assistant while writing code.
Does it prove anyone is a good developer?
No. It scores six invented tasks and twelve traps. It is a prompt to learn, not a judgement.
Does a pass mean it will be right next month?
No. A pass describes items like the test sample on the day of the test. It is not a promise about future items, and it does not replace your own checking.
Send an enquiry
Send us
- Your main language and framework
- Which assistants your developers use, by tool name
- How many would take part
- No logins, keys, customer data or payment details in the first enquiry
Later, once you agree
- The volunteers' names or codes, as they choose
- Your written statement on privacy and use of scores
- Each person's choice on whether a manager may see their result
You keep everything. The tasks run on invented code we create, with no access to your code, accounts or logins, and each person hands in a branch of the invented repository. We hold individual results only until they have been sent, or until the person asks us to delete them.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “ai-pairing-practice-with-a-private-score-for-each-developer” as the subject.