How not to burn through tokens when building with AI?

I strongly recommend doing the architecture before writing any code. Without it, you shouldn’t start at all. You won’t nail it on the first try anyway: every model has hallucinations and context-window limits. Even the simplest app needs a lot of context. What I’d do: draft the architecture in free models with big context windows (Gemini or Qwen). Then run that same architecture through other models and ask them to critique it and suggest what’s missing, based on the original task.

It helps to understand what a database is for and what types exist. For example, SQLite is super convenient (easy to inspect data visually) but it’s not great for concurrent writes. If multiple users try to save data at the same time, someone will hit a failure. Also: whether it’s safe to edit a live database manually is a big deal — one wrong move can corrupt data.

Frontend is what you (or the client) see. Backend is the logic hidden from users — like a car engine. Something is noisy and running and the car moves. The front is the steering wheel and buttons, the back is the engine, transmission, gearbox, electrics.

If you’re a vibe-coder, it’s usually better to ask for Python. It’s not perfect and it’s not for every task, but it’s the most common language and the AI is very confident with it. Models learn from open data; Python simply has the most of it. Dataset research for code models often shows Python at ~30–40% of repos, which correlates with generation quality. GitHub Octoverse confirms Python’s popularity, and papers/articles around CodeLlama/Codex show it dominating HumanEval-style benchmarks.

If your program must run 24/7 (not only when your laptop is on), you’ll have to move it to a remote (virtual) server — basically another computer that’s always on. All virtual servers cost money. Plan this step in advance.

I strongly recommend keeping your code on GitHub. It’s free, always accessible, and easy to copy anywhere. The best part for vibe-coding: you can roll back a few steps if the result of the next “flavor” turned out bad. And yes — after each prompt that changes the code, it’s better to commit, otherwise you won’t be able to roll back when things go sideways.

Testing is the most boring stage, in my opinion. You may need several different accounts. Just because it works for you doesn’t mean it will work for other people.

It’s good to roughly understand what a domain is, what an IP address is, what hosting is, and what DNS is (not an electronics store). It’s not a simple topic, but if you’re going to build a website, expose a service to the internet, or ship an app — you need the basics.

You should understand that AI is good at frontend and UI design, but it doesn’t give you a real “choice”: it will do what it thinks is right, and you’ll be stuck with it. Explaining “make it prettier” is hard because everyone’s taste is different — and a machine doesn’t really have taste. So you’ve got four options: keep it as-is, ask it to redo it, ask another model for a different design, or learn Figma yourself. But if you start with zero design skills, that alone won’t magically fix it.