When Implementation Becomes Free — The Bottleneck Moved Up
Redefining my role as a developer, felt firsthand while building with AI
One day while pushing through myWiki B1~B10 with Claude Code, I noticed something strange. I was barely writing any code myself, yet I was busier than ever. Drawing up designs, breaking features into tiny units, constantly checking whether the output matched the picture in my head. It wasn’t my hands that couldn’t rest — it was my brain. That’s when it hit me: “Wait, what am I actually doing right now?”
What I expected: faster implementation means I can build more
When I first started using AI coding tools, my expectation was simple. Less time writing code means I can ship more features faster. That was basically it.
What actually happened — the bottleneck moved up
Reality turned out different. The bottleneck called “implementation” shrank, but a new one appeared in the layer right above it. The idea that developers become managers, and managers become entrepreneurs — that framing clicked perfectly.
| Role | The essence of what they do |
|---|---|
| Developer | ”How do we build it?” (implementation) |
| Manager | ”Who builds what?” (coordination, prioritization) |
| Entrepreneur | ”Why and for what do we build it?” (direction, value) |
As AI started handling the “how” almost for free, I naturally found myself taking on the layer above. But it’s a move up — not a letting go of what’s below. Someone who still understands implementation and moves up has an overwhelming advantage.
Why the development sync keeps breaking down
Comparing the three areas, the difference in feel is stark.
Design is relatively easy. The output is one artifact — you get a few versions, pick one, and move on. You can judge with your eye.
Product/planning is somewhere in the middle. You have a direction in your head, so you can lead the AI toward it.
Development is where sync breaks down the further you go. AI only ever sees “this exact moment.” But a project has accumulated context — previous structure, conventions, the reasons things were built a certain way. AI keeps forgetting that accumulated history, so the gap between what it produces and the full picture in your head just keeps widening.
Here’s what I found works:
- Slice it small: One feature at a time, check the result before moving on. Don’t give the sync a chance to drift.
- CLAUDE.md: Lock conventions into a file so AI always references it, instead of explaining things every single time.
- Give the “why” along with the “what”: “Do it this way because of X” goes sideways far less often than “just do it this way.” When AI understands the intent, it wanders less.
- Never delegate the architecture map to AI: What I mean isn’t a single line of code — it’s the map of “how this app is structured at a high level.” That map has to stay in my hands.
Domain knowledge is the same story
Building the stock portfolio app gave me a similar lesson. Reading a book about stocks, my first thought wasn’t “I should invest” — it was “I should build an app.” So I bought shares but never sold any. While building the app, I realized the sell-side features felt thin — and that only became obvious when I was debugging a sell-related bug.
You need to be the user of the thing you’re building, at least once. It doesn’t have to be the full experience. Just one complete cycle. That’s the only way to know in your bones where “the itch only people in this domain feel” actually is.
Going forward — what “I handle the core features” really means
Now when I say “I handle the core features,” I mean designing and judging how something should work — not personally writing the code.
If you’re stuck in implementation mode, moving up is hard. But if you move up while completely letting go of implementation, your foundation gets shaky. The balance point is: I design, AI implements, I review. And the one thing I absolutely cannot let go of in that cycle is the full architecture map.
If you’ve been handing code off to AI and feel unclear about what you’re actually doing anymore — try drawing your architecture map on paper. That’s what you need to be holding.
Method: Claude Code 4-Lever Method · Cutting Dev Time with Build Plan · Deep dive: Why I Break Big Work into Intervals · Documentation Strategy in the LLM Era · Background: The Story Behind myWiki · Lessons from Building a Stock App with AI Agents