I have not done a systematic ablation study, so not all things might be necessary, but anyway, here's what's working for me very well (in no particular order):
0. Use Opus 5.5 on high.
1. Have in your CLAUDE.md the rule that code changes go together with updates to the docs. For me, that's HTML files in docs/. (Could be .md as well, but for human consumption, HTML is nicer.)
2. Have the rule that only that should go into the docs that an experienced engineer would need to rebuild the system from scratch, ignoring how it would look.
3. Larger work gets a plan doc in docs/plan, i.e. multi-PR work. There is a template how plans look, and an important part of the template is that the last step of the plan is always to delete the plan and fold anything from it that makes sense as long-term documentation into the docs.
4. Have a rule that before creating a PR, a sub agent needs to review the code, and have Codex Sol 6.1 high review it as well. Then let the main agent iterate on their findings until they are happy.
5. Every now and then, ask for an audit of the code. I ask for DRY, YAGNI, and KISS. Let it produce a report. Then let it fix all findings. If a lot, use a plan.
6. If you're adding something straight forward, just ask for it directly. If it's not, ask for a brief first. Review it. Then decide whether to implement in one go or through a plan.
7. Get an ultra plan, so you (mostly) don't have to worry about token usage but can use agents to their full ability.
8. Bonus and plug: Ask your agent to hand over with a demo video. It often finds and fixes issues while recording it, and you're not degraded to the agent's QA team, but it has to put in the work to convince you. I built a UI for directing agents as described: obeya.si. Free, open-source, local.
sadilek
One thing that's surprisingly powerful is to just say what you want in the prompt. One of my skill files now includes "inspect existing code under [subdir] for implementation patterns." Depending how much code you have, that might take a lot of tokens. You could either list the patterns that you want or include a smaller code sample in the skill's references.
A stronger version of this would be to make a separate gate. Fail the commit if the new code duplicates something already in a utility function, renames something that already had a name, uses for-loops instead of list comprehensions, whatever is bothering you.
smallerize
When you vide-code you don't care about code quality, right?
Personally I review most of the code and I do understand the frustration. I'm leveraging https://orca.virtuslab.com to orchestrate an agent to do the development with a few others to review the code; besides this I also put extra reviewers that focus on specific details/patterns which get launched by Orca.
While this isn't perfect, it is the best approach I have got so far.
I've always been a bottom-up programmer, so I tend to think more about discrete operations of software rather than the user-facing features (which IME will fall out naturally).
1. Experiment and solidify architecture before adding features. I think this is the hardest step for top-down thinkers.
2. Heavy testing and benchmarking. Prefer to TDD as much as possible. The actual lines for my agent-written codebases are generally ~70+% tests, benchmarks, and experiments.
3. Full mutation test coverage after the code is written. Doing this as a human is miserable IMO, but robots make it reasonable. This step resolves SO MANY subtle bugs.
At that point my main role is ensuring alignment with the actual specs.
mpd
You need to make sure you download your git history. You can analyze your git history with artificial intelligence to know where there were issues. There should be a complete record of every command you put into AI.
1. You need to audit your work regularly. You can ask almost any AI to audit your work. There are several different audits you can do, security, marketing, performance, seo, bias etc. Use more than one ai for the performance audits. This should tell you where a lot of the performance issues are. There are also specialty audits you can get from specific services. I also have a weekly audit run for general issues. Cover all the bases.
2. You have to watch the AI carefully to make sure it is not generating errors. I catch it looping quite often or making mistakes.
3. Ask people to review your site. There are places where you can get human reviews. Do this regularly. AI is self referential and will make mistakes that no person will make.
NishanStepak
I definitely don't touch any AI tools while I'm designing the high-level solution for the problem. If you ask it to propose a solution to you, you quickly go down the rabbit hole, which can sometimes lose you days. This is especially the case if your setting is not fully verifiable but you measure your success with a metric.
Once the design is complete, I think the rest is less important. At least that's how I feel.
caksoy
I can tell you what helps me and maybe you can incorporate some of this in your own code as well.
1- Ensure you have Changelogs.md, Agents.md properly written to your likings.
2- Depending on what you are building there is always a way to add actual UI tests and takes screenshots of before and after. If its a related to web UI, you can use playwright and or similar but there is always an option to test UI. Worst case scnerio is when none of libs help you and in those cases, you can add automated tests for UI using computer control from agents and take screenshots.
3- When reviewing PRs, always use a totally different agent. For example if you use claude code for creating PR, then perhaps ask Codex or Cursor to review the PR in depth.
4- Prefer smaller multiple PRs over larger ones.
5- Last resort: If you don't have to review and check PRs yourself, perhaps consider hiring a QA engineer if you can afford one.
Last but not least, learn to freeze the scope and remember not all bugs and edge cases are worth covering.
waximabbax
Ensure it's referencing well-regarded coding/ui/ux standards. If you're developing in C++, Google has great docs. If you're making an iOS app, Apple has great docs, of course. If you're making a user-facing web app, look up behavior-driven development (BDD) ... Etc, etc.
jesecamilo
"Vibe coding" as I understand the term is antithetical to keeping up quality.
drakonka
I use Claude Design Artifacts a lot for new features I'm building. Its really helpful for nailing a flow and look. Besides that my apps usually have a component library built so it doesn't repeat code.
Opus 5.5 has made it pretty effortless to get right the first time tbh. Usually it even lays things out better than I was thinking originally
comments (10)
0. Use Opus 5.5 on high.
1. Have in your CLAUDE.md the rule that code changes go together with updates to the docs. For me, that's HTML files in docs/. (Could be .md as well, but for human consumption, HTML is nicer.)
2. Have the rule that only that should go into the docs that an experienced engineer would need to rebuild the system from scratch, ignoring how it would look.
3. Larger work gets a plan doc in docs/plan, i.e. multi-PR work. There is a template how plans look, and an important part of the template is that the last step of the plan is always to delete the plan and fold anything from it that makes sense as long-term documentation into the docs.
4. Have a rule that before creating a PR, a sub agent needs to review the code, and have Codex Sol 6.1 high review it as well. Then let the main agent iterate on their findings until they are happy.
5. Every now and then, ask for an audit of the code. I ask for DRY, YAGNI, and KISS. Let it produce a report. Then let it fix all findings. If a lot, use a plan.
6. If you're adding something straight forward, just ask for it directly. If it's not, ask for a brief first. Review it. Then decide whether to implement in one go or through a plan.
7. Get an ultra plan, so you (mostly) don't have to worry about token usage but can use agents to their full ability.
8. Bonus and plug: Ask your agent to hand over with a demo video. It often finds and fixes issues while recording it, and you're not degraded to the agent's QA team, but it has to put in the work to convince you. I built a UI for directing agents as described: obeya.si. Free, open-source, local.
sadilek
A stronger version of this would be to make a separate gate. Fail the commit if the new code duplicates something already in a utility function, renames something that already had a name, uses for-loops instead of list comprehensions, whatever is bothering you.
smallerize
Personally I review most of the code and I do understand the frustration. I'm leveraging https://orca.virtuslab.com to orchestrate an agent to do the development with a few others to review the code; besides this I also put extra reviewers that focus on specific details/patterns which get launched by Orca.
While this isn't perfect, it is the best approach I have got so far.
Recently I wrote a post about this approach: https://alexitc.com/blog/2026-11-02-trading-speed-for-correc...
AlexITC
1. Experiment and solidify architecture before adding features. I think this is the hardest step for top-down thinkers.
2. Heavy testing and benchmarking. Prefer to TDD as much as possible. The actual lines for my agent-written codebases are generally ~70+% tests, benchmarks, and experiments.
3. Full mutation test coverage after the code is written. Doing this as a human is miserable IMO, but robots make it reasonable. This step resolves SO MANY subtle bugs.
At that point my main role is ensuring alignment with the actual specs.
mpd
NishanStepak
Once the design is complete, I think the rest is less important. At least that's how I feel.
caksoy
1- Ensure you have Changelogs.md, Agents.md properly written to your likings.
2- Depending on what you are building there is always a way to add actual UI tests and takes screenshots of before and after. If its a related to web UI, you can use playwright and or similar but there is always an option to test UI. Worst case scnerio is when none of libs help you and in those cases, you can add automated tests for UI using computer control from agents and take screenshots.
3- When reviewing PRs, always use a totally different agent. For example if you use claude code for creating PR, then perhaps ask Codex or Cursor to review the PR in depth.
4- Prefer smaller multiple PRs over larger ones.
5- Last resort: If you don't have to review and check PRs yourself, perhaps consider hiring a QA engineer if you can afford one.
Last but not least, learn to freeze the scope and remember not all bugs and edge cases are worth covering.
waximabbax
jesecamilo
drakonka
Opus 5.5 has made it pretty effortless to get right the first time tbh. Usually it even lays things out better than I was thinking originally
hhhkm