Claude Code zum besten Design-Partner machen

• Als Claude Code anfangs genutzt wurde, erfolgte der Ansatz schlicht über Prompt-Anweisungen und wiederholte Korrekturen, doch bei komplexen Aufgaben traten Probleme durch die Abhängigkeit vom Gesprächsverlauf und Kontextgrenzen auf
• Um das zu lösen, wird vor der Implementierung einer Funktion ein Plan-Dokument erstellen lassen, das in einer neuen Sitzung als einzige Single Source of Truth (SSOT) dient
• Das Plan-Dokument enthält eine Neuformulierung der Anforderungen, Erläuterungen zu Implementierungsdetails, Befehle zur Prüfung der Codequalität und mehr und wird auch während der Implementierung fortlaufend als Living Document aktualisiert
• Dadurch wird das Problem des Kontextverlusts gelöst, und selbst in neuen Sitzungen lässt sich das Projekt allein anhand eines einzelnen Dokuments fortführen
• Dadurch wird die AI letztlich nicht nur zu einem Ausführungswerkzeug, sondern zu einem kollaborativen Design-Partner, der Entwickler dazu bringt, tiefer über das Design nachzudenken und es zu dokumentieren

---

Problembewusstsein: Grenzen des einfachen Gesprächsansatzes

• Wenn man mit Claude Code interaktiv arbeitet, eignet sich das für einfache Aufgaben, aber je größer komplexe Aufgaben werden, desto mehr treten mehrere erhebliche Einschränkungen auf
  • Das Gespräch wird zur einzigen Quelle der Wahrheit, sodass neue Nachrichten frühere Anweisungen leicht überschreiben können, ohne dass dieser Moment klar erkennbar ist
  • Aufgrund der begrenzten Kontextgröße der AI können frühere Informationen verloren gehen, je länger das Gespräch wird
  • Zwar verfügt Claude Code über eine Funktion zur Gesprächskomprimierung, doch löst sie diese Grenze nicht vollständig

Experiment mit einem plan-dokumentzentrierten Ansatz

• Um diese Probleme zu lösen, wurde ein plan-dokumentbasierter Ansatz ausprobiert
  • Zu Beginn wird Claude Code die zu implementierende Funktion oder der zu behebende Bug so detailliert wie möglich beschrieben
  • Es werden auch bestehende Quelldateien oder zuvor erstellte Plan-Dokumente erwähnt, auf die verwiesen werden kann
  • Übermäßig konkrete Implementierungsvorgaben werden vermieden, um die Rolle der AI als Design-Vorschlagsgeber zu fördern
• Wenn das Plan-Dokument zufriedenstellend genug ist, wird der Gesprächsverlauf gelöscht und mit genau diesem Plan als neuem Kontext erneut begonnen
  • Der Plan enthält eine Funktionszusammenfassung, einen Implementierungsplan, Code und Pseudocode sowie Befehle für Typprüfung, Linting und Tests

Kollaborativer Design-Prozess

• Wenn einem das von der AI vorgeschlagene Design nicht gefällt, wird konkretes Feedback gegeben, um einen überarbeiteten Ansatz herbeizuführen
• Im Verlauf der Diskussion wird mitunter klar, dass der erste Vorschlag der AI besser geeignet war, und das ist effizienter, als allein auf Basis des eigenen Designs zu coden
• Ein strukturierter Dialog bietet eine Erfahrung, die der Diskussion eines Plans mit einem Entwicklerkollegen ähnelt
• Die AI präsentiert nicht von selbst einen völlig anderen Ansatz, kann aber auf Nachfrage andere Alternativen vorschlagen

Ansatz mit einem Living Document

• Das Plan-Dokument wird nicht einmal erstellt und dann abgeschlossen, sondern auch während der Funktionsimplementierung fortlaufend aktualisiert
  • Änderungen, die sich im Implementierungsprozess oder bei Typprüfung, Linting und Tests zeigen, werden in Echtzeit eingepflegt
• Es wird die Gewohnheit aufgebaut, bei jedem Code-Commit um eine Prüfung des aktuellen Plan-Stands zu bitten
• Da immer ein aktueller Plan erhalten bleibt, reicht es in neuen Gesprächssitzungen aus, nur den Plan anzuhängen, um ohne Kontextverlust nahtlos weiterzumachen

Code-Review und veränderte Entwicklungsgewohnheiten

• Nach Beginn der Implementierung werden Änderungen regelmäßig geprüft, und wenn die Ergebnisse zufriedenstellend sind, wird der Arbeit der AI auch stärker vertraut
• Bei der abschließenden Codeprüfung hilft das aktualisierte Plan-Dokument dabei, die Grundlage technischer Entscheidungen nachzuvollziehen
• Durch sorgfältige Planung und Dokumentation im Vorfeld entsteht die Erfahrung, zu einem besseren Entwickler zu werden
  • Weil man es der AI erklären muss, wird der eigene Entscheidungsprozess klarer strukturiert

Von Chaos zu Systematik

• Dieser Ansatz macht das Plan-Dokument zur einzigen Quelle der Wahrheit, behebt das Problem des Kontextverlusts und fördert architektonisches Denken
• Das Plan-Dokument umfasst sowohl Spezifikation als auch Implementierungsprotokoll und hält nicht nur das „Was“, sondern auch das „Warum“ und das „Wie“ fest
• Das Endergebnis ist ein planvoller, gut dokumentierter und verlässlicher Entwicklungsprozess
• Die AI etabliert sich nicht als bloßer Implementierer, sondern als kollaborativer Design-Partner

[jamsya]

Es scheint, als würde im Workflow von Entwickler:innen der Anteil der Rollen von PM und Architekt:in größer werden.

[GN⁺]

Hacker-News-Kommentare

• In den letzten zwei Wochen habe ich mich jeden Abend total darauf fokussiert, mit Claude Code den „perfekten Prompt“ zu bauen, mit dem sich ein Projekt in einem Rutsch fertigstellen lässt. Am Ende habe ich eine Struktur gebaut, in der eine einzige CLAUDE.md auf acht verschiedene Markdown-Dateien verweist, darunter Projektarchitektur, Modellspezifikation, Build-Reihenfolge, Test-Hierarchie und Szenarien. Das Projekt ist für modellbasierte Governance im Databricks Unity Catalog gedacht. Ich habe zwar viel relevante Erfahrung, fand die vorhandenen Tools aber nicht flexibel genug. Schließlich habe ich mir von drei Sub-Agenten bei der eigentlichen Arbeit an den Planungsdateien helfen lassen: einem Databricks-Experten, einem Pydantic-Experten und einem Prompt-Experten. Dadurch hat sich die Qualität der Markdown-Dateien stark verbessert – von Problemen mit älteren Pydantic-Versionen bis hin zu meinen Missverständnissen über Unity Catalog. Gestern habe ich es dann tatsächlich laufen lassen, und abgesehen davon, dass ich ein paar Tool-Nutzungen freigeben musste, waren die meisten Tools und Tests in zwei Stunden fertig. Dieser Ansatz war so anders als früher, dass ich ihn faszinierend fand. Ich habe wirklich das Gefühl, dass die Zukunft darin liegt, technische Dokumentation sorgfältig zu schreiben und alle auf dieselbe Richtung auszurichten. Ich glaube sogar, dass das produktiver ist, als selbst im Code zu graben. Ein Nachteil ist allerdings, dass ich bei Code-Arbeit zwar hoch fokussiert bin, meine Konzentration beim Umgang mit mehreren Markdown-Dokumenten aber leichter zerfasert. Wirklich eine spannende Zeit

  • Es fühlt sich so an, als würde ein neues Muster aufkommen, das einen dazu bringt, das System im Voraus zu entwerfen – ähnlich wie Test-Driven Development. Früher hat man das System beim Schreiben des Codes schrittweise konkretisiert, aber bei dieser Art AI-basierter Entwicklung entwirft und mappt man die Domäne vorab, und der eigentliche Code wird fast zu Boilerplate, die nur noch den Entwurf umsetzt. Genau bei solcher Boilerplate ist AI wirklich stark

  • Bei mir ist es genauso: Ich bin produktiver, aber meine Konzentration ist noch stärker zerstreut. Das fühlt sich irgendwie seltsam an, ist im Moment aber effektiv. Langfristig muss man dafür wohl eine Lösung finden. Im Moment funktioniert für mich am besten, mehrere Agenten in verschiedenen Repositories eines Projekts jeweils an unterschiedlichen Tasks arbeiten zu lassen und ständig Freigaben zu erteilen. Es fühlt sich ein bisschen an wie ein Projektmanager, der ein großes Team führt. Ebenfalls eine spannende Zeit

  • Wirklich ein frischer Ansatz. Mich würde interessieren, welches Framework in dem realen Experiment für die laufenden Agenten verwendet wurde

  • Ich zeichne inzwischen ebenfalls Produktdetails, User Journeys usw. per Sprache auf und starte damit dann den technischen Dokumentationsprozess. Eine minimale CLAUDE.md, für die Softwareentwicklung GitHub-Workflows, aber gute CI-Workflows zu bauen ist schwierig. Mein Playbook ist https://nocodo.com/playbook/

• Die Aussage „Wenn man erst plant, wird das Ergebnis besser“ überzeugt mich nicht wirklich. Ich habe große Features oder Projekte schon immer vorab strukturiert und über das Was, Warum und Wie nachgedacht – ob im Kopf, auf Papier, in Confluence oder am Whiteboard. 80 % von Software Engineering bestehen darin, zu überlegen und festzulegen, was, warum und wie man etwas tun will. Man stimmt Ideen und Ziele mit Stakeholdern ab und recherchiert. Nur die letzten 20 % sind das eigentliche Coden. So war es schon immer, und ich weiß nicht, ob man für ordentliche Planung oder Zieldefinition unbedingt AI braucht

  • Das mag in großen Teams oder in Umgebungen mit etablierter Kultur so sein, aber ein beträchtlicher Teil der Entwicklung konzentriert sich auf Solo-Projekte, kleine Teams, Side Projects, schnelle POCs oder einmalige Automatisierungstools. Solche Arbeiten starten nicht von Anfang an mit Dokumentation/Spezifikationen/Tests, sondern mischen Code mit Nachdenken und Implementierung. Es gibt Bereiche, in denen TDD gut passt, aber auch viele Fälle, in denen es unnötig ist. Seit der Einführung von AI-Coding-Agenten ist es jedoch viel wichtiger geworden, Ideen klar zu definieren und in Spezifikationen zu gießen. Alles, was in meinem Kopf herumschwirrt, in Worte zu fassen, ist entsprechend essenziell geworden. Die aktuell heißeste Programmiersprache ist Englisch

  • Ich mische Entwicklung und Design eher miteinander. Ich fange einfach an zu coden und verfeinere und entwickle es dann laufend weiter. In den meisten Fällen ist der grobe Lösungsweg ohnehin offensichtlich, deshalb habe ich nicht das Gefühl, dass sich tiefe Planung wirklich lohnt

• Früher war Prompt Engineering ein Witz, aber inzwischen spüre ich wirklich, dass es real ist. Manchmal verbringe ich 10 bis 20 Minuten damit, sehr sorgfältige Prompts und die Anfangsplanung auszuarbeiten, um Claude Code systematisch zu nutzen. Ähnlich wie OP speichere ich den Plan auch in Dateien und führe ihn in neuem Kontext aus. Was ich mir wirklich wünsche, ist eine gute CLI (derzeit nutze ich charm und cc). Am besten wäre es, wenn man für Implementierung, Planung und einzelne Sub-Agenten jeweils unterschiedliche Modelle nutzen könnte. Implementierung mit einem lokalen Modell, Planung mit einem Cloud-Modell, oder je nach Bedarf wechseln, um Geld zu sparen. Charm ist von allem, was ich bisher genutzt habe, am besten darin, ohne Kontextverlust hin- und herzuwechseln. Auch die parallelen Sub-Agenten gehören zu den besten Funktionen von claudecode. (CCR habe ich ausprobiert, war aber enttäuscht, weil es nicht über das Basismodell hinauskam)

  • Dass Prompt Engineering jetzt zum Thema geworden ist, liegt an Twitter-Hottakes und Content-Produktion. In Wirklichkeit war Prompt Engineering schon immer wichtig. GIGO („Garbage In, Garbage Out“) ist in jedem Machine-Learning-Projekt eine Grundwahrheit. Deshalb empfehle ich Kollegen und Freunden immer wieder: „Ihr müsst es selbst ausprobieren.“ Was vor sechs Monaten nicht ging, kann heute funktionieren. Nur wenn man selbst damit arbeitet, merkt man, was sich geändert hat und was möglich ist. Ich halte reale Erfolgsgeschichten, Blogposts, Gists und Beispiele für viel wertvoller als bloße Negativhaltung. Es reicht nicht, wenn es nur einfache Rechnungen oder Tippfehler findet – es muss meinen Workflow verbessern und mir wirklich helfen. Prompt Engineering ist wie vor 10 bis 15 Jahren tief in Google-Skills einzutauchen und laufend neue Entwicklungen und wirksame Muster zu lernen

  • Um mit AI zusammenzuarbeiten, ist Prompt Engineering wirklich zentral

  • Die Projekte, in denen ich AI eingesetzt habe, waren die am besten dokumentierten und getesteten Projekte, an denen ich je gearbeitet habe. Ein LLM braucht zwingend Kontext, um Leistung zu bringen, also verbessert sich die Dokumentation, und weil die Produktionskosten für Tests gesunken sind, gibt es mehr Tests. Entgegen der Vorhersage, dass die Code-Qualität sinken würde, wird sie eher besser werden

  • Ehrlich gesagt ist der Begriff „Prompt Engineering“ so etwas wie Architekturdesign mit einem neuen Medium. Früher war „Diagramm-Design“ eine gefragte Fähigkeit, heute ist es eine neue Form des Architekturentwurfs

• Ich habe Claude Code kürzlich kurz ausprobiert und will den empfohlenen Workflow testen. Das scheint ein ziemlich guter Ansatz zu sein. Allerdings ist CC teurer, als ich dachte. Ich habe nur ein einfaches Refactoring gemacht – 5 Minuten Arbeit plus 15 Minuten Review – und das hat schon 4 Dollar gekostet. Wenn ich es selbst gemacht hätte, wäre ich in 15 bis 20 Minuten fertig gewesen. Mich würde interessieren, wie viel andere normalerweise pro Feature mit CC ausgeben. Niemand spricht über die Preise

  • Mit einem Abo zahlt man pauschal 20 bis 200 Dollar, mit täglichen bzw. wöchentlichen Limits beim Token-Verbrauch. https://support.anthropic.com/en/articles/11145838-using-claude-code-with-your-pro-or-max-plan

  • AI-Investoren wünschen sich letztlich ein Modell, in dem der Arbeitsmarkt mit einer Marge von 15 % durch AI ersetzt wird. Es wird eine Zeit kommen, in der pro Entwickler 1:1 ein gleich großes AI-Budget gegenübersteht. Zum Beispiel wird ein Senior Developer mit 100.000 Dollar Gehalt durch 100.000 Dollar AI-Budget ersetzt. Das AI-Budget wird aus den Entwicklungskosten herausgeschnitten, Senior-Gehälter könnten sinken, und die Teams könnten drastisch schrumpfen. Im Moment befinden wir uns noch in einer „Gebiet sichern“-Phase, die vollständig von VCs subventioniert wird, aber wenn man sich die VC-Stimmung auf Twitter anschaut, scheint diese Phase bald zu enden. Auch mehrfach weitere 500 Millionen Dollar für neun Monate Runway einzuwerben, stößt irgendwann an Grenzen

  • Seit ich teilweise von Cursor zu Claude Code gewechselt bin, sind meine Kosten deutlich gestiegen. In der Firma nutze ich es hauptsächlich, daher war es leicht, meinen Chef zu überzeugen, aber für Side Projects ist es ein echtes Dilemma. Ich möchte nicht jedes Mal 20 Dollar zahlen, nur um zum Spaß eine App zu bootstrappen

  • Man kann die beiden Modelle Sonnet (20 Euro/Monat) und Opus (100 Euro/Monat) auswählen und abonnieren. Ich habe mit Sonnet angefangen und bin später zu Opus gewechselt. Sonnet ist ebenfalls absolut brauchbar. Innerhalb der Token-Limits reicht es für meine Zwecke bisher gut aus. Wie das in Zukunft aussieht, weiß ich allerdings nicht

  • Du sagst, „ich hätte das selbst in 15 bis 20 Minuten gemacht“, aber vielleicht könntest du diese 15 bis 20 Minuten für etwas anderes nutzen

• Mein Workflow ist ähnlich, nur mit der Kombination aus Visual Studio Code und ChatGPT5 Preview {vermutlich zahle ich über ein GitHub-Copilot-Abo, aber inzwischen bin ich mir da nicht mehr sicher}. Ich habe stark den Eindruck, dass nicht-agentische LLMs dazu neigen, Code schnell zu ruinieren. Mit dem Agent-Modus verändert sich der Aufbau von Code komplett. Ich bin zwar kein Python-Entwickler, aber es hat mich wirklich beeindruckt, wie das LLM neue Code-Haufen erstellt hat. Danach will ich ein kleines LLM in BitGrid laufen lassen und den Code erst im Nachhinein vollständig verstehen. Die Struktur ist, kleine Erkundungsschritte zu wiederholen und nur punktuell einzugreifen, um das Gesamtdesign so zu halten, wie ich es will. Dadurch bin ich überzeugt, dass LLMs in Zukunft Programmpartner werden. Mich würde interessieren, ob noch andere die Kombination aus Visual Studio Code und ChatGPT5 nutzen

• Es ist interessant zu sehen, dass Entwickler beim Optimieren von AI-Tools offenbar den Wert von „guter Kommunikation“ und „Erwartungsmanagement“ wiederentdecken. Das bisherige Bild des 10x-Entwicklers als Außenseiter oder Exzentriker sollte vielleicht überdacht werden

• Ich habe mit Replit eine ähnliche Erfahrung gemacht. Wenn eine App größer wird, bricht sie schnell auseinander, wenn Design-Dokumente nicht zur Task-Grundlage und Source of Truth werden. Bei OpenAI wird der Chat langsam und hängt sich schnell auf, daher hilft es, Dokumente separat zu erstellen und in einen neuen Chat zu importieren. Ich hatte auch auf menschlicher Ebene das Gefühl, dass wir das genauso tun sollten. Indem wir selbst reflektieren, dokumentieren und „Erinnerung“ in Design-Dokumenten festhalten, können sowohl wir als auch LLMs freier werden

• Ich habe diesen Workflow auch erst kürzlich entdeckt und war sehr überrascht. Wichtig ist, Claude nur minimale Anforderungen zu geben und den Plan-Modus frei laufen zu lassen. Wenn es zum Beispiel um einen Sales-Metrics-Report geht, reicht schon „Ultrathink relevant sales metrics“, und es nennt verschiedene Metriken, priorisiert sie und hilft beim Eingrenzen. Für jedes neue Feature lasse ich ein eigenes Verzeichnis anlegen und den Plan dafür in eine Datei schreiben. Danach lasse ich Schritt für Schritt einen Implementierungsplan, die nötigen Datenabfragen, die eigentliche Implementierung, Tests und User-Dokumentation erstellen und schicke es dann an QA. Früher brauchte schon ein einziges Sales-Forecasting-Feature ein großes Team und viel Zeit, heute setzt Claude es in einem Docker-Container in einem halben Tag um. Diese Veränderung beginnt meine Sicht auf Software zu verändern. Früher haben Unternehmen wegen NDA, IP usw. ihren Source Code niemals nach außen gegeben. Heute kann Claude selbst komplexe ERP-Systeme, die über 20 Jahre gewachsen sind, schnell neu implementieren und gleich Dokumentation und Tests beilegen. Realistisch betrachtet ist das noch nicht perfekt, aber das Tempo ist wirklich enorm

• Um gute Features aus Claude Code herauszuholen, ist es entscheidend, zuerst einen guten Plan zu schreiben. Ich nutze in letzter Zeit GPT-5 High in Cursor, um den Plan zu erstellen, und gebe ihn dann an Claude Code zur Implementierung weiter. Wenn man zusätzlich dokumentieren lässt, welche Teile der Codebase geändert werden müssen, erhält man 15 bis 20 % bessere Ergebnisse. Wenn das Planungsmodell Arbeitsweise, Architektur, Muster und sogar das Feature-Design dokumentiert, ist das Resultat besser. Und zuletzt hilft es enorm, Dokumentation und Plan unbedingt selbst zu reviewen und zu überarbeiten

  • In der Firma nutzen wir Google Workspace, daher ist Gemini bei „akademischem Stil“ sehr stark, aber beim Schreiben von Code schwächer als CC. Deshalb lasse ich Gemini den Plan sehr detailliert ausarbeiten und übergebe ihn dann an CC, damit es ihn in meiner Codebase anpasst und umsetzt. Mit dieser Methode habe ich überraschend gute Ergebnisse bei neuen Features und bei der Erweiterung bestehender Funktionen gesehen. Ein Produkt, das ich selbst gebaut habe, ist nach acht Wochen bereits in echter Produktion und wird Kunden in Demos gezeigt. Ich bin mit der Erfahrung und den Ergebnissen von CC sehr zufrieden. Wie ich schon früher auf HN geschrieben habe, hätten wir einen großen Teil davon zwar auch mit unserem Team umsetzen können, aber Frontend-Arbeit hätten wir uns kaum zugetraut. Was früher mehr als ein Jahr und den Einsatz zusätzlicher Engineers und Data Scientists gekostet hätte, war größtenteils in zwei Monaten fertig. Features hinzuzufügen dauert fast nicht mehr „Zeit“, sondern eher „Sekunden“. Ich finde es spannend, dass meine Erfahrung dank CC nun mit mehreren Menschen geteilt wird

• Ich frage mich, ob jemand einen guten Weg gefunden hat, Frontend-Design elegant in diesen Prozess einzubauen. Meistens bleibt es bei der Erwähnung eines Frontend-Frameworks oder bei Figma-Bildern. Das fühlt sich für mich noch nicht wie eine integrierte Designlösung an