Die Art, wie Software entsteht, verändert sich derzeit so grundlegend wie zuletzt beim Übergang vom handgeschriebenen Manuskript zum gedruckten Buch. Was vor wenigen Monaten noch als beeindruckende Autovervollständigung galt, ist inzwischen zu einem Paradigmenwechsel geworden: KI-Agenten schreiben, prüfen, debuggen und erweitern Code in vielen Projekten weitgehend selbstständig.

Wie weit dieser Wandel reicht, lässt sich an einer Aussage von Boris Cherny ablesen, dem Schöpfer von Claude Code bei Anthropic. Auf der Sequoia-Konferenz AI Ascent 2026 (nachzuhören im Sequoia-Podcast „Training Data") berichtete er, im laufenden Jahr keine einzige Zeile Code mehr selbst geschrieben zu haben. An manchen Tagen verantwortet er stattdessen mehrere Dutzend Pull Requests, an einem Spitzentag waren es 150. Das Modell schreibt, der Mensch prüft und entscheidet. Für Entscheidungsträger bedeutet das: Nicht mehr ob, sondern wie schnell und mit welchen Konsequenzen sich Entwicklungsprozesse, Teamstrukturen und Geschäftsmodelle verändern werden.

Wir bei mindtwo beobachten diese Entwicklung aus zwei Perspektiven: als Agentur für individuelle Softwareentwicklung, die agentenbasierte Workflows aktiv in eigenen Projekten einsetzt, und als Beratungspartner für Unternehmen, die ihre digitalen Plattformen zukunftsfest aufstellen wollen. Dieser Artikel ordnet ein, was sich technologisch, organisatorisch und strategisch verändert und welche Schlüsse Entscheidungsträger daraus ziehen sollten.

Vom Autocomplete zur autonomen Entwicklung

Noch bis vor wenigen Jahren war KI-gestützte Programmierung gleichbedeutend mit zeilenweiser Codevervollständigung. Entwicklerinnen und Entwickler tippten, der Assistent schlug die nächste Zeile vor, ein Tab-Druck übernahm den Vorschlag. Verantwortung für Architektur, Logik und Korrektheit blieb vollständig beim Menschen.

Mit der nächsten Generation großer Sprachmodelle hat sich dieses Verhältnis verschoben. Statt einzelne Zeilen vorzuschlagen, übernehmen Agenten heute komplette Aufgaben: Sie lesen eine Spezifikation, analysieren das vorhandene Code-Repository, ändern mehrere Dateien konsistent, führen Tests aus, beheben Fehlermeldungen iterativ und öffnen einen Pull Request zur Prüfung. Der Mensch wird zur Schnittstelle zwischen Geschäftsanforderung und Ergebnis. Er beschreibt das Ziel, prüft die Umsetzung und entscheidet, was in den Hauptbranch wandert.

Für die Praxis bedeutet das eine erhebliche Verdichtung: Die Anzahl der Änderungen, die ein einzelner Entwickler pro Tag verantworten kann, steigt um eine Größenordnung. Wo früher zwei bis drei Pull Requests am Tag eine gute Quote waren, sind heute mehrere Dutzend realistisch, bei vergleichbarer oder höherer Qualität, weil Tests, Linting und CI-Prüfungen vom Agenten ohnehin durchlaufen werden, bevor menschliche Reviewer überhaupt einen Blick auf den Code werfen.

Worin sich das technisch konkret zeigt

Drei Entwicklungen sind dabei besonders bemerkenswert:

  • Modellqualität als treibender Faktor: Der wesentliche Sprung kommt nicht aus aufwendigeren Tool-Stacks, sondern aus jedem neuen Modellrelease. Wer Prozesse heute aufbaut, sollte einplanen, dass die Fähigkeiten in kurzen Abständen substanziell zunehmen.
  • Wahl von Sprachen und Frameworks gewinnt an Bedeutung und verliert sie wieder: Anfänglich profitierten Stacks, die in den Trainingsdaten der Modelle stark vertreten waren, etwa TypeScript, React oder Laravel. Inzwischen wird diese Asymmetrie kleiner. Aktuelle Modelle arbeiten zuverlässig auch mit weniger verbreiteten Sprachen und können neue Frameworks aus der Dokumentation erlernen.
  • Verifizierung wird zur Kernkompetenz: Wenn Agenten Code schreiben, verlagert sich der Engpass von der Codeproduktion zur Codeprüfung. Belastbare Tests, klare Akzeptanzkriterien und gut strukturierte Repositories sind nicht mehr Kür, sondern Voraussetzung dafür, dass agentenbasierte Workflows überhaupt skalieren.

Loops und Routinen: Software, die sich selbst weiterbaut

Eine der spannendsten Konsequenzen agentenbasierter Entwicklung sind nicht die einmaligen Aufgaben, sondern dauerhaft laufende Schleifen. Statt einen Agenten einmal anzustoßen, lässt sich ein zeitgesteuerter Auftrag formulieren: „Prüfe alle 30 Minuten den Status offener Pull Requests und behebe fehlschlagende CI-Builds." Oder: „Beobachte das Issue-Backlog und schlage täglich drei priorisierte Tickets für die nächste Iteration vor."

Cherny beschreibt diese Praxis als „Loops" und prognostiziert, dass solche dauerhaft laufenden Routinen die nächste große Stufe agentenbasierter Entwicklung darstellen. Bei Anthropic werde intern bereits flächendeckend so gearbeitet: Mehrere parallel laufende Claude-Instanzen kommunizieren über Slack, koordinieren Aufgaben untereinander und arbeiten asynchron weiter, auch wenn die zuständige Person längst den Laptop zugeklappt hat.

Was zunächst nach Spielerei klingt, hat erhebliche organisatorische Bedeutung. Routinetätigkeiten, die bisher menschliche Aufmerksamkeit gebunden haben (Rebasing von Feature-Branches, Fixen flakiger Tests, Auswertung von Nutzerfeedback, Pflege von Abhängigkeiten), lassen sich an dauerhaft laufende Agenten delegieren. Die freigewordene Zeit fließt in das, was Algorithmen nicht leisten können: Kundenverständnis, Produktstrategie, architektonische Grundsatzentscheidungen.

Für Unternehmen entsteht daraus ein neuer Typus betrieblicher Aufgaben: die Pflege der eigenen Agenten-Landschaft. Welche Loops laufen? Welche Berechtigungen haben sie? Wie werden Ergebnisse dokumentiert und überprüft? Wer eine zukunftsfähige digitale Plattform aufbaut, sollte diese Fragen früh in die Konzeption einbeziehen, idealerweise in einem strukturierten Konzept-Workshop, in dem nicht nur die Anwendung selbst, sondern auch der spätere Betriebsmodus durchdacht wird.

Der Wandel der Entwicklerrollen: Generalisten statt Spezialisten

Mit der Verschiebung der Wertschöpfung verändern sich auch die Rollen. In klassischen Setups gab es klare Trennungen: Frontend-Spezialisten, Backend-Spezialisten, DevOps, Datenanalysten, UX-Designer, Produktmanagement. Jede Rolle hatte eigenes Tooling, eigene Sprache, eigene Verantwortung.

Diese Trennung wird unschärfer. Wenn ein Agent in der Lage ist, sauberes CSS, eine performante API-Schicht und eine SQL-Abfrage gleichermaßen zu schreiben, profitieren Generalisten, also Menschen, die mehrere Disziplinen verstehen und mit dem Agenten als Verstärker arbeiten. Cherny beschreibt es so: Im Claude-Code-Team schreibt inzwischen jedes Mitglied Code, auch Produktmanager, Designer, Datenanalysten, der Finance-Verantwortliche und das User-Research-Team. Die Trennlinien zwischen Disziplinen werden durchlässig.

Das bedeutet nicht, dass Spezialisten überflüssig werden. Tiefe bleibt wertvoll, gerade dort, wo Architekturentscheidungen langfristige Konsequenzen haben oder wo Performance-, Sicherheits- und Compliance-Anforderungen ein detailliertes Verständnis erfordern. Es bedeutet aber, dass die Schnittstellen zwischen Disziplinen durchlässiger werden und Teams flacher organisiert sein können. Eine kleine, breit aufgestellte Gruppe kann heute Resultate erzielen, für die früher eine dreifach so große Mannschaft nötig war.

Konsequenzen für die Personalstrategie

Für Unternehmen heißt das konkret: Stellenprofile sollten weniger auf einzelne Frameworks und mehr auf Problemverständnis, Lerngeschwindigkeit und domänenspezifisches Wissen abzielen. Eine Buchhalterin, die programmieren lernt, wird unter Umständen die bessere Autorin einer Buchhaltungssoftware sein als eine reine Entwicklerin ohne Fachverständnis, weil das Domänenwissen schwieriger zu beschaffen ist als die Fähigkeit, mit einem Agenten zu arbeiten.

Die strategische Dimension: Was passiert mit etablierten Geschäftsmodellen?

Wenn das Schreiben von Software um Größenordnungen günstiger wird, stellt sich die Frage, was das für den Wert der Produkte bedeutet, die mit Software gebaut werden. Wird Standardsoftware kommodifiziert? Verschwinden ganze SaaS-Kategorien, weil Unternehmen ihre Anwendungen schneller selbst bauen, als sie eine Lizenz kaufen können? Cherny spricht in diesem Zusammenhang halb scherzhaft von einer „Saspocalypse" und kommt zu einer differenzierten Einschätzung, die wir in unserer Beratungspraxis teilen.

Ein hilfreicher Bezugsrahmen ist das Modell der „7 Powers" des Strategieforschers Hamilton Helmer (breit diskutiert auch auf dem Acquired-Podcast). Es unterscheidet sieben Quellen dauerhafter Wettbewerbsvorteile: Skaleneffekte, Netzwerkeffekte, Counter-Positioning, Wechselkosten, Marke, exklusive Ressourcen und Prozessmacht. Durch KI verschieben sich diese Quellen unterschiedlich stark.

An Bedeutung verlieren:

  • Wechselkosten: Wenn ein Agent in der Lage ist, Datenmodelle, Workflows und Integrationen zwischen Plattformen automatisiert zu übertragen, schmilzt die Bindungswirkung proprietärer Datenformate. Anbieter, deren Lock-in primär auf Migrationsaufwand basierte, müssen diesen Vorteil zunehmend abschreiben.
  • Prozessmacht: Software, deren Wert vor allem darin lag, einen komplexen Geschäftsprozess sauber abzubilden, lässt sich heute schneller nachbauen. Wer hier nicht laufend an Domänentiefe, Datenqualität und Nutzererlebnis weiterentwickelt, gerät unter Druck.

Weiterhin bedeutsam, teilweise wichtiger:

  • Netzwerkeffekte: Plattformen, deren Wert mit der Zahl der Teilnehmer wächst, sind durch KI nicht angreifbar. Ein Modell hilft nicht dabei, die installierte Basis nachzubauen.
  • Skaleneffekte: Wer Infrastruktur, Vertrieb oder Compliance-Apparate in einer Größenordnung betreibt, die Wettbewerber nicht kurzfristig replizieren können, behält seinen Vorsprung.
  • Exklusive Ressourcen: Daten, Lizenzen, Patente oder regulatorische Zulassungen, die nicht beliebig vermehrbar sind, gewinnen tendenziell an Wert, weil das ergänzende Produkt günstiger zu bauen ist.
  • Marke und Vertrauen: Wenn die Erstellung eines funktionalen Konkurrenten technisch jederzeit möglich ist, entscheidet zunehmend, wem Nutzer und Kunden vertrauen. Eine Frage des strategischen Markenauftritts und der Konzeption, nicht der reinen Implementierung.

Was das für Unternehmen heißt

Für etablierte Anbieter ergibt sich daraus eine doppelte Aufgabe: einerseits die eigenen, nicht durch KI angreifbaren Vorteile aktiv ausbauen (Netzwerke, Datenbestände, Markenpositionierung) und andererseits die eigene Organisation so umbauen, dass sie agentenbasierte Entwicklung intern nutzt, bevor jüngere Wettbewerber das von Grund auf tun.

Für neu startende Unternehmen ist die Situation günstig wie selten: Mit einem kleinen, eingespielten Team lassen sich Produkte aufbauen, die in Funktionalität und Reife mit dem messen können, wofür etablierte Wettbewerber dreistellige Entwicklerzahlen einsetzen. Die Eintrittsbarrieren in viele Märkte sinken, und entsprechend ist mit deutlich mehr ernstzunehmenden Herausforderern zu rechnen.

Die Druckpresse-Analogie: Demokratisierung des Softwarebaus

Wer eine historische Parallele für das sucht, was derzeit geschieht, landet schnell beim Druck mit beweglichen Lettern. Cherny zieht im Gespräch genau diese Linie, und sie trägt. Vor 1440 war Lesen und Schreiben in Europa eine Tätigkeit einer kleinen, oft kirchlich oder höfisch verankerten Minderheit; in globaler Perspektive konnten laut Our World in Data noch 1820 nur etwa zehn Prozent der erwachsenen Weltbevölkerung lesen und schreiben. Bis zum Jahr 1500 entstanden, ausgelöst durch die Druckpresse, schätzungsweise zwischen 15 und 20 Millionen gedruckte Bücher in Europa, der Preis pro Werk fiel um eine Größenordnung. Über die folgenden Jahrhunderte stieg die Alphabetisierung kontinuierlich an. Heute liegt sie laut UNESCO bei den über 15-Jährigen weltweit bei 88 Prozent, bei Jugendlichen sogar bei 93 Prozent.

Die Analogie ist nicht perfekt, aber sie hilft, das Ausmaß einzuordnen: Wenn die Hürde, eine eigene Software zu erstellen, von „benötigt mehrjährige Spezialausbildung" auf „lässt sich in natürlicher Sprache beschreiben" sinkt, dann wird Softwareerstellung von einer Expertenpraxis zu einer breit verfügbaren Kulturtechnik. Das verschiebt nicht nur Geschäftsmodelle, sondern verändert auch, wer überhaupt als Auftraggeber, Mitgestalter oder Nutzerin auftritt. Cherny illustriert das mit einem zugespitzten Bild: Die beste Person, um eine Buchhaltungssoftware zu schreiben, sei vielleicht nicht mehr eine Entwicklerin, sondern eine erfahrene Buchhalterin, weil das Domänenwissen das eigentlich Knappe sei.

Wichtig ist dabei: Die Demokratisierung ersetzt nicht die professionelle Entwicklung. Auch nach der Erfindung des Buchdrucks blieben die professionelle Autorenschaft, das Verlagswesen und das Lektorat bestehen. Sie wurden differenzierter und wertvoller, weil mehr Inhalte überhaupt produziert wurden. Übertragen heißt das: Anspruchsvolle Plattformen, sicherheitskritische Anwendungen, komplexe Integrationen und durchdachte Nutzererlebnisse bleiben Domäne erfahrener Teams. Was sich verändert, ist der Anteil einfacher und mittlerer Anwendungen, die ohne professionelle Begleitung entstehen.

Standardisierte Schnittstellen: Der unauffällige Hebel

Eine technische Entwicklung, die in der öffentlichen Diskussion oft hinter den spektakuläreren Demos zurücksteht, ist die Standardisierung der Schnittstellen zwischen Agenten und Werkzeugen. Das von Anthropic vorgestellte Model Context Protocol (MCP), das inzwischen unter Governance der Linux Foundation steht, hat sich innerhalb eines Jahres zum De-facto-Standard entwickelt und wird von allen großen Modellanbietern unterstützt.

Praktisch heißt das: Eine einmal definierte Anbindung an ein Drittsystem (CRM, Ticketing, Datenbank, interne API) funktioniert mit verschiedenen Modellen, verschiedenen Clients, verschiedenen Anwendungen. Für Unternehmen reduziert das den Aufwand, Agenten produktiv in bestehende IT-Landschaften einzubinden, ganz erheblich. Wer heute Plattformen konzipiert, sollte solche standardisierten Anschlüsse von Anfang an mitdenken, statt sie nachträglich aufzusetzen.

Was Entscheidungsträger jetzt tun sollten

Aus den Beobachtungen lassen sich einige praktische Empfehlungen ableiten, die unabhängig von der konkreten Branche tragen:

  1. Eigene Entwicklungsprozesse ehrlich evaluieren. Wo in der eigenen Wertschöpfung wird Code geschrieben, geprüft, deployed? Welche dieser Schritte sind heute schon agentenfähig, welche nicht, weil Tests fehlen, Repositories unübersichtlich sind oder Dokumentation veraltet?
  2. Mit überschaubaren Anwendungsfällen starten. Interne Werkzeuge, repetitive Aufgaben, Datenpipelines: das sind klassische Einstiegsbereiche, in denen agentenbasierte Entwicklung schnell Wert liefert, ohne kritische Systeme zu gefährden.
  3. Verifizierungsschichten ausbauen. Belastbare automatische Tests, klare Code-Review-Prozesse und nachvollziehbare Logs sind Voraussetzung dafür, dass agentenbasierte Arbeit skaliert und auditierbar bleibt.
  4. Personalstrategie anpassen. Generalisten mit Domänenwissen, gute Reviewer, Architekturkompetenz und Produktverständnis gewinnen an Bedeutung. Schulungen, Hospitationen und neue Karrierepfade sollten das spiegeln.
  5. Strategische Aufstellung überdenken. Welche der eigenen Wettbewerbsvorteile sind durch KI angreifbar, welche nicht? Wo lohnt sich Investition in Netzwerk, Daten oder Marke, wo eher in operative Effizienz?
  6. Architektur zukunftsfähig planen. Standardisierte Schnittstellen, saubere API-Designs, klare Datenmodelle. Alles, was die eigene Plattform für Agenten leichter zugänglich macht, zahlt sich mehrfach aus.

Ausblick: Software als Kulturtechnik

Wir stehen am Anfang einer Verschiebung, deren Tempo wahrscheinlich noch deutlich zunehmen wird. Cherny brachte es in seinem Vortrag zugespitzt auf den Punkt: In einem Jahr werde Claude Code selbst vielleicht aus nur noch hundert Zeilen Code bestehen, weil das Modell den Großteil der heutigen Werkzeugschicht überflüssig mache. Ob es genau so kommt, sei dahingestellt. Die Richtung ist klar.

Für Unternehmen ist das keine Frage des „Ob". Wer in den nächsten Jahren digitale Produkte baut, wird agentenbasiert arbeiten, allein schon weil der Geschwindigkeits- und Kostenunterschied zum klassischen Vorgehen zu groß wird, um ihn zu ignorieren. Die strategisch interessantere Frage ist: Welche Rolle will das eigene Unternehmen in dieser Verschiebung spielen? Anbieter, der eigene Produkte schneller und differenzierter entwickelt? Plattform, die Dritten Werkzeuge und Daten zur Verfügung stellt? Berater, der andere durch die Transformation begleitet?

Wir bei mindtwo unterstützen unsere Kunden dabei, diese Fragen fundiert zu beantworten: von der strategischen Konzeption über die technische Umsetzung individueller Webanwendungen bis zur Etablierung agentenbasierter Entwicklungsprozesse in bestehenden Teams. Wer den richtigen Zeitpunkt sucht, sich mit diesen Themen ernsthaft auseinanderzusetzen: Es ist jetzt.

Weiterführende Quellen