Process first, tool second: why your AI workflow matters more than your AI tool

Why "which AI tool?" is the wrong first question

Most conversations about AI at work start with tools: Claude Code or Codex, ChatGPT or Gemini, Cursor or something else. It's an easy question to ask and an easy one to argue about. But when a team says "AI didn't work for us", the cause is almost never the tool. It's that nobody decided what "done" looked like, the whole job was handed over at once, or nobody checked the result.

Developers using these tools every day reached the same conclusion. In a widely discussed r/ClaudeAI thread titled "Vibecoding is no more about models", the poster argues that a better model still fails if you hand it a whole app in one go, and the discussion's own summary agrees that the workflow matters more than the model. One line from another thread puts it shortest: The spec is the entire game.

What our own tests showed

We've published three tests this month. Different tools and tasks, same pattern:

• Seven office jobs in Claude Code. Numbers came out exactly right when the request said "calculate and show the figures you used". Two of the seven jobs had a mistake that a quick human check caught. The checking step, not the tool, is what made the output safe. The seven jobs.
• The same research question in four assistants. Three gave three different customer counts for the same company; one matched the company's filing. The step that caught it wasn't a better tool; it was "check key figures against the source". The comparison.
• One written spec for a content workflow. From two customer calls and one page of instructions, the AI produced an insight bank, a plan, five pieces and a quote check, with all 11 quotes verified and nothing invented. The rules in the spec did that. The spec and the result.

What real teams say

• Vague in, junk out. A product manager with 20 years' experience, who has never written production code, describes a vague request producing junk, and a field-by-field spec producing something they'd pay for. Their estimate: building is about 20% of the time; specifying and checking is the rest.
• Small steps beat big asks. After six months of daily use, one Claude Code user's main advice is to plan first and then do one step at a time; asking it to "implement the whole feature" is where sessions go wrong.
• Nobody watching is expensive. One team reports a $1,400 bill in one hour after an agent looped on a repetitive task with no one checking. Commenters describe it as a known agent failure, not a single tool's bug.
• The people running automations for clients talk about process. An automation agency's lessons are about retries, a log of every run, and telling the client the same day something breaks. Not about which model.

When the tool does matter

It would be dishonest to say tools are interchangeable. They aren't, and the same forums show it:

• Cost and limits. One user who left Cursor for Codex says their workflow hadn't changed; the usage cap and extra bill had.
• Speed. Some users find one agent slower than another on the same kind of task.
• Current facts. In our comparison, the search-first tool was the only one that found recent news and matched the filing.
• Where your files and data are. If your team lives in Google Workspace or Microsoft 365, the tool that connects to it is the practical choice.

So the honest rule is: the process decides the outcome; the tool decides speed, cost and convenience. A good process also makes the tool replaceable. If you change tools next year, the spec, the checks and the approval step come with you.

Our order: outcome, use case, process, tool

1. Outcome: what changes for the business, and how you'll know (for example, "a five-bullet report every Monday at nine, numbers shown").
2. Use case: the specific task, who does it today, and how often.
3. Process: the steps, the rules, where AI helps and where a simple rule is better, the checks, and who approves.
4. Tool: whichever fits your plans, your data and your budget, very often one you already pay for.

That's how every project we take on runs. See how it works.

What to do before you pick a tool

• Write the outcome in one sentence.
• List today's steps for one task, in order.
• Decide what the output looks like and what "done" means.
• Write down what it must never do (invent figures, email clients, touch certain folders).
• Decide who checks the result, and how fast they can check it.

Then pick the tool. The full 6-step method, with a worked example.

Common questions