Manchmal macht es tatsächlich Spaß, mit anderen Menschen über KI in der Softwareentwicklung zu diskutieren. Besonders dann, wenn man auf Positionen trifft, die unterschiedlicher kaum sein könnten. Auf der einen Seite stehen diejenigen, die mit KI experimentieren, ihre Möglichkeiten austesten und versuchen, sie sinnvoll in den Entwicklungsalltag zu integrieren. Auf der anderen Seite gibt es immer noch viele, die jede Nutzung von KI kategorisch ablehnen. Für sie ist das Thema im Grunde bereits entschieden: KI taugt nichts, produziert keinen brauchbaren Code und spart am Ende ohnehin keine Zeit.

Interessanterweise gehen viele dieser Meinungen mit einer gewissen Verweigerungshaltung einher. Häufig hört man, dass es sich gar nicht lohne, KI überhaupt auszuprobieren. Allein das Testen sei bereits Zeitverschwendung, schließlich gebe es genügend Argumente, die angeblich belegen würden, dass KI ohnehin nichts taugt. Besonders oft fällt in diesem Zusammenhang das Argument, dass der durch KI erzeugte Code ja überprüft werden müsse. Dieser zusätzliche Review-Aufwand würde den möglichen Zeitgewinn direkt wieder zunichtemachen.

Dabei wird implizit eine bemerkenswerte Annahme getroffen: dass menschliche Entwickler offenbar keinen Code produzieren, der überprüft werden muss. Als wären Code Reviews nur deshalb erfunden worden, weil es jetzt KI gibt. In dieser Logik wäre der Code von Menschen grundsätzlich korrekt, während nur KI fehlerhaften Code erzeugt. Die Realität in der Softwareentwicklung sieht allerdings deutlich anders aus. Code Reviews existieren nicht, weil irgendjemand in der Vergangenheit KI vorhergesehen hat, sondern weil jede Quelle von Code potenziell fehleranfällig ist. Ganz egal, ob dieser Code von einer Maschine oder einem Menschen stammt.

Meine eigenen Erfahrungen zeigen ziemlich klar, dass Menschen sehr viele Fehler machen. Das ist völlig normal und gehört zum Entwicklungsprozess dazu. Jeder Entwickler hat schon schlechten Code geschrieben, oft ohne es in dem Moment zu merken. Im Vergleich dazu schneidet eine KI erstaunlich häufig ziemlich gut ab. Der entscheidende Unterschied liegt dabei weniger in der Fehlerfreiheit als in der Geschwindigkeit. Wenn ein Mensch einen Fehler macht, kann es Stunden dauern, bis er entdeckt und korrigiert wird. Mit KI laufen diese Iterationen oft innerhalb weniger Minuten ab. Fehler entstehen auf beiden Seiten, aber die Geschwindigkeit, mit der man sie finden und beheben kann, verändert sich drastisch.

Ein weiteres häufiges Argument lautet, dass der Review von KI-Code besonders aufwendig sei, weil bestehende Konzepte und Teamstandards nicht eingehalten würden. Die KI kenne diese Regeln schließlich nicht. Interessanterweise wird dabei selten erwähnt, dass neue Entwickler diese Standards ebenfalls nicht automatisch kennen. Niemand beginnt einen neuen Job und weiß intuitiv, welche internen Regeln in einem Team gelten. Auch Menschen müssen diese erst lernen, meistens anhand von Dokumentationen oder durch Gespräche mit Kollegen.

Genau dieselben Informationen könnte man einer KI ebenfalls geben. Tatsächlich liest eine KI ein solches Dokument sogar deutlich schneller als ein Mensch. Sollte es allerdings gar keine dokumentierten Standards geben, liegt das Problem vermutlich an einer ganz anderen Stelle. In vielen Teams existieren diese Regeln nämlich nur in den Köpfen einzelner Entwickler. Sobald jemand Neues hinzukommt, beginnt das mühsame Entschlüsseln dieser impliziten Erwartungen. Dass eine KI daran scheitert, zeigt dann weniger eine Schwäche der KI als eine Schwäche der vorhandenen Prozesse.

Oft wird auch argumentiert, dass eine KI gar nicht wissen könne, welche zusätzlichen Informationen in Meetings oder Calls besprochen wurden. Aber dieses Problem betrifft jeden, der an einem Meeting nicht teilgenommen hat. Wenn Informationen nicht festgehalten werden, kann niemand darauf zugreifen. Wer daraus ableitet, dass nur KI dadurch ein schlechter Entwickler wäre, müsste konsequenterweise auch jedem Kollegen, der einmal einen Termin verpasst hat, dieselbe Unfähigkeit unterstellen. In der Praxis wäre es ohnehin sinnvoller, solche Meetings zu dokumentieren oder direkt automatisch zusammenfassen zu lassen.

Ein besonders unterhaltsamer Teil dieser Diskussionen dreht sich um Coding-Standards und Code Style. Ich habe im Laufe meiner Karriere an genügend Code-Style-Meetings teilgenommen, um eine gewisse Skepsis gegenüber deren tatsächlichem Nutzen entwickelt zu haben. Häufig werden solche Meetings von jemandem initiiert, dessen persönliches ästhetisches Empfinden durch den Code anderer Entwickler beleidigt wurde. Diese Person erklärt dann zunächst ausführlich, wie wichtig ein einheitlicher Coding Style für jedes Team sei.

Darauf folgt meist eine Liste dramatischer Szenarien darüber, was alles passieren könnte, wenn man sich nicht darum kümmert. Der Code wäre angeblich schon nach wenigen Monaten völlig unlesbar. Danach werden Beispiele präsentiert, wie man Dinge „richtig“ macht. Ich habe tatsächlich einmal erlebt, dass ernsthaft gefordert wurde, die Einrückung im Code von vier auf drei Spaces zu ändern, weil dies angeblich deutlich besser lesbar sei. Nicht zwei, nicht vier – exakt drei.

Unternehmen lieben solche Initiativen, weil sie den Eindruck vermitteln, dass damit automatisch die Codequalität steigt und Fehler drastisch reduziert werden. Am Ende schreibt jemand ein Dokument mit den neuen Regeln. Dieses Dokument wird anschließend kaum noch gelesen, während es von seinem ursprünglichen Autor gelegentlich weiter gepflegt wird. In Code Reviews fallen Verstöße selten auf, weil auch der Reviewer das Dokument nie wirklich studiert hat. Manchmal gibt es dann irgendwann einen automatischen Reformat, und der Code landet wieder beim Standardstil der verwendeten IDE.

Ich habe in solchen Situationen oft gefragt, warum man bei PHP nicht einfach sagt, dass man sich an PSR-12 halten soll. Eine kurze Nachricht im Chat würde ausreichen, und jeder wüsste sofort, woran er ist. Die Reaktionen zeigen dann meist recht schnell, dass es selten wirklich um Verbesserungen ging. Häufig stehen persönliche Vorlieben oder ein gewisses Bedürfnis nach Einfluss im Mittelpunkt.

Genau hier liegt übrigens eine der Stärken von KI. Man gibt ihr einen etablierten öffentlichen Coding-Standard und lässt zusätzlich eine Pipeline laufen, die diesen Stil automatisch überprüft und erzwingt. Die KI kann sich problemlos daran halten oder bestehenden Code entsprechend anpassen. Sobald die Regeln klar formuliert sind, funktioniert das erstaunlich zuverlässig.

Grundsätzlich gilt: Wenn Prozesse sauber dokumentiert sind, kann eine KI hervorragend damit arbeiten. Wenn stattdessen viele Dinge nur im Kopf einzelner Entwickler existieren, dann deckt eine KI lediglich bereits vorhandene strukturelle Probleme auf. In gewisser Weise verhält sich die Einführung von KI sehr ähnlich wie das Onboarding eines neuen Junior Developers. Wenn ein Team daran scheitert, einer KI die notwendigen Informationen bereitzustellen, hätte es vermutlich auch große Schwierigkeiten gehabt, einen neuen Entwickler sinnvoll einzuarbeiten.

Natürlich kostet die Nutzung von KI Zeit. Man muss Prompts formulieren, Ergebnisse prüfen und manchmal nachjustieren. Aber genau diese Aufwände entstehen auch bei menschlicher Zusammenarbeit. Oft sogar in größerem Umfang. Gleichzeitig bringt KI einen enormen Geschwindigkeitsvorteil mit sich. Code entsteht in Sekunden oder Minuten statt in Stunden. Dieser Code ist nicht immer perfekt, aber perfekt war Code früher auch nicht.

Am Ende wirken viele der vorgebrachten Argumente weniger wie fundierte Kritik und mehr wie Ausreden. Dahinter steckt oft die Hoffnung, dass sich das Thema irgendwie von selbst erledigt, wenn man lange genug abwartet. Stattdessen wäre es wahrscheinlich sinnvoller, sich aktiv damit auseinanderzusetzen und die Entwicklung mitzugestalten. Denn wenn es berechtigte Bedenken gibt, dann lassen sie sich nur lösen, wenn man beginnt, mit der Technologie zu arbeiten – nicht, wenn man sie ignoriert.