Developers love an AI code assistant – and so, it seems, do their employers. Upwards of 97% of the former, according to recent research by GitHub, use coding tools in and outside of work. While this didn’t necessarily equate to official corporate sanction of coding assistants in each case, a “strong majority” of firms either tolerate or actively encourage their use.
WithSecure falls into the latter camp. As its chief architect Ari Inki explains, the cybersecurity firm not only encourages its developers to make active use of code assistants but also carefully regulates their procurement and internal usage. As with all architectural decisions, says Inki, the ultimate goal is to settle on assistive technology that it can invest in “once and use many times, in different places.”
Speaking to Tech Monitor, Inki explained that WithSecure had now tested four different coding assistants before settling on a single platform provided via AWS’ Bedrock service. That experimentation phase began with his team deciding precisely what they needed from such technology. Ultimately, recalls Inki, his colleagues wanted to avoid “ending up in a situation where the only thing that you’re constantly doing is just testing, testing, testing.”
Choosing the right code assistant
It made sense, he adds, to consider the bigger brands first. This was partly because they had more experience to draw on in training and building the tools. They were also better placed to handle security considerations, says Inki, including “how to sanitise the outputs that those code assistants can give.”
That includes the possibility of a code assistant generating code that could be covered by a “copyleft” license. This creates uncertainty, said Inki, not least as it’s not clear what sort of legal liability this could create. “It would be a bold company who would want to sort of test that first,” Inki said.
Next came user testing. WithSecure ran several pilots with its candidate applications, letting teams experiment with the tools and use them in their daily work before soliciting feedback. Ultimately, Inki says, “It’s surprisingly easy to read the situation – which got traction, which were the delightful tools.”
On a practical level, he says, the smoothness of the developer workflow and experience is key. How well a coding assistant integrates with a developer’s preferred IDE is critical. “The top-notch model isn’t necessarily the thing,” says Inki. “If the tool integrates into, for example, a Git workflow, then that’s a really natural way of forcing developers to use it.” By contrast, some tools were more disruptive and required developers to switch to their own interface or portal, suggestive – for now, at least – that code assistants allied to the key Git-based platforms have more appeal among experienced coders.
WithSecure is continuing to use developer feedback to judge the success of its code assistant strategy in the longer term rather than focusing on, as Inki puts it, ‘pure productivity numbers’ and ‘lines of code.’ Inki was reticent on precisely which platform the firm eventually settled on but is clear that “there were considerable differences between the capabilities” under consideration. More importantly, while some code assistants received a “lukewarm reception from our developers,” recalls Inki, the team enthusiastically embraced others.
Inki believes every company – or at least every software company – should be leveraging code assistants. Hardcore developers might be deep in code all day and operate largely on “muscle memory,” he suggests. However, when people have to split their time between different tasks and meetings and deal with unfamiliar code, assistants can help them overcome the “getting started tax”.
But in the end, he continues, tech leaders need to be realistic. While WithSecure enjoys clear benefits from using code assistance to help automate mundane or boilerplate tasks, these AI applications are still no substitute for the experienced or inspired coder. “One cannot,” he says, “offload innovation to the assistant.”