The bottleneck no one is measuring
Ask engineers what compliance feels like and the venting starts fast. A Hacker News thread on SOC 2 carried the title, simply, "the screenshots will continue until security improves." The comments under it read like a support group: the energy to build draining away, whole days lost to evidence collection, motivation killed at the personal level while goals and features slip at the company level. This is not a fringe gripe. It is the quiet consensus of the people doing the work.
Engineering dashboards track the wrong bottleneck. They track deploy frequency, lead time, change failure rate, time to recover. All the four key metrics that a generation of engineering leaders learned to optimize. None of them capture the work that is quietly eating the calendar of every senior engineer at a regulated SaaS company.
That work is compliance evidence assembly. The screenshots. The approval reconstructions. The "who signed off on this and where is the proof" hunts. The audit-prep weeks at the end of every observation window. It does not appear on a dashboard because it is not a deploy event. It appears in PTO calendars that move, in senior engineers who quietly start ignoring code review queues for two weeks, in roadmap commitments that slip by a sprint and then another sprint.
Compliance has quietly become the most expensive bottleneck in software engineering. Not because compliance is unimportant. Because the per-release evidence burden has not adapted to AI-paced shipping. The result is a velocity tax that engineering leaders cannot see on a dashboard but feel in every audit, every quarter, and every senior engineer's calendar.
The first job of this piece is to make that tax visible.
The data point that changes the conversation
Per LoopIQ research on public GitHub commits, the share of commits with explicit AI authorship signals grew roughly 10x year over year between spring 2025 and spring 2026. About 1 percent of public commits in April-May 2025 carried a signature-based AI attribution. About 10 percent did one year later. That is signature-based attribution, the kind an auditor can verify from commit history. Self-reported AI usage runs much higher, but auditors do not accept surveys.
Engineering velocity is sprinting. The compliance overhead per release, by contrast, has not changed since the monthly-release era. Approval evidence still gets reconstructed from Slack threads. Test results still get pasted into wikis. Scan outputs still get exported to PDFs the week before the audit kickoff. The per-release work has not adapted, but the release count has multiplied.
This is a multiplication problem, not an addition problem. If evidence assembly takes the same hour per release it took in 2020, and the release count has gone up 5x, the evidence assembly work has gone up 5x. If AI raises that count again over the next year, the evidence work scales with it. The audit-prep weeks at quarter-end are the visible symptom of a per-release tax that has been growing in the background.
Where the time actually goes
Most engineering leaders, asked to estimate the cost of compliance, will name the audit fee and the GRC platform subscription. Those are line items. They are not the cost. The cost is people work, and it shows up in five places.
Senior engineers stopping shipping to assemble screenshots. The work that requires institutional memory falls to the people with the most of it. A staff engineer who shipped a change four months ago is the only person who remembers the context the auditor is asking about. So she stops shipping for a week, two weeks, three, and reconstructs. The opportunity cost is not the hours. It is the roadmap work that did not happen during those weeks.
Audit prep weeks at the end of every quarter or observation window. The pattern is almost universal at regulated SaaS companies. The two to four weeks before the auditor arrives become a different kind of work for half the engineering org. Pull requests slow down. Reviewers vanish. Production changes get deferred. The engineering velocity drop in those weeks is real and it never quite recovers, because the next observation window starts the day this one closes.
The "who approved this and where is the proof" tax on every regulated release. Every change in scope of an audit needs an approval trail. In theory, that lives in the pull request. In practice, the substantive approval happened in a Slack DM, or in a meeting, or in a comment thread on a Notion doc. Stitching that back together at audit time means going person by person, system by system. It is detective work. Detective work is expensive.
The handoff cost when the work is fresh in one engineer's head and the auditor asks four months later. Software changes have a half-life of context. The week of the change, three engineers can reconstruct the decision tree from memory. Four months later, one of those engineers has left the company, another has shipped six more changes, and the third is on parental leave. The cost of recovering context for an auditor is not linear in time. It curves up.
The cost of NOT shipping while audit prep is happening. This is the one that almost never gets counted. Audit prep is not just expensive in hours spent. It is expensive in the work that does not get done during those weeks. The feature your engineering org did not ship in Q1 because half of staff was reconstructing approval chains for Q4 changes. The bug that lingered because the person who could fix it was answering an auditor's email instead. This is the bottleneck. The hours are visible. The unshipped work is the iceberg.
Why modern tooling made this worse, not better
Every tool in the modern engineering stack is locally optimal. GitHub for source control. Slack for fast communication. Jenkins or GitHub Actions for CI. Jira for ticketing. A vulnerability scanner for security findings. Datadog for observability. Each one does its single job well. Each one stores its evidence in its own format, in its own UI, behind its own API.
The seams between tools are where evidence falls through. The PR lives in GitHub. The substantive approval happens in Slack. The deploy gets triggered in Jenkins. The ticket sits in Jira. The vulnerability scan lives in the security scanner. The runtime evidence lives in Datadog. The audit story requires stitching these together: this change, in this PR, was approved by this person on this date, after this scan passed, with this test coverage, and shipped to this environment on this deploy.
The stitching is what is eating senior engineering time. Each tool, on its own, is faster than its predecessor. The work between the tools has gotten harder. A team that adds a new tool to its stack is almost always adding a new seam. Five years of stack expansion at most regulated SaaS companies has produced an evidence layer that no single tool was designed to assemble.
This is the part most platform purchases miss. Buying another best-in-class tool does not reduce the stitching work. It adds to it. The payoff is in reducing the seams, not in upgrading the endpoints.
Recordkeeping as a byproduct of work
The path out of this is not more diligence. It is not better screenshot hygiene. It is not a new wiki template that engineers swear they will keep updated this quarter. None of those scales at AI-shipping speed. The path out is structural: the work and the record have to live on the same surface.
The premise is simple. The evidence already exists. Tickets describe intent. PRs describe change. Approvals describe authorization. Tests describe verification. Scans describe assurance. Deploy logs describe execution. The data is not missing. The connections between the data are missing. A compliance-first SDLC workspace generates the record automatically because the work and the record live on the same surface. The act of shipping is the act of recording.
This is what "compliance recordkeeping as a byproduct" means in practice. You do not stop to assemble evidence. You do not bolt on a parallel documentation workflow. The ticket creates a record. The PR extends it. The approval signs it. The deploy seals it. The audit dossier exists the moment the release ships, not three months later when an auditor asks for it.
This is not a productivity hack. It is a different default. The current default is that engineering work and compliance work are two streams, and the second stream is reconstructed from the first whenever an auditor knocks. The new default is that there is one stream, and the record is an output of doing the work correctly the first time.
Why this matters more in an AI-shipping world
The risk profile of AI-generated code is different. Different defect classes. Different review needs. Different oversight expectations. Auditors are starting to ask for traceability per AI-assisted change: which agent produced the code, what prompt drove the change, who reviewed it, what tests covered it, what policy outcome attached at merge time.
This is not theoretical. The regulatory direction is clear. AI-influenced code paths in financial systems, healthcare systems, and government systems will carry evidence requirements that did not exist in 2024. Every percentage point of AI-assisted code in your codebase adds an evidence requirement to the audit conversation. The evidence backlog grows non-linearly with velocity.
This is the trap. The same AI assistants that are letting your team ship more in a quarter are also expanding the evidence surface area of each thing your team ships. If your evidence stream is manual today, AI-paced shipping makes it more expensive, not less. The tool that bought you velocity is buying you compliance debt at a faster rate than the velocity it is buying you.
The teams that recognize this early are quietly putting evidence capture infrastructure in place before their auditor catches up. The ones that do not are storing up a problem that is harder to fix the longer it goes unfixed.
What the right architecture looks like
For most regulated SaaS teams, the right shape is three layers.
The SDLC platform layer. This is where evidence gets captured at the source, as work happens. Tickets, PRs, approvals, tests, scans, deploy logs, all connected by the change they describe and the release they shipped in. This is the layer LoopIQ sits in. It generates the audit-grade record as a byproduct of the engineering work, not as a parallel project.
The GRC platform layer. This is where posture is monitored continuously, controls are tracked, drift is surfaced, and the auditor relationship is managed. Vanta and Drata are the dominant platforms here. They do this job well. A regulated SaaS team should be running one of them, and the evidence captured at the SDLC layer should flow into it.
The framework layer. This is the set of frameworks the organization carries. ISO 27001 for international customers. HIPAA for healthcare. PCI DSS for payment data. FedRAMP for federal. Each framework imposes its own control families.
Everyone thinks a spreadsheet and screenshots will keep them covered. That used to be enough for some teams, but now that shipping is happening faster than ever, it's the biggest bottleneck in your process. As a developer, I've seen it can easily slow you down by 5, 10, even 20 weeks a year now. That's why I built LoopIQ.
Done right, the audit becomes a download instead of a project.
Our manifesto
Recordkeeping for audits should be a one-click download, not a quarter-long project. Audit prep weeks should be a relic, not a recurring fixture on the engineering calendar. The senior engineer's job should be to ship the next thing, not to reconstruct the last thing for someone four months after she shipped it.
The bottleneck only gets more expensive the longer it goes unfixed. Every AI-assisted release added to the pile is one more change whose evidence has to be reconstructed by hand if it was not captured at the source. The math compounds.
The teams that move first move faster, indefinitely. The ones that wait are not standing still. They are accumulating a tax on every release, paid out in senior engineering hours, every quarter, forever, until they fix it.
See how LoopIQ captures the evidence chain as your team ships: Walk through it.