Coding-Agenten haben alle Frameworks ersetzt, die ich benutzt habe

> „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.“