Over the past five days (and many LONG nights until 2am), I ran an experiment.
I wanted to see what would happen if I treated AI not as a content tool, but as a mid-level engineering partner. Not something to “build an app for me,” but something closer to a fast, tireless implementer that still required direction, review, and architectural oversight.
The result surprised me.
In five days, a basic tennis and pickleball match-tracking app I had previously created as a hobby evolved into a real, seriously awesome, top-shelf product. It gained:
I know your eyes are glazing over…but here’s the important part:
This did not happen because “AI built it for me.”
It happened because my years of technical exposure finally had leverage.
I still invested more than 20 focused hours reviewing, restructuring, testing, validating, and making product decisions. Every change was evaluated. Every new feature required architectural thinking. Every deployment required QA.
In short, the typing was faster (my absolute favorite part). The coding was FAR better. The judgment was still mine (for better or worse).
AI Is a Multiplier, Not a Replacement
If there’s one thing this experiment clarified, it’s this:
AI does not replace experience. It amplifies it.
This only worked because I already understood how API endpoints should be structured, how authentication and sessions work, basic SQL design and schema changes, Stripe billing flows and webhooks, hosting constraints and deployment processes, security fundamentals, data privacy considerations, UI/UX frustrations and difficulties, how to test edge cases, what technical debt looks like, and tennis itself. I believe it is CRITICAL to know what you are creating software for. I know it back and forward and I know what a user like myself would want.
Without that foundation, the exact same tools would have produced a tangled mess very quickly.
AI can generate code. It cannot evaluate architectural tradeoffs. It cannot figure out your product vision without great description. It does not automatically understand long-term maintainability and it often won’t push back on things when it should (and would) if you knew what to ask it.
It will confidently generate something that “works” even if it is fragile, insecure, or poorly structured.
That oversight still requires experience.
What We Were Actually Solving
When I look back at the commit history from those five days, what stands out is not the feature count. It’s the categories of problems we were solving. This was not just “adding stuff.” It was turning a hobby project into something that could thrive in the real world.
If you can clearly define what you want, anticipate edge cases, understand infrastructure, and evaluate tradeoffs, AI becomes a powerful implementation layer.
If you cannot, it produces complexity faster than ever before.
This experience did not convince me that software is now “easy.”
It convinced me that experience is now more valuable, not less.
AI removed friction. Experience provided direction. And that combination is incredibly powerful.
If you’re a business owner wondering what AI makes possible, the honest answer is this:
It depends entirely on who is guiding it.
Used responsibly, it allows small teams to build at a speed that previously required much larger engineering organizations.
Used carelessly, it creates fragile systems very quickly.
The tool is extraordinary. Judgment still matters; maybe even more than ever.
