Opus 4.5 ist völlig anders als alle AI-Agenten, die ich bisher erlebt habe

• Claude Opus 4.5 zeigt im Gegensatz zu bisherigen AI-Coding-Agenten ein Maß an autonomer Entwicklungsfähigkeit, mit dem es auch ohne Eingriffe von Entwicklern ausgereifte Anwendungen erstellen kann
• Von einem einfachen Windows-Dienstprogramm zur Bildkonvertierung bis hin zu Tools für Videoaufnahme und -bearbeitung, AI-basierte Apps zur automatisierten Veröffentlichung von Posts sowie Apps zur Bestellverfolgung und Routenberechnung wurden in kurzer Zeit tatsächlich funktionsfähige Projekte fertiggestellt
• Opus 4.5 übernimmt komplexe Entwicklungsaufgaben wie die Konfiguration eines Firebase-Backends, die Analyse von Fehlerlogs und automatische Korrekturen sowie die Einrichtung von Deployments mit GitHub Actions eigenständig
• Der Autor gibt an, die Codestruktur nicht vollständig zu verstehen, bestätigt aber, dass Opus 4.5 Bugs selbstständig behebt und sogar Refactoring-Vorschläge macht
• Diese Erfahrung unterstreicht, dass die Möglichkeit, dass AI Entwickler vollständig ersetzen könnte, real geworden ist, und markiert einen Wendepunkt im Zeitalter AI-zentrierter Entwicklung

---

Das Erscheinen von Opus 4.5 und der Unterschied zu bisherigen AI-Agenten

• Frühere AI-Agenten litten oft unter ineffizient generiertem Code und wiederholter Fehlerkorrektur, was die Produktivität verringerte
  • Nach vielfachem Kopieren, Einfügen und Beheben von Fehlern wurde die Codebasis häufig beschädigt
• Opus 4.5 überwindet diese Probleme, schreibt von Anfang an den Großteil des Codes korrekt und wiederholt bei Fehlern direkt über die CLI Build- und Korrekturläufe
• Der Autor bewertet es als „das Modell, das das Versprechen von AI Coding tatsächlich eingelöst hat“

Projekt 1 – Windows-Dienstprogramm zur Bildkonvertierung

• Opus 4.5 erstellt auf eine einzige Anfrage hin ein Dienstprogramm mit Bildformat-Konvertierung im Rechtsklick-Menü des Windows-Explorers
  • Mit der dotnet CLI wurden Build- und Fehlerkorrekturprozesse automatisiert
  • Nur XAML-Fehler wurden in Visual Studio geprüft, kopiert und weitergegeben
• Zusätzlich wurden eine Website für die Distribution, ein PowerShell-Installationsskript und eine automatische Deployment-Pipeline mit GitHub Actions eingerichtet
• Für das Logo wurde Figma AI verwendet, während Opus die SVG-Konvertierung und Skripte für Icon-Formate schrieb

Projekt 2 – Tool für Bildschirmaufnahme und Bearbeitung

• Beginnend mit einem GIF-Aufnahme-Tool ähnlich LICEcap wurde es um Funktionen zur Video- und Bildbearbeitung erweitert
  • Bearbeitungsfunktionen wie Formen hinzufügen, Zuschneiden und Unschärfe anwenden wurden innerhalb weniger Stunden umgesetzt
• Der Quellcode ist auf GitHub veröffentlicht, und der Autor erwähnt, dass er „innerhalb weniger Stunden ein beachtliches Niveau erreicht“ habe
• Es wurde bestätigt, dass Opus 4.5 nicht nur die UI, sondern auch Backend-Integrationen umsetzen kann

Projekt 3 – AI-App zur automatisierten Veröffentlichung von Posts

• Mit Opus 4.5 wurde eine AI-basierte Mobile-App entwickelt, die automatisch Beiträge auf einer Facebook-Seite veröffentlicht
  • Nach dem Hochladen eines Fotos übernimmt die AI die Erstellung von Captions und das zeitgesteuerte Veröffentlichen
  • Firebase-Backend, Authentifizierung, Storage und Cloud Functions wurden von Opus direkt über die CLI eingerichtet
• Der Autor beschreibt, dass Opus die App fertiggestellt habe, während er Jalousien montierte
• Opus analysierte Fehlerlogs automatisch und behob sie, außerdem erstellte es ein Dashboard für die Verwaltung
• Eine Arbeit, die früher mehrere Monate gedauert hätte, wurde innerhalb weniger Stunden abgeschlossen

Projekt 4 – App zur Bestellverfolgung und Routenberechnung

• Durch das Parsen von Bestell-E-Mails in Gmail werden Termine, Routen, Fahrzeiten und Fahrtenbücher für Steuerzwecke automatisch berechnet
• Opus 4.5 übernahm die Integration der Google-Authentifizierung und die Firebase-Anbindung in einem Schritt
• Der Autor bewertet es mit den Worten, Opus habe „eine Aufgabe, die manuell quälend wäre, perfekt erledigt“

Verständnis des Codes und Qualitätsfragen

• Der Autor erwähnt, dass die App trotz fehlender Swift-Kenntnisse perfekt funktioniert
• Opus 4.5 findet und behebt Bugs selbstständig, sodass die Entwicklung auch ohne Verständnis der internen Codestruktur problemlos voranschreitet
• Zur Frage nach der Codequalität heißt es, dass „menschliche Lesbarkeit nicht wichtig ist, wenn der Code von AI gelesen und gewartet wird“
• Mit einem AI-spezifischen Coding-Prompt in VS Code wird Code erzeugt, der sich an Strukturen orientiert, die für LLMs leicht verständlich sind

Prinzipien des AI-zentrierten Codings

• Die Prompts gehen davon aus, dass es sich um „Code handelt, der von AI geschrieben und gewartet wird“
  • Betont werden einfache Strukturen, klare Einstiegspunkte, minimale Abstraktion und geringe Kopplung
  • Wichtig sind explizite Kontrollflüsse, einfache Funktionen, strukturiertes Logging und leichte Regenerierbarkeit
• Beim Refactoring dokumentierte Opus Verbesserungspunkte nach Priorität (hoch/mittel/niedrig)
• Bei Sicherheitsprüfungen wurde darum gebeten, API-Keys, Login-Verarbeitung und die Speicherung sensibler Daten zu überprüfen
  • Zur Vollständigkeit der Sicherheit merkt der Autor an, man liege „erst bei etwa 80 % und es fühlt sich noch unsicher an“

Der Wandel im Zeitalter der AI-Entwicklung

• Der Autor beschreibt die Realität, „dass man so etwas in wenigen Stunden bauen kann“, als eine Mischung aus Begeisterung und Leere
• Früher habe er geglaubt, „AI könne Entwickler nicht ersetzen“, inzwischen könne er diese Möglichkeit nicht mehr bestreiten
• Abschließend betont er, man solle im AI-zentrierten Entwicklungsumfeld nicht zögern, sondern selbst etwas bauen
• Zum Schluss warnt er: Für das Management von API-Keys muss man weiterhin selbst Verantwortung übernehmen

---

Zusammenfassung: Opus 4.5 wird nicht mehr nur als einfacher Code-Assistent gesehen, sondern als ein Modell auf dem Niveau eines AI-Entwicklers, das vollständige Anwendungen autonom entwerfen, implementieren und deployen kann. Der Autor erklärt, dass er dadurch die reale Möglichkeit, dass AI menschliche Entwickler ersetzen könnte, unmittelbar selbst erlebt habe.

[wegaia]

Als ich Opus 4.5 bat, eine einzige Zeile Code zu korrigieren, sah ich, dass es eigenmächtig etwa zehn Zeilen Konfigurationscode darüber gelöscht hatte. Als ich fragte, warum es das entfernt habe, sagte es einfach, der Code habe wohl keine Bedeutung und sei deshalb gelöscht worden..

[GN⁺]

Hacker-News-Kommentare

• Die Arbeit, die Ingenieure auf mittlerem Niveau übernehmen, besteht nicht einfach darin, eine neue App zu bauen, sondern darin, eine Struktur zu entwerfen, die Skalierbarkeit und Verständlichkeit berücksichtigt
  Opus 4.5 verarbeitet Anfragen auf dem Niveau von „bau mir eine App“ gut, aber wenn man wie in der realen Arbeit versucht, einem bestehenden Code neue Funktionen hinzuzufügen, verwendet es seltsame Abstraktionen oder man muss mehrfach nachbessern, um die gewünschte Qualität zu erreichen
  Nicht-Techniker denken vielleicht „solange es funktioniert, reicht das“, aber Ingenieure wissen, dass das nicht genügt

  • Es gibt zwei Arten des „richtigen Wegs“ — den zum Kontext passenden Weg und den Weg, in dem Ingenieure verallgemeinernd denken
    Ich erinnere mich daran, wie wir im Team früher über die „richtige Antwort“ gestritten haben. Am Ende musste jemand von außen kommen und uns daran erinnern, was aus Geschäftssicht wichtig war
    Manchmal ist der wirklich „richtige“ Weg, etwas auch unsauber schnell zu bauen, um zu prüfen, ob die Richtung stimmt
    Das Problem entsteht, wenn man von Anfang an überdesignt oder wenn umgekehrt Manager Refactoring verhindern. Am Ende ist Balance der Schlüssel
  • Wenn ich solche Projekte sehe, denke ich, man könnte doch einfach einen Bildkonverter oder Minesweeper-Klon von GitHub forken; dass das unbedingt ein LLM machen muss, wirkt nur wie ein Mittel zur Entfernung von Urheberrechten
  • Manche behaupten, „Codequalität ist jetzt nicht mehr wichtig“. Hauptsache, die Tests laufen heute; wenn morgen ein vollständiges Refactoring nötig ist, gibt man eben mehr Credits aus und baut es in ein paar Stunden neu
  • Ich war überrascht, wie gut Opus 4.5 den idiomatischen Mustern einer bestehenden Codebasis folgt
    Wenn man explizit anweist, den benachbarten Code zu lesen, funktioniert es deutlich besser. Schon ein oder zwei zusätzliche Sätze reichen aus
  • Wenn man beim Hinzufügen von Funktionen zu bestehendem Code die gewünschte Abstraktion direkt vorgibt, funktioniert es schrittweise gut
    Trotzdem bevorzuge ich persönlich GPT‑5.2

• Viele Ingenieure unterschätzen die aktuelle Leistung von LLM-Agenten wie Claude Code
  Unser Team hat mit Claude Code Code-Reviews, ESLint-Automatisierung, PR-Checklisten, Dokumentationssynchronisierung und Prüfungen der Testabdeckung automatisiert
  Auch die Ticket-Klassifizierung läuft automatisch, sodass die Hälfte der Arbeit schon erledigt ist, bevor ein Ingenieur überhaupt anfängt
  Ein Beispiel-Repository gibt es unter claude-code-showcase
  Ich bin überzeugt, dass das um 2026 zum Standard-Workflow der Branche wird

  • Zwischen Frontend (React, HTML, Mobile) und Low-Level-Bereichen (OpenGL, io_uring, libev usw.) gibt es große Unterschiede bei der Nutzungserfahrung mit LLMs
    Opus 4.5 baut gute JS-Apps, aber wenn man es bittet, einen Schattenalgorithmus aus einem Paper von 2003 in C++ zu implementieren, ist das Ergebnis völlig chaotisch
    Selbst wenn man ihm Fabien Sanglards Review zum Doom3-BFG-Threading gibt, kommt nur nutzloser Code heraus
    Am Ende gilt: „Wir unterschätzen LLMs nicht — wir warten nur, weil sie noch nicht praktisch genug sind“
  • Viele haben AI-Coding früh ausprobiert und wegen Fehlern und Frustration wieder aufgegeben
    Aber Opus 4.5 ist eine Stufe höher. Es macht viel weniger Fehler, und die meisten sind nur Kleinigkeiten
  • Ich unterrichte Studierende an der Universität und habe Cursor, Claude Code und Codex ausprobiert,
    und dank AI habe ich ein Projekt, das zwei Wochen gedauert hätte, in 5 Stunden fertiggestellt.
    Ohne AI hätte ich es gar nicht erst versucht
  • Es ist schon komisch, in einem von AI erzeugten README extra die Verzeichnisstruktur aufzuschreiben. Mit dem Befehl tree sieht man das ohnehin
  • Ich glaube, der Beruf „Programmierer“ selbst wird künftig kleiner, und die Fähigkeit, mit Werkzeugen kreativ zu arbeiten, wird wichtiger

• Ich habe Opus 4.5 viel benutzt; für komplexe Codeanalyse ist es hervorragend, aber es hat immer noch keine Problemlösungsfähigkeit auf menschlichem Niveau
  Es erkennt zum Beispiel einen Graph-Layout-Algorithmus korrekt, kann dessen Fehler aber nicht selbst beheben
  Für Codeanalyse und Wissensanreicherung ist es großartig, aber für komplexe Problemlösung reicht es noch nicht

  • Copilot hat Grenzen, weil es den Kontext zur Token-Einsparung abschneidet
    Wenn man echte Leistung will, muss man die API direkt nutzen, und ein einzelner PR kann dann dreistellige Kosten verursachen
    Siehe: models.dev
  • Dass Copilot bei der Nutzung von Opus 4.5 Tokens dreifach zählt und ich die Hälfte meines Monatskontingents in einer Woche verbraucht habe, war erstaunlich
  • Selbst wenn man AI nur als Codeanalyse-Tool nutzt, ist sie wertvoll
    Auch bei der Dokumentation ist sie oft besser als Menschen und hat tendenziell eine geringere Fehlerrate
  • Über Drittanbieter-Tools verhält es sich anders
    Ich empfehle, es mit einem Claude-Code-Abo direkt in VS Code oder Cursor zu verwenden

• Über die Feiertage habe ich mehrere Projekte mit GPT‑5.x gemacht —
  Swift-Automatisierungstools, ARM-JIT-Engine-Integration, Synthesizer-Prototypen usw.
  GPT‑5.2 und die Codex-Reihe sind so leistungsfähig wie Opus und können sogar den gesamten CI-Workflow auf einmal aufsetzen
  Für jemanden wie mich, der Gewohnheiten beim Planen und Überprüfen von Code hat, ist das ein Produktivitäts-Multiplikator

  • GPT‑5.2 hat oft die Existenz oder Funktion von CLI-Utilities halluziniert
    Ich musste im tatsächlichen Source Code nachsehen, um die Fehler zu bestätigen
  • Auch Gemini 3 Pro (High) und Tools wie Antigravity, Amp und Junie waren beeindruckend
    Ich habe in zwei Wochen eine Ratatui-Binding-Bibliothek für Ruby fertiggestellt
    Antigravity lässt mehrere Agenten parallel laufen und übernimmt Kontextkompression und automatisches Management
    Solche fortgeschrittenen Tools bieten eine völlig andere Erfahrung als die kostenlosen Versionen
    Zusammen mit Unix-Tools und der git-CLI lässt sich der Kontext klein halten und die Effizienz maximieren
  • LLMs sind stark bei Backend- und CLI-Code, aber in Bereichen, die visuelles Feedback erfordern, wie HTML/CSS oder JS-Frontend, immer noch schwach
    Bei strukturierten Ein- und Ausgaben sind sie stark, bei Dingen, die ein „sensorisches Finish“ brauchen, scheitern sie

• Mir ist aufgefallen, dass die negativen Kommentare zu LLMs auf HN zuletzt stark zurückgegangen sind
  Die meisten geteilten Projekte bleiben aber auf dem Niveau von Tech-Demos stehen
  Kontext aufzubauen, also Nutzeranforderungen zu verstehen, bleibt weiterhin die Aufgabe des Menschen
  Man kann an einem Wochenende mehrere Apps bauen, aber es gibt kaum jemanden, der sie wartet

  • Dass negative Kommentare weniger werden, könnte auch daran liegen, dass die Leute die sich ständig wiederholenden Debatten über „das neue Modell ist 1000-mal besser“ leid sind
  • Es kann auch sein, dass Leute, die monetarisierbare Produkte bauen, still entwickeln und deshalb nichts teilen
  • Deployment in Produktion und Wartung erfordern enormen Aufwand
    Karpathy hat Ähnliches berichtet — Prototypen sind leicht, Deployment ist schwer
    Bei persönlichen Tools reicht es oft, eher problemorientiert als perfektionistisch vorzugehen
  • Je mehr Menschen AI nutzen, desto häufiger bleiben sie an den letzten 20 % hängen, wo integratives Denken nötig ist
    Wenn man das Denken an AI delegiert, wird die eigene Fähigkeit zu denken schwächer
  • Auch in der Spieleentwicklung gilt weiter die 80/20-Regel
    Ideen lassen sich schnell testen, aber bis zu einem ausgereiften Produkt braucht es weiterhin menschliche Ausdauer

• Bei Opus 4.5 hat sich weniger das reine Wissen verbessert als vielmehr die autonome Problemlösungsfähigkeit
  Klar definierte Probleme hat es fast alle gelöst, sogar Reverse Engineering hat es übernommen
  In letzter Zeit schreibe ich weniger selbst Code, sondern verfasse Spezifikationen und steuere dann, wie Opus ausführt und verbessert

  • Als veröffentlichte Beispiele gibt es coding-agent-benchmark und
    das C64-Game-Reverse-Engineering-Projekt
  • Mich würde interessieren, wie man Überdesign verhindert
  • Ich nutze die Claude-Web-App effizient zum Rubber-Duck-Debugging
    Claude Code ist mächtig, weil es die gesamte Codebasis sehen kann, aber es verbraucht das Kontingent viel zu schnell
    Deshalb bin ich wieder zur Webversion zurückgekehrt
  • Ich gehe bei Side Projects in letzter Zeit fast genauso vor

• Mit Opus 4.5 habe ich sogar einen JavaScript-Interpreter auf Python-Basis, eine WebAssembly-Runtime und die C-Portierung einer Rust-String-Suchroutine ausprobiert
  Ich habe das meiste auf dem Smartphone getestet, und die Ergebnisse waren erstaunlich

  • Wenn der „in Python geschriebene JS-Interpreter“ auf Bellards MQJS basiert, sollte die Quelle angegeben werden
    Siehe: micro-javascript
  • Bei Problemen, die visuelles Schlussfolgern brauchen, etwa beim Slime-Mold-Path-Algorithmus, ist es weiterhin schwach
  • Mich interessiert das Ergebnis von „eine Rust-Routine nach C portiert und dadurch schneller gemacht“
  • Ich habe gesagt: „Schreib einen Python-3-Interpreter in JavaScript“, und ich war überrascht, dass sogar die Tests bestanden wurden
  • In letzter Zeit spüre ich aber keinen großen Unterschied mehr. Die Modelle stagnieren, stattdessen entwickeln sich die Agent-Frameworks weiter
    Beispielvideo: Mastodon-Link

• Der eigentliche Grund, warum Entwickler eingestellt werden, ist Verantwortung
  Schon in der Zeit, als man Code von StackOverflow oder GitHub kopierte, gab es Werkzeuge,
  aber wenn Probleme auftreten, ist am Ende immer ein Mensch verantwortlich

  • Heute ist die Person, die Verantwortung übernehmen kann, die wichtigste Figur
    Wenn ein verlässlicher Kollege bereit ist, seinen Namen unter AI-Code zu setzen, ist das okay
  • Die Branche belohnt aber eher Menschen, die Neues schaffen, als Verantwortung
    Wartung wird vernachlässigt
  • Code-Review in Echtzeit wird jetzt zum Standardmodus
    Ich habe am Wochenende 80 % eines SaaS mit AI gebaut und nur den Kern selbst geschrieben
    Als ich eine vor 22 Jahren geschriebene Sprachspezifikation eingefügt habe, hat Opus in 3 Minuten Parser und Tests fertiggestellt
    Wir sind jetzt an einem Punkt, an dem wir uns wie in der Bergbauindustrie an Veränderungen anpassen müssen
  • Deshalb nutze ich AI lieber als Editor und Reviewer statt als Autor
    Den Code schreibe ich, und AI übernimmt Problemsuche und Testvorschläge

• Opus 4.5 hilft mir gerade dabei, eine neue Programmiersprache zu entwickeln
  Wir diskutieren sogar Low-Level-Implementierungen und arbeiten zusammen wie beim Pair Programming
  In großen Codebasen braucht es aber weiterhin menschliche systemische Kontrolle
  Sonst ändert Opus die Spezifikation oder kleistert alles mit Workarounds zu
  Das ist kein Allheilmittel, aber es könnte das produktivste Jahr meines Lebens werden
  Gleichzeitig hoffe ich, dass mit der Verbreitung solcher Technik auch kleine Web-Communitys wieder aufleben

  • Vielleicht wird AI eines Tages ihren eigenen Code selbst warten,
    aber bis dahin halte ich für Menschen leicht verständliche Sprachen für wichtiger
  • Es gibt auch die skeptische Sicht: „Hat es überhaupt Sinn, so etwas zu bauen?“
  • Es gab auch scherzhafte Reaktionen wie: „Wer soll diesen Roman denn kaufen?“

• Ich habe Opus 4.5 die Aufgabe gegeben, das gesamte Projekt zu verbessern, und bekam eine absurde Architektur und unzählige Bugs zurück
  Für Tests oder Bug-Erkennung ist es hervorragend, aber wenn man ihm das Design der Gesamtstruktur überlässt, bereut man es

  • Stattdessen ist es effizienter, zu sagen: „Schlag Verbesserungsideen vor“, dann die guten auszuwählen und sie nach einer Erklärung durch Claude umsetzen zu lassen
  • Am besten funktioniert es, wenn man genau weiß, was verbessert werden soll
    „Verbessere einfach irgendetwas“ ist der schlechteste Prompt
  • Solche Fälle sind ein gutes Beispiel für die Schwächen des Modells
    Früher gab es auch einen Fall, in dem jemand einen Agenten über Nacht verbessern ließ und am Ende 100.000 Zeilen Müllcode bekam
    Deshalb ist planbasierte Entwicklung wichtig
    Siehe: The Highest Quality Codebase
  • Die meisten Modelle, auch Opus, sind schwach bei der Verbesserung vorhandenen Codes, aber gut beim Schreiben neuen Codes
  • 90 % der Code-Review-Vorschläge von AI sind nutzlos, aber die übrigen 10 % finden echte Probleme
    Es wirkt fast so, als könnte sie endlos weitere Änderungsvorschläge machen