Ich betrachte AI weder als gut noch als schlecht. Ich bewerte sie nicht aus der Distanz. Es ist die Art, wie ich jetzt arbeite. Das ist schrittweise passiert, über etwa zwei Jahre, und jeder Schritt veränderte, womit ich meine Zeit verbringe. Nicht die Probleme, die ich löse. Nicht die Qualität, nach der ich strebe. Nur wie ich dorthin gelange.

So verlief diese Verschiebung tatsächlich.

Ausgangspunkt: AI als Inhaltsmotor

Das erste Mal, dass AI ein Projekt grundlegend veränderte, war auf einer Schulungsplattform für gewerbliche LKW-Fahrer. BKF Online Schulungen bietet Pflichtfortbildungen für Berufskraftfahrer in Deutschland an. Fahrer schauen Schulungsvideos zu Sicherheit, Compliance und Gerätebedienung. Nach jedem Video beantworten sie Verständnisfragen, um zu bestätigen, dass sie den Inhalt verstanden haben.

Das Problem war der Massstab. Jedes neue Video benötigte einen Satz Fragen, richtige Antworten, Feedback zu falschen Antworten und Zeitstempel, die auf den relevanten Abschnitt des Videos verweisen. Das alles in mehreren Sprachen. Diesen Inhalt manuell für jedes Video zu erstellen war langsam und teuer. Es war der Engpass, der bestimmte, wie schnell neue Kurse ausgeliefert werden konnten.

Wir verbanden die OpenAI-APIs mit der Content-Pipeline. Wenn ein neues Video hochgeladen wird, transkribiert das System die Audiodatei automatisch, generiert Verständnisfragen aus dem Transkript, erstellt richtige und falsche Antworten, fügt Zeitstempel hinzu, damit eine falsche Antwort den Lernenden zum richtigen Abschnitt des Videos weiterleitet, und übersetzt das gesamte Paket in die benötigten Sprachen. Die gesamte Pipeline läuft ohne manuelle Eingriffe.

Das war kein Entwicklerproduktivitäts-Tool. Es war ein Produktmerkmal. AI beseitigte den Content-Produktions-Engpass, und die Plattform konnte ihre Kursbibliothek zu einem Bruchteil der bisherigen Kosten und Zeit skalieren. Das war das erste Mal, dass ich AI nicht als Experiment sah, sondern als Infrastruktur, die die Wirtschaftlichkeit eines Produkts verändert.

Coding-Begleiter: nützlich, aber begrenzt

Etwa zur gleichen Zeit begann ich, GitHub Copilot im Siemens SIMATIC AX Projekt einzusetzen. Das Team testete es als Entwickler-Tool und versuchte zu verstehen, wo es half und wo es im Weg stand.

In dieser Phase war es ein Coding-Begleiter. Autocomplete, dramatisch beschleunigt. Es konnte Boilerplate ausfüllen, Testfälle vorschlagen und gelegentlich aus einem Kommentar eine funktionierende Funktion produzieren. Nützlich, aber begrenzt. Der Entwickler erledigte immer noch das gesamte Denken. Die AI tippte nur schneller.

Der eigentliche Wert lag nicht im generierten Code. Er lag in der Reibung, die beim Ausprobieren wegfiel. Wenn das Schreiben einer Funktion dreissig Sekunden statt fünf Minuten dauert, ist man eher bereit zu experimentieren. Man schreibt die Version, von der man nicht sicher ist, weil das Wegwerfen fast nichts kostet. Diese veränderte Bereitschaft zu iterieren war wertvoller als der Code selbst.

Denkpartner: von der Idee zum Plan

Die nächste Verschiebung war, LLMs nicht zum Schreiben von Code zu verwenden, sondern zum Denken. Ich begann, lokale Modelle als eine Art adversariellen Interviewer einzusetzen. Ich beschrieb eine Idee, eine Architektur, ein Produktkonzept und bat das Modell, sie zu hinterfragen. Wo sind die Lücken? Welche Annahmen treffe ich? Was würde ein Skeptiker fragen?

Das war unordentlich und gesprächsartig. Viel Hin und Her. Viel menschliche Eingriffe. Das Modell würde einen Umweg nehmen und ich zog es zurück. Es verfehlte den Punkt und ich formulierte neu. Aber die Ausgabe waren nicht die Antworten des Modells. Die Ausgabe war mein Denken, geschärft dadurch, dass ich es gegen einen unerbittlichen (wenn auch manchmal stumpfsinnigen) Fragesteller verteidigen musste.

Was aus diesen Sessions herauskam, waren Pläne. Kein Code. Keine Designs. Strukturierte Pläne, die beschrieben, was zu bauen war, warum und in welcher Reihenfolge. Das Denken war meins. Der Prozess, es zu extrahieren, wurde durch das Modell beschleunigt.

Autonomer Builder: vom Plan zum Produkt

Dann übergab ich diese Pläne an Claude Code. Und die Rolle verschob sich erneut.

Die ersten Versuche waren eine Lernkurve. Zu viel Anleitung und die Ausgabe war genau das, was ich beschrieben hatte, aber in der Praxis kaum nutzbar. Zu wenig Anleitung und es baute etwas völlig anderes als beabsichtigt. Das richtige Mass an Führung zu finden war die Fähigkeit, die ich entwickeln musste. Nicht Prompt Engineering im oberflächlichen Sinne. Eher wie das Briefen eines neuen Teammitglieds: genug Kontext für gute Entscheidungen, genug Freiheit, um Probleme zu lösen, die ich nicht vorhergesehen hatte.

Das Hinzufügen von MCP-Servern veränderte die Dinge weiter. Das Verbinden von Claude Code mit einer Storyblok-CMS-Instanz bedeutete, dass der Agent Content-Strukturen abfragen, das Datenmodell verstehen und fundierte Entscheidungen über Komponenten und Layouts treffen konnte, ohne dass ich den Kontext manuell eintippen musste. Die benötigten Informationen waren direkt verfügbar, anstatt durch meine Beschreibung davon gefiltert zu werden.

Und jetzt sind wir an dem Punkt, wo ich ein Team von Agenten starten, ein klares Briefing mit Absicht und Einschränkungen bereitstellen und sie bauen lassen kann. Keine Produktionssysteme für Enterprise-Kunden. Aber funktionierende Prototypen. Greifbare Dinge, mit denen ich interagieren, sie gegen echte Szenarien testen und validieren kann, ob eine Idee standhält.

Was sich wirklich verändert hat

Meine Rolle verschob sich vom Schreiben von Code zur Validierung von Ergebnissen. Der Verlauf sieht so aus:

  • 2024: AI schreibt Inhalte, ich baue die Plattform darum herum
  • Anfang 2025: AI schreibt Code neben mir, ich treffe alle Entscheidungen
  • Mitte 2025: AI hinterfragt mein Denken, ich produziere bessere Pläne
  • Ende 2025: AI baut aus meinen Plänen, ich validiere und verfeinere
  • 2026: AI-Teams bauen aus meinen Briefings, ich konzentriere mich auf Problemdefinition und Qualität

Code wurde zu einer Schicht, die ich neu generieren kann. Wenn ein Prototyp nicht funktioniert, debugge ich ihn nicht. Ich verfeinere das Briefing und lasse ihn neu bauen. Wenn ein Ansatz falsch erscheint, erkunde ich drei Alternativen in der Zeit, die es früher brauchte, sich auf eine festzulegen. Die Wegwerfkosten sanken auf nahezu null, was bedeutet, dass die Bereitschaft zu experimentieren dramatisch zunahm.

Was sich nicht veränderte: Jemand muss immer noch das richtige Problem definieren. Jemand muss immer noch beurteilen, ob die Lösung tatsächlich für die Menschen funktioniert, die sie verwenden werden. Jemand muss immer noch die Architekturentscheidungen treffen, wo AI in ein System gehört und wo nicht. Das UX, die Architektur, die Problemdomäne. Das ist immer noch menschliche Arbeit. Es ist die Arbeit, die jetzt mehr, nicht weniger, zählt, genau weil alles andere billiger wurde.

Die eigentliche Stärke liegt nicht in mehr Output

Die Versuchung mit AI ist, sie einzusetzen, um mehr zu produzieren. Mehr Code, mehr Features, mehr Inhalte. Dieser Weg führt zu Rauschen. Mehr Zeug, das niemand bestellt hat, schneller gebaut als irgendjemand es bewerten kann.

Die eigentliche Stärke ist das Gegenteil. AI erlaubt mir, mich auf die Problemdomäne und das Ergebnis zu konzentrieren. Ich kann von einer Idee zu etwas Greifbarem schnell genug kommen, dass die Idee getestet wird, bevor ich Wochen in den Aufbau investiert habe. Ich kann Richtungen erkunden, die früher zu teuer zum Ausprobieren gewesen wären. Ich kann Arbeit ohne Schuldgefühle wegwerfen, weil die Kosten für ihre Neuerstellung trivial sind.

Das ersetzt nicht die Diagnose-Arbeit, das architektonische Denken, die fachübergreifenden Entscheidungen, die den Grossteil dessen ausmachen, was ich für Kunden tue. Es macht all das effektiver. Wenn ich in einen neuen Auftrag einsteige und eine Plattform verstehen muss, kann ich in Stunden statt Tagen Lösungen prototypisieren, um mein Verständnis zu testen. Wenn ich Architekturoptionen bewerte, kann ich Proof-of-Concept-Implementierungen von jeder einzelnen bauen, anstatt sie nur auf einem Whiteboard durchzudenken.

AI hat nicht verändert, wie gutes Engineering aussieht. Es hat alles, was kein gutes Engineering ist, leichter verwerfbar gemacht. Und das, still und leise, hat alles daran verändert, wie ich arbeite.