I'm tired of AI coding tools producing duplicated functions, huge bloated methods, unsafe casts, and schema changes that only make things appear to work. When I'm not carefully reviewing every change, the codebase quickly becomes inconsistent.
I've already set up typescript-eslint with strict type checking, SonarJS, and Knip, but I'd like to build a more complete quality process for a large project I'm developing alone. I'm especially interested in learning how to configure ESLint effectively, write useful custom rules, and combine linting with tests and other static analysis tools.
I also want to improve how the AI follows my existing standards. It often generates pointless tests that check visual details, such as whether a button appears in a particular location, instead of testing behavior. The project is an Nx monorepo containing Next.js, React Native, Fastify, and Python applications. What resources or practices would help me create guardrails that catch bad code early while still leaving the final review to me?
3 Answers
Custom ESLint rules are worth considering when your codebase has conventions that generic rules can’t express. For example, you could require every DTO file to contain exactly one class, require decorators on all its properties, and forbid constructors. A custom rule can turn that kind of team-specific standard into an automatic check instead of relying on the AI to remember it.
Start with a clear set of project conventions and enforce the mechanical parts with ESLint. You can also keep an instruction file for your coding assistant that explains which patterns to follow, where existing implementations live, and which checks must pass before it considers a task complete.
That won’t replace reviewing the diff, though. AI tools usually won’t inspect the entire repository every time, so explicitly tell them to look for and reuse existing code instead of inventing another version. The more relevant context and examples they receive, the less often they’ll ignore your established conventions.
ESLint can enforce patterns and catch many mistakes, but it can’t judge overall design or code quality. Use it as a guardrail, then rely on tests and your own review for behavior and architecture. For AI-generated tests, specify that they should verify observable behavior and meaningful failure cases rather than implementation details or layout.
It also helps to make the workflow explicit: have the assistant run formatting, linting, type checking, unit tests, and any affected application checks before presenting a change. Better prompts or reusable task instructions can reduce the back-and-forth, but the final review still needs to be yours.
That’s what I’m aiming for. I don’t want to outsource code review to a tool; I want a process that prevents the assistant from writing code that obviously violates my standards, so I can spend my time on the final review instead of repeatedly correcting the same issues.
There’s also a practical context-size limit. Configuration files and instruction documents consume the same context as the rest of the prompt, so an enormous set of rules can become less effective. Keep the guidance focused, and put the most important constraints where the tool will consistently see them.