Software development looks different than it did even a few years ago.
An engineer can describe a feature to an AI coding tool, get hundreds of lines of code back, test it, ask the AI to rewrite part of it, test again, and ship something that might previously have taken days or weeks.
Or, in the more extreme version, someone can “vibe code” an application largely through prompts and rapid iteration without spending much time actually writing code.
So what happens to the R&D tax credit?
The short answer: using AI does not automatically make the development qualify, and it does not automatically disqualify it either.
The harder question is what the team was actually doing.
01The R&D credit was never really about writing code
There is a common misconception that software engineers qualify for the R&D credit because they write software.
That is not the test.
Qualified research generally needs to involve technological uncertainty and a process of experimentation directed at developing or improving a business component. For software, that can mean uncertainty about capability, method, or appropriate design, followed by evaluating alternatives to resolve it.
The IRS specifically describes a process of experimentation as identifying uncertainty, identifying one or more alternatives, and evaluating those alternatives.
AI does not fundamentally change that analysis.
Suppose an engineer is trying to improve a system that cannot handle the company's expected transaction volume.
The engineer uses AI to propose several approaches, tests different database structures, tries alternative caching strategies, benchmarks the results, rejects approaches that fail under load, and continues iterating.
AI may have generated a large percentage of the actual code.
But the important part for the R&D analysis is what happened around that code: there was a technical uncertainty, alternatives were considered, and the team tested those alternatives.
Now compare that with:
“Build me a standard password reset page.”
The AI produces the code. The developer confirms that it works and moves on.
That is still software development. It just may not involve much technical uncertainty or experimentation.
That distinction existed long before AI.
AI simply makes it easier to produce a lot of code without necessarily producing qualified research.
02Vibe coding can involve a lot of experimentation
Here is where it gets more interesting.
Vibe coding can actually be extremely iterative.
Prompt. Test. Fail. Change the approach. Prompt again. Benchmark. Reject it. Try something else.
That can look very much like experimentation.
The problem is that six months later, the company's records may show one completed feature and a Git commit.
The experimentation happened inside an AI conversation that nobody saved.
So the R&D credit issue may not be:
Did the work qualify?
It may be:
Can you still show why it qualified?
03AI can make the documentation problem worse
Traditional software development often creates evidence almost accidentally.
There may be tickets, technical design documents, code-review comments, branches, test results, Slack discussions, pull requests, and multiple commits showing how a feature evolved.
With AI-assisted development, much more of the engineering process can happen inside a conversation with the coding tool.
The engineer may explain the problem, ask for several approaches, test them, report the failures back to the AI, revise the design, and eventually accept a solution.
If that history disappears, the final code may tell you very little about the process that produced it.
A finished repository generally does not tell you what was technically uncertain at the beginning, which alternatives failed, why one approach performed better than another, or how much of an engineer's time related to experimentation rather than routine implementation.
Those facts can matter considerably more for the R&D credit than the number of lines of code produced.
IRS guidance does not require one particular type of R&D record, but taxpayers must maintain records sufficient to substantiate the expenses and activities underlying the credit.
04One release can contain both R&D and ordinary development
Another mistake is treating an entire feature or product release as R&D simply because one difficult technical issue was involved.
Imagine an AI-assisted product release that includes:
- a new architecture developed to solve a scaling problem;
- several standard API integrations;
- routine bug fixes; and
- cosmetic UI changes.
Those activities do not necessarily receive the same tax treatment.
The R&D rules are applied at the business-component level and, where the requirements are not satisfied for the entire component, can “shrink back” to the smaller element where qualified research actually occurred.
For startups moving quickly with AI, this can become particularly important. The qualifying experimentation and routine implementation may happen in the same sprint, by the same engineer, sometimes on the same day.
“We built this product with AI” is not enough information to determine the credit.
05A clean final product can actually hide the R&D
There is another irony here.
Failed approaches are often some of the best evidence that genuine experimentation occurred.
Maybe the first architecture could not handle the required traffic.
The second introduced unacceptable latency.
The third caused memory problems.
The fourth finally worked.
Once the product ships, the repository may contain only version four.
AI can make that evolution even harder to see because alternative approaches can be generated, tested, and discarded very quickly.
For R&D purposes, the cleanest final codebase does not necessarily create the clearest tax record.
06Internal AI tools can have another hurdle
Companies are also using AI to build a lot of software for themselves.
Finance automation. Internal dashboards. Workflow tools. Customer-support systems. HR applications. Operational software.
Software developed primarily for a company's internal use can be subject to additional R&D credit requirements, including the high-threshold-of-innovation test.
That test generally considers whether the software is innovative, whether development involves significant economic risk, and whether suitable software is commercially available without modifications that themselves would satisfy the applicable requirements.
So “we built it ourselves with AI” does not automatically mean the project qualifies.
And with the amount of commercially available software now on the market, the facts around what the company was building and why can matter quite a bit.
07What about the cost of the AI itself?
There is another question we are starting to hear:
If engineers use an AI coding tool for R&D, can the company include the AI subscription in the credit?
Not automatically.
The R&D credit has specific categories of qualified research expenses, including qualifying wages, certain supplies, certain computer rental or lease costs, and contract research expenses.
Software license fees are not qualified “supplies” simply because the software was used during research. And the rules for qualifying computer rental or lease expenses have their own requirements.
So an AI coding subscription should not simply be added to an R&D calculation because developers used it.
The much larger expense for most startups will continue to be the people performing, directly supervising, or directly supporting the qualified research.
Which brings us back to the same question: what were those people actually doing?
08AI may also change the amount of the credit
AI can make qualified development substantially faster.
If an engineer previously spent 100 hours working through a technical problem and AI now helps resolve the same problem in 30, that may be a fantastic business outcome.
But it does not turn 30 hours of qualified work into 100 hours for purposes of the R&D credit.
The opposite can also happen.
AI may allow the same engineering team to attempt more difficult projects, test more alternatives, and perform more qualifying experimentation during the year.
AI therefore does not necessarily make the credit larger or smaller.
It changes how the work happens.
And the credit still follows the qualifying activities and expenses.
09The reporting is changing too
This becomes even more relevant for tax years beginning after 2025.
The revised Form 6765 requires certain taxpayers to report R&D information by business component in Section G, although there are important exceptions, including for certain smaller taxpayers and certain qualified small businesses making the payroll tax credit election.
For companies required to complete it, the form generally requires reporting at least 80% of qualified research expenses by business component, subject to a 50-component maximum.
That makes it increasingly difficult to reach year-end with one engineering payroll number and then try to reconstruct what everyone worked on months earlier.
AI-assisted development can make that reconstruction even harder.
10The takeaway
Your engineers can use AI and still perform qualified R&D.
AI is a tool. It does not determine whether the activity qualifies.
The important questions are still the same: What was technically uncertain? What alternatives did the team evaluate? What experimentation occurred? Who performed the work? And which costs actually relate to that work?
AI can make experimentation dramatically faster.
It can also make the evidence of that experimentation disappear dramatically faster.
If your engineering process has changed because of AI, it is worth asking whether your R&D credit process still reflects how your team actually develops software today.
That answer is going to depend on the type of software being developed, how heavily AI is being used, what the engineers are actually doing, and what records the company has when the year is over.
This article is general information, not tax or legal advice. The rules are fact-specific, change over time, and depend on details unique to your company. Talk to us about how they apply to your situation.