KI-generierten Code beurteilen: wie Teams das lernen

KI-generierten Code beurteilen heisst prüfen, ob ein Ergebnis trägt, bevor es in Produktion geht. Die Fähigkeit dazu entsteht durch eigenes Testen: Wer Software manuell und automatisiert selbst geprüft hat, erkennt, was ein grünes Testergebnis aussagt und was es verschweigt. Ohne diese Erfahrung bleibt nur, Vorschläge anzunehmen oder abzulehnen.

Warum reicht es nicht, dem Testergebnis zu vertrauen?

Ein grünes Testergebnis sagt aus, dass die geschriebenen Tests durchgelaufen sind. Es sagt nichts darüber, ob die richtigen Fälle geprüft wurden. Genau diese Lücke erkennt nur, wer selbst Tests geschrieben und dabei erlebt hat, welche Fälle man beim ersten Anlauf übersieht.

Mit KI-Agenten wächst die Bedeutung dieser Lücke. Wenn ein erheblicher Teil des Codes aus einem Agenten kommt, verschiebt sich die eigentliche Arbeit vom Schreiben zum Beurteilen.

Wo entsteht der Engpass?

Die naheliegende Annahme lautet: Mehr KI-Unterstützung heisst mehr fertige Software. Das stimmt nur zur Hälfte.

Output ist etwas anderes als Release-Kapazität. Releasefähig wird Code erst, wenn ihn jemand geprüft, getestet, verbessert und verantwortet hat. Genau dort sitzt der Engpass. Er wächst mit jedem zusätzlichen KI-Output. Wer die Produktion skaliert und die Prüfung unverändert lässt, staut die Arbeit hinten auf.

Wie baut man die Fähigkeit im Team auf?

Wer bei uns in die Softwareentwicklung einsteigt, beginnt mit dem Testen, manuell und automatisiert. Das ist die kürzeste Strecke zu einer Fähigkeit, die sich schwer nachholen lässt: einschätzen zu können, was ein Ergebnis wirklich belegt.

Diese Reihenfolge stammt aus der Zeit vor den KI-Agenten. Sie wird durch sie wichtiger.

Ein aktuelles Beispiel ist Eric Merz, der seit diesem Sommer als Praktikant in der Softwareentwicklung zu unserem Team in Mörschwil gehört. Er ist über das PiBS-Modell eingestiegen, die praxisintegrierte Bachelorausbildung Informatik der OST – Ostschweizer Fachhochschule, und studiert, während er bei uns arbeitet. Möglich gemacht haben diesen Weg Roger Strässle und Danilo Just von der OST. Sein Schwerpunkt liegt zurzeit beim manuellen und automatisierten Testen.

Was kostet es, die Fähigkeit später zuzukaufen?

Es wäre schneller, jemanden sofort Features bauen zu lassen. Kurzfristig sieht das nach Tempo aus. Der Output landet anschliessend im Review und belastet genau die Erfahrenen, die ohnehin der Engpass sind.

Damit steht jedes Unternehmen vor einer Wahl, die selten offen ausgesprochen wird: Baut man die Beurteilungsfähigkeit im eigenen Team auf, oder kauft man sie später als Dienstleistung zu? Beide Wege sind vertretbar. In vielen Unternehmen wird die Wahl allerdings gar nicht getroffen. Man sieht zu und hofft, dass sich die Leute von selbst anpassen.

Wie fängt man an?

Der erste Schritt ist eine bewusste Entscheidung darüber, wer im Team KI-Ergebnisse verantwortet. Der zweite ist eine Regel für wiederkehrende Findings: Ein Finding, das mehrfach auftaucht, gehört ins System statt in den einzelnen Pull Request, als angepasstes Prompt-Template oder als zusätzlicher Automatisierungsschritt. Sonst korrigiert man dieselbe Sache tausendmal von Hand.

Warum menschliche Aufsicht dabei unverzichtbar bleibt, steht im Beitrag KI ausser Kontrolle: Warum KI Ihr Copilot bleiben muss. Welche Fragen vor einer KI-Einführung zuerst gehören, beschreibt KI-Transformation: Wer die richtigen Fragen stellt, gewinnt.

Wenn Sie diese Entscheidung bewusst treffen wollen, sprechen wir gerne darüber, wie ein solcher Aufbau in Ihrem Team aussehen könnte. Wie wir Unternehmen dabei begleiten, sehen Sie bei unseren Leistungen.