Coding Agents for Non-Devs, Level 2

First-tier coding-agent work — an agent that organizes your files, renames things, or processes a folder of receipts — treats the agent as a very capable operator on top of your existing tools. Level 2 is a different leap entirely: the agent builds a small working application from scratch, with its own data and its own screens.

This isn't about becoming a developer. It's about learning to describe a small piece of software precisely enough that a builder tool can produce it, and precisely enough that you can tell when it's wrong.

Three pieces cover almost every non-dev build. Lovable takes a plain-English description and produces a working app with screens and logic. Supabase is where the data actually lives — think of it as the spreadsheet underneath the app, with real structure. Cursor is for when you want to see or hand-edit the underlying code directly, which becomes useful once you outgrow pure description-based building.

Most small internal tools never need Cursor at all. It's there for the moment you need more control than describing-and-correcting gives you.

The scoping rule that separates shipped tools from abandoned ones: one job, one table-ish data model, five screens or fewer. A candidate tracker's job is pipeline visibility, not email automation, not interview scheduling — those stay in existing tools. The tighter the scope, the more likely the tool actually gets built and actually gets used.

Write the one-job statement in a single sentence before opening Lovable. If you can't state the job in one sentence, the scope isn't ready yet.

Building with Lovable is a loop, not a single generation: describe what you want, click through the result, correct what's wrong, repeat. This is sometimes called vibe-building, but the discipline matters — each correction should be specific ("the stage dropdown should have these five values") rather than vague ("make it better").

Expect several rounds. The loop converges fastest when you test with real data early instead of placeholder text.

Design your table or tables in plain English before generating any screen. For a candidate tracker: candidates, with fields for name, role, stage, source, notes, and next_step_date. Naming the fields and their types up front prevents the single most common failure mode — generating a pretty screen on top of a data model that doesn't actually support the job it's supposed to do.

Once the data model is right, screens follow naturally: a pipeline board, a detail view, and a filtered list are just different views onto the same table.

Before anyone else touches the tool, run a short checklist: who can see all records versus only their own, who can edit versus only view, and what happens if two people edit the same record at once. These questions are easy to skip when you're the only user and expensive to discover later once colleagues depend on the tool.

Test with a second user early — even one colleague using the tool for a day will surface permission gaps that solo testing never will.

Internal tools built this way need light but real maintenance: know how to export your data, keep a backup habit, and recognize the signs you've outgrown the tool — heavier reporting needs, more than a handful of concurrent editors, or logic too complex to describe your way through. None of these are failures; they're signals to graduate to a more purpose-built tool or bring in a developer.

The 80% trap is the one to watch for specifically: generated apps get impressively far, then stall on auth, permissions, or data migrations that a non-dev can't easily debug. Keeping the data model simple is the best insurance against hitting that wall hard.

Not every recurring need justifies a custom tool. If an existing product already does the job — a CRM, a project tracker, a form builder — buying beats building, even for a non-dev empowered by AI. Building makes sense when the job is specific enough that no off-the-shelf tool fits it cleanly and simple enough to stay inside the one-job, five-screen bound.

The honest test: if you can't describe why the existing tools don't fit in one sentence, buy instead of build.