How Anthropic Builds And How Engineering Will Change Soon | Thariq Shihipar

Ryan Peterman · video · 2026-09-07 Reader 🖥️

practical, with a theoretical throughline · mixed (interview/dialogue: expository explanation interleaved with argumentative claims and illustrative narrative) — Ryan Peterman interviews Thariq Shihipar (Anthropic, Claude Code team) for concrete, importable practices (prompting habits, harness/loop patterns, maintenance norms, career moves), but the conversation keeps surfacing a theoretical claim underneath the tips: what 'software engineering' itself is for is changing, and the durable human skills are shifting from writing code to judgment, verification, and visibility.

Structure

Key terms

• Model vs. Harness
  The raw model's capability is analytically separate from the engineered system wrapped around it (permission classifiers like Auto Mode, sandboxing, verification, output-representation choices like Artifacts) that determines what the model is actually allowed and able to do safely and usefully.
• Loop Engineering Loop Engineering
  Setting up a system that prompts Claude on your behalf (scheduled or triggered) instead of prompting it yourself turn by turn; at team scale this requires heavy investment in skills and verification so that autonomously-landed changes can be trusted.
• Prompting (as durable skill) Prompting as Communication
  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.
• Luck Surface Area Luck Surface Area
  The more visible, public, shared work you do, the larger the area of your life exposed to serendipitous career opportunity — publicizing work is framed as a controllable input to something that looks like luck from the outside. (Auto-captions mis-transcribe this once as 'LLM surface area'; context and the section's own title make clear it is 'luck surface area.')
• Auto Mode Claude Code
  A classifier that runs after every Claude Code task to auto-approve actions that would otherwise require a manual permission prompt, introduced specifically because Claude's autonomous runs grew from a few minutes to multiple hours.
• Being Technical
  Understanding how computers, programs, and systems actually work at a foundational level — enough to judge whether AI-produced work (code, or by analogy a math proof) is actually good — independent of whether you personally hand-write code day to day.

Propositions

• explicitTreating Claude as a thought partner and giving it sufficient context is the single highest-leverage onboarding practice at Anthropic, and has reduced (though not eliminated) the technical role of an onboarding buddy.conf: high
• explicitOnboarding buddies are still necessary, but mainly for social and cultural integration (team norms, buy-in, having a friend) rather than technical ramp-up.conf: high
• explicitThe gap between external perception of frontier AI coding capability and Anthropic's internal usage is driven substantially by culture: a willingness to invest a day trying to get Claude to do something autonomously and accept failure as a cost of that investment, rather than a difference in model access.conf: high
• explicitAs models get smarter, the harness around them must grow more complex, not simpler — capability growth increases rather than eliminates the need for harness engineering.conf: high
  supportsAgent Harness Engineering · p1 — Thariq's 'harness gets more complicated as the model gets smarter' directly reinforces the corpus's 'a decent model with a great harness beats a great model with a bad harness' claim.
• explicitAuto Mode — a classifier that auto-approves actions instead of a manual permission prompt — became necessary specifically because Claude's autonomous runs grew from a few minutes to multiple hours.conf: high
• explicitThere is no single meaningful percentage for 'fully autonomous' changes at Anthropic — it depends heavily on team/function and on how much upstream ambiguity (e.g. a completed Figma spec) has already been resolved before Claude sees the task.conf: high
• implicitThe organizing principle for what a human should personally do is 'unique work' not previously done by anyone; work that merely repeats or translates prior work should be delegated to Claude.conf: high
• explicitA sufficiently well-specified spec lets Claude execute a task close to end-to-end, but most tickets are underspecified in practice, so the real bottleneck has shifted from writing code to discovering what you actually want.conf: high
  supportsMeasuring AI impact, assessing readiness, and new data trends · p1 — Thariq's 'it depends on how good the ticket is / people haven't figured out what they want' is a concrete instance of the broader claim that code generation was never the real bottleneck — planning and understanding needs are.
• explicitThe nature of intern/junior work at Anthropic has shifted away from tightly-specified implementation toward open-ended problems nobody has solved before, because AI now absorbs most of the well-specified implementation work.conf: medium
• explicitComputer-use/GUI-agent latency persists because reliable computer use needs a large, slow model (small models aren't good enough), and because most GUI actions are much harder to reverse than a code change, raising the cost of a mistaken action.conf: high
• explicitCoding-agent adoption is displacing computer-use/browser-use for many tasks, because an increasing share of knowledge work can be re-expressed as code-and-API calls rather than literal GUI interaction.conf: high
• explicitAnthropic engineers on a Max-tier subscription are rarely compute-constrained; people who do hit real limits usually under-specified an initially small task and iterated repeatedly, rather than having over-specified a large one.conf: high
• 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.conf: high
  supportsLoop Engineering · p1 — Both define loop engineering the same way: building a system that prompts the agent instead of prompting it yourself turn by turn.
  extendsWhat is “loop engineering?” · p6 — Where that extraction frames loop engineering as largely a rebranding of pre-existing cron/automation concepts, Thariq's account adds the specific ingredient that makes it work at team scale — heavy, deliberate investment in skills and verification, not just scheduling.
• explicitClaude Code's current comparative advantage is code implementation; the durable industry-wide direction is turning the rest of the software development lifecycle (review, CI/CD, incident response, feedback triage) into agent-run loops as well.conf: high
• explicitGenerative interfaces (Artifacts) — agent-generated, task-specific interactive UIs rather than plain text — are an underused and growing way of interacting with Claude, because plain text in/text out doesn't scale to the range of work Claude now does.conf: high
• 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.conf: medium
• explicitAnthropic recently removed roughly 80% of the Claude Code system prompt, including most tool-description examples, because examples had become mostly harmful — steering the model toward narrow imitation rather than judgment — as models got better at inferring intent.conf: high
• 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.conf: high
• explicitcontestedGetting tasteful/subjective output (e.g. visual design) depends on giving the model rich, structured references (an HTML or Figma file, not a screenshot) and on the human's own developed taste to judge when output is good enough — and that judgment skill becomes more, not less, valuable as models get more capable.conf: high
  supports[FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero · p27 — Both claim taste/human judgment is what makes AI-generated output actually good, and cannot itself be automated away.
  contradictsWhy cultivating agency matters more than cultivating skills in the AI era | Max Schoening (Head of Product, Notion) · p14 — Thariq treats taste as a durably valuable, increasingly important human differentiator; the other extraction argues taste may not be an enduring human advantage over AI since the idea-to-reaction feedback loop resembles a trainable process.
• explicitA workable personal norm for AI-assisted writing is: share the output as your own only if you'd also be comfortable showing the prompt that produced it — routine 'data readout' writing is increasingly AI-generated and shared without stigma, but writing where individual word choice carries intention (essays, pitches, internal position docs) remains expected to be human-written, and passing AI writing off as fully human-authored is regarded as misleading.conf: high
• explicitCode review practice has shifted toward attaching the full prompt history (including failed approaches) to large AI-generated PRs, so reviewers can judge how much exploration went into the change rather than guessing how well the author understands a 10,000-line diff.conf: high
• explicitCode maintenance priorities are being redefined rather than abandoned: stylistic conventions like naming matter less, while investment in verification/testing infrastructure and in maintaining a clear direction ('vision') for the codebase, encoded into skills, matters more.conf: high
• explicitWhether undo/redo and composability of operations matters for maintainability is contingent on whether the software is single-player or multiplayer: single-player tools tolerate weak undo, but multiplayer/collaborative software needs it because composing operations together matters more.conf: high
• explicitBecause code-generation cost keeps falling, most codebases will likely face a moment within the next year or two where a full rewrite (e.g. into a more performant runtime) becomes viable and worth considering, which changes what 'maintainability' should mean going forward.conf: medium
• explicitDeliberately deferring refactoring in the expectation that a future, more capable model will fix it later is not unreasonable, but is circumstance-dependent — mainly defensible for shorter-timescale, lower-stakes projects, not for anything meant to deliver value over six to twelve months.conf: medium
• explicitAnthropic's own incident rate has risen as a byproduct of higher development velocity, and the countermeasure under active development is to use Claude to build a better testing/deployment environment (replaying real requests against mock fixtures, broad chaos testing) rather than slowing code velocity down.conf: high
• explicitIndividually-built, informal tooling and harness experimentation (personal Claude Code setups, scheduling bots, multi-pane sessions) is common at Anthropic and treated as part of the job, with successful experiments later folded into the shared product.conf: high
• explicitPublicly sharing your own work durably increases your 'surface area of luck' for career opportunities; the bar for doing this is lower than most people believe, almost nobody who is advised to do it actually does it, and nearly everyone who genuinely commits to it succeeds.conf: high
  supports17) Jonas Slørdahl Skjærpe om svinghjuleffekter, liminalfaser og kunsten å ta heis · p21 — Both claim large personal career outcomes have a substantial luck/timing component, with visibility and being in the right place as a controllable input to that luck.
• explicit'Coding is largely solved' does not mean writing software now requires no skill; it means the historical failure mode of software projects — extremely high variance, frequent outright failure especially for less-resourced projects — has been mostly eliminated, freeing coding capacity to be applied to a much larger space of problems than before.conf: high
• explicitBeing technical — understanding how computers and systems actually work — remains important even as hand-writing code becomes optional, because judging whether AI-produced work is actually good still requires domain expertise, and effortful ('felt') learning, not passively watching Claude explain something, is what builds that expertise.conf: high
  supportsWho is LLM? · p7 — Both argue genuinely effective/valuable engagement with LLM-era work requires deliberately invested, effortful learning rather than passive exposure.
  supportsWho cleans up after the vibe-coding party? · p10 — Both argue that skipping deep technical grounding in favor of pure LLM interaction risks a real skill/judgment deficit.
• explicitTechnically fluent users get more value from AI-driven knowledge automation than non-technical users, because understanding how to compose tools/scripts/APIs lets them treat most knowledge work as reducible to code, a mental model non-technical users don't reach for by default.conf: high

Arguments

Narratives

• Thariq's own path to Anthropic: a fellowship at interpretability startup Goodfire, building and publicly sharing an interpretability visualization that got modest traction (about 500 likes), leading to DMs and an introduction to a role.
  → grounds the abstract 'luck surface area' claim in a concrete, personal, falsifiable case — supports the proposition that publicizing work expands career opportunity
• The Riemann Hypothesis anecdote: Jared telling Claude to 'keep going, believe in yourself' — which Thariq reframes as really meaning 'I'm giving you permission to use compute' — and mathematician Lev later verifying the result in detail neither Ryan nor Thariq could follow.
  → supports both the 'give the model permission to use compute' prompting technique and the claim that domain expertise/taste is what's needed to actually verify high-capability AI output
• An article about touring a modern apartment and being awed by conveniences (like music on demand) that would have required hiring a musician before — offered as an analogy for what abundance does to a market.
  → supports an implicit rebuttal to a zero-sum 'AI takes the work away' framing: abundance historically expands total consumption and the number of people paid to produce, rather than shrinking the field
• The DoorDash cart example: adding an item to a cart incorrectly on a website creates a multi-step, error-prone undo flow, unlike code where you can simply revert.
  → illustrates why GUI/computer-use actions are harder to reverse than code changes, supporting the proposition about computer-use latency and risk

Questions addressed

• ✅ What should a newcomer do to onboard successfully onto an AI-native engineering team?
  Treat Claude as a thought partner and lean on it for technical ramp-up; still use a human buddy, but mainly for social/cultural integration.
• ✅ Why is there such a large gap between Anthropic's internal AI usage and the industry's external perception of AI coding capability?
  Attributed to culture: willingness to invest a day in automation and accept failure as a cost, plus habitually thinking at a higher abstraction level.
• ⭕ What percentage of engineering work at Anthropic is fully autonomous now, versus a year ago?
  Deliberately reframed rather than answered with a number — Thariq argues the question itself is underspecified (depends on team, function, and how much upstream ambiguity was already resolved).
• ✅ How do you decide which model to use for a given task?
  Current heuristic given (smartest/slowest model for planning, faster model for execution), but explicitly flagged by the speaker as a soon-to-be-obsolete answer, not a durable rule.
• ✅ Is prompting a durable skill worth investing in, given that model-specific quirks change with every generation?
  Yes — the durable transferable skill is learning how to learn a new model quickly, not memorizing any one model's quirks.
• ✅ How do you get good subjective/tasteful output (e.g. visual design) out of a model?
  Give it rich structured references (HTML/Figma, not screenshots), and rely on the human's own developed taste to judge when output is good enough.
• ✅ Should you disclose when writing or output was substantially AI-generated?
  Yes, guided by a personal norm ('would I be comfortable showing the prompt?'), but no discussion of what happens when disclosure norms conflict across teams or organizations.
• ✅ How do you maintain code quality and ownership given much higher AI-driven code velocity?
  Reallocate effort from stylistic conventions (naming) to verification infrastructure (far more test code/fixtures) and to maintaining a clear codebase vision encoded in skills.
• ✅ Should people still learn to code, given Anthropic's own public claim that 'coding is largely solved'?
  Yes — being technical remains important because judging AI-produced work requires expertise; what changes is what 'learning to code' is for, not whether it matters.
• ✅ What's the source of the noticeable latency in computer-use/browser-use agents?
  A large, slow model is required for reliability, and GUI actions are much less reversible than code, which raises the cost of speed.
• ⭕ Is Thariq's own 'luck surface area' career advice representative, or is it survivorship bias from someone unusually well-positioned (an AI-lab insider with an unusually receptive, AI-hungry audience)?

Gaps

• incompleteThe entire account is a first-person report from one unusually skilled, senior, high-visibility informant — there is no organizational baseline, no failure-mode data, and no dissenting internal voice about what fraction of Anthropic engineers actually work the way Thariq describes.
  Read next: Internal Anthropic engineering surveys or DORA-style internal metrics (if any are ever published) on the actual distribution of AI-assisted practice adoption, not just exemplary anecdotes.
• incompleteThe claim that harnesses must grow in complexity as models improve is not reconciled with the corpus's competing observation (e.g. senior practitioners reportedly prompting agents less and less directly) about whether growing harness complexity is itself migrating into the product/model layer, so that the complexity becomes Anthropic's problem to solve rather than every user's.
  Read next: extract-osmani-loop-engineering and extract-bockeler-harness-engineering on where harness complexity is expected to live over time.
• incompleteNo treatment of downside risk in the 'publicize your work aggressively' career advice — no discussion of cases where visible public work backfired (confidentiality/IP exposure, ideas being copied, reputational cost of a public misstep) despite Thariq himself noting in passing that 'within certain companies, you might not be able to' post externally.
  Read next: Accounts of engineers penalized or constrained for public technical writing, or of ideas/side-projects being copied after being shared publicly, to weigh against the survivorship-biased success cases given here.
• incompleteThe claim that naming/style conventions matter less for maintainability doesn't address the scenario where a human must debug an unfamiliar, AI-written production incident under time pressure without Claude's help — arguably the exact moment readability matters most, and in some tension with the same conversation's admission that Anthropic's own incident rate has risen with velocity.
  Read next: extract-boeckeler-maintainability-sensors-coding-agents and extract-code-maintainability-plummets-ai-coding-era on maintainability decay under AI-driven code velocity.
• 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.
  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.
• incompleteThe discussion of 'coding is largely solved' (failure rates for software projects dropping) sits uneasily next to the later admission that Anthropic's own incident rate has risen as a byproduct of higher velocity — the conversation doesn't reconcile whether project failure has genuinely become rarer in absolute terms, or has simply relocated from pre-launch failure to post-launch incidents.
  Read next: Data on whether AI-era software failure is decreasing in aggregate or shifting in kind/timing (pre-ship vs. post-ship), e.g. incident-rate and DORA-style studies across the industry.

Closes gaps elsewhere

• Loop Engineering · g3 — Partially closes it: that gap flags loop engineering as framed entirely as an individual developer's problem, with no treatment of loops competing for shared review/CI/triage bandwidth. Thariq describes a team-scoped (not individual-scoped) loop system at Anthropic — a shared set of triage/verification loops with dedicated skill and verification investment specifically so multiple changes can land safely into the same codebase — which is a step toward the organizational, not just individual, framing the gap calls for. It does not fully close the gap: it still doesn't address two independently-designed engineers' loops directly colliding over the same review bandwidth.

Related documents

• Measuring AI impact, assessing readiness, and new data trends
• Why cultivating agency matters more than cultivating skills in the AI era | Max Schoening (Head of Product, Notion)
• [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero
• Who cleans up after the vibe-coding party?
• Who is LLM?
• 17) Jonas Slørdahl Skjærpe om svinghjuleffekter, liminalfaser og kunsten å ta heis
• Agent Harness Engineering
• How Anthropic's product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)
  Agent Harness Claude Code Taste & Judgment
• Own the Outer Loop
  Agent Harness Loop Engineering Taste & Judgment
• Software Factories, Light and Dark
  Agent Harness Loop Engineering