🧵 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....