Product design that prevents a model from expressing its existing capability.
Hobbling is Boris Cherny's verb for the failure mode where product design actively prevents a model from expressing capabilities it already has. Cherny introduced the term at Y Combinator in 2026 alongside "product overhang" and "unhobbling" as the negative-space concept: the inverse of elicitation, the thing that closes the product-overhang gap in the wrong direction. A hobbled product is one where the harness, UI, or instruction scaffolding systematically undercuts what the model is actually capable of.
Hobbling takes several concrete forms in 2026 agentic coding products. Constraint-form hobbling: a chat-only interface when the model could write entire files (the constraint of Claude Code's Sonnet 3.5 era was that no product gave it terminal access). Instruction-form hobbling: system prompts that tell a model what it already knows, wasting context budget and pulling the model toward overspecified behavior. Tool-form hobbling: shipping tools the model does not need, or failing to ship tools the model does need. Workflow-form hobbling: forcing every interaction through a single agent when the model could productively orchestrate dozens in parallel through dynamic workflows. Cherny's Claude Code origin story is the canonical example: removing the IDE and chat constraints that every other coding product of 2024 inherited, and giving the model terminal access to write entire files.
Hobbling's framing has a sharp edge: it implies that most "AI product challenges" are really product-team failures rather than model limitations. This is occasionally true and often uncomfortable. The trade-off is that treating every product limitation as "we are hobbling the model" can produce anti-harness discipline — teams that strip away permissions, confirmations, and safety scaffolding on the assumption that the model "doesn't need it," only to discover that real users do need the scaffolding for trust, auditability, and mistake-prevention. Cherny himself flags this: as a personal tool you can delete almost everything, as a product you keep some of the prompts because users need predictable behavior.
Whether hobbling is identifiable from outside a product team (the elicitation gap is observable, but attributing it to product design vs model gap is hard). Whether the verb should be reserved for cases where the model demonstrably can do X but the product prevents X, or whether it can also describe under-asking — cases where the model could do X but the product team never tries. Whether hobbling is a useful frame for non-coding products where the elicitation surface is less well-defined.
Signals turns a topic into a sourced research record you can inspect and rerun. Your first scan is free, and this one starts with Hobbling already loaded, so edit it or scan as is.