Kategorie: Einblicke

Das Problem: Der traditionelle BI-Stack als Flaschenhals

Eine einfache Frage zu den Umsatzzahlen beantwortet die Datenabteilung erst nach drei Tagen. LangChain stand vor genau diesem Problem. Ihr Data Stack: ein klassisches BI-Tool, gut für vordefinierte Reports, unflexibel für spontane Fragen. Jede Anfrage landete bei der Datenabteilung, damals eine Person. Sie entschlüsselte die Frage, suchte das Modell, schrieb SQL, validierte das Ergebnis und antwortete. Das bremste viele Anfragen aus.

Die Entwickler erkannten, dass der Workflow nicht skalierte. Sie wollten einen Stack für mehrere Benutzertypen gleichzeitig: Dashboards für Eilige, Notebooks für Techniker, direkte Fragen für Geschäftsanwender – und optimiert für einen KI-Agenten, der die Datenabteilung entlastet. Das war der Ausgangspunkt.

Die Lösung: Ein zentraler Arbeitsplatz für Menschen und Agenten

Das Team ersetzte den alten BI-Stack durch Hex. Hex bietet Dashboards, Notebooks, SQL-Workflows und eine konversationelle Schnittstelle – alles in einer Plattform mit eingebauten KI-Funktionen. So entstand ein zentraler Arbeitsplatz für Menschen und Agenten. Der Agent operiert als virtueller Analyst und ist über Hex, Slack, CLI oder MCP zugänglich. Nutzer fragen dort, wo sie arbeiten.

Ein Produktmanager fragt in Hex nach Nutzerverhalten, ein Vertriebler stellt die gleiche Frage über Slack, ein Entwickler nutzt das CLI. Der Agent liefert eine erste Antwort; die Datenabteilung validiert später. Die Migration dauerte sechs Wochen. Danach nutzen 100 Prozent des Unternehmens den neuen Stack. 30 Prozent der Mitarbeiter haben Agentenzugriff, beantragbar über die IT. Der Agent bearbeitet heute die 40‑fache Menge an Anfragen, die das dreiköpfige Daten‑Team zuvor schaffte. In den letzten 30 Tagen gab es rund 2.200 Agentengespräche – durchschnittlich 23 pro aktivem Nutzer.

Die Kontextschichten: Das Rezeptbuch für den Agenten

Die Qualität des Agenten hängt vom Kontext ab. Ein Datenagent ohne Kontext ist wie ein Koch ohne Rezept – er mischt Zutaten, aber das Ergebnis passt selten. LangChain hat vier Schichten aufgebaut, die dem Agenten genau sagen, was die Daten bedeuten und wie sie verwendet werden.

1. Datenmodelle mit klaren Definitionen

Die Grundlage sind Datenmodelle, verwaltet mit dbt. dbt organisiert SQL‑Abfragen und Beschreibungen für Tabellen und Spalten. Jede Spalte bekommt nicht nur einen technischen Namen, sondern eine erklärende Beschreibung. Statt account_status: Der Status des Kontos heißt es nun: account_status: Der aktuelle Lebenszyklusstatus des Kontos in Salesforce. ‚Active‘ bedeutet, der Kunde hat einen aktiven bezahlten Vertrag. ‚Churned‘ bedeutet, der Kunde hatte früher einen bezahlten Vertrag, der beendet wurde. ‚Prospect‘ bedeutet, das Konto ist noch kein Kunde. Für Kundenberichte filtere auf ‚Active‘, es sei denn, die Analyse schließt explizit abgewanderte oder potenzielle Konten ein. Diese Details liefern Geschäftswissen. Auch Tabellen werden beschrieben: Körnung, geeignete Fragen, Vorsichtshinweise. Schwache Definitionen führen zu technisch korrekten, aber fachlich nutzlosen Antworten.

2. Das semantische Modell für konsistente Metriken

Die zweite Schicht: das semantische Modell. Es definiert Begriffe wie ARR, Pipeline oder Nutzung und ihre Berechnung. So muss der Agent nicht raten, welche Tabelle oder Formel gemeint ist. Das semantische Modell baut auf den sauberen Datenmodellen auf – schlechte Fundamente nützen auch der besten Semantik nichts. Klare Modelle, Körnungen und Definitionen steigern die Qualität auf jeder Ebene.

3. Business-Kontext in Workspace Guides

Manche Informationen – wie unternehmensinterne Prozesse, team‑spezifische Workflows oder Reporting‑Konventionen – passen nicht in Tabellen‑ oder Metrikdefinitionen. Dafür verwenden die Entwickler Workspace Guides in Hex: schriftliche Anleitungen für den Agenten. Ein Guide erklärt etwa: Wie definieren wir die Pipeline für das wöchentliche Vertriebs‑Reporting? Welche Dashboards gelten als kanonisch für eine Metrik? Wie interpretieren wir die Produktnutzung bei verschiedenen Bereitstellungsarten? Welche Filter setzen wir bei Kunden‑Gesundheitsanalysen? Wann leiten wir eine Frage zur Validierung an die Datenabteilung? Diese Guides werden in einem GitHub‑Repository versioniert und automatisch mit Hex synchronisiert. Sie sind in natürlicher Sprache und fangen Nuancen ab, die nicht in Code passen.

4. Endorsements: Vertrauenssignale für den Agenten

Die vierte Schicht: Endorsements – Kennzeichnung vertrauenswürdiger Datenquellen. In vielen Unternehmen gibt es mehrere Tabellen oder Dashboards zu ähnlichen Konzepten. Ohne Vertrauenssignal könnte der Agent eine veraltete Quelle wählen. Deshalb markiert nur die Datenabteilung bestimmte Assets als „endorsed“. Ein endorsed Dashboard ist wie ein offizielles Rezept – der Agent vertraut ihm. Nur das Daten‑Team darf Endorsements vergeben, Änderungen an endorsed Dashboards müssen vorab geprüft werden. Sonst verliert das Signal an Wert, wenn alles endorsed ist. Zusätzlich hat der Agent Zugriff auf das dbt‑Repository, um die SQL‑Logik hinter jeder Spalte nachzuvollziehen. Das ist für technische Nutzer wichtig.

Der Feedback-Loop: Aus Fehlern lernen

Kontext allein reicht nicht. Das Team hat eine Feedback‑Infrastruktur aufgebaut. Sie nutzen das Context Studio von Hex (oder LangSmith). Damit analysieren sie Gesprächsthemen, Warnungen und Fehlschläge des Agenten. Häufige gleiche Fragen deuten auf ein fehlendes Dashboard hin. Bei wiederholten Fehlern zu einer Metrik verbessern sie die Definition im semantischen Modell. Erfordern Fragen internes Prozesswissen, erstellen sie einen neuen Workspace Guide. Greift der Agent auf die falsche Quelle zu, passen sie Endorsements oder die dbt‑Dokumentation an. Dieser Kreislauf aus Beobachten und Verbessern macht den Agenten zuverlässiger.

Fazit: Der Wandel von der Datenabteilung zum Systemkurator

Die Datenabteilung von LangChain wandelte sich vom Dienstleister zum Kurator eines intelligenten Systems. Sie verbringt Zeit mit der Verbesserung von Modellen, dem Schreiben von Guides, der Freigabe von Endorsements und der Analyse von Feedback‑Daten. Einfachere Fragen übernimmt der Agent – mit der 40‑fachen Menge an Anfragen. Jeder mit Agentenzugriff kann jederzeit fragen, ohne auf einen Termin zu warten. Das macht Datenzugang demokratischer, ohne Qualitätsverlust – solange der Kontext stimmt. Für Unternehmen, die KI‑Agenten im Datenbereich einsetzen möchten, ist dieser Ansatz eine Blaupause: Datenfundamente klären, den Agenten mit Kontext versorgen, einen Kreislauf des Lernens etablieren. So wird der Agent mehr als ein SQL‑Generator – er entlastet die Datenabteilung und steigert die Wertschöpfung.

Quelle: langchain.com

Softwareentwicklung mit KI gleicht dem Hausbau mit modernen Werkzeugen. Statt Stein für Stein zu setzen, heben Maschinen die Last. Nur dass die Steine hier Codezeilen sind und das Haus eine Plattform für Millionen Nutzer. Gergely Orosz besuchte Anthropic, um zu sehen, wie Teams dort arbeiten. Dieser Artikel zeigt, was sich verändert hat und was gleich geblieben ist.

Orosz sprach mit Katelyn Lesse, Jarred Sumner, Thariq Shihipar und David Hershey. Ihre Erfahrungen zeigen, wie KI den Alltag von Ingenieuren verändert – und welche Prinzipien bestehen bleiben.

Komplexe Projekte brauchen weiterhin Planung: Claude Managed Agents

Das Projekt Managed Agents dauerte sechs Monate. Die Planungsphase war entscheidend: „Bei manchen Produkten kann man sofort prototypen, bei anderen muss die Architektur stimmen“, sagt Lesse. Das Team griff auf Dokumente zurück, die bis zu zwei Jahre alt waren, und erstellte ein klassisches Product Requirements Document. Der Grund: Bei einem komplexen Vorhaben mit vielen Beteiligten – etwa dem Sandboxing-Team – mussten alle auf denselben Stand gebracht werden. „Das ist nicht verschwunden“, sagt Lesse. „Wir brauchen immer noch PRDs, um große Gruppen zu koordinieren.“

Selbst bei einem KI-affinen Unternehmen wie Anthropic ähnelt das Vorgehen dem aus der Zeit vor KI. Der Unterschied liegt in Geschwindigkeit und Flexibilität. Nach der Planung baute das Team einen „Spike“: Es testete das Backend von Claude Code für das Web. Statt wochenlanger Spezifikationen hackte ein Teammitglied Komponenten zusammen und arbeitete direkt mit dem Claude-Code-Team. „Die Abstimmung mit anderen Teams an Schnittstellen ist einfacher geworden“, erklärt Lesse. „Heute können wir einen Stub-Service aufsetzen und die Schnittstellen während der Entwicklung gemeinsam verfeinern.“

Mitten in der Entwicklung wurde klar, dass die Architektur geändert werden musste. Das Team entkoppelte das „Gehirn“ von Claude (Agent und Harness) von den „Händen“ (Sandboxen und Werkzeugen) und der „Session“ (Ereignisprotokoll). Jeder Teil wurde eigenständig. Zusätzlich entstand eine Abstraktion um Tresore und Anmeldedaten, die Credentials abholt, ohne dass der Agent sie sieht. Trotz KI-Unterstützung dauerte das Projekt sechs Monate. Ohne KI hätte es wohl zwei Jahre gebraucht. Die iterative Verfeinerung geht schneller, aber die Grundstruktur bleibt.

Ein 12-Monats-Projekt in 11 Tagen: Der Bun-Rewrite in Rust

Jarred Sumner, Schöpfer von Bun und heute bei Anthropic, schildert ein zweites Beispiel. Bun ist eine JavaScript-Laufzeitumgebung mit über 22 Millionen monatlichen Downloads und mehr als 500.000 Zeilen Code. Eine Migration von JavaScript/TypeScript nach Rust galt bisher als ein Jahr Arbeit für ein kleines Team. Mit KI-Unterstützung (Tool Fable, Tokens im Wert von rund 165.000 Dollar) gelang die Migration in elf Tagen. Bun nutzt jetzt Rust für Teile der Laufzeitumgebung, was Performancevorteile bringt.

Sumner ließ die KI den Großteil der Code-Konvertierung übernehmen. Er konzentrierte sich auf Validierung und Fehlerbehebung. „Die Verifikation war zeitaufwändiger als die Implementierung“, sagt er. Das passt zu einer Beobachtung im gesamten Artikel: KI schreibt Code, der Mensch prüft und testet mehr. Das Verhältnis von Coding zu Testing verschiebt sich – der Fokus verlagert sich. Code-Reviews werden von KI unterstützt, Tests automatisch generiert. Bei Anthropic durchlaufen KI-Tools wie Claude Code selbstständig Pull Requests, bevor ein Mensch hinschaut.

Veränderte Engineering-Praktiken: Prototyping, Verifikation und Teamstruktur

Was bedeutet das im Alltag? Erstens: Prototyping ist flüssiger. Teams müssen nicht wochenlang spezifizieren, sondern bauen schnell einen Stub, testen und verwerfen. Zweitens: Verifikation nimmt mehr Zeit ein. Schreibt KI 80 Prozent des Codes, müssen die restlichen 20 Prozent menschlicher Arbeit gründlich sein. Drittens: Code-Reviews und Tests werden zunehmend von KI erledigt. Entwickler müssen die Ergebnisse kritisch hinterfragen.

Auf Teamebene zieht sich Design durch das gesamte Projekt. Teams arbeiten an mehr Projekten gleichzeitig, weil KI Routineaufgaben übernimmt. Eine Regel: Maximal zwei Ingenieure pro Projekt. Das hält Kommunikationsaufwand gering. „Zwei-Pizza-Teams“ (maximal acht bis zehn Personen) bestehen weiter. Planung bleibt bei komplexen Vorhaben essenziell – wie bei Managed Agents. Auch die Herausforderung des Kontextwechsels bleibt: Arbeitet ein Engineer an mehreren Projekten, leidet die Tiefe des Verständnisses.

Was gleich geblieben ist – und was sich verändert hat

Viele Prinzipien sind unverändert. „Zwei-Pizza-Teams“, PRDs für komplexe Projekte, Planung und Architektur existieren weiter. Auch die Aufteilung zwischen Codieren und Testen verschiebt sich nicht grundlegend. Was sich ändert, ist das Tempo und die Art der Umsetzung. Ein Projekt, das früher zwei Jahre dauerte, schafft man heute in sechs Monaten. Eine Code-Migration, die ein Jahr benötigte, ist in elf Tagen erledigt. Das klingt nach Beschleunigung, aber es hat einen Haken: Die Abhängigkeit von KI-Tools wächst. Die Fähigkeit, ohne sie zu arbeiten, könnte verkümmern. Die Ingenieure bei Anthropic sind sich dessen bewusst. Sie setzen KI gezielt ein, verlassen sich aber nicht blind darauf.

Der „herausragende Software-Ingenieur“ zeichnet sich heute weniger durch Programmiergeschwindigkeit aus, sondern durch tiefes Verständnis – auch eine Schicht unterhalb dessen, woran man arbeitet – und die Fähigkeit, Arbeit zu koordinieren. Wer komplexe Zusammenhänge einer verteilten Architektur versteht und mit mehreren Teams abstimmen kann, ist wertvoller als jemand, der nur schnell Code produziert. KI kann Code schreiben, aber nicht die organisatorische Intelligenz ersetzen, die nötig ist, um ein Produkt wie Managed Agents zu planen und mit Stakeholdern abzustimmen.

Wird KI die Softwareentwicklung ersetzen?

Werden Ingenieure überflüssig? Diejenigen bei Anthropic, die am intensivsten mit KI arbeiten, teilen diese Sorge am wenigsten. „Je mehr die Softwareentwickler bei Anthropic praktisch mit KI arbeiten, desto weniger fürchten sie, dass ihre Jobs verschwinden.“ Katelyn Lesse bringt es auf den Punkt: „Die KI macht uns produktiver, aber sie ersetzt nicht das Denken. Sie ist wie ein Assistent, der einem die Zutaten reicht – kochen muss man trotzdem selbst.“ Die Rolle des Ingenieurs verschiebt sich vom Handwerker zum Architekten und Koordinator. Das erfordert andere Fähigkeiten, ist aber kein Niedergang, sondern eine Weiterentwicklung.

Der Blick hinter die Kulissen von Anthropic zeigt: KI-gestützte Softwareentwicklung ist Realität. Sie verändert, wie Teams planen, prototypen, testen und ausliefern. Aber fundamentale Prinzipien bleiben intakt: gute Architektur, klare Kommunikation, durchdachte Planung. Der Unterschied liegt im Wie. Das Wie wird schneller, flüssiger und erfordert ein tieferes Verständnis der Systeme. Für Entwickler bedeutet das: Wer bereit ist, sich auf diese neue Art des Arbeitens einzulassen, wird nicht ersetzt, sondern bekommt mächtige Werkzeuge an die Hand.

Quelle: newsletter.pragmaticengineer.com

Stell dir vor, du steckst mitten in einer großen Refactoring-Session. Vier KI-Agenten sind parallel am Werk, die Ergebnisse trudeln in unterschiedlicher Reihenfolge ein, und plötzlich fühlt sich der gesamte Workflow schwerer an als der Code, den du eigentlich ändern wolltest. Das ist einem Entwickler kürzlich bei der Arbeit mit einem Multi-Agent-System passiert. Er stoppte die Arbeit und bat den Orchestrator – die zentrale Instanz, die die Subagenten koordiniert – um eine ehrliche Analyse seiner eigenen Delegationsentscheidung. Die Antwort überraschte ihn. Das größte Problem war nicht die Anzahl der Agenten, sondern etwas, das er vorher nicht auf dem Radar hatte.

Der Entwickler arbeitete an einer .NET-Codebasis mit Claude Code. Vier Subagenten waren gestartet, um verschiedene Teile der Response-Pipeline umzubauen. Drei Agenten hatten klare Laufzeiten: etwa zwölf Minuten, fünfeinhalb Minuten und sieben Minuten. Ein vierter lief noch. Aus Sicht der reinen Parallelität war das ein Gewinn: Statt geschätzt 25 Minuten bei serieller Ausführung waren nur etwa 12 Minuten vergangen. Aber Geschwindigkeit war nicht der interessante Teil. Der Entwickler suchte nach den versteckten Kosten.

Seine erste Vermutung war die übliche: Jeder Subagent muss die gleiche Codebasis neu verstehen, Kontext aufbauen, Dateien lesen – die Duplizierung der Einarbeitung. Doch die größte Überraschung kam woanders. An einem Punkt während der Session schlug der Orchestrator vor, den Status der laufenden Agenten zu prüfen. Der Prompt war harmlos: „check on the agents.“ Der Entwickler folgte ihm. Statt einer kurzen Zusammenfassung zog das verwendete Tool das vollständige Rohprotokoll eines Hintergrundagenten in den Hauptthread – Zehntausende von Tokens voller JSONL, Zwischenschritten und Tool-Output. Und das passierte ein zweites Mal. Er hatte eine Kostenart entdeckt, die er nicht gesucht hatte: das teure Abfragen von Statusinformationen, die weit über das Nötige hinausgingen.

Wichtig ist hier eine Einschränkung: Die Behauptung, dass dieses Polling teurer war als die Duplizierungskosten durch vier Agenten, stammt vom Orchestrator selbst – als Selbsteinschätzung. Der Entwickler hatte keine exakte Token-Abrechnung pro Aufruf. Der verlässliche Teil ist enger: Die Transkript-Dumps waren real, die Zeitmessungen real, und der Pfad der Statusabfrage führte eindeutig zu großen, vermeidbaren Kosten. Ob es der größte Einzelposten war, bleibt eine Hypothese, bis die Tooling das genau messen kann. Wichtiger war, dass er einen Kostentreiber gefunden hatte, den er gar nicht gesucht hatte.

Als der Entwickler die Session nicht mehr als einen undifferenzierten „Subagenten-Kostenblock“ betrachtete, zerfiel das Bild in Teile, die nicht zusammengehörten. Zwei der vier Agenten arbeiteten im selben Bereich der Response-Pipeline. Unterschiedliche Aufgaben, unterschiedliche Dateien – aber beide mussten dieselbe Architektur, dieselben Testkonventionen und weite Teile des umgebenden Codes verstehen, bevor sie beginnen konnten. Jeder zahlte diese Orientierungskosten unabhängig. Das ist kein Argument gegen Delegation, sondern dafür, dass die Arbeit zu fein aufgeteilt wurde. Ein anderer Agent führte git stash und git stash pop aus, während Schwesteragenten im selben Baum schrieben. Nichts brach, aber das Risiko war strukturell, weil repository-weite Operationen in einer Single-Thread-Session völlig in Ordnung sind, aber bei mehreren Schreibern kaum zu rechtfertigen sind.

Der Entwickler stand nun vor einer Liste von Übeltätern: Status-Polling, doppelte Orientierung, unsichere Git-Operationen. Er versuchte, sie nach Kosten zu ordnen. Je länger er das tat, desto weniger überzeugte ihn die Frage, welcher Posten am teuersten war. Das eigentliche Problem lag tiefer.

Das Transkript-Polling beschäftigte ihn aus einem Grund, der nichts mit Token-Kosten zu tun hatte. Eine Token-Rechnung ist einmalig – bezahlt und erledigt. Was hier passierte, war anders. Das rohe Transkript blieb nach dem Tool-Aufruf im Kontext des Orchestrators und wurde bei jeder weiteren Runde mitgeschleppt, unabhängig davon, ob es noch nützlich war. In diesem Moment wurde ihm klar, dass er zwei sehr unterschiedliche Kostenarten gleich behandelt hatte. Tokens werden einmal ausgegeben. Kontext hingegen formt jede folgende Entscheidung. Es ging nicht mehr nur um Token-Verbrauch, sondern um die Qualität des Arbeitsgedächtnisses des Orchestrators.

Diese Erkenntnis trug zwei separate Ideen in sich, die es wert sind, auseinandergehalten zu werden. Die erste ist die gerade beschriebene: Verschmutzung im Kontext belastet jede spätere Runde. Die zweite handelt nicht von Platzmangel. Je mehr im Kontext liegt und um Aufmerksamkeit konkurriert, desto schwerer fällt es einem Modell, das Wesentliche herauszufiltern – selbst wenn noch viel Platz frei ist. Ein größeres Kontextfenster behebt das nicht. Es gibt dem Rauschen nur mehr Raum, sich anzuhäufen, bevor es auffällt. Kontextfenster werden nur noch größer werden. Was zählt, ist nicht, wie viel Platz vorhanden ist, sondern wie viel von dem, was dort liegt, die Aufmerksamkeit des Modells verdient. Das ist das eigentliche Problem, das Subagenten lösen müssen – wenn sie richtig eingesetzt werden.

Aus dieser Perspektive ist der Orchestrator der einzige Teil des Systems, der über eine lange Session hinweg Verständnis aufbaut. Er erinnert sich, warum eine Designentscheidung getroffen wurde, trägt architektonische Randbedingungen mit sich und weiß, welche Trade-offs bereits diskutiert wurden. Die Subagenten tun das nicht – und das ist Absicht. Sie sollen wegwerfbar sein. Erkundung, wiederholtes Dateilesen, gescheiterte Ansätze und lautes Zwischenreasoning sollen in den Worker-Kontexten bleiben und niemals den Weg zurück in den Hauptthread finden.

Diese Erkenntnis verändert, wofür Parallelität eigentlich gut ist. Das Problem der doppelten Orientierung war nicht wirklich, dass zwei Agenten dieselben Dateien lasen. Es war, dass zwei Agenten unabhängig voneinander dasselbe mentale Modell der Codebasis rekonstruierten, weil die Arbeit nach Aufgaben aufgeteilt war und nicht nach dem Wissen, das jede Aufgabe benötigte. Der Entwickler nennt diese Unterscheidung kognitive Lokalität: Aufgaben, die dasselbe mentale Modell benötigen, sollten normalerweise zusammenbleiben. Sie aufzuteilen zwingt mehrere Agenten, dasselbe Verständnis von Grund auf neu aufzubauen. Parallelität ist weiterhin nützlich, aber nicht der Hauptpunkt. Vier Agenten gleichzeitig laufen zu lassen ist gewöhnlich. Der wahre Vorteil ist, dass sie lautes Zwischenreasoning aus dem Hauptthread fernhalten und nur das zurückgeben, was er noch braucht. Das ist die Isolation, die Subagenten bieten sollen – und sie gilt nur, wenn der Hauptthread sie respektiert.

Der Entwickler ist heute überzeugt: Das ist die eigentliche Aufgabe von Subagenten. Nicht Zeit zu sparen, sondern Reasoning auszulagern, das der Orchestrator nicht behalten muss. So trägt er weniger und hat weniger Konkurrenz um seine Aufmerksamkeit. Wenn die Isolation stimmt und die Aufgaben nach kognitiver Lokalität gruppiert sind, werden Subagenten zum Werkzeug, das das Arbeitsgedächtnis des Orchestrators schützt – nicht nur ein Kostenfaktor, den man für Parallelität in Kauf nimmt. Das ist eine Überzeugung, keine Messung. Was er tatsächlich gemessen hat, ist die andere Seite: die Kosten, wenn die Isolation falsch läuft.

Sein nächster Schritt war naheliegend: Die Lektion in CLAUDE.md codieren, der festen Anweisungsdatei, die jede Session lädt. Es wäre einfach gewesen, eine große Korrekturpolitik zu schreiben, aber jede zusätzliche Zeile in einer solchen Datei ist ein Kostenfaktor, der bei jeder zukünftigen Session erneut anfällt. Also komprimierte er die Lösung auf den kleinsten Satz von Regeln, die die beobachteten Fehler adressierten. Jede Regel beantwortet dieselbe Frage: Verdient diese Information oder diese Art der Aufgabenaufteilung einen Platz im Kontext des Orchestrators?

1. Bevorzuge zwei bis vier Agenten in einer Welle. Wenn der Orchestrator fünf oder mehr möchte, soll er zuerst fragen, ob Aufgaben, die Dateien oder Konventionen teilen, zusammengelegt werden können.
2. Poll nicht den Status von Hintergrundagenten, wenn die Antwort bereits aus dem Bekannten gegeben werden kann. Hole kein vollständiges Transkript für eine leichte Frage.
3. Erlaube keine repository-weiten Git-Operationen innerhalb gleichzeitiger Agenten-Prompts.
4. Behandle überlappende Dateibesitzer als Konsolidierungssignal, nicht als Aufforderung, mehr Agenten zu spawnen.

Keiner dieser Punkte sagt dem Orchestrator genau, was er in jedem Fall tun soll. Jeder gibt ihm etwas zum Prüfen oder zum Selbstbefragen, kein Skript. Keiner ist für sich genommen tief. Ihr einziger Wert ist, dass sie alle auf dasselbe Ziel ausgerichtet sind: wegwerfbares Reasoning wegwerfbar zu halten und Platz im Kontext des Orchestrators für das zu bewahren, was später in der Session noch gebraucht wird.

Eine spätere Session förderte eine andere Lücke zutage. Der Entwickler hatte den Orchestrator mit expliziten Skills für die gewünschte Arbeit gestartet – Codierungsanleitung in einem Fall, Designanleitung in einem anderen. Er nahm an, dass einmal im Hauptthread aktive Skills automatisch von gespawneten Subagenten übernommen würden. Tun sie nicht. Ein Subagent erbt keine Skills aus der Eltern-Session, es sei denn, der Orchestrator übergibt sie explizit. Sein erster Impuls war, ein Bestätigungs-Gate vor dem Spawnen einzubauen. Der Orchestrator sollte anhalten, auflisten, welche Agenten er starten will und welche Skills jeder laden soll, und auf Zustimmung warten. Er ist froh, diese Version nicht behalten zu haben. Sie löste das falsche Problem. Es gab keine Hinweise, dass schlechte Spawn-Pläne aus Mangel an Bestätigung durchrutschten. Er hatte eine fehlende Tatsache über Skill-Weitergabe entdeckt – eine andere Art von Lücke. Ein universelles Bestätigungs-Gate hätte jeder ähnlichen Session eine Runde hinzugefügt, und bald hätte er diese Prompts wahrscheinlich nur noch auf Autopilot bestätigt. An dem Punkt erkannte er, dass er nicht wirklich die Governance verbesserte – er fügte nur ein Ritual hinzu. Und es hätte das eigentliche Problem von vorher nicht abgefangen: der Orchestrator, der seinen eigenen Kontext verschmutzt.

Die schmalere Lösung hielt besser. Vor dem Spawnen legt der Orchestrator dar, welche aktiven Skills für die Aufgabe jedes Agenten relevant sind, und verweist den Subagenten auf die Skill-Datei, statt den gesamten Skill inline zu kopieren. Bestätigung ist nur oberhalb der Batch-Größenschwelle erforderlich, die bereits existiert, oder wenn Dateibesitzer unklar sind. Daraus ergab sich eine Heuristik, die der Entwickler heute öfter verwendet als die Regel selbst: Bevor du eine Zeile zu einer festen Anweisungsdatei hinzufügst, frage dich, ob ein vernünftig kompetenter Orchestrator die richtige Entscheidung treffen würde, sobald er die eine fehlende Tatsache kennt. Wenn ja, sollte die Regel nur die Tatsache nennen. Wenn die Lösung beginnt, einen Entscheidungsprozess zu spezifizieren – Genehmigungen, Checkpoints, Pflichtschritte – ist das meist ein Zeichen, dass man Prozess codiert, wo eine kleine Klarstellung gereicht hätte. Ob diese Heuristik härteren Fällen standhält, weiß er noch nicht. Aber sie hindert ihn bisher daran, jeden interessanten Vorfall in eine Miniatur-Bürokratie zu verwandeln.

Am Ende dieser Analyse hat der Entwickler keine endgültige Antwort darauf, wie viel Governance genug ist. Stattdessen hat er ein kleines Schwungrad, mit einem Menschen noch fest in der Mitte. Eine Session legt eine Lücke offen. Jemand muss sie bemerken. Dann kommt die Entscheidung: Lässt sich die Lücke durch eine kleine Tatsache schließen, oder verlangt sie nach einem umfassenderen Prozess? Das ist die Steuer des Orchestrators – kein festes Gesetz, sondern ein ständiges Abwägen zwischen klarem Denken und bürokratischer Last. Und genau diese Abwägung macht den Unterschied zwischen einem System, das dich unterstützt, und einem, das dich ausbremst.

Quelle: martinfowler.com

Du sitzt am Computer und willst eine vertrauliche Nachricht verschicken. Ein Klick, die Verschlüsselung erledigt den Rest. Heute Alltag. Vor achtzig Jahren anders. Die Alliierten kämpften im Zweiten Weltkrieg gegen ein deutsches Verschlüsselungssystem. Es war so komplex, dass ein neuer Maschinentyp nötig wurde: der erste programmierbare elektronische Digitalcomputer. Der Historiker B. Jack Copeland beschreibt im IEEE Spectrum die Geschichte dieser Maschine – Colossus – und wie sie half, den Krieg zu entscheiden. Die Geschichte zeigt, wie aus einer militärischen Notwendigkeit eine Technologie entstand, die bis heute wirkt.

Im Sommer 1941 hörte eine britische Funkerin etwas Ungewöhnliches. Kein vertrautes Morsezeichen, sondern ein rhythmisches Wabern. Ein Bericht nannte es „seltsame neue Musik“. Es war der binäre Telex-Code einer neuartigen deutschen Verschlüsselungsmaschine, fortschrittlicher als die Enigma. Die Briten nannten sie „Tunny“ – Thunfisch. Ein Codename, der an die Tradition erinnerte, Verschlüsselungen nach Fischen zu benennen. Die Maschine stammte von der Firma C. Lorenz in Berlin. Das wussten die Codeknacker nicht. Sie standen vor einem Rätsel.

Der entscheidende Hinweis kam von einer Eigenart der abgefangenen Nachrichten: Jede begann mit einer unverschlüsselten Liste von zwölf deutschen Namen – Anton, Bertha, Dora. Die Briten vermuteten zwölf Räder in der Maschine. Die Namen gaben wohl die Einstellungen vor. Ein glücklicher Zufall half: Der Codeknacker John Tiltman fing zwei Nachrichten ab, die mit derselben Namensliste begannen. Die zweite war eine Wiederholung der ersten mit kleinen Unterschieden. Tiltman entschlüsselte beide Texte. Dem jungen Mathematiker Bill Tutte lieferte das genug Material, um die Funktionsweise der Lorenz-Maschine vollständig zu rekonstruieren. Seine Beschreibung war präzise.

Aber die Verschlüsselung zu verstehen reichte nicht. Man musste auch die Radstellungen im Einzelfall kennen. Alan Turing, der bereits die Enigma geknackt hatte, erfand eine Methode namens „Turingery“. Sie beruhte auf einem Trick, dem Delta-Verfahren: Buchstaben auf Bitebene addieren, quer, ergibt Informationen über die Radstellungen. Ein Jahr lang war Turingery die einzige Waffe gegen Tunny. Die Alliierten entzifferten 1,5 Millionen Buchstaben deutscher Geheimtexte – darunter oft Befehle, die Hitler selbst unterzeichnet hatte. Das brachte wichtige Informationen.

Dann verschwanden die Namenslisten am Anfang der Nachrichten. Die deutschen Bediener wurden vorsichtiger. Turingery verlor an Wirkung, weil es auf Fehlern der Gegenseite beruhte. Tutte entwickelte eine neue statistische Methode, die ohne diese Fehler auskam. Sie nutzte die mathematischen Eigenschaften der Maschine. Allerdings erforderte sie enorme binäre Berechnungen. Von Hand hätte eine einzige Nachricht Monate gedauert. Man brauchte eine Maschine, die diese Arbeit automatisierte.

Hier kam Tommy Flowers ins Spiel. Flowers war Ingenieur bei der britischen Post und hatte Erfahrung mit tausenden Elektronenröhren. Damals galten Röhren als unzuverlässig, weil die heißen Glühfäden schnell durchbrannten. Flowers hatte entdeckt, dass sie stabiler waren, wenn man sie dauerhaft eingeschaltet ließ. Er schlug vor, einen vollständig elektronischen Rechner zu bauen – ohne langsame Relais. Das war neu. Niemand hatte zuvor einen Computer mit so vielen Röhren gebaut. Flowers setzte sich durch und entwickelte Colossus, den ersten großen programmierbaren elektronischen Digitalcomputer. Die Maschine wog etwa eine Tonne und füllte einen ganzen Raum.

Colossus wurde in Bletchley Park aufgestellt. Er arbeitete schnell – erledigte die statistischen Berechnungen in Stunden statt Monaten. Bedient wurde er von jungen Frauen wie Dorothy Du Boisson und Elsie Booker. Sie sitzen auf historischen Fotos konzentriert vor den Schalttafeln. Die Maschine las Lochstreifen mit den abgefangenen Signalen und zählte, wie oft bestimmte Bit-Muster vorkamen. Aus diesen Zahlen leiteten die Mathematiker die Radstellungen ab. Colossus war kein Universalcomputer, aber programmierbar – die Verkabelung ließ sich ändern, um verschiedene Algorithmen auszuführen.

Colossus lieferte Ergebnisse. Die Alliierten belauschten die Kommunikation zwischen dem deutschen Oberkommando und den Frontgenerälen. Sie erfuhren von Truppenbewegungen, Nachschubplänen und strategischen Entscheidungen, bevor diese ausgeführt wurden. Manche Historiker glauben, dass Colossus den Krieg um mehrere Monate verkürzt hat. Nach Kriegsende wurde die Maschine auf Befehl Churchills geheim gehalten und zerstört. Erst in den 1970er Jahren durften die Beteiligten darüber sprechen. Heute steht eine originalgetreue Rekonstruktion in Bletchley Park. 2026 wurde Colossus als IEEE-Meilenstein der Technikgeschichte geehrt.

Was hat das mit KI zu tun? Auf den ersten Blick wenig. Colossus war ein Spezialrechner, kein lernendes System. Aber seine Technik – schnelle, automatische Berechnungen – ist die Basis moderner Computer. Heutige KI-Systeme nutzen ähnliche statistische Methoden, wie Tutte sie entwickelte. Ohne die Vorarbeit von Flowers und Turing gäbe es keine Sprachmodelle, keine Bilderkennung, keine automatische Übersetzung. Colossus war ein früher Schritt hin zu den Computern, die heute Alltag sind.

KI bedeutet im Kern: Eine Maschine lernt aus Daten und trifft Entscheidungen. Colossus hat nicht gelernt, aber er verarbeitete Daten – mit einer Geschwindigkeit, die für Menschen undenkbar war. Die Prinzipien ähneln sich: Daten aufnehmen, Muster erkennen, Ergebnisse liefern. Damals halfen Binärzahlen, den Krieg zu verkürzen. Heute sind es Milliarden von Text- und Bilddaten, die unser Alltag nutzt.

Colossus zeigt: Große Durchbrüche entstehen oft aus konkreter Notwendigkeit. Die Ingenieure und Mathematiker analysierten, tüftelten, bauten. Keine Angst vor komplexen Problemen. Das ist auch heute hilfreich, wenn wir über KI-Anwendungen nachdenken. Kein Hype, sondern systematisches Verständnis. Colossus war ein Werkzeug – mächtig. KI von heute ist auch nur ein Werkzeug. Was wir daraus machen, liegt an uns.

Quelle: spectrum.ieee.org

Du sitzt als Designer vor einem fertigen Mockup. Ein Padding-Wert ist falsch – drei Pixel zu viel. Früher hättest du ein Ticket aufgemacht oder einen Engineer angeschrieben. Oder es ignoriert. Vielleicht wäre der Fehler erst in der nächsten Sprint-Planung aufgefallen. Heute öffnest du einen Code-Editor, kopierst den Prompt, fragst die KI, und zwei Minuten später ist der Fix live. Keine Abhängigkeit, keine Wartezeit. Dein Produkt sieht aus, wie du es haben willst – ohne Umwege.

Ein aktueller Artikel beschreibt diesen Alltagswandel. Der Autor befragte neun Designer aus Unternehmen wie Shopify, Meta und kleinen Startups zu ihren Erfahrungen mit KI-unterstütztem Coden. Er erwartete ein Gespräch über Tools und Workflows. Stattdessen fand er eine grundlegendere Debatte: Was ist der Kern des Design-Jobs? Was macht KI mit der Identität der Designer? Wie verändert sich das Verhältnis zu den Engineers, die plötzlich mit denselben KI-Werkzeugen arbeiten?

Die Rückkehr zur Freude am Machen

Vier der neun Designer sagten, das Bauen funktionierender Produkte – nicht nur Mockups – bringe sie zurück zu dem, was sie ursprünglich zum Design gebracht hat. Roland Tiango, der bei Headway, Faire und Shopify gearbeitet hat, sagte: „Ich liebe es, dass das Pushen von Code Designern erlaubt, wieder die Begeisterung und das Versprechen des einfachen ‚Dinge-Machens‘ zu erfahren. Es ist der Teil des Jobs, in den wir uns zuerst verliebt haben – aber auch der Teil, der aus vielen guten Gründen oft eingeschränkt war. Der gesamte Produktentwicklungsprozess wird kürzer. Das erlaubt Designern hoffentlich, in ihre Stärken zu gehen.“ Der Autor teilt diese Begeisterung. Designer steckten zu lange in der Vorschlagsrolle fest, abhängig von anderen, um ihre Ideen außerhalb von Canvas-Tools zu testen. Viele sind erleichtert, dass die Ketten endlich abfallen. Jeffrey Kalmikoff von Motive, Meta und Uber ergänzt: „PRs als normaler Bestandteil der Designarbeit erlauben Designern, sich durchs Machen zu beschweren. Je weiter die Arbeit vom Hypothetischen entfernt ist, desto besser. Designer übernehmen mehr Verantwortung dafür, die Arbeit zu finden, statt gesagt zu bekommen, was sie tun sollen. Zugang zu Daten-Tools erlaubt jedem, Ideen zu validieren. Zugang zu Code erlaubt jedem, echte Dinge zu bauen. Design-Tools sind jetzt eine weitere Art, eine Idee auszudrücken, nicht die einzige.“

Nicht neu – aber jetzt zugänglicher

Designer, die programmieren, gibt es nicht erst seit der KI-Ära. Der Autor selbst lernte sechs Programmiersprachen und baute in seiner frühen Karriere Design und Bau selbst. Programmieren war bei vielen frühen Tech-Jobs Pflicht. Jessica Harllee, die bei Shopify, Faire und Etsy gearbeitet hat, programmiert seit 15 Jahren als Product Designer. Der Unterschied heute: „KI senkt die Einstiegshürde. Der Zugang zu Entwicklertools verkürzt den Kreislauf zwischen dem Erkennen eines Problems und der tatsächlichen Behebung.“ Sie scannt ständig die Teile von Shopify, die sie verantwortet, und repariert kleine Details, die sonst im Backlog gelandet wären. Auch Michael Hintze (Google, Meta, Apple) sieht Vorteile bei kleinen Änderungen: „Kleine Optimierungen wie Farbaktualisierung, Padding-Korrektur, Schriftwechsel können Kommunikationskosten eliminieren und Probleme schneller beheben, wenn das Team es zulässt, ohne zusätzliche Reviews.“

Die Schattenseite: Auflösung der Rollen

Doch es gibt eine Kehrseite. Der Autor beschreibt ein zweites Phänomen: Die Jobbeschreibung löst sich auf. Für manche ein Silberstreif, für andere eine Quelle der Angst. Kim Lenox (Adobe, Zendesk, LinkedIn) sagt: „Die letzten 15 Jahre hatten klar definierte, skill-spezifische Rollen. Man wusste, in welcher Spur man schwimmt, wie man zusammenarbeitet und wie man befördert wird. Das hat sich geändert. Wir sind zurück in der Dotcom-Ära: keine Jobbeschreibungen, keine Rollendefinition. Es geht um Experimentierfreude und Komfort mit Ambiguität. Was zählt, sind Design-Grundlagen, Neugier, Systemdenken, eine unterscheidbare Perspektive und die Kreativität, sich auszudenken, was es noch nicht gibt.“ Für eine andere Gruppe ist Code der am stärksten standardisierte Schritt im Workflow – kein Kernteil der Identität, sondern Mittel zum Zweck. Andrew Milmoe (Blue Origin, GE) sagt: „Code sind die letzten fünf Prozent meines Jobs. Mich interessiert viel mehr, KI zu nutzen, um den Problemraum zu verstehen, Seite an Seite mit Nutzern zu sein und sicherzustellen, dass das System Reibung reduziert und Produkte priorisiert werden, die Kunden und Business Wert bringen. Viel zu viele Leute assoziieren UX-Design mit dem Pushen von Code in Produktion. Das ist der einfachste Teil des Workflows.“

Die Angst vor der falschen Priorität

Die Angst ist nicht, dass Designer nicht coden können. Sondern dass sie Ausführung mit dem Job verwechseln und ihre Zeit in Velocity stecken, statt das Richtige zu bauen. Michael Hintze, der selbst einen CS- und Mathe-Hintergrund hat, bevor er zum Design wechselte, sagt: „Wenn ich Engineer hätte werden wollen, wäre ich es geworden. Ich entscheide mich bewusst dafür, meine Zeit auf die weniger ausführenden Aspekte zu konzentrieren. Welches Problem sollten wir lösen? Warum ist es am wichtigsten? Haben wir eine neuartige Lösung? Passt sie in alles andere rein? Engineers brauchen keine Hilfe beim Pushen von mehr Code. Sie brauchen Hilfe bei der Entscheidung, was gebaut werden soll, warum, und Unterstützung von der Organisation, um gute Ideen nicht sterben zu lassen.“

Nicht jeder Designer ist gleich

Kim Lenox, die Teams durch diese Transformation führt, sagt ehrlich: Nicht jeder Designer ist gleich. „Manche fühlen sich wohl damit, im Abstrakten zu arbeiten, Code zu schreiben, Ergebnisse zu sehen und zu wissen, wo sie justieren müssen. Andere haben nicht die Fähigkeiten oder die Geduld. Manche erleben Frustration und verlieren Zeit damit, Code zu bändigen. Andere fühlen sich ermächtigt, aber auch unter Druck, Energie in Dinge zu stecken, die sie nicht gern tun. Visuelle Menschen arbeiten lieber mit UX-Elementen.“ Und dann gibt es den Teil, den man nur durchs Tun versteht: Echte Software mit einem LLM zu bauen bedeutet viel Hin und Her, Warten, Kompilieren und Verhandeln mit einem manchmal inkompetenten Agenten. Der Output ist oft mangelhaft. Ein anonymer Designer: „Shipping ist 100 % schneller, aber die Qualität ist beim ersten Release niedriger.“ Ein anderer: „Die Ausfallzeiten sind real. Ich bin es gewohnt, stundenlang in Figma Deep Work zu machen. Jetzt muss ich durch das Hin und Her mit LLMs multitasken, um Leerlaufzeiten zu nutzen.“ Jeffrey Kalmikoff sieht darin eine neue Kernfähigkeit: „Rationales Multitasking – mehrere Projekte gleichzeitig verfolgen, ohne auszubrennen.“

Die Ingenieurs-Perspektive

Die Designer sprachen offen darüber, wie ihre Engineering-Kollegen die Entwicklung sehen. Der gemeinsame Nenner: Wer seine Grenzen kennt und die richtige Problemgröße wählt, entscheidet, ob ein Pull-Request eines Designers Geschenk oder Kopfschmerz ist. Oscar von Hauske Valtierra (Meta, Google) sagt: „Ingenieure wissen am besten, wie Systeme funktionieren und wo Dinge brechen. Es hängt vom Maßstab ab. UI in einem Startup auszuliefern ist nicht dasselbe wie in einem globalen Megakonzern.“ Michael Hintze warnt: „Alles, was komplexer ist als einfache Änderungen, ist oft Zeitverschwendung für einen Designer, weil ein Engineer die Aufgabe 100-mal effizienter erledigt. Vibe-Coding ist nicht dasselbe wie Produktionscode und kann Unmengen an Problemen schaffen.“ Pointiert formuliert es Hang Xu, ein ehemaliger Designer und Recruiter: „Ich habe mit mehreren Engineers bei KI-fokussierten Unternehmen gesprochen. Ihr privates Feedback war frustrierend. Während es sich für Designer ermächtigend anfühlt, erzeugt es für die Entwickler, die diese Initiativen unterstützen, jede Menge zusätzliche Arbeit. KI-Mandate führen dazu, dass viele von uns schlechte Kollegen werden, im Bestreben, KI-native zu wirken.“ Das verlagert die Frage vom „Ist das gut für mich?“ zum „Ist das gut für das Team?“ Designer beschweren sich oft über andere Funktionen, die halbgares Zeug abliefern. Hier besteht die Gefahr, genau diese Funktion zu werden.

Wer wacht über die Qualität?

Kim Lenox sagt: „Manche Menschen sind einfach besser in Ästhetik als andere, auch wenn sie keine Designer sind. Unmengen von Fehlern gehen live und müssen entdeckt und analysiert werden. Der kulturelle Drang nach Geschwindigkeit auf Kosten der Qualität ist der Übeltäter, nicht die Menschen hinter dem Code.“ Jeffrey Kalmikoff betont: „Es ist weiterhin wichtig, dass jede Funktion einen verantwortlichen Ansprechpartner für Qualität hat, unabhängig davon, wer die Arbeit ausführt.“ Jessica Harllee mit tiefem technischen Hintergrund lebt den Owners-Mindset: Sie jagt „broken windows“ in der User Experience und genießt die Reparatur ohne Bürokratie. Aber selbst sie macht nur, was sinnvoll ist. Der Mittelweg: kleine Fixes sofort, große Entscheidungen – wann, warum, was gebaut wird – bleiben in den Händen derer, die das Gesamtsystem verstehen.

KI-unterstützte Code-Erstellung ist weder Allheilmittel noch Bedrohung. Sie verschiebt die Spielregeln für Designer grundlegend. Wer seine Stärken kennt – ob im Systemdenken, in der Nutzerforschung oder der Ästhetik – kann KI nutzen, um schneller zu liefern und mehr Verantwortung zu übernehmen. Wer sich im Code verliert, riskiert, seine wertvollsten Fähigkeiten zu untergraben. Für Teams bedeutet das: klare Kommunikation, Respekt vor Stärken, bewusster Umgang mit Qualität. In einer Welt, in der alles zehnmal schneller shipped, ist Qualität das Erste, was ohne echte Sorgfalt und Leitplanken über Bord geht. Die Frage ist nicht, ob Designer coden können oder sollen, sondern ob sie wissen, wann sie es lassen sollten.

Quelle: rongoldin.substack.com