Anthropic’s Claude Code chat on agents, evals, and security

By Laura Fitzgerald

Anthropic’s Claude Code team — Cat Wu and Thariq Shihipar — joined Simon Willison for a fireside chat at the AI Engineer World’s Fair. The conversation is less about a product demo and more about how agentic coding has changed daily engineering work, where Claude Code is getting sharper, and why Anthropic treats coding-agent security and evals as first-class product constraints.

From “watch every prompt” to delegating implementation

The most interesting shift in the chat is not that Claude Code exists, but how quickly the usage model changed around it. Early Claude Code usage demanded constant supervision: every permission prompt got inspected, every file access got re-checked, and the human stayed tightly coupled to the loop.

That has relaxed with model improvements. Cat Wu’s description is basically the operating model many teams are converging on: the agent now absorbs more of the menial implementation work, which frees engineers to spend time on product decisions, UX, and higher-level system design. The important point for production teams is that this is not just “faster autocomplete.” It changes task allocation. Once the agent can handle a larger fraction of routine edits and follow-up fixes, the bottleneck shifts from typing code to deciding what should exist in the first place.

Thariq Shihipar’s reaction when he first tried Claude Code with Opus 4 says the same thing from a different angle: the qualitative jump was enough to change how credible the category felt. The baseline is no longer “can this help sometimes?” but “can this reliably take a real task and finish it without a human babysitting every step?”

Fable and the jump from assistive to one-shot

The chat also points to a second step change: Fable. Cat said that for a lot of internal use cases, Fable can one-shot a substantial amount of feature work now.

That matters because it suggests Anthropic sees a distinction between a coding assistant that iterates on existing scaffolding and a system that can synthesize more of a feature end-to-end from a high-level intent. For ML engineers, the practical question is not whether one-shot coding is impressive; it is whether the failure mode is acceptable. A one-shot feature generator only becomes operationally useful if the generated artifact is easy to review, easy to test, and easy to constrain to the relevant code paths.

If you are evaluating similar tools, the right benchmark is not “did it generate something plausible?” It is whether the output survives the same controls you would apply to a junior engineer’s patch set: tests, static checks, code review, and diff size. The more one-shot the workflow becomes, the more important those guardrails are.

Security has to scale with agent autonomy

The security thread in the conversation is the part production teams should pay closest attention to. As Claude Code got better, the human stayed in the loop less often. That increases the blast radius of a mistake, which means agent security has to improve in parallel with agent capability.

This is where coding-agent security stops being a paper concern. If an agent can read files, edit code, run commands, and interact with external systems, then prompt injection, unintended tool use, and workflow-trigger abuse become concrete deployment risks rather than abstract alignment issues. The Claude Code ecosystem has already surfaced this class of problem in public, including GitHub Action-related issues that show how agent-triggered workflows can be manipulated if permissions and event handling are too loose.

For engineering teams, that implies a few non-negotiables:

  • keep tool permissions as narrow as possible;
  • treat external content as untrusted input even when it arrives through developer workflows;
  • separate read-only assistance from write-capable automation;
  • make command execution and repository mutation observable and reviewable;
  • test agent behavior against adversarial prompts, not just happy-path tasks.

The key operational insight is that better models do not reduce the need for security reviews; they increase the value of getting the control plane right. If the agent can do more useful work, it can also do more damage when it is misled.

Evals and tool design are product work, not afterthoughts

The chat also surfaces something senior teams often learn the hard way: evals and tool design are not separate from product quality, they are the mechanism by which agent quality is made real.

Claude Code’s usefulness depends on whether Anthropic can measure the right behaviors: task completion, tool selection, code correctness, permission restraint, and recovery from partial failure. Once an agent starts doing more than text generation, the eval suite has to include workflow-level outcomes. A model that writes better code but opens the wrong files, over-trusts stale context, or mishandles permissions is not an improvement in production terms.

Tool design matters for the same reason. A coding agent is only as safe and effective as the interfaces it is given. The more ambiguous the tool boundary, the more likely the agent is to take actions that are syntactically valid but operationally wrong. Good tool design reduces the number of degrees of freedom the model has to reason about, which is one of the few reliable ways to improve both quality and safety at once.

That is the real signal in this chat: Anthropic is not treating Claude Code as a novelty terminal bot. It is treating it as a system whose value depends on evals, constrained tools, and security posture keeping pace with model capability. For teams building or adopting similar agents, that is the bar worth copying.

Sources

Further articles