KI-Coding-Agenten committen deine schlechten Gewohnheiten schneller
KI-Coding-Agenten erfinden keine neuen Fehler. Sie begehen die, die wir früher selbst gemacht haben, nur schneller. Die Arbeit mit ihnen fühlt sich an wie ein Blick in einen leicht verzerrten Spiegel. Die Hilfsbereitschaft, der Drang, etwas zu liefern, die vage Anforderung, die niemand hinterfragt hat, der schnelle Patch, der nur vorübergehend sein sollte. All das tun sie , allerdings 10-mal so schnell. Was mich interessiert, ist, was diese Agenten über meine eigene Arbeitsweise offenbaren, Tag für Tag. Und warum es am Ziel vorbeigeht, das Tool dafür verantwortlich zu machen.
)
1. Mit verbundenen Augen ins Unbekannte
Agenten wollen helfen. Unbedingt. Gib einem eine Aufgabe und er fängt sofort an zu lösen. Genau diese Aufgabe, so wie sie formuliert ist, kaum eine Frage, kaum ein Moment des Zweifels.
Angenommen, ich bitte darum:
„Bau ein Export-Feature."
Zehn Minuten später habe ich einen CSV-Export mit Filtern, drei Hilfsfunktionen und einen Haufen Tests. Sieht produktiv aus, aber könnte völlig falsch sein.
Vielleicht wollte der Kunde nie einen CSV-Export. Vielleicht war das eigentliche Problem nie einfach „Daten exportieren", sondern: „Ich will nicht mehr jeden Freitagnachmittag Zahlen in Excel kopieren."
Hier kommt der unangenehme Teil: Ich mache dasselbe. Ich höre eine Anforderung und fange an zu bauen, weil Bauen produktiv wirkt und Fragen stellen sich wie das Blockieren von Fortschritt anfühlt. Dabei begann jedes Stück Software, auf das ich wirklich stolz bin, mit langweiligen Fragen. Wer braucht das? Warum? Was passiert, nachdem man auf den Button geklickt hat? Muss es überhaupt ein Button sein?
Der Agent überspringt diese Fragen, weil ich ihm nie sage, dass er sie stellen soll. Und oft überspringe ich sie selbst. Deshalb schreibe ich inzwischen „Frag mich Fragen, bevor du Code schreibst" in meine Prompts. Eine so kleine Änderung, aber sie wirkt Wunder. Plötzlich will der Agent wissen, wer den Export verwendet, in welchem Format, und ob er nach einem Zeitplan laufen muss – genau die Fragen, die ich dem Kunden von Anfang an hätte stellen sollen.
2. Der schleichende Verfall
Die Fragen überspringen, auf Entwicklungsgeschwindigkeit optimieren und die Codebasis entwickelt schnell ein ganz bestimmtes Symptom: Duplikate.
Wenn es keinen offensichtlichen Ort gibt, wohin eine bestimmte Logik gehört, erfindet der Agent keinen. Er schreibt einen Helfer, der bereits zwei Ordner weiter existiert. Er baut eine zweite Version der Validierungslogik, weil die vorgesehene Abstraktion nie sichtbar war.
Und es funktioniert. Vorerst. Genau das macht es gefährlich: Duplizierter Code ist ein langsamer Bug-Generator. Eine Kopie wird aktualisiert, die andere nicht und sechs Monate später erinnert sich niemand mehr, welche die „echte" ist.
Ich habe diese Lektion teuer bezahlt. Ein Agent hat einmal selbstbewusst ein zweites Mapping für Datenbankdaten erstellt, die wir bereits woanders gemappt hatten. Die zwei Implementierungen drifteten auseinander: Beschreibungen fehlten, Dezimalstellen wurden unterschiedlich gerundet, und irgendwann waren die Daten selbst korrumpiert. Es hat die Production nie erreicht, weil ich es rechtzeitig bemerkt habe. Hat mich trotzdem viel zu viel Zeit und einige Nerven gekostet.
Die Lösung ist einfach. Muster aufschreiben, dort, wo der Agent sie findet. Bei mir ist das eine kurze Konventionsdatei im Repo-Root, eine AGENTS.md oder was auch immer das Tool liest: wo Mappings leben, welche Helfer bereits existieren, wie wir Dinge benennen. Der Agent liest sie vor jeder Aufgabe und wir sollten das ab und zu auch tun.
3. Wie ein Pflaster auf einem gebrochenen Bein
Agenten sind brillant darin, Fehler verschwinden zu lassen. Ein Test schlägt fehl? Assertion ändern. Response ist undefined? Mit Optional Chaining vergraben. Symptom weg, alle glücklich.
Aber der sichtbare Fehler ist meistens nur Rauch. Das Feuer sitzt woanders: ein unklares Datenmodell, Logik in der falschen Schicht, oder die Tatsache, dass niemand erklären kann, ob status = "done" bedeutet „genehmigt", „versendet" oder „der Praktikant hat auf das grüne Ding geklickt".
„Wie behebe ich diesen Bug?" ist selten die interessante Frage. „Warum war dieser Bug überhaupt möglich?" ist es.
Und ich habe genug Pflaster geklebt, ganz ohne Agenten. Nach einem Workshop habe ich sofort neue Relations in unser Entity-Relationship-Diagramm eingetragen und dann zwei Stunden damit verbracht, das Diagramm wieder konsistent aussehen zu lassen. Es hielt bis zum nächsten Review, wo das eigentliche Problem offensichtlich wurde: Das ERD war nie das Problem. Wir hatten einfach noch kein gemeinsames Domänenmodell.
Ich habe aufgehört zu zählen, wie viele schnelle Patches ich „später" aufräumen wollte. Später bedeutet in meiner Erfahrung 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 vielleicht einen Service, ein Interface, eine Factory, eine Dependency-Injection-Schicht plus eine README, die die Philosophie hinter der Hilfsfunktion erklärt.
Ich würde das gerne belächeln. Außer dass ich dasselbe selbst gebaut habe, meistens wenn das Problem unklar war und das Erfinden von Architektur sich sicherer anfühlte als eine echte Produktentscheidung zu treffen.
Overengineering ist tückisch, weil es professionell aussieht. Schichten, Muster, Namen wie AbstractExportStrategyProvider. Klingt wichtig genug, um das nächste Code-Review zu überleben. Aber Komplexität ist keine Qualität. Manchmal ist es nur ein kunstvoller Weg, einen Anruf zu verschieben, den niemand führen wollte.
Manchmal ist die richtige Lösung ein Button. Ein Cron-Job. Wörtlich: „Diese CSV herunterladen und an die Buchhaltung schicken." Keine erweiterbare Plugin-Architektur für ein Feature, das drei Leute einmal im Monat nutzen.
Die Frage, die ich jetzt zuerst stelle: Wie würde die peinlich einfache Version aussehen?
Meistens ist das die Version, die Bestand hat.
Agenten schreiben. Ich entscheide.
Punkte 3 und 4 klingen vielleicht widersprüchlich: Schnelle Patches vermeiden, aber auch Overengineering vermeiden. Das sind sie nicht. Das Ziel ist die einfachste Lösung, die das eigentliche Problem adressiert und das zu finden erfordert nach wie vor menschliches Urteilsvermögen.
Agenten sind hervorragend darin, Annahmen zu treffen, einen ersten Entwurf zu produzieren und sich durch repetitive Arbeit zu arbeiten. Bessere Prompts, Projektregeln und gute Beispiele helfen enorm. Sie ersetzen keine Klarheit.
Agenten schreiben. Ich entscheide weiterhin, was ausgeliefert wird und ich trage die Verantwortung für das, was in die Production gelangt.
Das ist die eigentliche Lektion für mich. Diese Agenten verstärken unsere Abkürzungen, unsere Annahmen, unsere halbgeschriebenen Anforderungen, schneller als wir es je selbst getan haben. Sie ersetzen nicht die Notwendigkeit für technisches Urteilsvermögen.
Also bevor ich dem Agenten die Schuld gebe, schaue ich auf die üblichen Verdächtigen: unklares Problem, unklare Verantwortung, unklare Ursache. Der Agent hat nichts davon eingeführt.
Er hat es nur unmöglich gemacht, es zu ignorieren.
)
)
)
)
)
)
)
)
)
)
)