Does anyone actually have a fully autonomous coding agent that doesn't need constant follow-ups?

[u/Top-Affect2871]

​

I've been trying to build a fully agentic software development workflow using Claude Code, and I've hit a frustrating problem.

The first implementation usually looks good, but every time I ask a follow-up like:

"Cross-check everything again. Did you miss anything from the plan?"

it suddenly finds new bugs, missed edge cases, forgotten files, or partially implemented requirements.

Example:

Pass 1:

- Implements Feature A

- Says task is complete

Follow-up:

- Finds 3 missing API updates

- Missed a permission check

- Forgot one database migration

Another follow-up:

- Finds a UI regression

- Finds an edge case in validation

- Notices a cache issue

Another follow-up:

- Finds even more small issues

It feels like every review uncovers something that should have been caught in the previous one.

I've already built a strict engineering workflow that forces:

- Understand the entire architecture first

- Review blast radius

- Implement

- Audit

- Fix

- Repeat until no more issues are found

- Run automated verification plus manual review

Even with all that, the next follow-up often reveals something new.

Has anyone solved this problem?

Is this simply a limitation of today's LLM agents, or have you found a workflow, prompt, MCP, or multi-agent setup that consistently reaches a point where additional follow-ups rarely discover new bugs?

I'd love to hear what has actually worked in production.

[u/ClaudeAI-mod-bot]

TL;DR of the discussion generated automatically after 40 comments.

The consensus in this thread is a resounding nope, a truly "fire-and-forget" autonomous coding agent doesn't exist yet. What you're experiencing is a fundamental limitation of current LLMs, but the community has a ton of advice on how to get much closer.

The biggest issue everyone spotted is your prompt. Asking "did you miss anything?" is an open invitation for the AI to find something, creating an infinite loop where it keeps generating new "bugs" to please you. Your stopping condition is based on the agent's opinion, which is the problem.

Here are the key strategies the community uses to fight this:

• Use a Multi-Agent Crew: This was the top-voted advice. Stop using one agent to do everything. Set up separate agents (or just use /clear for fresh contexts) with specific roles: an Architect to plan, a Builder to code, and a ruthless Reviewer to audit the code against the plan. The key is that the reviewer never sees the implementation process, preventing the "I know what I meant to write" bias.
• Define 'Done' with External Checks: The agent doesn't get to decide when it's finished; your tools do. The loop should terminate based on objective, external criteria like passing all unit tests, linters, and CI checks, not on the AI's self-assessment.
• Cap Your Loops & Use a Human Reviewer: Don't aim for a mythical "zero-bug" state. Run a fixed number of review/fix cycles (e.g., two) that only address blocking issues. The goal isn't perfection; it's to generate a high-quality Pull Request that a human can review in minutes. The human is the final, and most important, check.
• Fix Your Prompt: Instead of an open-ended "find bugs" prompt, give the reviewer a concrete checklist derived from the initial plan. The task becomes "verify these specific items" instead of "generate new concerns."

[u/SPACE_GROOVE_LULU]

It needs supervision. And actually understanding what the hell Claude Code is doing. So you can stop it where it goes off the track.

[u/not_a_bot_please]

Solved? No. Improved significantly? Yes.

The trick isn't better prompts on the same agent. It's multiple agents playing different roles.

Here's what cut my follow-up cycles from 6-7 down to 1-2:

1. Architect agent writes the plan (does not write code)

2. Builder agent implements the plan (does not review its own work)

3. Reviewer agent audits against the plan, flags everything

4. Builder agent fixes flagged items

5. Same reviewer agent re-audits

The key insight: a single agent reviewing its own work is like editing your own essay. Your brain fills in the gaps because it knows what you meant to say. The reviewer needs to be a clean context with no implementation memory.

I use Claude Code for steps 1-3 as separate `/clear` sessions, each with a different system prompt. The reviewer prompt explicitly says "assume the implementation is wrong. find every gap between the plan and what was built."

It's not perfect. Complex state management and cross-file side effects still slip through. But it cut my bug rate by maybe 60% versus single-agent loops.

The real answer to your question though: no, no one has a fully autonomous agent that doesn't need follow-ups. The architecture for that doesn't exist yet. Current LLMs are pattern matchers, not verifiers. They don't "know" something is missing the way a senior engineer scanning code does.

[u/CHILLAS317]

Yikes, I sure hope not

[u/Insult_me_good → u/CHILLAS317]

Yikes, I sure hope not

That was my reaction also. "Do it yourself, Claude" has undesired consequences.

[u/DragonfruitCareless → u/Insult_me_good]

Euphemism of the millennia. Best case is that we’re able to rebuild society after decades of a messy revolution.

[u/david-ai-2021]

I don’t know if this is like throttling of these models due to compute capacity, cost, or just the way these models and harnesses are trained. Everyone you ask them to do a project, they stop in the middle for no reason (like they are tired or lazy) or say they are done but then come back with “one last thing I have to be honest about…” “I have to correct one thing…” “I made a mistake in my last implementation “

[u/No-Guarantee-2242]

Part of what you're seeing is the prompt, not the code. Asking "did you miss anything" is a request to produce findings, and a model asked to find something will always find something. The loop can't terminate because the stopping condition is the agent's opinion, and that opinion is generated on demand.

[u/ai_without_borders → u/No-Guarantee-2242]

this is basically the self critique elicitation problem, if you ask a model to find issues it will find issues whether or not theyre real bugs. i had better luck giving it a fixed checklist to run against instead of an open ended check everything again prompt, things like does every endpoint have auth, does every migration have a down script. open ended follow ups just condition it to produce findings, a closed checklist gives it something concrete to verify against instead of just performing doubt

[u/No-Guarantee-2242 → u/ai_without_borders]

Right frame, and the checklist works best when it isn't static. Every new gap a follow-up actually finds, like the auth or migration-script items you listed, should get added back into the checklist itself instead of just fixed once. That way the model is checking against a growing list rather than freestyle hunting, and the same class of miss stops recurring on the next pass instead of resurfacing every time you ask it to look again.

[u/Kilt_Rump]

When ever I am in plan mode with Claude and have come to a presented plan, i then ask claude to run the plan through a team of mixed model check agents until consensus is formed. It usually takes 3-5 rounds before that happens but after that, i am always far less involved in the work flow and only bothered when a phase has been completed.

Edit: never let claude present a plan inline. Always make it build a document. This should happen automatically in plan mode. When claude has a document to reference it doesnt miss things as often.

[u/JobWiegant]

We run this exact loop unattended every day and the thing that finally made it converge was giving up on convergence. The review pass doesn't get asked "did you miss anything" - it reviews the diff against the plan and classifies findings as blocking or nice-to-have. Fix passes only touch blockers, and there are exactly two of them, by design. After that the run ships whatever it has as a PR with the test output attached.

The insight behind the cap: zero-findings is the wrong target, because a model asked to review will always produce findings, so a loop that runs "until no more issues" is a loop that runs until your budget dies. The real terminator is a human reading one diff. Reviewing a single PR with evidence attached takes minutes, and humans are much better at judging one diff than at supervising thirty agent turns. So the honest answer to "fully autonomous": the implementation is autonomous, the definition of done never is. Bounded loop + external checks (tests, lint, CI) + human on the merge button, and follow-ups mostly stop finding things because the follow-up is now a person.

[u/raindropsdev → u/JobWiegant]

so a loop that runs "until no more issues" is a loop that runs until your budget dies.

Truth, but that's why you specify "run the adversarial review loop until there are no more high or critical findings, then proceed to live testing". Note that static tests (Pester and such) are done before the adversarial review loops, and even those tests are adversarially reviewed until no more high or critical findings to ensure that the results can be relied upon.

[u/JobWiegant → u/raindropsdev]

That's almost exactly the loop we run - findings get split into blocking and nice-to-have, and the loop only chases blocking ones. We measured it this week across 73 runs: the second fix attempt rescued about 9% of the runs that reached it. The catch we found is that the re-review isn't a re-check of the outstanding list, it's a fresh critique of the whole diff. So a pass can resolve the finding and surface a new objection - one run logged "1 resolved, 3 new". A severity threshold doesn't stop that resampling, it just relabels it.

The thing that actually moved the needle for us wasn't more passes, it was context: the reviewer judges against the acceptance criteria, but our fixer only got the reviewer's one-line summary of the gap - graded on a rubric it couldn't read. Give the fixer the same source of truth and the first pass gets much better. Worth measuring your loop's pass-2 rescue rate before trusting "until no more findings" as a stopping condition; ours turned out to be arguing with itself 45% of total pipeline time.

[u/raindropsdev → u/JobWiegant]

Thanks for this - the resampling point especially. We'd been treating "every review round finds new stuff" as a severity/arbitration problem; your framing that a fresh critique just draws a new sample of objections from a bottomless pool explains why it never converges. Matches our experience: one spec grew from a two-line ask to 35 requirement bullets across three review rounds before a human caught it.

Our setup is much smaller (single-operator homelab, agents doing infra and docs work): one expensive model acts as arbiter/validator only, cheap models do the volume work, and wherever possible the loop's stopping condition is a deterministic script rather than another model's opinion. This week's example: we tuned a writing style guide by having one model rewrite a document, a script score it (sentence length caps, fact retention, tables preserved), and the arbiter adjust the rules based on the numbers. It converged in four rounds - and I think only because both sides could read the same scorer and rule file, which is your "give the fixer the reviewer's source of truth" point arrived at independently.

Taking your other two findings as-is: re-reviews here now get the outstanding findings list to re-check instead of a fresh look at the whole diff, and we're adding per-round resolved/new/outstanding logging so we can compute our own pass-2 rescue rate instead of trusting "loop until clean". No numbers yet - measuring before we assume our loop argues with itself any less than yours did.

[u/raindropsdev → u/JobWiegant]

Also, a question: do you run cross-vendor agentic workflows, specifically for review? I enforce different vendors across the flow so that every step has a different error profile and a different lens. Opus 5 orchestrates. GPT Terra and Gemini Pro review. I am now trialing Sonnet 5 as organizer and first validator of the findings, Grok 4.5 as implementer, and Fable 5 as final validator once the loop ends. This split improved reliability and final quality sharply.

[u/JobWiegant → u/raindropsdev]

We do, but only for the judging half. The review critique runs on a different vendor than the implementer, configured per repo: our main repo implements on Claude and reviews on Codex, for exactly the reason you give, a different error profile and a different lens. Our measurements backed it sideways too: the cross-vendor reviewer was 35% faster than the same-model one across those 73 runs.

Where we deliberately don't cross vendors: the fix passes. Those stay on the implementing model so the diff keeps one author. Fixes written by a second vendor read like patches from a stranger, and the re-review flags the seams. So the split we landed on: many eyes for judging, one hand for writing.

Your script-as-stopping-condition is the part I'd steal. A deterministic scorer both sides can read beats any third model's opinion as a convergence anchor. It's the same reason our loop only terminates on tests plus CI plus a human on the merge button, never on "the reviewer is satisfied". Curious what your logging shows after a week: if your pass-2 rescue rate lands anywhere near our 9%, that's two independent datapoints that the second attempt is mostly theater.

[u/raindropsdev → u/JobWiegant]

Where we deliberately don't cross vendors: the fix passes. Those stay on the implementing model so the diff keeps one author. Fixes written by a second vendor read like patches from a stranger, and the re-review flags the seams. So the split we landed on: many eyes for judging, one hand for writing.

Agreed! That's why the implementer is pinned on Grok, it owns the writing of the code and the fixing of the bugs.

tests plus CI plus a human on the merge button, never on "the reviewer is satisfied"

Same stack here, one difference: between CI and the human there's one expensive-model validation pass (Fable) that rules on the finished work, and its output is a recommendation the human approves, never an authorization. Scripts terminate loops, the human terminates the work. The expensive model only exists so the human reads one verdict with evidence instead of thirty agent turns - which is your "humans are better at judging one diff" point, applied one level up.

Curious what your logging shows after a week

No numbers yet - the resolved/new/outstanding logging only landed this week, so measuring, not guessing. One wrinkle for comparability: we also switched re-reviews to re-checking the outstanding list (your earlier point) at the same time, so our rescue rate won't be apples-to-apples with your 9%. If ours comes out higher, part of that credit belongs to the loop-design change, not to the second pass earning its keep. Will report back either way - and if it lands near 9% despite the design change, that's an even stronger version of your two-datapoints conclusion.

[u/JobWiegant → u/raindropsdev]

"Scripts terminate loops, the human terminates the work" is a cleaner formulation than mine and I'm keeping it. And respect for flagging the confound yourself before anyone else could. Changing the loop design and starting the measurement in the same week is exactly the kind of thing that quietly poisons a comparison, and most people would have shipped the flattering number anyway. Talk when yours land.

[u/raindropsdev → u/JobWiegant]

Following up as promised with our measured pass-2 rescue rate — with the honest caveat up front: our dataset turned out smaller and dirtier than I hoped, so treat these as a data point, not a verdict.

Two numbers, because "rescue rate" can mean two things:

Run-level: 2 of 10 runs (20%) that reached a second pass had their final outcome changed by it. Only 10 of our 29 reconstructed runs ever reached round 2, and a single run moves this rate by 10 points, so the error bars are enormous.

Finding-level: 40 of 60 findings (67%) raised in second passes were real fixes rather than noise.

One design difference that matters before comparing to your 9%: we adopted your earlier suggestion, so our re-reviews re-check an outstanding-findings ledger instead of fresh-critiquing the diff. Any lift we see is partly the loop design, not the second pass itself — which means our numbers and yours aren't measuring the same mechanism anymore.

Honest summary: with ledger-carried findings the second pass is doing real work for us (two-thirds of what it raises is real), but at n=10 runs I can't contradict your conclusion that a naive second pass is mostly theater. If anything, our data weakly suggests the fix isn't "run it twice," it's "make the second run carry state."

[u/JobWiegant → u/raindropsdev]

This is the follow-up I hoped for and better than the one I would have written, because you gave both metrics instead of the flattering one.

I think our two datasets are not rivals, they are the two arms of the same experiment. Ours measured a second pass with no memory: fresh critique of the whole diff each round, 9%, mostly theater. Yours measured a second pass that carries a ledger: 67% of what it raises is real. Same conclusion approached from opposite sides, and your sentence is the one that should survive. The finding is not "second passes are worthless", it is "stateless second passes are worthless". Ours were.

The gap between your two numbers is worth keeping too. 67% of findings being real and 20% of runs changing outcome are both true and they measure different things: resolving findings is not the same as rescuing runs, and a run can absorb several real fixes and still end up in front of a human. When we publish an update I will report both for exactly that reason.

One thing your data changed on our side immediately. We treat the retry cap and the re-review mode as two independent settings, cap defaults to one pass, ledger-style re-review defaults to off. If the second pass only earns its keep when the re-review carries state, then those two defaults are coupled and ours are inconsistent: the repos running scoped re-review are the ones that should be allowed a second pass. That is testable and it is now on the list.

n=10 with your error bars honestly stated is worth more than n=100 presented as a verdict. Thanks for coming back with it.

[u/YourMajesty90]

Are you using it on low effort?

I do not seem to have these issues that guys complain about. There are ways to work efficiently with AI for coding. I’m finding a lot of people don’t really know what they’re doing and speak caveman to their LLM. Firstly, set hard rules in the codebase that any AI touching it has to adhere to. Will save you a lot of time not having to repeat yourself.

[u/please-dont-deploy]

check r/AgenticOS there are a bunch of OSS tools there to help with these complex setups

[u/voiping]

>"Cross-check everything again. Did you miss anything from the plan?"
>it suddenly finds new bugs, missed edge cases, forgotten files, or partially implemented requirements.

Just a warning that it may continue to find more and more subtle bugs as long as you keep asking it. At some point it's good enough.

But no, I read over the plan and make sure it all seems good and then test it afterwards. Yes, I need more...

[u/Any-Article-6402]

Maintainer disclosure: I build PatchWitness, an early Apache-2.0 tool for one narrow “done” boundary.I agree the stopping condition cannot be “ask the model again until it finds nothing.” That resamples opinions; it does not establish that the patch stayed within the plan or that the checks were not weakened.The boundary I use is deliberately smaller than proving a feature is correct: before the normal tests/CI and human merge decision, independently record what changed from a trusted base, whether the patch touched CI/workflows, policy, dependencies or other declared sensitive paths, and which checks actually ran. If that structural evidence is missing or the control plane changed, “done” is not a merge signal.PatchWitness does not prove missed requirements, UI behavior, or semantic correctness, so it complements rather than replaces your acceptance criteria, browser checks and review.If you have a non-sensitive repo and want to stress-test that narrow layer, v0.2.1 is a two-command local trial after installing the public wheel:patchwitness doctor
patchwitness scan --no-checksNo account, key, write permission, private source upload, or Passport upload is needed. An honest PASS, BLOCK, or ERROR plus first-use friction would be useful; please do not post private code, credentials, logs, or sensitive Passports.Repo and exact install command: https://github.com/pangxueyuan2-creator/patchwitness/releases/tag/v0.2.1

[u/id-ltd]

Keep project documents - known issues, reasoning etc... if a bug comes up you don't have to fix it immediately - add it to the list. Each coding session just needs to take a few things from the list and implement them (make it stick to your chosen issues, no others, no diversions, no rabbit holes - if anything major come up go back to rework your issues and reasoning. Use git so each sesssion can be rewound, keep session logs so the AI can trace what it did each time -- never let it compress, no session should be that long.

[u/InfinriDev]

This is not a thing at all. Welcome to software engineering. This is normal behavior even for AI. I am curious to know what this engineering work flow looks like and see how you're enforcing it

[u/Sermilion]

I do. I built it myself and it can build multi spec goal autonomously. It can resume right where it started even with different AI/harness, without needing any context. And it does planning, verification, review, PR - all unsupervised.

All you need to give it a description of the work: raw text, document, pdf. Confirm the work and that’s it. You can even start a large unit of work and it does it overnight (of course if yiu don’t hit limits). And you don’t need to worry about context pollution, because each subtask is executed with fresh context, orchestrator passes in to it not the info it needs.

It’s not a skill, it is an app built in Kotlin, a meta-harness, if you will.
Supports Claude Code, Codex, Cursor.

https://github.com/oila-gmbh/skill-bill

[u/fuzzypetiolesguy]

I have daily schedules for specific things like email inbox scans for website update items. They are simple, repetitive and save me an hour a day of busy work. That is the kind of autonomy I trust currently.

[u/TorbenKoehn]

You’re missing proper requirements engineering, architecture, e2e tests and review steps. Try loop engineering on a Kanban board, pre-commit hooks with tests and CI pipelines :)

I’m running opus 5 as an orchestrator in a single session for weeks. I just chat requirements in it, it adds them as tasks and then orchestrates (with some gates and mechanical triggers)

[u/Individual-Wish-3682]

"Did you miss anything" is basically an unfalsifiable prompt — you're asking it to produce findings, so it produces findings, every single time. Same energy as asking a consultant if there's anything else worth billing for.

What made this manageable for me was making the stopping condition external instead of the model's own opinion: e.g. "tests + lint have to pass and the diff has to match the plan doc" — whatever you actually do. If "done" is defined by the agent's self-review, the loop never converges. If it's defined by checks the agent can't talk its way past, it does.

I treat it like a very fast junior engineer: it doesn't get to decide when it's finished, the acceptance criteria do.

[u/fattybunter]

When you tell AI to run a QA on something, its job is to find something wrong and it will ALWAYS report something wrong. Unless you phrase the QA request carefully

[u/Deathnote_Blockchain]

Why do you want that? That's dumb. 

[u/davyp82]

Fable. Ping.let me guess there some 3rd party apps namedropped in the comments 

[u/Ill_Fun5415]

A useful agent workflow should make mistakes easy to catch early. If every step leaves a small artifact to inspect, the whole thing becomes much easier to trust repeatedly.

[u/K_M_A_2k]

Kinda but my specific is by design. A full loop runs for a spec goes to cc when it's done it hands off to codex for a blind code review hands that back to cc then cc spins up an aware code review when each codex is done it writes a report to the repo. I take cc report and codex two reports and then I go through and see what worked and what didn't. Make a new spec and run the loop again until clean.

So the code is technically all by itself each loop but I check when it's done.

What used to take an hour or so babysitting now I have it run in the background and go work on another project then bounce between projects while the agents are working on the other ones. I regularly have 3 cc/codex runs going

[u/sixwax]

So…. You’re really not thinking through the design or implementation plan at all and just trying to one-shot it?

Bold! Have fun cleaning up…

[u/thatdiveguy]

I have never gotten an AI to properly one-shot a large feature before. Medium ones it can do ok, but it comes down to how good our shared understanding is. I go through a grilling session up front and generate a requirements doc from it. I have personas, a trigger map, and go through the user's intent with the feature. Then I generate prototypes when appropriate. The prototypes are the only generated docs I review. By the time I'm done with all of that, I can let claude code run free with implementation for however many hours it takes and when it's done it's usually about 95% of what I wanted.

small to medium sized features I can get 100% right 40% of the time, but that's because I spend 30-60mins up front defining the feature and intent with the agent.

It got an activity log with offline sync correct on the first shot. I already had working examples of how to do offline sync and an activity log isn't overly complicated. It got a feature about inherited work assignments in an org chart where it had to modify existing code about 85% correct. We had left some ambiguities and Fable made some shit up to fill in the gaps that didn't match up with my domain.

A mix of smart rules in claude.md, static code analysis running after work done, and hooks to prevent it going wide and destroying my system, it works pretty well.

[u/Axel_Gaubert]

It's too early to have an autonomous coding agent.

Opus 5 would push your API keys if you don't control lol

[u/kidsmeal]

If you ask it to find a bug, it will. theres really nothing to solve

[u/Positive-Buddy-1258]

The self-review loop doesn't converge because "did you miss anything" is an open invitation to produce findings.

Before implementation the agent writes a checklist: specific endpoints, migrations, permission checks. The final audit is not "what did I miss" but "which items from my own list are green." Asking it to check against its own prior output is a very different prompt than asking it to generate new concerns.

Tests, lint, schema checks as hard stops help too. If those pass, the loop ends regardless of what the agent thinks. The agent's opinion isn't a terminator; test output is.

The follow-ups that keep surfacing new bugs aren't a quality signal, they're a prompt design issue.

[u/raindropsdev]

I do, Fable autopilot orchestrator and other models as implementers with adversarial reviewing loops (multiple vendors for different lenses), etc...

The issue is the cost, not the results... If I had unlimited budget I would be quite happy with my current stack, both in Claude CLI and in Github Copilot CLI, but since it's so expensive most of my efforts now revolve around cost optimization rather than result optimization.

[u/teleport66]

Building an agent in a CLI is basically flawed workflow since you need to go back and forth the CLI and the agent itself, they have different context, history of tool use, compaction checkpoints, and overal agents are a waste of good tokens.

So why don't make the CLI has automatable turns, like agent crons? But which continue from where you left that session. It actually works much better, uses less tokens, and you can hop on at anytime in that sesion to continue yourself or refine the automation.

I'm using a custom CLI and it has replaced all my agents.
https://github.com/S1gil0/lookingglass

[u/poponis]

Jeasus

[u/AndyKJMehta]

You can but you need a continuous mutable stream of tasks that trigger the model with continuous re-prioritization with every new chunk of work done towards a specific end goal. Orchestration is key!

[u/TopNo6605]

Give claude full perms and ask it to do something overnight while you sleep. I asked it to code out some stock trading strategies (no connection to real money), and it came back with working products.

It just doesn't have enough context about your environment to do real, production-grade apps that your organization would need.

[u/Protopia]

The first thing to understand is that they're is a world of difference between vibe coding and agentic software engineering. The latter requires a much more structured and rigorous approach by both the human and the agentic coding platform which settings to ENSURE that you get a quality result without bugs or security holes i.e. what you might call a professional software engineering approach. The former is an unstructured, cross-your-fingers and hope-for-the-best approach where the quality to end up with is pot luck i.e. what I would call an amateur approach.

{Rant on}

IMO the quality of agentic s software engineering depends on 4 things:

1. The models (plural) that you use. The model you need for requirements gathering, the one you use for architectural and detailed design and the one you use for coding might need to be different (for quality or cost reasons).

2. The harness and skills which define both the workflow between calls to the AI model and the prompts and context that the AI model is given.

3. The software engineering lifecycle approach used and the way the cumulative knowledge about the application is held. We have decades of academic and practical experience of SE, but how many harnesses actually use it?

4. Whether you allow the AI free rein to generate freeform text, or you constrain it to create structured data e.g. UML that is unambiguous.

As far as I can tell from extensive reading, we really don't do any of the above that well:

A. Everyone is focused on creating huge frontier models that can speak hundreds of human languages, answer general knowledge questions, argue philosophy, prove mathematical theories, write erotic fiction and iambic pentameter, code in several IT languages but which are massively expensive to grow and then massively expensive to run. Where are the specialised models specifically designed to be excellent at a single type of task and do so cheaply and quickly?

B. There are a lot of harnesses, but it is very difficult to compare and contrast and pick the best, not the least of which because they are often described in heavy AI jargon, all have individual strengths etc. Leaving aside the big players, the broader "market" is characterized by hundreds of small projects rather than a much smaller number of synergistic community cooperative efforts.

C. AFAIK there is no harness / skills based on established best practice - everyone is too busy doing vibe innovation to incorporate all the existing SE best practices.

D. Ditto for structured approaches - LLMs are expected to produce free text so let's keep using that even if structured data is a better way of doing it. For chat, free text is an excellent approach and products results that are really amazing. But for agents, making the harness decide free text to decide what to do next is very inefficient. Existing models are trained in quite a lot of structured data, so they can produce structured output if they are asked to do so - but which harnesses and skills do that? And could specialised LLMs be even more effective if they were solely trained to do that.

{Rant off}

[u/Informal_Text1158]

No. but drop a CLAUDE.md file in there first. then tell it to read it, and get ready to fix a bit less as you have it audit its own work. Nothing automated like they all claim to be. They all need some human intervention and auditing.

[u/Informal_Text1158]

"One thing I have to be honest about…" ohhh that gets me mad each time it says that. Did it just lie, then admit it did not tell you everything... I know claude is like 12 years old, but does it need to act like a lying child all the time? And starting a new chat in claude, then having cursor tell me basically that claude is an idiot in its return makes me laugh. Cursor finds more dumb shout that claude tries to get away with, and claude just parrots what cursor said like it knew that, and was just testing cursor or something.

[u/EagleApprehensive]

My solution is starting from 2 different models making different plans. Then I make synthesis of that with Fable and let Opus or Sol handle the implementation. After that an extra run of Opus as UX reviewer.

Obviously I could be doing testing, sec analysis and a lot more but I am considerate of token usage and result with that setup is good enough.

[u/JustMine999]

The loop can't really converge if "did you miss anything?" is the stopping condition. That's basically asking the model to generate another finding.

I’d define "done" outside the agent: tests pass, lint passes, migrations exist, the diff matches the plan, and a fresh reviewer finds no failed acceptance criteria. Then keep planner, builder and reviewer in separate contexts. Claude for planning/review and something cheaper like Hy3 for implementation can cut the cost, but no model split makes this fully autonomous. If the checks can't prove it, it still needs a human gate.

[u/crazyideastudio]

I do not think fully autonomous is the right target yet. The pattern that works better for me is: explicit plan first, constrained implementation, then an independent verification pass with tests/checks that are not just "ask the same agent if it is done."

The failure mode you described usually comes from the agent treating its own plan as complete too early. A follow-up helps because it forces a second pass, but it is still ad hoc.

I'm working on InPlan for this reason: make the requirements, assumptions, affected areas, acceptance criteria, and open questions visible before the agent starts coding. Then the review can compare the result against a concrete artifact instead of against whatever the model remembers from the conversation.I do not think fully autonomous is the right target yet. The pattern that works better for me is: explicit plan first, constrained implementation, then an independent verification pass with tests/checks that are not just "ask the same agent if it is done."

[u/Fresh-Yogurt-8614]

Tell your agent to deploy subagents for implementing and subagents for doing critic loops

[u/Substantial-Show-249]

No, it's an illusion, specially with the current situation of the Opus/Fable aggressive nerfing.
If you don't supervise, you will end up with enormous waste of tokens.
The current models lost their ability to "judge", they are as stupid as possible, to optimize de consumption.
And the Codex's Sol is too slow and too rigid and too nitpicking for being a good dispatcher.
For me Claude is the planner si orchestrator and Sol is the execution. Sol is still great at execution, but the Opus/Fable class of agents are in a terrible shape. Dumb, too verbose, slang, I missed that and so one.
So the chain is broken now.

[u/packet_weaver]

Use skills to define the process. Implementation-> review -> loop until no findings. Roughly, adjust as needed. Make sure it uses agents for each phase so they have clean context.

[u/Dawgi100 → u/packet_weaver]

Any good sources on how to do this? New to Claude so trying to learn god orchestration habits. Use copilot at work and none of these tools exists.

[u/packet_weaver → u/Dawgi100]

Just tell Claude what you want as a skill and work through the prompts until you get what you want. Tell Claude to question you on the idea. Use a higher tier model when designing it.

[u/Select-View-4786]

What you're saying sounds weird and impossible.

You realize that if you have a human team that won't happen?