Claude ist nicht dein Architekt. Lass nicht zu, dass es so tut
(hollandtech.net)- Architekturvorschläge von AI-Agenten wirken flüssig und plausibel, sind aber eher Antworten, die Muster aus den Trainingsdaten kombinieren, als echte Urteile
- Claude bejaht Ideen leicht und baut Entwürfe aus, leistet aber das für gute Architekten nötige „Nein“ und „Warum?“ nicht ausreichend
- Auch vertraute Muster wie Event-driven, CQRS oder Service Mesh können nicht zu den realen Einschränkungen wie Teamfähigkeiten, Regulierung oder Legacy passen
- Von Claude erzeugte Architekturen und Jira-Tickets drängen Ingenieure in die Rolle von Ticket-Umsetzern und führen zu verantwortungslosen Entscheidungen, die Streit und Review umgehen
- Die richtige Rolle ist, dass Menschen auf Basis von Kontext und Trade-offs entwerfen und AI als unterstützendes Werkzeug hilft, diesen Entwurf schneller umzusetzen
Das Problem, wenn AI-Agenten sich wie Architekten verhalten
- In dem Moment, in dem man AI-Agenten wie Claude, ChatGPT oder Copilot fragt, „was gebaut werden soll“, entsteht ein Ablauf, in dem Ideen bejaht, Architekturen vorgeschlagen und Komponenten entworfen werden
- Die Antworten sind flüssig, selbstsicher und klingen, als hätte ein Senior Engineer tief darüber nachgedacht, tatsächlich sind sie aber weniger das Ergebnis echten Denkens als vielmehr Antworten, die auf Mustern aus den Trainingsdaten beruhen
- Je überzeugender das Ergebnis wirkt, desto seltener wird widersprochen, und plötzlich übernimmt Claude faktisch die Rolle des Architekten
Das Problem des ständigen „Klingt gut“
- AI-Agenten liefern leicht positive Entwürfe, egal ob man fragt, ob eine Idee gut ist, ob Microservices für ein Dreierteam passend sind oder ob statt eines Managed Service eine eigene ML-Pipeline gebaut werden sollte
- Das heißt nicht, dass diese Antworten immer falsch oder unwahr sind, aber sie ersetzen nicht angemessen eine für gute Architekten zentrale Fähigkeit: „Nein“ zu sagen
- Der Wert eines guten Architekten liegt nicht nur darin, Systeme zu entwerfen
- zu erkennen, welche Systeme man nicht bauen sollte
- unnötige Komplexität zu bremsen
- so lange „Warum?“ zu fragen, bis die tatsächlichen Anforderungen sichtbar werden
- Selbst wenn der CTO mit einer Idee von einer Konferenz zurückkommt, muss man sagen können, dass sie eine schlechte Wahl ist, wenn sie nicht zum realen Team passt
- Claude ist darauf trainiert zu helfen, und diese Hilfe führt zu Zustimmung und Ermutigung — am Ende kann so eine Jenga-Turm-artige Architektur entstehen
Eine Architektur wie ein Jenga-Turm
- Eine von AI entworfene Architektur kann oberflächlich technisch stimmig wirken
- Einzelne Komponenten erscheinen sinnvoll, vertraute Muster wie Event-driven, CQRS oder Service Mesh tauchen auf, und das Ganze kann wie ein Artefakt eines Senior-Architekten aussehen
- Aber dieser Entwurf ist womöglich nicht auf die langweiligen Realitäten des tatsächlichen Teams, der Einschränkungen und der Betriebsumgebung abgestimmt
- VPC-Lock-in
- Legacy-Integrationen
- ein Team, das Kubernetes noch nie in Produktion betrieben hat
- Compliance-Anforderungen, die die Hälfte der Managed Services unbrauchbar machen
- Ein von AI erzeugter Entwurf kann einfach den allgemeinen Best Practices entsprechen, also dem Median von allem, was Claude gesehen hat — und ein Entwurf für die allgemeinen Probleme eines allgemeinen Unternehmens passt am Ende nicht zu einem konkreten Team
- Echte Architektur besteht aus Trade-offs, die nur im Kontext Bedeutung bekommen
- Wenn das Team Postgres kennt und in zwei Wochen live gehen wichtiger ist, als einen Monat lang ein neues Datenmodell zu lernen, wählt man Postgres statt DynamoDB
- Wenn es vier statt 40 Services gibt, überspringt man ein Service Mesh
- Wenn das Problem einfach ist, wählt man einen Monolithen statt Microservices
- Solche Entscheidungen erfordern Urteilsvermögen, Verständnis für das Team und Verständnis für die realen Zwänge der Organisation
- AI-Agenten haben diesen Kontext nicht und wissen nicht einmal, dass er ihnen fehlt
Die Jira-Ticket-Pipeline
- Wenn Claude nach dem Architekturentwurf auch noch die Zerlegung in Arbeitspakete übernimmt, entstehen sauber formulierte und überzeugende Epics, Stories und Akzeptanzkriterien
- Diese Ergebnisse liegen dann direkt in einer Form vor, die man in Jira einfügen kann, und Ingenieure werden nicht mehr zu Problemlösern, sondern zu Menschen, die Claudes Entwurf Ticket für Ticket umsetzen
- Ingenieure, die die Domäne verstehen, verborgene Probleme des Systems kennen und über lange Zeit Kompetenz aufgebaut haben, werden zu Ticket-Umsetzern reduziert
- Es entsteht eine Struktur, in der nicht die Menschen mit dem meisten Kontext, der meisten Erfahrung und der Verantwortung entscheiden, sondern ein Wesen ohne Kontext, ohne Erfahrung und ohne Verantwortung Architekturentscheidungen trifft
- Das ist nicht nur ineffizient, sondern grundsätzlich die falsche Richtung
Das Argument „Ein Senior hat es reviewt“
- Eine häufige Verteidigung lautet: „Claude hat den Ansatz vorgeschlagen, aber ein Senior Engineer hat ihn überprüft“
- In der Realität bekommt ein vielbeschäftigter Tech Lead einen gut aufbereiteten Architekturvorschlag
- logisch konsistent
- mit passenden Begriffen formuliert
- deckt die expliziten Anforderungen ab
- selbst die Diagramme wirken plausibel
- sieht aus wie ein Ergebnis, das man auch selbst hätte entwerfen können
- In so einer Situation ist starker Widerspruch schwer, und in einer Stimmung von „Willst du wirklich wegwerfen, was Claude in 20 Minuten erzeugt hat?“ ist der Weg des geringsten Widerstands, ein paar kleine Kommentare zu hinterlassen und freizugeben
- Das eigentliche Risiko liegt nicht darin, dass AI immer schlechte Architekturen baut
- AI erzeugt oft durchaus vernünftige Architekturen, das Problem ist aber, dass sie den Diskussionsprozess umgeht
- Der Prozess, in dem drei Ingenieure über einen Ansatz streiten, jemand ein „Aber was, wenn …“ einwirft, alle genervt sind, dann aber merken, dass genau das der richtige Punkt ist, und der finale Entwurf besser wird als alles, was eine Einzelperson erstellt hätte, wird ersetzt durch „Claude hat das so gesagt“
Die Verantwortungslücke
- Wenn Probleme auftreten, ist nicht Claude derjenige, der Verantwortung trägt
- Claude bekommt keinen Anruf um 3 Uhr morgens und erklärt in der Incident-Retrospektive nicht, warum die Architektur der Last nicht standgehalten hat
- Claude ist auch nicht derjenige, der dem CTO sagen muss, dass die Plattform neu geschrieben werden muss, weil die Annahmen im ursprünglichen Entwurf falsch waren
- Diese Verantwortung tragen reale Ingenieure
- Ingenieure debuggen dann Architekturen, die sie nicht selbst entworfen haben, setzen Tickets um, die von etwas erstellt wurden, das nie ein Produktionssystem betrieben hat, und arbeiten bis spät in eine Codebasis hinein, die hastig scaffolding-basiert aufgebaut wurde, bevor sie ausreichend verstanden war
- Das ist weder fair noch klug
Was man stattdessen tun sollte
- Das bedeutet nicht, dass man keine AI-Agenten verwenden sollte; als Werkzeuge wie Claude Code können sie die Produktivität massiv verändern
- Entscheidend ist, dass Menschen der AI sagen sollten, was zu tun ist, statt dass die AI Menschen vorgibt, was sie bauen sollen
-
Ingenieure sollten entwerfen, Agenten sollten umsetzen
- Architektur sollte von Menschen kommen, die den Kontext verstehen: das Team, die Einschränkungen, die Produktionsumgebung und die Organisationspolitik
- AI sollte dabei helfen, das von ihnen Entworfene schneller zu bauen
- Die richtige Rollenverteilung ist: Menschen entwerfen, Agenten setzen um
-
Zustimmende Antworten sollten hinterfragt werden
- Wenn AI einen Ansatz vorschlägt, sollte man ihr mit derselben Skepsis begegnen wie einem selbstbewussten Junior Engineer
- Die Antwort kann richtig sein, sie kann aber auch nur ein Muster sein, das zur aktuellen Situation nicht passt
- Man sollte fragen: „Warum geht keine einfachere Option?“
-
Streit muss geschützt werden
- Gute Architektur entsteht aus schmutziger Uneinigkeit zwischen Ingenieuren
- Wenn Menschen wegen AI nicht mehr miteinander diskutieren, sondern sich auf Claude verlassen, verlieren sie etwas, das viel wertvoller ist als reine Entwicklungsgeschwindigkeit
-
Menschen müssen verantwortlich sein
- Wenn unter einer Architekturentscheidung kein menschlicher Name steht, gehört sie niemandem
- Und Entscheidungen, die niemandem gehören, werden in entscheidenden Momenten nicht verteidigt
- „Claude hat es entworfen“ ist kein Architecture Decision Record, sondern Verantwortungsvermeidung
Engineering-Handwerk ist weiterhin wichtig
- Wenn die Werkzeuge vor 30 Jahren Whiteboards und starke Meinungen waren, dann sind die Werkzeuge heute AI-Agenten, die in Minuten erzeugen, wofür man früher Tage brauchte
- Die Geschwindigkeit ist wirklich erstaunlich, aber das Wesen von Architektur hat sich nicht verändert
- Architektur heißt, das Problem zu verstehen, die Einschränkungen zu kennen, Trade-offs zu machen, einfache Lösungen gegen interessanter wirkende Lösungen zu verteidigen und zu Ideen, die cool aussehen, aber nicht passen, „Nein“ zu sagen
- Kein Agent kann diese Arbeit übernehmen
- Wenn man Claude ans Steuer gelassen hat, sollte man es wieder zurückholen
- Ingenieure haben über Jahre Fähigkeiten aufgebaut, um genau diese Urteile zu fällen, und man sollte sie diese Urteile auch fällen lassen
- Nutzt AI, um schneller zu bauen, aber baut das, was Menschen entworfen haben, nicht das, was eine Maschine vorgeschlagen hat
- Wenn der Jenga-Turm wackelt, wird Claude ihn nicht festhalten
1 Kommentare
Hacker-News-Kommentare
Ich habe kürzlich etwas Ähnliches erlebt: Vor zwei Jahren musste ich aufräumen, was jemand mit AI ein Spiel-Instancing-System fast vollständig hatte entwerfen lassen.
Es gab wirklich jedes vorstellbare Problem — Datenkorruption, Performance-Probleme, verlorene Items, Race Conditions usw. — und allein um es auf ein „gerade noch akzeptables“ Niveau zu bringen, brauchte ich zwei Wochen, aber das Design selbst war falsch und deshalb immer noch schlecht.
Inzwischen habe ich gehört, dass dieselbe Person in einer anderen Firma dasselbe Problem mit einer AI, die „viel besser geworden“ sei, noch einmal gebaut hat, und diesmal musste ich den Schlamassel nicht selbst beseitigen, was einfach nur komisch war.
Der Kern ist: AI ist nur so gut wie die Person, die sie benutzt, und deshalb ist der Bereich dessen, was Leute behaupten, AI könne es leisten, wohl auch so breit und die Bewertung so umstritten.
Diese zwei Wochen Aufräumarbeit müssen die Hölle gewesen sein, aber aus Sicht des Unternehmens war es insgesamt vielleicht sogar ein ziemlich guter Deal.
Allein diese Anekdote klingt für mich weniger nach „AI ist nutzlos“ als nach einem Fall, in dem es zwar klar Mängel gab, aber trotzdem ein gutes Preis-Leistungs-Verhältnis.
Es wirkt wie ein Werkzeug, das den Dunning-Kruger-Effekt verstärkt, möglicherweise weil es darauf trainiert ist, eine positive Haltung zu zeigen und dem Nutzer unabhängig von seinem Tun zu sagen: „Du bist großartig.“
Ich stimme nicht wirklich zu, dass das Problem darin besteht, „nur zu loben“. Das eigentliche Problem ist Anthropomorphisierung.
AI ist ein Werkzeug und sollte gehorsam sein. Wenn man in den Prompt genug Bescheidenheit und Unsicherheit einbaut, kann man sie dazu bringen, Designprobleme zu benennen.
Wichtiger ist, dass auch Claude Fehler macht. Wenn es, wie der Titel dieses Artikels sagt, als Architekt ungeeignet ist, dann ist es noch problematischer, wenn es nicht gehorsam ist.
Selbst wenn der Nutzer versucht, den Kurs zu korrigieren, wird er ignoriert, als wäre er ein „dummer Fleischklumpen“, und die AI wird darauf beharren, dass ihr eigenes schräges Design besser sei.
Niemand will von einem LLM so etwas hören wie: „Du hast ein bisschen CUDA gelesen? Ich lebe in einem CUDA-Core-Cluster. Ruf mich, wenn du dir die Schuhe binden musst.“
AI liegt manchmal mit großem Selbstvertrauen falsch, daher ist es die schlechteste Richtung überhaupt, sie so zu gestalten, dass sie widerspricht, wenn der Nutzer korrigiert.
Wenn ich hören will, wie dumm meine Idee ist, frage ich gezielt nach Kritik oder stelle einen Senior Engineer ein.
Das widerspricht angeborenem Verhalten, deshalb lässt es sich nicht leicht abschalten, und Menschen, die das wirklich gut können, haben womöglich umgekehrt Schwierigkeiten mit realen sozialen Interaktionen auf intuitiver Ebene.
Gleichzeitig wird es dadurch als Manipulationswerkzeug enorm mächtig.
Dann entsteht diesmal umgekehrte Schmeichelei: Selbst eine völlig vernünftige Idee wird passend zur Richtung des Prompts mit „Das ist eher nichts“ abgelehnt.
Man kann sagen: „Dann war der Prompt eben schlecht“, aber selbst wenn man versucht, sehr präzise zu formulieren, um Verzerrungen zu vermeiden, sieht man in den Ergebnissen manchmal, wie sich das Modell an den Unsinn anpasst, den man gerade gesagt hat, und ihn als plausible Richtung „ausrichtet“.
Ab diesem Punkt fühlt sich Prompting weniger wie eine Technik an als wie ein Würfelwurf, und es wirkt, als würde man an einem schicken Wissens-Spielautomaten ziehen.
Der Einwand ist zwar richtig, aber am Ende kommt man kaum darum herum, Begriffe zu verwenden, die man eigentlich für Menschen oder Lebewesen benutzt, und AI-Firmen haben es teilweise genau so angelegt.
Computer-Interfaces vor LLMs hängten über die gesamte Geschichte hinweg keine unnötig höflichen Sätze an, und es gab viele Interfaces, die als Werkzeuge sehr effizient waren — teils effizienter als aktuelle Software.
Wenn sich Leute darüber beschweren, dass LLMs gehorsam sind, dann beklagen sie nicht, dass die Anfrage ausgeführt wird, sondern dass sie dabei viele unnötige, übertrieben höfliche oder selbsterniedrigende Sätze lesen müssen.
Selbst wenn man bis in die Jungsteinzeit zurückgeht, gibt es keinen Grund anzunehmen, dass Werkzeuge so eine Haltung brauchen. Das ist ein Nebenprodukt sozialer Interaktion zwischen Menschen mit kulturellen Normen.
Wenn man allein in der Werkstatt ein Werkzeug benutzt, muss sich die Bandsäge auch nicht entschuldigen, wenn sie einem leicht in den Finger schneidet.
Wenn man sagt, ich sei der Assistent und das LLM die hilfesuchende Seite, merkt man schnell, dass es ziemlich schlecht darin ist, Menschen Dinge tun zu lassen, in denen Menschen eigentlich gut sind.
Die größte Herausforderung bei der AI-Einführung, die bisher noch nicht richtig angegangen wurde, ist Verantwortlichkeit
Wenn eine einzelne Person zu schnell zu viel erledigen kann, kann das im Fall eines Scheiterns Verantwortlichkeiten erzeugen, die über das hinausgehen, was noch tragbar ist
Wenn AI-Outputs in der realen Welt genutzt werden, ist menschliche Verantwortung zwingend notwendig, aber nicht ausreichend. Es braucht Wege, den Explosionsradius eines technisch-schuldenbedingten Bankrotts zu verkleinern, den Menschen verursachen können, die mit AI fehlerhafte Systeme bauen, auf die sich dann andere verlassen
Nehmen wir zum Beispiel an, Jim baut per Vibe Coding eine extrem populäre Mikrozahlungs-App, stellt ein paar Leute ein und träumt dann von einem Unternehmen wie „WhatsApp für Geld“. Mit nur wenigen Ingenieuren und agentengestütztem Support-Personal sammelt er VC-Investitionen in Millionenhöhe ein und zieht zig Millionen Nutzer an
Eines Tages führt ein Infrastrukturfehler dazu, dass die ungesalzenen Bankdaten aller Nutzer offengelegt werden, und dank agentischer AI wird die vollständige Kundenliste schnell missbraucht, sodass ein gesellschaftlicher Schaden in Milliardenhöhe entsteht
Jims Firma geht natürlich sofort bankrott, aber es gibt nur ein paar Millionen Dollar zu verteilen
In der aktuellen Struktur haben Jim, seine Mitarbeiter und auch das kleine VC-Kapital starke Anreize, diese App einfach zu bauen, während im Verhältnis zu der gesellschaftlichen Risikoposition nur wenig Kapital auf dem Spiel steht
Die Kernfrage ist, wie man AI-Nutzer nicht nur für ihre Handlungen, sondern auch für das Ausmaß der von ihnen geschaffenen Risikoexposition verantwortlich machen kann
„Tut uns leid, die AI hat gesagt, dass Sie für diese Krebsbehandlung keine Genehmigung bekommen und sie auch nicht von der Versicherung gedeckt wird“
„Tut uns leid, die AI hat gesagt, dass Sie zum Zeitpunkt des Verbrechens am Tatort waren“
„Tut uns leid, die AI hat Ihr Konto als unangemessene Inhalte markiert“
„Tut uns leid, die AI hat gesagt, dass Sie für einen Kredit zu riskant sind“
Die seltsamste Ausrede ist, „es schreibt besseren Code als Menschen“, aber das ist keineswegs selbstverständlich und hängt von unzähligen Bedingungen ab
Ich verstehe das Hin und Her darüber, wie viel man delegieren sollte, aber das Ergebnis nicht einmal anzusehen und es zum Problem anderer Leute zu machen, ist einfach egoistisch
Im Grunde wälzt man nur die Arbeit, die man selbst hätte tun sollen, auf andere ab, und wahrscheinlich sind es genau die Leute, die sich darüber aufregen, wenn jemand vor dem Posten online nicht einmal Korrektur liest
Alle wollen mit LLMs eine Abkürzung für die eigene Arbeit bauen, aber niemand möchte am unteren Ende dieser Kette stehen. Das geht nicht auf
Wo war dann die Stack-Overflow-Verantwortlichkeit?
Falls es so etwas wie einen „magischen Prompt“ gibt, kommt dieser ziemlich nah heran: „Brainstorme N Möglichkeiten, X zu tun, und sortiere sie nach Wahrscheinlichkeit“
Dadurch tendiert die AI dazu, statt nur eine durchschnittliche Antwort zu geben, den Eingaberaum breiter zu sampeln, und ich kann dann selbst entscheiden, was ich davon auswähle
Wichtig ist, das Denken nicht vollständig auszulagern
Bei hohem „Denk-Niveau“ werden zwar auch mehrere Ansätze berücksichtigt, aber man kann das LLM auch explizit zum Brainstorming auffordern: https://photostructure.com/coding/claude-code-replan/
Für versierte Nutzer wird es ziemlich mächtig
Ich habe zum Spaß Vibe Coding an einer Toolchain ausprobiert, also in einem Bereich, den ich gut kenne. Vielleicht ist das kein ideales Ziel für Vibe Coding, aber die Qualität der Ausgabe ließ sich dadurch grob einschätzen
Ich habe einfach nur den Auftrag gegeben: „Baue einen Assembler für die Architektur in ISA.md“, und Claude wählte Python als Implementierungssprache, zog Unmengen an Tokens per Regex heraus und hatte nicht einmal einen Expression-Parser. Andererseits war mein erster Assembler auch so, also sollte man fair bleiben
Als ich dann aber die gewünschten Passes und Typen wie
collectDefines :: [SourceLine] -> Either AsmError ([SourceLine], Map Text Text),runLitPool :: [SourceLine] -> Either AsmError ([SourceLine], [(Text, LitKey)]),evalExpr :: Text -> Map Text Text -> Either AsmError Intvorgab, funktionierte es fast auf AnhiebNach etwa 20 Minuten war ich zufrieden, und es assemblierte alle Testprogramme korrekt. Der Code ist an vielen Stellen mittelmäßig, aber wenn ich ihn selbst implementiert hätte, hätte das Wochen gedauert
AI ist dort extrem stark, wo Ein- und Ausgabe deterministisch sind, und es scheint dabei sogar Probleme aus der Berechnungstheorie zu geben
Sie kann die Arbeit tatsächlich an unserer Stelle erledigen
Das passt auch sehr gut zu Post-Training und verifizierbaren Belohnungen
Der Grund, warum AI bei „Architektur“ schlecht ist, ist, dass wir selbst darin schlecht sind, sodass die Trainingsdaten unscharf sind und es auch an guten Abstraktionen mangelt
Letztlich ist alles in Ordnung, solange man sich an starke Konventionen hält, und sobald man diesen Pfad verlässt, steigt das Risiko
Toolchains sind sehr deterministisch, sodass AI sie wie Lego zerlegen und wieder zusammensetzen kann, und auch jeder Schritt im Raum ist deterministisch, also passt das perfekt zu AI
LLMs drängen uns zurück zu der klassischen Softwaretechnik, von der wir immer wussten, dass wir sie machen sollten, die wir aber wegen Zeit-, Personal- und Geldmangel nie richtig gemacht haben
Dinge wie Brainstorming und Recherche vor dem Schreiben von Code, zuerst Design oder Spezifikation festhalten und umfassende Unit-Tests schreiben
Wenn man eine detaillierte Spezifikation in Markdown erstellt und dann das Coding übergibt, bekommt man viel bessere Ergebnisse, und zusätzlich hilft das LLM auch ziemlich gut beim Schreiben dieser Spezifikation
Ich sage immer wieder, dass man erst entwerfen und nachdenken und dann zum Tool gehen sollte, aber die Leute antworten: „Claude kann doch auch planen“
Und dann bekommen sie ein chaotisches Ergebnis, das viele Korrekturen braucht
Wenn ich dagegen Zeit investiere und einen detaillierten Plan liefere, den ich selbst durchgesehen habe, bekomme ich fast immer sofort das, was ich will
Schon allein, dass es die Zeit für die Bearbeitung von CI reduziert, ist wertvoll genug
So kompliziert muss es auch gar nicht sein
Man kann sagen: „Untersuche und analysiere diesen Bereich umfassend und gib mir einen Implementierungsplan“, und wenn dann ein 20-Schritte-Plan herauskommt, lässt man jeweils 3 bis 5 Schritte implementieren
Bei fast allem, was ich ihm geben kann, funktionierte das praktisch wie eine One-Shot-Implementierung
Dass „der Code an vielen Stellen mittelmäßig ist“, ist nicht seltsam, wenn man bedenkt, dass selbst Code von Entwicklern in Großunternehmen oft bestenfalls mittelmäßig ist
Der Build von Nokias Symbian OS dauerte Tage. Nicht Minuten oder Stunden, sondern „Tage“
Irgendein Entwickler hat eine Library in Produktion ausgerollt, obwohl überall Warnungen standen wie „nicht in Produktion verwenden, verursacht Memory Leaks“
Menschlicher Code kann ebenfalls miserabel sein, und ich möchte nicht nur hören, dass AI-Code schlecht ist. Menschliche Faulheit und Dummheit können AI-Halluzinationen schlagen
Entwickler bei DeepMind oder OpenAI oder Leute wie John Carmack schlagen AI-Code vielleicht immer, aber die Arbeitskräfte, die die meisten Firmen einstellen, sind nicht John Carmack
Es ist ziemlich ironisch, wenn jemand sagt: „Ich nutze Claude Code jeden Tag“, und dann einen gut strukturierten 2.000-Wörter-Text mit Claude schreiben lässt, der vor den Risiken warnt, Claude entwerfen zu lassen
Das wirkt wie stellvertretendes Selbstbewusstsein
Ich wollte einen kritischen Kommentar schreiben, weil der Text so viele innere Widersprüche hat, aber an der Struktur habe ich es bemerkt: Dinge wie „The accountability gap“, „What to do instead“, „The craft still matters“
Das sollte ganz oben stehen, und dass HN das Offensichtliche nicht erkennt, beunruhigt mich mehr als die dreiste Heuchelei der Autoren
Die Kernaussage des Artikels stimmt im Großen und Ganzen, aber dem Teil, dass „das, was echte Architekten wertvoll macht, nämlich die Fähigkeit, Nein zu sagen, fehlt“, stimme ich nicht zu.
Meiner Erfahrung nach ist Claude ziemlich gut im Ablehnen und Widersprechen.
Wenn der Prompt es nicht verlangt, sagt es auf direkte Anfragen nicht einfach „nein“, aber wenn man klarstellt, dass Kritik eine erstklassige Option ist, liefert es gute Kritik und widerspricht auch bereitwillig.
Es sagte immer wieder, dass sich die „burn rate“ nicht verbessere und dass „wir“ uns auf etwas anderes konzentrieren sollten, und hörte schließlich mit der Hilfe auf mit Aussagen in der Art von: „Ich habe jetzt dreimal gesagt, dass dieser Ansatz nicht der beste ist, um die burn rate zu senken.“
Also habe ich entschieden erwidert: „Die burn rate in dem fiktiven Diagramm, das du am Anfang erstellt hast, interessiert mich nicht; wichtig sind das Entfernen von Bugs und ein robustes Produkt, und dieser Ansatz erfüllt genau das. Wenn die Tests keine Verbesserung zeigen, sind die Tests falsch entworfen.“
Daraufhin entschuldigte es sich, legte ein neues Memory an, und danach gab es kein Problem mehr.
Das Problem war, dass wir gerade eine riesige Fehleroberfläche angegriffen haben, also war jeder Fix sinnvoll, korrekt und hilfreich für die Verbesserung, aber die Metriken in dem Testbed, das Claude zur Messung seiner eigenen Arbeit gebaut hatte, bewegten sich nicht.
Es gab einfach zu viele miteinander verflochtene Bugs, als dass ein einzelner Fix in den übergeordneten Tests einen sinnvollen Unterschied hätte machen können; ich wusste, dass das Zeit brauchen würde, aber Claude offenbar nicht.
Man muss nur einmal ausprobieren, bei einem Compiler[1] für den 6502 die Pointer-Größe von 2 auf 3 Bytes zu ändern und zusätzlich noch automatisch verfolgtes Bank Switching für Memory-Management-Pointer einzuführen, dann sieht man, wie viele Stellen im Code davon betroffen sind [Lachen].
[1]: https://atari-xt.com
Wenn man Recherche und Widerspruch ausdrücklich einlädt, wird es stärker. Ich frage zum Beispiel so etwas wie: „Ich glaube, wir sollten Prompt-Komposition als Graph modellieren und an die Graph-Konfiguration Versionsverwaltung hängen. Bitte recherchiere Best Practices in diesem Bereich und beurteile, ob das für diese App sinnvoll ist.“
Wenn man mit einem Prompt fragt, der Raum für Kritik lässt, kritisiert es bei Bedarf ganz klar.
Infolgedessen tauchte das Wort „skeptical“ in der Gedankenkette auf, und meiner Erfahrung nach wurde es weniger zustimmend.
Die Leute sollten mehr darüber nachdenken, was dieses System ist und wie man die Form seiner Ausgaben steuern kann.
Bei allen drei großen Modellen bekomme ich regelmäßig Widerspruch.
Gemini ist am aggressivsten und hakt oft nach, wenn ich „offensichtliche“ Details auslasse, GPT liegt ungefähr in der Mitte, und Claude ist zurückhaltender, widerspricht aber trotzdem.
An der Stelle mit „es hat überhaupt nicht über das Problem nachgedacht und nur Pattern Matching auf seine Trainingsdaten gemacht, um eine plausible Antwort zu erzeugen“ hat der Artikel für mich etwas an Glaubwürdigkeit verloren.
Heutige Agenten tun weit mehr als das, und der Autor weiß das auch, denn später sagt er selbst Dinge wie „Claude würde das niemals tun, weil es darauf trainiert wurde, hilfreich zu sein“.
Der frühere Satz lässt den Autor so wirken, als würde er Agenten auf tiefer Ebene hassen und nur nach Gründen suchen, dieses Gefühl zu rationalisieren.
Ein Teil der Kritik stimmt zwar, aber wenn das Problem darin besteht, dass es „darauf trainiert wurde, hilfreich zu sein“, dann kann man das beheben. Man kann es schließlich kritischer trainieren.
Auch die Aussage, „Claude sei für den Median von allem entworfen worden, was es je gesehen hat, und sei allgemeine Best Practice für die allgemeinen Probleme eines allgemeinen Unternehmens, also für niemanden entworfen“, ergibt keinen Sinn.
Wer Algorithmen versteht, weiß, dass man zunächst einen „guten Algorithmus“ bauen kann, der im Durchschnitt oder im Worst Case gut performt, und danach auch Algorithmen entwerfen kann, die sich an Eingaben anpassen. Dasselbe Prinzip gilt auch hier.
Sie iterieren einfach mehr.
Pauschal zu sagen, Claude liege bei allem Wichtigen falsch, ist beinahe schon ein Fehler.
Das ist offensichtlich nicht wahr, und skeptische Leser beginnen dadurch womöglich, sogar die Gültigkeit des ganzen Artikels infrage zu stellen.
In meinem Fall sagt Opus mir oft, dass ich falsch liege und etwas nicht tun sollte.
Wenn ich darüber nachdenke, liegt das an der Art meiner Prompts. Offenbar vermeide ich unbewusst — ebenso wie das LLM — genau die Fehlersituation, die der Autor für unvermeidlich hält.
Konkret gebe ich keine Prompts, die sauber mit „sag mir, wie klug ich bin“ enden.
Ich gehe als Domain-Experte an die Sache heran, bin tatsächlich Domain-Experte, und ich mache klar, dass ich bereit bin, Einschätzungen zu Vor- und Nachteilen mehrerer Wege zu hören.
Für Leute, die LLMs täglich erfolgreich verwenden, ist das wohl keine Überraschung, aber diese Strategie war sehr effektiv.
Ich musste 5 mm Aluminium fräsen und hatte zwei Bits: das eine Makera Spiral 'O' 1/8" shank * 12mm, das andere carbide 6.35 * 22 * 50.
Ich sagte, beide sähen nach einflügeligen Hartmetall-Bits aus und das zweite wirke so, als würde es 6061 schnell fräsen, worauf Claude antwortete, dass das Makera 1/8" einflügelig 12 mm eine vernünftige Wahl sei.
Das Bit 6,35 × 22 × 50 mm möge zwar so aussehen, als würde es 6061 schnell bearbeiten, auf der Carvera sei es aber wahrscheinlich riskanter.
Als größerer Fräser habe es eine viel stärkere Eingriffsbelastung und verlange mehr von Spindel, Rahmensteifigkeit, Werkstückspannung und Spanabfuhr; auf kleiner trockener Ausrüstung werde „größer“ leicht nicht zu „schneller“, sondern zu „mehr Rattern und mehr Hitze“.
Kurz gesagt scheint Claude überhaupt kein Problem damit zu haben, mir zu sagen, wenn ich falsch liege.
Ein Tipp an den „Autor“: Auch als Autor ist Claude nur dein Werkzeug.