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. »*
#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).
Reference page published on **eventuallycoding.com** on **July 28, 2026** by **Hugo Lassiège** (Lyon, developer turned entrepreneur, author of Bloggrify, Hakanai, and Writizzy). The author announces it as such: *"This will be more of a reference page than an article,"* intended for his own resources page. **Subject**: an exhaustive, tooled description of a **solo software factory** where *"the code produced is now nearly 100% generated,"* across several polyglot monorepos (Nuxt, Kotlin, JS — Hakanai, Writizzy, Bloggrify) in **continuous deployment to production**. **Distinction stated upfront**: this is not **vibe coding** in Karpathy's sense (experimentation, letting oneself be carried along) but **context engineering** — *"giving all the necessary context, at the right time, so that the software matches an intention and is systematically controlled,"* with the sentence that grounds the responsibility: *"Even if I don't write the code, I am responsible for it and must keep control over it."* **The entire toolset answers three questions**, and this is the text's most reusable reading grid: *"What does the agent know?"* (context, memory, code graph) — *"What does it know how to do deterministically, without improvising?"* (skills, procedures) — *"What stops it when it gets it wrong?"* (hooks, architecture tests, quality gates). **Six layers detailed**: (1) **context** — root `CLAUDE.md` + topical `.claude/rules/*.md` conditionally loaded via `paths:` + `.agents/*.md` for non-technical matters (personas, positioning, tone); (2) **skills** — about thirty, existence criterion *"if I explain the same thing a third time"*; (3) **tools** — JetBrains IDE MCP, **GitNexus** (code graph: `impact(symbol)`, `detect_changes()`), Claude-mem, RTK filtering wrapper, Sentry, read-only database; (4) **executable guardrails** — harness hooks, **architecture tests**, pattern linting (**ast-grep** for architecture decisions, not just ESLint); (5) **factory** — blocking quality gate with `needs:` on the quality job, five test stages; (6) **product process** — numbered specs with a drafting skill **and a closure skill**, design in Claude Design, staged delivery behind feature flags, distinction between **feature flipping** (Unleash) and **gating** (customer contract). **The rule that sums it all up**: *"What matters must be executable. An instruction is followed 'most of the time'… A hook or a test is followed all the time."* **A rarity for the genre**: a "To improve" section that exposes four lived limitations — the **impossibility of measuring a rule's obsolescence** (*"I have no way of knowing whether an old rule has become obsolete"*), the **rabbit hole** created by a boyscout rule, the **lack of packaging** for skills across projects, and above all the admission of tension: *"I am becoming less and less useful during implementation phases,"* *"torn between the satisfaction of having an increasingly efficient factory and the risk of losing knowledge."*
#software factory#context engineering#vibe coding
**Hugo Lassiège** — développeur devenu entrepreneur · basé à **Lyon** · écrit du code depuis 2001 et tient **eventuallycoding.com** (le blog a porté le nom `hakanai.free.fr` avant de devenir *Eventuallycoding* en 2013). *Eventuallycoding* est le nom-parapluie qui regroupe ses projets · sa chaîne YouTube et ses blogs.
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."
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#Architect Elevator#role of the architect
Gregor Hohpe (sources primaires) — digest de veille
SFEIR article (in French) that formalizes an **AI-driven SDLC in 11 phases (0 to 10)** and argues that the industry is converging toward it. Starting observation: in 2025, organizations added AI tools without transforming their operating model — producing a paradox of « everything changes… and nothing changes » (execution speed multiplies without proportional gain). The real answer is not the choice of tools but the **redesign of the cycle** for machine execution. The SFEIR cycle rests on **three immovable human gates** (Define, Plan, Ship), automatic phases between them, and **two capitalization moments** (Compound-1 pre-deployment, Compound-2 in production) that turn lessons into reusable rules. Three principles: **AI executes** (complete artifacts + proof of execution, never trusting the agent's own claims), the **human retains control of intent**, the **system learns cumulatively**. Measured results (redesign 6 months→1 day, **−30% of iterations** after ten cycles) and claimed convergence with ADLC, Google, and DORA 2025.
Guide from the media outlet **Every** (every.to/guides) published on **June 2, 2026**, co-signed by **Mike Taylor, Laura Entis and Claude**, proposing an **8-level maturity scale for AI adoption**. **Pivot thesis**: AI adoption **is not a race toward maximum sophistication** — ***« a higher level isn't necessarily better »*** ; one must identify the level that **matches one's own workflow and level of trust**, then regularly reassess whether moving up a notch adds **real value**. ***« The best way to find value in AI is to use it in a way that fits your work. »*** **Structuring axis**: at each level, *« you delegate more of your work to—and place more trust in—the AI »* (increasing delegation + trust). **The 8 levels**: **(1) Chatbot** — conversational interface with no embedded context (ChatGPT, Claude, Gemini); **(2) Copilot** — AI embedded in the workspace with access to the current file (Cursor, Claude in Excel, Gemini in Docs); **(3) Agent** — reactive system that executes step-by-step while requesting approval (Cowork, Codex); **(4) Autopilot** — one describes the **outcome** and the agent executes autonomously, review of the **final result** only (Lovable, Codex, Claude Code; tied to *vibe coding*); **(5) Workflows** — engineers building **harnesses** around agents (planning, review, confidence checks, guardrails; Compound engineering, Claude Workflows, Copilot AI Studio; shift from one-shot vibe coding → **agentic engineering**); **(6) Assistant** — **proactive, always-on** agents that monitor a domain and surface information without being prompted (OpenClaw, Hermes Agent, Claude Managed Agents; e.g. `heartbeat.md` every 30 minutes); **(7) Multi-agent** — simultaneous management of **several long-running agents** with distinct roles (Claude Managed Agents, OpenClaw, Codex Goals; *« firmly in senior engineering territory »*); **(8) Orchestrator** — an **agent manager** directs a team of sub-agents (planning, delegation, monitoring, consolidation; Gas Town, Paperclip, Symphony/OpenAI; *« highly experimental »* — even frontier engineers themselves hold this role). **Sweet spots by role**: **knowledge workers** typically operate between levels **1-4**, **engineers** between **5-8**. **Canonical parallel of intern onboarding**: *« Expect to put in a similar amount of effort with your agents before you can trust them… at the next level of autonomy »* ; and the marker phrase ***« You wouldn't brag that you had eight interns working overnight on a key project, and you hadn't checked their output. »*** The right level depends on **4 criteria**: output quality, cost, reliability (trustworthiness), stakes of failure; and **model capability** progressively shifts the "safe" level of autonomy. A framework directly usable to structure an **adoption doctrine** on the consulting side. Convergence with *systems around the model* (Dropbox/Okumura), *harness engineering* (Böckeler, Lattice, Wescale), Karpathy (vibe coding → agentic engineering), Cherny (/loop + Routines), and the *agent manager* doctrine (BFM/Girard).
#AI adoption#maturity scale#eight levels
**Mike Taylor** · **Laura Entis** et **Claude** (co-auteurs déclarés) · pour **Every** (every.to) · rubrique *Guides*. Mike Taylor est un auteur connu sur les sujets prompt/AI (co-auteur de *Prompt Engineering for Generative AI*) ; Laura Entis est journaliste/éditrice. La co-signature explicite de **Claude** comme auteur fait partie du positionnement éditorial d'Every (entreprise AI-native). Publié le **2 juin 2026**.
Continuous Delivery as the non-negotiable foundation of AI-assisted development — Dave Farley, on his channel *Modern Software Engineering*, argues that without CD, AI is not an accelerator but a trap (theory of constraints and Jevons paradox applied to generated code, ATDD/BDD as a safeguard, deployment pipeline as quality arbiter).
#Continuous Delivery#Generative AI in the SDLC#ATDD (Acceptance Test-Driven Development)
Dave Farley (Modern Software Engineering — YouTube channel)
Podcast by Greg Isenberg × Meng To (designer, founder of Design+Code, creator of the products Aura / New Form / Dream Cut) on **`design.md`** — Google's open-source convention, equivalent to `agents.md` / `skills.md` / `soul.md` but **for the design system** (typography, colors, spacing, WebGL/Three.js animations, reveal rules). Central idea: carrying the "**soul of design**" in a markdown file that is handed to an agent (Claude Code, Codex, OpenClaude, Gemini, Stitch, Aura, V0, Lovable, Cursor) to preserve **cross-medium consistency** (web, mobile, Replit slides, Hyperframes/Remotion motion design). Triad taught: **HTML = finished dish, design.md = recipe, skills = ingredients** (typography, lasers, skeuomorphic, 3D skills — 63 in New Form). Major diagnosis: **design drift** on one-shot workflows (`v0`, Lovable, Framer) that start strong then drift into generic output. Meta-message: *taste* is the only remaining **moat** — *"if something looks like another thing, its value drops by 10× to 100×"*. Workflow: **Reference → Design.md → Generate → Inspect → Systemize → Iterate (up to 1000+ prompts) → Remix → Expand → Export**. Critique of **purple gradients** ("you just run") as the generic post-vibe-coding baseline. Meng To claims to have spent ~$500,000 in tokens, run 1,000–10,000 iterations per product, and managed 4 products in parallel solo.
#design.md#Google#design system
Greg Isenberg (host — podcast Late Checkout / The Greg Isenberg Show, 12 mai 2026 livestream workshop ideabrowser.com) ; **Meng To** (guest — designer, fondateur Design+Code 2014, créateur Aura / New Form / Dream Cut, autodidacte parti à 18 ans, dropout, francophone d'origine canadienne)
Google whitepaper (the "Day 1" installment of a series, by Addy Osmani, Shubham Saboo and Sokratis Kartakis) mapping the transformation of the software development lifecycle (SDLC) in the age of coding agents. Thesis: the fundamental shift is not a new language but the move from writing code to **expressing intent**. The document sets out a spectrum ranging from *vibe coding* (prompting and accepting) to *agentic engineering* (AI implements under constraints, tests, and feedback loops designed by humans), with **context engineering** as the central skill, the **software factory** model (the developer's deliverable = the system that produces the code), **harness engineering** (Agent = Model + Harness), and a CapEx/OpEx economic analysis of total cost of ownership.
Interview with Andrej Karpathy (OpenAI co-founder, former Tesla Autopilot) moving from *vibe coding* to *agentic engineering*: December 2025 as the turning point "never felt more behind as a programmer," the Software 1.0/2.0/3.0 taxonomy, the openclaw example (bash script → text to copy-paste into the agent) and MenuGen rendered obsolete by Gemini's Nanobanana, the *verifiability* theory explaining why LLMs are *jagged* (math/code peak, "walk to the car wash 50m away" fails), the distinction between *vibe coding* (raise the floor) and *agentic engineering* (preserve the quality bar), the "animals vs ghosts" metaphor, the overhaul of hiring via agent-versus-agent projects, and the key formula: ***"You can outsource your thinking but you can't outsource your understanding."***
#Andrej Karpathy#vibe coding#agentic engineering
Andrej Karpathy (co-fondateur OpenAI, ex-Tesla Autopilot, créateur du terme "vibe coding")
Revamp of the engineering hiring process at Sierra in the age of coding agents: AI-native onsite interview (Plan/Build/Review), removal of the algorithmic coding test, replacement of the phone screen with a system design interview, pilot of a debugging interview on an existing codebase.
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