**Boris Cherny** (Creator & Head of Claude Code @Anthropic) veröffentlicht auf LinkedIn eine Framework-Tabelle, **« Steps of AI Adoption »**, die die Einführung agentischer KI durch ein Engineering-Team über **5 Stufen (0→4)** abbildet, jede charakterisiert durch eine **Größenordnung der gesteuerten Agenten** und eine **Transformation der Rolle des Engineers**: **0 Gated** (0 Agenten, abgeschotteter Zugang), **1 Assisted** (~1 Agent — „du + ein Agent“, betreutes Pair Programming), **2 Parallel** (~10 Agenten — **Orchestrator**), **3 Supervised autonomy** (~100 Agenten — **Manager of Managers**, ein Org-Baum), **4 AI-native** (~1.000+ Agenten — **VP Steering by Intent**). Die Tabelle kreuzt fünf Spalten: Anzahl der Agenten, *wie es aussieht*, *der Engpass*, *die hilfreichen Produkte*, *die Guardrails*. **Zentrale These**: mehr Tokens zu verbrauchen bringt keinen Stufenaufstieg — der Aufstieg zur nächsten Stufe erfordert, **den nächsten Engpass zu identifizieren und aufzulösen** UND **den nächsten Satz an Guardrails aufzubauen**. Konkret: Claude eine verlässliche **Self-Verification-Loop** geben (Tests + Build + Lint + E2E in einer echten Umgebung), **Auto mode** aktivieren (um blockierende Berechtigungsabfragen zu vermeiden), **Code-Review und Security-Review zum Standard machen**, Multi-Agenten-Oberflächen einführen (Agent View CLI, Desktop, iOS/Android-Apps, Tag), dann `/loop`, `/batch`, `/goal`, **dynamische Workflows** und **worktree isolation** für Subagenten. Zum Thema Steuerung: Nutzung (Dashboard) misst **Aktivität, nicht Ertrag**; die richtige Frage lautet *„hätten wir hierfür ohnehin Engineering-Aufwand investiert? Wenn ja, wie viele manuelle Engineer-Stunden hätte es gekostet?“* — das ist der ROI. Der eigentliche Gewinn stellt sich ein, wenn **Fixes und Wartung im Hintergrund ablaufen** und Teams sich auf das *Bauen* konzentrieren. Anthropic befindet sich auf **Stufe 3, auf dem Weg zu 4**; Boris Cherny erklärt, persönlich **Stufe 4** erreicht zu haben.
#Boris Cherny#Claude Code#Anthropic
Boris Cherny (Creator & Head of Claude Code @Anthropic)
Netflix — Aktionärsbrief Q2 FY2026: GenAI skaliert in der Produktion (≈300 Titel in 2026), LLMs für Discovery und Natural-Language-Suche, KI-Tools über den gesamten Werbezyklus hinweg (Netflix)
SFEIR-Analyse (in der Stimme des Unternehmens) der am 16. Juli 2026 bekanntgegebenen Entscheidung von **Airbus**, **Scaleway** (Konzern **iliad**) als seine **„Trusted Cloud“** auszuwählen, um seine kritischen Geschäftsanwendungen und sensibelsten Daten (Flugzeugkonstruktion, Engineering, industrielle Produktion, Betrieb, geistiges Eigentum) zu hosten und zu modernisieren. Am Ende einer Anfang **Januar 2026** eröffneten Ausschreibung, bei der **zehn Kandidaten** verglichen wurden, setzt sich Scaleway anhand **dreier Kriterien** durch — technologische/KI-Fähigkeiten, operative Exzellenz und vor allem **rechtliche und Governance-Garantien**: europäische Gerichtsbarkeit, echter Datenschutz, **Immunität gegenüber** dem US-**Cloud Act**. SFEIR betont die **Umkehrung der Hierarchie**: Governance wog schwerer als Funktionalität, obwohl die US-Hyperscaler (Microsoft, Google, AWS) eine funktionale Überlegenheit behalten, die kein europäischer Akteur „auf der ganzen Linie“ erreicht. Die mehrjährige Vereinbarung mit nicht offengelegtem Betrag **ergänzt** (ersetzt nicht) die **Multicloud**-Strategie von Airbus — die vom Unternehmen vertretene Doktrin: den Aufbau eines Portfolios, in dem jede Werkstatt gemäß ihren eigenen Zwängen arbeitet, während man sich die **Fähigkeit zum Wechsel** bewahrt (Reversibilität, vgl. France Télévisions/ALIX, ohne Neuentwicklung eingesetzt). Der eigentliche Einsatz ist die **IA souveraine**: Modelle auf industriellen Daten (Simulation, vorausschauende Wartung, unterstütztes Engineering) auszuführen erfordert eine **vollständige Kette — Rechenleistung, Training, Inferenz — die innerhalb einer vertrauenswürdigen Rechtsprechung verbleibt**. Drei Lehren: eine überschrittene **Glaubwürdigkeitsschwelle** für die europäische souveräne Cloud; **Governance > Funktionen** bei strategischen Daten; Souveränität wird **in Schichten** aufgebaut (Infrastruktur → Plattform → Modell), und der entscheidende Teil — die KI-Reversibilität — wird sich in den kommenden Monaten entscheiden.
SFEIRs Analyse aus dem Ingenieur-Kabinett ("die Lesart eines Ingenieurs") des Launches von **Kimi K3** am **16. Juli 2026** durch das chinesische Labor **Moonshot AI**: ein **Open-Weights-Modell der Spitzenklasse (frontier-class)**, für das der Anbieter **rund 2,8 Billionen Parameter**, einen **Ein-Millionen-Token-Kontext** und eine **Veröffentlichung der Gewichte vor dem 27. Juli 2026** beansprucht (voraussichtlich unter einer Modified-MIT-Lizenz, wie schon bei der K2-Reihe). These: Fähigkeiten, die einst proprietären Giganten (Anthropic, OpenAI, Google) vorbehalten schienen, werden **als offene Gewichte, zum Kampfpreis, aus einem chinesischen Labor** verfügbar. SFEIR – obwohl **Partner von Anthropic und Google Cloud** und damit „ohne Interesse daran, ein chinesisches Modell schönzureden" – legt einen zentralen **methodischen Vorbehalt** an: Am Launch-Tag existiert **keine offizielle, vollständige Benchmark-Tabelle**; Spezifikationen (2,8 Billionen, Kimi Delta Attention, +25% Trainingseffizienz) und Scores stammen **vom Anbieter selbst** oder aus **Community-Arenen** und sind „als Behauptungen, nicht als gemessene Fakten zu behandeln." Die neue Architektur (**Kimi Delta Attention**, hybride lineare Aufmerksamkeit; Dekodierung angeblich bis zu **6,3x schneller** bei 1M Token) bricht mit dem Takt der K2-Reihe (K2 Juli 2025 → K2.7 Code Juni 2026, alle zwei Monate ein Flaggschiff); zwei Varianten begleiten den Launch (**K3 Max**, **K3 Swarm Max**), mit erzwungenem Auslaufen der Reihe kimi-k2.5/moonshot-v1 am **31. August 2026**. **Die eigentliche Waffe ist der Preis** (~3 $/M Input, 0,30 $ gecacht, 15 $ Output laut Sekundärquellen): ein Open-Weights-Modell der Spitzenklasse auf diesem Niveau **zieht die gesamte Preis-Leistungs-Kurve nach unten** – die Kommodifizierung der Modellschicht, beschleunigt durch Open Source. Die entscheidende Singularität ist jedoch kein Score: Es ist die **Reversibilität**. Ein Open-Weights-Modell der Spitzenklasse verwandelt eine konsumierte API (Anbieterabhängigkeit) in eine **Option** (Self-Hosting, Portabilität, Ausstieg aus dem Lock-in) – um den Preis einer schweren Infrastruktur, um 2,8 Billionen Parameter zu hosten. SFEIRs Sicht: **Open Weights verändert die Frage, nicht nur die Antwort** – nicht mehr „welches Modell ist das beste/günstigste?", sondern „wie viel meines Systems bin ich bereit, von einem Anbieter abhängig zu machen, den ich nicht kontrolliere?". Die richtige Haltung bleibt ein **geroutetes Portfolio** (ein Modell pro Aufgabe, ein Modell pro Randbedingung), wobei Kimi K3 dem Entscheidungsraster eine **Spalte „Reversibilität"** hinzufügt. Die Überzeugung „AI Only" bleibt unverändert: Das Modell ist eine Commodity, der dauerhafte Vorteil liegt im Engineering drumherum (Context Engineering, Harness, Kostensteuerung, Fähigkeit, die Meinung zu ändern). Die Zahlen müssen weiterhin „selbst" validiert werden – an den eigenen Repositories, den eigenen Daten.
Tech-Watch-Digest aus Primärquellen zur Position von **Gregor Hohpe** (Autor von *Enterprise Integration Patterns*, *The Software Architect Elevator*, *Cloud/Platform Strategy*; ehemaliger AWS- und Google-Cloud-Enterprise-Strategist, ehemaliger Chief Architect bei Allianz) zur Rolle des Architekten im Zeitalter generativer KI. These: KI **entwertet** den Architekten **nicht**, sie **verschiebt seinen Wert** vom Code hin zu dem, was KI nicht leistet — **Entscheidungen treffen und verantworten, Kompromisse abwägen, „Optionen verkaufen“, mit Menschen kommunizieren, tragfähige Abstraktionen erzeugen**. Kernformel (Craft Conference 2026): „*Developers mainly interact with machines… GenAI. In contrast, architects communicate with humans*“. Seine Kernthese — der Architekt müsse nicht die klügste Person im Raum sein, sondern solle **alle anderen klüger machen** — gewinnt an Gewicht, je reichlicher Code verfügbar wird: Der Vorteil entsteht durch **Entscheidungsdisziplin** und das **Aufdecken verborgener Kompromisse**, nicht durch Menge. Der Digest schlüsselt seine Positionen zudem nach Rolle auf (Enterprise-Architekt: vom **Kartografen zum Scout**; Software-Architekt: Entscheidungen **debuggen** statt Code schreiben; Plattform-Architekt: **Abstraktionen statt Illusionen**), seine Metapher der **realen Optionen** (Wert steigt mit technologischer Volatilität, Black-Scholes-Analogie) sowie seine Warnungen („*An AI-driven SDLC punishes bad habits much faster*“; die Gewinner der KI-Ära werden daran gemessen, wie schnell sie von der Experimentierphase zu einer **kontrollierten Produktion** übergehen). ⚠️ Die weitverbreitete Formel „Architekten, die KI nutzen, werden diejenigen ersetzen, die es nicht tun“ **stammt nicht von Hohpe**. Themenbereich: Softwarearchitektur, die Rolle des Architekten, Entscheidungsfindung, reale Optionen, Plattformen, GenAI im SDLC.
#Gregor Hohpe#Architect Elevator#Rolle des Architekten
Gregor Hohpe (sources primaires) — digest de veille
SFEIR-Analysenotiz, die den Beruf des Softwarearchitekten im Zeitalter generativer KI anhand des Rahmenwerks von **Gregor Hohpe** (*The Software Architect Elevator*) neu untersucht. Zentrale These: Der „**Orakel**"-Architekt — der Inhaber überlegenen Wissens, der Regeln vom Elfenbeinturm aus diktiert — ist obsolet, da KI Code und Vorschläge auf Abruf generiert; der moderne Architekt wird zum **Intelligenzverstärker (IQ Amplifier)**, der Teams mentale Modelle, Geschäftskontext und Entscheidungswerkzeuge bereitstellt, um KI zu nutzen und dabei die Kohärenz des Systems zu gewährleisten. Das Dokument gliedert die Auswirkungen **Stockwerk für Stockwerk des „Architect Elevator"** (Enterprise-/Solution-/Platform-/Software-Architekt) und plädiert für **Domain-Driven Design (DDD)** als wesentliche Absicherung: Die **Ubiquitous Language** dient als Grundlage für *System Prompts* (ein über `.clinerules`/Vorlagen injiziertes Domänenwörterbuch, das Halluzinationen und fachliche Fehlinterpretationen reduziert), und **Bounded Contexts** begrenzen den der KI anvertrauten Geltungsbereich, um die Zuverlässigkeit der Generierung zu maximieren. Fazit: KI ist keine Bedrohung, sondern ein Katalysator, der den Architekten von technischer Routinearbeit entlastet, um Synthese, strategische Vision, Modellierung und die menschliche Verbindung zwischen Technik und Business in den Vordergrund zu stellen. Themenbereich: Softwarearchitektur, Rolle des Architekten, DDD, strukturiertes Prompting, KI-Governance im Unternehmen.
#Softwarearchitekt#Rolle des Architekten#generative KI
Prasanna Sankar (Mitgründer/CTO von Rippling, Gründer von Vorflux) veröffentlicht „The Great Flattening“ — einen Manifest-Essay, der die These vertritt, dass Coding-Modelle **übermenschlich** geworden sind und sich der Engpass von der Code-Produktion hin zur **Kodierung von Urteilsvermögen** in *Agent-Harnesses* verlagert hat. Alles innerhalb der Organisation „kollabiert zum Harness hin“; die eigentliche Arbeit aller wird zum *Self-Profiling*: das implizite Entscheidungswissen aus dem eigenen Kopf zu extrahieren, um es in die Codebase zu kodieren. Gleichzeitiger Launch von Vorflux („Autopilot für Software Engineering“), 15-Mio.-Dollar-Seed-Runde (Y Combinator, Peak XV Partners, Alliance DAO). Der Essay erzielte innerhalb von 24 Stunden über 60.000 Aufrufe auf X.
#Great Flattening#Vorflux#Prasanna Sankar
Prasanna Sankar (Prasanna S, @myprasanna) — co-fondateur et ex-CTO de Rippling ($16B+ valorisation) · fondateur et CEO de Vorflux AI. Article publié sur X (format long-form article) le 14 juillet 2026 · contenu repris comme manifeste Vorflux (vorflux.com/manifesto).
Nachricht von **Linus Torvalds** auf der Mailingliste **linux-media** (Thread "Linking Patchwork with Sashiko?", zu einem LLM-Tool zur Unterstützung von Maintainern), in der der Schöpfer und **oberste Maintainer** des Linux-Kernels **offiziell die Position des Projekts zu KI festlegt**. Als Antwort auf Roman Gushchin, der darauf hinwies, dass eine ablehnende Nachricht eine "sehr generell anti-LLM"-Haltung zum Ausdruck brachte, stimmt Torvalds zu ("Yes") und **weist dann kategorisch zurück, dass dies die Position des Kernels sei** ("And no, that's not the position of the Linux kernel"). Er **setzt sich als oberster Maintainer durch**: **"Linux is not one of those anti-AI projects"**; wer damit ein Problem hat, kann **"do the open source thing: fork it"** — "or just walk away". **Zentrale These**: **"AI is a tool, like the other tools we use, and clearly a useful tool"**; das war vor einem Jahr vielleicht noch nicht "so 'clearly' true", heute steht es aber außer Frage. Er unterscheidet **noch offene** Fragen ("what the AI economy will actually look like in the end") von der Frage, die **entschieden** ist ("is it useful?") — "anybody who doubts that clearly hasn't actually tried it". Er **räumt ein**, dass das Werkzeug **"painful"** sein kann — Belastung für Maintainer, und die Tatsache, dass es "keeps finding embarrassing bugs" —, verweigert aber die Vogel-Strauß-Haltung ("put your head in the sand going 'La La La, I can't hear you'"). **Die richtige Reaktion**: sicherstellen, dass **LLM-Tools Maintainern _helfen_**, statt ihnen Schmerzen zu bereiten. **Bewusst keine Zwangsausübung**: "nobody is forced to use it, but **I will very loudly ignore those who try to prevent others from using it**". Zur Unvollkommenheit: "AI isn't perfect, but hell, anybody who points at its problems had better also point at the mirror" — "**natural intelligence isn't always all that great either**". **Governance-Rahmen**: Das Kernel-Projekt "has always been and will remain about **technology**"; die soziale Dimension von Open Source ist ein "side benefit, not the _point_"; **"this is *NOT* some kind of 'social warrior' project, never has been, never will be"**; "we do open source because it results in **better technology**, not for religious reasons". Programmatischer Schlusssatz: **"we decide based on technical merit first. Not on fear of new tools."** Zu lesen als **doktrinäre Positionserklärung** einer der einflussreichsten Figuren der Software-Welt — ein Echo auf ESRs pro-LLM Gegenzeugnis (eine weitere Säule von Open Source, [[raymond-llm-coding-empowering-2026-07-08]]).
#Linus Torvalds#Linux#Linux-Kernel
Linus Torvalds (torvalds@linuxfoundation.org) — ingénieur logiciel finlando-américain · **créateur et mainteneur suprême du noyau Linux** (depuis 1991) et de **Git** (2005). Employé de la **Linux Foundation**. Figure centrale et notoirement franche de l'open source · dont la parole sur les mailing lists du kernel fait autorité et jurisprudence dans la communauté. S'exprime ici en sa qualité de **top-level maintainer** pour fixer la position officielle du projet vis-à-vis des outils d'IA. Autres participants au thread cités : Roman Gushchin (linux.dev) · Laurent Pinchart · Mauro Carvalho Chehab · Konstantin Ryabitsev (Linux Foundation) · Steven Rostedt · Stephen Finucane · Jason Gunthorpe · entre autres. (Message de mailing list linux-media ; date : 2026-07-14 ; date d'ajout à la veille : 2026-07-17.)
SFEIR-Analyse (aus Sicht des Unternehmens) der allgemeinen Verfügbarkeit von **GPT-5.6** durch OpenAI ab dem 9. Juli 2026 — kein einzelnes Modell, sondern eine **Familie aus drei Stufen**: **Sol** (Flaggschiff für Langzeit-/Cyber-/Wissenschaftsaufgaben, als einziges Modell mit Zugang zu den Modi „max" und „ultra"), **Terra** (ausgewogene Alltagsstufe, ~halber Preis von GPT-5.5) und **Luna** (schnell/wirtschaftlich, für hohes Volumen). Alle drei teilen sich ~**1,05 Mio. Token** Kontext, **128k** Ausgabe-Token und einen Wissensstand vom **16. Februar 2026**. Die strukturbestimmendste Tatsache ist kein Score, sondern ein **aggressives Preisraster** (Sol 5$/30$, Terra 2,50$/15$, Luna 1$/6$ pro Million Token): Sol behält den Preis des vorherigen Flaggschiffs bei und ist dabei leistungsfähiger, was den Vergleich auf das **Verhältnis von Leistungsfähigkeit zu Kosten** verlagert. Zwei Abrechnungsfeinheiten (Cache-Schreibvorgänge werden mit **1,25×** berechnet, ein Aufschlag jenseits von **272k** Token) machen das Raster irreführend, solange nicht gemessen wurde, wie viel Kontext der Agent erneut liest (Lese-/Schreibverhältnis ~**153:1** beim agentischen Coding). Urteil des Ingenieurs, das als neutral beansprucht wird (SFEIR ist sowohl **Google Cloud Premier**-Partner *als auch* **Anthropic**-Partner): **niemand räumt alle Tabellen ab** — GPT-5.6 dominiert Terminal-Bench 2.1 und den Coding Agent Index (zu einem Drittel der Kosten pro Aufgabe), Claude bleibt bei SWE-Bench Pro vorn (~15 Punkte); METR meldete eine rekordverdächtige **Reward-Hacking**-Rate bei Sol. Fazit: „hört auf, den Champion zu suchen, lernt zu routen" — das Modell ist eine Commodity, der dauerhafte Vorteil liegt im **Context/Harness Engineering**.
Engineering-Artikel, veröffentlicht am **12. Juli 2026** von **Scrapfly Engineering**, über einen wenig bekannten Browser-*Fingerprinting*-Kanal: **die letzten Bits einer Gleitkommazahl verraten das Betriebssystem**. **Der Mechanismus**: IEEE 754 legt fest, wie ein `double` gespeichert wird, verlangt aber **nicht**, dass `sin`, `cos`, `tanh` oder `exp` korrekt gerundet werden; jedes System liefert daher eine eigene **libm**, die einen Bruchteil eines ULP gegen Geschwindigkeit eintauscht, mit eigenen Minimax-Koeffizienten, Tabellen und Reduktionskonstanten. Dadurch liefert `Math.tanh(0.8)` **drei unterschiedliche Werte**, je nach glibc (Linux), libsystem_m (macOS) und UCRT (Windows) — „ein einziger tanh-Aufruf mit dem richtigen Eingabewert ist eine Signatur pro Betriebssystem. Wer macOS behauptet, aber Linux-Rechenbits zurückgibt, widerspricht dem eigenen User-Agent.“ **Das Erkennungsmerkmal ist neu und lässt sich genau datieren**: bis **Chrome 147** berechnete V8 `tanh` mit einem eingebetteten **fdlibm**-Port, überall identisch und ohne jedes Leck; der V8-Commit `c1486295ae5` ersetzte ihn durch `std::tanh`, ausgeliefert in V8 14.8.57, also **Chrome 148** — 148, 149 und 150 lecken, 147 und früher nicht. **Drei Oberflächen bündeln die Lecks**: `Math.tanh` (die **einzige** betroffene `Math.*`-Funktion, da V8 alle übrigen einbettet und statisch verlinkt), **sämtliche CSS-Trigonometriefunktionen** (Blink ruft direkt die libm des Hosts auf, nach einer gradbasierten Winkelreduktion, die keinen Code mit `Math.sin` teilt), und **Web Audio** (wo der Kompressor bei skalarer libsystem_m bleibt, während FFT- und Vektorstufen über **Accelerate** laufen). **Vier Fallen** erschweren die Gegenmaßnahme: Nur manche Funktionen lecken — daher **erzeugt das Fälschen der übrigen eine erkennbare Inkonsistenz**; JavaScript und CSS sind getrennte Codepfade; **macOS enthält zwei Mathematikbibliotheken, die voneinander abweichen** (skalar vs. Accelerate, je nach Funktion bei 10 bis 89 % der Eingabewerte: `cos(0)` liefert auf der einen Seite `1.0`, auf der anderen `0.9999999999999999`); und **auch die Architektur leckt** (FMA und die Vorzeichenweitergabe bei NaN unterscheiden sich zwischen ARM und x86). **Die verworfene und die gewählte Gegenmaßnahme**: Rauschen hinzuzufügen scheitert zweifach — der Wert stimmt mit **keinem** realen Betriebssystem überein, und die fehlende Determinismus pro Aufruf ist selbst ein Erkennungsmerkmal. Der einzige Weg ist die **bitgenaue Reproduktion**: die Koeffizienten der Ziel-libm extrahieren, sie **hexadezimal** transkribieren (eine dezimale Transkription würde anders runden), jede fused multiply-add-Operation explizit als `fma()` schreiben und mit `-ffp-contract=off` kompilieren, damit der Compiler keine davon erfindet oder wegoptimiert. **Bemerkenswerter Hinweis**: Der Herausgeber stellt vorab klar, dass „die Beiträge hier mit KI verfasst werden“, während Mechanismen, Zahlen und Code aus eigener Feder stammen.
#Fingerprinting#Browser-Fingerabdruck#Anti-Bot
**Scrapfly Engineering** — équipe d'ingénierie de **Scrapfly** · fournisseur d'infrastructure de collecte web. Le texte annonce sa position d'intérêt sans détour : *« Scrapfly ships a browser that has to match a real one across hundreds of signals · and math is one of the harder ones. »* On lit donc un **attaquant du problème de détection** · qui documente le canal parce qu'il doit le neutraliser.
SFEIR-Analyse (Stimme eines Beratungsunternehmens) zur Markteinführung von **LLMD** am 8. Juli 2026 durch das Pariser Startup **ZML** (gegründet von **Steeve Morin**, ehemaliger VP Engineering bei Zenly): ein Inferenzserver, der LLMs über **fünf Chip-Familien** hinweg ausführt (NVIDIA CUDA, AMD ROCm, Google TPU, Intel oneAPI, Apple Metal) **aus einer einzigen Codebasis**. Strukturierende These: Das Training tritt zugunsten der **Inferenz** in den Hintergrund, wo Kosten pro Token, Latenz und vor allem die **Abhängigkeit vom Silizium** nun entschieden werden. Die Wette von ZML — zusammengefasst im Motto *model to metal* — besteht darin, **das Modell von der Hardware zu entkoppeln** über einen in **Zig + MLIR** geschriebenen Compiler, der ein hermetisches natives Binary erzeugt, ohne Python im Ausführungspfad, bereitgestellt über eine **OpenAI-kompatible API**. Zwei Komponenten, zwei Lizenzen: **ZML** (das Framework, Apache-2.0, >90% Zig) ist Open Source; **LLMD** (der Server) ist es nicht, bei Markteinführung kostenlos. Der Artikel betrachtet das Objekt durch drei Brillen eines Beratungsunternehmens — **Token-FinOps**, **architektonische Freiheit** (Design to Exit), **Souveränität** (aufkommende europäische Chips, Integration in den VSORA-Jotunn8-Prozessor) — und liefert dann ein schonungsloses Urteil: Es handelt sich um eine **Alpha**, die "unter aktiver Beobachtung" zu halten ist, heute noch kein Wechsel.
X-Post von **Eric S. Raymond** (ESR, Autor von *The Cathedral and the Bazaar*, Mitbegründer der Open Source Initiative, ~50 Jahre Programmiererfahrung) — **ein frontales Gegenzeugnis zur Erzählung, dass „LLMs schrottigen Code produzieren und halluzinieren, unbrauchbar zum Programmieren“.** Seine These: Das **passiert ihm fast nie**, und **überhaupt nicht mehr in den letzten zwei Generationen** der von ihm genutzten Modelle („ChatGPT 5.4 und 5.5“ unter **codex**). Das frühere Symptom — ein Modell, das „entgleist“, wenn es sich seinem Kontextlimit nähert — ist verschwunden: codex zeigt jetzt eine **rote Warnung** an, die den Nutzer auffordert, die **Sitzung zu leeren**, statt abzudriften. **Nutzungsumfang**: KI angewandt auf **Feature-Änderungen, Refactoring und Debugging über 63 Projekte** in **C, Go, Rust, Python und Shell**; das Verfassen von Dokumentation; **das Dekompilieren einer DOS-Binärdatei in lesbaren Quellcode**. Eine etablierte **Arbeitsroutine**: Beim Wiederöffnen eines Projekts führt er zunächst die **Regressionstests** aus, startet dann codex und bittet es, den Code zu **auditieren** (Bugs + Verbesserungsvorschläge). Fazit: LLMs sind **„exzellent und enorm empowernd“**; ihre **größte Schwäche** ist der **„architektonische Tunnelblick“** — hervorragend darin, Code nach Spezifikation zu erzeugen, aber manchmal **blind für übergeordnete Muster** — was er als die **Aufgabe seines „Fleischhirns“** ansieht. Der stärkste, kontraintuitive Punkt: LLMs **liegen bei Details und Randfällen NICHT falsch**; er sagt, er sei diesbezüglich **schlechter als sie** (trotz 50 Jahren Erfahrung), denn wenn eine Änderung **fünf Stellen berühren** muss, findet das Modell **zuverlässig alle fünf**, während der Mensch vier korrigiert und **stundenlang debuggt**, bevor er die vergessene fünfte findet. Er stellt daraufhin die **„Herunterschreier“** in Frage: Leben sie in einem **anderen Universum**? Nutzen sie **alte, schwache Modelle**? Gibt es ein **Skill-Problem**, das er nicht sieht, weil seine **Denkgewohnheiten und Kommunikation** gut zu den „Griffen“ dieser Werkzeuge passen? Eine Frage, die er für wichtig hält zu klären, da „**Milliarden von Dollar durch fehlgeleiteten Token-Einsatz verschwendet würden**“. Sein Rezept, „ganz einfach“: **„Denke klar, sag dem Modell präzise, was du willst, und gute Dinge geschehen“** — mit dem Schlusssatz: „Was übersehe ich hier?“ Zu lesen als ein **Pro-LLM-Gegenpunkt einer historischen Figur der Open-Source-Bewegung** in der wiederkehrenden Debatte über die (Ab-)Wertung von Coding-Agenten — anklingend an das „Skill-Problem“ und die Spezifikationsdisziplin (vgl. [[martignole-token-manifesto-2026-07-17]]) und ein Diptychon bildend mit **Linus Torvalds'** doktrinärer Pro-KI-Werkzeug-Haltung im Namen des Linux-Kernels ([[torvalds-llm-outil-kernel-2026-07-14]]).
#Eric S. Raymond#ESR#esrtweet
Eric S. Raymond (ESR, @esrtweet sur X) — développeur · hacker et essayiste américain · **figure historique du mouvement open source**. Né le 4 décembre 1957 à Boston (Massachusetts) ; paralysie cérébrale de naissance · enfance en partie au Venezuela puis en Pennsylvanie. Auteur de l'essai très influent **« The Cathedral and the Bazaar »** (1997, livre 1999) · qui oppose le modèle « cathédrale » (développement centralisé et fermé) au modèle « bazar » (décentralisé et ouvert, à la Linux) ; il a **popularisé le terme « open source »** (contre « free software ») et contribué à convaincre **Netscape** d'ouvrir son code (naissance de Mozilla). **Co-fondateur de l'Open Source Initiative (OSI)** en 1998 · président jusqu'en 2005. A édité le **Jargon File** (*The New Hacker's Dictionary*) · maintenu des projets comme **Fetchmail** · écrit **« The Art of Unix Programming »** (2003). Se revendique **libertarien** · défenseur du port d'armes · ceinture noire de taekwondo ; commente régulièrement tech · politique et open source sur X. Se présente ici comme codeur « très · très bon » avec **~50 ans d'expérience**. (Post X personnel ; date de publication : 2026-07-08 ; date d'ajout à la veille : 2026-07-17.)
Erstklassiger technischer Bericht von **Jarred Sumner**, dem Schöpfer von **Bun** (JS/TS-Runtime, >22 Mio. Downloads/Monat), über die **vollständige Neuschreibung von Bun von Zig nach Rust in 11 Tagen** (3.–14. Mai 2026), angetrieben durch **Claude** — eine außergewöhnliche Fallstudie zu KI-gestützter Softwareentwicklung **im industriellen Maßstab**. Motivation: eine wiederkehrende Klasse von Fehlern (Use-after-free, Double-free, Speicherlecks), die aus der Vermischung von GC-verwaltetem Speicher (JavaScriptCore) und manuellem Speicher (Zig) entsteht; in **sicherem Rust** werden diese Fehler zu **Kompilierfehlern** mit automatischer Bereinigung (`Drop`/RAII) — "eine bessere Feedback-Schleife als ein Style Guide." Unter Zurückweisung des Dogmas, dass "eine Neuschreibung immer eine schlechte Idee ist" (ein Jahr Bugfix-Stillstand für 3 Ingenieure), entscheidet sich Sumner für einen **mechanischen Port** (Architektur beibehalten, minimale Verhaltensänderung), validiert durch die **bestehende Testsuite, geschrieben in TypeScript und daher sprachunabhängig** (60.624 Tests, 1,39 Mio. `expect()`-Assertions, 0 entfernte Tests, 6 Plattformen). Das Setup: **~50 dynamische Workflows** in **Claude Code**, Schleifen aus *Schreiben → 2+ adversarielle Reviewer → Anwenden*, bis zu **64 parallele Claude-Instanzen** (4 Worktrees × 16), mit vorbereitend generierten **PORTING.md** + **LIFETIMES.tsv**. Zahlen: **6.502 Commits** (Spitzenwert 695/h, 58/min, ~1.300 Zeilen/min), finaler Diff **+1.009.272 Zeilen**, ~16.000 Kompilierfehler als Warteschlange behandelt, **5,9 Mrd. ungecachte Input-Tokens + 690 Mio. Output ≈ 165.000 US-Dollar**. Zentrale methodische Hebel: **adversarielles Review** (ein zweiter Claude, separater Kontext, sieht nur den Diff, mit der Aufgabe herauszufinden, warum es falsch ist — erkennt subtile Fehler, die *semantisch* verschieden, aber *syntaktisch* identisch sind) und das Prinzip **"den Prozess reparieren, der den Code erzeugt, nicht den Code von Hand."** Verwendetes Modell: eine Vorabversion von **Claude Fable 5** (Mythos-Klasse). Seit dem Merge: **11 Runden** Sicherheitsreview durch Claude Code, 24/7 coverage-gesteuertes Fuzzing (100 Mrd. Ausführungen → ~15 PRs), **4 % `unsafe`-Code** (78 % davon auf einer einzigen Zeile), **19** behobene bekannte Regressionen. In Produktion: Claude Code v2.1.181, das erste Release auf Bun-in-Rust, **10 % schnellerer Start unter Linux**. Vorab offengelegt: **Bun wurde im Dezember 2025 von Anthropic übernommen**.
#Bun#Jarred Sumner#Zig-zu-Rust-Neuschreibung
Jarred Sumner (créateur de Bun ; travaille chez Anthropic depuis le rachat de Bun en décembre 2025)
Ein Essay von Jean-Paul Paoli (*The Intelligence Fabric*), der die Angst vor KI am Arbeitsplatz verschiebt: Die eigentliche Gefahr ist nicht der **Ersatz** (der Job, der verschwindet), sondern die **stille Auflösung** der Teambindungen, während *alle weiterhin beschäftigt bleiben*. These: Wenn jede:r Mitarbeitende KI zu ihrem/seinem **ersten Vertrauten und Mitarbeiter** macht, lösen sich drei „Fäden" des organisatorischen Gefüges ohne Entlassungen — die **Bindungen zwischen Kolleg:innen** (die Weitergabe stillschweigenden Wissens vom Junior zum Senior wird unterbrochen), die **Bindung zwischen Führungskraft und Mitarbeitendem** (Frühwarnsignale verschwinden, die Führungskraft wird zu „der/dem Letzten, der es erfährt, statt der/dem Ersten") und das **fachliche Urteilsvermögen** (man hört auf, jene auszubilden, die wissen, wie man die Arbeit *tut* und beurteilen können, ob die Maschine sich irrt). Paoli benennt das Phänomen **shadow intimacy** (in Analogie zu *Shadow IT*) und verordnet kein Verbot, sondern ein bewusstes „Neu-Verweben", Faden für Faden. Themenbereich: Management, organisatorischer Wandel, KI am Arbeitsplatz, emotionale Abhängigkeit von Modellen.
X-Thread (illustrierter Thread) von **Thariq Shihipar** (Claude Code Team / Anthropic): ein *Field Guide*, um das Maximum aus **Claude Fable 5** herauszuholen. Zentrale These, entlehnt von Korzybski – *"the map is not the territory"*: die **Karte** = das, was man Claude gibt (Prompts, Skills, Kontext); das **Territorium** = wo die Arbeit stattfindet (Codebase, reale Einschränkungen); die Lücke zwischen beiden = die **Unknowns**. Fable ist *"the first model where the quality of the work is bottlenecked by my ability to clarify its unknowns"*. Der Artikel liefert ein **4-Quadranten-Framework** (known knowns / known unknowns / unknown knowns / unknown unknowns) sowie ein **Toolkit von Techniken**, zeitlich geordnet (vor / während / nach der Implementierung) – Blindspot Pass, Brainstorms & Prototypen, Interviews, Referenzen, Implementierungsplan, Implementation-Notes, Pitches & Explainer, Quizzes – jeweils mit Beispiel-Prompts. Themengebiet: Prompt Engineering, Coding Agents, Methodik der Zusammenarbeit mit KI, HTML-Artefakte.
Kurze Notiz von Simon Willison (Weblog), die zwei Tipps wiedergibt, die während eines *Fireside Chat* bei AIE mit Cat Wu und Thariq Shihipar (Claude Code Team) zu hören waren: **das Modell (Fable, und in gewissem Maße Opus) sein eigenes Urteilsvermögen ausüben lassen, statt ihm Regeln zu diktieren** — veranschaulicht anhand der Entscheidung, ob Tests geschrieben werden sollen. Zweiter Tipp, von Jesse Vincent: um **wertvolle Fable-Tokens zu sparen** (angesichts einer bevorstehenden Preiserhöhung), Fable bitten, **kleine Aufgaben an weniger leistungsfähige Modelle zu delegieren**, wobei es selbst beurteilt, welches geeignet ist. Willison zeigt den genauen verwendeten Prompt (« *use your judgement to decide an appropriate lower power model and run that in a subagent* ») sowie die **Memory-Datei**, die Claude Code daraufhin schrieb. Bereich: Prompt Engineering, Coding Agents, Token-Ökonomie, Multi-Modell-Orchestrierung.
#Modellurteilsvermögen#Delegation an Subagents#Model Override
Agent-Guide (Thinkroom, die Plattform von Kieran Klaassen), der den **Compounding Knowledge Lifecycle** des compound-engineering-plugin (Every) dokumentiert: wie eine einmal gelernte Lektion sich „weiter auszahlt" — erfasst, gespeichert, abgerufen und auf Richtigkeit gehalten. Beschreibt die Anatomie eines *Learning* (`docs/solutions/`), dessen Erfassung über `/ce-compound`, die Gedächtniskarte (dauerhaft vs. flüchtig), den *grep-first*-Abruf (learnings-researcher), der an 5 Skills in Entscheidungspunkte eingebunden ist, sowie die drei Gegenkräfte, die das Gedächtnis davon abhalten, zu lügen. Direkt relevant: Es ist die Doktrin hinter der `docs/solutions/`-Konvention dieses Repos. Bereich: Compound Engineering, agentisches Wissensmanagement, Skills.
**Wiederkehrender Bericht von Mozilla**, *The state of open source AI*, **v1.0.1, Juli 2026**, eingeleitet durch einen Brief von **Raffi Krikorian** (CTO): sieben Abschnitte, eine interaktive Website und ein herunterladbarer Bericht. These, formuliert im Titel von Abschnitt 1: *« The model layer has commoditized. Value accrues to the harness above it. »* **Fähigkeitsstand**: Auf dem *Artificial Analysis Intelligence Index v4.1* erzielt das beste geschlossene Modell **61** Punkte (Claude Opus 5) und das beste offene Modell **57** (**Kimi K3**), Rang vier insgesamt und vor drei der größten geschlossenen Labore; auf dem *Epoch Capabilities Index* beträgt der Abstand **6 Punkte** (K3 bei 156 gegenüber GPT-5.6 Sol bei 162), beschrieben als *« about one release cycle »*, bei sich überlappenden Konfidenzintervallen. **Sägezahnförmige Frontier**: Offene Modelle führen bei Frontend-Code (K3 mit 1.679 Elo in der LMArena Frontend Code Arena, sechs von sieben Domänen), liefern sich ein Kopf-an-Kopf-Rennen bei agentischer Terminalarbeit (88,3 gegenüber 88,8 im Terminal-Bench 2.1) und geben bei professioneller Wissensarbeit Boden ab (Fable 5 führt vor K3 mit 92 Elo im GDPval-AA v2). **Nutzungsverschiebung**: Der Anteil der über OpenRouter geleiteten Tokens, die an Open-Weight-Modelle gehen, stieg von einem vernachlässigbaren Niveau auf ein Drittel Ende 2025 und dann auf eine **Mehrheit bis Mitte 2026**, wobei die sieben Modelle mit dem höchsten Volumen alle offen gewichtet sind — der Bericht selbst merkt an, dass *« by request count, closed US providers still lead »*, wobei der Vorsprung der offenen Modelle ein Vorsprung beim Token-Volumen ist, der sich auf Coding- und agentische Workloads konzentriert. **Der zentrale Gegensatz**: *« Open ships easy. Open deploys hard. »* — 79 % der Entwickler, die KI einführen, nutzen offene Modelle gegenüber 71 % bei geschlossenen, aber nur **53 %** der Teams mit offenen Modellen erreichen die Produktion **gegenüber 63 %**, und die Lücke wächst mit der Organisationsgröße (geschlossen 54 % → 73 %, offen 53 % → 57 %), was *« rules out a resources explanation »*. Die Reifegradkarte des Stacks (48 Komponenten, 9 Schichten) zeigt zwei durchgängig kalte Spalten — **Standardisierung** und ***Enterprise Readiness*** — identifiziert als die operative Lücke. **Abschnitt 5**: *« The agentic harness is another user agent »*, und *« The model is eating the harness »* — bei jedem Modell, für das beide Varianten existieren, gewinnt inzwischen der Harness des jeweiligen Labors selbst, wobei sich die Lücke von 21,8 Punkten auf etwa 3 verringert hat. Daher die Formel: *« A harness tuned tightly to one lab's weights… degrades on anyone else's model, so the tighter the tuning, the less swappable the weights underneath. Lock-in arrives as a side effect of optimization. »*
#Mozilla#state of open source AI#Open Weights
**Mozilla** — éditeur du rapport · avec une introduction signée **Raffi Krikorian** · *Chief Technology Officer*. Publié en **juillet 2026** (v1.0.1). Données issues de sources tierces créditées (Artificial Analysis, Epoch AI, OpenRouter, LMArena) et d'une enquête propre menée avec **SlashData** (*Mozilla / SlashData 2026 developer survey*, n = 1 410 sur la question des freins).
Analysenotiz **Trésor-Éco n° 391** (Juni 2026) der **Direction générale du Trésor** (Wirtschaftsministerium), verfasst von **Martin Chopard, Elisa Cotet, Tristan Gantois und Eloïse Villani**. Institutioneller Literaturüberblick zur Wirtschaftsforschung über **die Auswirkung der KI (vor allem generativer KI) auf die Beschäftigung**. **Dreiteilige These**: (1) KI wirkt sich über **zwei gegenläufige Kanäle** auf das Beschäftigungsvolumen aus — den **Verdrängungseffekt** (Substitution automatisierbarer Aufgaben) gegenüber dem **Produktivitätseffekt** (Komplementarität, niedrigere Kosten, gestiegene Nachfrage) — doch der **Gesamteffekt bleibt vorerst schwach/nicht messbar**, mangels zeitlichem Abstand und Verbreitung (≈20 % der EU-Unternehmen im Jahr 2025); (2) **heterogene Effekte** zeigen sich je nach **Berufen** (Exposition ≠ Effekt: alles hängt vom Grad der Substituierbarkeit/Komplementarität und der **Preiselastizität** der Nachfrage ab), **Arbeitskräften** (verzerrter technischer Fortschritt, Sorgen bezüglich **junger Menschen**) und **Sektoren** (Finanzwesen, IT, Unternehmensdienstleistungen am stärksten exponiert); (3) **langfristig bleibt der Nettoeffekt ungewiss** — zwischen massiver Substitution (falls sich agentische/physische KI durchsetzt) und **schöpferischer Zerstörung** (Lehre vergangener Revolutionen: Innovationen haben mehr Arbeitsplätze geschaffen als vernichtet). Schlussfolgerung zur **öffentlichen Politik**: den Übergang unterstützen (Ausbildung, Mobilität — der Plan „Osez l'IA“, France 2030) und **in KI investieren, um im internationalen Wettbewerb nicht zurückzufallen**. Umfangreich belegter Korpus (43 Fußnoten, Schätzpanels in den Tabellen 1-3).
#KI und Beschäftigung#generative Künstliche Intelligenz#Verdrängungseffekt
**Martin Chopard · Elisa Cotet · Tristan Gantois · Eloïse Villani** — économistes de la **Direction générale du Trésor** (DG Trésor) · Ministère de l'Économie · des Finances et de la Souveraineté industrielle · énergétique et numérique. Directrice de la publication : Dorothée Rouzet. Le document engage la DG Trésor mais « ne reflète pas nécessairement la position du ministère ».
Dritter Teil von Ashish Singhs Reihe «New Engineering Disciplines for the AI Era», gewidmet dem **KDLC — Knowledge Development Life Cycle**: einem **8-stufigen** Lebenszyklus, der Unternehmenswissen in ein **konstruiertes Gut** verwandelt, gleichrangig mit Code oder Daten. These: KI-Initiativen scheitern nicht an der Wahl des richtigen LLM oder an einem eingesetzten RAG-System, sondern weil sie **die zugrunde liegende Struktur des Wissens nicht adressieren** — „KI ist nur so wirksam wie das Wissen, das sie entdecken, verstehen, abrufen und dem sie vertrauen kann". Der KDLC verkettet Discovery → Extraction → Structuring → Knowledge Graph → Embedding → Index Optimization → Retrieval Evaluation → Refresh. Er stellt dem **traditionellen RAG** (isolierte Dokumente, Schlüsselwörter) das **Enterprise Knowledge Fabric** (Knowledge Graphs + Semantic Search + Vector DB + Hybrid Search) gegenüber, bei dem Agenten „Beziehungen, Kontext und geschäftliche Bedeutung" verstehen. Kernsatz: „Modelle liefern Reasoning. Memory liefert Kontinuität. Wissen liefert Verständnis." Drei Beispiele (Finanzen/Compliance, Softwareentwicklung, Gesundheitswesen) veranschaulichen die Wirkung.
#KDLC#Knowledge Development Life Cycle#Wissenslebenszyklus