Claude Code, Cursor and the tools we actually build with
People ask which AI coding tool we use, expecting one name. The answer is three kinds of tool, chosen per job, often all in the same week.
We build with three kinds of AI coding tool: terminal agents that work through a whole project on their own, editor assistants that help while a person edits code, and browser builders that produce a working app from a description with no setup. Each is good at a different stage. We mix them, and the choice depends on the job, not on a ranking.
Three kinds of tool, not one
As of this writing the AI coding tools fall into three families, and the names you hear (Claude Code, Cursor, Lovable and others) each belong to one of them. The families matter more than the brands, because the brands change monthly and the families have stayed put.
Terminal agents
A terminal agent runs in the command line, the plain text window that developers use to talk to a computer directly. You give it a task in English ("add a no show reason to the ride record and show it on the report") and it reads the project, edits the files, runs the checks and reports back. It can keep going on its own for a long stretch. Claude Code, from Anthropic, is the one we use most. OpenAI and Google ship tools in this family too.
What it is good for: real work on an existing project. Fixing a bug that spans several files. Adding a feature that touches the database, the screen and the email that goes out. Cloning one app into another. Because it works through the whole project rather than one file, it is the tool for most of what we ship.
Where it needs supervision: it will do exactly what you asked, at speed, so a vague request becomes a confident wrong answer. We write careful instructions, keep a rules file in every project that spells out how that project is tested and deployed, and verify the result on a live preview, not on the agent's say so.
Editor assistants
An editor assistant lives inside the program where code is written and suggests the next lines, explains a confusing section, or rewrites a block on request. Cursor is the best known. A person stays in the chair and the tool helps.
What it is good for: delicate changes where a person wants to see each line, reading an unfamiliar codebase, and the small, careful edits around money, logins and permissions. It is the tool we reach for when the question is "what does this actually do" rather than "build this."
Browser builders
A browser builder takes a description and produces a working app with a database, a login and hosting, with nothing installed on your computer. Lovable is one we have used. You type, a screen appears, you type again.
What it is good for: the very first version of something, built in front of the owner, with real data by the end of the hour. Our own operations hub started this way. Internal tools that will only ever have a few users do well here.
Where it runs out: when the app needs careful data rules, more than a couple of integrations, or a change the builder's interface does not expose. At that point the code is exported to a normal repository and the terminal agent takes over. Think of it as a sketchpad that happens to produce a real app.
Why we mix them
- A browser builder to get a working sketch in front of the client on day one.
- A terminal agent to turn the sketch into a maintained project with a proper database, tests and deployment rules.
- An editor assistant for the parts a person needs to read slowly.
- Our own eyes on a live preview, on a phone, before anything is merged. No tool replaces that step.
There is no ranking in this list because the question is never "which is best." It is "which stage is the project at, and who needs to be in the chair." A landscaper's CRM and a transit company's dispatch platform both passed through all three.
A typical week makes the mix concrete. Monday, a browser builder produces a rough inspection form in front of the operations manager, who changes her mind twice before lunch. Tuesday, the code moves into a proper repository and a terminal agent wires it to the real database, adds the login rules and writes the deployment steps. Wednesday, an editor assistant helps a person read through the photo upload code slowly, because that is the part that fails in the field. Thursday, the whole thing is on a live preview, on a driver's phone, being tried for real.
These are the tools behind every website, CRM, app and assistant we build, and the mix changes as the tools do; the habit of checking the result on the real thing does not.
Questions people ask
Do we need to know which AI tool was used to build our software?
Not really, as long as the result is plain code in a standard framework stored in your own repository. The tool is a means of writing; what matters is that the code can be read, tested and changed by whoever comes next. We note the tools used in the project documentation anyway.
Why not just use one tool for everything?
Because each kind is good at a different stage. A browser builder gets a working sketch in front of you fast, a terminal agent does the heavy work on an existing project, and an editor assistant is for the parts a person reads line by line. Using one for all three stages means fighting it at two of them.
Can we use a browser builder ourselves to make a small internal tool?
Yes, and for a tool with a handful of users and no customer data it is a reasonable way to start. When it needs to connect to your website, your customer list or a payment, export the code and have it looked at. The sketch is yours either way.
Want this done for your business?
Two minute intake. A real person reads every one and replies within a business day.
Keep reading
Vibe coding: what it is, what it is not, and what it means for your business
Vibe coding explained for owners: describing software in plain English and letting AI write it.
New softwareWe cloned a CRM for a new industry in a day. Here is how
How a CRM built for a home builder became a landscaping CRM and an advisor CRM in a day: what stayed, what changed, and why a proven core beats a blank page.
New softwareThe new age of software development: what changed and what did not
AI now writes most of the code in a software project.