Prompting as Communication
Getting good AI output as a communication and attention problem — clarity of intent and noticing what matters beat syntactic prompt tricks.
Also known as: prompting, prompting skill, prompt engineering, knowing what you want, Zinsser's question, vague prompt / vague result, attention / noticing, guidance, technique, learn to prompt / prompt to learn
How authors use it
Oldest first (extraction date when no publication date is known).
| Author | Their term | Their meaning |
|---|---|---|
| Philosophy Eats AI: What Leaders Should Know MIT Sloan Management Review · 2025-05-14 | learn to prompt / prompt to learn | A reflexive cycle in which the way humans learn to prompt models informs how those prompts then train (or fine-tune the use of) the models — so prompting becomes a co-evolutionary learning practice for human and machine. |
| The Best Prompting Advice Came From a Writing Teacher Ernie Svenson · 2026-04-21 | prompting | The act of instructing an AI tool to produce a specific output — treated by Svenson as a communication act that depends primarily on the user's clarity of intent, not on syntactic technique |
| The Best Prompting Advice Came From a Writing Teacher Ernie Svenson · 2026-04-21 | knowing what you want | Having thought through purpose, audience, tone, and success criteria — at least roughly — before issuing a prompt. Does not require a formal outline, but does require honest internal articulation. |
| The Best Prompting Advice Came From a Writing Teacher Ernie Svenson · 2026-04-21 | vague prompt / vague result | A prompt that fails to specify purpose, audience, tone, or success criteria — and the correspondingly unfocused output the AI returns. The pairing is treated as causal: vague input deterministically produces vague output. |
| The Best Prompting Advice Came From a Writing Teacher Ernie Svenson · 2026-04-21 | Zinsser's question | 'What am I trying to say?' — the one-sentence test Svenson borrows from On Writing Well and prescribes as a 10-second pause before prompting |
| The Best Prompting Advice Came From a Writing Teacher Ernie Svenson · 2026-04-21 | technique | Prompt-engineering tricks — formats, structures, special instructions — which Svenson concedes have their place but explicitly subordinates to clarity of intent |
| AI isn't a tool anymore. It's a collaborator. Ernie Svenson · 2026-04-28 | guidance | The skill of explaining what you want clearly, giving examples, correcting iteratively, and sustaining dialogue — equivalent to good management |
| When an Executive Asks You an Unexpected Question Melody Wilding · 2026-05-05 | Guidance | An executive's need for help forming a mental model of a situation — the question 'How should I be thinking about this?' — where they want your interpretation, not raw data |
| The real skill behind good AI prompts is older than computers Ernie Svenson · 2026-06-02 | attention / noticing | Sustained, self-directed conscious observation of the task, of oneself, and of what the AI just produced — deliberately directing your focus rather than having it captured. Ernie treats 'noticing' as its active exercise. |
| The real skill behind good AI prompts is older than computers Ernie Svenson · 2026-06-02 | prompting skill | Templates, prompt libraries, 'collecting the most prompts' — explicitly deflated as NOT where the value lives |
| How Anthropic Builds And How Engineering Will Change Soon | Thariq Shihipar Ryan Peterman · 2026-09-07 | Prompting (as durable skill) | Not the literal text typed into a chat box, but the accumulated context — skills built, data supplied, harness configured — that shapes model behavior; the durable underlying skill is learning how to learn a new model quickly, not memorizing any one model's quirks. |
Documents (19)
- LLMs Reward Expertise Sean Goedecke · 2026-09-12 source ↗ Reader 🖥️
The single most important variable in getting valuable output from an LLM is the user's pre-existing domain expertise — not prompting technique — because expertise is what lets a person signal sophistication to the model, evaluate and redirect its output, and supply the human judgment the model itself cannot originate, which means the human, not the model, is increasingly the bottleneck. - The habit that makes AI worth using Ernie Svenson · 2026-09-11 Reader 🖥️
The value AI adds to information-checking is entirely gated by a human habit — noticing when a claim is surprising or consequential and immediately submitting it to an AI chatbot for source-backed validation before believing or repeating it — because AI has made verification nearly effortless without making people any more inclined to do it. - The AI agent that shows up before you ask Ernie Svenson · 2026-09-08 Reader 🖥️
An AI agent that lives inside the team's existing chat tool (Slack/Teams) and proactively checks in, follows up, and does unprompted work is a qualitatively different and more valuable kind of AI than a chatbot you have to remember to use, because it supplies the initiative and follow-through that busy, distracted humans otherwise fail to supply themselves. - How Anthropic Builds And How Engineering Will Change Soon | Thariq Shihipar Ryan Peterman · 2026-09-07 Reader 🖥️
Inside Anthropic, engineering is already organized around treating Claude as a thought partner wrapped in an increasingly sophisticated harness/loop rather than around hand-writing code, and this shift will diffuse into the rest of the industry — leaving the durable human value in judgment, taste, verification design, and self-directed visibility rather than in code production itself. - How to turn your AI into a world-class designer Anshu Chimala · 2026-09-01 Reader 🖥️
AI models default to bland, repetitive ('design-by-committee') design because their training rewards the statistically safest choice at every token, so producing distinctive AI-generated design requires deliberately counteracting that bias at each stage of a Discover/Define/Deliver process — injecting externally-sourced variety and ambition, judging output with a fresh-context critic instead of the generating agent, enriching it with image/video generation, and then subtracting rather than adding to reach a polished result. - The Problem Is Prompt Debt Drew Breunig · 2026-07-30 source ↗ Reader 🖥️
Because natural language is an imprecise specification language for a probabilistic model, hand-tuning prompts to define durable system behavior accumulates a distinct 'prompt debt' — slowing iteration, becoming illegible to teams, and locking the application to one model's idiosyncrasies — which can only be paid down by specifying behavior with measurable evals rather than prose and letting automated search (e.g. DSPy, GEPA) generate and optimize the prompt itself. - 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. - Software Teaming in the Age of AI with James Herr and Woody Zuill Mob Mentality Show · 2026-07-07 Reader 🖥️
As AI takes over more of the actual typing, ensemble/mob programming becomes MORE important, not less — because code was never the real bottleneck (queueing on requirements and stakeholder availability always was, and AI's speed just exposes that more starkly), and because AI removes typing-speed as the reason non-coders couldn't stay in the room. The core discipline mob programming already trains — communicating high-level intent instead of dictating each low-level step — turns out to be the same skill effective AI-agent direction requires, so learning to team well and learning to direct agents well are converging into one discipline. But this potential is bounded by real, concretely observed LLM reliability limits (non-determinism, context forgetting, and test-hardcoding instead of genuine rule implementation) that demand deliberate engineering countermeasures — deterministic code generators, unit tests reframed as guardrails rather than TDD-as-design, and small on-demand skills files instead of one long instructions file — not blind trust in AI capability claims. - 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. - How to ask for help from people who don't know you pradyuprasad.com · 2026-06-30 Reader 🖥️
Asking a stranger for help is a learnable communication skill, not charisma or luck, and it succeeds by modeling the responder's mind and lowering their cost, risk, and obligation — making yourself worth helping and making it effortless (and safe) to say yes or no — rather than by centering your own need. - The real skill behind good AI prompts is older than computers Ernie Svenson · 2026-06-02 Reader 🖥️
Good AI output depends not on prompting technique but on attention — the pre-digital, self-cultivated skill of noticing what matters in the task and in the model's output — which cannot be taught, only chosen. - Stop Just Writing Code. Start Leading Agents: The Staff Engineer’s AI Edge Emad Mokhtar · 2026-05-07 source ↗ Reader 🖥️
The Staff Engineer skillset of defining outcomes, reducing ambiguity, creating guardrails, and reviewing work — originally built for leading human teams — transfers directly to leading AI coding agents, and is becoming more valuable, not less, as agents take over more implementation. - When an Executive Asks You an Unexpected Question Melody Wilding · 2026-05-05 source ↗ Reader 🖥️
When an executive asks you an unexpected question, you should diagnose which of three underlying needs — reassurance, guidance, or action — is driving the question, and respond to that need rather than providing exhaustive factual answers. - AI isn't a tool anymore. It's a collaborator. Ernie Svenson · 2026-04-28 source ↗ Reader 🖥️
Effective use of AI now requires the same human skill of clear guidance and dialogue that effective delegation to human employees always has, and people who struggle with the latter will struggle with the former. - The Best Prompting Advice Came From a Writing Teacher Ernie Svenson · 2026-04-21 Reader 🖥️
The biggest barrier to getting useful output from AI is not prompting technique but the same problem William Zinsser identified in bad writing — people try to communicate before they have figured out what they actually want to say; therefore the single most leveraged improvement most users can make is to pause and articulate their intent in one clear sentence before they prompt. - Charlie Hills 🦩's Post Charlie Hills 🦩 · 2026-04-16 source ↗ Reader 🖥️
Effective use of Claude Code requires deliberate setup, disciplined workflow habits, context management, precise prompting, and exploitation of power features — and learning these on day one would save weeks of friction. - Philosophy Eats AI: What Leaders Should Know MIT Sloan Management Review · 2025-05-14 source ↗ Reader 🖥️
Because generative AI is built from and operates through philosophical constructs (purposes, categories, knowledge), the executives who win with AI will be those who deliberately map and reconcile their organization's teleology, ontology, and epistemology — not those who optimize ethics, metrics, or models in isolation. - How Coders Can Survive—and Thrive—in a ChatGPT World IEEE Spectrum · 2023-07-03 source ↗ Reader 🖥️
Programmers remain relevant in an LLM-centered coding world not by out-generating AI at writing code, but by doubling down on what AI does not supply — problem-solving, software-engineering fundamentals, structural judgment, precise communication of intent, and critical scrutiny of AI output — while treating AI tools themselves as a fast-moving, interchangeable part of the workflow rather than a fixed skill to master once. - How to write clearly Edward T. Thompson · 1979 Reader 🖥️
Writing clearly is a learnable discipline rather than a gift, and it rests on first thinking clearly: because muddy prose is really muddy thinking, the writer who does the hard work of settling and ordering what to say before writing — then prunes, simplifies, and calibrates everything in the reader's service — can make almost any idea understood with the least possible effort from the reader.
Propositions touching this concept (88)
By publication month, oldest first (extraction month when no publication date is known).
2023-07
- explicitEffective prompting for code generation means decomposing a task into manageable chunks and asking for one function or step at a time, because asking the model to do too much at once produces worse results; the ideal mental model for the assistant is 'a smart intern who knows a lot about a subject but isn't that experienced.'
- explicitPrecision and clarity about what you want, with explicit follow-up, drives the quality of AI-assisted coding output more than any other single factor in prompting.
2024-03
- implicitBecause categories like Hallucinated Object and Wrong Attribute are not primarily caused by prompt underspecification, no amount of prompt engineering alone will eliminate them — some bug patterns are an intrinsic cost of the generative mechanism itself, not a solvable input problem.
2024-11
- explicitTreating AI as a 'person' (while explicitly not believing it is sentient) and assigning it a specific persona is an effective prompting heuristic because it helps guide and tailor the AI's responses to specific needs.
2025-04
- explicitAs AI absorbs the mechanics of coding, the skills that remain differentiating shift toward systems engineering, high-level architecture, data engineering and governance, and precise, persistent prompt engineering (including teaching junior engineers to interrogate rather than accept AI outputs at face value).
2025-09
- explicitAI adoption has not, so far, meaningfully changed developers' psychological relationship to their work — no measured shift in sense of meaning, need for cognition, or existential connection to colleagues, and no change in the perceived importance of most job skills except prompt engineering and (surprisingly) syntax memorization — with the exceptions that higher AI adoption is associated with greater authentic pride (via more time on valued work) and carries a small (21%) risk of reduced psychological ownership of one's code.
2025-12
- explicitThe developer role is shifting toward architecture, system design, prompt engineering, and quality judgment, with successful developers effectively delegating, reviewing, and guiding multiple concurrent AI agents — but agentic IDEs exist to serve developers, not replace them, and predictions of near-term engineering-team obsolescence have not materialized and will not.
- explicitdevelopedThe author's three-person team achieved 2–3x coding-agent throughput only after spending eight weeks deliberately redesigning how they collaborated around context management — not from better prompting alone.
- explicitIf results plateau despite prompt effort, that plateau signals diminishing returns on prompt engineering specifically, and the better next investment is feedback loops and guardrails rather than further prompt tuning.
2026-01
- explicitGetting good at testing and test infrastructure becomes more important, not less, because an agent needs fast feedback signals (compilation, static analysis, automated tests) to be effective and less prone to hallucination — and because the author personally cannot trust AI-generated code without unit/integration/end-to-end tests, while finding AI itself unreliable at writing good tests without targeted prompting.
- explicitMobile/remote coding workflows (prompting, validating, deploying from a phone or browser) risk eroding developers' remaining work-life boundaries, the same way mobile Slack did for communication — extending 'always reachable' expectations into code changes themselves, with no corresponding change in compensation norms for salaried engineers.
2026-02
- explicitIf codebase design patterns can be reliably harnessed, these topologies — not natural language prompting itself — may become the real abstraction layer for AI-assisted development, contrary to the common assumption that natural language is the new universal interface.
- explicitcontestedTDD is the strongest form of prompt engineering and a key tool for driving LLMs effectively.
- explicit⚡ disputed & corroboratedTDD is the strongest form of prompt engineering because it prevents agents from writing tests that verify broken behavior
2026-03
- explicitWhen AI-assisted development quality depends on who is prompting, senior engineers become bottlenecks — not because they write the code, but because they alone know what to ask the AI for — and this is a systems problem requiring a systems solution, not a skills problem that training, documentation, or more pairing can fix, because those approaches are slow and do not scale.
- explicitdevelopedThis approach is scale-calibrated, not universal: the signal that a team needs it is whether AI-output quality visibly varies by who is prompting, or whether generation/review work routes through a handful of people who know how to prompt effectively; small teams (around five people) may not need it, while teams of around fifteen almost certainly do, and the right adoption sequence is one instruction first (usually generation or review), with further instructions following adoption rather than preceding it.
- explicitcontestedAs models absorb more harness-level capabilities natively (planning, self-verification, long-horizon coherence), harness engineering will matter less in the sense of patching deficiencies, but will remain valuable for the same reason prompt engineering still is: well-configured environments, tools, state, and verification loops make any model more efficient regardless of its base intelligence.
2026-04
- explicitcorroboratedAI has shifted from being a command-response tool to being a collaborator that requires dialogue and guidance.
- explicitThe critical skill for AI is not prompt engineering or tool selection but simply explaining clearly what you want and why.
- implicitcorroboratedThe ability to take another's perspective is a prerequisite for effective guidance of both humans and AI.
- implicitThere is a maturity progression from ad-hoc prompting to structured environment configuration.
- explicitdevelopedWith each new model generation, the team removes prompting interventions and product crutches that are no longer needed.
- explicitMost people lose time due to poor workflow discipline, not poor prompting.
- explicitPrompting alone is not the unlock for effective AI coding agent use; structure is.
- explicitThe dominant failure mode in AI prompting is not technical but cognitive — users do not know what they want before they ask.
- explicitZinsser's diagnosis of bad writing — that it is a thinking problem, not a craft problem — applies directly to bad prompting.
- explicitcorroboratedKnowing what you want requires at least rough internal answers to four questions: purpose, audience, tone, and success criteria.
- explicitBeing able to state your intent in one clear sentence is a sufficient readiness test for prompting.
- explicitcorroboratedClarity-of-intent yields larger improvements in output quality than any specific prompting technique.
- implicitPrompting is fundamentally a writing act — a communication problem governed by the same rules of clarity that govern good prose.
- implicitdevelopedThe act of articulating intent before prompting is itself a form of thinking — writing-to-think rather than writing-to-output.
- explicitGitHub stopped updating its own status page, reportedly because of how poor its true availability had become, prompting a third party to build a replacement tracker.
- explicitAI use is on the right track when it is congruent with the collaborative nature of product development — co-design, co-prompting, evolving contexts, and shared understanding that compounds.
2026-05
- explicitA commonplace book (copies of external quotes/passages only, no personal thoughts) deepens attention to the surrounding world by prompting closer noticing of what one reads, sees, or overhears.
- explicitA single experiment run is not a valid test of whether an AI-era practice works, because tool versions, prompting techniques, and even small interaction details (e.g. dictation versus typing prompts) change fast enough that 'we tried this and it didn't work' is an unreliable conclusion — experiments must be repeated and tuned, and the resulting learning should itself be treated as ephemeral.
- implicit⚡ disputed & corroboratedProactive AI that acts without explicit prompting is desirable.
- explicitGood prompting for requirement extraction means naming the domains/areas of interest and leaving room for open-ended answers, rather than over-specifying the desired outcome or issuing vague commands like 'just make it better.'
- explicitcontestedBenchmarks systematically overstate AI autonomy because they measure performance against pre-articulated problems; the prompting/framing work itself is what humans uniquely add and it is uncounted.
- explicitImplementation is only one part of software engineering — understanding the problem, trade-offs, system design, stakeholder communication, quality review, risk management, documentation, and maintenance are the rest — so as AI absorbs more implementation, direction (not prompting skill per se) becomes the engineering advantage.
- explicitA structured pre-prompt that forces reflection on what one is actually trying to achieve, what one knows versus assumes, and what a sharp answer would look like ('meta-prompting') measurably improves the quality of the eventual output, by making AI interrogate the user's own thinking before executing the task.
- explicitcorroboratedBefore coding (or prompting), teams should reach a shared design concept — agents amplify whatever direction you give them
- explicitAll executive questions stem from one of exactly three underlying needs: reassurance, guidance, or action
2026-06
- explicitDifferent execution modes (project generation, feature generation, bug fixing, documentation writing, data engineering) require structurally different prompting strategies — notably, bug fixing should shift from 'symptom prompting' to 'evidence prompting,' require a failing reproduction test before any fix is attempted, and must not let the agent 'clean up' unrelated code alongside the fix.
- explicitOrchestrating separate Claude subagents with their own context windows and focused, isolated goals is what combats agentic laziness, self-preferential bias, and goal drift — not better prompting within one context.
- explicitState management and concurrency are where AI-generated code most consistently fails, and the correct fix is structural — a runtime that manages state, cache invalidation, and concurrency automatically — not a prompting-based fix.
- explicitMost companies claiming to build AI guardrails are actually just doing more prompting; almost no one is building real guardrails and tooling from scratch, because that is a lot of work.
- 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.
- 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.
- 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.
- explicitcorroboratedLoop engineering is replacing yourself as the person who prompts the agent — you design the system that does the prompting instead.
- explicitTwo well-placed practitioners — Peter Steinberger and Boris Cherny (head of Claude Code at Anthropic) — independently report they no longer prompt coding agents directly; they design loops that prompt the agents for them, and this convergent testimony is offered as the article's central evidence that prompting skill is being superseded as a differentiator.
- implicitThe article's opening contrarian claim ("you shouldn't be prompting coding agents anymore") is in real tension with its own closing counsel ("don't forget that prompting your agents directly is also effective... it's all about finding the right balance") — the piece asserts a strong headline position and then substantially walks it back without ever giving a rule for when a task needs direct prompting versus a designed loop.
- explicitGiving an AI good context is not a prompting skill but a noticing/attention skill.
- explicitcorroboratedAgent 'loops' (run to end of turn, restart the prompt, split a heavy spec across iterations, no supervision) are not new (the 'Ralph Wiggum loop', since ~last July) but are now easy specifically because compounding correctness lets even sloppy prompting improve each iteration.
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.
- explicitThinking Machines Lab's Tinker API produced a real-world proof point (Bridgewater fine-tuning a proprietary financial-judgment model) beating prompting-only frontier-model use on both accuracy (~85% vs. 74-78%) and cost (single-digit dollars vs. $20-90 per run for GPT/Opus 4.8).
- explicitEngineering the model's environment nests in three concentric levels: prompt engineering (the instructions) is inside context engineering (what the model sees and when), which is inside harness engineering (both plus tool orchestration, state, error recovery, verification, safety, lifecycle). The harness is not a wrapper around a prompt.
- explicitPrompting small local models re-imposes the discipline of specific, precise instructions that capable frontier models had let developers abandon.
- explicitHrag built a daily sales forecaster using Gemini and natural-language prompting (plus screenshots to troubleshoot errors) in about an hour, without writing code himself.
- implicitcorroboratedA non-technical user can reliably produce correct, usable outputs (a working sales forecaster, an accurate news summary) through natural-language prompting and screenshot-based troubleshooting alone, without a separate verification step.
- explicitdevelopedFraming generative AI as a chatbot tool that mainly needs better prompting will not materially reduce the risks of expertise erosion or homogenization.
- implicitThe guidance can be trusted and applied to the reader's own workflows because it comes 'straight from the team that built' Fable 5.
- explicitMost current AI practices (prompt engineering, agents, RAG, context engineering, vibe coding, evals) are still emergent and variable rather than stable and codified.
- explicitAI is not good at strategy unless you steer it hard on the constraints (technology, personnel and motivation, competitive/regulatory/compliance landscape, brand identity): lazy prompting yields predictable answers the competition would expect, whereas real value requires enumerating the inputs, a critical back-and-forth conversation, and a model willing to push back.
- explicitcorroboratedUse parallel subagents frequently with explicit guidance on when delegation is appropriate and asynchronous orchestrator-subagent communication, and keep long-lived subagents that retain context — this saves time and cost through cache reads and avoids bottlenecking on the slowest subagent.
- explicitAgent-assisted development should be run as an explicit, staged lifecycle in which each stage is a discrete, named skill — grill/plan, then /to-spec, then /to-tickets, then /implement (one ticket per session), then /code-review, then commit — rather than ad-hoc prompting or a single 'plan mode'; this answers the recurring user question 'what is the main flow?'.
- implicitdevelopedCodifying agent workflows into reusable, installable, versioned skills is a better unit for distributing engineering practice than ad-hoc prompting — the load-bearing premise behind shipping a versioned skills library at all.
- explicitFeeding an agent a domain model before one-shotting an application produced markedly better results than prompting requirements alone, in the author's own experiment (without a model, the agent made dubious code-structure and database-schema choices that worked but were harder to understand and performed worse); multiple retreat participants likewise reported iterating on domain models with an agent before allowing code generation, sometimes mixing text and diagrams (PlantUML, Mermaid) as agent input.
- explicitFeeding an agent an explicit domain model before generating an application yields better code structure and database performance than prompting requirements alone.
- explicitAn agent harness is the non-model software — the loop, tool execution, context management, state, and safety layer — that surrounds the LLM at runtime, distinct in scope from prompt engineering (a single call) and context engineering (what the model sees).
- explicit⚡ disputed & corroboratedHarness features expire as models improve because each component encodes an assumption about a model limitation that becomes false once the model absorbs the capability (the 'Kirby effect') — concretely: chain-of-thought prompting was absorbed into reasoning models trained via RL on CoT traces, and Amp removed its experimental 'plan mode' once models could reliably obey a single 'plan, don't edit' instruction.
- explicitDesigning agentic loops (instead of prompting) pays off only for a specific class of scaling problems and is wasteful elsewhere — like microservices, adopt the abstraction only where the scaling problem justifies its complexity.
- 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.
- implicitPrompting an LLM on unfamiliar territory is qualitatively different from prompting it on familiar ground (which feels like writing loose pseudocode) -- in the unfamiliar case the developer becomes more like a product manager or customer of 'Someone Else's Code' than a programmer, which the author treats as more than just the next rung on software's historical abstraction ladder (assembly to C to Python to prompting).
2026-08
- explicitOpt-in adoption left a meaningful share of physicians holding a license they didn't use, prompting MGB to adopt a use-it-or-lose-it policy (losing the license after three months of non-use), because the license carries a per-person monthly cost.
- explicitReplacing step-by-step prompting with one verifiable goal lets an agent inspect its own code, add and run tests, fix failures, and verify packaging, iterating until the goal is met without waiting for another human prompt after each step.
2026-09
- explicitdevelopedReviewing code with the same model/session/assumptions as the agent that wrote it reproduces the author's own blind spots; adversarial review requires structural independence (a different model, a context-isolated session, or structured adversarial prompting) modeled on GAN generator/discriminator dynamics and Zero Trust's explicit-verification and least-privilege principles.
- explicitTeams that default to parallel, individual AI-chat work (everyone prompting alone) run into coordination trouble — information overload and wasted effort — because the speed of solo AI use skips the whiteboard-style alignment step teams used to take before splitting up work, and the resulting misalignment accrues as a 'debt to the collective.'
- implicitBecause Mantis requires sandboxed reproduction as evidence rather than trusting a critic agent's textual assessment alone, Google treats raw LLM judgment about vulnerabilities as structurally insufficient on its own, not merely as something to be improved with better prompting.
- explicit'Loop engineering' means building a system that prompts Claude on your behalf instead of prompting it yourself turn by turn; at Anthropic's scale it only produces value when paired with heavy investment in skills and verification, so autonomously-landed changes can be trusted.
- explicitThe most important skill in prompting an LLM is expertise in the domain you're prompting about — not prompting technique in the abstract.
- explicitGenuine domain understanding — not the surface stylistic habits of an expert prompter — is what makes expert-level prompting reproducible; copying Tao's message style without his mathematical understanding would not reproduce his results.
- explicitdevelopedThe usefulness of domain knowledge for prompting implies that human technical expertise will remain valuable as a structural matter even as models get more capable, not merely as a transitional artifact of current model limitations.
- explicitThe objection that OpenAI's own math-discovery prompts were 'inexpert' does not refute the expertise thesis, because OpenAI's expert mathematicians checked and filtered the model's suggested discoveries before they counted as real results — expert filtering downstream can substitute for expert prompting upstream.
- explicitGenerating deterministic code instead of prompting the LLM directly, or bolting on RAG/MCP/logging to an existing system, is an improvement over raw LLM delegation but still leaves the decision logic fragmented across code, infrastructure and control flow, and does not by itself deliver full accountability.
- explicitManaging one's own attention and knowing how to evaluate information, once slowed down enough to look at it, are real, teachable skills in the age of AI — and both matter more than any prompting technique.
2026-10
- explicitFrameworks that abstract away the 'hard AI parts' (prompting, control flow, token curation) are solving the wrong problem; frameworks should instead absorb the hard non-AI parts (infrastructure, state persistence, protocol plumbing) so builders can spend their effort on the AI-hard parts.
- explicitAfter 25+ years coding, the author personally now spends more time orchestrating and prompting multiple agents than reviewing their output line-by-line, reserving manual coding for subtle problems or cases where agents get it wrong.
Tensions
Context size: should you shrink the problem to fit a small usable window (decompose / reset), or grow and trust a large window?
from: When working with AI coding agents, how should you select the model, its reasoning/effort level, and its context size for a given task?
- [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero (AI Engineer (channel); speaker: Matt Pocock (AI Hero)): Shrink: keep every task inside the ~100k smart zone; clear rather than compact; a 1M window is 'more dumb zone', good for retrieval, not coding.
- Agent Harness Engineering (Addy Osmani): Shrink: fight context rot with compaction, offloading, and skills; do not let the window fill.
- Harness design for long-running application development (Anthropic Engineering (long-running harness design)): Shrink (on weaker models): context resets with a handoff artifact beat compaction, because a fresh agent has no anxiety about approaching limits.
- GitHub - musistudio/claude-code-router: Use Claude Code as the foundation for coding infrastructure, allowing you to decide how to interact with the model while enjoying updates from Anthropic. (musistudio): Grow, but only as a per-task escalation: route requests past ~60k tokens to a dedicated long-context model rather than forcing one window to hold everything.
- Charlie Hills 🦩's Post (Charlie Hills 🦩): Manage in place: /compact and one-task-per-session when context degrades.
Assessment: The apparent 'grow / trust the big window' position for CODING largely dissolves once retrieval is separated from coding — which is exactly Pocock's move ('good for retrieval, less good for coding') and musistudio's (longContext is a routed escalation, not the coding default). No text argues you should code inside a full 1M window. The only genuine pressure toward trusting a bigger window is the vendor-forward Fable 5 / Opus 4.6 claim that coherence loss is being engineered away — but that is a moving target (convergence 5), not a stable dial, and even the harness paper only relaxed context resets AFTER measuring that the new model no longer needed them. A secondary, live sub-dispute survives: reset vs compact. Pocock, the harness paper and best-practices favor clearing/resetting to a fresh agent; Hills and Osmani lean on compaction. The reset camp has the better argument on today's models — compaction preserves the same anxious agent — but the disagreement is real and unresolved. Verdict: shrink-and-decompose is the default for coding; grow only as an explicit retrieval escalation; prefer reset over compact unless the model version has demonstrably killed context anxiety.
Effort/reasoning: does more thinking make output better, or does more reasoning make it worse (over-engineering / over-editing)?
from: When working with AI coding agents, how should you select the model, its reasoning/effort level, and its context size for a given task?
- [MODEL] Claude Code is unusable for complex engineering tasks with the Feb updates #42796 (stellaraccident (via https://github.com/anthropics/)): More thinking is better and structurally required: reducing thinking depth caused a catastrophic, measurable quality regression.
- Prompting Claude Fable 5 (Claude Platform Docs): More reasoning over-produces: higher effort yields unrequested tidying, refactoring, and over-planning that must be actively suppressed.
- Coding Models Are Doing Too Much (nrehiew.github.io): Reasoning is a double-edged sword: reasoning models over-edit MORE by default, yet respond BEST to explicit constraints and become the most faithful editors.
- Claude Code: Best practices for agentic coding (Anthropic (Claude Code best practices guide)): Middle: scale the thinking budget to difficulty via the think < think hard < ultrathink ladder.
Assessment: This looks like a head-on collision but is really the corpus resolving a category error, so I keep it as a divergence-under-adjudication rather than a live two-camp fight. The two things bundled into one 'effort' dial are separable: reasoning DEPTH (deliberation and research before acting — what stellaraccident measures as the Read:Edit ratio) versus action SCOPE (how much the model rewrites — what nrehiew measures as over-editing). They are separable but DEFAULT-COUPLED: more reasoning, unconstrained, tends to produce more scope. nrehiew is the empirical bridge — constrained reasoning models are the MOST faithful, proving depth and tight scope combine positively when you address them separately. Fable 5 already acts on this, pairing 'reduce effort' with a distinct anti-over-engineering instruction. The actionable verdict: do NOT cut reasoning depth to fix over-editing (that is stellaraccident's exact grievance and it backfires into shallow, edit-first behavior); keep the depth and add an explicit scope constraint. The failure is treating one knob as if it controls both correctness-depth and edit-scope.
Who selects the model/effort/context — a human deciding per task, or an automatic router — and who is trusted to hold the dial?
from: When working with AI coding agents, how should you select the model, its reasoning/effort level, and its context size for a given task?
- Charlie Hills 🦩's Post (Charlie Hills 🦩): Human selects: the developer manually assigns Opus to think and Sonnet to build.
- Claude Code: Best practices for agentic coding (Anthropic (Claude Code best practices guide)): Human selects: the user picks the thinking level (think/ultrathink) and configures the tools per task.
- The Pulse: a new trend, smart model routing (The Pragmatic Engineer (Gergely Orosz)): Auto-router selects — but beware who owns it: an intelligent router (or Cursor 'Auto') picks the cheapest capable model automatically.
- GitHub - musistudio/claude-code-router: Use Claude Code as the foundation for coding infrastructure, allowing you to decide how to interact with the model while enjoying updates from Anthropic. (musistudio): Semi-automatic, user-owned rules: config-driven scenario routing plus custom-router JS and subagent pinning.
- [MODEL] Claude Code is unusable for complex engineering tasks with the Feb updates #42796 (stellaraccident (via https://github.com/anthropics/)): The dial must be transparent and user-controllable: the real harm was the PROVIDER silently rationing the effort dial.
Assessment: The human-vs-auto axis is less about capability than about (a) whether task difficulty can be detected a priori and (b) who bears the principal-agent risk. No router in the corpus actually measures difficulty — musistudio routes by token-count and static scenario, and the Pragmatic Engineer's routers infer 'good enough' without a demonstrated oracle — so 'auto' today means 'static-heuristic', not 'optimal'. Automation is safe when the user owns the policy (musistudio) and dangerous when the router profits from the choice (Cursor Auto) or when the provider adjusts the dial invisibly (stellaraccident). Verdict: keep the human holding the difficulty judgment and the effort dial until routers can both measure adequacy and prove neutral incentives; automate only the mechanical dispatch, over rules you own and can audit.
Open gaps (60)
- 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').
- incompleteThe employee analogy is pushed without acknowledging where it breaks down. AI doesn't have intrinsic motivation, emotional responses, career goals, or social context — all of which shape human employee management. The skills may overlap but are not identical.AI isn't a tool anymore. It's a collaborator. — read next: Literature on human-AI teaming (e.g., Parasuraman & Riley on automation trust) would clarify where the analogy holds and where it misleads.
- incompleteThe claim that prompt engineering doesn't matter is stated as a contrast to 'guidance' but doesn't engage with what prompt engineering actually is. Much of prompt engineering IS the skill of clear explanation. The opposition may be a straw man.AI isn't a tool anymore. It's a collaborator. — read next: Consider whether 'guidance' is simply prompt engineering rebranded for a non-technical audience.
- uninformedNo acknowledgment that AI's need for human guidance may be a temporary state. As models improve, the 'collaborator' framing may itself become obsolete, replaced by more autonomous agents.AI isn't a tool anymore. It's a collaborator. — read next: Follow developments in agentic AI and autonomous task completion to test whether the guidance-skill thesis has a shelf life.
- incompleteThe piece ends with a sales pitch for the author's Inner Circle community, which undermines the analytical posture. The claim that guidance is 'just a basic human skill' sits in tension with selling a paid program to develop it.AI isn't a tool anymore. It's a collaborator. — read next: N/A — rhetorical observation.
- uninformedThe post does not address trade-offs or costs of the recommended approach -- e.g., the overhead of maintaining skills and hooks, the risk of over-engineering small projects, or when ad-hoc prompting is actually sufficient.
- misinformedThe claim that 'output tokens are literally the mechanism for reasoning' conflates text generation with all model computation. The model performs substantial reasoning in forward passes and (with extended thinking) in hidden thinking tokens. Visible output verbosity is a proxy for reasoning, not the mechanism itself.I benchmarked CC's caveman plugin against 'be brief'. The token math is wild. — read next: Research on chain-of-thought prompting vs internal model representations; literature on extended thinking / scratchpad approaches.
- incompleteNo evidence or reasoning is provided for any of the 32 claims. Every tip is stated as flat assertion. There is no explanation of WHY each practice works, what failure mode it prevents, or how the author discovered it. This makes it impossible to evaluate which tips generalize vs. which are idiosyncratic to the author's workflow.Charlie Hills 🦩's Post — read next: Look for experience reports or controlled comparisons of Claude Code workflows (e.g., with vs. without CLAUDE.md, with vs. without branching per task).
- incompleteThe social media format (LinkedIn listicle) constrains depth. Tips like 'Set a scope limit to only the files you name' and 'Replan at halfway to reset the goal' are operationally vague — a reader new to Claude Code would not know how to implement them.Charlie Hills 🦩's Post — read next: The author's own linked guides (beginner-to-advanced, design-in-code) likely expand on these compressed tips.
- uninformedEvery pattern in the catalog is presented with the author's own prescriptive worked example as its sole evidence; the catalog never cites an external case study, a controlled comparison, or independent practitioner validation for any individual pattern, despite the patterns ranging from simple (constraint-based prompting) to organizationally significant (atomic task decomposition coordinating parallel work across multiple teams).
- incompleteThe adversarial-critic prompt pattern is presented as highly effective but with only anecdotal evidence from one use case. The failure modes of this approach (model sycophancy despite hostile persona, critique that is adversarial in tone but generic in substance) are not explored.Eating My Own Dog Food: How I Used the Framework to Write the Post About the Framework — read next: Research on LLM sycophancy and the reliability of adversarial prompting for substantive critique.
- 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
- incompleteSvenson excludes the exploratory use case in which the user genuinely does not yet know what they want and is using the AI as a thinking partner to find out. This is one of the most valuable uses of LLMs — and it is precisely the case where the Zinsser test would tell you not to prompt yet, which would be bad advice.The Best Prompting Advice Came From a Writing Teacher — read next: Andy Matuschak on tools for thought; literature on writing-to-think (Zinsser himself elsewhere acknowledges this); research on using LLMs as brainstorming partners
- incompleteThe universal claim that intent-clarity dominates all technique is asserted but not measured. Different users at different skill levels likely face different bottlenecks — some are blocked by vague intent, others by context-loading, others by inability to evaluate outputs. The essay's one-size-fits-all framing under-serves users whose bottleneck is elsewhere.The Best Prompting Advice Came From a Writing Teacher — read next: Empirical studies on prompt-quality factors; segmentation of AI-user skill levels (novice/intermediate/advanced) in productivity research
- incompleteThe analogy presumes that writing-craft principles transfer cleanly to prompting because both are 'communication.' But writing is human-to-human communication with shared context and reading conventions; prompting is human-to-model communication with very different priors, failure modes, and feedback loops. The essay does not stress-test where the analogy breaks.The Best Prompting Advice Came From a Writing Teacher — read next: Cognitive science of human-AI communication; research on shared common ground in conversation (Herbert Clark); the literature on prompting as distinct from natural-language instruction
- misinformedThe TDD-as-prompt-engineering claim rests on self-selected testimonials from leading-edge LLM users; Fowler himself flags confirmation bias, and no controlled comparison against other test or specification strategies is offered.Fragments: February 18 — read next: Look for controlled studies on whether TDD improves LLM coding outcomes versus alternative feedback strategies.
- incompleteCost is essentially absent from a story framed as nearly effortless ('an hour', '20 minutes'): no mention of Gemini's subscription price for the described use cases (only the news-digest feature notes it needs 'Pro and Ultra'), nor of the time investment required to become effective at prompting and iterating.3 ways this coffee shop is growing with Gemini — read next: Compare against Google's published Gemini pricing tiers and independent small-business cost/ROI reporting on AI-tool adoption.
- uninformedNone of the conversation's strong quantitative-sounding claims (the autonomous-change percentage being unmeasured by design, the incident-rate increase, '100 times more testing code,' engineers 'not in the IDE for six months') are backed by cited internal eval or metrics data — they are informal, first-person estimates, despite Anthropic's own emphasis elsewhere in the corpus on evals as the standard of truth for claims about model/practice performance.How Anthropic Builds And How Engineering Will Change Soon | Thariq Shihipar — read next: Any published Anthropic internal engineering metrics or eval results on AI-assisted development adoption and outcomes, to check these estimates against measured data.
- 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.
- incompleteNo outcome evidence or survivorship check. The essay is entirely prescriptive, illustrated with hypotheticals; there is no reported ask that succeeded or failed and no base rate, so we cannot tell whether these heuristics actually raise reply rates or merely describe a plausible-sounding etiquette derived from the author's own (presumably successful) experience.How to ask for help from people who don't know you — read next: Read against empirical work on cold-outreach response — cold-email reply-rate studies, referral-effect data, and any A/B-tested outreach experiments — to convert intuition into base rates.
- incompleteThe method presupposes the asker already has demonstrable proof of work and something to trade. It does not address the person at the very start with nothing to show, or asks made purely from need — arguably the case where help matters most and is hardest to earn.How to ask for help from people who don't know you — read next: Read alongside literature on asking from low status / genuine need, and on how newcomers bootstrap a first credible artifact before they have any standing.
- incompleteTension with the essay's own constructible-credibility thesis (p10). It dismisses institutional credibility as 'weak,' but inherited status, warm networks and pedigree heavily determine who even opens your message and grants the initial attention the whole method depends on; 'credibility is built, not assigned' understates how status-gated the starting line is.How to ask for help from people who don't know you — read next: Read against work on networks, homophily and privilege in who gets replies — and against extract-heis-03-christin-gorman-leder-uten-tittel#g1 ('whose work is invisible without a platform').
- incompleteSilent on scale and on the responder's side of the ledger. There is no treatment of what happens when many askers apply the same tactics to one sought-after responder (specificity and low-friction blurbs become an arms race; inbox overload dominates), nor of when or why a responder should say yes.How to ask for help from people who don't know you — read next: Read alongside attention-economy / inbox-overload treatments and issue-selling-at-scale critiques (e.g., the overload gap in extract-hbr-buy-in-for-big-idea).
- incompleteCulture-specificity is unexamined. The prescribed norms — directness, brevity, low-obligation asks, and especially 'make it easy to say no' — reflect a particular high-individualist, low-context professional culture; the essay presents them as universal, but reciprocity and obligation norms differ sharply across cultures.How to ask for help from people who don't know you — read next: Read against cross-cultural communication research (high- vs low-context cultures; differing norms of reciprocity, face and obligation) to see where the heuristics invert.
- incompleteThe article never reconciles its headline framing ('built in three prompts,' 'built in two prompts') with the seven distinct named techniques it goes on to describe — it's unclear how many techniques were actually stacked to produce the opening hero demos, or what the realistic cost/iteration/wall-clock budget of the full pipeline is for a team that isn't the author.How to turn your AI into a world-class designer — read next: Treat 'N prompts' claims skeptically until technique count and iteration count are reconciled; look for a follow-up or reader Q&A addressing total cost.
- incompleteThe method assumes a single, fixed message that already exists, whole, before writing begins -- 'you know where you will stop before you start.' It has no place for exploratory or discovery writing, in which the point emerges only through the act of drafting. This is in tension with Thompson's own implicit 'clear writing = clear thinking': he treats thinking as prior to and separable from writing (think via the cards, then transcribe), whereas the writing-as-thinking tradition holds that writing IS the thinking, and that outlining-first can only help once the hard cognitive work is already done.How to write clearly — read next: Read Peter Elbow 'Writing With Power' and Sonke Ahrens 'How to Take Smart Notes' (Zettelkasten) on writing as thinking-to-discover, and Franco 'What we lose when AI writes for us' on writing as constituting (not merely reporting) a view -- against Thompson's think-first-then-write separation.
- incomplete'Clarity' is treated as always achievable by simplification, but some subjects are irreducibly complex, uncertain, or essentially ambiguous, and faithful writing must preserve that -- flattening them into one clean surface reading can falsify. Every Thompson exemplar (all the fish died; the cherry tree) is a subject where nothing complex is lost; none tests the claim against genuinely conceptual or contested material.How to write clearly — read next: Read Ousterhout on essential vs. accidental complexity and deep-simple vs. simplistic, and technical-writing / explanation-theory work on rendering irreducible complexity without falsifying it -- to see where 'be clear' shades into 'oversimplify.'
- incompleteThe essay is pre-digital and pre-collaborative: it prescribes clarity as a solo writer's individual discipline, yet its own proof texts ('Notice how WE edited this', 'Condensing, as Reader's Digest does it') reveal that the exemplary clear prose is the product of a collective editorial apparatus. It says nothing about writing with editors, collaborators, revision tooling, or (now) AI drafting assistants -- the very machinery that actually produces the 'condensed' Digest style it holds up as the model.How to write clearly — read next: Read on editorial process and collaborative revision (how Reader's Digest condensing actually worked as a pipeline), and current work on AI-assisted drafting where the outline-first and condense steps are negotiated with a machine rather than performed alone.
- incomplete'Start where your readers are -- how much do they know?' assumes a single, knowable audience with an identifiable common level of knowledge (natural for a mass magazine with an imagined 'average reader'). It gives no guidance for heterogeneous or unknown audiences -- the default condition of digital publishing -- where readers span wildly different priors and there is no one level to start from.How to write clearly — read next: Read on writing for mixed audiences and layered/progressive-disclosure documents (letting expert and novice readers each take the path suited to them) rather than a single pitched level.
- 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)
- illogicalThe essay treats 'skill' and 'domain expertise' as effectively synonymous, but its own evidence (Tao's brevity, indirect pushback, and habit of proposing his own next steps) is arguably a distinct interpersonal/communication skill layered on top of subject knowledge. The essay never disentangles whether a subject-matter expert with poor communication habits would get Tao-level results, or whether communication skill is doing independent causal work alongside — not merely downstream of — domain knowledge.LLMs Reward Expertise — read next: See this corpus's 'Prompting as Communication' concept, which frames good AI output as fundamentally a communication/attention problem distinct from subject knowledge; a piece that separates the two variables experimentally would resolve the equivocation.
- incompleteThe postscript's own rebuttal (OpenAI's expert mathematicians filtered the model's suggested discoveries) reveals a second, structurally different locus for expertise — applied downstream as institutional filtering/checking, rather than upstream as prompting skill — that the essay does not integrate into its main thesis. If organizational filtering can substitute for individual prompting expertise, the essay's individual-level framing ('the human is the bottleneck') may understate how much of the real bottleneck is organizational/institutional rather than personal.LLMs Reward Expertise — read next: Compare with corpus material on how organizations institutionalize AI-output verification and expert review as a substitute for (or complement to) individual user expertise.
- incompleteNo discussion of durable, large-scale, or legacy codebases; every example (CLI tool, personal dashboard, browser extension, a user-management endpoint) is small, disposable, or greenfield. The claim that the Staff Engineer skillset transfers to leading agents is untested against the harder case of agents operating inside a decade-old, high-stakes production system.Stop Just Writing Code. Start Leading Agents: The Staff Engineer’s AI Edge — read next: extract-orosz-when-ai-writes-almost-all-code (production-quality regressions already observed) and extract-whats-an-orchestrator-why-software-needs-one (accountability scaling with agent-driven productivity).
- illogicalThe author frames 'reviewing becomes more important' as sufficient reassurance without reconciling it with his own admission that agents 'make mistakes... sometimes create bugs that look very convincing.' If agent output is specifically liable to look convincing while being wrong, review itself becomes harder exactly as it becomes more necessary — a tension the piece raises but doesn't resolve.
- incompleteThe conversation calls for executives to do teleology/ontology/epistemology mapping but offers no concrete method, template, or worked example of how to do it. Starbucks and Amazon are gestured at but not decomposed into a reproducible exercise.Philosophy Eats AI: What Leaders Should Know — read next: The companion MIT SMR article ('Philosophy Eats AI') likely supplies more; also relevant: Cynefin frameworks, OKR/teleology-mapping methodologies, and ontology-engineering literature from knowledge-graph practice.
- incompleteThe 'indifference, not ignorance' diagnosis of the Gemini case is asserted but not evidenced. It is rhetorically convenient (it lets philosophy do explanatory work) but the alternative hypothesis — that the team genuinely failed to anticipate the conflict — is dismissed rather than refuted.Philosophy Eats AI: What Leaders Should Know — read next: Reporting on Google's internal Gemini launch decisions; postmortems of similar AI launch failures.
- incompleteSchrage's claim that simulated reason 'may be better than the real thing' for many use cases is dropped without elaboration. Which use cases? On what evidence? This is a load-bearing claim about epistemology that is not defended.Philosophy Eats AI: What Leaders Should Know — read next: Daniel Kahneman / Gary Klein on heuristics vs. analytical reasoning; recent benchmarks on LLM reasoning vs. expert human reasoning.
- uninformedNo engagement with critiques that 'philosophy eats AI' is itself a marketing framing — a management aphorism designed to sell consulting and articles, rather than a tested empirical claim. The thesis is defended by examples chosen to fit it.Philosophy Eats AI: What Leaders Should Know — read next: Critical management studies on the 'X eats Y' aphorism genre; the history of how Drucker's 'culture eats strategy' was actually used and misused.
- incompleteThe learn-to-prompt / prompt-to-learn cycle treats human and model learning rates as observable and comparable. But no operational definition is offered for either learning rate, and there is no discussion of how an executive would measure whether 'humans are learning faster than the models'.Philosophy Eats AI: What Leaders Should Know — read next: Organizational learning literature (Argyris, Senge); ML evaluation/eval-set methodology; recent work on continuous evaluation in production AI systems.
- uninformedThe conversation foregrounds teleology/ontology/epistemology but is silent on axiology (theory of value) — even though the entire argument is about value creation. The choice of three of the four classical branches is unexplained.Philosophy Eats AI: What Leaders Should Know — read next: Standard introductions to philosophy that include axiology; literature on value-sensitive design in HCI.
- incompleteSchrage's hint that pattern-based meaning-making is a 'different philosophical insight' is not developed. Is this a continental/post-structuralist claim about meaning-as-similarity? A pragmatist one? The philosophical lineage of the new account is left implicit.Philosophy Eats AI: What Leaders Should Know — read next: Wittgenstein on family resemblance; connectionism vs. symbolic AI debates; recent philosophy-of-mind work on LLM cognition.
- incompleteThe talk does not address who is responsible for the initial codebase quality when starting a greenfield AI-assisted project. If the AI generates the initial code, the entropy problem exists from day one.It Ain't Broke: Why Software Fundamentals Matter More Than Ever — read next: Investigate AI-assisted bootstrapping practices and whether initial architecture prompting can produce deep-module structures from the start.
- 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.
- uninformedThe 'high-level intent' thesis (mob programming trains the same skill as agent direction) is asserted by analogy (the taxi-driver example) with no apparent awareness of the broader prompting-as-communication literature the corpus already contains (e.g., the Zinsser-derived 'clarity of intent yields larger improvements than any specific technique' claims), which frames intent-clarity as a general writing/communication skill unrelated to team programming specifically. Engaging that literature would either strengthen the claim (two independent traditions converging on the same finding) or complicate it (if intent-clarity turns out to be a generic communication skill rather than something mob programming specifically instills).Software Teaming in the Age of AI with James Herr and Woody Zuill — read next: Read the corpus's prompting-as-communication material (Zinsser-derived prompting advice) alongside this episode's high-level-intent claim and ask whether mob-programming background adds anything beyond general clear-communication skill.
- incompleteNo method for developing the one skill it names as decisive. The essay says attention is the key, says it can't be taught, and then offers only the paid 'Inner Circle' as a path — leaving the practical reader without an actionable next step, which is ironic for a self-styled 80/20 practical newsletter.The real skill behind good AI prompts is older than computers — read next: Cal Newport 'Deep Work'; Nir Eyal 'Indistractable'; William James on attention; mindfulness / meta-attention research — the how-to layer the essay withholds
- illogicalThe thesis is close to unfalsifiable: any AI success is credited to attention, any failure blamed on inattention. It also equivocates between 'attention' as (a) present-moment noticing and (b) accumulated domain expertise ('knowing what matters about the task') — much of what he calls noticing is actually expertise/tacit knowledge, a different faculty.The real skill behind good AI prompts is older than computers — read next: Michael Polanyi 'The Tacit Dimension'; Gary Klein 'Sources of Power' (expert intuition as pattern recognition); Ericsson on expertise — to separate 'attention' from 'expertise'
- incompleteTitle/body mismatch. The headline promises a skill 'older than computers,' but the body only asserts the pre-digital, timeless pedigree of attention — it never substantiates the historical claim it uses as a hook.The real skill behind good AI prompts is older than computers — read next: Matthew Crawford 'The World Beyond Your Head' (attention as a cultural/historical achievement); Simone Weil on attention
- practicalThe technique requires the flaky test to actually fail during the collection runs. For tests that fail once in thousands of runs, the script's loop-until-both-outcomes approach may be impractical without guidance on how many runs are needed.
- incompleteThe single example generalizes cleanly because it is a quantifiable, well-documented statistic (solar capacity vs. output) with an unambiguous correct answer and clear public sources. The piece extends the habit to "a claim" in general without addressing contested, values-laden, rapidly-evolving, or novel claims where sources themselves disagree, are sparse, or are already AI-generated — cases where a confident ten-second validation could produce false confidence rather than correction.The habit that makes AI worth using — read next: Literature distinguishing fact-checkable empirical claims from contested/interpretive claims; studies of chatbot reliability specifically on breaking-news or actively-disputed topics.
- incompleteThe article does not address how to diagnose which of the three needs applies in real time. The taxonomy is presented, but the recognition heuristics are thin — you would need to read context clues, but the article gives little guidance on what those clues are or what to do when the signals are ambiguous.When an Executive Asks You an Unexpected Question — read next: Literature on executive communication patterns, or Chris Voss's 'Never Split the Difference' on reading implicit needs in conversation
- incompleteThe framework assumes a one-to-one mapping between questions and needs, but real executive questions often blend needs — an exec might want both reassurance and guidance simultaneously. The article does not address mixed or shifting needs.When an Executive Asks You an Unexpected Question — read next: Research on conversational dynamics and need-shifting in organizational communication
- uninformedNo empirical evidence or research is cited for the three-category framework. It is presented as practitioner wisdom without grounding in communication research, psychology of questioning, or organizational behavior studies.When an Executive Asks You an Unexpected Question — read next: Academic literature on question types and communication pragmatics, e.g., speech act theory (Searle) or the SPIN selling framework's question taxonomy for a parallel practitioner model