Den Vormittag habe ich damit verbracht, das Material für eine interne Schulung zu überarbeiten. Sechsundzwanzig dichte Seiten, voller Workflows, Befehle, Checklisten. Irgendwann habe ich innegehalten und aus dem Fenster gesehen. Ich habe mich gefragt: wann ist das alles passiert?
Vor einem Jahr diskutierten wir noch, ob wir Copilot zur Autovervollständigung nutzen sollten. Heute schreiben wir Dokumente namens „Constitution“, die das Verhalten von KI-Agenten regeln, die ganze Features erzeugen. Der Sprung war nicht graduell. Es war, als wäre der Boden über Nacht ein paar Zentimeter verrutscht.
Vibe Coding und sein Reiz
Beim Vorbereiten des Materials hat mich ein Begriff getroffen: Vibe Coding. Vage beschreiben, was du willst, und die KI etwas produzieren lassen. Wir alle haben das in den ersten Monaten gemacht. Es hatte etwas fast Magisches, wenn aus einer ungefähren Beschreibung Code erschien. Funktionierte er? Manchmal ja, oft nein. Aber das Gefühl der Geschwindigkeit war berauschend.
Das Problem ist, dass diese Geschwindigkeit eine Illusion war. So generierter Code, ohne präzise Spezifikationen, ohne durchdachte Architektur, häufte technische Schulden in beeindruckendem Tempo an. Jedes neue Feature war eine Wette. Vielleicht funktioniert es heute, vielleicht zerbricht morgen alles, sobald jemand etwas anderes berührt.
Ich habe POCs wie Raketen starten und in wenigen Wochen zerschellen sehen. Nicht, weil die KI Fehler gemacht hätte, sondern weil niemand darüber nachgedacht hatte, was wir bauen. Wir improvisierten mit einem höchst leistungsfähigen Werkzeug ohne Partitur.
Die Spezifikation als neue Ausdrucksform
Die Antwort, die wir erkunden und im Kurs zu lehren versuchen, kehrt den Ansatz um. Sie heißt Spec-driven Development, und die Grundidee ist einfach, fast banal: schreibe zuerst mit manischer Präzision, was du willst, und lass dann jemand anderen (in diesem Fall einen KI-Agenten) es umsetzen.
Aber ein Aspekt fasziniert und beunruhigt mich zugleich. Präzise Spezifikationen zu schreiben ist enorm schwer. Es verlangt, an jeden Edge Case zu denken, jedes Fehlerszenario, jede mögliche Mehrdeutigkeit. Es verlangt, exakt zu wissen, was man will, bevor man es funktionieren sieht.
Das ist gewissermaßen das Gegenteil dessen, wie viele von uns programmieren gelernt haben. Ich habe gelernt, indem ich experimentierte, probierte, irrte, korrigierte. Ein ständiger Kreislauf von Versuch und Fehler, der am Ende etwas hervorbrachte, das funktionierte. Jetzt wird von uns verlangt, alles im Voraus zu denken, präzise zu sein, bevor wir eine einzige Zeile Code schreiben.
Ich bin nicht sicher, dass es nur eine positive Veränderung ist. Vielleicht verlieren wir etwas im Experimentieren, im zufälligen Entdecken eleganter Lösungen, die beim Schreiben aufscheinen. Aber vielleicht gewinnen wir etwas anderes: die Möglichkeit, größere und komplexere Systeme zu bauen, als wir je allein hätten bauen können.
Das Paradox der Kompetenzen
Etwas, worüber ich viel nachgedacht habe, ist das Kompetenzparadox dieser neuen Arbeitsweise. Im Material gibt es einen Satz, den ich mehrfach unterstrichen habe:
Das heißt nicht, dass technische Kompetenzen obsolet werden. Im Gegenteil — sie müssen noch solider sein.
Klingt kontraintuitiv. Wenn die KI den Code schreibt, warum soll ich programmieren können? Die Antwort: man muss besser programmieren als zuvor, um zu erkennen, ob das, was die KI produziert hat, Sinn ergibt. Um die Architektur zu validieren. Um Sicherheitsprobleme zu erkennen. Um zu wissen, wann etwas ein fragiles Workaround ist, getarnt als elegante Lösung.
Ich habe Junioren erlebt, die sich für KI-Code begeisterten, ohne zu merken, dass er gravierende Schwachstellen enthielt. Nicht-parametrisierte Queries, fehlende Validierungen, hardcodete Secrets. Die KI hatte unsichere Patterns aus ihren Trainingsdaten kopiert. Es brauchte jemanden mit Erfahrung, das zu erkennen.
In gewisser Weise werden wir Vollzeit-Reviewer. Unsere Arbeit verschiebt sich von der Produktion zur Aufsicht, vom Schreiben zum kritischen Lesen. Ich weiß nicht, ob das Verlust oder Gewinn ist. Wahrscheinlich beides.
Die Constitution und die Illusion der Kontrolle
Im Framework, das wir einführen, gibt es ein zentrales Konzept: die Constitution. Ein Dokument, das die unverrückbaren Prinzipien des Projekts festhält. Dinge wie „kein any-Type erlaubt“ oder „Mindest-Coverage 80 %“ oder „jede PR braucht menschliche Code Review“. Die KI soll diese Prinzipien in jeder Entscheidung respektieren.
Funktioniert das? Im Wesentlichen ja. Die KI folgt den Regeln, wenn man sie ihr klar gibt. Aber etwas an dem Ganzen ist leicht ironisch. Wir schreiben Verfassungen für Maschinen. Wir definieren Gesetze, denen Algorithmen folgen sollen. Eine interessante Umkehrung der Beziehung zwischen Menschen und Werkzeugen.
Was ich mich frage, ohne Antwort, ist, wie weit diese geschriebenen Regeln das einfangen können, was wir wirklich meinen. Ich kann „kein Workaround oder Hack im Code“ schreiben — aber wie definiere ich genau, was ein Hack ist? Manchmal ist die Linie zwischen pragmatischer Lösung und Hack unscharf, kontextabhängig, verlangt Urteil. Dieses Urteil bleibt vorerst menschlich.
Die Zeit, die nicht mehr ist
Etwas hat sich subtil, aber tief verändert: der Bezug zur Zeit. Früher dachte ich, wenn ich schätzte, wie lange ein Feature dauert, in Stunden oder Tagen Arbeit. Heute denke ich, wie lange ich brauche, eine ausreichend präzise Spezifikation zu schreiben und den Output zu validieren.
Paradoxerweise dauert das manchmal länger. Eine vollständige Spezifikation zu schreiben, jede Mehrdeutigkeit zu klären, jeden Edge Case zu definieren, kann genauso lang dauern wie das Schreiben des Codes. Aber die Art der Arbeit ist eine andere. Mentaler, abstrakter. Weniger Stunden vor dem Debugger, mehr Stunden im Denken.
Nicht alle im Team finden sich damit zurecht. Manche Kollegen liebten gerade dieses Flow-Gefühl, wenn der Code aus den Fingern strömt, wenn man im Problem versinkt und Lösungen fast von selbst auftauchen. Dieser Geisteszustand ist seltener geworden. Die Arbeit ist fragmentierter, mehr Review und Validierung, weniger ununterbrochenes Schaffen.
Sicherheit als notwendige Obsession
Es gibt einen Aspekt von KI-Code, der mich offensichtlich unruhig macht: die Sicherheit. Im Kursmaterial habe ich einen ganzen Abschnitt den spezifischen Risiken gewidmet. Unsichere Patterns, verwundbare Abhängigkeiten, nicht-parametrisierte Queries. Die KI hat keine Bosheit, aber auch keine Vorsicht. Sie reproduziert, was sie gesehen hat, Fehler eingeschlossen.
Was mich beunruhigt: viele dieser Probleme sind nicht auf den ersten Blick erkennbar. Der Code kompiliert, die Tests laufen, die Anwendung funktioniert. Die Schwachstelle ist verborgen, still, wartet, bis sie jemand findet und ausnutzt. Es braucht ein erfahrenes Auge, sie zu sehen. Es braucht Zeit für sorgfältige Reviews.
Wir haben automatische Tools in die Pipeline gehängt: Audit der Abhängigkeiten, Secret-Scan, statische Analyse. Sie helfen, reichen aber nicht. Am Ende muss jemand sich hinsetzen und den Code Zeile für Zeile lesen und fragen: was könnte hier schiefgehen? Und ich habe (wieder) die Bedeutung von e2e-Tests gelernt.
Was von uns bleibt
Manchmal frage ich mich, was in fünf Jahren von unserem Beruf bleibt. Nicht im apokalyptischen Sinn „Programmierer werden ersetzt“, was mir vereinfachend scheint. Sondern: was werden wir tatsächlich tun, Tag für Tag.
Wahrscheinlich werden wir weniger Code schreiben und mehr Spezifikationen. Wir werden mehr Code lesen, als wir schreiben. Wir werden mehr Zeit damit verbringen, an Architektur, Sicherheit und die Implikationen jeder Entscheidung zu denken. Weniger Handwerker und mehr Architekten, weniger Bauende und mehr Aufsehende.
Ich weiß nicht, ob das allen gefallen wird. Viele liebten es, Code zu schreiben. Viele liebten dieses Gefühl, etwas mit den eigenen Händen zu bauen, auch wenn die Hände nur metaphorisch waren. Vielleicht wandelt sich dieses Gefühl. Oder man sucht es anderswo, in privaten Projekten, in denen niemand verlangt, effizient zu sein.
Ein Beruf im Übergang
Was ich in der Schulung jenseits von Befehlen und Checklisten zu vermitteln versuche, ist das Bewusstsein, dass wir in einer Übergangszeit sind. Wir wissen noch nicht, wohin wir gehen, aber wir wissen, dass wir nicht zurückkehren werden.
Vibe Coding war ein Experiment, eine jugendliche Phase im Umgang mit diesen Werkzeugen. Jetzt versuchen wir, erwachsen zu werden, Prozesse und Disziplinen zu bauen, die uns erlauben, diese Macht zu nutzen, ohne uns zu verletzen. Eine Arbeit im Werden, klar.
In einigen Monaten werde ich dieses Material wahrscheinlich erneut ansehen und es schon überholt finden. Etwas wird sich wieder verändert haben. Werkzeuge anders, Workflows weiterentwickelt. Das Schöne und das Mühsame der Arbeit in einem so schnell bewegten Feld.
Vorerst kann ich dokumentieren, was wir lernen, es mit dem Team teilen, versuchen, Kompetenzen zu bauen, die über das spezifische Werkzeug hinausgehen. Strukturiert denken, präzise Spezifikationen schreiben, fremde Outputs kritisch validieren: das scheinen mir Fähigkeiten, die nützlich bleiben, was auch geschieht — und die Menschen wertvoll machen.
Oder zumindest ist es das, was ich mir in letzter Zeit immer wieder sage.
Was du mitnimmst
Es braucht mehr technische Kompetenz, nicht weniger: man muss besser programmieren als zuvor, um zu beurteilen, ob das Produzierte Sinn ergibt.
Eine Constitution für Maschinen zu schreiben löst das Problem des Urteilens nicht: die Unterscheidung zwischen pragmatischer Lösung und Hack bleibt kontextabhängig, und dieses Urteil bleibt menschlich.
Der Flow, in dem der Code aus den Fingern strömt, ist seltener: die Arbeit hat sich von der kontinuierlichen Kreation zur kritischen Review verschoben.
Fragen & Antworten
Wie verändert sich der Beruf der Entwicklerin mit KI-Agenten?
Vom Code-Schreiber zur Person, die Spezifikationen schreibt und validiert. Früher war der Engpass das Produzieren der Zeilen; jetzt ist es das Definieren, was zu produzieren ist, und das Prüfen, ob es korrekt erzeugt wurde. Code wird zum Nebenprodukt der Spezifikation, und die Spezifikation wird wieder zum Kern des Handwerks — wo sie vor vierzig Jahren stand, bevor der Boom der zufälligen Komplexität sie in den Schatten stellte.
Was bedeutet „Spezifikations-Architekt“?
Jemand, der ausführbare Spezifikationen schreiben kann — keine narrative Doku, sondern Anweisungen, die präzise genug sind, um beim Übergeben an einen KI-Agenten korrekten Output zu erzeugen. Das schließt explizite Akzeptanztests ein, Schnittstellenverträge, System-Invarianten, nichtfunktionale Anforderungen (Latenz, Kosten, Sicherheit). Die Kompetenz ist nicht neu — sie war für formale Systeme und TLA+ schon zentral —, aber sie wird wieder breit nachgefragt.
Ist, wer heute Code schreibt, von Obsoleszenz bedroht?
Wer nur Code schreibt, ja. Wer Code schreibt, gestützt auf tiefes Domänenverständnis, Architektur-Trade-offs und Verifikation, nein — diese Kompetenz bleibt unersetzlich. Das Risiko ist nicht die KI, es ist eine berufliche Identität, die nur auf dem Tippen baut. Die Neugier, die fragt, warum etwas funktioniert, lässt sich nicht automatisieren.
Wie bereitet man sich auf diesen Übergang vor?
Drei konkrete Investitionen: (1) leichte formale Spezifikationen lernen — property-based Testing, klare Schnittstellenverträge; (2) sich an Code Review von KI-generiertem Code als Hauptaktivität gewöhnen, nicht als Beiwerk; (3) Systemurteil entwickeln — was sind die echten Anforderungen eines Projekts, wo kostet ein Fehlschlag und wo nicht. Eine Metamorphose vom Handwerker zum Architekten, die früher wenigen Senioren vorbehalten war und heute alle betrifft.
Der Autor
