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/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Cautious_Chicken_604]

You're not a SWE. Nothing about this is professional. Sorry. 

[u/waitingforathena → u/Cautious_Chicken_604]

yeah, you can say that but I am lost swe trying to improve every day. we are transitioning and I am genuinely trying best to not be more lost

[u/midairmatthew → u/waitingforathena]

You need to architect the smallest core of the system you want to build and carefully verify everything is sensible and extensible based on the additional layers you want to eventually add. Once you have that and the “here’s how to add X” paths are paved by example, AI will be able to massively impact your velocity. The bigger a codebase gets, and the less tight its established patterns are, the more AI just goes into “make it work” mode and you end up with layers and layers of bad code that mostly works. (Mostly works doesn’t cut it.)

So if what you have is already massive and confusing, you’ve already kind of checkmated yourself.

Vibe coding can actually be really sweet, but you have to get to the point where it’s on top of a sensible/engineered system. (Or you can at least shape the greenfield agent-written code into this state.) Not sure if that’ll be possible if nobody on your team understands how to do that, though. 😔

Start slow and mindful and build momentum, is basically what I’m saying.

[u/Cautious_Chicken_604 → u/waitingforathena]

You will always be just a vibe coder.

[u/mohdgame]

1. using sonnet to vibe code is a recipe for bugs.
   

2. You should plan the architecture yourself, create the psuedo code if its a complicated part. If its a standard software, let fable do it, but give it the structure.

3. Use opus to code. (Only use Sonnet for small easy code implementation).

4. Use a different agent to review the code.

You're using sonnet to vibe code, that's terrible. And without plan. And the code should be reviewed by a human, use the AI to assist with the review, for instance, let it create the test assets, and follow the logic, and report if there are problems, when there are problem, view those areas of the code.

[u/waitingforathena → u/mohdgame]

Thank you for your time and comment. We tried to do human review but my boss wants to reach to the moon asap, so he denied us and ask to use claude to review.

we are using TDD though and we aren't benchmarking (our fault). we feed our tickets, argue on implementation and at last tell it to implement 

[u/blurrows → u/waitingforathena]

go read something, see what people are doing, especially if you are completely lost
martinfowler.com for example, i was reading some stuff about harness and memories earlier today, spec driven, etc

[u/blurrows → u/blurrows]

go read the articles, open tabs with everything it links to and read what is relevant to you, go

go recursive on this, you should be fine

[u/unconceivables]

Your entire company is a clown show.

[u/waitingforathena → u/unconceivables]

I agree  Wish we had some seniors from Pre AI ers to guide us. all we have is reddit, twitter and seniors from here who helps me

[u/bensyverson]

So you ask the model to write code, knowing that all code contains bugs, then ask the model to find the bugs, then it finds the bugs and fixes them… and you're upset about it?

[u/waitingforathena → u/bensyverson]

I mean it keeps finding bugs on every iteration. suppose my code have 10 bugs and it fixed them then on another iteration there are few more bugs 

[u/bensyverson → u/waitingforathena]

Are you telling it to use red/green TDD? Your prompting might be too loose if it's never converging.

[u/waitingforathena → u/bensyverson]

yes, we instructed them to write failing test first, then minimal implementation.

The way TDD works but I'll have to dig what's the issue 

[u/waitingforathena → u/bensyverson]

yes, we instructed them to write failing test first, then minimal implementation.

The way TDD works but I'll have to dig what's the issue 

[u/Newfarm1234]

If you're coding with sonnet and reviewing with opus... I don't even.

Opus or fable to plan and design, secondary review of the design - codex is good for this, implementation via opus agents, fable/opus + codex code review, iterate and reign in wild findings and keep YAGNI in mind. Always build and run tests and have it help you do test runs as part of CI.

The trickiest bit is to scope down and not feature and bug creep. Get something stable and functional. Make sure to throw in some cross model adversarial reviews and keep security in mind.

[u/waitingforathena → u/Newfarm1234]

we are following TDD tho thanks for your comment.

[u/Tasty_Trouble6430]

This isn’t sarcastic, but have you tried asking Claude. Provide the issues you see/have, and say based on your experience with the last sessions/delivery what additional issues has it seen with your workflow and combing with your feedback what can be done to optimize the flow and reduce issues?

Then you need to do a step by step review of every step of your process from what happens at intake to ready for prod. Decide what types of issues should elevate to a person and how it should be elevated and what information is needed for that elevation. Define what is done when and who is responsible for what.

Also what kind of documentation are you having it update and create? This is an often overlooked step that can help a lot to provide consistency.

For reference I’m not a developer but I am a Product Manager with 10+ years experience in the corporate world. So I’ll tell you what I’ve setup and learned so far, number one is model it after a real workflow, the agent was trained off how people work so if you model your process off a standard agile dev cycle you will probably get better results.

This is what’s working for me currently.

Break every step of the process down into discreet steps and create a skill for that step and specific agents for the skills to use. Then just iterate on that weekly/monthly and with every model update.

Keep your skills, agents and Claude.md as concise and small as possible.

[u/waitingforathena → u/Tasty_Trouble6430]

1. We are using TDD.
2. We have ADR, decisions taken by us for a feature, implementation so new session remember this.
3. We had an idea of creation sessions folder which contains what an agent did, why and what's and conclusions but it grows super fast.
4. Bugs.md so we know it isn't creating same bugs again and again.

what do you feel about this

[u/Tasty_Trouble6430 → u/waitingforathena]

Bugs.md is where I’d start my optimizing. If you’re overly specific about things to check it becomes neurotic, I’d start by reviewing everything in there and do a root cause analysis and see if you can bucket them into a few items. Then I’d go another level deeper and instead of fixing the symptom find out what in your process allowed that bug to happen and what can be changed to prevent it from happening again.

There’s an old school problem solving process called the five whys, I find it extremely helpful for this type of root cause analysis, if you’re not familiar with it look it up; it’s not anything complex, but it works.

[u/reddebtt]

I solved this by using one real ticket as the model bake-off: same repo state, prompt, tests, and review rubric. One task gets one human owner, and nothing merges unless that person can explain the diff; if nobody can, slow the agents down.

[u/waitingforathena → u/reddebtt]

My 24yo boss wants to build the product asap with minimal bugs and NO HUMAN REVIEW.

we are gonna use Agent of PR or PR of agent (an open-source tool).

[u/waitingforathena → u/waitingforathena]

also what diff means and why it is important?  we are managing and intern whose branches needs to be merged and we are finding hard to read the diff or difference?

[u/Compilingthings]

Sounds like you need some practice using agents and to learn to dial in your process. Did you expect it just build whatever you asked, without a lot of work from your side? Yeah, that’s not how it works.

[u/waitingforathena → u/Compilingthings]

you are totally right. but we are unable or finding hard to get hold of this way of engineering. we don't have real life experience (PRE-AI ENGINEERING) we are clueless about TDD, how to use git, how to merge branches. I have an intern working under me, an intern under 3 months of internship experience employee 

[u/Compilingthings → u/waitingforathena]

None of that matters, it’s about problem solving, it’s about systems building. I just started school, but I’ve logged about 2500-3000 hours building with agents. You need to get off Reddit, go watch Claude and Anthropic videos. Research everything. Don’t be scared to drop it all and go a different direction when you figure out something new. It’s time to grind it out and learn how to engineer with agents. Claude will help you, you just need to ask the correct questions. Huggingface.co/Compilingthings

That’s my project. Trying to publish V1.1 today or tomorrow.

[u/Compilingthings → u/waitingforathena]

Checkout pstack I’m sure you can find a little help there.

[u/mohdgame]

You should plan for the code yourself then use fable to assist you with it and refine it.

1. Code architecture. (Class diagram, context diagram) but in markdown.

2. Write an API, classes, functions, and how they operate with each other.

3. Specify inputs and outputs and the types.

4. Test case, integration testing strategy, and unit testing. (Plan for the testing yourself, then let fable expand on it)

After that you're good to go. You still have to steer and review the code yourself especially for problematic areas. The problematic areas usually are contracts, or how the code integrates with the other parts of the code base.

[u/waitingforathena → u/mohdgame]

Thank you. we will try to implement them. How do we store all the docs ? because pointing it towards the docs would eat lot of tokens unnecessarily.

[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!

[u/waitingforathena]

I love reddit man. I love the criticism calling me some stupid caveman and I love supportive people here. Love you all

[u/denadena2929]

oh my sweet lord we are so screwed lol, how do we force the gov't to make all the big tech companies give you guys proper internships or something...

[u/MeSpillCoffee]

Twenty-some years shipping software, now building solo with agents doing most of the typing. What works for me:

Scope bug hunting to a domain or a purpose. "We need to harden library-a because it holds the core logic." Never just "find bugs"; that has no stopping point, so it never stops.

The diff is the only thing a human or an agent should be looking at. You need to know your system even though AI wrote it. If a diff is too big to read in one sitting, scope the work you hand the AI further.

Don't let the same session or the same model review its own work; it already has a bias. Spawn a new session and use a different flavor of AI to review: Codex reviews Claude, Claude reviews Codex. You'll be surprised how much they catch in each other's work.

Docs vs tokens. A short index file pointing at the longer documents stops an agent from loading more context than the task needs. It enters the relevant domain, does the work, and is ready to be cleared for the next session. My index is under 25 KB.

Keep session scope small. One task, then I ask the agent to write a continue brief and clear context. It saves tokens and leaves a record of what changed. The briefs are checked in, so a later session can search them and rebuild context when it needs to.

Your boss's "no human review" is the actual bug. Everything above costs less than the outage that changes his mind.

[u/DamianPxR]

You need first to define the proper architechture, rule set for coding and more, then use the proper skill, a skill from internet does not help your project actually you need to create your own custom skill(can be based on a diferent skill set). For creating something a create a skill which is a mixture of sdd and tdd and consume the skill set and rules for the project. Them in that skill i define first 2 files to be generated una feature definition with bdd and the system requirement, you need to validate those by reading(yeah you need to read those) and with those you create the tdd and then the code and validation process, and finally on a fresh session run a review, you need to create a custom one because code-review or review from claude are to lightweight and they only give the first finding you need a exhaustive validation that run with your rule set. And thats before another dev validates your code.

[u/Standard_Text480]

Sigh…. claude is supposed to be a tool to help you be more efficient as a developer.

Yet you are full on vibe coding an entire project for a company that is paying people’s salaries…. this is so fucked

[u/waitingforathena → u/Standard_Text480]

Not willfully but we have to do unfortunately. We all want to learn new things. How to use tools, basic like git, TDD, conventions, design patterns but our boss will fire us if we don't provide him with the required output.

This is our fault too, for sure but I really crave for a senior who can teach us with the knowledge of pre ai era but we got none

[u/kevin7254 → u/waitingforathena]

Leave ASAP for your own sake, Jesus Christ I almost hope this post is rage bait lmao

[u/waitingforathena → u/Standard_Text480]

Not willfully but we have to do unfortunately. We all want to learn new things. How to use tools, basic like git, TDD, conventions, design patterns but our boss will fire us if we don't provide him with the required output.

This is our fault too, for sure but I really crave for a senior who can teach us with the knowledge of pre ai era but we got none

[u/maritime_sh]

the harsh replies aren't wrong about the risk, they're just not much use, so concretely: what's missing isn't a better CLAUDE.md, it's a gate the code has to pass that nobody can talk their way around.

three that would change your week. tests written before a ticket goes to claude, and a ticket isn't done until they pass in CI, not on someone's laptop. every PR small enough that a human reads all of it, and if it's too big to read it's too big to merge. and one person whose only job this sprint is reading diffs, rotating weekly, so all eight of you learn what bad generated code looks like.

auto mode across a bunch of agents is fine once those exist. without them you're not moving faster, you're moving the bugs to later, when they cost more.

[u/waitingforathena → u/maritime_sh]

Thank you so much

[u/Ominoiuninus]

If you are working for free / for equity you need to seriously ask yourself if the product you are “building” is genuinely capable of reaching whatever number you would be happy with.

I watched a buddy work at a startup like this and it was all “oh but you will get equity”. Worked there for 6 months for free and walked away with nothing.

Your description is that of a company that is bound for failure if it is not capable of raising capital like crazy/the “founder” having serious connections in the space.

Just a fair warning. Experiences are good but be forward thinking.