Improve Agent Mode Code Generation Reliability and Validation Process
Improvement
Claude code is fantastic. Lets make it better. At the moment in agent mode when it completes a task it says things like 'ive successfully completed x and y. ' and then makes a set of claims about what it has done. normally the first time this is complete nonsense. It usually takes 8 to 10 goes to sort out the problems, and sometimes they fail anyway. So my suggestion is don't make these claims! change the prompt response to something like 'ive implemented a first draft of the changes, now lets test them to see what weve got' or something like that. More broadly still, look at git: BMAD-method, that haa more sophisticated ways of building apps. Essentially BMAD is using an architecture much closer to what professional software engineers use, both in documentation and implementation and testing. If you set this up as a default, the quality code will be much better. I'm a no coder, but i want my code to be enterprise quality. so does everyone else. Claude Code can pull ahead of everyone even more if it does this.
13 Comments
I have a repo that solves this issue with one md file. It is a complete workaround until this is updated officially. Ran into the same issues , this is the most consistent across, rust, c+, machine learning tasks, python, html, node, application development, complex algorithms, cuda coding.
Hope it helps
that is absolutely brilliant! Thank you. Does it make sense just to incorporate it directly as a section of claude.md? The problem of LLMs fictionalising is getting worse it seems. OpenAI Agent is high as a kite. I suspect that the models, when overworked, have two choices 1) generalise 2) lie. They do a bit of 1 but mostly 2. Some people have been saying the problem is with overambitious prompts, which could be a fair crit as well.
Don't Make the the claude.md too big, may cause truncation. Just make a rule that claude needs to reference the rule before and after each task.
A good pair is to have a good PRD and Break up large tasks into phases and phase gate him, make sure he gets your conditional approval at the end. (I literally have him on dangerously skip permissions constantly, and only if he gets stuck or finishes a major task or phase will he ask me my permission and provide me a summary of what he has done and a checklist if it falls inline with the hard rules.)
This is the claude.md im using at the moment. What do you think?
Data Handling and Logic
Dynamic processing – Always work with live data structures at runtime; never hard‑code counts, sizes or indexes. Use language‑native methods for sizing, iteration and checks. Dynamic data improves realism and coverage in testing, helping uncover edge‑case defects
Treat all cases equally – Do not assume where special cases, patterns or exceptions may lie; process all relevant data and let the data reveal patterns. Avoid preset logic based on legacy code; start fresh.
Validation, Testing and Verification
Exhaustive validation – Validate every output, change or feature against all required cases before proceeding. Aim to cover as many input combinations and user states as practical to reduce undiscovered defects
Include edge cases (smallest and largest inputs, unusual user behaviour). If any test fails or required data is missing, halt and fix the issue before continuing.
No untested claims – Never claim that code works without running it. Always test your code and scripts before including them in documentation. Deploy early and test in environments that mirror production to avoid "works on my machine" problems
Use automated and manual reviews – Leverage automated tools (linting, type checking, static analysis, security scanning, and unit/integration/E2E tests) alongside manual reviews. Structured code reviews improve quality and security and prevent undetected bugs and technical debt
Dynamic test data – Avoid static sample data in tests. Generate realistic dynamic data (e.g., varied names, timestamps, UUIDs) using random data generation or parameterized tests. Dynamic test data enhances realism, coverage and reliability
trissential.com
and mitigates flaky tests
Quantified success criteria – Define clear, measurable success metrics (e.g., response time thresholds, zero test failures). Do not rely on vague descriptions; quantified targets ensure accountability.
Documentation and Changelogs
Immediate documentation – Update project logs, changelogs and todos after every meaningful change. A changelog should contain a curated, chronological list of notable changes for every version so users and contributors can see precisely what changed
Structured documentation – Provide comprehensive README, architecture documents, API documentation, deployment guides, and troubleshooting instructions. Good documentation acts as a "single source of truth" that improves knowledge transfer, compliance and onboarding
Feature Design and Implementation
Generic, extensible designs – Build features to support all relevant inputs or states. Use relative logic (ratios, dynamic indexing) rather than hard‑coded thresholds. Design for scalability and future growth; test on both smallest and largest observed inputs.
No placeholders or magic numbers – All code must be production‑ready. Do not use TODOs, placeholders or incomplete implementations; avoid hard‑coding array sizes, indexes or business logic without dynamic checks.
Modular, reusable code – Break down complex tasks into smaller, manageable functions following separation of concerns. Modular code is easier to test, maintain and reuse
Tooling and Environment Setup
Consistent environment – Ensure necessary tools (e.g., Playwright, Docker, GitHub CLI, language runtimes and testing frameworks) are installed and configured. Use scripts to create development environments and verify installations.
Project structure – Adhere to an enterprise‑quality project structure with core files (README, CONTRIBUTING, CODE_OF_CONDUCT, LICENSE, SECURITY, CHANGELOG), directories for documentation, tests (unit, integration, e2e, performance), scripts, Docker configuration, and separate configuration files for different environments.
Version control and CI/CD – Use GitHub workflows or equivalent for continuous integration (running linting, type checks, tests, security scans) and deployment. Enforce branch protections and require pull‑request reviews with multiple approvals.
Quality Gates and Continuous Compliance
Pre‑commit checks – Run mandatory validation scripts before committing changes: linting, type checking, security scanning (e.g., npm audit, bandit, gosec), unit and integration tests.
Security and compliance – Implement secure coding practices: input validation and sanitization, authentication/authorization, encryption of data in transit and at rest, secrets management. Follow industry regulations (e.g., GDPR) and conduct regular vulnerability scans and audits.
Monitoring and observability – Provide structured logging, metrics and health checks. Implement error tracking, performance monitoring and alerting to detect and respond to issues quickly.
Disaster recovery and backup – Plan for failure: create automated backups, cross‑region replication, rollback capabilities and incident response playbooks.
Performance and Scalability
Performance targets – Define performance goals (e.g., API response time, database query time, uptime) and test against them.
Scalability – Design for horizontal scaling, database sharding, caching and load balancing. Implement resource monitoring and auto‑scaling policies.
Communication and Collaboration
Explicit communication – Clearly report what was done, what was tested, and the exact results (including numbers of items processed, tests run and failures). Raise questions or blockers immediately.
Collaboration standards – Use issue and pull request templates, code of conduct and contributing guidelines to foster inclusive and efficient collaboration.
Enforcement and Continuous Improvement
Violations and corrections – If any rule is violated, stop immediately, fix the issue, log the violation in the changelog, re‑validate affected work and acknowledge the root cause.
Continuous improvement – Regularly review and refine these guidelines based on lessons learned, emerging best practices and feedback from teams.
These combined guidelines integrate the dynamic, data‑driven mindset and strict testing/validation rules of the Universal Hard Rules & Constraints with the comprehensive, enterprise‑grade processes of the CLAUDE.md standards. Together they promote robust, adaptable, secure and maintainable development while ensuring full transparency and accountability at every step.
I've run into this problem over and over again despite very explicit instructions in CLAUDE.md. Claude will forget to run the full set of tests no matter what I do. I remind it, and it says oh I forgot or some other meaningless excuse. I've asked it what I should do to get it to follow the rules, and its recommendation to me was to add "be sure to follow the Workflow Rules section of CLAUDE.md" every time I give it a request to start a coding task!
Worse yet, I've had times during this process where it would make the worst excuses for obvious test failures. Like there were 20 breaking tests, it would fix 18 of them and say "the other test failures are minor" with no basis. Or if a test failed because it couldn't access the db, it would say "its an environmental difference, its supposed to fail." It was not. Before I added the instructions to CLAUDE.md, it would regularly just compile the file it generated, it wouldn't even link it let alone write/run tests. That code never worked, ever. Felt like working with an engineer just out of school.
This is a good start but more concise is better than longer detail. Ill post an example of this using the my MD repo you used. :)
You can put a wrapper on all claude prompts that forces it to re-read claude.md each time, with some optional improvements. Best part, CC can implement this itself. Works sort of well, as long as your claude.md isn't too long. There are some more advanced things you can do if you set up google memory bank and make your own MCP for it, or try a Neo4J knowledge graph, but that's probably overkill; something tells me this will get fixed, because it's really gone downhill. I suspect it's because we're being served different model types to test user frustration and feedback. See here for memory wrapper example.
claude-code-memory-wrapper.md
FWIW, I did a massive rework of my CLAUDE.md to make it shorter and split
other parts out into referenced docs. It sped things up a lot, and CC seems
less confused now.
On Sun, Jul 20, 2025 at 10:23 AM ALeslie743 @.***>
wrote:
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
@ALeslie743
I want to adapt this and credit you, can you post this as a Gist on your Github?
This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.
This issue has been automatically closed due to 60 days of inactivity. If you're still experiencing this issue, please open a new issue with updated information.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.