Die Softwareentwicklungsbranche verändert sich – dauerhaft

Im Jahr 2003 gründete ich DCSL Software, das später zu One Beyond wurde. Ich stieg 2023 aus, nachdem ich das Unternehmen internationalisiert und auf mehr als 300 Mitarbeiter ausgebaut hatte. Seitdem habe ich ein Robotik-Start-up gegründet und über 4 Millionen Pfund Seed-Finanzierung eingeworben.

Ich hätte nie erwartet, wieder Produktionssoftware zu schreiben. Ich hörte 2014 auf, täglich zu programmieren, nicht weil ich es nicht konnte, sondern weil das passiert, wenn ein Unternehmen wächst. Man stellt Leute ein, die besser in der Umsetzung sind, man konzentriert sich auf Führung, und allmählich rückt die Tastatur in weitere Ferne. Fast ein Jahrzehnt lang fühlte sich das völlig natürlich an.

Was ich nicht erwartet hatte, war, dass ich mich fast zehn Jahre später wieder auf dem Entwicklerstuhl wiederfinden würde – nicht nostalgisch, sondern praktisch. Nicht herumspielend, sondern eine wirklich komplexe Robotik-Plattform aufbauend. Und nicht, indem ich jedes Framework oder jede Sprache, die an mir vorbeigegangen war, neu lernte, sondern indem ich auf eine grundlegend andere Weise arbeitete.

Diese persönliche Veränderung ist das deutlichste Signal, das ich gesehen habe, dass sich etwas Strukturelles in der Softwareentwicklung verändert hat.

Wie wir früher Software entwarfen – und warum

Als ich anfing, waren wir fest in der Wasserfall-Ära. Das war keine Ideologie, es war Ökonomie. Software war langsam und teuer zu entwickeln, also war der einzige vernünftige Ansatz, im Vorfeld sehr gründlich nachzudenken.

Wir schrieben detaillierte Spezifikationen, weil wir mussten. Verträge hingen davon ab. Die Lieferung hing davon ab. Eine gute Spezifikation zu schreiben war eine Spezialfähigkeit, und eine, in der ich zufällig recht gut war. Ich konnte visualisieren, wie das fertige Produkt aussehen könnte, bevor es existierte, Bereiche der Komplexität vorhersehen und Verhalten mit genug Präzision beschreiben, dass ein Team dagegen entwickeln konnte.

Diese Fähigkeit war selten und schwer zu lehren. Viele Menschen hatten Schwierigkeiten damit, weil es sich ein komplexes System vorzustellen, das noch nicht existiert, wirklich schwer ist. Aber es war wichtig, denn Fehler spät im Prozess zu machen, war schmerzhaft und teuer.

Im Laufe der Zeit bewegte sich die Branche in Richtung Agile. Öffentlich wurde dies als bessere Art dargestellt, auf Änderungen zu reagieren. Stillschweigend war es auch eine Anerkennung, dass bei großen, langfristigen Systemen keine Spezifikation unverändert überlebt. Unternehmen ändern sich, Benutzer ändern sich, Technologie ändert sich, und so zu tun, als ob dem nicht so wäre, verursachte oft mehr Schaden als Nutzen.

Agile war pragmatisch, aber es kam mit Kosten. Wir gaben weitgehend das tiefgehende Vorab-Design auf und ersetzten es durch schrittweise Entdeckung. Das funktionierte, aber es normalisierte auch eine Denkweise, bei der es als unnötig oder sogar riskant angesehen wurde, zu weit vorauszudenken.

Was sich änderte – und warum ich wieder zu bauen begann

Der Grund, warum ich in der Lage war, zur praktischen Entwicklung zurückzukehren, ist nicht, dass ich plötzlich die Zeit oder den Wunsch fand, ein Jahrzehnt an Werkzeugen neu zu erlernen. Es ist, weil KI die Kosten des Experimentierens grundlegend verändert hat.

Dies ist der Teil, der oft missverstanden wird. Die echte Veränderung ist nicht, dass Code schneller zu schreiben ist. Es ist, dass das Ausprobieren von Dingen jetzt günstig, schnell und weitgehend reversibel ist.

Dinge, die früher Entwicklerwochen gedauert hätten, können jetzt in Minuten versucht werden. Man kann einen Ansatz erkunden, sehen, wie er sich anfühlt, ihn vollständig verwerfen und mit sehr geringem Aufwand eine andere Richtung ausprobieren. Das war vorher einfach nicht möglich.

In der Vergangenheit gab es eine starke emotionale und finanzielle Bindung an Code. Wenn etwas zwei Entwickler drei Wochen zum Bauen brauchte, war man verständlicherweise zögerlich, es wegzuwerfen. Entscheidungen verhärteten sich früh, nicht immer weil sie richtig waren, sondern weil es zu kostspielig war, sie rückgängig zu machen.

Diese Einschränkung ist verschwunden, und das ist es, was mich zurückgezogen hat. Ich kann jetzt auf der Ebene operieren, auf der ich am stärksten bin – das Problem verstehen, das System gestalten, erkennen, wenn Komplexität einschleicht – während KI die Mechanik übernimmt. Ich schreibe keinen Code so, wie ich es in meinen Zwanzigern tat. Ich leite ihn, verfeinere ihn, korrigiere ihn und halte ihn gelegentlich davon ab, in eine völlig falsche Richtung zu gehen. In der Praxis fühlt sich das viel mehr nach Teamleitung als nach Programmieren an. Man ist effektiv der Chef – gibt die Richtung vor, überprüft die Ausgabe, erkennt faule Abkürzungen und wehrt sich, wenn sich etwas nicht richtig anfühlt.

Warum Design immer noch wichtig ist – mehr denn je

Es wäre leicht anzunehmen, dass diese neue Freiheit Design weniger wichtig macht. In Wirklichkeit macht es es wichtiger.

Eine klare, detaillierte Vorstellung davon zu haben, was man zu bauen versucht, ist immer noch enorm wertvoll. Tatsächlich verbessert es aktiv die KI-Ausgabe. Je klarer die Absicht, desto besser die Ergebnisse. Vages Denken produziert einfach vage Systeme schneller. Was wichtig zu verstehen ist, ist, dass KI sich sehr wie eine Person verhält. Sie möchte hilfreich sein. Sie möchte eine Antwort geben. Wenn man vage ist, wird sie die Lücken füllen. Wenn man unvorsichtig ist, wird sie Annahmen treffen. Wenn man sie nicht herausfordert, wird sie selbstbewusst den falschen Weg weitergehen.

Der Unterschied ist, dass Design nicht länger ein sprödes, einmaliges Artefakt ist, das jahrelang unverändert überleben muss. Es ist zu einem Leitfaden für Experimente geworden, anstatt eine Einschränkung dafür zu sein. Man kann eine starke Vision davon haben, wohin man geht, während man immer noch bereit ist, den Weg dorthin auszuprobieren, zu verwerfen und weiterzuentwickeln.

Die neue Fähigkeit besteht darin zu wissen, wann Erkundung produktiv ist und wann es nur Rauschen ist. KI wird fröhlich weiterhin Struktur generieren, lange nachdem sie hätte vereinfacht werden sollen. Sie weiß nicht, wann eine Datei zu groß geworden ist, wann eine Abstraktion undicht ist oder wann etwas, das heute „funktioniert", später Schmerzen verursachen wird. Diese Instinkte kommen immer noch aus der Erfahrung.

Was das in der Branche zerbricht

Sobald Experimente günstig werden, hören viele lang gehaltene Annahmen auf zu gelten. Planung geht nicht mehr darum, im Voraus alles festzulegen. Es geht darum, Absicht, Einschränkungen und Grenzen zu setzen.

Schätzung wird weniger darum, Aufwand vorherzusagen, und mehr darum, den Raum zu verstehen, den man erkundet.

Und unsere Beziehung zu Code ändert sich vollständig. Es gibt weit weniger Bindung an spezifische Implementierungen und weit mehr Fokus auf Verhalten, Struktur und Ergebnisse.

Deshalb fühlt sich die Softwareentwicklungsbranche unruhig an. Viele Menschen versuchen, alte mentale Modelle auf neue Werkzeuge anzuwenden. Das funktioniert eine Weile, aber es verfehlt den Punkt.

Die echte Veränderung

Der Grund, warum ich zuversichtlich bin, dass diese Veränderung dauerhaft ist, ist einfach: Ich würde sonst nicht wieder bauen.

Der einzige Grund, warum ich glaubwürdig nach einem Jahrzehnt zur praktischen Entwicklung zurückkehren kann, ist, dass die Einschränkungen, die mich anfangs hinausgedrängt haben, nicht mehr gelten. Software kann jetzt durch geführtes Experimentieren auf eine Weise evolvieren, die vorher einfach nicht möglich war.

Das bedeutet nicht, dass Erfahrung weniger wichtig ist. Es bedeutet, dass sie anders wichtig ist. Der Wert liegt nicht mehr darin, sich Syntax oder Frameworks zu merken. Er liegt in Urteilsvermögen, Struktur und zu wissen, wann man aufhören sollte.

Dies ist nicht das Ende der Softwareentwicklung. Aber es ist das Ende des alten Modells. Und sobald man auf diese Weise gearbeitet hat, gibt es kein Zurück mehr.