Strategic frameworks and doctrines for the AI transition.
29 fiches · 99 entities · Updated
Navigating the AI transition in software has produced a wave of frameworks and doctrines, and this collection assembles them. Maturity models, mapping methods, operating principles, named methodologies: structured ways of deciding where to invest, what to automate, and how to sequence change. The value on offer is transferable mental models rather than particular tools — how to reason about the move from human to agentic lifecycles, how to weigh building against buying under fast-shifting capability, how to organize teams around agents. Several entries put forward their own lifecycles and maturity ladders for the agentic shift. Each fiche records a framework advanced in the field and the reasoning that underpins it.
90% AI adoption rate
Dropbox · stated in source
"about 80% of the code merged into the base is written by Claude"
Jason Clinton · stated in source
43,5% of occupation-specific messages fall outside the user's occupation
Work at the Frontier · stated in source
20% increase in merged PRs
Dropbox · stated in source
Post by **Ethan Mollick** published on **August 31, 2026** on *One Useful Thing* (~2,200 words). He starts from a security incident to raise an organizational question: when should an AI ask a human for help?
Ethan Mollick — professeur à la Wharton School (University of Pennsylvania) · auteur du blog *One Useful Thing* sur Substack.
Essay by **Bill Staples**, CEO of **GitLab**, published on **August 24, 2026** on the about.gitlab.com blog: an announced **31-minute** read, roughly **39,000 characters**, presented as the sequel to a memo written to the board of directors in January 2026 and partially published in May under the title *GitLab Act 2*. The text presents itself as a response to **Anthropic**'s AI-native SDLC playbook, published three days earlier, from which it borrows the opening line — "Code is no longer the bottleneck" — to pose the question that drives it: what becomes scarce when code becomes abundant. (A) The economic diagnosis: the useful unit is not cost per line but **cost per accepted change**, which aggregates generation, environment, context, verification, review, remediation, and governance; AI collapses the generation term alone, which makes the others proportionally heavier — an organization ten times faster at generating "will simply move the queue." (B) The architectural response: four capabilities — agent platform, machine-scale execution, durable context, governance — forming an enterprise layer that outlives the model, "The model should be replaceable. The agent should belong to the customer." (1) Three modes coexist durably, from human-driven legacy to autonomous development, against the idea of a single maturity curve. (2) The CI/CD pipeline becomes the place where the inner loop runs, instead of being an end-of-line gate. The figures cited are Stripe's, Spotify's, and Amplitude's; GitLab produces only one, about its own source control. The corpus already holds [[claxton-anthropic-ai-native-sdlc-playbook-2026-08-21]], the source this text responds to, and [[sfeir-sdlc-pdlc-articulation-2026-07-22]] on the SDLC/PDLC articulation that Staples adopts as his own.
Bill Staples · directeur général de GitLab (fonction non affichée par la page) · sur le blog about.gitlab.com.
Long-form guide from **Anthropic** by **Louis Claxton** (Applied AI team), published on **August 21, 2026** on the claude.com blog: a stated **40-minute** read, roughly **64,000 characters**, presented as a collection of *plays* drawn from the team's work with its clients. (A) The diagnosis: with code no longer the bottleneck, it shifts to the stages on either side of the build (plan, review/test, deploy), line-by-line controls stop holding once the agent writes most of the diff, and governance cost rises as exceptions still route through periodic committees. (B) The response: six stages (Plan, Design, Build, Test, Deploy, Maintain) organized as a **loop** rather than a chain, each ending with a **committed artifact** that the next stage reads — `intent.md`, `spec.md`, `plan.md`, the diff and its tests, the PR and its findings, the incident record. (1) Institutional knowledge becomes versioned files: `CLAUDE.md`, skills, `REVIEW.md`, `bands.yaml`. (2) Governance splits into two layers, with the skill positioned as an advisory control and the hook as the deterministic layer behind it. Separation of duties is set as an invariant — the agent that writes the code cannot approve it — and the piece closes on *"The loop keeps running. Human judgement stays above it."* The corpus already holds [[clinton-anthropic-secure-ai-native-sdlc-2026-07-21]] on the security side of the same cycle, and [[hingel-augment-how-ai-changes-sdlc-six-stages-2026-06-08]] on the same six-stage breakdown as seen by a competitor.
Louis Claxton (Anthropic, équipe Applied AI) · sur le blog claude.com ; contributions créditées à Jim Blackhurst · Will Steuk et Jamal Arif.
Guide signed by **Michael Segner**, published on **August 20, 2026** on the claude.com blog in the *Claude Code* category: a **5-minute** read announced for approximately **31,500 characters** of body text, also offered as a PDF. Stated material: interviews with **more than a dozen** startups, fifteen named — **Artemis Security**, **Cainex**, **Clay**, **ClickHouse**, **Cognition**, **Commure**, **Crosby**, **Emergent**, **Harvey**, **Heidi**, **Higgsfield**, **Omni**, **Parahelp**, **Translucent**, **Zingage**. (A) Five operating rules: *everyone ships*, *automate the tedium*, *trust, but verify*, *build for rebuilding*, *prototype, dogfood, productionize*, each closed with product tips and gathered into a final checklist. (B) A body made of attributed quotes, each rule illustrated by named executives rather than by an aggregated metric. The four figures highlighted are those of the interviewed companies: **+30%** more features shipped (ClickHouse), **2 to 3×** engineering productivity (Omni), **100%** of bug triage automated (Clay), **more than 6,000 PRs per week** (Artemis Security). Two passages depart from the testimonial register: **Cainex**'s self-correction loop on medical coding, described step by step, and the internal use of **Claude Tag** at **Anthropic** as first responder for CI/CD on-call. The question posed at the opening — *"what would it look like if an organization built their product development lifecycle with Claude Code from the ground up?"* — connects with [[claxton-anthropic-ai-native-sdlc-playbook-2026-08-21]], published the next day by the same publisher, and extends [[cherny-wu-reflecting-year-claude-code-2026-07-17]].
Michael Segner · auteur du guide sur le blog claude.com (fonction non affichée par la page) ; entretiens avec les dirigeants de quinze entreprises nommées.
X post by **Andrew Ng** from **August 14, 2026** (16:29 UTC), reprising the "Dear friends" letter from ***The Batch* #366** (DeepLearning.AI, same date), ~900 words. Ng presents **The AI Engineering Skills Map** and publishes **four skills** held to be the most important. **(1) Building and deploying AI applications** — the specificity is named: *« The key difference between AI and non-AI applications is that the former has unpredictable outputs »*, hence the emphasis on *evals* and error-analysis loops. **(2) Software engineering fundamentals**, because *« Understanding software fundamentals allows you to recognize what tradeoffs even exist »* — the inexperienced developer fails *« because they don't know what context to give their coding agent »*, hence the goal of *« steering coding agents using the precise language of software engineering »*. **(3) Using coding agents**, in an operational formulation: *« help the agent autonomously close loops by providing verifiers or evals »*, and *« knowing how much to intervene and how much to leave them alone »*. **(4) *Shaping the build***: *« 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 »*, paired with *« Engineers should no longer expect to be given a pixel-perfect design and asked only to implement it. »* A **terminology note** carries most of the framing: Ng talks about **skills** in AI engineering and **not the role** "AI Engineer", with an explicit analogy — *« All developers today should know how to work with the cloud, and only a smaller number have a "Cloud engineer" title. »* The whole is backed by *« an analysis of more than 10,000 job postings, dozens of structured interviews with experts, hiring managers, and recruiters, surveys, and other online data »*, of which **no numeric results are published**: Ng describes his process as *« informally… akin to running clustering »* and announces a detailed map in future posts. He states the interest in the second-to-last sentence: *« DeepLearning.AI's principal focus is to help developers gain these AI engineering skills. »*
**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).
News article analyzed, published on **VentureBeat** on **August 11, 2026** by **Michael Nuñez**, based on an **exclusive interview with Timothée Lacroix**, co-founder and CTO of **Mistral AI**, conducted ahead of the announcement, ~2,000 words. Mistral is expanding its infrastructure offering in three parts: **Mistral Regional Endpoints** in general availability (pinning inference and its associated processing to Europe or the United States), a **Priority Tier** in public preview (committed service levels, custom quotas, availability SLA), and a **coalition of European enterprises** whose multi-year commitments are meant to fund **200 MW by the end of 2027** and **1 GW by the end of 2030**. The vehicle is called the **European Compute Unit (ECU)**: a claim on capacity built by Mistral, fungible across inference, training, model adaptation, or managed Kubernetes, over a targeted five-year horizon. Lacroix describes the mechanism bluntly — *"The whole point of compute units is to have commitment"* — and, on early exit: *"There is no getting out."* The article scales the ambition: Mistral states it operates *"less than 200 MW"* and details three sites totaling **77 MW** (44 MW near Paris, 23 MW in Sweden with EcoDataCenter, 10 MW in Les Ulis); **Epoch AI** puts the initial capex for a one-gigawatt AI datacenter at **~$38B**, and **Goldman Sachs Research** puts next-generation facilities at **$15-20M/MW excluding chips**, against the **~$4B** Mistral has raised in total (PitchBook). Added to this is a decision that *"is likely to raise a few eyebrows among sovereignty purists"*: Mistral is starting to **host third-party open models**, beginning with **GLM-5.2** from **Z.ai**, a Chinese lab — *"It's a great model. Everyone loves it. It's open-weight, so there was no good reason for us not to do it."* The article digs into the fine print of Mistral's documentation, which mentions *"limited, controlled transfers"* to subcontractors outside the region; pressed for detail, Lacroix points to **tool calls**, web search in particular, and states that **gating is the feature, not the bug**. The author's framing: *"full regional control is available, but the moment an AI agent reaches out to the open web, sovereignty becomes a configuration decision, not a default."* Two dependencies remain: **GPUs** come from Nvidia, and **Microsoft** — anchor tenant of Mistral's European datacenters since July — is presented as what de-risks the buildout.
**Michael Nuñez** — journaliste **VentureBeat** · couvre l'IA et l'infrastructure ; déjà présent au corpus. L'article est bâti sur un **entretien exclusif avec Timothée Lacroix** · cofondateur et CTO de Mistral AI · conduit **avant l'annonce** · et fait suite à un entretien de juin avec le même interlocuteur. Publié le **11 août 2026**.
Long-form article published on **X** on **August 11, 2026** by **Jesse Zhang**, CEO of **Decagon** (customer-service AI agents), under a dilemma-shaped title — *« To FDE, or not to FDE? »* — devoted to the **Forward Deployed Engineer**, which has become *« the answer to almost every hard question in AI go-to-market »*. Starting observation: Anthropic and OpenAI have built enterprise deployment arms explicitly modeled on Palantir, *« every seed-stage company »* advertises an FDE offering, and job postings for the title are said to be up several hundred percent in a year. **(A) The Palantir genealogy** supplies the framework: **Shyam Sankar**'s (CTO) formula, *« FDEs eat pain and excrete product »*, and **Joe Lonsdale**'s reminder that Palantir spent nearly two decades being called a *« glorified consultancy »* on the basis of an accurate observation. **Gotham**'s bespoke deployments (CIA, NSA, military intelligence) were encoded into platform primitives — ontology, object models, permissions, workflow engines, provenance tracing — which became **Foundry**, then Apollo and AIP; standardization pushed gross margin into the 80% range and Palantir moved from an FDE motion to account-based selling, with many FDEs migrating into core engineering. *« The pain was the input to the product, not a cost of sale. »* **(B) The criterion proposed** is not to give up on FDEs but to know when to stop: go early, then ask whether one is still **discovering** — *« The trap is not starting. It's not stopping. »* **(C) A distinction few make: FDE ≠ implementation.** *« Building that integration into their ticketing system »* is real work, but it is execution against a known spec, not discovery of an unknown one; conflating the two *« is how a company convinces itself that a growing services org is a product investment »*. Closing line: *« If your FDEs are eating pain and excreting more pain, you don't have an FDE team. You have a services business. »* Two figures are put forward about Decagon — *« two-thirds of deployment work is now done autonomously via Duet »* and *« a few days on average to launch the first AOP, even for large banks, airlines, telcos »* — without the "deployment work" denominator being defined or the AOP acronym spelled out.
**Jesse Zhang** — cofondateur et **CEO de Decagon** (agents IA de service client, San Francisco) · 85 000 abonnés sur X · site personnel `jessezhang.org`. Il cite son cofondateur **Ashwin Sreenivas** · **ex-Palantir** · d'où la profondeur du récit Palantir. Publié le **11 août 2026**.
Doctrinal manifesto published on **meta.com** on **August 10, 2026**, signed with only a first name (*"– Mark"*) by **Mark Zuckerberg**, under the title *"The Future is for Everyone: The Path to a Positive AI Future"*, ~6,500 words. Three principles are announced from the outset: individual empowerment as a source of prosperity, invention as the primary purpose of superintelligence, balance of power as the foundation of safety. **(A) The central argument is a political argument**, stated as a short chain: *"Humanity is not a monoculture"* — people's values encode opposing trade-offs, no technical solution can align simultaneously with conflicting interests, so any singular superintelligence would have to prioritize certain values over others and would thereby be incapable of being benevolent toward everyone. Hence the formula: *"There is no such thing as a singular benevolent superintelligence."* Safety is reframed as a problem of power distribution, illustrated by a thought experiment repeated three times (a single superintelligent lawyer versus everyone having one; the same for cybersecurity, then for business). **(B) A redefinition of alignment**: *"Solving alignment is necessary for billions of people to adopt personal superintelligence agents. But it also implies that if we reach a state where billions of people are using and scrutinizing personal superintelligence agents, then we will have solved alignment with their interests."* The corollary targets the rest of the industry without naming it: *"the most dangerous scenario would be leading labs training powerful models and keeping them for themselves."* **(C) Datable commitments**: a **fully private** mode where *"even Meta"* cannot see or grant access (a WhatsApp analogy); **free** versions for billions of people paired with a **dynamic bidding mechanism** for paid compute; the announced **resumption** of open source releases — *"we will soon resume releasing some open source models"*; and a structure giving the **independent board** the power to approve release safety criteria and verify each release's compliance, with the author acknowledging that Meta is a founder-controlled company. **(D) Two public-policy proposals**, repeated three times: that labs share **intermediate training checkpoints** and engineers with the government rather than an end-of-cycle review, and that the **physical production** of dangerous materials be regulated rather than the spread of knowledge. The text's sourcing is nearly nonexistent.
**Mark Zuckerberg** — fondateur et PDG de **Meta**. Texte signé du seul prénom (*« – Mark »*) · publié le **10 août 2026** sur un domaine dédié de meta.com. La signature n'est pas « Meta » · et l'alternance des pronoms est régulière : **« we » pour les engagements de l'entreprise** (*« we will offer free versions »*, *« Meta is implementing a governance structure »*) · **« I » pour les affirmations normatives ou contestables** (*« I think this view of alignment is fundamentally flawed »*, *« I propose that companies developing frontier AI should… »*, *« My honest guess, and it is a guess »*). Les engagements produits et de gouvernance sont au « nous » · les propositions de politique publique au « je ».
In-depth op-ed published on **sfeir.com** on August 1, 2026, authored by **SFEIR** (the firm's editorial voice). It brings together **two July 2026 publications** with opposite methodologies — the preregistered field experiment **"The Cybernetic Teammate"** at **Procter & Gamble** (Dell'Acqua, Ayoubi, Lifshitz, Sadun, **Ethan Mollick** et al., *Organization Science* 37(4), 2026) and the first report in **OpenAI Economic Research**'s **"Work at the Frontier"** series (Jul. 27, 2026, >800,000 messages from US ChatGPT users) — into a single thesis: *"generative AI doesn't just speed up existing work, it redistributes who does what."* The architecture unfolds in four stages: **the mechanism** (P&G: AI acts as a *boundary-spanning* device, erasing functional silos — an individual + AI reaches the level of a pair without AI, **+0.37 σ**), **the scale** (OpenAI: **43.5%** of profession-specific messages fall outside the user's own profession), **the agenda** (Mollick: the walls are thinning, the division of labor must be rethought, and well-orchestrated recomposition "pays off handsomely"), then **the firm's response** — **Skill Based Organisation (SBO)**, adopted at SFEIR under the impetus of **Rosalie Zandona** (VP People & Culture): **actually operational skill** replaces the job description as the unit of organization (**up to 13 skills identified per role**), shifting from a **status-based identity** ("I am a manager") to an **operational identity** ("I know how to design complex architectures"). The rhetorical move is proof by internal example: *"we made the shift in-house before recommending it."* **Three caveats are noted**: the SBO shift dates back to **February 2026**, hence *predating* the diagnosis it is supposed to resolve (the argumentative order reverses the chronological order); **nothing in the data demonstrates** that a skill-based organization absorbs crossover better than a role-based one (an untested design hypothesis); the P&G result has been circulating **since March 2025** (NBER w33641) — the "a few weeks earlier" applies to the peer-reviewed publication, not to the result itself.
**SFEIR** — ESN française « AI Only » (~850 ingénieurs, 8 agences France & Benelux). Voix éditoriale du cabinet (byline « SFEIR »).
Episode "Phase 5 · Review" of the SFEIR series on the augmented SDLC, published **the same day** as the Addy Osmani LinkedIn post that it translates into a phase specification. Thesis: **quality has changed address** — it is no longer read in the code (agents produce more of it than anyone can review) but in **the ring of constraints surrounding the agent**. Osmani's ring (seven dimensions — correctness, security, performance, accessibility, maintainability, **economic efficiency**, **comprehensibility** — linked by the **back-pressure** rule: "a loop is only granted the autonomy that can be verified cheaply and reliably, not an inch more") is redrawn, translated, and attached to phase 5 of SFEIR's 11-phase cycle. The structuring corollary: **the bottleneck has never been generation, it is verification** — "generation is a wide mouth, verification a narrow neck; speeding up the mouth thickens the pile at the neck." **The most interesting design decision is a cycle-architecture choice**: Review is deliberately **outside the three human gates** (Define, Plan, Ship), because making Review the gate would put human attention — a finite resource — as the control point of a generation capacity that itself scales: "you would have built a pipeline whose maximum throughput is the number of diffs a senior can read before the end of the day." Hence the split: **Review instruments, Ship decides** — Review delivers an *opposable body of evidence*, Ship decides on the evidence, not on the full diff. A position staked against Monperrus (from whom SFEIR retains the diagnosis — human inspection of every diff cannot withstand agentic speed — but rejects the conclusion: acceptance cannot be delegated). The named trap is **circular validation** (the agent that writes the code writes the tests that validate it: "you built a mirror, not a ring"), with five countermeasures drawn from Anthropic (independent gates in separate context windows, deterministic + agentic never substituting for one another, shadow mode, risk-based tiering, logging to the SIEM) and Compare the Market's warning (**AST graph ~70% vs vector RAG ~58%**, with RAG performing *worse than no context at all*). The firm's own extension is **the ratchet**: "every escape becomes a constraint" — a defect that has crossed the ring is closed *within the ring* (test, lint rule, review rubric, harness guardrail) at Compound-1, "the only asset in the chain that appreciates while the models depreciate" (an unaudited internal measurement: **−30% fix iterations after ten cycles**). It closes by reformulating the question: "is this code good?" has become unanswerable; what remains is **"what does my system refuse to let through?"**
SFEIR (voix éditoriale du cabinet, article non signé individuellement) — construit sur Addy Osmani (Google) ; cite Martin Monperrus · Paula Hingel (Augment Code) · DORA/Google Cloud · Jason Clinton (Anthropic) · l'équipe Engineering de Compare the Market
SFEIR's decryption (firm voice) of Jason Clinton's (Deputy CISO, Anthropic) debrief published five days earlier — already documented in [[clinton-anthropic-secure-ai-native-sdlc-2026-07-21]]. **The added value lies not in the facts but in the thesis that rereads them**: if Anthropic's controls hold, it is because **a cycle with named stages exists to hang them on** — "the SDLC is the foundation, not a formality." The demonstration proceeds by rereading the mapping (**PSR at Plan, CLAUDE.md + egress allowlist at Code, review agents at Test, continuous DAST at Deploy, triage + SIEM routing at Monitor**), then through a **four-part anaphora**: (1) *without an SDLC, productivity gains do not materialize* — Clinton cites **Amdahl's law**: multiplying code volume by 8 multiplies nothing if review stays sequential and human, and Anthropic gained not by distributing agents but by **identifying the blocking stage (Test) and rebuilding it** — "you don't optimize a bottleneck you haven't mapped" (echoing DORA 2025's **mirror effect**); (2) *without an SDLC, security has no anchor point* — a **gate is by definition a control placed between two stages**, and Clinton's three threats are addressed at distinct moments; (3) *without an SDLC, no **token FinOps** policy can be formulated* — agentic scanning is billed on consumption and grows with code throughput, so **risk-based tiering IS the FinOps policy** (it decides where three agent passes get paid for and where a SAST suffices), otherwise "token spend is not steered, it is discovered at month's end"; (4) *without an SDLC, there is nothing to measure* — the indicators (16% → 54% of PRs commented, one third of past incidents intercepted) exist only because there are stages where a counter can be placed; absent that, one produces only **usage figures** (licenses, tokens) that say nothing about quality or risk. Two strong points beyond the thesis: the reading of the **incident agent-à-agent** ("a security perimeter that rests on an instruction in a prompt is not a perimeter"; **an agent's access to other agents is part of its attack surface**) and an **explicit methodological caveat** — Anthropic's figures about Anthropic, unaudited, published by the vendor of the model described, in the context of a young codebase with no mainframe: **what transposes is the method, not the figures**.
SFEIR (voix éditoriale du cabinet, article non signé individuellement) — commentaire de Jason Clinton (Deputy CISO, Anthropic)
**SFEIR Internal Research Report** (editorial-preparation document, sourced deep research — ~70 references) on the American **AI Kill Switch Act**, framed around **European sovereignty** and the **"so what" for enterprises**. It is the **factual basis** for a future blog article — it lays out where the "very low bar" thesis **holds** and where it needs **nuance**. **Key contribution vs. press coverage** (including [[arstechnica-ai-kill-switch-act-2026-07-23]]): (1) a reading **of the law's text itself** (new **section 2220F**, "Shutdown-Capability Standard and Graduated Deployment-Corrections Framework," introduced July 23, 2026, 119th Congress) — authority vested in the **DHS Secretary via CISA** (the "Director"), in consultation with Commerce + DNI; (2) **two CUMULATIVE thresholds** — ≥ **$500M** in AI revenue (including affiliates) **AND** training compute > **$100M** — meaning **few labs are covered today**, which **strictly contradicts** the "low bar" thesis; (3) but a **very broad real-world reach** through the **expansion mechanism** (annual threshold updates by DHS, "affiliates" clause, compute indexed to cloud pricing, revenue growth) and above all through the **domino effect** on customers; (4) **graduated sanctions**: up to **$2M/day** (general violation), **$20M/day** (emergency-authority violation); (5) **critical nuance**: since the **OpenAI/Hugging Face** incident occurred during **red-teaming/internal evaluation**, it **would NOT trigger** the emergency authority as currently written (the text excludes red-teaming). The **sovereignty** angle draws on the **Anthropic precedent** (Fable 5 / Mythos 5 cut off for **19 days** in June 2026) as **operational proof** of a "de facto kill switch," and leads into **CTO recommendations** (tested multi-model architecture, continuity clauses, exposure mapping, sovereign options).
**SFEIR** (recherche interne / deep research). Document non signé nominativement — préparation éditoriale pour le blog SFEIR · dans la ligne souveraineté/adoption du cabinet (cf. [[sfeir-mistral-microsoft-souverainete-strategie-industrielle-2026-07-22]]). Base factuelle équilibrée (arguments **et** contre-arguments) · références numérotées.
SFEIR analysis (firm's voice, "an engineers' reading") of the deal announced on **July 21, 2026** between **Mistral** and **Microsoft**: an **industrial partnership worth several billion dollars**, structured in three parts — (1) **compute in Europe** (reserved Azure capacity on the continent, datacenters in France, latest-generation **NVIDIA Vera Rubin** systems, to "close the European compute deficit"); (2) **Mistral's models in Microsoft's tooling** (**Mistral Medium 3.5** and **Mistral OCR 4** in **Microsoft Foundry**, accessible in **Copilot Studio** to build business agents); (3) above all **Azure Local down to disconnected mode** (public cloud, supervised connected cloud, and **air-gapped** entirely off the external network — for defense secrecy, healthcare, critical banking). **Notable fact, confirmed by Brad Smith: no new equity stake** by Microsoft in Mistral's capital — a massive partnership **without a capital tie-up**. SFEIR — an Anthropic and Google Cloud partner, "with no interest in overselling the French champion" — regards Mistral as **"the best European bet on the model layer"** and offers a three-part reading. **What the deal brings a CIO**: a leading-edge European model, executable in a disconnected environment and controlled by the customer (in-memory encryption, locally managed keys), checks boxes that few offerings check. **The tension**: this sovereignty is deployed **on the infrastructure of an American hyperscaler**; four sovereignties must be distinguished — **model, execution, infrastructure, commercial relationship** — of which one can "get three out of four, but you still need to know which one is missing." The only element that makes sovereignty **truly portable** is the **open-weights nature** of Mistral's weights (the same reversibility logic as for **Kimi K3**). The absence of an equity stake is not a detail: it preserves Mistral's governance **and** minimizes the risk of an antitrust review (FTC, European Commission) — **assumed regulatory arbitrage**, not just technical choice. **The real blind spot**: the **legibility of Mistral's industrial strategy**, present simultaneously on nearly every front (B2C with Le Chat, B2B via Azure distribution, open-weights model **and** frontier ambition, highly capital-intensive infrastructure — 200 MW secured, a 1 GW cap by 2030 —, partnerships with a handful of large accounts, Robostral/OCR verticalization, service to regulated sectors): sovereign full-stack (optimistic reading) or the dispersion of a three-year-old company valued at ~€20B across businesses with divergent economic models (cautious reading). For technical leadership: **separate the model from the channel**, **design to exit** (Design to Exit — open-weights makes the exit door credible), **route rather than bet** (sovereign multi-LLM architecture, RAISE). Conclusion: **sovereignty is an architectural property, not a label** — it is qualified dependency by dependency; the missing industrial legibility remains the real open question, settled not by press releases but by "the trade-offs of the next twelve months."
SFEIR (voix éditoriale du cabinet)
SFEIR analysis (consulting-firm voice, "an engineer's reading") articulating two frameworks too often conflated: the **SDLC** (Software Development Life Cycle — *building the software correctly and reliably*) and the **PDLC** (Product Development Life Cycle — *building the right product and succeeding in the market*). Central thesis: the two cycles are not competitors but **nested** — the SDLC is the subset of the PDLC **housed under its development phase**; when a product team reaches the "build" stage, a full SDLC cycle (design → build → test → review → deployment) runs inside it. The SDLC is standardized (**ISO/IEC/IEEE 12207**, 2017 and 2026 editions), with its lineage of models (Waterfall 1970, V-model, iterative/spiral, **Agile 2001**, **DevOps/DevSecOps 2009+**) and its **DORA** metrics (throughput, stability, MTTR, change failure rate). The PDLC, being the umbrella cycle, runs from **ideation/discovery** to **market withdrawal** (not to be confused with the marketing **PLC** of Theodore Levitt, 1965, which describes a *commercial curve*, not *organized work*: "the PLC observes a curve; the PDLC organizes work"). **Tipping point**: the SDLC natively addresses **only one risk in four** — via **Marty Cagan's "Four Big Risks"** framework (Value → PM, Usability → Designer, Feasibility → Lead Engineer, Business viability → PM) — an organization excellent at SDLC but blind to PDLC produces "software nobody wants" — John Cutler's **"feature factory"** (success measured by output, not outcome). **Why AI changes everything**: generative AI **compresses the SDLC** (Google/JetBrains data, May 2026: **~85% of developers** regularly use coding agents, **~41% of new code** is AI-generated; implementation goes from weeks to hours), so the **bottleneck shifts upstream** — deciding *what* to build (Marty Cagan, April 2026: "when the cost of delivery collapses, the bottleneck shifts to discovery"). Consequences: DORA 2025 (~5,000 professionals, 90% AI adoption) shows a **positive correlation with throughput but a negative one with stability** (more unvalidated features means instability and rework); Andrew Ng (AI Startup School, July 2025) reports teams **reversing the "1 PM for 4 engineers" ratio to "2 PMs for 1 engineer"**; and with **spec-driven development**, the PDLC/SDLC boundary becomes **porous** (the product spec becomes directly executable by agents). **What a CIO should take away**: an augmented SDLC becomes a **market standard, not a differentiator** — the junction with the product must be instrumented, **executable specifications** demanded as input, technical metrics cross-referenced with outcome metrics, and the role of "feature supplier" **refused**. For a CPO: the shift of the bottleneck toward discovery is both a **promotion** (product judgment becomes scarce again) and a **notice to act** (industrialize discovery to reach parity with the SDLC). SFEIR's in-house framework ("Designing and building in the agentic era" — **11-phase cycle** + **Software Factory 10x**) is positioned as the answer on the engineering side, with the **articulation of the two cycles** as the next lever. Conclusion: "as code becomes a commodity, margin shifts toward product judgment and governance."
SFEIR (voix éditoriale du cabinet)
Analysis by Janakiram MSV (The New Stack, July 20, 2026) of the **architectural convergence** of the three hyperscalers' enterprise agent platforms: in nine months, **Amazon Bedrock AgentCore**, **Microsoft Foundry**, and **Gemini Enterprise Agent Platform** have converged on the **same six primitives** — runtime, memory, tool gateway, identity, observability, governance — under different brand names. What was a fragmented collection of libraries 18 months ago is becoming a distinct **platform layer**. The thesis: this convergence replays the **2011-2016 PaaS inflection**, where **Cloud Foundry** and **Heroku** unified VMs, load balancers, queues, and secret stores around a portable **application contract** — except that here **no equivalent contract yet exists**, and **no open source project has claimed it**. Consequence: an enterprise cannot **move an agent from one cloud to another** (session state, traces, and identity all end up with a single provider; migrating means rebuilding everything). The author proposes a **line-by-line mapping** of the Cloud Foundry contract onto agents, sets out three design principles (package the agent as **one deployable unit**, **attach** capabilities rather than embedding providers, integrate the **operational** layer into the abstraction), points to what open protocols (MCP, A2A, OpenTelemetry) leave out of scope — the **lifecycle** — and delivers three due diligence questions: **governance** (neutral foundation vs. vendor), **packaging** (the same artifact on two clouds without rewriting), **state** (exportable memory). Verdict: whoever ends up owning the **agent control plane** will define *what an agent is*.
Janakiram MSV
**Boris Cherny** (Creator & Head of Claude Code @Anthropic) publishes a framework table on LinkedIn, **« Steps of AI Adoption »**, mapping an engineering team's adoption of agentic AI across **5 stages (0→4)**, each characterized by an **order of magnitude of agents driven** and a **transformation of the engineer's role**: **0 Gated** (0 agents, locked-down access), **1 Assisted** (~1 agent — "you + one agent", supervised pair programming), **2 Parallel** (~10 agents — **orchestrator**), **3 Supervised autonomy** (~100 agents — **manager of managers**, an org tree), **4 AI-native** (~1,000+ agents — **VP steering by intent**). The table crosses five columns: number of agents, *what it looks like*, *the bottleneck*, *the products that help*, *the guardrails*. **Central thesis**: consuming more tokens does not move you up a level — advancing to the next stage requires **identifying and breaking the next bottleneck** AND **building the next set of guardrails**. Concretely: giving Claude a trustworthy **self-verification loop** (tests + build + lint + e2e on a real environment), enabling **Auto mode** (avoiding blocking permission prompts), making **code review and security review the default**, adopting multi-agent interfaces (Agent view CLI, Desktop, iOS/Android apps, Tag), then `/loop`, `/batch`, `/goal`, **dynamic workflows** and **worktree isolation** for subagents. On steering: usage (dashboard) measures **activity, not return**; the right question is *"would we have spent engineering effort on this anyway? if so, how many manual engineer-hours would it have cost?"* — that's the ROI. The real payoff arrives when **fixing and maintaining happens in the background** and teams focus on *building*. Anthropic sits at **stage 3, heading toward 4**; Boris Cherny states he has personally reached **level 4**.
Boris Cherny (Creator & Head of Claude Code @Anthropic)
SFEIR's engineering-cabinet analysis ("an engineer's reading") of the **July 16, 2026** launch of **Kimi K3** by the Chinese laboratory **Moonshot AI**: an **open-weights, frontier-class model** whose provider claims **~2.8 trillion parameters**, a **one-million-token context**, and **weight release before July 27, 2026** (likely under a Modified MIT license, as with the K2 lineage). Thesis: capability once thought reserved for proprietary giants (Anthropic, OpenAI, Google) is becoming available **in open weights, at a discount price, from a Chinese lab**. SFEIR — despite being an **Anthropic and Google Cloud partner**, and thus "with no interest in overselling a Chinese model" — adopts a cardinal **methodological caveat**: on launch day, **no official, complete benchmark table** exists; specs (2.8T, Kimi Delta Attention, +25% training efficiency) and scores are **vendor-stated** or drawn from **community arenas**, "to be treated as claims, not measured facts." The new architecture (**Kimi Delta Attention**, hybrid linear attention; decoding claimed up to **6.3x faster** at 1M tokens) breaks with the K2 cadence (K2 Jul. 2025 → K2.7 Code Jun. 2026, a flagship every two months); two variants accompany the launch (**K3 Max**, **K3 Swarm Max**), with forced sunsetting of the kimi-k2.5/moonshot-v1 series on **August 31, 2026**. **The real weapon is price** (~$3/M input, $0.30 cached, $15 output per secondary sources): a frontier open-weights model at this level **pulls the whole price-performance curve down** — the commoditization of the model layer, accelerated by open source. But the decisive singularity is not a score: it is **reversibility**. A frontier open-weights model turns a consumed API (vendor dependency) into an **option** (self-host, portability, exit from lock-in), at the cost of heavy infrastructure to host 2.8T parameters. SFEIR's view: **open-weights changes the question, not just the answer** — no longer "which model is best/cheapest?" but "how much of my system am I willing to make dependent on a vendor I don't control?". The right posture remains a **routed portfolio** (one model per task, one model per constraint), with Kimi K3 adding a **"reversibility" column** to the decision grid. The "AI Only" conviction stands unchanged: the model is a commodity, the durable advantage lies in the engineering around it (Context Engineering, harness, cost governance, ability to change one's mind). The figures still need validating "on your own" — your repositories, your data.
SFEIR (voix éditoriale du cabinet)
Primary-source tech-watch digest on the position of **Gregor Hohpe** (author of *Enterprise Integration Patterns*, *The Software Architect Elevator*, *Cloud/Platform Strategy*; former AWS & Google Cloud Enterprise Strategist, former Chief Architect at Allianz) regarding the role of the architect in the era of generative AI. Thesis: AI **does not devalue** the architect, it **shifts their value** from code to what AI does not do — **making and owning decisions, arbitrating trade-offs, "selling options," communicating with humans, producing sound abstractions**. Key formula (Craft Conference 2026): "*Developers mainly interact with machines… GenAI. In contrast, architects communicate with humans*". His signature thesis (the architect should not be the smartest person in the room, they should **make everyone else smarter**) grows stronger as code becomes abundant: the advantage comes from **decision discipline** and **surfacing hidden trade-offs**, not from volume. The digest also breaks down his positions by role (enterprise architect: from **cartographer to scout**; software architect: **debugging** decisions rather than writing code; platform architect: **abstractions, not illusions**), his **real options** metaphor (value increasing with technological volatility, Black-Scholes analogy), and his warnings ("*An AI-driven SDLC punishes bad habits much faster*"; the winners of AI will be defined by how fast they move from experimentation to **governed production**). ⚠️ The widely circulated formula "architects who use AI will replace those who don't" **is not from Hohpe**. Domain: software architecture, the architect's role, decision-making, real options, platforms, GenAI in the SDLC.
Gregor Hohpe (sources primaires) — digest de veille
SFEIR analysis note that reexamines the software architect profession in the age of generative AI through the framework of **Gregor Hohpe** (*The Software Architect Elevator*). Central thesis: the « **Oracle** » architect — the holder of supreme knowledge dictating rules from an ivory tower — is obsolete, since AI generates code and proposals on demand; the modern architect becomes an **intelligence amplifier (IQ Amplifier)** who provides teams with mental models, business context, and decision tools to leverage AI while ensuring system coherence. The document breaks down the impact **floor by floor of the "Architect Elevator"** (Enterprise / Solution / Platform / Software architect) and argues for **Domain-Driven Design (DDD)** as an essential safeguard: the **ubiquitous language** serves as the basis for *system prompts* (a domain dictionary injected via `.clinerules`/templates, reducing hallucinations and business misinterpretations) and **bounded contexts** restrict the scope entrusted to AI to maximize generation reliability. Conclusion: AI is not a threat but a catalyst that relieves the architect of technical grunt work to emphasize synthesis, strategic vision, modeling, and the human link between tech and business. Domain: software architecture, the architect's role, DDD, structured prompting, enterprise AI governance.
SFEIR (synthèse) — d'après Gregor Hohpe
Third installment of Ashish Singh's « New Engineering Disciplines for the AI Era » series, devoted to **KDLC — Knowledge Development Life Cycle**: an **8-stage** life cycle for turning enterprise knowledge into an **engineered asset**, on a par with code or data. Thesis: AI initiatives fail not for lack of the right LLM choice or a deployed RAG system, but because they **do not address the underlying structure of knowledge** — « AI is only as effective as the knowledge it can discover, understand, retrieve, and trust ». The KDLC chains Discovery → Extraction → Structuring → Knowledge Graph → Embedding → Index Optimization → Retrieval Evaluation → Refresh. It contrasts **traditional RAG** (isolated documents, keywords) with the **Enterprise Knowledge Fabric** (Knowledge Graphs + Semantic Search + Vector DB + Hybrid Search), where agents understand « relationships, context, and business meaning ». Signature line: « Models provide reasoning. Memory provides continuity. Knowledge provides understanding. » Three examples (finance/compliance, software engineering, healthcare) illustrate the impact.
Ashish Singh
Long-form essay by **Shubham Saboo** (X/Twitter) advancing a thesis on the Product Manager role in the age of agents: the next key skill is **not prompt engineering** but **Loop Engineering** — designing a *system that improves with every run* rather than writing the perfect prompt every time. A **loop** is a repeated cycle: change what shapes the agent's behavior → run it → evaluate the output → keep the change if quality rises, revert otherwise → **compound the learning** so the next version starts ahead. For a PM, the entry point is not code but the **durable artifacts** that encode their judgment: PRD-review skill, customer-call *summarizer*, evaluation rubric, launch checklist, research workflow, `CLAUDE.md`, prompt template, prioritization framework. Because they are reused, these artifacts **compound in both directions** — and **drift** silently (a CLAUDE.md that keeps growing, a checklist that gets ignored…): the model has not regressed, the artifacts have drifted unwatched. A loop has **5 parts**: trigger, action, **proof**, memory, **stop condition** (the most critical). **Evals** become PM work (testing the artifact against known examples: 3 good / 3 bad PRDs, 5 understood calls, 2 past launches). **Memory** lives on **GitHub** (the repo becomes "product memory": commits, diffs, eval results, decision log, rollback). Recommended first loop: a **weekly product signal loop** (every Friday). Taste remains central — but it now needs **proof**. Cites Boris (creator of Claude Code): "he no longer writes prompts, he writes loops."
Shubham Saboo (@Saboo_Shubham_)
Internal teardown report on the open-source release **`xai-org/x-algorithm`** (May 15, 2026) — the **For You feed** algorithm of **X (formerly Twitter)** in 2026, with four audience-tuned growth recommendation tracks (personal/founder, brand/company, generalized framework, client/consulting deliverable). **Pivot thesis**: ***« The famous 2023 weight table — replies count more than likes by a big multiplier — describes a system that no longer exists in this form. »*** The 2026 algorithm is a **transformer (Phoenix, Grok-1-derived)** that learns weights from your engagement history, scored against a **19-dimension multi-action surface**, gated by an offline content-understanding service (**Grox**). **The shape of scoring now matters far more than the numbers — and the numbers themselves are not in the public release**. **4-component architecture**: (1) **Home Mixer** (Rust, request-time orchestrator, hydrate → source → filter → score → select → filter); (2) **Thunder** (Rust, Kafka-fed in-memory store of recent posts, sub-ms lookups for in-network candidates); (3) **Phoenix** (JAX ML, two-tower retrieval + ranking transformer, ~Grok-1-derived); (4) **Grox** (offline, spam/safety/PTOS/banger classifiers + multimodal v5 embedder). **The 19 actions predicted by Phoenix** (key change vs. 2023): favorite, reply, repost, photo_expand, click, profile_click, vqv (video quality view gated by min duration), share, share_via_dm, share_via_copy_link, dwell, quote, quoted_click, follow_author, not_interested, block_author, mute_author, report, dwell_time (continuous). **Final score** = `Σ (weight × P(action))` modified by **3 structural multipliers**: (a) **OON_WEIGHT_FACTOR < 1** (out-of-network penalty), (b) **author diversity decay** `(1-floor) × decay_factor^position + floor` (exponential attenuation of repeated posts from the same author within a single render), (c) **video duration gate** (vqv only contributes if `video_duration_ms > MIN_VIDEO_DURATION_MS`). **Key caveat**: **no numeric weight value** (`FAVORITE_WEIGHT`, `OON_WEIGHT_FACTOR`, `AUTHOR_DIVERSITY_DECAY`, `MIN_VIDEO_DURATION_MS`...) is in the release — everything is `crate::params::*`, managed by an internal X feature-switch service for A/B testing. ***« Anyone telling you 'replies are worth N.N× more than likes in 2026' is fabricating a number that is not derivable from the OSS release. »*** **Key differences vs. 2023**: (1) removal of every hand-engineered feature (*« We have eliminated every single hand-engineered feature and most heuristics from the system »*); (2) a single model predicting 19 actions vs. multiple single-action models; (3) Grox separates content understanding from ranking; (4) new first-class signals (continuous dwell, gated vqv, follow_author, 3 share variants); (5) two-tower OON retrieval (vs. SimClusters+heuristics) with multimodal text+image+ASR-video embeddings. **Three layers of reach** (generalized framework): Eligibility (binary, Grox+filters) → Retrieval (probabilistic, two-tower ANN) → Ranking (continuous, weighted-sum + multipliers). **Two laws of mechanical growth**: (1) In-network is multiplicative, OON is additive; (2) The model's job is to predict you, not reward you. **Deliberate honesty boundary**: released Phoenix checkpoint = mini (2 layers, 4 heads, 256-dim, 537K sports-post corpus), not the production model; Thrift integrations stubbed (`panic!("Not implemented")` in `candidate_features.rs`); brand-safety lists, topic ID mappings, language penalties, ad-blending rules absent from the public release.
Rapport interne **non signé** (typique des deliverables d'analyse interne / brouillon de livrable client). Sources primaires citées : (a) le repo public **`xai-org/x-algorithm`** (release 15 mai 2026) · (b) les `README.md` du repo et de ses sous-modules (`home-mixer/`, `phoenix/`, `thunder/`, `grox/`) · (c) le code source Rust (Home Mixer, Thunder) et Python/JAX (Phoenix, Grox) inspecté directement avec citations file:line. Le rapport est explicitement écrit en posture *"what we observe in the public source release · and what it implies for measurable growth interventions"* — registre de teardown analytique avec discipline d'honnêteté épistémique (section A.3 *"Honesty boundary"* listant exhaustivement ce qui n'est pas dérivable de l'OSS).
Analyst note by **Mitch Ashley**, VP and Practice Lead for *CIO & Technology Buyers* and *Software Lifecycle Engineering* at **The Futurum Group**, published on **April 29, 2026** in the *Market Coverage News* section: short format, roughly **9,500 characters**, opening with five summary bullets and closing with five watch-list items. Subject: the deal announced on **April 21, 2026** under which **SpaceX** gains the right to acquire **Cursor** for **$60 billion** within the year, or to pay **$10 billion** for a compute partnership backed by **xAI**'s **Colossus** cluster in Memphis, described as equivalent to **1 million H100 GPUs**. (A) The two-need reading: Cursor was carrying both a compute ceiling and margin compression — the company pays market-rate prices for **Anthropic**'s and **OpenAI**'s models, which it routes to its customers while competing with them via its **Composer** line; SpaceX was seeking AI revenue and a narrative ahead of an IPO targeted for June. (B) The structure reading: a $10 billion floor and a $60 billion purchase option exercisable in publicly traded stock after the listing, which, Ashley writes, *"allocates risk more honestly than a straight acquisition."* (1) For buyers, it sets a **six-month** window to re-verify zero-data-retention clauses and vendor identity. (2) For providers, it distinguishes three exposures — **Google** shielded by **Antigravity**, **AWS** dependent on Anthropic, **IBM** lightly exposed but well positioned on the governance angle. The corpus already holds [[beck-starving-genies-usage-limits-ai-coding-2026-04-03]] on the resource constraint imposed on coding tools and [[nyt-musk-promises-spacex-ipo-track-record-2026-06-02]] on SpaceX's announcements.
Mitch Ashley · VP et responsable des pratiques CIO & Technology Buyers et Software Lifecycle Engineering chez The Futurum Group · ancien CIO et CTO.
Deep Research - AI4* Revolution - 6 pillars of software production - Copilots→Agents transition - Vibe vs Check paradox - FinOps for AI crisis - Governance as critical path - GenAI Landing Zone
Deep Research Veille Interne
IA générative strategic framework - 4 deployment quadrants - Access paradox - Data as moat - Strategic differentiation - Harvard Business Review - Bharat N. Anand - Andy Wu
Bharat N. Anand (NYU Stern School of Business Dean) · Andy Wu (Harvard Business School)
Wardley Mapping explained, situational awareness, value chain, Genesis→Commodity evolution, visual strategy, modern Sun Tzu
Recherche synthétique compilée (28 sources)
Pragmatic Engineer - Measuring AI Impact - Developer Productivity - Metrics - GitHub Copilot - DX - Engineering Efficiency
Gergely Orosz and Laura Tacho
Context Engineering - Domain Understanding - DICE - Rod Johnson - LLM - Domain Model - Embabel
Rod Johnson
AI Workflow for generating Wardley Maps, LLM prompts capabilities, Obsidian graph, NetworkX clustering, strategic bootstrap - Video Tutorial
Auteur vidéo (Product Manager ERP/Business Intelligence)