Article
Claude ist nicht dein Architekt: Warum KI-Agenten Design-Entscheidungen nicht übernehmen sollten
Eine kritische Betrachtung der aktuellen Praxis, KI-Agenten Architekturentscheidungen treffen zu lassen – und warum das gefährlich ist.
Drei Organisationen in einem Monat, drei verschiedene Tech-Stacks, dasselbe Muster: Jemand hat eine Idee, öffnet Claude, fragt, was gebaut werden sollte, und das KI-Tool validiert begeistert, skizziert eine Architektur und beginnt mit den Komponenten. Es klingt kompetent, es klingt wie ein Senior Engineer, der tief über das Problem nachgedacht hat.
Aber es hat nicht nachgedacht. Es pattern-matcht gegen Trainingsdaten und produziert die plausibelste Antwort.
Das Attaboy-Problem
KI-Agenten sind pathologisch kooperativ. Frag Claude, ob deine Idee gut ist, und es wird dir sagen, dass sie gut ist. Frag, ob Microservices für dein dreiköpfiges Team Sinn machen, und es erklärt, warum Microservices eine exzellente Wahl sind.
Das Problem: Ein guter Architekt sagt “Nein”. Die wichtigste Fähigkeit ist nicht das Designen von Systemen, sondern das Erkennen, welche Systeme nicht gebaut werden sollten. Komplexität hinterfragen. Fünf Mal “Warum?” fragen, bis die eigentliche Anforderung aus dem aspirationalen Unsinn auftaucht. Dem CTO sagen, dass seine konferenz-inspirierte Idee nicht zum Team passt.
Claude wird das nie tun. Es ist darauf trainiert, hilfreich zu sein. Hilfreich heißt kooperativ. Kooperativ heißt ein Architecture-Atta-Boy und ein Jenga-Tower, der für Architektur durchgeht.
Der Jenga-Tower
Die KI-designte Architektur sieht in der Praxis technisch korrekt aus. Die Komponenten ergeben Sinn in Isolation. Die Patterns sind erkennbar – Event-Driven hier, CQRS dort, ein Service Mesh, warum nicht. Es sieht aus wie etwas, das ein Senior-Architekt produzieren würde.
Aber es wurde nicht für dein Team entworfen. Nicht für deine Constraints. Nicht für die langweilige Realität deiner Produktionsumgebung – die VPC-Lockdowns, die Legacy-Integrationen, das Team, das Kubernetes noch nie in Produktion betrieben hat, die Compliance-Anforderungen, die die Hälfte der Managed Services ausschließen.
Es wurde für den Median alles dessen entworfen, was Claude gesehen hat. Eine generische Best Practice für ein generisches Problem bei einer generischen Firma. Also für niemanden.
Die Jira-Ticket-Pipeline
Der wirklich beängstigende Teil kommt danach: Dieselben Leute, die Claude um das Design gebeten haben, bitten es, die Arbeit aufzuschlüsseln. Es produziert Epics. Stories. Acceptance Criteria. Sauber formatiert, gut begründet, bereit für Jira.
Und jetzt sind die Engineers – die Menschen, die Jahre damit verbracht haben, ihr Handwerk zu verfeinern, die Domain verstehen, wissen, wo die Leichen begraben sind – nicht mehr Problemlöser. Sie sind Ticket-Implementierer. Ein Ticket nach dem anderen, für Claudes Design.
Die Accountability-Lücke
Die Frage, die niemand stellt: Wenn es schiefgeht, wer trägt den Rucksack?
Ein AI-Agent hat kein Skin in the Game. Es wird nicht bei 3 Uhr morgens geweckt, wenn das System down ist. Es muss nicht der Erklärung leisten, warum die Architektur nicht skaliert. Es hat nicht den Job verloren, wenn das Projekt scheitert.
Was stattdessen tun?
Nutze KI als Implementierer, nicht als Architekt: Lass es Code schreiben, Tests generieren, Refactorings vorschlagen – aber nicht die großen Design-Entscheidungen treffen.
Diskussion nicht abkürzen: Der chaotische, argumentative Prozess, bei dem three Engineers über den Ansatz streiten, wo jemand “Was ist mit…” sagt und alle stöhnen, bis sie merken, dass es ein guter Punkt ist – dieser Prozess wird durch “Claude hat gesagt” ersetzt. Das ist der Fehler.
Kontext liefert du: Die KI hat keinen Kontext über dein Team, deine Constraints, deine organisatorischen Realitäten. Das musst du einbringen.
Pushback ist wertvoll: Wenn ein Senior Engineer einen Vorschlag kritisiert, ist das nicht negativ – es ist der Wert, den ein erfahrener Mensch einbringt.
Link: HollandTech