By Akshay Shrimanker, CPA

At a recent NYCPA C Corporations Committee meeting,  a timely question sparked a lively discussion: does “vibe coding” qualify for the federal R&D tax credit?

The short answer is that vibe coding is not automatically qualifying or nonqualifying. It is a workflow. The R&D credit analysis still comes down to the same fundamentals: defining the business component, identifying technical uncertainty, and substantiating a real process of experimentation.

What is changing is not the statute or the regulations. What is changing is the fact pattern, because AI assisted development can create a single sprint where true experimentation sits right next to routine integration, debugging, and configuration. That mixed nature is exactly where credit claims can get strong with good scoping, or vulnerable when they are overly broad.

What people mean by “vibe coding”

In practice, “vibe coding” generally refers to using large language models and agentic tools (for example, AI assisted IDEs and code generation tools) to accelerate software development. The developer is still building the product, but the path from idea to code to test to iteration is shorter. You might see:

• Rapid prototyping and spike solutions
  • Multiple alternative designs explored quickly
  • Heavier reliance on automated test generation and refactoring suggestions
  • Faster iteration on architecture patterns, libraries, and integrations

From an R&D credit standpoint, that can be helpful or harmful depending on documentation. Faster does not mean nonqualifying. But faster often means less formal documentation unless the team is intentional.

The R&D credit is not about the tool, it is about the uncertainty and the experimentation

Treas. Reg. §1.41-4 makes two points that are especially relevant for AI assisted development.

First, qualified research must be intended to eliminate uncertainty about capability, method, or appropriate design of a business component.

Second, simply using computers or information technology does not, by itself, establish qualified research.

That framing is why “we used AI to code” is not an eligibility argument. The defensible argument is that the team used a process of experimentation to resolve technical uncertainty in developing or improving a business component, and the work fundamentally relied on principles of computer science.

A practical way to express this to founders and engineering leaders is:

• AI can change the speed of experimentation.
  • It does not replace the need to prove there was experimentation.

Why “shrink back” becomes more important with vibe coding

A recurring theme in the committee discussion was the “shrinking back” rule.

The R&D requirements are applied first at the level of the discrete business component (product, process, software, etc.). If the overall component fails the qualified research requirements, the analysis “shrinks back” to the most significant subset of elements and continues shrinking until a qualifying subset is found, or the most basic element fails as well.

In AI assisted software development, shrink back becomes practical, not theoretical.

A release might include:

• A novel technical solution where the team evaluates multiple approaches under uncertainty
  • Routine refactoring for readability
  • Debugging and troubleshooting after the feature is essentially working
  • UI changes and cosmetic improvements
  • Configuration and deployment work

When those are lumped together as “this feature is R&D,” auditors can challenge the scope. The shrink back rule is the roadmap to focus on the subset that truly involved uncertainty and experimentation.

This is also a helpful internal discipline. It forces a team to identify what actually advanced the technical objective, versus what was important work but not credit eligible.

Internal use software vs customer facing software

Another key caution raised in the meeting is the difference between:

• Software developed to be sold, licensed, or otherwise marketed, or software built to enable interaction with third parties
  • Software developed primarily for internal use in general and administrative functions that support the business (for example, finance, HR, internal reporting, back office systems)

Internal use software can still qualify, but the bar is higher. In addition to meeting the core requirements of section 41(d)(1), internal use software generally must satisfy the “high threshold of innovation” test.

That high threshold has three prongs:

1. The software is innovative
2. The development involves significant economic risk
3. The software is not commercially available for the taxpayer’s intended purpose without qualifying modifications

For practitioners advising tech companies, this distinction matters because the same development team may be building both internal tools and customer facing product features. Vibe coding may show up in both places, but internal tools typically require more careful screening and documentation.

Qualified research expenses in an AI heavy development stack

AI tools might show up in qualified research expenses (QREs). The core categories are still what practitioners know:

• Wages for qualified services
  • Supplies (with limits and exclusions)
  • Contract research (generally 65% of qualifying contract research amounts, subject to specific requirements)
  • Certain payments for the right to use time-sharing computers in conducting qualified research

Where AI raises real-world questions is the last category. Does using Open AI or Claude credit considered time sharing of computers in conducting qualified research?

Treas. Reg. §1.41-2(b)(4) provides that amounts paid for the use of personal property generally are not QREs, except for amounts paid to another person for the right to use (time-sharing) computers in the conduct of qualified research, subject to conditions including that the computer is owned and operated by someone other than the taxpayer, located off the taxpayer’s premises, and the taxpayer is not the primary user.

Practically, companies are now spending significant dollars on cloud infrastructure and AI model usage. The committee reflected on what many firms are seeing: practitioners are trying to understand whether certain AI usage fees fit within existing regulatory language written for an earlier computing era.

A conservative and defensible approach is to treat AI tool spend as a separate question from activity qualification:

• First, identify the qualifying activities, scoped correctly (often via shrink back).
  • Second, determine whether any nonwage costs meet a specific QRE category and can be substantiated under the regulation.

Even when costs are potentially includable, wages are usually the dominant driver of the credit. That reality can help prioritize effort: get the activity narrative and wage nexus right first, then evaluate whether any tool or compute costs belong in QREs.

Documentation tips for vibe coding claims

AI assisted development can actually improve substantiation if teams use the same tooling they already rely on:

• Define business components at the feature or module level, not “the whole platform.”
  • Capture the technical uncertainty at the start of the sprint: what was not known about capability, method, or design.
  • Preserve evidence of evaluating alternatives: design docs, architecture decision records, spike summaries, test results, benchmarks, and rejected approaches.
  • Tag tickets or commits that reflect experimentation versus routine work.
  • When a sprint blends qualifying and nonqualifying tasks, be prepared to shrink back and explain the subset that qualifies.
  • For internal tools, document why the project meets the high threshold of innovation, including economic risk and lack of commercially available alternatives.

Akshay Shrimanker, CPA, is the founder and CEO of Shay CPA P.C., an accounting firm based in New York City that specializes in working with technology startups. He helps technology companies with their tax compliance, R&D tax credits, and accounting. He holds a bachelor of business administration degree in accounting from CUNY-Baruch College. He is also involved with the NYCPA and was awarded the NYCPA's Forty Under 40 award in 2020. He has also authored articles for The CPA Journal. Akshay is the immediate past chair of the Society’s C Corporations Committee and is the past president of the Queens/Brooklyn Chapter (2016/17) and previously chaired the Emerging Technology and Entrepreneurship Committee (ETEC) in 2017.