Marcos Ambrosi.Engineering and operations advisor for service businesses
← All posts
Marcos Ambrosi

Process, not prompting: the Claude Code workflow I run

AI gives you code that runs. Not code that survives. The difference isn't the prompt. It's what goes in before the model writes, and what checks it after. Here's the whole workflow.

  • AI Engineering

Claude Code and Codex give you code that runs. Not code that survives. The difference is the process around them. What context goes in, and what reviews what comes out.

You type a prompt and wait for production-ready code. It breaks. So you write a better prompt, and then a better one after that, and forty minutes later the session is bloated, the context has rotted, and the model is confidently wrong about a file it read once.

Don't get me wrong, the models are getting insanely good. Good enough that prompting is the least of your problems. What they need is context: what the task is, what "done" looks like, what already lives in the codebase.

The stakes here are money, not aesthetics. One-shotted code ships. Then it comes back six months later as a rewrite you pay someone else to do, or, if you're an engineer, spend countless hours fixing.

Actually, the data backs this up: Veracode's 2025 GenAI Code Security Report tested more than 100 models across four languages and found that 45% of AI-generated code introduced an OWASP Top 10 vulnerability. Apiiro studied tens of thousands of repositories at large enterprises. AI-assisted developers produced 322% more privilege escalation paths and 153% more architectural design flaws, and exposed secrets nearly twice as often as their non-AI peers. The velocity everyone celebrates? Those same developers shipped 3 to 4 times more code, but generated 10 times more security findings per month. One peer-reviewed study reviewed 19 others and reached a plain conclusion: AI models introduce vulnerabilities despite the mitigations built to stop them.

None of that gets fixed with a sharper prompt. You're not going faster. You're moving the work downstream, where it costs more to fix.

For the last 20 years, software teams figured out how to ship reliable code. Requirements, tickets, code review, tests, design review. AI didn't invalidate any of that. It made it optional. Most people took that as permission to skip everything, and to treat the prompt as the whole job. That's where things break.

I've been running Claude Code for more than a year. Client work, my own products, and side experiments. Here's the workflow I've landed on (notice how little of it is about the prompt).

The setup, in one line

Linear for tickets. Fable to plan, Opus to execute, Codex to review. Playwright for tests. A custom UI/UX agent and two design skills, Impeccable and Taste, as the final pass. Conductor holds each of these in its own clean workspace.

Looks like a lot. Setup is a one-time thing. Once it's wired up, you forget it's there.

If you're not technical, here's the shape of it. Three different AI models, each doing a different job. One plans the work, one writes it, one checks it. You wouldn't let the same person design a building and sign off on its own safety inspection. Same idea. And not one of those jobs is "write a clever prompt."

Now the why.

Scope it before you build it (Linear)

This is the step that kills more bad AI output than any tool in the stack.

I don't ask Claude Code to build "a feature." I write a Linear issue with acceptance criteria, then point Claude at that specific issue.

I draft the ticket in the Claude desktop app, in a project that already has context about the codebase. I drop in a rough user story. Claude helps me shape it into something with clear acceptance criteria. Then it goes to Linear.

Here's the part that matters even if you never touch code. I have to decide what "done" looks like before anything gets built. A bounded task with clear criteria can't wander off and refactor your auth system because you asked for a settings page.

And this is the real answer to the prompt question. The acceptance criteria in that ticket does more work than any prompt ever will. People obsess over how to phrase the ask. The leverage isn't in the phrasing. It's in knowing exactly what you're asking for. Get that wrong and no prompt saves you.

Plan before you write code (Fable)

Before any code gets written, I run planning through Fable.

Opus can plan. It's more than capable, and I ran it that way for months. Fable's plans just come out more complete on the parts people skip. Test coverage. Edge cases. Implementation risks. Post-implementation tasks. Not always by a huge margin. But enough small things that the difference compounds over a week.

The lesson isn't "use Fable." It's this. Pay for the best model you can afford at the planning step. Use something cheaper to execute. For a while I planned with Opus 4.8 and executed with a lighter model. Now I plan with Fable and keep Opus for execution. Same principle either way.

Because here's what nobody spending money on AI features wants to hear. If the plan is wrong, the best model in the world will build the wrong thing beautifully. And it'll build it whether your prompt was elegant or sloppy.

So read the plan. Push back on it. Fix it before you let it run. Fixing a plan costs minutes. Fixing shipped code costs weeks.

Execute against the plan (Opus)

Once the plan is right, Opus executes. Inside Claude Code, on the ticket.

This is the one step where the prompt actually shows up. And it's the least interesting part of the process. The plan already made the hard calls. Opus just carries them out. It writes reliable code without the token cost of the top-tier planning model, which matters when you're running 8 to 10 tickets a week and paying for every one.

The one thing to watch is context. I don't have hard data on where a session starts degrading, just a year of watching it happen. My rule of thumb: I don't let it hit 100%. Around 70%, I split the ticket or start fresh. Losing two minutes to a new session beats spending an hour debugging code the model hallucinated because it forgot what was already in the codebase.

A second reviewer, every time (Codex)

Every task, before it merges, goes through the Codex plugin running inside the Claude Code CLI as a review pass.

Codex finds two or three issues per task. Every task. Some are small. Some would have shipped and broken something. The point isn't the specific issues. It's that a second model with different training catches what the first one missed. No prompt makes a single model catch its own blind spots.

Bonus: reviewing with a different provider means I'm not paying Opus to critique its own work. Lower token cost, better review.

Prove it runs (Playwright)

Claude Code writes Playwright tests as part of the ticket, then runs them via MCP to verify the feature works end to end.

This closes the loop. It's not "the model says it works." It's "the browser says it works." When Playwright fails, we don't merge. A confident prompt doesn't prove anything. A passing test does.

Review the design before it ships (UI/UX agent, Impeccable, Taste)

For anything that touches the interface, a custom subagent reviews the result from a design perspective. Hierarchy, spacing, states, accessibility basics. It's a Claude Code agent with a focused system prompt and one job.

On top of that, I run two skills. Impeccable and Taste. Both were built to stop AI from producing generic slop. Purple gradients. Inter for every font. Cards nested inside cards. Gray text on colored backgrounds. Impeccable has a detector that catches this deterministically, plus 23 commands like audit, polish, and critique that I run on every UI ticket. Taste layers stricter rules on layout, motion, and hierarchy.

Between the agent and the two skills, the UI ships looking like a designer touched it. Which, in a way, one did.

The thing holding it together (Conductor)

All of that runs inside Conductor. It lets me run multiple Claude Code sessions in separate workspaces from one machine. Each ticket gets its own workspace, its own context, its own branch.

Three parallel workstreams is my ceiling. Past that, my brain becomes the bottleneck, not the tools.

The rules underneath the stack

Strip out the tool names and the workflow is the one engineering teams have used for two decades.

Decide what "done" means before you build. Plan before you write. Give planning, execution, and review to different specialists. Prove the work with tests. Review the design before it ships.

Not one of those rules is about the prompt. AI didn't change any of them. It just made each step faster, if you're willing to set it up. The prompt sits at exactly one point in that chain, and it's downstream of every decision that actually matters.

The part that matters if you're paying for this

You don't have to do any of this yourself.

You're a founder, not an engineer. You're not going to set up Conductor or tune a context-window rule. That was never the job.

But whoever builds your AI feature should be doing something like this. And that's the part you can check, without writing a line of code. Ask them: How do you decide what "done" means before you start? What reviews the code after the model writes it? How do you know it actually runs before it ships?

If the answer is "I prompt Claude Code and it builds it," that's your money on the line. One-shotting looks fast and cheap right up until the rebuild.

I show my work like this so you can tell the difference when you see it. Before I spent six figures on something I couldn't evaluate myself, that's exactly what I'd want to know.

Sources

Written by

Marcos Ambrosi

Engineering and operations advisor for service businesses. Sixteen years building software and leading teams, based in Montevideo.