The hard part turned out not to be writing code. It was learning what to trust, what to test, and when to stop.
I’m not a traditional developer.
I didn’t start with a computer science background, years of coding experience or a mental model of how every layer of a modern app fits together.
I started with an idea and AI tools that suddenly made building software feel accessible.
That part was exciting.
The more interesting part came later.
Because after the first few successful prompts, I realised the hard part wasn’t getting AI to generate something.
The hard part was learning:
- what to trust;
- what to test;
- what to leave alone;
- when to slow down;
- when to stop prompting;
- and when I was clearly outside my depth.
These are the ten lessons that have mattered most so far.
1. AI removes the syntax barrier, not the judgment barrier
AI can write code I couldn’t write myself.
That’s enormously empowering.
But it doesn’t decide whether the product behaviour makes sense.
It doesn’t know whether a feature is actually needed.
And it doesn’t take responsibility for the consequences if something is wrong.
The more I build, the more I see the distinction like this:
AI can generate the implementation. I still own the judgment.
That includes:
- deciding what should happen;
- recognising when the output is wrong;
- testing whether it actually works;
- noticing unintended side effects;
- knowing when a technical decision deserves a second opinion.
That shift in mindset has probably helped me more than any clever prompt.
2. Small, testable slices beat ambitious prompts
Early on, it’s very tempting to ask:
Build the entire user flow.
or:
Add profiles, matching, messaging, notifications and payments.
AI can often generate something impressive from that.
But the larger the change, the harder it becomes to know exactly what broke when something goes wrong.
Now I prefer:
one behaviour → one success condition → one test
Then move on.
It feels slower.
It usually isn’t.
Thin slices make debugging easier, rollback easier and unexpected side effects much easier to spot.
3. Tell the AI what must NOT change
This turned out to be one of the most useful habits.
Instead of:
Change the onboarding screen.
I try to write:
Change only the onboarding screen. Do not modify authentication, navigation, database structure, existing mobile behaviour or any unrelated components.
AI builders are extremely good at changing things.
Sometimes they are a little too good at it.
Defining boundaries is often just as important as defining the feature.
4. “Fixed” is a claim, not proof
This one sounds obvious until you’ve watched an AI confidently announce:
Fixed.
…and then discovered that the bug still exists.
Or that the original bug is gone but something else quietly broke.
I’ve learned not to treat the AI’s status message as evidence.
The evidence is the test.
If a problem involved:
- access permissions;
- user data;
- a specific interaction;
- persistence;
- authentication;
- cross-user visibility;
I try to reproduce the original failure condition and verify the new behaviour myself.
“Fixed” means: now test it.
5. GitHub is not just “developer stuff”
At first, Git felt like infrastructure I wasn’t qualified to understand.
Now I think of it much more simply:
Git is a history of what changed and a way back to a known-good state.
That’s incredibly valuable when an AI can modify a lot of code very quickly.
My basic habit now is:
- keep the project synced;
- know what the last working state was;
- checkpoint before larger changes;
- keep changes narrow enough that I can understand what happened.
For a non-technical builder, that sense of reversibility is huge.
6. Stop prompting when you enter a repair loop
There’s a very specific failure pattern:
fix → break → fix → regression → another fix
At some point, continuing to prompt is not progress.
It’s gambling.
When I notice the same area breaking repeatedly, I stop and reframe the problem.
I try to write down:
- what currently happens;
- what should happen;
- what must remain untouched;
- what has already been tried;
- what changed just before the problem appeared.
Then I restart from a clean description instead of piling another repair prompt on top.
That alone has saved me a lot of wasted iterations.
7. Test behaviour, not appearances
One of the dangerous things about AI-built apps is how finished they can look.
A screen can be polished, responsive and convincing while important behaviour underneath is still fragile.
So I try to test journeys rather than screenshots.
For example:
create account → sign in → perform action → save data → leave → return → verify state
I also try:
- refreshing;
- bad input;
- a second user;
- mobile;
- permissions;
- edge cases.
The visual layer can create a false sense of completion.
A working screen is not the same thing as a working product.
8. Some areas are red zones
There are parts of an app where I’m happy to experiment quickly.
There are others where I deliberately slow down.
My current red zones are:
- authentication;
- permissions;
- real user data;
- payments;
- database changes;
- production deployment;
- secrets and credentials;
- anything security-sensitive.
That doesn’t mean AI can’t help there.
It means I don’t want the AI that built the thing to be the only thing telling me it is safe.
At some point, independent review becomes part of responsible building.
9. Don’t build everything AI makes easy
AI creates a strange temptation.
Because adding a feature feels cheap, you start adding features because you can.
That’s dangerous.
A multi-user mode, permissions system, audit log, notification engine or advanced dashboard may be technically possible in an afternoon.
That doesn’t mean the product needs it.
One of the best habits I’m developing is keeping a mental “not yet” list.
If no real user has created the need yet, I try not to solve the hypothetical problem.
AI makes overbuilding easier than ever.
That makes restraint more valuable, not less.
10. Learn when you’re outside your depth
This may be the most important one.
AI makes it possible to go much further without traditional technical skills.
But confidence can grow faster than competence.
I’ve learned to watch for moments where I stop understanding what I’m approving.
That’s usually a signal to slow down.
Being a non-technical builder doesn’t mean pretending everything is understandable.
It means learning:
- what I can safely validate;
- what I need help with;
- where independent review matters;
- when “I don’t know” is the correct technical decision.
That’s not a weakness.
It’s part of building responsibly.
What I would tell another non-developer
You don’t need to become a traditional programmer before AI becomes useful.
But the more serious your product becomes, the more important it is to develop a different set of skills:
- scope discipline;
- verification;
- version control;
- product judgment;
- risk awareness;
- knowing when to ask for help.
AI can remove a lot of friction from software development.
It does not remove responsibility.
And oddly enough, that’s what makes building with it interesting.
Want to try Lovable with 10 extra credits?
I’ve learned most of this while building with Lovable and making plenty of mistakes along the way.
If you’re new to Lovable and want to experiment with it yourself, my current invite gives new users 10 extra credits:
https://lovable.dev/invite/SDWBXFW
Use them on something small enough that you can actually understand what changed.
That’s probably more valuable than trying to build the whole idea in one shot.
Referral disclosure
This is my personal Lovable invite link.
According to the referral offer currently shown in my Lovable account:
- you receive 10 extra credits when signing up through the invite;
- I receive 100 Lovable credits if you later subscribe to a Pro plan with at least 100 credits/month.
Your subscription does not cost more because of the referral.
I use Lovable myself, and any referral credits help fund more building, testing and experimentation.
Top comments (0)