Agentic Engineering Patterns

• Ein Leitfaden, der Entwicklungsweisen im Zeitalter von Coding-Agenten wie Claude Code und Codex zusammenfasst und neue Engineering-Patterns für die Zusammenarbeit mit Agenten vorstellt
• Erklärt anhand verschiedener Patterns, wie sich Entwicklungsgewohnheiten und Workflows ändern sollten in einer Umgebung, in der die Kosten für das Schreiben von Code stark gesunken sind
• Ordnet zentrale Bereiche agentenzentrierter Entwicklung wie Prinzipien, Tests, Codeverständnis und Prompt-Design strukturiert ein
• Jedes Pattern ist als praxisorientiertes Pattern-Dokument aufgebaut, inklusive realer Codebeispiele, Arbeitsweisen und Beispielen für den Einsatz von Prompts
• Praktisches Referenzmaterial für Entwickler im Zeitalter von Coding-Agenten, um agentenbasierte Coding-Umgebungen systematisch zu gestalten und die Qualität zu sichern

---

Überblick über Agentic Engineering Patterns

• Ein Leitfaden zu effektiven Engineering-Methoden für die Entwicklung zusammen mit Coding-Agenten (Claude Code, OpenAI Codex usw.)
• Siehe auch den Einführungsartikel Writing about Agentic Engineering Patterns
  • Ein Dokument mit einer Struktur, in der fortlaufend mehrere Patterns (Kapitel) ergänzt werden – ähnlich wie bei klassischen „Design Patterns“
  • Im Mittelpunkt steht, wie sich Workflows und Entscheidungsweisen von Entwicklern verändern, wenn die Kosten für das Schreiben von Code deutlich gesunken sind
  • Es wird nicht als Blogpost, sondern als aktualisierbarer Guide geführt und soll kontinuierlich erweitert werden

1. Principles

• Writing code is cheap now

  • Durch das Aufkommen von AI-Coding-Agenten sind die Kosten für die anfängliche Codeerstellung fast auf null gesunken
  • Früher war Codeerstellung teuer, daher war Entwicklung stärker auf Design und Planung ausgerichtet; heute ist ein Ansatz möglich, bei dem Ideen sofort im Code ausprobiert werden
  • Auch wenn die Kosten für Codegenerierung gesunken sind, verursacht guter Code – etwa mit Tests und Wartbarkeit – weiterhin Aufwand

• Hoard things you know how to do

  • Ein wichtiges Kapital von Entwicklern ist die Anhäufung von Wissen darüber, was möglich ist
  • Betont wird die Gewohnheit, verschiedene Problemlösungen und kleine Codeexperimente zu speichern und in wiederverwendbarer Form zu sammeln
  • Solche gesammelten Codes und Beispiele können als starke Eingaben für Coding-Agenten dienen, wenn man sie anweist, neue Funktionen zu erstellen

• Anti-patterns: things to avoid

  • Es ist ein Anti-Pattern, von Agenten erzeugten Code ohne Review zu teilen oder dafür PRs einzureichen
  • Auch von Agenten verfasste PR-Beschreibungen müssen von Menschen direkt geprüft und überarbeitet werden
  • Um die Zeit von Code-Reviewern nicht zu verschwenden, sollten Tests, Validierungsschritte und Gründe für Implementierungsentscheidungen mitgeliefert werden

2. Testing and QA

• Red/green TDD

  • Testgetriebene Entwicklung (TDD) ist ein besonders effektives Entwicklungsmuster, wenn sie zusammen mit Coding-Agenten eingesetzt wird
  • Wenn Tests zuerst geschrieben werden, kann der Agent Code in Richtung der Testerfüllung erzeugen
  • Schon mit minimalen Prompts hilft das, präzisen und verlässlichen Code zu erzeugen

• First run the tests

  • Bei der Arbeit mit Coding-Agenten sind automatisierte Tests keine Option, sondern ein Muss
  • In einer Umgebung mit geringeren Kosten für das Schreiben von Tests kann der Agent Tests schnell erzeugen und anpassen
  • Tests sind wichtig, weil nicht garantiert werden kann, dass Code funktioniert, bevor er tatsächlich ausgeführt wurde

3. Understanding code

• Linear walkthroughs

  • Ein Pattern, bei dem von Agenten erzeugter Code oder ein Projekt vom Anfang bis zum Ende in Reihenfolge gelesen wird, um die Struktur zu verstehen
  • Selbst bei einfachen Projekten kann man durch das Nachvollziehen des Codeflusses neue Techniken und Strukturen lernen
  • Als Antwort auf die Sorge, AI-Codegenerierung könne das Lerntempo verlangsamen, wird gezeigt, dass die Code-Erkundung selbst eine Lernchance sein kann

• Interactive explanations

  • Eine Methode, bei der man beim Verstehen von Code oder Systemen mit dem Agenten im Dialog Erklärungen anfordert
  • Durch wiederholtes Fragen lassen sich Funktionsweise und Struktur des Codes schrittweise erfassen
  • Ein Pattern, das den Prozess des Codeverständnisses zu einem dialogorientierten Lernansatz erweitert

4. Annotated prompts

• GIF optimization tool using WebAssembly and Gifsicle

  • Enthält ein Prompt-Beispiel zum Erstellen eines GIF-Optimierungstools auf Basis von WebAssembly und Gifsicle
  • Zeigt einen Implementierungsansatz für ein Single-Page-Tool mit HTML, JavaScript und CSS
  • Erklärt anhand realer Prompts und Codebeispiele, wie Coding-Agenten genutzt werden können

5. Appendix

• Prompts I use

  • Eine Sammlung von Prompt-Beispielen für Coding-Agenten, die tatsächlich verwendet werden
  • Zusammenstellung praxisnaher Prompt-Patterns für unterschiedliche Aufgaben
  • Bietet nützliche Templates für die Zusammenarbeit mit Agenten

[GN⁺]

Hacker-News-Kommentare

• Es wirkt, als würden wir schon wieder dasselbe tun
  Einfache und vernünftige Konzepte — zum Beispiel „Schreibe Tests zuerst“, „Baue kleine, kombinierbare Module“ — werden mit komplizierten Namen neu verpackt, und daraus entsteht dann vermutlich wieder eine Beraterindustrie.
  Nur dass es diesmal um „sprechende Maschinen“ geht. Eine Welt, in der man einfach per Sprache Anweisungen gibt

  • COBOL hatte ein ähnliches Versprechen. Es hieß, es sei so menschenlesbar, dass man keine Programmierer mehr brauche, aber am Ende musste man Probleme trotzdem zerlegen und lösen, also wie ein Programmierer denken. Dass eine Sprache menschenfreundlich ist, bedeutet also nicht, dass Programmierer verschwinden
  • Auch diesmal wird sich der Zyklus des AI-Booms wohl wiederholen. Im Moment heißt es bei Kritik noch „Du verstehst es einfach nicht“, aber bald werden die Probleme offen zutage treten. Vor allem die Situation, in der „AI so viel Code erzeugt, dass weder Menschen noch AI damit umgehen können“. Dann tauchen wieder Patterns und Anti-Patterns auf, plus Berater, die behaupten, das Problem zu lösen
  • Weil AI auf Englisch spricht und Englisch versteht, leidet die Klarheit der Interfaces. Es ist mächtig wie eine CLI, aber unklar, welche Art der Interaktion wirklich effektiv ist. Deshalb ist es wichtig zu dokumentieren und zu teilen, „was man wie anweist, um gute Ergebnisse zu bekommen“. Nur sollte das nicht wieder in etwas wie eine OOP-Coaching-Industrie abgleiten
  • Ja, genau so wird es kommen, und diesmal viel schneller. Der Zehnjahreszyklus Blogger → Speaker → Bücher → Berater → Zertifizierungsstellen wird sich innerhalb weniger Jahre komprimieren
  • Ich stimme nicht zu, dass der Titel des Artikels übertrieben kompliziert ist. Das eigentliche Problem ist eher das Missverständnis „Man muss es nur in Worten sagen“. In der Praxis fallen die Ergebnisse je nach Person völlig unterschiedlich aus. Am Ende läuft es auf die Erkenntnis hinaus, dass „gute Entwicklungsgewohnheiten für Menschen auch gut für AI sind“. AI wirkt menschlich, ist aber nicht menschlich. Deshalb braucht sie mehr Erklärung

• Ich würde Simon gern fragen: Wie macht man Code-Review in einer Welt, in der Code billig ist?
  Teammitglieder arbeiten nach dem Motto „Es läuft doch, also passt es“, ohne die Struktur zu verstehen. Reviews werden immer größer, und ich werde zum Flaschenhals. Ich habe auch überlegt, AI-Reviewer als Stellvertreter einzusetzen, aber ich mag nicht, dass dabei das menschliche Gespür verloren geht

  • Ein wirklich spannendes Thema. Wenn Code immer schneller erzeugt wird, wird Review zum Flaschenhals. Wenn Code billig ist, könnte man die Maßstäbe fürs Review senken, aber ich möchte im Gegenteil bessere Qualität. Vor allem Security-Reviews dürfen nie ausgelassen werden. Vielleicht braucht es einen systematischen Ansatz wie bei Security-Teams in großen Organisationen
  • Wenn man agentenbasiertes Review nutzt, ist das Setzen des Kontexts entscheidend. Wenn man einen Loop aus Planung → Ausführung → Test/Korrektur → Review/Refactoring → Erstellung von QA-Guides fährt, entwickelt sich nicht nur der Code weiter, sondern auch Dokumentation und Testanleitungen
  • „Es läuft doch, also passt es“ ist kein technisches Problem, sondern ein Problem der Unternehmenskultur. Manche Firmen legen weiterhin Wert auf gut lesbaren Code. Das kann sogar ein Wettbewerbsvorteil sein
  • Ich investiere in die Automatisierung von statischer und dynamischer Analyse. Ich nutze Qualitätstools wie benutzerdefinierte Lint-Regeln, starke Typprüfung und Mutation Testing sehr aktiv. Reviews allein sind zu langsam und ineffizient, deshalb ist automatisiertes frühes Feedback der Schlüssel
  • Solche Einstellungen ändern sich nicht leicht. Vielleicht ist es besser, in ein Team zu wechseln, das Softwarequalität ernst nimmt

• Ich nutze AI hauptsächlich für Boilerplate-Code oder zur Lösung von Dokumentationsproblemen
  Agentenartige Aufgaben habe ich auch ausprobiert, aber die Ergebnisse sind für mich noch nicht zuverlässig genug. Gleichzeitig sagen manche Leute, sie würden „inzwischen fast keinen Code mehr selbst schreiben“. Diese Diskrepanz finde ich interessant

  • Für mich ist direktes Programmieren oft schneller als AI. Das Planen, Ausführen und Validieren verlangsamt den Prozess eher. Aber bei großen Refactorings ist AI deutlich schneller
  • In den letzten Monaten ist die Leistung von Agenten sprunghaft gestiegen. Inzwischen geht es über simples Autocomplete hinaus bis hin zur Implementierung kompletter Features
  • Vielleicht lässt sich das durch den Unterschied zwischen Entwicklern erklären, die bei AI-Code ein „Iiiih“-Gefühl der Fremdartigkeit empfinden, und solchen, die das nicht tun
  • Letztlich trennt sich je nach Art der Aufgabe ziemlich klar, wann AI gut passt und wann nicht
  • Mir gefällt das erste Ergebnis oft auch nicht, aber wenn man den Review-Loop mehrfach durchläuft, steigt die Qualität deutlich. Wenn man AIs gegenseitig reviewen lässt oder Testkriterien klar definiert, wird es viel besser

• Ich experimentiere gerade mit agentenartigen Coding-Loops
  Zum Beispiel verfolge ich im fesh-Projekt das Ziel, „Linux-Binaries kleiner zu komprimieren“. Das war ein Problem mit klaren Tests und deshalb gut für einen AI-Loop geeignet
  Ich habe dabei Folgendes gelernt:

  • Der Test-Harness ist alles. Ohne Validierungsloop driftet die Richtung ab
  • Es ist wichtig, AI experimentell Dinge ausprobieren zu lassen
  • Man muss zwischen Sessions ein .md-Scratchpad hinterlassen, damit das Gelernte fortgeführt werden kann
  • Tests sind wirklich entscheidend. AI scheitert auf seltsame Weise, deshalb sollte man automatisierte Testgenerierung aktiv nutzen
  • Ohne Tests kann man den Ergebnissen des Loops nicht vertrauen. Deterministische Validierungsverfahren sind unverzichtbar
  • Es war nützlich, Entscheidungs-Logs und Ablehnungs-Logs getrennt zu führen. Besonders rejections.md war wertvoller. Man muss festhalten, „warum dieser Ansatz verworfen wurde“, damit AI nicht dieselben Fehler wiederholt
  • Bei Browser-Automatisierung ist es ähnlich. Man braucht nicht nur funktionale Validierung, sondern auch verhaltensbezogene Validierung (wirkt es menschlich?). Und .md-Logs erhöhen die Qualität der nächsten Session stark

• Im Test-Abschnitt hätte ich gern das Problem der selbsterfüllenden Tests, die LLMs erzeugen, behandelt gesehen
  Manchmal prüfen Tests in Wirklichkeit gar nichts, oder sie bestehen sogar mit hartkodierten Werten. Menschen müssen AI zu strengen Testgewohnheiten anleiten

  • Mich würden konkrete Beispiele interessieren. Gemeint scheinen nicht bloß einfache Logikfehler zu sein, sondern Tests, die oberflächlich okay aussehen, in Wirklichkeit aber bedeutungslos sind
  • Schlechte Tests sind gefährlicher als gar keine. Wenn das Vertrauen einmal gebrochen ist, bricht das Vertrauen in die gesamte Test-Suite zusammen
  • Deshalb ist Mutation Testing wichtig. Wenn Tests trotz veränderten Codes bestehen, sind es schlechte Tests
  • Man kann AI anweisen, Teile des Codes absichtlich zu verändern, um zu prüfen, ob die Tests fehlschlagen. Wenn nicht, sind die Tests nutzlos
  • Natürlich ist es auch bei Menschen nicht leicht, sie dazu zu bringen, solche Tests zu schreiben

• Bei jeder neuen LLM-Generation fühlt es sich an, als würden alle bisherigen Lehren entwertet
  Komplexe Konstruktionen wie LangChain, die gebaut wurden, um die Grenzen älterer Modelle zu umgehen, waren nach GPT-3.5 plötzlich nicht mehr nötig. Bald könnte vielleicht schon ein einzelner Agent für alles ausreichen

  • Deshalb versuche ich, modellversionsunabhängige Patterns zu formulieren. Red/Green-TDD könnte das Modell bald selbst erledigen, aber das Konzept an sich bleibt nützlich
  • Am Ende könnte sich alles in Richtung ClaudeVM bewegen
    Dazugehörigen Artikel ansehen

• In Diskussionen über Agent Engineering fehlt oft ein Punkt
  Die meisten Lehren werden wie universelle Wahrheiten formuliert, hängen in Wirklichkeit aber von Teamgröße, Reife des Codebases, Testniveau und Risikotoleranz ab. Wichtig ist, klar zu benennen, „wann dieses Pattern funktioniert“

  • Deshalb halte ich die Patterns nicht in einem Buch fest, sondern in Form einer Website. So kann ich sie laufend aktualisieren und den Geltungsbereich angeben
  • Wenn man als Berater mit verschiedenen Codebases arbeitet, sieht man, dass die Leistung von Claude Code extrem von der Qualität der Codebase abhängt. Projekte mit starken Typen und Tests funktionieren fast perfekt, in lockerem JavaScript-Umfeld dagegen eher schlecht
  • Trotzdem sind manche Patterns universell. Zum Beispiel ist ein unabhängiger Source of Truth (Harness) fast überall sinnvoll. Tools wie showboat und rodney helfen dabei

• Im Moment tauchen jeden Tag Dutzende „Agent-Team-Frameworks“ auf
  Das ist wie in der frühen Softwaretechnik eine chaotische Experimentierphase. Aber am Ende werden sich ein paar Patterns als Standard etablieren.
  Für unser Team war es effektiv, wie ein menschliches Team vorzugehen — zuerst eine Produktspezifikation (Spec) schreiben, sie dann mit AI verfeinern und sie anschließend als Grundlage in einen Workflow mit getrennten Agentenrollen geben

• Heute habe ich in einer Vorlesung für Studierende die Entwicklung der CPU- und GPU-Architektur erklärt
  Früher hat Moore’s Law dank immer besserer Hardware vieles gelöst, aber heute ist Parallelität der Schlüssel.
  Simons Gedanke, dass „Code billig ist“, ist ein ähnlicher Paradigmenwechsel.
  So wie sich im Zeitalter paralleler Hardware grundlegend verändert hat, was effizienter Code ist, wird sich im AI-Zeitalter der Entwicklungsprozess selbst verändern. Wer das zuerst versteht, wird einen Vorteil um den Faktor 10 bis 100 haben

• In unserem Team war ein Loop mit menschlicher Validierung an Zwischenpunkten am praktikabelsten
  Vollautonome Agenten bestehen zwar Tests, verletzen aber oft implizite Invarianten.
  Deshalb lassen wir Menschen kurz vor irreversiblen Entscheidungen eingreifen.
  Allerdings ist es wiederum eine eigene Herausforderung, AI verständlich zu machen, „was irreversibel ist“.
  Wir suchen neben Dokumenten wie CLAUDE.md nach einem systematischen Weg, implizite Regeln der Codebase zu vermitteln