Was bleibt vom Produktteam, wenn KI den Code schreibt?

‍Mein Solo-Experiment WirkTakt zeigt, wie sich Rollen, Tempo und Verantwortung in der Produktentwicklung verschieben.

Gerade findet in Duisburg die Mensch und Computer 2026 statt. Das Motto lautet „Transforming Interactions“. Im Programm stehen unter anderem Sessions zu „Human-AI Trust & Agency“ und „Prototyping & AI-Assisted Design“. Ich kann dieses Jahr leider nicht dabei sein. Das Thema der Konferenz könnte für meinen August trotzdem kaum passender sein.
Die Verbindung zur Mensch und Computer ist für mich nicht nur thematisch. Im vergangenen Jahr war ich selbst auf der Mensch und Computer 2025 in Chemnitz. Gemeinsam im Arbeitskreis UX-Strategie der German UPA entwickelten wir einen KI-gestützten UX-Strategie-Coach und erprobten ihn in einem Workshop mit 13 Teilnehmenden. Im Beitrag „UX-Strategie spielerisch reflektieren“ untersuchten wir, wie generative KI strategische Reflexion unterstützen kann: durch strukturierte Fragen und neue Perspektiven – nicht durch fertige Antworten. Die weiterentwickelte Perspektive ist inzwischen unter dem Titel „AI as a reflection partner in UX strategy“ erschienen.

Ein Jahr später hat sich mein Experiment verschoben. In meinem persönlichen App Projekt mit dem Namen WirkTakt war die KI nicht mehr nur Reflexionspartner, sondern auch technischer Umsetzungspartner. Dadurch konnte ich als Einzelperson ein vollständiges Produkt von der Idee bis zur Veröffentlichung im App Store bringen. Das bedeutet nicht, dass KI ein interdisziplinäres Team ersetzt. Aber es zeigt, wie stark sich gerade die Grenzen dessen verschieben, was eine einzelne Person anstoßen, gestalten und umsetzen kann.
Genau daraus entstand die Frage, die mich durch das Projekt begleitet hat: Was passiert, wenn eine Product Designerin ohne Swift-Kenntnisse versucht, mit ChatGPT und Xcode eine native iPhone-App zu entwickeln und im App Store zu veröffentlichen?

Das Ergebnis heißt WirkTakt – und es ist nicht meine erste App. Bereits 2015 brachte ich mit votingLAB gemeinsam mit einem Team eine App in den Store. Neu war diesmal der Weg: WirkTakt habe ich als KI-gestütztes Solo-Projekt von der Idee bis zur Veröffentlichung umgesetzt.

Am 12. August 2026 begann ich mit der Umsetzung. Am 23. August reichte ich die App bei Apple ein. Vier Tage später war sie im App Store verfügbar. Bis zur Einreichung waren es zwölf Kalendertage, rund 80 Stunden Arbeit und der Entwicklungsstand Build 119 – ohne eine Zeile Swift selbst geschrieben zu haben.

Die ausführliche Entstehungsgeschichte, den Tracking-Flow und meine Designentscheidungen zeige ich in der WirkTakt Case Study. In diesem Artikel geht es um die weiterführende Frage:

Wie verändert sich Produktarbeit, wenn die KI nicht nur Ideen liefert, sondern Teile der Umsetzung übernimmt?

Vibe Coding verändert nicht nur das Programmieren

Der Begriff „Vibe Coding“ wurde Anfang 2025 von Andrej Karpathy (KI-Forscher, Gründungsmitglied von OpenAI und ehemaliger KI-Leiter bei Tesla) geprägt. Gemeint ist eine Form der Softwareentwicklung, bei der Menschen in natürlicher Sprache beschreiben, was entstehen soll, während eine KI den Code erzeugt und verändert. Fehlermeldungen, Änderungswünsche und neue Funktionen fließen wieder in den Dialog zurück, statt den Code selbst Zeile für Zeile zu schreiben.

Bei WirkTakt sah dieser Kreislauf meistens so aus:

1. Ich beschrieb ein Problem oder eine gewünschte Änderung.
2. ChatGPT erzeugte oder veränderte die Swift-Dateien.
3. Ich öffnete das Projekt in Xcode und installierte den neuen Build auf meinem iPhone.
4. Ich testete den konkreten Ablauf im Alltag.
5. Ich dokumentierte Fehler, Unklarheiten und visuelle Abweichungen.
6. Danach begann die nächste Runde.

Auf den ersten Blick klingt das wie eine neue Art zu programmieren. Für mich war es vor allem eine neue Art, Produktarbeit zu organisieren. Denken, Spezifizieren, Umsetzen und Testen liefen nicht mehr als klar getrennte Phasen ab. Sie rückten sehr eng zusammen.

Erst bauen, dann merken, dass es niemand braucht

WirkTakt war nicht mein erster Versuch. Anfang des Jahres hatte ich bereits an einem Samstagnachmittag eine kleine App zum Thema mentale Gesundheit gebaut. Nach ungefähr sechs Stunden lief eine erste Version auf meinem iPhone.
Technisch war das beeindruckend. Inhaltlich hielt die Begeisterung nicht lange an. Nach wenigen Tagen merkte ich, dass mich die App eher zusätzlich an mein Smartphone band, als mir wirklich zu helfen. Ich verlor selbst die Lust an der Nutzung und legte das Projekt auf Eis.

Die Erkenntnis daraus war simpel, aber wichtig:

‍Nur weil sich etwas plötzlich bauen lässt, entsteht daraus noch kein sinnvolles Produkt.

‍

Bei WirkTakt war die Ausgangslage anders. Dieses Mal begann ich nicht mit einer technischen Möglichkeit, sondern mit einem Problem aus meinem eigenen Alltag. Für die Einstellung meiner verordneten ADHS-Medikation sollte ich Einnahmen und Beobachtungen dokumentieren. Meine selbst erstellte Excel-Tabelle funktionierte im Urlaub 18 Tage lang. Im normalen Arbeitsalltag wurde das Nachtragen am Rechner zu aufwändig – und ich vergaß es immer häufiger.
Die App-Idee entstand also nicht aus dem Wunsch, unbedingt etwas mit KI zu bauen. Die KI machte es mir möglich, ein bereits vorhandenes Problem selbst zu bearbeiten.

Die KI übernahm die Umsetzung – nicht die Produktverantwortung

Ich habe WirkTakt als Solo-Projekt entwickelt. Trotzdem wäre „ganz allein“ die falsche Beschreibung. ChatGPT war mein technischer Umsetzungspartner. Apple stellte Plattform, Entwicklungsumgebung und Prüfprozess bereit. Zahlreiche bestehende Frameworks und Konventionen bildeten die Grundlage.

Meine Aufgabe lag an einer anderen Stelle. Ich musste:

• das Problem und die Zielsetzung definieren,
• den Funktionsumfang priorisieren und begrenzen,
• Informationsarchitektur und Abläufe festlegen,
• Fragen, Skalen und Begriffe formulieren,
• visuelle Entscheidungen treffen,
• Fehler erkennen, beschreiben und reproduzieren,
• Datenschutz und Produktgrenzen berücksichtigen,
• verschiedene Geräte und Systemzustände testen,
• und entscheiden, wann die App gut genug für eine erste Veröffentlichung war.

Die KI konnte Code erzeugen. Sie konnte mir aber nicht abnehmen, welches Problem ich eigentlich lösen wollte, welche Eingaben Menschen mit ADHS im Alltag zumutbar sind oder welche Formulierung bei einem gesundheitsbezogenen Produkt falsche Erwartungen weckt.

Genau darin liegt für mich eine wichtige Verschiebung:

‍Die Arbeit verschwindet nicht. Sie wandert von der direkten Produktion stärker in Richtung Zielklärung, Orchestrierung, Bewertung und Qualitätssicherung.

‍

Wenn fast alles machbar scheint, wird Nein sagen wichtiger

Nach dem ersten Prototyp entstanden ständig neue Ideen. Zusätzliche Check-ins, weitere Skalen, mehr Kontext, andere Auswertungen, Zyklusdaten, Erinnerungen, Exportmöglichkeiten und Einstellungen – vieles ließ sich mit wenigen Anweisungen zumindest als erste Version erzeugen.
Dadurch entstand ein neues Problem: Die technische Hürde, eine Funktion auszuprobieren, war plötzlich sehr niedrig. Die inhaltliche Frage, ob diese Funktion wirklich in das Produkt gehört, blieb genauso schwierig wie vorher.

Vielleicht wurde es sogar schwieriger. Wenn eine Umsetzung Wochen kostet, erzwingt der Aufwand automatisch eine gewisse Priorisierung. Wenn ein erster Entwurf nur wenige Prompts entfernt scheint, fühlt sich fast jede Idee zunächst legitim an.

Ich musste deshalb immer wieder fragen:

• Löst diese Funktion ein relevantes Problem?
• Macht sie die Dokumentation einfacher oder erzeugt sie neue Belastung?
• Hilft sie bei der persönlichen Reflexion oder sammelt sie nur mehr Daten?
• Gehört sie in Version 1.0 oder baue ich sie nur, weil es gerade möglich ist?
  ‍

Je schneller KI Dinge erzeugen kann, desto wertvoller wird die Fähigkeit, bewusst etwas nicht zu bauen.

Feedback wird zur Schnittstelle zwischen Mensch und Maschine

Während des Projekts merkte ich schnell, dass die Qualität meiner Rückmeldung die Qualität des Ergebnisses bestimmte. „Das sieht komisch aus“ war keine brauchbare Spezifikation.

Ich musste genauer werden:

• Welcher Screen und welcher Zustand sind betroffen?
• Was stimmt fachlich oder visuell nicht?
• Welches andere Element dient als Referenz?
• Wie kann ich das fehlerhafte Verhalten reproduzieren?
• Woran erkenne ich, dass die Korrektur erfolgreich war?
  ‍

Screenshots, konkrete Vergleiche und klar beschriebene Soll-Zustände halfen enorm. Statt „Die Kachel ist falsch“ funktionierte zum Beispiel: „Diese Kachel soll dieselben Abstände, Zustände und Interaktionen verwenden wie die Kachel auf dem Heute-Screen.“
Das ist für mich mehr als gutes Prompting. Es ist eine Form von Übersetzungsarbeit: Eine diffuse Wahrnehmung muss so präzise werden, dass daraus eine überprüfbare Änderung entstehen kann. Diese Fähigkeit war schon immer Teil von Design, Product Management und Softwareentwicklung. In der Zusammenarbeit mit KI wird sie zur direkten Schnittstelle der Umsetzung.

Ein funktionierender Build ist noch kein funktionierendes Produkt

Die KI konnte Änderungen erstaunlich schnell umsetzen. Sie konnte aber nicht garantieren, dass das Produkt danach als Ganzes noch funktionierte.
Einige Probleme wurden erst auf echten Geräten sichtbar. Erinnerungen waren in der App korrekt geplant, erschienen aber nicht als Systemmitteilung. Auf einem iPhone SE mit iOS 17 funktionierte die lokale Speicherung zunächst nicht zuverlässig. Texte passten auf Deutsch, waren in der englischen Version aber zu lang. Farben funktionierten im Dunkelmodus und verloren im Hellmodus ihren Kontrast.

Auch die Veröffentlichung war nicht mit einem funktionierenden Build erledigt. App-Store-Texte, Screenshots, Signierung, Datenschutzangaben, Altersfreigabe, Supportseite und die Abgrenzung des gesundheitlichen Verwendungszwecks gehörten ebenfalls zum Produkt.
Das war eine der deutlichsten Grenzen der Zusammenarbeit: Die KI konnte einzelne Aufgaben bearbeiten. Die Verantwortung für die Konsistenz des Gesamtsystems blieb bei mir.

Was bedeutet „Solo-Projekt“ künftig noch?

WirkTakt zeigt, wie weit eine einzelne Person heute mit KI-Unterstützung kommen kann. Für mich ist das trotzdem kein Beleg dafür, dass interdisziplinäre Teams überflüssig werden.

Ich habe ein überschaubares Produkt für ein Problem aus meinem eigenen Alltag entwickelt. Ich war gleichzeitig Auftraggeberin, erste Nutzerin und Entscheiderin. In einem größeren Produkt mit vielen Zielgruppen, komplexer Infrastruktur, hohen Sicherheitsanforderungen und langfristigem Betrieb wäre diese Konstellation nicht übertragbar.

Trotzdem verschieben sich Rollen und Grenzen:

• Product Designer können Ideen früher selbst funktional erproben.
• Prototypen und technische Umsetzung rücken näher zusammen.
• Übergaben zwischen Disziplinen können kleiner und kontinuierlicher werden.
• Entwickler werden nicht nur für die Codeproduktion gebraucht, sondern um Architektur, Sicherheit, Wartbarkeit und technische Risiken zu beurteilen.
• Produktverantwortliche müssen schneller entscheiden, welche der vielen möglichen Lösungen überhaupt verfolgt werden sollen.
  ‍

Die interessante Zukunft ist für mich deshalb nicht „Mensch oder Computer“. Sie liegt in der Gestaltung der Arbeitsteilung:

‍Welche Aufgaben delegieren wir – und bei welchen Entscheidungen wollen wir oder müssen wir als Menschen verantwortlich bleiben?

Produktivität ist keine automatische Folge

Mein Experiment war für mich eindeutig: Ohne ChatGPT hätte ich WirkTakt nicht in zwölf Tagen bis zur Einreichung bringen können. Daraus folgt aber nicht, dass KI jede Person in jedem Entwicklungskontext automatisch schneller macht.

Eine randomisierte Studie von METR kam 2025 in einem sehr spezifischen Setting zu einem überraschenden Ergebnis: Erfahrene Open-Source-Entwickler benötigten mit damaligen KI-Werkzeugen für Aufgaben in vertrauten Codebasen im Durchschnitt 19 Prozent mehr Zeit. Eine spätere Untersuchung von METR zeichnete bereits ein gemischteres und statistisch unsicheres Bild. Der Nutzen hängt also stark von Aufgabe, Erfahrung, Werkzeug und bestehendem System ab.

Wie problematisch es werden kann, Produktivität vor allem an der Menge des erzeugten Codes zu messen, zeigt auch eine aktuelle Reuters-Recherche über Metas interne KI-Transformation. Im Rahmen von „Project OT“ plante Meta kleinere, KI-gestützte Teams und prüfte, einzelne Teams um bis zu 60 Prozent zu verkleinern. Laut internen Daten stieg die Zahl der Codeänderungen an internen Plattformen und Infrastrukturen zwar um 220 Prozent. Neue oder verbesserte Funktionen, die tatsächlich Nutzer erreichten, nahmen jedoch nur um 36 Prozent zu. Gleichzeitig stiegen größere technische und sicherheitsbezogene Vorfälle um 40 Prozent, während Beschäftigte 70 Prozent mehr Zeit für deren Behebung aufwenden mussten.

Die Zahlen belegen nicht, dass KI allein für jedes Problem verantwortlich war. Sie verdeutlichen aber: Mehr Code ist nicht automatisch mehr Wert. Wenn die Produktion beschleunigt wird, ohne Prüfung, Architektur und Qualitätssicherung entsprechend mitzudenken, entstehen neue Fehler und zusätzlicher Aufwand.

Auch mein Credit-Limit erinnerte mich daran, dass diese Arbeitsweise von Infrastruktur, Tarifen und der Verfügbarkeit einzelner Anbieter abhängt. Nach den ersten intensiven Entwicklungstagen waren meine verfügbaren Credits aufgebraucht. Ich musste fast eine Woche pausieren.

Hinzu kommt die ökologische Frage. Eine persönliche Umweltbilanz kann ich nicht seriös berechnen, weil mir Angaben zu verwendeten Modellen, Tokens, Rechenzeit und Infrastruktur fehlen. Untersuchungen zum Ressourcenbedarf von KI-Modellen zeigen zudem, wie stark der Energiebedarf je nach Modell, Hardware sowie Länge der Ein- und Ausgabe schwanken kann.

Schneller bauen zu können bedeutet daher nicht automatisch, produktiver oder nachhaltiger zu arbeiten. Die niedrige Hürde kann Ressourcen sparen – oder dazu verführen, immer neue Varianten und Funktionen zu erzeugen.

‍

Hinzu kommt die ökologische Frage. Eine persönliche Umweltbilanz kann ich nicht seriös berechnen, weil mir Angaben zu verwendeten Modellen, Tokens, Rechenzeit und Infrastruktur fehlen. Untersuchungen zum Ressourcenbedarf von KI-Modellen zeigen zudem, wie stark der Energiebedarf je nach Modell, Hardware sowie Länge der Ein- und Ausgabe schwanken kann.

Schneller bauen zu können bedeutet daher nicht automatisch, produktiver oder nachhaltiger zu arbeiten. Die niedrige Hürde kann Ressourcen sparen – oder dazu verführen, immer neue Varianten und Funktionen zu erzeugen.

Eine Case Study braucht nicht zwingend ein Kundenprojekt

In meinen Mentoring-Sessions höre ich häufig eine Frage: Wie kann ich eine Case Study erstellen, wenn ich noch kein passendes Projekt habe oder meine bisherigen Kundenprojekte nicht öffentlich zeigen darf?

WirkTakt ist eine mögliche Antwort darauf. Eine gute Case Study muss nicht zwingend aus einem großen Auftrag entstehen. Sie kann mit einem eigenen, realen Problem beginnen. Entscheidend ist nicht der bekannte Kundenname, sondern ob der Prozess nachvollziehbar wird:

• Welches Problem sollte gelöst werden?
• Welche Annahmen gab es?
• Welche Entscheidungen und Zielkonflikte entstanden?
• Was wurde getestet und verändert?
• Wo lagen Grenzen und offene Fragen?
• Was ist tatsächlich belegt – und was noch nicht?
  ‍

Ein selbst initiiertes Projekt sollte transparent als solches bezeichnet werden. Gerade dann kann es aber sehr gut zeigen, wie jemand denkt, priorisiert, mit Unsicherheit umgeht und Verantwortung übernimmt.
Der fertige Screen ist nur das Ergebnis. Die eigentliche Case Study steckt in den Entscheidungen auf dem Weg dorthin.

‍

Was ich aus dem Experiment mitnehme

WirkTakt hat meinen Blick auf die Zusammenarbeit mit KI verändert.
‍

Meine wichtigsten Erkenntnisse sind:

1. Ein relevantes Problem bleibt wichtiger als technische Geschwindigkeit

Mein erster App-Versuch war schnell gebaut und ebenso schnell wieder bedeutungslos. WirkTakt blieb relevant, weil die App ein konkretes Problem aus meinem Alltag löst.

2. Fachliche Erfahrung wird nicht ersetzt, sondern anders eingesetzt

Ich schrieb keinen Code. Meine Erfahrung half mir stattdessen bei Nutzerführung, Sprache, Priorisierung, Datenschutz, Qualität und Produktabgrenzung.

3. Präzises Feedback wird zur Kernkompetenz

Wer Wirkung, Zustand, Abweichung und gewünschtes Ergebnis klar beschreiben kann, arbeitet wesentlich besser mit generativen Werkzeugen zusammen.

4. Schnelle Umsetzung erhöht den Bedarf an Product Scoping

Wenn neue Funktionen leicht erzeugt werden können, braucht es umso mehr Klarheit darüber, was nicht gebaut wird.

5. Testen und Verantwortung bleiben menschliche Aufgaben

Generierter Code kann funktionieren und trotzdem unverständlich, inkonsistent oder für den Nutzungskontext ungeeignet sein. Die Freigabe einer Lösung bleibt eine verantwortliche Entscheidung.

6. Die Zukunft der Zusammenarbeit braucht neue Übergänge

Design, Produktarbeit und Entwicklung werden nicht einfach zu einer einzigen Rolle. Aber ihre Grenzen werden durchlässiger. Wir müssen weniger über starre Übergaben und mehr über gemeinsame, kontinuierliche Bewertung sprechen.

‍

Mein Fazit

Am 12. August hatte ich eine Idee. Am 23. August lag WirkTakt bei Apple zur Prüfung. Am 27. August war die App im App Store verfügbar.
Das Ergebnis begeistert mich nicht, weil eine KI mir die gesamte Arbeit abgenommen hätte. Es begeistert mich, weil ich mit ihrer Hilfe etwas umsetzen konnte, das vorher außerhalb meiner technischen Möglichkeiten lag.
Die KI schrieb den Code. Aber sie kannte weder das Ausgangsproblem noch meinen Qualitätsanspruch. Sie entschied nicht, welche Funktion relevant war, welche Formulierung verantwortungsvoll klang oder wann aus einem funktionierenden Build ein veröffentlichbares Produkt wurde.

Vielleicht ist das die spannendste Veränderung unserer Zusammenarbeit mit Computern: Wir müssen nicht mehr jede Umsetzung selbst beherrschen. Dafür müssen wir umso genauer erklären, beurteilen und verantworten können, was wir mit diesen neuen Möglichkeiten schaffen.

Wer tiefer in den Produktprozess einsteigen möchte, findet in meiner WirkTakt Case Study den Weg von der Excel-Tabelle bis zur veröffentlichten iPhone-App – einschließlich Produktprinzipien, Kernflow, Scoping, Datenschutz und Testing.

‍WirkTakt ist veröffentlicht. Ob die App auch außerhalb meines eigenen Alltags funktioniert, ist der nächste Teil des Experiments. Ich werde berichten.

‍

Hast du selbst schon ein Produkt gemeinsam mit KI umgesetzt oder siehst du die Entwicklung eher kritisch?
Dann diskutiere gerne unter meinem LinkedIn Beitrag mit mir.
Ich bin gespannt auf deine Erfahrungen.

👉 Hier gehts zur Diskussion, Link
‍

‍

Quellen und weiterführende Informationen

• Mensch und Computer 2026: „Transforming Interactions“
• Programm der Mensch und Computer 2026
• Andrej Karpathy: ursprünglicher Beitrag zu „Vibe Coding“
• OpenAI: Codex-Nutzung und Limits
• Jegham et al.: „How Hungry is AI?“
• METR: „Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity“
• METR: Update zur Entwickler-Produktivitätsstudie von 2026
• Reuters: „Mark Zuckerberg had a bold plan to replace Meta staff with AI. Here’s how it imploded.“

‍