ExpertsFMClaude Code’s Next Era — Thariq Shihipar, Anthropic
Latent Space: The AI Engineer Podcast · September 29, 2026
5 Selected Lessons:
heuristic · 3 framework · 2
Effort-level allocation by task type
Source
Latent Space: The AI Engineer Podcast — Claude Code’s Next Era — Thariq Shihipar, Anthropic (September 29, 2026) · at 21:52 ▸ · at 25:15 ▸
When this applies
when allocating scarce verification/review resources across a portfolio of tasks with different risk profiles
The takeaway
Match the depth of verification to the risk and ambiguity of the task class, not uniformly across all tasks.
Why it works
Effort in agentic systems is spent mostly on verification and edge-case testing rather than core task-solving; high-stakes domains like security benefit far more from extra verification than low-stakes ones like UI work.
One level up
Resource allocation should track where marginal verification yields the most risk reduction, not be spread evenly.
Where it stops holding
This stops working when the model itself becomes near-perfect, at which point verification tokens become unnecessary across the board ('with verification, in the limit, your model doesn't need to verify').
Detail
procedure:
- Classify task domain: code review/security vs general software engineering vs UI work
- Set effort to high/max for code review and security tasks
- Set effort to low/medium for UI and simpler software engineering tasks
- Use decision/implementation notes to audit what the model considered and rejected
benchmarks: {"security_high_effort_impact":"large eval score change","swe_effort_impact":"small eval score change"}
rationale: Effort scales with task complexity; for security, high effort meaningfully changes outcomes, but for most software engineering it mainly adds verification overhead
In their words
we see that effort scales with basically the complexity of the task. So for security, effort gets like way more results. Like high effort versus like low effort gets like changes the evals a lot, but for software engineering, it doesn't change it a huge amount
Supervisor/implementation agent split
Source
Latent Space: The AI Engineer Podcast — Claude Code’s Next Era — Thariq Shihipar, Anthropic (September 29, 2026) · at 40:54 ▸ · at 43:29 ▸
When this applies
when managing any long-running delegated process at risk of goal drift
The takeaway
Separate the agent doing the work from the agent checking whether the work still matches the original intent, and run the checker out-of-band so it doesn't add noise to the main thread.
Why it works
A forked sub-agent that reviews the whole transcript against the original goal (without polluting the main context) can catch laziness, missed approvals, or drift that the primary execution agent cannot self-detect while mid-task.
One level up
Oversight functions should be structurally decoupled from execution functions to remain objective and low-overhead.
Where it stops holding
This stops working when the overhead of running a second supervising pass outweighs the task's stakes, e.g. for trivial or very short tasks.
Detail
procedure:
- Run execution agent on the task
- Fork a separate sub-agent (keeps prompt cache, doesn't pollute main context) to review the full transcript
- Have it ask: was this the original goal? Did the solution solve it? Was the agent lazy, and if so why?
- Surface next-step suggestions, ideally as multiple choice
rationale: keeps high-level context and implementation detail in separate agents so neither is overloaded
In their words
I do have two panels, and I often try to have a supervisor thing keep the high-level context and then the implementation detail in another agent.
Elicit unknowns before implementation
Source
Latent Space: The AI Engineer Podcast — Claude Code’s Next Era — Thariq Shihipar, Anthropic (September 29, 2026) · at 4:11 ▸ · at 6:30 ▸
When this applies
when any agent or employee receives an underspecified task from someone who knows less than they think about the problem
The takeaway
Before executing on a request, actively pull out the requester's unstated assumptions rather than assuming the instruction is complete.
Why it works
Most requesters have more ambiguity in their head than they realize; surfacing unknowns (schema, call stack, requirements) before work starts prevents wasted iteration cycles.
One level up
Design the interface between two parties around the one who has less knowledge, not the one who has more.
Where it stops holding
This stops working when the requester is already a highly skilled prompter/specifier who has done the elicitation work themselves, in which case clarifying questions just add friction.
Detail
rule: Design the agent to actively ask clarifying questions and surface unknowns, because most users know less about their own requirements than they believe.
threshold: Split based on whether the user is 'a very good prompter' or not — default toward more clarification for most users
rationale: Elicitation prevents costly rework from the agent solving the wrong problem
In their words
I, the whole, believe that pretty much everyone is more on the latter than the former, that they like have more ambiguity and they know less than they want, than they like think they know about the problem.
Front-load context to cap iteration cost
Source
Latent Space: The AI Engineer Podcast — Claude Code’s Next Era — Thariq Shihipar, Anthropic (September 29, 2026) · at 18:11 ▸ · at 21:52 ▸
When this applies
when delegating a task to any capable-but-imperfect agent (human or AI) with a limited budget of attempts
The takeaway
Spend more time specifying goals and constraints upfront on expensive, capable workers to avoid costly correction loops.
Why it works
Under-specified prompts cause the agent to produce output you then reject and redo, burning far more total resources (tokens/rate limits) than front-loading context would have.
One level up
The cost of clarifying intent before delegation is almost always cheaper than the cost of correcting a wrong deliverable after the fact.
Where it stops holding
This stops working when the task is genuinely simple or exploratory, where rapid iteration is cheaper than upfront specification.
Detail
rule: Stick to a moderate usage tier (Max 20X) and invest in upfront context rather than iterating via undo/redo cycles
threshold: Max 20X as a personal recommendation; watch for hitting rate limits from repeated 'undo and redo' cycles as the warning sign
rationale: Iterative correction after the fact 'eats up so much more of your usage' than giving better context upfront
In their words
I think what I see a lot of times is people hit rate limits when they're doing this sort of like, oh, like it did a lot of work, and you're like, oh, I don't like this. Like, can you like undo this and redo it?
External embedded evaluators for credible safety signaling
Source
Latent Space: The AI Engineer Podcast — Claude Code’s Next Era — Thariq Shihipar, Anthropic (September 29, 2026) · at 1:13:17 ▸
When this applies
when any organization needs its self-reported risk assessments to be credible to outside stakeholders who don't trust self-interested reporting
The takeaway
When your own incentives create a credibility problem for a risk claim, bring in an independent party with no stake in the outcome to validate or report on it.
Why it works
A financially-motivated actor's own safety claims are inherently less credible than an independent party's, so embedding non-financially-motivated evaluators inside the process creates a credible signal that isn't simply 'take our word for it.'
One level up
Trust in a self-interested actor's safety claims scales with how visibly that actor has ceded unilateral control over the verification process.
Where it stops holding
This stops working when the pool of independent evaluators is too small or too close to the industry to be seen as truly independent (acknowledged in the transcript as 'a very small community').
Detail
rule: Bring in evaluators with no financial stake to independently assess and publicly report on safety practices, rather than relying on self-assessment alone
rationale: it's like very important that like there's someone who's not financially motivated... or at least someone who can report out to the public what practices are like
In their words
I think it's like very important, you know, that like there's someone who's not financially motivated, yeah, who's not going to be like, hey, like you guys can't release this model