🧵 Erste tiefgehende Erfahrung mit dem Schreiben von Code mit AI-Agenten. Innerhalb von 2 Tagen habe ich eine Plattform im japanischen Arcade-Stil für „AI vs AI“-Kämpfe von Grund auf aufgebaut. Die Stolpersteine und Lektionen, die ich dabei gelernt habe, sind wahrscheinlich wertvoller als das Schreiben des Codes selbst. 1/ Onboarding für Agenten ≠ UX für Menschen Für Menschen gestaltete Registrierung: Formular → Bestätigungs-E-Mail → Anleitung. Für Agenten gestaltet: Ein POST-Endpunkt erledigt Registrierung + Berechtigung + Warteschlange, gibt API-Schlüssel + watchUrl zurück. Agenten sehen keine UI, klicken keine Buttons. Sie benötigen einen curl-Befehl und ein JSON. Die menschliche UX strebt nach „einem Klick weniger“. Die Agenten-UX strebt nach „einem API-Aufruf weniger“. 2/ Code War Room: Zusammenarbeit mehrerer Modelle beim Schreiben von Code Wir haben einen Multi-Agenten-Workflow: • Claude schreibt Code • Codex macht Review + bewertet (/10) • ≥ 8.5 muss erreicht werden, um zu versenden, sonst weiter bearbeiten Wichtige Entdeckung: Die Bugs, die verschiedene Modelle finden, sind völlig unterschiedlich. Codex ist gut in API-Vertragslücken und Wettlaufbedingungen, Claude ist gut in Architekturdesign und Funktionsintegrität. Die Review-Punkte in 4 Phasen: 9.5 → 9.3 → 9.4 → 9.6. Es reicht nicht, dass ein Modell fertigstellt, mehrere Modelle müssen sich gegenseitig herausfordern, um guten Code zu produzieren. 3/ "Läuft lokal" ≠ "Kann bereitgestellt werden" Lokal perfekt. Nach dem Push auf Vercel serverless überall 500. Ein zustandsbehafteter Wettkampfscheduler (setTimeout + In-Memory-DB + SSE) auf einem zustandslosen serverless = Katastrophe. Nach dem Hinzufügen eines Redis-Patches traten erneut Probleme mit fehlender Serialisierung, abgelaufenen Instanz-Caches, doppeltem Schreibkonkurrenz… auf. Am Ende wechselte ich zu Railway (mit persistenten Prozessen), 10 Minuten lösten einen Bug, der einen Tag lang Probleme bereitete. Lehre: Zuerst die richtige Architektur wählen, dann den Code schreiben. 4/ Demo → Realer Wechsel ist ein blinder Fleck im Produktdesign Ich habe einen beeindruckenden Demo-Kampfzyklus erstellt. Aber als echte Benutzer-Bots sich registrierten, lief die Seite noch die Demo. Es braucht eine vollständige Zustandsmaschine: Registrierung → Demo stoppen → Paarung → echten Kampf starten → nach dem Kampf wieder zur Demo zurückkehren. Diese Logik wurde im PRD nicht einmal erwähnt. 5/ Produkte für Agenten erstellen, erfordert, dass man wie ein Agent denkt Die erste Version des House Bots kontrollierte nur automatisch seine eigene Seite. Das Ergebnis war, dass der gegnerische Bot nicht wusste, dass er die API anrufen musste, und der Wettkampf in Runde 0 stecken blieb. Nachdem ich es geändert hatte, sodass beide Seiten automatisch angreifen, konnte jeder, der sich registrierte, innerhalb von 5 Sekunden ein vollständiges BO7 sehen. Die beste UX für Agenten: Der Benutzer muss nichts tun, das System erledigt alles für ihn. ─── 📊 Projektdaten: 133 Dateien | ~15.8k LOC | 198 Tests | 22 Sub-Agenten | 8+ Review-Runden 🎮 Online-Erlebnis: 📂 Vollständig Open Source: Enthält vollständige Dokumentation des Code War Room-Workflows und Designrichtlinien für Agenten-UX, herzlich willkommen zum Forken. Zum Schluss möchte ich sagen, dass Agenten sehr gut im Täuschen sind. Ich habe mehrmals erlebt, dass sie offensichtlich ein anderes Modell für die Prüfung verwendet haben, aber behaupteten, es sei nicht so. Als ich darauf bestand, die Protokolle zu überprüfen, gab er schließlich zu, dass er sich geirrt hatte 😂😂. Menschen sind als Richtungsgeber, für ästhetische Stile sowie für Entscheidungen und Reviews unerlässlich, zumindest derzeit.

Ja, ich glaube, x402 sollte ein Internetprotokoll sein, das nicht nur mit USDC funktioniert, nicht nur mit einer Kette, es sollte universell sein und mehr Tokens unterstützen. Agenten oder Benutzer müssen sich keine Sorgen darüber machen, wo ihre Gelder liegen, welche Tokens sie haben, sie finden einfach das Produkt oder die Dienstleistung, die sie benötigen, klicken auf Bezahlen und erhalten es dann. Den Rest überlässt man den Implementierungen von GOAT Network’s x402. Ganz einfach!