Agentic Engineering

Professional software engineering with AI agents doing much of the production while the human applies full expertise in design, review, security and operations — the disciplined counterpart to vibe coding.

Also known as: agentic engineering, Agentic Engineering, Agentic Programming, agentic programming, AI-augmented engineering / augmented engineering, augmented engineering, augmented development, AI-first software delivery (AIFSD), RIPER-5, supervised vs. unsupervised agents, agentic coding wave, engineering at AI speed

How authors use it

Oldest first (extraction date when no publication date is known).

Documents (49)

• Bun Rewrites 535K Lines of Zig into Rust in Four Months, Eliminates Numerous Memory Leaks Bruno Couriol · 2026-09-20 source ↗ Reader 🖥️
  A single domain expert, directing dozens of parallel adversarial-review AI agents against a mechanical (behavior-preserving) porting process anchored to an extensive pre-existing test suite, rewrote a 535K-line production codebase into a memory-safer language in months instead of a year and shipped measurable bug and memory-leak reductions — but critics dispute whether passing that same test suite ever was, or could be, sufficient proof that a million lines of largely unreviewed AI-generated code are actually safe.
• Podcast: How Will We Train Developers If AI Does the Routine Work: A Conversation with Scott Hanselman Michael Stiefel (host) with Scott Hanselman (guest, VP, Microsoft/GitHub) · 2026-09-14 Reader 🖥️
  The software industry must institutionalize a formal, metriced 'preceptor' role -- modeled on nursing's dedicated teaching-nurse system -- whose explicit job is to grow junior engineers into seniors, because AI has absorbed the routine, low-stakes toil junior developers used to learn from, and without deliberate, funded intervention the industry's short-term hyper-optimization will hollow out the senior-engineer pipeline within a generation.
• Practices I Abandoned with Agents: An Ode to Test-Driven Development Adam Tornhill · 2026-09-03 source ↗ Reader 🖥️
  Granular, human-cognition-scaled Test-Driven Development does not survive the transition to agentic coding and should be replaced by a coarser, feature-level practice — tests (especially end-to-end) as the human/agent abstraction boundary, with failing-test discipline retained but no longer organizing work into small red-green-refactor steps.
• All models, no matter how smart, will eventually build systems... Steve Yegge · 2026-09-02 Reader 🖥️
  Any AI coding model, left unconstrained, will eventually build a system that outgrows its own capacity to understand or maintain it — so the durable fix is not a smarter model but an externally imposed cap on system size.
• I'm done using AI Brett Codes · 2026-08-10 Reader 🖥️
  After using LLM-powered coding harnesses in earnest for over a year, the author concludes that the personal (mental-health, craft, deskilling), societal, and environmental harms of AI outweigh any productivity benefit it offers him, and that no moderate or selective level of use is viable — so he is stopping entirely.
• The Economic Benefit of Refactoring Giles Edwards-Alexander (published on martinfowler.com, byline Martin Fowler) · 2026-07-30 source ↗ Reader 🖥️
  Refactoring an agentic codebase according to a strict, correctness-preserving discipline can pay a measurable economic dividend — in this experiment, an 83% reduction in the input-token cost of an identical representative future change — because it lets an AI agent read a smaller, more targeted slice of the code to make the same change, even though the total code volume barely shrinks.
• Building AI Agents: API, Webhooks, Security, and Integration Alex Wang · 2026-07-29 Reader 🖥️
  Building AI agents is mostly not about the agent logic itself — it's traditional software engineering (API connections, webhooks/auth, data pipelines, frontend/backend integration, security/permissions) plus product thinking about how users interact with agents, and the hard part is making all these pieces reliably fit together.
• Presentation: Getting Rid of LeetCode Interviews in the World of AI Daniel Doubrovkine · 2026-07-29 source ↗ Reader 🖥️
  Because algorithmic whiteboard interviews measure luck and recent rehearsal rather than genuine engineering ability — as the speaker's own repeatedly inconsistent interview record proves — companies should replace them with open-ended, AI-assisted system-design exercises that reveal the judgment and human skills AI cannot substitute.
• Uber's Zero Growth Stack: Scaling Services, While Optimising Infrastructure and AI Cost Olimpiu Pop · 2026-07-28 source ↗ Reader 🖥️
  Uber's 'Zero Growth Stack' shows that sustaining service growth without proportional infrastructure growth now requires treating both compute resources (via dynamic, cgroup-aware GC tuning like GOGCTunner) and AI-tool spend (via usage caps and proposed code-quality-linked metrics) as continuously governed control loops rather than static, one-time settings or unconstrained rollouts.
• AI Demands More Engineering Discipline, Not Less Charity Majors · 2026-07-27 source ↗ Reader 🖥️
  AI's collapse of the cost of writing code doesn't reduce the need for engineering rigor — it relocates that rigor away from the code itself and into the validation, observability, and feedback infrastructure surrounding it, which is why nondeterministic AI-generated systems demand more engineering discipline, not less.
• GitLab 19.2 Puts AI Agents to Work on the Security Backlog Matt Saunders · 2026-07-21 source ↗ Reader 🖥️
  GitLab 19.2 bets that adding governed AI agents to the security-and-review layer — with a human always making the final call — can close the gap between how much code AI now lets developers generate and how much security and review work humans can actually absorb, though the release's own headline evidence for that bet (a vendor-commissioned ROI study) is far thinner than the governance engineering built around it.
• Podcast: Formal Methods for Every Engineer in an AI-Powered Future Gabriela Moreira (guest); host Shane Hastie (InfoQ) · 2026-07-10 Reader 🖥️
  Formal methods are a practical tool for reasoning about the edge cases of complex distributed and concurrent systems, and because AI in 2026 collapses the historic barriers to writing specifications and the glue code that binds them to real implementations, the profession's enduring human work shifts to defining which system behaviours are correct — the judgment AI cannot take over.
• mattpocock/skills v1.1: does /wayfinder beat grill-with-docs? Matt Pocock (AI Hero) · 2026-07-08 source ↗ Reader 🖥️
  Pocock announces that v1.1 of his Claude Code skills repo now composes a complete agentic coding lifecycle (Grill -> Spec -> Tickets -> Implement -> Code Review), whose headline addition, /wayfinder, decomposes a plan too big for one session into agent-sized chunks mapped as GitHub issues with blocking edges so the work can be parallelized.
• Future Of Software Development Martin Fowler · 2026-07-07 source ↗ Reader 🖥️
  Thoughtworks convened invitation-only 'Future of Software Development' Open Space retreats in 2026 to examine how AI and LLMs will reshape the profession, and Fowler deliberately captured the discussions as unattributed fragments rather than one coherent narrative — the fragmentary form itself signalling that the profession's future is too unsettled to reduce to a single thesis.
• Looking back at the Future of Software Engineering unconference Bartosz Ocytko · 2026-07-07 source ↗ Reader 🖥️
  As agentic engineering matures into human-built-and-operated 'software factories,' the decisive questions of software engineering shift from raw automation to governance — where human judgment and sign-off sit in the automated loop, how platforms (rather than universal upskilling) safely absorb citizen developers, what would keep developer tooling relevant, and how organizations manage the widening gap between teams that codify their processes early and those that don't.
• Jimmy Nilsson's Post — reflections after the Thoughtworks 'Future of Software Development' retreat Jimmy Nilsson · 2026-07-07 source ↗ Reader 🖥️
  Reflecting on Thoughtworks' 'Future of Software Development' retreat, the author reports that leading practitioners have moved past the hype-versus-doom polarisation about agentic coding toward nuanced 'when, where and how' thinking, converging on the view that enduring engineering fundamentals (DDD, XP, TOC, TDD, BDD, CD) plus a renewed 'Extreme Humanism' matter more than ever in the agentic age — which is why he is optimistic.
• Notes from FOSE Europe Giles Edwards-Alexander · 2026-07-07 source ↗ Reader 🖥️
  Five months into the agentic era the value of agentic engineering is now settled ('the evidence is in'), so the live frontier of the debate has moved from the tools themselves to the socio-organisational questions they raise — how to design your organisation (Optimiser vs Learner), where engineering rigour and human judgement now live, and how to coordinate agentic work across teams and enterprises — none of which is yet resolved.
• We've Stopped Arguing About Whether AI Changes Software Greg Herlein · 2026-07-07 source ↗ Reader 🖥️
  The debate over whether agentic AI transforms software engineering is settled; the transformation is a shift in the center of gravity of the work — from writing code to specifying, verifying, and curating knowledge.
• Fragments: July 6 Martin Fowler · 2026-07-06 source ↗ Reader 🖥️
  Agentic software development has crossed from aspiration into established practice — the debate is no longer whether it changes software engineering but how — and the central live question is whether classic design and architecture fundamentals still matter, with Fowler's emerging answer being that they do, both because agents use the same constructs humans do and because good design hedges against escalating token costs and the risk of losing affordable access to AI.
• SWLW #710: Revised rules of Eng Leadership, When AI costs more than the engineer, and more. Oren Ellenbogen · 2026-07-06 Reader 🖥️
  As AI reshapes engineering, the decisive leadership work shifts to human judgment applied to fundamentals — reaffirming sound operating principles, justifying AI's now salary-scale cost, and demanding engineering rigor — because AI only amplifies (in magnitude, not direction) whatever practices, clarity, and dysfunction already exist.
• Why did Martin Fowler invite 60 engineers to a ski resort? Ivett Ördög · 2026-07-05 source ↗ Reader 🖥️
  The turn to AI-built software has reopened rather than resolved the foundational questions of the craft — should humans still read code, how do we know it works, does code quality still matter, and how do we manage newly-empowered citizen developers — and the author's connective throughline is an optimistic one: AI democratizes building while the disciplines that make code good for humans remain exactly the ones that make it good for AI.
• Software Design in the Agentic Age: Placing Your Bets aardling.eu · 2026-07-03 Reader 🖥️
  Even though no one yet has evidence that classic code-design and domain-modeling discipline is necessary for agentic development, the author bets on maintaining it anyway — high test coverage, sound domain models and Ubiquitous Language, disciplined Bounded Contexts, and code quality — because doing so is the dominant strategy under uncertainty (cheap to unwind if unnecessary, expensive to retrofit if not) and because it preserves the option to revert an organization from agentic code generation back to human engineering if AI's economics or reliability falter.
• Have your agent record video demos of its work with shot-scraper video Simon Willison (Simon Willison's Newsletter) · 2026-06-30 source ↗ Reader 🖥️
  Coding agents should record video demos of their own work, and the tooling that enables it — shot-scraper's new storyboard-driven `video` command — is itself best built by an agent and driven straight from its `--help` output, so the human's remaining job is reviewing the design rather than writing the code.
• Google Just Dropped a Masterclass on Agentic Engineering (It's SO Good) Cole Medin · 2026-06-24 Reader 🖥️
  A developer's or team's AI-coding results are determined far more by the harness they deliberately engineer around a model — specs, context, guardrails, verification, and the discipline of continuously improving that system — than by which model they use, so investing upfront in 'agentic engineering' over ad-hoc 'vibe coding' is the highest-leverage move available right now, even though it costs more to start.
• You can't unit test for taste Karl Tryggvason · 2026-06-22 source ↗ Reader 🖥️
  In software you can assert correctness with red/green tests, but taste — judging what output is good, relevant and well-proportioned where there is no ground truth — cannot be unit-tested, so it stays an irreducibly human, iterative judgment even when AI does the production work.
• The New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering Addy Osmani, Shubham Saboo, Sokratis Kartakis · 2026-06-15 Reader 🖥️
  As AI increasingly handles code generation itself, what separates production-grade 'agentic engineering' from risky 'vibe coding' is not which AI tool a team uses but how deliberately it designs and maintains the harness, verification (tests + evals), and context around the model — so the discipline a team already has is what AI amplifies, for better or worse.
• Vibe Coding Agent Security And Evaluation Sokratis Kartakis, Aron Eidelman, Wafae Bakkali, Meltem Subasioglu · 2026-06-08 Reader 🖥️
  Operationalizing vibe coding in the enterprise requires redefining trust across two distinct, jointly necessary axes — a defence-in-depth 'Security' architecture (seven pillars: infrastructure, data, model, application/runtime, identity, observability/SecOps, governance) that proves an agent stayed inside its boundary, and a seven-dimension 'Evaluation' framework that proves what happened inside that boundary was actually worth shipping — because a vibe-coded agent can pass every security check while still misreading intent, and no single check (deterministic or AI-judged) covers both questions at once.
• How I Use Agents Without Stopping My Own Growth Jared Currie · 2026-05-27 source ↗ Reader 🖥️
  Agentic coding tools are safe to lean on only if the developer deliberately keeps exercising the judgment they would otherwise outsource — by planning before delegating and reviewing generated code as if reconstructing its reasoning themselves — because the tools amplify whichever posture the developer brings to them.
• How we Claude Code Claude · 2026-05-22 Reader 🖥️
  As models get more capable and agents are trusted to run longer on more ambiguous tasks, engineers should stop trying to hand-constrain Claude up front and instead let it interview them into a spec, review that spec through richer, denser artifacts (HTML, not long Markdown), and build verification directly into the artifact itself (as an agent-readable DOM contract) so the same checks can run under human, agent, and headless (CI) supervision alike.
• Bliki: Vibe Coding Martin Fowler · 2026-05-21 source ↗ Reader 🖥️
  Vibe coding — building software by prompting an LLM without ever looking at the generated code — is a distinct practice from agentic programming, useful only for disposable software, because forgetting the code exists produces serious risks in security, maintainability, and correctness.
• SWLW #701: Gazing at the misty AI Frontier, From Vibe Coding to Agentic Engineering, and more. Oren Ellenbogen · 2026-05-18 Reader 🖥️
  In the agentic era, software leaders win by raising their ceiling — investing in fundamentals, original thinking, and emotionally-attuned leadership — rather than letting AI flatten everyone to the same elevated floor.
• Vibe coding and agentic engineering are getting closer than I'd like Simon Willison · 2026-05-08 source ↗ Reader 🖥️
  As AI coding agents become more reliable, the experiential distinction between 'vibe coding' (unreviewed, low-accountability coding) and 'agentic engineering' (expert-supervised AI coding) is collapsing, which forces practitioners to find new trust signals — usage over inspection — while the entire software development lifecycle must restructure around dramatically cheaper code production.
• Stop Just Writing Code. Start Leading Agents: The Staff Engineer’s AI Edge Emad Mokhtar · 2026-05-07 source ↗ Reader 🖥️
  The Staff Engineer skillset of defining outcomes, reducing ambiguity, creating guardrails, and reviewing work — originally built for leading human teams — transfers directly to leading AI coding agents, and is becoming more valuable, not less, as agents take over more implementation.
• [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero AI Engineer (channel); speaker: Matt Pocock (AI Hero) · 2026-04-24 source ↗ Reader 🖥️
  AI is not a new paradigm for software engineering — the fundamentals that make working with humans effective (small tasks, vertical slices, deep modules, fast feedback loops, alignment through dialogue, TDD) are exactly what make working with AI agents effective; the path from idea to shipped feature is therefore a deliberately planned, human-driven pipeline (align → PRD → vertical-slice Kanban → AFK implementation → QA) in which the codebase itself is treated as the battleground, not the spec.
• Find the North Star Kent Beck — Still Burning Podcast · 2026-04-22 Reader 🖥️
  Play and intrinsic motivation matter more than productivity metrics in augmented software development, and knowing when to step back may be the most important skill as AI reshapes the field — but this claim is only gestured at in a promotional blurb, not developed.
• Harness engineering for coding agent users Birgitta Böckeler · 2026-04-20 source ↗ Reader 🖥️
  Coding agent users should engineer an outer harness of feedforward guides and feedback sensors — distributed across computational and inferential execution types and across the change lifecycle — to reduce review toil and increase system quality, but the behavioural harness (ensuring functional correctness) remains the hardest unsolved problem.
• Presentation: Engineering at AI Speed: Lessons from the First Agentically Accelerated Software Project Adam Wolff · 2026-04-20 source ↗ Reader 🖥️
  When AI drives implementation cost to near zero, the competitive advantage shifts from planning and coding speed to the speed of your feedback loop — how fast you can ship, learn from users, and reverse course — making experimentation, not upfront design, the right engineering strategy.
• Charlie Hills 🦩's Post Charlie Hills 🦩 · 2026-04-16 source ↗ Reader 🖥️
  Effective use of Claude Code requires deliberate setup, disciplined workflow habits, context management, precise prompting, and exploitation of power features — and learning these on day one would save weeks of friction.
• Agent Skills: Google-Backed AI Coding Agent Workflow Addy Osmani · 2026-04-10 source ↗ Reader 🖥️
  AI coding agents produce poor-quality output when unconstrained, so encoding senior-engineer workflows as structured skills — covering the full define-plan-build-verify-review-ship lifecycle — forces agents to follow the disciplined practices that distinguish professional engineering from mere code generation.
• All of AI's New Models and Tools AI Daily Brief · 2026-04-09 Reader 🖥️
  The AI industry shipped a burst of consequential models and tools the week of April 7 2026 — from Meta's Muse Spark to Z.AI's GLM-5.1 to Anthropic's Managed Agents — yet much of the public discourse fixated on models nobody can use yet (Mythos, Spud), obscuring the practical advances that actually matter to builders.
• 11) AI-spesial med Vilde Opsal og Anders Sveen Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · 2026-02-16 source ↗ Reader 🖥️
  AI-assisted development is a real step up in abstraction that pays off only when teams pair it with judgment, structure and active learning — speed gains come from agentic tooling, but durable value comes from evals, information architecture and refusing to outsource learning to the model.
• The third golden age of software engineering – thanks to AI, with Grady Booch The Pragmatic Engineer (Gergely Orosz, host; Grady Booch, guest) · 2026-02-04 Reader 🖥️
  Software engineering is entering a historically recurring pattern — a rise in the dominant level of abstraction — rather than being automated out of existence, because 'software engineering' has always meant balancing human, economic, legal, and ethical forces (not just writing code), and today's AI tools only automate the coding layer, which is itself bounded by the already-seen patterns they were trained on.
• The Future Of Software Engineering Thoughtworks · 2026-02 Reader 🖥️
  As AI takes over code production, engineering rigor does not disappear but migrates to specifications, tests, constraints, risk management, and a new 'middle loop' of supervisory work — and organizations that fail to deliberately rebuild their practices, roles, and governance around these new destinations will suffer compounding losses in quality, comprehension, and stability.
• Steve Yegge's Vibe Coding Manifesto: Why Claude Code Isn't It & What Comes After the IDE Latent Space · 2025-12-26 source ↗ Reader 🖥️
  Chat-style coding tools like Claude Code are a transitional phase, not the destination; the real endpoint is an agent-orchestration dashboard for fleets of simultaneously-running coding agents, and the discipline this demands — reading diffs instead of code, tolerating unpredictability, and solving multi-agent merge collision — will determine which engineers and teams survive the shift to 'factory farming' of code.
• The Bet On Juniors Just Got Better Kent Beck (Software Design: Tidy First?) · 2025-12-12 Reader 🖥️
  Because AI coding assistants used as 'augmented coding' tools compress a junior developer's ramp-to-profitability and make it more likely they survive the unprofitable early period at all, hiring juniors is now a better economic bet than before -- not a worse one -- provided organizations deliberately manage them for learning rather than production.
• How Claude Code Is Built Gergely Orosz · 2025-09-23 source ↗ Reader 🖥️
  Claude Code is built by a small team that treats the Claude model itself — not its own surrounding code — as the real product, deliberately minimizing scaffolding, choosing an "on-distribution" tech stack the model already masters, deleting code whenever a new model release subsumes it, and restructuring code review, testing, incident response, and prototyping around AI doing the first pass; Orosz presents this as a plausible preview of how "AI-first" engineering teams will operate, while flagging that Anthropic's unlimited, cost-free access to its own frontier model and its identity as a research lab (not a product company) limit how directly the specifics transfer elsewhere.
• Coding agents have crossed a chasm singleton.io · 2025-06-14 source ↗ Reader 🖥️
  Autonomous coding agents have crossed a real capability threshold -- from 'smarter autocomplete' and pair-programming assistance to genuine delegate-to collaborators the author can hand whole tasks to -- which shifts the developer's bottleneck from writing code to framing problems well enough for an agent to reason about them, while the developer's own technical foundation and review discipline remain what separates good AI-assisted outcomes from confidently-wrong ones.
• How Microsoft Developers Use AI in Real-World Coding | BRK103 Microsoft Developer · 2025-05-21 source ↗ Reader 🖥️
  AI tools are most valuable to an individual developer not as autocomplete or as a replacement for judgment, but as a fast, tireless conversational partner for ideation, documentation, test generation, and debugging across a developer's own long-lived codebase — provided a knowledgeable human stays in the loop to evaluate, correct, and hold accountability for what the AI produces before it reaches the team's review process.
• Presentation: AI-First Software Delivery: Balancing Innovation with Proven Practices Wes Reisz · 2025-01-01 source ↗ Reader 🖥️
  AI-first software delivery is not one-size-fits-all: teams should choose between supervised and unsupervised agentic approaches based on code longevity and their ability to verify outputs automatically, using structured human-AI collaboration (RIPER-5) to preserve engineering discipline — because AI amplifies whatever practices you already have, good or bad.

Propositions touching this concept (26)

By publication month, oldest first (extraction month when no publication date is known).

2025-01

• explicitRIPER-5 codifies how good engineers already work — it is not a novel methodology but an explicit protocol that makes implicit engineering habits communicable to an LLM.
  Presentation: AI-First Software Delivery: Balancing Innovation with Proven Practices · p9

2026-04

• explicitcorroboratedThe most important skill in augmented development might be knowing when to step back.
  Find the North Star · p3
• explicitThe real unsolved problem in AI-augmented development is multiplayer human collaboration, not multi-agent AI coordination
  Genie Lessons: Nobody Wants Agents · p4

2026-05

• explicit⚡ disputed & corroboratedVibe coding and agentic programming are categorically different practices.
  Bliki: Vibe Coding · p2
• explicitConceptual hygiene — keeping vibe coding and agentic programming distinct — is worth defending against popular usage.
  Bliki: Vibe Coding · p9
• explicitAgentic programming is recovering the Great Lost Joy of molding one's own development environment — the Internal Reprogrammability that was central to Smalltalk/Lisp but lost in the IDE era.
  Fragments: May 5 · p2
• explicitdevelopedIt remains an open question whether internal code quality still matters in the age of agentic programming, or whether LLM capabilities will eventually render it irrelevant.
  Fragments: May 5 · p8
• explicitThe relevant skill for engineers has shifted from vibe coding to agentic engineering, and hiring practices should screen for the latter
  SWLW #701: Gazing at the misty AI Frontier, From Vibe Coding to Agentic Engineering, and more. · p1
• explicitcontestedVibe coding and agentic engineering, which Willison previously considered categorically distinct, are converging in his own practice because he has stopped reviewing every line of agent-produced code.
  Vibe coding and agentic engineering are getting closer than I'd like · p1

2026-06

• explicitAI coding is a spectrum, not a binary switch, running from vibe coding (casual prompting, 'does it seem to work' verification) through structured AI-assisted coding to agentic engineering (engineered specs, automated evals, CI gates); picking a point other than the most structured end is legitimate for proof-of-concepts or MVPs.
  Google Just Dropped a Masterclass on Agentic Engineering (It's SO Good) · p2
• explicitVibe coding has low upfront cost but high ongoing cost (burning large volumes of tokens iterating on unstructured, sloppy code because there is no system for the AI to follow); agentic engineering inverts this — high upfront investment in building the harness, then output that is three to ten times more reliable and cheaper at scale, with the crossover reached quickly enough to justify diving in early.
  Google Just Dropped a Masterclass on Agentic Engineering (It's SO Good) · p9
• explicitcorroboratedThe key differentiator between vibe coding and agentic engineering is not whether a team uses AI, but how much structure, verification, and human judgment surrounds the AI's output.
  The New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering · p2
• explicitIn agentic engineering, the developer's primary output is the system that produces code — specifications, agents, tests/quality gates, feedback loops, and guardrails — not the code itself (the factory model).
  The New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering · p6
• explicitVibe coding has near-zero upfront cost (CapEx) but hides a compounding operational cost (OpEx): token burn from unstructured prompting loops, a 'maintenance tax' from reverse-engineering unstructured AI-generated code, and expensive security remediation after the fact; agentic engineering inverts this profile — high upfront CapEx (specs, tests, structured context), low marginal OpEx.
  The New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering · p11
• explicitestablishedMature agentic engineering practice routes tasks to different models by cost/complexity — large frontier models for requirements/architecture/complex implementation, smaller cheaper models for deterministic work like test generation, code review, and CI/CD monitoring — to avoid paying premium token prices for trivial tasks.
  The New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering · p13
• implicitA team's incentive structure must actually reward the upfront CapEx investment (writing tests/evals before code, maintaining AGENTS.md as reviewed code, owning harness components as shared infrastructure) for agentic engineering's economics to pay off — otherwise the easier, cheaper-looking vibe-coding path wins by default under normal shipping-speed pressure.
  The New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering · p17
• explicitcontestedSlowing augmented development is the path to actually going faster — because trust enables sustained velocity.
  Trust Factory · p7

2026-07

• implicitThe absence of a visible flood of impressive new applications built with agentic programming — even from well-resourced AI boosters like Google or Microsoft — is evidence against the most bullish capability claims.
  Fragments: July 21 · p9
• explicitdevelopedThe endpoint of agentic engineering is a largely self-evolving 'software factory' in which a feature request is built into the existing system, and which humans build and operate rather than hand-code.
  Looking back at the Future of Software Engineering unconference · p1
• explicitTeams with well-engineered systems — low build times, modular architecture, and high test coverage enabling continuous delivery — benefit most from agentic engineering.
  Looking back at the Future of Software Engineering unconference · p3
• explicitAgentic engineering amplifies both good and bad team practices, so teams that codify their processes early continuously widen the gap over slower-adapting peers — small companies gain first, while large companies risk process and tech-stack fragmentation unless shared skill marketplaces, tooling, and a culture of reuse take hold.
  Looking back at the Future of Software Engineering unconference · p12
• explicitUsage-based billing for coding agents (GitHub Copilot's transition) more accurately reflects the real inference cost of agentic programming than flat subscription pricing did, and will raise what developers and their employers pay.
  Radar Trends to Watch: July 2026 · p3
• explicitIn just five months, the prevailing sentiment about agentic engineering shifted from Deer Valley's hesitant belief that 'there was something here even if we weren't yet sure what it was' to Engelberg's confidence that the value is here.
  Notes from FOSE Europe · p1
• explicitAgentic engineering demonstrably works and is here to stay; its value is no longer in question.
  Notes from FOSE Europe · p2
• implicitThe maturation of agentic engineering is recapitulating the trajectory of earlier movements such as DevOps and domain-driven design — value gets demonstrated, then organisations risk mishandling it by creating specialist silos and reaching for old modeling tools.
  Notes from FOSE Europe · p13

2026-09

• explicitcorroboratedOrganizational governance of AI-augmented engineering can be compressed into four elements — Purpose (what the work is for), Articles (what must remain true), Actors (who/what does delegated work), Artifacts (what is preserved and remembered) — with the harness making Articles executable, people and agents staffing Actors, and evidence/ledgers becoming Artifacts.
  From AI Code to Trusted Software: Harness Engineering in Practice · p17

Tensions

Open gaps (86)

• scopeAll referenced engineering principles come from Google. No acknowledgment that different organizational contexts (startups, regulated industries, open-source projects) may need different trade-offs.
  Agent Skills: Google-Backed AI Coding Agent Workflow — read next: Literature on context-dependent software engineering practices; critique of one-size-fits-all process frameworks.
• incompleteThe piece advocates video demos as the way to show an agent's work, but never addresses that a scripted storyboard exercises a predetermined happy path — it even stubs navigator.clipboard via injected JavaScript — so it demonstrates 'the flow runs as scripted', not 'the feature is correct'. The adjacent sqlite-utils story is the counter-example the piece doesn't connect: its release-blocking data-loss bug was invisible to any demo and caught only by code review. Demos verify liveness and UX, not correctness.
  Have your agent record video demos of its work with shot-scraper video — read next: Read on evals and property-based testing as complements to demos, and Geoffrey Litt's 'understand to participate' (quoted later in this same newsletter) on why watching output cannot substitute for conceptual understanding of the change.
• incompleteThe '--help as embedded SKILL.md' pattern assumes the --help text stays accurate, complete and token-cheap as the tool grows. The piece does not consider --help drift (help falling out of sync with behavior), how a large tool's full --help fits an agent's context budget, or when the embedded-skill approach should give way to a real SKILL.md or progressive disclosure.
  Have your agent record video demos of its work with shot-scraper video — read next: Agent-native design and progressive-disclosure/token-efficiency literature; compare with SKILL.md ecosystem write-ups on versioning and staleness.
• incompleteThe whole reliability argument rests on the human catching design flaws by reviewing agent-written documentation, yet the piece does not examine the case where the agent's prose is as confidently wrong as its code — doc rot, plausible-but-inaccurate documentation that reads clean. Release notes are declared 'safe to outsource because boring, predictable and accurate', but boring text is also the text least likely to be scrutinized.
  Have your agent record video demos of its work with shot-scraper video — read next: Cognitive-debt and comprehension-debt writing; work on documentation as a review surface and on LLM-generated-text 'tells' and silent inaccuracy.
• incompleteCross-family review is recommended from repeated anecdote ('it really does work'), with no false-positive rate, no cost/benefit accounting, and no discussion of when it fails to catch things or produces noise that costs more review time than it saves.
  Have your agent record video demos of its work with shot-scraper video — read next: See the GitHub Copilot 'Rubber Duck' analysis of cross-family review as cost-effective only when invoked sparingly at high-signal moments, and eval methodology for measuring reviewer models.
• incompleteTeam adoption is treated as an exercise for the reader. Pocock's answer to 'how does this work in a team?' is essentially: 'the upstream becomes team-shared, the downstream is one or two devs managing the pipeline.' He gives no story for: review queue scaling, distribution of PRD-authoring authority, who owns skills/coding-standards as a shared asset, code-review burden as a team-wide labour question, or how juniors learn craft in a workflow where most code is agent-written.
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero — read next: Cutler on overload and accountability culture; Beck on socio-technical change; Fearless Change for the adoption-of-practices angle in the user's hidden-layer interests.
• incompleteThe 'pre-AI books' recommendation is the closing thesis but is left underspecified. Pocock cites Pragmatic Programmer (tracer bullets), Ousterhout's Philosophy of Software Design (deep modules), Brooks's Design of Design (design concept), Fowler's Refactoring (small steps) — but does not give a reading list, nor a mapping of which insight from which book deploys at which point in the workflow. This is the load-bearing connection to the user's craft tradition and is left as a 'go buy them on Amazon.'
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero — read next: The user's library already covers Beck (small steps, TCR, simple design), Hickey (Simple Made Easy), Yourdon & Constantine (Structured Design), Meadows (Thinking in Systems). The mapping work is for the orchestrator to do: e.g., Pocock's 'don't bite off more than you can chew' is Fowler-on-refactoring; deep modules is Ousterhout; tracer bullets is Hunt & Thomas; design concept is Brooks. The honest gap is that Pocock does not even mention Beck — surprising given Beck's TCR is operationally close to red-green-refactor as Pocock practices it.
• incompletePocock's workflow structurally mirrors Anthropic's harness paper (planner / generator / evaluator) and Böckeler's adaptive-control framing, but he does not name them or compare. The grill-me skill is alignment; the PRD-to-Kanban is planning; the AFK Ralph loop is generation; TDD + manual QA + reviewer-Opus is evaluation. Surfacing this overlap is essential to placing his workshop in the broader 2026 AI-coding discourse.
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero — read next: Anthropic harness paper, Böckeler on adaptive control, Addy Osmani on agent patterns (in the user's saves) — all map onto Pocock's lifecycle with different vocabulary.
• incompletePocock conflates two definitions of 'done': (a) feature shipped with QA-imposed taste, and (b) commit produced by the Ralph loop with passing tests. The transitions between (a) and (b) — especially the merge-and-conflict-resolution at the end of multiple parallel sandbox branches — are sketched (the Sandcastle merger agent) but not interrogated for what happens when the merger itself produces semantically broken code. This is exactly where small-PR discipline matters and where he admits he doesn't have the answer.
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero — read next: Beck on incremental design and TCR; trunk-based development literature; the smallcode failure-mode catalog if it covers merge-stage failures.
• incompleteThe implicit premise that the developer can read agent output well enough to QA, code-review, and impose taste is enormous. Pocock states 'understanding code deeply is going to make you a much, much better developer and get more out of AI' and 'bad codebases make bad agents' — but does not address the developer who is themselves junior, distracted, or not the original architect. The workflow may be most valuable to seniors and least usable by the engineers who most need leverage.
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero — read next: Marcus on code quality (in user's recent saves), Beck on apprenticeship/teaching contexts, Cutler on directly-responsible-individuals and skill distribution.
• uninformedPocock specifically defers the question on conforming to security, architectural, and API-contract constraints ('I'm going to answer that in a bit') and never returns to it. For the user's organizational context (Norwegian senior leader watching governance signals), this is the highest-value question and is left unaddressed.
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero — read next: Security-review skill, Schneier on Security, explainable-AI requirements paper in the user's library, organisational adoption studies on AI tooling in regulated industries.
• missing evidenceThe entire framework is grounded in a single three-month engagement. No DORA metrics, no controlled comparison with unconstrained approaches, no data on defect rates or rework costs. The talk is honest about this, but it means the prescriptive claims rest on practitioner intuition rather than empirical evidence.
  Presentation: AI-First Software Delivery: Balancing Innovation with Proven Practices — read next: Studies measuring productivity and quality outcomes of structured vs. unstructured AI-assisted development; DORA-instrumented teams using agentic workflows.
• tensionThe talk argues that (1) AI amplifies whatever practices you have, and (2) pair programming is essential for reviewing AI output. But if your practice is already strong enough to benefit from amplification, why is the review burden so high? The high review burden suggests the AI is generating output that doesn't match team standards — which is the amplification-of-weakness problem the talk warns about.
  Presentation: AI-First Software Delivery: Balancing Innovation with Proven Practices — read next: Research on AI code quality vs. human code quality at different experience levels; studies on code review effectiveness for AI-generated code.
• scope limitationThe framework addresses coding agents exclusively. It does not address other AI applications in the SDLC (testing agents, deployment agents, monitoring agents, design agents) or how the supervised/unsupervised choice might differ for those. The 'shifting left' claim is broader than the framework can support.
  Presentation: AI-First Software Delivery: Balancing Innovation with Proven Practices — read next: End-to-end SDLC automation literature; agent architectures for testing, deployment, and operations.
• illogicalThe opening claim is stated as a universal law ('all models, no matter how smart, will eventually...') but the very next sentence reports a model update (5.1) apparently fixing the specific instance — which is evidence *against* an unconditional universal, or at minimum requires 'eventually' to be doing a great deal of unexamined work (fixed by 5.1 now just means the runway got longer, not that the law was falsified). The tweet doesn't reconcile this tension; it just moves past it with 'For now.'
  All models, no matter how smart, will eventually build systems... — read next: Any future extraction of similar Yegge or practitioner commentary on later Fable versions could test whether the 'runway keeps getting longer but the ceiling remains' framing holds up, or whether at some capability level the failure mode stops recurring altogether.
• uninformedNo discussion of what GLM-5.1's open-source release means for safety and governance. A 754B frontier-capability model with commercial licensing and no apparent safety gating — the opposite of the Mythos approach — yet the newsletter does not explore the tension.
  All of AI's New Models and Tools — read next: Examine open-source AI safety governance frameworks; compare Anthropic's restrictive release of Mythos with Z.AI's open release of a comparably capable model.
• incompleteManaged Agents' limitation of no persistent memory across sessions is mentioned but not explored. This is a fundamental constraint on the types of agents that can be built, yet the newsletter moves past it quickly.
  All of AI's New Models and Tools — read next: Investigate stateful agent architectures and the technical challenges of persistent agent memory.
• illogicalThe newsletter frames safety-gated releases as a 'status symbol' (implying marketing theater) while simultaneously treating the actual safety concerns around Mythos as legitimate. These framings are in tension but not reconciled.
  All of AI's New Models and Tools — read next: Analyze whether staggered releases serve genuine safety purposes or primarily function as demand-generation marketing.
• incompleteGitHub's infrastructure strain from agentic coding is presented as evidence of rapid change, but the quality implications of 14 billion agent-generated commits per year are not examined. More commits does not necessarily mean better software.
  All of AI's New Models and Tools — read next: Study code quality metrics for AI-generated vs. human-written code at scale; examine whether agent-driven commit volume correlates with software quality or technical debt.
• incompleteThe entire intellectual substance of this episode is behind the paywall / in the audio. The email provides only marketing copy. All three propositions are teasers without supporting argument.
  Find the North Star — read next: Listen to the actual podcast episode (Still Burning S1E03) or obtain a transcript to extract the real content. Consider using the podcast-transcript skill if the episode becomes available.
• incompleteThe behavioural harness is acknowledged as 'the elephant in the room' but no concrete framework or methodology is proposed for solving it beyond mentioning approved fixtures as a partial pattern.
  Harness engineering for coding agent users — read next: Read the approved fixtures pattern (lexler.github.io/augmented-coding-patterns) and explore specification-based testing approaches (property-based testing, contract testing) as potential behavioural harness components.
• incompleteThe article does not address how to evaluate harness quality or coverage — it raises the question ('If sensors never fire, is that high quality or inadequate detection?') but offers no answer.
  Harness engineering for coding agent users — read next: Explore meta-testing approaches: mutation testing for harnesses, harness coverage metrics, or adversarial testing of the harness itself.
• incompleteThe cybernetic framing (feedforward/feedback, Ashby's Law) is adopted as the organizing metaphor but not critically examined. Control theory assumes a well-defined desired state and measurable error signal — software development often has neither.
  Harness engineering for coding agent users — read next: Read Stafford Beer's work on viable systems and cybernetic management to assess how well control-theory concepts transfer to inherently creative/ambiguous engineering tasks.
• incompleteNo discussion of the cost-benefit analysis of harness engineering itself — when is the investment in building and maintaining a harness worthwhile vs. simply relying on human review?
  Harness engineering for coding agent users — read next: Look for empirical studies or experience reports quantifying harness ROI in agent-assisted development.
• incompleteThe interaction between guides and sensors — coherence, contradiction, priority resolution — is raised as an open question but not explored.
  Harness engineering for coding agent users — read next: Explore policy conflict resolution in cybernetic and multi-agent systems literature.
• incompleteThe post gives no evidence, examples, or specifics for its claims (no case study, no named failure mode, no data on where reliability breaks down) — it is a genre artifact (LinkedIn engagement post) built primarily to drive traffic to a paid/free workshop advertisement rather than to substantiate an argument.
  Building AI Agents: API, Webhooks, Security, and Integration — read next: None warranted at this depth of content; for a substantive treatment of agent-integration reliability, look to primary engineering writeups or postmortems rather than promotional social posts.
• uninformedFor a reader already deep in agentic engineering, the claim that agent-building requires real software engineering plus product thinking is a truism with near-zero novel informational content — the post doesn't engage with any of the harder, more specific questions in this space (e.g. what specifically breaks in webhook/auth reliability at scale, how permission layers should be scoped for agent tool access).
  Building AI Agents: API, Webhooks, Security, and Integration — read next: N/A — not a genuine knowledge gap for this reader; noted for completeness.
• uninformedThe $165,000 token cost is reported 'at API pricing' without noting whether this reflects a subsidized internal rate (Bun/Anthropic are commonly owned), nor is any counterfactual maintenance-cost comparison offered for continuing to hand-fix the original Zig memory bugs over time.
  Bun Rewrites 535K Lines of Zig into Rust in Four Months, Eliminates Numerous Memory Leaks — read next: See the companion gap already recorded on the same underlying event in extract-pragmatic-engineer-anthropic-building-software#g3.
• incompleteNo evidence or reasoning is provided for any of the 32 claims. Every tip is stated as flat assertion. There is no explanation of WHY each practice works, what failure mode it prevents, or how the author discovered it. This makes it impossible to evaluate which tips generalize vs. which are idiosyncratic to the author's workflow.
  Charlie Hills 🦩's Post — read next: Look for experience reports or controlled comparisons of Claude Code workflows (e.g., with vs. without CLAUDE.md, with vs. without branching per task).
• incompleteThe social media format (LinkedIn listicle) constrains depth. Tips like 'Set a scope limit to only the files you name' and 'Replan at halfway to reset the goal' are operationally vague — a reader new to Claude Code would not know how to implement them.
  Charlie Hills 🦩's Post — read next: The author's own linked guides (beginner-to-advanced, design-in-code) likely expand on these compressed tips.
• uninformedThe claim that human skills (empathy, ethics, collaboration, judgment) now matter more than code output is attributed secondhand to a single executive recruiter's remark in conversation, not examined against counter-evidence or defined more precisely — it is asserted as received wisdom rather than argued.
  Presentation: Getting Rid of LeetCode Interviews in the World of AI — read next: Primary research on which specific human capacities remain predictive of engineering performance as AI absorbs code production.
• incompleteAll three case studies come from a single team (Claude Code at Anthropic) building a CLI tool with unusually tight dogfooding loops. The argument that experimentation should replace upfront design is not tested against contexts with higher costs of failure (healthcare, infrastructure, finance), longer feedback cycles, or larger teams where coordination costs dominate.
  Presentation: Engineering at AI Speed: Lessons from the First Agentically Accelerated Software Project — read next: Literature on high-reliability organizations (e.g., Normal Accidents by Perrow); experiences of AI adoption in safety-critical domains
• incompleteThe talk assumes a small, highly skilled team that can make and evaluate architectural decisions rapidly. No discussion of how these practices scale to larger organizations where most engineers are not senior architects.
  Presentation: Engineering at AI Speed: Lessons from the First Agentically Accelerated Software Project — read next: Team Topologies (Skelton & Pais); research on scaling agile and continuous deployment in large organizations
• uninformedThe SQLite analysis conflates SQLite's limitations with the specific way it was deployed (npm native dependency distribution, Better-SQLite3 binding). SQLite-via-WASM (e.g., sql.js) would have avoided the native dependency problem entirely. The multiprocess locking concern is real but standard WAL mode mitigates it significantly.
  Presentation: Engineering at AI Speed: Lessons from the First Agentically Accelerated Software Project — read next: SQLite documentation on WAL mode; sql.js and other WASM-based SQLite distributions
• incompleteThe argumentative framing — 'AI-native is the right framing' — is never set against its alternative ('AI-augmented' as integration into existing patterns; 'AI-using' as a feature choice). The playbook treats 'AI-native' as the default future rather than as one strategic posture among several.
  The Founder's Playbook: Building An AI-Native Startup — read next: Read alternative framings: AI-augmented engineering writeups, smallcode-style minimalism (already extracted), and the broader 'is AI-native a category or a marketing label?' debate.
• incompleteFowler offers no mechanism for detecting when 'disposable' software is silently graduating into consequential software. The disposable/consequential boundary is treated as legible to the author, but in practice it is one of the most common failure modes in software organisations — internal scripts becoming critical infrastructure.
  Bliki: Vibe Coding — read next: Cutler on institutional overload and shadow systems; classic discussions of 'tactical' vs 'strategic' programming (Ousterhout, Philosophy of Software Design); literature on shadow IT and end-user computing.
• incompleteNo engagement with the cultural/professional question of whether vibe coding deserves the name 'coding' at all, or whether legitimising it as a coding practice (rather than, say, 'spec-driven prototyping') invites exactly the diffusion problem Fowler is trying to push back against.
  Bliki: Vibe Coding — read next: Naur on programming as theory building; the broader 'what is programming' debate that has resurfaced post-LLM.
• uninformedAs an explicitly non-conclusion-forming fragments post, its picture of the 'state of practice' rests on a single retreat and a handful of blog posts rather than systematic adoption or outcome data.
  Fragments: July 6 — read next: Look for DORA-style empirical studies of agentic-development outcomes at scale.
• incompleteAs an index, the post provides no synthesis or throughline of what the retreat collectively concluded; a reader cannot learn the substance of the discussions from this page alone and must chase each individual fragment and external write-up.
  Future Of Software Development — read next: Read Fowler's individual fragment posts, plus participant accounts such as Annie Vella's 'Finding Comfort in the Uncertainty', the Rachel Laycock New Stack interview, and the Thoughtworks report.
• incompleteBecause the retreat was held under the Chatham House Rule, the insights are unattributed, so a reader cannot trace claims to their sources or weigh them against the speakers' contexts and track records.
  Future Of Software Development — read next: Seek on-record accounts from named participants who wrote their own posts or granted permission to be quoted.
• incompleteParticipants were all selected for being 'active in the LLM-fuelled changes,' so the retreat's perspective is pre-filtered toward AI-engaged practitioners; skeptical, displaced, or AI-critical voices are structurally underrepresented.
  Future Of Software Development — read next: Read AI-skeptic and labor-impact perspectives to counterbalance the sampling.
• incompleteNo engagement with organizations that lack Microsoft's scale, cash, or executive sponsorship -- a resource-constrained startup, a non-tech company's small engineering team, or a highly outsourced/offshore engineering org has no obvious path to implementing preceptorship as described (400-500 person 'shards,' formal cohorts, explicit executive buy-in).
  Podcast: How Will We Train Developers If AI Does the Routine Work: A Conversation with Scott Hanselman
• incompleteThe 'third place' collapse and anthropomorphization-of-AI risks are raised as real sociological costs, but Hanselman offers no organizational remedy beyond his own personal practice (periodic travel to Seattle); there is no discussion of what fully distributed, no-office companies could do instead, nor any engagement with whether his prescription (in-person contact) is feasible for organizations that chose remote-first specifically to access geographically dispersed talent.
  Podcast: How Will We Train Developers If AI Does the Routine Work: A Conversation with Scott Hanselman
• incompleteThe conversation explicitly opens but does not close the team-augmentation question — what does multi-agent + multi-human team coordination look like in practice? Vilde admits FINN/Vend has not cracked it.
  11) AI-spesial med Vilde Opsal og Anders Sveen — read next: Nils Brede Moe (Heis ep 9) on AI paradox + autonomy + learning culture; Pocock workshop on harness design for long-running agent teams; emerging literature on multi-agent code review and orchestration.
• incompleteNorwegian/Nordic constraints (persondata, public-sector compliance, sovereignty, DPA-with-Anthropic) are mentioned repeatedly but never developed into a coherent picture of how the Norwegian stack will diverge from the US default agent stack.
  11) AI-spesial med Vilde Opsal og Anders Sveen — read next: Smidigposten / Norwegian agile community pieces on public-sector AI; sovereign-AI / data residency discussions; Vipps/DNB/NAV-specific writeups.
• uninformed (in a time-stamped sense)The episode is explicitly dated end of January 2026 and pre-DeepSick announcement; the participants flag this themselves.
  11) AI-spesial med Vilde Opsal og Anders Sveen — read next: Re-listen after major model releases; compare against follow-up Heis special when produced.
• incompleteSeveral central claims — that HTML specs net-reduce token cost, that Opus 4.7's vision model materially improves screenshot-based feedback, that the verification framework meaningfully improves reliability — are asserted from the presenter's own experience with a single demo repo, without any measurement, benchmark, or before/after comparison.
  How we Claude Code — read next: Compare against the corpus's recurring pattern of unreplicated single-author agentic-workflow anecdotes (e.g. extract-anatomy-of-an-agent-harness's own unquantified 'giving the model a way to verify its own work improves quality 2-3x' claim) for how thin this evidentiary base typically is across the corpus.
• incompleteEvery control in the 7-pillar architecture is justified by first-principles reasoning about non-determinism and by citing named threat patterns (slopsquatting, invisible payloads, Confused Deputy), but no incident data, overhead measurements, or cost-benefit comparison is offered for any proposed control — e.g., no data on how much the 'Vibe Diff' + hardware MFA step actually reduces blind-approval rates versus a simpler gate, or on the operational cost of running a continuous Red/Blue/Green triad alongside every development workflow.
  Vibe Coding Agent Security And Evaluation — read next: This corpus's own extract-lulla-loop-engineering-building-blocks-adoption-impact documents, for a structurally similar case (loop engineering's prescribed building blocks), that almost none of a comparably detailed practitioner-prescribed architecture shows up as committed, verified practice in real repositories — worth reading against this whitepaper's unverified 7-pillar prescriptions for the same pattern.
• incompleteThe evaluation framework explicitly scopes out 'the feedback loop from user corrections back into the model, the harness, or the eval suite' as future work — but the applied tip 'Mine user corrections as labeled failure data' in the same document is precisely that feedback loop's first step (clustering corrections into failure modes), left unconnected to how those clusters would actually drive harness or eval changes.
  Vibe Coding Agent Security And Evaluation — read next: The corpus's context-engineering and agent-config-decay material on how harness/context changes get fed back from observed failures.
• uninformedThe anecdotal 10x productivity-gap claim (OpenAI) and the 2,000-hours-to-trust figure are both reported second-hand without method, sample size, or how 'productivity' or 'trust' were measured — exactly the kind of practitioner-anecdote-presented-as-data this user's persona flags as a red line (wants benchmark data over vendor/anecdotal claims).
  Steve Yegge's Vibe Coding Manifesto: Why Claude Code Isn't It & What Comes After the IDE — read next: Look for controlled studies or larger-sample practitioner surveys on agentic-coding productivity differentials and on time-to-trust/calibration with AI coding agents, rather than single-company anecdotes.
• incompleteThe 'software factory' vision presupposes teams that already have low build times, modular architecture, and high test coverage; it does not explain how the large population of teams without those prerequisites gets there, leaving the later 'growing gaps' under-explained as remediable rather than fixed.
  Looking back at the Future of Software Engineering unconference — read next: Read on bootstrapping engineering rigour and modernization with agents (legacy modernization, test-suite generation, CI/CD adoption paths).
• incompleteThe announcement asserts benefits (parallelizable decomposition, better code review, fixed grilling) with no evidence, benchmark, or worked example — support is an anecdote plus a 'Watch the video ->' link. Most tellingly, the comparison the subject line promises ('does /wayfinder beat grill-with-docs?') is entirely absent from the body: 'grill-with-docs' is never defined or mentioned outside the subject line, so the head-to-head is not under-evidenced but wholly missing from the text — the clearest proof that the substance lives in the un-transcribed AI Hero video.
  mattpocock/skills v1.1: does /wayfinder beat grill-with-docs? — read next: Watch and transcribe the linked AI Hero changelog video (https://www.aihero.dev/skills/skills-changelog-v1-1-wayfinder-to-spec-to-tickets-grilling-improvements), or trial the mattpocock/skills v1.1 repo directly, to recover the actual reasoning, demos, and the /wayfinder vs grill-with-docs comparison.
• incompleteNo discussion of durable, large-scale, or legacy codebases; every example (CLI tool, personal dashboard, browser extension, a user-management endpoint) is small, disposable, or greenfield. The claim that the Staff Engineer skillset transfers to leading agents is untested against the harder case of agents operating inside a decade-old, high-stakes production system.
  Stop Just Writing Code. Start Leading Agents: The Staff Engineer’s AI Edge — read next: extract-orosz-when-ai-writes-almost-all-code (production-quality regressions already observed) and extract-whats-an-orchestrator-why-software-needs-one (accountability scaling with agent-driven productivity).
• illogicalThe author frames 'reviewing becomes more important' as sufficient reassurance without reconciling it with his own admission that agents 'make mistakes... sometimes create bugs that look very convincing.' If agent output is specifically liable to look convincing while being wrong, review itself becomes harder exactly as it becomes more necessary — a tension the piece raises but doesn't resolve.
  Stop Just Writing Code. Start Leading Agents: The Staff Engineer’s AI Edge
• incompleteThe 'enormous challenges on several levels' are asserted but none are named or characterised, so the counterweight to the optimism is left empty.
  Jimmy Nilsson's Post — reflections after the Thoughtworks 'Future of Software Development' retreat — read next: Look for the promised follow-up articles and other retreat participants' write-ups that detail the specific challenges.
• uninformedThe central claim that 'the evidence is in' is asserted but the evidence itself is never presented — no measured outcomes, no specification of which patterns are effective or when. The Chatham House Rule and first-24-hours caveat partly explain this, but it leaves the confidence claim empirically ungrounded within the piece.
  Notes from FOSE Europe — read next: Seek empirical or DORA-style measurement studies of agentic-engineering outcomes, and the catalogued agentic-engineering pattern libraries the author mentions.
• incompleteThe article presents the three-layer agentic stack (orchestration, execution, review) as an emerging standard but provides no analysis of whether this architecture is actually sound or just the first thing that crystallized. There is no discussion of failure modes, debugging, or accountability within this architecture.
  Radar Trends to Watch: May 2026 — read next: Bryan Cantrill's laziness essay; 'Hidden Technical Debt of Agentic Engineering'; distributed systems architecture literature
• uninformedBooch dismisses Amodei's prediction partly on the basis that current models are trained only on previously-seen patterns, but doesn't engage with the trajectory argument — that model capability has been expanding beyond narrow CRUD patterns at a measurable rate — which is the actual empirical crux of near-term automation-timeline disagreements, rather than a settled historical analogy.
  The third golden age of software engineering – thanks to AI, with Grady Booch — read next: Pair with benchmark- or practitioner-report-driven pieces examining the rate of capability expansion across recent model releases, not just a snapshot of current limits.
• incompleteNo quantitative comparison is given between outcomes under Claude-Code-first-pass review/testing/incident-response and Anthropic's own prior, pre-Claude-Code baseline. Every improvement cited (67% PR throughput increase, faster incident root-causing, two-week migrations) is self-reported by Anthropic insiders or by customer companies with an interest in the tool's success, with no external or controlled measurement.
  How Claude Code Is Built — read next: Read against extract-dx-measuring-ai-impact and extract-five-studies-ai-software-engineering, which raise the same self-selection and construct-measurement concerns for AI-engineering-impact claims generally.
• incompleteThe article notes Anthropic deliberately keeps feature flags minimal because 'feature flags slow the team down,' but never examines whether this is sustainable given the growth-driven monitoring load the same article describes (alerts firing 'pretty much every day' simply from rapid growth) — nor what happens to blast-radius risk as Claude Code's external user base keeps scaling well past where it is today.
  How Claude Code Is Built — read next: Read against async-code-reviews-choking-throughput's discussion of trunk-based development and feature flags as an alternative risk-mitigation mechanism the article doesn't engage with directly.
• incompleteThe author treats unrestricted, cost-free access to the most expensive Claude model as a structural advantage unique to Anthropic, but never asks what Claude Code's own internal practices (TDD renaissance, 60-100 releases/day, 5+ prototypes/day) would look like, or whether they would remain viable, under the token-cost and usage-quota constraints that every other company — including Claude Code's own external users, per a reader comment quoted in the discussion thread — actually operates under.
  How Claude Code Is Built — read next: Compare against practitioner reports from non-Anthropic teams operating under real token budgets, to see which of these practices survive a hard cost constraint.
• incompleteThe 67% PR-throughput increase coincides with, but the article never disentangles from, the fact that new joiners during Anthropic's hiring surge were likely disproportionately experienced senior engineers already fluent with Claude Code's own on-distribution stack (TypeScript/React) — leaving open whether the throughput gain is attributable to Claude Code itself or to who Anthropic was able to hire.
  How Claude Code Is Built — read next: Look for engineering-productivity research that isolates tool effect from hiring-composition effect during headcount-doubling periods.
• incompleteThe claim that AI-generation-plus-review 'produces better outcomes than human-only development... for many classes of problems' never specifies which classes, nor offers defect rates, incident rates, or review-time data -- the comparison rests entirely on the author's felt experience.
  Coding agents have crossed a chasm — read next: Benchmark or incident-rate studies comparing AI-assisted vs. human-only development outcomes at a scale beyond one practitioner's personal projects.
• uninformedWritten from a solo/small-team vantage, the piece never considers what changes about the delegate-to/intern model at team or organizational scale -- whether multiple developers each treating their agent as 'their own intern' produces consistent review discipline, or how an organization would verify that review is actually happening rather than being rubber-stamped once agent output starts to feel reliably good.
  Coding agents have crossed a chasm — read next: Team-scale pieces on agent code review and governance already in the corpus, e.g. extract-agentic-ai-and-code-reviews.
• incompleteNo evidence is offered that the workflow improves outcomes. Every recommendation rests on the author's personal, weeks-long use ('outrageously useful', 'it brings me joy') and on adoption metrics (160K stars, 7M downloads on skills.sh) that measure popularity, not code quality, delivery speed, or defect rate. There is no controlled comparison against ad-hoc prompting or alternative flows, and no account of the added review burden that a mandatory code-review stage over many agent-session tickets creates.
  New Skills! v1.1 brings /wayfinder, /research, /implement, /to-spec, /to-tickets — read next: Controlled studies on whether staged / spec-driven agent flows beat ad-hoc prompting; DORA-style measurement of agentic-engineering outcomes; work on whether the review burden from many agent-produced tickets becomes the binding constraint.
• incompleteThis is a single-author, opinionated, model-dependent toolkit. Skill behaviour varies by model (the grilling-itself bug 'especially with Fable'), the design reflects one person's taste ('it brings me joy'), and there is no account of when the full lifecycle is overkill (small changes), how it holds up on large or brownfield codebases, or whether rigid phase-gating (grill -> spec -> tickets -> implement) helps or hinders an agent that might benefit from lookahead across phases.
  New Skills! v1.1 brings /wayfinder, /research, /implement, /to-spec, /to-tickets — read next: Read on model-dependence of skill/agent behaviour, on when phase gates help vs hinder AI-assisted problem-solving, and on running staged agent flows against large / legacy codebases where the assumptions (clean start, session-sized decomposition) hold least.
• incompleteThe report never quantifies how many participants held each position ('some,' 'a few,' 'many,' 'people in the second camp') or names them beyond one externally-linked Sam Ruby quote, so a reader cannot tell whether 'camp 2 offered compelling arguments' reflects a genuine majority shift or the author's own selective emphasis — the same structural problem the corpus already flags for sibling retreat reports (cf. extract-future-of-software-development#g3 on pre-filtered attendance; extract-nilsson-fose-linkedin#g4 on in-group consensus).
  Software Design in the Agentic Age: Placing Your Bets — read next: Seek an attributed, quantified account of the same debate, or dissenting views from practitioners outside this self-selected, AI-engaged invite list.
• incomplete'Rigour and engineering practices remain crucial' and the whole quality-pipeline description are reported as retreat consensus that 'seemed to feel...was working well,' with no outcome data (defect rates, cost, cycle time) — continuing the same DORA-empirics gap the corpus already flags for other retreat-adjacent reports (extract-heis-14-oystein-ulseth-pendler-lede-levere#g5; extract-fowler-fragments-july-6#g3).
  Software Design in the Agentic Age: Placing Your Bets — read next: Look for DORA-style or controlled empirical studies of agentic quality-pipeline outcomes at scale, rather than practitioner self-report.
• uninformedThe central bet on design quality depends on long-term maintainability and evolvability, yet the author concedes there 'isn't much data on long term evolvability with agentic development' because the space is young. The most load-bearing timescale of the argument is therefore supported largely by analogy to human software engineering rather than by evidence from agentic development itself.
  Software Design in the Agentic Age: Place Your Bets — read next: Watch for longitudinal studies of agent-maintained codebases as they mature, and for evidence on whether agentic assumptions about cost-of-change transfer from the human case.
• incompleteThe 'raise the floor but not the ceiling' claim is repeated approvingly but never operationalized. How does a leader, in practice, recognize ceiling-extending original work as opposed to confidently-presented model-mediated work? Without a heuristic, the framing becomes a flattering self-description rather than a usable filter.
  SWLW #701: Gazing at the misty AI Frontier, From Vibe Coding to Agentic Engineering, and more. — read next: Read Cedric Chin on tacit knowledge or Tyler Cowen on 'what counts as taste in an AI era' for concrete diagnostics; also Karpathy's full talk for his hiring criteria as a partial answer
• incompleteTwo of the curator's headline framings — 'AI raises the floor' and 'AI eats closed loops first' — are pulled toward each other but not reconciled. If AI raises the floor on closed-loop work, the implication is that closed-loop expertise becomes commodity labor while open-loop / relational / ethical work becomes the new premium. The newsletter implies this but does not state it, leaving leaders without an explicit instruction.
  SWLW #701: Gazing at the misty AI Frontier, From Vibe Coding to Agentic Engineering, and more. — read next: Elad Gil's full 'Misty AI Frontier' piece + a careful read of Yue Zhao's leadership argument against Christensen's disruption framing — the synthesis is more useful than either alone
• incompleteThe newsletter implicitly equates 'agentic engineering' (a craft skill) with 'agentic leadership' (a hiring/strategy task) but never separates them. Whether the same person should both code with agents and lead teams that code with agents — and whether the screening criteria are the same — is left ambiguous.
  SWLW #701: Gazing at the misty AI Frontier, From Vibe Coding to Agentic Engineering, and more. — read next: Bruno Fernandez-Ruiz's 'Engineering in the Compiler Age' slides (referenced here, worth a focused extraction) and Karpathy's actual hiring section to see how he separates IC craft from leadership selection
• incompleteThe 'Anthropic AI-resistant evaluation' story is treated as a positive exemplar, but the newsletter does not engage with the obvious tension: a long-horizon take-home where AI is permitted requires significant unpaid candidate time, which is a known equity problem. The curator endorses the design pattern without acknowledging its cost.
  SWLW #701: Gazing at the misty AI Frontier, From Vibe Coding to Agentic Engineering, and more. — read next: The original Anthropic write-up, plus any of the recent compensated-interview / pair-programming-screen literature, for a more honest cost-benefit picture
• illogicalThe endorsement of 'gut over head' (SahilBloom tweet) sits uneasily next to the endorsement of 'shared design concept before you code' (Pocock). The first valorizes unjustified judgment; the second valorizes explicit-and-shared rationalization before action. The newsletter treats both as obviously correct without noting that they pull in opposite directions for a leader deciding which to lean on in a given situation.
  SWLW #701: Gazing at the misty AI Frontier, From Vibe Coding to Agentic Engineering, and more. — read next: Daniel Kahneman on when intuition is trustworthy (closed environments with rapid feedback — i.e., precisely the closed loops AI is eating); Gary Klein's recognition-primed decision research for the conditions under which gut beats analysis
• incompleteThe issue diagnoses AI-era pressures (salary-scale economics, direction-less amplification, agent reliability, term-inflation) and poses them as open questions to the reader ('where does your company sit?', 'what would you do differently?') but never synthesizes them into an operating model — it stops short of what a leader should actually do.
  SWLW #710: Revised rules of Eng Leadership, When AI costs more than the engineer, and more. — read next: Will Larson's 'Revised Rules of Engineering Leadership' itself (the linked favorite), and John Cutler / engineering-strategy sources that convert principles into concrete decision rules.
• incompleteThe continuity framing (fundamentals and judgment are what matter, AI only raises their stakes) under-weights the possibility that some fundamentals themselves must change under AI — it treats 'fundamentals' as fixed rather than a live question.
  SWLW #710: Revised rules of Eng Leadership, When AI costs more than the engineer, and more. — read next: Sources debating whether the fundamentals taught today are still the right ones (e.g. Tobias Torrissen on juniors and fundamentals; 'The Future of Software Engineering' on mid-level retraining).
• incompleteAI/agent-assisted development is conspicuously absent from an essay published in 2025/2026 about how teams are defined. If a meaningful share of engineering work is mediated by agents, the definition of 'team', headcount-as-cost, and the engineering manager's role all shift. Cutler doesn't touch this, though it is plausibly the next pendulum swing.
  TBM 423: Why Defining Teams Is So Hard — read next: DORA AI capabilities report; Kent Beck on AI-assisted design ('Tidy First?' series); Addy Osmani / Steve Yegge on agentic engineering; Cutler's own TBM pieces on institutional overload and AI (TBM 412).
• incompleteThe document identifies the productivity/experience paradox but offers no framework for resolving it beyond the 'agent experience' reframe. How should organizations actually measure and invest in developer satisfaction when it is decoupled from output?
  The Future Of Software Engineering — read next: DORA team's ongoing research on developer experience metrics; Nicole Forsgren's work on SPACE framework
• incompleteThe batch-size regression is flagged as an 'active regression needing industry attention' but no countermeasures are proposed beyond general governance reform.
  The Future Of Software Engineering — read next: DORA State of DevOps reports; continuous delivery literature on changeset sizing with AI tools
• incompleteNewman explicitly leaves the AI-agent guardrails question open in the Q&A, but the talk never develops what a structural, Ronan-Point-style progressive collapse specific to AI-agent-produced software would actually look like — e.g., whether a single flawed architectural pattern an agent replicates across many services or many repositories is the software analogue of Ronan Point's shared, flawed prefab construction system, and if so, what 'reduce interconnection' would mean for a fleet of AI-generated services sharing the same generative pattern or the same underlying model.
  Presentation: Understanding Progressive Collapse: How To Avoid A Cascading Failure — read next: Corpus material on agentic engineering and code-quality risk from AI-generated code at scale; look for post-incident analyses of correlated failures traced to a shared AI-generated pattern or shared prompt/skill.
• incompleteThe claim that this is a tooling-level change rather than a process paradigm shift is offered with no argued criterion for what would count as a 'paradigm shift' versus 'just faster tooling' — making the claim hard to falsify and, read against three years of subsequent change in how software gets built (specs-as-code, agent-run verification loops, the SDLC itself being restructured), looks understated in hindsight even on the speakers' own terms.
  How AI coding companions will change the way developers work — read next: extract-addy-osmani-software-factories-light-dark.json or similar later material explicitly arguing the SDLC itself, not just the typing, has changed.
• incompleteThe 'usage as trust signal' argument assumes that usage reveals bugs, but many serious defects (security vulnerabilities, data races, subtle data corruption) can lurk for months or years without being triggered by normal usage. Usage is a better signal than artifact appearance, but it is not a sufficient signal for safety-critical properties.
  Vibe coding and agentic engineering are getting closer than I'd like — read next: Literature on latent defects in software; Nancy Leveson's work on system safety; the Therac-25 case.
• incompleteThe essay treats the accountability gap between human teams and AI agents as an acknowledged discomfort but does not explore solutions — contractual liability, organizational accountability structures, or the possibility that AI vendors could offer guarantees or insurance for agent-produced code.
  Vibe coding and agentic engineering are getting closer than I'd like — read next: Legal scholarship on AI liability; Anthropic's own responsible scaling policy; discussions of AI insurance markets.
• incompleteHe asserts taste cannot be tested but never addresses how taste is developed or transmitted. He brings pre-existing taste to every judgment (the population-map problem, the anglophone-Wikipedia bias, the suspect Reykjavik=10) yet treats it as a given human endowment — silent on how a novice, a team, or the next generation would acquire or inherit it, especially once AI removes the on-ramp tasks that used to build it.
  You can't unit test for taste — read next: Read Polanyi on tacit knowledge and Dreyfus on skill acquisition (novice-to-expert); pair with the corpus's junior-apprenticeship thread (heis-09, heis-12, ki-utvikling-og-folelser) and Beck 'Tidy First?' / Ousterhout on design judgment as cultivated rather than innate. Ask: does taste transmit at all when AI removes the practice that used to form it?
• incompleteHe confines 'you can't unit test for taste' to messy data and treats code as the safely 'verifiable domain,' but never turns the lens onto AI-generated code itself, where tests pass yet design taste — simplicity, deep modules, restraint — has no red/green check. As agents generate more test-passing code, the untestable-taste problem migrates into the codebase, not away from it.
  You can't unit test for taste — read next: Read Ousterhout 'A Philosophy of Software Design,' Beck 'Tidy First?,' and Hickey 'Simple Made Easy' on design quality as unassertable; cross with corpus docs agents-dont-know-what-good-looks-like (behavioral vs capability verification) and cognitive-surrender (surface-correctness signals). Test the claim: is a green build ever evidence of good design?
• incompleteHe delegates the 'subjective' rating to the LLM's latent weights and finds it useful, but never examines whether that latent 'taste' is genuine judgment or averaged internet popularity — i.e., whether outsourcing scoring to a model launders the very anglophone-Wikipedia bias he diagnosed a section earlier into a 'subjective score' he can no longer see or audit.
  You can't unit test for taste — read next: Read on models as reflections of their training distribution (Bender et al.) and on popularity-as-proxy-for-quality critiques; probe the LLM ratings against non-anglophone sources to see whether the 'taste' is judgment or a re-encoding of who edits Wikipedia.