I'm constantly out of Codex quota — because finally there's a tool that can build the backlog of things I've always dreamed of! As always, the problem with code quality is that it competes with the velocity of development. You want more velocity? Fine, then you'll have more technical debt. Less velocity tends to mean less technical debt.
Agentic AI excels at coding, but it tends to cut corners, just like humans do. When your classes are approaching 2000 lines for a simple recipe application, even the agent struggles with it. The problem is that an LLM doesn't really stop and think "Oh, there's a lot of technical debt, I will have to clean it" if you don't have that in your prompt. This is why human oversight is still needed, and it might be that it will always be needed with this technology.
However, it is possible to steer an AI agent towards better practices, and I don't mean putting "do not make mistakes" into your prompt when saying that. Here are a few tips to get started:
Spec driven development
Before shooting feature prompts like there is no tomorrow — take some time to plan first. Use either Linear.app or JIRA and write your spec into implementable tickets and guidelines. Or use architectural documents in Markdown format. In this case, the more the better: ask AI to create database schemas, API contracts, everything it can think of for these documents. Then, go through the planned tickets, adjusting them either by prompting or editing yourself. Once the spec is done, it's just so much easier for AI to do the actual implementation against it. The tickets also keep track, for both AI and for you, of what was done and what is still missing.
Without these documents, the agent must burn a lot of tokens and context window to figure out from the code "how does this work". Even with a small drift, the documentation provides a sense of what the codebase is about and what kind of problem it tries to solve.
Write good test harnesses
When GenAI started rolling out to users, the first vibe-coding iteration was that you ask a chatbot to write you code, then you copy-paste it to your editor, try to run it, and see if it works or not.
Now that agents can not only write but also run code, testing becomes a breeze. Instead of testing everything yourself, you can ask the agent to eat its own "dogfood" and try the application itself. It's surprisingly effective at writing good tests.
Do not settle for an "All tests are green ✅️" comment from AI — ask for proof. Screenshots or, better yet, videos of Playwright test execution. Even an LLM is unable to hallucinate that.
With a good test harness, your agent doesn't break existing functionality. When this happens, the first impulse is, of course, frustration. But is that the fault of the agent? I'd say it doesn't really matter if you or the agent break existing functionality — it's more of a sign that your test harness is not good enough and not ready for agentic coding. The fix is simple: improve the test harness. And for that, ask the agent for help.
Use linter rules
I used to hate linters — mostly because while I care about good code quality, I hate fixing the findings. But that's not a problem anymore with agents, and since then I've grown to love them.
Create strict linter rules — AI agents usually tend to put everything into a couple of big files, and why wouldn't they if you haven't prompted otherwise? Instead of trusting CLAUDE.md or AGENTS.md, it's better to codify your requirements through linter rules.
And if there isn't a linter rule that fits your needs, nothing is preventing you from prompting the creation of your own. Here are a few I invented for a React application (yes, I'm now also a frontend developer, thanks to Codex 😁):
no-restricted-propertiesforces a shared i18n date formatter and bans usingtoLocaleDateString(). Useful when you want to support multiple locales but in a controlled way.no-restricted-syntaxbans brittle CSS selectors — only semantic queries orgetByTestIdare allowed.
These are also good ones, from the community:
sonarjs/cognitive-complexitybans functions that have a cognitive complexity of over 30. Cognitive complexity means there are too many (nested) if/for/and/else structures, which tend to increase cognitive complexity.max-linesmax 500 lines per file. It's not an ideal rule of thumb, but it keeps the context window within limits, as the agent does not have to read thousands of lines every time it has to do a simple change.sonarjs/no-duplicate-stringflags strings repeated 5+ times
Golang also has very good linter rules available in golangci-lint . Here are a few you should at least consider:
cyclopcyclomatic complexity max 12 per function, avg 8.0 per packagefunlenmax 100 lines or 60 statements per functionunusedflags unused consts, vars, functions, and types
These rules force the AI to write smaller, more understandable, and testable classes/files/functions, which leads to less cognitive complexity and, by design, better architecture. The benefits are clear for AI as well: fewer tokens spent, less context window used while reading mega large files, and also a possibility to use multiple agents simultaneously in a codebase if you are feeling adventurous.
And this is just the start
Adding pre-commit hooks to make sure bad code does not end up in the repository... adding CI/CD hooks for running tests… enforcing formatting with Prettier or gofmt… running linters automatically on every commit… blocking merges if coverage drops… scanning dependencies for vulnerabilities… There's a lot we could still add.
And you know what? All these should already have been there, even before the era of Agentic AI. A lot of quality gates make sure your code stays high quality. Agentic AI doesn't replace good engineering practices — it amplifies them. If your foundations are weak, it will show immediately. If they're solid, it becomes a force multiplier.
If you'd like to learn more about engineering these guardrails, NorthCode offers a separate training workshop where we'll set up these guardrails for your live codebase. Learn more here.
