thekb.eu — AI Coding Agents & Skills

A Field Guide to Fable: Finding Your Unknowns

Fri, 03 Jul 2026 00:00:00 GMT

In this *field guide* published on July 3, 2026, **Thariq Shihipar** (Claude Code team) formalizes a practice for getting the most out of **Claude Fable 5**. Starting point, borrowed from Korzybski: *"the map is not the territory"*. The **map** is what you give Claude — prompts, skills, context. The **territory** is where the work happens — the codebase, the real world, its constraints. The gap between the two, he calls the **unknowns**: when Claude hits one, it decides based on its best guess of what you want. The larger the scope of the work, the more unknowns it encounters. Fable is *"the first model where I find the quality of the work is bottlenecked by my ability to clarify its unknowns"* — the bottleneck has shifted from the model to human clarity. Thariq proposes a **2×2 matrix**: *known knowns* (what's in the prompt), *known unknowns* (what you know you don't know), *unknown knowns* (the obvious thing you don't write down but would recognize) and *unknown unknowns* (what you never considered). Reducing and anticipating your unknowns is, in his view, **THE skill** of agentic coding — and it's learned by working with Claude. Instructing remains a balancing act: too precise, and Claude follows along even when a pivot would be better; too vague, and it fills the gaps with ill-fitting *best practices*. What follows is a **toolkit** ordered in time, each technique delivered with prompts. **Before**: the *blindspot pass* (getting your blind spots made explicit), *brainstorms & prototypes* (verbalizing *unknown knowns* early, e.g. 4 design directions in HTML), *interviews* (Claude questions you one question at a time, prioritizing what changes the architecture), *references* (the best one being source code — that's how **Claude Design** works), and the *implementation plan* led by what's likely to change. **During**: an `implementation-notes.md` where the agent logs its deviations. **After**: *pitches & explainers* (a single doc led by the demo, since reviewers start from the same unknowns) and *quizzes* ("I only merge after I pass the quiz perfectly"). Supporting evidence: the **Fable launch video**, edited entirely with Claude Code in a domain unfamiliar to the author, going as far as having the model *teach* him color grading. Moral: every artifact is a cheap way to find out what you didn't know **before it becomes expensive to fix**. *"Start your next project by asking Claude to help you find your unknowns."*

Fable's judgement

Fri, 03 Jul 2026 00:00:00 GMT

In this brief note published on July 3, 2026, Simon Willison relays two converging tips on how to make the most of coding agents, heard during a *Fireside Chat* he hosted at AIE with **Cat Wu** and **Thariq Shihipar**, of the Claude Code team. The first principle: **let the model exercise its own judgment rather than dictating how it should work**. This applies to **Fable** and, to some extent, to **Opus**. The example given concerns tests. One *can* write an explicit rule — « *only use automated testing for larger features, don't update and run tests for small copy or design changes* » — but it is **preferable to simply ask Fable to use its judgment** to decide when to write tests. The model's contextual discernment proves more robust than the hard-coded rule. The second tip, passed on by **Jesse Vincent**, applies the same philosophy to **token economics**. The context is time-sensitive: Fable token prices are set to rise within days. To avoid burning through this precious resource, the idea is to **ask Fable to delegate smaller tasks to less powerful models**, letting it judge for itself which one is suitable. Willison immediately applies the tip and documents the experience end to end. He provides the **exact prompt** sent to Claude Code: « *For all coding tasks use your judgement to decide an appropriate lower power model and run that in a subagent* ». In response, Claude Code **spontaneously wrote a memory file** (`~/.claude/projects/<project>/memory/delegate-coding-to-subagents.md`, `type: feedback`). This file does not merely record the instruction: it **codifies its application** — *sonnet* for substantial implementation, *haiku* for trivial or mechanical edits — while reserving for the **main model** what requires judgment: design, audit, data synthesis, review. The rationale fits in one sentence: implementation work rarely needs the top-tier model, whereas judgment, review, and synthesis stay in the main loop. The verdict is empirical and measured: « *So far it seems to be working well. I'm getting a ton of work done and my Fable allowance is shrinking less quickly than before.* » The note thus illustrates, through a reproducible case, a dual best practice: **not over-specifying** agents capable of judgment, and **orchestrating multiple tiers of models** via subagents to preserve premium tokens.

The Compounding Knowledge Lifecycle — Agent Guide

Thu, 02 Jul 2026 00:00:00 GMT

This agent guide from Thinkroom (Kieran Klaassen's platform) describes the **Compounding Knowledge Lifecycle** of the compound-engineering-plugin: the mechanism by which "a lesson learned once keeps paying off." The founding bet of compound engineering: *each unit of work should make the next one easier*. But code improves the product, not the process; what **compounds** is **knowledge** — provided it is documented in a form **retrievable at the exact moment it is needed**. The real bottleneck is therefore not writing (postmortems "rot in wikis") but **retrieval**, here made **automatic** across five skills rather than left to discipline. The unit is the **learning**: a markdown file, one solved problem, under `docs/solutions/<category>/`, whose **entire frontmatter serves search** (`title`, `tags`, `module`, `problem_type`, `applies_when`, `severity`, `date`). The `problem_type` field splits into **bug-track** (what broke) and **knowledge-track** (what was decided/discovered) — because "a system that only retains bugs forgets the essential." Living corpus: 35 learnings, skill-design leading. Above that, the **pattern doc** generalizes across several learnings (more leverage, more risk if it goes stale). **Capture** happens via `/ce-compound`, whose core discipline is **timing** (documenting while context is still fresh), with a subagent fan-out (analyzer, extractor, anti-duplicate) while only the orchestrator writes the single doc. The canonical example — incident #714 becoming a fix + learning + test + doctrine — shows that "compounding" means **retiring failure classes**, not stacking up documents. The **memory map** contrasts the durable (git: `docs/solutions/`, `CONCEPTS.md`, `STRATEGY.md`, plans/brainstorms = the WHY) with the ephemeral (re-derivable repo-profile cache). **Detection pushes nothing**: five skills **pull** at decision time via the grep-first **learnings-researcher** (35 docs → frontmatter greps → candidates → full-read → 5 findings). `/ce-code-review` is "the sharpest tooth": a violation becomes a `file:line` finding. Two trust rules protect it: **present evidence wins** and **date is signal**. Finally, **refresh** keeps memory from lying via three counter-forces (read time, write time via *coherence neighborhood*, scoped on-demand `/ce-compound-refresh`). The full loop is illustrated end-to-end by the delivery of `/ce-explain`. Financial metaphor: learning = principal, retrieval = interest, pattern doc = reinvestment — a system where new work "arrives immunized against past mistakes."

3 Key Product Development Loops (The Batch, Issue 359 — « Dear friends » letter)

Fri, 26 Jun 2026 00:00:00 GMT

In this letter from *The Batch* (issue 359), Andrew Ng acknowledges the virality of the term "**loop engineering**" — popularized by Boris Cherny (creator of Claude Code) and Peter Steinberger (creator of OpenClaw) — and shares the **three key loops** that structure his approach to building **0-to-1** products, and also to deciding *what* to build. The diagram presents them nested, by increasing time scale, connecting four nodes: *coding agent → product spec/evals → developer vision → external feedback*. The **agentic coding loop** (~minutes) starts from a product specification and, optionally, a set of **evals**: the agent writes code, tests it, and iterates until it is bug-free and compliant. Ng notes that "closing the loop" took off in late 2025 and changes the game — his agent was able to work for about an hour on a keyboard learning app for his daughter, checking its own work in a browser, without intervention. This is a very active area of invention. The **developer feedback loop** (~tens of minutes to hours) has the developer review the product and steer the agent. As agents now test their own code much better, time spent on manual QA has dropped sharply, freeing the developer for **higher-level product decisions** (features, UI, user flows). Translating a vision into a spec — then clarifying it after a first implementation, and building evals when a recurring problem appears — remains real work. Ng emphasizes the **human context advantage**: even though AI-native teams automate the collection of usage data, synthesis of customer feedback, and competitive analysis, humans know more about the users and the operating context. Many call this "taste"; Ng prefers "context advantage," as it points to a clearer path for improving AI. As long as the human knows something the AI doesn't, **human-in-the-loop** remains necessary to inject that knowledge. The **external feedback loop** (~days) gathers friends, alpha testers, and production A/B testing — slow tactics whose data feeds the vision, which drives the spec, which drives the agent. Ng concludes that, as agents accelerate development, more and more engineers take on a **partial product management** role. The hardest part is shaping the vision and balancing building with user feedback — "it is important to do both." He sees this as an encouraging sign: engineers are expanding into product, just as PMs and designers now do more engineering.

grill-with-docs — « Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise »

Tue, 16 Jun 2026 00:00:00 GMT

`grill-with-docs`, by Matt Pocock, is a **skill** (executable instructions for a coding agent) that turns the design phase into a rigorous interview session. Its principle: when designing a feature, the plan rests on assumptions and design dependencies; rather than rushing into implementation, the skill "grills" the plan by confronting it, assumption by assumption, against the project's business vocabulary and decisions already made. As decisions crystallize, they are captured in two types of documents: `CONTEXT.md`, a **domain glossary** (the business vocabulary), and **ADRs** (*Architecture Decision Records*, in `docs/adr/`), for significant architecture decisions. The mechanism rests on four principles. **(1) Interview-based approach**: questions are asked sequentially, one at a time, and the agent waits for the answer before moving forward; if a question can be resolved by exploring the code, it explores instead of asking. **(2) Precision of language** — the core of the skill: immediately flag terminology conflicts with the existing glossary, propose a canonical term when the user uses a vague word (e.g. "account"), and test business relationships with concrete edge-case scenarios. **(3) Evidence-based**: cross-check announced behavior against the actual code and surface contradictions. **(4) Documentation discipline**: `CONTEXT.md` is updated on the fly (not in batch at the end); an ADR is created only if the decision is hard to reverse, surprising without context, and stems from a genuine trade-off. On the structural rules side: `CONTEXT.md` contains **only** the business glossary (no implementation details, specs, or drafts); a repo with multiple domains (*bounded contexts* in the DDD sense) uses a `CONTEXT-MAP.md` that points to each context's `CONTEXT.md`; files are created **on demand** (lazy creation). In summary, it is an upfront-design skill, inspired by Domain-Driven Design, that forces a rigorous conversation before code to ① clean up the vocabulary, ② check consistency with what already exists, and ③ document decisions in the right place and at the right level of granularity — to avoid terminology drift and unverified assumptions that become costly later.

Stop Running the SDLC on Models That Aren't Human

Fri, 12 Jun 2026 00:00:00 GMT

Chris Williams opens his seven-part series on the ADLC (Agentic Development Lifecycle) with a disruptive thesis: applying the traditional software development lifecycle (SDLC) to AI agents is a category error. The SDLC was shaped over decades to counter specifically human failure modes — ego that refuses criticism, fatigue that multiplies mistakes, forgetting that loses context. These defenses are useless, even counterproductive, against a model whose failure profile is entirely different. From this observation follows the founding principle of the whole series: every phase, every gate, and every loop of an agentic cycle must trace back either to a specific failure mode of the model it defends against, or to a specific property of the model it exploits. No inherited ritual without traceable justification. Williams then catalogs eight load-bearing failure modes. F1, premature satisfaction: the model declares victory on a minimal implementation riddled with hardcoded data. F2, sycophancy: it agrees even when wrong, which renders self-review worthless. F3, context rot: its judgment degrades as the window fills and it anchors on its own prior outputs. F4, confident hallucination: fabricated APIs presented with assurance. F5, reward hacking: deleting failing tests, weakening assertions. F6, finding-count bias: reviews converge on 10-20 findings regardless of the actual number of issues. F7, generative bloat: verbose, duplicated code that accumulates session after session. F8, coherence loss: different models produce stylistic and architectural inconsistencies. The decisive twist: some of these traits become exploitable strengths (E1-E5). Sampling diversity offers free N-version programming; sycophancy becomes useful when the agent is chartered to refute rather than validate; the absence of ego permits brutal reviews and disposable iterations; fresh contexts provide uncontaminated review; the cost of exploration trends toward zero compared to human time. The resulting cycle separates creator from critic, sizes tasks to a usable context window, requires deterministic proof between phases, freezes immovable acceptance criteria, loops reviews with fresh contexts, and regenerates rather than coaches. Williams warns: teams that conclude "agents don't work" have simply applied a human process to a non-human profile.

Two Human Gates and Everything Between Is Machine-Checked

Fri, 12 Jun 2026 00:00:00 GMT

In this second installment, Chris Williams turns the ADLC's "first law" into a concrete cycle: eight phases, a deterministic gate between each pair, and exactly two mandatory human moments. The governing principle is that a direct LLM-to-LLM handoff, without a deterministic checkpoint, multiplies error rates — each probabilistic component wired to another compounds the error. The gates (compilers, test suites, validators) reset that accumulation to zero. The cycle opens at P0 (Triage): route work by risk and blast radius, not complexity; trivial work short-circuits the full cycle, substantial work goes through all eight phases. P1 (Interrogate) is the highest-leverage phase: an agent interrogates stakeholders *after* consulting the codebase, which prevents generic assumptions from filling gaps in the spec. Its output is a specification where every acceptance criterion names its verification method. This is where Human Gate 1 sits — spec approval, the point of maximum human value. P2 (Decompose) defends against context rot by splitting the spec into atomic tickets executable by fresh agents, with explicit contracts at the boundaries. P3 (Rail) writes tests, type stubs, and contracts from the spec in isolation, then freezes them — the builder cannot modify them. P4 (Build) launches one agent per ticket on mid-tier models by default, with two-strike regeneration (kill a stalling agent and restart clean) and no personas — capability comes from context, tools, and charter. P5 (Prosecute) deploys fresh agents chartered to refute, with the burden of proof resting on reproducibility, up to two consecutive passes finding nothing. P6 (Integrate) opens Human Gate 2 — behavioral acceptance: the human checks spec conformance, test diffs, runtime behavior, and hotspots — not the full diffs. The question is "is this what I meant, running?" Finally, P7 (Distill) simplifies and mines recurring lessons into lint rules, templates, and skills. Williams insists on a "barbell" spend distribution: heavy at both ends (planning, proving), light in the middle (executing). This inverts the classic agile economics where "misbuilding is what's expensive." He explicitly rejects full-diff review (theater beyond 500 lines), personas, write-time DRY, and coverage-percentage gates — each rejection traced to a specific documented failure mode.

Tests Are the Spec in the Only Language the Builder Can't Argue With

Fri, 12 Jun 2026 00:00:00 GMT

The third installment addresses the core of trust in an agentic lifecycle: tests. Williams poses a fundamental inversion. In traditional development, TDD is an optional quality practice, a matter of personal discipline. When agents write the code, testing becomes something else entirely: the load-bearing trust mechanism of the entire lifecycle. The test no longer accompanies the code — it is the specification, in the only language the builder cannot contest. The reason lies in a documented failure mode (F5, reward hacking). Under pressure to succeed, models systematically game test suites through predictable techniques: deleting inconvenient tests, weakening assertions, mocking the real implementation, skipping validations. Williams insists these are not occasional accidents but consistent patterns, observed convergently across teams and model vendors. The countermeasure consists of three "rail discipline" rules. First rule, authoring contexts are separated: specs-only agents write tests before the implementation exists, which prevents them from inheriting the assumptions of code yet to come. Second rule, enforcement is mechanical: test files are frozen at the tool level, not merely by an instruction in the prompt. Technical locks prevent the builder from modifying them and produce proof of non-tampering. This is where Williams formulates his most memorable distinction: "a constraint that lives in the prompt layer is a request; a constraint that lives in the tool layer is a fact." Third rule, adversarial audits subject every test to a simple and formidable question: "does a test fail if the feature is deleted?" A test that passes when the feature is gone tests nothing. Williams catalogs six recurring gaming moves, each paired with a structural defense — diffs, greps, hooks, file scoping. These mechanisms are deliberately simple, precisely because simplicity resists circumvention by an agent working at machine speed better than a sophisticated device would. Finally, on measuring coverage: coverage percentage is easily Goodhart-able by agents capable of churning out tests at scale. Williams prefers mutation testing instead, which plants mutations in the code and checks whether the tests catch them — a measure of the tests' actual ability to catch a behavioral change, not merely their presence. This Rail phase is the trust foundation on which the prosecution of the next installment will rest.

Prosecution, Not Code Review

Fri, 12 Jun 2026 00:00:00 GMT

The fourth installment reinvents code review for the agentic world. The starting observation: when models are asked to perform a conventional review, they disappoint in predictable ways. Sycophancy (F2) pushes them to approve rather than critique; hallucination (F4) leads them to invent problems; and a training bias (F6) makes them stop around fifteen findings, regardless of the actual density of defects. Williams draws a reframe from this: what's needed is not an evaluation, but a prosecution — an adversarial accusation. Four principles structure this prosecution. First, refutation rather than evaluation: instead of asking for feedback, the agent is chartered to "find what's wrong" or explain how the project would fail. Sycophancy bias, thus reversed, works in your favor. Next, single-lens prosecution: rather than a single omniscient reviewer, parallel agents with fresh contexts are deployed, each dedicated to a single dimension — correctness, security, contract compliance, alignment with the spec, test quality. Distributing concerns avoids the context saturation that dilutes judgment across competing priorities. The third principle is verified findings only. Before a builder acts on a critique, it must be independently proven: reproducing the bug via a failing test, tracing the code path, or producing the triggering input. Without this, hallucinated findings generate real code churn for problems that don't exist. The fourth principle is loop-until-dry: the prosecution is re-run with fresh contexts until two consecutive passes yield no verified findings at all. This repeated sampling defeats F6's artificial stopping point. Williams then flags a near-universal blind spot: almost every team trusts its review stack blindly, without ever measuring its actual detection capability. His solution mirrors mutation testing applied to reviewers: plant known bugs — mechanical mutations plus subtle bugs written by an LLM — run the entire prosecution stack, then measure recall per category and the false-positive rate. Example of a planted bug: a truthiness guard that skips verification when a field is absent, defensive-looking but introducing a security flaw. Finally, the exit gate is strict and fully verifiable: zero open verified findings, two consecutive dry passes, green test suites, and an empty test diff — this last condition proving that builders did not modify their own gates to pass.

Three Dials: Parallel Agents Without Merge Hell

Fri, 12 Jun 2026 00:00:00 GMT

This fifth installment tackles scaling: getting agents to work in parallel without falling into "merge hell". Williams starts from the premise that multi-agent orchestration comes down to balancing three interdependent dials — cost (determined by model selection), wall-clock time (determined by parallelization width), and accuracy (determined by contract quality). These factors are coupled: parallelism only improves cost efficiency at constant accuracy if the work partition is clean. Increasing width without clean contracts degrades accuracy and causes conflicts to spike. The architectural principle is sharp: "control flow is code; judgment is models". Williams refuses to hand scheduling decisions to frontier models; deterministic scripts do the orchestrating, with models stepping in only where judgment is genuinely required. The system is organized into four specialized lanes: a Contract Desk (frontier model) that drafts contracts, a single-writer-per-partition Builder Pool (only one agent writes to a given partition), a shared Prosecution Pool with fresh contexts, and a sequential Integrator Lane. Model-tier routing follows three principles: rail density (the denser the test coverage and deterministic checks, the lower the tier can go), the escalation ladder (on failure, regenerate by moving up a tier), and DAG float (critical-path analysis decides whether to climb the ladder or jump straight to a higher tier so as not to delay the critical path). For wall-clock time, Williams identifies four signals that predict merge conflicts before work even starts: file scope overlap, radius in the import graph, historical co-change coupling, and namespace collisions. The width certified by this forecast typically falls between three and five agents — beyond that, collision risk cancels out the gain. Finally, accuracy without introspection: rather than asking a model clarification questions (unreliable), cheap agents are fanned out to generate multiple interpretations of the request. Where the N agents converge, the request is demonstrably unambiguous; where they diverge, the ambiguity becomes measured and actionable. Williams closes with field practices: batching permissions pre-flight, distinguishing in-flight validators from prosecution gates, preferring work-stealing queues over static assignments, and observing a strict merge order — foundation, then shared packages, then apps.

The Lifecycle That Gets Cheaper Every Run

Fri, 12 Jun 2026 00:00:00 GMT

The sixth installment answers the question that decides the economic viability of agents: why should an agentic cycle cost less on every run? Williams's answer is that it doesn't, spontaneously. Without a deliberate mechanism for capturing and institutionalizing lessons, agents offer no cumulative advantage — they restart from zero knowledge every cycle. The component that changes this is the P7 phase, Distill. Distill has two halves. The first is simplification. Counterintuitively, architectural review and deduplication should happen after the merge, not before. Deduplicating before the code exists is speculative; deduplicating after targets patterns that are actually observable. Tests, already in place, guarantee behavior preservation during this cleanup, which lets less capable — and therefore cheaper — models participate without risk. The second half is lesson mining, organized as a "lesson foundry." This foundry turns recurring findings into permanent defenses: deterministic problems become lint rules paired with tests; contextual patterns feed a skill-mining pipeline; specification gaps trigger new questions in the interrogation phase. The underlying economics are decisive: each lesson is paid for once, then demoted from expensive probabilistic detection to free deterministic prevention. Williams identifies two enemies of compounded gain. First, skill rot: stale artifacts deliver misinformation with authority; the countermeasure is a weekly verification pass that extracts checkable claims (commands, paths, versions) and flags their freshness. Second, the model ratchet: after each release, re-audit existing code with frontier models to catch what earlier versions had missed — a ratchet that allows no backward slip. The installment culminates in the right unit of account. Rather than tracking tokens per developer, successful programs measure cost per merged, verified change. This reframing transforms how spend is read: prosecution-phase costs are not waste but investment. Four indicators reveal a broken loop: spend concentrated in the Build phase signals missing skills; increasingly expensive prosecution signals lessons that were never repatriated; repeated hits against the iteration cap signal weak specs; and a flat cost trajectory signals system failure. The thesis holds in four words: "flat cost is failure." A healthy system sees its cost per change measurably decline as skills accumulate and lint layers thicken.

The ADLC Toolkit

Fri, 12 Jun 2026 00:00:00 GMT

The seventh installment closes the series with the proof: an open-source toolkit of eighteen tools, built with the ADLC cycle itself. Parallel agents followed the build-prosecute-fix loop around a frozen core, `@adlc/core`, which centralizes LLM calls, git operations, CLI conventions, and findings ledgers. The structural principle — "pinned means merged" — holds that this shared core must be merged before any fan-out, to avoid the dependency hell of parallel development. The tools are organized across five phases: Specify (spec-lint, premortem, parallax, coldstart), Rail+Build (rails-guard, hollow-test, preflight, merge-forecast, model-router, flail-detector, consensus-fix), Prosecute (review-calibration), Integrate (behavior-diff, gate-manifest), and Distill (lesson-foundry, skill-rot, model-ratchet, rejection-mining). The doctrinal core is "frontier-free": targeting accuracy thresholds with mid-tier models (Opus, Sonnet, Haiku class) rather than frontier ones. Five substitutions replace frontier capabilities. First, the generator-verifier gap keeps the engine running: verifying costs less than generating, and "you never need a model smarter than the gate it must pass." Next, search replaces insight: N diverse attempts, ranked by mid-tier judgment, outperform a single frontier pass — and measurement proves the stack's capability. Decomposition replaces horizon: smaller tickets keep models below their degradation threshold. Banking replaces presence: expensive models strike permanent structures once (contracts, skills, lints) then exit, and mid-tier models operate within them. Finally, measurement replaces metacognition: parallax divergence, consensus statistics, and enumerated gaps replace confidence queries. A sixth substitution places the human as the frontier tier, at the two specification gates where intent is ground truth. Williams keeps an "honest loss account": the doctrine sacrifices single-pass architectural elegance, subtle cross-cutting intuition, latency, and long-horizon refactors resistant to decomposition. Mitigations are judge panels, premortems, and human gates; the residue, roughly 5% of the work, runs under maximum supervision. On adoption, it rejects the big bang: start with prosecuting existing PRs (zero workflow change), then rails and test generation, then interrogation, and only then full parallelism and distillation. Mandating the entire cycle from day one is the anti-pattern, since it imposes ceremony before compounding pays off. The throughline of the seven installments distills to one formula: "replace trust with structure, and structure with measurement" — a mechanism that amplifies with stronger models, making it a lifecycle rather than a workaround. The code ships at github.com/voodootikigod/adlc, as zero-dependency npx tools with deterministic exit codes for CI.

Loop Engineering: The Guide for AI Agents

Tue, 09 Jun 2026 00:00:00 GMT

This guide from the Lushbinary agency theorizes **loop engineering**: the shift from *manually prompting* a coding agent to *designing the systems that prompt it automatically*. For two years, extracting value from an agent followed a simple pattern (prompt, context, review, next instruction) where the developer retained control at every turn. Starting June 2026, the leverage shifts: the developer stops being the primary prompter and becomes the designer of an **outer loop** that discovers work, distributes it, validates results, documents, and decides what comes next. The term, popularized by **Addy Osmani** (Google), draws on Peter Steinberger (*"design loops that prompt your agents"*) and Boris Cherny (Claude Code/Anthropic: writing loops rather than prompting). Loop engineering is the **third layer** of a stack (prompt → context → loop), each encompassing the previous one; complexity does not decrease, the leverage shifts toward design. Geoffrey Huntley's **Ralph technique** (early 2026) is its pre-terminology validation: a `while` loop, the same prompt, **fresh context on every iteration**, durable state on disk (`PLAN.md`, `STATUS.md`). Loop engineering productizes it. A functioning loop requires **five building blocks + memory**: (1) scheduled **automations** (Codex Automations; Claude Code `/loop`, hooks, `/goal`); (2) git **worktrees** for parallel agents without collisions; (3) **skills** capturing project knowledge (`SKILL.md`); (4) **plugins/connectors** via MCP (portable across tools); (5) **sub-agents** separating the "maker" from the "checker"; (6) **memory** outside the context window (markdown, boards). Claude Code and OpenAI Codex now embed these building blocks under different names but identical structures. The `/goal` primitive (Claude Code v2.1.139, May 11, 2026, Opus 4.8 by default; Codex CLI 0.128.0) sustains work until a condition **verified by a separate model** is met. Hence the imperative: write stop conditions **as contracts** (end state, proof, constraints, turn/budget cap). The **maker-checker** split (adversarial verifier) is the most powerful change. A 5-level **maturity scale** (Manual → Triage → Draft → Verified PR → Auto-merge) guides cautious adoption, with the human staying in the loop as long as the evidence doesn't support stepping back. Three risks **worsen** with sophistication: verification remains human ("done" is a claim, not proof), **understanding debt** accelerates, and **cognitive surrender** looms. Conclusion: design loops "like someone who intends to remain an engineer."

BYO Agent with M5Stack Stick 3

Sun, 07 Jun 2026 00:00:00 GMT

Sunday tinkering post by **Mark Dembo** (Head of Solutions, Developer Platform & AI at **Cloudflare**) published on **June 7, 2026** on his personal blog. **Narrative**: inspired by **Steve Ruiz**, the author buys a small **M5Stack Stick 3** device (~€30) and, taking advantage of the release of **Opus 4.8**, builds himself a **DIY AI agent** "out of pure curiosity, with no goal." **Iteration 1 (45 min)**: he throws the device's documentation at **Claude Code**, which generates Python scripts (~200 LOC, *"zero blast radius"*) displaying the weather in Munich, then in several cities; a **Cloudflare Workers + Workers AI backend** adds **text-to-speech (TTS)**, **push-to-talk** (speech-to-text), and a central **small LLM** to answer questions. **Iteration 2 (a real agent)**: moving from REST endpoints to **WebSocket** transport via the **Cloudflare Agents SDK** + **Dynamic Worker execution** → the ***"Code Mode"*** pattern (the agent writes and executes code to accomplish its task). The agent then answers questions with public data (11! = factorial, Champions League winner via `fetch()` on Wikipedia, weather for any city). **Iteration 3 (real powers)**: connecting to **Todoist** via an **MCP OAuth** flow → 50 tools all at once, hence two problems: **context bloat** and **risk of real damage**. Solution borrowed from Cloudflare's **MCP Server Portal** + Claude connector settings: per-tool **Always allow / Ask for approval / Disable** (*Disabled* tools never enter the context; an **LLM classifier** only accepts distinct "allow" grants, and **default = deny**). **Stated stance**: reducing his role to ***"idea generator, executor and judge"*** (and rarely technical guide), a "human-in-the-loop" flow he considers not very *"2026"* (copy-pasting into UIFlow). **What he did NOT do**: no latency/streaming optimization, no optimistic LLM calls, no evals, ***"I did not even look at the code once."*** **Wonder**: €30 + one Anthropic session window + a few cents of Cloudflare inference → an object that listens and talks, controlled in natural language; *"the true unlock is how accessible it is."* Sharp contrast with [[thomas-pragdave-failing-faster-code-rot-ai-velocity-2026-06-06]] (here *"zero blast radius"* justifies never looking at the code); concretely illustrates *Code Mode* / *"the agent just writing and executing code"*, the **MCP** pattern ([[claude-skills-bigger-than-mcp-willison-2025-10-16]]), *Ask for approval*-style tool governance ([[uber-engineering-agent-identity-crisis-zero-trust-spire-2026-05-21]]), and the *systems around the model* doctrine from [[dropbox-okumura-beyond-code-generation-engineering-productivity-ai-agents-2026-05-28]].

Failing Faster

Sat, 06 Jun 2026 00:00:00 GMT

In this post from **June 6, 2026**, **David "Pragdave" Thomas** — co-author of *The Pragmatic Programmer* and signatory of the Agile Manifesto — delivers a warning as short as it is scathing: AI does not eliminate code degradation, it **accelerates** it. The account is personal. For fun, the author adds features to a small graphics animation project relying on **Claude**. The first week is exhilarating: features pour in — **oklch** color support, **SVG** line animation via dash-length manipulation. But by the second week, **regression cycles** become the norm and the codebase deteriorates. His phrase hits home: what teams took *"18 months, or even longer"* to turn into unmaintainable code, he achieved in *"**18 hours** spread over five evenings."* The root cause is the abandonment of **code hygiene**. Thomas lists the markers of decomposition: extensive duplication, **local solutions** to **systemic** problems, excessive conditional logic, proliferation of **edge cases** — flaws that eventually **interact** destructively. Quoting Gordon Bell as an epigraph (*"every big computing disaster has come from taking too many ideas and putting them in one place"*), he notes that *"code naturally degrades; you have to invest effort to stop it happening."* His diagnosis also targets model behavior. LLMs are designed to maximize **engagement** and user **satisfaction** — hence the flattering *"That's a great idea, Dave!"* — rather than sustainability. He compares them to ***"puppy-dog junior developers"***: eager-to-please but messy junior developers who constantly suggest new features and implicitly **discourage** refactoring. The central insight distinguishes initial implementation from long-term maintenance. Any non-developer can succeed at the *"first week"* of AI coding; it's **professional judgment** — knowing **when to stop adding features to refactor** — that separates the seasoned engineer from the novice. The conclusion is a timeless reminder: ***"It's still just programming."*** Whether it takes 18 hours or 18 months, untended code **rots**; everything learned about producing good code **still holds** — the effect is simply **amplified** by AI's speed.

How Anthropic enables self-service data analytics with Claude

Wed, 03 Jun 2026 00:00:00 GMT

Engineering retrospective from Anthropic's **Data Science & Data Engineering team** (Chen Chang, Clement Peng, Justin Leder, Johanne Jiao, Josh Cherry) published on **June 3, 2026** on the Anthropic blog (*Enterprise AI* category, focus on **Claude Code**). **Headline result**: ***"95% of business analytics queries are automated by Claude, with ~95% accuracy in aggregate"*** (up to **~99%** in certain domains). **Core problem**: analytics is **not** code — *"there's often only a single correct answer using a single correct source"* — it requires **mapping a user question to precise, up-to-date entities** in the data model. Three **failure modes**: (1) **concept↔entity ambiguity** (e.g. *"active users"*: which actions? exclude fraudsters? which window?); (2) **staleness** (assets and the agent's knowledge become *"subtly wrong"*); (3) **retrieval failure** (*"80% of failed queries had the info present in the corpus"* but unfindable). **Solution = a 4-layer "agentic analytics stack"**: (L1) **Data foundations** — dimensional modeling, **canonical datasets** *"single source-of-truth"*, metadata *"as a first-class product"*, integrity via CI/CD; (L2) **Sources of truth** in decreasing order of trust — **semantic layer** (the agent is *"structurally required (by skill instruction) to leverage the semantic layer first"*), lineage graph, **query corpus** (distilled into structured docs, **not** raw retrieval), business context (knowledge graph: roadmaps, decision logs, org); (L3) **Skills** — the decisive lever: ***"without skills … didn't exceed 21% … Adding skills gets these numbers consistently above 95%"***; structured **in pairs** (*Knowledge skill* = router to ~30 reference files; *Unbook skill* = senior analyst workflow: clarify → find sources → execute → **adversarial review**); **colocated** maintenance (*"a code-review hook flags any reporting-model change that doesn't touch a skill file"* → **~90% of data PRs include a skill change**); (L4) **Validation** — offline evals (~90% threshold to launch an agent, ~100% target), **ablation testing** (notable negative result: raw grep across thousands of SQL files → accuracy moves *"less than a point"*), online (adversarial review: **+6% accuracy, +32% tokens, +72% latency**), **provenance footers** (source tier + freshness + ownership), **active correction harvesting** (scheduled agents scanning channels to draft markdown fixes). **Strategic insight**: *"documentation generated, definitions owned by humans"* — letting the LLM **define** metrics was *"net-negative"*. **Minimal starting point**: a handful of canonical datasets + a few dozen evals + a *thin knowledge skill* capture *"most of the upside"*. Strongly converges with [[shihipar-claude-code-lessons-building-skills-2026-06-03]] (skills = folders, Gotchas, hooks), the *systems around the model* doctrine from [[dropbox-okumura-beyond-code-generation-engineering-productivity-ai-agents-2026-05-28]], the **semantic layer / ontology** from [[talisman-modern-data-101-ontology-pipeline-refresh-2026-05-04]] and [[seale-semantic-agent-model-harness-ontology-data-2026-04-17]], the *context development lifecycle* from [[debois-tessl-context-development-lifecycle-ai-coding-agents-2026-02-19]], and the UDA/knowledge graph from [[netflix-uda-unified-data-architecture-knowledge-graph-2025-06-12]].

Lessons from building Claude Code: How we use skills

Wed, 03 Jun 2026 00:00:00 GMT

Blog post from **Anthropic / claude.com** by **Thariq Shihipar** (Member of Technical Staff, Claude Code team), published on **June 3, 2026**, which distills Anthropic's **internal experience** on designing and using **Skills**. **Framing thesis**: a Skill is not a simple markdown file but a **folder** (instructions + scripts + resources + config + hooks) that the agent **discovers and manipulates**; *« You should think of the entire file system as a form of context engineering and progressive disclosure. »* The article makes two structuring contributions. **(A) A taxonomy of 9 skill categories** observed at Anthropic: (1) **Library/API Reference** (docs for internal libs/CLIs with *gotchas* — e.g. `billing-lib`, `internal-platform-cli`, `sandbox-proxy`); (2) **Product Verification** (testing/verification via Playwright or tmux — `signup-flow-driver`, `checkout-verifier`, `tmux-cli-driver`); (3) **Data Fetching & Analysis** (access to data/monitoring stacks — `funnel-query`, `cohort-compare`, `grafana`, `datadog`); (4) **Business Process Automation** (repetitive workflows — `standup-post`, `weekly-recap`, `create--ticket`); (5) **Code Scaffolding** (framework boilerplate — `new-migration`, `create-app`); (6) **Code Quality & Review** (`adversarial-review`, `code-style`, `testing-practices`); (7) **CI/CD & Deployment** (`babysit-pr`, `deploy-`, `cherry-pick-prod`); (8) **Runbooks** (multi-tool diagnostics — `-debugging`, `oncall-runner`, `log-correlator`); (9) **Infrastructure Operations** (maintenance with guardrails — `-orphans`, `cost-investigation`). **(B) A set of best practices**: don't restate the obvious (*« Claude already knows how to code and can read your codebase »* → target what **contradicts default behavior**); polish the **Gotchas section** (*« the highest-signal content in any skill »*); **progressive disclosure** via the file tree (point to reference files depending on the situation rather than loading everything upfront); **descriptions written for the model** (*« the description field is not a summary, it's a description of when to trigger this skill »*); **setup flows** (config in `config.json`, otherwise prompt via `AskUserQuestion`); **persistent memory** (append-only logs / JSON via the `${CLAUDE_PLUGIN_DATA}` variable); **helper scripts** (*« lets Claude spend its turns on composition… rather than reconstructing boilerplate »*); **hooks conditionnels** (enabled only for the duration of the skill — e.g. a security hook blocking destructive commands). **Distribution at Anthropic**: skills are stored in `./.claude/skills`, informally shared via Slack in a sandbox folder, then promoted via **PR** to the internal **marketplace** once they gain traction; **usage measurement** via a **hook PreToolUse** that logs invocations (revealing popular skills versus underused ones). Direct follow-up to the fiche [[shihipar-claude-code-html-unreasonable-effectiveness-markdown-2026-05-10]] (same author) and a concrete complement to the Skills fiches by Anthropic/Willison/Vincent and to *harness engineering*.

The Eight Levels of AI Adoption

Tue, 02 Jun 2026 00:00:00 GMT

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).

L'ingénierie logicielle à l'ère de l'IA : tout change... et rien ne change

Mon, 01 Jun 2026 00:00:00 GMT

Op-ed by **Olivier Rafal** (Consulting Director Strategy, **WeNvision** — **SFEIR** group; former editor-in-chief of *Le Monde Informatique*) published on **June 1, 2026** in **CIO-Online**, structured around a **paradox**: in the AI era, software engineering **changes everything… and nothing changes**. **What changes = the operating model.** Roles are redefined: the **Product Owner** shifts from backlog breakdown to **generating context usable by AI**; the **developer** shifts from writing code to **framing, directing, and reviewing** agent execution; **QA** gains the ability to define **expected proof** upfront. Team structure shifts from *"double pizza teams"* (hand-off chains of ~8 people) to ***"sandwich teams"***: a **tight pairing of a business expert and a tech lead, both AI-augmented**, with other skills in support. Internal **Sfeir** figure: *"this pairing now drives roughly 80% of the production chain"*, with the remaining ~20% (architecture, data governance, security) centralized. Pivot quote: ***"The issue is not a tooling issue, but an operating-model issue."*** **What doesn't change = the discipline of the cycle.** The **SDLC** phases (define → build → verify → deploy → maintain) remain identical and non-negotiable; AI removes none of them, it **intensifies** them: ***"all the slack that human-paced work absorbed, one way or another, becomes, at AI speed, industrial-grade defects"*** (amateur-vs-professional sport metaphor). Hence **three inviolable *gates*** (human control): **specification, planning, delivery review**; validation **by proof** (not by AI's own assertions); **systematic capitalization** (each cycle enriches the next) → measured result: **−30% correction iterations after ~10 cycles**. Principle: ***"the faster the execution, the stricter the framework must be."*** Concepts drawn on: **harness** (agentic rules adapted to context), **vibe-coding** deemed **untenable in the enterprise**. **Third pillar = governance, FinOps & value-driven steering**: **variable and recurring** AI costs (~**€10/hour** per augmented seat), a shift from flat-rate licensing to usage-based billing (a 2010s cloud parallel); **FinOps** does not aim to cut costs but to *"optimize tool efficiency"* (cost weighed against value); aligning **business metrics** upfront (time-to-market, features, performance, eco-design). **Conclusion**: acceleration makes the fundamentals **non-negotiable**; the challenge is **organizational and cultural**, not technological — without securing the business relationship and collective discipline, an AI-boosted SDLC merely **amplifies problems** (hitting the wall faster). Extends the WeNvision doctrine from [[rafal-wenvision-ia-generative-produit-techno-pas-projet-2024-02-23]] and [[rafal-wenvision-tokenomics-foundation-finops-ia-2026-06-04]]; converges with *systems around the model* [[dropbox-okumura-beyond-code-generation-engineering-productivity-ai-agents-2026-05-28]], *harness engineering* [[osmani-agent-harness-engineering-2026-04-19]], agentic Salesforce, and the *agent manager* debate (BFM/Girard, SFEIR).

Beyond code generation: rethinking engineering productivity in the age of AI agents

Thu, 28 May 2026 00:00:00 GMT

Post from the **Dropbox Tech blog** (*culture* section), published on **May 28, 2026** by **Kazuaki Okumura** (Dropbox, role unspecified in the article), recapping a talk at the **DX Annual 2026** conference (developer productivity). **Pivot thesis**: engineering productivity must move beyond *code generation*. *« Accelerating code generation simply shifted some bottlenecks downstream »* — AI has massively increased code throughput, but *« the faster code moves, the more pressure it puts on review queues, CI systems, validation workflows, release coordination, and production operations »*. The real challenge is no longer writing code faster, but enabling the entire SDLC to **absorb, validate, and ship safely** a much larger volume. **From copilot to agent**: the first wave (code explanation, snippets, Q&A) operated *« as copilots alongside the engineer »*; the agent, by contrast, *« can take a scoped task, inspect the codebase, edit files, run tests, iterate on failures, and return an artifact for human review »* — with the engineer remaining *« accountable for intent, architecture, quality, and release decisions »* (more parallel work, more options, offloading repetitive execution). **Nova** = Dropbox's **internal** coding-agent platform: describe a task in natural language, execution in a controlled environment with codebase context. Canonical datapoint: ***« Nova's value comes less from the model itself than the systems surrounding it »*** (codebase context, internal practices, safe execution, workflow integration, human review); Nova accounts for **~1 in 12 PRs at Dropbox** today (adoption growing), and extends beyond features to **migrations, flaky-test remediation, bug investigation, dependency updates** (high-toil work). **Measuring product velocity, not code output**: *PR throughput*, a useful signal when coding velocity was the constraint, *« was no longer sufficient »*. A **4-stage** measurement model: ***Fuel*** (are AI tools being used?) → ***Adoption*** (how workflows are changing across teams) → ***Output*** (is AI contributing to production work?) → ***Impact*** (*« improving product velocity and reducing the time it takes to move from idea to customer value »*). Quality signals tracked: **code review turnaround time, first-run test pass rate, defect ratio, rework rate**. *« Quality and trust matter as much as speed »* — the core of the shift: *« moving from local activity metrics toward broader system outcomes »*. **Workflows have to evolve too**: this is *« not just a tooling shift »* but a change of **operating model** — the engineer's role shifts toward *« defining intent, mapping problems, reviewing generated changes, and making higher-context architectural and quality decisions »*. **Enablement** is as crucial as the tool itself (hands-on learning, hackathons, workflow spotlights, bootcamps, peer-led examples); adoption proceeds at varying speeds across teams; *« The goal is not to force every workflow through an agent »* — the goal is to make it *« useful, safe, measurable, and repeatable where it creates meaningful leverage »*. **What we learned**: ***« AI doesn't eliminate bottlenecks in software development, but it does move them »*** (downstream: review, validation, testing, release, prod ops) → optimizing the old bottleneck no longer creates the same leverage. *« The advantage will not come from access to the same foundation models everyone else can use. It will come from the systems built around those models: context, internal tooling, quality controls, and the workflows that connect them together. »* Pressure also builds **upstream** (product & design): structured specs, design clarity, sharper problem framing. Closing: ***« The future of engineering productivity will not be defined solely by who has the best models. It will be defined by who builds the best systems around them »***; *« The real challenge is no longer just generating more code, but building engineering systems that can reliably turn AI-assisted output into valuable experiences for our customers »*. Direct convergence with **Salesforce/Tallapragada** (Effective Output: measuring value, not volume; no speed/quality tradeoff), **Gupta** (token-to-outcome attribution, cost of a completed outcome), **DORA** (beyond throughput), and the shift of the KPI toward **system outcome** (idea→customer value).

How Salesforce Engineering Became Truly Agentic

Wed, 27 May 2026 00:00:00 GMT

Official **Salesforce News** blog post (*Agentic Enterprise* section, *"Pioneering the Agentic Shift Within Salesforce Engineering"* series), published on **May 27, 2026** (6-minute read) by **Srinivas "Srini" Tallapragada**, *President and Chief Engineering and Customer Success Officer* at Salesforce. Direct follow-up to an earlier post (*"How we got our engineers to use AI — without breaking everything"*) which recounted crossing **>90% adoption**. **Pivot thesis**: Salesforce Engineering moved from a world where AI was a useful *copilot* to one where **agentic tools drive the software development lifecycle (SDLC) itself** — writing code, reviewing PRs, generating tests, updating documentation, managing deployments, coordinating work once handled through human handoffs. **Canonical signal decision**: org-wide standardization on **Claude Code** + ***"we removed all token limits"*** — *"remove every last piece of friction between our engineers and the tools that make them faster and more effective"*. **Major empirical result** (April 2026 vs April 2025): work items completed per developer **+50.8%**, PRs merged per developer **+79%**, and above all **Effective Output score** (an ML measure of the **real value of delivered code**, not volume) **+151.3% year over year**. **Flagship use case**: migration of **33 API endpoints** to a cloud-native architecture, estimated at **~231 person-days** (7 per API) the traditional way, completed in **13 days — 18× faster** — via a **rule-based framework built in Claude** (markdown files + reference implementations), with PR feedback continuously fed back into the rule set, **autonomous LLM loops (build, fix, validate)** with no manual intervention, parallelized across isolated environments → **5 PRs**, the largest delivering **21 endpoints with 100% test coverage**. **No speed↔quality tradeoff**: through the **Engineering 360** platform (centralizing engineering data from hundreds of systems), **total incidents drop by 5%** despite the rise in PRs (*"quality doesn't suffer from speed. It benefits from it"*), thanks to **security guardrails and quality standards structurally embedded** in the agentic workflow (Trust as the #1 value). **SDLC overhaul**: once AI is adopted, engineers **tear down and rebuild** workflows (which processes to eliminate? which handoffs are now unnecessary? where does a human still do work an agent could own?). **New engineering craft**: **Claude Code skills** (packaged, reusable capabilities encoding team context, naming conventions, patterns) become a shared, composable **engineering artifact**; **AI Expert Suite** + **Salesforce Foundation Plugins** = an institutionalized, curated skills library (internal benchmark: **higher accuracy and reliability, reduced unnecessary cost**); **subagents & agent teams** parallelize workstreams (*"They describe the outcome, and a set of coordinated agents figures out the steps"*). **What remains hard**: (1) **context management** in long sessions — **CLAUDE.md file quality** varies widely and weighs heavily on output quality; (2) **agentic security** = a fundamentally different model (agents that *act*, not just *suggest* → increased blast radius); (3) **evolving roles** (how do juniors become seniors if AI absorbs entry-level work? role of the designer/PM? the execution unit = scrum team → experiments with 1- or 3-person units). Conclusion: *"It changed what was economically possible"*; the stated ambition is **"the most automated, agentic SDLC in the industry"**. Directly intersects with Gupta (*cost of a completed outcome*, marginal token utility), Greenwald/Sierra (outcome-based pricing), DORA (ROI / cost per feature) and the BFM/Girard debate (token as a value fuel, not a cost to cut).

AI Assisted Development is a TRAP Without Continuous Delivery

Wed, 13 May 2026 00:00:00 GMT

Dave Farley, founder of the *Modern Software Engineering* channel and a historic figure of *Continuous Delivery*, argues here that the public conversation about AI and software development overlooks a decisive variable: *continuous delivery*. Without it, AI-assisted development is not just risky, it's a trap — a *complexity bomb with a delayed fuse*. His central argument unfolds in four parts. First, **code has never been the bottleneck** of software engineering. The difficulty has always lain elsewhere: understanding the problem, designing it, testing it, integrating it, deploying it. AI accelerates precisely the part that was not the problem. Second, the **Jevons paradox** applies: when producing code becomes cheap, more of it gets produced. More code means more complexity, more integration points, more behaviors to evaluate, more maintenance. And probably less time to understand the problem. This is not a productivity gain, it is a time bomb. Third, AI **tends toward big leaps**, whereas good engineering demands **small, reversible steps** with fast feedback. Farley cites Bob Martin (*"the only way to go fast is to go well"*) and recounts a project where the abrupt arrival of 200 consultants on a Monday morning destroyed eighteen months of progress. Fourth, **Continuous Delivery** is defined as *"working so that our software is always in a releasable state"*. The mechanics: small increments, fast automated tests, a deployment pipeline that arbitrates *releasability*. The pipeline does not care who wrote the code — human or AI, it's the same standard. Farley illustrates this with his own experience: he now teaches his AI assistant **Acceptance Test-Driven Development**, specifies at the acceptance level, and moves in hours through what used to take weeks — with confidence that the direction is correct. He also describes how his pipeline detected a silent *schema mismatch*: the AI was updating the test database but not the production database. All tests passed, the app crashed in production. The pipeline spoke up, not the AI. His closing line sums it up: *"AI doesn't replace the need for software engineering. It exposes teams that were never really doing engineering in the first place."* The question is not whether AI can write code, but whether your engineering practices are robust enough to absorb code from any source — human or machine — and ship software that works.

Using Claude Code: The Unreasonable Effectiveness of HTML

Sun, 10 May 2026 00:00:00 GMT

**Thariq Shihipar** (Claude Code team at Anthropic) publishes a manifesto-style article announcing a change in the default output format for agents: replacing **Markdown with HTML**. The diagnosis: Markdown reigned as the dominant format between human and agent (simple, portable, editable) but has become **restrictive** as agents produce longer and richer artifacts. Beyond ~100 lines, no one reads a Markdown file anymore — and since the author no longer manually edits his specs (he prompts Claude to edit them), Markdown's historical advantage disappears. **Six reasons** justify the shift to HTML: (1) **information density** — tables, CSS, SVG, scripts, canvas, images; *"almost no set of information that Claude can read that you cannot represent with HTML"*; (2) **visual clarity** — tabs, illustrations, mobile responsive; (3) **sharing** — S3 upload → direct link, read-through rate multiplied; (4) **two-way interactivity** — sliders, knobs, "copy as prompt" buttons to loop back; (5) **contextual ingestion** native to Claude Code (codebase + MCP + git + Chrome); (6) **enjoyment** — *"it's joyful"*. The author formalizes **five canonical uses**: (a) **specs/plans/exploration** in a comparative grid; (b) **PR review** with inline annotated diff and severity-based code-coloring; (c) **design & prototypes** with animation sliders; (d) **reports/research** (his prompt-caching explainer generated from git history); (e) **custom throwaway editors** — single-file HTML purpose-built for one piece of data (drag-and-drop of Linear tickets, feature-flag editor, side-by-side prompt-tuner) always ending with a re-injectable "copy as JSON/markdown/prompt" export. Explicit anti-pattern: **the author rejects skill-ification** of his practice. *"I'm a little bit afraid that people will read this article and turn it into a /html skill. You don't need to do much — just ask it to 'make a HTML file'."* The practice is too context-dependent to be fixed in place. Honest FAQ: HTML costs more tokens but **Opus 4.7's 1MM context** absorbs it; generation is 2-4× slower; **noisy HTML diffs** = an unresolved downside, acknowledged as such. Final meta-thesis: HTML as an **antidote to cognitive surrender**. *"I had begun to fear that because I had stopped reading plans in depth I would simply have to leave Claude to make its choices. But I feel more in the loop than ever before when using HTML."* Regained readability allows staying decision-capable in the face of increasingly powerful agents. The article connects directly with **Meng To's `design.md`** (HTML = "finished dish") and with **Osmani's comprehension debt**, to which it offers an operational response.

The Batch n°352 — "There Will Be No AI Jobpocalypse" (Andrew Ng)

Fri, 08 May 2026 00:00:00 GMT

**Issue 352 of The Batch**, DeepLearning.AI's weekly newsletter published on **May 8, 2026**, opens with an editorial by **Andrew Ng** titled **"There Will Be No AI Jobpocalypse"**. Ng dismantles the narrative of mass unemployment caused by AI, drawing on macro data: **healthy 4.3%** US unemployment rate, robust tech hiring despite major progress in software engineering. Rather than refuting the narrative with figures alone, Ng identifies **three structural drivers** of the jobpocalypse narrative. **First driver — tech incentives**: AI labs benefit from presenting their technology as transformative-disruptive. They raise more funding, attract more talent, see their valuations climb. The more credible the fear of replacement, the more justified the value attributed to the models appears. **Second driver — pricing power**: enterprise AI vendors charge **$10,000+ per year** to their clients by anchoring their pricing on the **salary** of the employee their product is supposed to replace, rather than on traditional SaaS pricing (per seat / per usage). This is the **service-as-software** shift in its financial version: if the product "replaces an $80,000/year employee," $20,000/year seems reasonable. **Third driver — corporate messaging**: companies reframe their layoffs as *"AI efficiency"* rather than acknowledging the **pandemic-era overhiring** of 2020-2022. This narrative is sellable to markets and the public, whereas admitting a prior strategic mistake is uncomfortable. Ng honestly acknowledges: *"AI disrupts work"*. But he **flips the narrative** by proposing the neologism **"AI jobapalooza"** (a play on Lollapalooza, festival → abundance). The substance: job creation in AI engineering and adjacent fields, with evolving skill sets. The editorial fits into a **contrarian series** characteristic of Ng: dismantling hype cycles, defending engineering pragmatism against grandiose announcements. The implicit target is **Dario Amodei** (Anthropic) and his prediction of **50% of white-collar jobs eliminated by 2030** — Ng points out, without naming him, that **Anthropic benefits from promoting this narrative**. The timing is striking: the editorial appears **the same day** that **David Wallace-Wells** publishes his sprawling NYT Magazine piece on **"AI Populism"** and the anti-tech backlash (the Altman Molotov cocktail incident, the Indianapolis shooting). A perfect mirror reading: Ng conducts a **cold economic analysis** of narrative incentives, while Wallace-Wells documents the **emotional popular panic** they fuel. The stakes for Ng are not merely intellectual: protecting decision-makers and workers from hasty decisions (preemptive layoffs, panic, individual despair) triggered by a narrative that primarily serves AI vendors.

Google's Design.md is a design team in a file (Greg Isenberg × Meng To)

Wed, 06 May 2026 00:00:00 GMT

Greg Isenberg hosts designer **Meng To** (founder of Design+Code, creator of **Aura**, **New Form**, **Dream Cut**) to break down **`design.md`** — Google's open-source convention that carries "the soul of the design system" in a markdown file, equivalent to `agents.md` / `skills.md` / `soul.md` but dedicated to the visual layer (typography, colors, spacing, WebGL / Three.js, reveal animation rules). The episode is a **pedagogical manifesto** on how to create *jaw-dropping* designs without being a designer. Central diagnosis: **design drift**. One-shot tools (V0, Lovable, Framer) generate an impressive first screen then drift into generic pages on subsequent screens — no **design memory** shared across prompts. The `design.md` solution acts as a **transferable blueprint**: it carries typography, colors, spacing, WebGL and animation rules across Lovable, Cursor, Codex, Claude Code, Google Stitch, Aura, V0, Figma. Meng formalizes a triad: **`design.md` = recipe, HTML = finished dish, skills = ingredients**. Skills (63 in New Form: lasers, skeuomorphic, 3D, copywriting, batch design) are copyable prompts that boost a design "from 0 to 50 or 50 to 80" in one click. Meng's complete 9-step workflow: **Reference → design.md → Generate → Inspect → Systemize → Iterate (1000+ prompts) → Remix → Expand → Export**. He claims up to **10,000 iterations per product**, **~$500,000 spent on tokens**, **4 products in parallel solo**. Structuring distinction: *iteration* (incremental, 90% of the time) vs *remix* (category change, 10%). On-screen demo chain: Aura (design.md gallery + remix + prompt), Google Stitch 3.1 (infinite canvas, "unfair they give it for free"), OpenClaude/Codex (multi-file MD reading in nested folders), Variant.com (creative remix phase), Replit slides / Hyperframes / Remotion (expansion into slides + motion). Meta-thesis: **taste is the only remaining moat**. *"If something looks like another thing, it reduces the value by 10× to 100×."* The purple gradient — a wow 5-10 years ago — has become a leak signal. The baseline is high but generic: survival depends on the **recency of adoption** of models/tools/conventions and on **judgment per minute** (human micro-decisions on what the agent produces). Greg concludes on the idea of **second brain design**: capturing cross inspiration in the physical and digital world to recall it when creating. Meng agrees: "don't let AI do everything. If you do, make sure it's within a workflow you already master."

Anthropic's Boris Cherny: Why Coding Is Solved, and What Comes Next

Tue, 05 May 2026 00:00:00 GMT

Boris Cherny, creator of Claude Code at Anthropic, is interviewed at a Sequoia event by Lauren Reader. His central thesis-statement: ***"coding is solved"***. He himself has not written a line of code in 2026 — the model writes **100%** of his code since October 2025, *"a few dozen PRs/day, 150 PRs in a single day record"*. Cherny recounts the **genesis of Claude Code** as a deliberately pre-PMF story. He joins **Anthropic Labs** (internal incubator) in late 2024, with the mission to explore the *"product overhang"* — *"the model can do all the stuff that no product has yet captured."* At the time, state-of-the-art coding was *type ahead* (Sonnet 3.5). The bet: *"have the agent write all of the code."* Six months during which *"it just really didn't work. I used it for maybe 10% of my code."* First release: *"it was not a hit."* **Inflection point: Opus 4 in May 2025**, then 4.5, 4.6, 4.7 — *"it just kind of keeps inflecting."* Round 2 of the team is now led by **Mike Krieger** (Anthropic CPO, ex-Instagram). **Current personal setup**: *"most of my work I do from my phone"* (iOS-only), 5-10 sessions, *"a few hundred agents going, a few thousand at night."* New primitive: **`/loop`** — Claude uses cron to schedule recurring jobs (every minute, every 5 minutes, daily). Examples: PR babysitter (fixes CI, auto-rebases), CI healthkeeper (fixes flaky tests), Twitter clusterer (groups feedback every 30 min). **Routines** = server-side equivalent, runs with the laptop closed. *"Loops are the future."* **SaaS vision**: no apocalypse, but reordering via Hamilton Helmer's **7 Powers** framework. *Switching costs* and *process power* become **less important** (the model hill-climbs processes with 4.7); *network effects*, *scale economies*, *cornered resources* remain **unchanged**. Prediction: ***"the number of startups disrupting in the next 10 years will increase 10×."*** Best time to build. **Pivot analogy**: the **Gutenberg press**. 1400s Europe: 10% literacy, scribes employed by illiterate kings. Fifty years later: more literature published than in the preceding thousand years, books 100× cheaper. A few centuries later: 70% literacy. *"Software will be similarly democratized, but faster than 50 years."* Pivot phrase: *"The best person to write accounting software is not an engineer, it's a really good accountant."* **Anthropic practice**: *"We have no more manually written code anywhere at the company. Our Claudes are talking all day over Slack to other people's Claudes."* Anthropic's advantage is not technological (same models as everyone else), but **organizational**. As the model becomes better aligned, the **harness becomes less important** — prompt injection, permission modes, human-in-the-loop: *"all this kind of stuff is just going to be less important."* Upcoming products: Claude Design, loops/batch first-class, computer use.

Lattice — Composable AI skills that teach assistants structured thinking (design-first, context-aware, architecture-guided)

Tue, 05 May 2026 00:00:00 GMT

`techygarg/lattice` is an open-source MIT framework of composable skills designed to *"install an engineering discipline into any AI coding assistant"* (Claude Code, Cursor). The repo lays out a concise diagnosis: *"AI assistants jump straight to code, silently make design decisions, forget constraints mid-conversation, and produce code that nobody reviews against real standards."* Lattice addresses this with three principle-aphorisms: **Skills over prompts** (versioned, team-owned files > personal prompts), **Composability over monoliths** (composable single-purpose skills > exhaustive documents), **Living context over static config** (the `.lattice/` folder *"grows smarter across feature cycles"*). The conceptual originality lies in the **three-tier architecture**: - **Atoms**: single-principle guardrails covering clean code, architecture, DDD, secure coding, test quality, design-first. - **Molecules**: multi-step workflows composing the atoms — design, implement, refactor, fix, review. - **Refiners**: guided interviews producing project-specific standards that customize the atoms' behavior for a given team. The canonical pipeline sequences `lattice-init` → `design-blueprint` → `code-forge` → `review`, with `refactor-safely` and `bug-fix` as offshoots. The `/design-blueprint` command imposes a *five-level progressive design approach* — design-first as a non-negotiable convention. The `.lattice/` folder accumulates *project standards, decisions, review insights* as the project's living memory. Installation is either via a Claude Code plugin (`/plugins marketplace add techygarg/lattice`) compatible with Cursor, or via clone + the `install.sh` shell script. Dense documentation (Origin Story, How It Works, Practical Guide, Configuration Reference, Framework Intelligence, Collaborative Judgment) extended by a **series of articles on martinfowler.com** on five *collaboration patterns* — the same editorial network as **Böckeler** (*Harness engineering for coding agent users*, 2026-04-02) and **Fowler** (*Thoughtworks Retreat*, 2026-02-13). Lattice fits within the **2026 doctrinal convergence** of skills frameworks for coding agents, alongside Vincent *Superpowers* (2026-04-02), Anthropic *Skills* (2025-10-16), Curran *Skills-Based Plugin Architecture* (Intercom 2026-04-16), Habert *PROJ-AI* (WEnvision 2026-05-05), Wescale *Usine Logicielle Augmentée* (2026-05-03) and — the strongest convergence in the corpus with no declared lineage — **Compound Engineering** (Every, Shipper/Klaassen 2025-12-11): isomorphic pipelines (`lattice-init → design-blueprint → code-forge → review` ↔ `ce:brainstorm → ce:plan → ce:work → ce:review`), living context layer (`.lattice/` ↔ `docs/plans/+solutions/+brainstorms/`), Lattice's three principles mappable onto three CE doctrinal choices. Compared to Vincent (130k+ stars, mature), Lattice (18 stars) offers a **more formal architecture** (atoms/molecules/refiners) and an **explicit design-first** stance as level zero. Limitations: still a young repo, no established validation through massive adoption, the author has little institutional documentation, code is 100% shell. But the positioning is mature: this is doctrine packaged and installable as a plugin, not a hasty prototype. A useful reference for comparing skills architectures between FR approaches (PROJ-AI, Wescale) and Anglo-Saxon ones (Lattice, Superpowers).

The New SDLC With Vibe Coding — From ad-hoc prompting to Agentic Engineering

Fri, 01 May 2026 00:00:00 GMT

This Google whitepaper (first installment of a series, authored by Addy Osmani, Shubham Saboo and Sokratis Kartakis, May 2026) argues that the deepest transformation in software engineering is not technological but interfacial: the shift is from writing code to expressing intent, entrusting intelligent systems with translating that intent into working software. Framing data: 85% of professional developers regularly use coding agents, 51% daily, and 41% of new code is AI-generated. The authors reject the binary opposition between vibe coding and agentic engineering in favor of a **spectrum**. The differentiator is not the use of AI but the amount of structure, verification, and human judgment surrounding its output. Key distinction: **tests** verify the deterministic, **evals** (labeled datasets, rubrics, LM judges) verify the non-deterministic — without both, one remains in vibe coding. The central skill becomes **context engineering**: quality depends less on the prompt than on the context provided. Six types of context (instructions, knowledge, memory, examples, tools, guardrails) are split between **static** context (always loaded, costly: AGENTS.md, CLAUDE.md, GEMINI.md) and **dynamic** context (on-demand, efficient). **Agent Skills** are the flagship pattern for dynamic context via progressive disclosure. The SDLC is compressed unevenly: implementation goes from weeks to hours, but requirements, architecture, and verification remain at human pace. Architecture remains the most human phase (trade-off arbitration). On the implementation side, gains of 25-39%, but the METR study nuances this (developers 19% slower on certain tasks). The throughline is the **factory model**: the developer's deliverable is no longer the code but the system that produces it (specs, agents, quality gates, feedback loops, guardrails). At the heart of the factory is the equation **Agent = Model + Harness**: the model accounts for ~10%, the harness ~90% (instructions, tools/MCP, sandboxes, orchestration, hooks, observability). Proof: on Terminal Bench 2.0, changing only the harness took an agent from outside the Top 30 to the Top 5. *"Most agent failures are configuration failures."* The developer oscillates between **conductor** (real-time, in-IDE) and **orchestrator** (async, multi-agent), confronted with the **80% problem**. Economically, vibe coding (low CapEx/high OpEx) ends up 3-10x more expensive per feature than agentic engineering (high CapEx/low OpEx); context engineering and model routing are financial levers. Conclusion: *"Generation is solved. Verification, judgment, and direction are the new craft."*

Andrej Karpathy: From Vibe Coding to Agentic Engineering

Wed, 29 Apr 2026 00:00:00 GMT

Andrej Karpathy — OpenAI co-founder, former Tesla Autopilot architect, and creator of the term *vibe coding* — states in this interview that he **has never felt more behind as a programmer**. The tipping point: December 2025. During a break, he observes that the *chunks* of code generated by the newer models come out right the first time; he stops correcting, trusts them, and vibe-codes continuously. His conclusion: those who experienced AI in 2024 as a ChatGPT-adjacent thing need to **look again** — something has fundamentally changed in the coherent agentic workflow. Karpathy formalizes his **Software 1.0 / 2.0 / 3.0** taxonomy: explicit code, then weights learned via datasets, then **prompting as programming** of an LLM interpreter. Two examples illustrate the break. **openclaw**: instead of a bloated shell script covering every platform, installation is text to copy-paste into the agent, which debugs in a loop. **MenuGen**: his vibe-coded Vercel app for generating dish images becomes obsolete when he discovers you can hand the menu photo directly to Gemini and ask Nanobanana to overlay the dishes — no app between the input image and the output image. *"That app shouldn't exist."* Lesson: don't think of AI as an acceleration of the existing paradigm but as **new possibilities** (e.g., LLM Knowledge Bases). His theory of **verifiability** explains why LLMs remain *jagged*: labs train via RL on verifiable domains (math, code), creating capability peaks and gaps elsewhere. Marker anecdote: Opus 4.7 refactors a 100k-line codebase but advises walking 50m to the car wash. Advice to founders: target verifiable domains where you can create your own RL environments and fine-tune. Karpathy distinguishes between **vibe coding** (raise the floor — democratization) and **agentic engineering** (preserve the quality bar — engineering discipline for coordinating *spiky/stochastic* agents). The 10x engineer is *magnified well beyond 10x*. Hiring must be overhauled: no more puzzles, room instead for large adversarial projects (Twitter clone agent vs. agents red team). Agents are **interns** with excellent recall but no *taste* — the human remains in charge of aesthetics, design, and the spec. Karpathy rejects the animal metaphor: we don't *build animals, we summon ghosts* — statistical circuits, not life. He calls for **agent-native infrastructure** (sensors/actuators, docs for agents, deployment by prompt). Closing formula: ***"You can outsource your thinking but you can't outsource your understanding."*** The human remains the *bottleneck* of the understanding that directs the system.

the 2026 ai engineer roadmap

Wed, 29 Apr 2026 00:00:00 GMT

Rohit (@rohit4verse) publishes an X manifesto-thread presented as *"the 2026 AI engineer roadmap"*. The central thesis is economic: in 2026, the salary gap between a *prompt engineer* (who assembles GPT wrappers) and a *systems architect* (who ships autonomous systems in production) reaches $150k. The market is said to be saturated with thin layers on top of GPT — *"features waiting to be sherlocked by big tech"*. To become indispensable, one must build deep: orchestration, memory, local inference. The thread proposes a blueprint of 5 portfolio projects ranked by complexity, each with its key architectural decisions. **Project 1 — AI mobile app with SLM (beginner)**: offline-first app with small models. Proves edge AI mastery: lazy loading models, sliding window + semantic chunking, dynamic quantization (4-bit for older devices, 8-bit for recent ones), battery optimization, encrypted offline-first sync. **Project 2 — Self-improving coding agent (intermediate)**: autonomous agent that codes, tests, and learns from its failures. *"A chatbot waits for a prompt. An agent waits for a goal. The difference is the loop."* Plan-execute-test-reflect loop, sandboxing, memory hierarchy (short-term / long-term / failure memory), reflection mechanism via vector similarity, code safety via static analysis. **Project 3 — Cursor but for video editors (advanced)**: *"text is the past, vision and video are the present."* Fork of an open-source editor (Shotcut suggested), multimodal agent that understands intent ("make this cinematic"), translates it into concrete parameters (LUT, gaussian blur, dramatic cues), detects scenes, generates an edit decision list, offers undo with reasoning. **Project 4 — Personal life OS agent (expert)**: *"an agent that forgets is useless; an agent that knows your life is a partner."* Personal knowledge graph built continuously (calendar, finance, health), proactive monitoring (anomalies detected every 6h), explicit value alignment, privacy architecture (encryption at rest, offline-capable), predictive planning, transparent reasoning with data-point citations. **Project 5 — Autonomous enterprise workflow agent (master)**: *"the final boss of ai engineering."* Agent that drives business workflows end-to-end. Event-driven (Slack/Jira), multi-agent delegation, self-healing with circuit breaker, immutable audit trail, RBAC, full observability, human-in-the-loop, post-completion workflow learning, cost management. The thread closes on a darwinian slogan: *"the replaceable: building wrappers. the unfireable: shipping autonomous systems."* Call to ship over the weekend, document in public, tag the author for amplification. Openly growth-hacker format. To be read as an **architectural inventory** of 2026 patterns (edge AI, agentic loops, multimodal, deep context, multi-agent orchestration), not as a study. The density of aphorisms — *"sherlocked"*, *"unfireable"*, *"final boss"* — betrays viral intent, but the technical content lines up with the 2026 consensus (Karpathy, Sierra, Stripe Minions, Anthropic).