Every generation of software has a surface—the thing users actually touch. And every generation, that surface gets thinner.

Web gave us the browser. APIs gave us the endpoint. Mobile gave us the app. Each one collapsed the distance between intent and action. Each one cost less to build than the last.

Now we're in the chat generation. And for a growing category of software—developer tools especially—the surface has collapsed to almost nothing. The AI is the interface. I think this is the most important product insight most builders are still ignoring.

The Surface Tax

Think about what each generation of software cost you to build.

Web meant designing pages, building navigation, handling browser quirks, arguing about responsive breakpoints. A serious web app was months of frontend work before you shipped a single feature that mattered.

APIs were leaner—you shipped endpoints and let someone else worry about the UI. But you still needed docs, SDKs, auth flows, and a developer portal. The surface shrank, but it was still a surface you had to maintain.

Mobile didn't actually shrink anything. It added another surface on top of the existing ones. Now you needed native apps, App Store approvals, platform-specific UX, two codebases or a framework that pretended one was enough. The surface area multiplied.

Then chat arrived. And something genuinely different happened.

The Chat Collapse

Chat isn't just a new surface. It's the surface collapsing into the interaction itself.

When a developer opens an AI assistant in their terminal and says "add rate limiting to the auth middleware," there's no screen to navigate. No form to fill out. No button to click. The intent is the interface. The AI interprets, executes, and responds—all within the context the developer is already working in.

This isn't theoretical. I use this workflow every day. The tools I interact with most have no UI in the traditional sense. There are no wireframes, no design system, no frontend framework. There's a prompt, a set of tool definitions, and the developer's existing environment. That's the entire product surface.

And the pattern isn't limited to terminals. Notion AI embeds in the doc. Copilot embeds in the IDE. Google's AI embeds in the inbox. The winning products aren't building new surfaces—they're dissolving into existing ones.

The Builder Stops Building UI

Here's the part that hasn't fully landed yet: the fundamental relationship between product builder and user interface has inverted.

Historically, you designed screens. You decided what the user would see, where the buttons would go, how the workflow would feel. The UI was the product, because it was what the user actually experienced. Two products with identical backends could live or die on which one had the better dashboard.

With AI-first products, the interaction is generated dynamically. The "UI" is whatever the model produces in response to the user's intent. You don't design screens—you define capabilities. Tool definitions. Context windows. System prompts. The model assembles the experience on the fly, every time.

This changes what it means to ship. Your job as a builder isn't to design the experience—it's to define what the product can do. The verbs. The boundaries. The model handles the presentation.

If you've read my piece on verb extraction, this should sound familiar. AI-first products are verb extraction all the way down. You define the actions, set the boundaries, and the AI constructs the interface around them. The screen was always just the middleman.

I just shipped a concrete version of this idea. Worktale—my developer journal—now integrates directly with Claude as a skill. A developer working in Claude Code can pull up their commit history, generate summaries, review their work—without ever leaving the conversation. No dashboard. No separate app. The journal dissolved into the workflow the developer was already in.

The entire "interface" for this integration is a set of tool definitions. That's it. I didn't design a single screen. I defined what Worktale can do—extract and tell—and the AI handles the rest. The two verbs I started with became the two capabilities the model invokes. Same product, zero UI, deployed directly into the developer's existing tool.

The CLI Advantage

For developer tools specifically, the implications are concrete. The terminal is where developers already live. A CLI that's AI-first doesn't ask them to context-switch—it meets them where they are, in the environment where the actual work happens.

Compare the surface investment:

Traditional Web App

Design system. Responsive frontend. Auth UI. Onboarding flow. Dashboard. Settings pages. Notification system. Months of work before the product does what it's supposed to do.

AI-First CLI

A binary. A package manager entry. A set of tool definitions. A system prompt. Days of work—and the product does exactly what it's supposed to do.

And with AI in the loop, the CLI isn't even limited to static commands anymore. It's conversational. It has context. It can read a codebase, understand intent, and take action. The "interface" is whatever the conversation needs it to be in that moment.

Distribution is native too. npm install, dotnet tool install, brew install. No App Store review cycle. No landing page required. The package manager is the app store.

The math is ruthless: less surface means faster time to market. Faster time to market means faster feedback loops. Faster feedback loops mean faster product-market fit. For developer tools, AI-first CLI is the shortest distance between an idea and someone using it.

The Discovery Problem

I'd be lying if I said this was all upside.

CLIs have a discovery problem. They're invisible to anyone who doesn't already know they exist. You can't screenshot a terminal session and have it go viral. You can't demo a CLI in a sales call the way you'd demo a dashboard with smooth animations and a dark mode toggle. There's no App Store browse, no Product Hunt hero image, no visual hook that makes someone stop scrolling.

If you've read my Marketing Monday piece, you know this tension is personal. I've shipped CLI tools. Marketing them is a different kind of hard. The product works, but nobody can see it working.

So yes—AI-first CLI is the fastest path to building the product. But you still need a path to eyeballs. Documentation that's genuinely good. Blog posts that demonstrate the workflow. Conference talks. Word-of-mouth from developers who actually used the thing and told a colleague. The go-to-market looks different for invisible products.

This is the honest trade-off. You save months on the surface. You spend that time on distribution instead. Whether that's a good trade depends on your audience—but for developer tools, where trust is built by usage and not by landing pages, I think it is.

Surfaces Don't Die, They Stack

One more thing, because I want to be precise about the claim I'm making.

The surface evolution isn't a straight line of replacement. APIs didn't kill web apps. Mobile didn't kill APIs. Chat won't kill any of them. Each new surface becomes the dominant modality for a specific context while the others persist. They stack.

Chat AI is the fastest path for developer tools because developers already live in text-based environments and already think in commands and queries. The terminal is natural. The model is additive. The fit is obvious.

For consumer products, the equivalent move is embedding AI into existing visual surfaces—not handing your mom a terminal. I'm not arguing that every product should be a CLI. I'm arguing that for the specific category of developer tooling, the economics have flipped. The fastest, cheapest, most natural way to reach developers is the surface they're already staring at.

What This Means For Builders

If you're building a developer tool: stop designing dashboards. Start defining capabilities. Ship a CLI with AI built in, distribute it through package managers, and let the model handle the interaction layer. You'll be in developers' hands in weeks instead of months.

If you're building a platform: expose your functionality as tool definitions and context that AI can consume. MCP servers, function calling schemas, structured output. The products that win in this era are the ones AI can use on behalf of the developer.

If you're a developer evaluating tools: pay attention to which tools meet you in your workflow versus which ones ask you to leave it. The best developer tools have always been the ones that disappear into the work. AI just made that literal.

If you're still spending months on a web UI for a tool that developers will use from a terminal: you're building the wrong surface.

The Bottom Line

We went from web to API to mobile to chat. Each generation collapsed the surface between user and action. Each one cost less to build. Chat—specifically, AI-native chat—is the logical endpoint of that compression for developer tools.

The product builder no longer builds the UI. They define the verbs, set the boundaries, and let the model construct the experience. The screen was always just a middleman between intent and outcome. AI removed the middleman.

Skip the screen. Ship the capability. The developers are already in the terminal—go meet them there.

Building a developer tool and wondering whether to start with a dashboard or a CLI? I help teams figure out the right surface for their product and ship it fast. Let's talk.