Der knappe Skill ist nicht Tippen, sondern Verifikation

TL;DR

In der KI-gestützten Entwicklung hat sich der Engpass verschoben. Code zu produzieren ist billig geworden -- Agenten schreiben, testen und reviewen. Die knappe Ressource ist die Verifikation: die Fähigkeit zu beurteilen, ob das Erzeugte wirklich hält. Wer freigibt, verantwortet, und Verantwortung lässt sich nicht an ein Modell delegieren. Dieser Artikel beschreibt, warum Verifikation heute der entscheidende Skill ist -- aus täglicher Praxis, nicht aus der Theorie.

Ein Panel, das die Frage auf den Punkt brachte

Am 16. Juni saß ich beim Wien Software Architecture Meetup auf dem Panel "Architecture & Development in the New", im Accenture Börsengebäude am Schottenring. Neben mir: zwei Stimmen von Accenture, eine von SQUER, eine von fab4minds. Ich war der einzige unabhängige Solo-Practitioner in der Runde. Die anderen sprachen aus der Enterprise- und Beraterperspektive. Ich spreche aus der Werkbank.

Eine Frage zog sich durch den ganzen Abend: Was ändert sich wirklich, wenn Maschinen den Großteil des Codes schreiben? Meine Antwort war kurz, und sie hat polarisiert: Das Tempo ist nicht das Problem. Der Engpass ist gewandert. Früher kostete die Code-Produktion Zeit. Heute kostet die Prüfung Zeit. Der knappe Skill ist nicht mehr Tippen, sondern Verifikation.

Ich arbeite seit Ende 2024 täglich so. Diese Verschiebung ist für mich keine Prognose. Sie ist mein Arbeitsalltag.

Was sich tatsächlich verändert hat

Wenn man mich fragt, was KI an meiner täglichen Arbeit am meisten verändert hat, lautet die ehrliche Antwort: Ich schreibe kaum noch Code, ich orchestriere. Mehrere Agenten-Sessions laufen parallel, jede will irgendwann eine Entscheidung von mir. Was früher Tipparbeit war, ist heute Entscheidungsarbeit.

Der Gewinn ist real. Geschwindigkeit und Breite sind enorm gestiegen. Rollen, die klassisch fünf bis zehn Personen besetzen, laufen bei mir über Agenten: Implementierung, Tests, Reviews, Dokumentation. Dass das funktioniert, weiß ich nicht aus der Theorie, sondern weil ich seit Ende 2024 täglich so baue -- über 250 Prototypen sind dabei entstanden.

Aber es gibt eine Kehrseite, und die wird selten benannt. Die Aufmerksamkeit des Menschen ist die neue knappste Ressource. Am Abend ist nicht die Hand müde, sondern das Urteilsvermögen. Kontextwechsel kosten. Und genau hier liegt der entscheidende Punkt:

Meine Agenten arbeiten parallel. Wenn ich zögere, werde ich zum Flaschenhals.

Der Engpass bin ich. Nicht weil ich zu langsam tippe, sondern weil ich die letzte Instanz bin, die beurteilt, ob das Erzeugte hält. Mehr Agenten produzieren mehr Output. Mehr Output braucht mehr Prüfung. Und Prüfung lässt sich nicht beliebig parallelisieren, solange am Ende ein Mensch verantwortet.

Warum Code billig wurde und Vertrauen nicht

Es lohnt sich, die zwei Dinge sauber zu trennen, die hier oft vermischt werden: Produktion und Verifikation.

Produktion ist die Erzeugung von Code, Tests, Konfiguration, Dokumentation. Das können Agenten heute beeindruckend gut. Sie sind schnell, sie sind ausdauernd, und sie kennen keinen Feierabend.

Verifikation ist die Beurteilung, ob das Erzeugte korrekt, sicher und sinnvoll ist. Ob die Tests das Richtige prüfen. Ob die Architektur in drei Monaten nicht teuer wird. Ob die Abkürzung, die der Agent genommen hat, ein Problem ist oder nicht.

Code ist billig geworden. Vertrauen nicht. Ein Agent, der etwas Plausibles behauptet, das einfach falsch ist, kostet mich mehr als ein Agent, der gar nichts liefert. Denn der falsche, plausible Output ist der gefährlichste: Er sieht nach Lösung aus.

Ein konkretes Beispiel aus meiner täglichen Arbeit. Bei mir gilt eine harte Regel: Wenn ein Review-Agent einen Bug behauptet, wird nicht sofort gefixt. Erst wird ein Test geschrieben, der den Bug beweist. Klingt pedantisch. Aber erstaunlich oft stellt sich beim Schreiben des Tests heraus: Der Bug existiert gar nicht. Der Agent hat etwas Plausibles behauptet, das nicht stimmte. Hätte ich sofort gefixt, hätte ich funktionierenden Code kaputtrepariert -- auf Zuruf einer Maschine.

Das ist Verifikation in ihrer reinsten Form. Nicht mehr mit Syntax kämpfen, sondern mit Behauptungen.

Verifikation als Architekturproblem, nicht als Fleißaufgabe

An dieser Stelle kommt der häufigste Einwand: "Und wenn der Mensch das gar nicht mehr prüfen kann, weil es zu viel ist?" Die Frage ist berechtigt. Wenn fünf Agenten parallel arbeiten, kann ich nicht jede Zeile lesen. Das wäre der sichere Weg zurück in den Flaschenhals.

Die Antwort liegt nicht in mehr Disziplin. Sie liegt in der Architektur. Der Mensch prüft nicht jede Zeile, er prüft das Prüfsystem. Verifikation muss man in die Struktur einbauen, nicht prozessual nachrüsten. Vier Mechanismen tragen das bei mir:

• Gewaltenteilung beim Review. Nach jeder Arbeitswelle laufen mehrere Reviewer-Rollen parallel, alle nur lesend: eine für Security, eine für Testlücken, eine für Architektur, eine prüft, ob das Geplante überhaupt umgesetzt wurde. Wer prüft, implementiert nie, sonst prüft er am Ende seine eigene Arbeit. Das Interessante daran: Jede Rolle findet eine andere Fehlerklasse. Kein einzelner Reviewer hätte alle gefunden.
• Scope-Enforcement. Jeder Agent darf nur in seine zugewiesenen Dateien schreiben. Seit ich das erzwinge, habe ich bei parallelen Agenten keine Merge-Konflikte mehr. Nicht weil die Agenten brav sind, sondern weil die Struktur Konflikte unmöglich macht.
• Gates statt Meetings. Am Ende jeder Arbeitseinheit laufen automatische Prüfungen: Typecheck, Tests, Schema-Validierung, ein Abgleich zwischen Doku und Realität. Ein Gate, das nicht blockt, ist Deko.
• Fehler werden Regeln. Jeder gefundene Fehler wird als Learning extrahiert und maschinenlesbar in künftige Sessions eingespeist. Das System lernt schneller, als ich vergessen kann.

Das ist für mich Governance: nicht Kontrolle im Nachhinein, sondern Strukturen, in denen der Fehler gar nicht erst entstehen kann. Wer tiefer einsteigen will, wie man KI-Agenten über viele Sessions konsistent und prüfbar hält, findet die Details in Harness Design für KI-Coding-Agenten.

Wer freigibt, verantwortet

Es gibt einen Teil der Verifikation, den keine Architektur abnimmt: die Freigabe. Und genau hier liegt der Kern, der auf dem Panel am meisten polarisiert hat.

Verantwortung kann man nicht an ein Modell delegieren. Wer freigibt, haftet. Ein Agent ist für mich wie ein Compiler: ein mächtiges Werkzeug, aber niemand verklagt den Compiler. Wenn ein Agent etwas entscheidet, antwortet trotzdem ein Mensch dafür. Für ein Unternehmen, das gar keinen Code schreibt, gilt genau dasselbe: Wenn eine KI eine Rechnung, ein Angebot oder eine Kundenmail erzeugt und keinen Fehler meldet, ist das kein Beleg für Richtigkeit -- jemand muss inhaltlich freigeben.

Accountability lässt sich nicht automatisieren.

Mein praktisches Modell dafür hat drei Teile. Erstens: Jede Freigabe ist ein menschlicher Akt und ist protokolliert. Jedes Artefakt trägt einen Herkunfts-Marker -- welcher Agent hat es erzeugt, welcher Mensch hat es freigegeben. Zweitens: Wenn etwas schiefgeht, frage ich nicht zuerst "wer war's", sondern "welches Gate hat versagt und warum hat es den Fehler nicht gefangen". Drittens: Die Konsequenz aus einem Fehler ist ein schärferes Gate, nicht nur ein Schuldiger.

Damit das nicht zur Theorie wird, ziehe ich eine klare Linie zwischen dem, was Agenten entscheiden dürfen, und dem, was ich entscheide. Mein Kriterium ist Reversibilität. Alles, was sich rückstandsfrei zurückdrehen lässt -- Code in einem Branch, Tests, Reviews, Refactorings -- dürfen Agenten entscheiden. Alles, was nach außen wirkt oder nicht umkehrbar ist -- Deploy, Datenlöschung, Kommunikation -- entscheide ich. Ohne Ausnahme.

Und diese Linie steht bei mir nicht in einem Policy-Dokument, sondern im Code: in Berechtigungen, Hooks und Gates. Ein Agent kann sie nicht überreden. Eine Linie, die nur in einem PDF steht, existiert in der Praxis nicht.

Wichtig ist die ehrliche Einordnung: Bei mir fallen Owner und Freigeber zusammen, weil ich solo arbeite. In einer Organisation heißt dasselbe Prinzip, dass Ownership nicht diffundieren darf. Wenn "die KI" der Owner ist, ist niemand der Owner.

Der neue Skill: begründet widersprechen

Wenn Verifikation der knappe Skill ist, dann verschiebt sich auch, was man lernen muss. Die "struggle time", die früher beim Schreiben von Code anfiel, verschwindet nicht. Sie wandert: vom Code-Schreiben zum Falsifizieren.

Der wertvolle Skill ist nicht mehr, schnell Boilerplate zu tippen. Der wertvolle Skill ist, einem Agenten begründet zu widersprechen. Behauptungen prüfen, Hypothesen falsifizieren, Urteilsvermögen aufbauen. Das ist anstrengend, also echte struggle time -- nur an einer anderen Stelle.

Genau das meine ich, wenn ich sage, dass Verifikation der knappe Skill ist. Es geht nicht um Misstrauen gegenüber der Technik. Es geht um die nüchterne Erkenntnis, dass ein Agent, dem man nicht widersprechen kann, kein Werkzeug mehr ist, sondern ein Vorgesetzter. KI ist ein Werkzeug -- mächtig, aber nicht magisch. Die Stelle, an der der Mensch unersetzlich bleibt, ist das Urteil über das Ergebnis.

Es gibt ein verwandtes Thema, das ich hier bewusst nur streife: Geregelte Organisationen mit Freigabeprozessen und Guardrails tun sich mit dieser Verschiebung schwerer als ein Solo-Builder. Das ist ein eigenes Thema für einen eigenen Artikel. Hier bleibe ich bei der einen These: Verifikation ist der Skill, auf den es ankommt -- ob solo oder im Team.

Fazit

Die Verschiebung des Engpasses von der Produktion zur Verifikation ist die wichtigste Veränderung in der KI-gestützten Entwicklung. Wer das ignoriert, optimiert weiter die falsche Stelle.

Die Kernpunkte zusammengefasst:

1. Code ist billig geworden, Vertrauen nicht. Der gefährlichste Output ist der plausibel falsche.
2. Verifikation ist ein Architekturproblem. Gewaltenteilung beim Review, Scope-Grenzen, automatische Gates -- der Mensch prüft das Prüfsystem, nicht jede Zeile.
3. Wer freigibt, verantwortet. Accountability lässt sich nicht automatisieren. Ziehen Sie die Linie entlang der Reversibilität, und schreiben Sie sie in Code, nicht in ein PDF.
4. Der neue Skill ist begründeter Widerspruch. Behauptungen falsifizieren statt blind übernehmen.

Wie man diesen Prüf-Loop selbst aufbaut, habe ich im AI Builder-Guide auf agenticbuilders.at/guide zusammengestellt. Und wenn Sie über einen konkreten Anwendungsfall in Ihrem Unternehmen sprechen möchten, erreichen Sie mich über die Kontaktseite -- ich arbeite bewusst nur mit ein bis zwei Kunden gleichzeitig und nehme mir entsprechend Zeit.