Come rilevare l'uso di Cursor e Copilot nei colloqui di programmazione
Perché il playbook di ChatGPT non funziona con Cursor e Copilot
I consigli standard sul rilevamento delle frodi per i colloqui di programmazione sono costruiti su un presupposto: il candidato fa alt-tab su una finestra di chat, chiede una soluzione e la incolla di nuovo. La dimensione dell'incollamento, la durata del cambio di scheda e la velocità di digitazione in burst dipendono tutti da quel flusso di lavoro.
Nel 2026, questo presupposto è sbagliato per gli strumenti IA che i candidati effettivamente usano. Cursor, GitHub Copilot, Windsurf, Continue e la nuova ondata di strumenti a overlay invisibile come Cluely non incollano. Rimangono dentro l'editor, accettano suggerimenti con Tab e emettono caratteri nel buffer in un modo che sembra molto più una digitazione che un evento di incollamento. Un candidato che usa bene Cursor non attiverà mai un allarme di incollamento sulla tua piattaforma e non cambierà mai scheda nemmeno una volta. Il rapporto di integrità di uno strumento di screening ingenuo leggerà pulito.
Questo è un problema diverso e richiede uno stack di segnali diverso. Questo articolo esamina l'impronta comportamentale degli assistenti IA nell'editor, i momenti specifici in cui si rompono, e come progettare la sessione in diretta in modo che un utente onesto di questi strumenti produca comunque segnali interpretabili.
Che aspetto ha effettivamente l'IA nell'editor per la piattaforma
Tre categorie di strumenti, tre tracce diverse:
- Agenti di completamento a scheda (Copilot, Cursor Tab, JetBrains AI). Un suggerimento "ghost text" appare dopo una breve pausa; il candidato preme Tab; 40–300 caratteri finiscono nel buffer in un unico tick. Per un registratore di tasti, quel tick può leggersi come un burst di tasti veloci o come un singolo evento di inserimento, a seconda di come l'editor invia l'input.
- Editor agentic (Cursor Composer, Windsurf Cascade, Claude Code, Aider). Il candidato digita o dice un'istruzione in linguaggio naturale in un pannello laterale; l'agente riscrive un blocco del file. Dall'esterno, questo sembra una serie di modifiche multi-riga senza tasti corrispondenti tra di esse.
- Strumenti overlay invisibile (Cluely, Interview Solver, Interview Coder). Un processo separato legge lo schermo e mostra al candidato una risposta in un overlay nascosto dalle API di cattura dello schermo. Il candidato quindi riscrive o trascrivi da esso. La traccia sulla piattaforma è "il candidato l'ha digitato da solo", ma il ritmo è sbagliato.
Il candidato non sta incollando. Stanno accettando, trascrivendo o instruendo. Ognuno di questi ha una spia.
Segnale 1: burst di accettazione Tab all'interno di un flusso di digitazione
L'impronta più netta di uno strumento di completamento a scheda è la forma del flusso di tasti. Il codice digitato a mano su una riga di 30 caratteri sembra 30 pressioni di tasti distanziate di 80–250 ms, con la pausa occasionale di 1–2 secondi. Un'accettazione Tab di Copilot sulla stessa riga sembra un evento a +0 ms seguito da 30 caratteri a +1 ms ciascuno — o in alcuni editor, un singolo inserimento nel buffer senza temporizzazione per carattere.
Il registratore di tasti di ClarityHire classifica qualsiasi esecuzione contigua di input dove il ritardo tra i tasti scende sotto ~5 ms come un blocco emesso da macchina. Il blocco viene registrato separatamente dai caratteri digitati e appare nel rapporto di integrità come un tipo di evento distinto — non un incollamento, non una pressione di tasto, un'accettazione.
Cosa cercare nel rapporto:
- Una serie di 5–10 eventi di accettazione al minuto, ognuno di 40–250 caratteri di lunghezza, intervallato da una digitazione normale. Questo è il ritmo canonico di Copilot/Cursor.
- Blocchi di accettazione che completano intere funzioni in un evento (300+ caratteri). Questo è un comportamento dell'editor agentic, non completamento a scheda.
- Zero incollamenti, zero cambi di scheda, ma il candidato produce una soluzione di lavoro di 200 righe in 22 minuti netti. Il volume stesso è il segnale.
Nessuno di questi è una pistola fumante. Tutti insieme, contro un problema che il candidato non ha mai visto, lo è.
Segnale 2: i salti del cursore che il candidato non può fare a mano
Quando un umano scrive codice, il cursore si muove come gli umani muovono i cursori: tasti freccia, Home/End, il clic occasionale in un'altra riga. Quando un editor agentic riscrive una regione, il cursore teletrasporta — la modifica successiva è a due funzioni di distanza dalla precedente, senza navigazione intermedia. Quando uno strumento effettua il refactoring su più file, il file attivo cambia senza una ricerca fuzzy Cmd-P.
L'editor collaborativo utilizzato nelle sessioni di programmazione in diretta registra la posizione del cursore e il documento attivo ad ogni modifica. Nella timeline, le "modifiche teletrasportate" risaltano: una modifica alla riga 80 immediatamente seguita da una modifica alla riga 12 di un file diverso, senza navigazione visibile e senza scorrimento. Un umano può farlo con hotkey, ma l'ammasso di tali mosse in una sessione è quello che conta. Due o tre è normale. Venti in 20 minuti è l'agente al lavoro.
Segnale 3: ritmo di digitazione che non corrisponde alla linea di base del candidato
L'accettazione Tab dà al candidato una riga finita. Devono ancora digitare l'istruzione che l'ha evocata, o digitare la riga successiva da soli. Quindi il flusso di tasti diventa bimodale: lunghi tratti di codice emesso da macchina separati da brevi tratti di digitazione umana.
La biometria dei tasti sulle porzioni digitate è ancora utile — l'impronta di soggiorno e fuga del candidato dovrebbe essere coerente in tutta la sessione. Ma il rapporto è il nuovo segnale: un candidato pesante su Cursor digita forse il 15–25% dei caratteri nel file finale. Un non-utente digita 95%+. Il rapporto è visibile nel rapporto e non dipende dalla corretta classificazione di nessun singolo evento.
Questo è anche il segnale che cattura gli strumenti overlay invisibile. Un candidato che legge da un overlay Cluely e riscrive la risposta digita a un ritmo insolitamente costante, con pochissime correzioni, perché sta trascrivendo piuttosto che componendo. La distanza di modifica tra il flusso di tasti e il file finale cade verso zero. La vera autorialità ha backspace, ridenominazioni e tentativi ritirati; la trascrizione no.
Segnale 4: l'invio è più coerente del processo
Esegui un'analisi della coerenza del codice sul file finale e ottieni una lettura separata. Cursor Composer e Claude Code producono file altamente coerenti — uniformemente idiomatici, denominazione coerente, gestione degli errori difensiva per i casi che il candidato non ha esercitato. Questo è un modo di fallimento diverso dal codice cucito da ChatGPT, che tende a essere incoerente. Il codice Cursor è troppo pulito per il processo visibile.
La domanda diagnostica è quella che il giudice della coerenza già pone: questo sembra scritto da una sola persona, da capo a fondo, in 30 minuti, mentre mi parla su video? Un umano sotto pressione d'intervista produce un file con almeno un bordo ruvido — un console.log rimasto indietro, una funzione che intendevano rinominare, un commento che contraddice il codice. Un file di Cursor-Composer raramente ne ha. L'assenza di disordine è il segnale.
Cosa chiedere nella stanza
Il rilevamento è metà della risposta. L'altra metà è porre la domanda che un utente dell'agente non può deflettere:
- Scegli una riga non ovvia e chiedi il perché. "Hai usato
Mapqui invece di un oggetto — quale era il compromesso?" Un autore reale sceglie uno. Un utente di accettazione-e-proseguire scrolla le spalle. - Forza una piccola estensione. "Aggiungi un flag che rende questo insensibile alle maiuscole/minuscole." Cinque righe, nessuna accettazione Tab consentita. Il candidato o lo scrive con fluidità o si ferma. Entrambi sono segnali.
- Chiedi di un bug che puoi vedere. Pre-pianta un problema sottile nel prompt o nello scaffolding. Gli strumenti agentic tendono a "ripararlo" senza riconoscerlo. Chiedi al candidato di percorrervi ciò che hanno cambiato e perché. L'utente onesto spiega; l'utente dell'agente narra il diff.
Queste domande di follow-up sono lo stesso strumento che useresti per un take-home con generazione IA. Il punto non è catturare lo strumento — è scoprire se il candidato ha la relazione con il codice che il ruolo richiede.
Come progettare la sessione in modo che il segnale sia interpretabile
Due scelte strutturali rendono tutto quanto sopra più facile da leggere:
- Stabilisci la regola prima che inizi la sessione. "Puoi usare qualsiasi strumento tu voglia. Cursor, Copilot, i tuoi snippet personali. Ti chiederemo di estendere e difendere quello che scrivi." Questo è il framing open-book, e converte un problema di rilevamento in un problema di interpretazione. Un candidato che dichiara l'uso di Cursor in anticipo e spiega il suo lavoro va bene. Un candidato che lo nasconde e non può spiegare è quello che vuoi filtrare.
- Riserva cinque minuti della sessione per modifiche senza aiuti. Dì al candidato in anticipo: gli ultimi cinque minuti sono una piccola estensione, senza strumenti IA. Guarda come digita quando l'assistente se n'è andato. Questo singolo blocco produce una linea di base pulita da confrontare con il resto della sessione.
Queste due regole danno al tuo rapporto di integrità qualcosa su cui ancorarsi. Senza di esse, stai inferendo il ritmo su un precedente vuoto; con esse, hai una sezione a linea di base nota in ogni intervista.
Cosa fare successivamente
Se conduci colloqui tecnici e il tuo attuale rapporto di integrità tiene traccia solo degli incollamenti e dei cambi di scheda:
- Aggiungi un detector di blocco di accettazione al tuo keystroke logging, o scegli una piattaforma di programmazione che lo spedisce. Senza di essa, gli utenti Cursor sono invisibili a te.
- Aggiungi il blocco di cinque minuti senza aiuti a ogni sessione in diretta questa settimana. Ti costa quasi nulla e ti dà una linea di base per ogni candidato, non solo quelli sospetti.
- Aggiorna le tue istruzioni rivolte ai candidati per dire cosa è e cosa non è consentito. La maggior parte dei candidati rispetterà una regola chiara; i pochi che non lo faranno la nasconderanno male.
- Smetti di fare affidamento sui conteggi di cambio di scheda come segnale primario. Nel 2026, lo strumento di frode che il candidato sta usando non richiede loro di lasciare l'editor.
La corsa agli armamenti contro l'IA nell'editor non è vincibile solo dal rilevamento. È vincibile dal design dell'intervista che rende indistinguibile l'uso onesto dello strumento dal non-uso, e l'uso disonesto dello strumento impossibile da difendere nella stanza. Il segnale che vuoi non è "hanno usato Cursor" — è "sanno cosa fa il loro codice." Costruisci la sessione attorno a quella domanda e il problema di rilevamento si risolve per lo più da solo.