I personally build rules using static analysis tools. All my guardrails hook into my .NET static analyzer pipeline. This makes the agent fail at build time then it goes and corrects itself.

Additionally, .NET added a bunch of formatting rules in its static analyzer for .NET 11 that give greater control on the styling of the code the agent generates. For example you can ban `=>` function syntax using editorconfig. The build will fail and the agent has to adjust.

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.

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.

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.

always review what claude has done and try to know what is it

OpenSpec solves this incidentally by dividing work into planning, implementation, and archiving phases. If you tell it what you're doing and the business reasons during planning (and bicker with it about technical implementation) then it goes off the rails much less when it actually does the work. You can also PR the spec to coworkers before implementation and run the implementation step in a new context to keep it more on track.

Have a vision, and know what to say no to [0]. Thats how I build all my own projects, most recent here for example

[0] - https://github.com/con-dog/clingon

My cofounder and I built https://www.archme.io for this.

It is an abstraction on top of code, turning your codebase into architecture diagrams and then keeping them up to date on each commit.

As a bonus you can do PR review and propose changes in it as well.

I don’t think it is “you” that deals with this. You have outsourced your engineering to Claude, so Claude must deal with this, and if it’s not good enough to deal with that task just yet, you should wait for improvements to Claude until it is. (Some of the other suggestions here are good; it is possible that Claude already is good enough to deal with the task and you’re just not asking it correctly.)

I'm not sure if there is any standard for this, I also tried to search about it in the past. But what I ended up doing that has been working well is to keep everything documented. Every task and decisions are documented on .md files, referencing related tasks and decisions. The project becomes bloated quickly, but Claude can easily locate and relate decisions from a long time ago. Some times I even ask to do do something and mid-way Claude realizes that it goes against a previous written decision.

The same I was facing now I have built complete app but always worried about it is really protected and production ready I also facing this issue I don't know what to do

Remember, "There will be a quiz".

Just know what you're doing, what and how you want it from a coding agent. It saves time on typing but not on thinking

The way I deal with it is to not have an agent write all of my code. Hand tools didn't become obsolete after power tools were invented.