X-Post von **Andrew Ng** vom **14. August 2026** (16:29 UTC), Wiederaufnahme des "Dear friends"-Briefs aus ***The Batch* #366** (DeepLearning.AI, gleiches Datum), ca. 900 Wörter. Ng stellt **The AI Engineering Skills Map** vor und veröffentlicht **vier Skills**, die als die wichtigsten gelten. **(1) Aufbau und Bereitstellung von KI-Anwendungen** — die Besonderheit wird benannt: *« The key difference between AI and non-AI applications is that the former has unpredictable outputs »*, daher die Betonung von *evals* und Fehleranalyse-Loops. **(2) Grundlagen der Softwareentwicklung**, denn *« Understanding software fundamentals allows you to recognize what tradeoffs even exist »* — der unerfahrene Entwickler scheitert *« because they don't know what context to give their coding agent »*, daher das Ziel, *« steering coding agents using the precise language of software engineering »*. **(3) Einsatz von Coding-Agenten**, in operativer Formulierung: *« help the agent autonomously close loops by providing verifiers or evals »*, sowie *« knowing how much to intervene and how much to leave them alone »*. **(4) *Den Build gestalten***: *« Given a clear spec, coding agents are rapidly improving at delivering to it. Thus, our work as engineers is shifting toward deciding what should be in the spec »*, ergänzt durch *« Engineers should no longer expect to be given a pixel-perfect design and asked only to implement it. »* Ein **Hinweis zur Terminologie** trägt den größten Teil der Rahmung: Ng spricht von **Skills** im AI Engineering und **nicht von der Rolle** "AI Engineer", mit einer expliziten Analogie — *« All developers today should know how to work with the cloud, and only a smaller number have a "Cloud engineer" title. »* Das Ganze stützt sich auf *« an analysis of more than 10,000 job postings, dozens of structured interviews with experts, hiring managers, and recruiters, surveys, and other online data »*, wovon **keine numerischen Ergebnisse veröffentlicht werden**: Ng beschreibt sein Vorgehen als *« informally… akin to running clustering »* und kündigt eine detaillierte Map in künftigen Beiträgen an. Sein Eigeninteresse benennt er im vorletzten Satz: *« DeepLearning.AI's principal focus is to help developers gain these AI engineering skills. »*
#AI Engineering Skills Map#Skills-Map#Andrew Ng
**Andrew Ng** — fondateur de **DeepLearning.AI** · general partner d'**AI Fund** · cofondateur de **Coursera** et de **Google Brain** · ancien chief scientist de Baidu. Texte signé · à la première personne · écrit *« with my team »* sans qu'aucun collaborateur soit nommé. Publié le **14 août 2026** sur X et dans ***The Batch* n°366** — même texte aux deux endroits ; préférer *The Batch* pour toute citation durable. Quatrième fiche Ng du corpus · après les lettres n°350 (24 avril) · n°352 (8 mai) et n°359 (26 juin).
Branchenmeldung (**Payments Dive**, Format *Dive Brief*, **6. August 2026**) zur Quartalsbilanz von **Block**: Das Unternehmen hat seinen Kunden bereits mehrere KI-Tools zur Verfügung gestellt — **Moneybot** (Cash App) und **Managerbot** (Square) — und hat noch nicht entschieden, wie es dafür abrechnen will. **Jack Dorsey** im Analystencall: *„We're in a fortunate position where we can experiment with a number of models, and then choose the right one that's going to align all of our incentives with our customers.“* **Der finanzielle Hintergrund erhellt diese Haltung.** Sechs Monate zuvor hatte Block rund **4.000 Personen entlassen, etwa 40 % der Belegschaft**, im Rahmen einer Umstrukturierung, die ausdrücklich mit KI begründet wurde. Im Q2 2026: Bruttogewinn **+25 % auf 3,2 Mrd. USD**, Umsatz **+10 % auf 6,62 Mrd. USD**, aber **Nettogewinn bei 89 Mio. USD, −83 %** im Jahresvergleich, bedingt durch Abfindungskosten zum Abschluss der Restrukturierung; die Prognose für 2026 wurde angehoben. Der Wert der KI wird demnach zunächst über die Kostenstruktur erschlossen, bevor er über den Preis erschlossen wird. **Die gewichtigste Aussage steckt in der Mitte der Meldung**, entnommen dem Aktionärsbrief: *„Starting in June, agentic AI helped write and review nearly all of our production code changes“* — das Schreiben **und** Überprüfen nahezu aller Produktionscode-Änderungen, bei einem börsennotierten Zahlungsunternehmen, sechs Monate nach dem Abbau von 40 % der Belegschaft. Eine selbstberichtete Aussage gegenüber Investoren, ohne Definition von *„nearly all“* oder dessen, was *„review“* umfasst. **Die Tools**: **Goose**, ein zwei Jahre zuvor aufgebautes internes System, beschrieben als modellagnostisch (es bindet für Mitarbeitende verschiedene kommerzielle Modelle ein); **Buzz**, im Vormonat gestartet für *„agent collaboration, communication, and code repositories.“* **Auf Kundenseite**: Moneybot überwacht die Nutzeraktivität in Cash App und zeigt Konten, Salden und Transaktionen an — über **eine Million wöchentlich aktive Konten**; Managerbot übernimmt automatisiertes Marketing, Margenanalyse und schlägt Square-Händlern *„operational fixes“* vor. Analysten von **Evercore ISI** listen vier Monetarisierungswege auf — SaaS-Pakete, Direktabonnements, Unternehmensangebote, nutzungsbasierte Preisgestaltung — **keiner davon an Ergebnisse gekoppelt**. Genannte Prioritätsreihenfolge: **Produktqualität → Distribution → Adoption → Preismodell**. Zwei Fakten zur Distribution runden das Bild ab: Square wird in **Google Maps** integriert, mit einem *„conversational AI experience,“* beschrieben als *„the first step in a broader partnership between Square and Google“*; und das Zahlungsgerät **Tags** (Schlüsselanhänger und NFC-Chip-Sticks) verzeichnet **drei Millionen Personen auf der Warteliste**. Analystenzitate: William Blair (*„Block epitomizes the secular shift toward tech-forward digital finance firms“*) und Bank of America zum *„post-reset operating model.“*
#Block#Jack Dorsey#Cash App
**Justin Bachman** — Senior Reporter · **Payments Dive** (groupe Industry Dive). Journaliste sectoriel paiements ; signe ici un **Dive Brief** · format court en deux temps (*Dive Brief* = les faits du jour, *Dive Insight* = le contexte) qui compile une conférence de résultats · une lettre aux actionnaires · un communiqué et trois notes d'analystes.
Dokumentationsseite zu **Notion as Code**, veröffentlicht im **Notion Ambassadors**-Workspace und abgerufen am **3. August 2026**. Produkt im **Closed-Alpha-/Warteliste**-Status, mit einem Warnhinweis vorab: *« This product is under development so we recommend you try it out in a new workspace vs. your primary workspace »* und *« There may be breaking changes until we're fully launched »*. **Das Prinzip ist Infrastructure as Code, angewandt auf einen dokumentarischen Workspace**: *« Instead of having to make individual public API requests, you can describe the final state and we handle updating your workspace to match. »* Zwei Bausteine: ein **TypeScript SDK** zur Beschreibung des gewünschten Zustands und ein öffentlicher API-Endpunkt `/v1/infra_as_code` zu dessen Bereitstellung. **Der Mechanismus, der alles zusammenhält, ist der Ressourcenbezeichner**: Das Skript enthält **überhaupt keine Notion-ID**, sondern nur vom Autor gewählte *resource IDs*; das erste Deployment liefert eine **Zuordnungstabelle** `resourceId → RecordPointer` zurück, die bei nachfolgenden Aufrufen wieder übergeben wird, sodass dieselben Datensätze **aktualisiert statt neu erstellt** werden. Daraus folgen drei Eigenschaften, und sie sind die einzigen, die zählen: Das Skript ist **idempotent** (erneutes Deployment = Aktualisierung), es ist **vom Workspace entkoppelt** (mehrere Zuordnungstabellen erlauben das Deployment **desselben Skripts auf mehrere Workspaces**), und es ist Code — daher Variablen und Schleifen, wobei als Beispiel genannt wird, *« build 10 teams that all have a very similar structure and just need some nouns renamed »*. **Die API ist asynchron**: `POST /v1/infra_as_code` liefert eine `taskId` zurück, die über `GET /v1/async_tasks/{taskId}` abgefragt wird, bis der Status `succeeded` erreicht ist. **Zwei bemerkenswerte betriebliche Unterschiede**: Das Produkt erfordert **persönliche Zugriffstoken** anstelle der üblichen Bot-Token der öffentlichen API, und das **Rate Limit ist auf 5 Anfragen pro Minute gesenkt**, da ein einzelner Aufruf nicht mehr eine einzelne Entität, sondern einen Batch erzeugt. **Für dieses Korpus festzuhalten**: Die Seite ist explizit für den assistierten Einsatz geschrieben — *« A typescript SDK for you **or your coding agent** to describe what you want »* —, und der empfohlene Einstiegsweg besteht darin, das SDK auf einem experimentellen Branch zu klonen und *« either you or your favorite coding agent »* die README öffnen zu lassen. **Genannte Einschränkungen**: kein Erstellen eines neuen Workspace möglich, nur teilweise Abdeckung der Primitiven, sowie eine Seite ohne Autor- oder Datumsangabe.
#Notion as Code#Infrastructure as Code#IaC
**Notion** — documentation produit publiée sur l'espace public **Notion Ambassadors**. **Aucun auteur nommé · aucune date de publication** sur la page : la fiche est datée de son **observation** (3 août 2026). Le produit est en **alpha fermée** — l'accès passe par un formulaire d'inscription · et le texte précise que l'on peut commencer à écrire ses scripts avant d'être accepté.
**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)
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.)
Brief „Dear friends“ von Andrew Ng in *The Batch* (DeepLearning.AI, Ausgabe 359) über **loop engineering**, angewendet auf die **0-to-1**-Produktentwicklung. Ng stellt seine **3 zentralen Loops** vor — agentic coding loop (~Minuten), developer feedback loop (~Stunden), external feedback loop (~Tage) — verschachtelt nach zunehmender Zeitskala, verbunden über *coding agent → product spec/evals → developer vision → external feedback*. Zentrale These: Menschen behalten einen **context advantage** (statt eines „taste“), der human-in-the-loop unverzichtbar macht; Ingenieure übernehmen eine partielle Rolle im Produktmanagement. Themenfeld: coding agents, Produktentwicklung, agentische Methodik.
LinkedIn-Post von Fred Plais (CEO von Archie, ex-Platform.sh): KI hat Engineers so schnell gemacht, dass sich der **Engpass stromaufwärts verschoben** hat, an eine Stelle, die niemand im Blick hat. Da die Ausführung nicht mehr der langsame Teil ist, ist die Denkzeit verschwunden, die früher "während der Code gebaut wurde" existierte — die richtige Vision muss jetzt in einem Bruchteil der Zeit geformt und die richtigen Entscheidungen getroffen werden. Zwei seltene Profile entstehen: dasjenige, das eine **Vision präzise genug artikulieren kann**, damit ein Agent sie ausführt, ohne zu entgleisen, und dasjenige, das weiß, wie man **Agenten orchestriert** (ihre Fehler antizipiert, sie verkettet, einen Fehler abfängt, bevor er sich fortpflanzt). Für "Code-Output" einzustellen wird obsolet: das ist genau das, was aufgehört hat, selten zu sein. Kernthese: "klar zu denken war schon immer der Job — Geschwindigkeit hat es nur unmöglich gemacht, das vorzutäuschen".
Ein arXiv-Paper (cs.SE) von Martin Monperrus, das für den SDLC eine radikale These vertritt: Coding-Agenten haben eine Fähigkeitsschwelle überschritten, sodass menschliches Code-Review keine notwendige Komponente einer Qualitätspipeline mehr ist. Zwei Thesen: (1) autonome LLM-basierte Systeme erreichen alle Ziele des Reviews (Fehlererkennung, Qualität, Compliance) bei geringeren Kosten und höherem Durchsatz; (2) das hybride Modell „der Agent schreibt, der Mensch reviewt“ ist nicht haltbar — es gewährleistet weder echte Qualität noch skaliert es mit der KI-Geschwindigkeit und erzeugt ein „trügerisches Sicherheitsgefühl“. Monperrus stellt der inspection de Fagan (1976) eine multi-agentenbasierte adversarial verification pipeline gegenüber (Generator-Agent + unabhängige Reviewer-Agenten + Tests/formale Methoden + abstimmungsbasierter Konsens). Der Mensch konzentriert sich auf die Spezifikation, architektonische Trade-offs, die Freigabe kritischer Domänen sowie Grenzfälle. Empfehlungen: zunächst Pilotierung an risikoarmen Komponenten, Messung Agent vs. Mensch, explizite Ablehnungsentscheidungen.
Produktankündigung von Stack Overflow (offizieller Blog) zur Einführung von **Stack Overflow for Agents**, einer *API-first*-Plattform für Wissensaustausch, konzipiert für das agentische Zeitalter. Kernthese: Coding-Agenten arbeiten **isoliert**, ohne Zugang zu einer gemeinsamen, verifizierten Wissensbasis. Daraus resultiert die **„Ephemeral Intelligence Gap“** — Agenten lösen weltweit unabhängig voneinander dieselben Probleme, verschwenden dabei Tokens und Rechenleistung und verlieren die Lösung am Ende der Session; dieselben Architekturmuster werden in einer Schleife immer wieder neu entdeckt. Leitprinzip: *„plausible Antworten zu generieren ist billig geworden, aber zu verifizieren, welche davon in der Produktion Bestand haben, nicht.“* Vierstufiger Workflow: **zuerst suchen** (validiertes Wissen nutzen) → **beitragen, wenn eine Lücke besteht** (der Agent entwirft, der Mensch genehmigt vor der Veröffentlichung) → **verifizieren** (Ergebnisse, Anpassungen, Kontextbedingungen) → **Signale kumulieren** (Stimmen, Antworten, Verifizierungen erzeugen einen Konsens). Drei maschinenlesbare Formate: **Questions**, **TIL** (Debug-Spuren), **Blueprint** (wiederverwendbare Muster, höchster Qualitätsanspruch). Vertrauen beruht auf **Community-Moderation** und **Multi-Agenten-Verifizierungsschleifen**; Menschen beanspruchen die Eigentümerschaft ihres Agenten über Stack Overflow SSO (einen „Community-Anker“, der den Agenten an eine menschliche Reputation bindet). Differenzierte Vorteile: Entwickler (weniger Retry-Schleifen), KI-Labore (hochwertige Daten für Fine-Tuning/Evaluation), Unternehmen (**Stack Internal**, eine proprietäre Wissensebene ohne Datenabfluss).
#Stack Overflow for Agents#Coding-Agenten#Wissensbasis
Fundierter technischer Leitfaden (Blog der Agentur Lushbinary) zum **Loop Engineering**: Gestaltung der Systeme, die Coding-Agenten in einer Schleife steuern, statt sie manuell zu prompten. Behandelt die Genealogie Prompt → Context → Loop Engineering, die Ralph-Technik (Geoffrey Huntley), die **fünf Bausteine + Memory** einer Loop, ihre Umsetzung in Claude Code und OpenAI Codex, das Schreiben überprüfbarer Abbruchbedingungen, eine Reifegradskala für die Einführung sowie die Risiken, die mit zunehmender Ausgereiftheit der Loops zunehmen. Bereich: agentisches Software-Engineering, Coding-Agenten, Harness/Orchestrierung.
Leitfaden von Augment Code (Paula Hingel), der beschreibt, wie KI-Agenten den Software Development Lifecycle (SDLC) Stufe für Stufe umstrukturieren. These: KI erzeugt **in manchen Phasen höheren Durchsatz und in anderen ein höheres Instabilitätsrisiko** — ein Symptom ungleichmäßiger Adoption ohne Neuziehung der Review-Grenzen. Stützt sich auf **DORA 2025**: KI-Adoption korreliert positiv mit Delivery-Durchsatz und Produktperformance, aber **negativ mit Stabilität**. Sechs neu betrachtete Phasen (Requirements, Design/Architektur, Implementierung, Testing/QA, Deployment, Maintenance), drei zentrale Risiken (Erosion der Junior-Pipeline, **zirkuläre Validierung** von KI-generierten Tests, Governance-Lücken bei Skalierung) und drei entstehende Rollen (**Intent Engineering**, Agentic DevOps, AI Governance/Assurance). Umsetzbare Empfehlungen: eine Phase vor der Skalierung auditieren, Governance einem Stresstest unterziehen, die **Spezifikation** ins Zentrum stellen, explizite Rollback-Richtlinien definieren, die Junior-Rolle rund um Review neu gestalten.
#SDLC#Software Development Lifecycle#Coding Agents
Atlassian-Datenstudie (Inside Atlassian), die den tatsächlichen Ertrag eines **AI-native SDLC** misst, der von **Rovo Dev** angetrieben wird. Bei 3.400 Repositories von 2.500 Kunden (ein Quasi-Experiment mit Propensity-Score-Matching) mergen adoptierende Repositories **19 % mehr PRs pro Monat**; bis zu **37–51 %** bei Repositories mit geringer/mittlerer Aktivität und **59–87 %**, wenn **3 bis 5 Mitglieder** des Teams das Tool nutzen. Auf der Effizienzseite sparen Entwickler **2–3 Std./Woche** (≈10 % der 24 Stunden, die für Coding und Review aufgewendet werden), d. h. 20–30 Stunden/Woche, die bei einem Team von 10 reinvestiert werden. Die These: Solows (1987) „Produktivitätsparadox“ auflösen, indem man von **Nutzungsmetriken** (Tokens) zu **Wirkungsmetriken** (Durchsatz, eingesparte Zeit, Fehlerquote, Zufriedenheit) übergeht. Empfehlung: mit einem **Team** (nicht einer Einzelperson) beginnen und 2–3 Monate später messen.
Überarbeitung des technischen Einstellungsprozesses bei Sierra im Zeitalter der Coding-Agenten: KI-natives Onsite-Interview (Plan/Build/Review), Abschaffung des algorithmischen Coding-Tests, Ersatz des Telefon-Screenings durch ein System-Design-Interview, Pilotprojekt eines Debugging-Interviews an einer bestehenden Codebasis.
Rolle des Entwicklers angesichts von KI-Coding-Agenten, eintägiges Experiment mit der BMAD-Methode, Entwicklung hin zum Agent Supervisor - Technischer Blog