AI development for product managers

After nearly two decades in the UK, I've moved back home to South Africa for good. Everything I own is currently on that ship, and I've been killing time at my mom's house. Naturally, I ended up hijacking her laptop to mess around with Google's new IDE, Anti Gravity.

I'd played with GenAI before. At KPMG I once used Gemini to bash out a REST API spec when resourcing got tight, and — to my amazement — it made it into production. But those were small, isolated wins. This time I wanted to know whether an AI agent could help me build a living system from the ground up.

First decision: the stack. The language I started my career in is ancient history now, so it came down to JavaScript or Python. Both have massive communities and endless Stack Overflow threads — which turns out to be just as useful for an AI's brain as it is for mine.

The problem worth solving

Anyone who's worked in logistics knows the warehouse-intake headache. A massive shipment arrives and nothing matches — the tags, the barcodes and the paperwork are all telling different stories. Everything grinds to a halt while someone sorts it out.

I kept coming back to one question: what if you could feed a messy product identifier — a scuffed barcode, a vague description — into a system, and it went and found everything the internet knows about that product?

So that's what I mapped out. A self-serve platform where you create an API endpoint and define the exact fields you care about — material, dimensions, whatever. Your input goes to Gemini with a tailored prompt, the AI scours the web, maps what it finds back to your fields, and returns clean JSON.

The build

This was never going to be a Hello World exercise. I wanted real-world weight: Clerk authentication, a Postgres database on Supabase, Gemini integration, and full management for organisations and custom APIs.

The echo technique

Anti Gravity is new enough that there aren't many guides for the complicated stuff. To beat blank-page syndrome I used what I call the echo technique: treat Gemini as a sounding board and bounce ideas back and forth until the plan and the stack are solid. The same loop is how I fine-tuned the core prompt later on.

Co-piloting, not autopilot

I didn't go full sci-fi with an autonomous swarm of agents. I loaded our plan, the database scripts and a few code snippets into Anti Gravity, gave it a few minutes and a hefty chunk of tokens, and got an implementation plan back.

Then we ignored parts of it. My product and architecture background mattered here: I sequenced the build exactly the way I'd run it with a team of human engineers.

Plumbing first. Wire up the Postgres database on Supabase and prove the connection strings work.
Security and a basic UI. Once Clerk was in, we could log in and watch data actually stick to the database.
The heavy lifting. The custom-API logic — the AI nailed this user story with only minor tweaks.
A testing panel. So users could check the accuracy of Gemini's results in real time.

How fast was it really?

By the time I came up for air, I'd spent about two and a half days on the build. Teams I've managed would have needed four or five developers for a solid week to get to the same place. You can argue about what that means for the industry, but it's hard to argue with the calendar.

Where it bites

The AI's eagerness to help is, honestly, a security flaw. It wants to solve your problem so badly that it will happily copy live connection strings and passwords into public test files. If you're not watching, those secrets go straight to GitHub. This happened to me at least five times. Watch for it.

The playbook I'd hand a friend

Start in a normal chat window. Talk the idea through with a regular LLM and get a real plan before the agent sees any context.
Be ruthlessly explicit. Name the auth provider, the database, the schemas. Vagueness is an invitation to improvise.
Question the blueprint. The first plan isn't gospel — resequence it the way you'd run the project yourself.
Break stories down small. When something goes sideways — and it will — small increments make debugging survivable.

What this does to the PM role

There's an old school of thought that says a PM who gets too technical is sacrificing their strategic edge. It was always a bit of a myth, but now it's obsolete. PMs who understand the engine can use AI to close the distance between a concept and a product almost entirely.

We're heading for a world where a specification isn't a document — it's a working prototype. For lean products, one PM might build the whole thing. Execution isn't the junior partner of strategy anymore. If you want your vision to survive contact with the build, you have to get your hands dirty.

The PMs who thrive from here are the ones who can take the engine apart and put it back together. End-to-end used to be the edge. Now it's the job.