Inside a fintech's 4× bug-fix velocity with Claude Code.

The baseline measurement methodology that made the 4× claim defensible

Hatchpay's head of engineering productivity, Devika Chandrasekaran, established the baseline measurement protocol in early September 2025, six weeks before the Claude Code rollout began. The protocol was designed to produce a defensible reference number that would survive the inevitable post-rollout questioning about whether the productivity improvement was real or methodological. Chandrasekaran's team stratified the company's bug-fix backlog by severity (P0 through P3), by codebase area (payments-rails, merchant-onboarding, reporting, integrations), and by estimated complexity (engineer time estimate at triage). The team then sampled 240 bug-fix tickets from the previous eight weeks of completed work, distributed proportionally across the strata, and measured five variables for each: time from ticket assignment to first commit, time from first commit to merged PR, time from merged PR to deployed-to-production, total engineer hours logged against the ticket, and the rate at which the fix produced a follow-up bug within 30 days of deployment.

The baseline numbers the protocol produced were the reference set against which the post-rollout numbers would be compared. The median time from ticket assignment to merged PR was 2.8 calendar days. The median engineer hours per bug-fix ticket was 6.4. The follow-up bug rate within 30 days was 11.2 per cent. The distribution had a meaningful long tail — the 90th percentile time to merged PR was 11 days and the 90th percentile engineer hours was 28 — which the team noted as a structural feature of the bug-fix workload. The tail was concentrated in the payments-rails codebase area, where the integration complexity and the regulatory sensitivity produced longer investigation cycles than the median work required. Chandrasekaran's team flagged the long-tail concentration as an important variable to track separately in the post-rollout analysis, on the hypothesis that the tail might be the segment where the agent integration produced the largest absolute time savings.

The protocol also captured a set of qualitative variables that the quantitative measurements would not surface. Each ticket in the baseline sample was reviewed by a senior engineer who categorised the cause of the bug (logic error, integration failure, data quality issue, race condition, etc.), the type of fix (defensive coding, root-cause repair, configuration change, dependency update, etc.), and the engineering judgement required to produce the fix (routine, moderate, complex). The qualitative categorisations were the variables Chandrasekaran's team used to test whether the post-rollout improvement was uniform across categories or concentrated in specific categories. The hypothesis going in was that the agent integration would produce uniform improvement across routine and moderate categories but smaller improvement on complex categories that required substantive engineering judgement. The hypothesis turned out to be partially right — the complex category did show smaller improvement than the routine and moderate categories — but the absolute improvement on the complex category was still meaningful and larger than the team had expected.

The baseline measurement was not the only methodological investment the team made. Chandrasekaran's team also instrumented the company's Linear workflow to capture additional structured data during the rollout period: which engineer touched each ticket, in what sequence, what tools they used, what code paths they investigated, what commits they produced. The instrumentation was designed to support both the productivity measurement and the post-rollout analysis of which workflow patterns were producing the strongest improvements. The instrumentation produced a dataset of approximately 4,300 ticket-instrumented bug-fix events across the rollout window, which is the dataset that supports the more detailed claims about which integration patterns produced which share of the improvement. The dataset is internal to Hatchpay but the high-level findings have been shared at engineering leadership forums and have informed the writeup in this field study.

The rollout phasing that staged the integration deliberately

The Claude Code rollout was phased across three waves over the seven-month window, deliberately structured to allow the engineering organisation to absorb each layer of integration before adding the next. The first wave, beginning in mid-September 2025, was Claude Code as a developer tool: each engineer received a Claude Code seat license and was instructed to use it for bug-fix work at their discretion. The wave included an onboarding session, an internal documentation set, and a paired-programming engagement with the platform engineering team for engineers who wanted hands-on guidance. The first wave's deliberate scope was to establish baseline familiarity with the tool before any workflow integration. No Linear integration. No hooks-based policy. No structured workflow. The intent was to surface the tool's value in its unmodified form and to identify the failure modes the subsequent integration would need to address.

The first wave's results were instructive. After six weeks, approximately 62 per cent of engineers reported regular use of Claude Code on bug-fix work, but the productivity improvement against the baseline was modest — approximately 1.5×, well below the 4× the eventual rollout would produce. The qualitative feedback surfaced consistent themes. Engineers reported that Claude Code was useful for investigation but that the integration friction with Linear (the team's ticket tracker), with the company's GitHub repositories, and with the company's deployment pipeline meant that meaningful portions of the bug-fix workflow remained manual. The engineers also reported variation in their personal effectiveness with the tool — some engineers had figured out productive workflow patterns through trial and error, while others were using the tool in ways that produced less benefit. The variation suggested that workflow standardisation could compound the productivity improvement, which the second wave was designed to test.

The second wave, beginning in mid-November 2025, was Claude Code integrated with Linear and GitHub through the platform engineering team's custom integration layer. The integration allowed an engineer to open a Linear ticket, trigger a Claude Code investigation session that pulled the ticket context, the relevant codebase, the deployment history, and the recent incident traces, and then collaboratively work through the bug with the agent. The integration produced a substantial improvement over the first wave's results — productivity improvement against baseline reached approximately 2.8× by the end of January 2026. The integration also produced a more uniform improvement across engineers; the variation between high-effectiveness and low-effectiveness engineers narrowed substantially as the standardised workflow replaced the trial-and-error approach. The second wave's findings validated the hypothesis that workflow integration was a meaningful share of the productivity opportunity, and they set up the third wave's expansion into policy enforcement.

The third wave, beginning in early February 2026, added the hooks-based policy enforcement layer that completed the integration. The hooks operated at the pre-tool-call boundary of each Claude Code session and enforced the company's engineering policies: which codebase areas required peer review before an automated commit, which deployment targets required additional security review, which data categories required compliance team sign-off before being accessed in an investigation session, and which fix patterns required architectural review before being approved. The hooks produced a substantive shift in the workflow's character — engineers no longer needed to remember which policies applied to which work, because the hooks would enforce the policies automatically and provide guidance when a policy required additional steps. The third wave's productivity improvement reached the 4.1× headline number by April 2026, with the additional improvement over the second wave's 2.8× attributable substantially to the reduction in policy-compliance overhead that the hooks produced. The combined three-wave rollout is the structural pattern that the field study captures, and the phasing — deliberately allowing each layer to mature before adding the next — was the design decision that produced the cumulative improvement.

The hooks-based policy enforcement that completed the workflow

The hooks-based policy enforcement that the third wave added is the technical layer that warrants detailed examination because it is the layer that most clearly demonstrates how an agent integration moves from useful to load-bearing. The hooks are encoded as a configuration file at .hatchpay/policy.yaml in each service repository, with the policy structure defined by the platform engineering team and the per-service customisation maintained by the service's responsible engineering team. The hook engine itself is a thin shim that the platform team built around Claude Code's native hooks API: the shim reads the policy file, evaluates the proposed action against the policy constraints, and either allows the action, requires additional steps, or blocks the action with a structured rejection. The hooks operate at three boundary points in each Claude Code session: pre-investigation (before the agent accesses any code), pre-modification (before the agent commits any changes), and pre-deployment (before any changes flow into production).

The pre-investigation hooks enforce data access policies. The payments-rails codebase contains data structures and code paths that the company's compliance posture restricts to specific engineer roles, and the hooks check whether the engineer initiating the Claude Code session has the appropriate role before allowing the agent to access those code paths. The check is layered on the company's existing role-based access control — the hooks do not replace the access control, they enforce the additional policy that engineers accessing sensitive code through an agent must have an explicit role-grant that is separate from the broader code-access grant. The layered control is a compliance posture the company adopted after a 2024 audit that flagged the difference between human-initiated access and agent-initiated access as a category that required separate governance. The hooks are the operational implementation of the audit response, and they have held without incident through the four months since the third wave began.

The pre-modification hooks enforce review policies. Certain code areas — the payments-rails service, the cryptographic key management layer, the regulatory reporting subsystem — require human peer review on any commit, agent-produced or otherwise. The hooks check whether the proposed modification falls into one of these areas, and if it does, they require the engineer to acknowledge that the modification will be subject to peer review before the agent commits. The acknowledgement is more than a procedural step; it triggers the platform engineering team's automated review-assignment logic, which selects an appropriate reviewer based on code ownership, current workload, and the modification's complexity. The integration of the hook with the review-assignment logic is the part of the workflow that the engineers cite most consistently as the productivity multiplier. Before the integration, the engineer needed to manually identify and request a reviewer; after the integration, the reviewer assignment happens automatically and the engineer is notified when the reviewer has been assigned.

The pre-deployment hooks enforce the company's release policies. Hatchpay's deployment pipeline runs through a phased rollout from canary to full production over a defined timeline, with validation checkpoints at each phase. The pre-deployment hooks check whether the proposed deployment satisfies the policy for the codebase area being changed — some areas allow standard rollout, some require extended canary windows, some require deployment outside of business hours, some require additional security approval. The hooks enforce these policies at the moment the engineer initiates the deployment, providing immediate feedback rather than allowing the engineer to attempt a deployment that the pipeline would reject downstream. The compression of the feedback loop is itself a meaningful productivity contribution — engineers do not lose context switching between failed deployment attempts and re-investigating why the attempt failed. The pre-deployment hooks have produced approximately 230 policy-redirect events in the four months since they were deployed, each one redirecting an engineer from a non-compliant deployment attempt to the compliant path before the deployment infrastructure would have rejected it. The estimated time-saving from these redirects, based on the median time-cost of a failed deployment and subsequent re-investigation, is approximately 380 engineer-hours over the four months.

The Linear integration and the issue routing automation

The Linear integration is the workflow surface that anchors the bug-fix workflow, and the integration's specific design has been a structural contributor to the productivity improvement that the headline number obscures. Hatchpay uses Linear as its primary ticket tracker, with approximately 1,400 active tickets at any given time across the engineering organisation's various queues. The integration the platform engineering team built has three components. The first component is the Linear-to-Claude-Code session bootstrap: when an engineer assigns themselves a Linear ticket and clicks a custom "Investigate with Claude Code" action, the integration creates a Claude Code session pre-loaded with the ticket context, the linked GitHub commits, the relevant deployment history, the recent error traces from Datadog, and the conversation history from the ticket. The bootstrap eliminates the manual context-gathering work that engineers previously spent the first 15-30 minutes of a bug-fix session doing.

The second component is the automated issue triage that the integration produces. When a new bug ticket is created in Linear — either by a customer support escalation, an internal report, or a production alert — the integration triggers a Claude Code triage session that reads the ticket, examines the relevant code paths, identifies the likely root cause area, estimates the severity and complexity, and proposes an assignment to the engineer with the most appropriate combination of code ownership, current workload, and expertise match. The triage suggestions are recommendations, not assignments — the engineering manager retains the final assignment decision — but the recommendations are accepted approximately 78 per cent of the time. The 22 per cent of cases where the manager overrides the recommendation are tracked and the override reasons are analysed quarterly to improve the triage model's accuracy. The triage automation has reduced the median time-to-assignment from approximately 6 hours to approximately 40 minutes, which is a productivity contribution that does not show up directly in the bug-fix-velocity metric but which compounds throughout the workflow.

The third component is the automated resolution capture. When an engineer closes a Linear ticket as resolved, the integration triggers a Claude Code summarisation session that reads the ticket, the linked code changes, the investigation notes, and the deployment outcome, and produces a structured resolution summary that the integration writes back to the Linear ticket. The summary captures the root cause, the fix approach, the deployment timeline, and any follow-up work that may be needed. The summary serves multiple downstream purposes: it provides the customer support team with the explanation they need to follow up with affected customers; it provides the engineering management team with the data they need to identify systemic patterns in the bug distribution; and it provides future engineers investigating similar issues with the historical context that accelerates their investigation. The resolution capture is the component that the engineering management team has cited most frequently as the workflow change that has shifted the engineering organisation's relationship with its own bug-fix history.

The Linear integration's structural significance is that it transforms Linear from a passive ticket tracker into an active workflow surface that orchestrates the agent's involvement at each stage of the bug-fix lifecycle. The transformation is what allows the engineer to spend their attention on the substantive engineering work — investigation, design, implementation, verification — rather than on the workflow overhead that surrounds that work. The headline productivity improvement of 4.1× would not have been achievable without the workflow transformation; the agent's contribution to the substantive work is meaningful but smaller than the workflow transformation's contribution. The implication for engineering leaders considering similar deployments is that the integration with the existing workflow surface is the leverage point, not the agent's raw capability. The agent is the engine. The integration is the transmission.

The February 2026 incident that validated the speedup under load

The production incident in February 2026 that operationally validated the workflow's performance under load is the single most consequential data point in the field study, because it tested whether the productivity improvement that the controlled measurements had captured would hold up under the disruption and pressure of a real incident. The incident began on Wednesday 18 February 2026 at 14:23 Eastern time when a downstream banking partner produced a malformed response to a payment authorisation request in a category the Hatchpay system had not encountered in production before. The malformed response triggered an exception in the payments-rails service that cascaded into a 7 per cent error rate across the full payment authorisation flow within approximately four minutes. The incident response protocol activated immediately: the on-call SRE — a senior engineer named Tomás Lévesque — was paged, the engineering leadership team was notified, and the customer-facing status page was updated to reflect degraded service.

The incident response involved approximately 22 engineers across the bug investigation, the customer communication, the banking-partner liaison, and the post-incident review work. The Claude Code workflow was used extensively throughout the response — not as the primary diagnostic tool, but as the substrate that allowed the engineers to coordinate their work efficiently while each individual engineer pursued their specific investigation thread. The integration with Linear allowed the incident commander, Devika Chandrasekaran (acting in her secondary role as senior engineering leader), to create incident tickets that each carried the full context of the incident's evolving state, and the engineers working on specific aspects of the response could pick up their assigned threads with the context already pre-loaded. The fundamental fix — a defensive parser change in the payments-rails service that gracefully handles the malformed response category — was identified, implemented, peer-reviewed, deployed through the canary phase, and rolled out to full production within 47 minutes of the initial page.

The 47-minute mean-time-to-recovery was the metric that operationally validated the workflow's performance, because it represented a substantial improvement over the company's previous mean-time-to-recovery for similar-severity incidents. The previous-year equivalent — a similar payment authorisation incident in February 2025 — had taken 3 hours and 18 minutes to recover. The improvement was not attributable to any single workflow change. The faster fix identification was helped by Claude Code's investigation assistance against the codebase. The faster fix implementation was helped by the standardised workflow patterns the rollout had established. The faster peer review was helped by the automatic reviewer-assignment logic that the hooks triggered. The faster deployment was helped by the policy hooks that prevented the engineer from attempting a non-compliant deployment and losing time to a rejected attempt. Each of these contributions was small in isolation. The combination compressed the recovery time by approximately 4×, mirroring the headline productivity improvement that the controlled measurements had captured.

The post-incident review that Chandrasekaran ran the following Monday produced an additional finding that the field study should record. The review identified that the workflow's behaviour under incident pressure had not degraded relative to its behaviour under controlled conditions, which is the property the team had been most concerned about going into the third wave. Several of the engineering organisation's senior leaders had expressed concern in advance that the workflow's productivity improvement might be a controlled-conditions artifact that would fail to materialise under the pressure of a real incident. The February incident's outcome was the operational evidence that the concern was unwarranted. The workflow held. The engineers used the tools effectively under pressure. The integration produced its expected value. The incident was, in Chandrasekaran's framing during the post-incident review, the data point the team had been waiting for. The rollout could now be considered complete in the sense that its operational durability had been tested at a non-trivial scale and had held.

What to watch

Hatchpay's rollout has been in operational use for four months at the headline 4.1× productivity level and seven months overall. The field study captures a specific moment in the rollout's maturation, and the next twelve months will be the period in which the durability of the productivity gain is tested under conditions the present measurement window did not capture.

• Whether the productivity gain holds as the engineering organisation grows; Hatchpay plans to expand to approximately 130 engineers over the next 12 months, and the workflow's productivity contribution at the larger scale will be measured in the same methodology that produced the present baseline.
• Whether the workflow extends from bug-fix to feature development; the company has begun a pilot of the same integration pattern applied to feature work, and the early signals suggest the productivity contribution is smaller than the bug-fix improvement but still meaningful — preliminary data from a 6-week pilot shows approximately 1.8× feature-development velocity improvement.
• Whether the policy hooks' compliance posture remains adequate as the company's regulatory exposure expands; Hatchpay is planning a European banking partnership that will introduce new compliance requirements, and the hooks framework will need to extend to handle the additional governance constraints.
• Whether the workflow pattern transfers to other Series B and Series C fintechs; Chandrasekaran has presented the architecture at three engineering conferences in 2026 and the engineering leadership teams at five competing fintechs have circulated preliminary plans for similar rollouts. The transferability will be measured by the outcomes those rollouts produce.
• Whether the Anthropic API pricing trajectory and product evolution remain compatible with the workflow's economic model; the monthly API spend has been running at approximately $38,000 against an avoided-cost saving estimated at approximately $84,000, but the economic case depends on continued favourable pricing and continued capability evolution that supports the integration pattern.

Frequently asked

How did Hatchpay validate that the 4× number reflected real productivity gain rather than measurement artifact?

The validation operated at three levels. The first was the baseline measurement protocol that stratified bug-fix work by severity, codebase area, and complexity, producing a reference dataset of 240 tickets with five quantitative and three qualitative variables per ticket. The second was the controlled comparison during the rollout window — engineers who had not yet onboarded to each successive wave served as the control group for the engineers who had. The third was the February 2026 incident that operationally validated the workflow's performance under real incident pressure; the mean-time-to-recovery improvement (47 minutes versus 3 hours 18 minutes for the comparable previous-year incident) closely matched the controlled-measurement productivity improvement. The triangulation of all three validation levels is what the team relies on to defend the headline number.

What was the relative contribution of each rollout wave to the headline productivity gain?

The first wave (Claude Code as a developer tool, no integration) produced approximately 1.5× improvement against baseline. The second wave (Linear and GitHub integration) extended the improvement to approximately 2.8×. The third wave (hooks-based policy enforcement, automated routing) extended the improvement to the headline 4.1×. The structural finding is that the agent alone produced a meaningful but modest improvement; the integration with the workflow infrastructure produced the substantial additional improvement; and the policy enforcement layer produced the final compounding effect that completed the workflow. Each layer's contribution compounded with the previous layers rather than substituting for them.

Why did Hatchpay choose Claude Code over alternative agent platforms?

The choice was driven by the integration surface — specifically the hooks API that allowed the platform engineering team to enforce policies at the pre-tool-call boundary without modifying the agent's core behaviour. Alternative platforms at the time of the rollout decision required more invasive integration work to achieve the equivalent policy enforcement. Chandrasekaran's team also weighted Anthropic's commercial posture toward the agent-platform team buyer (the team Hatchpay had not yet formed but anticipated forming) and the model quality on the categories of work the workflow targeted. The decision predated the formal benchmarking studies that subsequently confirmed Claude Code's strength on refactor and migration work, but the early signals had already pointed toward Claude Code as the right choice for the integration-heavy workflow the team was designing.

What is the hooks-based policy enforcement, and how does it differ from traditional code review processes?

The hooks operate at the pre-tool-call boundary of each Claude Code session and enforce the company's engineering policies automatically — data access policies, peer review policies, deployment policies. The hooks differ from traditional code review processes in that they shift policy enforcement upstream of the work rather than downstream. Traditional code review catches policy violations after the engineer has invested time in the work; the hooks redirect the engineer to the policy-compliant path before the investment. The shift produces a substantial reduction in policy-compliance overhead — the estimated time-saving from policy redirects alone is approximately 380 engineer-hours over the four months since the third wave deployed. The hooks do not replace code review; they reduce the volume of policy-related issues that code review needs to catch, freeing reviewer attention for substantive engineering quality.

How did the integration with Linear specifically contribute to the productivity gain?

The Linear integration has three components: session bootstrap (pre-loads Claude Code with ticket context, code paths, deployment history, error traces), automated triage (Claude Code reads new tickets and recommends assignment), and resolution capture (Claude Code writes structured resolution summaries back to the ticket). The bootstrap eliminates the 15-30 minute context-gathering at the start of each bug-fix session. The triage reduces median time-to-assignment from approximately 6 hours to approximately 40 minutes. The resolution capture provides downstream functions — customer support, engineering management, future investigations — with structured artifacts that compound over time. The integration transforms Linear from a passive ticket tracker into an active workflow surface that orchestrates the agent's involvement at each stage of the bug-fix lifecycle. The transformation is what allows the engineer to spend attention on substantive engineering rather than workflow overhead.

What is the economic case for the rollout, and how sensitive is it to the Anthropic API pricing?

The monthly Anthropic API spend has been running at approximately $38,000 against an avoided-cost saving estimated at approximately $84,000 — net monthly benefit of approximately $46,000. The avoided-cost saving is the engineering hours the team would have spent on bug-fix work absent the productivity improvement, valued at the company's loaded engineer cost. The economic case is sensitive to the API pricing trajectory; a substantial pricing increase from Anthropic would compress the net benefit and could force a recalibration. The team has built the workflow to be reasonably model-agnostic at the integration layer so that a model substitution would be feasible if pricing required it, though the substitution would carry non-trivial transition cost. The economic case is robust to plausible pricing variation but not to extreme pricing scenarios.