*Part 5 of 10 in [Curiosity’s Wager](/curiositys-wager/2026/11/02/start-here).*

Over-reliance raises a question. What do we lose or fail to develop when we hand an activity over? Deskilling names the risk of losing skills through reduced practice. Drawing on the idea of technical debt, cognitive debt describes how work can advance while we accumulate gaps in our understanding. I want to explore these concerns through payroll and my own coding, then explain how we're trying to respond. So with our salon and barbershop design partner, we've automated arithmetic that previously required manually connecting information from different systems. It reduced the time involved and increased their confidence in the calculation.

But the calculation wasn't everything that practice was doing. Working through services, prices, clients, and discounts also provided encounters through which someone developed a feel for the shop. Automating the arithmetic could remove those encounters. We've discussed this with our design partner and built analytics pages, but working through the numbers is different from reading a report or looking at a graph. We haven't found an adequate replacement for everything that practice provided. That same question comes back to me in my own coding. I'm not trying to learn TypeScript at an expert level or retain every bit of Python I've previously known. I do, though, want to understand enough to question and direct what we're building. Is the work advancing while my ability to explain it, recognize problems, or change its direction falls behind? So we call one of our objectives operator cultivation.

As we design the tools and the development process, we're trying to include what happens to the people using them, including me. Where can the arrangement help us develop and test our understanding?

One distinction I use is automate, augment, and amplify. We can automate a commission calculation. We can augment someone's work with a warning that a charge looks unexpected. We can also ask what capacities we might amplify, not just while they're using a system, but whose ability to understand their situation, notice the problem, or pursue a goal could grow.

More output by itself doesn't establish that someone has become more capable. But what might we be able to do to help people become able to do or be the sort of things they want to be able to do or the person that they want to be? These questions remain open for me. What might we lose through this automation? Or what understanding am I needing to develop in my own work? Bringing that uncertainty to our design partner, my co-founder, and now this class is part of shared curiosity. What deserves preserving? What do we want to become able to do? And how might we reshape the work? Reshape, restructure, rearrange this arrangement itself to support that.

---

[Series contents](/curiositys-wager/2026/11/02/start-here) · [Previous: Deference: am I learning to say yes?](/curiositys-wager/2026/11/02/deference) · [Next: Projection: whose picture of the work?](/curiositys-wager/2026/11/02/projection)