We’ve arrived at a world where AI is everywhere. Its prominence is felt most acutely in the world software engineering. LLMs such as ChatGPT and Claude weren’t initially designed to write code, but it quickly became apparent that they were very good at it. And now they are specifically tuned for it.
Stories are abound of software engineer layoffs and a slowdown in junior developer recruitment, being attributed (rightly and wrongly) to AI. The impending SaaSpocalypse led to tech stock taking a massive hit as media questioned the value of traditional software companies when AI can build bespoke code for everyone. Vibe coding was Collins Dictionary word of the year for 2025, underling that idea that anyone develop their own apps with today’s AI tools.
This raised an interesting question for those of us who support companies making R&D tax credit claims for software projects. What happens when core development work is being support by – or even fully carried out by – AI?
There are some clear-cut, and some less clear answers to this.
Vibe coding: The DSIT Guideline (which defined R&D for tax purposes in the UK) clearly sets out the concept of the “competent professional” – a project is not an advance in science or technology if it is “readily deducible to a competent professional in the field” – coming up with an advance that is readily deducible is not qualifying R&D. The means that project that are vibe-coded using off-the-shelf tools by a non-technical person – even something innovative – doesn’t qualify – that person wouldn’t be considered to be a competent professional, and clearly if a non-technical person developed could achieve it, it is readily-deducible using existing technology.
AI assistants & agentic coding: It is less clear-cut where a genuine competent professional (e.g. a software engineer or solution architect) is using AI to support their coding. But we can follow the established guidelines. If the work was towards an overall advance in technology (say software engineering), and it wasn’t readily deducible (e.g. you couldn’t use a prompt to come up with the architectural design or code directly), this may qualify – particularly where you can demonstrate prototyping, experimentation, trial and error, failures, etc. This I think is where many claims will sit in the short-to-mid-term. I have seen through my own work using coding agents that whereas it is easy to create something that functionally works, a lot of work is still required to direct these agents to make sensible technology decisions, particularly for secure, manageable, scalable, production-deployable systems. However, as progress with LLMs, coding agents and harnesses continues, the tools will be become more and more capable, and I believe it will be harder to justify each project longer-term.
Developing the agents, harnesses and other tooling: Increasingly, the innovation will be around building the tools to develop, deploy and maintain technology. With agents getting stronger – not just at coding, but at architecting – the innovative work will be around creating the agents and harnesses themselves. But even then, AI will take over more of this. Claude Code itself was allegedly coded by Claude!
The bottom-line is that the software environment is changing fast. There will always be innovation. The approach to assessing what is qualifying R&D may stay conceptually the same. But what innovation can be argued to be qualifying R&D for tax purposes will evolve, and the baseline will continue to climb fast. This isn’t really any different to how it always has been, the pace has – what is advancing today may not be tomorrow. Keeping track of the technology baseline is going to get a whole lot tougher for all of us – including for HMRC.
