The new bottleneck
I used to think the hard part of building software was execution. Can I ship this fast enough? Do I know the right tools? Can I write clean code under pressure?
AI solved that. Not perfectly, but enough. I can scaffold an app in an afternoon. I can write a CLI tool in a day. I have agents that write code, review PRs, and generate tests while I'm thinking about the next thing. The execution bottleneck is basically gone.
But something weird happened. When you can build anything, everything becomes a candidate. Every idea feels viable. Every problem looks solvable. Your capability expanded but your time didn't — and nobody adjusted the expectations.
I spent a morning recently brainstorming my next project with an AI agent. We went through five ideas. A screenshot tool for developers. A visual bug reporter. A context switcher for dev environments. Each one felt promising for about 10 minutes until we dug in and found the gap was either already filled or too thin to justify a new tool.
That process — generating ideas, validating them, killing most of them — used to take weeks with a human collaborator. Now it takes hours. Which sounds great until you realize it means you can burn through ideas faster than you can commit to one.
The bottleneck moved. It's not "can I build this" anymore. It's "should I build this." And more specifically: of all the things I could build today, which one actually matters?
That's a prioritization problem, not an engineering problem. And it's why I built Scope — a tool that reads your existing workflow signals and tells you what matters right now. Not more information. Less. Just the three things that need your attention, and permission to ignore everything else.
I think this shift is going to define the next few years of building. The best builders won't be the fastest coders. They'll be the ones who are best at deciding what not to build.