We Can Build Everything. That's the Problem.

There's a paradox in software development right now.

We can build faster than ever before. What used to take days now takes minutes. As a result, many of us have been endlessly crafting new apps, scripts, tools, whatever we can think of. Dream up an idea, turn it into a prompt, and an agent spits out the prototype a few minutes later. And honestly, it's a ton of fun.

But at the same time these coding superpowers keep accelerating, the way people interact with the digital world is shifting just as quickly underneath us.

When personal agents can take our intents and assemble customized solutions on the fly, many of our assumptions about what software is, and how it should be built, start to break down.

As a builder, hooked on Claude Code and the thrill of seeing ideas come to life, there are four questions I keep coming back to as I try to figure out what's actually worth building:

1. Is this a product or an artifact?

Some software no longer needs to be durable, branded, or reusable. If it exists to answer one question for one person, it can be disposable by default.

A parent asks their agent to generate a chore chart customized to their three kids' ages and schedules. It lives on the fridge for a month, then disappears. That's fine. No need to turn everything into a new app.

Durability used to be the default assumption. Now it may be the exception.

2. Am I building a primitive or a wrapper?

Most products are designed to cover a wide range of potential users and use cases. You show up with a specific problem and then spend time trying to fit your problem into the shape of the tool. If we're lucky, it works just right, but often we're left wishing different features existed.

Take budgeting apps for example. You could search "best budgeting app 2026" and get ten options with different philosophies you have to evaluate. You spend your time connecting accounts to each one, fixing buckets, just to realize it can't really answer the question you showed up with.

Your agent, though? It just asks what you're trying to track and assembles exactly that.

The question becomes: should I build the full, pre-configured experience that I think everyone wants (the budgeting app), or just the primitives that everyone needs (access to transaction data, categorization, account balances)?

In a world of personal agents, primitives win. A treadmill. A bank account. An analytics pipeline. These don't need to be UIs. They're interfaces between systems in the world and software. Agents can build customized experiences as long as they can access the underlying information.

Your bank account's real value isn't the app. It's the ability to move money and report balances. A smart thermostat's value isn't its beautiful UI. It's exposing temperature and controls to an agent that already knows your preferences and schedule.

The pattern is the same. The primitive is the value. The interface is just packaging.

3. Does this need shared context?

Agents still miss the mark sometimes in small, nuanced ways. Too many assumptions. Unclear timelines. No baseline to compare against.

Your agent can plan a trip in seconds. But if it doesn't know you hate early mornings, have a knee injury, and already visited Rome, it's planning for a stranger.

Reasoning is fast and cheap now. The hard part is context. Your agent is only as good as the context it can access, and right now that context is scattered across dozens of apps and services that don't talk to each other.

This is why personal data vaults may become one of the most critical pieces of infrastructure in an agent-first world. Whoever solves personal context ownership and portability unlocks the real potential of agents.

4. Is the UI the product or the fallback?

Products don't disappear in an agent-first world. Their role changes. The UI stops being the primary interface. The API, schema, and guarantees become the product.

Linear started as a beautifully designed project management tool. Now a huge amount of interaction happens through GitHub automations, Slack commands, and agent integrations. The UI becomes a fallback, not the front door.

If your value proposition only works through the UI, agents will route around you. How many bots are already battling anti-scraping measures right now just to get access to the underlying primitives? To an agent with browser access, every UI is just a slow API. The products that build infrastructure for agents and offer UIs as convenient fallbacks are the products that will win.

So, what are we building?

For a lot of us who built careers around shipping polished software, this is something of an identity crisis. "What should I build?" is a genuinely different question than it was two years ago. But I think the builders who sit with that discomfort and resist the urge to just ship something because they can are the ones who'll figure out what the best products actually look like on the other side of this.