If you’ve been following the exploding popularity of AI developer tools, like I have, then you’ve probably also noticed a growing divide between two camps of developers. On one side, we have enthusiastic folks claiming that these tools are making them 10X more productive and that they are gladly paying hundreds of dollars a month to get access to the best models. On the other hand, there are plenty of experienced developers trying to use these tools and finding that they don’t follow instructions, get stuck in loops and require so much babysitting that it’s often easier to just write the code themselves. So who’s right?
What if I told you that they’re both right? The difference lies in their development style. The first group is doing bottom-up development while the other is solving problems top-down. Once you recognize this pattern, you can start to deliberately shift between exploration and implementation modes to get the best of both worlds.
An exploration mindset
Bottom-up development is about exploration. It’s about iterating quickly to discover new and interesting applications. Quick prototypes, hackathon projects and startups all share the same goal of quickly finding something interesting and getting feedback on it. The more successful prototypes you build, the closer you get to building something that people actually want. Each working prototype becomes a stepping stone - not toward a predetermined destination, but toward discovering what’s possible. This approach to innovation, where you build on each small success to reach the next opportunity, is what Joel Lehman and Kenneth Stanley describe in “Why Greatness Cannot be Planned” as the true path to breakthrough discoveries:
Contrary to popular belief, great inventors don’t peer into the distant future. A false visionary might try to look past the horizon, but a true innovator looks nearby for the next stepping stone. The successful inventor asks where we can get from here rather than how we can get there. It’s a subtle yet profound difference.
Source: Why Greatness Cannot be Planned , p.128
AI tools are great at bottom-up development especially when creating new projects. You can easily spin up dozens of agents working autonomously to prototype different ideas. Each of them start from scratch and keep iterating until they have something which works. The more detailed spec you give them at the start, the more you can control the direction but since the goal is to explore a problem space and find interesting things which work it’s not a dealbreaker for the folks using bottom-up development if the agent goes off and builds something slightly different from the spec as long as it works and it’s interesting.
Figure-1: Tetris is an example of bottom-up problem solving. You don’t exactly know where you’re going, you’re just trying to find pieces that fit together to clear rows so that you can see further ahead.
If you’re a startup founder building some kind of React web app with shadcn and Tailwind then you’ll be amazed at how quickly tools like Claude Code can build a working prototype for you. However, most developers are not startup founders and many apps aren’t React web apps.
Solving for X
Top-down development is about solving a specific problem. Your boss or your client describe the application that they want and it’s your job as a developer to figure out how to implement it. You may have some freedom to choose which frameworks or libraries to use but you can’t just build something different even if it ends up being more interesting or innovative.
Figure-2: Sudoku is an example of top-down problem solving. You’re given the constraints and there are only a few valid solutions. You’re only done when all the constraints are satisfied.
Under those kinds of constraints, it can be really frustrating when AI agents go off-script and try to build the kinds of apps that they already know how to build instead of the specific app that the user asked for. The agent just keeps changing the code until it finds something that works but the top-down developers would rather have a partial solution which sticks to the spec than a complete solution which breaks the spec.
Widening our perspective
Given the way I’ve just described these two approaches, you might be thinking: “Ah, so AI is only good for vibe coders but doesn’t work for Real Programming jobs?”
Here’s what’s missing from that view: I believe that most top-down development projects actually begin as bottom-up ideas — we just don’t realize it — but those detailed specifications don’t appear out of thin air. Somewhere along the line, there was a brainstorming session, a research paper, or a side-project which sparked the decision to commit time and resources to begin the top-down development process.
This exploration phase plays an important role in framing the whole project, yet traditional IDEs are not built for exploration. We have advanced debugging tools which let us spend weeks optimizing a function to run 0.1% faster, but when it comes to brainstorming architectural decisions we’re still using whiteboards and sticky notes. It’s still early but I believe that generative AI will open up a whole new set of tools to augment the exploration phase of development.
This is why there appears to be a productivity gap. Bottom-up developers have adapted their development style to embrace exploration as an ongoing part of development, while the top-down developers are trying to use AI tools within the constraints of their existing workflows. The productivity gains come from shifting your mindset from viewing exploration as a separate, upfront phase to seeing it as something that happens continuously throughout the development process - using AI to constantly test assumptions and validate ideas as new uncertainties emerge.
These days, when I’m exploring a new idea, I try to frame it as a collection of stepping stones. I ask myself: what smaller, self-contained experiments could I prototype to test my assumptions and help scaffold the main project? For example, splitting-off complex parts of the UI, testing how different libraries and frameworks fit together, building debugging tools to help me design the data model. Each of these stepping stones can be built in parallel, using AI agents, which allows me to quickly discover what works and then re-combine the best results within the constraints of the larger project.
Thanks to John Berryman for his thoughtful feedback on an early draft of this post.