DEV Community: Cody

10 Things I Learned Building With AI as a Non-Developer

Cody — Sat, 29 Aug 2026 22:39:45 +0000

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.

Invite:

https://lovable.dev/invite/SDWBXFW

10 Lovable Credits for New Users — and How Not to Waste Them

Cody — Wed, 26 Aug 2026 13:06:23 +0000

I’m not a traditional developer.

I’m learning to build software by actually building with AI tools — and Lovable has become one of the tools I use most.

One thing became obvious surprisingly quickly:

Getting more AI credits is useful. Learning not to waste them is much more useful.

So if you’re just starting with Lovable, here are the lessons I wish I had known before using my first serious batch of credits.

And if you haven’t created an account yet, my current invite gives new users 10 extra Lovable credits:

👉 https://lovable.dev/invite/SDWBXFW

More on that — including what I get from the referral — at the bottom.

1. Don’t start by asking Lovable to “build my app”

The tempting first prompt is something like:

Build me a platform for X with authentication, profiles, payments, a dashboard and a beautiful responsive interface.

It feels efficient.

It usually isn’t.

The larger the instruction, the more assumptions the AI has to make. Every wrong assumption becomes something you’ll have to repair later.

Start by defining:

what the product must actually do;
what the main entities are;
what the first user journey looks like;
what absolutely does not need to exist yet.

Then build one meaningful slice at a time.

2. Separate thinking from building

One of my most useful habits is not asking the coding tool to solve every product question while it is also writing code.

First decide what you want.

Then ask Lovable to implement it.

For a larger feature, I often work in this order:

problem → specification → implementation → test → refinement

That extra thinking step can save several rounds of rebuilding.

3. Tell it what must remain untouched

This is a surprisingly powerful addition to prompts.

Instead of:

Change the profile card.

Try:

Change only the profile card. Do not alter navigation, authentication, database structure or the existing mobile layout.

AI development tools are very good at changing things.

Sometimes they’re a little too enthusiastic about it.

Defining boundaries reduces accidental regressions.

4. One clear objective beats five repair prompts

When something doesn’t work, it’s tempting to keep throwing little correction prompts at it.

That can create a loop:

fix → new problem → fix → regression → another fix

When that happens, stop.

Describe:

the current behaviour;
the desired behaviour;
the relevant constraints;
what has already been tried.

Then solve the underlying problem once.

5. Functional first, beautiful second

It is incredibly easy to spend credits tweaking:

spacing;
border radii;
gradients;
button positions;
typography;
tiny responsive details.

Those things matter.

But not before your important flows actually work.

My preferred order is:

architecture → functionality → reliability → usability → visual polish

Otherwise you may lovingly polish a screen that gets rebuilt two days later.

6. Make big changes deliberately

Before a significant change, know how you can get back to a working state.

Version control is not something only “real developers” need.

AI-assisted building actually makes it more important, because large amounts of code can change very quickly.

Before a risky change:

make sure the current version works;
commit or checkpoint it;
define the scope of the next change;
test immediately afterwards.

Being able to undo a bad idea is a feature.

7. Don’t confuse “the page looks right” with “the product works”

A generated interface can look remarkably finished while important things underneath are still incomplete.

Test the actual user journey.

For example:

create account → sign in → perform core action → save data → return later → find it again

Click the boring buttons.

Try bad input.

Refresh the page.

Use mobile.

Use a different account.

The last 20% of building often contains 80% of the things users will eventually complain about.

8. Treat your database as part of the product

For non-developers, the visual interface is much easier to understand than the data model underneath it.

That makes it tempting to postpone database thinking.

Don’t.

Before adding lots of features, understand at least:

what data you’re storing;
which data belongs to which user;
which relationships exist;
what users may read;
what users may change;
what should never be exposed.

A beautiful application sitting on a confused data model becomes painful surprisingly quickly.

9. Use another AI as a thinking partner

A coding agent doesn’t have to be your only AI.

For complicated changes, I often find it useful to work out the logic separately first and then give the builder a much cleaner instruction.

In other words:

use one AI to think with you and another to build with you.

The better your specification becomes, the less expensive experimentation tends to become.

10. Spend credits on learning, not just output

Some “failed” prompts aren’t actually wasted credits.

If a failed attempt teaches you:

how your application is structured;
why a certain approach breaks;
how authentication works;
how your database behaves;
how to write a better specification;

then you’re becoming a better builder.

The real waste is repeatedly making the same mistake without changing your process.

That’s why I keep small notes about what worked and what didn’t.

Over time, those notes become your own development playbook.

Want 10 extra Lovable credits?

If you’re new to Lovable and were planning to experiment with it anyway, my current invite gives new users 10 extra credits:

👉 https://lovable.dev/invite/SDWBXFW

Use them to build something small enough that you can understand what is happening.

Then build the next piece.

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 subsequently subscribe to a Pro plan with 100 credits/month or more.

It doesn’t make your subscription more expensive.

I’m sharing the link because I use Lovable myself, and the referral credits help fund further building and experimentation.

If that arrangement works for you, feel free to use it:

https://lovable.dev/invite/SDWBXFW

Happy building.

lovable #vibecoding #ai #webdev