Coding-Agenten haben alle Frameworks ersetzt, die ich benutzt habe
(blog.alaindichiappari.dev)„Software Engineering ist zurück“
- Mit dem Fortschritt von Frontier-AI-Modellen und Coding-Agenten beginnt das Zeitalter des automatisierten Programmierens. Das manuelle Tippen von Code Zeile für Zeile verschwindet, und Softwareingenieure können sich wieder auf grundlegendes Design und Denken konzentrieren.
- Seit Ende letzten Jahres hat sich die Reife von Tools und Modellen dramatisch verbessert, sodass in gut aufgebauten Umgebungen eine Arbeitsweise möglich ist, bei der man sich auf die Architektenrolle konzentriert und bei Bedarf dennoch direkt eingreifen und Korrekturen vornehmen kann.
- In der Web-, Mobile- und Desktop-Entwicklung haben sich unnötige Frameworks und Abstraktionsebenen angesammelt, die echte Komplexität nicht lösen und stattdessen eher zusätzliche Probleme erzeugen.
- Von den drei Problemen, die Frameworks angeblich lösen — Vereinfachung, Automatisierung und Senkung der Arbeitskosten — hatte nur die Automatisierung einen legitimen Wert, doch selbst diese lässt sich nun durch KI-Automatisierung ersetzen.
- Man sollte nicht zum Operator von Systemen werden, die von Hyperscalern wie Google, Meta und Vercel entworfen wurden, sondern zum echten Engineering zurückkehren und eigene Designs und Produkte selbst bauen.
Der Aufstieg des automatisierten Programmierens
- Die von Antirez geprägte Bezeichnung „automated programming“ trifft das Wesen deutlich besser als „vibe coding“.
- Wie bei Druckmaschine, Webstuhl und Fließband war Automatisierung ein Kern historischer Innovationen, und auch dieser Wandel steht in dieser Tradition.
- Seit Dezember 2025 haben sich die Fähigkeiten von Frontier-Modellen und Coding-Agenten dramatisch verändert, was für aufmerksame Beobachter bereits offensichtlich ist.
Die veränderte Rolle des Ingenieurs
- Aufgaben, die tiefes Nachdenken erfordern — etwa Architektur, Trade-offs, Produktentscheidungen und Edge Cases — bleiben weiterhin bestehen.
- Verschwunden ist die ermüdende und zehrende Handarbeit, jede einzelne Codezeile selbst zu tippen.
- Nutzt man Modelle und Tools in einer sauberen und gründlich aufgebauten Umgebung, kann man die Rolle des Architekten übernehmen, ohne jeden Ziegel selbst zu setzen.
- Dafür braucht es die Erfahrung aus 20 Jahren direkter Programmierarbeit; wenn einem etwas nicht gefällt, kann man selbst hineingehen, es verstehen, anpassen und anschließend die Konfiguration aktualisieren.
- Da sich benötigte Tools sofort erzeugen lassen, kann man mehr Zeit darauf verwenden, die erdachte Technik zu verwirklichen.
Frameworks und unnötige Komplexität
- In der Web-, Mobile- und Desktop-Entwicklung hat sich über Jahre eine massive Verschmutzung durch Frameworks, Libraries und Tooling angesammelt.
- Abstraktionsebenen, die nichts Bedeutendes abstrahieren, stapeln sich übereinander und erzeugen zehn neue Probleme, während sie vorgeben, eines zu lösen.
- Die gesamte Branche hat sich dafür entschieden, fertiges Denken einzukaufen, statt ihr Denken angesichts der wirklichen Komplexität des Softwarebaus zu schärfen.
- Es ist, als würde man ein gebrochenes Bein mit Seide umwickeln: Von außen sieht es gut aus, aber das Bein ist immer noch gebrochen.
Die drei Probleme, die Frameworks angeblich lösen
- „Vereinfachung (Simplification)“: Ingenieure haben Angst davor, selbst zu entwerfen, und übernehmen blind die Struktur anderer.
- Statt vom Ziel rückwärts zu entwerfen, wird ein One-size-fits-all-Design überall angewendet.
- Das ist keine Vereinfachung, sondern intellektuelle Kapitulation (intellectual surrender).
- „Automatisierung (Automation)“: Der einzige wirklich nachvollziehbare Wert liegt in der Beseitigung von Boilerplate-Code.
- Dazu gehört die Automatisierung wiederholbarer, aber notwendiger Aufgaben wie ORM, CRUD-Verwaltung, Codegenerierung und API-Dokumentation.
- Doch genau an diesem Punkt verändert KI gerade alles.
- „Senkung der Arbeitskosten (Labour cost)“: Der stille Grund, der nicht auf Konferenzfolien auftaucht.
- Wenn Google, Meta und Vercel bestimmen, wie Produkte gebaut und Code ausgeliefert wird, kann man statt Softwareingenieuren auch „React-Entwickler“ einstellen.
- Keine Ausbildung nötig, Plug-and-play, leicht austauschbare Arbeitskräfte wie Zahnräder (cogs).
- Das ist kein Engineering, sondern Betrieb (operating).
Die Realität der neuen Arbeitsweise
- Seit mehr als zwei Jahren wird auf diese Weise nahezu fehlerfrei entwickelt; die eigentliche Revolution begann im vergangenen Dezember.
- Es eröffnet sich die Chance, unnötige Komplexität zu entfernen und sich auf ideengetriebene Komplexität zu konzentrieren.
- Die Kosten für das Entfernen von Boilerplate nähern sich praktisch null, und es ist nicht mehr nötig, denselben Code zweimal zu schreiben.
- Kleine, zweckgebundene Werkzeuge, die exakt zum Problem passen, lassen sich sofort erstellen.
- Ohne auffälligen Monorepo-Manager erfüllt ein einfaches Makefile 99 % der Use Cases.
- Wenn ein Problem wirklich sehr komplex wird, denkt man erst dann darüber nach; es vorher niemals vorwegzulösen, ist Engineering.
- Man sollte nicht Probleme lösen, von denen jemand auf einer Konferenzbühne behauptet, dass sie vielleicht irgendwann auftreten, sondern die Probleme, die man jetzt tatsächlich hat.
Die Wiederentdeckung von Bash und grundlegenden Tools
- Agenten sind äußerst versiert im Umgang mit grundlegenden Tools (basic tools), die es seit Jahrzehnten gibt.
- Bash entstand 1989, und selbst das gewöhnlichste Modell von heute kennt Bash besser als jeder Mensch auf der Welt.
- Bei Coding-Agenten zeigt sich ein Trend weg von komplexen und teuren MCP-Konfigurationen hin zu einfachen agentischen Schleifen auf Bash-Basis.
- Das älteste Werkzeug ist das zukunftssicherste Werkzeug (most future proof).
Die Kosten der Framework-Abhängigkeit
- Für die meisten Use Cases braucht man keine teuren und fehleranfälligen Frameworks und Begleitbibliotheken, von denen nur 10 % der Funktionen genutzt werden.
- Versteckte Kosten wie Wartung, Sicherheitsupdates und Designbeschränkungen sind hoch und schränken die Freiheit von Entwicklern ein.
- Wer diesen Trade-off weiterhin akzeptiert, verpasst die größte Chance seit Jahrzehnten.
- Man sollte Strukturen misstrauen, die den Designphilosophien großer Unternehmen wie Google, Meta und Vercel untergeordnet sind.
- Entwickler sollten ihrem eigenen Denken und ästhetischen Empfinden vertrauen und eigene Werkzeuge und Produkte bauen.
„Wickelt kein gebrochenes Bein in Seide, sondern baut etwas, das wirklich euch selbst gehört.“
5 Kommentare
Das ist wirklich eine Methodik, um Software auf maximal wartungsunfreundliche Weise zu entwickeln. Das ist jemand, der im KI-Zeitalter ganz praktisch vorlebt, wie man sich im neuen Zeitalter seinen Platz lebenslang sichert.
Die Aussage „teure und fehlerhafte Frameworks und Zusatzbibliotheken, von denen man in den meisten Use Cases nur 10 % der Funktionen nutzt“ kann ich wirklich überhaupt nicht nachvollziehen .. War es nicht immer eine Tugend, eine Umgebung in der passenden Größe für das Projekt gut auszuwählen? Wenn man wohl nicht viele Funktionen bauen wird, kann man doch etwas Leichtgewichtiges wie Express verwenden. Muss man wirklich ausgerechnet einen Ersatz für Express von Grund auf neu bauen..
Wenn man schon von etwas mit vielen Funktionen spricht, von denen man kaum etwas nutzt, dann träfe das eher auf Webserver wie Apache oder nginx zu. Baut man den Webserver neu von Grund auf, nur weil er schwergewichtig ist? Nein, man konfiguriert ihn einfach und nutzt ihn.
Es gibt bereits gut strukturierte Frameworks und reichlich Material, an dem KI trainiert wurde. Muss man da wirklich noch etwas völlig Eigenes neu bauen? Mir scheint das eher die Produktivität zu verringern.
Ich denke nicht, dass man etwas wieder verwerfen muss, das die Kosten für die Architektur gesenkt hat und es ermöglicht, sich auf das Wesentliche (den Service) zu konzentrieren.
Hm ... ist diese Praxis nicht eher aus der Zeit, als Cursor unbegrenzte Nutzung angeboten hat ...? Eher scheint mir zumindest vorerst die Richtung zu sein: Wie kann man Token sparen und AI gut unterstützen?
Auch ohne teure Tokenpreise kann man Duplikate beseitigen — warum sollte man dann keinen Frameworks verwenden?
Hacker-News-Kommentare
In naher Zukunft werden viele Entwickler und Unternehmen wegen AI-Hype wohl einen harten Schock erleben
Im Moment kann man mit AI zwar Dinge bauen, aber das eigentliche Problem sind die Bereiche, die man erst versteht, wenn man selbst frontal dagegenläuft
Am Ende werden Leute, die nur „Vibe Coding“ betreiben, an reale Grenzen stoßen, und nur diejenigen überleben, die verstehen, wie Systeme tatsächlich funktionieren
Ein Bug konnte in 2 Minuten behoben und gemergt werden, und „das System verstehen“ und „den Code nicht selbst schreiben“ schließen sich nicht aus
AWS setzt riesige Summen auf diese Richtung, und je stabiler nichtdeterministische Tools werden, desto größer ist die Chance, dass sie menschliche Qualität übertreffen
Wenn man ohne Verständnis auslagert, lassen sich Korrektheit, Wartbarkeit und Skalierbarkeit des Ergebnisses nicht garantieren
Aber wenn ich mit solchen Leuten zusammenarbeiten soll, frage ich mich, warum man ihnen Hunderttausende Dollar zahlen und zusätzlich noch ihre LLM-Abos finanzieren sollte
Klar wird es Fälle geben, in denen mit „Vibe Coding“ gebaute Apps auseinanderfallen, aber Teams, die parallel testen, Versionsverwaltung nutzen und dokumentieren, werden eher noch erfolgreicher sein
Am Ende ist ein ausgewogener Ansatz entscheidend
Vielleicht taucht irgendwann ein „de-slopper bot“ auf
Der Grund, warum man Frameworks nutzt, ist, dass ihre Entwickler mehr Probleme und Skalierungsfragen erlebt haben als ich
Am Anfang eines Projekts ist alles einfach, aber wenn es größer wird, ist ein Redesign schmerzhaft
Wenn man solche Texte liest, wirkt oft schon der Text selbst, als wäre er von einem LLM geschrieben
Metaphern wie „Ziegel schneiden und zusammennähen“ zeigen eher diesen Widerspruch
Den gesamten Stack selbst zu bauen ist nach wie vor ineffizient und verursacht hohe Wartungskosten
Neu ist nur, dass man jetzt leicht maßgeschneiderte Komponenten passend zum Problem bauen kann
Man muss nichts Neues lernen, wenn vertraute Frameworks völlig ausreichen
mein Problem, das Plattformproblem und das Problem, das Framework zu umgehen
Es fühlt sich merkwürdig an, Texte über den Schmerz des Codens zu lesen. Das Coden selbst ist eher der einfache Teil
Wenn Tolkien AI benutzt hätte, hätte er vermutlich seine Zeit damit verschwendet, Prompts zu verfeinern
Gerade bei schwierigen Teilen ist AI-Hilfe eher Gift als Hilfe
Wenn das dieselben Leute sind, ist das widersprüchlich
Heute lasse ich das meist Claude Code übernehmen, und es ist in wenigen Minuten gelöst
Ich vertraue aber eher dem Code, den ich selbst geschrieben habe. Am Ende ist Tiefe des Verständnisses wichtiger als Geschwindigkeit
Wenn man wie Warhol neue Werkzeuge gut einsetzt, ist auch das Kunst
LLMs sind nur Werkzeuge, die in der frühen Phase des Schaffens helfen; Genialität kommt weiterhin vom Menschen
Node.js-Sicherheitspatches als lästig zu empfinden ist ein Missverständnis
Das ist ein Privileg. Eine selbstgebaute Lösung hat keine Security-Community und dafür umso mehr Schwachstellen
React-Entwickler findet man leicht, aber Entwickler für ein „von AI gebautes proprietäres Framework“ gibt es nicht
Das ist keine große Leistung
Es gibt einen Mittelweg zwischen Coding-Agenten und Frameworks
Ich nutze weiterhin dieselben Tools, aber repetitive Arbeit übernimmt der Agent
Ich konzentriere mich auf Architektur und Edge Cases
Agenten zu ignorieren ist genauso extrem wie blind auf sie zu vertrauen
Die wahre Fähigkeit besteht darin, zu wissen, wann man das Steuer übernehmen muss
Das Problem dieses Textes ist, dass er Frameworks und „echtes Engineering“ als Gegensatz darstellt
Plattformen wie Vercel, Next.js und Firebase ermöglichen sofortige Deployments und CI/CD
Wenn man an die Zeit denkt, als man so etwas noch selbst mit Jenkins aufsetzen musste, ist das revolutionär
Echtes Engineering bedeutet nicht „neu erfinden“, sondern schnell an den Kunden ausliefern
Dass AI bestehende Frameworks ohne Bewährung in realen Einsätzen neu implementiert, ist ineffizient
Ohne Ökosystem und gemeinsame Muster wird Zusammenarbeit schwierig
Wenn unerfahrene Entwickler AI falsch einsetzen, ist das nichts Neues
Wenn man alles selbst baut, verliert man Dokumentation, Middleware und Wartbarkeit
Sie merken erst jetzt wieder, dass man „APIs verbinden kann“
Aber solche Entdeckungen gehen nicht automatisch mit einem Verständnis von Trade-offs einher
Ich habe in den letzten 6 Monaten Embedded-Entwicklung mit Cursor + Opus 4.x gemacht
LLMs helfen nicht nur bei Software, sondern auch bei Schaltungsdesign, CAD und CNC
Zum Beispiel habe ich Wrapper-Funktionen für ein ST7789-basiertes Display in drei Prompts fertiggestellt
Inzwischen nutze ich fast keine Libraries mehr außer LVGL, TinyUSB, Kompression und Kryptografie
Zweckgebundene Funktionen, die vom LLM erzeugt werden, sind klein, schnell und ohne unnötige Abstraktion
Ich glaube, für viele Libraries ist es jetzt Zeit abzutreten
Dinge wie .NET sind unersetzlich, aber allgemeine Funktionssammlungen lassen sich durchaus ersetzen
Der anstrengende Teil des Codens ist nicht das Tippen, sondern Zusammenarbeit mit Menschen, Tests und architektonisches Denken
Das Schwierigste, was ich zuletzt gemacht habe, war das Design einer lockfreien Datenstruktur
Im LLM-Zeitalter wird der Wert von Frameworks sogar noch größer
Dank ihrer Trainingsdaten sind LLMs stark bei vertrauten Mustern wie React
Wichtig ist auch, dass Menschen eingreifen und debuggen können
Selbst wenn AGI kommt, gibt es keinen Grund, effiziente Frameworks nicht erneut zu lernen
Schon dieses Gespräch ist ein interessantes Experiment