In meiner Zeit als Entwickler und generell in Softwareprojekten habe ich immer wieder zwei sehr unterschiedliche Typen von Softwareentwicklern kennengelernt. Der Unterschied liegt weniger im Können oder im Wissen, sondern vor allem in der Herangehensweise bei der Lösungsfindung. Beide Gruppen können zu sehr guten Ergebnissen kommen, aber sie arbeiten auf völlig unterschiedliche Weise.

Ich selbst gehörte immer zu den Entwicklern, die sich zunächst lange Gedanken machen. Bevor die ersten Zeilen Code entstehen, steht bei mir meist eine Phase der Analyse und Konzeption. Ich überlege mir mögliche Architekturen, entwerfe Strukturen und versuche, das Problem möglichst umfassend zu verstehen. Erst wenn sich ein klares Bild ergibt, beginne ich mit der eigentlichen Implementierung. Das hat den Vorteil, dass viele Entscheidungen bereits getroffen sind, bevor sie im Code sichtbar werden.

Diese Vorgehensweise hat allerdings eine kleine Schwäche, zumindest aus Sicht vieler Kunden. Sie sehen gerne möglichst früh etwas Greifbares. Wenn über längere Zeit nichts Sichtbares entsteht, werden sie schnell unruhig. Sobald die eigentliche Entwicklung beginnt, geht es zwar oft sehr schnell voran und die Begeisterung ist groß, aber die Phase davor muss man häufig mit kleinen sichtbaren Fortschritten überbrücken, damit Vertrauen und Geduld erhalten bleiben.

Andere Entwickler haben dieses Problem kaum. Sie steigen direkt mit dem Code ein und lassen das Konzept während der Arbeit entstehen. Ideen werden unmittelbar ausprobiert, Ansätze getestet und bei Bedarf auch wieder verworfen. Für sie ist es selbstverständlich, Code neu zu schreiben oder ganze Teile zu ersetzen, wenn sich während der Entwicklung bessere Lösungen ergeben. Dabei entsteht oft ein Flow, in dem man Schritt für Schritt weiterkommt und sich die Lösung organisch entwickelt.

Auch dieses Vorgehen hat jedoch seine eigene Dynamik in der Zusammenarbeit mit Kunden. Zwar gibt es sehr früh etwas zu sehen, doch danach kann es Phasen geben, in denen sich aus Kundensicht scheinbar wenig bewegt. Vieles passiert im Hintergrund: Refactoring, neue Ansätze, verworfene Ideen und erneute Versuche. Für Außenstehende wirkt es dann manchmal so, als würde der Fortschritt langsamer werden, obwohl intern intensiv gearbeitet wird.

Wenn man sich heutige Diskussionen über Begriffe wie Vibe Coding und Context Engineering anschaut, erkennt man erstaunlich viele Parallelen zu diesen beiden klassischen Arbeitsweisen. Beim Context Engineering wird zunächst der Kontext aufgebaut, strukturiert und vorbereitet, bevor er an eine KI übergeben wird. Das erinnert stark an die Entwickler, die zuerst ein Konzept ausarbeiten und erst später mit der eigentlichen Umsetzung beginnen.

Beim Vibe Coding hingegen entsteht der Kontext während der Arbeit mit der KI. Man probiert Dinge aus, passt Prompts an, verwirft Ergebnisse und tastet sich iterativ an eine Lösung heran. Genau wie beim Entwickler, der direkt mit dem Coden beginnt und das Konzept währenddessen wachsen lässt.

Was nun besser oder schlechter ist, lässt sich kaum eindeutig beantworten. Viel hängt von persönlichen Vorlieben ab, aber auch davon, welche Informationen zu Beginn vorhanden sind und welche Erwartungen der Kunde hat. Manche Projekte profitieren von einer klaren Konzeptphase, andere von einem experimentelleren Ansatz.

Interessant ist vor allem, dass die aktuellen KI-Diskussionen im Kern keine völlig neuen Arbeitsweisen hervorbringen. Sie greifen vielmehr bekannte Konzepte der Softwareentwicklung auf und machen sie sichtbarer. Die Werkzeuge ändern sich, doch die grundlegenden Denkweisen bleiben erstaunlich konstant. KI verstärkt diese Unterschiede lediglich und räumt gleichzeitig viele Nebengeräusche aus dem Weg, die sie früher überlagert haben.