Part I of IV

The Software Map

An AI coding tool answers your idea with a plan full of words nobody taught you, then asks you to approve it. This part builds a working picture of how software actually runs, so you can understand that plan and judge it.

The outcome

You can understand the plan an AI tool proposes, decode any technical question into the plain decision underneath, and approve each choice instead of guessing yes.

Who this is for

For PMs, founders, and non-engineers newer to how software works who want to direct an AI build with confidence.

What you’ll walk out with

You arrive withYou leave with

Blind yes to the planJudge a build plan and approve it
Frozen by unfamiliar wordsDecode any technical question
No frame for a systemBreak a product into its three parts
Guessing at what brokeTrace a request and read a failure
No undo across filesTake a save point before AI edits
Straight to productionShip a change through the right environment

Start with chapter one

A real incident

A founder approved an AI build plan he did not fully understand, and strangers took it apart within days. The chapters next door build the map that lets you judge yours.

01 / 09

A real incident

A founder shipped an entire SaaS built by an AI tool, with zero hand-written code, then posted within days: "guys, i'm under attack."

Strangers were draining his API keys, bypassing the paid subscription, and writing junk to his database, and he could not stop them. The code the tool produced ran fine. The failure was in the decisions around it that he approved without understanding them.

Enrichlead founder on X (@leojr94_), March 2025, reported by Pivot to AI

02 / 09

What happened

He shared how he built it, and the attacks started the same week.

FROM: THE FOUNDER, ON X

maxed out usage on api keys, people bypassing the subscription, creating random shit on db

None of it was a sophisticated hack.

There was no sign-in gate, no limit on requests, and the API keys sat in the browser where anyone could read them. Textbook gaps, all of them inside choices the tool had proposed and he had approved.

03 / 09

What actually failed

The AI wrote working code. The choices wrapped around it went unexamined.

The API keys lived in the browser, public to anyone who opened the page and free to drain.

There was no sign-in gate, so bypassing the paywall took almost no effort.

Nothing checked what strangers could write, so the database filled with junk.

A better model would not have prevented any of it, because the gap was never in the code the model produced.

04 / 09

The pattern

This was not one unlucky founder. The same gap repeats across AI-built apps.

170

of 1,645 audited AI-built apps leaked user data, about one in ten

20+

documented AI-app breaches in 13 months, tens of millions of users exposed

Researchers keep finding the same causes: secrets shipped to the browser, missing sign-in checks, and data anyone could query. The tools generate the code, and judging the plan is left to whoever approves it.

CVE-2025-48757 (Lovable), May 2025; Cloud Security Alliance incident tracking, 2025-2026

05 / 09

The one idea

You do not have to write the code, but you do have to understand the plan an AI tool proposes and judge the decisions inside it.

Every attack above traced back to a single choice, about where a key lives, who gets in, or what a stranger may write, that someone approved without being able to judge it.

06 / 09

What this part builds

A working map of how software runs, enough to understand any plan and judge it.

Instructions

Split any product into its instructions, where they run, and an input becoming an output.

Where it runs

Tell which half runs on the device and is public, which runs remotely, and where the data sits.

The round trip

Trace a tap to the server and back, read its status and timing, and spot a failure.

Checkpoints

Save a version before an agent edits, and send every change through preview before users see it.

07 / 09

The objection worth answering

"I brought in the AI so I would not have to understand the code."

Fair, and you still do not have to write it. Understanding a plan is not the same as authoring one, because you are judging a short list of decisions, where the keys live, who gets in, what a stranger may write, not memorizing a language.

The founder who was under attack could not tell that his keys were public or his door was unlocked, so he approved both. A working model could not have saved him, because the choices it returned were his to judge, and he had no way to judge them.

08 / 09

What actually fixes it

Each gap in the story maps to a move this part teaches.

A plan waved throughThe question

→ Read the plan like a quote and question any line you do not recognize before you approve it.

Keys in the browserWhere software lives

→ Know which half is public before a secret goes anywhere near it.

No version to fall back toFiles and Git

→ Save a checkpoint before an agent edits, so any earlier version restores.

Shipped straight to usersEnvironments

→ Send every change through a preview environment before real users reach it.

The gaps that sank him are the chapters waiting here.

09 / 09

From story to part

Every gap in that story is a chapter in this part.

Seven chapters build the map: what the instructions are, where they live, how a request travels, and how a change reaches users. By the end you can understand the plan an AI tool proposes and approve each choice instead of guessing yes.

Start with chapter one →