I Didn't Learn to Code. I Learned to Build.
How changing my approach to software development—and treating AI as a collaborator instead of a shortcut—turned six months of hesitation into months of consistent shipping.
Overview
In September 2025, I started working on my first startup, myBusiness. Six months later, I had almost nothing to show for it. I wasn't blocked by programming—I was blocked by uncertainty. This article explains the mindset shift, planning process, and AI-assisted workflow that transformed development from something I studied into something I finally did.
Category:
AI
Published:
Publisher:
Philip Heyes
Reading
5 min
Series
Coding
Startup
Intoduction
For six months, I convinced myself that learning was progress. Every week I compared frameworks, watched tutorials, and experimented with technologies that had nothing to do with the product I actually wanted to build. It felt productive because I was always busy.
Looking back, I wasn't building software—I was delaying the moment I had to commit. When I finally changed my approach in April 2026, development accelerated almost immediately. The biggest surprise wasn't that AI wrote code faster than I could. It was that the bottleneck had never been typing code in the first place.
The Problem Was Never Programming
For nearly six months, I confused preparation with progress. I cycled endlessly between questions that felt important. Should I build natively or cross-platform? Which framework would still matter five years from now What if I chose the wrong backend? What if someone later proved that my entire architecture was flawed? Every answer created three new questions. Instead of building my product, I built tiny experiments that solved problems I didn't actually have. They taught me syntax, but they didn't move my startup forward.
Eventually I realized something uncomfortable. My hesitation wasn't technical. It was psychological. I wasn't afraid of writing code. I was afraid of committing to decisions I couldn't defend.
That realization changed everything.
Building Started Before Writing Code
In April 2026, I made a decision that completely changed the trajectory of the project. I stopped trying to become a developer. Instead, I decided to become a founder who builds. That distinction sounds subtle, but it changed how I approached every problem.
Before writing meaningful code, I focused on designing the process behind the product. Together with Claude, I defined the project's scope, documented the architecture, outlined engineering principles, created development roadmaps, and established clear boundaries for what the first version would intentionally not include.
Those documents weren't written for AI. They were written for me. As a founder, it's incredibly easy to convince yourself that one more feature will make the product better. In reality, endless additions are one of the fastest ways to never ship anything. Having written constraints gave every future decision context. Whenever I found myself drifting, I could return to the original plan instead of starting over.
The project gained direction long before it gained code.
I Didn't Need More Tutorials. I Needed Context.
Even after the planning was finished, I still wasn't ready to build. Not because I couldn't use AI. Because I still didn't understand the ecosystem I was entering. I couldn't confidently read an engineering job description. I didn't understand why certain languages became dominant, how modern development environments worked, or why different technologies existed in the first place.
So instead of diving into implementation, I paused. For several days, I focused exclusively on understanding software development from a high level. Not to master every technology. To understand the landscape. I learned the vocabulary. The history. The trade-offs. The reasoning behind modern tools. Ironically, those few focused days taught me more than the previous six months combined. Once I understood the map, choosing a route became dramatically easier.
After that, I committed to a single technology stack and stopped looking over the fence. Instead of constantly asking whether another framework was better, I invested my energy into becoming genuinely comfortable with the one I had already chosen. That commitment unlocked the next stage.
My development workflow evolved from a single conversation with an AI into a coordinated system. Each morning started with planning. Claude became responsible for strategy and implementation planning. Claude Code coordinated execution. Other specialized models assisted with isolated engineering or design tasks. Every participant worked from shared documentation inside the repository. Tasks were documented. Completed work was recorded. Changes were reviewed before they were merged.
My role gradually shifted away from writing every line myself. Instead, I became responsible for directing the system. Setting priorities. Reviewing implementations. Testing functionality. Making product decisions. Synchronizing multiple contributors toward a single outcome.
The less I focused on typing code, the more software we actually shipped.
AI Didn't Replace Developers. It Changed What Developers Do.
By the middle of May, development finally felt different.The commits became consistent. Progress became measurable. Questions that once consumed entire weeks were resolved in hours.
Today, the core of myBusiness is largely built, although significant work remains before launch. Some systems still require refactoring. Others haven't been implemented yet.
That's simply part of building ambitious software. The difference is that today's uncertainty is no longer about capability. A year ago, my biggest question was whether I could build the product at all.
Today, the question is how to build it better.
That shift has completely changed my perspective on software development. AI didn't eliminate the need for developers. It eliminated the need to spend years reaching the point where meaningful building could begin.
Programming syntax became dramatically less valuable. Judgment became dramatically more valuable. The difficult questions were never about semicolons or language syntax.
They were always about architecture.
Product direction.
Prioritization.
User experience.
Trade-offs.
Those responsibilities still belong to people. AI accelerates execution. It doesn't replace judgment.
Conclusion
When I started working on myBusiness, I believed software development was a profession I needed to earn the right to enter.
I thought the path looked something like this:
Learn everything.
Become confident.
Start building.
Experience taught me the opposite.
Build.
Learn continuously.
Improve with every iteration.
The tools will change. The models will improve. The workflows I use today will almost certainly look outdated a few years from now.
What won't change is the lesson they taught me. The shortest path to becoming capable isn't waiting until you feel ready. It's building something real, accepting that your understanding will evolve, and allowing the work itself to become your teacher.
I didn't become a builder because AI wrote code for me. I became a builder because, for the first time, the distance between an idea and the ability to test it became small enough that there was no longer a reason to wait.