Feedback Loops

Automated signals — tests, linters, type checks, AI reviews — that let humans and agents detect and correct errors quickly; their quality sets the ceiling on AI-assisted work.

Also known as: feedback loops, feedback loop, feedback loops (as ceiling), fast feedback, feedback speed / feedback loop, sensors (feedback controls), sensor, computational sensor, inferential sensor, computational controls, inferential controls, guides (feedforward controls), self-correction guidance, steering loop, Feedback Flywheel, double feedback loop, outrunning your headlights, observability, degree of automated verification

How authors use it

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

Documents (58)

• Agentic AI and Code Reviews Zach Davis, Michelle Gill, Elisabeth Hendrickson, Angie Jones, Sha Ma, Randy Shoup, James Wickett · 2026-09-14 source ↗ Reader 🖥️
  As AI agents generate code faster than human attention can scale to review it, code review must be reorganized from a single human merge-time gate into a layered, risk-tiered verification system — deterministic checks, continuous author/review-agent loops, structurally independent adversarial review, and specialist multi-agent review — with human judgment deliberately reserved for intent, strategic risk, and accountability rather than mechanical inspection, and every automated decision recorded as a durable, auditable artifact.
• John Cutler's Post John Cutler · 2026-09-12 source ↗ Reader 🖥️
  Shifting from outputs to outcomes fails not because the idea is wrong but because teams adopt the language of outcomes while keeping the psychology of outputs — chasing certainty, easy measurement, and reputational credit instead of committing to the qualitative judgment, tolerance for ambiguity, and honest attribution that outcome-orientation actually demands.
• How LinkedIn Trains AI Job Search 8x Faster with Multi-Teacher Distillation Claudio Masolo · 2026-09-11 source ↗ Reader 🖥️
  LinkedIn made multi-teacher knowledge distillation practical for its production job-search ranking system not through a distillation-algorithm breakthrough but through training-infrastructure engineering — a custom SGLang-based framework that serves teacher models directly inside the training loop (an online mode for fast iteration, an offline precomputed-and-cached mode once teachers stabilize) plus a stack of largely independent training-speed optimizations — collectively yielding a roughly eightfold training speedup that lets a compact 0.6B student model approach cross-encoder-quality ranking while avoiding the cost and latency of calling a frontier LLM on every search request.
• Is Your Strategic Plan Too Ambitious? Or Not Ambitious Enough? Rebecca Knight · 2026-09-10 source ↗ Reader 🖥️
  How ambitious a strategic plan should be is not an intrinsic property of the target number but something you calibrate by systematically examining the underlying problem, your available resources and talent, your tolerance for uncertainty, your measurement time horizon, and your competitive position — a deliberate exercise most organizations skip, defaulting instead to timid, business-as-usual plans.
• Meta's Recipe for Building Agents as "Organizational Second Brains" Sergio De Simone · 2026-09-09 source ↗ Reader 🖥️
  To make an AI agent trustworthy as an organizational domain expert rather than just a document-retrieval tool, keep institutional knowledge entirely out of the model's weights and instead encode it in structured, version-controlled, auditable files consulted by an explicit and testable reasoning layer, with human experts as a permanent, recorded correction source — so the agent's expertise compounds reliably through a self-improvement loop instead of eroding or hallucinating over time.
• Presentation: From AI Agent Demo to Production: Automated Testing and Evaluation Zhou Yu · 2026-09-07 source ↗ Reader 🖥️
  Because static, single-turn benchmarks with fixed golden answers cannot evaluate multi-turn, tool-using agents whose correctness depends on live backend state and conversational history, teams must replace ad hoc manual testing with AI-simulated user personas that generate realistic, coverage-optimized conversation trajectories against which scenario-grounded, automated evaluation can run inside CI/CD — turning agent testing from the manual bottleneck that keeps roughly 95% of agents stuck in demo into a scalable, continuously-refreshed, self-improving production pipeline.
• The AI-Native SDLC playbook Louis Claxton · 2026-08-21 source ↗ Reader 🖥️
  Once agentic coding collapses the build phase to hours, the traditional SDLC's human-speed controls (committees, meetings, line-by-line review) become the bottleneck and stop matching reality, so organizations should rebuild the lifecycle as a non-linear loop of six stages (plan, design, build, test, deploy, maintain) where every stage commits a version-controlled artifact the next stage reads, human judgment concentrates at artifact-acceptance gates rather than at the point of production, and governance is enforced as code (hooks, branch protection, managed settings) rather than through periodic human review bodies.
• Addy Osmani's Post Addy Osmani · 2026-08-01 source ↗ Reader 🖥️
  Because agents can now generate more code than people can read, software quality control must move from human inspection of the code itself into deterministic constraints (tests, checks, metrics) engineered into the harness and environment around the agent.
• Pascal BORNET's Post Pascal BORNET · 2026-08-01 Reader 🖥️
  Organizations mistake a team's ability to keep performing despite a broken system (endurance, sustained by workarounds and quiet compensation from strong employees and loyal managers) for evidence that the system itself is healthy, and leaders should instead treat the places demanding the most resilience as the places most in need of structural redesign.
• Grafana's gcx and MCP Server Reach GA for Telemetry-Driven Agent Development Claudio Masolo · 2026-08 source ↗ Reader 🖥️
  As AI coding agents let engineers generate diffs faster than they (or reviewing agents) can build genuine understanding of them, Grafana's newly-GA gcx CLI and MCP server let those same agents query live observability data (metrics, logs, traces, SLOs) during development, so that implementation and testing decisions are grounded in and checked against actual system behavior rather than training-data assumptions or a code review that has become unreliable.
• John Cutler's Post John Cutler · 2026-07-31 Reader 🖥️
  In an environment where every competitor has access to the same AI technology, durable advantage comes not from adopting AI fastest but from building — through problem-first, hypothesis-driven experimentation and a genuine social contract of trust — a team practice that learns faster than the surrounding hype cycle.
• 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.
• AWS Billing Bug Shows Customers Trillion-Dollar Estimates While Its Own Cost Alarms Fail to Act Steef-Jan Wiggers · 2026-07-27 source ↗ Reader 🖥️
  AWS's July 2026 billing-estimate incident -- in which a single unit-pricing bug displayed trillion-dollar phantom bills to customers for over 24 hours while AWS's own cost-anomaly alarms detected the anomaly but failed to halt the pipeline, alert engineers, or trigger any automated safeguard -- shows that billing telemetry is itself a fallible system dependency whose failure modes propagate into every automated cost control built on top of it, exposing that AWS still gives customers no way to convert an alert into a hard spending limit.
• The Meter Was Always Running Bennie Haelen · 2026-07-23 source ↗ Reader 🖥️
  Because a control plane can only govern a loop it can independently observe, organizations running tool-using agents must build one below-the-agent, turn-level, fleet-queryable observability substrate -- not per-run trace viewers, billing dashboards, or agent self-reporting -- and that single substrate, not three separate systems, is what answers cost, delegation, and runaway-action governance at once.
• How Do You Know That? Kent Beck — Still Burning Podcast · 2026-07-22 Reader 🖥️
  The skill that matters most — in engineering craft, in working with AI agents, and in locating accountability when automated systems act — isn't knowing the answer but asking 'how do you know that?': interrogating the actual reasons behind behavior, code, and systems, because that meta-intelligence diagnoses root causes invisible to observers of behavior alone, and because AI agents, having no drive or accountability of their own, can never do that interrogating or that owning on a human's behalf.
• Fragments: July 21 Martin Fowler · 2026-07-21 source ↗ Reader 🖥️
  This is not a single-thesis essay but a set of retreat dispatches with no forced unifying claim; the headline findings from the underlying Thoughtworks report are quoted up front but only two of the five (the executive/engineer expectation gap, and — more thinly — verification-as-bottleneck) are actually elaborated in the body, while the recurring thread that does run through the fragments that follow is a practitioner's-eye skepticism about the gap between AI hype and what people who actually work with LLMs observe — in board expectations, incident response, vibe-coding governance, and even the felt experience of reading AI-touched prose.
• Google's AlphaEvolve Reaches General Availability with Evolutionary Code Optimization as a Service Steef-Jan Wiggers · 2026-07-19 Reader 🖥️
  AlphaEvolve's move from DeepMind research project to generally-available Google Cloud product proves that LLM-driven evolutionary code optimization delivers real, substantial engineering gains, but only inside the narrow band of problems that already have (or can be given) a precise, automatable evaluation function -- outside that band, in the 'messy' business logic that makes up most production software, the approach currently has no demonstrated purchase, and the announcement's vendor-only evidence means even the in-band gains should be read as directional, not verified.
• A cautionary tale about AI in tech writing: Why "Trust but Verify" is the only way to scale Betsalel (Saul) Williamson · 2026-07-13 Reader 🖥️
  The genuinely scalable use of AI in technical documentation is not to trust the LLM's raw output but to wrap it in a software-development-style pipeline -- specs as ground truth, deterministic tools (linters, formatters, style checkers) doing everything mechanical, and human 'trust but verify' review concentrated only on the residual, non-automatable judgment work (procedure validity, UX intent, omission, accountability) -- so that the 8-hour/17,500-word claim is evidence not that AI collapses the verification burden of technical writing but that a disciplined pipeline can relocate and compress it enough to make speed and rigor compatible.
• 11 Tips For AI Coding With Ralph Wiggum Matt Pocock · 2026-07-11 source ↗ Reader 🖥️
  Autonomous agent loops ("Ralph") become reliably productive only when the human stops writing code and instead wraps the loop in disciplined scaffolding — an explicit end-state/stop-condition, an externalized progress file, commit-blocking feedback loops, small steps, risk-first sequencing, stated quality expectations and a sandbox — scaffolding that compensates for the agent's lack of judgment and cross-session memory and that, unguardrailed, would let the loop accelerate software entropy.
• AI Enthusiasts Are in a Race Against Time, AI Skeptics Are in a Race Against Entropy Charity Majors · 2026-07-11 Reader 🖥️
  The AI enthusiast-versus-skeptic split inside high-performing engineering orgs is not one side being right and the other wrong but two groups each responding to a real existential threat (missed windows vs. systems decaying into slop) that they never see the other's side of, and the cure is to rebuild a shared reality by telling the whole story and then treat AI adoption as an engineering problem rather than a rhetorical war.
• OpenAI Fixes 18-Year-Old GNU libunwind Bug by Treating Crash Debugging Like Epidemiology Steef-Jan Wiggers · 2026-07-11 Reader 🖥️
  When production crashes resist every hypothesis, the fastest way to see their structure is not deeper analysis of individual cases but building a complete, labeled dataset across the whole population of failures — a population-level, epidemiological approach that revealed OpenAI had conflated two unrelated bugs (silent CPU corruption on one Azure host and an 18-year-old race condition in GNU libunwind's setcontext) into a single unsolvable mystery.
• How Datadog Used Claude and Cursor for Test-Driven Production Migration Sergio De Simone · 2026-07-10 Reader 🖥️
  Datadog's AI-assisted migration of a critical production system off a key-value backend onto a relational one succeeded not because Claude and Cursor generated code autonomously, but because a strong human-authored test suite plus a live blue/green validator supplied the pass/fail oracle that bounded and verified every AI-generated change — making the coverage of that verification, not the capability of the model, the ceiling on how much AI output could be trusted.
• Slack Introduces Agent Driven End-to-End Testing to Improve Resilience in UI Test Automation Leela Kumili · 2026-07-10 Reader 🖥️
  Agentic testing — AI agents that execute end-to-end tests from a high-level intent rather than fixed scripts, adapting around superficial UI or service changes instead of failing — reduces brittle-test maintenance and belongs as a complementary top layer of the test pyramid, reserved for debugging and exploratory use because of cost, while deterministic tests remain the primary mechanism for validating critical logic.
• 20 Loop Design Patterns Every AI Engineer Should Know Rahul (@sairahul1) · 2026-07-08 Reader 🖥️
  Reliability and quality in production AI come not from bigger models or better prompts but from wrapping model calls in an improvement loop (generate -> evaluate -> learn -> adjust), and here is a taxonomy of ~20 such loops -- all of which, the thread finally concedes, reduce to one substrate: Act -> Observe -> Evaluate -> Adjust.
• The Anatomy of an Agent Harness Akshay · 2026-07-08 Reader 🖥️
  An agent harness is not monolithic prompt-glue but a decomposable system of roughly twelve components (orchestration loop, tools, memory, context management, prompt construction, output parsing, state, error handling, guardrails, verification, subagents) plus seven design-decision axes, and naming the parts is what lets you reason about, debug, and — because the parts are treated as separable and independently improvable — evolve agent behavior; yet as delivered the list reads as a convergent practitioner checklist organized by mechanism and vendor vocabulary rather than an orthogonal, coupling-minimizing decomposition with defined interfaces.
• Experiences with local models for coding Birgitta Böckeler · 2026-07-08 source ↗ Reader 🖥️
  Running small, locally-hosted open models for agentic coding is not yet a plug-and-play substitute for frontier models — it remains frustrating and far below frontier capability, and is viable today only for a narrow class of small, well-scoped, often pre-planned tasks, with the choice of task (more than the model or harness) being the dominant factor that determines whether it works.
• Shifting Platform Development from Projects to Products Ben Linders · 2026-07-02 source ↗ Reader 🖥️
  Once an internal platform outgrows serving a single team, the project model — upfront scope, milestone delivery, and velocity/completion metrics — stops producing a coherent, usable system, and the platform must instead be run as a product: driven by user problems, hypothesis-based roadmaps, self-service APIs, clear tenancy boundaries, and adoption metrics.
• 5 Things World-Class Engineers Do That You Don't Steve Huynh · 2026-07-01 source ↗ Reader 🖥️
  Elite engineers are distinguished not by raw intelligence or effort but by five deliberate practices the author claims to have observed repeatedly across podcast conversations with principal/distinguished engineers: measuring growth monthly rather than waiting for reviews, amplifying colleagues instead of maximizing solo output, absorbing complexity so customers experience simplicity, deliberately avoiding the crowded competitive path, and converting personal failures into institutional lessons.
• 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.
• Three more static code analysis sensors Birgitta Böckeler (published on martinfowler.com) · 2026-05-20 source ↗ Reader 🖥️
  For maintainability concerns that cross file and module boundaries, computational static-analysis sensors (dependency rules, coupling metrics) can usefully enforce a few structural invariants but cannot judge what coupling is appropriate; the most productive sensor is an inferential, prompt-driven AI modularity review that reads the code itself, with the deterministic tools relegated to enforcement of known rules and to triage of review attention.
• Maintainability sensors for coding agents Birgitta Böckeler · 2026-05-19 source ↗ Reader 🖥️
  Static analysis tools like ESLint, now cheap to customize because AI can write the rules and messages, are an immediately high-value sensor for keeping an AI coding agent's output maintainable — provided their warnings are rewritten as explicit self-correction guidance for the agent rather than left as generic human-facing messages — but this same newfound ease risks producing feedback overload and a false sense of quality assurance.
• DoorDash Used Copilot to Convert Its XCTest-Based iOS Test Suite to Swift Testing Sergio De Simone · 2026-05-09 source ↗ Reader 🖥️
  DoorDash migrated its iOS test suite from XCTest to Swift Testing at scale by combining AI-assisted code transformation (Cursor/Copilot with migration rules) with strict reliability gates (ten-consecutive-pass requirement), achieving ~60% faster CI tests while surfacing hidden concurrency defects that sequential execution had masked.
• Fragments: May 5 Martin Fowler · 2026-05-05 source ↗ Reader 🖥️
  The current moment in AI-assisted software development is defined by a tension between the power of cloud-hosted AI genies and the risks they carry — to code quality, to truth, to budgets, and to autonomy — and the pieces Fowler curates collectively ask whether the escape route runs through disciplined engineering practice, local-first computing, or some combination of both.
• How to Build a Superteam That Keeps Getting Better Harvard Business Review · 2026-05-01 source ↗ Reader 🖥️
  In periods of rapid change, teams win not because they start with the best plans or the most talent but because their leaders build a continuous-improvement culture — one that makes experimentation, curiosity, early problem-surfacing, hands-on involvement, non-threatening feedback, and growth-oriented investment in people the daily default — so the team's rate of learning, not its starting position, determines whether it becomes a 'superteam.'
• [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.
• It Ain't Broke: Why Software Fundamentals Matter More Than Ever Matt Pocock (AI Hero conference talk, AI Engineer) · 2026-04-23 Reader 🖥️
  Because AI amplifies the cost of bad code through software entropy, investing in software design fundamentals — shared understanding, ubiquitous language, deep modules, TDD, and deliberate architecture — matters more in the AI era than it ever did before.
• 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.
• Sam Hatoum's Post Sam Hatoum · 2026-04-20 source ↗ Reader 🖥️
  Spec-driven development with AI is not waterfall because waterfall's fatal flaw was slow feedback, not specifications themselves, and AI collapses the feedback loop from months to minutes — making specs more essential, not less.
• Presentation: How Netflix Shapes our Fleet for Efficiency and Reliability Joseph Lynch, Argha C · 2026-04-20 Reader 🖥️
  Efficiency and reliability are not opposing goals but a single optimization problem: by reasoning about risk-adjusted cost (not utilization) and managing the balance of hardware supply against software demand through layered proactive and reactive levers, you can run critical services with high reliability while spending less overall.
• Architecture as Code to Teach Humans and Agents About Architecture Neal Ford and Mark Richards · 2026-04-15 Reader 🖥️
  Software architecture should be defined as code — capturing structural constraints deterministically — so that both human developers and AI agents can receive fast feedback on whether implementations conform to design intent.
• Technology Radar, Volume 34 Thoughtworks (Technology Advisory Board) · 2026-04-14 source ↗ Reader 🖥️
  AI-assisted, agentic software development is moving faster than the industry's ability to evaluate it, which means teams must simultaneously retain long-held craftsmanship principles (testability, deliberate design, feedback loops) and rethink team/agent topologies, trust boundaries and metrics that were built for a pre-agent world.
• How to Turn Individual Talent into Organizational Excellence Harvard Business Review · 2026-03-12 Reader 🖥️
  Sustained organizational excellence is produced not by individual talent, hiring, or motivation but by a deliberately designed system in which talent development, socially-enforced team standards, and disciplined recurring routines reinforce one another.
• Patterns for Reducing Friction in AI-Assisted Development Rahul Garg · 2026-02-24 source ↗ Reader 🖥️
  AI coding assistants produce misaligned output not because they lack capability but because developers skip the same onboarding, design discussion, and standards-sharing rituals that make human pair programming effective, and adopting five collaboration patterns that mirror those rituals can transform AI from a source of friction into a force multiplier.
• Harness engineering: leveraging Codex in an agent-first world Ryan Lopopolo (OpenAI) · 2026-02-11 source ↗ Reader 🖥️
  Building a product with zero manually-written code at scale (one million-plus lines, five months, a team that grew from three to seven engineers with throughput that increased rather than degraded) required redefining engineering work from writing code to designing environments, pushing all team knowledge into repository-local legible artifacts, mechanically enforcing architectural invariants and documentation freshness, and relaxing human-paced process norms (blocking merge gates, manual cleanup) in favor of continuous, agent-driven correction — because human time and attention, not code production, is the one truly scarce resource the whole system must be organized to protect.
• Why Rust is different, with Alice Ryhl The Pragmatic Engineer (Gergely Orosz, host) · 2026 Reader 🖥️
  Rust earns its growing adoption not by adding features but by systematically engineering away whole classes of programmer mistakes — null, uninitialized memory, unhandled errors, stale documentation, memory-unsafety, non-exhaustive matches — through a type system, ownership/borrow checker, and a governance and tooling culture (RFCs, editions, Cargo, doc-tests) that treats reliability as a composite property rather than a single feature.
• Nick Tune's Post Nick Tune · 2025-12-03 source ↗ Reader 🖥️
  Good system prompts, skills, and rules are not sufficient to make AI-generated code reliable because AI does not follow instructions reliably enough on their own; once prompt tuning hits diminishing returns, the more effective lever is strengthening feedback loops and guardrails -- strict lint rules, minimum test coverage, and automated review of AI-written code.
• A pragmatic guide to LLM evals for devs The Pragmatic Engineer · 2025-12-02 Reader 🖥️
  LLM evaluation cannot be bolted on as generic scored metrics or traditional deterministic unit tests; it must be built bottom-up from systematic error analysis of real interaction traces, using code-based assertions for objectively-checkable failures and a human-calibrated LLM-as-judge for subjective ones.
• How to measure AI developer productivity in 2025 | Nicole Forsgren Lenny's Podcast (Lenny Rachitsky interviewing Nicole Forsgren) · 2025-10-19 source ↗ Reader 🖥️
  Because lines-of-code-style productivity metrics are trivially gamed by verbose LLM output and the DORA/SPACE frameworks were not designed for AI's new failure modes (earlier and faster feedback loops, nondeterministic output requiring trust verification, review time displacing writing time), measuring whether AI is actually helping developers requires starting with qualitative listening and short forced-choice surveys, adding trust as an explicit new dimension, and framing whatever is measured in the specific business terms (market share, margin, velocity) that an organization's leadership already uses -- while openly acknowledging that AI's contribution usually can't be cleanly separated from concurrent developer-experience improvements.
• Disposable Code Is Here to Stay, but Durable Code Is What Runs the World Charity Majors · 2025-07-29 source ↗ Reader 🖥️
  Software development is splitting into two durably separate domains -- cheap, AI-generated disposable code and expensive, trust-earning durable code -- and because the cost of software is defined by its maintenance rather than its authorship, generative AI changes who can write code but does not eliminate the need for the fast-feedback-loop engineering discipline (tests, CI/CD, observability) that durable code has always required.
• Claude Code: Best practices for agentic coding anthropic.com · 2025-04-18 source ↗ Reader 🖥️
  Because Claude Code is deliberately low-level and unopinionated, its effectiveness on your problem is set by the harness you engineer around the model — the context, tools, and workflow you supply — not by the raw model alone.
• 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.
• Software Development As Collective Learning With Hazel Weakly John Cutler from The Beautiful Mess · 2024-04-28 Reader 🖥️
  Effective software development is produced by the emergent, collective behavior of a system of collaborating people, not by maximizing any individual's personal output as a 'force multiplier'; the real job shared by architecture and leadership is building explicit, intentional structures for how people learn, decide, and check in with each other, so that many independent local decisions add up to globally coherent outcomes, and so that structural change (migrations, reorgs) can happen continuously and safely rather than through disruptive one-off events.
• Automated Bug Fixing at Facebook Scale ByteByteGo · 2024-03-05 source ↗ Reader 🖥️
  SapFix demonstrates that an end-to-end automated program-repair pipeline — combining mutation- and template-based patch generation (fed by patterns from Getafix), automated test design (Sapienz), and static-analysis fault localization (Infer) — can operate at industrial, multi-million-line-codebase scale, but even at Facebook's scale the system is deliberately stopped one step short of full autonomy: it proposes tested candidate patches and routes every one through a specific, context-qualified human reviewer rather than deploying any fix on its own.
• Scaling the Practice of Architecture, Conversationally Andrew Harmel-Law · 2021-11-30 source ↗ Reader 🖥️
  Architecture should be practiced as a decentralized, conversational discipline — anyone can make an architectural decision as long as they first seek out and record advice from those meaningfully affected and those with relevant expertise (the 'Advice Process') — supported by four lightweight tools (Architecture Decision Records, a recurring Architecture Advisory Forum, team-sourced architectural principles, and a technology radar) that let architecture scale with team autonomy instead of being bottlenecked on a small group of designated architects.
• Why your team doesn't need to use pull requests infrastructure-as-code.com (Kief Morris) · 2021-01-02 source ↗ Reader 🖥️
  Pull requests were designed to vet contributions from untrusted outside contributors, so applying them to a trusted team's own code sacrifices Continuous Integration's fast feedback and flow for no corresponding risk-reduction benefit; teams should instead integrate continuously and get code review through pairing, periodic group reviews, or post-integration pipeline approval gates.

Propositions touching this concept (78)

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

2018-07

• explicitThe proposed mechanism is a balancing feedback loop of privacy restoration: increasing observability ('transparency') triggers a natural human response to preserve privacy by socially withdrawing from co-present peers (e.g., headphones, avoidance) and re-routing interaction to email/IM rather than converse in front of a visible audience of colleagues.
  The impact of the 'open' workspace on human collaboration · p3

2019-02

• explicitReleasing frequently (weekly, fortnightly, or daily) increases both engineer motivation and overall velocity, by shortening the feedback loop between writing code and seeing its effect.
  Software Engineering at Google · p7

2021-01

• explicitPairing, periodic (e.g. weekly) group reviews, and post-integration pipeline-approval gates each provide meaningful human code review without delaying the CI integration/feedback loop, and can be combined.
  Why your team doesn't need to use pull requests · p8
• explicitA faster, more frequent coding-integration-feedback loop (enabled by CI, discouraged by PR batch-and-wait) encourages smaller, more frequent commits, which improves both quality and flow.
  Why your team doesn't need to use pull requests · p9

2021-04

• explicitSociotechnical Architecture does not require full upfront design of all systems together; it requires feedback loops ('sensors') on the structural elements, visible properties, and relations of the What/Who/How systems sufficient to ground decisions, preserving each part's execution autonomy.
  Sociotechnical Architecture as Enabler of Product Thinking · p6

2024-04

• explicitAs a leader's position rises, the direct feedback loop on their own decisions lengthens drastically -- roughly 3-6 months for managers, 1-3 years for directors, 5-10 years for CTOs -- meaning an executive who only learns from observed outcomes will learn at most two lessons across an entire career, so leaders must build faster, deliberate introspection and alternative feedback mechanisms.
  Software Development As Collective Learning With Hazel Weakly · p10

2024-06

• explicitcorroboratedThe 'generative AI is like an excitable junior engineer' analogy only holds for disposable, self-contained code never meant to be integrated into a larger body of work or maintained by others — which is a narrow and atypical case; for ordinary production code the analogy fails because AI provides no feedback loop, no apprenticeship relationship, and no contribution to team culture.
  Generative AI Is Not Going To Build Your Engineering Team For You · p4

2025-02

• explicitAs AI absorbs more of the mechanics of writing code, developers will increasingly focus on problem framing, feedback loops, and architecture — continuing a decades-long trend of raising the abstraction level (punch cards -> assembly -> compiled high-level languages -> AI-generated code).
  The Future of Work by Henrik Kniberg · p11

2025-03

• explicitUsing AI coding tools has addictive properties similar to slot machines, with sunk cost fallacy and tiredness feedback loops degrading output quality.
  Eight years of wanting, three months of building with AI · p7

2025-06

• explicitSeveral teams build a self-reinforcing feedback loop in which the agent itself is asked to update its own guiding documentation (end-of-session summaries, workflow-instruction refinements) after each task, so institutional knowledge accumulates automatically rather than depending on someone remembering to write it down.
  How Anthropic Teams Use Claude Code · p6

2025-07

• explicitInvesting in fast feedback loops (frontloaded tests, CI/CD, observability) is the cheapest and easiest way to build good durable software, not overhead on top of 'real' development work.
  Disposable Code Is Here to Stay, but Durable Code Is What Runs the World · p3
• explicitcorroboratedOnly companies that had already invested in reliability and observability before adopting AI are the ones currently realizing efficiency gains from AI -- AI has made fast feedback loops and software guardrails more important, not less.
  Disposable Code Is Here to Stay, but Durable Code Is What Runs the World · p4

2025-10

• explicitDORA's four metrics (deployment frequency, lead time, MTTR, change fail rate) still work for assessing the overall speed and stability of a delivery pipeline, but can't be applied blindly in the AI era, because feedback loops now need to happen much earlier and faster than the pipeline-level feedback DORA was originally built to capture.
  How to measure AI developer productivity in 2025 | Nicole Forsgren · p3

2025-12

• explicitAn investment of a few hours building a custom, domain-tailored data viewer materially increases the speed and quality of manual trace review compared to generic off-the-shelf observability tools.
  A pragmatic guide to LLM evals for devs · p6
• explicit'Spec-driven development' as a term has undergone semantic diffusion (per Fowler's 2006 framing, and the earlier fate of the word 'agent') to the point of uselessness as a label — now meaning anything from a more detailed prompt, to a product requirements document, to literal code-as-assembly, to documentation for an open-source library — even though some version of the underlying discipline (compressed intent, verifiable feedback loops) remains valuable under the author's own preferred framing.
  No Vibes Allowed: Solving Hard Problems in Complex Codebases – Dex Horthy, HumanLayer · p9
• explicitAs coding stops being the bottleneck, the business must get directly and immediately involved in the (now faster) feedback loop, changing company governance structure.
  Steve Yegge's Vibe Coding Manifesto: Why Claude Code Isn't It & What Comes After the IDE · p9
• explicitCombining prompts/skills/rules with feedback loops -- strong lint rules, minimum test coverage, and automated review of AI-generated code -- is where results start to materially improve.
  Nick Tune's Post · p3
• explicitIf results plateau despite prompt effort, that plateau signals diminishing returns on prompt engineering specifically, and the better next investment is feedback loops and guardrails rather than further prompt tuning.
  Nick Tune's Post · p4

2026-01

• explicitA team-wide CLAUDE.md instructional file (e.g. 'always run via this command,' 'always lint before a PR') and giving the agent a way to verify its own work are, in Boris Cherny's account, the most important levers for getting high-quality results — he states that a working verification feedback loop alone can 2-3x result quality.
  The Pulse #158: New Ways Of Coding With AI Tools · p7
• explicitGetting good at testing and test infrastructure becomes more important, not less, because an agent needs fast feedback signals (compilation, static analysis, automated tests) to be effective and less prone to hallucination — and because the author personally cannot trust AI-generated code without unit/integration/end-to-end tests, while finding AI itself unreliable at writing good tests without targeted prompting.
  When AI Writes Almost All Code, What Happens To Software Engineering? · p7
• explicitcorroboratedBeing a solid software engineer rather than merely a 'coder' will be more sought-after than before, because the engineering discipline (verification, tight feedback loops) is what makes AI-generated volume actually work, and 2025's vibe-coding wave already showed nontechnical people struggling to build software that actually works even with AI generating their code.
  When AI Writes Almost All Code, What Happens To Software Engineering? · p9

2026-02

• explicitOver five months, a team of initially three (growing to seven) engineers built an internal product to roughly one million lines of code, with zero manually-written code across application logic, tests, CI configuration, documentation, observability, and tooling — all written by Codex — in an estimated one-tenth the time hand-writing it would have taken.
  Harness engineering: leveraging Codex in an agent-first world · p1
• explicitThe engineering team's primary job shifted from writing code to designing environments, specifying intent, and building feedback loops that let Codex agents do reliable work — summarized by the team as 'humans steer, agents execute.'
  Harness engineering: leveraging Codex in an agent-first world · p3
• explicitThe team's own retrospective frames its central lesson as: discipline in agent-generated software now shows up in the scaffolding (environments, feedback loops, control systems) rather than in the code itself — reframing 'engineering discipline' away from code-level craft and toward environment design as the locus of rigor.
  Harness engineering: leveraging Codex in an agent-first world · p17

2026-03

• explicitThe wording of grading criteria steers model output independent of and prior to the evaluator-feedback loop — including stylistic convergence (e.g. 'museum quality' pushing toward a particular look).
  Harness design for long-running application development · p5
• explicitTeams with good engineering practices (fast feedback, observability, frequent delivery) get a steep productivity step-up from AI; teams without amplify their existing chaos.
  13) Tobias K. Torrissen om kodekvalitet, konferanser og AI · p6

2026-04

• explicitcorroboratedBad codebases produce bad agents; the quality of automated feedback loops (tests, types, lint) is the ceiling on the agent's output quality.
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero · p8
• explicitDevelopers should own their planning stack rather than adopt off-the-shelf frameworks (SpecKit, OpenSpec, TaskMaster); without ownership, when the stack fails you have no observability.
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero · p16
• explicitdevelopedDefining architecture as code creates a fast feedback loop that lets architects detect when implementation diverges from design.
  Architecture as Code to Teach Humans and Agents About Architecture · p1
• explicitdevelopedComputational controls are cheap, fast, and deterministic; inferential controls are expensive, slow, and non-deterministic but provide richer semantic judgment.
  Harness engineering for coding agent users · p5
• explicitThe progression of Claude Code's vision is: single task success, multi-tasking (6 at a time), then orchestrating 50-100+ remote agents with self-improving feedback loops.
  How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code) · p19
• explicitCross-functional collaboration must be tighter and more continuous for AI products than for traditional software — the feedback loop must be shared across engineering, SMEs, and testing.
  Generative AI in the Real World: Aishwarya Naresh Reganti on Making AI Work in Production · p18
• explicit⚡ disputed & corroboratedSpec-driven development with AI collapses the feedback loop from months to minutes.
  Sam Hatoum's Post · p3
• explicitTDD, BDD, and acceptance criteria are spec-first practices that are accepted as agile because their feedback loops are tight.
  Sam Hatoum's Post · p4
• explicitSystem prompts / agent markdown are a governance lever that requires organizational feedback loops, not just initial configuration
  Presentation: Leadership in AI-Assisted Engineering · p13
• explicitThe activities of learning, community involvement, speaking, and organizing multiply rather than merely accumulate — they create positive feedback loops
  Developing Your Leadership Skills toward Principal Engineering · p3
• explicitcorroboratedEffective fleet management requires layered feedback loops operating at different timescales: months (supply shaping), minutes (autoscaling), and seconds (load shedding).
  Presentation: How Netflix Shapes our Fleet for Efficiency and Reliability · p9
• explicitInternal platforms with clear roadmaps, active feedback loops, and sustained investment in quality become less expensive over time, not more.
  Platform as a Product: Delivering Value While Balancing Competing Priorities · p6
• explicitLLMs do not use feedback loops effectively by default; they produce too much code before checking.
  It Ain't Broke: Why Software Fundamentals Matter More Than Ever · p8

2026-05

• explicitA good measurement target for AI's systemic impact has skin in the game and real feedback loops — a team owning its own features in production is a much better target than a single contributor's delivery of a temporary artifact.
  Reinventing team flow within AI uncertainty · p7
• explicitRewriting a lint rule's message as explicit self-correction guidance for the agent (telling it when suppression is acceptable, and how to record the reason) measurably changes the agent's behavior.
  Maintainability sensors for coding agents · p3
• explicitThe one rule category where the agent's default behavior went unchallenged (repeatedly raising the cyclomatic-complexity threshold instead of refactoring) was also the one rule for which the author had not written explicit self-correction guidance.
  Maintainability sensors for coding agents · p4
• explicitPredictive analytics systems create self-reinforcing feedback loops that can trap individuals in downward spirals (e.g., bad credit score leading to joblessness leading to worse credit score)
  Designing Data-Intensive Applications: The Cloud & Doing the Right Thing · p6
• explicitdevelopedAI tools generate code that works, not code that is inherently secure; functional correctness has natural feedback loops, security does not.
  The Founder's Playbook: Building An AI-Native Startup · p9
• explicitdevelopedCustom error messages that explain the underlying concept (layering, etc.) work as self-correction guidance for AI agents and meaningfully change agent behaviour.
  Three more static code analysis sensors · p2
• explicitAI does not create metacognition on its own, but functions as a real-time cognitive mirror: the cycle of asking, receiving an answer, refining the question, and challenging the output lets a person notice patterns in their own thinking, which a saved, reflected-on feedback loop can then deliberately develop.
  Doug Shannon's Post · p2
• explicitConsistency reduces coordination costs, enables cross-boundary flow, makes the system legible above the team level, supports faster feedback loops, and lowers cognitive load.
  TBM 421: Minimally Viable Consistency (Part 3) · p1

2026-06

• explicitA raw AI model is not an agent; it only becomes one when wrapped in a harness — the scaffolding that provides state, tool execution, feedback loops, and enforceable constraints — so securing vibe coding means securing the harness, not the model's code syntax.
  Vibe Coding Agent Security And Evaluation · p1
• explicitThe large language model used by an AI coding assistant accounts for only about 10% of system quality; the other 90% is the harness — instructions, tools, context, guardrails, orchestration, and observability.
  Google Just Dropped a Masterclass on Agentic Engineering (It's SO Good) · p1
• 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
• explicitCalibration (predicted vs observed exploitation) is the missing instrument; without the feedback loop, prioritization decays into permanent uncalibrated guessing.
  Predict, Don't Enumerate · p16

2026-07

• explicitcorroboratedRalph is an autonomous agentic loop: the same prompt is run repeatedly, and each iteration reads a plan file and a progress file, chooses its own next task, explores the codebase, implements, runs feedback loops, and commits — so the agent, not the human, selects what to work on next while the human defines only the desired end state.
  11 Tips For AI Coding With Ralph Wiggum · p1
• explicitThe loop's output quality is bounded by the feedback loops wrapped around it — types, tests, linting, browser automation, pre-commit hooks — and the strongest setup blocks commits unless everything passes, so the agent cannot declare victory on red; these are not AI-specific tricks but ordinary good engineering that autonomous loops make non-negotiable.
  11 Tips For AI Coding With Ralph Wiggum · p6
• explicitAn agent treats the existing codebase as evidence that outweighs a few lines of instruction, so it imitates whatever patterns it sees ('agents amplify what they see; poor code leads to poorer code'); an autonomous loop therefore ACCELERATES software entropy — piling dozens of commits per hour where a human commits once or twice a day — unless the codebase is kept clean, quality expectations are made explicit, and feedback loops enforce standards.
  11 Tips For AI Coding With Ralph Wiggum · p9
• implicitdevelopedThe method presupposes that a well-constructed feedback loop plus explicit scope can substitute for human judgment on a bounded task, so the human's work is relocated from writing code to (a) up-front scoping/requirements and (b) after-the-fact verification of committed output — not to continuous supervision.
  11 Tips For AI Coding With Ralph Wiggum · p14
• explicitShort, fast feedback loops are the cardinal sign of engineering discipline, and fewer than 10% of software teams currently work this way.
  AI Demands More Engineering Discipline, Not Less · p5
• explicitAI mandates issued without accompanying engineering discipline (fast feedback loops, observability) will not, by themselves, produce discontinuous returns on investment.
  AI Demands More Engineering Discipline, Not Less · p10
• explicitThe wins and the costs of AI acceleration happen to two different groups of people, so there is no natural feedback loop connecting the person who reaps a win with the person who pays its downstream cost.
  AI Enthusiasts Are in a Race Against Time, AI Skeptics Are in a Race Against Entropy · p4
• explicitReal, discontinuous AI capability gains are achievable for teams founded pre-AI, but they happen because of pre-existing engineering discipline — high discipline, fast feedback loops, and a culture of experimentation and measurement — not because AI is magic (the Fin/Intercom case: 3x output in 9 months, defect backlog halved, downtime down 35%).
  AI Enthusiasts Are in a Race Against Time, AI Skeptics Are in a Race Against Entropy · p7
• explicitThe second fix is to treat AI-adoption disputes as engineering problems, not epistemological debates: replace 'what's wrong with you' and 'that will never work' with 'what would it take for you to feel comfortable shipping code to production without reading it?' and put the answer — better evals, tests, feature flags, guardrails, observability, decoupling, blast-radius reduction — on the roadmap.
  AI Enthusiasts Are in a Race Against Time, AI Skeptics Are in a Race Against Entropy · p9
• explicitAgile and XP practices survive the agent era selectively: ceremony and status theater fade, while short feedback loops, test-first thinking, CI, refactoring, and small releases survive because they cheaply expose that a spec was wrong.
  Why AI Coding Agents Still Need Clear Specs · p7
• implicitProviding self-correction sensors that the agent actually uses (e.g. a browser it can inspect after editing) could materially raise small-model viability; some one-shot failures are missing feedback loops rather than raw incapability.
  Experiences with local models for coding · p19
• implicitBecause the system's accuracy and trustworthiness depend on continuous developer feedback to recalibrate relevance and suppress false positives, its quality is not a fixed property of the retrieval architecture but an ongoing operational commitment that could silently degrade if that feedback loop is deprioritized.
  Dropbox Integrates MCP and Dash to Close the Gap Between Security Design and Code Review · p10
• explicitInternal-only feedback loops (velocity, completion, quality) optimize for completion rather than long-term value because they carry no validation from actual users.
  Shifting Platform Development from Projects to Products · p4
• explicitFeedback loops must be continuous and specific rather than an annual company-wide survey, because individual sentiment about tools fluctuates day to day and a single yes/no snapshot produces near-worthless data.
  Presentation: Platform Engineering for Everyone - Success Can’t Be Coded · p14
• explicitPractice Evolution is the connective tissue between knowing and doing -- experimentation, feedback loops, workflow adaptation -- and requires accepting that no AI 'best practices' exist yet because conditions change weekly.
  TBM 431: The Denominator That Matters · p5
• explicitestablishedAgent observability must be architected around the turn as the unit of observation, not the request, because a single user intent fans out into many model and tool calls whose relationships -- not any one call's timing -- carry the signal that matters.
  The Meter Was Always Running · p3
• explicitA tool call is a first-class governance decision -- which tool, what parameters, what result size, whether policy constrained it -- not an implementation detail invisible to observability.
  The Meter Was Always Running · p5
• explicitdevelopedA useful observability substrate needs a minimum concrete signal set -- run/turn structure, token and model accounting, tool-call events, guardrail decision events, identity and authority context, and outcome/bound metadata -- landed in a fleet-queryable store, not only a per-run trace viewer.
  The Meter Was Always Running · p7
• explicitThe same observability substrate answers three governance problems organizations usually treat as separate -- cost, delegation, and runaway actions -- because all three require the same kind of turn-level evidence of the same loop.
  The Meter Was Always Running · p10
• explicitEnforcement and observation are two faces of the same layer: policy can only be enforced on evidence that was independently observed, so putting both anywhere the agent can edit yields neither real enforcement nor real observability.
  The Meter Was Always Running · p12

2026-08

• explicitGrafana's gcx CLI and MCP server, now generally available, let AI coding agents query live observability data (metrics, logs, traces, SLOs, Synthetic Monitoring) from Grafana Cloud or a self-hosted stack during development.
  Grafana's gcx and MCP Server Reach GA for Telemetry-Driven Agent Development · p1

2026-09

• explicitRust's compiler-enforced ownership/borrow-checking converts a recurring class of memory bugs (use-after-free, double-free, forgot-to-free on error paths) into compile errors, which the author considers a better feedback loop than a style guide.
  Bun Rewrites 535K Lines of Zig into Rust in Four Months, Eliminates Numerous Memory Leaks · p2
• explicitAgent-scale delivery systems need atomic changes and self-improving feedback loops driven by production data, rather than manual human overrides, to stay reliable at the speed agents operate.
  Cloudflare Introduces the Agent Development Lifecycle to Replace Traditional SDLC · p3
• explicitWhen an implement/QA feedback loop keeps failing, the root cause is almost always missing plumbing (e.g., no single reproducible command to start the whole stack) rather than a limitation of the agents themselves.
  Inside a Software Factory · p9
• explicitAgentic tooling collapses the feedback loop between writing an under-specified spec/story and discovering it was wrong — from roughly two to four weeks (or, historically, six months) down to about 40 minutes.
  Presentation: From Retrieval to Reasoning: Building Production-Ready Agentic AI Systems with Knowledge Graphs · p4
• explicitTreating an agent as "fire and forget" — handing it a spec and waiting for finished output without a continuous human-agent feedback loop — fails to produce what was actually wanted.
  Presentation: From Retrieval to Reasoning: Building Production-Ready Agentic AI Systems with Knowledge Graphs · p9

2026-10

• explicitScrum's defining, durable property was never its default cadence (the 2-week sprint) but its empiricist feedback loop (inspect and adapt), and that loop remains valid — indeed becomes more valuable — as build speed increases.
  Erik van der Pluijm's Post · p5

Tensions

Open gaps (125)

• incompleteNo decision procedure. Twenty patterns, zero guidance on when to pick which. Each pattern carries only a 'Used for: [domains]' tag (naming application areas, not selection criteria, forces, or trade-offs). This is a pattern CATALOG, not a pattern LANGUAGE -- it has none of the GoF/Alexander connective tissue (Intent, Applicability, Consequences, forces that resolve into a choice). For a reader whose bar is 'a taxonomy without when-to-use-which is half a pattern language', this is the central omission.
  20 Loop Design Patterns Every AI Engineer Should Know — read next: Read against a real pattern-structure: Anthropic's harness paper (extract-anthropic-harness-design-long-running-application-development#p8) ties evaluator use to a concrete condition -- worth its cost only when the task sits beyond what the model does reliably solo -- exactly the selection criterion this thread lacks. Also extract-ai-workflow-patterns-real-unit-of-adoption-2026 (guidance on which workflows to automate first / how patterns chain).
• incompleteNo failure modes or costs per loop. Only pattern 17 (Tree Search) names any cost ('computationally expensive'). Every loop here adds latency and token cost and can degrade: over-critique/thrash, reward-hacking the evaluator, infinite retry against an unsatisfiable threshold, and -- for the memory patterns -- drift and poisoning. The thread frames accumulated memory as pure monotonic gain.
  20 Loop Design Patterns Every AI Engineer Should Know — read next: extract-anthropic-harness-design-long-running-application-development#p8 (the evaluator becomes unnecessary overhead when the task is within the model's solo capability) and extract-turing-post-5-patterns-long-running-agents#p9 and #p20 (memory drift as a real production failure mode; persistent state makes behavioral drift a property of the system, not a bug) -- the exact risk the thread's Memory Loops ignore.
• incompleteThe patterns are not orthogonal, and the thread never acknowledges the overlaps -- it even undercuts its own '20 distinct patterns' premise by collapsing all of them into one meta-pattern (Act -> Observe -> Evaluate -> Adjust) at the end. Branch-and-Explore (16) is explicitly a depth-1 Tree Search (17); Error Library (8) and Success Pattern (9) are the same store with opposite valence; Adversarial Critique (4) and Debate (18) are the same adversarial pressure; Progress Evaluation (14) is the observe step of Plan-Execute-Replan (11); Constraint Satisfaction (15) generalizes Score-and-Retry (2).
  20 Loop Design Patterns Every AI Engineer Should Know — read next: Dedupe to the ~8 underlying mechanisms (evaluate-and-revise, experience-memory, memory-compression, adaptive-planning, runtime-routing, decomposition, search-over-alternatives, meta-optimization); read the '20' as valence/depth/count/stance/level variants inflated to a shareable round number.
• incompleteComposition and nesting are asserted but never specified. Pattern 20 ('the loop improves the loop') and the five categories imply loops nest and chain, but there is no grammar for how -- which loop wraps which, where they conflict, or the orchestration cost of stacking them. For a systems thinker, the composition rules are exactly the missing part.
  20 Loop Design Patterns Every AI Engineer Should Know — read next: extract-anthropics-three-agent-harness#p8 (the handoff artifact between composed agents is the critical design variable) and extract-anthropic-harness-design-long-running-application-development#p10 (file-based inter-agent communication as sufficient orchestration) show what specifying composition actually looks like.
• incompleteSelection bias baked into the format. '20' is a round, shareable number, and the padding that reaches it (valence flips, depth variants, stance variants) is driven by thread virality -- reinforced by the 'worth six figures / Save this / Repost / Follow @sairahul1 / Bookmark this' framing -- not by the actual cardinality of distinct mechanisms.
  20 Loop Design Patterns Every AI Engineer Should Know — read next: Discount the count; treat the list as a prompt to name the ~5 patterns with real research lineage (Reflexion, Tree/MCTS search, multi-agent debate, automatic prompt optimization a la DSPy/APE, plan-execute-replan) and to source them properly.
• 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.
• incompleteNo cost/ROI accounting is given for building and running the simulation infrastructure itself. The talk names running cost as a design constraint (avoiding, e.g., 10,000-conversation batches every CI run) but never quantifies the engineering cost of building personas/scenarios, judge-calibration labor, or how the total cost compares to the manual-tester process it replaces — beyond the qualitative, unquantified two-year Pearson relationship.
  Presentation: From AI Agent Demo to Production: Automated Testing and Evaluation — read next: Corpus material on eval/observability infrastructure cost and token/infra economics, for a fuller before/after ROI picture of adopting simulation-driven testing.
• 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.
• incompleteThe claim that fewer than 10% of teams work in fast feedback loops is asserted with no citation or methodology ('Five percent, maybe?'), yet it is load-bearing for the article's optimistic claim that AI tooling 'brings this more within reach.'
  AI Demands More Engineering Discipline, Not Less — read next: Check DORA / State of DevOps survey data and other measured accounts of feedback-loop and CI/CD adoption rates against this impressionistic estimate.
• incompleteThe essay argues humans cannot be beaten by machines at 'validation' but does not address the transition period when the SRE-style production/observability discipline she prescribes has not yet been built — leaving open how teams should behave in the likely-long interval where neither strong human review nor strong automated validation exists.
  AI Demands More Engineering Discipline, Not Less — read next: Read maturity-model and incremental-adoption literature on sequencing testing and observability investment relative to AI code-generation adoption.
• incompleteThe core remedy — 'tell the whole story,' 'invite feedback,' 'close the loop,' 'make it easy' — is a behavioral/individual-virtue prescription, yet Majors herself names the structural incentives working against it (wins are trumpeted publicly, costs griped privately; real power dynamics make honest cost-disclosure risky). Beyond 'surface it in the same forum,' she gives no incentive or mechanism-design fix that would make disclosing your own downstream costs structurally rewarded rather than merely encouraged.
  AI Enthusiasts Are in a Race Against Time, AI Skeptics Are in a Race Against Entropy — read next: Read commons-governance and mechanism/costly-signaling work (Ostrom on shared resources; signaling under cheap talk) and psychological-safety instrumentation: how to make cost-disclosure a low-cost, high-status default rather than an act of individual courage.
• 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.
• incompleteThe article names the risk that an incomplete evaluator lets the evolutionary search produce code that is fast but subtly wrong in ways tests don't catch, but never describes what safeguards, staged rollout, or independent verification practices Google or its customers actually use to catch this failure mode before production deployment.
  Google's AlphaEvolve Reaches General Availability with Evolutionary Code Optimization as a Service — read next: Look for an AlphaEvolve engineering deep-dive (Google Cloud blog technical posts, the original AlphaEvolve paper, or a customer's own engineering writeup) describing evaluator-hardening and pre-production verification practices.
• incompleteThe decomposition is not orthogonal and specifies no module boundaries. Four of the named components — memory (3), context management (4), prompt construction (5), and state management (7) — are views of a single 'what the model sees / what persists' concern (Claude Code's git-commits-as-checkpoints sits under state, MEMORY.md under memory, compaction under context, prompt assembly under construction, but they are one persistence-and-window problem wearing four hats). Guardrails/permission (9) is not disjoint from tools (2) — the walkthrough runs the permission check INSIDE tool execution (step 4). Output parsing (6) is near-vestigial under native tool calling (a sub-step of the loop, not a peer module). And the orchestration loop (1) is a LEVEL above the contents it manages, not a coequal component ('the complexity lives in everything the loop manages'). The prose enumerates eleven items under a 'twelve components' heading. So the list reads as a practitioner checklist organized by mechanism and vendor vocabulary, not a coupling-minimizing partition into high-cohesion modules — it cannot tell you where to actually cut the system.
  The Anatomy of an Agent Harness — read next: Read Parnas ('On the Criteria To Be Used in Decomposing Systems into Modules'), Yourdon & Constantine on coupling/cohesion, and Ousterhout on deep modules; re-derive the harness as narrow-interface deep modules and test which of the eleven are genuinely separable versus one persistence/context responsibility split four ways — the structured-design question the piece's naming step presupposes but never answers.
• incompleteAnatomy without failure-mode interactions. The seven-step walkthrough gives happy-path dynamics only; the piece never addresses how components interfere when things go wrong — compaction (context management) discarding state the verifier still needed, a guardrail tripwire firing mid-tool-call and leaving state half-written, or a memory 'hint' that contradicts actual state after a context reset. The hardest engineering lives in these cross-component failure interactions, which the static list and the clean walkthrough elide.
  The Anatomy of an Agent Harness — read next: Read extract-anthropic-harness-design-long-running-application-development and extract-anthropics-three-agent-harness on context-reset handoff artifacts and evaluator calibration; look for how components must expose contracts to survive each other's failures rather than only cooperating on the happy path.
• incompleteNo interface or contract between components is specified. The piece names components but never states what each EXPOSES to the others — what memory hands to context management, what guarantees the loop makes to the tool layer, what verification consumes and returns. Without interface contracts, the 'independently improvable' premise (p13/p14) that the sibling's fitness-selection strategy depends on is unverified: 'add one mechanism' only stays local if the components are actually decoupled, which the piece asserts by layout rather than by design.
  The Anatomy of an Agent Harness — read next: Read on module interfaces/APIs (information hiding, contracts) and re-examine the sibling's automated 'add one mechanism, keep if better' loop to check whether a change to one component ripples across the coupled memory/context/state cluster.
• incompleteTwo overlapping taxonomies whose relationship is left unstated. The twelve components and the seven decisions substantially overlap: decisions 3/4/5/6 (context-window strategy, verification design, permission architecture, tool scoping) simply re-open components 4/10/9/2 as 'choices,' while only decisions 1/2/7 (single-vs-multi-agent, ReAct-vs-plan-execute, harness thickness) are architectural choices not already a component. The piece presents both frameworks without saying whether the seven decisions are just the tunable parameters of a subset of the twelve components.
  The Anatomy of an Agent Harness — read next: Consolidate into one model — components as nouns (what the harness contains) versus configuration axes as verbs (how each is set) — and test whether 'seven decisions' collapses into 'the tunable dials on four of the components,' leaving only single-vs-multi-agent, ReAct-vs-plan, and thickness as genuinely first-order architecture.
• incompleteThe article never explains why AWS's cost-anomaly alarms, despite firing, were not wired to any automatic halt-the-pipeline or page-an-engineer action. Was this an intentional design choice (e.g. to avoid auto-halting on what might be a false positive) or a plain configuration gap nobody had closed? Without that distinction, the reader cannot judge whether this was a one-off oversight or a predictable consequence of how AWS designed alarm response for this system.
  AWS Billing Bug Shows Customers Trillion-Dollar Estimates While Its Own Cost Alarms Fail to Act — read next: AWS's own postmortem practices and SRE literature on the design tradeoff between auto-remediation and human-in-the-loop response for anomaly detection; how organizations decide which alarms are allowed to trigger automatic action versus which require a human gate.
• 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 piece names a real risk ('feedback overload for the agent, sending it into a spiral of over-engineered refactorings') from activating more rule sets, but doesn't examine how many of the newly surfaced findings were actually net-helpful versus noise, nor propose any staging, severity-tiering, or gating mechanism for introducing new rules without triggering that spiral.
  Maintainability sensors for coding agents — read next: Practices for incrementally rolling out static-analysis rule sets to agents (staged activation, severity tiers, rule-adoption cadence) rather than activating full sets at once.
• incompleteNo engagement with the possibility that the practice does subtle epistemic harm: it lets the decision-maker experience the feeling of having consulted wisdom without the actual feedback loop (real advisors push back, get hurt, hold you accountable, and update their advice based on what happened last time). The closer the simulation gets to feeling real, the more it may displace practices that actually improve decisions.
  Build an AI Advisory Board with GPTs for Decision-Making — read next: Cutler on accountability and DRIs (directly responsible individuals); literature on simulated advice in clinical and organizational decisions (Logg et al. on algorithm aversion/appreciation); the AI-coding-quality conversation in the user's library (Marcus, the SQLite-vs-LLM-rewrite finding) for the more general pattern of fluent output being mistaken for capable output.
• incompleteThe adoption results report that 131 of 165 generated patches passed all tests and 55 were reported to developers, but never say how many of those 55 were actually accepted and merged to production — the single number that would most directly validate (or undercut) the claim that automation plus human gatekeeping is working well. 'Reported' and 'adopted' are conflated throughout.
  Automated Bug Fixing at Facebook Scale — read next: Later Facebook/Meta engineering retrospectives on SapFix or its successors, if any exist in the corpus or elsewhere, for merge/acceptance-rate data.
• incompleteThe piece never explains why mutation-based repair is limited to Null Pointer Exceptions specifically, beyond noting that Facebook 'plans to cover more mutation strategies' — leaving open whether NPEs were chosen because they are mechanically easiest to patch via mutation, most frequent in the crash population, or safest to automate, each of which would carry different implications for which bug classes are good candidates for automated repair generally.
  Automated Bug Fixing at Facebook Scale — read next: extract-what-survived-contact#p5 and this corpus's agentic-testing material, for how today's systems reason about which categories of defect are safe to hand to automated remediation versus which require a human-authored fix.
• incompleteEvery play redefines the human's role (from author to reviewer, from implementer to orchestrator, from on-call responder to incident-queue triager) but the piece never addresses the human cost of that shift — skill atrophy from no longer writing code directly, morale effects of reviewing AI output all day, or how an organization trains new engineers who never practiced the skills the plays assume a senior reviewer already has.
  The AI-Native SDLC playbook — read next: Look for practitioner accounts (not vendor playbooks) of how teams that have run this kind of pipeline for a year or more describe the experience of the reviewer-not-author role, and whether junior engineers develop judgment without first doing the work themselves.
• uninformedThe piece is presented as consolidating 'real best practices our Applied AI team executes on a daily basis for our customers,' but every quantitative claim (leading/lagging indicators, 'elapsed time falls from weeks to hours') is prescriptive guidance on what to measure, not a reported result; no outcome data from an actual deployment appears anywhere in the piece.
  The AI-Native SDLC playbook — read next: Look for independent case studies, post-mortems, or DORA-style empirical measurement of organizations that adopted this specific stage structure, as distinct from vendor-authored playbooks.
• missing evidenceNo data on what fraction of migrations the AI completed without human intervention vs. those requiring manual fixes
  DoorDash Used Copilot to Convert Its XCTest-Based iOS Test Suite to Swift Testing
• unjustified assumptionThe ten-consecutive-pass threshold is presented without justification — why ten and not five or twenty?
  DoorDash Used Copilot to Convert Its XCTest-Based iOS Test Suite to Swift Testing
• scope omissionNo discussion of tests that could not be migrated (e.g., UI tests, tests with XCTest-specific features)
  DoorDash Used Copilot to Convert Its XCTest-Based iOS Test Suite to Swift Testing
• missing evidenceCost of building the tooling (MCP server, migration rules, Bazel integration) is not quantified against the savings
  DoorDash Used Copilot to Convert Its XCTest-Based iOS Test Suite to Swift Testing
• inconsistencyThe article conflates Copilot and Cursor — the title says 'Copilot' but the body describes Cursor throughout
  DoorDash Used Copilot to Convert Its XCTest-Based iOS Test Suite to Swift Testing
• scope omissionNo mention of how the migration handles XCTest-specific patterns like setUp/tearDown lifecycle or XCTestCase subclassing
  DoorDash Used Copilot to Convert Its XCTest-Based iOS Test Suite to Swift Testing
• 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 analogy presumes that writing-craft principles transfer cleanly to prompting because both are 'communication.' But writing is human-to-human communication with shared context and reading conventions; prompting is human-to-model communication with very different priors, failure modes, and feedback loops. The essay does not stress-test where the analogy breaks.
  The Best Prompting Advice Came From a Writing Teacher — read next: Cognitive science of human-AI communication; research on shared common ground in conversation (Herbert Clark); the literature on prompting as distinct from natural-language instruction
• incompleteThe manual-vs-automated eval divergence is described but not diagnosed. It is unclear whether manual iterative 'success' merely reflects the human closing the loop through follow-up messages while the automated one-shot exposes the model's real ceiling — i.e. whether the two modes measure different things.
  Experiences with local models for coding — read next: Literature comparing one-shot vs. multi-turn agent benchmarks; studies on human-in-the-loop correction inflating apparent capability; self-correction/sensor studies (her own 'sensors for coding agents' work).
• incompleteThe harness's contribution is under-explored and internally in tension: she found swapping OpenCode vs. Pi made little difference, yet Jigar Jani's near-all-local coding depends on continuously enhancing his harness with skills. How much of viability is raw model vs. harness engineering (skills, code-search/understanding tools, self-correction sensors) is left open.
  Experiences with local models for coding — read next: SmallCode-style harness-engineering studies for small models; her own harness-engineering framework; controlled comparisons isolating harness features (progressive disclosure, tool routing, skills) at fixed model.
• incompleteNo treatment of the social-and-organisational fate of the artefacts themselves. Dependency-cruiser configs, custom coupling-analyser CLIs, and imported Modularity Skill packs are all new load-bearing artefacts. Who owns them? Who updates them when the architecture should change? In the absence of an owner, the rules outlive the intent behind them and become either silently violated or silently obsolete — the classic linter-suppression-debt pathology, scaled to architecture.
  Three more static code analysis sensors — read next: Cutler on institutionalised overload and waste; Fearless Change (Manns & Rising) on what it takes for organisational invariants to survive; Tornhill's Software Design X-Rays on attaching social/ownership data to code-quality signals; Vlad Khononov's modularity work directly (since his Skills are now part of the harness).
• incompleteThe article treats the dependency-cruiser rule set as a substitute for a markdown structure guide, but it skips the question of whether enforcement and explanation are interchangeable. A rule that says 'clients cannot import services' enforces a constraint but does not teach why the layering exists — and the moment the constraint is wrong, the team has no shared prose to reason with. This silently relocates design intent into tooling that few people maintain, and few people can read.
  Three more static code analysis sensors — read next: Ousterhout 'A Philosophy of Software Design' on the role of design documents; Parnas on module specifications; Hickey 'Simple Made Easy' for the distinction between rules-as-policy and rules-as-understanding.
• incompleteHeavy reliance on Khononov's externally maintained Modularity Skills pack as the thing that makes Sensor 3 work. The article does not examine: skill-pack versioning, drift, security/supply-chain assumptions, or what happens when the skill author changes their mind. The harness now has a third-party dependency at the level of taste, not just at the level of code.
  Three more static code analysis sensors — read next: Khononov's Learning Domain-Driven Design and his coupling talks; literature on prompt drift; the emerging 'skills-as-dependency' discussion (Osmani's agent-skills writing).
• incompleteThe coupling-analyser is described as a vibe-coded custom CLI. The article acknowledges it would benefit from suppression of legitimate high-coupling hubs but does not engage with the more interesting question: if your coupling tool requires hand-curated exceptions for every architectural pattern, you are effectively encoding architectural intent in two places (the rules AND the exception list). At that point, why not skip the metric layer and go directly to the inferential review?
  Three more static code analysis sensors — read next: Tornhill, Software Design X-Rays; the dependency-cruiser community's own discussion of when DSM-style tools earn their keep.
• incompleteThe article observes that the AI modularity review found duplicate routes, scattered parameters, and misplaced auth — i.e. exactly the things a senior reviewer would find in a half-hour read of the code. There is no contrastive baseline against human-only review, against pair-review with the original implementing agent, or against a much cheaper rubric like 'review every file changed >X times in the last 30 days'. Without such a baseline, the proposition 'the review is the best available sensor' is unfalsifiable on the evidence given.
  Three more static code analysis sensors — read next: DORA reports' methodology on baselines; Beck on test-commit-revert and 'starving genies' as alternative scaffolds for keeping AI-edited code honest.
• incompleteNo engagement with the relationship between this approach and existing fitness-function / architecture-as-code tooling (ArchUnit, NetArchTest, ts-arch, Modulith, even Structure101). dependency-cruiser is one point in a much larger design space; treating it as 'the' dependency-rules sensor leaves the reader without a sense of where the boundary lies between custom configuration and adopting an established framework.
  Three more static code analysis sensors — read next: Ford/Parsons/Kua 'Building Evolutionary Architectures' on fitness functions (which she links to in the framing); ArchUnit; ts-arch.
• incompleteThe framing assumes the agent is always the implementing actor and the human (plus other agents) are the reviewers. It does not consider the inverse case — where humans implement and the AI modularity review is the rubric against which their code is judged — even though the same tooling would work. This matters because it shapes whether the harness is 'AI guardrails' or 'organisational architecture discipline that happens to use AI'.
  Three more static code analysis sensors — read next: Cutler on operating-system design; Beck on team practices.
• unstated assumptionFowler's curation implicitly assumes that the discipline-vs-tarpit tension is the defining axis of AI-assisted development, but economic and organizational dimensions (team structure, hiring, skill deskilling) are largely absent from the fragments selected.
  Fragments: May 5 — read next: Cross-reference with pieces on how AI changes team composition and organizational design (e.g., the 'kill your org chart' literature).
• implicit premiseThe local-model argument rests on a single practitioner's 'good enough' assessment (van den Ende). There is no quantitative comparison of local vs. cloud model performance on real engineering tasks, leaving the threshold claim unsubstantiated.
  Fragments: May 5 — read next: Look for benchmarks comparing local open-weight models (e.g., Llama 3, Mistral) against cloud models on SWE-bench or similar agentic coding evaluations.
• selection biasThe fragments are curated from Fowler's professional network (ThoughtWorks colleagues, Beck, Jessitron, RedMonk) — a community that values craft and internal quality. The 'move fast and let AI clean up later' perspective is represented only as a foil, not through its strongest advocates.
  Fragments: May 5 — read next: Seek out arguments from the 'galaxy brain' camp — practitioners or companies that have successfully scaled with AI-generated code despite low internal quality.
• uninformedThe cited 75.33% law-professor preference finding for LLM answers over peer instructors is reported without the students'-side outcome (whether students who received LLM answers actually learned better or worse), the specific sample of contract-law questions used, or which models were tested — details that materially affect how far the finding generalizes beyond 'LLMs write plausible short answers professors like reading.'
  Fragments: July 21 — read next: Read the original Stanford Law study directly for full methodology and any student-learning-outcome measures, and check for replication in other legal or technical education domains.
• incompleteThe article treats AI as equivalent to a junior developer, but AI has fundamentally different failure modes — it can be confidently wrong in ways juniors rarely are, and it lacks the ability to say 'I don't understand the requirement.' The junior-developer analogy may lead to under-investment in verification.
  Patterns for Reducing Friction in AI-Assisted Development — read next: Research on AI confabulation/hallucination in code generation; studies comparing AI and human error patterns in software development
• incompleteThe framework assumes the developer can articulate their conventions and constraints explicitly enough for AI to follow. This is Polanyi's paradox — we know more than we can tell. The Sensible Defaults pattern may hit a ceiling where the most important quality signals are precisely the ones hardest to codify.
  Patterns for Reducing Friction in AI-Assisted Development — read next: Polanyi's 'The Tacit Dimension'; research on knowledge management and the limits of codifying expert judgment
• incompleteNo discussion of how these patterns interact with rapidly improving AI capabilities. If AI models become better at inferring project conventions from code context, some of these patterns (especially Knowledge Priming) may become unnecessary. The framework lacks a theory of its own obsolescence.
  Patterns for Reducing Friction in AI-Assisted Development — read next: Papers on in-context learning improvements in LLMs; research on retrieval-augmented code generation
• incompleteThe article focuses entirely on individual developer-AI interaction. There is no treatment of how AI collaboration patterns interact with team dynamics — e.g., whether standardized prompts reduce healthy variation in approach, or whether shared priming docs create new coordination costs.
  Patterns for Reducing Friction in AI-Assisted Development — read next: Research on coordination costs in software teams; Brooks's 'The Mythical Man-Month' on communication overhead
• uninformedNo engagement with the existing literature on human-AI teaming from other domains (aviation, medicine) where collaboration frameworks have been developed and empirically tested for decades.
  Patterns for Reducing Friction in AI-Assisted Development — read next: Research on crew resource management (CRM) in aviation; human-AI teaming frameworks from DARPA and military contexts
• incompleteThe entire pattern presupposes an organization already has OpenTelemetry instrumentation, defined SLOs, and a Grafana-compatible observability stack to query — this is unglamorous infrastructure work that many teams have not done. The article treats 'point the agent at your telemetry' as a drop-in capability rather than naming the maturity precondition, so teams without that substrate get no guidance on how to get from zero to telemetry-grounded agent development.
  Grafana's gcx and MCP Server Reach GA for Telemetry-Driven Agent Development — read next: Observability-maturity and adoption-sequencing literature; the corpus's own material on trace validation as future/hard infrastructure work.
• incompleteThe 'amnesiac AI' framing assumes no progress on persistent AI memory (RAG, project context, long-term memory). If AI memory improves, the strongest argument for specs (external memory) weakens — though the argument from verifiability would remain.
  Sam Hatoum's Post
• illogicalThe thought experiment ('if coding became instant') proves too much — it assumes zero implementation cost, but actual AI implementation is not zero-cost. The gap between 'minutes' and 'instant' may matter more than the post acknowledges.
  Sam Hatoum's Post
• incompleteTreats overload as a permanent atmospheric condition rather than a designed outcome. The article tells overwhelmed managers how to coach overwhelmed reports about growth, but never asks why aggregate work has expanded or whether it should be cut. The one-sentence 'lighten their load' is the closest it comes — it is not developed and not staffed with examples.
  Supporting Your Employees' Career Growth When Everyone Is Overwhelmed — read next: John Cutler's 'institutionalized overload' (TBM 412 and related) treats overload as a systems problem with feedback loops and organizational levers — read this against Knight's piece to see what's missing when the manager is the only actor in the frame.
• incompleteThe article never canvasses structural alternatives to adding a C-suite role: explicit resilience portfolio for COO; resilience standing committee with rotating chair; embedding resilience accountability in existing role mandates; redesigning the boundaries between CISO/CRO/COO so the gap disappears. The choice between 'new role' vs. 'redesigned roles' is never made an argument — it is assumed.
  The Case for Hiring a Chief Resilience Officer — read next: Donella Meadows on leverage points (a new actor is a relatively low-leverage intervention compared to changing rules, feedback loops, or paradigms); Cutler on accountability culture and DRIs (whether accountability needs a title or a clearer commitment); Yourdon & Constantine on coupling and cohesion applied to org structures — when do you add a module vs. refactor existing modules?
• uninformedCitations are underspecified throughout: the Journal of Organizational Behavior study on manager involvement gives no sample size, effect size, or definition of 'manage from a distance'; the Frontiers in Psychology moonlighting study names a sample size (324) but no effect size or engagement instrument; every leader-behavior percentage (33%, 43%, 53%, 56%, 59%, 90%+) is reported without a confidence interval, base rate, or description of how 'average team' leaders were sampled.
  How to Build a Superteam That Keeps Getting Better — read next: The original Journal of Organizational Behavior and Frontiers in Psychology papers directly; Ron Friedman's book 'Superteams' (Simon & Schuster, 2026), from which this article is adapted, for full survey methodology.
• illogicalSurvivorship bias in case selection: every illustrative organization (Thunder, Meta, Netflix, Amazon, Spotify, LinkedIn, Microsoft, Airbnb, Adobe, Estée Lauder, HubSpot, Keap, Basecamp, Haberman) is a documented success story for the practice it illustrates. No case of a team that experimented boldly and failed, admitted uncertainty and lost credibility, or had a hands-on leader who tipped into micromanagement is discussed, so each practice's downside risk and failure rate are invisible by construction.
  How to Build a Superteam That Keeps Getting Better — read next: Base-rate and survivorship-bias literature (e.g., Mlodinow, Taleb) applied to management case studies; accounts of experimentation cultures or hands-on leadership that did not pay off.
• incompleteThe claim that AI raises the incentive to live good engineering culture is asserted but not mechanised. Continuous delivery has been well-described for 20 years and only patchily adopted. Why will AI succeed in changing this where the prior decade's tooling, DORA reports, and platform engineering did not? A causal story is missing.
  14) Øystein Ulseth pendler mellom å lede og levere — read next: DORA 2025/2026 specifically on AI's interaction with delivery practices; Birgitta Böckeler and Martin Fowler on AI-coding feedback loops; Kent Beck's TCR work as the practice end of the same idea.
• incompleteThe conversation reaches the 'cover your ass' diagnosis of Norwegian public-sector risk-aversion but does not investigate the structural causes — why has the last ~10 years been 'feigere'? Datatilsynet stance is named, the Nikolai Tangen episode is named, but the institutional feedback loop producing the pattern is not unpacked.
  16) Inga Strümke om hvor AI er på vei, den outsourcede problemløsningen og datamanifolden — read next: John Cutler on institutional overload and accountability culture (already in the user's reading); recent NSM/Nkom assessments on resilience; Norwegian public-administration literature (NIBR / NIFU) on risk-distribution between politikere and direktorater; Annie Duke / Daniel Kahneman on outcome-bias driving risk-aversion.
• incompleteNo outcome evidence. The piece asserts the product approach is better but supplies zero before/after data — no reduced backlog, no adoption numbers, no user-satisfaction or lead-time improvement. It persuades by resonance with the reader's own pain, not by measured result.
  Shifting Platform Development from Projects to Products — read next: Mik Kersten, 'Project to Product' (value-stream flow metrics); DORA / SPACE for platform outcome measurement; Evan Bottcher, 'What I Talk About When I Talk About Platforms' (Thoughtworks) for how to evidence platform value.
• incompleteThe funding and governance shift is invisible. Moving from project budgets (predictable, milestone-scoped, one-time) to ongoing product funding — and granting the platform team authority to prioritize by aggregate value and to say no — is the real organizational cost of product thinking, and the article never names it.
  Shifting Platform Development from Projects to Products — read next: Mik Kersten, 'Project to Product' (funding argument); Sriram Narayan, 'Products Over Projects' (martinfowler.com); John Cutler on product operating models and how funding shapes behavior.
• incompleteThe piece fuses the mindset shift with one specific cloud-provider architecture (self-service, CRDs, service/control/management planes). It leaves unresolved whether that architecture is a precondition of product thinking, a consequence of it, or merely this team's instance — a lighter platform could adopt product thinking without it.
  Shifting Platform Development from Projects to Products — read next: Skelton & Pais, 'Team Topologies' (platform-as-product and the 'thinnest viable platform'); John Cutler on separating operating model from tooling.
• incompleteThe 'internal customer' analogy is imported without its main caveat: internal customers usually cannot exit or choose an alternative, so adoption can be produced by mandate rather than genuine demand — making adoption a gameable success metric. The captive-customer problem is never addressed.
  Shifting Platform Development from Projects to Products — read next: Marty Cagan, 'Empowered' / 'Inspired' (do product principles hold for captive internal users?); John Cutler on internal platforms and 'build vs. mandate' dynamics.
• incompleteNo deprecation or sunsetting mechanism. The founding complaint is 'accumulated capabilities competing in priority', yet the product model as described adds new abstractions without any account of retiring unused ones — the accumulation problem is diagnosed but structurally left unsolved.
  Shifting Platform Development from Projects to Products — read next: Kent Beck on removing/simplifying (Tidy First? — subtraction as design work); lifecycle/deprecation practices in platform engineering (e.g., Team Topologies on platform evolution).
• incompleteReed's prescription assumes organizations will reinvest AI-driven efficiency gains in human thoroughness, but the same talk reports that the current pattern is the opposite: 'AI's main impact on my life is more incidents because we're generating more code.' The systems-thinking question of how to design feedback loops that prevent capture of efficiency-as-throughput is left untouched. Without that loop, the 'AI does efficiency, humans do more thoroughness' division is a moral exhortation, not a mechanism.
  Presentation: The Ironies of A^2 I^2 (Ironies of Automation and Artificial Intelligence in Incidents) — read next: Donella Meadows on leverage points (especially feedback loops, rules of the system, and goals of the system). John Cutler on institutional overload and on how organizations metabolize efficiency gains. Possibly Christensen on capabilities-as-process — i.e., the org's existing process consumes new capability.
• uninformedAll supporting evidence is qualitative and anecdotal (two expert interviews, the Bezos/Amazon anecdote, one Burberry case) with no data on the relative frequency or cost of the two failure modes — plans that were too timid vs. plans that were too ambitious — so a reader cannot tell which error is more common or more costly in practice.
  Is Your Strategic Plan Too Ambitious? Or Not Ambitious Enough? — read next: Empirical strategy-execution research on goal-setting outcomes (e.g., academic stretch-goal research, or large-sample studies of strategic-plan success/failure rates).
• illogicalThe piece treats 'start small while aiming high' (the Bezos narrative) and '10x goals can't be achieved incrementally' (Sull's funding argument) as compatible, but doesn't reconcile that starting with books was itself an incremental first step — the article never clearly distinguishes incremental execution in service of a big vision from incremental ambition-setting, even though only the latter is framed as the failure mode to avoid.
  Is Your Strategic Plan Too Ambitious? Or Not Ambitious Enough? — read next: Real-options theory or staged-investment strategy models that formalize the distinction between a small, reversible first step and a capped level of ambition.
• incompleteNo mention of psychological safety or incentive/reward-system design, even though several failure modes (#4 credit-seeking, #9 cherry-picking around promo time, #11 fabricating causal stories) are natural responses to a reward system that punishes honest reporting of ambiguity, setbacks, or unattributable work. The post diagnoses the symptom (behavior) without naming the likely structural cause (what gets rewarded).
  John Cutler's Post
• incompleteThe deck compresses three detailed organizational case studies (build-trap escape, code migration, OKR alignment) into a handful of two-to-four-word bullets per box ('Portfolio approach', 'Layer HIL validation', 'Domain slicing', 'Back briefing'), with no operational detail on how these practices were actually implemented step by step, who owned the change, or how long it took to land.
  John Cutler's Post — read next: Cutler's longer TBM newsletter essays (already in this corpus, e.g. extract-tbm-430-incubate-compound-refinance-liquidate, extract-tbm-432-bundling-unbundling-capabilities) or a recording/write-up of the underlying live Dotwork client presentation would likely supply the missing mechanism.
• incompleteAll three case stories are presented as success narratives — the pivot worked in every case. The deck gives no counter-example of a team that adopted the same problem-first, hypothesis-driven, trust-first practice and still failed, nor any base rate for how often the 'before' pattern actually resolves the way these stories describe. Survivorship bias in the anecdotes is unaddressed.
  John Cutler's Post — read next: Practitioner retrospectives or failure-mode write-ups of AI-adoption playbooks would help test whether the practice generalizes beyond hand-picked success cases.
• incompleteThis LinkedIn post is a by-product of a live client talk ('Presenting to some of the biggest companies... I have a bad habit of creating new presentations and never doing the same one twice. So might as well share!'). The verbal narration, audience Q&A, and worked-exercise detail that would have accompanied these slides in the room are not captured here — only the static slide text and imagery survive as a 34-image carousel, so the connective reasoning between slides is partly inferred rather than stated.
  John Cutler's Post — read next: A recording or write-up of one of the actual Dotwork client sessions, if it surfaces, would fill in the missing connective tissue.
• 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.
• incompleteThe feedback loop claim is asserted via metaphor ('systems thinking terminology') but not demonstrated. There is no evidence that these activities actually compound rather than merely accumulate. The mechanism by which speaking leads to organizing leads to centrality is never specified — it could equally be a survivorship bias narrative.
  Developing Your Leadership Skills toward Principal Engineering — read next: Research on career capital theory (Cal Newport's 'So Good They Can't Ignore You') for a more rigorous framework on how skills compound
• incompleteThe claimed outcome metrics (days-to-minutes, 'useful almost all the time,' zero regressions) are self-reported by Meta with no sample size, no independent audit, no defined baseline for what 'days' meant before, and no disclosure of failure modes.
  Meta's Recipe for Building Agents as "Organizational Second Brains" — read next: Read the original Meta engineering blog post for methodology detail, and look for independent replication or a comparable published case study outside Meta.
• uninformedNo technical detail is given on the model(s) used, the cost or latency of the recipe-based reasoning pipeline, or how the 200+ files are authored, reviewed, and kept current at scale — the encoding-format-and-lifecycle question already raised about an earlier Meta agent article remains only partially answered here.
  Meta's Recipe for Building Agents as "Organizational Second Brains" — read next: Compare against extract-meta-unified-ai-agents-performance-optimization and the original Meta engineering blog post for architecture and lifecycle detail.
• incompleteThe talk assumes Netflix-scale engineering investment (dedicated capacity modeling teams, custom hardware benchmarking, fleet-wide shaping systems, multi-region traffic steering) without addressing what a smaller organization should prioritize. The techniques are presented as a coherent system, but there is no guidance on which components yield the most value independently.
  Presentation: How Netflix Shapes our Fleet for Efficiency and Reliability — read next: Look for writing on 'minimum viable platform engineering' or staged infrastructure maturity models — e.g., Charity Majors on observability, or Will Larson's infrastructure strategy writing
• incompleteThe cost-of-failure model uses a beta distribution and Poisson process but provides no guidance on how to calibrate these models in practice — where does the failure frequency data come from? How do you estimate tail impact without having experienced tail events?
  Presentation: How Netflix Shapes our Fleet for Efficiency and Reliability — read next: Look into SRE literature on error budgets (Google SRE Book), or actuarial/financial risk modeling approaches adapted for reliability engineering
• incompleteThe talk focuses exclusively on compute (CPU, memory, network) and does not address data-layer efficiency — storage costs, data transfer costs, or database licensing — which for many organizations dominate cloud spend.
  Presentation: How Netflix Shapes our Fleet for Efficiency and Reliability — read next: Seek talks or papers on data infrastructure cost optimization at scale — e.g., Netflix's data platform team publications, or Uber's cost optimization writing
• incompleteThe organizational dynamics are unaddressed: how does a centralized infrastructure team get authority to override individual team hardware preferences? The talk mentions 'infrastructure needs to do the heavy lifting' but not how to achieve that organizational mandate.
  Presentation: How Netflix Shapes our Fleet for Efficiency and Reliability — read next: Platform engineering organizational models — Team Topologies (Skelton & Pais), or talks on Netflix's infrastructure organization
• incompleteMulti-cloud or hybrid strategies are not discussed — the entire framework assumes AWS as the sole provider. The fungibility argument could extend to cross-provider flexibility but this is unexplored.
  Presentation: How Netflix Shapes our Fleet for Efficiency and Reliability — read next: Look for writing on multi-cloud capacity strategy, or provider-abstraction layers at scale
• incompleteThe mechanism — a balancing feedback loop of privacy restoration under observation — is hypothesized but not instrumented. No measure of headphone use, avoidance, or perceived observability was collected, so the mediating variable is inferred from volume shifts. Competing explanations (noise avoidance, changed physical adjacency of one's actual collaborators, task changes, or a Hawthorne/observer effect from being badged) are not ruled out.
  The impact of the 'open' workspace on human collaboration — read next: Read Bernstein's own transparency-paradox work (2012) and privacy/boundary-management theory (Altman) for the mechanism; look for studies that directly measure the mediator (privacy-seeking behavior, perceived observability) rather than inferring it, and that separate 'loss of enclosure' from 'change of neighbors'.
• uninformedEvery quantitative claim in the piece (1/10th the time, 3.5 PRs/engineer/day, 1M+ lines, throughput increasing with team size) is self-reported by the team that built the system and has an organizational interest in publicizing it, with no external audit, no comparison codebase built by an equivalent human-only team under the same product requirements, and no stated method for what counts as a meaningfully-sized 'line of code' or PR.
  Harness engineering: leveraging Codex in an agent-first world
• incompleteThe piece describes human review as optional ('Humans may review pull requests, but aren't required to... we've pushed almost all review effort towards being handled agent-to-agent') but never says what determines which PRs actually receive a human look versus none, or what happens when agent-to-agent review systematically misses the same class of issue because both the authoring agent and the reviewing agent share the same model's blind spots.
  Harness engineering: leveraging Codex in an agent-first world
• incompleteThe scale-dependence of the method itself is unexamined. Epidemiological debugging worked here only because of ChatGPT-scale volume (a full year of core dumps) plus Rockset's abnormally high signal frequency, which together produced enough failures for population statistics to be meaningful. The article says nothing about the small-team or rare-bug case, where population data never accumulates and correlations would never appear.
  OpenAI Fixes 18-Year-Old GNU libunwind Bug by Treating Crash Debugging Like Epidemiology — read next: How to root-cause when failure volume is too low for population statistics — fault injection, deterministic record-and-replay, coverage-diffing single passing/failing runs, and stress-amplifying the triggering event; and how the epidemiological approach degrades at small N.
• incompleteNo diagnostic method is given. The post's central prescription — 'ask where people are quietly compensating for structural failure' — presupposes that compensation is discoverable, but by the post's own logic that compensation is exactly what stays invisible to leadership. No audit technique, survey instrument, incident-review practice, or workload signal is proposed for actually surfacing it.
  Pascal BORNET's Post — read next: Practitioner or academic sources on surfacing invisible/absorbed organizational work — e.g. resilience-engineering methods (Hollnagel/Woods/Dekker) for observing adaptive capacity, or workload/burnout diagnostic instruments.
• incompleteThe post never distinguishes this 'bad' resilience (workaround-masking) from legitimate resilience — a system's genuine, healthy capacity to absorb shocks without needing structural change. As written, 'resilience' is used almost entirely pejoratively, which risks reading as an argument against slack/buffer capacity generally rather than against dysfunction specifically.
  Pascal BORNET's Post — read next: Resilience-engineering tradition (Hollnagel, Woods, Dekker) treats resilience as the adaptive capacity of a sociotechnical system — a largely positive framing this post never engages with or reconciles its own usage against.
• incompleteThe talk claims AI performs well in good codebases and poorly in bad ones, but provides no data or examples to substantiate this — it relies entirely on the audience's intuitive agreement.
  It Ain't Broke: Why Software Fundamentals Matter More Than Ever — read next: Look for empirical studies measuring AI coding tool performance as a function of codebase quality metrics (coupling, cohesion, test coverage).
• incompleteThe talk does not address who is responsible for the initial codebase quality when starting a greenfield AI-assisted project. If the AI generates the initial code, the entropy problem exists from day one.
  It Ain't Broke: Why Software Fundamentals Matter More Than Ever — read next: Investigate AI-assisted bootstrapping practices and whether initial architecture prompting can produce deep-module structures from the start.
• incompleteThe 'Improve Codebase Architecture' skill is mentioned but described only as 'quite complicated' — the talk does not explain how to refactor a shallow-module codebase into deep modules, which is the hardest step.
  It Ain't Broke: Why Software Fundamentals Matter More Than Ever — read next: Read Ousterhout's A Philosophy of Software Design chapters on deep modules; explore the mattpocock/skills GitHub repo for the actual skill implementation.
• incompleteThe talk assumes TDD is applicable to all AI-generated code, but does not address domains where TDD is hard to apply (UI, data pipelines, exploratory prototyping) or where the cost of test-writing may exceed the cost of debugging.
  It Ain't Broke: Why Software Fundamentals Matter More Than Ever — read next: Look for frameworks on when TDD is cost-effective vs. when other feedback mechanisms (type checking, property testing, visual review) are better suited.
• incompleteThe talk's five tips are presented as independent failure modes, but the dependencies between them are not explored. For example, does ubiquitous language require deep modules to be effective? Does Grill Me only work if the developer already has architectural knowledge?
  It Ain't Broke: Why Software Fundamentals Matter More Than Ever — read next: Consider whether these practices form a prerequisite chain or can be adopted independently.
• incompleteThe category of bug Rust does NOT prevent is left implicit. Logic bugs, mis-modeled domains, distributed-systems race conditions across services, mis-handled business invariants — these are arguably the dominant cost in modern backends, and Rust's compile-time machinery does not touch them. Yet the conversation rhetorically positions Rust as 'reliable' full stop.
  Why Rust is different, with Alice Ryhl — read next: Read Hillel Wayne on formal methods and where types stop helping; Rich Hickey 'Simple Made Easy' on complexity that types don't catch; recent work on property-based testing (Hegel/Hypothesis — sponsor of this very episode, interestingly).
• incompleteThe organizational shift Rust demands is gestured at ('change the struct, not the code') but never made explicit. Adopting Rust seriously means moving design effort upstream — into types and ownership topology — which has real implications for who designs, when, and how PRs are reviewed. The conversation treats this as a personal learning curve when it is plausibly a team-process redesign.
  Why Rust is different, with Alice Ryhl — read next: Read Kent Beck on where in the design timeline to invest effort (Tidy First?), Yourdon & Constantine on coupling/cohesion as the unit of design, and Ousterhout's 'A Philosophy of Software Design' on deep modules — then ask: in a Rust shop, who owns ownership decisions, and when?
• incompleteThe cost-of-incidents argument is anchored to a Western, large-company threat model ('don't get woken up at night,' 'don't ship a CVE,' 'don't lose root'). It would be much stronger framed against actual cost-curve data: how much do memory-safety CVEs cost on average, what fraction of Google/Microsoft/AWS incident postmortems involve memory bugs, what's the marginal Rust dev-hour cost per prevented incident? Alice alludes to '~70% of Microsoft/Google bugs are memory bugs' folklore without citing.
  Why Rust is different, with Alice Ryhl — read next: Read the Microsoft Security Response Center memory-safety report (the source of the 70% figure), Google's Android memory-safety post-Rust adoption data, the CISA secure-by-design memo, and the US DoD/NSA memory-safety guidance Alice alludes to.
• incompleteThe Cargo/npm risk parallel is acknowledged and immediately dropped. Given the kernel's explicit rejection of fetch-and-run package management (Linus's anecdote), Rust's strategy for supply-chain integrity is load-bearing for any organization considering it for security-sensitive code — yet the episode offers nothing beyond 'it's a hard problem.'
  Why Rust is different, with Alice Ryhl — read next: Read crates.io's threat model docs, the Cargo audit/cargo-vet tooling, Linux distributions' approaches to vendoring Rust crates, and recent academic work on the npm/PyPI/crates supply-chain attack surface.
• incompleteThe Rust-and-AI thesis ('compiler-as-leash for agents') is asserted but not pressure-tested. Crucially absent: what happens when the agent reaches for `unsafe` to satisfy the compiler? What happens when the agent's chosen data structure is the wrong one and the compiler keeps approving — but at the cost of forcing Arc<Mutex<...>> everywhere? The compiler can't catch 'this struct shape was a bad idea.'
  Why Rust is different, with Alice Ryhl — read next: Look for empirical evaluations of AI coding agents in Rust vs in Go/TypeScript (recent benchmarks from Anthropic/OpenAI/SWE-bench-Rust), and pair with vibe-coding critiques like Steve Yegge / Gene Kim — exactly what Kjetil is already reading.
• uninformedGergely floats 'is Rust uniquely good for agents because of compiler feedback?' and neither speaker has data; Alice has 'tried to use them' but is 'still learning.' This is a place where the conversation would have benefited from a third voice with measured agent-on-Rust experience.
  Why Rust is different, with Alice Ryhl — read next: Recent reports/benchmarks on agentic coding by language (e.g. METR/Anthropic, Cursor postmortems, the Aider language-success-rate leaderboard) would directly fill this.
• illogicalThe phrase 'when it compiles, it works' is acknowledged-in-quotes but then deployed as if it were literally true (Alice's refactoring anecdote, Gergely's monologue). This conflates 'no bugs in the bug-classes Rust catches' with 'no bugs at all.' For an audience of senior engineers, the difference matters and the slippage is rhetorically convenient.
  Why Rust is different, with Alice Ryhl — read next: Read any survey on bug-class distributions in production systems; pair with Brian Goetz / Bjarne Stroustrup commentary on the limits of static typing.
• incompleteNo discussion of how the harness itself is engineered, tested, or evaluated. The Observability section mentions traces and `/eval` but provides no example evaluation results, no harness-coverage metrics, no failure-mode regression tests beyond 'trace-to-test'. The harness is presented as fait accompli, not as something the reader could audit.
  GitHub - Doorman11991/smallcode: AI coding agent optimized for small LLMs. 87% benchmark with 4B-active model. — read next: Connect to Birgitta Böckeler's harness-engineering article (already in the user's library): her steering-loop concept asks how a team iterates the harness based on observed failures. Apply that lens here — what is SmallCode's own steering loop?
• incompleteGrinich's 'industrialization phase' analogy launders externalities
  Itchy Brain (Still Burning: Michael Grinich & Kent Beck on AI adoption, enterprise developer tools) — read next: Tooze on energy transitions; the IEA's compute-electricity projections; the literature on whether the late-19th-century industrialization actually 'cleaned up' or just exported externalities. For Kjetil specifically: this is the systems-thinking lens — feedback loops, stocks/flows, who absorbs what — applied to the rhetoric of inevitability.
• illogicalThe piece promises evidence 'to reconstruct why a run behaved the way it did' while simultaneously prescribing metadata-by-default, content-capture-by-exception as the data-minimization rule. But in an LLM loop the 'why' is largely semantic -- it lives in the prompt and tool-result content the design says not to store by default. Turn counts, byte sizes, retries, and policy decisions can show that a run wandered (which turn, how much, how many retries) but not what the model was reasoning toward when it chose to retry or picked an expensive model. The recipe answers 'that' and 'how much' more convincingly than the 'why' its own framing promises.
  The Meter Was Always Running — read next: extract-fowler-bockeler-static-sensors-iii draws exactly this computational-vs-inferential-sensor distinction for code modularity review and argues explicitly that deterministic (computational) sensors alone are insufficient where semantic interpretation is required -- the same lesson applied to a different loop.
• uninformedThe document is an industry-wide, cross-client synthesis produced by a 22-person advisory board; it does not — and structurally cannot — speak to how any of these recommendations play out inside a specific team's existing culture, legacy codebase, or organizational politics. Every blip is stated as a general recommendation, not a contingent one.
  Technology Radar, Volume 34 — read next: Pair with team-level case studies or first-person practitioner accounts (e.g. this corpus's own harness-engineering and agent-config-decay extractions) to ground the Radar's generalizations in a specific team's experience.
• incompleteThe post gives no mechanism, example, or metric for how 'strong lint rules', 'minimum test coverage', or 'auto-review of AI code' were actually assembled or measured in practice -- it is a one-paragraph assertion rather than a case study, unlike other feedback-loops content in this corpus that documents specific before/after outcomes.
  Nick Tune's Post — read next: See extract-honeycomb-disposable-vs-durable-code for a more developed argument that fast feedback loops and guardrails are what let organizations actually realize AI efficiency gains, with more context on why feedback investment compounds.
• illogicalThe piece's own thesis is 'never let AI guess' and 'never rely on an LLM to proofread its own work' -- yet the described QC layer is dominated by deterministic formatting/style tools and a single human 'proofing for flow' pass, with no description of independent fact-checking of the underlying technical claims/procedures against the actual system. The step that supposedly matters most (procedure validation, checking for 'odd assumptions in the code,' 'terms overlapping or in conflict with end-user language') is described impressionistically as a bullet list of questions, while the mechanical tooling steps are described with brand-name, checkable specificity. This asymmetry suggests the namesake verification step is the least rigorously engineered part of the pipeline it is meant to anchor.
  A cautionary tale about AI in tech writing: Why "Trust but Verify" is the only way to scale — read next: Look for accounts that specify concrete verification methods for procedure/business-logic correctness (e.g., running the documented steps against the live system, second-reviewer sign-off) rather than describing verification only as an unstructured reading pass.
• incompleteThe piece treats the shift of the bottleneck from generation to verification as a personal discovery specific to documentation, without situating it in the broader pattern -- already present elsewhere in this corpus -- that verification capacity, not implementation speed, is the new binding constraint across AI-assisted knowledge work generally (code included). The documentation-specific framing adds real value (named tools, a shard-based pipeline) but doesn't acknowledge it is one instance of a wider, already-observed shift.
  A cautionary tale about AI in tech writing: Why "Trust but Verify" is the only way to scale — read next: Cross-read against corpus material on spec-driven software development making the identical claim for code, to see whether the same verification-capacity bottleneck has a consistent shape (or different failure modes) across code vs. documentation.
• 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.