Building AI Apps Like an Engineer: I’m Learning the Path, and Checking Whether My AI Follows It

An introduction to a new series. I’m learning the process software engineers follow, checking whether AI builders follow it too, and testing which guardrails make them.

Two sentences come up almost every time AI-built apps are mentioned.

From developers, IT teams and investors: “AI-built apps are half-built. Messy, insecure, not real software.”

From almost everyone else: “I don’t understand any of this. Everyone’s talking about vibe coding and I feel left behind.”

I’ve heard both. I’ve felt the second one myself. So I’ve decided to find out for myself whether the first one is true, and whether it has to be.

The question I’m trying to answer

If I learn how a software engineer builds an app properly, can I get an AI builder to build it that way too?

Not “can AI write code”. It clearly can. The real question is whether it follows the same path an engineer follows: the planning, the checks, the testing, the care after launch. And if it doesn’t, what guardrails make it?

That’s what this series is: my notes as I learn the path, check the AI against it, and test what works.

Why the question matters

Building an app has never been easier. Lovable, Replit, Bolt, Cursor and others turn an idea into a working app in an afternoon. They’re also growing fast, adding hosting, databases, logins, payments and even their own security checks.

But the worries aren’t made up. In May, a security firm called RedAccess reported finding about 380,000 publicly reachable apps built on Lovable, Base44, Netlify and Replit. Around 5,000 of them exposed sensitive information, including business records and personal details. (Axios, Security Boulevard)

What struck me most: nobody hacked those apps. Most were simply left open, public when they should have been private. That isn’t a clever attack. It’s a step in the process that never happened.

Which made me wonder how many other steps get skipped.

What I’ve learned so far: the path

The first thing I learned is that engineers don’t just write code. They follow a process, and writing code is only one stage of it. Here’s the path as I understand it so far:

• Rules: agree how the work will be done before it starts.
• Requirements: who it’s for, what data it holds, what it won’t do yet.
• Architecture: which parts run on the user’s screen and which run on a server you control. (This is where most leaks seem to start.)
• Build: keep secrets secret, check permissions in the right place, make small changes.
• Test: prove it works, including when things go wrong or someone tries what they shouldn’t.
• Release: go live in a way you can undo.
• Operate: know when something breaks, before your users tell you.
• Maintain: keep it healthy, because an app that’s safe in January can be unsafe in June without you changing a thing.

And at every stage, engineers ask three questions:

• What could go wrong?
• How would I know if it did?
• How do I undo it?

My hunch (to be tested)

Here’s the honest part. My hunch is that AI builders are very good at one stage, writing the code, and quietly skip a lot of the others. Not because they can’t do them, but because nobody asks them to.

I’ve seen small signs of it already. When I asked a builder to fix a security problem, it told me it was done. It was, inside the builder. But the fix hadn’t reached GitHub, so as far as everything else could see, nothing had changed. “Done” and “done properly” weren’t the same thing.

If the hunch is right, the problem with AI-built apps isn’t the AI. It’s the missing half of the process. And that should be fixable by someone who learns the process, even without writing the code themselves.

But a hunch isn’t a finding. So I’m going to check.

How I’ll check

For each stage of the path, I’ll do the same four things:

1. Learn it. What does an engineer actually do at this stage, and why? In plain English, with every term explained.
2. Watch the AI. Give an AI builder a normal request and see whether it does that stage on its own.
3. Add a guardrail. If it skips the stage, try a guardrail: a standing rule in the builder’s instructions, a question to ask at the right moment, or an outside check.
4. Check the guardrail held. Not “the AI said it did it”, but evidence that it actually did.

I’ll report what I find, including when the AI does better than I expected, and when a guardrail I liked doesn’t work.

The guardrails I’m starting with

These are my starting ideas. Part of the point is finding out which ones work.

• A rules file. Most builders let you give standing instructions that are read before every change. Lovable calls it Knowledge, Cursor has Rules, Claude Code reads a CLAUDE.md file. I want to know whether a good rules file can make an AI follow the engineer’s path by default.
• The right question at the right moment. For example, before building: “What data does this app store, and what happens if it leaks?” Or after a change: “Show me the test that proves this works for the wrong user too.”
• An outside check. Something that looks at the result without trusting the builder’s word. Some platforms now check their own work. Lovable, for example, runs a quick security scan every time you publish, and its own documentation says those scans don’t replace a thorough security review (Lovable docs). That’s where my own tool, Verilay, comes in: an independent second look at the code and the live site. I’ll be clear about what it can and can’t check, the same as any other tool.
• A human, at the right moments. Engineers have their work reviewed by other engineers as normal practice. I want to find out when that second pair of human eyes matters most.

Who might find this useful

If you’ve never built anything and feel left out of the conversation: you’re learning alongside me. Every term gets explained. No question is too basic.

If you’ve built an app with AI and quietly wonder whether it’s “proper”: you can run the same checks on your own app as I go.

If you’re a developer, in IT, or an investor and you’re sceptical: I’d genuinely value you checking my work. If I’ve misunderstood how engineers do something, tell me.

What’s coming

Roughly in this order, though your questions may change it:

• Start here: how software gets built, explained from the beginning
• A plain-English glossary, growing with each post
• The rules file: can one setting make an AI builder follow the engineer’s path?
• The open database: why it keeps happening, and what catches it
• “It works” vs “it’s done”: what proof should look like
• Who checks what: AI code reviewers, security scanners, penetration testing and human engineers
• When a human engineer is worth it, and why it’s not about distrusting AI
• Choosing an AI app builder: the questions that actually matter
• Day 30: what happens after an app goes live

Tell me where to start

Which question would you most like answered first? Email me at [email protected].

And if you feel left behind by all of this: so did I. That’s why I’m writing it down.