Software coding practices in an AI assistant world

AI-powered coding assistants, are rapidly transforming software development. Studies have shown that coding assistants can boost developer productivity and decrease time to task completion by up to 55%. By providing us with faster text completion, tools to improve code quality in areas like readability and maintainability, so freeing us up from repetitive tasks. This then allows us to focus on the creative and strategic aspects of software development that provide the real value add and job satisfaction - lets face it no-one likes writing boiler plate tests!! -- am I right?

However, to truly measure the impact of such tools we require a more comprehensive approach that considers not just speed and quality metrics, but also developer adoption, team dynamics and even potential biases generated by the AI model used by these tools. I've been developing software for a few decades (yes - decades - strokes gray beard ) and when I first started using coding assistants like Amazon Q, GitHub CoPilot and TabNine I got annoyed pretty quickly as they would consistently return incorrect results or misinterpret what I prompted them to do.

In this article I'll summarise some of these annoyances that I first came across when using these tools, and how I over came them by applying techniques like TDD and Pair Programming, techniques I have been using in the industry for the majority of the 20 years I have spent coding. These will be very much aligned to Amazon Q , thats the assistant I use the most, however they apply across the board, no matter what tool suits your current way of working. I've found that while the tool itself gives you a much faster pace, it is not magic. Its non-deterministic nature, where it generates various suggestions for a given prompt, can be an unexpected and potentially distracting feature - unless fully understood.

While Amazon Q developer has some awesome features, it's also good to remember that as a developer we have the ultimate power in the galaxy. The assistant may generate a 'moon' for example, when what you really want ( what you thought you prompted it to do ) is to build a space station !!! When I first started on this path, this would happen a lot and I would end up deleting the entire moon and building my own space station ( after turning off the assistant and grumbling into my coffee )

Instead of leaning back and relaxing because Amazon Q will code for you, you need to be extra focused on implementation decisions. Otherwise, you may miss relevant requirements of your code, as you are pulled in different directions by random recommendations.

Remember: you are still the owner of the controls here and in control of your destiny.

What I found was the tried and trusted practices of software development like test-driven development (TDD) and pair programming, helped to mitigate the occurrence of bad behavior from the assistant.

But what are these bad behaviors and how do I use these traditional techniques to address them ?

Well read on...

Amazon Q is an AI assisted tool for programmers. It allows users to interact with it in a natural language format and by issuing specific commands that give it enough context to complete code generation. Developers can describe their desired functionality through prompting or request completions for particular code lines. Amazon Q then analyzes the existing code base and contextual elements to generate relevant suggestions, ranging from code completions to entire pieces of code, tailored to what it thinks is the programmer's intent. Therefore what I see Amazon Q's real role as helping developers articulate their thoughts and understand the problem at hand ; and this just happens to be one of the aspects of pair programming too !

Comments are important when writing real code and it turns out they are really useful to AI Assstants too - but its all too easy to ignore them or "come back to them later" - however you are missing a trick if you do as your assistant is using them. So remember to always compose clear and concise comments before seeking code recommendations, this can significantly enhance the process of self-reflection and understanding. In essence, Amazon Q acts as a catalyst for internal dialogue, prompting developers to articulate their ideas and start the discussion with themselves.

Pair programming is a technique in software development where two programmers work together, either on a single computer or remotely - each taking turns to be the driver and the navigator of the code. The driver is typically responsible for typing code, while the navigator is responsible for guiding the implementation and also giving feedback and suggesting improvements. Pair programming promotes a culture of collaboration, error reduction and code improvement and its good fun working with your colleges. When working with Amazon Q however, just remember that it lacks the ability to question or challenge your assumptions, so it cannot give you alternative perspectives the way a human being can when pairing. That old critical thinking piece. ( well not yet )

TDD forces us to think about the problem in a structured way, breaking it down into smaller, testable units, also preventing YAGNI violations. TDD not only improves code quality through testing, but also promotes well-designed code. TDD also emphasizes tool chain and separation of concerns, design principles that make the code more flexible and adaptable to future changes, easier to understand, maintain, and modify. TDD also helps us to identify and address potential issues early on, reducing the likelihood of introducing AI smells later in the development process. Amazon Q is extraordinarily effective when suggesting big chunks of code and repetitive patterns, but there is always a risk of falling into some of the limitations described below. These limitations are not tool limitations per-se but limitations we have as developers that have been baked into our behavior over time. A time before the advent of the AI assistant itself. What do these limitations look like ?

Amazon Q's predictive nature makes it challenging to engage in a truly bidirectional dialogue. While the AI assistant can prompt us to think and reflect, it is important not to become passive recipients of its suggestions which can lead to some pitfalls such as the adoption of poorly crafted code, or even bad 'code smells'.

Interestingly, this can arise not only from relying solely on Amazon Q but also from solo coding. This is because our brains have a natural tendency towards laziness (even more so for developers ) and so gravitate towards familiar and repetitive tasks, as these require less cognitive effort. This tendency can lead us to take shortcuts and overlook important considerations.

But what if I dont have a buddy on hand to help me with these techniques ? - Well with awareness comes knowledge and by understanding what the limitations are, you can apply the following tips. These in turn will improve results that you get when using assistants, even when its just you doing the code. Used correctly the assistant can even morph into a lesser version of that coding buddy.

This refers to the unfortunate tendency to switch off the brain and accept everything, in an infinite Tab/Enter loop. Which occurs while using Amazon Q, because communication is unidirectional; it makes it all too easy to disconnect and simply accept its suggestions. Accepting every recommendation provided by the AI assistant requires less cognitive effort.

Pair programming encourages us to actively engage our own critical thinking abilities through discussion. It should force us to carefully evaluate the suggestions offered, and consider their relevance, maintainability and whether they adhere to good practice.

Knowing your context means that even when following good practices and prompt Amazon Q to do the same, it will still continue to suggest stale implementations or bad patterns. The only way to identify this is by knowing the bigger picture (or context) of the application. Which is a critical skill for software engineers as we often think about architecture and the best and minimum implementation for the feature.

Both TDD and pair programming help us think about context more and so can help mitigate this limit. One thing to take into consideration is that Amazon Q can easily generate more code than you need to make the next test pass. Some discipline and dialogue is required not to accept too much code in one go and avoid the auto-completion limit described above.

TDD and pair programming forces us to discuss approaches and solutions. Saying and explaining things out loud pushes us to reflect if we really have the right level of understanding or if we really have the best solution.

The sunk cost fallacy in this context is when we're hesitant to delete generated code, even though coding an alternative from scratch would yield a better long-term solution.

Regular pairing ensures that every line of code is reviewed by at least two individuals, promoting a sense of collective ownership. It fosters a code base that is both consistent and maintainable. It also allows objectively evaluating the current implementation, considering potential benefits, giving enough psychological safety to remove code snippets (or even the entire work) when necessary no matter who or what created it.

This is the ill conceived preference to accept the automated suggestions of Amazon Q over the manual code input that comes from us. It stems from an assumption that an output generated through computation is 'better' or more accurate than something done by a human.
In reality, Amazon Q often provides code snippets that aren't the most appropriate. Sometimes this is because the prompt isn't sufficiently precise; we may need to rephrase it or provide more information or context - and thats ok !

Pair programming keeps you focused by requiring you to communicate your progress and decisions to your partner. It prevents you from getting distracted and going down rabbit holes. When two pairs of eyes are looking at the code, we can better identify potential problems that might be overlooked by a single developer.

This is when we find it harder to develop alternative code implementations once we've seen a suggestion from Amazon Q. Pair programming can, again, be useful in tackling this: it can encourage reflection and discussion, which can lead to a deeper understanding of the problem, the code and other potential solutions.

As long as new tools will continue to find their way into the developer tool chain, what really matters is getting the best out of them. Sometimes to do this we need to apply techniques and practices that are new and sometimes ones that are older, but well understood.

Amazon Q (and similar tools) can enhance the quality of the software produced, but only if the development process fosters communication, and if the implementation is focused on iteratively producing clean and efficient code. Like all good software it is the product of many great minds and now we have an additional helper, with Amazon Q, to assist those minds in the art of building

There is a claim that such tools aim to transform people into better developers, this in my opinion is false, as the ability to generate code does NOT make one a good developer. Rather it is the understanding of what is required and the guiding of the development journey, that separates the better developers.

So using tools like Amazon Q, gives us time and more moments to step back and reflect, not only on velocity but on effectiveness gained by using them and so they then become the perfect companion for well known and widely accepted techniques like Pair Programming and TDD to help developers build.