That is until you realise downstairs are the normies who want to use AI.
Restaurants today are places full of tech, using a whole range of services for supplies¹, sales² and HR³. The day-to-day communication happens on through Telegram or WhatsApp groups: the kitchen talks to the floor, photos document every single delivery – if necessary on a scale showing the weight of items like meat to spot discrepancies with the order, invoices are shared with the relevant people, team members post time-off requests or tell the team they’re late because of a cancelled train. And the list of tools goes on: kitchen display system (the CI/CD of a restaurant), booking system, website and other marketing channels, and don’t forget accounting software.
Though coding agents have brought down the cost to create software and made it more accessible, even if you wanted to create your own, available time is the limiting factor. Unlike engineering where you can go down the odd rabbit hole, experiment or spend time to build your internal tools, hospitality is a relentless industry providing no such luxury.
Add key ingredients for operations in a restaurant: software has to just work™️ and do so consistently; both in terms of its technical reliability and minimal risk of team members making mistakes. An order gone wrong costs time and money.
While I’m sure there’ll be a lot more people writing their own apps. The more interesting question to me is how does software become programmable? In industries like hospitality, a large part of software usage is about creating a representation of the physical world, as a system of record. This requires the user to have a solid understanding of two things – what’s going on outside the computer, and how to turn this into a digital model using the UI and primitives provided by the tools. The latter may be harder because of user interface being too restrictive, too generic, or too complex. The people behind these products have to make decisions on abstractions and primitives that work for a large enough customer base to be economically viable.
But each abstraction comes with a translation cost and a lot of that cost is borne by the person using the tool. And often it’s too high, meaning that powerful tools end up not being used, widening the digital divides between those who can afford to benefit from these systems and those who can’t. But LLMs are great at translating things. Dynamically generated code does have the potential to become the invisible interface between the user and the underlying primitives.
Sunil Pai outlined how sandboxes enabled user-specific software. I wonder about how do you design a feature that can be user specific? What are the primitives, the guardrails and correction mechanisms when code is at the heart of it but nobody is around to pore over it.
And I’m curious which one of these new tools I’m going to see first downstairs.
¹ Services like MarketMan make it easier to purchase supplies, manage inventory and manage invoices among other things.
² POS (Point-of-Sale) services such as Square, Toast or Lightspeed allow to take orders, accept payments and provide dashboards to view and export sales data.
³ HR systems like Planday and Workforce are used to manage the payroll, clocking in and out, and to comply with local regulations