Detailed Analysis
A frustrated hobbyist developer's forum post captures a recurring tension in the current wave of AI-assisted coding: the gap between Claude's genuine capability on broad software tasks and its struggles with narrow, physically-grounded engineering problems. The poster, a window manufacturer with no formal programming background, describes successfully building a 3D window visualizer using Claude that reportedly outperforms a commercial tool costing £200 per month. Yet the same workflow has stalled entirely on a much smaller task: animating a five-bar friction stay, a mechanical hinge mechanism used in window hardware. Despite burning through £200 in credits on a platform called Fable and running over 100 iterations using Claude Opus in "max/thinking" mode, the user has been unable to get a working animation after 11-plus hours of effort.
The technical crux of this failure likely lies in the nature of the problem itself. A five-bar friction stay is a real-world four-bar (or five-bar) linkage mechanism with specific geometric constraints, non-linear motion paths, and physical friction behavior that must be reproduced accurately in 3D space and code. Large language models like Claude are exceptionally good at generating plausible-looking code and creative visual output based on patterns seen during training, but linkage mechanisms require precise kinematic modeling: correct pivot points, rigid-body constraints, and rotation limits that must satisfy simultaneous geometric equations. Unlike generating a static 3D model or a generic UI, animating a constrained mechanical system accurately is closer to a solved-but-narrow engineering problem than a creative or conversational one, and it's the kind of task where small errors compound rather than average out. This explains why iterative prompting, even at high volume, may fail: without ground-truth kinematic equations, reference CAD data, or an image/video sample to anchor the model's understanding, Claude is essentially guessing at joint constraints rather than solving them.
This anecdote is broadly illustrative of a well-documented weak spot in current-generation AI models: precise spatial and mechanical reasoning tasks that require consistent multi-step physical logic rather than pattern completion. Coding assistants like Claude excel when tasks map cleanly onto common software patterns already well-represented in training data—web visualizers, CRUD apps, standard 3D scenes—but they degrade sharply on domain-specific mechanical engineering problems that are rare, poorly documented online, or require exact numerical precision rather than "looks right" outputs. This is consistent with broader industry observations that LLM-based coding tools perform unevenly across domains, doing well on generic software engineering while struggling with CAD/CAM, robotics kinematics, and other physics-constrained problems where a single wrong constraint breaks the whole system.
The episode also highlights a growing pain point for non-technical users adopting AI coding tools without engineering literacy: the tendency to treat model iteration as a brute-force solution, spending significant money on repeated attempts rather than reformulating the problem with better inputs (such as providing exact linkage dimensions, reference diagrams, or breaking the animation into simpler sub-steps like defining pivot coordinates first). It underscores an emerging best practice in AI-assisted engineering work—that success often depends less on raw model power (Opus, "max" mode) and more on how well the human operator can decompose a physically constrained problem into pieces the model can verify incrementally. As AI coding assistants proliferate into hobbyist and small-business contexts far from professional software engineering, this kind of story is likely to become common: genuine excitement about newfound creative capability colliding with the model's blind spots in precise, physics-based domains, prompting user communities to develop informal workarounds—reference photos, explicit equations, or third-party CAD-export tools—to bridge that gap.
Read original article →