Kategorie: Erklärer

Wenn Maschinen tanzen – aber nur im Video

Ein humanoider Roboter macht eine Rückenrolle, schenkt Wein ein oder fegt mit einem Besen. Die Bewegungen wirken flüssig, fast lebendig. Man könnte glauben, die Zukunft sei da. Doch diese Videos sind inszenierte Darbietungen, näher an einem Film als an echter Technologie. Jeremy Hsu von Ars Technica zeigt, warum man virale Roboter-Clips skeptisch betrachten sollte.

Menschen neigen dazu, humanoiden Robotern menschenähnliche Fähigkeiten zuzuschreiben. Das Gehirn interpretiert Gesichter, Körper und Bewegungen automatisch. Jonathan Hurst von Agility Robotics und der Oregon State University bringt es im Artikel auf den Punkt: „Menschen extrapolieren automatisch und nehmen an, dass ein Roboter, der wie ein Mensch aussieht, all die Dinge tun kann, die ein Mensch tun kann – was nicht stimmt.“ Diese Fehleinschätzung nutzen viele Start-ups, um Investoren zu gewinnen. Die Roboter können die Erwartungen nicht erfüllen.

Die Kluft zwischen Demo und Realität

Sergey Levine von der University of California, Berkeley spricht das Problem der Generalisierung an. Ein Roboter zeigt vielleicht in einer kontrollierten Studioumgebung einen Backflip oder gießt aus einer bestimmten Flasche Wein in ein bestimmtes Glas. Aber in einer fremden Umgebung mit anderer Flasche und Glas? Meist nicht. „Das ist tatsächlich viel schwieriger, als einen Roboter in einer Stage-Demo einen Backflip machen zu lassen“, sagt Levine. Roboterfähigkeiten lassen sich nur durch groß angelegte Tests in echten Umgebungen messen – nicht durch ein einminütiges Video.

Die Demos sind ein kleiner, optimierter Ausschnitt. Oft kontrollieren Menschen im Hintergrund die Aktionen per Fernsteuerung (Teleoperation). Dipam Patel von der Purdue University rät: „Solange ein Forschungspapier oder ein Unternehmen nicht explizit erwähnt, dass der Roboter vollständig autonom ist, sollte man das mit einem sehr großen Körnchen Salz nehmen.“ Viele beeindruckende Clips zeigen ferngesteuerte Roboter, keine autonomen.

Darauf solltest du achten

Bei viralen Robotervideos helfen konkrete Fragen, die Inszenierung zu durchschauen. Patel schlägt drei vor: Ist die Umgebung neu für den Roboter? Ein Roboter, der eine Aufgabe zum ersten Mal in unbekanntem Raum löst, ist beeindruckender als einer, der sie unter Trainingsbedingungen wiederholt. Ist die Geschwindigkeit realistisch? Videos werden oft beschleunigt; achte auf Angaben wie „2x“ – in Wirklichkeit sind Roboter oft langsam. Wie transparent ist die Quelle? Unternehmen, die auch Fehler zeigen, sind glaubwürdiger. Der Artikel unterscheidet zwischen Unterhaltungs-Clips und informativen Demonstrationen, die den Trainingsprozess offenlegen. Reale Fortschritte zeigen sich in langwierigen Tests und wissenschaftlichen Publikationen, nicht in perfekt geschnittenen Videos.

Die Analogie des Zauberkunststücks

Ein Zauberer lässt eine Münze verschwinden – der Trick wirkt echt, ist aber Illusion. Genauso sind Robotervideos inszenierte Vorführungen, die Aufmerksamkeit oder Investitionen gewinnen sollen. Der wahre Stand der Technik gleicht einem Zauberer, der denselben Trick tausendmal übt, aber bei neuen Bedingungen scheitert. Ein humanoider Roboter, der in einer Show einen Salto macht, ist ein Highlight – kein Beleg dafür, dass er alltägliche Aufgaben bewältigt.

Diese Einsicht hilft, den Hype einzuordnen. Die Robotik macht Fortschritte, aber stetig, nicht spektakulär. Forscher arbeiten an flexiblen, vielseitigen Robotern. Bis dahin ist es ein langer Weg. Jeremy Hsus Artikel erinnert daran, gesunde Skepsis zu bewahren. Nicht jedes virale Video ist ein Durchbruch – oft nur ein gut gemachter Werbespot.

Was das konkret bedeutet

Für Technikinteressierte: Virale Robotervideos sind unterhaltsame Einblicke, keine Beweise für die Gegenwart. Wer echte Fortschritte verstehen will, sucht nach wissenschaftlichen Publikationen, Langzeittests und Berichten, die auch Grenzen benennen. Die Robotik leidet unter Überhöhung durch Social Media. Die Frage, ob ein Roboter den Abwasch erledigen kann, ist nicht mit einem Tanzvideo beantwortet. Echte Fortschritte zeigen sich in zuverlässiger, alltagstauglicher Funktion – selten in einem 30-Sekunden-Clip.

Quelle: arstechnica.com

Du kennst das: Eine Suchmaschine liefert in Sekunden Ergebnisse, dein Smartphone erkennt deine Stimme und trägt einen Termin ein. Dahinter steckt Künstliche Intelligenz. Ein Bericht des Wall Street Journal (WSJ) hat Diskussionen ausgelöst. Der Artikel zeigt, wo KI heute eingesetzt wird – in der Medikamentenentwicklung oder automatisierten Kundenbetreuung. Bereiche, die vor fünf Jahren undenkbar schienen. Was bedeutet das? Wie stellst du dir diese Technologie vor, ohne dem Hype zu verfallen?

Stell dir einen Assistenten vor, der unendlich viele Bücher gelesen hat, aber nicht versteht, was in ihnen steht. Er zitiert jede Statistik, doch nach den Gefühlen des Autors gefragt, steht er ratlos da. So funktioniert KI im Kern. Sie ist kein bewusstes Wesen, sondern ein Mustererkennungssystem. Der WSJ-Bericht hebt Fortschritte bei generativer KI hervor – Systeme, die Texte, Bilder oder Musik erzeugen. Sie lernen aus Datenmengen, berechnen Wahrscheinlichkeiten: Welches Wort folgt? Welches Pixel passt? Das Ergebnis wirkt menschlich, aber die Maschine versteht nichts. Sie spielt ein komplexes Ratespiel.

Der WSJ-Artikel betont: Unternehmen wie Google, Microsoft und Amazon investieren Milliarden. Ein Bereich ist die personalisierte Medizin. KI analysiert Patientendaten, erkennt Risiken, schlägt Behandlungen vor. Doch der Bericht warnt: Je leistungsfähiger die Systeme, desto lauter die Forderungen nach Regulierung. Wer trägt die Verantwortung, wenn eine KI einen Fehler macht – eine falsche Diagnose oder eine diskriminierende Entscheidung? Die Frage ist gesellschaftlich, nicht technisch. Diese Debatte greift der WSJ-Bericht auf.

Vielleicht fragst du dich: „Was hat das mit mir zu tun?“ Eine Menge. Jedes Mal, wenn ein Streaming-Dienst eine Empfehlung gibt, Spam gefiltert wird oder ein Chatbot hilft, arbeitet KI im Hintergrund. Sie ist Teil deines Alltags – unsichtbar, aber präsent. Der WSJ-Artikel beschreibt, wie Unternehmen ihre Effizienz steigern, aber auch Arbeitsplätze verändern. Routineaufgaben werden automatisiert. Das klingt bedrohlich, bietet aber Chancen. KI befreit uns von stupider Arbeit, damit wir uns auf Kreatives und Soziales konzentrieren können. Die Frage ist, wie wir diesen Wandel gestalten.

Ein weiterer Punkt ist die „Erklärbarkeit“ von KI. Viele Systeme arbeiten wie eine Blackbox: Daten rein, Ergebnisse raus, niemand sagt genau, warum. In Medizin oder Rechtswesen ist das ein Problem. Wie soll ein Richter eine KI-Entscheidung nachvollziehen, wenn selbst Entwickler sie nicht erklären? Der WSJ-Artikel verweist auf Forschungsansätze, die Entscheidungen transparenter machen – etwa durch eine Liste der wichtigsten Faktoren. Doch das ist schwierig: Je komplexer das Modell, desto schwerer durchschaubar seine Logik.

Auch die Wirtschaft ist betroffen. Der Bericht zitiert Analysten: KI wird in zehn Jahren globale Wertschöpfung in Billionenhöhe freisetzen. Gleichzeitig warnen sie vor einer „KI-Lücke“ zwischen großen Konzernen und kleinen Unternehmen. Das erinnert an die Anfänge des Internets: Wer zu spät kam, hatte das Nachsehen. Heute ist es ähnlich. Wer KI nicht versteht oder einsetzt, riskiert den Anschluss. Aber der WSJ-Artikel macht Mut: Viele KI-Tools sind als Open Source oder Cloud-Dienste erschwinglich. Du musst kein Datenwissenschaftler sein – du musst lernen, richtig zu fragen.

Ein übersehener Aspekt ist der Energieverbrauch. Der WSJ-Bericht erwähnt: Das Training eines einzigen großen KI-Modells kann so viel Strom verbrauchen wie ein Haus in einem Jahr. Das wirft ökologische Fragen auf. Energieeffizientere Chips und Algorithmen sollen helfen, aber das Thema bleibt. KI ist kein Selbstläufer, sondern eine Technologie, die wir bewusst gestalten müssen. Der Bericht fordert mehr Forschung zu nachhaltiger KI.

Zurück zur Analogie: Stell dir KI wie einen extrem schnellen, spezialisierten Handwerker vor. Er schlägt einen Nagel perfekt in die Wand, aber bei der Bildauswahl für die Einrichtung scheitert er – ihm fehlt der Geschmack. So sind aktuelle Systeme: Meister der Mustererkennung, unfähig, Kontext, Ironie oder Ethik zu verstehen. Der WSJ-Artikel unterstreicht: Deshalb müssen wir KI in menschliche Entscheidungsprozesse einbetten.

Der WSJ-Bericht zeigt: KI ist keine Zukunftsmusik mehr. Sie durchdringt unseren Alltag – von Assistenten über selbstfahrende Autos bis zur personalisierten Werbung. Aber sie ist kein Wundermittel. Sie ist ein Werkzeug, das in den richtigen Händen Vorteile bringt, aber auch Risiken birgt. Der wichtigste Satz aus dem Artikel: „KI ist nicht intelligent im menschlichen Sinne – sie simuliert Intelligenz.“ Wenn du das verinnerlichst, nutzt du die Chancen, ohne dem Hype zu glauben. KI wird bleiben. Sie wird nur so gut sein, wie wir sie einsetzen.

Quelle: wsj.com

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