Google describes site reliability engineering as what happens when you ask a software engineer to design an operations team.

The important idea was not to perform operations faster. Engineers do not want to babysit systems forever. They design systems that need less babysitting. They eliminate toil by building, instrumenting, and automating rather than adding people every time the load increases.

I think companies are approaching a similar inflection point with AI.

We should be asking: what happens when you design business workflows assuming AI is a capable contributor?

Moving from AI research to running a larger organization across product, engineering, operations, go-to-market, and support has made me think about management differently. When another project lands on the desk, the default question is usually “Who should own this?” or “How many people will we need?”

An engineering mindset starts somewhere else: “What is the right system for this outcome?”

Some work should stay human. Some should be human-in-the-loop. Some can be AI-first with human oversight. The design problem is deciding which is which, then giving every workflow the right context, interfaces, checks, and escalation paths.

Engineering teams already developed much of this playbook.

Coding agents work well not just because models understand code, but because the environment is designed for delegated execution. Code is versioned. Changes are reviewable. Tests provide feedback. CI runs the procedure consistently. Observability exposes failures. Permissions constrain what can reach production. Rollbacks make many mistakes reversible.

Six months ago, our developer workflows were something nobody outside engineering thought about. Now the rest of the company watches them and asks: can we do this for sales, operations, support, onboarding, and everything else?

DevOps was the niche function that thought in systems, automation, and reliability. It was solving the exact problem every department is about to face: how do you get agents to perform real work without a human supervising every step?

This leads to what I think of as the programmable company.

Its operating knowledge is written down in a form both humans and agents can execute. The knowledge is connected to tools and permissions. Work produces an observable trace. Outcomes update the system continuously as the company learns.

This is different from storing policies in a wiki. Documentation tells someone what the process should be. An executable operating system helps perform the process, notices when reality diverges from it, and incorporates what happened next.

The hierarchy changes too. Traditional companies scale by passing information and instructions up and down layers. A programmable company can make context available directly at the point of execution. Humans remain essential around judgment, relationships, novel situations, and high-stakes decisions, but less of their time is spent routing information or pushing routine work through the organization.

SRE transformed infrastructure because it was a mindset shift, not merely a new tool category. AI-first company design will be similar.

The companies that figure out how to turn their operating knowledge into reliable, self-improving systems will operate at a fundamentally different scale.