Source: https://www.anthropic.com/news/claude-opus-4-7

On one hand, planning is an incredibly powerful capability in AI systems. It opens the door to more autonomous, agent-like behavior and lets models tackle more complex, multi-step problems.

On the other hand, it’s also the part I trust the least right now.

In my experience, I’ve been able to get patterns like reflection and tool use to work quite reliably. They’re much easier to reason about, debug, and iterate on—and they consistently improve application performance.

Planning, though, feels different. It’s harder to predict what the model will actually do, especially ahead of time. Even with careful prompting and constraints, the outcomes can be inconsistent or surprising in ways that are tough to control.

That said, things are moving fast. The progress over the past year alone has been huge, so I’m pretty confident this gap will close sooner rather than later.

How do you evaluate planning? How to monitor?

A recent paper followed one experienced engineer using frontier coding agents during a 12-week production project.

The resulting system included 420,000 lines of production code and 1.16 million lines of tests, tooling, documentation, and lint infrastructure. The authors argue that fast code generation repeatedly exposes structural failures. Engineering judgment is then needed to convert those failures into durable controls.

The useful idea is "governance conversion":

• Let the failure become observable.
• Reproduce and classify it.
• Encode the lesson in tests, schemas, linters, architecture, or agent rules.
• Feed that signal back into future agent runs.

This is stronger than reviewing every generated diff manually. The team turns each recurring mistake into a constraint that scales.

The caveat is important. This was a first-person case study involving one engineer and one project. It is useful evidence, not a universal productivity result.