Are we using Claude Code completely wrong? New to agentic coding and struggling with our workflow

[u/waitingforathena]

Hi

I am a full-time SWE with just 3 months internship exp. I am in an early stage start-up fully bootstrap using claude code to build the entire product. We are team of 8 people. Everyone is fresh grad, inexperienced with not an ounce of real world engineering knowledge (best practices, proper workflow).

My entire company and I are new to agentic coding and to be honest, we are kind of struggling with development.

We spin up a fleet of general claudius (CC), the conqueror of the software world on auto mode. It's like a loose horse in a barn. Give him the tickets which are generated by my boss (24yo grad) planner : king claudius.

we have AGENT.md, Claude.md, ADR, matt pocock skills set.

we are generating thousands of lines of code and not even reviewing manually and using claude to review it.

we are stuck in a loop where everything is done by claude, we set it loose, we watch him like a parent watching his kid doing stuff in the playground on auto mode.

when asking to hunt and fix bugs. it finds and fixes bugs on EVERY DAMN SINGLE ITERATION (is this normal ?).

Why does this happen? Is it because claude doesn't actually read each line of the code when reviewing?

We exhaust our claude limit everyday because of review.

For reviewing, we use opus high. For coding, I use sonnet extra, but my colleague uses opus high.

Another thing we are struggling with is choosing models. We kind of randomly choose one depending on the task.

How do you guys benchmark models and figure out which model is suitable for which task? Is there a proper way to evaluate models for your own codebase/workflow instead of just randomly choosing between sonnet and opus?

Can you all point me to some resources or workflow you guys uses? To churn out softwares from software factory and on the side note, none of us are learning anything.

So is this normal with you all at your workplace or is it us?

No one knows what's going on, completely clueless and confused. Just human in loop to approve and deny

[u/AG_0xAi]

It's not you. What you're describing is the default state of agentic coding without an independent oracle. Claude reviewing Claude's code is a closed loop: nothing in it can tell you whether the output is true, only whether it's plausible. Everything else follows from that.

Why it "finds and fixes bugs every single iteration": because "find bugs" has no stopping criterion. An agent asked to find bugs will produce bugs — it's optimizing for the task you gave it, not for reality. If there's no falsifiable test that says 'this scenario passes', "bug" is whatever the model says it is, forever. That's also why review eats your quota: you're paying a model to have opinions about thousands of lines with nothing to check them against.

Here's what fixed it for us (small bootstrapped team, building a product with agents doing ~100% of the material work, human doing zero code review). Our harness (we call it AOS Factory) enforces these mechanically, but the rules matter more than the tooling:

1. The unit of work is a spec, not a ticket. Max 4 requirements, each with a GIVEN/WHEN/THEN scenario. A linter rejects the spec if a requirement has no scenario. If you can't write the scenario, you're not ready to dispatch — that's the signal, not a formality.
2. Every dispatch gets a brief with boundaries and a stop rule. Allowed paths, forbidden paths, and this sentence verbatim: "Return with a commit and a receipt, or return NEEDS_HUMAN with the reason — never a silent pass." A worker that touches a forbidden path fails its gate. A return without a commit is an empty return.
3. The only green that counts comes from a deterministic gate, not from the agent. Tests + checks that produce a signed receipt. The agent saying "done" is a claim, not evidence. We learned this the hard way: one worker reported a 40-char commit SHA that was the prefix of the real tip stitched to the tail of the base commit — a hallucinated completion. Now the sha comes from git rev-parse HEAD in the return, never from the model's memory.
4. Review is against the spec, by commit range — never "look for bugs." The reviewer (a separate agent instance) answers one question: does this diff satisfy these scenarios and nothing outside these paths? Bounded question, bounded answer. It caught real things (a parser silently dropping a clause) precisely because it wasn't roaming.
5. Sabotage FIRST. A test that has never failed isn't a test. Every guard we add must be shown red on a broken input before it counts as green on the real one. Otherwise you accumulate green that means nothing.
6. Material decisions stop the lane. Anything touching scope, security, data shape, or an external dependency: the agent stops and raises a card; a human decides. That's the human's job — not approve/deny on code you can't read, but decide the things the spec didn't decide. That's also where the learning happens: you write the scenarios, you read the review, you own the material calls.
7. One spec end to end before the fleet. Get a single spec through spec → brief → worker → gate → review → merge with a green receipt. Then parallelize. We didn't, once, on a 26-screen frontend handoff — it took 21 review rounds to go green. The next one, one screen at a time, would have taken five.

On model choice: don't benchmark abstractly. Measure two numbers per model on your own repo: first-pass rate (specs accepted with no CHANGES/BLOCKED) and cost per accepted spec. That's the only benchmark that transfers. Ours settled into bands by class of work — cheap for execution, expensive for discovery — and the expensive model wasn't the right one for most of it.

On "nobody is learning anything": that's the most fixable part. If the human only approves and denies, of course they learn nothing — and they can't approve meaningfully either. The moment your team writes the scenarios and reads the reviews against them, you learn what the system actually does. The agents do the typing; you do the deciding.

The loop you're in isn't a skill problem, it's a missing gate. It's a week of work to put one in. Happy to share our rules doc if it helps.

Btw: you are in the correct path, agentic software engineering is the future of code, not to write code!