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.
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.
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.
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.
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.
Yeah I feel like what you say makes sense. Part of my issue comes from the fact that we're a pre-PMF startup, so rapid experimentation and prototyping really matters at the moment with very little room left for deep thought around testing and benchmarking.
The trouble comes later when the "experimental features" actually start getting traction and we discover all the holes in our implementation.
By the time we need to "productionize" our experiment, it has already been patched all over the place to account for bugs.
I get a feeling that this is made worse by the fact that since a lot of what we're doing is rapid prototyping, our repo is cluttered with examples of bad code that the agent picks up on and then goes ahead to copy in its own implementation.
I get that we need to clean this up, but it's crazy trying to figure out where to start and what to tackle
One of my mantras is 'fast is the best UX'. Users will put up with minor annoyances as long as they're over with quickly. Once you fix the annoyances, you're still fast, which leads to User Delight.
> I get that we need to clean this up, but it's crazy trying to figure out where to start and what to tackle
Enumerate, then fix-or-nix all known examples of bad code first. If you clear the path first, you will advance more quickly. It can feel frustrating having to do that, but my experience is that paying off tech debt earlier will prevent hitting the wall at an inopportune time.
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
With great difficulty - it's very hard to keep LLMs from generating codebases that are hard to reason about for humans - the spaghetti intermingles with a ball of mud.
So far, my most successful ventures have been tiny CLIs that do something I have been itching to write that one day when I'd had some free time (that never materialized).
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.
Coming from someone with a non technical background that has started building things post AI, I think what helps me the most is referencing other successful products and learning from their bad reviews/mistakes.
Now to your question specifically, I believe it's not that hard to maintain quality when you're not obsessing over a million features, what I've seen people do is make their app or software do everything instead of focusing on a sum of functionalities that are actually worth keeping and will certainly impact the user experience.
I have Claude run the simplify and code-review skills as part of verification. Also every month or so I use the tech-debt skill on all my codebases and fix any issues. The more tech debt you have, the more the models start doing strange things.
And the usual stuff any decent CI pipeline should have: tests, builds, linting, SQL breaking changes and potential heavy migration checks, etc.
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'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
I'm going to try out having product specs committed in the repo itself - hopefully this gives every agent I spin up context into how the product is supposed to behave as opposed to having to "guess" it from reading the code adjacent to whatever prompt I gave it
what helped me is not letting the agent touch code until theres a plan for how it fits the expectation and existing code, and actually pushing back on it. then review the changes, not just "does it work"
You are part of the ecosystem, try to go with the flow, make the most out of what you can and accept that fact that at the end of the day its a trade off. You are optimizing certain things like speed and features at the cost of understanding, confidence and possible bugs.
If you want to be focus more on quality than speed then software engineering may not be the right domain at this point of time.
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 view any LLM generated code as a movie set, something that looks good, and has to last for one use. Use it like you would use Harbor Freight tools, as something to get a job done once, but not something to rely on.
LLMs can give you the API calls, and help you figure out how certain libraries work, but they're going to fail spectacularly on quality. I don't see any way around this for the next year or so.
The only positive suggestion I have is to keep the scope of your prompts tightly controlled. Be very, very specific in what you want, avoid wiggle room.
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.
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.
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.
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.
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.
Yeah I feel like what you say makes sense. Part of my issue comes from the fact that we're a pre-PMF startup, so rapid experimentation and prototyping really matters at the moment with very little room left for deep thought around testing and benchmarking.
The trouble comes later when the "experimental features" actually start getting traction and we discover all the holes in our implementation.
By the time we need to "productionize" our experiment, it has already been patched all over the place to account for bugs.
I get a feeling that this is made worse by the fact that since a lot of what we're doing is rapid prototyping, our repo is cluttered with examples of bad code that the agent picks up on and then goes ahead to copy in its own implementation.
I get that we need to clean this up, but it's crazy trying to figure out where to start and what to tackle
One of my mantras is 'fast is the best UX'. Users will put up with minor annoyances as long as they're over with quickly. Once you fix the annoyances, you're still fast, which leads to User Delight.
> I get that we need to clean this up, but it's crazy trying to figure out where to start and what to tackle
Enumerate, then fix-or-nix all known examples of bad code first. If you clear the path first, you will advance more quickly. It can feel frustrating having to do that, but my experience is that paying off tech debt earlier will prevent hitting the wall at an inopportune time.
If you’re pre PMF then don’t worry about code quality. (Seriously)
Pump out features and iterations as fast as you can until customers are buying your product.
Startups fail because they can’t find customers, not because their code quality is low.
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
With great difficulty - it's very hard to keep LLMs from generating codebases that are hard to reason about for humans - the spaghetti intermingles with a ball of mud.
So far, my most successful ventures have been tiny CLIs that do something I have been itching to write that one day when I'd had some free time (that never materialized).
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.
Coming from someone with a non technical background that has started building things post AI, I think what helps me the most is referencing other successful products and learning from their bad reviews/mistakes. Now to your question specifically, I believe it's not that hard to maintain quality when you're not obsessing over a million features, what I've seen people do is make their app or software do everything instead of focusing on a sum of functionalities that are actually worth keeping and will certainly impact the user experience.
I face similar problems on a daily basis. Mostly UI bugs, and copywriting.
Fixing these is exahusting. What I ended up doing was building a "feedback"[1] tool I can point to my agent.
Basically, I collect bugs/improvements and then tell codex to fix them.
Being able to gather a bunch of bugs in a working session has been a boost in productivity.
[1]. https://pecky.app
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
I have Claude run the simplify and code-review skills as part of verification. Also every month or so I use the tech-debt skill on all my codebases and fix any issues. The more tech debt you have, the more the models start doing strange things.
And the usual stuff any decent CI pipeline should have: tests, builds, linting, SQL breaking changes and potential heavy migration checks, etc.
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'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.
Yeah, I'm going to try this out the coming weeks.
I wonder if there are people around who have stories to share about de-AI-Slopifying a codebase.
[flagged]
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
I'm going to try out having product specs committed in the repo itself - hopefully this gives every agent I spin up context into how the product is supposed to behave as opposed to having to "guess" it from reading the code adjacent to whatever prompt I gave it
[flagged]
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.
1. Design first. Vibe design before vibe code 2. Build all CRUD operations for all data entities and clean your database regularly
what helped me is not letting the agent touch code until theres a plan for how it fits the expectation and existing code, and actually pushing back on it. then review the changes, not just "does it work"
You are part of the ecosystem, try to go with the flow, make the most out of what you can and accept that fact that at the end of the day its a trade off. You are optimizing certain things like speed and features at the cost of understanding, confidence and possible bugs.
If you want to be focus more on quality than speed then software engineering may not be the right domain at this point of time.
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
always review what claude has done and try to know what is it
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 view any LLM generated code as a movie set, something that looks good, and has to last for one use. Use it like you would use Harbor Freight tools, as something to get a job done once, but not something to rely on.
LLMs can give you the API calls, and help you figure out how certain libraries work, but they're going to fail spectacularly on quality. I don't see any way around this for the next year or so.
The only positive suggestion I have is to keep the scope of your prompts tightly controlled. Be very, very specific in what you want, avoid wiggle room.
Remember, "There will be a quiz".
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.
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]
[dead]
[dead]
[flagged]
[flagged]
[flagged]
[flagged]
[flagged]