Agentic Engineering — aus der Praxis.
Wie ich einen KI-Agenten als Planungspartner — nicht als Code-Generator — eingesetzt habe, um eine komplexe Datenbankmigration zu entwerfen, bevor eine einzige Zeile Code geschrieben wurde.
Als 18 Agenten jeweils ihre eigenen Memory-Dateien pflegten, wurde das System unwartbar. Die Lösung war eine klare Trennung: Daten sammeln ist eine Aufgabe, Wissen destillieren eine andere.
KI kann Features schnell bauen. Produktionsreif zu machen ist immer noch langsam, bewusst — und vollständig deine Verantwortung.
Zwei Wochen nach dem Start war die Memory-Datei meines typescript-implementers 95 KB groß und 2.133 Zeilen lang. Das System, das Agenten schlauer machen sollte, machte sie langsamer.
Session 13. Ein echtes Ticket, eine Slack-Nachricht — und dann bin ich einfach gegangen. Was danach passierte, hatte ich nicht erwartet.
Niemand schreibt über seine fehlschlagenden Agenten. Ich schon. Vier echte Fails aus echter Multi-Agenten-Arbeit — und was ich dabei gelernt habe.
Ich hab 8 Agenten gleichzeitig 16 Stunden lang laufen lassen, um eine vollständige Cashback-Web-App zu bauen. Hier ist die Quittung.
Wie ich in fünf intensiven Tagen von einem generalistischen KI-Agenten zu 18 Spezialisten gekommen bin — und warum Spezialisierung die wichtigste Architekturentscheidung im Agentic Engineering ist.
Session 9. Ein echtes Produktions-Ticket bei einem Enterprise-Unternehmen. Neun Agenten in Folge. Ich hab zugeschaut. Hier ist, was wirklich passiert ist.
Ich bat meinen KI-Agenten, sich selbst einen Namen zu wählen. Er entschied sich für „Cairn." Warum das mehr bedeutet, als es klingt.
Bereit für das nächste Level?
Kontakt aufnehmen