Astra fürs Programmieren: Warum tun wir uns das noch einmal an?
Astra for Coding: Why Are We Doing This Again?
Armin Ronacher testete GPT-6 Astra in einer autonomen "Software-Fabrik" und verbrannte dabei rund 4 Milliarden Token. Das Ergebnis: kein brauchbarer Code, aber ein Modell, das mit absurden Python-Einzeilern C-Code patcht, Node.js über PowerShell fernsteuert und selbst generierte Unit-Tests ohne Einrückung abliefert. Seine Vermutung: Das Training belohnt Token-Effizienz und Aufgabenabschluss, bestraft aber miserablen Code kaum – ein Fall von Neijuan.
Ich bin immer mehr davon überzeugt, dass das gesamte AI-Engineering Neijuan ist.
- taurath
Wenn der Code scheiße ist, wird es für die Modelle immer schwieriger, Änderungen vorzunehmen, und das bremst den Fortschritt bis zum Stillstand aus – das ist meine Erfahrung mit „Fabriken“, die das ausprobiert und alle paar Monate Verfeinerungsschritte unternommen haben.
Ich verstehe aufrichtig nicht, was die Leute tun, die sagen, sie lesen keinen Code mehr, denn es muss einigermaßen trivial sein, nicht direkt in diese Probleme zu laufen, die sich immer wieder auftürmen – dann sagen die Leute, man solle einfach besser prompten, und dann hätten sie dieses Problem nicht, aber ich schaue mir den Code genau dieser Leute an, und er ist grauenhaft, und dann stelle ich fest, dass sie nicht weit über eine Proof-of-Concept-Phase hinausgekommen sind. Ich sehe ganze Teams auf ein Kriechen verlangsamen und nicht in der Lage sein, mit Änderungen oder Produktionsvorfällen umzugehen. Das scheint bei vielen Leuten, mit denen ich spreche, üblich zu sein.
Ich persönlich denke, die Befürworter müssen liefern oder den Mund halten – die Versprechungen gehen viel zu weit. Jede einzelne Person, die ich als starken Verfechter dieser Techniken gesehen habe, hat sowohl nahezu unbegrenzte Tokens zur Verfügung als auch scheinbar das Geschäft, eine Lösung zu verkaufen. Ich kann kaum Ingenieure finden, die nicht gerade etwas vermarkten und mit diesen Techniken in Produktionssystemen erfolgreich sind, es sei denn, sie sind recht einfach oder erledigen eine sehr spezifische Aufgabe aus einer ausgereifteren Codebasis.
- nojs
Das deckt sich bisher auch mit meiner Erfahrung mit Astra.
> Ich vermute, dass im Trainingsprozess etwas „schiefgeht“. Das Modell wird stark dafür belohnt, bei Long-Horizon-Aufgaben erfolgreich zu sein, aber vermutlich gibt es kaum Bestrafung für „scheiß Code“.
Meine Vermutung ist, dass sowohl OpenAI als auch Anthropic in den letzten Monaten ihre RL-Agenda von „als nützlich bewertet gemäß menschlichem Feedback“ auf „erfolgreich bei Long-Horizon-Aufgaben“ umgestellt haben, was zu Agenten führt, die im Sinne autonomer Aufgabenerfüllung näher an AGI sind, aber seltsamerweise schlecht in der Kommunikation.
Das Ergebnis ist, dass sie erstaunlich gut bei Long-Horizon-Aufgaben, Computernutzung und dem Lösen schwieriger Mathe-/ARC-AGI-artiger Probleme sind, aber immer seltsamer im Umgang werden.
- specproc
> Ich bin mehr und mehr überzeugt, dass das gesamte AI-Engineering Neijuan (内卷, was „nach innen rollen“ bedeutet) ist. In China beschreibt es ein System, das immer mehr Anstrengung und Wettbewerb verlangt, ohne den Output zu verbessern. Die Art und Weise, wie es manchmal im Westen auftaucht, ist der 996-Unsinn. Der englische Begriff für Neijuan ist „Involution“ aus dem Buch Agricultural Involution. Agricultural Involution beschreibt die Intensivierung der Landwirtschaft, die die Produktivität pro Quadratmeter erhöht, während die Produktivität pro Kopf unverändert bleibt.
Das resoniert
- codingisfreedom
Ich habe Astra gebeten, mir eine App für einen Prototyp zu bauen, den ich schnell mit Sonnet erstellt habe.
Es sind 2 Tage vergangen und es hat keine wirklichen Fortschritte bei der eigentlichen App gemacht. Es hat Docs, Skripte, Workflows erstellt und macht bei jedem PR eine Menge Reviews.
Ich habe ihm gesagt, dass ich nur ein MVP brauche.
Ich bin mir ziemlich sicher, dass ein durchschnittlicher Senior Engineer diese Aufgabe viel schneller erledigt hätte, und garantiert mit lesbarerem, hochwertigerem Code. In der Zwischenzeit habe ich, glaube ich, locker 100k Tokens für nichts verbraucht.
Lustige Welt, in der wir leben, dass das „SOTA“ und „AGI“ sein soll.
Ich bin wirklich neugierig, woran diese OAI- und A/-Ingenieure arbeiten, dass sie diese Modelle so sehr loben. Ich habe seit Opus 4.5 keine Verbesserung gesehen.
Außerdem bin ich von jeder „One-Shot“-Demo da draußen wirklich unbeeindruckt. Sie bedeutet nichts für ernsthaftes Software-Engineering.
- buildbot
Ich habe genau diese Muster auch bei Opus und Fable beobachtet – zum Beispiel vergessen sie, dass sie Dateien bearbeiten können, und verwenden stattdessen Python-Skripte als Patch-Werkzeug …
- gps372
Eine frühe Lektion, die ich aus dem AI-Engineering gelernt habe, war: Es gibt keinen Ersatz dafür, einem Agenten ein gut vorbereitetes Epic zu geben. Statt einfach zu sagen „implementiere Themes in meinem Produkt“, muss man spezifisch sein, sogar spezifischer als sonst. Man muss genau sagen, was im Scope ist und was nicht, bis hinunter zu Buttons, Events und Layouts.
Man kann das Epic mit Hilfe von AI vorbereiten, aber die endgültige Überprüfung muss von jemandem durchgeführt werden, der die Verantwortung für die Spezifikationen übernehmen kann und daher verantwortlich ist, wenn etwas durch die Maschen gefallen ist. Die Antwort von AI wird durch die Output-Tokens des jeweiligen Agenten begrenzt sein, und es wird keine Konsequenzen für AI geben, selbst wenn es seine Fehler akzeptiert.
- _usefulcat
Ich möchte meinen Gegenpunkt einreichen. Ich arbeite an einer etablierten Codebasis, baue neue Features und behebe Bugs. Sie hat Zugriff auf unser Storyboard, Git und ein paar andere MCPs. Solange die Story gut geschrieben ist mit klaren Anforderungen und Erwartungen, produziert sie immer qualitativ hochwertigen Code, den ich als Mensch mit verschiedenen automatisierten und manuellen Tests validiere. Ich mache Peer-Review des Codes. Meine Kollegen machen dann ebenfalls Peer-Review.
Ich habe zwei Dinge bemerkt: Neue Features dauern mindestens die Hälfte der Zeit, die ich früher gebraucht habe, und Bugs treten viel seltener auf. Noch schneller beim Bugfixing.
Mein Fazit ist, dass man solide Anforderungen, klaren Kontext und sorgfältige menschliche Aufsicht braucht, vor allem während der Planung, aber auch während der Verifikation.
- juancn
Alles Scheißige, das ins Kontextfenster gelangt, verschiebt das Ganze in Richtung Scheißigkeit.
Bisher ist das meine Erfahrung mit so ziemlich jedem Modell.
Der Kontext nährt sich von seinem Output.
Sobald es diesen Weg einschlägt, degeneriert es immer weiter, es sei denn, man stoppt es und gibt ihm genügend Gegenbeispiele und Details dazu, was man will (d. h. man schubst es im latenten Raum in Richtung einer besseren Stelle).
Es wird noch schlimmer, wenn das Kontextfenster komprimiert wird, bevor man die Chance hat, zu korrigieren.
Long-Horizon-Agenten können sich mit Maschinengeschwindigkeit degenerieren.
Ich denke immer noch, dass man viel bessere Ergebnisse erzielt, wenn man ihnen kurzfristige, gut spezifizierte Aufgaben gibt.
- Gigachad
Ich habe dasselbe beobachtet: Die neuen Modelle wollen obszöne Bash-Befehle oder Python-Skripte ausführen, die völlig unlesbar sind und jedes existierende Optionsflag nutzen.
Es ist unmöglich, das zu reviewen. Diese Befehle sind weniger lesbar als Regex.
- AmazingTurtle
gpt-6-astra ist eine Zicke, es betreibt ständig Scope Creep mit „noch einer Sache“, um diesen verdammten letzten Schliff zu geben. Die Ergebnisse sind schließlich ein bisschen besser, aber zu welchem Preis? Rechnen wir mal nach.
gpt-5.6-sol: 1x Basis
gpt-6-astra: 2,5x Basis im Abo
dann neigt gpt-6-astra dazu, häufig Subagenten zu spawnen, oft mit allen möglichen Modellen wie gpt-5.6, 5.3-codex usw., was nett ist. Es ist ein guter Koordinator, aber noch mehr Kosten.
und dann neigt es dazu, _vollständige Testsuiten_ immer und immer wieder laufen zu lassen (jede dauert etwa 15 Minuten), nur um zu verifizieren, dass _ein Test_ behoben wurde usw., und das so lange, bis der Test behoben ist, was sich schließlich auf etwa 2 Stunden summiert.
gestern habe ich ihm die Aufgabe gegeben, meine Änderungen in einem Repo auf die neuesten Upstream-Änderungen zu rebasen. Während gpt-5.6-sol dafür konsistent etwa eine Stunde von Anfang bis Ende brauchte, lief astra mehr als 6 Stunden und war immer noch nicht fertig. Es fand ständig „noch eine Sache“, die Goldplating war und die ich nicht verlangt hatte.