Vibe Coding

Building software by prompting an LLM without reading or owning the generated code — acceptable for disposable software, dangerous as a production practice.

Also known as: vibe coding, Vibe coding, vibe-coding, vibecoding, vibe-coded, vibe coders

How authors use it

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

Documents (43)

• AI Is Changing the Rules of Entrepreneurship Victor P. Seidel, Bret Greenstein, Thomas H. Davenport · 2026-09-09 source ↗ Reader 🖥️
  AI has moved entrepreneurship from a resource-scarcity paradigm (the lean startup, optimized around scarce capital and labor) to a resource-abundance paradigm the authors call 'abundance entrepreneurship,' in which a single founder can orchestrate AI agents to generate, build, and run many ventures in parallel -- so the challenge for entrepreneurs and established firms alike is no longer gaining access to scarce resources but organizing abundant ones, which shifts the binding constraint to founder attention, judgment, and the domain expertise needed to tell which abundant option is actually worth pursuing.
• Inside a Software Factory Paul Iusztin · 2026-09-04 Reader 🖥️
  A 'software factory' — a human-operated automated pipeline of eight SDLC stages over a shared context layer — is the right unit of analysis for disciplined AI-assisted development because it locates humans precisely at brainstorming, planning, and final review while agents execute everything between, and the engineering skill lies not in maximizing automation but in calibrating how much of the factory to build, buy, or leave manual as team scale and trust in the plan grow.
• An LLM wiki changed how I work Casey Newton · 2026-08-19 source ↗ Reader 🖥️
  Building a Karpathy-style, LLM-compiled and LLM-maintained personal wiki — seeded with his own multi-year reporting archive and fed daily by his reading — has been the single most useful change Casey Newton made to his work this year, replacing two earlier, effortful manual knowledge-tracking practices (Notion's agentic link search and Capacities' hand-curated 'blips') with a self-organizing but high-maintenance external memory system that he cannot yet confidently recommend to anyone else.
• What's an Orchestrator—and Why Does Software Need One? Tim O'Brien · 2026-08-17 source ↗ Reader 🖥️
  Software development is splitting the 'developer' role into an 'orchestrator' — a generalist who directs delegated-intelligence systems, remains accountable for what they produce, and can support them without AI — and this role should be professionalized (apprenticed, certified, insured) the way medicine and engineering are, because its holders now carry outsized responsibility without the licensing structures that responsibility normally requires.
• The Self-Building Agent: A LangChain4j Experiment Kevin Dubois, Mario Fusco · 2026-07-24 source ↗ Reader 🖥️
  In a controlled experiment where a code assistant designed and rebuilt its own multi-agent coding system, replacing an autonomous LLM-driven supervisor architecture with a deterministic, pre-declared workflow architecture cut end-to-end task time roughly threefold by eliminating LLM-induced coordination overhead, establishing a concrete speed-versus-autonomy trade-off between the two patterns.
• The case for making your own apps Casey Newton · 2026-07-22 source ↗ Reader 🖥️
  As AI collapses the cost of building software toward zero, a large and growing share of the software people use — within a few years, plausibly a third to half of it — will be hyper-personalized, disposable software they (or their friends and colleagues) make themselves, which will hollow out commercial SaaS products whose value was mainly a mediocre one-size-fits-all UI while sparing those that hold irreplaceable data or can operate headlessly.
• 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.
• 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.
• Who cleans up after the vibe-coding party? Sam Learner · 2026-07-11 Reader 🖥️
  AI coding tools have made producing an open-source contribution nearly free while leaving the cost of reviewing, verifying and maintaining it entirely on human maintainers -- degrading the reputational and communal incentives that sustained volunteer contribution and pushing individual maintainers toward uncoordinated, defensive responses (ending bug bounties, banning AI submissions outright) in the absence of any systemic rebalancing of who does software's unglamorous, chronically undervalued maintenance work.
• Vibe coding has escaped the terminal Casey Newton · 2026-07-08 source ↗ Reader 🖥️
  Vibe-coding tools have escaped the terminal and IDE into consumer-friendly, GUI-native app builders like Raycast's Glaze, making it cheap and fun enough for a non-technical user to build genuinely bespoke, hyper-personalized desktop software — which gives Newton modest but real confidence that such software has a near-term future.
• AI Is Changing Software Engineering. The Fundamentals Still Matter. Abby Bangser · 2026-07-07 source ↗ Reader 🖥️
  AI is transforming who produces, consumes, and maintains software, but the organisations moving fastest succeed by doubling down on engineering fundamentals — right-sized boundaries, modular abstractions, clear interfaces, and operational discipline — as the foundation that lets humans and AI build together safely and sustainably.
• Looking back at the Future of Software Engineering unconference Bartosz Ocytko · 2026-07-07 source ↗ Reader 🖥️
  As agentic engineering matures into human-built-and-operated 'software factories,' the decisive questions of software engineering shift from raw automation to governance — where human judgment and sign-off sit in the automated loop, how platforms (rather than universal upskilling) safely absorb citizen developers, what would keep developer tooling relevant, and how organizations manage the widening gap between teams that codify their processes early and those that don't.
• 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.
• The New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering Addy Osmani, Shubham Saboo, Sokratis Kartakis · 2026-06-15 Reader 🖥️
  As AI increasingly handles code generation itself, what separates production-grade 'agentic engineering' from risky 'vibe coding' is not which AI tool a team uses but how deliberately it designs and maintains the harness, verification (tests + evals), and context around the model — so the discipline a team already has is what AI amplifies, for better or worse.
• Vibe Coding Agent Security And Evaluation Sokratis Kartakis, Aron Eidelman, Wafae Bakkali, Meltem Subasioglu · 2026-06-08 Reader 🖥️
  Operationalizing vibe coding in the enterprise requires redefining trust across two distinct, jointly necessary axes — a defence-in-depth 'Security' architecture (seven pillars: infrastructure, data, model, application/runtime, identity, observability/SecOps, governance) that proves an agent stayed inside its boundary, and a seven-dimension 'Evaluation' framework that proves what happened inside that boundary was actually worth shipping — because a vibe-coded agent can pass every security check while still misreading intent, and no single check (deterministic or AI-judged) covers both questions at once.
• Running Python code in a sandbox with MicroPython and WASM Simon Willison · 2026-06-06 Reader 🖥️
  WebAssembly-embedded MicroPython is the first Python sandbox that meets all the criteria Willison thinks a trustworthy in-process sandbox must satisfy — clean PyPI install, memory/CPU limits, controlled file and network access, host-function interop, and active upstream maintenance — making it the right substrate for safely running plugin and agent-generated Python code.
• Flood of AI 'garbage' is pushing open-source developers to the limit New Scientist - Home · 2026-06-05 source ↗ Reader 🖥️
  AI tools have made producing open-source code contributions nearly free while the human cost of reviewing, fixing and rejecting them has stayed fixed or risen, and this asymmetry is driving burnout, maintainer attrition, and defensive lockdowns across open-source projects that nearly all software depends on.
• Trust Factory Kent Beck (Software Design: Tidy First?) · 2026-06-02 Reader 🖥️
  Extreme Programming was a 'trust factory' — its practices, principles, and values all produced trust as a byproduct of producing software — and AI-augmented ('genie') development is breaking this because it accumulates code far faster than it accumulates trust; the remedy is to deliberately slow augmented development so it manufactures trust the way XP did.
• Using AI to write better code more slowly Nolan Lawson (Read the Tea Leaves) · 2026-05-25 source ↗ Reader 🖥️
  LLMs are flexible enough to produce either fast, unvetted slop or slower, carefully reviewed and understood code, and deliberately choosing the latter — running multiple different models to hunt for bugs, personally validating and triaging what they find, and refusing to ship a PR you don't fully understand — is a better way to use AI for programming, even without a velocity payoff.
• Bliki: Vibe Coding Martin Fowler · 2026-05-21 source ↗ Reader 🖥️
  Vibe coding — building software by prompting an LLM without ever looking at the generated code — is a distinct practice from agentic programming, useful only for disposable software, because forgetting the code exists produces serious risks in security, maintainability, and correctness.
• SWLW #701: Gazing at the misty AI Frontier, From Vibe Coding to Agentic Engineering, and more. Oren Ellenbogen · 2026-05-18 Reader 🖥️
  In the agentic era, software leaders win by raising their ceiling — investing in fundamentals, original thinking, and emotionally-attuned leadership — rather than letting AI flatten everyone to the same elevated floor.
• A model that produces code which compiles and passes the tests it was given is not the same as a model that produces robust code Gary Marcus · 2026-05-09 Reader 🖥️
  Code that compiles and passes its given tests is not the same as robust code; conflating the two inflates AI-coding claims, and progress requires acknowledging this gap rather than celebrating throughput.
• Vibe coding and agentic engineering are getting closer than I'd like Simon Willison · 2026-05-08 source ↗ Reader 🖥️
  As AI coding agents become more reliable, the experiential distinction between 'vibe coding' (unreviewed, low-accountability coding) and 'agentic engineering' (expert-supervised AI coding) is collapsing, which forces practitioners to find new trust signals — usage over inspection — while the entire software development lifecycle must restructure around dramatically cheaper code production.
• Podcast: The AI Joy Gap: Why Some Developers Thrive While Others Struggle Michael Parker · 2026-04-20 Reader 🖥️
  AI-assisted development is creating a polarized experience — joyful for greenfield builders, miserable for legacy-code maintainers — and closing this 'joy gap' requires better planning and review tooling, organizational structures like AI platform teams, and cultural practices that reconnect developers with each other and with the customer problems they are solving.
• LLMs Corrupt Your Documents When You Delegate Philippe Laban, Tobias Schnabel, Jennifer Neville · 2026-04-17 source ↗ Reader 🖥️
  Current LLMs are unreliable delegates that silently corrupt documents during long delegated workflows, as demonstrated by the DELEGATE-52 benchmark across 52 professional domains and 19 models.
• Podcast: Tiger Teams, Evals and Agents: The New AI Engineering Playbook Sam Bhagwat · 2026-04-10 source ↗ Reader 🖥️
  Shipping agentic AI applications to production requires organizations to combine software engineering rigor with data science's comfort with statistical uncertainty, using cross-functional Tiger Teams, domain-specific evals built on proprietary data, and a culture of enthusiastic experimentation.
• 14) Øystein Ulseth pendler mellom å lede og levere Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · 2026-04-07 source ↗ Reader 🖥️
  The best technology leaders pendle (commute) deliberately between leading and delivering — driven not by career ambition but by the joy of building at the right level of abstraction — because crossing that boundary in both directions is what makes you precise: a hands-on background gives leaders pragmatism about complexity and trade-offs, while a leadership background gives builders the holistic, risk-aware perspective that lets them choose what to build.
• Claude Code Source Leak Megathread sixbillionthsheep (Reddit) · 2026-04-01 source ↗ Reader 🖥️
  The Claude Code source leak revealed that the competitive advantage in AI coding tools lies not in model capability but in the orchestration layer -- memory, multi-agent coordination, web search pipelines, session management, and autonomous background agents -- and the community's response exposed collective assumptions about code quality, IP ownership of AI-generated code, and the governance gap in agentic systems.
• 13) Tobias K. Torrissen om kodekvalitet, konferanser og AI Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · 2026-03-16 source ↗ Reader 🖥️
  In the age of LLM-generated code, the durable value of an engineering leader is not in writing code but in cultivating the engineering practices, explicit design discipline, and craft community that determine whether a long-lived system can be understood, maintained, and adapted — and code quality, understood as 'obvious over clever,' matters more in this era, not less.
• 11) AI-spesial med Vilde Opsal og Anders Sveen Truls Jørgensen og Audun Fauchald Strand — Heis Podcast · 2026-02-16 source ↗ Reader 🖥️
  AI-assisted development is a real step up in abstraction that pays off only when teams pair it with judgment, structure and active learning — speed gains come from agentic tooling, but durable value comes from evals, information architecture and refusing to outsource learning to the model.
• When AI Writes Almost All Code, What Happens To Software Engineering? Gergely Orosz · 2026-01-06 Reader 🖥️
  As AI crosses a real capability threshold and starts writing the large majority of code for many developers and teams, the part of software engineering that was always about judgment, verification, architecture, and accountability — not typing syntax — becomes more valuable, not less, while the raw ability to write code in a given language stops being a differentiator at all.
• Steve Yegge's Vibe Coding Manifesto: Why Claude Code Isn't It & What Comes After the IDE Latent Space · 2025-12-26 source ↗ Reader 🖥️
  Chat-style coding tools like Claude Code are a transitional phase, not the destination; the real endpoint is an agent-orchestration dashboard for fleets of simultaneously-running coding agents, and the discipline this demands — reading diffs instead of code, tolerating unpredictability, and solving multi-agent merge collision — will determine which engineers and teams survive the shift to 'factory farming' of code.
• Gene Kim on Vibe Coding - Part III | Episode 412 | Troubleshooting Agile Douglas Squirrel · 2025-12-24 source ↗ Reader 🖥️
  Agentic coding tools work by letting the AI observe and check the effects of its own actions rather than just chatting, which shifts the developer's job from writing code to decomposing problems into task graphs and delegating pieces to AI — a scarce, teachable combination of specification and delegation skill (not raw coding ability) that now determines who benefits, while the same power that makes the tools valuable (a 'sawzall') makes them dangerous if used past their original disposable-prototyping purpose without guardrails and supervision.
• Gene Kim on Vibe Coding - Part II | Episode 411 | Troubleshooting Agile Douglas Squirrel · 2025-12-18 source ↗ Reader 🖥️
  Vibe coding changes software teams' organizational unit of work — toward smaller, option-rich teams and even individual business-stakeholder-plus-developer pairs rather than net headcount reduction — and because trust in these tools is a learned skill that takes about a year to build, leaders should start adopting now rather than wait for the technology to mature further.
• The Bet On Juniors Just Got Better Kent Beck (Software Design: Tidy First?) · 2025-12-12 Reader 🖥️
  Because AI coding assistants used as 'augmented coding' tools compress a junior developer's ramp-to-profitability and make it more likely they survive the unprofitable early period at all, hiring juniors is now a better economic bet than before -- not a worse one -- provided organizations deliberately manage them for learning rather than production.
• How AI will change software engineering – with Martin Fowler The Pragmatic Engineer · 2025-11-19 source ↗ Reader 🖥️
  AI's defining change to software engineering is not primarily a jump in abstraction level but a shift from deterministic to non-deterministic systems — and the disciplines that make software durable and legible to teams over time (small reviewable steps, tests, refactoring, shared vocabulary, mentorship) matter more, not less, as a result, even as the field has not yet worked out how teams — as opposed to individuals — should operate with AI.
• The Pragmatic Engineer 2025 Survey: What's in your tech stack? Gergely Orosz · 2025-07-15 source ↗ Reader 🖥️
  AI coding-tool adoption among software engineers has become near-universal (85% of ~3,000 respondents) by mid-2025, but which tools are used is strongly shaped by company size and policy — larger companies converge on a single vendor-supplied tool (GitHub Copilot) while smaller companies permit broader experimentation (Cursor, Claude, ChatGPT) — and genuine engineer adoption should be distinguished from 'vibe coding' tool usage, which the data shows is mostly non-engineers (founders, directors, engineering leads) prototyping rather than hands-on developers building production software.
• Leading your engineers towards an AI-assisted future Pete Hodgson · 2025-06-26 source ↗ Reader 🖥️
  An engineering leader should drive AI-coding adoption the same way they'd drive any major capability shift — by setting a clear, phased goal (Experimentation, then Adoption, then Impact) measured with lightweight KPIs, giving teams real autonomy over how they get there, and backing that autonomy with concrete organizational support (training, budget, protected time, a community of practice, empathetic communication) — rather than mandating a usage percentage from day one.
• Coding agents have crossed a chasm singleton.io · 2025-06-14 source ↗ Reader 🖥️
  Autonomous coding agents have crossed a real capability threshold -- from 'smarter autocomplete' and pair-programming assistance to genuine delegate-to collaborators the author can hand whole tasks to -- which shifts the developer's bottleneck from writing code to framing problems well enough for an agent to reason about them, while the developer's own technical foundation and review discipline remain what separates good AI-assisted outcomes from confidently-wrong ones.
• How Microsoft Developers Use AI in Real-World Coding | BRK103 Microsoft Developer · 2025-05-21 source ↗ Reader 🖥️
  AI tools are most valuable to an individual developer not as autocomplete or as a replacement for judgment, but as a fast, tireless conversational partner for ideation, documentation, test generation, and debugging across a developer's own long-lived codebase — provided a knowledgeable human stays in the loop to evaluate, correct, and hold accountability for what the AI produces before it reaches the team's review process.
• How AI will change software engineering Kari McMahon · 2025-04-14 source ↗ Reader 🖥️
  Generative AI is changing software engineering fast enough that confident predictions about the field's future are themselves unreliable, so engineers and organizations should focus less on forecasting the end-state and more on adapting skills, protecting junior pipelines, and treating the engineering team (not the individual) as the unit that has to stay productive.
• Eight years of wanting, three months of building with AI Lalit Maganti · 2025-03-01 source ↗ Reader 🖥️
  AI coding agents are a genuine force multiplier for implementation and last-mile polish, and can unlock projects that would otherwise die from the intersection of difficulty and tedium, but they are a dangerous substitute for design, architecture, and taste -- the developer must retain ownership of the soul of the software or risk building a codebase they cannot reason about.
• Presentation: AI-First Software Delivery: Balancing Innovation with Proven Practices Wes Reisz · 2025-01-01 source ↗ Reader 🖥️
  AI-first software delivery is not one-size-fits-all: teams should choose between supervised and unsupervised agentic approaches based on code longevity and their ability to verify outputs automatically, using structured human-AI collaboration (RIPER-5) to preserve engineering discipline — because AI amplifies whatever practices you already have, good or bad.

Propositions touching this concept (60)

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

2025-03

• explicitcontestedVibe-coding (full delegation to AI) produces functional but unmaintainable systems; the developer must take ownership of all design decisions and review every change.
  Eight years of wanting, three months of building with AI · p5

2025-07

• explicitMost survey mentions of dedicated 'vibe coding' tools (Vercel v0, Bolt.new, Lovable) come from founders, director+ roles, or engineering leads (roughly two-thirds), with the remaining third split between staff+ engineers and other software engineers — suggesting these tools serve prototyping/demo needs for less hands-on roles rather than being broadly adopted by individual-contributor engineers for production work.
  The Pragmatic Engineer 2025 Survey: What's in your tech stack? · p6

2025-11

• explicitVibe coding (strictly defined as not looking at the generated code) is appropriate for prototyping, exploration, and disposable work — including by non-programmers — but not for anything requiring long-term capability.
  How AI will change software engineering – with Martin Fowler · p2
• explicitVibe coding removes the learning loop — the iterative back-and-forth between what the computer produces and what the developer is thinking — and without that loop the developer cannot later tweak, modify, or evolve the resulting software; the only option is to regenerate it from scratch.
  How AI will change software engineering – with Martin Fowler · p3
• explicitdevelopedBuilding a rigorous, shared, DSL-like vocabulary to communicate with the LLM — ideally co-built with the LLM itself — is a more promising line of attack than either unchecked vibe coding or large upfront specifications, echoing domain-driven design's 'ubiquitous language.'
  How AI will change software engineering – with Martin Fowler · p9

2025-12

• explicitcorroboratedAI coding assistants used for augmented coding (not vibe coding) compress a junior's ramp time by collapsing the mechanical search/exploration part of a task -- e.g. evaluating AI-surfaced API options in twenty minutes instead of researching from scratch for three hours -- and the time this frees up should be reinvested in deliberate learning, not more unprofitable feature work.
  The Bet On Juniors Just Got Better · p4
• explicitcontestedVibe coding is unlikely to reduce engineering headcount, and in at least one observed case (the Toppo Pal / Fidelity application) it led to team growth and increased hiring, not reduction.
  Gene Kim on Vibe Coding - Part II | Episode 411 | Troubleshooting Agile · p1
• explicitdevelopedVibe coding shifts the natural organizational unit toward a pair — the person with the problem and the person who can fix it — rather than a full cross-functional squad.
  Gene Kim on Vibe Coding - Part II | Episode 411 | Troubleshooting Agile · p3
• explicitVibe coding's deeper economic effect runs through increasing 'option value' — more modules, more parallel experiments per module, and shorter cycle times per experiment — the same mechanism Carlos Baldwin credits with the economic value unlocked by Amazon's service decomposition.
  Gene Kim on Vibe Coding - Part II | Episode 411 | Troubleshooting Agile · p4
• explicitWho succeeds at agentic/vibe coding is predictable from three specific, teachable traits — skill at specification, skill at delegation, and willingness to do the final ~5% by hand — not from seniority or raw coding ability; one organization's performance reviews independently corroborated this same pattern among resistant senior engineers.
  Gene Kim on Vibe Coding - Part III | Episode 412 | Troubleshooting Agile · p5
• explicitVibe coding, as Karpathy originally coined it, referred to disposable, exploratory code never meant to reach real users or real data — generalizing it into 'use this tool for everything in production and remove the safety catches' is a misuse of the term and a real operational danger.
  Gene Kim on Vibe Coding - Part III | Episode 412 | Troubleshooting Agile · p7
• explicitMany professional developers (as distinct from 'vibe coders') want human-in-the-loop controls — fine-grained permissions, approval gates before destructive actions (rm -rf, database writes, deployments), configurable per-task autonomy levels, and audit trails — making the friction-versus-safety trade-off an actively contested design dimension rather than one settled in favor of full autonomy.
  10 Things Developers Want from their Agentic IDEs in 2025 · p9

2026-01

• explicitEven senior, AI-skeptical engineers (David Heinemeier Hansson) distinguish 'pure vibe coding' (still aspirational for professional work) from 'supervised collaboration' (already real and productive) — and resist vendor claims of agents writing 90%+ of code as inconsistent with holding the line on quality and cohesion.
  The Pulse #158: New Ways Of Coding With AI Tools · p9
• 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-04

• explicitcontestedThe 'specs-to-code' approach (edit specs, never look at code) is just vibe coding renamed and does not work; the code is the developer's battleground.
  [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero · p5
• implicitThe explosion of new apps (84% increase) driven by vibe coding represents a quantity-over-quality dynamic that platforms will need to actively manage.
  Radar Trends to Watch: May 2026 · p12
• explicitcorroboratedThe specs-to-code movement is vibe coding by another name.
  It Ain't Broke: Why Software Fundamentals Matter More Than Ever · p14
• explicitcorroboratedVibe-coded prototypes and vibe-written PRDs are just higher-velocity versions of premature convergence — new rituals replacing old ones without changing the underlying model
  TBM 415: Demand Mix, Discovery, and AI as a (Dys)function Multiplier · p9
• explicitVibe coding (using AI coding assistants) and building agentic applications are two distinct activities that should not be conflated.
  Podcast: Tiger Teams, Evals and Agents: The New AI Engineering Playbook · p8

2026-05

• explicitVibe coding is defined by the practice of not looking at the generated code.
  Bliki: Vibe Coding · p1
• explicit⚡ disputed & corroboratedVibe coding and agentic programming are categorically different practices.
  Bliki: Vibe Coding · p2
• explicitVibe coding lowers the skill threshold for building software to the point that non-programmers can do it.
  Bliki: Vibe Coding · p4
• explicitestablishedVibe-coded software is appropriate only for disposable use.
  Bliki: Vibe Coding · p5
• explicitdevelopedSecurity is the most serious risk of vibe coding.
  Bliki: Vibe Coding · p6
• explicitConceptual hygiene — keeping vibe coding and agentic programming distinct — is worth defending against popular usage.
  Bliki: Vibe Coding · p9
• implicitThe risks of vibe coding scale with code lifetime, audience size, and data sensitivity — not with code volume per se.
  Bliki: Vibe Coding · p12
• explicitLimitations of vibe coding are a moving target tied to model and harness capability.
  Bliki: Vibe Coding · p13
• risk assessmentdevelopedThe robustness gap is most dangerous for vibe coders with little experience and even more so for autonomous coding agents.
  A model that produces code which compiles and passes the tests it was given is not the same as a model that produces robust code · p4
• explicitThe relevant skill for engineers has shifted from vibe coding to agentic engineering, and hiring practices should screen for the latter
  SWLW #701: Gazing at the misty AI Frontier, From Vibe Coding to Agentic Engineering, and more. · p1
• explicitcontestedVibe coding and agentic engineering, which Willison previously considered categorically distinct, are converging in his own practice because he has stopped reviewing every line of agent-produced code.
  Vibe coding and agentic engineering are getting closer than I'd like · p1
• explicitcorroboratedVibe coding is acceptable for personal tools where bugs affect only the creator, but grossly irresponsible for software that affects other people.
  Vibe coding and agentic engineering are getting closer than I'd like · p7
• explicitEnterprises will continue to prefer proven, professionally managed software products over vibe-coded internal alternatives because they need solutions validated by other large organizations over months.
  Vibe coding and agentic engineering are getting closer than I'd like · p8

2026-06

• explicit"Vibe coding" (generating code from high-level intent) is explicitly not the same as "vibe-in-production": production-grade reliability requires that AI agent use remain fully intended and controlled, rather than relying on unvalidated AI output reaching production.
  Spec-Driven Production Grade Development In The Age Of Vibe Coding · p1
• explicitVibe coders should treat public MCP registries as fine for prototyping but unsafe for production: audit server code before connecting, never pass credentials to unverified community servers, scope servers to read-only/non-production data, and log tool usage for audit.
  Agent Tools & Interoperability · p9
• 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
• explicitSecurity and Evaluation are two distinct, jointly necessary axes of trust: Security proves an agent stayed inside its boundary; Evaluation proves what happened inside that boundary was actually worth shipping. A vibe-coded agent can pass every security check and still misread intent, ignore conventions, or degrade user experience.
  Vibe Coding Agent Security And Evaluation · p2
• explicitSecurity operations must themselves become agentic (a continuous Red/Blue/Green triad) because the attack surface in vibe coding is non-deterministic, natural-language-driven, and changes faster than manual security review can track; traditional UEBA is ineffective against non-deterministic AI behaviour.
  Vibe Coding Agent Security And Evaluation · p9
• explicitVibe-coding evaluation differs from evaluating deterministic software or other agent categories along three axes: there is no complete spec to test against (underspecification gap), the gap between 'the agent thinks it succeeded' and 'the code is actually correct' is unusually wide because users and even experienced engineers cannot fully validate the output, and each session is iterative over a stateful, living codebase where bad early decisions compound.
  Vibe Coding Agent Security And Evaluation · p12
• explicitVibe-coding evaluation breaks into seven dimensions — intent satisfaction, functional correctness, visual/behavioural correctness, cost and efficiency, code quality/convention matching, trajectory quality, and self-repair behaviour — with safety and responsible AI cutting across all seven rather than being a separate gate.
  Vibe Coding Agent Security And Evaluation · p13
• explicitThe relevant success unit for a vibe-coding session is convergence — did the user end up with something they wanted — not turn-level accuracy; sessions abandoned mid-flow are far more informative failure signals than individual incorrect turns.
  Vibe Coding Agent Security And Evaluation · p16
• explicitAI coding is a spectrum, not a binary switch, running from vibe coding (casual prompting, 'does it seem to work' verification) through structured AI-assisted coding to agentic engineering (engineered specs, automated evals, CI gates); picking a point other than the most structured end is legitimate for proof-of-concepts or MVPs.
  Google Just Dropped a Masterclass on Agentic Engineering (It's SO Good) · p2
• explicitVibe coding has low upfront cost but high ongoing cost (burning large volumes of tokens iterating on unstructured, sloppy code because there is no system for the AI to follow); agentic engineering inverts this — high upfront investment in building the harness, then output that is three to ten times more reliable and cheaper at scale, with the crossover reached quickly enough to justify diving in early.
  Google Just Dropped a Masterclass on Agentic Engineering (It's SO Good) · p9
• explicitcorroboratedThe key differentiator between vibe coding and agentic engineering is not whether a team uses AI, but how much structure, verification, and human judgment surrounds the AI's output.
  The New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering · p2
• explicitTests verify the deterministic parts of a system; evals verify the non-deterministic parts (trajectory, tool choice, response quality against a bar); without both, the practice is vibe coding regardless of how sophisticated the prompts are.
  The New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering · p3
• explicitVibe coding has near-zero upfront cost (CapEx) but hides a compounding operational cost (OpEx): token burn from unstructured prompting loops, a 'maintenance tax' from reverse-engineering unstructured AI-generated code, and expensive security remediation after the fact; agentic engineering inverts this profile — high upfront CapEx (specs, tests, structured context), low marginal OpEx.
  The New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering · p11
• explicitContext engineering functions as a financial lever, not just a quality one: a dense, high-signal context payload raises an agent's first-pass success rate and avoids the token-burning trial-and-error loops that plague vibe coding.
  The New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering · p12
• explicit66% of CTOs personally use 'vibe coding' tools for rapid prototyping, versus 48% of respondents overall — the most senior technical leaders are using the least-governed AI-tool category for their own work.
  Engineering Leadership Report 2026 · p9

2026-07

• explicitcorroboratedAutonomous loops are the terminal stage of a discipline progression — vibe coding, then planning, then multi-phase plans, then Ralph — in which each stage trades more human prompting for more scaffolding; Ralph's specific advance is replacing a fresh human-written prompt per phase with one looped prompt plus a self-maintained TODO/progress state.
  11 Tips For AI Coding With Ralph Wiggum · p2
• explicitPlatform, SRE, and operational teams should support non-engineer, vibe-coded software creation rather than try to remove or prevent it, because shadow IT is already happening.
  AI Is Changing Software Engineering. The Fundamentals Still Matter. · p6
• implicitEach wave of democratised software creation — PaaS and cloud a decade ago, vibe-coding today — must be supported and governed rather than resisted.
  AI Is Changing Software Engineering. The Fundamentals Still Matter. · p7
• explicitA vibe-coded experiment linking a wearable's heart-rate/recovery data to your work calendar can surface which meetings and colleagues correlate with physiological stress spikes — converting felt stress into directional, personal data.
  🧠 Community Wisdom: How AI is changing product operating models, tracking work stress with Whoop, whether you nee… · p1
• explicitVibe-coded citizen-developer applications require deterministic infrastructure-level controls — separate infrastructure and restricted data access — to defuse the lethal trifecta, because relying on the developers' own security awareness is insufficient.
  Fragments: July 21 · p5
• explicitMost current AI practices (prompt engineering, agents, RAG, context engineering, vibe coding, evals) are still emergent and variable rather than stable and codified.
  John Cutler's Post · p6
• explicitExisting vibe-coding vendor tools fall short at safely accessing production data and APIs, leading to static data embedded in apps that bypasses access control or leaks it, so the platform itself must ship access and data guardrails.
  Looking back at the Future of Software Engineering unconference · p10
• explicitThe goal is to move from 'vibe coding' (Vibe-DD, optimizing purely for flow) to 'viable / responsible vibe coding' that keeps flow at the center but adds proactive rigor, correctness and ownership through always-on quality workflows.
  Presentation: The Multi-Agent Approach: Building Reliable and Controllable Software Development Automation · p12
• explicitGlaze is an all-in-one vibe-coding app purpose-built for creating and sharing Mac desktop apps, distinct from general-purpose coding tools like Claude Code.
  Vibe coding has escaped the terminal · p1
• explicitThe gap between vibe coding and vibe engineering is where most teams will get burned first — running agents in real infrastructure demands engineering rigor, not just prompting.
  SWLW #710: Revised rules of Eng Leadership, When AI costs more than the engineer, and more. · p11
• explicitAs AI increasingly writes production code, 'vibe coding' is no longer adequate for enterprise reliability; concrete specifications, testing, and verification (spec-driven development) are what let coding agents build software that stays reliable as projects grow.
  The Org Age of AI: A Collection of Enterprise AI Adoption Guides · p4
• explicitAI coding tools have produced a large influx of proposed open-source contributions, most of which are low quality, useless, or require significant review time even when submitted in good faith, including from vibe coders who sometimes cannot understand the code they submit.
  Who cleans up after the vibe-coding party? · p3

2026-09

• explicitThe clear line between vibe coding and disciplined, maintainable use of coding agents is defined by whether a software factory — process and gates — sits around the agent.
  Inside a Software Factory · p2

Tensions

Open gaps (88)

• 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.
• uninformedNo mention of legal or IP questions raised by AI-generated business assets -- copyright status of AI-generated code, branding, and marketing copy, or liability when an autonomous agent like Felix independently spends capital and enters payment transactions.
  AI Is Changing the Rules of Entrepreneurship — read next: Legal scholarship on AI agent liability and the IP status of generative output; regulatory commentary on autonomous agents holding and spending capital.
• incompleteSycophancy and the 'illusion of progress' are named as core challenges, but the only prescribed mitigation is a general exhortation to 'leave their computers for the real world of commerce' -- no concrete practice (adversarial-critic prompting, real customer-validation gates, third-party audits) is offered, even though this is the crux of the 'expertise still matters' argument.
  AI Is Changing the Rules of Entrepreneurship — read next: Corpus material on adversarial-critic prompting patterns explicitly names the same unresolved failure mode -- see extract-eating-my-own-dog-food-ai-autonomy-framework#g5 ('model sycophancy despite hostile persona, critique that is adversarial in tone but generic in substance').
• incompleteParker frames the joy gap as greenfield vs. legacy but never examines whether the 'joy' experienced by greenfield developers is sustainable or genuine. Rapid AI-assisted prototyping may produce initial excitement that fades as technical debt accumulates or as developers realize they've lost depth of understanding.
  Podcast: The AI Joy Gap: Why Some Developers Thrive While Others Struggle — read next: Research on skill atrophy in automation-heavy domains (aviation, healthcare); Bainbridge's 'Ironies of Automation' for the classic formulation
• incompleteThe AI platform team concept is asserted but not developed. How does it differ from existing developer experience (DX) or platform engineering teams? What skills does it require? How does it avoid becoming a bottleneck itself? The analogy to Docker containers is gestured at but not followed through.
  Podcast: The AI Joy Gap: Why Some Developers Thrive While Others Struggle — read next: Team Topologies (Skelton & Pais) on platform team design patterns; internal developer platform literature
• incompleteThe thread extensively discusses Claude Code's web search pipeline but never addresses how claude.ai's web search differs, despite ai-software noting they use the same search index but 'completely different content pipelines.' The implications for the much larger claude.ai user base are unexplored.
  Claude Code Source Leak Megathread — read next: ai-software's own blog posts and any Anthropic documentation on the claude.ai search pipeline
• uninformedThe conspiracy theory about intentional leaking ignores the simplest explanation: organizational silos. The team building anti-distillation defenses is likely not the team managing the npm build pipeline. Large organizations routinely have sophisticated capabilities in one area and elementary failures in another.
  Claude Code Source Leak Megathread — read next: Literature on organizational failures in complex systems (e.g., Perrow's 'Normal Accidents', Vaughan's 'The Challenger Launch Decision')
• illogicalThe 'user delight > code quality' argument commits a temporal fallacy. Current user satisfaction says nothing about the long-term sustainability of the codebase. a0flj0 correctly identifies this but is dismissed by the majority. The argument conflates a snapshot metric with a trajectory.
  Claude Code Source Leak Megathread — read next: Ward Cunningham on technical debt; Lehman's Laws of Software Evolution
• incompleteNobody in the thread addresses the ethical implications of KAIROS/Dream Mode from a data privacy perspective. An agent that autonomously processes user data while the user is away raises consent and data processing questions, especially under GDPR.
  Claude Code Source Leak Megathread — read next: GDPR Article 22 on automated decision-making; any Anthropic privacy policy or DPA covering background processing
• misinformedSeveral commenters conflate the leaked source code (the CLI orchestration layer) with Claude's model weights or training data. JulioMcLaughlin2 correctly notes this is 'the wrapper sent to Anthropic's servers' but this distinction is lost on many participants who ask if this enables a 'free Claude.'
  Claude Code Source Leak Megathread — read next: Basic architecture of LLM applications: the distinction between inference server, API, and client-side orchestration
• incompleteThe Undercover Mode discussion lacks any serious ethical analysis. A feature designed to let AI contribute to public repos without disclosure has implications for open-source trust, code review practices, and the integrity of contribution records. The thread treats it as either 'cool' or briefly 'an ethical landmine' without following up.
  Claude Code Source Leak Megathread — read next: Open source governance literature; existing policies on AI-generated contributions (e.g., Linux kernel policy)
• uninformedThe thread assumes that Anthropic's session limit A/B testing is unusual or nefarious. In reality, nearly all SaaS products use feature flags and A/B testing for resource allocation. The finding is significant for transparency reasons but the conspiratorial framing ('tricking you') is unwarranted without evidence of deceptive intent.
  Claude Code Source Leak Megathread — read next: Standard practices in SaaS product management; Anthropic's Terms of Service on usage limits
• unstated assumptionThe author assumes that the inability to externalize institutional knowledge and design context is a fundamental limitation of AI, not merely a tooling limitation. This conflates current AI capabilities with inherent constraints. Future models with persistent memory, codebase-scale context, and temporal reasoning could potentially bridge this gap.
  Eight years of wanting, three months of building with AI — read next: Read work on long-context models, AI memory architectures, and research on whether design taste can be formalized or learned (e.g., Christopher Alexander's pattern language as a possible bridge).
• omissionThe article does not discuss the economics of AI-assisted development beyond the $200/month Claude Max subscription. The 250 hours of personal time invested is mentioned but not analyzed in terms of opportunity cost or compared to hiring/contracting alternatives.
  Eight years of wanting, three months of building with AI — read next: Compare with analyses of AI coding tool ROI; consider the total cost including cognitive overhead and the discarded vibe-coding month.
• unexamined tensionThe author claims 'AI didn't just make the same project faster -- it changed what the project was' (adding editor extensions, docs, WASM playground). But he also claims the core value comes from the parser architecture, which AI was harmful for. This raises the question: did AI expand the project's scope in the right direction, or did the cheap last-mile features dilute focus on the hard core?
  Eight years of wanting, three months of building with AI — read next: Consider the 80/20 principle in open source: does breadth of features or depth of core reliability drive adoption?
• implicit premiseThe expertise-x-verifiability framework assumes that 'taste' and design judgment are inherently human and non-formalizable. This is stated as obvious but is actually a deep philosophical claim about the nature of aesthetic and design knowledge. If taste could be partially formalized (as design systems and API design guidelines attempt), the framework's boundaries would shift.
  Eight years of wanting, three months of building with AI — read next: Joshua Bloch's 'How to Design a Good API and Why It Matters'; API design guideline literature; whether LLMs can learn design heuristics from large corpora of well-designed APIs.
• incompleteFowler offers no mechanism for detecting when 'disposable' software is silently graduating into consequential software. The disposable/consequential boundary is treated as legible to the author, but in practice it is one of the most common failure modes in software organisations — internal scripts becoming critical infrastructure.
  Bliki: Vibe Coding — read next: Cutler on institutional overload and shadow systems; classic discussions of 'tactical' vs 'strategic' programming (Ousterhout, Philosophy of Software Design); literature on shadow IT and end-user computing.
• incompleteNo engagement with the cultural/professional question of whether vibe coding deserves the name 'coding' at all, or whether legitimising it as a coding practice (rather than, say, 'spec-driven prototyping') invites exactly the diffusion problem Fowler is trying to push back against.
  Bliki: Vibe Coding — read next: Naur on programming as theory building; the broader 'what is programming' debate that has resurfaced post-LLM.
• 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 vibe-coding governance discussion describes deterministic infrastructure controls and board-level threat-modeling sessions as mitigations, but gives no account of who owns ongoing enforcement, how already-deployed shadow-IT tools get triaged or migrated, or what the platform one company is 'looking to build... to control this work without stifling the useful tools' concretely consists of.
  Fragments: July 21 — read next: Platform-engineering and golden-path literature on retrofitting governance onto organically-grown shadow tooling without killing its usefulness.
• 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 argument assumes that team autonomy and team learning are the right units of analysis. It does not engage with alternative views — e.g. that AI might shift the unit back to the individual contractor or fragment work into smaller, more decomposable tasks, in which case the team-level prescription is the wrong response to the wrong question.
  9) Nils Brede Moe om AI-paradokset, autonomi, læringskultur og fremtidens team — read next: Read agentic-work literature (Eric Ries, Naval-style 'agency leverage' arguments, Yegge's vibe-coding manifesto) for the opposing view.
• incompleteThe conversation explicitly opens but does not close the team-augmentation question — what does multi-agent + multi-human team coordination look like in practice? Vilde admits FINN/Vend has not cracked it.
  11) AI-spesial med Vilde Opsal og Anders Sveen — read next: Nils Brede Moe (Heis ep 9) on AI paradox + autonomy + learning culture; Pocock workshop on harness design for long-running agent teams; emerging literature on multi-agent code review and orchestration.
• incompleteNorwegian/Nordic constraints (persondata, public-sector compliance, sovereignty, DPA-with-Anthropic) are mentioned repeatedly but never developed into a coherent picture of how the Norwegian stack will diverge from the US default agent stack.
  11) AI-spesial med Vilde Opsal og Anders Sveen — read next: Smidigposten / Norwegian agile community pieces on public-sector AI; sovereign-AI / data residency discussions; Vipps/DNB/NAV-specific writeups.
• uninformed (in a time-stamped sense)The episode is explicitly dated end of January 2026 and pre-DeepSick announcement; the participants flag this themselves.
  11) AI-spesial med Vilde Opsal og Anders Sveen — read next: Re-listen after major model releases; compare against follow-up Heis special when produced.
• incompleteTorrissen's frame is largely Norwegian consultancy and public-sector. The 30-year-lifespan argument is anchored in NAV/Skatt/politi; he gestures at differential quality bars for low-stakes consumer apps but does not engage with product-company contexts (startup, scaleup, SaaS) where the relevant time horizon is 3-5 years and the relevant readers are 5-10 engineers, not 70 forvaltere.
  13) Tobias K. Torrissen om kodekvalitet, konferanser og AI — read next: Read this against the Pocock workshop extraction (product-company AI workflow) and Vidar Moe (Heis), to see how product-company engineers calibrate quality differently.
• incompleteThe 'engineering practices matter more under AI' claim rests on one cited Telenor talk. Strong intuition, weak evidence. A serious version needs DORA-style measurement of practice maturity × AI uplift.
  13) Tobias K. Torrissen om kodekvalitet, konferanser og AI — read next: DORA 2025 (already in user's library); the Entur AI adoption piece; Addy Osmani's agent patterns; any rigorous productivity studies.
• incompleteThe 'obvious over clever' principle is presented as inheritance from NAV's tekniske retning but the tradeoff against domain-modelling power, type-system expressiveness, and idiomatic language use is not explored. A 'maximally obvious' codebase in a functional language with strong types may look obscure to a Java-trained 70-forvalter pool.
  13) Tobias K. Torrissen om kodekvalitet, konferanser og AI — read next: Greg Young / Vlad Khononov on domain modelling; Ousterhout's 'A Philosophy of Software Design'; Rich Hickey's 'Simple Made Easy' (vs. 'easy ≠ obvious').
• incompleteTorrissen acknowledges he's about to participate in a recursive case (reviewing code that was itself generated agentically) and only jokes. The methodology gap — how does code review change when the developer's intent is partially encoded in prompts, ADRs, and context files rather than commit history — is left for next time.
  13) Tobias K. Torrissen om kodekvalitet, konferanser og AI — read next: Anthropic 'harness design' talk and the Pocock workshop already in this corpus.
• incompleteThe advice to juniors assumes the fundamentals taught today are the right ones; doesn't engage with the possibility that fundamentals themselves need re-curation for a world where LLMs are the second author. What does TDD even mean when test generation is also automated?
  13) Tobias K. Torrissen om kodekvalitet, konferanser og AI — read next: Kent Beck's recent 'Tidy First?' work on AI and design; 'starving genies' series; DORA on AI testing practices.
• uninformedTorrissen disclaims familiarity with the formal 'distribution law' he invokes (Parnas/Helland-style). He gets the spirit right but doesn't engage with the literature on when distribution is forced (latency, regulatory, fault isolation).
  13) Tobias K. Torrissen om kodekvalitet, konferanser og AI — read next: Pat Helland's papers; Parnas on module boundaries; Vlad Khononov directly.
• incompleteCode quality discussion is silent on data and persistence design — arguably the longest-lived and hardest-to-change layer in 30-year systems. The whole conversation is about behavioural code.
  13) Tobias K. Torrissen om kodekvalitet, konferanser og AI — read next: Stripe-style schema evolution practice; Martin Kleppmann's data engineering work; event-sourcing reflections from CQRS practitioners.
• incompleteScale dependence of pendling. The whole career story plays out inside two large Norwegian financial-services organisations (Storebrand, Fremtind) that recognise technical depth as legitimate seniority. The conversation never tests whether pendling is feasible — or how it changes shape — in small startups (no role to come back to), pure consultancies (the IC vs. leader frame may not apply), public-sector hierarchies (rigid grade structures), or US-style stock-comp tracks where stepping back is also stepping out financially.
  14) Øystein Ulseth pendler mellom å lede og levere — read next: Pair with Charity Majors' 'Engineer-Manager Pendulum' original essay to see her conditions for it working; pair with Will Larson on staff-engineer archetypes for the IC-track question; pair with Norwegian-public-sector accounts (NAV optimising for fast flow) for the bureaucracy edge case.
• incompleteThe people who can't pendle. Ulseth's account is sympathetic to both directions but assumes the listener has the option of swinging both ways. It does not address those who are only-leaders (lost technical currency) or only-deliverers (no taste for organisational complexity) — and whether they should be coached, paired, or left in their lane. There is a real possibility that pendling is a personality privilege as much as an organisational one.
  14) Øystein Ulseth pendler mellom å lede og levere — read next: Camille Fournier on technical-leadership transitions; Cutler on the costs of forcing technical contributors into managerial roles; Allen Holub on accountability and the limits of role-fluidity.
• incompleteThe architect's function is never defined. The talk asserts that architecture has not changed in its core function, only in practice — but it does not say what the function is. The closest thing to a definition is 'enabling speed and flow via loose coupling and high cohesion', which is more a goal than a function and which collapses architecture into platform engineering in some readings.
  14) Øystein Ulseth pendler mellom å lede og levere — read next: Vlad Khononov on coupling in distributed systems; Ruth Malan on architecture as 'the design decisions that are hardest to change'; Team Topologies for the sociotechnical framing Ulseth invokes.
• incompleteBredde/dybde sounds clean but is operationally underspecified. How does a sjefsarkitekt choose which initiatives to take as 'mine'? Ulseth nods that they should be 'both important and interesting' and that the two usually overlap — but the harder cases (important-but-boring, interesting-but-marginal) are not discussed. This is the place where pendling-by-design either works or quietly collapses into one side.
  14) Øystein Ulseth pendler mellom å lede og levere — read next: Cutler on how leaders allocate attention; deep-dive into 'staff-plus' patterns where senior ICs balance technical and political work.
• 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.
• incompleteNo data on whether pendling actually produces better outcomes. The argument is largely 'I felt better and have heard I do better.' The episode lacks any reference to organisational research on whether engineer-manager pendulum careers correlate with better team or product outcomes — and whether the benefits go to the individual, the team, or the organisation.
  14) Øystein Ulseth pendler mellom å lede og levere — read next: Pragmatic Engineer / Newcomer on staff-plus role outcomes; LeadDev surveys on engineer-manager transitions; academic work on bidirectional career mobility in knowledge work.
• uninformedUlseth notes he has not yet seen conversational architecture practiced and that sociotechnical architecture is a new acquaintance — yet these are the frameworks he is now bringing into Fremtind's IT strategy. The talk does not engage seriously with the published critiques of these models (e.g. that Team Topologies under-specifies platform-team funding, or that Harmel-Law's model assumes a maturity teams may not have).
  14) Øystein Ulseth pendler mellom å lede og levere — read next: Andrew Harmel-Law's own book and the Architecture Decision Records literature; critical reviews of Team Topologies (Manuel Pais et al.).
• illogicalThe piece argues both that AI's pace of change is unlike anything the author has seen in 20+ years, and that established change-management patterns from prior technology waves (DevOps, cloud, CD) will straightforwardly transfer — without reconciling why a genuinely unprecedented shift would be well-served by a non-unprecedented adoption playbook. The claim that 'proven methodologies' suffice is asserted, not argued against the claim of novelty made two paragraphs earlier.
  Leading your engineers towards an AI-assisted future — read next: Look for arguments specifically about what, if anything, is structurally different about AI adoption that would break a Mission Command-style rollout — e.g. the rate of tool obsolescence outpacing a Community of Practice's ability to stay current.
• incompleteEvery control in the 7-pillar architecture is justified by first-principles reasoning about non-determinism and by citing named threat patterns (slopsquatting, invisible payloads, Confused Deputy), but no incident data, overhead measurements, or cost-benefit comparison is offered for any proposed control — e.g., no data on how much the 'Vibe Diff' + hardware MFA step actually reduces blind-approval rates versus a simpler gate, or on the operational cost of running a continuous Red/Blue/Green triad alongside every development workflow.
  Vibe Coding Agent Security And Evaluation — read next: This corpus's own extract-lulla-loop-engineering-building-blocks-adoption-impact documents, for a structurally similar case (loop engineering's prescribed building blocks), that almost none of a comparably detailed practitioner-prescribed architecture shows up as committed, verified practice in real repositories — worth reading against this whitepaper's unverified 7-pillar prescriptions for the same pattern.
• incompleteThe evaluation framework explicitly scopes out 'the feedback loop from user corrections back into the model, the harness, or the eval suite' as future work — but the applied tip 'Mine user corrections as labeled failure data' in the same document is precisely that feedback loop's first step (clustering corrections into failure modes), left unconnected to how those clusters would actually drive harness or eval changes.
  Vibe Coding Agent Security And Evaluation — read next: The corpus's context-engineering and agent-config-decay material on how harness/context changes get fed back from observed failures.
• incompleteNo engagement with the counter-thesis that agentic specification is itself a learnable new craft with its own first principles, rather than a hollow shell around an absent practice. Moe treats 'specifying' as essentially less than 'building' — the alienation premise depends on this. But it is at least defensible to argue that designing the specification surface, the test contract, the architectural guardrails, and the review protocol for an agent is a real engineering act that has its own depth. The essay would be stronger if it engaged this counter-position rather than implicitly dismissing it.
  KI, utvikling og følelser — read next: Steve Yegge's vibe coding manifesto (which the user is tracking) and Gene Kim's vibe coding series are explicit attempts to defend specification as craft. Read Moe in tension with them, not just alongside. Beck's evolutionary design tradition is also relevant: is the agent a new kind of pair-programmer that requires a new design discipline, or is it the thing that hollowed out the discipline?
• illogicalLawson labels his own practice 'this other, slower style of vibe coding' while this corpus's canonical definition of the term (Fowler) is specifically *not looking at the generated code* — the direct opposite of Lawson's practice of reading every AI-review finding and demanding full comprehension of a PR 'front-to-back.' The piece never acknowledges this tension, muddying exactly the careful-review-vs-unreviewed-generation distinction it is trying to draw.
  Using AI to write better code more slowly — read next: extract-fowler-bliki-vibe-coding#p1 and #p9 (conceptual hygiene between vibe coding and agentic programming) directly bear on this terminological collision.
• incompleteThe abstract does not define what counts as 'corruption' — whether it includes formatting changes, semantic drift, factual errors, or data loss. The 25% figure is hard to evaluate without knowing the corruption metric.
  LLMs Corrupt Your Documents When You Delegate — read next: Read the full paper's methodology section to understand how corruption is operationalized and measured.
• incompleteThe abstract does not clarify what 'agentic tool use' configurations were tested. The negative result (tools don't help) is only as strong as the range of agentic approaches evaluated.
  LLMs Corrupt Your Documents When You Delegate — read next: Read the full paper's experimental setup for agentic configurations.
• incompleteNo discussion of whether corruption rates vary significantly across the 52 domains. Some domains (e.g., music notation, crystallography) may have much stricter fidelity requirements than others.
  LLMs Corrupt Your Documents When You Delegate — read next: Check the full paper for per-domain breakdowns.
• incompleteExtraction limited to abstract only (242 words). The full paper likely contains detailed methodology, per-model results, domain breakdowns, and qualitative error analysis not available here.
  LLMs Corrupt Your Documents When You Delegate — read next: Obtain and extract the full PDF at https://arxiv.org/pdf/2604.15597
• evidentiaryNo evidence or examples of the robustness gap — the post asserts the distinction without demonstrating it
  A model that produces code which compiles and passes the tests it was given is not the same as a model that produces robust code — read next: Read the linked TNW article for the substantive argument
• conceptualThe 'compiles and passes tests' vs. 'robust' distinction needs operationalization: what specific failure modes does Marcus have in mind?
  A model that produces code which compiles and passes the tests it was given is not the same as a model that produces robust code
• argumentativeNo engagement with counterarguments (e.g., that test coverage can be systematically expanded to close the gap)
  A model that produces code which compiles and passes the tests it was given is not the same as a model that produces robust code
• referentialOpenClaw reference is opaque — unclear whether it's a real tool or rhetorical device
  A model that produces code which compiles and passes the tests it was given is not the same as a model that produces robust code
• structuralThe post is a pointer; the substantive argument lives in the TNW article which is not included here
  A model that produces code which compiles and passes the tests it was given is not the same as a model that produces robust code — read next: Follow the TNW link for the full argument
• incompleteThe piece offers no data on how typical Newton's experience is — he is an early-access, well-resourced tech journalist with a household connection to Anthropic, not a representative consumer; there is no discussion of skill floor, cost sensitivity, or failure/abandonment rate for a broader user base trying Glaze.
  Vibe coding has escaped the terminal — read next: Look for adoption/retention data on vibe-coding app-builders (Glaze, Wabi) beyond first-month enthusiast anecdotes — completion rates, subscription churn, or a more skeptical follow-up in the spirit of this corpus's 'AI Confidence Theater' theme, which treats vivid personal anecdote as a weak substitute for verifiable evidence.
• incompleteNewton flags the copyright/IP question about AI-generated Nightwing artwork but doesn't pursue what it implies for Glaze's business model, Raycast's legal exposure, or likely rightsholder response.
  Vibe coding has escaped the terminal — read next: Seek legal/industry analysis of IP liability for AI app-builders that call image-generation models, and how a marketplace like Glaze's store moderates for this.
• incompleteNo examination of the security/privacy architecture behind an app like Source Code, which merges phone contacts with LinkedIn data into a 'private, locally stored' CRM; Newton himself says he is 'still thinking through issues related to privacy and security,' but the piece never examines what guarantees Glaze actually provides around local storage, API-key handling, or data-exfiltration risk.
  Vibe coding has escaped the terminal — read next: Look for appsec-focused writing on the threat model of vibe-coded apps built by non-technical users that handle personal data (contacts, LinkedIn, API keys) — directly relevant to the reader's application-security interest.
• uninformedAs an outside-observer journalist rather than a practitioner, Newton doesn't engage with the mechanism underneath Glaze — what agent/model architecture it runs, how the 'circle an element to edit it' feature is implemented, or whether the generated code's quality or security is auditable. The piece is long on implications and 'vibes,' short on any rigorous look at what's actually happening under the hood.
  Vibe coding has escaped the terminal — read next: For the engineering-craft angle, look for a practitioner teardown of Glaze's (or Wabi's) underlying agent harness and tooling, analogous to a technical review of Claude Code internals.
• illogicalThe 'SaaS-pocalypse' and 'revenge' framing treats one person's delight in personalizing his own software as evidence for a market-level claim (a genuine threat to existing SaaS and App Store businesses), without addressing switching costs, the long-term maintenance burden of AI-generated one-off code, or whether most consumers actually want to build rather than buy.
  Vibe coding has escaped the terminal — read next: Look for a more rigorous build-vs-buy or market-structure analysis of personal software in the vibe-coding era, rather than a single enthusiast's month-one impression.
• uninformedFowler attributes the current software-industry downturn and job losses primarily to the end of zero-interest-rate financing rather than AI, but does not engage with the counter-evidence elsewhere in the discourse that some of the layoff wave is genuine AI-driven restructuring (not merely macroeconomic or a cover story) — he states his view confidently without weighing the split causation other commentators report.
  How AI will change software engineering – with Martin Fowler — read next: Compare against corpus accounts that split the layoff wave into AI-washing/cover-story and genuinely AI-driven restructuring components.
• 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.
• incompleteThe 'descaling of software' counter-trend is named by Beck and left hanging
  Itchy Brain (Still Burning: Michael Grinich & Kent Beck on AI adoption, enterprise developer tools) — read next: Steve Yegge on vibe coding; Gene Kim's vibe coding series; Simon Willison on the 'no-coder using LLMs to build real software' phenomenon; the Schoening agency-over-skills extraction in this repo (the agency thesis is the descaling-friendly side of this tug of war). Honest framing: Beck's craft instincts and Grinich's institutional instincts pull in opposite directions; you may have to choose.
• incompleteThe 'raise the floor but not the ceiling' claim is repeated approvingly but never operationalized. How does a leader, in practice, recognize ceiling-extending original work as opposed to confidently-presented model-mediated work? Without a heuristic, the framing becomes a flattering self-description rather than a usable filter.
  SWLW #701: Gazing at the misty AI Frontier, From Vibe Coding to Agentic Engineering, and more. — read next: Read Cedric Chin on tacit knowledge or Tyler Cowen on 'what counts as taste in an AI era' for concrete diagnostics; also Karpathy's full talk for his hiring criteria as a partial answer
• incompleteTwo of the curator's headline framings — 'AI raises the floor' and 'AI eats closed loops first' — are pulled toward each other but not reconciled. If AI raises the floor on closed-loop work, the implication is that closed-loop expertise becomes commodity labor while open-loop / relational / ethical work becomes the new premium. The newsletter implies this but does not state it, leaving leaders without an explicit instruction.
  SWLW #701: Gazing at the misty AI Frontier, From Vibe Coding to Agentic Engineering, and more. — read next: Elad Gil's full 'Misty AI Frontier' piece + a careful read of Yue Zhao's leadership argument against Christensen's disruption framing — the synthesis is more useful than either alone
• incompleteThe newsletter implicitly equates 'agentic engineering' (a craft skill) with 'agentic leadership' (a hiring/strategy task) but never separates them. Whether the same person should both code with agents and lead teams that code with agents — and whether the screening criteria are the same — is left ambiguous.
  SWLW #701: Gazing at the misty AI Frontier, From Vibe Coding to Agentic Engineering, and more. — read next: Bruno Fernandez-Ruiz's 'Engineering in the Compiler Age' slides (referenced here, worth a focused extraction) and Karpathy's actual hiring section to see how he separates IC craft from leadership selection
• incompleteThe 'Anthropic AI-resistant evaluation' story is treated as a positive exemplar, but the newsletter does not engage with the obvious tension: a long-horizon take-home where AI is permitted requires significant unpaid candidate time, which is a known equity problem. The curator endorses the design pattern without acknowledging its cost.
  SWLW #701: Gazing at the misty AI Frontier, From Vibe Coding to Agentic Engineering, and more. — read next: The original Anthropic write-up, plus any of the recent compensated-interview / pair-programming-screen literature, for a more honest cost-benefit picture
• illogicalThe endorsement of 'gut over head' (SahilBloom tweet) sits uneasily next to the endorsement of 'shared design concept before you code' (Pocock). The first valorizes unjustified judgment; the second valorizes explicit-and-shared rationalization before action. The newsletter treats both as obviously correct without noting that they pull in opposite directions for a leader deciding which to lean on in a given situation.
  SWLW #701: Gazing at the misty AI Frontier, From Vibe Coding to Agentic Engineering, and more. — read next: Daniel Kahneman on when intuition is trustworthy (closed environments with rapid feedback — i.e., precisely the closed loops AI is eating); Gary Klein's recognition-primed decision research for the conditions under which gut beats analysis
• incompleteNo engagement with the maintenance burden of personal software: who fixes a self-made app when the underlying AI model changes behavior, an integrated API changes, or a bug surfaces months later — especially for the large population of non-technical creators Glaze is explicitly targeting, who by definition cannot debug it themselves.
  The case for making your own apps — read next: Newton's own earlier hands-on Glaze review (extract-platformer-vibe-coding-escaped-terminal) and Fowler's vibe-coding bliki entry, both of which raise exactly this accountability/maintenance gap for AI-generated software more generally.
• incompleteThe '3-4x faster' adoption claim is stated without supporting data, methodology, or definition of what metric is being measured. What specific growth metrics are being compared?
  Podcast: Tiger Teams, Evals and Agents: The New AI Engineering Playbook — read next: Look for empirical studies comparing technology adoption curves (e.g., Thoughtworks Technology Radar data, Stack Overflow surveys, or job posting analysis).
• incompleteNo discussion of how to determine appropriate accuracy thresholds for different risk levels. The framework jumps from 'build evals' to 'hit your threshold' without addressing how to set the threshold.
  Podcast: Tiger Teams, Evals and Agents: The New AI Engineering Playbook — read next: Risk management frameworks for AI systems, such as NIST AI Risk Management Framework or EU AI Act risk categories.
• incompleteThe Tiger Team concept is described but there is no discussion of how Tiger Teams dissolve back into the organization, how knowledge transfers, or how the org evolves its permanent structure based on what Tiger Teams learn.
  Podcast: Tiger Teams, Evals and Agents: The New AI Engineering Playbook — read next: Literature on temporary organizations, project-to-product transitions, and Team Topologies by Skelton and Pais.
• misinformedThe distinction between vibe coding and building agentic applications is drawn too sharply. In practice, development workflow agents (the Discord-to-GitHub-issue agent described) are themselves agentic applications that need evals, blurring the boundary Bhagwat draws.
  Podcast: Tiger Teams, Evals and Agents: The New AI Engineering Playbook — read next: Inner loop / outer loop development frameworks; the concept of 'dogfooding' applied to AI agent development.
• incompleteTrust is treated as one undifferentiated resource. Trust between paired programmers, trust from the rest of the team, trust from the customer, trust in the system (observability) — Beck collapses these. But they have different production functions, different decay rates, and may not be substitutable. A skeptic might point out that customer trust is far more about delivered value than pairing rituals, while pair-trust is largely independent of customer outcomes.
  Trust Factory — read next: Janson + Wester on pair-trust (Heis ep 6 — 'if something feels off, say it once'); Printzell Halvorsen on Nordic societal trust enabling distributed teams (Heis ep 8); Onora O'Neill on the trust-trustworthiness distinction and on different kinds of trust requiring different verification structures.
• incompleteThe 'trust factory' metaphor is endorsed without examining what it concedes. 'Factory' implies trust is manufactured by repeating standardized processes — but a major tradition (cultural, philosophical, theological) treats trust as precisely the kind of thing that cannot be manufactured. Beck does not engage this objection. The metaphor's industrial framing also obscures that XP practices may have worked because they instantiated values the practitioners already held — not because the practices produced the values.
  Trust Factory — read next: Cutler on operating-system design vs cultural pre-conditions (TBM series); Diego Gambetta on trust as a non-manufacturable resource; the 'culture eats process for breakfast' literature.
• incompleteThe four 'slow development' prescriptions are stated but not operationalized for the augmented case. How exactly do you 'slow development to encourage frequent person-to-person interaction' when the genie is so seductive? What are the equivalent of XP practices for the augmented era? Beck explicitly defers this ('not yet settled') but a reader looking for action is left with a principle, not a practice.
  Trust Factory — read next: Beck's own subsequent essays (the 'XPAI' thread he's hinting at); Birgitta Böckeler on harness engineering; Garg on reducing friction in AI development (both already in the user's extracted corpus); Bockeler/Anthropic harness writing.
• incompleteThe cultural specificity of trust is not addressed. XP emerged in a high-trust professional subculture (Chrysler C3, early agilists). Whether the trust factory works in low-trust organizational contexts — or only metabolizes pre-existing trust — is left untested. Same question applies to whether trust factories scale across cultural and national boundaries.
  Trust Factory — read next: Printzell Halvorsen on Nordic high-trust societies enabling distributed teams (Heis ep 8); Fukuyama on high-trust vs low-trust societies; cross-cultural management literature.
• incompleteThe article never specifies the accountability mechanism when multiple orchestrators, or an orchestrator and a vendor/platform, jointly produce a system that fails — it only asserts that delegated intelligence is 'always traceable back to an accountable operator' without addressing shared or contested authorship, which is the common real-world case (an orchestrator directing a third-party agent platform built by another company).
  What's an Orchestrator—and Why Does Software Need One? — read next: Multi-party AI liability and supply-chain accountability frameworks (e.g. the enterprise-as-accountable-integrator argument in extract-outsourced-ai-still-own-the-risk); agent identity/attribution mechanisms that bind actions to a specific accountable principal.
• illogicalThe '100x productive, 100x responsible' claim underlying the insurance/licensing prediction is a bare assertion with no supporting mechanism — it isn't clear that liability scales linearly (or at all) with output volume rather than with the severity and irreversibility of specific decisions, which is how liability actually tends to be assessed (e.g. malpractice law weighs harm caused, not cases handled per year).
  What's an Orchestrator—and Why Does Software Need One? — read next: Legal/insurance literature on how liability and malpractice exposure are actually assessed for high-throughput professionals; the clinical-vs-legal-standards-of-proof distinction between diagnostic usefulness and legal culpability.
• incompleteThe article asserts that finishing and delivering software 'takes the same effort, energy, and technical expertise... as it always has,' which sits in tension with its own DRM anecdote showing a months-long task compressed to 40 minutes — it never reconciles why orchestration effort is claimed to be unchanged in kind when the article's own evidence shows it collapsing by roughly two orders of magnitude in time.
  What's an Orchestrator—and Why Does Software Need One? — read next: Measured before/after productivity studies of AI-assisted delivery (e.g. time-to-10th-PR, throughput metrics) that could clarify whether 'effort' and 'elapsed time' are being conflated here.
• misinformedThe opening hook's claim that reading the article digitally (via a browser) necessarily means 'you have just used' cURL overstates cURL's role in that specific pathway -- most mainstream web browsers use their own networking stacks rather than libcurl to fetch web pages, even though cURL genuinely is extremely widely embedded elsewhere (package managers, command-line tools, embedded devices, app backends). The framing conflates cURL's real, vast reach with a specific, likely inaccurate claim about browser page-loading.
  Who cleans up after the vibe-coding party? — read next: cURL's own documentation on where libcurl is and isn't actually used (browsers vs. tooling vs. embedded systems) for a precise picture of its footprint.
• misinformedThe article calls coining 'vibe coding' Karpathy's most prominent public contribution. This understates his substantive influence (nanoGPT, neural network educational content, Tesla autopilot architecture). Suggests the author is writing for an audience that knows the meme but not the work — and may carry that same shallowness into other technical claims.
  Why Google Isn't Chasing Claude Code — read next: Karpathy's own writing (Software 2.0 essay, nanoGPT, his lecture series). Useful to calibrate when this newsletter's technical depth is reliable.
• incompleteNo explicit threat model. The article enumerates sandbox capabilities but never names the adversary: is it a confused agent, a malicious plugin author, a prompt-injection chain, or a curious user? Each implies different controls and different acceptable risk.
  Running Python code in a sandbox with MicroPython and WASM — read next: Anthropic's 'How we contain Claude' (linked in the same newsletter) provides an explicit threat-model decomposition; pair with Willison's earlier Lethal Trifecta essay for an integrated view.
• incompleteSandboxing solves blast-radius questions but not authority questions. The Meta example (linked in the same issue) shows that the catastrophic failure is granting agents excessive *sanctioned* power — which a perfectly secure sandbox does nothing to prevent. The article never connects these.
  Running Python code in a sandbox with MicroPython and WASM — read next: Read the Meta item against Anthropic containment essay against this piece syntopically; ask 'what authority does the code inside the sandbox have, and who decided?'
• incompletePyodide is dismissed for server-side use on the basis of a 2024 statement; no engagement with running Pyodide via Node embeddings, with PyPy-WASM, RustPython, Starlark, or restricted-Python variants. The 'survey of alternatives' is thin given the strength of the resulting claim.
  Running Python code in a sandbox with MicroPython and WASM — read next: Recent Pyodide release notes, RustPython status, the Bytecode Alliance's component-model work for cross-language sandboxing.
• incompleteNo discussion of side channels or supply-chain risk in the distributed 362KB WASM blob. A prebuilt opaque artifact in a PyPI package is itself a trust delegation, and reproducible builds are not addressed.
  Running Python code in a sandbox with MicroPython and WASM — read next: WebAssembly component-model security analyses; reproducible-build practices for prebuilt native artifacts on PyPI.
• incompleteThe 'usage as trust signal' argument assumes that usage reveals bugs, but many serious defects (security vulnerabilities, data races, subtle data corruption) can lurk for months or years without being triggered by normal usage. Usage is a better signal than artifact appearance, but it is not a sufficient signal for safety-critical properties.
  Vibe coding and agentic engineering are getting closer than I'd like — read next: Literature on latent defects in software; Nancy Leveson's work on system safety; the Therac-25 case.
• incompleteThe essay treats the accountability gap between human teams and AI agents as an acknowledged discomfort but does not explore solutions — contractual liability, organizational accountability structures, or the possibility that AI vendors could offer guarantees or insurance for agent-produced code.
  Vibe coding and agentic engineering are getting closer than I'd like — read next: Legal scholarship on AI liability; Anthropic's own responsible scaling policy; discussions of AI insurance markets.