Entwickler einstellen, wenn die KI den Code schreibt

Das Signal, das nichts mehr misst

Stell dir das klassische Software-Interview vor, so wie es Millionen Male gelaufen ist. Ein Whiteboard oder ein geteilter Editor, eine Aufgabe mit einem netten algorithmischen Twist, eine Uhr, die läuft. Die Kandidatin soll unter Beobachtung eine Funktion tippen, die ein Array umdreht, einen Baum invertiert, den kürzesten Pfad findet. Bewertet wird, wie schnell und wie sauber sie von der leeren Datei zur funktionierenden Lösung kommt. Jahrzehntelang war das ein vernünftiges Signal: Wer das flüssig konnte, konnte meistens auch im Job Code produzieren.

Genau dieses Signal misst inzwischen das Falsche. Wenn ein Modell den Großteil des Codes schreibt – und in vielen Teams tut es das längst –, dann ist „schnell sauberen Code aus dem Kopf tippen" nicht mehr die knappe Fähigkeit. Sie ist zur billigsten Zutat im ganzen Prozess geworden. Was knapp geblieben ist, testet das klassische Interview überhaupt nicht: Urteilsvermögen. Lesen, zerlegen, verifizieren – und vor allem wissen, was überhaupt zu bauen ist.

Wir stellen also weiter auf ein Signal ein, das eine Fähigkeit prüft, die das Werkzeug auf der anderen Seite des Tisches besser beherrscht als jeder Bewerber. Das ist kein kleines Justierproblem. Das ist ein kaputtes Messgerät.

Warum das klassische Interview bricht

Fangen wir bei der unbequemen Wahrheit an: LeetCode und HackerRank sind KI-trivial lösbar. Nicht „mit Mühe", nicht „bei einfachen Aufgaben" – trivial. Die gesamte Gattung der algorithmischen Puzzle-Fragen, das Hard-Problem inklusive, ist exakt die Art von gut abgestecktem, millionenfach im Trainingsmaterial vorhandenem Handwerk, in der Modelle herausragen. Ein aktuelles Modell löst das mediane Interview-Problem korrekt, kommentiert, mit optimaler Laufzeit, in Sekunden. Ein Test, dessen Aufgaben das billigste Werkzeug im Raum fehlerfrei erledigt, misst nicht mehr das Talent des Menschen. Er misst bestenfalls, ob der Mensch die Fähigkeit des Werkzeugs auswendig gelernt hat.

Damit fällt die stillschweigende Annahme, auf der das ganze Format ruhte: dass Coding-Speed der Engpass sei. War er lange. Wer schneller sauber tippte, lieferte schneller, und das Interview war ein vernünftiger Proxy dafür. Aber der Engpass hat sich verschoben. Produktion ist nicht mehr das Nadelöhr – sie ist reichlich, schnell, billig. Was ein Team ausbremst, ist nicht mehr, wie schnell jemand die erste Version schreibt, sondern ob jemand erkennt, dass diese Version die falsche Sache tut, ein Sicherheitsloch enthält oder ein Problem löst, das niemand hatte.

Es kommt schlimmer: Das klassische Interview belohnt aktiv das Falsche. Es prämiert den Reflex, sofort loszutippen – „zeig mir, dass du Code produzierst". Genau dieser Reflex ist im KI-Zeitalter ein Antimuster. Die wertvolle erste Bewegung ist nicht das Tippen, sondern das Innehalten: die Aufgabe hinterfragen, die Ränder abklopfen, entscheiden, ob das Problem überhaupt richtig gestellt ist. Ein Prozess, der Menschen dafür belohnt, diesen Schritt zu überspringen, selektiert die falsche Denkweise heraus.

Und das Whiteboard-Ritual hat schon immer eine Fähigkeit getestet, die im echten Job kaum vorkommt: fehlerfreies Produzieren aus dem Nichts, ohne Nachschlagen, ohne Iteration, ohne die Werkzeuge, die man real jeden Tag benutzt. Diese Kunsthaftigkeit war früher ein verzeihlicher Kompromiss. Heute ist sie absurd: Wir verbieten der Kandidatin genau das Werkzeug, mit dem sie den Job tatsächlich machen wird, und bewerten sie dann in einer Disziplin, die dieses Werkzeug ohnehin übernimmt.

Wofür man stattdessen einstellt

Wenn das Tippen billig wird, verschiebt sich der Wert eines Menschen auf alles, was das Tippen umgibt. Nicht auf die Fähigkeit, Code zu erzeugen, sondern auf die Fähigkeit, den erzeugten Code zu dirigieren, zu prüfen und zu verantworten. Konkret sind das eine Handvoll Eigenschaften, die das klassische Interview nie ernsthaft getestet hat:

• Geschmack. Die Fähigkeit, zwischen zwei funktionierenden Lösungen die bessere zu erkennen – die einfachere, die robustere, die, die das Team in zwei Jahren noch verstehen wird. Geschmack ist kein Luxus; er ist der Filter, der einen Strom generierten Codes von Schrott trennt.
• Systemdenken. Modelle bauen lokal sinnvoll und global inkonsistent. Sie schmuggeln ein zweites, konkurrierendes Muster ein, ohne es zu merken. Wer einstellt, sucht den Menschen, der sieht, wie eine Änderung ins Ganze passt – oder eben nicht.
• Generierten Code gnadenlos reviewen. Die Kernfähigkeit. Plausiblen, sauber aussehenden, selbstbewusst falschen Code lesen und die subtile Lücke finden: den nie behandelten Edge Case, den erfundenen API-Aufruf, die stille Annahme, die nicht hält.
• Fremden, kaputten Code debuggen. Nicht den eigenen frischen Code, sondern ein System, das jemand anderes – oder etwas anderes – gebaut hat und das um drei Uhr nachts umfällt. Das ist die reale Arbeit, und sie verlangt genau das Gegenteil vom Whiteboard-Reflex.
• Produkturteil. Zu wissen, was zu bauen ist. Code kann tadellos sein und trotzdem das falsche Problem lösen. Der Mensch, der erkennt, dass ein Feature gar nicht gebraucht wird, spart mehr als jeder schnelle Tipper je produziert.
• Spezifikation und Kommunikation. Ein Modell ist nur so gut wie die Absicht, die man ihm gibt. Wer eine unklare Anforderung in eine präzise, prüfbare Spezifikation übersetzen kann, hat die eigentliche Ingenieursarbeit schon geleistet – der Rest ist Generierung.

Man sieht das Muster: Jede dieser Eigenschaften ist eine Urteils-Fähigkeit, keine Produktions-Fähigkeit. Sie lassen sich nicht ans Modell delegieren, weil sie genau der Punkt sind, an dem aus „der Code läuft" ein „wir verstehen, was er tut, und stehen dafür ein" wird.

Wie man das tatsächlich prüft

Die gute Nachricht: Sobald man weiß, wofür man einstellt, sind die Prüfformate naheliegend – sie sehen der echten Arbeit einfach ähnlich. Drei Formate ersetzen das Whiteboard sauber.

Einen fehlerhaften PR live reviewen lassen. Man gibt der Kandidatin einen realistischen Pull Request von zwei-, dreihundert Zeilen, in den man bewusst eine Handvoll Fehler eingebaut hat: einen Off-by-one am Rand, eine Autorisierung, die genau einen Pfad vergisst, eine Annahme, dass die Antwort sortiert ist. Dann schaut man zu, wie sie liest. Findet sie die subtilen Sachen oder nur den offensichtlichen Tippfehler? Priorisiert sie nach Sprengradius – Zahlungslogik zuerst, Variablenname zuletzt? Kann sie erklären, warum etwas falsch ist, nicht nur dass es sich komisch anfühlt? Dieses Pair-Review-Interview misst in vierzig Minuten mehr über die tatsächliche Tauglichkeit als jede algorithmische Frage.

Ein kaputtes System debuggen lassen. Man setzt sie vor eine kleine, laufende Anwendung mit einem echten Bug – einer, der sich nicht durch Hinstarren löst, sondern durch Hypothesen, Logs, Zerlegen. Wie geht sie vor, wenn sie den Code nicht geschrieben hat und nicht versteht? Bildet sie eine Theorie und testet sie, oder rät sie planlos herum? Debugging ist der ehrlichste Test für Urteilsvermögen, den es gibt, weil man es nicht auswendig lernen kann.

Ein Take-home MIT erlaubter KI. Das ist die entscheidende Umkehrung, das „KI-erlaubte Interview". Statt das Werkzeug zu verbieten, das die Kandidatin ohnehin benutzen wird, gibt man es ihr ausdrücklich in die Hand – und bewertet dann nicht den Code, sondern das Urteil. Welche Prompts hat sie formuliert? Wo hat sie dem Modell widersprochen? Was hat sie an der ersten generierten Version verworfen und warum? Man lässt sie ihre Entscheidungen durchsprechen. Zwei Kandidaten liefern denselben funktionierenden Code ab; der eine hat ihn blind übernommen, die andere hat drei stille Fehler abgefangen und eine Architekturentscheidung getroffen. Das klassische Interview konnte die beiden nicht unterscheiden. Dieses Format sieht nichts anderes.

Der gemeinsame Nenner: Man testet nicht mehr die leere-Datei-Produktion, sondern die Interaktion mit Code, der schon existiert – lesen, urteilen, verbessern, verantworten. Genau das ist die Arbeit.

Das Junior-Problem

Hier wird es unbequem, und ehrliche Analyse darf davor nicht ausweichen. Alles bisher Gesagte läuft auf eine Fähigkeit hinaus, die man Urteilsvermögen nennt – und Urteilsvermögen ist erworben, nicht angeboren. Die klassische Frage ist: Wie erwirbt es ein Junior, wenn er nie den ersten Entwurf schreibt?

Der traditionelle Weg, wie Entwickler Urteil aufbauten, war brutal, aber wirksam: Man schrieb selbst tausend Zeilen schlechten Code, sah sie im Review zerpflückt, verstand warum sie schlecht waren, und baute daraus über Jahre eine Intuition. Das Schreiben-und-Scheitern war der Lehrpfad. Wenn ein Modell den ersten Entwurf übernimmt, verschwindet genau dieser Pfad. Der Junior sieht nur noch fertigen, plausibel aussehenden Code – und plausibel aussehender Code lehrt einen nichts, weil er die Fehler versteckt, aus denen man lernen würde.

Das ist der drohende Kollaps der Junior-Pipeline. Wenn Teams nur noch für Urteilsvermögen einstellen, aber Urteilsvermögen nur durch jahrelanges Schreiben-und-Scheitern entsteht, dann stellt niemand mehr die Menschen ein, in denen dieses Urteil überhaupt erst wachsen könnte. Man verzehrt einen Bestand an Senioren, den ein früheres, langsameres System produziert hat, und legt gleichzeitig die Fabrik still, die den Nachschub baut. Das rächt sich nicht dieses Quartal, aber es rächt sich.

Der Ausweg ist keine Nostalgie, sondern eine bewusst gebaute Ausbildung. Ein paar Konturen zeichnen sich ab:

• Erzwungenes tiefes Lesen. Wenn Juniors nicht mehr durch Schreiben lernen, müssen sie durch strukturiertes, angeleitetes Lesen lernen. Nicht generierten Code durchwinken, sondern ihn zerlegen: Warum diese Struktur? Was passiert bei leerer Eingabe? Wo würde das brechen? Reading-as-training, bewusst und begleitet.
• Apprenticeship neu ernst nehmen. Der Senior, der einem Junior über die Schulter schaut, während der einen generierten PR auseinandernimmt, ist kein Luxus mehr – er ist der einzige verbliebene Übertragungsweg für Urteil. Teams, die das systematisch tun, werden in fünf Jahren Senioren haben. Die anderen werden sie einkaufen müssen, teuer.
• Gezielt Reibung erzeugen. Manchmal heißt Ausbildung, den Junior den ersten Entwurf bewusst selbst schreiben zu lassen – ohne Modell –, nicht weil das effizient ist, sondern weil das Scheitern der Lehrstoff ist. Effizienz und Ausbildung ziehen hier in verschiedene Richtungen, und man muss die Spannung bewusst aushalten.

Wer das Junior-Problem ignoriert, optimiert sich in eine Sackgasse: maximale kurzfristige Produktivität, ausgetrocknete Talent-Pipeline.

Die Gegenseite: Fundamente zählen mehr, nicht weniger

Jetzt die ehrliche Gegenrede, sonst kippt die These ins Gegenteil und wird genauso falsch. Die Verlockung, aus alldem den Schluss zu ziehen „Programmieren-Können ist egal, Hauptsache gute Prompts", ist real – und sie ist eine Falle.

Der Grund ist einfach und hart: Man kann keinen Code reviewen, den man nicht versteht. Jede einzelne Urteils-Fähigkeit, die oben steht, setzt tiefe technische Fundamente voraus. Um den erfundenen API-Aufruf zu erkennen, muss man wissen, wie die echte API sich verhält. Um die stille Race Condition zu sehen, muss man Nebenläufigkeit im Bauch haben. Um zu spüren, dass eine Datenstruktur die falsche ist, muss man tausend Datenstrukturen im Einsatz gesehen haben. Der „gnadenlose Reviewer" ist kein Gegenentwurf zum tiefen Techniker – er ist der tiefe Techniker, nur dass sein Hebel nicht mehr das Tippen ist, sondern das Urteil.

Deshalb ist der reine Prompt-Jockey – jemand, der Modelle geschickt bedient, aber den ausgegebenen Code nicht wirklich lesen kann – kein akzeptabler Ersatz, sondern das gefährlichste Profil überhaupt. Er produziert schnell plausibel aussehenden Code und hat keine Möglichkeit zu erkennen, wann dieser Code selbstbewusst falsch ist. Er verwandelt die Organisation in eine Maschine, die Verständnis-Schulden schneller anhäuft, als irgendjemand sie zurückzahlen kann.

Man darf also nicht ins Gegenteil überkorrigieren und Leute einstellen, die nie etwas gebaut haben. Wer nie ein System von der leeren Datei bis in die Produktion getragen hat, hat auch nie die Narben gesammelt, aus denen Urteil besteht. Die richtige Lesart ist nicht „Fundamente sind unwichtig geworden", sondern eine unbequemere: Die Messlatte für Tiefe steigt, sie sinkt nicht. Früher konnte ein mittelmäßiger Techniker mit hohem Output nützlich sein – er produzierte eben viel. Diese Nische verschwindet, weil das Modell den Output übernimmt. Was bleibt, ist die Anforderung, tief genug zu verstehen, um dem Modell zu widersprechen. Das ist ein höherer Anspruch, kein niedrigerer.

Fazit

Das klassische Interview hat jahrzehntelang eine reale Fähigkeit gemessen: schnell sauberen Code produzieren. Diese Fähigkeit ist nicht wertlos geworden, aber sie ist nicht mehr knapp – das billigste Werkzeug im Raum beherrscht sie besser als jeder Bewerber. Wer weiter darauf einstellt, misst mit einem kaputten Instrument und wundert sich über die Ergebnisse.

Knapp geworden ist das, was das Whiteboard nie testen konnte: Geschmack, Systemdenken, die Fähigkeit, generierten Code gnadenlos zu prüfen, fremde kaputte Systeme zu debuggen, das richtige Problem zu erkennen und eine präzise Spezifikation zu formulieren. Man prüft es, indem man Menschen echte Arbeit tun lässt – einen fehlerhaften PR reviewen, ein System debuggen, ein Take-home mit erlaubter KI durchdenken – und nicht den Code bewertet, sondern das Urteil dahinter. Und man baut die Ausbildung neu, sonst trocknet die Pipeline aus, die überhaupt erst Urteil produziert.

Genau danach stellen wir bei NH Labs ein. Nicht nach Tippgeschwindigkeit und nicht nach der Zahl gelöster Puzzle-Aufgaben, sondern nach Urteilsvermögen und der Bereitschaft, Verantwortung zu tragen – für jede Zeile, die eingereicht wird, egal wer oder was sie getippt hat. Wir suchen die Menschen, die generierten Code lesen wie ein Lektor ein Manuskript: schnell, skeptisch, mit einem Gespür dafür, wo die glatte Oberfläche einen Fehler versteckt. Deshalb können unsere Kunden dem Ergebnis vertrauen – nicht weil eine KI schnell war, sondern weil ein Mensch mit gutem Urteil dafür geradesteht.