Ich glaube, ich muss mich an eine neue Denkweise gewöhnen, vielleicht nicht nur ich, sondern eine ganze Branche, die sich über Jahrzehnte daran gewöhnt hat, dass Softwareentwicklung vor allem dort passiert, wo Menschen Code lesen, Code schreiben, Code bewerten und Code verantworten.
In meinen letzten Beiträgen habe ich mehrfach darüber geschrieben, dass KI zwar Code erzeugen kann, aber nicht versteht, was wirklich zählt, dass Denken nicht durch Prompting ersetzt werden kann und dass echte Expertise nicht durch Abkürzungen entsteht. Ich halte all das weiterhin für richtig, vielleicht sogar für richtiger als zuvor, aber in den letzten Wochen habe ich eine Beobachtung gemacht, die mich trotzdem ins Grübeln gebracht hat.
Eine falsche Annahme
Ein Geschäftspartner von mir, ein echter Fachexperte in seinem Bereich, hat von mir meinen bevorzugten Entwicklungsstack eingerichtet bekommen, dazu eine Deployment Pipeline und Claude Code. Ich habe ihm damit im Grunde die Werkzeuge in die Hand gegeben, mit denen ich selbst arbeite, nur ohne die Annahme, dass daraus sofort ein ernstzunehmendes Softwareprojekt entstehen würde.
Diese Annahme war falsch.
Seitdem entwickelt er eine eigene Anwendung, die in seinem Fachbereich ihresgleichen sucht. Er weiß bis ins kleinste Detail, was eine perfekte Software können muss, welche Arbeitsschritte automatisiert werden sollten, welche Masken Fachanwender wirklich brauchen, welche Begriffe im Interface stehen müssen und welche Sonderfälle in der Praxis tatsächlich relevant sind. Er kann sich die fertige Software so klar vorstellen, dass er das Modell nicht mit technischen Konzepten steuern muss, sondern mit einem extrem präzisen Bild des gewünschten Ergebnisses.
Und das Erschreckende daran ist, sie funktioniert.
Er versteht keine einzige Zeile Code, zumindest nicht in dem Sinn, wie wir Entwickler das meinen. Er fragt nicht, ob die Architektur sauber ist, ob der Code elegant ist, ob die Komponenten schön getrennt sind oder ob eine Abstraktion an der richtigen Stelle sitzt. Er testet die Software, er prüft den Ablauf, er klickt sich durch die Fachlogik, er erkennt sofort, wenn ein Ergebnis fachlich falsch ist, und wenn es funktioniert, dann ist es für ihn gut genug.
Outcome statt Code
Für mich ist das unangenehm, weil ich anders denke. Ich will verstehen, welcher Code produziert wird, ich will nachvollziehen, warum eine Entscheidung so getroffen wurde, ich zwinge der KI manchmal meinen eigenen Willen auf, weil ich eine bestimmte Struktur, eine bestimmte Benennung oder eine bestimmte Architektur für richtig halte. Das ist nicht falsch, aber ich frage mich zunehmend, ob diese Denkweise in jedem Kontext noch die produktivste ist.
Der Fachexperte interessiert sich nicht für den Code, er interessiert sich für den Outcome. Wenn die Architektur für das erste Feature ungünstig gewählt wurde und das zweite Feature dadurch schwieriger wird, dann ist das für ihn kein Drama, weil die KI innerhalb weniger Minuten beides umbaut, bis es wieder funktioniert. Was ich früher als Kartenhaus gesehen hätte, das beim dritten Feature einstürzt, bleibt erstaunlich stabil, nicht weil der Code zwangsläufig schön ist, sondern weil die Kosten des Umbaus plötzlich so stark gesunken sind, dass schlechte frühe Entscheidungen nicht mehr automatisch wochenlange Folgeschäden verursachen.
Was bedeutet Wartbarkeit, wenn Änderungen billig werden?
Das widerspricht vielem, was wir gelernt haben, denn klassische Wartbarkeit beruhte immer auf der Annahme, dass Änderungen teuer sind. Wir haben saubere Schichten, klare Schnittstellen, konsistente Namenskonventionen und möglichst einfache Strukturen geschaffen, weil jede spätere Änderung von Menschen verstanden, geplant, implementiert und getestet werden musste. Wenn eine Änderung früher eine Woche Arbeit bedeutet hätte, dann war Wartbarkeit ein Schutz vor zukünftigen Kosten.
Aber was bedeutet Wartbarkeit, wenn dieselbe Änderung heute in vier Stunden erledigt ist, vielleicht morgen in vierzig Minuten und übermorgen über Nacht automatisch vorgeschlagen, umgesetzt und getestet wird?
Ich behaupte nicht, dass Architektur dadurch unwichtig wird. Ganz im Gegenteil. Sicherheit, Datenschutz, Rechtekonzepte, Datenintegrität, Nachvollziehbarkeit, Rollback Strategien und Betriebssicherheit verschwinden nicht, nur weil ein Modell schneller Code schreiben kann. In meinem Beitrag über KI und Verantwortung habe ich geschrieben, dass LLMs keine Verantwortung übernehmen können, und das bleibt der entscheidende Punkt. Aber die Frage verschiebt sich, denn vielleicht ist der Mensch mit der Verantwortung nicht mehr automatisch der Entwickler, der jede Zeile Code versteht, sondern derjenige, der das Ziel, die fachlichen Grenzen und die Konsequenzen des Systems am besten begreift.
Die Rollen drehen sich um
Genau hier wird es spannend, weil sich die Rollen plötzlich umdrehen.
Bisher war Softwareentwicklung oft ein Übersetzungsprozess. Ein Fachexperte erklärt einem Product Owner seine Welt, der Product Owner verdichtet daraus Anforderungen, ein Entwickler übersetzt diese Anforderungen in technische Strukturen, ein Tester prüft später, ob das Ergebnis ungefähr dem entspricht, was ursprünglich gemeint war. An jeder dieser Stationen geht Kontext verloren, weil Menschen nicht dieselben Begriffe verwenden, weil implizite Annahmen nicht ausgesprochen werden und weil fachliche Nuancen im technischen Prozess gerne zu Randnotizen schrumpfen.
Jetzt sitzt der Fachexperte direkt vor dem Werkzeug und beschreibt, was er braucht. Nicht perfekt, nicht immer sauber, nicht immer technisch sinnvoll, aber mit einer fachlichen Präzision, die ein externer Entwickler oft erst nach vielen Workshops erreicht. Gute Anforderungen sind, wie ich schon im Beitrag über AI Slop geschrieben habe, komprimierte Entscheidungen. Und wer könnte bestimmte Entscheidungen besser komprimieren als jemand, der den Fachbereich täglich lebt?
Das heißt nicht, dass jeder Fachexperte plötzlich Softwareentwickler wird. Es braucht Vorstellungskraft, Hartnäckigkeit, Freude am Bauen und die Fähigkeit, ein gewünschtes Ergebnis klar zu beschreiben. Es braucht Menschen, die nicht nur sagen können, was sie nicht wollen, sondern die ein Bild davon haben, wie ein besserer Prozess aussehen müsste. Aber diejenigen, die diese Kombination aus Fachwissen, Vision und Basteltrieb mitbringen, werden schwer aufzuhalten sein.
Habe ich mir mein eigenes Grab gegraben?
Mein Geschäftspartner geht mittlerweile noch einen Schritt weiter. Er nutzt in seiner Anwendung selbst mehrere LLMs, überwacht den Token Verbrauch, lässt Modelle auf eigens gebaute Tools zugreifen und automatisiert damit interne Arbeitsabläufe, die früher mehrere manuelle Schritte benötigt hätten. Das alles steckt in einer einzigen Software und mit einem Klick ist die Anwendung live.
An dieser Stelle stellt sich natürlich die unangenehme Frage, ob ich mir mein eigenes Grab gegraben habe, indem ich ihn ermächtigt habe. Vielleicht ja. Vielleicht habe ich ihm Werkzeuge gegeben, mit denen er Dinge selbst bauen kann, für die er früher mich gebraucht hätte. Aber selbst wenn ich es hinausgezögert hätte, wäre es vermutlich nur eine Frage der Zeit gewesen, bis er an denselben Punkt gekommen wäre.
Also bleibt die viel wichtigere Frage, was ich daraus lerne.
Was wir Entwickler lernen können
Vielleicht müssen wir Entwickler aufhören, die neue Entwicklung nur durch die Brille unseres bisherigen Berufsbildes zu betrachten. Vielleicht sollten wir weniger fragen, ob ein Fachexperte sauber genug entwickelt, und mehr fragen, warum er in manchen Situationen schneller zum besseren Produkt kommt. Vielleicht liegt seine Stärke gerade darin, dass ihn der Code nicht interessiert, weil er dadurch keinen Respekt vor unnötiger technischer Komplexität hat. Er akzeptiert keine Ausrede, warum ein Prozess unbequem bleiben muss, nur weil die bestehende Struktur das gerade nahelegt. Er will das Ergebnis und er testet gnadenlos aus Sicht der Menschen, die später damit arbeiten müssen.
Davon können wir etwas lernen.
Wir Entwickler neigen dazu, technische Schönheit mit Produktqualität zu verwechseln. Natürlich gibt es eine Verbindung zwischen beidem, aber sie ist nicht absolut. Eine fachlich mittelmäßige Software mit sauberer Architektur bleibt eine mittelmäßige Software, während eine fachlich brillante Software mit rauen technischen Kanten in der Praxis oft sofort Wert schafft. Früher hätten diese Kanten das System irgendwann unwartbar gemacht, heute müssen wir zumindest neu bewerten, welche Kanten wirklich gefährlich sind und welche nur unseren Geschmack beleidigen.
Eine komplexe Schnittstelle, bei der der Betreiber selbst meint, dass es im Schnitt zwei bis drei Wochen dauert, bis die ersten Rückfragen kommen, hat dieser Fachexperte in einer Stunde eingebaut. Und ja, sie funktioniert ohne Probleme. Zwei weitere Stunden später existierte ein User Interface, das für Fachanwender bequemer und nachvollziehbarer ist als alles, was es in diesem Bereich bisher gab.
Ein Warnsignal für Softwarehäuser
Das ist keine Kleinigkeit, sondern ein Warnsignal für Softwarehäuser.
Wer weiterhin glaubt, dass der eigene Wert hauptsächlich darin liegt, Anforderungen entgegenzunehmen und daraus in mehreren Wochen oder Monaten Software zu bauen, wird es schwer haben. Der Markt wird sich nicht dafür interessieren, ob ein Fachexperte den Code versteht, solange das Ergebnis funktioniert, sicher betrieben werden kann und schneller verfügbar ist als jede klassische Projektumsetzung. Softwarehäuser müssen sich neu erfinden, weg vom reinen Umsetzer, hin zum Ermöglicher, Beschleuniger, Architekten, Qualitätssicherer und Betreiber von sicheren Rahmenbedingungen, in denen Fachleute ihre Prozesse selbst formen können.
Die Zukunft gehört nicht denjenigen, die Fachanwender klein halten, damit sie weiterhin Tickets schreiben müssen. Sie gehört denjenigen, die Fachanwender befähigen und gleichzeitig dafür sorgen, dass Sicherheit, Datenqualität, Architektur und Betrieb nicht dem Zufall überlassen werden.
Für mich persönlich fühlt sich das gleichzeitig bedrohlich und motivierend an. Ja, ich mache mir leichte Sorgen, weil ich sehe, wie schnell sich die Grenzen verschieben. Aber statt mich an eine alte Vorstellung von Softwareentwicklung zu klammern, sollte ich auf diesen Zug aufspringen und das machen, was ich am besten kann, nämlich Software entwickeln, nur in einer Geschwindigkeit, die bis vor kurzem noch unvorstellbar war.
Und ehrlich gesagt macht es auch richtig Spaß.
Fazit: Die Programmiersprache hat sich geändert
Die Quintessenz ist einfach, die Programmiersprache hat sich geändert. Sie ist nicht mehr nur PHP, JavaScript, Python oder SQL. Sie ist Deutsch oder Englisch, und die Qualität hängt immer stärker davon ab, wie klar, konkret und widerspruchsfrei ich meine Anforderungen beschreiben kann. In genau dieser Disziplin ist der gute Fachexperte dem reinen Entwickler oft überlegen, weil er nicht über technische Möglichkeiten nachdenkt, sondern über fachliche Notwendigkeiten.
Das bedeutet nicht, dass Entwickler verschwinden. Es bedeutet aber, dass Entwickler, die nur Code produzieren, austauschbarer werden. Entwickler, die Fachlichkeit verstehen, Anforderungen schärfen, Systeme absichern, Architektur bewusst gestalten und KI Werkzeuge mit klarem Urteil führen können, werden wertvoller als je zuvor.
Vielleicht ist das die eigentliche Verschiebung. Nicht der Entwickler wird durch KI ersetzt, sondern die Distanz zwischen Fachwissen und Software wird kleiner. Wer diese Distanz früher verwaltet hat, muss sich neu erfinden. Wer sie verkleinert, wird gewinnen.
Haltet euch fest, Softwarehäuser, eure Zeiten werden schwerer, wenn ihr euch nicht neu erfindet.