There’s a plethora of AI tools available for software developers, and they offer fantastic productivity benefits in the right hands. But like all large language models, even coding AIs make stuff up, so you need to treat your AI like a precocious kid who’s smart but still has imaginary friends!
The best part of AI as a coding assistant is that the models have been trained on every line of code that exists publicly, and every scrap of documentation. AI doesn’t have memory lapses like I do, so it retrieves all this information on demand. My own retrieval system is erratic, and consists of lots of muttering “what was that command again?”. Not a problem for the AI.
There is a catch: you have to ask it in exactly the right way to get the response you want. There’s a whole new term for talking to AI engines, namely Prompt Engineer. It certainly is a skill, but not an insurmountable challenge.
My preferred AI assistant is one that integrates into your development environment. These types are context aware of what you are working on, and give very good help as you work. I particularly like shifting the tedious work off to the AI like “please generate a POCO for class x” and it will write all the boring constructor assignments for the object, exactly correct for the class that exists in my code.
I love having the AI as my permanent pairing partner, jumping in to ease my way as I work. Having the AI integrated into my dev environment keeps me in the flow, and is just more productive for me than hopping out to a browser to go find docs.
My top benefits have been in getting help with unfamiliar library code, generating repetitive code, and writing unit tests.
As you can tell, I’m really enjoying working with AI, and I don’t fear that it will replace me anytime soon. For all that we call it “intelligence”, the foundation of these models is the ability to interpret natural language in order to retrieve existing information from the vastness of the internet. They are not creative in any way. They do not solve new problems.
Let’s also return to how AI makes things up. AI does not understand the answers it gives in any human sense. The code-specific AI is less prone to returning nonsense answers, as its source material is actual working code and the problem space is more constrained. The AI will do its best, and often that is misleading. A more senior software engineer will be able to evaluate the AI suggestions, and quickly discard ones where the AI is off track, but juniors can be led wildly astray.
For a junior developer, AI can be an actual productivity sink rather than an accelerator. That’s quite a disappointment, as it would be fantastic if AI could teach junior developers to write better software. The tech is not there yet.
Even worse, when AI is used by juniors and it does get it right, it encourages “monkey see, monkey do” behaviour. There are already worrying studies on how people can delay their own learning by leaving it all to the AI – a kind of “falling asleep at the wheel” phenomenon.
At KRS, we have provided AI tools only to our more senior developers. We are still doing old-fashioned, human-led mentoring of juniors, based on individual needs and skill levels. We want knowledgeable, engaged, creative people, who can use AI as the tool it is, no more, no less.