Building NonDevPilot - Lovable for existing projects

jun 8, 2026

2 min read

Chapter 1: The question

i was using cursor.
and claude code.
and codex.

and they all seemed to just… know my codebase.

ask about a function buried in some file it knows.

and one day a dumb little question hit me:

wait.
does it read all my code every time?

because if it does…
that’s a LOT of tokens.

a real repo is huge.
sending all of it on every message would cost a fortune
and be painfully slow.

so either these tools are burning money on every keystroke,

or i was missing something.

i was missing something.

Chapter 2: The answer

turns out - no.
they don’t send your whole code.

not even close.

they’re way smarter than that.

some of them index the repo once
break it into pieces,
understand how things connect,
and only pull in the bits relevant to what you asked.

some just read files on demand
they look at a map of the project first,
then open the two files they actually need.

different methods, same idea:

never send everything.
send the minimum.

that’s the whole game.
knowledge graphs, embeddings, retrieval, token budgets...

all of it exists for one reason:
keep the context tiny.

Chapter 3: Where i got the idea

i came across sparkles.dev
and got obsessed with how something like that works under the hood.

connect a repo,
talk to it,
it changes your code.

how?
how does it not cost insane money?
how does it run a stranger’s code safely?

i didn’t want to just read about it.

i wanted to build it to actually understand it.

Chapter 4: So i built NonDevPilot

lovable, but for the projects you already have.

connect github → describe a change → see it live → get a pull request.

did i build everything?

no.

the fancy stuff — the full knowledge graph, the multi-agent pipeline — that’s still roadmap.

but building the core taught me more than any tutorial could.

i learnt how to:

give the AI a map instead of the whole repo
let it read only what it needs
run untrusted code in an isolated sandbox so it can’t touch my machine
turn its edits into a real PR

and somewhere in there it clicked

i finally understand how the big companies build these products.

Chapter 5: The real lesson

here’s the thing nobody tells you:

plugging an AI into code is easy.

that’s a weekend.
an API key and a prompt.

the actual engineering is everything around it:

saving tokens and cost so it scales without bleeding money
security : running code you don’t trust, safely, in isolation

that’s the hard part.
that’s the part that separates a demo from a product.

the “connecting AI to code” bit?
anyone can do that now.

the real work is making it cheap, fast, and safe.

Final thoughts

i haven’t implemented all of it.

but now i know how it’s done.

and honestly that was the whole goal.

build it to understand it.

i’ll keep implementing the rest the indexing, the agents, the validation
piece by piece.

but the mental model is there now.

and that’s worth more than the code.

You can see the demo here.