Wie man KI-generierten Code in einer Take-Home-Submission erkennt

Warum "KI-Detektoren" meist nicht funktionieren

Tools, die behaupten zu klassifizieren, ob eine Code-Submission KI-generiert wurde, haben konsistent schwache Genauigkeit. Sie produzieren viele False-Positives (bestrafen Kandidatinnen, die zufällig in sauberem Stil schreiben) und viele False-Negatives (moderne LLMs können auf Anfrage idiosynkratisch aussehenden Code produzieren). Auf ihren Output zu reagieren ist riskant.

Verlässliche Detection kommt aus anderem Winkel: sie versucht nicht, das Artefakt zu klassifizieren. Sie vergleicht das Artefakt mit dem Prozess, der es produzierte.

Was menschliche von KI-Submissions tatsächlich unterscheidet

Drei Signale, keines basiert auf Klassifizierung des finalen Codes:

1. Process-Trace

Wie wurde der Code geschrieben? Menschen schreiben iterativ — eine Funktion erscheint, wird editiert, umbenannt, kriegt einen Bug-Fix. KI-eingefügter Code kommt in großen Brocken an, oft komplett bei erstem Erscheinen. Capture die Keystroke- und Edit-Timeline der Submission und der Unterschied ist sichtbar.

ClarityHire zeichnet diese Timeline für Take-Home-Submissions auf und zeigt "Paste-Rate"- und "Edit-Iteration"-Signale, die Process-Patterns inkonsistent mit handgeschriebenem Code flaggen. Es beschuldigt die Kandidatin nicht — es zeigt das Signal für den Reviewer zum Probing.

2. Kohärenz zwischen Code und Erklärung

Eine Kandidatin, die den Code geschrieben hat, kann ihn spezifisch erklären. Eine, die ihn eingefügt hat, kann es nicht. Das Walk-Through-Interview am Ende jedes Take-Home ist der einzige verlässlichste Detektor von KI-eingefügten Submissions, weil die Kandidatin ihre eigenen Entscheidungen in Echtzeit verteidigen muss.

Probe spezifisch: "Warum hast du diesen Ansatz gegenüber der Alternative gewählt?" "Was würde sich ändern, wenn X anders wäre?" "Führ mich durch, was passiert, wenn diese Funktion mit [Edge-Case] aufgerufen wird." Kandidatinnen, die es geschrieben haben, antworten fließend. Kandidatinnen, die es eingefügt haben, improvisieren vage.

3. Stil-Konsistenz

Über mehrere Submissions oder verschiedene Teile einer einzelnen Submission, blieb der Stil kohärent? Naming, Kommentar-Stil, Error-Handling-Patterns. KI-Submissions haben oft verdächtige interne Konsistenz und verdächtige externe Inkonsistenz: uniformer als ein Mensch innerhalb eines Projekts schreiben würde, variabler als die anderen Artefakte der Kandidatin.

Was mit dem Signal tun

Niemals auto-rejecten. Die Signale sind probabilistisch, und die Kosten eines False-Positive sind hoch — ethisch und für die Pipeline.

Nutze sie als Triage: eine geflaggte Submission bekommt einen rigoroseren Walk-Through. Der Walk-Through löst es sauber in fast jedem Fall. Wenn die Kandidatin ihren Code fließend verteidigt, bleibt der Score. Wenn nicht, reflektiert der Score, was sie verteidigen kann.

Das ist humaner als ein Black-Box-Klassifikator, der ein Urteil fällt, und produziert bessere Hiring-Ergebnisse.

Was Kandidatinnen kommunizieren

Sag ihnen vorab: "Diesem Take-Home folgt ein 30-minütiger Walk-Through, wo du deinen Code erklärst. Nutze, was dir hilft, deine beste Arbeit zu liefern, aber sei bereit, deine Entscheidungen zu verteidigen."

Kandidatinnen, die KI-Assistenten effektiv als Tool nutzen und ihre eigene Arbeit fließend erklären können, sind nicht die Leute, die du herausfiltern willst — so arbeiten Engineers 2026. Der Filter ist für Leute, die ohne Verständnis einfügen. Der Walk-Through ist das richtige Instrument.

Wohin das geht

Detection-basierte Ansätze werden weiter Boden verlieren gegen verbesserte LLMs. Process-Trace- und Walk-Through-Ansätze werden weiter funktionieren, weil sie nicht davon abhängen, dass das Artefakt anders aussieht — sie hängen davon ab, dass die Beziehung der Kandidatin zu ihrer eigenen Arbeit verteidigungsfähig ist. Diese Beziehung ist, wofür du sowieso hirest.