In meinem letzten Beitrag habe ich dir gezeigt, warum Verifikation die Grundlage von allem ist, was ich mit Agenten mache, und wie du deine eigenen Verifikationsfähigkeiten entwickeln kannst. Die wichtigste Erkenntnis war: Wenn ein Agent seine eigene Arbeit nicht überprüfen kann, ist alles andere egal. Du bleibst der Flaschenhals und verbringst deinen ganzen Tag damit, deine Agenten zu beaufsichtigen.
https://x.com/poteto/status/2094457600259842065
Aber sobald die Verifikation funktioniert, stellt sich die nächste Frage: Wie findest du eigentlich heraus, was du bauen sollst?
https://x.ai/bot/plugin/9717366
In diesem Beitrag zeige ich dir, wie ich mit pstack Recherche, Planung, Prototyping und Architektur angehe. Das ist genau der Workflow, der es mir ermöglicht, Tausende von PRs pro Monat in die Produktion zu bringen und dabei eine außergewöhnlich hohe Codequalität zu halten.
Ende August mit 2.462 PRs in der Produktion
Die Kunst, jemanden zu beaufsichtigen, der schlauer ist als du
Früher, in den guten alten Zeiten von 2024, musstest du, um eine Änderung in einem System vorzunehmen, zuerst genug davon lesen, um ein mentales Modell davon zu entwickeln, was vor sich geht. Abhängig von der Größe und Komplexität der Codebasis konnte das Stunden, Tage oder sogar Monate dauern. Bei einer kleinen Änderung konntest du vielleicht mit einem lokalen Verständnis eines kleinen Subsystems auskommen. Wenn du jedoch den Kern umstrukturiert hast, brauchtest du wahrscheinlich ein mentales Modell des gesamten Systems, um die Umstrukturierung korrekt und effektiv durchzuführen.
Agenten beseitigen diese Hürde offensichtlich. Du kannst Änderungen an Systemen sehr einfach vornehmen, indem du deinem Agenten einfach Anweisungen gibst, und er wird es tun, unabhängig davon, wie viel oder wie wenig du über den Code weißt. Aber die Qualität des Codes und der Benutzererfahrung hoch zu halten, ist dennoch schwierig, besonders wenn du nicht bereits ein Fachexperte bist, der weiß, worauf er achten und was er fragen muss.
Obwohl die neuesten Modelle sehr leistungsfähig geworden sind, beobachte ich immer noch zwei Fehlermodi:
- Sie sind nicht in der Lage, deine Absicht vollständig zu verstehen, weil sie zu vage oder schlecht spezifiziert sind.
- Sie haben nicht genügend Kontext, um die Arbeit korrekt auszuführen.
Beide Probleme hängen zusammen. Agenten gut einzusetzen, hängt davon ab, wie gut du in der Lage bist, den Kontextfenster des Agenten mit hochwertigem Kontext zu füllen. Du kannst sicherlich Code schreiben, der funktioniert, ohne dies zu tun, aber ich stelle fest, dass die Ergebnisse und die Qualität viel besser sind, wenn ich die Arbeit investiert habe, um meinen Agenten alles zur Verfügung zu stellen, was sie für eine qualitativ hochwertige Arbeit benötigen.
In deinen eigenen Worten
Die neuesten Modelle sind sehr leistungsfähige Programmierer. Während ich bei älteren Modellen vielleicht sehr spezifisch angeben musste, was ich wollte, fast schon micromanaging betrieben habe, können die neuesten Modelle Code besser schreiben als du oder ich. Es gibt also eine feine Balance, die ich anstrebe: Dem Agenten zu sagen, was ich erreichen möchte, ihm aber gleichzeitig die Freiheit zu geben, es auf Wegen zu lösen, an die ich vielleicht nicht gedacht hätte.
Das ist die Kunst, jemanden zu beaufsichtigen, der schlauer ist als du, in einer Codebasis, die du nicht selbst geschrieben hast, und bei der Menschen das gesamte mentale Modell der Codebasis nicht mehr im Kopf behalten können.
Eine Technik, die ich gerne verwende, ist der indirekte Prompt. Anstatt dem Agenten genau zu sagen, was ich will, versuche ich, es aus ihm herauszulocken – in seinen eigenen Worten.
Wenn zum Beispiel jemand ein Problem in Slack meldet, bitte ich den Agenten oft, den Thread zu lesen und das Problem in seinen eigenen Worten wiederzugeben, bevor er etwas anderes tut.
Zum Beispiel könnte ich sagen:
/poteto-mode lies diesen Slack-Thread. Gib in deinen eigenen Worten und in einfachem Deutsch wieder, was du für das zugrundeliegende Problem hältst
Das erreicht drei Dinge:
Erstens zwingt es den Agenten, ein verrauschtes Gespräch in eine strukturierte Problembeschreibung zu komprimieren. Zweitens kann ich so Missverständnisse sofort erkennen. Wenn der Agent sich auf eine falsche Fährte im Thread versteift, kann ich ihn schnell korrigieren, bevor er anfängt, Code zu schreiben.
Und drittens habe ich ihn nicht möglicherweise auf den falschen Weg geführt, indem ich meine eigenen Annahmen und Hypothesen geäußert habe, die falsch sein oder das, was der Agent sonst erreichen könnte, einschränken könnten.
Ein mentales Modell aufbauen
Den Agenten zu bitten, sich so auszudrücken, dass du es verstehen kannst, ist ein wichtiger Teil der Zusammenarbeit mit jemandem, der schlauer ist als du. Das war die Inspiration für /teach, eine Fähigkeit, die deinem Agenten hilft, dir Dinge auf intuitive Weise zu erklären. Ich verwende sie immer dann, wenn ich sicherstellen muss, dass mein Agent etwas tut, das für mich Sinn ergibt.
Unter der Haube ruft /teach /how und /why auf.
/how verfolgt die Laufzeitmechanik. Wenn du /how fragst, bewertet der Agent die Komplexität des Subsystems. Wenn das Subsystem mehrere Verzeichnisse oder Dienste umfasst, startet es parallele Explorer-Agenten auf schnellen, effizienten Modellen wie Grok.
/how ist die Virtualisierung implementiert?
/why untersucht Motivation und Absicht. Code sagt dir, was passiert. Er sagt dir selten, warum jemand ihn so geschrieben hat. Wenn du /why ausführst, durchsucht pstack historische Beweise aus mehreren Quellen parallel: Git-Verlauf und PR-Review-Kommentare, Linear-Tickets, Notion-Design-Dokumente, Slack-Gespräche, Datadog-Monitore, Sentry-Fehler, Code-Abstammung und Analytics-Warehouse-Ereignisse.
/why hängen wir immer noch an einer alten Version von node.js fest?
Ich verwende /teach immer dann, wenn ich möchte, dass der Agent etwas wiederholt, damit ich seine Arbeit besser verstehen und ihr vertrauen kann.
/teach mir, warum du es so und nicht <anders> implementiert hast. Welche Kompromisse hast du eingegangen und warum?
In der Praxis habe ich auch festgestellt, dass die vom /teach-Skill durchgeführte Recherche nicht nur für Menschen, sondern auch für Agenten nützlich ist. Selbst bei den neuesten Modellen (das hängt auch von der Qualität des Harnesses ab) stelle ich fest, dass sie oft Dinge selbstbewusst behaupten, ohne sie mit Daten zu untermauern oder den Code tatsächlich zu lesen, der nötig ist, um ein mentales Modell seiner Funktionsweise aufzubauen. Dieser Akt, dir beizubringen, was es tun wird und warum, hilft also auch dem Agenten.
Aus der Geschichte lernen
Viele meiner Projekte erstrecken sich über mehrere Gespräche. Vor ein paar Monaten habe ich zum Beispiel daran gearbeitet, Virtualisierungsfehler und Performance-Probleme zu beheben, die Leute in Cursor gemeldet haben. Mir ist aufgefallen, dass ich jedes Mal, wenn ich einen neuen Chat gestartet habe, praktisch von vorne anfangen musste, um den reichhaltigen Kontext wieder aufzubauen, den mein Agent zuvor hatte, als er ein ähnliches Problem gelöst hat.
Was mir klar wurde, ist, dass deine vergangenen Transkripte oft eine Goldgrube für reichhaltigen Kontext sind. pstack wird mit dem /recall-Skill ausgeliefert, um deinen aktuellen Kontext aus dem Chat-Verlauf abzurufen, sodass auch neue Agenten den richtigen Kontext haben, den sie brauchen, um wieder in einen guten Zustand zu gelangen.
/recall die Arbeit, die ich gestern an der Virtualisierung gemacht habe, und lies dann diesen Fehlerbericht in Slack
/teach, /recall, /how und /why zu verwenden, ist meine Methode, um meine eigenen mentalen Modelle der Codebasis aktuell zu halten, komprimiert in eine Form, die ich leicht verstehen und mir merken kann. Und es hilft auch den Agenten!
Rückwärts arbeiten
Sobald du das Problem verstanden hast, wie spezifizierst du die Lösung?
Meiner Meinung nach neigen die meisten Harnesses mit Plan-Modi dazu, Implementierungsdetails zu überspezifizieren und alles andere zu unterspezifizieren. Deshalb habe ich in pstack etwas frech gesagt, dass "ich nicht an Planung glaube". Die Wahrheit ist, dass ich plane, aber ich tue es durch Code.
Für bestimmte Arten von Arbeit, wie das Erstellen von gemeinsam genutztem Code oder Paketen, die andere verwenden werden, bin ich ein großer Verfechter der Readme-getriebenen Entwicklung. Falls du damit nicht vertraut bist: Es ist eine Entwicklungstechnik, die früher populär war, bei der du damit beginnst, zuerst deine Readme zu erstellen. Das zwingt dich, deinen Entwicklererfahrungs-Hut aufzusetzen, bei dem du damit beginnst, die APIs für einen hypothetischen Benutzer zu beschreiben, und dich rückwärts zur Implementierung und Architektur arbeitest.
Als ich zum Beispiel Dune, unser hauseigenes Client-Framework für Desktop-Apps, gebaut habe, habe ich zuerst ein Tutorial dafür geschrieben, damit ich verstehen konnte, wie es wäre, eine App damit zu bauen. Oder zumindest habe ich es versucht. Es war ein echter Kampf, den Agenten dazu zu bringen, etwas Gutes oder Lesbares zu produzieren. Also musste ich zuerst etwas Zeit investieren, um mein Messer zu schärfen, indem ich den /technical-writing-Skill erstellt habe.
Der erste Durchgang der Readme ohne den /technical-writing-Skill war schmerzhaft zu lesen, weil er verschiedene Ziele vermischte. Er versuchte, ein Tutorial, eine Anleitung, eine architektonische Erklärung und eine API-Referenz in einem einzigen Dokument zu sein, geschrieben mit dem üblichen KI-Geschwafel und manierierter Prosa.
/technical-writing verwendet das Diátaxis-Framework, um die Dokumentation in vier verschiedene Modi zu unterteilen:
- Tutorial: Lernen durch Tun. Eine Lektion, die einen Neuling durch eine Reihe von Schritten führt, um etwas Sichtbares zu bauen.
- How-to-Anleitung: Schritte zur Lösung eines spezifischen, realen Problems für einen erfahrenen Benutzer.
- Referenz: Trockene, vollständige, maßgebliche technische Beschreibungen von Maschinen, APIs und Konfigurationsflags.
- Erklärung: Diskussion auf hohem Niveau, die Hintergründe, Designentscheidungen und Kompromisse klärt und beleuchtet.
Es verwendet auch /unslop, sodass es eine sehr lesbare Dokumentation produziert.
Einen Plan auf diese Weise zu schreiben, ist sehr hilfreich, weil es deinen Agenten auch ein konkretes Ziel und einen konkreten Zweck gibt, an dem sie ihre eigene Arbeit messen können. Und natürlich ist es auch viel einfacher zu verstehen, was genau der Agent bauen wird.
Viele der pstack-Skills bauen in der Entwurfsphase aufeinander auf. Zum Beispiel:
(1) /recall meine Arbeit zur Behebung von Virtualisierungsfehlern und Performance-Problemen der letzten 7 Tage. Verwende /how und /why, um zu verstehen, wie unsere aktuelle Virtualisierungsimplementierung funktioniert.
(2) Verwende dann /poteto-mode-Planung und /technical-writing, um eine neue Virtualisierungs-Engine zu entwickeln, die Flackern und Ruckeln kategorisch beseitigt. Lass uns mit dem Schreiben eines Tutorials beginnen, wie ich dieses neue Paket verwenden würde, um eine React-App zu virtualisieren
(3) Nachdem du den Plan geschrieben hast, /teach mir und beweise mir, warum dieser neue Ansatz unserer aktuellen Engine überlegen ist
Die Technik hier besteht wirklich darin, interessante und reichhaltige Kontexte hervorzulocken, die deinen Agenten die Fähigkeit geben, das Problem so zu sehen wie du – nicht nur als kleinen Ausschnitt:
- Der erste Teil des Prompts ruft relevanten vergangenen und gegenwärtigen Kontext darüber ab, wie die Virtualisierung in meiner App implementiert ist.
- Der zweite Teil führt den Agenten dazu, diesen Kontext, wie z. B. zuvor behobene Fehler, zu nutzen, um ein neues Design zu entwickeln, das diese Probleme vollständig beseitigt.
- Der letzte Teil besteht darin, deinen Agenten zu bitten, dir zu beweisen, dass dieses neue Paket überlegen ist. Hier sind hochwertige Tools wie Verifikations-Skills wichtig.
Hundertmal messen, einmal schneiden
Bei der Planung sind zwei der häufigsten Fehler, die ich sehe:
- Das erste Design des Agenten zu akzeptieren.
- Den Plan ohne empirische Belege zu überkochen.
Als Menschen Code geschrieben haben, haben wir oft über Designdokumente miteinander kollaboriert. Das waren Dokumente, die über die Architektur auf hohem Niveau, Alternativen, Kompromisse und alle ungewöhnlichen Implementierungshinweise sprachen. Es war üblich, mehrere Iterationen dieser Dokumente zu durchlaufen, bevor man sich auf ein endgültiges Design einigte.
Bei Agenten können wir zwar die Zeremonie des Designdokuments überspringen, aber ich sehe oft den Fehler, das Erste zu akzeptieren, was der Agent zurückgibt. Mit pstack können wir stattdessen den Ansatz "Zweimal messen, einmal schneiden" bis zum Äußersten treiben, indem wir parallele Agenten verwenden.
Wir tun dies, indem wir das Prototyping-Playbook verwenden.
In pstack sind Playbooks keine Skills, sondern Referenzdateien innerhalb von /poteto-mode. Diese Playbooks werden (aus Token-Effizienzgründen) bedingt geladen, je nach Art der Aufgabe, an der du arbeitest. Diese 23 Playbooks (Stand 0.15.0) enthalten jeweils einen Workflow, den ich verwende, wenn ich eine Aufgabe erledige.
Im Gegensatz zu Skills werden Playbooks automatisch vom Agenten als Teil von /poteto-mode verwendet. Zum Beispiel:
/poteto-mode prototypisiere ein paar Optionen für das neue Dropdown-Menü /poteto-mode behebe diesen Fehler /poteto-mode evaluiere diese Skill-Änderung
Prototyping ist eines meiner Lieblings-Playbooks von pstack. Es gibt dir mehrere Versuche für ein Ziel und hilft dem Agenten, über die beste Option nachzudenken. Dies ist nicht nur für visuelles Prototyping nützlich, sondern auch für das Prototyping verschiedener Lösungen für Funktionen, Fehlerbehebungen usw.
/poteto-mode prototypisiere ein paar Optionen für <Funktionsanfrage>. Verwende /control-app* und mache Videos/Screenshots, die ich überprüfen und auswählen kann
\ Hinweis: /control-app ist der Verifikations-Skill, den wir in [Teil 1]([https://x.com/poteto/status/2094457600259842065](https://x.com/poteto/status/2094457600259842065)) erstellt haben*
Beim Prototyping visueller Änderungen baut der Agent Wegwerf-Skizzen in deiner App oder in einem Scratch-Verzeichnis. Wenn er eine UI-Interaktion testet, platziert er zwei oder drei Variationen hinter einem einfachen Schalter. Dann steuert er die Interaktion mit dem /control-app-Skill, macht Screenshots von jeder Variante und misst die tatsächliche Zeit oder das Layout.
Prototyping ist Planung, aber mit Code. Es gibt Agenten die Freiheit, den Problemraum zu erkunden, und gibt ihnen die Chance, dich mit etwas zu überraschen, an das du selbst nicht gedacht hättest. Prototypen ermöglichen es Agenten, ihre eigenen Fragen mit empirischen Belegen zu beantworten, anstatt auf meine Eingabe zu warten.
Größere Änderungen architektonisch gestalten
Als Ingenieur im Zeitalter der Agenten ist es wichtiger, meine Zeit mit Architektur zu verbringen, die richtigen Datenstrukturen auszuwählen und darüber nachzudenken, wie die Systeme, die ich baue, zusammenarbeiten werden. Meine Agenten füllen die Implementierungsdetails aus.
Ein weiterer nützlicher Skill, den pstack mitbringt, ist /architect. Er strukturiert das Design in klare, disziplinierte Phasen:
- Das Problem verankern. Der Agent führt /how und /why über die betroffenen Systeme aus, um ein genaues mentales Modell der bestehenden Verantwortlichkeiten und Einschränkungen zu erstellen.
- Skizzieren. Der Agent betritt eine Architektur-Arena. Er startet unabhängige Kandidaten-Runner parallel, oft über verschiedene Modellfamilien hinweg. Jeder Runner erhält die Verankerungs-Briefing und entwirft ein vollständiges Design-Paket: die Nutzungsskizze des Aufrufers, die Kern-Typdefinitionen, die öffentlichen Funktionssignaturen und eine prägnante Begründung. Dies geschieht normalerweise durch das Skizzieren nur der Typ-Signaturen, die sich daraus ableiten, wie wir wollen, dass die Aufrufstellen aussehen. Jeder Runner muss die Schnittstellentiefe bewerten, Fehlermodi bei schwachen Modellen untersuchen und gegen unseren Katalog von Design-Warnsignalen prüfen.
- Gegenseitig bewerten und synthetisieren. Ein gegenseitig bewertender Agent, der ein anderes Modell als der Hauptagent verwendet, bewertet die Kandidaten anhand einer strengen Bewertungsmatrix.
- Gegen die Skizze implementieren. Der Agent ersetzt die Platzhalter-Körper der Skizze durch echte Logik. Wenn der Agent während der Implementierung feststellt, dass eine Funktion unerwartete Parameter oder zusätzlichen Zustand benötigt, meldet er die Diskrepanz.
- Verwerfen, wenn das Design falsch ist. Wenn wir während der Implementierung feststellen, dass die Skizzen falsch waren, wirft der Agent alles weg und beginnt von vorne.
Der Punkt hier ist, dem Agenten eine in sich geschlossene Mini-Schleife zu geben, in der er mehrere konkurrierende Designs aus verschiedenen Modellfamilien zu einem optimalen Ansatz synthetisieren kann, und darauf zu achten, rigoros zu sein und keine Angst zu haben, sein Design zu verwerfen, wenn sich herausstellt, dass die von ihm entwickelte Architektur auf der Grundlage empirischer Beweise falsch ist. Wenn dieselbe Problemumgehung an nicht zusammenhängenden Aufrufstellen auftritt oder wenn die Typen Notluken wie 𝚊𝚗𝚢 oder erzwungene Casts erfordern, ist das ein empirischer Beweis dafür, dass die Architektur falsch ist.
/architect diese neue <Funktionsanfrage>
Die große Lektion hier ist, dass es weitaus effektiver ist, mit Code zu planen, indem man /poteto-mode-Prototyping und /architect verwendet.
Es ist auch der Grund, warum ich mich nie damit abgebe, abstrakte Pläne gegnerisch zu überprüfen. Die Agenten fangen an, über theoretische Risiken zu halluzinieren und komplexe Randfälle zu erfinden, um sich gegen Probleme zu schützen, die nie auftreten werden. Überkoche deine Pläne nicht, wenn sie noch abstrakt sind: Lass den Agenten offene Fragen selbstständig durch Prototyping und die Verifikation seiner eigenen Arbeit beantworten.
Okay, aber ich möchte wirklich ein Planungsdokument
Obwohl pstack nicht mit einem Planungs-Skill kommt, wird es mit einem mehrphasigen Planungs-Playbook ausgeliefert. Ich verwende dies normalerweise, nachdem der Agent ein Design entwickelt hat, mit dem ich zufrieden bin, als eine Möglichkeit, einen taktischen Ausführungsplan zu erstellen.
/poteto-mode verwandle dieses Design in einen Plan
Jede einzelne Aufgabe im Plan ist um Beweis und Verifikation herum strukturiert. Das Playbook sagt den Agenten, dass Tests allein keine ausreichende Verifikation sind. Es ist nur dann verifiziert, wenn es den Code tatsächlich ausgeführt und verifiziert hat, dass er funktioniert.
Jeder Plan wird von einem automatisierten Skript überprüft, das seine Struktur und Formatierung validiert. Nach der Genehmigung wird der Plan Punkt für Punkt ausgeführt. Jeder PR ist klein, in sich geschlossen und leicht zu überprüfen.
Für wirklich große Projekte (wie eines, das mich eine ganze Woche kosten könnte), entscheide ich mich manchmal dafür, die Pläne vorübergehend in der Codebasis zu speichern, damit andere Agenten über die laufende Arbeit informiert sind. Aber ich lösche sie normalerweise, wenn ich fertig bin, damit ich die Codebasis nicht in einem Zustand der Verwirrung hinterlasse. Ich finde es nicht wertvoll, Pläne dauerhaft aufzubewahren.
Der Workflow in der Praxis
Um zu sehen, wie all diese Teile zusammenpassen, gehen wir drei konkrete Beispiele durch, wie ich diese Workflows prompte.
Beispiel 1: Recherche zu einem mehrdeutigen Fehler
Wenn ein Problem in der Produktion auftritt und die Ursache unklar ist:
/poteto-mode untersuche, warum Hintergrund-Worker regelmäßig mit Timeout-Fehlern ausfallen. Gib mir eine Aufschlüsselung dessen, was wir wissen, welche Daten du verwendet hast und deine besten Hypothesen.
Der Agent erkundet den Code, überprüft parallel Metriken und historische Commits und gibt dir seine besten fundierten Vermutungen, wo das Problem liegen könnte.
Beispiel 2: Entwerfen einer neuen Dienstgrenze
Bei der Einführung eines neuen Subsystems, von dem andere Module abhängen werden:
/poteto-mode wir müssen Ratenbegrenzung für externe Webhooks hinzufügen. /architect dies zuerst und beantworte alle offenen Fragen mit Prototypen. Lass mich vor dem Fortfahren überprüfen.
Der Agent verankert die bestehende Webhook-Architektur, startet konkurrierende Design-Runner über mehrere Modelle hinweg, benchmarkt mit Wegwerf-Prototypen und produziert eine saubere, verifizierte Schnittstelle.
Beispiel 3: Ausführen einer Multi-PR-Migration
Bei der Ausführung einer komplexen Umstrukturierung über viele Dateien hinweg:
/poteto-mode erstelle einen Plan, um unsere gesamte UI-Bibliothek auf StyleX zu migrieren. Zerlege die Migration in kleine, verifizierbare PRs. Jeder PR muss seine visuellen Regressionstests und Live-Verifikationsschritte haben. Ich möchte, dass das Endergebnis zu 100 % mit dem Original identisch ist – inklusive Fehler
Der Agent zerlegt die Arbeit in unabhängige Schritte, schreibt eine überprüfbare Checkliste und bereitet jede Einheit so vor, dass sie gebaut, verifiziert und sicher ausgeliefert werden kann.
Beispiel 4: Dinge reparieren, die Leute in Slack melden
Wenn du mich jemals in Slack in einem unserer Issue- oder Feedback-Kanäle gesehen hast, hast du wahrscheinlich diese Klassiker gesehen:
# Thread hat bereits ausreichend Kontext
/poteto-mode mach es
/poteto-mode reproduziere dies mit /control-app. Wenn es auf main reproduzierbar ist, behebe es und zeige mir ein Video als Beweis
Viele der Skills, über die ich hier gesprochen habe, werden bereits automatisch von /poteto-mode verwendet, sodass du in den allermeisten Fällen einfach /poteto-mode verwenden und dein Leben weiterleben kannst!
Die Kunst der Planung
Der Plan-Modus wird oft verwendet, um sich selbst davon zu überzeugen, dass der Agent das Richtige tun wird. Aber die Realität ist, dass abstrakte Pläne dir nur die Illusion von Fortschritt geben. Ein langer und ausführlicher Plan lässt es so aussehen, als ob du und dein Agent sehr produktiv wart, aber es fehlt ihm wahrscheinlich an Substanz.
pstack gibt dir Werkzeuge, um gründliche Untersuchung, empirische Beweise und rigorose Verifikation zu kombinieren. Wenn du auf diese Weise planst, fühlt sich die Arbeit mit Agenten nicht mehr wie ein Glücksspiel an. Sie wird vorhersagbar und wiederholbar.
https://x.ai/bot/plugin/9717366
Danke fürs Lesen, und bleib dran für Teil 3!
