Shivansh Inamdar builds software for autonomous warehouse robots at Nimble Robotics. When a robot bug can bring down a section of a fulfillment center, the failure path stops being an afterthought. His essay distills three hard-won reliability lessons that apply to any software system — web apps, mobile apps, distributed services — but are rarely taught in practice.
-
Design for failure, not around it. In robotics, sensors fail, items shift, grasps slip. A bag that sags in the wrong way can cascade into a warehouse-wide outage. Build to detect failure, contain it, and recover — don’t just optimize the happy path and tack on error handling later. “At scale,” Inamdar writes, “the failure path is the product experience.”
-
Instrument before you need it. You can’t pause a physical robot mid-operation to inspect state. The same is increasingly true for distributed systems, third-party APIs, and black-box models. The right framing: “When this fails at 2am, what will I wish I had logged?” Design observability in up front.
-
Your model of the input is always too clean. Transparent packaging defeats sensors. Spec-violating boxes appear. The same principle holds for user input, upstream data, and API responses. Treat every assumption as a hypothesis to be tested against reality — and test with the messiest data you can find, not the cleanest.
The essay closes with a pointed observation about AI coding tools: they can get the happy path working, but they cannot provide failure-mode thinking, observability design, or skepticism about inputs. Those remain the engineer’s job. The engineers who thrive alongside AI, Inamdar argues, are the ones who hunt for failure modes and own everything outside the happy path.
The takeaway is simple and refreshingly concrete: write software as if it is moving something physical. Ask not just “does it work?” but “what happens when it fails?”