Der genaue KI-Delivery-Stack, den ein CPO nutzt, um Nacharbeit um 25 % zu reduzieren
KI kann in Sekunden Code erzeugen. Aber ohne Architektur hilft sie nur dabei, das Falsche schneller auszuliefern. In diesem Interview teilt ein CPO und Director of Engineering das Architektur-zentrierte KI-System, mit dem er die Prototyping-Zeit halbiert, Nacharbeit um 25 % reduziert und Leitplanken für einen KI-gestützten SDLC entwirft.
Yurii Lozinskyi
Der CPO und Director of Engineering bei Verysell
KI-Führung: KI verschiebt das Projektmanagement vom Koordinieren hin zum Systemdesign und reduziert manuelle Aufgaben durch Integration von KI.
Architektur-Rolle: Robuste Architektur verhindert Delivery-Chaos durch KI, indem sie KI-generierte Arbeiten an Qualitätsstandards und Zielen ausrichtet.
Prototypen-Effizienz: Architekturorientierte KI senkt die Kosten drastisch und beschleunigt den Weg vom Konzept zum funktionierenden Prototyp auf wenige Tage.
Wert von Ingenieuren: KI steigert den Wert von Senior Engineers, indem sie Architekturdesign fördert und wahlloses Coden reduziert.
Wandel im Projektmanagement: Künftige Projektmanagement-Rollen nutzen KI zur Koordination und konzentrieren sich stärker auf Design, Strategie und Steuerung.
Yurii Lozinskyi ist CPO und Director of Engineering bei Verysell AI, wo er die KI-Auslieferung leitet. Mit 25 Jahren Erfahrung ist es sein tägliches Handwerk, Software- und KI-Initiativen in messbare Geschäftsergebnisse zu verwandeln.
Wir haben uns also mit ihm zusammengesetzt, um zu erfahren, wie er das macht. Das hat er uns erzählt.
Wie man sicherstellt, dass KI nicht nur ein glänzendes Spielzeug ist
Ich bin Produkt- und Technikverantwortlicher, der dort arbeitet, wo KI-Systeme, Software-Auslieferung und betriebswirtschaftliche Realität aufeinandertreffen. Ich habe über 15 Jahre lang Lösungen in den Bereichen Banken, Versicherungen, ITSM/MSP-Plattformen, Einzelhandel und Gesundheitswesen geliefert. Und irgendwie zieht es mich immer wieder zur Versicherung, weil dort sowohl die Komplexität als auch die Wirkung am größten sind.
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
Derzeit leite ich Projekte nicht mehr im klassischen Sinne. Ich entwerfe, wie Projekte laufen sollten und bleibe während der Auslieferung möglichst praxisnah involviert. Das bedeutet Betriebsmodelle, KI-gestützte Delivery-Muster und Hypothesen-Validierungs-Roadmaps über mehrere Teams und Kunden hinweg.
Kurz gesagt: Mein Tagesgeschäft besteht darin, sicherzustellen, dass KI nicht nur ein glänzendes Spielzeug am Rand ist, sondern ein Teil davon, wie Arbeit definiert, ausgeführt und ganzheitlich gesteuert wird.
Wie KI das Projektmanagement von Koordination hin zur Systemgestaltung verschiebt
Führungsverantwortung in der Auslieferung wechselt von Kalenderverwaltung hin zu Systemgestaltung. Ich verbringe deutlich weniger Zeit in Statusmeetings oder damit, manuell Artefakte zu entwerfen, die Maschinen inzwischen in Sekunden erzeugen können. Wenn KI mir hilft, die erste Version eines Plans oder einer Zusammenfassung zu schreiben, lasse ich sie das gerne tun.
Viele Projektmanager verbringen heute immer noch 40–60 % ihrer Zeit mit Statusverfolgung, manuellen Berichten, der Identifikation grundlegender Risiken und dem Übertragen von Informationen zwischen Tools und Personen. In einer KI-unterstützten Umgebung sinkt dieser Wert auf unter 10–15 %, da eingebettete Agents Updates, Zusammenfassungen, Erinnerungen und einfache Eskalationen über Jira/Linear, Slack/Teams und Dokumente hinweg übernehmen.
Der Preis dafür ist, dass meine Aufgabe eine Ebene nach oben gewandert ist: Ich befasse mich mit Einschränkungen, Abnahmekriterien, Leitplanken und Rückkopplungsschleifen. Anders gesagt: Ich gestalte die "Gleise", auf denen Menschen und KI-Agents agieren.
Ich bin Architektur-orientiert: Ich nutze das C4-Modell und ISO/IEC 25010 als Rahmen für Architektur-Vision-Dokumente und verwende diese dann als Prompts. Das ist der spannende Teil – Architektur wie eine API für KI zu behandeln. Eure Architektur-Dokumente sind keine Regalware, sondern der Treibstoff für einen KI-gestützten Software-Entwicklungs-Lebenszyklus (SDLC). Dazu gleich mehr.
KI macht es trivial einfach, schnell zu agieren – meine Rolle ist also sicherzustellen, dass wir in die richtige Richtung schnell sind. Statt zu fragen: "Wer macht diese Woche was?" frage ich jetzt: "Verhindert unser System, dass wir schnell das Falsche liefern?"
KI macht es trivial einfach, schnell zu agieren – meine Rolle ist also sicherzustellen, dass wir in die richtige Richtung schnell sind.
Warum Architektur KI-induziertes Delivery-Chaos verhindert
Ich mag C4, ISO 25010 und Architektur-Vision-Dokumente, weil sie ein Rückgrat für die Integration von KI in die Auslieferung bilden. Ohne dieses Rückgrat kann KI schnell zu einer weiteren Quelle des Chaos in der Auslieferung werden.
Konkret:
- C4 gibt KI eine Landkarte des Systems. Statt „Schreib einfach irgendeinen Code“ können wir sagen: "In diesem Kontext und Container, über diese Schnittstellen, implementiere diese Änderung." Das hält KI-generierte Arbeit in klaren architektonischen Grenzen.
- ISO 25010 definiert „gut“ über „es kompiliert“ hinaus. Wir übersetzen die Qualitätsattribute in konkrete Szenarien – Performance, Sicherheit, Wartbarkeit, Zuverlässigkeit – und nehmen sie in Prompts und Abnahmekriterien auf. KI erzeugt dann PoCs und Tests, die mit den klaren Qualitätsanforderungen, nicht nur mit funktionalen Erwartungen, übereinstimmen.
- Architektur-Vision-Dokumente integrieren alles. Sie verbinden Geschäftsziele, C4-Sichten und ISO-konforme Qualitätsszenarien zu einer gemeinsamen Erzählung für Menschen und KI. Für Menschen dienen sie als Abstimmungsgrundlage. Für KI stellen sie die Hauptkontextquelle für die Generierung von Code, Tests und Dokumentation bereit.
Zusammen verwandeln sie KI von einer zufälligen Superkraft in eine kontrollierte Komponente eines KI-gestützten SDLC – mit klaren Grenzen, Nachvollziehbarkeit und einem gemeinsamen Verständnis dessen, was wir bauen wollen.
Wie sich die Kosten von Fehlentscheidungen mit architekturgeführten KI-Prototypen minimieren lassen
Hier ein Beispiel: Wir hatten ein AI-Matching-Feature, das in der „alten Welt“ etwa zwei Wochen vom Konzept bis zum klickbaren Prototyp benötigt hätte.
Anstatt mit Jira-Tickets und Ad-hoc-Prompts zu starten, schrieben wir zuerst ein kurzes Architecture Vision Document. Wir zeichneten C4-Diagramme: Systemkontext, beteiligte Container, Schlüsselkomponenten sowie einige auf ISO 25010 ausgerichtete Qualitätsszenarien (z. B. Latenz, Prüfbarkeit, Fehlerbehandlung).
Dann behandelten wir diese Architektur wie eine API für KI:
- Wir gaben das Vision Document und C4-Ausschnitte als einzige Wahrheitsquelle in unseren Coding Assistant ein.
- Wir forderten ihn auf, das Grundgerüst, die Kernlogik und erste Tests innerhalb der festgelegten Container und Schnittstellen zu generieren.
Man bittet die KI nicht einfach, „Schreib mir etwas Code“, sondern: „Implementiere diese spezifische Interaktion mit diesen Vorgaben und diesen Qualitätsanforderungen.“ Das ist ein ganz anderes Spiel. Das Ergebnis war ein stimmiger PoC in nur wenigen Tagen, anstatt alles mühsam von Hand zu schreiben.
Ingenieur:innen prüften und korrigierten weiterhin, aber:
- Die Zeit vom „Wir sollten das ausprobieren" bis Stakeholder durch einen klickbaren Prototyp gehen konnten, verkürzte sich von etwa zehn Werktagen auf drei bis vier. Es fühlt sich fast unfair an, wie schnell ein glaubwürdiger Prototyp entsteht, wenn die Architektur die Prompts leitet – statt vager Wünsche.
- Wir hatten 20–25 % weniger Überarbeitungsschleifen, weil der von der KI generierte Code die in der Architektur verankerten Grenzen und Muster bereits beachtete.
- Ingenieur:innen berichteten davon, etwa 20 % weniger Zeit für Boilerplate- und Verbindungscode zu benötigen – die Rolle der „Integrationsingenieurin“ wurde so praktisch überflüssig.
- Die Testabdeckung dieses Bereichs war von Anfang an höher, weil der Assistent die dokumentierten Qualitätsszenarien nutzte, um Tests für Randfälle vorzuschlagen, die wir sonst zu diesem Zeitpunkt noch nicht geschrieben hätten.
Mit anderen Worten: Sobald wir die Architektur explizit und strukturiert festgelegt hatten, verhielt sich die KI nicht mehr wie ein cleveres Autocomplete, sondern wie ein Junior-Engineer, der das System versteht, hervorragende Dokumentation schreibt und niemals schläft.
Und das Wichtigste: Die Kosten, Fehler zu machen, sanken massiv – und genau das ist in chaotischen Bereichen entscheidend.
Warum KI Senior Engineers wertvoller macht – nicht weniger
Entgegen der Vermutung macht KI Senior Engineers noch wertvoller, nicht weniger.
Setzt du KI auf eine schwache Architektur und schlechtes Urteilsvermögen, entsteht ein noch schnelleres Chaos. Stellst du sie in den Dienst einer starken Architekt:in, kann eine oder einer plötzlich fünf Designs vor dem Mittagessen evaluieren – und hat noch Zeit für Gespräche mit Stakeholdern.
KI schließt manche Kompetenzlücken, verstärkt aber den Unterschied zwischen ziellosem Codieren und absichtsvoller Gestaltung noch deutlicher.
Setzt du KI auf eine schwache Architektur und schlechtes Urteilsvermögen, entsteht ein noch schnelleres Chaos. Stellst du sie in den Dienst einer starken Architekt:in, kann eine oder einer plötzlich fünf Designs vor dem Mittagessen evaluieren – und hat noch Zeit für Gespräche mit Stakeholdern.
Tschüss, Business Analyst – willkommen, Fachexpert:in.
Welche Delivery-Aufgaben zuerst mit KI automatisiert werden sollten
Im Moment eignen sich vor allem jene Teile der Delivery-Arbeit für die Automatisierung, die „kontextreich, musterorientiert und wenig selbstverliebt“ sind:
- Wie bereits erwähnt, können PoC-Code und Tests aus Architektur-Vision-Dokumenten sowie C4/ISO 25010-Spezifikationen generiert werden
- Entwurf von Entscheidungsprotokollen, Designoptionen und Risikolisten
- Chaotische Slack-Threads so aufbereiten, dass Ihr zukünftiges Ich sie lesen kann, ohne zu verzweifeln
KI ist hervorragend im Vorschlagen, aber schrecklich darin, Verantwortung zu übernehmen. In diesen Bereichen behalten Menschen nach wie vor eindeutig die Kontrolle:
- Das Problem einrahmen
- Abwägen von Risiko und Geschwindigkeit
- Umgang mit regulatorischen und ethischen Grenzen
- Entscheiden, wann „technisch korrekt“ trotzdem die falsche Lösung zum Ausliefern ist
Der Sweet Spot ist momentan, die frühen Entdeckungs- und Designschleifen zu komprimieren. Agenten sind gut darin, aus einer kohärenten Spezifikation plausible Wege abzuleiten. Sie erkennen aber noch nicht, wann ein Weg politisch, ethisch oder strategisch falsch ist; deshalb behalten Menschen die Kontrolle.
Warum PMs Feedback-Loops gegenüber Ritualen priorisieren sollten
Traditionelles Projektmanagement ist oft von viel Ritual ohne klaren Zweck geprägt. Ich entferne mich davon und wende mich Systemen zu, die Feedback höher als Formalia bewerten.
In der Praxis bedeutet das:
- Weniger monolithische Pläne; mehr kleine, testbare Hypothesen
- Weniger große Statusmeetings; mehr asynchrone Updates, von KI automatisch zusammengefasst
- Weniger aufgeblähte Anforderungsdokumente; mehr lebendige Architektur-Vision-Dokumente, mit denen Menschen und KI gleichermaßen arbeiten können
Wir achten nach wie vor auf Termine, Budgets und Risiken. Aber wir überlassen der KI die Buchhaltung, damit sich Menschen auf Design, Entscheidungen und Stakeholder-Realität konzentrieren können.
Ironischerweise steigt der Respekt für Struktur, wenn die Hälfte aller Rituale wegfällt.
Ironischerweise steigt der Respekt für Struktur, wenn die Hälfte aller Rituale wegfällt.
Wie KI-Integrationen die Projektauslieferung in GitHub und CI/CD optimieren
Aus technischer Sicht bedeutete „Leichtgewichtigkeit“, KI direkt in das Repository und die Umgebungen zu integrieren – nicht einfach ein weiteres Dashboard hinzuzufügen.
Im Detail haben wir einen KI-Coding-Assistenten namens Codex in unsere GitHub-Repositories und die CI/CD-Pipeline integriert. Die Ingenieure arbeiten weiterhin in ihrer gewohnten IDE, aber der Assistent erkennt die Struktur des Repos und kann alles aus C4-basierten Architekturdiagrammen und Architektur-Vision-Dokumenten ableiten, wie oben beschrieben. Zu etwa $20 USD pro Ingenieur und Monat ist dies günstiger als fast jeder andere Produktivitätshebel.
Zudem nutzen wir einfache Bereitstellungsautomation (auf GitHub basierende Pipelines), sodass KI-unterstützte Änderungen mit einem Klick in eine dedizierte Prototypumgebung ausgerollt werden können.
Sogar die Prompterstellung ist teilweise automatisiert: Ein modernes GPT-Modell (GPT-5.2) kann strukturierte Prompts für Werkzeuge wie Eraser aus unseren Architektur-Vision-Dokumenten generieren.
Entscheidend ist, dass all dies innerhalb standardisierter Leitplanken geschieht: Ingenieure prüfen weiterhin jeden Pull Request, CI/CD läuft wie gewohnt, und nichts gelangt ohne menschliche Freigabe in die Produktion. KI beschleunigt die langweiligen Aufgaben; die Verantwortung für Design, Risiko und Endergebnis bleibt beim Menschen.
Warum KI-Prototypen Delivery-Rituale neu definieren
All das hat unsere Delivery-Rituale maßgeblich verändert.
Den Umfang festzulegen bedeutete früher: „Lass uns stundenlang diskutieren und dann ein Dokument schreiben, das keiner liest.“ Jetzt heißt es: „Lasst uns schnell zu einem Prototypen kommen und an etwas Interaktivem diskutieren.“
Wir starten mit einem hochleveligen Ergebnis, halten es in einem Architektur-Vision-Dokument fest, skizzieren C4-Ansichten und nutzen dann KI, um ein PoC oder zumindest ein realistisches Mock-up zu erstellen. Plötzlich hat jeder eine Meinung – weil es etwas Greifbares gibt.
Mit anderen Worten: Wir erreichen Übereinstimmung über Verhalten, nicht über Stichpunkte.
Wir validieren mit einer Mischung aus KI-generierten Tests (sehr gut für Abdeckung und Regression) und von Menschen entworfenen Szenarien (ideal für Beurteilung und ungewöhnliche Sonderfälle).
Und wir verlagern das Ausführungsmanagement von „Aufgaben zuweisen“ zu „Abläufe gestalten“: Wer oder was sollte als Nächstes diese Arbeit sehen – und in welchem Kontext?
Wie ein unkomplizierter AI-Delivery-Stack aussieht
Mein Stack ist meinungsstark, aber unkompliziert.
Für Architektur und Abstimmung verwende ich Diagramme im C4-Stil und Architecture Vision Documents, gezeichnet mit Tools wie Eraser. So lassen sich diese leicht gemeinsam mit Menschen iterieren und anschließend ins AI-Ökosystem einspeisen.
Für Spezifikationen bevorzuge ich textorientierte Dokumente, die Absichten, Rahmenbedingungen und Qualitätsattribute so beschreiben, dass ein LLM sie versteht.
Auf der Entwicklungsseite setze ich moderne IDEs mit starker AI-Unterstützung sowie Tools wie Claude Code und Codex ein, um auf Basis dieser Architektur-Artefakte direkt PoC-Implementierungen und Tests zu generieren. Ich habe bewusst darauf verzichtet, komplette Produktionsfunktionen an AI auszulagern. Sie konzipiert, erstellt Grundstrukturen und schlägt vor. Ingenieure – echte – entscheiden weiterhin, was produktiv gesetzt wird.
Wichtig ist: Jedes dieser Tools ist keine Insel mehr. Sie sind inzwischen Teil eines AI-gestützten SDLC: Anforderungen, Architektur, Coding, Testing und selbst Governance – alle erhalten eine unterstützende Schicht.
In der Praxis erwarte ich, dass dieser Wandel etwa 18-25 % Produktivitätssteigerung in der Delivery bringt. Um es klar zu sagen: Diese Zahl hängt stark vom Ausgangsniveau einer Organisation ab – von Reife, bestehenden Prozessen und Architekturdisziplin.
Wie gezielte Tool-Auswahl AI-Delivery verbessert
Im letzten Jahr haben wir gezielt damit begonnen, Tools auszutauschen und zu testen, statt zu versuchen, alles auf einmal „AI-fähig“ zu machen.
Auf der Delivery-Seite haben wir Miro für leichtgewichtige Roadmaps und Architektur-Workshops eingeführt – aber zunächst nur als Pilot bei einigen kleinen Projekten. Wir wollten herausfinden, wie gut Miro-Boards in Kombination mit AI-generierten Zusammenfassungen lange Foliensätze und manuelle Abstimmungsdokumente ersetzen können. Die ersten Anzeichen sind gut, aber wir müssen den Ansatz erst finalisieren und skalieren, bevor er zum Standard wird.
Für Dokumentation und Spezifikationen haben wir ein textbasiertes Tool für die Erstellung von Architecture Vision Documents weiter genutzt. Wir ergänzten es durch sehr schlanke, benutzerdefinierte GPTs als AI-Unterstützung – und verabschiedeten uns geräuschlos von großen statischen Spezifikationsdokumenten, die ohnehin ungepflegt blieben und sich schlecht in Prompts übersetzen ließen.
Wie bereits erwähnt, setzten wir auf der Engineering-Seite Codex als AI-Coding-Assistenten ein, integriert in unser Git-Repository und die CI-Pipeline, um PoC-Grundstrukturen und Testgenerierung zu unterstützen. Unsere bestehenden IDEs und Deployment-Werkzeuge behalten wir jedoch bei. Anders gesagt: Wir reißen den Stack (noch) nicht heraus. Wir legen AI als Schicht obenauf – dort, wo es klar Zeit spart, und führen dies zunächst mit kontrollierten Piloten ein, bevor wir irgendetwas unternehmensweit ausrollen.
Wir reißen den Stack (noch) nicht heraus. Wir legen AI als Schicht obenauf – dort, wo es klar Zeit spart, und führen dies zunächst mit kontrollierten Piloten ein, bevor wir irgendetwas unternehmensweit ausrollen.
Wohin sich Projektmanagement in den nächsten fünf Jahren entwickelt
In fünf Jahren wird die Rolle „Projektmanager“ als reine Koordinationsfunktion im Tech-Bereich weitgehend verschwinden. Die Aufgaben bleiben, aber eingebettete AI-Agenten übernehmen die meisten Koordinations-, Nachverfolgungs- und Reporting-Aufgaben direkt in den Tools.
Die Menschen, die früher als PMs arbeiteten, steigen entweder auf und gestalten AI-gestützte SDLCs und Governance-Modelle, oder sie wechseln in Produkt- und Strategie-Rollen.
PM-Performance-Dashboards werden sich von „pünktlich / im Budget“ hin zu wenigen Systemmetriken verschieben, die sie aktiv beeinflussen: Durchlaufzeit für Änderungen, Rate unentdeckter Fehler, Entscheidungs-Latenz, Experiment-Durchsatz und Vertrauenswert bei Stakeholdern. AI übernimmt die meisten Zählaufgaben. PMs sind dafür verantwortlich, ob sich diese Zahlen in die gewünschte Richtung entwickeln – nicht, weil sie mehr Tickets verschoben haben, sondern weil sie bessere Arbeitsweisen gestaltet haben.
Die PMs, die bei „Status-Nachverfolgung“ bleiben, werden leise durch Bots ersetzt, die das rund um die Uhr erledigen und problemlos sechs Dashboards gleichzeitig updaten.
Warum PMs KI wie ein Teammitglied und nicht wie ein zu erlernendes Thema behandeln sollten
Mein Rat: Hören Sie auf zu versuchen, „KI zu lernen“, als wäre es ein neues Framework, und behandeln Sie sie stattdessen wie ein neues Teammitglied mit bestimmten Stärken und Schwächen. Unserer nennen wir scherzhaft „gptBuddy“.
Suchen Sie sich einen Arbeitsablauf, ein Team und eine wichtige Kennzahl aus und führen Sie ein kompromissloses Experiment durch. Wenn Sie keine spürbare Verbesserung sehen, ändern Sie das Setup oder hören Sie auf.
Der wahre Wert von KI wirkt von außen langweilig. Es ist nicht das Sci‑Fi-Zeug, das die Leute erwarten. Es sind die unspektakulären, sich summierenden Gewinne: Testgenerierung, Dokumenten-Überarbeitung, Gerüstbau, Variantenexploration und so weiter.
Heben Sie dabei gleichzeitig den Blick von den Tools und skizzieren Sie, wie ein KI-gestützter SDLC für Ihr Unternehmen aussehen könnte. Wenn Sie es nicht tun, macht es jemand anderes – und deren Teams werden schneller vorankommen, mit weniger Meetings und weniger Drama.
Hören Sie auf zu versuchen, „KI zu lernen“, als wäre es ein neues Framework, und behandeln Sie sie stattdessen wie ein neues Teammitglied mit bestimmten Stärken und Schwächen.
Weiter mitlesen
Sie können Yurii Lozinskyi auf LinkedIn und Dev.to folgen, während er sein technisches Know-how zu KI, Engineering, Produkt und Delivery teilt. Und schauen Sie sich Verysell AI an.
Weitere Experteninterviews folgen bald auf The Digital Project Manager!
