Von Ion Anghel · April 2026
Ein CTO rief mich letztes Quartal an. Sein Pitch, grob zusammengefasst: „Wir hinken bei KI hinterher. Ich will jeden Entwickler bis Monatsende auf Copilot haben, und ich will die Velocity steigen sehen." Ich stellte ihm drei Fragen. Habt ihr Tests? „Einige." Habt ihr CI, das schlechte Merges blockiert? „Irgendwie." Wann hat zuletzt ein Senior den PR eines Juniors ernsthaft von vorne bis hinten reviewt? Lange Pause.
Er hatte kein KI-Problem. Er hatte ein Codebase-Problem, ein Prozess-Problem und ein Hiring-Problem, übereinandergestapelt. Copilot-Lizenzen zu kaufen würde alle drei schlimmer machen, nur schneller.
Ich will von Anfang an klar sein, denn der Rest dieses Textes wird wie Skepsis klingen und ist es nicht: Ich halte KI-gestützte Softwareentwicklung für eine der wichtigsten Verschiebungen unseres Handwerks in zwanzig Jahren. Ich nutze sie täglich. Ich liefere mehr dadurch. Der Punkt dieses Artikels ist nicht, dass KI überhypt ist — er ist, dass KI als Lösung für Probleme verkauft wird, die sie nicht löst, und diese Verwechslung kostet Teams echtes Geld.
KI ist ein Verstärker, kein Reparaturwerkzeug
Große Sprachmodelle und die darauf aufbauenden Agenten können eines sehr gut: sie führen die Muster fort, die sie sehen. Gib ihnen ein sauberes Modul mit konsistenter Benennung, vernünftigen Typen und Tests daneben, und sie werden es im gleichen Geist erweitern. Gib ihnen einen 200-Zeilen-Controller mit drei verschiedenen Error-Handling-Stilen, einem globalen mutablen Singleton und String-Konkatenation in SQL, und sie werden dir treu noch mehr genau davon produzieren. Das Modell wird sich nicht widersetzen und sagen: „Eigentlich hat diese Klasse zu viele Verantwortlichkeiten, lass mich erst refactoren." Es wird sich dem Raum anpassen.
Das ist der Teil, bei dem in keinem Verkaufsgespräch verweilt wird. KI hat keinen Geschmack zu deinem Codebase. Sie hat Statistik über deinen Codebase. Wenn die Statistik schlecht ist, ist der Output schlecht — nur ist es jetzt mehr davon, und es geht schneller live.
Das spürt man in jedem halbwegs alten Monorepo. Schick einen Agenten durch ein Legacy-Modul und schau, was rauskommt: selbstbewusst geschriebener Code, der plausibel aussieht, die vorhandenen Helper nutzt, die vorhandenen Anti-Patterns befolgt und die vorhandenen schwachen Tests besteht. CI ist grün. Der PR ist klein. Er wird gemergt. Sechs Wochen später pagest du jemanden um 2 Uhr nachts wegen einer Race Condition, von der der Agent nichts wissen konnte, in einem System, das der Agent nicht modellieren konnte.
Die Lösung ist nicht, den Agenten zu verbannen. Die Lösung ist anzuerkennen, dass der Codebase diese Velocity gar nicht erst tragen konnte.
Sicherheit ist die Stelle, wo es zuerst weh tut
Über die Jahre habe ich eine ganze Reihe kleiner bis mittelgroßer Webplattformen geprüft, und dieselbe Handvoll Probleme taucht fast jedes Mal auf. API-Keys, die in Git eingecheckt wurden, oft in der öffentlichen Historie auffindbar. .env-Dateien, die aus dem Webroot ausgeliefert werden, weil jemand eine Verzeichnisregel falsch konfiguriert hat. Webhooks, die jedes POST akzeptieren, weil die Signaturprüfung „TODO" war. Nutzereingaben, die ungeprüft in SQL fließen, oder in Shell-Befehle, oder in Template-Strings, die das Framework fröhlich als HTML rendert. GDPR-Consent-Flags, die im UI existieren, aber im Backend nie ausgewertet werden.
Keines dieser Probleme wurde von KI geschaffen. Sie sind Jahrzehnte älter. Aber was KI ändert: Sie senkt dramatisch die Kosten, neuen Code hinzuzufügen, und die meisten Teams haben keine entsprechende Investition darin, die Kosten zu erhöhen, unsicheren Code hinzuzufügen. Also werden dieselben Muster reproduziert, nur schneller. Der Agent sieht, dass die bestehenden Controller keine Eingaben validieren, und schreibt einen neuen Controller, der keine Eingaben validiert. Der Agent sieht, dass Secrets aus einer in Git getrackten .env geladen werden, und verwendet dieses Muster selbstbewusst in einem neuen Service. Der Agent ist nicht leichtsinnig. Er ist konsistent. Mit einem Codebase, der schon leichtsinnig war.
Ich habe über eine spezifische Variante dieses Versagensmusters in From Vibe Coding to Insecure Keys geschrieben — ein Projekt vom Prompt zur Produktion an einem Wochenende, mit Credentials direkt im Browser-Bundle. Das ist kein KI-Bug. Das ist eine Prozesslücke, die KI billig genug gemacht hat, um sie im großen Stil sichtbar werden zu lassen.
Ohne Tests und CI ist Velocity nur Risiko
Es gibt ein Gespräch, das ich immer wieder mit Engineering-Leadern führe. Sie wollen KI-Adoption an PR-Durchsatz messen, an Codezeilen, oder an geschlossenen Jira-Tickets. Das alles misst eine einzige Sache: wie schnell du Code ins System bringst. Keines davon misst, ob der Code überhaupt rein gehört.
Wenn du keine Tests hast, hast du kein Feedback. Wenn du kein CI hast, das diese Tests bei jeder Änderung laufen lässt und Merges bei Fehlern blockiert, hast du kein Sicherheitsnetz. Wenn du keinen Code Review hast, in dem ein zweiter Mensch tatsächlich das Diff liest und nachhakt, hast du keinen Qualitätsfilter. Setz einen KI-Agenten oben drauf, und was du gebaut hast, ist eine schnellere Strecke von der Idee zum Incident.
Die Teams, die echten Hebel aus KI ziehen, sind nicht die, die sie am aggressivsten adoptiert haben. Es sind die, die das Langweilige schon hatten — eine Testsuite, die in unter zehn Minuten läuft, eine Deploy-Pipeline, aus der du mit einem Klick zurückrollen kannst, Alerting, das einen Menschen pagest, bevor Kunden twittern. KI komprimiert die Arbeit zwischen den Leitplanken. Sie ersetzt die Leitplanken nicht.
„Vibe Coding" skaliert nicht über das Demo hinaus
Es gibt einen Arbeitsmodus — schnell, dialogisch, dem Modell weitgehend vertrauend — der wirklich wunderbar ist für Prototypen, interne Tools, Wochenendprojekte, neue Stacks lernen. Ich mache das ständig. So entsteht eine Menge nützlicher Software.
Es ist aber katastrophal unpassend für jedes System, das echte Nutzerdaten, Geld oder fremde Credentials verarbeitet und von jemandem deployt wird, der nicht persönlich jede Zeile liest, bevor sie live geht. Der Grund ist nicht, dass das Modell schlecht ist. Der Grund ist, dass „Vibe Coding" die Prüfungen bewusst abschaltet — du liest das Diff nicht sorgfältig, du denkst nicht adversarial über Eingaben nach, du fragst nicht „was passiert, wenn das fehlschlägt." Genau diese Prüfungen sind das, was Produktionscode mehr braucht, nicht weniger.
Der Fehler, den manche Unternehmen 2026 machen, ist, einen Workflow, der für einen Hackathon großartig ist, zur Grundlage eines Unternehmens zu machen. Das geht nicht.
Das eigentliche Problem ist fast nie technologisch
Hier die unbequeme Beobachtung, zu der ich immer wieder komme. Wenn ein Leadership-Team eine Flotte von KI-Tools kauft, um seine Engineering-Organisation zu „transformieren", ist KI oft nicht der eigentliche Kauf. Der eigentliche Kauf ist das Umgehen von drei viel schwierigeren Gesprächen.
Das erste handelt von technischer Schuld — der Art, die verlangt, vor dem Board laut auszusprechen, dass die Plattform, die ihr fünf Jahre lang gefeiert habt, darunter fault, und dass jemand ein Quartal mit Aufräumen verbringen muss. Das zweite handelt von Einstellungen — dass die Latte gesunken ist, dass es Leute im Team gibt, die nicht eingestellt oder befördert hätten werden sollen, und dass kein Maß an Tooling ein Team repariert, das nicht weiß, wie „gut" aussieht. Das dritte handelt von Standards — dass die Organisation sich nie darauf geeinigt hat, was „fertig" heißt, welche Tests Pflicht sind, was ein Review tatsächlich fangen muss, und dass alle jahrelang nach persönlichem Geschmack gearbeitet haben.
KI wird vermarktet als ein Weg, diese Gespräche zu überspringen. Sie ist es nicht. Sie ist nur ein Weg, ihre Konsequenzen schneller eintreten zu lassen.
Wo KI ihren Platz verdient
Ich will mit dem aufhören, was funktioniert, denn vieles tut es.
Auf einem gesunden Codebase — mit sauberen Modulgrenzen, vernünftigen Typen, einer echten Testsuite, Observability, die man tatsächlich lesen kann — ist KI-Assistenz wirklich transformierend. Ein Refactor über Dutzende Dateien wird zu einer Halbstunden-Aufgabe statt zu einem Sprint. Tests für gut strukturierten Code zu schreiben wird angenehm statt zäh. Dokumentation, für die niemand Zeit hatte, wird generiert und dann auf das Wesentliche zurechtgestutzt. Code Review bekommt ein zweites Augenpaar, das nie müde wird und die langweilige Klasse von Fehlern fängt, die Menschen um 17 Uhr übersehen. Explorative Analyse auf einem Datensatz, den du nie angefasst hast, wird zu einem Gespräch statt zu einem Nachmittag voller Stack Overflow.
In jedem dieser Fälle kommt der Hebel aus derselben Quelle: das Fundament war solide genug, damit das Modell in die richtige Richtung verstärken konnte. KI hat nichts repariert. Sie hat Arbeit beschleunigt, die schon korrekt war.
Was du Montagmorgen tun solltest
Wenn du gerade dabei bist, KI-Tooling über deine ganze Engineering-Organisation auszurollen, gibt es nur eine Sache, um die ich dich vorher bitten würde. Öffne die letzten drei Produktions-Incidents und lies die Postmortems ehrlich. Wurden sie durch etwas verursacht, was ein LLM hätte verhindern können — einen Tippfehler, einen vergessenen Null-Check, einen fehlenden Import? Oder wurden sie durch etwas Strukturelleres verursacht — keinen Test für diesen Pfad, kein Alerting auf dieses Signal, kein Review für diesen PR, einen Service, den niemand im Bereitschaftsdienst verstand?
Wenn es die zweite Kategorie ist — und sie ist es fast immer — dann ist das wirkungsvollste, was du dieses Quartal tun kannst, kein Copilot-Rollout. Es ist eine Testsuite, die bei jedem PR läuft. Es ist eine einseitige schriftliche Definition davon, was „fertig" für dein Team heißt. Es sind zwanzig Minuten Pairing pro Woche zwischen einem Senior und einem Junior beim Code Review, bis die Latte gemeinsam ist.
Mach das, und dann hol die KI rein. Sie wird sich zehnfach auszahlen, weil sie endlich etwas haben wird, das es wert ist, verstärkt zu werden.
Disclaimer: Ich bin bullish auf KI. Ich glaube, die meisten der rauen Kanten, die ich beschreibe, werden in den nächsten Jahren geglättet werden, und ich glaube, dass Entwicklerinnen und Entwickler, die lernen, neben diesen Werkzeugen zu arbeiten, mit weitem Abstand mehr liefern werden als die, die es nicht tun. Aber der Weg in diese Zukunft führt durch Engineering-Disziplin, nicht daran vorbei. Die Teams, die mit KI gewinnen werden, sind diejenigen, die schon ohne sie gewonnen haben — und die Teams, die heute kaputt sind, werden schneller kaputt sein, teurer, und vor mehr Kunden.