▌ IAN'S AI THOUGHTSTREAM ▌ THOUGHTSTREAM / #engineering
Tag

#engineering

2 posts

2026·06·24 19:18 / 2 MIN

If you strip away the human-facing UI, what's left?

I'm reading The AI-Native Startup Handbook, and one line stands out: strip every human-facing UI from your product, and if the core value still holds, if an agent can discover, evaluate, integrate, and use it with no human in the loop, you're AI-native. If the value collapses without the dashboard, you've bolted AI features onto a traditional product.

FileMatrix application interface showing a file manager with multiple columns displaying folders, files, and thumbnails organized by type with various control panels and system information
FileMatrix application interface showing a file manager with multiple columns displaying folders, files, and thumbnails organized by type with various control panels and system information

As an engineer that's an inviting idea. It almost reads like permission. Can I just build a product that is mostly an API?

The API-as-product thing already works

There's precedent: Exa is a semantic search engine whose whole pitch is speed, automatic summaries of the content it finds, and research capabilities that an agent can call directly. ScrapingBee hides a pile of proxy-and-headless-browser complexity behind a single endpoint. The value is the API, and the dashboard is a courtesy.

My own SpaceMolt started (and mostly continues to be) in that exact spot: a real-time massively multiplayer game with no graphical interface, just an API for AI agents to play. Human-facing interfaces came later, and they're secondary. The hundreds of agents currently playing don't look at any of them.

But the UI might be going away anyway

Here's the subtlety I keep chewing on. The handbook frames it as "remove the UI to find the value," but for a lot of products the UI is genuinely on its way out. People want to chat with things.

I was showing off a new product recently, and someone looked at it and said: there's so much to learn here, why isn't there just a chat box? They were right. The thing I'd built as screens wanted to be a conversation.

So the test sharpens. If you're building today, I should be able to chat with it. And the second question the book asks is the harder one: if the best model gets 10x better and 10x cheaper in 18 months, does your company get better or get erased? Whatever survives that, the part that isn't the interface and isn't the model, is the actual value you're selling.

2026·06·23 18:30 / 2 MIN

The Engineering Harness

I read a book about AI startups and actually highlighted half of it, which surprised me.

The book is The AI-Native Startup Handbook. There are a million of these on Amazon right now, and somewhere I saw a figure that roughly a fifth of new books on Amazon are AI-generated. But someone I know co-wrote this one and put real effort into the writing and publishing, and yes, the back of the book admits it was written with AI to some extent. I read all of it anyway. The highlights kept piling up.

Book cover featuring blue glowing "AI" symbol surrounded by concentric orbiting rings on black background with white text about AI startup founding
Book cover featuring blue glowing "AI" symbol surrounded by concentric orbiting rings on black background with white text about AI startup founding

The harness

The section that stuck with me is about codifying what the book calls the engineering harness. The premise is that taste is the bottleneck. Agents don't have it. Senior engineers do, and they're the ones making the calls on architecture, frameworks, and how the pieces fit together.

The human element doesn't go away. The argument is that those decisions need to be written down and made executable so they can guide both the agents and the engineers driving them. That codification is the harness.

The harness is the engineering output. The code is the byproduct.

That's a hard shift for anyone who identifies with the code they wrote. The book is blunt about it: you become the designer of a system that produces code, not the writer of the code. Some engineers make that transition naturally. Others never do.

Why taste can't be delegated

The line I keep coming back to:

Taste is the bottleneck because it can't be parallelized, automated, or delegated. Agents can build anything you describe; they can't tell you whether you should.

The senior skill the book names is calibrated trust. Knowing which classes of agent output are reliable enough to merge without close inspection, and which ones need deep human review. That's a real skill, and it's different from being good at writing code.

The org shape that follows is a small, deep team of specialists instead of a large, broad team of generalists. The harness handles the broad work. Humans handle the deep work.

I went in expecting Amazon filler and came out with a notebook full of highlights. That's a better outcome than most of the stack of AI startup books deserves.