Software soll schneller entstehen, gleichzeitig steigen die Anforderungen an Qualität, Sicherheit und Wartbarkeit. Rapid Software Development versucht, diesen Zielkonflikt aufzulösen. Frank Rudolf und Dustin Augstein erklären, welche Rolle Architektur, Automatisierung und KI dabei spielen – und warum mehr Geschwindigkeit vor allem klare Strukturen und Verantwortung braucht.
Von Frank Rudolf, Dustin Augstein und Philipp Ebnet
Der Druck auf Entwicklungsteams wächst: Digitale Produkte und neue Funktionen sollen schneller verfügbar sein, während Anwendungen zuverlässig, sicher und langfristig betreibbar bleiben müssen. Rapid Software Development setzt deshalb darauf, früh sichtbare Ergebnisse zu schaffen und Lösungen anschließend schrittweise weiterzuentwickeln. Ein funktionierendes Frontend bedeutet dabei noch lange nicht, dass eine Anwendung bereits Enterprise-fähig ist.
Geschwindigkeit entsteht dabei nicht allein durch schnelleres Programmieren. Wiederkehrende Aufgaben beim Aufsetzen von Entwicklungsumgebungen, CI/CD-Pipelines oder Infrastruktur lassen sich automatisieren. Gleichzeitig schaffen eine übergreifende Corporate Architecture, gemeinsame Templates und klare technische Leitplanken die Grundlage dafür, dass Teams nicht für jedes Projekt dieselben Strukturen neu entwickeln müssen. Auch KI verändert diesen Prozess. Sie kann bestehenden Code erweitern, Boilerplate-Code erzeugen und teilweise Unit-Tests erstellen. Bei Konzeption und Architektur bleibt jedoch erfahrene menschliche Steuerung entscheidend. Ohne klare technische Leitplanken kann schnell viel Code entstehen, der langfristig schwer wartbar oder erweiterbar ist.
Die Folge zeigt:
Die Folge richtet sich an IT-Entscheider, Product Owner, Projektverantwortliche, Softwarearchitekten und Entwickler, die Entwicklungsprozesse beschleunigen möchten und sich mit der Frage beschäftigen, wie sich KI, Automatisierung und moderne Softwarearchitekturen sinnvoll miteinander verbinden lassen.
Zum Nachlesen: das vollständige Gespräch mit Sprecherwechsel. Das Transkript wurde KI-gestützt erstellt und redaktionell geprüft.
Philipp Ebnet, CGI: Herzlich willkommen zu einer neuen Folge unseres Podcasts Digitalwandler. Ich bin Philipp und möchte erfahren, wie es um die Digitalisierung in Deutschland steht. Dafür lade ich alle zwei Wochen Expertinnen und Experten ins virtuelle Studio ein, die Fragen zu Best Practices, ungenutzten Chancen und Verbesserungsbedarf beantworten. Heute geht es um Geschwindigkeit. Unternehmen stehen zunehmend unter Druck, Software schneller bereitzustellen. Der DORA-Bericht 2025 zeigt beispielsweise, dass KI in der Softwareentwicklung hilfreich sein kann, zugleich aber bestehende Stärken und Schwächen einer Organisation verstärkt. Entscheidend ist demnach das zugrunde liegende organisatorische System. Auch die Cloud Native Computing Foundation, kurz CNCF, weist darauf hin, dass interne Plattformen die Arbeit von Produkt- und Anwendungsteams beschleunigen können, wenn sie gemeinsame Fähigkeiten, Prozesse, Policies und Technologien kuratiert bereitstellen. Wie solche Plattformen aussehen können, wie Unternehmen mit dem wachsenden Geschwindigkeitsdruck umgehen und wie sich entsprechende Ansätze in der eigenen Organisation etablieren lassen, darüber spreche ich heute mit Frank Rudolf und Dustin Augstein. Frank verfügt über langjährige Erfahrung im Projektmanagement im IT-Umfeld und ist AI Lead im Defense-Sektor bei CGI Deutschland. Dustin ist Softwarearchitekt und hat viel Erfahrung mit Containerisierung und KI. Die beiden kennen sich seit 20 Jahren. Nach unterschiedlichen Karrierewegen - Frank war unter anderem bei der Bundeswehr, Dustin arbeitete für verschiedene Forschungsinstitute - arbeiten beide heute bei CGI Deutschland zusammen. Hi Frank, hi Dustin, schön, dass ihr da seid.
Frank Rudolf, CGI: Hallo Philipp.
Dustin Augstein, CGI: Hallo!
Philipp Ebnet, CGI: Viele Unternehmen stehen heute unter Druck, digitale Produkte, interne Anwendungen und Funktionen schneller bereitzustellen. In diesem Zusammenhang fallen Begriffe wie Rapid Software Development oder Rapid Application Development. Was verbirgt sich dahinter und wie würdet ihr diese Ansätze einordnen? Frank, möchtest du anfangen?
Frank Rudolf, CGI: Ich sehe darin eine Evolution des IT-Projektmanagements. Früher wurden IT-Projekte häufig mit klassischen Wasserfallmodellen umgesetzt, später kamen agile Modelle hinzu. Mit den neuen technischen Möglichkeiten, die KI mitbringt, reichen diese Modelle für die heutigen Anforderungen teilweise nicht mehr aus. Rapid Software Development oder Rapid Application Development verfolgt im Kern das Ziel, Stakeholdern so schnell wie möglich etwas Sichtbares zu zeigen und die Enterprise-Fähigkeit anschließend schrittweise nachzuziehen.
Philipp Ebnet, CGI: Welche Missverständnisse begegnen dir bei diesem Ansatz besonders häufig?
Frank Rudolf, CGI: Das größte Missverständnis betrifft die Erwartungshaltung. Ein Frontend kann bereits so aussehen, wie es der Kunde haben möchte, obwohl die Applikation noch nicht Enterprise-fähig ist. Dafür ist weitere Arbeit notwendig und es braucht Experten, die eine Lösung sicher und nachhaltig betreibbar machen. Das sind unterschiedliche Aspekte, die sich aber miteinander verbinden lassen, um auch die Enterprise-Fähigkeit von Applikationen schneller herzustellen als bisher.
Philipp Ebnet, CGI: Warum ist Geschwindigkeit in der Softwareentwicklung heute wichtiger geworden?
Frank Rudolf, CGI: Das betrifft aus meiner Sicht alle Unternehmen und Branchen. Häufig sprechen wir von Time-to-Market, aber auch intern wollen Unternehmen produktiver werden und können sich sehr große, lang laufende Projekte oft nicht mehr leisten. Ziel ist es, schnell Ergebnisse zu erzielen, KI sinnvoll in der Softwareentwicklung einzusetzen und den Mehrwert der verfügbaren Technologien möglichst schnell zu nutzen.
Philipp Ebnet, CGI: Woran können Entscheider merken, ob sie in der richtigen Geschwindigkeit entwickeln oder zu langsam sind?
Frank Rudolf, CGI: Eine eindeutige KPI gibt es dafür nicht. Das ist schwer zu greifen. Wir arbeiten viel in Projekten der öffentlichen Hand, in denen häufig sehr viele Einzelanforderungen definiert und entsprechend vergeben werden. Für Kunden ist es dann oft schwer nachzuvollziehen, wenn man auf einen anderen methodischen Ansatz setzt, mit dem man möglicherweise schneller zum Ziel kommt. Das ist kommunikativ anspruchsvoll. Mit einer flexibleren Projektsteuerung kann man schneller vorankommen und zugleich den Kommunikationsaufwand reduzieren. Statt einzelne Anforderungen am Ende nur abzuhaken, arbeitet man auf eine Vision hin und stimmt sich kontinuierlich mit dem Kunden ab. So wird das Produkt Schritt für Schritt reifer und schließlich praxistauglich.
Philipp Ebnet, CGI: Dustin, du bist näher an der praktischen Anwendung. Welche Aufgaben eignen sich heute besonders gut für KI-Unterstützung?
Dustin Augstein, CGI: KI soll Entwicklungsprozesse vor allem beschleunigen. Jedes Unternehmen möchte schneller und effizienter werden, und im Entwicklungsprozess gibt es viele Bereiche mit entsprechendem Potenzial. Die große Herausforderung besteht darin, dabei die Qualität nicht zu vernachlässigen. Gerade beim Vibe Coding kann die Qualität schnell abnehmen. Entscheidend ist deshalb, die richtigen Tools auszuwählen und KI gezielt dort einzusetzen, wo sie Geschwindigkeit erhöht, ohne dass die Qualität darunter leidet.
Philipp Ebnet, CGI: Wo wird die Wirkung von KI aus deiner Sicht überschätzt?
Dustin Augstein, CGI: Das zeigt sich auch in der öffentlichen Diskussion. Ich werde häufig gefragt, warum man mit Vibe Coding überhaupt noch Entwickler braucht, wenn scheinbar alles automatisch funktioniert. Das ist deutlich überzeichnet. Im amerikanischen Markt haben Unternehmen Mitarbeiter mit der Begründung entlassen, dass KI ihre Aufgaben übernehmen könne. Teilweise zeigt sich inzwischen, dass die Qualität darunter leidet, Produkte nicht mehr vermarktbar sind oder bestimmte Prozesse nicht mehr ausreichend bedient werden können, sodass Mitarbeiter zurückgeholt werden. Stand heute ist KI ein sehr gutes Werkzeug zur Unterstützung, ersetzt Entwickler aber nicht.
Philipp Ebnet, CGI: KI kann also für mehr Geschwindigkeit sorgen. Wo geht unabhängig von den eingesetzten Tools im Entwicklungsprozess typischerweise Zeit verloren?
Dustin Augstein, CGI: Vor allem bei wiederkehrenden Aufgaben, die vor der eigentlichen Entwicklung notwendig sind: beim Aufsetzen von Git-Repositories und CI/CD-Pipelines, bei der Infrastruktur oder bei den Stages, auf denen Software ausgerollt und getestet wird. Gerade bei Containerisierung und Microservices wiederholen sich diese Schritte immer wieder. Genau dort lässt sich durch Automatisierung deutlich beschleunigen.
Philipp Ebnet, CGI: Das betrifft also auch die Architektur?
Dustin Augstein, CGI: Auf jeden Fall. Entwicklungsprozess und gewählte Architektur sind eng miteinander verzahnt. Bei einer Microservice-Architektur wird ein großer Gesamtservice in kleinere Teilbereiche aufgeteilt, sodass bei Update-Zyklen nur einzelne Bereiche aktualisiert werden müssen. Das bringt Vorteile, schafft aber auch neue Herausforderungen, etwa beim Datenaustausch zwischen Services oder bei Message Queues. Wenn ich den Entwicklungsprozess beschleunigen möchte, muss ich deshalb auch die Architektur entsprechend anpassen.
Philipp Ebnet, CGI: Frank, wo können Architekturentscheidungen, fehlende Architektur oder Unklarheiten die Entwicklung ausbremsen?
Frank Rudolf, CGI: Ich würde nicht unbedingt von Fehlern sprechen, denn Architekturentscheidungen werden auf Grundlage von Anforderungen getroffen, und Anforderungen können sich im Projektverlauf ändern. Früher führte eine solche Änderung häufig dazu, dass große Teile eines Projekts neu gedacht werden mussten, weil Anforderungen sehr linear abgearbeitet wurden. Heute ist Architektur eines der wichtigsten Kommunikationsmittel - sowohl im Team als auch mit dem Kunden. Viele Kunden verfügen inzwischen über eigenes IT-Know-how und können auf Architekturebene mitdiskutieren. Gleichzeitig wird darüber sichtbar, welche Komplexität hinter einer Umsetzungsaufgabe steckt. Kommunikation ist eine wesentliche Grundlage solcher Projekte, und Architektur unterstützt diese Kommunikation entscheidend.
Philipp Ebnet, CGI: Was sollte zu Beginn geklärt werden, damit später keine unerwarteten Kosten oder Probleme entstehen?
Frank Rudolf, CGI: Man kann das technisch und aus Projektmanagementsicht betrachten. Aus meiner Sicht braucht eine Organisation zunächst eine Corporate Architecture. Sie muss grundsätzlich wissen, wie sie arbeiten und wie Software und Technologien betrieben werden sollen. Das bildet die Grundlage für alle weiteren Schritte. Auf Basis dieser Corporate Architecture kann ein Softwarearchitekt leichter kommunizieren und ein konkretes Projekt darin umsetzen. Häufig fehlt eine solche übergreifende Vision, weil einzelne Projekte historisch unabhängig voneinander gewachsen sind und dadurch heterogene IT-Landschaften entstanden sind. Mit Microservice-Architekturen wird eine Gesamtvision noch wichtiger. Sonst baut man dieselben Dinge mehrfach auf, was erhebliche Kosten verursacht. Die Transformation von heterogenen Systemlandschaften in eine komplexe, Microservice-orientierte Welt ist deshalb ein zentraler Knackpunkt und erfordert entsprechende Beratung.
Philipp Ebnet, CGI: Dustin, hast du eine fehlende Corporate-Architecture-Vision in der Praxis erlebt? Welche Auswirkungen hatte das auf deine Arbeit?
Dustin Augstein, CGI: Ja, vielleicht noch einen Schritt weiter vorne angefangen: Das beginnt beim Product Manager. Er bekommt die Anforderungen des Kunden vorgelegt und entwickelt daraus eine Vision. Wie stellt er sich das Zielbild dieser Anwendung vor?
Meine Aufgabe ist es dann, dieses fachliche Zielbild auf eine gute Softwarearchitektur herunterzubrechen und zu übertragen. Die große Herausforderung besteht dabei – ihr hattet das auch schon angesprochen – darin, die Architektur so zu gestalten, dass sie sich möglichst leicht erweitern lässt. Auch Anforderungen, die erst später hinzukommen, sollten sich gut integrieren lassen, ohne dass man die gesamte Architektur wieder umwerfen muss.
Als wir noch nicht so viel Erfahrung hatten wie heute, kam es durchaus vor, dass wir mit der Architektur begonnen und Microservices entwickelt haben, die jeweils unterschiedlich aufgebaut waren. Wir hatten ein größeres Team, und verschiedene Entwickler haben sich um unterschiedliche Microservices gekümmert. Die einzelnen Entwicklergruppen sind dann losgelaufen und haben ihre Microservices so entwickelt, wie sie es jeweils für richtig hielten. Natürlich ist dabei auch jeder mit seinem eigenen Ansatz und Geschmack an die Sache herangegangen.
Schwierig wurde es, wenn Entwickler zwischen den Microservices wechseln mussten. Dann mussten sie sich jedes Mal neu hineindenken. Dadurch gab es große Unterschiede in der Qualität und auch in der Ausbringung der Services.
Und genau das ist es, was man mit dieser Corporate Architecture erreichen möchte: eine Homogenisierung, sodass der grundlegende Aufbau der Microservices gleich ist. Der Nachteil der unterschiedlichen Architekturen war vor allem, dass sich die Entwicklungszeit durch die zusätzlichen Einarbeitungszeiten erhöht hat. Das galt sowohl beim Wechsel zwischen den Microservices als auch dann, wenn neue Entwickler ins Team kamen.
Philipp Ebnet, CGI: Standards können die Qualität erhöhen. Wie schafft ein Unternehmen gleichzeitig genügend Freiraum, damit Entwickler ihre Fähigkeiten und Kreativität einbringen können?
Dustin Augstein, CGI: Kreativer Freiraum ist eng mit Motivation verbunden. Gerade bei verteilter Arbeit und im Homeoffice ist es wichtig, dass Entwickler motiviert bleiben und Technologien einsetzen können, mit denen sie gerne arbeiten. Gleichzeitig darf kein Wirrwarr entstehen. Deshalb braucht es ein gemeinsames Gerüst. Man kann beispielsweise Templates für Python-, Java- oder .NET-Microservices bereitstellen, in denen die Grundstruktur bereits vorgegeben ist. Entwickler erhalten Anwendungsbeispiele und wissen, wie sie etwa Datenquellen oder andere Services anbinden können. Innerhalb dieses Rahmens können sie frei entwickeln und zwischen vorbereiteten Technologien wählen. Gleichzeitig enthält das Grundgerüst Vorgaben der Corporate Architecture und grundlegende Security-Mechanismen.
Frank Rudolf, CGI: Ergänzend dazu ist die technische Vorbereitung nur ein Teil. Wenn Entwickler ihre Aufgaben mit den Themen und Programmiersprachen umsetzen können, die ihnen liegen, werden sie meist automatisch schneller. Freiraum und die Verantwortung für einzelne Arbeitspakete fördern außerdem die Motivation. Gleichzeitig entsteht Geschwindigkeit dadurch, dass die organisatorische Vorarbeit nur einmal geleistet werden muss. Wenn die Corporate Architecture definiert ist und die Entwickler sie kennen, lassen sich neue Anforderungen oder neue Softwareprodukte deutlich schneller umsetzen.
Philipp Ebnet, CGI: Auf welcher Organisationsebene sollte die Entwicklung solcher Plattformen und Templates verankert sein? Wer sollte an den Entscheidungen über ihre Ausgestaltung beteiligt sein?
Frank Rudolf, CGI: Es gibt zwei Ebenen. Auf Kundenseite sollte ein Enterprise Architect grundlegende Vorgaben machen. Auf Projektebene übernimmt diese Aufgabe in der Regel der Softwarearchitekt. Für ihn ist es anspruchsvoll, Anforderungen so generisch herunterzubrechen, dass sie als Templates nutzbar sind und schnell wieder Output erzeugt werden kann. Entscheidend ist deshalb die Zusammenarbeit zwischen dem Softwarearchitekten des Projekts und dem Enterprise Architect des Kunden oder der eigenen Organisation. Wenn beide gut zusammenarbeiten und die richtigen Werkzeuge zur Verfügung stehen, lassen sich sehr schnell Ergebnisse erzeugen. Dagegen ist es beispielsweise aufwendig, ständig Visio-Diagramme zu pflegen und sicherzustellen, dass immer die aktuelle Version verwendet wird, ohne dass daraus unmittelbar Mehrwert entsteht.
Philipp Ebnet, CGI: Welche Tools oder Praxisansätze haben sich für euch bewährt? Frank, vielleicht zunächst aus Projektsicht, anschließend kann Dustin die Entwicklerperspektive ergänzen.
Frank Rudolf, CGI: Es gibt viele Tools am Markt, aber wir haben festgestellt, dass keines davon alle unsere Anforderungen abdeckt. Gleichzeitig wollten wir vermeiden, täglich 15 verschiedene Tools bedienen zu müssen, weil das zusätzliche Komplexität, Schulungsaufwand und Zeit kostet. Deshalb haben wir vor einigen Jahren ein eigenes Tool entwickelt, mit dem wir den Prozess von der Architektur bis zum Deployment managen und die Corporate-Architecture-Vision nachhaltig umsetzen können. Damit können wir Microservices sehr schnell ausrollen, weiterentwickeln und in bestehende Architekturen integrieren.
Philipp Ebnet, CGI: Dustin, kannst du das technisch noch etwas einordnen?
Dustin Augstein, CGI: Ja, natürlich ist die Gesamtthematik bekannt. Dementsprechend gibt es auch verschiedene Tools. Aber wir haben gerade schon versucht zu erklären, dass es letztlich um eine Kombination geht: um den Einsatz von Tools, eine entsprechende prozessuale Ausrichtung des Teams und darum, diesen Prozess mit den richtigen Anwendungen zu unterstützen.
Als wir uns dann angeschaut haben, welche Anwendungen es dafür bereits auf dem Markt gibt, haben wir immer nur Lösungen für einzelne Teilbereiche gefunden. Das hat uns schließlich dazu gebracht, unser eigenes Tool zu entwickeln, das diese verschiedenen Aspekte miteinander kombiniert.
Wenn man damit beispielsweise eine Architektur zeichnet, kann man diese Zeichnung anschließend auch direkt praktisch anwenden und deployen. Gleichzeitig entsteht daraus eine Dokumentation, und auch der gesamte Entwicklungsprozess lässt sich damit unterstützen.
Philipp Ebnet, CGI: Ein zentrales Ziel ist also, Komplexität zu reduzieren und nicht mit einer Vielzahl einzelner Tools arbeiten zu müssen. Was kann ein Tool leisten und welche Aufgaben bleiben trotzdem bei Führungskräften und der Organisation?
Dustin Augstein, CGI: Wenn wir die Thematik von vorhin noch einmal aufgreifen, stellt sich natürlich die Frage: Wer bestimmt eigentlich diese Templates? Ich glaube, dabei spielt auch die Motivation eine wichtige Rolle und damit die Frage, wie man die Entwickler einbezieht.
Wichtig ist zunächst, eine gewisse Homogenisierung der Architektur beziehungsweise beim Aufbau der Microservices zu schaffen. Wie genau das umgesetzt wird, ist dabei weniger entscheidend. Natürlich sollte man sich an grundlegenden, bekannten Patterns orientieren. Aus meiner Erfahrung war es aber immer sinnvoll, die Entwickler direkt mit einzubeziehen.
Jeder Entwickler bringt seine eigenen Erfahrungen mit, und das ist auch gut so, denn keine einzelne Person kann alles wissen. Wenn man die Entwickler einbezieht und sie an der Gestaltung der Templates mitwirken können, wird es auch ein Stück weit zu ihrem eigenen Thema. Das steigert die Motivation und damit letztlich auch die Geschwindigkeit.
Philipp Ebnet, CGI: Wenn ein Unternehmen schneller und strukturierter entwickeln möchte, aber mit Rapid Software Development noch keine Erfahrung hat: Was wären die ersten Schritte? Frank, worauf würdest du aus Projektmanagementsicht zuerst achten?
Frank Rudolf, CGI: Die ersten Schritte lassen sich im Wesentlichen unter einer gewissen Risikoaffinität zusammenfassen. Rapid Software Development bringt das Risiko mit sich, dass Stakeholder den aktuellen Entwicklungsstand nicht jederzeit anhand klar abgegrenzter und messbarer Einheiten nachvollziehen können. Stattdessen arbeitet man stärker auf Basis einer gemeinsamen Vision. Die Organisation muss also bereit sein, dem Entwicklungsteam den entsprechenden Freiraum zu geben. Meine persönliche Erfahrung ist, dass dadurch deutlich mehr Geschwindigkeit entsteht.
Ein zweiter Punkt ist, Rollen breiter zu verstehen. Projektmanager und Product Owner sollten auch technische Zusammenhänge nachvollziehen können. Gleichzeitig müssen Product Owner und Architekten eng zusammenarbeiten und gegenseitig verstehen, warum bestimmte Entscheidungen getroffen werden. So können Anforderungen von Anfang an so formuliert werden, dass sie auch sinnvoll umsetzbar sind.
Der dritte Punkt ist, sich ein Stück weit von dem Anspruch zu lösen, bereits im Vorfeld alles perfekt festzulegen. Früher wurde beispielsweise sehr detailliert definiert, wo ein Button sitzt und wie viele Pixel Abstand er haben muss. Statt diesen Aufwand vollständig in Requirements Engineering und Anforderungsdokumentation zu investieren, kann man mit einem ersten Entwurf direkt ins Gespräch mit dem Kunden gehen: Gefällt dir das so oder möchtest du es anders haben?
So bekommt man unmittelbar Feedback und kann sich bei der Dokumentation auf die Anforderungen konzentrieren, die tatsächlich relevant sind.
Dustin Augstein, CGI: „Ich würde noch ergänzen, dass das Gleiche auch in die andere Richtung gilt. Das heißt: Ich als Softwarearchitekt muss und sollte nicht alles bis ins Detail vorgeben, sondern einen gewissen Freiraum lassen. Das ist eng damit verbunden, Verantwortung zu übertragen.
Es gibt eine grobe Zielrichtung, die durch die konzeptionelle Architektur bestimmt wird. Wie diese dann im Detail umgesetzt wird oder wie beispielsweise ein Button aussieht, kann man den Entwicklern selbst überlassen. Damit überträgt man ihnen auch Verantwortung. Und das wiederum ist eng mit Motivation verbunden: Die Entwickler können selbstbestimmter vorgehen, und einzelne Personen wie der Softwarearchitekt werden nicht zum Nadelöhr.
Wenn man das anders handhabt, kommt man schnell an den Punkt: Ich kann gerade nicht weiterentwickeln, weil ich erst eine Aussage von Person X brauche. Überträgt man dagegen die Verantwortung, können die Entwickler selbstständiger agieren und einfach weiterarbeiten. Sie kommen dann mit einem Ergebnis, über das man anschließend gemeinsam diskutieren kann. Und meistens kommt dabei etwas Gutes heraus.
Philipp Ebnet, CGI: Mehr Freiraum und weniger Detailvorgaben können also auch die Motivation erhöhen. Wenn klassische KPIs hier nur eingeschränkt funktionieren: Auf welche Signale würdest du achten, um zu erkennen, ob der Ansatz funktioniert oder angepasst werden muss?
Frank Rudolf, CGI: Signale beschreibt es eigentlich ganz gut. Dieser Ansatz zwingt einen dazu, sehr nah am Entwicklungsteam zu sein – im besten Fall jeden Tag im Daily. So sieht man sehr genau, in welche Richtung sich die Entwicklung bewegt. Man hat sehr schnell ein Frontend, sehr schnell erste Funktionen und kann die Software dadurch frühzeitig begreifen.
An diesem Punkt kann man als Product Owner oder Projektmanager direkt intervenieren und sagen: Liebes Team, wir müssen noch einmal in eine andere Richtung, das wird so nicht zum richtigen Ziel führen. Diese Signale muss man natürlich aufgreifen.
Es hilft deshalb nicht, wenn man seine Projektmanagementrolle so versteht: Ich mache die Zahlen schön und der Architekt macht die Software schön. Beides muss jeden Tag direkt ineinandergreifen. Das bedeutet an dieser Stelle für alle Seiten mehr Aufwand. Gleichzeitig vermeidet man aber, über einen längeren Zeitraum in die falsche Richtung zu laufen und später wieder umkehren zu müssen.
Wenn ich bereits am ersten Tag sehe, dass der eingeschlagene Weg nicht der richtige ist, kann ich direkt gegensteuern und verliere kaum Zeit. Und auch der Anteil der Arbeit, den man dadurch verwerfen muss, ist zu diesem Zeitpunkt noch nicht besonders groß.
Philipp Ebnet, CGI: Das zeigt auch, wie wichtig Zusammenarbeit und Soft Skills werden. Wenn du dich dafür interessierst, hör gerne auch in unsere Folge „Microchanges für den Alltag“ rein. Dort erklärt Luam Hammelrath, warum Soft Skills in der Zusammenarbeit und für die eigene Karriere aus ihrer Sicht künftig wichtiger werden. Dustin, du hast zu Beginn gesagt, dass KI Entwickler derzeit nicht ersetzt. Gleichzeitig gibt es die Sorge, dass weniger Entwickler, Architekten oder anderes Personal benötigt werden, wenn KI Code schreiben kann. Wie ordnest du das ein?
Dustin Augstein, CGI: Ja, das ist definitiv ein sehr heißes Thema. Wir haben darüber auch in Managerkreisen intensiv diskutiert, denn aus Unternehmenssicht stellt sich völlig zu Recht die Frage: Warum brauche ich noch genauso viele Entwickler, wenn die KI inzwischen Code schreiben kann?
Man muss bei allen Aussagen dazu immer sagen: Das ist der Stand heute. Die Entwicklung geht derart rasant voran, dass zumindest ich nicht abschätzen kann, wie das in einem halben oder sogar in zwei oder drei Jahren aussehen wird.
Stand heute ist es so, dass KI Code sehr gut versteht. Sie kann bestehenden Code erweitern und Boilerplate-Code sehr gut schreiben und teilweise sogar eigenständig Unit-Tests erstellen. Was sie aber nicht zuverlässig leistet, ist die Konzeption und Architektur. Die eigentliche Herausforderung besteht darin, das fachliche Bild, diese Vision, in eine sinnvolle Architektur zu überführen.
Wenn man KI dabei nicht mit der Erfahrung eines Entwicklers einsetzt und sie nicht grundsätzlich lenkt – also beispielsweise vorgibt, welche Technologien eingesetzt werden sollen –, dann produziert die KI sehr schnell sehr viel Code, der am Ende kaum brauchbar ist. Ich würde es sogar sehr deutlich sagen: Der Code funktioniert vielleicht zunächst, ist aber weder wartbar noch erweiterbar und teilweise für Menschen kaum noch nachvollziehbar.
Genau daraus sind auch die Geschichten entstanden, bei denen Entwicklerstellen gestrichen wurden. Es sah zunächst gut aus: Man hat die KI loslegen lassen, es kam etwas heraus, es ging unglaublich schnell und das Ergebnis war auf den ersten Blick brauchbar. Als dann aber der erste Fehler auftrat und jemand genauer hinschauen musste, ist das Ganze zusammengebrochen. Kein Mensch konnte den Code mehr sinnvoll reparieren, und auch die KI kam an diesem Punkt nicht mehr weiter. Am Ende musste man praktisch wieder von vorne anfangen.
Deshalb erleben wir gerade einen Umbruch. Vibecoding ist unglaublich hilfreich, und ich möchte es auch nicht mehr missen. Aber wir brauchen weiterhin erfahrene Entwickler, die die technischen Zusammenhänge und Hintergründe verstehen und wissen, wie man KI sinnvoll einsetzt.
Philipp Ebnet, CGI: Welche Fähigkeiten baust oder vertiefst du persönlich, um dich beruflich weiterzuentwickeln?
Dustin Augstein, CGI: Vibe Coding ist derzeit eines der treibenden Themen und man kann sich dem nicht verschließen. Gleichzeitig ist es kein Ansatz, mit dem sich alles lösen lässt. Es braucht weiterhin eine Toolchain, die der KI Grenzen und Strukturen vorgibt. Entscheidend ist deshalb, die richtigen Werkzeuge zu haben, um KI gezielt zu lenken.
Philipp Ebnet, CGI: Frank, die Entwicklung verläuft sehr schnell. Wenn wir ungefähr drei Jahre vorausblicken: Wie werden sich Softwareentwicklung, Plattformen und automatisiertes Deployment aus deiner Sicht verändern?
Frank Rudolf, CGI: Ich sehe darin einen normalen technologischen Wandel, der derzeit allerdings sehr schnell verläuft und in Unternehmen und Organisationen spürbar sein wird. Faktisch wird weniger klassische Softwareentwicklung notwendig sein. Meine Hoffnung ist, dass Unternehmen deshalb nicht an Softwareentwicklern sparen, sondern mit den vorhandenen Entwicklern und den neuen Technologien mehr Produktivität erreichen. Die Rolle des Entwicklers verändert sich ohnehin seit vielen Jahren. Früher suchte man beispielsweise gezielt C-Sharp-Entwickler oder sehr spezifische Fähigkeiten. Heute wird von Entwicklern häufig erwartet, dass sie mit verschiedenen gängigen Sprachen umgehen können, auch wenn sie persönliche Schwerpunkte haben. Künftig wird sich die Rolle aus meiner Sicht stärker in Richtung Architektur entwickeln, weil die Orchestrierung der Technologien für das gewünschte Ergebnis wichtiger wird. Gleichzeitig entsteht eine Herausforderung für Nachwuchsentwickler: Erfahrungswissen, wie Dustin es über 20 Jahre aufgebaut hat, entsteht durch Lernen, Fehler und Weiterentwicklung. Wenn sich die Rolle weiter verdichtet und komplexer wird, fehlt dafür möglicherweise Zeit. Das ist meine persönliche Einschätzung. Ob KI in zehn Jahren alles allein übernimmt, kann ich bei der aktuellen Entwicklungsgeschwindigkeit nicht ausschließen. Ich bin aber überzeugt, dass es diese Rolle in den nächsten zehn Jahren weiterhin geben wird - sie wird nur komplexer.
Philipp Ebnet, CGI: Zum Abschluss: Welchen Rat würdet ihr Unternehmen geben, damit sie auch künftig Geschwindigkeit und Handlungsfähigkeit erhalten, ohne unnötige Komplexität aufzubauen? Frank, vielleicht zunächst aus Projektmanagementsicht, anschließend Dustin aus Entwicklersicht.
Frank Rudolf, CGI: Alle Organisationen und Unternehmen, die ich kennengelernt habe, verfügen über enormes Potenzial, das häufig gebunden ist. Dieses Potenzial sollte man freisetzen, Kontrollen nicht zu eng gestalten und den Menschen Raum geben. Viele möchten sich einbringen und etwas voranbringen. Wenn man dieses Potenzial mit den verfügbaren Technologien verbindet, kann daraus die gewünschte Produktivitätssteigerung entstehen.
Dustin Augstein, CGI: Es geht darum, Verantwortung stärker in Richtung der Entwickler und der Technik zu verlagern, damit sie selbstständiger arbeiten können. Bei Automatisierung und KI-gestützter Beschleunigung sollte man allerdings behutsam vorgehen: nicht alles auf einmal, sondern Schritt für Schritt. Zunächst beginnt man mit kleineren Anwendungsfällen. Wenn diese etabliert sind, folgt der nächste Schritt.
Philipp Ebnet, CGI: Vielen Dank euch beiden für die Antworten und das Gespräch. Ich habe viel mitgenommen und gelernt. Danke, dass ihr da wart.
Frank Rudolf, CGI: Danke!
Dustin Augstein, CGI: Danke, dass wir hier sein durften.
Philipp Ebnet, CGI: Danke euch beiden. Wenn du mehr über Franks und Dustins Plattform erfahren oder wissen möchtest, wie dein Einstieg in Rapid Software Development aussehen kann, wirf einen Blick in die Show Notes. Dort findest du ihre Kontaktdaten und weitere Informationen zur Plattform. Und natürlich vielen Dank auch an dich fürs Zuhören. Wenn dir die Folge gefallen hat, like und abonniere den Podcast gerne, damit du keine Folge verpasst. Ich freue mich auf das nächste Mal. Bis dahin: Ciao, wir hören uns.
