KI-Coding-Agenten committen deine schlechten Gewohnheiten schneller
KI-Coding-Agenten erfinden keine neuen Fehler in der Softwareentwicklung. Sie committen die Fehler nur schneller, die wir immer schon gemacht haben. Die Arbeit mit ihnen fühlt sich an wie ein Blick in einen leicht verzerrten Spiegel. Der Drang, hilfreich zu sein, die Eile, etwas auszuliefern, die vage Anforderung, die niemand hinterfragt hat, der schnelle Patch, der eigentlich nur vorübergehend sein sollte. All das tun sie auch, nur zehnmal so schnell. Mich interessiert, was diese Agenten Tag für Tag über meine eigene Arbeitsweise offenlegen. Und warum es am eigentlichen Punkt vorbeigeht, dem Tool die Schuld zu geben.
)
1. Mit verbundenen Augen loslaufen
Agenten wollen helfen. Unbedingt. Gib einem Agenten eine Aufgabe und er legt sofort los. Er löst genau diese Aufgabe, genau so, wie sie formuliert wurde, fast ohne Rückfragen oder einen Moment des Zweifels.
Angenommen, ich sage:
„Baue eine Exportfunktion.“
Zehn Minuten später habe ich einen CSV-Export mit Filtern, drei Hilfsfunktionen und einem Haufen Tests. Sieht produktiv aus, könnte aber völlig falsch sein.
Vielleicht wollte der Kunde nie einen CSV-Export. Vielleicht war das eigentliche Problem nie einfach nur „Daten exportieren“, sondern: „Ich möchte nicht mehr jeden Freitagnachmittag Zahlen in Excel kopieren.“
Und jetzt kommt der unangenehme Teil: Ich mache genau dasselbe. Ich höre eine Anforderung und fange an zu bauen, weil es sich sofort produktiv anfühlt und Fragen stellen wirkt eher wie eine Blockade des Fortschritts. Dabei begann jede Software, auf die ich wirklich stolz bin, mit langweiligen Fragen. Wer braucht das? Warum? Was passiert, nachdem die Person auf den Button geklickt hat? Muss es überhaupt ein Button sein?
Der Agent überspringt diese Fragen oft, weil ich ihm nie sage, dass mir welche stellen soll. Und in der Hälfte der Fälle überspringe ich sie ebenfalls. Deshalb schreibe ich inzwischen „Stell mir Fragen, bevor du Code schreibst“ in meine Prompts. Es ist eine winzige Änderung, aber sie wirkt Wunder. Plötzlich will der Agent wissen, wer den Export nutzt, in welchem Format er gebraucht wird und ob er nach einem Zeitplan ausgeführt werden muss. Das sind genau die Fragen, die ich dem Kunden von Anfang an hätte stellen sollen.
2. Der schleichende Verfall
Überspringt man die Fragen und optimiert nur auf Entwicklungsgeschwindigkeit, zeigt die Codebasis schnell ein ganz bestimmtes Symptom: Duplikate.
Wenn es keinen offensichtlichen Ort gibt, an den eine bestimmte Logik gehört, wird der Agent diesen auch nicht auf magische Weise finden. Er schreibt eine Hilfsfunktion, die zwei Ordner weiter bereits existiert. Er baut eine zweite Version der Validierungslogik, weil die vorgesehene Abstraktion für ihn nie sichtbar war.
Und es funktioniert. Vorerst. Genau das macht es so gefährlich: Duplizierter Code ist ein schleichender Bug-Generator. Eine Kopie wird aktualisiert, die andere nicht, und sechs Monate später weiß niemand mehr, welche die „echte“ ist.
Ich habe für diese Lektion bezahlt. Ein Agent erstellte einmal sehr selbstbewusst ein zweites Mapping für Datenbankdaten, die wir an anderer Stelle bereits gemappt hatten. Mit der Zeit drifteten die beiden Implementierungen auseinander: Beschreibungen verschwanden, Dezimalzahlen wurden unterschiedlich gerundet und irgendwann wurden die Daten selbst beschädigt. Das erreichte nie das Produktivsystem, weil ich es rechtzeitig bemerkte. Trotzdem kostete es mich viel zu viel Zeit und einiges an Nerven.
Die Lösung ist einfach. Schreib die Muster an einer Stelle auf, an der der Agent sie finden kann. Bei mir ist das eine kurze Konventionsdatei im Stammverzeichnis des Repositories, eine AGENTS.md oder was auch immer das jeweilige Tool liest: wo Mappings liegen, welche Hilfsfunktionen bereits existieren und wie wir Dinge benennen. Der Agent liest sie vor jeder Aufgabe und wir sollten das von Zeit zu Zeit vielleicht auch mal tun.
3. Ein Pflaster auf einem gebrochenen Bein
Agenten sind brillant darin, Fehler verschwinden zu lassen. Ein Test schlägt fehl? Ändere die Assertion. Eine Response ist undefined? Vergrabe sie unter Optional Chaining. Symptom weg, alle glücklich.
Doch der sichtbare Fehler ist meistens nur der Rauch. Das Feuer liegt woanders: in einem unklaren Datenmodell, in Logik, die in der falschen Schicht liegt, oder in der Tatsache, dass niemand erklären kann, ob status = "done" „genehmigt“, „ausgeliefert“ oder „die Aushilfe hat auf das grüne Ding geklickt“ bedeutet.
„Wie behebe ich diesen Bug?“ ist selten die entscheidende Frage. „Warum war dieser Bug überhaupt möglich?“ ist es.
Und ich habe auch ohne Agenten schon mehr als genug Pflaster aufgeklebt. Nach einem Workshop begann ich sofort damit, unserem Entity-Relationship-Diagramm neue Beziehungen hinzuzufügen, und verbrachte anschließend zwei Stunden damit, das Diagramm wieder konsistent aussehen zu lassen. Das hielt bis zum nächsten Review. Dort wurde das eigentliche Problem offensichtlich: Das ERD war nie das Problem. Wir hatten uns schlicht noch nicht auf ein gemeinsames Domänenmodell geeinigt.
Ich habe aufgehört zu zählen, wie viele schnelle Patches ich „später“ aufräumen wollte. Später bedeutet meiner Erfahrung nach oft: nie. Der Agent hat mir diese Gewohnheit nicht beigebracht. Er führt sie nur schneller aus, als ich es je könnte.
4. Der Komfort der Komplexität
Agenten lieben Struktur. Bitte um eine kleine Hilfsfunktion und du bekommst womöglich einen Service, ein Interface, eine Factory, eine Dependency-Injection-Schicht und dazu eine README, die die Philosophie hinter der Hilfsfunktion erklärt.
Ich würde mich gerne darüber lustig machen. Allerdings habe ich genau das selbst schon gebaut. Meistens dann, wenn das Problem unklar war und sich das Erfinden einer Architektur sicherer anfühlte, als eine echte Produktentscheidung zu treffen.
Overengineering ist tückisch, weil es professionell aussieht. Schichten, Muster, Namen wie AbstractExportStrategyProvider. Das klingt wichtig genug, um das nächste Code-Review zu überstehen. Aber Komplexität ist nicht dasselbe wie Qualität. Manchmal ist sie nur ein aufwendiger Weg, eine Entscheidung aufzuschieben, die niemand treffen wollte.
Manchmal ist die richtige Lösung ein Button oder ein einfacher Cronjob. Ganz wörtlich: „Lade diese CSV herunter und schicke sie an die Buchhaltung.“ Keine erweiterbare Plugin-Architektur für ein Feature, das drei Personen einmal im Monat nutzen.
Die Frage, die ich mir inzwischen zuerst stelle: Wie würde die fast schon peinlich einfache Version aussehen?
Meistens ist das die Version, die Bestand hat.
Agenten schreiben. Ich entscheide.
Die Punkte 3 und 4 mögen widersprüchlich klingen: schnelle Patches vermeiden, aber gleichzeitig nicht überentwickeln. Das sind sie nicht. Das Ziel ist die einfachste Lösung, die das eigentliche Problem löst. Sie zu finden, erfordert weiterhin menschliches Urteilsvermögen.
Agenten sind hervorragend darin, Annahmen zu treffen, einen ersten Entwurf zu erstellen und repetitive Aufgaben abzuarbeiten. Bessere Prompts, Projektregeln und gute Beispiele helfen enorm. Klarheit ersetzen sie nicht.
Agenten schreiben. Ich entscheide weiterhin, was ausgeliefert wird, und ich trage die Verantwortung für das, was im Produktivsystem landet.
Das ist für mich die eigentliche Lektion. Diese Agenten verstärken unsere Abkürzungen, unsere Annahmen und unsere halb formulierten Anforderungen. Und das schneller, als wir es je selbst könnten. Sie machen technisches Urteilsvermögen nicht überflüssig.
Bevor ich also dem Agenten die Schuld gebe, überprüfe ich die üblichen Verdächtigen: ein unklares Problem, unklare Verantwortung, eine unklare Ursache. Nichts davon hat der Agent eingeführt.
Er hat nur dafür gesorgt, dass es sich nicht länger ignorieren lässt.
)
)
)
)
)
)
)
)
)
)
)