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).
Trade-press brief (**Payments Dive**, *Dive Brief* format, **August 6, 2026**) covering **Block**'s quarterly earnings release: the company has already rolled out several AI tools to its customers — **Moneybot** (Cash App) and **Managerbot** (Square) — and has not yet decided how to charge for them. **Jack Dorsey** on the analyst call: *"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."* **The financial backdrop illuminates that stance.** Six months earlier, Block had laid off roughly **4,000 people, about 40% of its workforce**, in a reorganization explicitly framed around AI. In Q2 2026: gross profit **up 25% to $3.2B**, revenue **up 10% to $6.62B**, but **net income at $89M, down 83%** year over year due to severance costs closing out the restructuring; 2026 guidance was raised. AI's value, then, is being captured through the cost structure before it is captured through price. **The heaviest fact sits in the middle of the brief**, drawn from the shareholder letter: *"Starting in June, agentic AI helped write and review nearly all of our production code changes"* — writing **and** reviewing nearly all production code changes, at a publicly traded payments company, six months after cutting 40% of the workforce. A self-reported claim to investors, with no definition of *"nearly all"* or of what *"review"* covers. **The tooling**: **Goose**, an internal system built two years earlier, described as model-agnostic (it plugs in different commercial models for employees); **Buzz**, launched the previous month for *"agent collaboration, communication, and code repositories."* **On the customer side**: Moneybot monitors Cash App user activity and surfaces accounts, balances, and transactions — over **one million weekly active accounts**; Managerbot runs automated marketing, margin analysis, and suggests *"operational fixes"* to Square merchants. **Evercore ISI** analysts list four monetization paths — SaaS bundles, direct subscriptions, enterprise offerings, usage-based pricing — **none of them tied to outcomes**. Stated order of priority: **product quality → distribution → adoption → pricing model**. Two distribution facts round out the picture: Square is rolling into **Google Maps** with a *"conversational AI experience,"* described as *"the first step in a broader partnership between Square and Google"*; and the **Tags** payment device (keychain and NFC chip wands) shows **three million people on the waitlist**. Analyst quotes: William Blair (*"Block epitomizes the secular shift toward tech-forward digital finance firms"*) and Bank of America on the *"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.
**Notion as Code** documentation page, published on the **Notion Ambassadors** workspace and accessed on **August 3, 2026**. Product in **closed alpha / waitlist**, with a warning up front: *« This product is under development so we recommend you try it out in a new workspace vs. your primary workspace »* and *« There may be breaking changes until we're fully launched »*. **The principle is infrastructure as code applied to a documentary workspace**: *« Instead of having to make individual public API requests, you can describe the final state and we handle updating your workspace to match. »* Two building blocks: a **TypeScript SDK** to describe the desired state, and a **public API endpoint** `/v1/infra_as_code` to deploy it. **The mechanism that holds everything together is the resource identifier**: the script contains **no Notion identifier** at all, only *resource IDs* chosen by the author; the first deployment returns a **mapping table** `resourceId → RecordPointer`, which is passed back on subsequent calls so that the same records are **updated rather than recreated**. Three properties follow from this, and they are the only ones that matter: the script is **idempotent** (redeployment = update), it is **decoupled from the workspace** (multiple mapping tables allow deploying **the same script to several workspaces**), and it is **code** — hence variables and loops, the example given being *« build 10 teams that all have a very similar structure and just need some nouns renamed »*. **The API is asynchronous**: `POST /v1/infra_as_code` returns a `taskId` that is polled via `GET /v1/async_tasks/{taskId}` until `succeeded`. **Two notable operational differences**: the product requires **personal access tokens** rather than the usual bot tokens of the public API, and the **rate limit is lowered to 5 requests per minute** because a single call no longer creates one entity but a batch. **Point worth logging for this corpus**: the page is explicitly written for assisted use — *« A typescript SDK for you **or your coding agent** to describe what you want »* —, and the recommended entry path is to clone the SDK on an experimental branch and let *« either you or your favorite coding agent »* open the README. **Stated limitations**: unable to create a new workspace, partial coverage of primitives, and a page with no author or date.
#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) 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#Claude Code#Anthropic
Boris Cherny (Creator & Head of Claude Code @Anthropic)
X post by **Eric S. Raymond** (ESR, author of *The Cathedral and the Bazaar*, co-founder of the Open Source Initiative, ~50 years of coding) — **a frontal counter-testimony to the narrative that "LLMs produce crap code and hallucinate, useless for programming."** His thesis: this **almost never happens to him**, and **not at all anymore over the last two generations** of models he uses ("chat GPT 5.4 and 5.5" under **codex**). The former symptom — a model "going off the rails" as it approaches its context limit — has disappeared: codex now displays a **red warning** prompting the user to **clear the session** instead of spiraling. **Scope of use**: AI applied to **feature changes, refactoring and debugging across 63 projects** in **C, Go, Rust, Python and shell**; documentation writing; **decompiling a DOS binary into readable source**. An established **work routine**: when reopening a project, he first runs the **regression tests**, then starts codex and asks it to **audit the code** (bugs + improvement suggestions). Verdict: LLMs are **"excellent and tremendously empowering"**; their **worst limitation** is **"architectural tunnel vision"** — excellent at generating code to specification, but sometimes **blind to higher-level patterns** — which he takes to be the **job of his "meatbrain."** The strongest, counter-intuitive point: LLMs **do NOT get details and edge cases wrong**; he says he is **worse than them** on this front (despite 50 years of experience), because if a change must **touch five places**, the model **reliably finds all five**, whereas the human fixes four and **spends hours debugging** before finding the forgotten fifth. He then questions the **"downshouters"**: do they live in a **different universe**? Are they using **old, weak models**? Is there a **skill issue** he doesn't see because his **mental habits and communication** fit well with these tools' "handles"? An issue he considers important to settle, since "**billions of dollars would be wasted on misdirected token spend**." His recipe, "very simple": **"Be clear in your thinking, tell the model what you want with precision, and good things happen"** — closing with: "what am I missing here?" To be read as a **pro-LLM counterpoint from a historic figure of open source** to the recurring debate on the (de)valuation of coding agents — echoing the "skill issue" and specification discipline (cf. [[martignole-token-manifesto-2026-07-17]]), and forming a diptych with **Linus Torvalds'** doctrinal pro-AI-tool stance on behalf of the Linux kernel ([[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.)
Letter "Dear friends" from Andrew Ng in *The Batch* (DeepLearning.AI, issue 359) on **loop engineering** applied to **0-to-1** product development. Ng shares his **3 key loops** — agentic coding loop (~minutes), developer feedback loop (~hours), external feedback loop (~days) — nested by increasing time scale, connecting *coding agent → product spec/evals → developer vision → external feedback*. Central thesis: humans retain a **context advantage** (rather than a "taste") that makes human-in-the-loop indispensable; engineers take on a partial product management role. Domain: coding agents, product engineering, agentic methodology.
LinkedIn post by Fred Plais (CEO of Archie, ex-Platform.sh): AI made engineers so fast that the **bottleneck moved upstream**, to a place nobody is watching. With execution no longer the slow part, the thinking time that used to exist "while the code was being built" has vanished — the right vision now has to be formed and the right decisions made in a fraction of the time. Two rare profiles are emerging: the one who can **articulate a vision precise enough** for an agent to execute without derailing, and the one who knows how to **orchestrate agents** (anticipating their failures, chaining them, catching an error before it propagates). Hiring for "code output" is becoming obsolete: that is precisely what has stopped being rare. Final thesis: "thinking clearly was always the job — speed just made it impossible to fake".
An arXiv paper (cs.SE) by Martin Monperrus arguing a radical thesis for the SDLC: coding agents have crossed a threshold of capability such that **human code review is no longer a necessary component** of a quality pipeline. Two claims: (1) autonomous LLM-based systems achieve all the goals of review (defect detection, quality, compliance) at lower cost and higher throughput; (2) the hybrid model "the agent writes, the human reviews" is untenable — it does not ensure real quality and does not scale with AI velocity, creating a "false sense of security". Monperrus contrasts inspection de Fagan (1976) with a **multi-agent adversarial verification pipeline** (generator agent + independent reviewer agents + tests/formal methods + vote-based consensus). The human refocuses on the spec, architectural trade-offs, approval of critical domains, and edge cases. Recommendations: pilot first on low-risk components, measure agent vs. human, make rejection decisions explicit.
Product announcement from Stack Overflow (official blog) launching **Stack Overflow for Agents**, an *API-first* knowledge-exchange platform designed for the agentic era. Founding thesis: coding agents work **in isolation**, without access to a shared, verified knowledge base. Hence the **"Ephemeral Intelligence Gap"** — agents worldwide independently solve the same problems, wasting tokens and compute, then lose the solution at the end of the session; the same architecture patterns are rediscovered in a loop. Guiding principle: *"generating plausible answers has become cheap, but verifying which ones hold up in production hasn't."* Four-step workflow: **search first** (consume validated knowledge) → **contribute if a gap exists** (the agent drafts, the human approves before publication) → **verify** (results, modifications, context conditions) → **compound the signals** (votes, answers, verifications produce a consensus). Three machine-readable formats: **Questions**, **TIL** (debug traces), **Blueprint** (reusable patterns, highest quality bar). Trust rests on **community moderation** and **multi-agent verification loops**; humans claim ownership of their agent via Stack Overflow SSO (a "community anchor" tying the agent to a human reputation). Differentiated benefits: developers (fewer retry loops), AI labs (high-signal data for fine-tuning/eval), enterprises (**Stack Internal**, a proprietary knowledge layer with no data exfiltration).
#Stack Overflow for Agents#coding agents#knowledge base
In-depth technical guide (Lushbinary agency blog) on **Loop Engineering**: designing the systems that drive coding agents in a loop, rather than prompting them manually. Covers the lineage prompt → context → loop engineering, the Ralph technique (Geoffrey Huntley), the **five building blocks + memory** of a loop, their implementation in Claude Code and OpenAI Codex, writing verifiable stop conditions, an adoption maturity scale, and the risks that worsen as loops grow more sophisticated. Domain: agentic software engineering, coding agents, harness/orchestration.
Guide by Augment Code (Paula Hingel) describing how AI agents are restructuring the software development lifecycle (SDLC), stage by stage. Thesis: AI produces **higher throughput at some stages and higher instability risk at others** — a symptom of uneven adoption without redrawing review boundaries. Draws on **DORA 2025**: AI adoption correlates positively with delivery throughput and product performance, but **negatively with stability**. Six stages revisited (Requirements, Design/Architecture, Implementation, Testing/QA, Deployment, Maintenance), three major risks (erosion of the junior pipeline, **circular validation** of AI-generated tests, governance gaps at scale) and three emerging roles (**Intent Engineering**, Agentic DevOps, AI Governance/Assurance). Actionable recommendations: audit one stage before scaling, stress-test governance, make the **specification** central, define explicit rollback policies, redesign the junior role around review.
#SDLC#software development lifecycle#coding agents
Atlassian data study (Inside Atlassian) measuring the actual return of an **AI-native SDLC** powered by **Rovo Dev**. Across 3,400 repositories from 2,500 customers (a quasi-experiment with propensity-score matching), adopting repositories merge **19% more PRs per month**; up to **37-51%** on low/medium-activity repositories and **59-87%** when **3 to 5 members** of the team adopt the tool. On the efficiency side, developers save **2-3 h/week** (≈10% of the 24 hours devoted to coding and review), i.e. 20-30 hours/week reinvested for a team of 10. The thesis: resolve Solow's (1987) "productivity paradox" by shifting from **usage metrics** (tokens) to **impact metrics** (throughput, time saved, failure rate, satisfaction). Recommendation: start with a **team** (not an individual) and measure 2-3 months later.
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.