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:
These are the ten lessons that have mattered most so far.
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:
That shift in mindset has probably helped me more than any clever prompt.
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.
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.
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: I try to reproduce the original failure condition and verify the new behaviour myself.
“Fixed” means: now test it.
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:
For a non-technical builder, that sense of reversibility is huge. 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:
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.
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:
The visual layer can create a false sense of completion.
A working screen is not the same thing as a working product.
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:
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.
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.
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:
That’s not a weakness.
It’s part of building responsibly.
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:
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.
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](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.
This is my personal Lovable invite link.
According to the referral offer currently shown in my Lovable account:
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.