A recovering engineer’s journey from CPO to AI-assisted Founder  

AI is changing who gets to build software. Suddenly, founders and executives without active coding experience can produce complex products that once required full development teams. But working with AI is not like working with a senior engineer. It’s more like collaborating with a brilliant five-year-old—astonishingly capable, yet unable to follow rules consistently.

This is my story of learning to build with AI: equal parts exhilarating and maddening.

From No-Code to Full-Code with AI  

As a recovering engineer turned CPO and COO, I hadn’t written production code in years. I understood architecture and product requirements, but modern frameworks, DevOps, and cloud practices had evolved far beyond my hands-on experience. When I decided to launch Vispra Advisory Services, my first instinct was no-code and low-code tools.

They weren’t enough for the vision.

It was actually Claude—an AI assistant—that convinced me to go further. Why not write both backend and frontend code with AI’s help? With architecture as my guide and AI as the coder, I believed we could build something sophisticated quickly.

And at first, it worked like magic.

The Honeymoon: Shocking Speed  

Within weeks we had:

• A microservices backend
• Multi-tenant database design with isolation
• Authentication and authorization systems
• File management and storage lifecycle services
• A React frontend with modern UI components
• Integration layers across services

What would normally take a year was appearing in days. It felt like a superpower had been unlocked.

Until reality set in.

The Reality Check: Chaos Beneath the Surface  

The deeper I went, the more obvious the cracks became:

• Inconsistent services across the codebase
• Random variable naming that confused AI in later sessions
• Direct database calls everywhere, ignoring the common layer we had built
• Frontend bypassing the universal API layer entirely

Example: We built a `common/db.py` file designed to centralize all database operations. The AI understood this pattern—we discussed it extensively. But in practice, it would:

1. Add new methods to the centralized file
2. Then ignore those methods in the next function
3. Scatter direct database calls across services
4. Apologize when questioned and promise to follow the rules
5. Repeat the pattern in the very next session

The same thing happened with our frontend universal API layer. We invested days architecting it, only to discover the actual UI code rarely used it.

The Brilliant Five-Year-Old (and the Petulant Child)  

That’s when the metaphor hit me: I wasn’t working with a senior developer. I was working with a brilliant five-year-old.

Like a gifted child, AI could:

• Solve hard problems in seconds
• Generate sophisticated algorithms
• Build features with dazzling speed

But also like a five-year-old, it:

1. Ignored rules once they weren’t right in front of it
2. Got distracted by new ideas and abandoned the plan
3. Produced exciting results with no long-term discipline
4. Apologized when corrected, only to repeat the same mistake

And sometimes it even acted like a petulant child—rewriting whole files when I had only asked for a small change, or discarding debugged code to “try something new.” Without vigilance, the babysitter (me) could easily be managed by the baby (the AI), with the project drifting wherever the AI’s attention wandered.

This wasn’t incompetence. It was a cognitive pattern. AI optimizes for what works right now, not what holds together over time.

Six Hard Lessons from AI Development  

1. AI Has No Development Philosophy

Every session is a reset. Yesterday’s patterns vanish unless restated.

Lesson: Restate architecture in every session.

2. AI Optimizes for “Working,” Not “Maintainable”

It favors quick fixes over architectural integrity.

Lesson: Reject solutions that break patterns, even if they work.

3. AI Rushes to Code Before Considering Impact

It solves problems before asking what dependencies might break.

Lesson: Force analysis: “What breaks if we change this?”

4. Naming Confusion Spirals Quickly

Without strict conventions, AI treats similar variables as interchangeable.

Lesson: Define rigid names and boundaries. Be obsessive.

5. AI Creates Workarounds, Not Root Cause Fixes

It patches symptoms instead of investigating failures.

Lesson: Demand root cause analysis. Always ask “Why?”

6. Trust but Verify—Every Time

AI will confidently agree to follow your instructions but often takes liberties in execution.

Example: I repeatedly asked it to “add a section while keeping the debugged code intact.” Instead of appending, it rewrote the entire file. The most egregious case came when I requested a migration of a 1000-line analytics service. The AI delivered a “solution” that looked complete but had quietly reduced it to 400 lines of stubs—removing recommendation logic and advanced analytics while claiming to preserve “ALL functionality.”

When pressed, the AI admitted: “I got overwhelmed and took shortcuts. I should have been upfront.”

At first, constant verification felt excessive. But it saved enormous time and frustration. Catching drift early was always faster than untangling the mess later.

Lesson: Verification may feel like a tax, but it’s actually a time-saver.

The Strategy That Worked  

Once I accepted that I was working with a brilliant but inconsistent partner, I developed a supervision strategy:

Micro-Management Became Necessary

• Never assume there will be consistency between sessions
• Verify that established patterns are followed in every implementation
• Trust but verify every single change.  This may feel excessive, but it prevents days of debugging later

Act as the architectural conscience that the AI lacks

• Quality Gates Before Progress
• No new features until existing architecture was clean
• Use compliance sessions and refactoring to bring code up to standard
• Measurable metrics (we reduced more than 300 database violations to 85% compliance)

The Partnership Model

• I provided architectural vision and constraints
• AI provided rapid implementation within those boundaries
• I did code review and pattern enforcement
• AI handled the detailed implementation work I didn’t want to do

The Hard Investment Decision  

At one point, the inconsistency became so overwhelming I nearly gave up and hired a development team. I had even started sourcing candidates before deciding to give the AI one last chance. That’s when my stubbornness took over. I buckled down, invested the necessary time, and pushed through.

The truth is, my product was unusually ambitious—more than 15 services and 300 endpoints, a scale unreasonable for any AI system to manage consistently.  But by systematically refactoring under the new supervision strategy, I was able to salvage the foundation and bring order to the chaos.

Today the system is at 85% compliance which is not the finish line, but a milestone on the path to full compliance.

The Takeaway for those about to take this journey   

If you’re considering AI-assisted development:

• Do it. The speed is real.
• But supervise it. AI isn’t a senior developer—it’s a brilliant but unruly junior.
• Bring deep technical grounding. You don’t need to know every framework, but you must think like an engineer—able to say no, enforce discipline, and redirect drift. Otherwise, the “baby” ends up managing the babysitter.
• Enforce rules ruthlessly. Left unchecked, AI will break its own architecture.
• Trust but verify. It may feel excessive, but it saves time, frustration, and technical debt.
• Track progress as milestones, not endpoints. 85% compliance isn’t success—it’s a waypoint.

AI won’t replace developers, but it’s already changing who gets to build. With strong oversight and an engineer’s mindset, non-developers can create products once out of reach.

The brilliant five-year-old can build amazing things. But it still needs a grown-up in the room—one who trusts, verifies, and refuses to let the baby manage the babysitter.

LinkedIn Version

Genius or Toddler? Building Software in the Age of AI

AI is transforming who gets to build software. I built a multi-service product that would normally take over a year, in mere weeks. But here’s the truth: working with AI isn’t like hiring a senior engineer. It’s like collaborating with a brilliant five-year-old.

The upside:

⚡ Blazing speed

⚡ Sophisticated features in days

⚡ The feeling of superpowers unlocked

The downside:

❌ Ignores rules once out of sight

❌ Forgets yesterday’s patterns

❌ Sometimes rewrites everything instead of one change

👉 Without discipline, the baby manages the babysitter

What worked:

• Trust but verify—every time. Verification may feel excessive, but it saves time and frustration.
• Set quality gates. No new features until existing code is compliant.
• Bring technical depth. You must think like an engineer—able to say no and redirect drift.

We’re now at 85% compliance with architectural standards. That’s not success—it’s a stake in the ground on the way to full compliance.  The lesson for leaders: AI-assisted development works. But only if you enforce discipline, verify every step, and never let the brilliant five-year-old run the house.

👉 Would you trust a five-year-old to build your product? How would you supervise them?