Seit 2000 habe ich viele Frameworks und Technologien kommen und gehen sehen. Fast alle versprachen mehr Produktivität in der Entwicklung, nur wenige hielten dieses Versprechen. Bei Coding Agents verändert sich trotz ihrer Schwächen etwas. Ich nutze insbesondere Claude Code und Codex nicht bloß für Fragen im Chat, sondern nach einer spezifikationsbasierten Methode und mit einer Wissensbasis, die ich für jedes Projekt aufbaue.
Anforderungen, Einschränkungen und Akzeptanzkriterien, schriftlich festgehalten vor dem Code, basierend auf der Dokumentation oder Beschreibung des Kunden.
Wie es aufgebaut wird: beteiligte Teile, Ablauf, Risiken. Spezifikation und Plan werden überprüft, bevor ein Code geschrieben wird.
Ich wechsle zwischen Claude Code und Codex in den verschiedenen Phasen, gemäß dem genehmigten Plan.
Zuerst automatisiert, dann interaktiv. Bei Bedarf wird das Problem oder Feature zu einem wiederholbaren Test.
Ich prüfe, ob der Code der Spezifikation entspricht, und aktualisiere die Dokumentation: erledigte Arbeit, Roadmap, Entscheidungen, Stolpersteine.
Mit Projektgerüst meine ich die Anweisungen, das Fachwissen und die Abläufe, auf die der Agent bei jeder Anfrage zurückgreift. Für jedes Projekt baue ich es schrittweise auf. Dazu gehören Dokumente mit Fachregeln, Verfahren und Informationen, die für die Qualität entscheidend sind.
Das ist eine Antwort auf etwas, das ich in den letzten Jahren oft erlebt habe: Projekte ohne jede Dokumentation. Mit einem Agenten wird es besonders wichtig, Entscheidungen, Nutzeranfragen und Stolpersteine festzuhalten. So lässt sich später nachvollziehen, warum etwas auf eine bestimmte Weise umgesetzt wurde.
Dieses Gerüst braucht Pflege. Die Informationen wachsen, und der Agent muss weiterhin die passenden Stellen finden. Deshalb muss das Projektgerüst wie Code gepflegt und verbessert werden. Es ist auch immer auf das jeweilige Projekt zugeschnitten.
Am meisten lohnt es sich in komplexen Projekten, deren Abläufe über Webanwendungen, APIs und externe Dienste wie ein CRM führen, oft verteilt auf mehrere Repositorys. Ohne festgehaltenes Fachwissen sieht der Agent in der IDE jeweils nur einen Ausschnitt und muss den gesamten Ablauf bei jeder Frage neu erschließen. Mit dem Projektgerüst kann er ihm über die Systemgrenzen hinweg folgen.
Eine wirksame Harness muss auch Fehler sichtbar machen: Aktionsgrenzen und unabhängige Prüfungen helfen, falsche Änderungen vor der Übernahme ins Produkt zu stoppen.
Softwarequalität mit Coding-Agenten: Prüfungen und der Shopify-Fall
Ich lege Technologien und Richtlinien fest, richte das Projektgerüst ein und entwickle Funktionen nach dem spezifikationsbasierten Ablauf. Ausgangspunkt sind die Dokumentation oder die Beschreibung des Kunden. Wenn es sinnvoll ist, teile ich die Arbeit in mehrere parallele Stränge auf.
Das Projektgerüst laufend an die Entwicklung des Projekts anpassen.
Ich beginne mit dem vorhandenen Material, oft dem Code selbst, und lege eine schrittweise Migrationsroadmap fest, wobei ich die beste Abfolge wähle. Ich wechsle zwischen den vom Agenten durchgeführten Tests und manuellen Überprüfungen der laufenden Arbeit ab.
Wie ich Migrationsprojekte angehe
Bei Systemen, in denen jede Prüfung die vollständige Anwendung, eine gemeinsam genutzte Datenbank oder manuelle Konfigurationen benötigt, bereite ich zunächst eine Umgebung und wiederholbare Prüfungen vor. Der Aufwand, Änderungen überprüfbar zu machen, gehört zur Einführung des Agenten.
Etwas Laufendes und Testbares so früh wie möglich haben, wenn auch minimal. Das Risiko besteht darin, wochenlang konzentriert zu arbeiten und beim ersten Start nicht zu verstehen, warum es nicht funktioniert: besser ist es, klein anzufangen, zu überprüfen, dass es läuft, und Funktionen schrittweise hinzuzufügen.
Ich analysiere den Code und die verwendeten Muster. Das ist besonders hilfreich, wenn ihre Einhaltung im Review geprüft wird. Das Fachwissen der Beteiligten und Produktexperten überführe ich in das Projektgerüst. So kann ich mich schneller einarbeiten und eigenständig beitragen.
Immer einen kritischen Blick bewahren: Was der Agent vorschlägt, muss gegen das, was über das Projekt bekannt ist, abgewogen werden.
Bei Projekten mit mehreren Repositorys oder Produkten analysiere ich die Abläufe zwischen den Systemen. Das hilft bei der Suche nach verteilten Fehlern und bei der Einschätzung, welche Folgen neue Funktionen haben. Diese Arbeit gehört meist zur Wartung: Ich komme oft hinzu, wenn das System bereits produktiv und etabliert ist.
Die Flüsse zwischen Systemen explizit machen, die kein einzelnes Repository vollständig zeigt.
Mit direktem Datenzugriff ermöglicht der Agent eine vertiefte, interaktive Analyse und kann Werkzeuge und Algorithmen vorschlagen. Das Projektgerüst hält frühere Analysen, Ergebnisse und Entscheidungen fest. So bleiben der Datenfluss und die Gründe für jede Entscheidung nachvollziehbar.
Ich arbeite an Testumgebungen oder anonymisierten Daten, nicht an Produktionsdaten.
Aus meiner Erfahrung kommt man nicht weit, wenn man einfach akzeptiert, was der Agent vorschlägt. Sie müssen sich in das Thema und den Problembereich einarbeiten.
Der Agent schließt auf das durchschnittliche Wissen, das während des Trainings gesammelt wurde: Er ist auf weit verbreitete Technologien und aktuelle Methoden sehr effektiv, auf veraltete oder nicht standardisierte Kontexte weniger zuverlässig. Ein weiterer Grund, aktuelle Lösungen immer dann vorzuziehen, wenn es möglich ist.
Zunächst scheint es, neue Fronten schnell zu eröffnen. Später müssen Sie jedoch seine Vokabeln lernen, in seine Welt eintreten und seine Methoden lernen: Wir passen uns mehr an, als es sich an uns anpasst.
Ein Projektgerüst, das alle ohne Abstimmung bearbeiten, verliert an Präzision. Im Team müsste es wie Code im Repository verwaltet werden: mit einer verantwortlichen Person sowie einem Review- und Freigabeprozess. Bis dahin nutze ich es als eigenes Arbeitswerkzeug außerhalb des Projekt-Repositorys und behandle es so vertraulich wie den Kundencode.
Coding Agents können die Produktivität steigern, je nach Aufgabe und Kontext. Sie ersetzen das Verständnis des Systems nicht; darin liegt weiterhin der entscheidende Unterschied.
Auch die Ausbildung von Nachwuchsentwicklern verändert sich. Es besteht die Gefahr, dass sie die KI so lange befragen, bis etwas funktioniert, ohne selbst dazuzulernen. Deshalb ermutige ich die Entwickler, die ich betreue, ein eigenes Verständnis des Produkts aufzubauen, und bespreche ihre Aufgaben mit ihnen. Demselben Grundsatz folge ich als Teamleiter.
Für ein Team würde ich Werkzeuge und Zugriffsstufen nach den Tätigkeiten auswählen, statt automatisch allen dieselbe Lizenz zuzuweisen. Zur Anschaffung gehören Schulung, gemeinsame Praktiken und klare Zuständigkeiten für Kontext und Dokumentation.
Ich würde Bearbeitungs- und Reviewzeiten, Fehler und Nacharbeit gemeinsam mit den Kosten messen. Token, erzeugte Zeilen und die Zahl der Pull Requests reichen nicht aus, um Nutzen oder individuellen Beitrag zu bewerten: Dies ist ein methodischer Vorschlag, keine allgemeingültige ROI-Formel.
Ich nutze Code-Agenten nur dort, wo es die Regeln des Kunden erlauben, und mit professionellen Konten. Wenn der Kunde keine KI-Werkzeuge erlaubt, arbeite ich ohne sie.
Für die Datenanalyse arbeite ich an Testumgebungen oder anonymisierten Daten, nicht an Produktionsdaten.
Es ist ein anderes Thema als KI als Entwicklungswerkzeug, und es verdient dieselbe Konkretheit.
Wer wie ich Unternehmensanwendungen entwickelt und wartet, stößt im Inneren von Anwendungen weitaus seltener auf KI, als die aktuelle Hype-Welle vermuten lässt. Abgesehen von wirklich innovativen Diensten, die wahrscheinlich Spezialisten erfordern, ist die häufigste Anforderung nach wie vor "Chat mit Ihren Daten". Und selbst dort ist eine klare Unterscheidung notwendig.
Ein RAG-System, das eine Dokumentensammlung abfragt und dabei den Texten treu bleibt, lässt sich relativ einfach in einer ersten Version erstellen. Ein Werkzeug, das präzise Analysen durchführt und korrekte Antworten liefert, ist eine andere Aufgabe: Deterministischer Code muss mit einem Sprachmodell zusammenarbeiten, das von Natur aus nicht deterministisch ist, und der Aufwand wächst weit schneller als die Präzision, die Sie gewinnen.
Coding Agents kennen diese Themen sehr gut; es ist ihr Fachgebiet. Aber auch hier müssen Sie, um weit zu kommen, in die Problemdomäne eintauchen.
Das Projekt, die Architektur und die Kosten im Detail: Anwendungen mit eingebauter KI
Das beschriebene Projekt befindet sich in der Entwicklungs- und Testphase.
Diese Studien untersuchen unterschiedliche Aufgaben und Rahmenbedingungen; sie belegen keinen Produktivitätsgewinn, der für jedes Projekt gilt.