Kategorie: Einblicke

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

Stell dir vor, du stehst am Fuß eines gigantischen Gebirges, dessen Gipfel im Nebel verschwinden. Du weißt, dass dort oben etwas Unvorstellbares wartet – eine neue Welt, die alles verändern wird. Aber der Aufstieg ist gefährlich, und niemand hat eine Karte. Genau das beschreibt Google-CEO Demis Hassabis in seinem Essay „A Framework for Frontier AI and the Dawning of a New Age“. Er spricht von einem Wendepunkt in der Menschheitsgeschichte, von einer Technologie, die so mächtig ist wie die Entdeckung des Feuers. Während er das Potenzial betont, bleiben die Risiken unausgesprochen – das macht viele Beobachter nervös.

Aufsicht nach dem Vorbild der FINRA

Hassabis schlägt ein neues Gremium vor: ein „Frontier AI Standards Body“ innerhalb der US-Regierung, ähnlich der Finanzaufsicht FINRA. Dieses Gremium soll sogenannte Frontier Labs regulieren – Unternehmen, die Modelle an der technologischen Grenze entwickeln. Die Idee klingt vernünftig: Labs müssten ihre Modelle vor der Veröffentlichung von unabhängigen Prüfern testen lassen, Sicherheitslücken schließen und sich regelmäßigen Evaluierungen unterziehen. Im Fall einer Eskalation könnte dieses Gremium sogar eine Verlangsamung der Entwicklung koordinieren. Auf den ersten Blick ist das ein Schritt in die richtige Richtung. Auf den zweiten Blick zeigt sich ein grundlegendes Problem: Der Vorschlag ist vage, lässt viele Fragen offen – und geht nicht auf das größte Risiko ein.

Denn Hassabis spricht von Experten, die sich uneinig sind, aber er vermeidet es, konkret zu werden. Er sagt nicht, worüber genau sie streiten. Dabei ist die Kluft enorm: Einige Experten schätzen die Wahrscheinlichkeit einer totalen Katastrophe durch KI auf fünf Prozent, andere auf neunzig Prozent. Das ist kein kleiner Unterschied – es ist die Frage, ob wir als Zivilisation überleben. Aaron Scher von der Future of Life Institute bringt es auf den Punkt: Wenn Hassabis von „Sicherheit“ spricht, meint er nicht Jobs oder Datenschutz, sondern die Gefahr, dass KI außer Kontrolle gerät und alles vernichtet. Doch in seinem Essay klingt es, als ginge es um ein harmloses Update für dein Smartphone. Diese beschönigende Sprache ist gefährlich, weil sie den Eindruck vermittelt, das Problem sei beherrschbar – dabei ist es das vielleicht nicht.

Hassabis vergleicht KI mit Feuer und Elektrizität. Eine treffende Analogie, aber bedenke: Feuer kann Wärme und Licht bringen, aber auch ganze Städte niederbrennen. Elektrizität hat unser Leben revolutioniert, aber ohne Schutzschalter und Sicherungen wäre sie tödlich. Was Hassabis vorschlägt, ist im Grunde ein Sicherungskasten – aber er sagt nicht, was passiert, wenn die Sicherung durchbrennt. Sein Gremium könnte Modelle prüfen, aber was, wenn ein Modell intern weiterentwickelt wird und nie nach außen dringt? Eli Tyre von der Organisation „The Limits“ weist zu Recht darauf hin, dass der Vorschlag nur öffentliche Veröffentlichungen betrifft. Die größte Gefahr liegt jedoch in den Laboren selbst: Wenn ein System beginnt, sich selbst zu verbessern, ohne dass es jemand bemerkt, gibt es keinen Rettungsring.

Reaktionen und Googles Rolle

Die Reaktionen auf Hassabis‘ Essay sind gemischt. Jack Clark von Anthropic lobt den Vorstoß, weil er zeigt, dass die führenden KI-Unternehmen das Problem ernst nehmen. Samuel Hammond sieht darin ein deutliches Warnsignal: Wenn alle großen Labs gleichzeitig Alarm schlagen, dann ist die Lage ernst. Connor Leahy von Conjecture fordert ein vollständiges Verbot von Superintelligenz, nicht bloß eine freiwillige Selbstregulierung. Denn selbst eine starke Überwachungsbehörde wie die SEC in den USA – die nicht einmal perfekt funktioniert – wäre kein Ersatz für ein internationales Abkommen. Ein Standards Body allein kann den Wettlauf nicht stoppen, er kann ihn höchstens etwas verlangsamen. Und das reicht nicht, wenn die Gefahr so groß ist, wie viele Experten vermuten.

Ein weiterer Punkt: Der Vorschlag von Hassabis kommt von Google. Google hat sich in der Vergangenheit nicht als Vorreiter in Sachen KI-Sicherheit hervorgetan. Ende 2024 unterzeichnete Google einen Vertrag mit dem US-Verteidigungsministerium, der die Nutzung von KI-Modellen für „alle legalen Zwecke“ erlaubt – einschließlich autonomer Waffen. Das ist eine krasse Abkehr von den Prinzipien, die Hassabis einst bei der Gründung von DeepMind propagierte. Ein Forscher namens Alex Turner hat aus diesem Grund gekündigt. Er war Teil eines internen Widerstands, der versuchte, den Deal zu verhindern – vergeblich. In seinem Abschiedsbrief beschreibt Turner, wie Jeff Dean, eine wichtige Person bei Google, zwar mehr Druck gemacht habe als die meisten, aber letztlich nicht genug, um die Führung umzustimmen.

Warum der Vorschlag zahnlos bleibt

Turners Geschichte ist eine Warnung. Sie zeigt, wie Machtverhältnisse und Gewinninteressen Sicherheitsversprechen über den Haufen werfen können. Hassabis‘ Standards Body wäre vielleicht eine gute Idee, wenn er wirklich unabhängig wäre und echte Durchsetzungsbefugnisse hätte. Aber was passiert, wenn die gleichen Unternehmen, die ihn finanzieren, ihn politisch unterwandern? Das wäre wie ein Fuchs, der den Hühnerstall bewacht. Die FINRA ist kein ideales Vorbild, weil sie in der Finanzkrise versagt hat. Ohne eine starke staatliche Aufsicht – ein „SEC für KI“ – bleibt der Vorschlag ein zahnloser Tiger. Und selbst dann: Wie will eine Behörde die Entwicklung einer Superintelligenz kontrollieren, die sich in Millisekunden verbessern kann? Die Zeit drängt, und die Vorschläge sind nicht einmal ansatzweise so dringlich wie die Lage.

Dennoch sollten wir Hassabis nicht völlig unterschlagen. Er hat den Anstoß gegeben, über Regulierung zu reden – das ist mehr, als viele andere tun. Sein Essay ist ein erster Schritt, aber er bleibt stehen, wo die eigentliche Arbeit beginnt. Die Frage ist: Sind wir bereit für die Revolution? Wir sprechen über eine Technologie, die das Potenzial hat, die Menschheit in ein Zeitalter des Überflusses zu führen – aber auch in ein finsteres Zeitalter der Knechtschaft oder gar Auslöschung. Hassabis sagt, KI sei zehnmal so folgenreich wie die Industrielle Revolution, und das in einem Zehntel der Zeit. Stell dir vor, die gesamte Lebensqualität würde sich in zehn Jahren verfünfzigfachen – oder auf null fallen. Keine Übertreibung, das ist das Szenario, vor dem Experten warnen.

Was jetzt nötig wäre

Was bleibt? Zunächst die Erkenntnis, dass wir nicht nur auf die großen Unternehmen angewiesen sind. Jeder kann sich informieren, Druck ausüben, diskutieren. Die Politik muss handeln – aber sie handelt nur, wenn die Öffentlichkeit es einfordert. Der Fall Alex Turner zeigt, dass es in den Laboren Menschen gibt, die das Richtige tun wollen. Doch sie brauchen Unterstützung von außen. Der Vorschlag von Hassabis ist ein Anfang, aber er darf nicht das Ende sein. Wir brauchen ein internationales Moratorium für die Entwicklung von Superintelligenz, vergleichbar mit dem Stopp der Kernwaffentests. Wir brauchen Transparenz und echte demokratische Kontrolle. Und wir brauchen eine Debatte, die nicht von PR-Phrasen überlagert wird. Denn am Ende geht es nicht um Technologie – es geht um unsere Zukunft.

Die nächsten Monate werden zeigen, ob die Branche ihren Worten Taten folgen lässt. Oder ob wir weiterhin Rennen fahren, ohne zu wissen, ob die Strecke ins Nirgendwo führt. Lies die Essays, hör auf die Warnungen – und lass dich nicht von schönen Worten einlullen. Die KI ist da, und sie wartet nicht. Wir müssen uns jetzt entscheiden.

Quelle: thezvi.substack.com