David Heinemeier Hansson setzt bei der Softwareentwicklung auf KI-Agenten

Warum die Rolle menschlicher Entwickler nicht verschwindet

Hansson stellt den manuellen Code als wirtschaftlich zunehmend unattraktiv dar. Daraus folgt jedoch nicht, dass menschliche Entwickler in absehbarer Zeit überflüssig werden. Ihre Aufgaben verändern sich vielmehr. Sie müssen weniger Zeit mit der direkten Eingabe standardisierter Implementierungen verbringen, dafür aber mehr Zeit in die Definition von Zielen, Einschränkungen und Qualitätskriterien investieren.

In einem agentenbasierten Prozess sind mehrere menschliche Fähigkeiten weiterhin unverzichtbar:

• Problembeschreibung: Anforderungen müssen so formuliert werden, dass ein Agent sie korrekt interpretieren kann.
• Priorisierung: Nicht jede technisch mögliche Funktion ist für das Produkt oder das Unternehmen sinnvoll.
• Architektur: Einzelne Änderungen müssen in ein konsistentes Gesamtsystem eingebettet werden.
• Qualitätskontrolle: Tests und automatisierte Prüfungen müssen entworfen, bewertet und erweitert werden.
• Sicherheit: Berechtigungen, Datenflüsse und Angriffsflächen dürfen nicht allein einem Modell überlassen werden.
• Verantwortung: Unternehmen müssen klären, wer für Entscheidungen und Fehler eines Agenten haftet.

Gerade bei geschäftskritischer Software reicht es nicht aus, dass eine Anwendung in einem Standardszenario funktioniert. Sie muss sich auch bei ungewöhnlichen Eingaben, hoher Last, fehlenden Daten und gezielten Angriffen erwartungsgemäß verhalten. Ein KI-Agent kann dabei unterstützen, aber er ersetzt nicht automatisch die Verantwortung für die Bewertung.

Die Grenzen automatisierter Codeprüfung

Ein häufig genannter Vorteil von KI-Agenten ist ihre Fähigkeit, Tests zu schreiben und Änderungen selbstständig zu validieren. Das kann die Entwicklung beschleunigen, solange die Prüfungen die relevanten Risiken abdecken. Ein Testsystem kann jedoch nur das zuverlässig prüfen, was zuvor als erwartetes Verhalten beschrieben wurde.

Fehler entstehen häufig an den Rändern eines Systems: bei ungewöhnlichen Berechtigungen, widersprüchlichen Daten, unvollständigen Eingaben oder der Kombination mehrerer Funktionen. Auch ein umfassendes Testpaket kann eine falsche Produktentscheidung nicht erkennen. Wenn ein Agent eine Funktion baut, die technisch funktioniert, aber den falschen Geschäftsprozess abbildet, liegt das Problem nicht im Code, sondern in der Interpretation der Anforderung.

Für Unternehmen bedeutet dies, dass die Qualitätssicherung nicht ausschließlich nachgelagert erfolgen sollte. Sie muss bereits bei der Definition der Aufgaben beginnen. Agenten benötigen klare Zuständigkeiten, begrenzte Zugriffsrechte, nachvollziehbare Änderungsprotokolle und definierte Freigabepunkte. Besonders sensible Aktionen sollten eine ausdrückliche menschliche Bestätigung erfordern.

Auch die Lesbarkeit des Codes bleibt relevant. Selbst wenn menschliche Entwickler weniger Code direkt schreiben, müssen sie in kritischen Situationen verstehen können, wie ein System arbeitet. Das gilt insbesondere bei Sicherheitsvorfällen, rechtlichen Auseinandersetzungen und langfristigen Migrationen. Die Vorstellung, generierten Code grundsätzlich nicht mehr lesen zu müssen, ist daher für viele Unternehmensanwendungen nur eingeschränkt tragfähig.

Neue Anforderungen an Architektur und Governance

Hansson argumentiert, dass klassische Softwarearchitektur neu gedacht werden müsse, wenn nicht mehr Menschen, sondern Agenten den größten Teil der Änderungen vornehmen. Traditionelle Abstraktionen und Designmuster könnten in einer solchen Umgebung eine andere Funktion erhalten. Sie dienen dann nicht nur dazu, menschlichen Teams Orientierung zu geben, sondern auch dazu, maschinelle Systeme innerhalb klarer Strukturen zu halten.

Für die Unternehmenspraxis folgt daraus ein Bedarf an neuen Governance-Modellen. Dazu zählen Richtlinien für den Einsatz von Agenten, Regeln für den Zugriff auf Quellcode und Produktionssysteme sowie Verfahren für die Dokumentation automatisch erzeugter Änderungen.

Ein belastbares Modell sollte unter anderem folgende Fragen beantworten:

• Welche Aufgaben dürfen Agenten selbstständig ausführen?
• Welche Daten dürfen sie lesen oder verändern?
• Wie werden sensible Informationen vor der Verarbeitung geschützt?
• Wer genehmigt Änderungen an produktiven Systemen?
• Wie werden Quellen, verwendete Modelle und Eingaben dokumentiert?
• Wie lässt sich eine fehlerhafte Änderung schnell zurücknehmen?
• Welche Prüfungen müssen vor einer Veröffentlichung erfolgreich abgeschlossen sein?

Diese Fragen betreffen nicht nur die IT-Abteilung. Sie berühren Datenschutz, Informationssicherheit, Compliance, Einkauf und Risikomanagement. Ein KI-Agent, der auf interne Daten zugreifen und eigenständig Änderungen durchführen darf, ist nicht bloß ein Produktivitätswerkzeug. Er wird zu einem Bestandteil der Unternehmensinfrastruktur.

Die geplante technische Richtung von 37signals

Nach den vorliegenden Berichten beabsichtigt 37signals, künftige Versionen von Hey als native Anwendungen für die unterstützten Plattformen zu entwickeln. Für die Serverseite soll dabei Rust eine größere Rolle spielen. Das ist insofern bemerkenswert, als Hansson die Sprache in der Vergangenheit kritisch bewertet hatte.

Hansson begründet den Wechsel mit der Annahme, dass KI-Agenten die Komplexität von Rust für Menschen teilweise abschirmen können. Die Entwickler müssten sich dann weniger mit der Syntax und den technischen Einzelheiten befassen, könnten aber von Eigenschaften wie hoher Leistung und effizientem Speicherverbrauch profitieren.

Diese Argumentation lässt sich technisch nachvollziehen, ist aber nicht ohne Einschränkungen. Wenn Menschen den erzeugten Rust-Code nur selten im Detail prüfen, können Fehler und Sicherheitsprobleme schwerer erkennbar werden. Außerdem hängt die Leistungsfähigkeit einer Anwendung nicht allein von der Programmiersprache ab. Architektur, Datenmodell, Netzwerkanforderungen, Caching, Produktumfang und Betriebsumgebung beeinflussen den Ressourcenverbrauch ebenfalls erheblich.

Berichte über einen deutlich geringeren CPU- und Speicherbedarf der neuen Hey-Architektur sind daher als produktspezifische Angaben zu verstehen. Ein Vergleich zwischen einer bestehenden Webanwendung und einer neu konzipierten nativen Anwendung kann nicht ohne Weiteres als allgemeiner Beleg für die Überlegenheit einer bestimmten Sprache oder eines bestimmten Entwicklungsmodells dienen.

Welche Rolle bleibt für Ruby on Rails?

Die Aussagen Hanssons sind auch deshalb relevant, weil sie auf einer Konferenz für die Rails-Community fielen. Ein großer Teil der Keynote soll sich jedoch nicht mit der unmittelbaren Weiterentwicklung von Rails, sondern mit agentenbasierter Entwicklung, nativen Anwendungen und Rust beschäftigt haben.

Hansson stellte Ruby on Rails nach den vorliegenden Berichten weiterhin als geeignetes Framework für Webanwendungen dar. Die klaren Konventionen und die standardisierte Struktur könnten auch für KI-Agenten hilfreich sein. Ein Agent kann sich in einem bekannten Projektaufbau leichter orientieren, wenn Verzeichnisstruktur, Namensgebung und typische Abläufe vorhersehbar sind.

Damit erhält ein früheres Kernprinzip von Rails eine neue Begründung. „Convention over Configuration“ sollte ursprünglich vor allem menschlichen Entwicklungsteams helfen, schneller zu konsistenten Anwendungen zu gelangen. Nun könnte dieselbe Konventionalität auch die Zusammenarbeit mit KI-Systemen erleichtern. Je weniger Entscheidungen ein Agent aus unvollständigen Informationen ableiten muss, desto geringer ist das Risiko uneinheitlicher Implementierungen.

Gleichzeitig stellt sich die Frage nach der strategischen Führung des Frameworks. Wenn der ursprüngliche Schöpfer seine eigene praktische Nutzung von Ruby deutlich reduziert, erwarten Anwenderinnen und Anwender möglicherweise eine Erklärung zur langfristigen Ausrichtung. Ein Framework kann auch ohne die tägliche Beteiligung seines Gründers weiterentwickelt werden. Dafür braucht es jedoch eine klare technische Roadmap, aktive Maintainer und transparente Prioritäten.

Rails verfügt über eine etablierte Community und Unternehmen, die zur Weiterentwicklung beitragen. Diese Faktoren können die Stabilität des Projekts sichern. Offen bleibt jedoch, ob Rails künftig vor allem als klassisches Webframework, als besonders agentenfreundliche Entwicklungsumgebung oder als langfristig gewartete Plattform positioniert werden soll.

Die Bedeutung von Schnittstellen für KI-Agenten

Hansson sprach sich außerdem dafür aus, dass Softwareanbieter stärker auf Kommandozeilenschnittstellen und klar strukturierte Programmierschnittstellen setzen sollten. Agenten können über solche Schnittstellen Funktionen meist eindeutiger und kontrollierter ausführen als über grafische Oberflächen, deren Elemente sich verändern oder unterschiedlich interpretiert werden können.

Eine gut gestaltete Kommandozeilenschnittstelle kann Agenten standardisierte Befehle, strukturierte Antworten und begrenzte Zugriffsrechte bieten. Sie erleichtert zudem die Protokollierung und Automatisierung. Für Geschäftsanwendungen kann dies die Grundlage für agentenbasierte Workflows bilden, etwa bei der Auswertung von Daten, der Erstellung von Berichten oder der Verwaltung wiederkehrender Aufgaben.

Allerdings ersetzt eine Schnittstelle keine Produktstrategie. Unternehmen müssen festlegen, welche Aktionen ein Agent ausführen darf, welche Bestätigung erforderlich ist und wie Nutzerinnen und Nutzer nachvollziehen können, was geschehen ist. Gerade bei Finanzdaten, Kundendaten oder administrativen Änderungen braucht es klare Grenzen und eine verständliche Darstellung der Folgen.

Für Anbieter wie 37signals kann eine stärkere Ausrichtung auf Agenten zudem die bisherige Bedeutung grafischer Oberflächen verändern. Produkte werden traditionell über ihre Bedienoberfläche, Arbeitsabläufe und Nutzererfahrung differenziert. Wenn Agenten Funktionen zunehmend über standardisierte Schnittstellen aufrufen, verlagert sich der Wettbewerb teilweise auf Datenzugriff, Integrationen, Berechtigungsmodelle und Zuverlässigkeit.

Was die Entwicklung für B2B-Unternehmen bedeutet

Für Unternehmen aus dem B2B-Bereich ist Hanssons Ankündigung weniger als unmittelbare Handlungsanweisung denn als Signal für eine sich verändernde Softwareproduktion zu verstehen. KI-Agenten können bereits heute Entwicklungsaufgaben beschleunigen. Die entscheidende Frage lautet jedoch, in welchen Bereichen der Einsatz wirtschaftlich und organisatorisch sinnvoll ist.

Ein schrittweises Vorgehen kann Risiken begrenzen. Unternehmen können zunächst klar abgegrenzte Aufgaben auswählen, bei denen Daten, Berechtigungen und erwartete Ergebnisse gut kontrollierbar sind. Dazu gehören beispielsweise die Erstellung von Testfällen, die Dokumentation bestehender Funktionen, die Migration einfacher Schnittstellen oder die Entwicklung interner Prototypen.

Für produktive Systeme sollten dagegen strengere Anforderungen gelten. Agenten benötigen einen begrenzten Zugriff, Änderungen sollten versioniert und überprüfbar sein, und jede Veröffentlichung muss definierte Tests durchlaufen. Zusätzlich sollte ein Unternehmen dokumentieren, welche Teile einer Anwendung automatisch erzeugt wurden und welche menschlichen Prüfungen stattgefunden haben.

Für die Einführung sind insbesondere folgende Punkte relevant:

• Use-Case-Auswahl: Beginnen Sie mit Aufgaben, deren Risiken und Erfolgskriterien eindeutig definiert sind.
• Zugriffskontrolle: Vergeben Sie Agenten nur die Berechtigungen, die für den jeweiligen Arbeitsschritt notwendig sind.
• Transparenz: Protokollieren Sie Eingaben, Änderungen, verwendete Modelle und Freigaben.
• Review-Prozesse: Legen Sie fest, welche Änderungen zwingend von Menschen geprüft werden müssen.
• Messbarkeit: Bewerten Sie nicht nur die Menge des erzeugten Codes, sondern auch Fehlerquote, Wartungsaufwand und geschäftlichen Nutzen.
• Schulung: Entwickeln Sie Kompetenzen in Anforderungsdefinition, Systembewertung, Sicherheit und Agentensteuerung.

Unternehmen sollten zudem vermeiden, agentenbasierte Entwicklung ausschließlich als Personal- oder Kostensenkungsprogramm zu betrachten. Werden Entwicklerinnen und Entwickler nur daran gemessen, wie viele Aufgaben ein Agent übernimmt, besteht das Risiko, dass notwendige Prüfungen und Architekturarbeit vernachlässigt werden. Die entscheidende Kennzahl bleibt die zuverlässige Bereitstellung eines wertvollen Produkts.

Ein Wandel des Berufsbilds, kein vollständiger Wegfall von Softwarekompetenz

Hansson beschreibt die neue Rolle von Programmierern als „professionelle Macher“, die eine leistungsfähige maschinelle Intelligenz anleiten. Diese Beschreibung betont die kreative und konzeptionelle Seite der Softwareentwicklung. Menschen entscheiden, welches Problem gelöst werden soll, welche Nutzergruppen im Mittelpunkt stehen und welche Qualitätsanforderungen gelten.

Das Berufsbild könnte sich dadurch ausdifferenzieren. Neben klassischen Softwareentwicklern könnten stärker spezialisierte Rollen entstehen, etwa für Systemarchitektur, technische Produktentwicklung, Daten- und Sicherheitsgovernance oder die Gestaltung agentenbasierter Arbeitsabläufe. Gleichzeitig bleibt ein solides Verständnis von Programmierung wichtig, weil nur damit die Ergebnisse von Agenten zuverlässig bewertet werden können.

Wer den erzeugten Code nicht selbst von Grund auf schreibt, muss ihn nicht automatisch weniger verstehen. Im Gegenteil: Bei bestimmten Anwendungen kann die Fähigkeit zur Analyse und Bewertung komplexer Systeme wichtiger werden. Ein Team, das Code lediglich akzeptiert, weil er von einem leistungsfähigen Modell erzeugt wurde, gibt einen Teil seiner technischen Kontrolle ab.

Die langfristige Entwicklung wird deshalb wahrscheinlich nicht durch einen vollständigen Gegensatz zwischen manueller und automatisierter Programmierung bestimmt. In vielen Organisationen wird eine Kombination entstehen. Menschen schreiben weiterhin besonders kritische oder konzeptionell wichtige Komponenten selbst, während Agenten bei Routineaufgaben, Variantenbildung und vorbereitenden Analysen unterstützen.

Warum die Ankündigung nicht als allgemeines Ende des Programmierens gilt

Die Formulierung, manuelles Programmieren verliere seine wirtschaftliche Bedeutung, ist weitreichend. Sie basiert jedoch vor allem auf Hanssons Erfahrungen bei 37signals und auf seinen persönlichen Entwicklungsprojekten. Diese Erfahrungen sind aufschlussreich, bilden aber nicht automatisch die Bedingungen großer Unternehmen, regulierter Branchen oder sicherheitskritischer Systeme ab.

In Banken, im Gesundheitswesen, in der industriellen Steuerung oder in öffentlichen Infrastrukturen gelten häufig besondere Anforderungen an Nachvollziehbarkeit, Zertifizierung und Haftung. Dort kann der Einsatz von Agenten sinnvoll sein, aber er muss in bestehende Kontrollsysteme integriert werden. Auch große Organisationen verfügen über komplexe Legacy-Systeme, heterogene Teams und zahlreiche Abhängigkeiten, die eine schnelle Umstellung erschweren.

Hinzu kommen Unterschiede bei Datenqualität, Modellzugang und Infrastruktur. Ein kleines Unternehmen kann seine Prozesse möglicherweise grundlegend umstellen und neue Anwendungen von Beginn an agentenfreundlich konzipieren. Ein Konzern muss bestehende Systeme, Verträge, Sicherheitsvorgaben und interne Zuständigkeiten berücksichtigen.

Die Aussage Hanssons ist deshalb vor allem ein Indikator für eine Entwicklung, die sich in Teilen der Softwarebranche bereits abzeichnet: Die direkte Codeeingabe wird für bestimmte Aufgaben weniger dominant. Wie weit diese Verschiebung reicht, hängt vom Anwendungsfall, vom Risiko und von der Fähigkeit eines Unternehmens ab, automatisierte Produktion mit professioneller Kontrolle zu verbinden.

Ein Signal für die nächste Phase der Softwareentwicklung

Die Ankündigung von David Heinemeier Hansson markiert einen sichtbaren Wendepunkt in der Debatte über KI und Softwareentwicklung. Ein langjähriger Vertreter des Programmierens als Handwerk erklärt, dass er den größten Teil der Implementierung inzwischen an KI-Agenten delegiert. Damit wird die Diskussion von der Frage, ob solche Werkzeuge genutzt werden sollten, auf die Frage verschoben, wie Entwicklungsorganisationen mit ihnen arbeiten können.

Die praktischen Folgen sind noch nicht abschließend geklärt. Agenten können die Umsetzung beschleunigen, neue Projekte wirtschaftlich ermöglichen und kleineren Teams Zugang zu umfangreicher technischer Unterstützung geben. Gleichzeitig können sie technische Schulden, Sicherheitsrisiken und unübersichtliche Architekturen schneller erzeugen, wenn Anforderungen und Kontrollmechanismen nicht ausreichend definiert sind.

Für Ruby on Rails bleibt die Entwicklung ambivalent. Die Konventionen des Frameworks könnten sich als Vorteil für KI-gestützte Entwicklung erweisen. Zugleich steht die Community vor der Aufgabe, die langfristige Rolle und Weiterentwicklung des Projekts klar zu bestimmen. Hanssons persönliche Abkehr vom manuellen Programmieren bedeutet nicht automatisch das Ende von Rails. Sie verändert jedoch die Erwartungen an die Person, die das Framework geprägt hat, und an die Organisationen, die seine Zukunft mitgestalten.

Für B2B-Entscheider liegt die wichtigste Erkenntnis daher nicht in der Frage, ob künftig noch Menschen Code schreiben werden. Entscheidend ist, wie Unternehmen Verantwortung, Qualität und strategische Kontrolle organisieren, wenn Maschinen immer größere Teile der Implementierung übernehmen. Die Geschwindigkeit der Codeerzeugung ist nur ein Faktor. Nachhaltiger Erfolg entsteht erst, wenn diese Geschwindigkeit mit überprüfbaren Anforderungen, sicherer Infrastruktur und belastbaren Entscheidungsprozessen verbunden wird.

Bibliografie

1. The Verge: „Ruby on Rails creator: ‘We’re done writing code by hand.’“, Jess Weatherbed, 24. September 2026. https://www.theverge.com/tech/999834/ruby-on-rails-creator-were-done-writing-code-by-hand
2. The Decoder: „Ruby on Rails creator DHH says he’s done writing code by hand“, Matthias Bastian, 25. September 2026. https://the-decoder.com/ruby-on-rails-creator-dhh-says-hes-done-writing-code-by-hand/
3. Ruby on Rails: „Rails World 2026 Opening Keynote – DHH“, YouTube. https://www.youtube.com/watch?v=vDjW_dRyKXY
4. The Pragmatic Engineer: „DHH’s new way of writing code“, Gergely Orosz, 8. April 2026. https://newsletter.pragmaticengineer.com/p/dhhs-new-way-of-writing-code
5. LavX News: „Rails World keynote leaves Rails’ future unclear“, Marta Kowalska, 25. September 2026. https://news.lavx.hu/article/rails-world-keynote-leaves-rails-future-unclear
6. Jared Norman: „What About Rails?“, 24. September 2026. https://jardo.dev/what-about-rails
7. ZEN Software: „DHH on programming with AI agents, chapter by chapter“, Arjan Franzen, 27. August 2026. https://zensoftware.cloud/articles/dhh-on-programming-with-ai-agents