Warum eine Retrospektive

Vor etwas mehr als einem Jahr habe ich angefangen, AI-Tools nicht mehr nur zu testen, sondern wirklich produktiv in meinen Engineering-Alltag zu integrieren. Heute kann ich diese Vermutung bestätigen — mit einer wichtigen Einschränkung: Es hängt fast ausschließlich davon ab, wie man die Werkzeuge nutzt. Nicht davon, welches gerade als Top-Tool gilt.

Diese Retrospektive ist ein Versuch, die wichtigsten Erkenntnisse aus zwölf Monaten in fünf Lehren zu bündeln. Die Lehren sind nicht spektakulär. Sie sind das Ergebnis von echten Versuchen, echten Fehlern und echten Anpassungen.

Lehre 1: Der Workflow ist wichtiger als das Modell

Die häufigste Diskussion in der KI-Engineering-Welt dreht sich um Modelle. Welches ist gerade vorne, welches hat den größten Kontext, welches ist am günstigsten. Diese Diskussionen sind interessant, aber im Alltag sehr nachrangig.

Was wirklich zählt, ist der Workflow drum herum. Welche Skills sind definiert. Wie sind Subagents strukturiert. Wo greifen MCP-Server. Wie ist die Fallback-Kette aufgebaut. All das hat zusammen einen viel größeren Effekt auf die Produktivität als die Wahl zwischen Modell A und Modell B.

Konsequenz: Investiere in Skills, Prompt-Vorlagen, Tool-Anbindungen, Review-Strukturen — nicht in Modell-Vergleiche.

Lehre 2: Robustheit ist Pflicht, nicht Luxus

Eine der unangenehmsten Erkenntnisse: KI-Workflows können still versagen. Klassische Pipelines sind laut, wenn sie kaputt gehen. KI-Pipelines sind oft leise. Bei mir hat das zu einem mehrwöchigen stillen Ausfall geführt — der Workflow lief technisch, klassifizierte aber praktisch nichts mehr.

Vier Schichten die ich heute immer einbaue:

  • Fallback-Ketten: Mehr als ein Provider, mehr als ein Modell
  • Strukturierte Logs: Was gerade passiert, welche Stufe aktiv ist
  • Smart-Alerts: Workflow ohne Erfolg seit X Stunden → Alarm
  • Regelbasierter Fallback: Wenn alle KI-Stufen ausfallen, nicht Stillstand

Lehre 3: Persistentes Memory ist der echte Multiplikator

Workflows ohne persistentes Memory sind Wegwerf-Workflows. Nicht weil sie nicht funktionieren, sondern weil sie nicht klüger werden. Die ersten sechs Monate ohne Memory waren weitgehend Wegwerf-Sessions.

Heute lesen meine wichtigsten Workflows beim Session-Start eine Memory-Datei: bekannte Eigenheiten von Systemen, persönliche Präferenzen, Lessons Learned. Der Effekt ist groß — der Agent versteht den Kontext besser, macht weniger Anfängerfehler.

Lehre 4: Sicherheit von Anfang an

KI-Workflows haben ein eigenes Sicherheits-Profil. Vier alltägliche Risiken:

  • Daten-Lecks: Screenshots mit internen URLs, Logs mit Tokens ungefiltert weitergegeben
  • Tool-Berechtigungen: Minimale Berechtigung pro Aufgabe — was nicht gebraucht wird, ist nicht zugänglich
  • Provider-Datenschutz: Was man an externe Anbieter schickt, geht dorthin
  • Action-Grenzen: Was darf der Agent automatisch, was braucht menschliche Bestätigung

Lehre 5: Team-Fähigkeit ist der entscheidende Schritt

KI-Tools, die nur für Einzel-Engineers funktionieren, haben eine begrenzte Zukunft. Was mein Setup braucht, damit es team-fähig wird: geteilte Skills, geteilte MCPs, klare Tool-Vorgaben, dokumentierte Konventionen, erwartete Verifikation.

Team-Fähigkeit ist aus meiner Sicht der nächste große Schritt für KI-gestützte Engineering-Arbeit. Persönliche Workflows sind weitgehend ausgereift.

Mein Blick nach diesem Jahr

KI-gestützte Engineering-Arbeit ist 2026 an einem Punkt, an dem sie real produktiv ist — vorausgesetzt man baut sie ernsthaft auf. Was sich über das Jahr nicht verändert hat: KI ersetzt keine Verantwortung. Sie nimmt einem weder Architektur-Entscheidungen noch fachliche Einordnung ab.

Was sich sehr verändert hat: die Geschwindigkeit, mit der gute technische Arbeit möglich wird, wenn das Setup stimmt. Gute Engineers, die strukturiert arbeiten, können mehr erreichen als je zuvor.