Kategorie: Erklärer

Du stehst an der Gepäckausgabe am Flughafen. Dein Koffer kommt auf dem Band, du greifst zu – aber zwischen deinem Koffer und dem nächsten liegen immer zwei andere Koffer. Du wartest jedes Mal, bis die anderen vorbeigezogen sind. Wären alle Koffer eines Typs direkt hintereinander, könntest du sie viel schneller einsammeln. Genauso arbeitet der Speicher deines Computers – und viele Entwickler ignorieren das, bis die Performance plötzlich einbricht.

Ein erfahrener Java-Entwickler hat sich dieses Phänomen genauer angesehen. Er berichtet von seiner Arbeit mit großen Klassen und vielen Attributen. Normalerweise denkt man bei Performance an Algorithmen und deren Komplexitätsklassen – O(n), O(log n) und so weiter. Doch selbst bei einem einfachen linearen Durchlauf (O(n)) können die Laufzeiten dramatisch variieren. Der Grund liegt tiefer: im Zusammenspiel zwischen CPU-Caches und der Anordnung der Daten im Arbeitsspeicher.

Wie der Computer seine Daten organisiert

Die CPU hat mehrere Cache-Ebenen: L1, L2 und L3. L1 ist klein und extrem schnell, L3 größer und langsamer. Das Betriebssystem teilt den Arbeitsspeicher in Seiten (Pages) ein, und die Hardware lädt Daten in sogenannten Cache-Lines. Eine Cache-Line ist typischerweise 64 Bytes groß. Wenn du auch nur ein einziges Byte aus dem Speicher anforderst, lädt die CPU gleich die gesamte Umgebung – 64 Bytes – in den Cache. Der Gedanke dahinter: Daten, die zeitlich oder räumlich nahe beieinander liegen, werden oft zusammen benötigt.

Der Entwickler hat auf seinem System die konkreten Werte ermittelt: L1d-Cache pro CPU-Kern etwa 35 KiB (nach Teilung durch die Anzahl der Instanzen), was 560 Cache-Lines entspricht. Diese Zahlen sind nicht nur Theorie – sie entscheiden darüber, wie schnell dein Programm läuft.

Array of Structs vs. Struct of Arrays – ein Beispiel

Angenommen, du modellierst ein Spiel mit Monstern. Jedes Monster hat einen Namen, eine Position, Lebenspunkte und einen booleschen Wert is_alive. In Java würdest du vermutlich eine Klasse Monster schreiben mit allen Feldern und dann ein Array von Monster-Objekten anlegen. Das nennt man Array of Structs (AoS). Jedes Objekt belegt im Speicher eine bestimmte Größe – sagen wir 64 Bytes. Wenn du jetzt alle Monster durchgehst und nur prüfen willst, ob sie noch leben, holst du trotzdem jedes Mal das gesamte Monster-Objekt in den Cache. Die Cache-Line wird mit den 64 Bytes eines Monsters gefüllt – und du nutzt nur ein einziges Byte daraus. Verschwendung.

Die Alternative: Lege die Daten spaltenweise an. Statt eines Arrays von Monstern hast du separate Arrays für jeden Feldtyp: ein boolean-Array für is_alive, ein float-Array für die x-Position, ein int-Array für Lebenspunkte. Das nennt sich Struct of Arrays (SoA). Nun liegen alle booleschen Werte hintereinander im Speicher. Eine Cache-Line fasst 64 boolesche Werte (1 Byte pro boolean in Java, wenn nicht optimiert). Du kannst also 64 Monster auf einmal auf ihren Lebensstatus prüfen, ohne unnötige Daten zu laden.

Der Entwickler hat einen Benchmark durchgeführt. Bei einer Monster-Struktur von 1 KiB Größe zeigte sich ein bis zu 30-facher Geschwindigkeitsvorteil für SoA. Bei kleineren Strukturen (z. B. 64 Bytes) ist der Unterschied geringer, weil mehrere Monster-Objekte noch in eine Cache-Line passen. Aber sobald die Struktur größer wird, explodiert der Performance-Unterschied. Die CPU kann die Daten viel effizienter vorausladen, wenn sie sequenziell angeordnet sind. Der sogenannte Prefetcher erkennt das Muster und holt die nächste Cache-Line, bevor du sie brauchst. Du wartest praktisch nie auf den Speicher.

Wenn der Zugriff zufällig wird

Nicht alle Programme durchlaufen Daten schön linear. Hash-Maps, Bäume, Graphen und viele andere Datenstrukturen springen wild im Speicher umher. Der CPU-Prefetcher kann dann nicht mehr vorhersagen, wo die nächste Anfrage hingeht. Jeder Zugriff wird zu einem Cache-Miss – die CPU muss auf den langsameren Hauptspeicher warten. Hier wird die Größe deiner gesamten Datenmenge zum entscheidenden Faktor: Passt sie in den L1-Cache, sind die Zugriffe blitzschnell. Für L2 dauert es länger, für L3 noch länger, und wenn du den Hauptspeicher brauchst, wird es richtig teuer.

Der Entwickler hat eine Pointer-Chasing-Benchmark gebaut: N Monster-ähnliche Knoten werden zufällig verlinkt, und dann wird der Kette gefolgt. Jeder Sprung trifft eine unvorhersehbare Adresse. Das Ergebnis: eine Treppenkurve, die zeigt, wie die Zugriffszeit in Stufen ansteigt, sobald die Datenmenge die nächste Cache-Grenze überschreitet. Die Tabelle im Originalartikel verdeutlicht das: Bei 512 Monstern mit je 64 Bytes (Arbeitsmenge 32 KiB) liegt die Latenz bei ~3 ns – alles in L1. Verdoppelst du die Strukturgröße auf 128 Bytes (64 KiB Arbeitsmenge), steigt die Latenz auf ~11 ns, weil die Daten bereits in L2 ausweichen. Bei großen Datenmengen (131.072 Monster, 8 MiB vs. 16 MiB) liegen die Latenzen bei über 160 ns. Das ist der Unterschied zwischen einem Wimpernschlag und einem spürbaren Warten.

Besonders bemerkenswert: Die Kurven für verschiedene Strukturgrößen zeigen das gleiche Treppenmuster, nur verschoben. Größere Strukturen treffen die Stufen früher. Das heißt: Wenn du die Kontrolle über die Gesamtgröße deines Working Sets behältst, kannst du die Performance massiv beeinflussen.

Was heißt das für dich?

Als Entwickler denkst du vielleicht zuerst an Algorithmen-Komplexität. Das ist wichtig, aber nicht alles. Der Weg zum Speicher ist oft der Flaschenhals. Wenn du eine Datenstruktur entwirfst, frage dich: Welche Felder werden gemeinsam genutzt? Wie groß ist mein Working Set? Passt es in den L1-Cache? Kann ich die Daten so anordnen, dass sie sequenziell gelesen werden? Besonders bei Java mit seinen Objekt-Overheads (Header, Padding) ist der Unterschied zwischen AoS und SoA eklatant. Moderne JVMs optimieren zwar, aber sie zaubern nicht – sie können keine Cache-Misses vermeiden, wenn die Daten falsch liegen.

Auch für KI- und Datenverarbeitungs-Pipelines ist das relevant. Viele Matrix-Operationen, Embedding-Lookups oder Graph-Traversals profitieren von cache-freundlichen Layouts. Das Wissen um Cache-Lines und Seiten ist keine Spielerei für Assembler-Programmierer – es ist ein Werkzeug für alle, die ernsthaft performante Software schreiben wollen.

Der Artikel des Entwicklers erinnert uns daran: Jedes Byte zählt. Nicht nur auf der Festplatte, sondern auch im Arbeitsspeicher. Die Hardware ist kein undurchschaubarer Kasten – sie folgt klaren Regeln. Wer sie versteht, kann aus demselben Algorithmus das Doppelte oder Dreifache an Leistung herausholen. Und manchmal reicht schon eine kleine Umstellung – von Array of Structs zu Struct of Arrays – um aus einer lahme Endlosschleife einen rasanten Durchlauf zu machen.

Quelle: fzakaria.com

Ein Architekt, der jahrelang Grundrisse von Hand zeichnete, bekommt plötzlich einen Assistenten, der in Minuten Baupläne entwirft. Softwareentwickler erleben Ähnliches mit Coding Agents. Ein erfahrener Open‑Source‑Entwickler hat seine Erfahrungen geteilt: Er schreibt kaum noch Code von Hand. Viele erleben diesen Wandel.

Seine Arbeitsweise hat sich fundamental verändert. Projekte wie Vite+ (Features in Rust, obwohl er die Sprache kaum beherrscht), fate 1.0 (Live Views, Drizzle‑ und GraphQL‑Support) und Codiff (eine schnelle Diff‑Review‑App) entstanden zu 90 % oder 100 % durch KI‑Codegenerierung. Für Athena Crisis, ein älteres, von Hand geschriebenes Spiel, ließ er die KI 70 Fehler beheben, Features implementieren und Tests schreiben – während er an anderen Projekten arbeitete. „Ich bin einfach nur erstaunt“, sagt er. Nie zuvor gab es eine solche Verbesserung der Entwicklererfahrung.

Wie der Workflow mit KI‑Agenten heute aussieht

Er nutzt die Codex CLI mit einem starken Modell (GPT‑Level). Er bevorzugt die Befehlszeile, weil sie mit einem leeren Blatt beginnt – keine alten Chats, keine Ablenkung. Sein Arbeitsplatz: ein Terminalfenster pro Projekt, links Codex, rechts die Konsole. So arbeitet er an drei bis sechs Projekten gleichzeitig. Der Flaschenhals ist nicht mehr das Schreiben von Code, sondern das Diskutieren und Reviewen der Ergebnisse. Er ordnet die Projekte räumlich auf einem großen Bildschirm: fate oben Mitte, void links, Athena Crisis rechts. Diese räumliche Zuordnung hilft beim Multitasking.

Seine Prompts sind knapp: „Ich will X bauen. Hol Kontext aus Y und Z, mach einen Vorschlag und frag mich, was noch unklar ist.“ Bevor der Agent startet, iteriert er mit ihm über den Plan. Bei Fehlerbehebungen schreibt der Agent zuerst einen Test, der den Fehler reproduziert. Das erhöht die Wahrscheinlichkeit, dass er das richtige Problem löst. Trotzdem: Die Modelle gehen oft in die falsche Richtung. Manchmal ist es besser, eine Sitzung abzubrechen und neu zu starten. Für größere Änderungen nutzt er /review-Zyklen. Sein Review‑Tool ist Codiff, das einen geführten Walkthrough der Änderungen liefert.

Die neuen Engineering Values

Der Autor leitet Werte ab, die für die Softwareentwicklung ab 2026 entscheidend sind. Die Art, Code zu produzieren, hat sich gewandelt, aber grundlegende Prinzipien bleiben – ihre Gewichtung verschiebt sich.

Starke Verantwortung

Gute Ingenieure zeichnen sich durch Domänenwissen und Eigentümerschaft aus. KI‑Agenten verstärken das: Wer sein Produkt kennt, liefert schneller. Wer keine Ahnung hat, erzeugt Lärm. Koordination wird teurer. Deshalb setzt er auf kleine Teams von zwei bis drei Personen mit klaren Zuständigkeiten und isolierten Repositories. Das tut weh, denn er war lange ein Verfechter von Monorepos. Starke Verantwortung bedeutet, Architektur, Anforderungen und langfristige Richtung zu verstehen, die Arbeit der Agenten zu reviewen und Entscheidungen zu treffen – manchmal direkt auf main zu pushen. Code‑Reviews in kleinen Teams dienen der Abstimmung, nicht dem Streit über Zeichensetzung.

Geschmack, Geschmack, Geschmack

Er hat eine geringe Toleranz für Bullshit – und mit Agenten könne jeder den ganzen Tag Bullshit produzieren. Sein Appell: „Hör einfach auf.“ Guter Geschmack bedeutet nicht nur, großartige Produkte zu bauen, sondern auch zu entscheiden, ob es sich lohnt, Zeit in etwas zu investieren. Sein Rat an Teams: Verbringt mehr Zeit damit herauszufinden, was die Zeit wirklich wert ist.

Strenge Leitplanken und schnelle Feedbackschleifen

Große Organisationen legen Code enge Beschränkungen auf, um Geschwindigkeit zu halten. Mit Coding Agents verhält es sich ähnlich: Jede Sitzung gleicht einem neuen Mitarbeiter ohne Kontext. Je mehr Regeln (Lint‑Regeln, automatisierte Tests, schnelle Verifikation), desto schneller iterieren Menschen und Agenten. Schnelle, skalierbare Werkzeuge sind wichtiger denn je. Enge Feedbackschleifen machen den Unterschied zwischen einer Minute und einer Stunde Bearbeitungszeit. Tools sollten nur geänderte Dateien prüfen und nicht mit der Codebasis wachsen.

Kontext im Repository

Kontext war bisher über viele Orte verteilt: Notion, Meetings, implizites Wissen, Commit‑Kommentare. Jede Agentensitzung ist wie ein neuer Mitarbeiter, der nicht an all diese Quellen herankommt. Die Lösung: den gesamten relevanten Kontext direkt im Repository ablegen – lokal, zugänglich für Agenten und Menschen. Das ist der Ort, um Geschmack, Werte und Denkweise zu injizieren. Agenten sollten keinen Schrott in die Codebasis spülen. Code wird noch stärker fürs Lesen optimiert: Weniger und einfacherer Code ist leichter zu verstehen und zu reparieren.

Den eigenen Stack besitzen

Früher bestand eine App zu 95 % aus Drittanbieter‑Abhängigkeiten. Externe Bibliotheken waren sinnvoll, weil eigenes Schreiben teuer war. Aber das machte abhängig von einem Stack ohne Kontrolle. Jede Abhängigkeit bringt Architektur, Einschränkungen und Entscheidungen mit. Agenten verschieben die Kosten: Sie machen es günstiger, eigene Lösungen zu bauen. Der Entwickler hat einen eigenen Open‑Source‑JavaScript‑Stack aufgebaut – für Daten, Internationalisierung, UI, Tool‑Konfigurationen. Das erlaubt ihm, neue Projekte schnell mit engen Vorgaben für Agenten zu starten und die volle Kontrolle zu behalten.

Was das für uns bedeutet

Der Autor weiß, dass dies nicht nur individuelle Arbeitsweisen betrifft, sondern ganze Organisationen umkrempelt. „Alle technischen Organisationen werden sich drastisch ändern müssen, wenn sie erfolgreich sein wollen.“ Wer heute noch in traditionellen Code‑Reviews und langen Genehmigungsprozessen denkt, verliert den Anschluss. Code und Programmierung werden nicht verschwinden. Englische Spezifikationen in Markdown sind eine furchtbare Programmiersprache – dynamischer Code mit Agenten erscheint sinnvoller.

Die Rolle des Ingenieurs verschiebt sich vom Code‑Schreiber zum System‑Dirigenten. Alte Werte wie Sorgfalt, Verantwortung und guter Geschmack bleiben zentral, müssen aber neu interpretiert werden. Statt selbst jede Zeile zu tippen, kuratierst du die Ausgabe von KI‑Assistenten. Statt jedes Detail zu wissen, musst du sicherstellen, dass die Leitplanken stimmen. Statt aufwändiger Koordinationsschleifen setzt du auf kleine, fokussierte Teams und klare Verantwortungen. Das passiert jetzt. Die Frage ist nicht, ob du mitziehst, sondern wie schnell du deine eigenen Engineering Values anpassen kannst.

Quelle: cpojer.net

Ein Klick auf einen präparierten Link in einem öffentlichen Repository kann innerhalb von Sekunden alle deine privaten Repositories kompromittieren. Ein Angreifer könnte Code lesen, ändern oder Push-Requests in deinem Namen ausführen. Das ermöglicht eine kürzlich entdeckte Sicherheitslücke in der browserbasierten Version von Visual Studio Code (VSCode), die der Sicherheitsforscher Ammar Askar veröffentlicht hat.

Was ist github.dev und warum ist es ein Ziel?

GitHub bietet mit github.dev eine praktische Funktion. Du kannst aus jedem Repository die URL von github.com auf github.dev ändern oder über das Menü auswählen. Du öffnest dann eine schlanke Version von VSCode im Browser. Diese Web-App kann auf alle Dateien des Repositories zugreifen – auch auf private – und ermöglicht Pull Requests, Commits und mehr. GitHub sendet ein OAuth-Token an github.dev, das dem Browser-Zugriff die vollen Rechte deines Kontos gibt. Dieses Token ist nicht auf das eine Repository beschränkt, sondern erlaubt Lese- und Schreibzugriff auf alle Repositories, auf die du Zugriff hast. Ein Angreifer, der an dieses Token gelangt, hat die Kontrolle über deine komplette GitHub-Präsenz. Die Schwachstelle setzt hier an.

Die Sicherheitsarchitektur von VSCode-Webviews

VSCode verwendet für die Darstellung von Inhalten wie Markdown-Vorschauen oder Jupyter-Notebooks sogenannte Webviews. Das sind Iframes mit einer eigenen Herkunft (vscode-webview://...), die vom Hauptfenster (vscode-file:// oder im Browser entsprechend) getrennt sind. So soll verhindert werden, dass schädlicher Code aus dem Webview auf die Node.js-APIs oder die VSCode-internen Funktionen zugreifen kann. Standardmäßig ist jede Kommunikation zwischen den beiden Fenstern nur über die window.postMessage()-API erlaubt. Das ist eine solide Maßnahme – wenn sie konsequent angewendet wird.

Der Fehler: Tastatureingaben werden ungefiltert weitergereicht

Es gibt eine Ausnahme für die Benutzererfahrung. Wenn du dich in einem Webview befindest und eine Tastenkombination wie Strg+Umschalt+P (Befehlspalette) drückst, erwartest du, dass die Aktion auch im Webview funktioniert. VSCode löst das, indem es standardmäßig einen Event-Handler namens did-keydown im Webview registriert. Dieser lauscht auf Tastatureingaben und leitet sie als Nachricht an das Hauptfenster weiter. Das Problem: Es gibt keine Prüfung, ob die Tastatureingaben tatsächlich vom Benutzer oder von einem Skript innerhalb des Webviews stammen. Ein Angreifer, der JavaScript im Webview ausführen kann – zum Beispiel über eine manipulierte Jupyter-Notebook-Zelle – kann also beliebige Tastatureingaben simulieren.

Der Angriffsablauf im Detail

Um die Lücke für eine Token-Exfiltration zu nutzen, mussten mehrere Hürden überwunden werden. Mit simulierten Tasten kann man die Befehlspalette öffnen und mit Pfeiltasten navigieren, aber Text lässt sich nicht eingeben – der Eingabefokus liegt auf einem HTML-Input-Element, das nicht auf programmatische Tastenevents reagiert. Also nutzt Askar einen anderen Trick: VSCode hat eine Standard-Tastenkombination Strg+Umschalt+A, die die primäre Schaltfläche einer Benachrichtigung bestätigt. Wenn das Webview eine Benachrichtigung auslöst, die zur Installation einer empfohlenen Erweiterung auffordert, kann der Angreifer diese mit Strg+Umschalt+A akzeptieren.

Die nächste Hürde: Seit VSCode 1.97 gibt es einen Vertrauensmechanismus für Verlage (Publisher). Bei der ersten Installation einer Erweiterung eines unbekannten Herausgebers erscheint ein Dialog, der die Zustimmung erfordert. Der Angreifer kann diesen Dialog nicht per Tastendruck bestätigen, weil die Schaltfläche „Publisher vertrauen & installieren“ nur auf direkte Klick-Events reagiert – nicht auf programmatische Tastatureingaben. Hier kommt eine andere VSCode-Funktion ins Spiel: lokale Arbeitsbereichserweiterungen. In einem vertrauenswürdigen Arbeitsbereich (github.dev-Arbeitsbereiche sind immer vertrauenswürdig) können Erweiterungen direkt aus dem Verzeichnis .vscode/extensions installiert werden, ohne den Publisher-Vertrauenscheck zu durchlaufen. Der Angreifer muss also lediglich eine eigene Erweiterung in das Repository des Opfers packen.

Ein weiteres Problem: Die Web-Version von VSCode erwartet Erweiterungen von vscode-cdn.net und schlägt bei lokalen Dateien eine Content Security Policy (CSP)-Verletzung. Askar umgeht das, indem er die Erweiterung so konfiguriert, dass sie selbst eine neue Tastenkombination (Strg+F1) definiert, die den Befehl workbench.extensions.installExtension aufruft – und diesen Befehl so parametrisiert, dass die Publisher-Prüfung übersprungen wird. Nachdem die lokale Erweiterung installiert ist und die neue Tastenkombination aktiv wird, simuliert das Angreifer-Skript ein weiteres Tastendruck-Ereignis für Strg+F1. Daraufhin wird die eigentliche bösartige Erweiterung installiert, die das OAuth-Token ausliest und an den Angreifer sendet.

Der Proof-of-Concept und was du tun kannst

Askar hat einen funktionierenden Proof-of-Concept veröffentlicht. Der Link führt direkt auf ein Jupyter-Notebook in github.dev. Nach einem Klick siehst du eine Statusmeldung, und innerhalb weniger Sekunden werden deine privaten Repositories und dein Token in einem Informationsfenster angezeigt. Wenn du den PoC selbst ausprobierst, solltest du anschließend die Erweiterung deinstallieren und die cookies/local storage von github.dev löschen, da die bösartige Erweiterung sonst auf allen github.dev-Seiten aktiv bleibt. Falls du noch nie github.dev genutzt hast, erscheint vor dem ersten Laden ein Anmeldedialog. Wenn du in diesem Moment den Link nicht klickst, sondern die Seite schließt, bist du sicher.

Was VSCode gut gemacht hat und was fehlt

Der Forscher meldete die Lücke verantwortungsvoll, und sie wurde innerhalb kurzer Zeit geschlossen. Die Version von github.dev erhielt einen Patch, der die Weitergabe von Tastatureingaben aus Webviews einschränkt. Die grundsätzliche Architektur bleibt anfällig, ähnliche Fehler könnten in Zukunft auftreten. Die Desktop-Version von VSCode ist ebenfalls betroffen, allerdings ist der Angriff dort schwieriger, da der Angreifer das Opfer erst dazu bringen muss, das Repository zu klonen und das Notebook zu öffnen.

Was das für dich bedeutet

Die Sicherheitslücke zeigt, wie ein kleiner Kompromiss bei der Benutzerfreundlichkeit schwerwiegende Konsequenzen haben kann. Sei vorsichtig mit Links, die dich auf github.dev öffnen, insbesondere wenn sie auf Jupyter-Notebooks oder andere interaktive Inhalte verweisen. Lösche regelmäßig die Browserdaten für github.dev, wenn du es nicht aktiv nutzt. Ein Klick kann ausreichen, um die Kontrolle über deine gesamte GitHub-Identität zu verlieren.

Quelle: blog.ammaraskar.com

Wenn ein Vermieter einen Generalschlüssel für jede Tür hätte, könnte er die Möbel umstellen oder den Strom abdrehen. Dieses Unbehagen verspüren viele europäische Organisationen bei US-Cloud-Anbietern. Die Sorge vor einem digitalen Kill Switch – dem Abschalten von Diensten durch US-Behörden – ist gewachsen. Die EU-Kommission hat nun Maßnahmen vorgestellt, die dieses Problem angehen sollen: Regulierung von Cloud-Diensten für den öffentlichen Sektor und Stärkung der heimischen Tech-Industrie.

Am 3. Juni 2026 veröffentlichte die EU-Kommission das „European Technological Sovereignty Package“ mit zwei Gesetzesvorschlägen: dem Cloud and AI Development Act (CAIDA) und dem überarbeiteten Chips Act 2.0, plus einer Open-Source-Strategie für den Energiesektor. Matthew Finnegan berichtet auf Computerworld darüber. US-Anbieter werden nicht verboten, aber öffentliche Auftraggeber müssen bei sensiblen Workloads bestimmte Kriterien beachten. Vizepräsidentin Henna Virkkunen: „Technologische Souveränität bedeutet nicht Protektionismus. Europa bleibt offen, partnerschaftlich und setzt auf fairen Wettbewerb.“ Ziel ist, Abhängigkeiten von einzelnen Anbietern zu vermeiden.

Ein Balanceakt zwischen Offenheit und Unabhängigkeit. Der CAIDA zielt darauf ab, die Rechenzentrumskapazität in der EU zu verdreifachen – in fünf bis sieben Jahren. Genehmigungsverfahren werden vereinfacht, Anreize geschaffen. Öffentliche Auftraggeber müssen in vier Stufen Souveränitätskriterien erfüllen. Stufe 1 verlangt nur Datenzentren in der Region – das erfüllen US-Anbieter bereits. Stufe 4 fordert vollständige Kontrolle über den Software-Stack, inklusive Cybersecurity-Zertifizierungen und Unabhängigkeit von der Eigentümerstruktur. Laut Finnegan fallen 70 Prozent der öffentlichen Workloads unter Stufe 1, 20 Prozent unter Stufe 2, 9 Prozent unter Stufe 3 und nur 1 Prozent unter Stufe 4. Die EU greift gezielt dort ein, wo die Risiken am größten sind.

Für private Unternehmen ändert sich vorerst nichts. Die Regulierung betrifft nur öffentliche Beschaffungen. Die Kriterien könnten aber als Standards dienen. Europäische Cloud-Anbieter könnten von den höheren Souveränitätsstufen profitieren. Der Chips Act 2.0 fördert die Halbleiterproduktion in Europa. Ziel ist eine widerstandsfähige Wertschöpfungskette von der Hardware bis zur Cloud-Infrastruktur.

Die Vorschläge müssen noch vom Europäischen Parlament und dem Rat der EU verhandelt werden. Die endgültigen Regeln könnten anders aussehen. Die EU will ihre technologische Souveränität stärken, ohne sich von der Welt abzukoppeln. Es ist ein vorsichtiger Schritt, kein radikaler Bruch. Für Tech-Anwender heißt das: Die Cloud-Landschaft in Europa wird sich verändern. Die Frage ist, wie schnell und ob der Preis in Form höherer Kosten oder geringerer Innovation zu hoch ist.

Quelle: computerworld.com

Du leitest eine Werkstatt, in der früher jeder Handgriff teuer war und minutiös geplant werden musste. Schablonen, Arbeitsabläufe, genaue Zeitpläne. Heute stehen Maschinen in der Werkstatt, die Sägen, Schleifen und Zusammenbauen in Sekundenschnelle erledigen. Die Flaschenhälse verschieben sich. Wer prüft die Arbeit der Maschinen? Wie kommt ein fehlerfreies Produkt raus? Und was machen erfahrene Handwerker, wenn die Maschine 80 Prozent der Routinearbeiten übernimmt?

Genau diese Verschiebung erlebt die Softwareentwicklung. Jahrelang war die teuerste Ressource im Engineering die Zeit der Entwickler: Code schreiben, testen, refactoren. Darauf waren alle Prozesse ausgelegt. Jetzt übernehmen KI-Assistenten wie Claude Code weite Teile des Programmierens. Eine Führungskraft des Claude-Code-Teams hat beschrieben, wie sie ihre Organisation umgebaut hat. Wer die alten Prozesse nicht hinterfragt, wird von der Beschleunigung überrollt.

Planung: Von der Monatsvorschau zur Just-in-Time-Strategie

Früher: Plane langfristig, Codeänderungen sind teuer. Ein sechsmonatiger Roadmap war Standard. Wochenlange Diskussionen über Features, Design-Dokumente, Prioritäten – dann Umsetzung. Im Claude-Code-Team hielt das nicht einmal drei Monate. Die KI veränderte die technische Landschaft so schnell, dass detaillierte Planung obsolet war, bevor die erste Deadline kam.

Die Lösung: Just-in-Time-Planung. Statt aufwändiger Dokumente setzt das Team auf schnelle Prototypen. Bau etwas, lass interne Nutzer damit arbeiten, sammle Feedback. Aus diesem Kreislauf entstehen die nächsten Schritte – fast wie beim JIT-Compilieren. Weniger Produkt-Reviews, mehr Hands-On. Entscheidungen fallen in Pull-Requests und Prototypen, nicht in Besprechungsräumen.

Wissenstransfer: Frag nicht den Autor, frag die KI

Eine große Veränderung betrifft den Wissenstransfer. Bisher: Wer hat diesen Code geschrieben? Dann suchte man die Person, unterbrach sie, fragte nach dem Warum. Mit KI-generierten Commits wird das sinnlos. Der „Autor“ ist jetzt ein Prompt – und die Person, die den Prompt eingegeben hat, kann nicht mehr alle Details erklären.

Der neue Reflex: Stell die Frage zuerst Claude. Die KI hat Zugriff auf den gesamten Codebase, die Commit-Historie und oft mehr Kontext als der Mensch. Frag dich gleich mit, ob dieser Wissensabruf automatisiert werden kann. Beispiel: Die Teamleitung las morgens manuell Kundenfeedback-Kanäle. Heute fasst ein automatisiertes Claude-Analyse-Skript die Erkenntnisse zusammen, ohne dass jemand extra eingreift. Das spart Zeit und liefert konsistentere Ergebnisse.

Code-Review: Vertrauen, aber prüfen, wo es zählt

Code-Reviews waren die heilige Kuh der Qualitätssicherung. Jeder Pull-Request wurde von mindestens einem Entwickler gegengelesen. In einer KI-gestützten Organisation hält das nicht stand – die Menge an generiertem Code überfordert jeden Menschen. Die Antwort des Teams ist eine klare Arbeitsteilung.

Claude übernimmt Stilprüfung, Linting, Bugerkennung und automatisches Hinzufügen von Tests. Das ist schnell, zuverlässig und 24/7 verfügbar. Der Mensch bleibt eingebunden, wo es auf Expertise ankommt: bei Sicherheitsfragen, juristischen Risiken, Produktentscheidungen. Product Manager und Designer prüfen, ob der Code den Funktionsumfang trifft und das Nutzererlebnis stimmt. Die Führungskraft betont, dass dieses Gleichgewicht dynamisch bleibt – was heute menschliche Expertise erfordert, kann die nächste KI-Generation vielleicht selbst übernehmen. Die Grenzen regelmäßig neu ausloten.

Teamstruktur: Warum Rollen verschwimmen und welche Profile jetzt zählen

Wenn KI die Routinearbeit erledigt, verändern sich die Anforderungsprofile. Product Manager prototypen jetzt selbst – früher undenkbar. Entwickler entdecken Design und Content. Klassische Rollenbilder lösen sich auf. Zwei besonders wertvolle Profile entstehen: der kreative Baumeister mit Produktverständnis und der Tiefenexperte für Systemarchitektur.

Der kreative Baumeister hat Visionen, versteht das Problem und leitet die KI geschickt an. Er ist neugierig, probiert aus, scheitert schnell und lernt daraus. Der Systemexperte sorgt dafür, dass die KI überall laufen kann – vom lokalen Rechner bis zur Cloud. Reine Schreibgeschwindigkeit von Code wird unwichtiger. Die Kunst liegt in der Orchestrierung: Wo braucht es menschliches Urteilsvermögen? Dort wird investiert.

Die Umstellung: Wenige Prinzipien, viel Freiheit

Wie führt man tiefgreifende Veränderungen ein? Die Führungskraft beschreibt einen Ansatz aus verbindlichen Teamprinzipien und dezentraler Freiheit für Unterteams (Pods). Drei Prinzipien sind nicht verhandelbar: Erstens, jeder im Team nutzt das eigene Produkt – Claude Code und Claude Cowork – tagtäglich. Zweitens, die Teamstruktur bleibt flach. Manager arbeiten zunächst selbst als Entwickler mit, bevor sie führen. Drittens, keine falsche Nostalgie: Prozesse, die nicht mehr funktionieren, werden sofort abgeschafft.

Innerhalb dieses Rahmens haben die Pods große Autonomie. Sie entscheiden selbst, wie sie Claude ins Triage-System einbinden, Standups gestalten, Workflows als erstes „claudifizieren“. Diese Mischung aus klarer Richtung und lokaler Anpassung verhindert Erstarrung, aber auch Chaos.

Metriken für den Wandel: Drei Zahlen, die jede Führungskraft verfolgen sollte

Wie misst man, ob die neue Arbeitsweise greift? Die Führungskraft schlägt drei konkrete Kennzahlen vor. Erstens, die Einarbeitungszeit neuer Teammitglieder sinkt. Im Claude-Code-Team liefern Engineers in der ersten Woche produktiven Code. Früher dauerte das Monate. Zweitens, die Durchlaufzeit eines Pull-Requests wird kürzer. Wenn sie nicht sinkt oder steigt, liegt das Problem oft in der Build-Infrastruktur oder CI-Pipeline, nicht im Code-Review. Drittens, der Anteil KI-gestützter Commits steigt. Zielmarke: 100 Prozent. Seit Monaten gebe es im Team keinen nicht assistierten Commit mehr.

Wichtig: Höherer Durchsatz ist kein Selbstzweck. Er ist nur wertvoll, wenn er das eigentliche Ziel unterstützt – Probleme schneller lösen, bessere Produkte liefern. Blind auf mehr Code setzen, ohne Qualität und Ausrichtung zu kontrollieren, führt ins Leere.

Für den Start: Der lauteste Workflow ist der erste Kandidat

Wenn du vor der Frage stehst, wo du anfangen sollst: Such dir den Workflow, der am meisten Lärm macht – den teuersten, unbeliebtesten, den, vor dem dein Team zurückschreckt. Frag dich: Dient er noch seinem Zweck? Falls ja, kann ich ihn automatisieren? Die Führungskraft erinnert an ein eigenes Beispiel: ein wöchentliches Review-Meeting mit vielen Teilnehmern, die teilnahmslos auf ihre Laptops starrten. Die einfache Frage „Warum haben wir dieses Meeting?“ offenbarte: Es war ein Relikt. Das Meeting wurde gestrichen.

Für die nächste Woche: Nimm dir einen Prozess vor. Vielleicht den Code-Review-Workflow, die Planungssitzung, die Art, wie ihr Tickets priorisiert. Frag, welchen Teil ein KI-Assistent übernehmen kann – nicht nur Schreiben, sondern auch Analysieren, Zusammenfassen, Vorschlagen. Die Antwort wird nicht perfekt sein, aber sie wird den Weg zeigen.

Quelle: claude.com