“AI makes teams move faster” - diesen Satz haben wir alle schon gehört. Meist denken wir dabei an Startups, die ganze Produkte in wenigen Tagen produzieren.
Aber wir vergessen, dass wir uns auch schneller in die falsche Richtung bewegen können. Und genau darin liegt die Gefahr von KI in der Softwareentwicklung.
In diesem Artikel schauen wir uns an, was der neue limitierende Faktor in der Softwareentwicklung ist, welche Probleme das bereitet und wie wir uns damit arrangieren können.
Der Engpass hat sich verschoben
Früher war es Zeit
Früher war Zeit der limitierende Faktor in der Softwareentwicklung. Heute ist sie das nicht mehr, zumindest nicht im selben Maß.
Und weil Zeit der Engpass war, haben sich Software-Teams genau überlegt, welche Tasks sie wann bearbeiten wollten. Es ging darum, die zeit so gut wie möglich zu nutzen.
Der Aufstieg der KI-Agenten hat diesen Engpass verschoben.
Es braucht immer noch Zeit, Software zu entwickeln, aber eben nicht mehr so viel - und genau das ist der Punkt. Sowas wie “Dafür würde ich zwei Wochen brauchen. Lass uns das erstmal verschieben.” hört man nur noch selten. Öfter heißt es nun “Ich schaue mir das kurz an und melde mich morgen.”.
Das Problem ist:
Nur weil etwas schnell gebaut werden kann, heißt das nicht, dass es schnell verstanden oder richtig entschieden wird.
4 Dinge, die jetzt zum Engpass werden
Die Konsequenz aus dem letzten Abschnitt ist leider nicht, dass es keine Engpässe mehr gibt und wir endlos viel Software in kürzester Zeit erstellen können.
Stattdessen werden nun 4 andere Themen zu Engpässen.
Fokus
Nur weil jetzt alles schneller gebaut werden kann heißt das nicht, dass alles gebaut werden sollte.
Wir alle kennen diese Produkte, die am zu Beginn fast perfekt erschienen, weil sie genau ein Problem sehr gut gelöst haben. Aber mit der Zeit kommen immer mehr Features dazu, bis das Produkt irgendwann kaum noch verwendbar ist und man sich nach einer Alternative umschauen muss..
Genau das gleiche passiert jetzt durch KI, nur viel schneller und auch in kleineren Teams.
Es werden einfach immer weiter neue Features hinzugefügt anstatt zu hinterfragen, was das beste für das Produkt ist.
Koordination
Früher war der Aufwand eines Features ein natürlicher Filter für Entscheidungen. Dieses Verhältnis existiert heute nicht mehr und große Änderungen sind plötzlich billig.
Außerdem können große Features in kurzer Zeit implementiert werden:
Die Custom Implementation “Text 2 SQL” liefert nicht die gewünschte Verlässlichkeit? Kein Problem, ersetze das kurz durch die API eines Drittanbieters. Eine Stunde später fällt dir auf, dass die anderen Entwickler all ihre Module anpassen müssen, weil die Datenstruktur der neuen API leicht anders ist. Und außerdem hast du vergessen zu checken, welche Rate Limits der Anbieter hat und jetzt musst du viel Geld bezahlen, um diese zu umgehen. Aber das ganze ist schon deployed.
Früher hätte man die Entscheidung im Team diskutiert. Heute wird einfach umgesetzt.
Verständnis
Früher musste man den Code verstehen, um ihn schreiben zu können. Das hat kurzfristig zwar länger gedauert. Langfristig hatte es aber den positiven Effekt, dass die Entwickler das System verstanden haben, schneller Debuggen konnten und den Projektmanagern bessere Antworten geben konnten (“Wie entscheidet unser System eigentlich XYZ?”).
Heutzutage wird diesem Verständnis allerdings immer weniger Aufmerksamkeit geschenkt.
Anstatt den Code und die Architektur zu verstehen, die die KI implementiert, wird oft gesagt “funktioniert ja, das ist das Wichtigste”. KI entkoppelt das Schreiben von Code vom Verständnis des Codes.
Kurzfristig lässt sich so mehr Code produzieren.
Langfristig verlieren die Entwickler so die Kontrolle über den Code und bringen sich in Lagen in denen sie nicht mehr wissen, das ihr System tut.
Und nicht selten entwickeln sie Code (oder lassen entwickeln), der schwer zu debuggen ist, auch für einen KI-Agenten. Und genau das macht diese Entwicklung so gefährlich.
Ownership
Ein weiteres Problem, das durch AI verstärkt wird: Verantwortung.
In vielen Teams sieht man mittlerweile folgende Situation: Man findet einen Bug und der dazugehörige Code ist schwer zu verstehen. Deswegen bittet man den Entwickler, der diesen Code gepusht hat, um Erklärung. Die Antwort des Entwicklers ist dann aber: “Ehrlich gesagt habe ich das mit einem KI-Agenten gemacht. Ich weiß nicht, warum das genau so implementiert wurde”.
Noch vor ein paar Jahren hätte sich jeder Entwickler geschämt zugeben zu müssen dass er nicht weiß, was er da gemacht hat.
Heute ist das anders.
Und das liegt daran, dass sich Entwickler nicht mehr für den Code verantwortlich fühlen, den die KI implementiert. Sie betrachten sich nicht mehr als den Autor.
Mit 4 Regeln zur Lösung
Diese Probleme entstehen nicht durch KI, sondern durch unseren Umgang damit. und genau deswegen müssen wir unsere Arbeitsweise anpassen. Die folgenden Regeln sollen dabei helfen.
Du hat die Kontrolle
Viele Entwickler geben die Kontrolle an die KI ab. Sie lassen den Agenten entscheiden, wie die Architektur auszusehen hat und welche Implementationsstrategie verfolgt wird.
Mit diesem Ansatz ist das Chaos vorprogrammiert.
Der Agent wird schlechte Architekturentscheidungen treffen, ungewollte Patterns einführen, bestehende Services nicht richtig einbinden usw. Und das wird schneller als du denkst zu einer Codebase führen, die weder für dich noch für den Agenten wartbar ist.
Die Lösung liegt darin, eigene Recherchen und Entscheidungen zu treffen, bevor du den KI-Agenten involvierst.
Dann kannst du nämlich so prompten: _“Ich will Feature XZY implementieren. Erstelle dafür ein neues Model mit diesen Feldern: […]. Dann erstelle einen Controller names XYZ und einen neuen Service ABC”.
Du lässt der KI also gar keinen Entscheidungsspielraum und erleichterst dir damit auch den späteren Code-Review.
Dein Code, deine Verantwortung
Wenn du den Code pushst, bist du verantwortlich für den Code. Du wirst dafür geradestehen müssen, wenn etwas damit schief läuft und du wirst Bugs in dem Code fixen müssen. Und wenn Fragen zu dem Code aufkommen, musst du eine Antwort haben.
Verstehe jede Zeile
Du solltest alles was der KI-Agent produziert verstehen. Lese jede Zeile, verstehe den Flow, hinterfrage alles.
Nur so kannst du sicherstellen, dass du es verstehst und dass du Verantwortung für den Code übernehmen kannst.
Das wird schwieriger, je größer die Änderungen des KI-Agenten sind. Wenn nur eine neue Methode mit 5 Zeilen hinzukommt ist es recht einfach, diese zu verstehen. Wenn aber 1.000 Zeilen und 15 Dateien angefasst werden, wird es schwierig.
Am einfachsten vermeidest du das, indem du Regel 1 befolgst: Du selbst triffst die Architekturentscheidungen und lässt die KI dann die Änderungen in kleinen Schritten durchführen, die du Häppchenweise reviewen kannst.
Triff große Entscheidungen nicht alleine
Auch wenn es verführerisch ist, größere Änderungen und Features schnell selbst zu implementieren - lass es lieber.
Bring das gegenüber dem Team zur Sprache und hole deren Meinung ein. Fast immer wirst du Erkenntnisse erlangen, die deinen Plan beeinflussen. Und deine Kollegen werden es dir danken, wenn du sie nicht übergehst.
Fazit
Die Softwareentwicklung hat sich in den letzten Jahren stark verändert. Während früher der zeitliche Aufwand oft eine große Rolle gespielt hat, ist dies heute weniger relevant.
Dadurch ist aber eine ganz neue Kategorie von Engpässen entstanden, denen mit viel Disziplin und strikten Regeln begegnet werden muss.