KI verändert nicht nur, was wir bauen — sie transformiert grundlegend, wie wir arbeiten. Product-Engineering-Organisationen in den Bereichen Dev, PM, Program und QA müssen ihre Prinzipien weiterentwickeln, um diesen Wandel voll auszuschöpfen. Bei Fynd treiben wir diese Veränderungen aktiv voran, damit wir die Kraft der KI in unserer gesamten Product-Engineering-Organisation wirklich nutzen können.

Im Folgenden stellen wir die vorgeschlagenen Arbeitsweisen vor, mit denen unsere Teams jede Rolle innerhalb von Product und Engineering spürbar beschleunigen und gleichzeitig die typischen Übergaben zwischen Organisationseinheiten deutlich reduzieren können.

1. Ein einzelnes Repo pro Produkt

Fasse alle zugehörigen Microservices eines Produkts in einem einzigen Git-Repository zusammen. Das langfristige Ziel ist es, die Anzahl der Repos zu verringern und Setup sowie Verwaltung zu vereinfachen.

Das bedeutet nicht, alles in einen Monolithen zu verschmelzen. Die Microservices-Architektur bleibt bestehen. Die Änderung betrifft die Git-/Code-Repo-Ebene — eine einheitliche Codebasis pro Produkt, um den Zugang zu verbessern, das Onboarding zu vereinfachen, Stack-Konsistenz sicherzustellen und die Navigation in der Codebasis zu erleichtern.

Der eigentliche Durchbruch: Auch nicht-technische Teammitglieder können jetzt sinnvoll beitragen. Product Manager sollten mit KI-Unterstützung auf SDE-1-Niveau mitarbeiten können. Design-Teams sollten UI/UX-Verbesserungen direkt umsetzen können. Einfache und mittelschwere Entwicklungsaufgaben werden für alle wirklich zugänglich.

2. Das Repo als zentraler Wissens-Hub

Euer Repo sollte zur einzigen Quelle der Wahrheit für alles Wissen und alle Dokumentation werden. Erstellt ein /docs-Verzeichnis und speichert dort alles — anstatt Informationen über Ticketsysteme, Dokumentationstools, PDFs und andere verstreute Plattformen zu verteilen.

Skills, Dokumentation, Regeln, Hooks und Runtime-Versionen sollten zentralisiert sein. Selbst wenn Inhalte ursprünglich als Bild, PDF oder Diagramm vorliegen, konvertiert sie in Markdown, um die KI-Sichtbarkeit und das kontextuelle Verständnis zu verbessern.

Das Repo wird so zu einer vollständig indexierten Wissensbasis für KI-gestützte IDEs wie Cursor oder Claude Code. Diese Tools konsumieren automatisch die Kontextinformationen und schaffen eine einheitliche Arbeitsoberfläche für alle Beteiligten — QA-Engineers, Program Manager und Product Manager können den Code direkt erkunden und hinterfragen, wodurch Informationsverluste bei der Übersetzung minimiert werden.

3. Keine APIs mehr programmieren — Agents bauen

Anstatt traditionelle APIs zu entwickeln, beginnt damit, Agents zu bauen. Verändert euer Denken hin zum Entwurf intelligenter, autonomer Systeme, die argumentieren, entscheiden und handeln können.

Erkundet Frameworks wie LangGraph, OpenAI Agents, CrewAI und ähnliche Tools. Diese Ökosysteme bieten bereits die Grundlagen, die ihr braucht — verschwendet keine Zeit damit, grundlegende Infrastruktur neu zu erfinden.

CRUD ist kein Differenzierungsmerkmal mehr. Es ist im Grunde ein „Hello World"-Prompt. Mit KI-gestützten IDEs kann jeder, der verständliches Englisch schreiben kann, CRUD-Anwendungen in unter einer Stunde generieren.

4. Feature-basierte Teams statt Service-basierte Teams

Keine getrennten Frontend-Teams, Backend-Teams oder funktionsbasierten Gruppen mehr. Arbeitet als Feature-first-, ergebnisorientierte Teams.

Jedes Team verantwortet ein Feature von Anfang bis Ende — von der Problemdefinition und dem Design über Entwicklung, Integration, Testing und Release bis hin zur Wirkungsanalyse nach dem Launch. Keine fragmentierte Ownership, keine schichtbasierten Übergaben, kein „Das ist die Verantwortung eines anderen Teams."

Wenn ein Feature ansteht, übernimmt ein einzelnes Team die volle Verantwortung, es auszuliefern — vollständig und korrekt. End-to-End-Ownership. Klare Verantwortlichkeit. Echte Ergebnisse.

5. Über Rollengrenzen hinausgehen

Die Grenzen zwischen Devs, QAs, PMs und Program werden zunehmend unsichtbar.

KI hat die Hürde zur Umsetzung dramatisch gesenkt. Man braucht keine tiefe Spezialisierung mehr, um sinnvoll in Frontend, Backend, Testing, Automatisierung oder Dokumentation beizutragen. Mit KI-IDEs und Interfaces in natürlicher Sprache kann jeder CRUD-Apps bauen, UIs generieren, Skripte schreiben oder Tests erstellen.

PMs und Program Manager sollten technisch versiert werden und mit KI Prototypen bauen. Engineers sollten direkt mit Kunden interagieren und Lösungen mitgestalten — nicht nur Tickets abarbeiten. Die Zukunft gehört denen, die in End-to-End-Problemverantwortung denken, nicht in funktionalen Silos.

6. Code ist billig — Ownership, Innovation und Geschwindigkeit zählen

Code zu generieren ist keine seltene Fähigkeit mehr. Was selten ist: Klarheit im Denken, gutes Urteilsvermögen, tiefes Problemverständnis und die Fähigkeit, schnell und mit Überzeugung voranzugehen.

Das Differenzierungsmerkmal ist nicht „Kannst du programmieren?", sondern „Kannst du das richtige Problem identifizieren, den richtigen Ansatz entwerfen und schnell zur Wirkung bringen?" Da KI die Ausführungszeit komprimiert, verlagert sich der Wert auf die Qualität der Entscheidungsfindung und Eigeninitiative.

Entweder erweiterst du deine Rolle über die definierten Grenzen hinaus, oder du wirst zum Ultra-Experten für Probleme, die weit über das hinausgehen, was KI bewältigen kann — tiefgreifendes Performance-Engineering, fortgeschrittene Sicherheitsanalyse, Architekturdesign im großen Maßstab und komplexe Domänenherausforderungen auf Basis von nicht-öffentlichem Wissen.

7. QA muss über manuelle Arbeit hinauswachsen

Quality Engineers müssen sich zu vollwertigen Quality-and-Automation-Engineers weiterentwickeln.

Automatisieren war noch nie so einfach. Was früher umfangreichen Code erforderte, dauert mit KI-Unterstützung jetzt kaum 15 Minuten — und das in höchster Codequalität. QA hat gerade den besten Vorteil: Bauen ist einfach geworden, aber Verifizierung ist nach wie vor ungelöst. Es braucht Menschen, die sowohl durch Automatisierung als auch manuell testen können.

QA-Engineers können anfangen, kleine Bugs selbst zu beheben. Wer immer noch ausschließlich manuell arbeitet, zeigt einen Mangel an Initiative, über die aktuelle Aufgabe hinauszudenken.

8. Architektur einfach halten, bis echte Skalierung nötig ist

Führt keine komplexen Tech-Stacks ein, bevor ihr echte Skalierung habt. In der Anfangsphase zählen Geschwindigkeit und Klarheit weit mehr als architektonische Raffinesse. Startet mit etwas Einfachem, leicht Verständlichem und mit möglichst wenigen beweglichen Teilen.

Kafka, Redis oder andere schwergewichtige Komponenten für kleine Erweiterungen einzusetzen, ist oft eine Verschwendung von Speicher, Engineering-Aufwand und operativem Overhead. Komplexität muss verdient werden — nicht vorausgesetzt.

Optimiert zuerst die Grundlagen. Wenn eure Datenbankindizes noch nicht vollständig optimiert sind, ist eine Caching-Schicht nur eine Verschleierung von Ineffizienz. Baut einfach, skaliert wenn nötig und führt fortgeschrittene Komponenten erst dann ein, wenn das Problem sie wirklich erfordert.

9. Fallt nicht auf den Mythos herein: „KI lässt mich das Programmieren verlernen"

Das Argument, dass KI uns das Programmieren verlernen lässt, ist so, als würde man sagen, wir sollten keine Waschmaschinen benutzen, weil wir vergessen könnten, wie man Wäsche von Hand wäscht. Was wirklich zählt, ist das Ergebnis und der gelieferte Mehrwert — nicht der manuelle Aufwand dahinter.

Wir schreiben die meisten Systeme heute nicht mehr in Assembly oder gar C, obwohl diese Sprachen effizient sind. Höherwertige Werkzeuge lassen uns schneller arbeiten und komplexere Systeme bauen. KI ist einfach der nächste Schritt in dieser Entwicklung — sie beschleunigt die Entwicklung und ermöglicht es uns, uns auf übergeordnete Problemlösung zu konzentrieren.

Im Kern sind wir Problemlöser. Code zu schreiben ist nur ein Werkzeug in unserem Werkzeugkasten. Es ermöglicht die Lösung, aber es ist nicht die Lösung selbst.

10. Sei neugierig — frag die KI alles

Hab keine Angst, der KI jede einzelne Frage zu stellen, egal wie grundlegend sie ist. Es gibt kein Urteil — KI ist unendlich geduldig und rund um die Uhr verfügbar.

Nutze KI als deinen persönlichen Lehrer. Lass dir Konzepte Schritt für Schritt erklären, bis du etwas vollständig verstanden hast. Der schnellste Weg, Wissenslücken zu schließen, ist einfach zu fragen — anstatt so zu tun, als wüsste man etwas, oder stundenlang zu suchen.

Lernen ist keine Einbahnstraße. Während du der KI Fragen stellst, bringst du ihr auch deinen Kontext bei — deine Codebasis, dein Produkt, deine Rahmenbedingungen. Je mehr du interagierst, desto besser wird sie darin, dir zu helfen.

Die Menschen, die am schnellsten wachsen werden, sind nicht diejenigen, die bereits alles wissen — es sind diejenigen, die neugierig genug sind, so lange zu fragen, bis sie es wirklich verstanden haben.

Enjoyed this thought?

Get notified when I publish new insights.

Subscribe to Newsletter

Related Thoughts

Vom Ingenieur zum CTPO: Technische Führung im großen Maßstab

Die Reise vom Code-Schreiben zur Führung von Engineering-Organisationen: wie technische Tiefe mit Führung kombiniert wird und was im großen Maßstab wirklich zählt.

KI-gestützte Medienverarbeitung: Was Wir Beim Bauen von PixelBin Gelernt Haben

Lektionen vom Bauen von KI-Medientools im großen Maßstab: Inferenzoptimierung, API-Design und Ausgleich zwischen Qualität und Latenz.

Warum AI-First Organisationsdesign Nicht Um Tools Geht

Die meisten KI-Transformationen scheitern, weil Organisationsdesign ignoriert wird. So bauen Sie AI-First-Organisationen, die tatsächlich funktionieren.