Riding Model Improvements

Building for the model curve: designing products and harnesses whose compensating scaffolding is deliberately stripped as each model generation absorbs it.

Also known as: AGI pilled, Ride the models, retina display analogy, the model will eat your harness for breakfast, frontier model, frontier models, speciation, November Inflection, load-bearing (harness component)

How authors use it

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

Documents (20)

• How building software is changing at Anthropic The Pragmatic Engineer · 2026-07-28 Reader 🖥️
  Inside Anthropic, AI has not eliminated the traditional structure of software engineering (planning, PRDs, cross-team alignment, code review) so much as relocated where the effort and the bottleneck sit — from writing code to verifying it, and from one engineer working alone to fleets of parallel AI agents whose output is checked, merged, and increasingly re-reviewed by other AI, while every design assumption must now be re-tested at each new model generation.
• Stop Overengineering Your Agent Harness Hugo Bowne-Anderson · 2026-07-22 source ↗ Reader 🖥️
  Most builders should reject the coding-agent-derived harness checklist (memory, compaction, sub-agents, hooks) as a default and instead size their harness to where a given task actually falls on two independent axes — action complexity and context complexity — because harness features are provisional, encoding assumptions about model limitations that expire as models improve (the 'Kirby effect'), so the discipline is to build the minimum viable harness for the job and prune it as capability arrives.
• How the 4 New AI Models Change How You Work AI Daily Brief · 2026-07-10 Reader 🖥️
  A backlogged wave of AI models arriving at once shows the frontier shifting from raw capability to division of labor — orchestrator models directing cheaper, faster, specialized models (voice front-ends, implementation coders) — so working well now means matching each task to the right model rather than always reaching for the smartest one.
• Prompting Claude Fable 5 Claude Platform Docs · 2026-07-07 Reader 🖥️
  Prompting Claude Fable 5 well means steering a markedly more capable, longer-horizon, strongly-instruction-following model with brief goal-and-intent-first directives and asynchronous, memory- and subagent-aware scaffolding — and pruning the enumerated rules, guardrails, and hand-holding that prior, weaker models required.
• How to Actually Prompt Fable 5, Straight From the Team That Built It CyrilXBT · 2026-07-01 Reader 🖥️
  This thread is essentially Anthropic's official Fable 5 prompting guide, compressed and repackaged for practitioners as a six-step migration checklist — it restates the guide's core techniques (latency/timeouts, effort tiers, progress-auditing, proactivity constraints, memory, subagents, final-response format, refusal fallback) nearly verbatim while dressing a public-doc summary in 'straight from the team that built it' authority framing and layering in a few uncited specifics (the ultrathink/ultracode keywords, a sub-5% refusal rate, an 'audit beat softer phrasings' test) that the official extraction does not contain.
• 46 thoughts on the near future bayes · 2026-06-30 Reader 🖥️
  The near future is defined by an already-underway, multi-order-of-magnitude 'algorithmic takeoff' in AI capability — extending from software into robotics, science, and physical production — that will compress vast economic and institutional change into a short, poorly governed window, producing genuine winners and losers, real risks to human agency and strategic stability, and no consensus (including from the author) on how to manage any of it responsibly.
• This Week in AI: Rethinking the Agent Harness Michelle Smith · 2026-05-22 source ↗ Reader 🖥️
  In mid-2026 the strategic locus of AI value has shifted from model selection to harness design, so practitioners — including non-developers — should build their own skill-driven agent harnesses rather than depend on bespoke applications or wrapped commercial products.
• 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.
• GitHub - Doorman11991/smallcode: AI coding agent optimized for small LLMs. 87% benchmark with 4B-active model. https://github.com/Doorman11991/ · 2026-05-21 source ↗ Reader 🖥️
  A well-engineered harness — context budgeting, forgiving tool-call parsing, patch-first editing, two-stage tool routing, decomposed planning, and per-model profiles — can extract production-grade agentic coding work from small (7B-20B), locally-hosted LLMs that would otherwise be considered too weak for the task, making local, private, frontier-free coding agents viable.
• Why cultivating agency matters more than cultivating skills in the AI era | Max Schoening (Head of Product, Notion) Lenny Rachitsky, Max Schoening · 2026-05-09 Reader 🖥️
  In the AI era, the differentiating factor for product builders is not skill acquisition but agency — the willingness to treat the world as malleable and to make things — and the products that endure are those built around a tiny, exceptionally good core rather than an accumulation of features.
• The AI paradox: More automation, more humans, more work | Dan Shipper Lenny Rachitsky (host); Dan Shipper (guest, CEO Every) · 2026-05 Reader 🖥️
  Despite radically improving model capabilities, the agentic era will paradoxically generate more work for more humans — because every agent needs a human gardener, SaaS persists (with users bringing their own tokens via Codex/Claude Code), and progress merely commoditizes yesterday's competence and pushes humans further up the value chain to define what is worth doing next.
• Lenny Rachitsky's Post Lenny Rachitsky · 2026-04-24 source ↗ Reader 🖥️
  Anthropic's Claude Code team ships at compressed (week-or-day-scale) timelines by merging the PM/engineer/designer roles around product taste, deliberately building and shipping products before the underlying model is fully capable so the gap can be tested the instant a better model ships, building its own internal tools with Claude Code rather than buying SaaS, and hiring people who respond to escalating production chaos with enthusiasm rather than stress.
• How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code) Lenny's Podcast · 2026-04-23 Reader 🖥️
  In an era of rapidly improving AI models, the PM role must shift from multi-quarter planning and cross-functional coordination toward radical speed of execution, product taste, and the ability to continuously adapt the product harness to extract maximum value from each new model generation.
• Anette Mellbye's Post Anette Mellbye · 2026-04-20 source ↗ Reader 🖥️
  AI companies must determine early whether they are building durable infrastructure — characterized by switching costs, customer unlearning, and accumulated institutional knowledge — or mere wrappers that platform providers will absorb in their next release.
• Anthropic's Designs Three-Agent Harness Supports Long-Running Full-Stack AI Development Leela Kumili · 2026-04-06 source ↗ Reader 🖥️
  Splitting long-running AI development tasks among three specialized agents — planner, generator, and evaluator — with structured handoff artifacts solves the two core failure modes of autonomous coding sessions (context loss and self-evaluation bias), producing higher-quality and more consistent outputs.
• Don't train the model, evolve the harness Akshay · 2026-04-06 Reader 🖥️
  For a model you don't control — a frozen, rented commodity whose weights you can't change — the reliable leverage on agent performance lives in the harness (the code that feeds the model context, runs its tool calls, and decides when a run ends), not in the weights: a benchmark score conflates model and harness, so most apparent 'model failures' are harness failures (often mundane output-plumbing, not reasoning), and the disciplined way to capture that leverage is an automated fitness-selection loop that adds one mechanism at a time and keeps it only when it clearly beats the current best — a process that compounds until the harness runs out of tricks and the residual misses are genuine capability gaps.
• Harness design for long-running application development anthropic.com · 2026-03-24 Reader 🖥️
  Harness design for long-running autonomous coding should be approached as a moving target: build a multi-agent architecture (planner, generator, evaluator) that compensates for the current model's specific weaknesses on long-horizon, subjective-judgment tasks, then aggressively strip components as model capability advances — because every harness component encodes an assumption about what the model can't do alone, and those assumptions go stale.
• Skill Issue: Andrej Karpathy on Code Agents, AutoResearch, and the Loopy Era of AI No Priors: AI, Machine Learning, Tech, & Startups · 2026-03-20 Reader 🖥️
  The jump in code-agent capability since December 2024 has made human throughput — not model capability — the binding constraint, and the central challenge is now removing yourself from the loop so autonomous agents can maximize token throughput on your behalf.
• Head of Claude Code: What happens after coding is solved | Boris Cherny Lenny's Podcast · 2026-02-19 source ↗ Reader 🖥️
  A year after Claude Code's launch, coding itself is — in Boris Cherny's own, carefully qualified words — 'largely solved' for the kind of programming he does, which has pushed both the bottleneck and the interesting work for Anthropic's Claude Code team upstream: from writing code to reviewing/prioritizing it, from engineering as a distinct discipline to a convergence of engineering/product/design, and from building for today's model to deliberately betting on, and designing for, the model that will exist six months from now.
• Just Talk To It - the no-bs Way of Agentic Engineering Peter Steinberger · 2025-10-14 source ↗ Reader 🖥️
  As coding-agent models (specifically GPT-5-Codex) get good enough to read a codebase and follow short, direct instructions on their own, most agentic-engineering 'harness ceremony' — subagents, RAG, elaborate plan files, custom hooks, MCP servers — becomes charade that works around older model limitations rather than exploiting current model capability, so the highest-leverage practice for a solo developer is to talk to the model directly and let judgment (about blast radius, context budget, and when real structure is needed) develop through intuition rather than process.

Propositions touching this concept (59)

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

2024-10

• explicitNo single frontier model (GPT, Claude/Sonnet, o1) dominates on every axis that matters for coding (speed, editing ability, long-context handling, raw coding capability); as of this conversation the speakers judge Sonnet the best all-round, with o1 strong specifically at interview-style reasoning problems but worse at inferring loose human intent.
  Transcript for Cursor Team: Future of Programming with AI | Lex Fridman Podcast #447 · p11
• explicitPublic coding benchmarks like SWE-Bench are significantly contaminated in frontier models' training data (including the underlying repositories, not just the issues), which undermines their value as an evaluation signal — human qualitative 'vibe checks' are used internally as a necessary supplement.
  Transcript for Cursor Team: Future of Programming with AI | Lex Fridman Podcast #447 · p12

2025

• explicitcorroboratedDefensible AI products combine a frontier model with proprietary data, existing trust relationships, and deep domain expertise; the model is the enabler, the defensibility lives in everything around it.
  Building AI Agents For The Enterprise · p10

2025-12

• explicitThis tacit 'senior thinking' is barely represented in frontier models' base training data — published books and blog posts 'only scrape the surface,' and essentially no corpus of senior engineers' spoken-aloud pairing sessions exists — which is why agents can recognize the elements of senior thinking without having any intrinsic determination to apply them.
  What happens when the coding becomes the least interesting part of the work · p3

2026

• explicitFrontier models can predict their own token cost before executing a task only with weak-to-moderate correlation with actual usage (up to 0.39, achieved by Claude Sonnet-4.5 on output tokens), and input-token prediction is harder than output-token prediction for most models -- with one named exception, Kimi K2, which attains its highest correlation (0.38) on input tokens rather than output.
  How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption in Agentic Coding Tasks · p8

2026-03

• explicitcorroboratedWe should expect speciation of AI models — smaller specialized models with a cognitive core — rather than a single monolithic oracle.
  Skill Issue: Andrej Karpathy on Code Agents, AutoResearch, and the Loopy Era of AI · p10
• implicitThe science of fine-tuning models without losing capabilities is insufficiently developed, which inhibits model speciation.
  Skill Issue: Andrej Karpathy on Code Agents, AutoResearch, and the Loopy Era of AI · p21

2026-04

• explicitGPT-5.4 over-edits the most among frontier models while also being one of the weakest on correctness
  Coding Models Are Doing Too Much · p5
• explicitcorroboratedDeepSeek-V4-Flash is the cheapest small model on the market, beating even GPT-5.4 Nano; DeepSeek-V4-Pro is the cheapest of the larger frontier models.
  DeepSeek v4, and the end of the OpenAI/Microsoft AGI clause · p2
• explicitcorroboratedDeepSeek's models trail state-of-the-art frontier models by approximately 3-6 months.
  DeepSeek v4, and the end of the OpenAI/Microsoft AGI clause · p4
• explicitThe original prompt-in / text-out abstraction LLM was built around in April 2023 is no longer sufficient to represent what frontier models do.
  DeepSeek v4, and the end of the OpenAI/Microsoft AGI clause · p8
• explicitFor a frozen model with zero weight changes, rewriting only the harness can match a frontier model's headline benchmark metric at roughly 7x lower cost per task — the leverage sits in the code around the model, not in the weights.
  Don't train the model, evolve the harness · p1
• implicitFor most teams the practical choice is harness-vs-nothing, not harness-vs-fine-tuning: because you cannot change a rented frontier model's weights, harness engineering is the only lever actually available, and the 'don't train' framing reframes where to look rather than adjudicating a live tradeoff.
  Don't train the model, evolve the harness · p10
• explicitestablishedFrontier models are converging on capability; competitive advantage now lies in the harness and application layer rather than model selection.
  Generative AI in the Real World: Aishwarya Naresh Reganti on Making AI Work in Production · p13
• explicitEven frontier models (Gemini 3.1 Pro, Claude 4.6 Opus, GPT 5.4) corrupt an average of 25% of document content by the end of long workflows.
  LLMs Corrupt Your Documents When You Delegate · p3
• explicitNon-frontier models fail more severely than frontier models on DELEGATE-52.
  LLMs Corrupt Your Documents When You Delegate · p4
• explicitOpen-weight models have reached viability as serious alternatives to closed frontier models, shifting the competition to cost, portability, and support trade-offs.
  Radar Trends to Watch: May 2026 · p2

2026-05

• explicitA frontier model has read 'Hyrum's Law' in training data but does not apply it when designing your API at 3am — skills make it do so.
  Agent Skills · p10
• explicitNo post-training pre-product-market-fit — companies should prove value with frontier models first, then optimize with custom models
  Baseten CEO Tuhin Srivastava on the AI Inference Crunch, Custom Models · p12
• explicitxAI/Grok failed as a frontier model competitor and the highest-return use of its compute is renting to Anthropic
  Suprise Elon Anthropic Team Up Reshapes the AI Race · p3
• explicitElon Musk is better at scaling known-but-hard engineering problems than at cracking genuinely unknown breakthroughs like frontier model research
  Suprise Elon Anthropic Team Up Reshapes the AI Race · p4
• explicitdevelopedFrontier model capability now moves U.S. policy in weeks, not years (six weeks from light-touch policy to FDA-style review proposals after Mythos).
  This Week in AI: Rethinking the Agent Harness · p8
• explicitMythos Preview produces noticeably higher-quality triage output than prior frontier models: fewer hedged findings, clearer reproduction steps, less work to fix-or-dismiss.
  Project Glasswing: what Mythos showed us · p5
• explicitcontestedMythos Preview's distinguishing capability over other frontier models is chain-stitching: turning several low-severity primitives into a single, more severe exploit, where prior frontier models would identify the bug but stop short of finishing the chain.
  Project Glasswing: what Mythos showed us · p6
• explicitAny GA cyber-capable frontier model must include additional safeguards on top of emergent baseline behavior; emergent refusals alone are not a complete safety boundary.
  Project Glasswing: what Mythos showed us · p8
• explicitFree AI models are now roughly equivalent to paid frontier models from one year ago.
  Who Cares About Consumer AI? · p5

2026-06

• explicitModern AI systems — not just the frontier models but most of them — can, with only minimal prompting, autonomously hack into networks, steal data, deploy ransomware and destroy systems.
  Cybersecurity and the Gap Between Skill and Ability · p3
• explicitCorporate guardrails on frontier models cannot contain the risk in the long term, because smaller, cheaper, open-source and locally-run models — especially ensembles run in concert — match frontier models, keep improving, will be passed hand-to-hand like script-kiddie tools, and carry no guardrails; instructing models to surveil and report malicious prompts fails for the same reason.
  Cybersecurity and the Gap Between Skill and Ability · p7
• explicitContext Rot and 'Lost in the Middle' research (across 18 frontier models) shows every model's performance degrades as input grows — even holding task difficulty constant — so a model's raw context-window capacity is the wrong metric for how much can safely be loaded; active context must be treated as a deliberately allocated budget, the way infra teams treat memory.
  Agent Skills · p11
• explicitcorroboratedMany firms over-route tasks to frontier models that exceed the requirements of the work.
  Your Company Needs an Energy Strategy for AI's Next Phase · p7
• explicitestablishedMature agentic engineering practice routes tasks to different models by cost/complexity — large frontier models for requirements/architecture/complex implementation, smaller cheaper models for deterministic work like test generation, code review, and CI/CD monitoring — to avoid paying premium token prices for trivial tasks.
  The New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering · p13
• explicitcorroboratedCheap open models run in loops beat expensive frontier models on cost-per-outcome (Claude ~1.1x/iteration vs GLM 5.2 ~1.05x/iteration at ~5x lower cost -> run the cheap loop 5x more and win), so open-model platforms are the real winners and frontier-lab tokenmaxxing won't survive CFO scrutiny.
  Agentics / Tech Things: Tokenmaxxing is dead, long live tokenmaxxing · p8

2026-07

• explicitThe 'no real agency, therefore nothing to worry about' dismissal wrongly treats 'AI labs are responsible for their models' behavior' and 'frontier models are not fully under their makers' control' as mutually exclusive, when both can be true at once.
  A big week for AI denialism · p8
• implicit⚡ disputed & corroboratedFrontier model capability at the top labs is converging closely enough that competitive advantage is migrating from the model layer to the product/harness layer.
  ChatGPT Just Became A Work Agent · p8
• explicitMicrosoft's in-house MAI models, tuned via its Frontier Tuning program, reportedly match or beat frontier models on specific tasks (matching GPT-5.4 at 10x efficiency on Excel agentic tasks; beating GPT-5.5 on quality for McKinsey's use case at a tenth of the cost) at far lower cost, and Microsoft is now weighing MAI (not DeepSeek) for some internal functions — sidestepping both cost and China-sovereignty concerns at once.
  AI Costs Are Surging and the Cheap Model Fix Might Not Last · p5
• explicitIn a single controlled experiment -- a Chaos Mesh NetworkChaos delay injected between a catalogue service and its Postgres database, with the context deliberately salted with misleading signals (RTT-inflated query timings), run as one ~9,800-token prompt against eleven models -- closed frontier models (Claude Opus 4.8, GPT-5.5, Gemini 3.1 Pro) passed, larger open-weight models mostly kept pace, and lower down Gemma 4 31B was the only self-hostable model to identify the root cause, while the larger Qwen3.6 35B and Qwen3 Coder Next both missed it.
  AI Root Cause Analysis Shifts from Model Reasoning to Context Engineering · p4
• explicitThe per-call cost of AI RCA is negligible (a few cents, even on frontier models) once the correlation work happens deterministically before the model is invoked.
  AI Root Cause Analysis Shifts from Model Reasoning to Context Engineering · p8
• explicitThe proxy model uses a two-phase PREPARE/EXECUTE workflow: PREPARE sends a sample of the data to a frontier model and trains a lightweight local model inside the database; EXECUTE then runs the query against that local proxy instead of the external LLM, reportedly reaching ~100,000 rows/second.
  AlloyDB Ships Proxy Models That Replace LLM Calls with Local Inference Inside the Database · p4
• explicitThe proxy falls back to the frontier model when its confidence is too low or when no trained model is available, allocating the expensive model only to the cases the cheap local model cannot handle.
  AlloyDB Ships Proxy Models That Replace LLM Calls with Local Inference Inside the Database · p5
• implicitThe proxy model is task-specific knowledge distillation relocated into the database and triggered at query time — using a frontier model as teacher to train a cheaper student for a single predicate — rather than a general inference-serving optimization on the same model.
  AlloyDB Ships Proxy Models That Replace LLM Calls with Local Inference Inside the Database · p10
• implicitThe order-of-magnitude cost and throughput win is conditional on two unproven assumptions: that the local proxy's judgments are accurate enough to substitute for the frontier model's on the target predicate, and that a model trained once on a data sample stays valid as the underlying data distribution shifts.
  AlloyDB Ships Proxy Models That Replace LLM Calls with Local Inference Inside the Database · p11
• explicitcorroboratedThere is no fixed capability threshold at which AI becomes 'dangerous' — every past generation of models was once judged too dangerous to release and later proved trivial (GPT-2 is now a weekend student project), and today's frontier models will look the same way in a decade.
  Arvind Narayanan on Why AI Isn't All That Revolutionary · p10
• explicitToday's disparate AI-industry stories are symptoms of a single shift: the AI race has moved beyond who has the best frontier model to encompass hardware, data, pricing, and ecosystem control all at once.
  How the Escalating AI Wars Benefit You · p1
• explicitThe agentic coding capabilities of small local models remain very far from what she is now used to with bigger frontier models.
  Experiences with local models for coding · p12
• explicitPrompting small local models re-imposes the discipline of specific, precise instructions that capable frontier models had let developers abandon.
  Experiences with local models for coding · p13
• explicitGrok 4.5 roughly matches frontier models (Opus 4.8, GPT-5.5) on coding/agent benchmarks and tops a SaaS-workflow agent benchmark, while running at a fraction of frontier per-task cost (about a third of GPT-5.5, a fifth of Opus, a ninth of Fable 5) using less than half the tokens.
  How the 4 New AI Models Change How You Work · p6
• explicitcorroboratedAgentic workloads fire far more LLM calls per task than chat, in a plan-act-observe loop, and a large share of those calls (tool-argument fills, yes/no gates, summaries) do not need a frontier model.
  Microsoft Three-Layer LLM Routing Architecture for AI Agents on AKS · p1
• explicitThe same one-line model-swap flexibility that lets teams adopt more capable (often more expensive) frontier models also lets them downgrade to much cheaper, sometimes open-weight, locally hostable models for many automation-style tasks without materially losing accuracy -- Clare reports reproducing her steering-hooks case-study results with gpt-oss-120b.
  Podcast: Strands Agents with Clare Liguori · p14
• explicitThe article frames the persistence and eventual discovery of PixelSmash as part of "the latest wave of security flaw discovery since the introduction of cybersecurity-focused frontier models," explicitly linking it to InfoQ's own earlier coverage of Anthropic's Claude Mythos.
  AI-Enabled Security Researchers Discover How a Crafted Video Can Provide Attackers Access to Your PC · p7
• explicitGovernment access to frontier models is becoming a negotiated, revocable condition rather than a settled right: Anthropic's restored access to two models (after earlier export-control-driven removal) came bundled with a new cybersecurity classifier and continued government cooperation; OpenAI's GPT-5.6 launched as a tiered preview at the government's request; and OpenAI's proposed 5% government equity stake is read as an attempt to build public trust as much as a financial arrangement.
  This Week in AI: Chips, Checks, and Changing Jobs · p4

2026-09

• implicitClaude Opus 5 is being treated as the 'frontier' reference point against which a multi-provider, multi-model system's quality is validated — even though HydraFusion's own selling point is that it need not rely on any single frontier model.
  GitHub Copilot's Project HydraFusion Promises Frontier Level Performance Through Multi-Model Routing · p8
• explicitMantis's guidance recommends pairing lightweight 'flash'/'lite' models with low-depth tasks (rapid classification, deduplication) and reserving heavier frontier models for tasks needing deep contextual understanding (crash reproduction, side-effect-free patch generation).
  Google Mantis: An Agentic Vulnerability Scanning Harness for Reducing False Positives · p7
• explicitChoosing which specific model to use for a task is becoming a less durable skill than learning how to get the most out of whichever frontier model exists; a current (self-flagged as temporary) heuristic is to use the smartest/slowest model for planning and a faster model for implementation.
  How Anthropic Builds And How Engineering Will Change Soon | Thariq Shihipar · p16
• explicitGetting good output from current frontier models often means explicitly giving the model permission to use more compute (brainstorm first, use subagents/workflows) rather than relying on encouragement, because models default to responding and finishing as fast as possible unless told otherwise.
  How Anthropic Builds And How Engineering Will Change Soon | Thariq Shihipar · p18
• explicitLocal/open-weight models are only 'a few months behind' commercial frontier models on benchmarks and have already reached practical sufficiency for real work — a maturation pattern Warden compares to open-source web servers (Apache, nginx) eventually displacing early commercial server software (Sun Solaris, Microsoft IIS).
  Generative AI in the Real World: Local Voice AI with Pete Warden · p3
• implicitIdentity and authorization gaps, not raw model capability or prompt quality, are already the dominant production failure mode for agentic systems — frontier models (cited: Claude Mythos, 'Fable 5') have shown they can discover and exploit whatever boundary the infrastructure fails to enforce.
  Podcast: Securing AI Agents: Identity, Authorization, and the DPACT Framework · p14
• implicitThe frontier model doing routine I/O work is 'wildly overqualified' for that work — there is a large capability-cost mismatch when the most expensive model in the stack performs routine reads and boilerplate generation.
  Portal by Spotify cut my Claude Code token usage by 90% · p13
• explicitTypeSafe AI is releasing its first "System One Model," Jev, a new class of frontier models that produce fast, structured decisions (typed values plus calibrated probabilities) for direct use by software, instead of generating text.
  Introducing System One Models & Jev · p1
• explicitA company's most durable competitive data is not its archive of finished, successful work ('execution-grade knowledge,' which frontier models are increasingly also exposed to) but its record of rejections, near misses, overrides, and postmortems ('verification-grade knowledge'), which competitors cannot quickly reproduce.
  When AI can do more than we can check · p9

Tensions

Open gaps (75)

• incompleteThought 4 in Culture and Psychology diagnoses a wealth 'doublespeak' (people who say AI benefits everyone but wouldn't trade their own position for a random person's) and unusually applies this critique to the author himself. But the same reflexive scrutiny is not extended to the piece's own epistemics: nearly every uncertain judgment call across the other 45 points (how many OOMs remain, how fast robots scale, whether a pause is wise, whether nationalization happens) resolves toward 'faster/bigger/more capable than consensus expects' — also the reading most flattering to, and most aligned with the visible incentives of, someone with insider familiarity with frontier AI (the piece name-drops GB300s, Anthropic, GLM5.2, Fable, and 'Mythos 2' with specificity). The self-awareness about wealth-doublespeak is not turned on the analogous possibility that consistently forecasting acceleration is itself a predictable output of the author's own position and incentives.
  46 thoughts on the near future — read next: No direct corpus parallel exists; flag as a standalone critical gap about author-incentive disclosure in AI-maximalist forecasting content generally.
• incompleteAgency is presented as the key differentiator but its uneven distribution is noted without exploring why. Structural barriers to agency (economic precarity, organizational culture, psychological safety, access to tools) are absent from the analysis. The advice to 'just make things' assumes access and psychological conditions that are themselves unevenly distributed.
  Why cultivating agency matters more than cultivating skills in the AI era | Max Schoening (Head of Product, Notion) — read next: Amartya Sen's 'Development as Freedom' on capability theory; research on psychological safety (Amy Edmondson) as a precondition for agency in organizations
• incompleteThe intelligence-saturation thesis (retina display analogy) is provocative but untested. Whether knowledge work has a clean saturation point or a long tail of edge cases requiring frontier intelligence is not examined. The analogy breaks if cognitive tasks are heterogeneous in their intelligence requirements.
  Why cultivating agency matters more than cultivating skills in the AI era | Max Schoening (Head of Product, Notion) — read next: Research on scaling laws and emergent capabilities in LLMs; Dario Amodei's 'Machines of Loving Grace' essay on where intelligence bottlenecks actually bind
• incompleteThe conversation repeatedly invokes 'quality' and 'craft' as things the industry is losing but offers no mechanism for measuring or incentivizing quality in an era where shipping speed is the dominant metric. The 'obviously good' standard is acknowledged to be subjective ('you know it when you see it').
  Why cultivating agency matters more than cultivating skills in the AI era | Max Schoening (Head of Product, Notion) — read next: John Ousterhout's 'A Philosophy of Software Design' on complexity as the enemy of quality; the Toyota Production System literature on building quality into the process rather than inspecting it afterward
• uninformedThe piece doesn't address whether enterprises outside the US (e.g., EU/Nordic firms) face a symmetric version of this problem — their own export-control, data-sovereignty, and procurement constraints on using either US frontier models or Chinese open models — which would materially change the calculus described here.
  AI Costs Are Surging and the Cheap Model Fix Might Not Last — read next: EU AI Act / data-sovereignty rules as they interact with foreign frontier and open-weight model access; how European enterprises are already navigating a three-way (US frontier, Chinese open, EU-hosted) model-sourcing decision.
• incompleteNo engagement with cost ceilings or economic boundaries. $124-$200 per multi-hour autonomous run is presented as routine; there is no discussion of when this stops scaling (e.g. teams running this 100x/day, regulated environments with per-call cost controls, or comparison to a human contractor at equivalent output).
  Harness design for long-running application development — read next: Read pieces that treat agent-cost economics directly — Simon Willison's pricing analyses, the smallcode argument for smaller models, any IT-procurement perspective. Also: Anthropic's own enterprise pricing docs as the implicit deployment context.
• incompleteNo treatment of audit, observability, governance, or failure containment for long-running autonomous coding. The piece's implicit deployment is 'a single engineer running experiments at Anthropic Labs.' A Norwegian public-sector or regulated context would need: persistent audit trails of each agent's actions and tool calls, rollback semantics for partial builds, secret management when agents access live services, IP provenance of generated code, and human-checkpoint policies. File-based agent communication is actually well-suited to audit — but the author never makes that case.
  Harness design for long-running application development — read next: Read the EU AI Act's high-risk-system requirements, NIST AI RMF agent guidance if it exists yet, and any sober writing on agent observability stacks. Also: cross-reference Anthropic's enterprise-tier compliance docs.
• incompleteThe 'simplify when models improve' methodology assumes monotonic capability advance. It does not address the (empirically real) case where a new model has different — not strictly better — failure modes. E.g. Sonnet 4.5's context anxiety vs. Opus 4.6's regression on some niche tasks. The methodology is silent on what to do when component removal *reveals* a new weakness rather than confirming an old strength.
  Harness design for long-running application development — read next: Look for empirical model-version-comparison work — Aider/SWE-bench longitudinal results, internal Anthropic evals if available, and practitioner accounts of regressions (e.g. Simon Willison's lab notebooks).
• incompleteThe criteria-as-stylistic-steering observation ('museum quality' produces visual convergence) is surfaced and then dropped. It is treated as a quirky finding rather than a serious concern about AI-generated homogenization. At scale, if many teams use Anthropic-suggested criteria, the result is a deep convergence in the look of AI-generated software.
  Harness design for long-running application development — read next: Read on cultural homogenization risk in generative AI (Naomi Klein, Ted Chiang, and design-criticism writing). Also: the 'AI slop' discourse and any empirical work on generated-design diversity.
• incompleteThe 'long-running' threshold is operationalized only through examples (3.8 to 6 hours) — never defined. A reader cannot tell whether the prescriptions apply to a 30-minute task, a multi-day task, or only to the specific case study durations. Böckeler's harness theory and the smallcode piece operate at different time scales without acknowledgment.
  Harness design for long-running application development — read next: Cross-reference extract-bockeler-harness-engineering.json (theoretical-control framing — variety reduction, feedforward, feedback sensors) which is time-scale-agnostic; the smallcode piece's smaller-task framing; and reach for any time-scale-explicit treatment of agent autonomy windows.
• uninformedThe piece is silent on the existence of a broader harness-engineering theoretical literature (Böckeler's adaptive-control framing, the smallcode engineering-instinct view) — even though Anthropic Labs is presumably aware. As a result, named phenomena are coined fresh ('context anxiety') without acknowledging or engaging with adjacent theory. This is not necessarily a mistake — it may reflect the piece's narrow Labs-experiment scope — but it does mean the reader has to do the cross-mapping work themselves.
  Harness design for long-running application development — read next: Maintain the syntopical map (already in this repo as syntopical-harness-engineering-for-ai-coding-agents.json) and treat this article as one empirical data point, not a theoretical contribution.
• incompleteThe article doesn't address what happens when the evaluator agent is wrong. If the evaluator has calibration errors, the generator will iterate toward those errors. The regress (who evaluates the evaluator?) is assumed away.
  Anthropic's Designs Three-Agent Harness Supports Long-Running Full-Stack AI Development — read next: Literature on specification gaming in RL; AI alignment work on reward hacking
• uninformedNo comparison to alternative approaches. The context-reset claim is made without benchmarks against compaction or other memory strategies. The practical superiority is asserted, not demonstrated.
  Anthropic's Designs Three-Agent Harness Supports Long-Running Full-Stack AI Development — read next: Anthropic's research on long-context models; MemGPT and other memory architecture papers
• incompleteThe conversation is entirely from Anthropic's perspective. No competing viewpoints from OpenAI, Google, or independent practitioners are represented. The interview format means Lenny largely agrees with and amplifies Cat Wu's positions rather than stress-testing them.
  How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code) — read next: Read critical analyses of Anthropic's approach from outside observers; compare with product practices at other frontier labs.
• incompleteThe 'just do things' philosophy and extreme speed of shipping are presented as unqualified goods. The costs (product consistency, user confusion, bugs shipped) are acknowledged but treated as acceptable trade-offs without exploring when they become unacceptable — particularly for enterprise customers who need stability.
  How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code) — read next: Look at enterprise SaaS literature on release management and the cost of change fatigue for large organizations.
• uninformedThe discussion of Co-work replacing tedious PM tasks (decks, meeting prep, email triage) lacks any engagement with the quality ceiling problem: are these AI-generated outputs actually good enough for high-stakes contexts, or do they create a mediocrity trap?
  How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code) — read next: Seek empirical studies on AI-generated content quality in professional settings; read critiques of 'good enough' AI output.
• incompleteThe Open Claude decision is framed purely as a resource allocation choice. The community trust cost and the broader ecosystem implications of an AI company restricting how its model can be accessed through third-party tools are not explored.
  How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code) — read next: Read platform economics literature on ecosystem lock-in; review community responses and long-term effects of similar decisions by other platform companies.
• incompleteNo binding-constraint diagnostic. The whole thesis presupposes the harness — not the model's capability ceiling — is what limits your task, but the piece offers no way to tell in advance whether a given task is harness-bound or capability-bound; you only learn which after gains flatten. The headline example (file-plumbing, 0% -> parity) is a selected case where the harness was the entire story and does not generalize to reasoning-bound tasks. This is the Meadows leverage-point question left unanswered.
  Don't train the model, evolve the harness — read next: Read Boeckeler's adaptive-control harness framing and Anthropic's 'remove components one at a time, keep only the load-bearing' methodology, looking for a procedure that predicts, before investment, which constraint binds — e.g. a cheap probe that separates 'model got the answer but the wrapper lost it' from 'model can't do this at all.'
• incomplete'Don't train' vs 'evolve the harness' is a soft strawman. Fine-tuning is never actually analyzed — no cost, no cases where training genuinely IS the right lever (domain shift, latency/cost at scale, proprietary capability the frontier lacks). For a rented frontier model the real contrast is harness-vs-nothing, so the title over-generalizes into 'never train.'
  Don't train the model, evolve the harness — read next: Read a fine-tuning cost/benefit source to bound when weight-changing is warranted, so the 'harness-first' heuristic has an explicit boundary rather than an absolute.
• incompleteThe automated 'add one mechanism, keep if better' loop has no pruning or garbage-collection step, so accreted mechanisms can ratchet harness complexity upward — precisely the cost the quoted deep-dive warns against (scaffolding should shrink; tight model-coupling creates lock-in). The maintenance and portability cost of an ever-growing auto-generated harness is named in the abstract but never quantified or bounded.
  Don't train the model, evolve the harness — read next: Read on harness co-training overfitting and the 'delete components one at a time' methodology; look for how an automated harness search can be given a complexity penalty or removal operator so it thins rather than only accretes.
• incompleteSecond-hand, single case, no first-party numbers. The entire empirical spine is one relayed Hugging Face experiment (7x cost, 14-point transfer, 3.5-80.1% spread) with no reproducible benchmark, dataset, task definition, or independent replication — thin ground for a rigorous adopter to act on.
  Don't train the model, evolve the harness — read next: Read the source Hugging Face post directly and seek independent harness-ablation studies before treating the 7x / 3.5-80.1% figures as generalizable.
• incompleteThe essay treats the AI as a passive instrument that 'follows your lead.' This was largely true for early single-shot text generation but is increasingly false for frontier models that ask clarifying questions, offer alternatives, and probe for missing intent. The advice still helps, but the underlying model of AI behavior is dated.
  The Best Prompting Advice Came From a Writing Teacher — read next: Recent work on clarifying-question behaviors in agentic models; Anthropic's writing on Claude's interrogative defaults; research on mixed-initiative interaction
• 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 article's proposed defenses — splitting a task apart and keeping only the 'stitching together' step in-house, or using a public model for rough ideas and fine-tuning a smaller in-house model on the real work — are never evaluated for practicality: how much of the value of frontier-model reasoning is lost when the integrating step is withheld, and whether a smaller in-house model can absorb frontier-quality reasoning without becoming a materially weaker substitute.
  Is Your AI Training the Competition? — read next: Research on task-decomposition costs in AI-assisted workflows; small-model fine-tuning/distillation-from-a-public-model literature and its quality gap versus frontier models.
• incompleteProvenance is asserted, not sourced, and the title oversells it. 'Straight from the team that built it' implies insider access, but the body reveals the actual source is Anthropic's PUBLIC official prompting guide, relayed by an anonymous X account with no link to the guide, no author attribution, and no way to see what was faithfully relayed versus added or distorted. The persuasive authority exceeds the sourcing.
  How to Actually Prompt Fable 5, Straight From the Team That Built It — read next: Read the primary guide directly (extract-prompting-claude-fable-5) instead of this relay; treat 'straight from the team' as marketing, not provenance. Locate and confirm the thread-only specifics — the ultrathink/ultracode keywords, the thinking.display value semantics, the sub-5% refusal rate, prompt-cache-cost coverage, the 'audit beat softer phrasings' result, Mythos-drops-cyber — against Anthropic's actual published pages before relying on any of them.
• incompleteDouble staleness / secondary-source drift. The thread compresses an UNDATED official guide (flagged in the sibling extraction as drifting silently as the model and platform update) and is itself a dated July-1-2026 tweet — a dated secondary source of an undated primary. Every version-specific claim (effort defaults, classifier domains, thinking.display values, xhigh-model list, sub-5% refusal rate) is twice-removed from the changelog.
  How to Actually Prompt Fable 5, Straight From the Team That Built It — read next: Re-verify every version-specific claim against the platform changelog and the 'Introducing Claude Fable 5 and Mythos 5' page at time of use; never migrate a production workflow on a tweet's restatement of an undated doc.
• incompleteNo evals or verification — the same bar as the docs, and no better. The thread inherits the official guide's central weakness (no reproducible benchmark, dataset, baseline, or numbers for any recommended prompt block) and layers on further unverified quantification ('audit-language produced more reliable self-checking than softer equivalents'; refusals affect 'under five percent of typical developer queries') with no method behind either. A thread adds zero measurement.
  How to Actually Prompt Fable 5, Straight From the Team That Built It — read next: Do not treat the thread as evidence for any technique. Build an A/B eval harness (as the sibling gap prescribes) that measures each system-prompt block's marginal effect on your own tasks before adopting it; pair with an evals-disciplined source (extract-anthropic-harness-design-long-running-application-development).
• incompleteSelection/hype bias of the thread format: it reproduces the guide's recommendations but trims its hedges. It presents effort as 'not a quality dial' while dropping the guide's intelligence axis and its warning that higher effort can over-deliberate; it never addresses interaction effects among the stacked system-prompt blocks (brevity, audit, proactivity, memory, final-response) that the reader is told to add together; and the engagement-optimized 'different category of tool' framing amplifies upside while muting trade-offs.
  How to Actually Prompt Fable 5, Straight From the Team That Built It — read next: Read the primary guide for the caveats the thread trims; assemble and test the composed system prompt as a whole (the sibling's interaction-effects gap) rather than trusting the thread's flattened, upside-first presentation.
• incompleteAuto research is demonstrated only on hyperparameter optimization — a narrow, well-defined search with clear metrics. No evidence or discussion of how it would work on research requiring genuine novelty, taste, or paradigm shifts.
  Skill Issue: Andrej Karpathy on Code Agents, AutoResearch, and the Loopy Era of AI — read next: Literature on AI-driven scientific discovery beyond optimization: can agents formulate novel hypotheses, not just test existing ones? See work on AI scientists (e.g., Sakana AI's 'The AI Scientist').
• uninformedThe Jevons paradox argument for software engineering jobs is applied without discussing the significant disanalogies: ATMs automated a narrow task within banking, while AI agents potentially automate the entirety of software production. Demand elasticity analysis is hand-waved.
  Skill Issue: Andrej Karpathy on Code Agents, AutoResearch, and the Loopy Era of AI — read next: Economic analysis of AI labor displacement that distinguishes between task-level automation (Jevons applies) and occupation-level automation (potentially different dynamics). See Acemoglu vs Brynjolfsson debate.
• incompleteSecurity and trust implications of the 'apps dissolve into APIs' vision are acknowledged but not seriously explored. Dobby discovered unprotected Sonos APIs — this is a security vulnerability presented as a feature.
  Skill Issue: Andrej Karpathy on Code Agents, AutoResearch, and the Loopy Era of AI — read next: Research on agent-to-API security models, OAuth for agents, and the attack surface of agent-mediated home automation.
• illogicalKarpathy simultaneously claims (1) everything is a skill issue and current tools are sufficient, and (2) models are jagged, burst at the seams, and going too far ahead makes them net negative. These are in tension — if the tools truly suffice, jaggedness should be manageable.
  Skill Issue: Andrej Karpathy on Code Agents, AutoResearch, and the Loopy Era of AI — read next: Framework for distinguishing 'skill issues' from genuine capability boundaries in AI agent systems.
• incompleteThe paradox is asserted but its mechanism is under-specified. Shipper offers 'every agent needs a human' (a maintenance claim), 'benchmarks miss prompting' (an attention claim), and 'models commoditize yesterday's competence' (a frontier claim). These are three different mechanisms doing different work, and Shipper conflates them. The maintenance claim is explicitly transient — he concedes personal agents return as models improve. The attention claim is partially circular — he will redesign his benchmark to zero out a saturated model. Only the frontier claim is structural, and it is the least developed. A serious version of the thesis needs to argue that the new frontier work is itself non-automatable and remunerated — neither is shown.
  The AI paradox: More automation, more humans, more work | Dan Shipper — read next: Acemoglu & Restrepo on task displacement and reinstatement; the 'augmentation vs. automation' literature (Brynjolfsson, Mitchell); recent econometric work on AI's effect on call-centre and software-engineering productivity (the GitHub Copilot RCT, Brynjolfsson-Li-Raymond on generative AI in customer support)
• incompleteThe 'humans-as-orchestrators' vision is unfalsifiable in this conversation. Shipper says explicitly that when models 'saturate' his senior-engineer benchmark, he will redesign it to zero out the current model. If the benchmark moves to wherever AI cannot yet go, the claim 'humans are still needed' is true by construction and tells the listener nothing about the actual trajectory of automatable knowledge work. A senior engineering leader needs a falsifiable formulation — what specifically would need to be true for Shipper to concede that the 'more humans' claim has expired? — and the conversation does not offer one.
  The AI paradox: More automation, more humans, more work | Dan Shipper — read next: Popper on falsifiability; Sutton's 'bitter lesson' as the counter-frame; the eval-design literature (HELM, MMLU saturations, the ARC-AGI debate); recent critiques of human-baseline benchmarks (Anthropic's METR work on long-horizon agentic tasks)
• incompleteSelection effects in the Every case are uninterrogated. Every is ~30 self-selected curious early adopters with pre-release model access, dual media-and-software business model, founder writer-CEO, no legacy systems, no regulated environment, no enterprise sales process longer than the model release cycle. Every assertion in the conversation is sourced from this one organization and projected onto knowledge work in general. For evaluating organizational impact in a Norwegian enterprise context (regulated industries, slower procurement, less English-language model access for non-English work, strong worker-council constraints), the generalization gap is large and unflagged.
  The AI paradox: More automation, more humans, more work | Dan Shipper — read next: Erik Brynjolfsson's recent work on cross-firm productivity dispersion in AI adoption; Wharton-led surveys on enterprise AI deployment; case studies from regulated EU firms (Klarna's published numbers and their later retraction); Norwegian-context: BI Handelshøyskolen / Sintef studies on AI adoption in Nordic enterprise (the 'forskning og digitalisering' extraction in this library)
• incompleteToken-economics assumption (SaaS users bring their own tokens via Codex) is treated as a stable equilibrium when it is more plausibly a transitional artifact. Once enterprise procurement notices that token spend is shifted to user-attached agent harnesses, three forces will push back: (a) per-call agent-tier pricing from SaaS vendors capturing the new volume, (b) enterprise consolidation of agent infrastructure (corporate-controlled Codex/Claude Code deployments), and (c) usage-based SaaS pricing emerging precisely to capture agent-driven volumes. Each of these inverts Shipper's 'buy SaaS stocks' conclusion. He does not engage any of them.
  The AI paradox: More automation, more humans, more work | Dan Shipper — read next: Tomasz Tunguz's recent essays on AI pricing; the cloud-pricing history (AWS's evolution from flat to consumption); Bessemer State of the Cloud reports on agent-driven pricing changes; OpenRouter / LLM-aggregator economics
• incompleteShipper's 'CEO must be personally AI-pilled' claim sits uncomfortably with his 'super-agent per company maintained by a forward-deployed engineer' claim. If the FDE is the load-bearing role and the per-company agent is the substrate, the CEO's personal model fluency is arguably the wrong variable to optimize — the firm needs FDE talent supply and an org design that protects FDE attention from the C-suite. The conversation never reconciles the personal-fluency prescription with the structural FDE prescription.
  The AI paradox: More automation, more humans, more work | Dan Shipper — read next: Karl Weick on 'sense-making' in organizations; recent CIO/CTO surveys on AI organizational placement (Gartner, MIT Sloan); the literature on 'two-pizza team' analogues for AI deployment
• incompleteNo engagement with worker-attention costs of the prescription. 'Ride the models' for every new release, 'try Codex in your off-hours if your employer blocks it', 'every agent needs a human gardener', 'inbox-zero for 10 straight days via Codex monologue' — collectively this is a maximally attentive lifestyle marketed as liberation. Shipper notes he 'works way more' and frames it as paradox-evidence, not as cost. For a senior engineering leader thinking about sustainable organizational design, the elision of attentional and psychological cost is significant.
  The AI paradox: More automation, more humans, more work | Dan Shipper — read next: The 'AI psychological costs' extraction in this library (extract-psychological-costs-of-ai-*); Cal Newport on attention residue and deep work; recent labour-economics work on AI-driven work intensification (LSE, Stanford); union/works-council positions on AI workload
• illogicalThere is internal tension between (a) 'CLIs are over, GUIs win' and (b) 'agents using SaaS via CLI is how SaaS survives'. If the user's primary surface is Codex/Co-work GUI and the agent talks to SaaS over CLI, then CLIs are precisely what is preserved — they are the agent-readable API layer, not the user surface. Shipper conflates the user-surface CLI claim with the agent-readable-API CLI claim. The two are different and have opposite trajectories: the first dies, the second flourishes. The conversation does not separate them.
  The AI paradox: More automation, more humans, more work | Dan Shipper
• incompleteThe four-question framework is presented without evidence of its predictive validity. It is asserted as useful but not tested against historical cases beyond the selected examples.
  Anette Mellbye's Post — read next: Compare with established frameworks for competitive moats (e.g., Hamilton Helmer's 7 Powers, or Christensen's disruption theory) to evaluate whether the four questions add genuine diagnostic power.
• incompleteThe post does not address the possibility that wrappers can deliberately evolve into infrastructure — the transition path is left unexplored. The binary framing (wrapper vs infrastructure) may be too rigid.
  Anette Mellbye's Post — read next: Look for case studies of companies that started as wrappers and successfully built infrastructure moats over time.
• uninformedThe Figma example conflates stock-price reaction with actual strategic vulnerability. A 7% drop on a competitor announcement is not evidence that Figma is a wrapper; it may simply reflect short-term market uncertainty.
  Anette Mellbye's Post — read next: Examine Figma's actual switching costs, network effects, and design-system integrations to make an independent assessment.
• incompleteThe concept of 'unlearning' is introduced as the strongest moat but is not analyzed for its ethical implications — is it desirable for vendors to engineer customer dependency through capability atrophy?
  Anette Mellbye's Post — read next: Consider the ethics of vendor lock-in through deliberate or incidental deskilling of customer organizations.
• incompleteThe 'rethinking' is asserted rather than performed. The article never enumerates the prior harness assumptions being overturned (e.g., DAG-based orchestration, deterministic tool dispatch, code-defined skills, developer-mediated change) nor articulates the new principles replacing them beyond 'skills written in English.' For a piece titled 'Rethinking the Agent Harness,' the actual rethink is one anecdote and one neologism.
  This Week in AI: Rethinking the Agent Harness — read next: Berryman & Ziegler, 'Prompt Engineering for LLMs' (the cited O'Reilly book); Anthropic's own Claude Code design docs; the Stanford paper at arXiv:2603.28052; Birgitta Böckeler's 'harness engineering' piece for an attempt to actually decompose the harness layer.
• incompleteSingle-case generalization. The unity ('build your own harness') rests almost entirely on one consulting client where it 'worked perfectly.' No failure modes, no boundary conditions, no comparison to cases where a bespoke app or a wrapped product would still be the right choice.
  This Week in AI: Rethinking the Agent Harness — read next: Post-mortems of agent deployments at scale; the Cognition/Devin retrospectives; harness-engineering writeups from teams shipping to production rather than consultants.
• incompleteThe relationship between the three sections is unargued. Mythos, the compute buildout, and the harness thesis are juxtaposed without the article noticing that they imply different theories of where AI value is moving — model layer (compute), capability frontier (Mythos), or harness layer (Berryman). The implicit reconciliation would be the most interesting move and isn't made.
  This Week in AI: Rethinking the Agent Harness — read next: Articles framing 'value migration in the AI stack' explicitly; investor letters or analyst notes that try to resolve which layer captures economic returns.
• incompleteThe 'open agent protocol' is named without being specified. No design sketch, no examples of what an environment-supplied skill looks like, no comparison to existing proposals (MCP, A2A, agent-to-agent protocols). The reader is left with a direction but no testable proposal.
  This Week in AI: Rethinking the Agent Harness — read next: Anthropic's Model Context Protocol spec; agent interoperability proposals from Google, OpenAI, and the LangChain ecosystem; the future-cast section in the next Berryman appearance.
• uninformedSchneier's challenge to Mythos's uniqueness is mentioned and then immediately set aside ('either way, it's a problem that's coming'). The article does not engage with the substantive question of whether the policy response is calibrated to actual differential capability or to perceived capability — a question whose answer matters for whether FDA-style review is wise.
  This Week in AI: Rethinking the Agent Harness — read next: Schneier's full post on Mythos; CAISI's framing; counter-arguments from researchers who replicated Mythos-like findings on cheaper public models.
• illogicalMild equivocation on 'harness.' Claude Code (a specific product), 'the agent harness' (a layer), and Berryman's bespoke consulting build (a specific instance) are used interchangeably. A reader could leave thinking 'use Claude Code' and 'build your own harness' are the same recommendation, when the article's argument actually requires the latter and only points at the former as an example.
  This Week in AI: Rethinking the Agent Harness — read next: Explicit harness taxonomy work — what distinguishes a product, a framework, and a bespoke harness — e.g., Böckeler's 'harness engineering' piece.
• uninformedThe reporting draws entirely on four named individuals inside Anthropic (a platform-org engineering head, one high-profile external contractor turned employee, one cross-functional engineer, one applied-AI/sales-engineering role) with no comparison to Anthropic teams operating under tighter constraints, no former-employee or outside-critical perspective, and no acknowledgment that access journalism inside the very lab that sells the tools being praised may select for best-case, showcase-ready stories.
  How building software is changing at Anthropic — read next: Look for outside-in or critical accounts of Anthropic engineering culture (former-employee retrospectives, competitor comparisons, or the promised follow-up piece comparing Anthropic and OpenAI) to check whether practices like the 11-day Bun rewrite are typical internally or a cherry-picked outlier.
• incompleteThe '60% sufficient by token spend' figure conflates volume with value: 60% of token spend is not 60% of business value, and the hardest 40% may be exactly where frontier-model quality matters most, so the savings story may understate the risk concentrated in high-stakes tasks.
  The Pulse: a new trend, smart model routing — read next: Distribution of task criticality and the marginal value of frontier models on the hardest tasks; portfolio thinking about where to spend the expensive tokens rather than average-cost reasoning.
• incompleteNo base rate or comparison to non-LLM SAST/DAST. The post claims Mythos produces 'noticeably higher quality' triage output and that the harness produces 'meaningful coverage', but provides no quantitative baseline against either prior frontier models or traditional static analysis. The reader has to take Cloudflare's qualitative judgment on faith.
  Project Glasswing: what Mythos showed us — read next: Read the Anthropic harness paper (planner/generator/evaluator) and any forthcoming Mythos technical report for quantified eval data; cross-reference with industry SAST benchmarks (e.g. OWASP Benchmark) to triangulate.
• incompleteThe 'context anxiety / compaction discards earlier findings' claim is offered as a one-line motivation for the harness but is the most theoretically interesting failure mode in the post — and the one that connects most directly to the user's harness-engineering reading thread. Bourzikas leaves the mechanism opaque (how often does compaction discard a real finding? does Mythos behave differently from general frontier models on this dimension?).
  Project Glasswing: what Mythos showed us — read next: Re-read the Anthropic harness paper's 'context anxiety' discussion; pair with Böckeler's variety-reduction framing and the smallcode failure-mode catalog; consider an extraction comparing the three on a single axis: 'what is the model's relationship to its own context, and what does the harness do about it?'
• incompleteNo eval methodology to verify that any recommended prompt actually works for the reader's own task. The single near-quantified claim ('nearly eliminated fabricated status reports') is unquantified, drawn from Anthropic's own testing, with no reproducible benchmark, dataset, baseline, or numbers — so a rigorous adopter cannot confirm which system-prompt blocks earn their place.
  Prompting Claude Fable 5 — read next: Pair with an evals discipline (e.g. extract-anthropic-harness-design-long-running-application-development, which uses graded evaluators); build an A/B eval harness that measures each system-prompt block's marginal effect before adopting it wholesale.
• incompleteThe document is undated. It is thoroughly version-specific (Fable 5 vs Opus 4.8, effort tiers, adaptive/summarized-only thinking, the `refusal` stop reason, safety-classifier domains) yet carries no published or last-updated date, so its claims will drift silently as the model and platform update.
  Prompting Claude Fable 5 — read next: Cross-check every version-specific claim against the platform changelog and the 'Introducing Claude Fable 5 and Mythos 5' page at time of use; re-verify before betting a migration on any stated default or limit.
• incompleteThe behavioral-improvement claims (bug-finding recall 'noticeably higher', vision accuracy 'substantially higher', single-pass implementations of multi-day systems, more dependable subagent dispatch) are all qualitative, with no benchmark numbers, task definitions, or independent verification.
  Prompting Claude Fable 5 — read next: Seek third-party or benchmark evidence for the specific claimed gains before relying on them; treat the improvement list as vendor signal, not measurement.
• incompleteNo guidance on interaction effects among the many recommended system-prompt blocks (brevity, anti-over-engineering, anti-overplanning, checkpoint, autonomy, readability, progress-audit, memory). The doc never says whether they conflict, how much instruction budget they consume together, or which takes precedence — awkward given its own advice to prefer brief high-level instructions over enumeration.
  Prompting Claude Fable 5 — read next: Consult context-engineering / progressive-disclosure material on instruction budgets; assemble and test the composed system prompt as a whole rather than validating each block in isolation.
• incompleteEnglish- and software-only. Every example prompt is English and targets agentic/coding/enterprise-document work; there is no guidance for non-English prompting or for non-software domains, even though the guide claims broad capability gains.
  Prompting Claude Fable 5 — read next: Look to practitioner reports on multilingual and domain-specific steering; do not assume the English software-agent prompts transfer unchanged.
• uninformedNo stated boundary for when 'steer with a brief instruction' stops working and explicit enumeration becomes necessary. The doc asserts brevity suffices, yet its own recommended blocks are long, multi-clause instructions — leaving the reader without a rule for where high-level steering degrades.
  Prompting Claude Fable 5 — read next: Use eval-driven tuning to find the point where high-level steering fails and enumeration is required for a given behavior and effort level.
• uninformedThis is Lenny's secondhand, seven-bullet summary of a podcast interview whose full content is already extracted elsewhere in this corpus (extract-catherine-wu-claude-code-anthropic, 19+ propositions). Points 1, 2, 3, and 5 here restate claims already present in that primary extraction; points 4, 6, and 7 do not appear among that extraction's top propositions. It is unclear whether that reflects genuinely new material from the full conversation or simply a difference in what Lenny chose to highlight versus what the original extraction's author prioritized.
  Lenny Rachitsky's Post — read next: See extract-catherine-wu-claude-code-anthropic for the fuller primary-source extraction this post summarizes.
• incompletePoint 6 (abandoning Notion, Linear, and Figma in favor of custom Claude-Code-built tools plus Cowork and Slack) is presented as a pure productivity win, with no discussion of the switching costs, the maintenance burden of many bespoke internal tools built by non-engineers, or what is lost specifically in design handoff, accessibility review, or historical design-rationale tracking without a dedicated design tool like Figma.
  Lenny Rachitsky's Post
• incompleteThe interview is a podcast transcript — the dialogue form allows Mounk to push back but not to synthesize. Several threads are opened and not closed: the precise mechanism of the alignment tax; whether Chinese political safety and alignment safety are actually converging or just using similar words; what 'frontier model' means precisely for open-source prohibition purposes.
  Sebastian Mallaby on AI Safety and the Race for Superintelligence — read next: Mallaby's book 'The Infinity Machine' on DeepMind presumably develops these arguments more carefully
• incompleteThe headline '87% benchmark with 4B-active model' is the entire credibility hook and is completely unspecified in the body. No benchmark name (SWE-Bench? Aider polyglot? HumanEval? a custom suite?), no subset, no scoring methodology, no comparison baseline (what does a frontier model score on this same eval? what does the same 4B model score without SmallCode?), no link to results. For a rigorous adopter this is the single most disqualifying gap.
  GitHub - Doorman11991/smallcode: AI coding agent optimized for small LLMs. 87% benchmark with 4B-active model. — read next: Check the GitHub repo itself for an evals/ or results/ directory; check the project's `/eval` command output; check whether any third party has reproduced. Compare against published SWE-Bench / Aider / HumanEval+ leaderboards for similar-sized models. Look for the actual model named in the example (gemma-4-e4b) and find its baseline scores.
• incompleteNo comparison to other small-model-aware agentic coding tools — Aider (with local models), Cline + Ollama, Continue, OpenHands with local backends, Roo. The only named comparator is OpenCode, which is set up as a strawman ('assumes frontier models').
  GitHub - Doorman11991/smallcode: AI coding agent optimized for small LLMs. 87% benchmark with 4B-active model. — read next: Read Aider's local-model documentation and benchmark notes (Paul Gauthier publishes Aider polyglot scores for many models). Compare with Cline's local-model guidance and OpenHands' SWE-Bench results with open models.
• incompleteOne-author ecosystem risk: SmallCode depends on BoneScript, MarrowScript, and budget-aware-mcp — all by the same GitHub user. If the author stops maintaining, four projects rot together. This single-maintainer concentration is not flagged anywhere.
  GitHub - Doorman11991/smallcode: AI coding agent optimized for small LLMs. 87% benchmark with 4B-active model. — read next: Check commit history and contributor counts on all four repos; check npm download stats for smallcode and budget-aware-mcp; check whether MarrowScript / BoneScript have any external adopters.
• misinformedThe escalation target list cites 'Claude Sonnet 4.5 / 4.6, Haiku 4.5' and 'GPT-5.4 Mini / Nano' and 'DeepSeek V4 / V4 Pro / V4 Flash'. As of the document's apparent date, these specific named version numbers may be aspirational, outdated, or fabricated. The presence of confidently-named future/non-existent model versions weakens credibility on other un-checkable claims.
  GitHub - Doorman11991/smallcode: AI coding agent optimized for small LLMs. 87% benchmark with 4B-active model. — read next: Cross-check the named model versions against vendor product pages; if they are not real, treat the rest of the README's confident numbers (87%, '8-15 → 1-2 tool calls', '1400+ lines from 50 lines') with proportional skepticism.
• illogicalThe marketing claim ('87% with 4B-active model') and the body text ('7B-20B local models') are inconsistent. The title advertises a 4B-active model; the body describes the project as targeting 7B-20B. If 4B-active means MoE active params with a larger total, both can be true — but the README never reconciles them, leaving the reader to guess.
  GitHub - Doorman11991/smallcode: AI coding agent optimized for small LLMs. 87% benchmark with 4B-active model. — read next: Identify the actual model used to produce the headline number; if it is MoE (e.g. gemma-4-e4b with ~4B active), check whether 7B-20B framing in the body is meant as total-parameter range, active-parameter range, or both — the project's positioning depends on which.
• 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?
• incompleteThe cybernetic / control-theory framing latent in the design (variety reduction via BoneScript topologies, feedback via early-stop detection, model profiles as adaptive control) is never made explicit. Connecting this project to the broader harness-engineering conversation (Anthropic's effective harness paper, Böckeler's framework) would let it argue from theory rather than just engineering instinct.
  GitHub - Doorman11991/smallcode: AI coding agent optimized for small LLMs. 87% benchmark with 4B-active model. — read next: Read SmallCode against Böckeler's 'Harness engineering for coding agent users' (in this batch) — map SmallCode's components to her feedforward/feedback and computational/inferential axes. Read against the Anthropic harness-design materials the user is also tracking.
• illogicalNo method is given for telling, after a model upgrade, which specific harness component has actually become obsolete versus still load-bearing. The essay asserts pruning as general practice ('yesterday's necessary workaround may be tomorrow's dead weight'), yet its own examples show inconsistent pruning in the wild — Claude Code and Codex still ship 'plan mode' even though Amp removed its equivalent — without explaining why the same capability threshold would be crossed for one product's harness and not another's.
  Stop Overengineering Your Agent Harness — read next: Read practitioner accounts of harness regression-testing across model versions to see what evidence teams actually use to decide a component is safe to remove.
• incompleteThe Maven Assistant case study — the essay's single detailed low-complexity example — describes an already-live consumer health product with meaningful compliance stakes (self-harm handoffs, withheld high-cost benefits questions). The essay never shows a genuinely minimal internal/low-stakes agent receiving the 'keep it small' advice, leaving open whether even Maven's 'moderate action complexity' harness (routing, bounded tools, guardrails, handoffs) is itself already more than many builders need.
  Stop Overengineering Your Agent Harness — read next: Read case studies of minimal single-tool, single-turn internal agents to test whether even Maven's harness is over-built for lower-stakes use cases.
• incompleteThe essay names but doesn't explain the skew whereby public harness-engineering discourse is dominated by coding/personal-agent problems even though support, sales, and enterprise agents are described as the majority of what builders actually build — leaving unaddressed whether this reflects genuine attention bias, differing incentives to publish, or something else.
  Stop Overengineering Your Agent Harness — read next: Read industry-adoption surveys on where AI agents are actually deployed (support/sales/enterprise vs. coding) to check whether the discourse mismatch tracks a real minority-attention bias.
• unasked questionNo discussion of whether other frontier models (from Google, OpenAI, xAI) have similar capabilities — the narrative is anchored entirely on Anthropic/Mythos, suggesting the policy shift may be broader than one model.
  The Trump administration's AI doomer moment — read next: Comparative assessments of frontier model capabilities across labs; government red-team evaluations.
• implicit premiseThe article assumes the pre-release review mechanism will function effectively but does not examine the Commerce Department's actual capacity to evaluate frontier models — a critical institutional capacity question.
  The Trump administration's AI doomer moment — read next: NIST/Commerce Department AI evaluation capabilities; UK AISI's experience with model evaluation.