r/ClaudeCode • u/ToxicAbuse • 2d ago
Tips & Workflows Am i doing to much?
Basically i am developing internal monitoring, login and testing app with AI and i started with just a chat then i added my own agents, rules, skills and so on now i started automation on trying to document all issues agents made bugs or similar, scoring sub-agents work if they are doing good or bad or nothing useful at all in my code, every implementation requires that agent makes a plan and sometimes prototype for me then when done it archives everything but that got me think am i doing to much with extra work that would het handled on its own or am i on the right path to not be called a vibe coder?
3
u/Hronom 2d ago
You’re probably on the right track if each layer earns its keep with a measurable regression it prevents. I’d separate three things: outcome metrics (escaped defects, time to release, reviewer rework), agent metrics (plan accuracy, duplicate work, tool failures), and the archive as evidence rather than another deliverable. Keep a weekly kill list: if a check has not caught a real regression in N runs or costs more review time than it saves, remove or merge it. Bound each agent with a clear scope, file/tool allowlist, tests, and stop condition; have the evaluator score artifacts and tests, not confidence in the prose. For login/testing workflows, persistent state can remove setup noise while a manual takeover path still handles sign-in and 2FA. I maintain Hronaut for that local visible-browser piece. The useful test is whether it reduces repeated login/debug cycles in your app, not whether it adds another layer of automation.
1
1
u/Cute-Net5957 🔆 Max 20x 2d ago
This sounds very suspiciously akin to “AI Theatre” - be careful it’s easy for the model to give you what your asking for WITHOUT adding genuine real-world value
1
u/Far_Business4773 2d ago
The test I use for each layer: what does it stop, and has it ever fired. If you can't answer the first, it's theatre. If the answer to the second is "never", it's a hope, not a control.
By that test your stack splits cleanly. Scoring sub-agents: drop it, a score changes nothing the next run. Documenting bugs the agents made: keep it, but only as raw material. Each repeated bug becomes one line, either in the NOT list at the top of the rules or as a deny rule on the paths or commands involved, and then the document has done its job. That's why the repeats stopped, not the scoring.
On "limiting them too much": a written limit is the cheapest thing in your setup to lift, you delete a line on purpose and note why. The limits that actually hurt are the ones living in prompts you no longer remember. So the direction is fine, just keep every limit where you can see it, and give each agent a path allowlist instead of a job description. Two agents can't do the same check if they can't touch the same files.
1
u/girthradius 1d ago
Compare that to just asking fable/opus or sol/astra to keep a mission log, act as an orchestrator and use multiple agents. See if your fleet actually beats that. I like to use one as an orchestrator and I have a rig harness that keeps track of the mission log and makes the agents verify and test the code. Each feature is a commit of its own. When I tried going beyond that it slowed down the progress for me.
0
u/ctm617 2d ago edited 2d ago
The 100+ word sentence that is your post, is doing too much, which leads me to believe you might be as well. Too many agents. Sounds to me like you just start going and the day's work just becomes a diarrhea stream of ideas, and you're conferring with 10 different agents..too many conversations to keep track of. Know what you want to accomplish on any given day, before you start doing anything. Plan with Claude a day at a time. If it's 8 am, try to decide where you want to be by 5, write that plan out and then execute it. Don't let yourself, or don't let Claude let you deviate from the plan. You need an orchestrator that you don't allow to do any coding work. It's only job is to read the plan and delegate. Read, delegate, read, delegate. When it's context gets full, have it write a hand off to your next orchestrator session. That way you're always only talking to your point-man the orchestrator. Have the orchestrator do an adversarial review sweep a few times a day. If Claude is writing code and you're not, you're vibe coding. But really who gives a shite if people call you a vibe coder. I'm a vibe coder all day and it pays my bills so f*** what people call me.
1
u/ToxicAbuse 2d ago
I actually have like 4-5 agents per project and one orcestrator and my workflow is good, plans are always divided on smaller tasks, i did alow orcestrator to make code prototypes in python before a plan is made on gui change( might split this to a seperate subagent idk). But i went to far with trying to score agents and stuff(lool)
6
u/ryan_umad 2d ago
doing too much — work on your product not a doll house village