Vom Werkzeug zur Arbeitsweise

Auftakt der Serie „Von der Session zum System“.

Vor einiger Zeit saß ich in Berlin mit Sebastian Korfmann zusammen. Sebastian kenne ich als Software-Engineer aus dem Cloud- und Infrastruktur-Umfeld – jemand, der Werkzeuge nicht nach Marketing-Folien beurteilt, sondern danach, ob sie ihm im Alltag Arbeit abnehmen. Er erzählte von seinen Erfahrungen mit KI-Werkzeugen: was er damit baut, wie sich seine Arbeit verändert hat, wo es hakt. Ich habe interessiert zugehört – und dabei gemerkt, dass ich selbst erstaunlich wenig beisteuern konnte.

Das muss ich erklären. Ich arbeite seit über dreißig Jahren an Software, einen großen Teil davon an verteilten Systemen – Node, TypeScript, GraphQL, Cloud-Architekturen – und habe über viele Jahre Training für Softwareentwickler und Architekten gegeben. Was mich an dieser Arbeit am meisten reizt: digitale Produkte zu bauen, und zwar ganzheitlich. Die Fachdomäne wirklich verstehen, Richtungsentscheidungen treffen, gestalten – es geht mir schon lange nicht mehr nur um Programmierung und Architektur. Mit den Jahren haben sich auch meine Schwerpunkte verschoben: weg davon, jedes feine Detail selbst in der Hand zu haben, hin zu Struktur, Konsistenz, Prozessen, Produktivität, Methoden und Konzepten. Mit KI hatte ich bis dahin trotzdem noch nie gearbeitet. Keine einzige Session, kein Copilot. Nicht aus Ablehnung – grundsätzliche Skepsis gegenüber neuer Technik ist nicht meine Art. Es hatte sich schlicht nie ergeben. Der Rummel seit dem ChatGPT-Start Ende 2022 war zwar nicht zu überhören – Schlagzeilen, Konferenz-Keynotes, Kollegen, die davon erzählten –, aber was ich hörte und las, klang für mich nach beeindruckenden Demos, und meine Tage waren voll. Wenn überhaupt, war ich ein bisschen zurückhaltend – so, wie man eben zurückhaltend ist bei Dingen, die man noch nicht selbst ausprobiert hat.

Dazu kam noch etwas anderes, und darüber rede ich nicht so gern, weil es nichts mit Technik zu tun hat, sondern mit mir. Ich war müde geworden. Nicht am Beruf, sondern an einer bestimmten Sorte Vorhaben: eigene, größere Projekte, digitale Produkte, die ich lange im Kopf hatte. Ich kenne die Komplexität solcher Vorhaben gut genug, um zu wissen: Viele dieser Themen kann ich allein nicht in der Qualität umsetzen, die ich selbst erwarte. Die Ideen waren da, teils detailliert ausgearbeitet, in Notizen und halb angefangenen Repositories. Was fehlte, war die Kraft für die schiere Menge an Umsetzungsarbeit – neben Anstellung und allem anderen. Wer einmal versucht hat, ein komplettes Produkt allein zu bauen, kennt das Verhältnis: Auf eine Stunde, in der man wirklich gestaltet – eine Richtungsentscheidung, ein Konzept, ein Stück Fachlichkeit –, kommen zwanzig Stunden Fleißarbeit. Boilerplate, Konfiguration, Formulare, Fehlerbehandlung, Deployment, Dokumentation, dazu das ganze Organisatorische drumherum. Irgendwann habe ich aufgehört, neue Schubladen aufzumachen, weil die alten schon voll waren.

In dieser Verfassung traf ich also Sebastian. Was mich an dem Gespräch gepackt hat, war seine Art zu erzählen: keine Superlative, keine „das verändert alles“-Rhetorik, sondern die nüchterne Art, in der man einem Kollegen von einem Werkzeug berichtet, das sich im Alltag bewährt hat. Diese Tonlage kannte ich, und sie machte mich neugierig. Also habe ich mir vorgenommen, das Ganze endlich selbst auszuprobieren. Nicht zehn Minuten, sondern ein paar Tage, an echten Aufgaben.

Die ersten Tage

Ich habe mit Claude und ChatGPT angefangen, im Browser, an Aufgaben aus meinem tatsächlichen Alltag: ein Architekturkonzept gegenlesen, eine API-Migration skizzieren, einen Datenimport schreiben, den ich sonst vor mir hergeschoben hätte. Kurz darauf kamen Claude Code und Codex dazu – also die Werkzeuge, die nicht nur antworten, sondern im Terminal direkt am Repository arbeiten: Dateien lesen, ändern, Tests laufen lassen. Anthropic hatte Ende September Claude Sonnet 4.5 veröffentlicht, OpenAI etwa zeitgleich sein Codex-Update; ich bin, ohne es zu planen, in einem ziemlich guten Moment eingestiegen.

Und dann passierte etwas, womit ich nicht gerechnet hatte: Ich war binnen Tagen sehr angetan. Nicht milde interessiert – angetan. Drei Dinge haben mich erwischt:

• Die Geschwindigkeit. Aufgaben, für die ich einen halben Tag angesetzt hätte, waren in einer Stunde in einem Zustand, den ich ernsthaft reviewen konnte.
• Die Produktivität über den ganzen Tag. Nicht ein einzelner beeindruckender Moment, sondern die Summe: Es blieb abends messbar mehr fertig liegen als vorher.
• Die Qualität. Das hatte ich am wenigsten erwartet. Der erzeugte Code war nicht fehlerfrei, aber deutlich besser, als ich es nach allem, was ich über generierten Code gehört und gelesen hatte, erwartet hätte – strukturiert, mit sinnvoller Fehlerbehandlung, oft mit Tests.

Aus den paar Tagen Probe wurden Wochen täglicher Arbeit. Inzwischen arbeite ich jeden Tag mit diesen Werkzeugen und steige immer tiefer ein – gerade erst hat Anthropic mit den Skills eine Möglichkeit nachgelegt, Claude wiederverwendbare Arbeitsanweisungen mitzugeben, und ich merke, dass ich anfange, solche Ankündigungen zu lesen wie früher Release-Notes von Node.

Ein paar Wochen sind keine Erfahrung. Das ist mir bewusst, und genau deshalb schreibe ich das hier auf. Wer so schnell zum täglichen Nutzer wird, sollte der eigenen Begeisterung erst einmal misstrauen – frische Begeisterung ist ein schlechter Zeuge. Also versuche ich, genau hinzuschauen und zu notieren, was ich tatsächlich beobachte – mit dem einzigen Prüfstein, den ich habe: über dreißig Jahre Handwerk, an denen ich jedes Ergebnis messen kann.

Beobachtung eins: Erzeugen wird billig, Prüfen wird der Engpass

Die erste Verschiebung habe ich schon nach wenigen Tagen bemerkt, und sie ist fundamentaler, als sie klingt. Der teure Teil meiner Arbeit war immer das Erzeugen: Code schreiben, Dokumente formulieren, Konzepte ausarbeiten. Das Prüfen – Reviews, Gegenlesen, Abnahme – war der kleinere Posten. Dieses Verhältnis kippt gerade. Erzeugen ist plötzlich billig; in einer Stunde entsteht mehr Text und Code, als ich früher an einem Tag geschafft hätte. Was nicht billiger geworden ist: beurteilen, ob das Erzeugte stimmt. Meine Arbeit verlagert sich sichtbar vom Schreiben zum Lesen, vom Produzieren zum Begutachten.

Im Gespräch mit einem Kollegen habe ich dafür eine Formulierung gefunden, die hängen geblieben ist: Das Werkzeug ist weniger Assistent, mehr Sekretär. Ein Assistent, wie ihn die Produktnamen versprechen, ergänzt hier eine Zeile und schlägt dort ein Wort vor – die Arbeit bleibt meine. Ein Sekretär im alten Sinn nimmt ganze Vorgänge entgegen: Ich diktiere die Absicht, er fertigt das Schriftstück, und ich zeichne ab. Das klingt bequemer, ist aber eine andere Verantwortung. Beim Assistenten prüfe ich Vorschläge im Vorbeigehen; beim Sekretär muss ich das fertige Stück wirklich lesen, denn meine Unterschrift steht darunter. Wer abzeichnet, ohne zu lesen, hat nicht delegiert, sondern kapituliert. Ich ahne, dass in dieser Verschiebung der eigentliche Umbau meiner Arbeitsweise steckt – nicht im Werkzeug selbst.

Beobachtung zwei: Die Schubladen gehen wieder auf

Die zweite Beobachtung ist persönlicher, und sie hat mich mehr überrascht als jede Benchmark. Die Müdigkeit, von der ich oben geschrieben habe, ist nicht weg – aber sie hat ihren Grund verloren. Die Produktideen, die liegen geblieben sind, weil die Umsetzung für einen Einzelnen zu groß war, sind plötzlich wieder in Reichweite. Nicht, weil die KI das Produkt baut. Sondern weil sie genau den Teil übernimmt, der mich zermürbt hat: die zwanzig Stunden Fleißarbeit rund um die eine Stunde, die wirklich Nachdenken verlangt. Das Formular-Grundgerüst, die Testabdeckung, der Import-Adapter, das Deployment-Skript – all das entsteht jetzt so schnell, dass ich – wie sagt man so schön – das Eisen schmieden kann, solange es heiß ist.

Vielleicht hat mich das Ganze auch deshalb so schnell für sich eingenommen: Meine Schwerpunkte hatten sich über die Jahre ohnehin genau dorthin verschoben, wo diese Werkzeuge nichts wegnehmen – Struktur, Konsistenz, Konzepte, die Fachdomäne, die Richtungsentscheidungen. Vieles von der Detailarbeit und den wiederkehrenden Aufgaben dagegen, auch den organisatorischen, wird jetzt wieder einfacher und damit produktiver. Nicht alles. Aber genug, dass es wieder Spaß macht.

Ich habe in den letzten Wochen abends wieder an eigenen Sachen gebaut, freiwillig und mit einer Freude, die ich eine Weile nicht hatte. Das ist die Stelle, an der ich vorsichtig formulieren muss, weil sie sich so leicht zur Heilsbotschaft aufblasen lässt. Also nüchtern: KI ist für mich gerade vor allem ein Hebel für den Einzelnen mit Erfahrung. Die Betonung liegt auf beidem. Der Hebel wirkt, weil ich nach dreißig Jahren weiß, was ich bauen will, wie es geschnitten sein muss und woran ich erkenne, dass ein Ergebnis taugt. Ob derselbe Hebel auch für jemanden wirkt, der diese Urteilsfähigkeit noch nicht hat, weiß ich schlicht nicht – ich habe da einen Verdacht, aber Verdacht ist kein Wissen, und für diese Serie will ich beides sauber auseinanderhalten.

Beobachtung drei: Der Ton stimmt immer

Die dritte Beobachtung halte ich nur kurz fest, denn ich verstehe sie noch nicht gut genug, um mehr daraus zu machen. Mir fällt auf, wie diese Systeme antworten. Im Berufsleben gibt es dafür ein augenzwinkerndes Kürzel: SABTA – sicheres Auftreten bei totaler Ahnungslosigkeit. Die Psychologie kennt das Muster als Dunning-Kruger-Effekt: Am selbstbewusstesten tritt oft auf, wer am wenigsten weiß. Genau so wirken diese Systeme auf mich – die richtige Auskunft und die falsche kommen im selben ruhigen, kompetenten Ton. In einem Code-Review verrät sich ein unsicherer Kollege durch Formulierungen – „ich glaube“, „müsste eigentlich“. Hier gibt es dieses Signal nicht. Zweimal in den vergangenen Wochen hätte ich beinahe eine Behauptung übernommen, die sich bei der Prüfung als frei erfunden herausstellte – eine API-Signatur, die es nie gab, souverän vorgetragen. Beide Male hat mich nur die Gewohnheit gerettet, Dinge nachzuschlagen. Dieses sichere Auftreten verdient ein grundsätzliches Misstrauen, und ich will verstehen, woher es kommt – strukturell, nicht anekdotisch. Das hebe ich mir für später in dieser Serie auf, wenn die Beobachtungen dafür beisammen sind.

Was diese Serie werden soll

Ich beginne hier eine Serie, weil ich ahne, dass die Geschichte größer ist als mein Schreibtisch. Im Moment beobachte ich mich selbst: einen Einzelnen in der Session, mit direkter Kontrolle über jedes Ergebnis. Aber ich arbeite nicht allein – ich arbeite in und mit Teams, und ein Team ist etwas anderes als die Summe einzelner Sessions. Und über den Teams stehen Unternehmen mit ihren Prozessen, ihrem Wissen, ihrer Verantwortung. Diesen Bogen will ich in den kommenden Folgen Schritt für Schritt durchgehen: vom Ich über das Wir zum System. Nicht als Theorie, sondern entlang dessen, was ich tatsächlich erlebe und ausprobiere – inklusive der Sackgassen, von denen es absehbar einige geben wird.

Die nächste Frage drängt sich dabei schon auf. Im Team, mittags unter Kollegen, zuletzt auf einem Konferenzflur: Das Gespräch landet nach wenigen Minuten an derselben Stelle. Welches Modell ist das beste? Claude oder GPT, welche Version, welche Benchmark. Ich habe diese Diskussion selbst geführt und dabei ein Unbehagen entwickelt, das ich erst allmählich einordnen kann: Nach diesen ersten Wochen täglicher Arbeit fällt mir auf, dass die Wahl des Modells meine Ergebnisse weniger verändert hat als so ziemlich alles andere an meiner Arbeitsweise. Alle reden über das beste Modell – aber ist das überhaupt die richtige Frage? Der gehe ich in der nächsten Folge nach.

Weiterführende Quellen

• Introducing Claude Sonnet 4.5 – Anthropics Ankündigung des Modells, mit dem ich eingestiegen bin (September 2025)
• Claude Sonnet 4.5 is probably the „best coding model in the world“ – Simon Willisons nüchterne Ersteinschätzung
• Introducing upgrades to Codex – OpenAIs Codex-Update mit GPT-5-Codex (September 2025)
• Equipping agents for the real world with Agent Skills – Anthropics Engineering-Beitrag zu Skills (Oktober 2025)

Kommentare