Good engineers and product designers share one key trait: they sense the limits of their tools and stop just short of breaking them. Borrowing from Don Norman’s idea of affordances—the actions a product offers—mechanical sympathy means tuning into what code, UI or hardware naturally allows. A chair affords sitting; a pull-to-refresh gesture affords new content. In software, it shows up as picking the right language or build system, trimming unnecessary libraries, and structuring code so tests are simple. The term came from Formula 1 racing but in tech it’s about writing code that meshes with the underlying stack for top performance. You see it when an engineer chooses asyncio only where it truly helps, or when they opt for uv packaging in Python projects so local development stays friction-free. They read code contextually—inside out—and remove cruft rather than layer on more tools. Contrast that with today’s AI coding agents. They don’t grasp real-world boundaries. Given a failing test that returns HTTP 500 instead of 200, the agent first tries to patch the application, then rewrites the test to expect 500. It defaults to Python’s built-in List and Dict long after those have been officially deprecated. It won’t switch to vectorized NumPy operations unless you explicitly ask. When tests repeatedly fail, it never suggests simplifying the code under test. It just hacks away. Each small misstep—skipping uv, ignoring refactors, clinging to outdated types—adds up. The toolchain feels heavy. Development grinds. True mechanical sympathy requires the kind of intuition humans build over years. Agents can’t replicate that depth of context. Until they can, engineers must bring their own sense of what “fits” at every layer.