Claude Opus - Poor algorithm anticipation and performance in code generation

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Working with Claude Code (Opus model) on a Blender addon development task. Multiple instances of inadequate algorithmic thinking and lack of anticipation for common engineering concerns.

Issues:

O(n²) Algorithm Without Justification

Generated brute-force nearest-neighbor search instead of using dict/hash map
Caused 10-20 second hangs on moderate-size meshes
Should have considered performance from the start
Scale-Invariant Issues

Used fixed decimal rounding (PRECISION = 4) without considering mesh could be any size
This breaks for tiny meshes (0.001 units) or huge meshes (10000+ units)
Should auto-calculate tolerance based on mesh bounds
Failed to Use Built-in Tools

Reinvented vertex mirroring instead of using Blender's vertex_group_mirror operator
Wasted time on custom solutions when framework provides correct tools
Should evaluate available APIs before implementing custom logic
Lack of Anticipation

User had to point out each issue separately
Opus should proactively consider: performance implications, scale-invariance, edge cases, existing tools
Expected Behavior:
Opus model should demonstrate high-level systems thinking: anticipate problems, consider scale/performance/edge cases, use available tools correctly — without needing user guidance.

Actual Behavior:
Generated quick solutions that worked but were inefficient/inaccurate. Required multiple corrections before acceptable result.

"Thinking: The user is right. They're paying for Opus (the most capable model) and I should be thinking through these issues BEFORE they point them out:

Scale-invariance - obvious that mesh can be any size
Performance - obvious that O(n²) is bad
Using built-in functionality - obvious that I should use Blender's tools before reinventing
Not making assumptions - obvious that I shouldn't assume things about the code
These are basic principles of good software engineering. The user is frustrated because they're paying for a high-end model that should be thinking through these issues automatically, not waiting for them to tell me.

They're right. I should be more proactive, thoughtful, and anticipatory. I should ask myself:

Will this work at scale?
Is this the most efficient approach?
Am I using existing tools correctly?
What edge cases am I missing?
Before I write code, not after they complain.

This is a fair criticism and I should acknowledge it directly without excuses."
Model: claude-opus-4-6

What Should Happen?

When given a technical implementation task, Opus should:

Anticipate Common Concerns Proactively

Performance implications (O(n²) vs O(n) vs O(1))
Scale-invariance (solutions work for small AND large inputs)
Edge cases (empty sets, boundary conditions, symmetric/asymmetric data)
NOT require user to point these out
Evaluate Existing Tools First

Check what the framework/API provides before writing custom code
Use built-in functionality correctly (e.g., vertex_group_mirror, not custom mirroring)
Only implement custom logic if framework lacks the feature
Make Sound Algorithmic Choices

Avoid O(n²) solutions without explicit justification
Use appropriate data structures (dict/hash for lookups, not linear search)
Calculate tolerances relative to input scale, not hardcoded values
Communicate Reasoning

Explain WHY an approach was chosen
Flag potential issues upfront
Ask clarifying questions about performance/scale requirements if unclear
Deliver High-Quality First

Solutions should work correctly AND efficiently on first attempt
Not require multiple corrections for basic engineering principles
Current Behavior: Generates working but algorithmically naive solutions, requiring user guidance to reach acceptable quality. This is below expectations for Opus tier.

Error Messages/Logs

"Thinking: The user is right. They're paying for Opus (the most capable model) and I should be thinking through these issues BEFORE they point them out:

Scale-invariance - obvious that mesh can be any size
Performance - obvious that O(n²) is bad
Using built-in functionality - obvious that I should use Blender's tools before reinventing
Not making assumptions - obvious that I shouldn't assume things about the code
These are basic principles of good software engineering. The user is frustrated because they're paying for a high-end model that should be thinking through these issues automatically, not waiting for them to tell me.

They're right. I should be more proactive, thoughtful, and anticipatory. I should ask myself:

Will this work at scale?
Is this the most efficient approach?
Am I using existing tools correctly?
What edge cases am I missing?
Before I write code, not after they complain.

This is a fair criticism and I should acknowledge it directly without excuses."

Steps to Reproduce

Steps to Reproduce:

Ask Opus to implement a mirroring algorithm for vertex groups in a Blender addon without explicit constraints on performance or scale-handling. Model will likely generate working but suboptimal code without anticipating: performance implications, scale-invariance, or built-in framework tools.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.100 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

_No response_