AI-gestützte Wissensarbeit: Wie ich meinen Recherche- und Schreibprozess neu aufbaue

Wie verändert AI, wie wir arbeiten? Die Frage stellt sich gerade jeder. Nur: Darüber nachdenken lässt einen nicht spüren, wo es besser wird und wo schlechter. Das geht nur durch Ausprobieren, Experimentieren, Rinse and Repeat.

Spätestens seit dem ChatGPT-Moment Ende 2022 setze ich mich auf verschiedenen Feldern der Frage aus: Was ändert sich, wenn ich AI nicht nur einsetze, sondern meinen Prozess darum herum neu aufbaue? Besser? Schlechter? Anders? Muss man herausfinden.

Dieses Feld hier: Wie ich recherchiere und schreibe. Fachartikel in unserem Fachgebiet. Nicht Theorie, sondern was sich tatsächlich verändert hat.

Der Kipppunkt, es wirklich praktisch anzugehen, war Claude Code. Monatelang nur fürs Coding eingesetzt. Bis irgendwann im November 2025 der Gedanke kam: Das ist nicht nur ein Coding-Tool. Das ist ein Workflow-Tool. Für alles. Dass Anthropic es inzwischen "Claude Code + Cowork" nennt, bestätigt genau diesen Shift. Drei Monate rein.

Seit 15 Jahren mache ich im Grunde dasselbe: Teams helfen zu verstehen, dass nicht das Tool die Veränderung bringt, sondern der Workflow, den das Tool ermöglicht. Das war so, als wir von Wiki-Seiten und Shell-Skripten zu Puppet und Chef gegangen sind. Das war so bei Terraform und Pulumi — ein Workflow, der für AWS, Azure, Google und das eigene Rechenzentrum gleich funktioniert. Das war so bei CI/CD mit maschinenlesbaren BDD-Tests bis hin zu Continuous Deployment. Jetzt ist AI das neue Schweizer Taschenmesser, das viele dieser Workflows nochmal verbessern kann.

Und irgendwann fiel mir auf: Ich helfe Teams seit Jahren bei genau diesem Muster — und schreibe selbst noch wie vor zwei Jahren. Recherche: manuell. Quellensuche: manuell. Faktencheck: manuell. Solide. Langsam. Limitiert durch die Stunden am Tag.

Die Dark-Factory-Serie hätte ich so nicht geschrieben. Drei Teile, jeweils 30+ Primärquellen aus fünf Ländern. Zu aufwändig neben dem Tagesgeschäft.

Also habe ich angefangen, die Patterns aus der Softwareentwicklung auf das Schreiben anzuwenden. Spec schreiben, Agent arbeiten lassen, Output kritisch prüfen. Klingt glatter als es ist.

Wie andere das machen

Ethan Mollick schreibt jeden Post selbst. AI gibt Feedback am fertigen Entwurf. Simon Willison veröffentlicht Commit-Hashes — man kann seine AI-generierten Texte auf die exakten Prompts zurückführen. Tiago Forte sagt offen: Claude formuliert 90% seiner Texte.

Drei Leute, drei komplett verschiedene Ansätze. Meiner ist nochmal anders. Und vermutlich in sechs Monaten auch schon wieder.

Was ich gerade mache

1. Das Recherche-Briefing

Am Anfang steht ein Briefing. Kein Prompt. Ein Dokument, das ich selbst schreibe: Was wissen wir schon? Was fehlt? Welche Quellen müssten existieren, wenn die These stimmt?

Klingt trivial. Ist es nicht.

Zu wissen, was man nicht weiss, und das so zu formulieren, dass eine Maschine damit arbeiten kann — das ist der Teil, den ich am wenigsten delegieren kann. Ein schlechtes Briefing produziert plausibel klingende Ergebnisse, die an den eigentlichen Fragen vorbeigehen. Ein gutes spart Stunden.

2. Multi-Modell-Recherche

Das Briefing geht an Gemini Deep Research, ChatGPT und Claude. Alle drei. Gemini findet aktuelle Studien. ChatGPT liefert gut bei US-Quellen. Claude bei strukturierter Synthese. Was nur ein Modell findet, behandle ich mit mehr Skepsis als was alle drei unabhängig liefern.

Wichtig: Rohmaterial. Nicht Wahrheit.

Manchmal zeigt die Recherche eine Lücke. Für die Dark-Factory-Serie hatten wir jede Menge US- und UK-Daten zur Junior-Pipeline-Krise, aber fast nichts aus dem DACH-Raum. Also: Folge-Briefing, nur für DACH-Arbeitsmarktdaten. Bitkom, ZEW, IAB, ICT-Berufsbildung Schweiz. Diese Nachrecherche hat den dritten Artikel substantiell verändert. Ohne sie wäre der DACH-Abschnitt dünn geblieben.

3. Muster finden

Dann wird es manuell. Recherche-Ergebnisse durchgehen, markieren was belastbar ist, was wackelt, was rausfliegt. Und schauen: Welche Muster tragen einen Artikel?

Pflichtenheft-Denken und Spec-Driven Development — im Grunde dasselbe Pattern, 30 Jahre auseinander. Oder die duale Ausbildung als strukturelles Äquivalent zu Molly Kinders Residency-Modell. Solche Verbindungen ziehe ich. Die kommen nicht aus der Maschine. Zumindest noch nicht.

4. Texterstellung

Aus den Mustern wird ein Struktur-Briefing: welche Argumente in welcher Reihenfolge, welche Daten stützen was, welcher Ton. Dann schreibe ich den Artikel mit Claude Code.

Ja. Genau das Level 4 aus dem Dark-Factory-Artikel. Spec schreiben, Agent arbeiten lassen, Output prüfen. Der Blog beschreibt nicht nur diesen Workflow — er ist dieser Workflow.

5. Faktencheck

Kein Entwurf geht raus ohne mehrere Runden. Stimmt die Zahl mit der Quelle überein? Primärquelle oder sekundär? Ist eine Behauptung empirisch belegt oder meine Interpretation — und ist das klar gemacht? Funktionieren die Links?

Für die Dark-Factory-Serie: fünf Runden.

Ein Beispiel. Gemini lieferte "54% Rückgang bei Junior-Stellenausschreibungen in Deutschland", Verweis auf Indeed Hiring Lab. Die Zahl liess sich aus der verlinkten Quelle nicht verifizieren. Raus damit. Ersetzt durch eine qualitative Trendaussage, die sich belegen lässt.

Faktencheck frisst die meiste Zeit. Schafft auch den meisten Wert. AI beschleunigt die Recherche, aber Verifikation bleibt Handarbeit. Definitiv.

6. Bilder

Hero-Images und Infografiken: Gemini Image Generation. Jedes Bild wird gegen den aktuellen Text geprüft — wenn sich Text durch Faktencheck ändert, kann ein Bild ungültig werden. Für die Dark-Factory-Serie habe ich 15 Infografik-Varianten generiert. Da probiere ich noch viel aus.

7. Der externe Holdout-Check

Nach fünf, sechs, sieben Iterationen sind die Modelle confident: alles passt. Quellen geprüft, Zahlen belegt, keine offenen Punkte. Genau dann braucht man einen Check, der nicht im selben System steckt.

Ich lasse den fertigen Artikel durch GPTZero. Nicht wegen des AI-Scores — der liegt bei 95-100%, und das ist ehrlich. Wofür: den Plagiarismus-Score als Proxy für fehlerhafte Quellenangaben. Und tatsächlich, auch nach mehreren Faktencheck-Runden, in denen ich und die Modelle überzeugt waren, alles sei sauber — kaputte Referenzen. Links ins Leere. Zuschreibungen mit einer Indirektion zu viel.

Seitdem läuft zusätzlich ein eigens gebauter Reference-Checker-Agent über alle Links. Jede URL wird geprüft: HTTP-Status, Spezifität, Inhaltsübereinstimmung. Bei der Dark-Factory-Serie hat das über 40 Probleme gefunden. Quer über fünf Artikel. Am häufigsten: AI-halluzinierte URL-Slugs. Die Domain stimmt, der Pfad ist erfunden. Sieht auf den ersten Blick gut aus. Führt ins Nichts.

Bisheriger Plagiarismus-Höchstwert bei GPTZero: 4%. Jeder Match war am Ende korrekte Zitation, kein unattribuierter Inhalt. Aber der Weg dahin hat gezeigt: Die AI-gestützten Schleifen allein reichen nicht. Man braucht einen komplett unabhängigen Prüfpunkt von aussen.

Wobei — auch mit dem externen Check bin ich noch nicht zufrieden. Die 1-4% Plagiarismus-Score sind irreführend. 90% davon sind wörtliche Zitate, korrekt attribuiert, mit Fussnote und Link. GPTZero findet eine Textübereinstimmung mit der Quelle und flaggt sie. Zu Recht, aus Sicht des Tools: Es sieht identischen Text und kann nicht unterscheiden, ob das ein Plagiat ist oder eine saubere Zitation.

Das Problem sitzt tiefer. Meine Zitationen sind Hugo-Fussnoten — Prosa-Text am Ende des Artikels. Für Menschen lesbar. Für Maschinen ein Blob, den man parsen und interpretieren muss, um die Verbindung zwischen Inline-Marker und Quellenangabe herzustellen. Es gibt keinen strukturierten Weg für ein Tool zu sagen: "Ah, der Satz in Zeile 47 ist ein Zitat aus Quelle 3, korrekt attribuiert, kein Plagiat."

Was es bräuchte: maschinenlesbare Metadaten. BibTeX, CSL-JSON, strukturierte Frontmatter — irgendwas, das ein Plagiarismus-Checker oder ein Faktencheck-Agent konsumieren kann, ohne Prosa zu interpretieren. Hugo-Fussnoten waren die pragmatische Wahl für Geschwindigkeit und Einfachheit. Aber sie sind eine Sackgasse, wenn man den Zitationsprozess automatisiert prüfbar machen will. Da fehlt mir noch ein Stück in der Pipeline.

8. Git

Alles versioniert. Entwürfe, Briefings, Recherche-Ergebnisse, Editing-Schleifen. Die komplette Entstehungsgeschichte ist nachvollziehbar, vom ersten Briefing bis zum finalen Text. Simon Willisons Idee, adaptiert auf meinen Workflow.

Was funktioniert

Recherchetiefe, die vorher unrealistisch war. Die Dark-Factory-Serie zitiert über 30 Primärquellen pro Artikel. Fünf Länder. Zwei Sprachen. Harvard, Brookings, McKinsey, Bitkom, ZEW, IAB. Jede einzelne Quelle manuell geprüft.

Ohne AI wäre das ein Vollzeit-Rechercheprojekt gewesen. Mit AI: intensiv, aber machbar neben dem Tagesgeschäft. Mehr Reichweite bei der Recherche, gleiche Qualitätsansprüche bei der Prüfung.

Was nicht funktioniert

Drei Monate rein, ein paar Sachen laufen, anderes nicht.

Multi-Modell-Recherche liefert definitiv breiter als jede Einzelquelle. Die Faktencheck-Schleifen fangen Halluzinationen zuverlässig ab. Git macht den Prozess nachvollziehbar. So weit, so gut.

Was noch nicht funktioniert: Der Übergang von Recherche zu Struktur ist zu manuell. Infografiken brauchen zu viele Iterationen. Und ich habe keinen guten Workflow für die englische Version — Rewrite, nicht Übersetzung. Da fehlt mir noch was.

Und dann die Sachen, wo ich schlicht keine Ahnung habe. Wie verändert sich das alles, wenn die Modelle in sechs Monaten besser sind? Was passiert, wenn Kollegen denselben Workflow nutzen — skaliert das? Welche Art von Artikel funktioniert so definitiv nicht? Schauen wir mal.

Das nächste Problem

Der Schreibprozess produziert Artikel. Er produziert aber auch Recherche-Ergebnisse, Briefings, Quellensammlungen, Muster. Und die liegen jetzt in Git-Repos und lokalen Dateien und in meinem Kopf.

Bisher: Confluence-Seite schreiben. Link rein, Architekturbeispiel rein, Erkenntnis rein. Fertig. Veraltet in dem Moment, wo man speichert. Und nach drei Monaten findet sie keiner mehr. Nicht weil die Seite schlecht wäre — sondern weil die Suche nicht mitspielt und die Struktur nicht skaliert. Das kennt jeder, der mal in einem Wiki gearbeitet hat.

Also stellt sich eine neue Frage: Wie baut man eine Wissensbasis, die mit der Geschwindigkeit mithalten kann, in der wir jetzt recherchieren?

Ich sehe da eine Architektur entstehen. Noch nicht fertig, sage ich mal. Aber die Bausteine werden sichtbar.

Taxonomie. Nicht die Art, die jemand in einem Workshop an ein Whiteboard malt und die dann niemand benutzt. Etwas Lebendiges. Ich baue gerade eine kleine Anwendung, die meinen LinkedIn-Feed auswertet — Scoring, eine erste simple Taxonomie, um Trends, Tools und Ideen zu clustern. Hemdsärmelig. Aber es zeigt schon, was Noise ist und was Signal.

Vector Databases und RAG. Die ganze Toolchain, damit eine Wissensbasis nicht nur durchsuchbar ist, sondern Zusammenhänge findet. Spannend, was Redis da gerade im AI-Bereich macht — ich hatte einen Call mit einem Redis Solution Architect über ihren Vector-DB-Pfad. Oder RuVector und was Leute dort an Retrieval-Patterns bauen. Obsidian mit Taxonomien als persönliches Knowledge Management, das sich in einen Team-Workflow einbetten lässt. Alles Ansätze, die ich evaluiere.

Bot-Integration. Das Wissen muss dahin, wo die Leute arbeiten. Slack. Teams. Nicht "geh ins Wiki und such."

Und dann die zwei Fragen, die bei Kunden immer zuerst kommen.

Local AI versus Frontier Models. Kundenrecherche, interne Strategie, vertrauliche Architektur-Patterns — das kann nicht zu OpenAI. Für allgemeine Recherche und Synthese brauche ich aber die Frontier-Modelle. Die Grenze ist nicht technisch. Sie ist organisatorisch und regulatorisch. Und für jeden Kunden anders.

Kosten. Vector-DB-Hosting, API-Calls, Embedding-Modelle, Bot-Infrastruktur. Für meinen eigenen Workflow überschaubar. Aber wie skaliert das in einem Kundenprojekt mit 20 Leuten? Keine Ahnung. Muss ich noch durchrechnen.

Das ist alles Work in Progress. Aber die Richtung wird klarer: Wissen, das bei der Recherche entsteht, muss in eine Struktur fliessen, die es wiederverwendbar macht. Nicht als Confluence-Seite, die nach drei Monaten stirbt.

Warum öffentlich

Ab August 2026 verlangt der EU AI Act eine Kennzeichnung für AI-generierte Inhalte. Ich warte nicht darauf.

Im DACH-Raum gibt es keinen etablierten Ansatz. Die meisten schweigen über ihren AI-Einsatz. Andere kleben einen Disclaimer drunter. Ich versuche was Drittes: den Prozess beschreiben. Einschliesslich der Stellen, die noch nicht laufen.

Wo das hinführt

Der Blog ist mein Testfeld. Aber die eigentliche Anwendung liegt woanders.

Wer Team Topologies kennt, kennt das Enabling Team: Ein Team, das temporär Capability Gaps in anderen Teams schliesst — und dann weiterzieht. Training, Coaching, Pair Programming. Wissen transferieren, bis das andere Team selbständig ist. Genau das machen wir bei Infralovers. Wir sind ein Enablement Team to Hire.

Der Kern dieses Modells sind Menschen. Curriculum Design, Coaching, den Raum lesen, verstehen wo ein Team wirklich steht und was es als nächstes braucht. Kein AI-System ersetzt das. Aber das Modell hat ein strukturelles Problem: Wenn das Enabling Team geht, geht ein grosser Teil des Kontextwissens mit. Die Trainingsunterlagen bleiben. Die Confluence-Seiten bleiben. Aber die Fähigkeit, im richtigen Moment die richtige Information zu finden — die war an Personen gebunden.

Und genau da wird es spannend.

Was, wenn die Recherche-Ergebnisse, die Architektur-Patterns, die Entscheidungsgrundlagen aus einem Enablement-Engagement nicht in einem Wiki verschwinden, sondern in eine Wissensbasis fliessen, die kontextuell abrufbar ist? Nicht "such im Wiki." Sondern: Du arbeitest an einem Terraform-Modul, und das System weiss, welche Patterns in deiner Organisation gelten, welche Entscheidungen das Enabling Team mit deinem Lead besprochen hat, welche Fehler andere Teams schon gemacht haben.

RAG über die interne Wissensbasis. Adaptive Learning Paths, die tracken was ein Team schon kann und was noch fehlt. Bot-Integration in Slack oder Teams, die Antworten gibt, wenn der Coach nicht mehr da ist. Das sind die Bausteine, die ich im vorherigen Abschnitt beschrieben habe — Vector Databases, Taxonomien, Retrieval-Patterns. Nur eben nicht für meinen Blog-Workflow, sondern für den Wissenstransfer in Organisationen.

Die Idee ist nicht, den menschlichen Teil zu ersetzen. Die Idee ist, die Halbwertszeit eines Enablement-Engagements zu verlängern. Das Coaching endet. Die Wissensbasis bleibt. Und sie antwortet.

Ob das funktioniert? Keine Ahnung. Ich baue gerade die Stücke zusammen. Erst für meinen eigenen Workflow, dann für unser Team, dann schauen wir, wo es bei Kunden trägt. Aber die Richtung ist klar: AI-gestütztes Information Retrieval wird verändern, wie Enabling Teams arbeiten. Nicht das Ob, sondern das Wie und das Wie-lange-wirkt-es.