As generative AI becomes embedded in software development, a new question is showing up in boardrooms and engineering stand-ups alike:

“If our developers are using AI to write and refine code, does that still count as R&D?”

The short answer is: sometimes — but not automatically.

The longer answer is more interesting, because it reveals something important about how the R&D credit actually works — and why AI doesn’t break the framework as much as people think.

The Starting Point: There Is No Special ‘AI Rule’

Today, there is no specific IRS guidance, regulation, or case law that directly addresses:

• “vibe coding,”

• agentic coding,

• or Gen-AI-assisted software development.

That doesn’t mean AI is excluded.
It means AI must be evaluated using the same four statutory tests that have always governed software R&D under §41.

The framework hasn’t changed.
What’s changing is how work is performed inside that framework.

Why the Four Tests Still Matter

For software development to qualify for the R&D credit, activities must satisfy four requirements:

1. Permitted Purpose

2. Technological in Nature

3. Elimination of Uncertainty

4. Process of Experimentation

AI does not replace these tests. It changes how they show up in practice.

1. Permitted Purpose: AI Changes the Method, Not the Goal

The permitted purpose test asks whether the activity is intended to create or improve a business component’s:

• functionality,

• performance,

• reliability,

• or quality.

Using AI does not change that purpose.

If a team uses an AI tool to:

• design a more scalable architecture,

• optimize query performance,

• or improve system reliability,

the objective remains the same. The AI is a tool — not the purpose.

From a §41 standpoint, intent still matters more than technique.

2. Technological in Nature: Prompting Is Not the Same as Outsourcing Thinking

One common concern is whether prompting an AI in natural language still counts as “technological” activity.

This question misses where the real work happens.

In AI-assisted development, the human developer increasingly operates as:

• a systems designer,

• an architectural decision-maker,

• and a validator of complex technical outcomes.

The developer is not replacing engineering judgment — they are shifting it up the stack.

From a §41 perspective, the activity remains grounded in computer science principles:

• system design,

• performance tradeoffs,

• algorithmic behavior,

• and integration constraints.

The AI generates options.
The human evaluates, selects, tests, and rejects them.

That distinction matters.

3. Elimination of Uncertainty: AI Often Reframes Uncertainty — It Doesn’t Remove It

Another misconception is that AI eliminates uncertainty by “knowing everything.”

In practice, AI often moves uncertainty, rather than resolving it.

Instead of uncertainty about syntax or implementation details, teams face uncertainty around:

• scalability,

• reliability under load,

• emergent behavior across services,

• or how AI-generated components behave in real systems.

For example:

• an AI may propose multiple viable architectures,

• but uncertainty remains about which will perform best in production,

• or fail least catastrophically under edge cases.

That uncertainty is exactly what §41 is designed to incentivize resolving.

4. Process of Experimentation: AI Accelerates — Not Eliminates — Experimentation

If anything, AI increases the importance of experimentation.

Developers can now:

• generate multiple approaches rapidly,

• test alternatives more frequently,

• discard failed designs earlier,

• and iterate faster than before.

But faster experimentation is still experimentation.

The work shifts from writing each alternative manually to:

• designing the tests,

• validating outputs,

• interpreting failures,

• and making informed technical tradeoffs.

The experiment didn’t disappear.
It became more cognitive.

A Helpful Mental Model: A Bug as a Failed Experiment

One useful way to think about AI-assisted development is to reframe how bugs are viewed.

Instead of:

“We’re just fixing bugs,”

consider:

“We’re documenting failed hypotheses.”

A bug often proves that:

• an AI-generated approach was incomplete,

• a system assumption was wrong,

• or an integration behaved unpredictably under real conditions.

That failure creates new technical uncertainty — and triggers a new cycle of experimentation.

This is no different from physical engineering disciplines.

The difference is that in software, the “crash test” happens in staging environments, load tests, and production telemetry rather than laboratories.

What This Means for Documentation

This shift does not reduce documentation needs. It increases them.

Traditional metrics like:

• lines of code,

• or raw commit volume

are becoming less meaningful indicators of research effort.

What matters more is capturing:

• why alternatives were evaluated,

• how decisions were made,

• and what uncertainty was being resolved.

That evidence often already exists — just not framed deliberately.

Examples include:

• architectural decision records explaining discarded approaches,

• Jira tickets documenting failed experiments,

• pull request discussions debating AI-generated logic,

• and commit messages explaining why a change was necessary.

The substance is there.
The framing often isn’t.

The Real Risk: Treating AI Output as Finished Work

Where companies get into trouble is not using AI — it’s treating AI output as final.

When developers:

• blindly accept generated code,

• skip validation,

• or fail to document evaluation and testing,

the activity begins to resemble routine implementation rather than research.

The human must remain the dominant actor.

That’s not a philosophical preference. It’s a §41 requirement.

The Takeaway

Generative AI does not disqualify software development from the R&D credit.

But it also doesn’t automatically qualify it.

The credit has always rewarded:

• uncertainty,

• experimentation,

• and disciplined technical judgment.

AI doesn’t remove those elements — it concentrates them at a higher level.

Companies that:

• treat AI as an accelerator of experimentation,

• retain human ownership of technical decisions,

• and document the evaluation process thoughtfully,

are often strengthening their R&D position — not weakening it.

The framework hasn’t broken.
But the way we apply it needs to evolve.

For additional context and a deeper dive, check out the Bloomberg article - https://news.bloomberglaw.com/tax-management-memo/ai-reshapes-software-r-d-tax-credits-eligibility-landscape-1