AI Is Just a UI

AI Is Just a UI

AI earns its keep as an interface layer on top of deterministic systems. That’s where the integration wins live. That’s how non-technical people get leverage they didn’t have before. The systems doing the actual work should be boring, reliable, and predictable. The AI sits in front of them.

Almost nobody builds this way. People keep trying to make AI the system itself, and the line between “interface” and “system” keeps moving because the models get more capable every few months. So it’s a fair question. How much should sit in front? When does the interface start becoming the system?

I don’t have a clean answer. But I’ve watched this play out in enough places over the last year that the pattern is hard to miss.

I tried to replace Todoist

Start with a small case. I follow GTD. I wanted software that could think about my priorities, break tasks down, and tell me what to work on next. Todoist does most of it. I wanted the rest.

So I built a Claude plugin to do it.

It was bad. Really bad. AI doesn’t have the context to prioritise my work. It doesn’t know which project is urgent because a client is waiting, or which task I’ve been dodging for a week, or that I do my best thinking before lunch. Prioritisation is a judgment call that requires knowing me. AI doesn’t know me well enough.

The bigger problem was that I don’t always want an AI interface at all. GTD has this concept of an inbox where you capture every thought as it comes. Sometimes I’m on my phone and I want to type a quick note. Sometimes I want to speak it. Sometimes I want to sit down at my laptop and drag things around in my backlog. Chat can’t do all of that. Sometimes I just need to write the thought down. No AI. No processing. Just capture.

I went back to Todoist. Todo apps aren’t hard to build from scratch, that wasn’t the issue. The issue is that Todoist has years of product decisions baked in. Recurring tasks. Filter composition. The quick-add syntax. The mobile experience. That nuance matters, and I wasn’t going to recreate it in an afternoon of prompting.

Where AI actually helps with my todos is the doing. “What’s on my plate today?” “Move that meeting prep to Thursday.” Those are interface questions. Todoist stays the system. AI sits in front when a conversation is the right shape. It gets out of the way when it isn’t.

And sometimes I don’t need either. I just need the add button.

Star Trek got this right

The Enterprise computer is the model. It understands natural language. Picard talks to it and it routes commands to navigation, life support, weapons, shields. All deterministic systems. The computer just makes them conversational.

The Enterprise still needed a crew. The computer was genuinely good. It understood Picard perfectly. And they still had engineers on board because the judgment calls, the novel situations, the creative problem solving, none of that lived in the computer.

The computer was the interface. The crew was the system.

Modern aviation is the same split. Autopilot flies most of the route. The pilot is still flying the plane. The weather turning bad, the mechanical warning, the call to divert, those belong to the pilot. The plane’s operating system handles everything that can be handled deterministically. The human handles everything else.

We’re building the same thing now. Without the warp drive.

A fintech where this mattered

The question isn’t whether you’re using AI. It’s whether AI is load-bearing or sitting on top of something that already holds itself up.

I worked at a fintech where the core design choice was that most of the platform was deterministic, but a human credit assessor made the final call. The system surfaced the data, ran the checks, scored the application. The human looked at it and hit the button. Or didn’t.

At Macquarie Bank, where I’d worked before, they’d pushed even further. Almost the entire process was deterministic. No AI at all. Just years of rules and risk models running on reliable infrastructure, and an assessor with a button.

Palantir goes the other way. They use AI to fold millions of data points into decisions that couldn’t be made deterministically otherwise. There’s a spectrum. Where you sit on it depends on your domain, your regulators, and how much you need to prove the outcome was correct.

At the fintech I ran a proof of concept using AI to configure workflows. The platform had deterministic building blocks, each doing one thing well. AI turned out to be a great interface for wiring them together. It can write code, so writing config is trivial. Describe what a workflow should do, and AI generates the config. The blocks don’t change. They don’t need to.

When AI is the building

The rest of the company had Claude Code too. They ran with it. Slack bots, prototype products, agents, all sorts. These were people with real product knowledge. They understood the business. Their instincts about what to build were often right.

But they didn’t understand the code Claude was writing for them. I’d find crontabs they didn’t know were running. Background processes on schedules they’d never configured. When something broke, they couldn’t debug it. They’d open Claude Code again and ask it to fix things, or ask how to reduce the token usage of a bot they couldn’t read. They couldn’t run their own code without AI in the loop.

AI as glue holds up. AI as scaffolding falls down the moment you try to take the scaffolding away. The software team was using AI to configure deterministic blocks. The blocks stayed standing on their own. The other teams had built products where the AI was the building. Take the AI away and there was nothing underneath.

This isn’t new

The judgment call about what should be deterministic and what can stay probabilistic only really matters when the thing you’re building takes off. Before product-market fit, just ship. Build it however you can. But if it works, if people start depending on it, you need someone who can look at the system and draw lines. This part needs to produce the same result every time. This part can be flexible. This part is an interface. This part is the system.

Vibe coders get a hard time, and I want to be fair to them. A lot of them have great product knowledge. They understand their customers. They can see the problem clearly. They’re delivering value. That matters more than clean architecture, at least at the start.

But eventually features stack on features. Nothing gets refactored. The architecture was never intentional, it was whatever got scaffolded that first week. This has been happening since the dawn of software engineering. Before AI. Before vibe coding. We used to call it legacy software. The tools are different now. The dynamic is identical. Good engineers have always been the ones who step in and impose structure before things collapse under their own weight.

One conversation, many systems

The real win is the integration layer. People would rather talk to an EA than open their email, then their todo list, then their calendar, then Slack, then back to email. But you have to onboard an EA. You don’t just hand them five logins and say figure it out. You spend weeks explaining how you work and what matters. AI is the same.

OpenClaw is a good example. It’s an open-source AI assistant that lives in Telegram or WhatsApp. You message it like you’d message a colleague. Behind it, it’s connected to your email, your calendar, Todoist, your files, whatever you’ve wired up. None of those systems go away. OpenClaw sits in front of them. It has persistent memory and a heartbeat scheduler, so it keeps working on things even when you’re not actively talking to it.

The value isn’t the AI. It’s the integration. One message can touch five services. Users build their own workflows by stringing together their CRM, their inbox, their project tracker through conversation. The workflows aren’t perfect, because AI isn’t perfect. They’re useful because they tell you what the deterministic code should eventually do. Someone hacks together a flow that works 90% of the time, and that last 10% shows you exactly where to build the next reliable block.

Unix philosophy, applied to AI. Build small reliable systems that do one thing well. Let AI be the composition layer. Let users define how things connect, because they know the job better than a platform team guessing from the inside.

Where this is going

The productivity gains people keep chasing aren’t going to come from AI that does everything. They come from AI sitting in front of systems that already work, connecting them, and giving you one conversation instead of fifteen tabs. They come from non-technical people being able to reach into tools they couldn’t use before. That’s where the leverage is.

AI can surface more than you could on your own. I use it to pull from more source material than I’d ever read manually, and it finds the relevant parts for whatever I’m working on. That’s an interface to information, the same way OpenClaw is an interface to your tools, the same way Claude Code is an interface to a codebase.

The line between interface and system will keep moving. The models will keep getting better. But the principle holds. Build the deterministic parts well. Let the AI layer evolve on top. That’s the part it’s actually good at.