Skip to main content
Secure/Chapter 58 · Why Secure

Working Code Isn't Safe Code

Share

Share this page

Pass it to someone who needs it.

Your app works. Every feature does what you asked, so it feels finished. But working and safe are two different things, and your agent only ever aimed for the first. This part gets your app safe, and the good news is you do not have to become a security expert to do it. You have to know what you are protecting, and make your AI lock each piece down.

9.1.1AI writes working code, not safe code

Ask your agent for a login and you get a working login. You did not ask it to stop someone from skipping that login, reading another user's data, or pasting in something that breaks your database, so nothing guarantees it does.

The agent optimizes for the goal you can see: the feature works. Safety is the goal you cannot see until it fails, so unless you name it, it gets skipped.

9.1.2Security is the requirement nobody asks for

A broken feature shows itself the moment you click. A security hole shows nothing. It sits quiet and working until the day someone finds it, and by then the damage is done.

That is why security has to be a deliberate step, not something you hope the agent included. You name the requirement out loud, the same way you named what the app should do.

9.1.3You don't need to be an expert

This is not a hacking course, and you will not be writing cryptography. You need one thing the agent does not have on its own: the judgment to say "protect this."

Once you point at a risk, the agent is genuinely good at applying the known, standard defense for it. Your job is knowing what to point at. The rest of this part hands you that list.

9.1.4Name what you're protecting

Almost every risk lands on one of four things. Name them, and you know what to hand your agent:

Protect:
- Your DATA      what you store about users
- Your ACCOUNTS  who is allowed in, and as whom
- Your SURFACES  every input a stranger can reach
- Your SECRETS   the keys that unlock everything

The next chapters take these in turn: locking the doors with real auth, guarding your surfaces against the common attacks, and running a full audit before you launch. Start by having your agent map the risks for your specific app:

Act as a senior security engineer reviewing my app
before launch. In plain language, no jargon, list the
main things I need to protect: the user data I store,
who can log in and what they can reach, the inputs a
stranger can send, and the secrets that must stay
hidden. For each, name the single biggest risk and the
standard way to defend it. Do not fix anything yet,
just give me the map.

My app and what it handles:

Do this now: paste the prompt, get your app's plain-language risk map, and keep it open as you work through the rest of this part.

Discussion

Questions, ideas, and feedback on this chapter.

Mahmoud Zalt

Mahmoud Zalt

Software engineer, 16+ yrs · built Sistava.com in 3 months, idea to production, using these methods

ExploreBook a call
Companion RepoContribute
Support me

Support my work

A small tip keeps the free work coming.

© 2026 Mahmoud Zalt. Free to read, not to republish. Copyright & license