Editor's Note: This is Part 2 of our 3-part series on low-friction R&D documentation. In Part 1: Stop Documenting "for SR&ED", we explored how healthy engineering habits naturally generate audit-ready tax evidence. Today, we break down what the CRA actually needs to see in your records when AI coding agents are writing the bulk of your syntax.
In late September, I spoke at a VTJTalks panel here in Vancouver titled "How AI is Reshaping Startup Funding". While the main focus of that talk was securing startup funding and establishing a Go-To-Market plan in a post-LLM world where POCs and MVPs are developed extremely quickly, when the conversation turned to Government Funding and SR&ED, most of the audience questions boiled down to: If AI coding agents are generating 70% to 90% of our code, what actually counts as human R&D — and how do we prove it to the CRA?
Fortunately, Canadian tax law anticipated this decades ago. Under subsection 248(1) of the Income Tax Act, time spent on "computer programming" or "engineering" has never been eligible for SR&ED by itself. Typing code (or any other activity you might think of as doing the work of development) is only eligible when it is "directly in support of" an experimental effort undertaken "for the purpose of achieving technological advancement".
As mentioned in our June post Your AI Agents and Your SR&ED Claim Should Grow Together, what ENTAX is seeing across Canadian tech companies today isn't a disappearance of engineering effort, but rather a reallocation of effort up the stack. Delegating routine syntax writing to an agent so your team can spend more of their day formulating hypotheses and running deeper experiments should actually improve your SR&ED eligibility ratio.
So while the conceptual eligibility of someone sitting back in their chair and giving orders to an agent isn't the problem (as long as those directives are related to SR&ED), the issue is less about whether the direction was SR&ED, and more about proving that you were in the chair.
The Playbook is Changing
For the last thirty years, the software industry — and the SR&ED consulting industry — has relied on the fact that development teams make heavy use of Source Control and Ticketing systems to track their activities. Even when developers have absolutely no formal tracking of their hours, if a company needed to substantiate what their devs spent time on, it was easy to point at metrics like "lines of code written", "Git commits", "pull requests", or "closed tickets" to prove who did the work. While the CRA would grumble that hourly tracking was the preferred method of tracking time, all but the grumpiest of reviewers would agree that a comprehensive list of tickets and code changes was a reasonable way to demonstrate how developers spent their time.
As of 2026, that justification is dying.
The problem is that widespread adoption of agentic coding tools like Claude Code, Cursor, and any number of other coding harnesses means that there is virtually no relationship between code output and actual human effort. Nowadays, an agent can generate 30 commits, open and review its own pull requests, and mark associated tickets as resolved — all registered under a developer's GitHub account — while that developer is grabbing lunch, or even sleeping.
This means that pointing at a massive commit history no longer proves that a human was sitting at their desk working at all, let alone that they were putting hours into any one specific R&D project.
What to Do: Practical Solutions to the Decoupling Problem
Many development teams try to solve this problem by saving their raw chat logs and prompt histories. While it's true that you can make a sophisticated argument about how the timestamps on your session transcripts prove the times you were working, dumping a 50,000-line chat archive onto a reviewer's desk won't win an audit on its own.
The first step is to pivot from Activity Metrics to Intent Metrics. Using a structured, spec-driven agent workflow (like Matt Pocock's approach), where engineers run interactive "grilling" sessions with the agent, overrule bad recommendations, and log Architectural Decision Records (ADRs), will immediately do a better job of proving where the human intent came into play, and shows the CRA that a human was acting as the Senior Researcher directing the project, not just a passive observer.
But even a great decision log only proves that you did the thinking; it doesn't prove how long it took. Worse, now that agents are tackling the coding, we find that developers are spending more of their day away from the chat window so they can focus on those higher-level issues by whiteboarding, debating architecture with teammates, or diagramming out a workflow. Chat timestamps won't capture that time either.
So what we need is a low-friction way for humans to estimate or report their actual time. For most Agile teams, the simplest solutions fall into two buckets: Top-Down Estimates during Sprint Planning, and Retrospective Reflection.
Top-Down: Roadmapping and "Human" Story Pointing
While agents have changed how long it takes to implement a feature, at the end of the day your team still needs to decide which tickets are going to make it into this sprint, and how to divvy up tasks.
The team already needs a rough idea of the work to be done and each developer's capacity to do it in order to set the roadmap and milestones, which is why Story Pointing exists in the first place. If you make the effort to explicitly scope tickets and story points around the anticipated human time required (how difficult will it be to map the unknowns, design the spec, build verification harnesses, and evaluate the agent's output), your team will not only have a better idea of capacity and burn, but will also get a reasonable estimate of SR&ED time for free.
While CRA policy rejects blindly guessed numbers that are assigned at the end of the year, a contemporaneous sprint planning record is widely regarded as one of the most reliable methods for reasonably tracking time, short of a literal timesheet.
Bottom-Up: Alternatives to a Timecard
…But timecards are a pain, I hear you say. That's true, and as a consultant I find that implementing timecards for their own sake is often counterproductive, as it gives leadership a false sense of security while many employees wind up blowing off the extra chore. Fortunately, you don't need to force your developers to run a stopwatch every time they switch windows. You can piggyback on meetings you are already having. Here are some ideas:
-
Record your standup: Most teams today already use transcription or AI meeting notetakers (like Fireflies, Otter, or built-in Meet/Teams/Zoom tools) during their standups or engineering syncs. If you simply make it a habit during Monday's standup or Friday's wrap-up to have each developer take 60 seconds to state what they spent their time wrestling with since the last meeting, and roughly how their week was split, that meeting transcript automatically becomes a dated, contemporaneous record of human time and technical setbacks. It's 90% as good as a timecard without being anywhere close to the same level of effort.
-
Use Sprint Retrospectives to spot time-sinks: R&D is, by its nature, unpredictable. Things break or results don't come back as expected, and suddenly a three-hour task turns into a four-day rabbit hole. This is what a Sprint Retrospective is for. If your management process makes time to diagnose problems (e.g. "We estimated half a day for the cloud upload permissions, but Alice spent 25 hours rewriting the system to fight overwrite edge cases"), you've immediately got a solid record of the narrative and time justification the CRA looks for when reviewing a claim.
-
Make a tracking sheet: Okay, yes, this one is a timecard, but a timecard doesn't have to be all that complicated. Having developers take two minutes on Friday afternoon just to log the percentage split of their time across projects goes a long way, even if they don't go minute-by-minute through their whole week. A shared spreadsheet or a lightweight, free, open-source time tracker like Kimai takes almost zero effort, requires no complex tooling, and means that you have an actual record to point to when the CRA asks for proof that someone was contributing to a claimed project.
Conclusion
Using coding agents to move faster doesn't jeopardize your SR&ED claim; relying on dead metrics like Git commits to prove your hours does. A workflow that shows human direction (like spec-driven decision logs or sprint retros), or a ritual that captures human time (whether through Sprint Planning estimates, recorded standup updates, or a weekly spreadsheet) — ideally both — will let your agents write as much code as they want without jeopardizing your ability to claim eligible human R&D time.