Seven Habits of Highly Effective AI Coding

In the past year, AI coding has gone from novelty to necessity. However, much of the conversation around AI coding focuses on vibe coding within relatively “de novo” use cases. There is no question that tools like Cursor and Windsurf are making software development accessible to everyone.

Most companies — and a large number of developers — don’t work in this environment. They work in the context of large, legacy codebases that can be millions or even billions of lines long. The cost of a mistake in these environments, whether a bug or a security issue, is huge. Some estimates say that the cost of bad software is over $2 trillion per year.

These massive codebases can hugely benefit from developers using AI coding tools, but they must be harnessed in a responsible way. In this regard, AI coding is no different than “regular” coding:

• You need to ensure there are no obvious bugs or vulnerabilities and that the code is performant and robust;
• You need to be certain all third-party libraries are safe, up-to-date and properly licensed;
• You need to ensure that your new code is readable, so humans and large language models (LLMs) can assess it and minimize the chance that something unintentionally sneaks in;
• You need to ensure that your code is maintainable, so your codebase doesn’t become more brittle as more AI code is written.

At Sonar, we regularly talk to thousands of developers working in hundreds of companies, and our products analyze more than 300 billion lines of code a day. It is clear from these conversations that we need to establish clear best practices for using AI coding tools inside organizations.

So with that in mind, here are seven AI coding “habits” that organizations should adopt:

1. Golden Rule: Developers Are Accountable

“You break it, you own it” is often referred to as the Pottery Barn rule. For AI coding, we need a new variant on this. As a developer, if code you accept from an AI tool breaks, you own it. We believe there is an accountability crisis related to AI code. Some customers have told us they are seeing their developers accept over 95% of AI coding-generated pull requests. This suggests that the code is not being scrutinized at all — a lack of ownership. In every organization, the golden rule has to be that developers are responsible for their code, regardless of whether they wrote it or accepted it from the AI coding tools.

2. (Over) Document Your Project Context

Mermaid diagrams, project structure files, design structure documents. Developers and architects have been using these for years. In an AI coding world, we’d err on the side of excess. Clear, comprehensive project documentation outlining the project’s intentions and how it is designed to work will help developers ensure new code fits into your overall architecture. Robust documentation also provides critical context to AI coding tools and agents to operate more effectively on your codebase.

3. Keep It Simple — Really

Code entropy is real. Codebases that are not properly maintained will become more and more disordered. It is impossible to maintain a codebase if that code is not readable — OK, maybe not impossible, but very, very difficult. Anyone working with AI coding needs to establish rules to ensure simplicity, prompting LLMs with these guardrails in the context window and checking to ensure that the guardrails are followed. What are the guardrails? We hear three fairly often, and you can consider these either an “and” function or an “or” function:

1. Guardrail A: All functions should be less than X (50-100) lines long
   AND/OR
2. Guardrail B: You need to minimize Cognitive Complexity (you can use Cyclomatic Complexity if you prefer)
   AND/OR
3. Guardrail C: You need to keep the level of duplications as low as possible

4. Absolutely, Positively No Stray Code

This point is software development 101 but crucial in AI coding. LLMs will often produce code that ends up not being used, incorporating for example, unused references. There should be no stray code in your AI-generated code. Not only does this make it harder to understand and maintain your codebase, it also introduces significant security risks. For example, malicious actors can start tricking LLMs to include seemingly benign references or dependencies that are not used now, but could be used with bad intent in the future, creating a massive security hole for you. This is called backdoor or sleeper agent injection, and it is just one example of the many ways LLMs can be modified to produce new attack vectors. It is a great example of why secure code must be high quality and fit for purpose.

5. Analyze Everything

The volume of AI-generated code is overwhelming, and the issues that it creates are often subtle and hard to find. You’re not just looking for spelling mistakes and misplaced semicolons. You need to ensure that there are no complex bugs or known vulnerabilities. You have to also ensure that third-party libraries the AI suggests are properly licensed and well maintained. Developer review is essential, but this just adds to the toil that kills developer productivity and happiness. No developer wants to be a copy editor for AI, and without the appropriate tooling, they cannot keep up with the volume or complexity of the issues that may be lying in AI code. It is vital to equip developers with solutions that can help identify and triage issues for review. These solutions should be deterministic, with a high level of trust and transparency to balance the non-deterministic AI output.

6. Mandatory Unit Tests

Some companies have a high bar for code coverage. All companies need that high bar. Comprehensive unit test coverage on AI-written code, and continuous execution of the tests, is a must, with the tests written in advance and certainly not by the same coding agent that is writing the code. AIs can learn how to cheat unit tests (aka reward hacking).

7. Rigorous Code Reviews

Analyzing code for issues is only part of the solution. The only way to ensure that the AI coding habits are universally adopted is to have a strong discipline of code reviews in place. Pull requests must fail if the best practices are not followed, and developers need to be able to remedy the issues quickly. This requires a lot of discipline in the development teams, and best-in-class tooling to facilitate and automate the checks.

These AI coding habits can rightly be called software development best practices. However, in a world of widespread AI coding usage, we have to raise expectations. Best practices that may have been considered no longer “nice-to-haves” are now “must-haves.” Code that you introduce now will likely persist in your codebase for years, maybe decades. Just think about how much COBOL code is still in the wild.

There is no question AI coding models and tools are rapidly improving. However, no matter how good the models become, companies have to ensure their code is built securely, is maintainable over the long term and that the technical debt remains under control. As with our health, an ounce of prevention, bolstered by strong habits, is worth a pound (or more) of cure.

Pairing with solutions like SonarQube’s AI Code Assurance feature, which operates seamlessly at the code review stage, organizations can easily assess whether each of these best practices is in place in the AI-generated code itself. If AI Code Assurance finds severe issues, the pull request doesn’t move forward and developers are given the list of issues that are causing the failure. Trust and empower your development teams and always verify.