Sonar: AI-assisted code or not, developers must ‘start left’

Shift left mindset

Organisations are beginning to understand the imperative of testing and analysing code to ensure that it’s clean. They’re turning toward a shift left mindset, using automated tools early in the coding process, but it’s not enough.

Shift left is wonderful, but we can start earlier.

Starting left — reviewing and analysing code from the start, with the right tools — is the solution. It avoids the problem of unwieldy tools that find too many problems instead of the most important ones and ensures that the code that makes it through to production is secure and high-quality. Taking code quality concerns one step further with this approach is the best way for organisations to not only release high-quality and secure software but also avoid the costly plague of technical debt created by those tools.

The increasing demand and advancements in AI for code generation alongside business demands for software mean that development teams are writing more lines of code than ever before — which can lead to increasing problems. In fact, code churn is increasing and is expected to double by the end of the year. So then, ‘shift left’ was already a top priority, but the rapid adoption and use of AI coding assistants mark a critical inflexion point for the practice.

The problem is that shifting left isn’t enough. 

To tackle the problem of bad code, exacerbated by AI, organisations are turning toward a system of ‘checks and balances’ and adopting automated tools that can equip teams to perform tasks faster and at a greater scale. But the rising amount of code being written and used means shift left doesn’t take things one necessary step further. 

Teams need to start code-scanning as early as possible — ergo, starting left.

A start left approach goes even further and avoids imposing the burden later on in the SDLC for developers. It’s clear that the best way to reduce tech debt and disruption in the CI/CD pipeline is to not incur it in the first place.

How to start left

How does a start left approach work?

A start left approach focuses on early tool integration to prevent bugs and vulnerabilities, continuous feedback and learning throughout the SDLC and fostering a collaborative development process. It requires organisations to enable developers with the tools they love — tools that are integrated into IDE and CI/CD pipelines, accurate, fast, user-friendly and inspire confidence. Further, paring down tools to the best and most necessary will save money and time during the development process and ensure companies actually discover and resolve the major issues that can affect software.

Rather than just finding problems, teams should focus on preventing code issues from occurring in the first place — which is all about quality. Starting left can lead companies to generate clean code from the get-go: code that is easy to read, maintain, understand and change through structure. High-quality code maximises its value when re-used, resulting in high-quality, reliable and secure software.

No unwieldy tools

A core component of starting left is tooling – not just supplying developers with code-scanning tools but using the right ones: not all code-scanning automated products are created equal. Too many prioritise the quantity of issues they identify rather than finding the real issues. In reality, companies can’t triage and fix the critical, costly problems as they become overwhelmed by the sheer number of them, including a bevvy of false positives.

Already, developers spend up to 42% of their time managing code-level technical debt, which slows velocity and productivity and is counterproductive to what AI is looking to solve. AI models can generate syntactically correct code that is not necessarily optimised for clean code practices, leading to code that is harder to understand, modify, or extend.

Trying to rectify some of these smaller code problems retroactively can also contribute to technical debt, costing businesses $2.4 trillion annually.

Clean As You Code

Manish Kapur, senior director for product & Solutions at Sonar.

To ensure teams don’t waste time tediously fixing a large volume of lesser problems, they should take a Clean As You Code approach to development as well as look at resolving imperative issues found. Code evaluation for quality and security should truly start in the integrated development environment (IDE) and extend through Pull 

Requests and the CI pipeline of the DevOps platform. It’s not enough to have tools. Teams must ensure the ones they use fit the Clean as You Code model and don’t create more problems for developers than they actually solve.

Longevity & integrity

Our software-dependent world has made code more important than ever. The demand for and integration of AI in the coding process have resulted in developers writing increasing amounts of code, all of which must be analysed and tested for security and quality.

Developer teams understand the necessity of writing quality and secure code, but it’s not enough to shift left for code security or simply use automated tools. Instead, teams must start left with tools they know they can trust and employ a Clean as You Code methodology. This not only ensures code quality but also avoids the issue of unwieldy tools that focus on identifying a large number of code issues rather than priority problems and finding solutions, which accrues costly, avoidable tech debt. Ultimately, shifting left is a step in the right direction, but it’s not the best way for businesses to release software with quality and longevity.

As we continue to use these tools and rely more on AI for coding, proper safeguards are crucial to protect the integrity of code and ensure it continues to serve as a vital business asset.