The economics of completed work
Work across the lab
At X-Arc, our own operation is one place we test the mission of decoupling business growth from human headcount. It includes engineering for deployed systems, research tools and the infrastructure the lab uses to work. We reconstructed its engineering history across the lab's repositories and the client repositories where our team contributes, counting all contributors within that scope.
The audited histories contain 103 non-merge commits in May, 188 in June, 924 in July and 1,846 in August. September had reached 1,897 by the September 25 snapshot. A commit is a saved revision of code or documentation. Merge commits are excluded so integrating a branch does not itself add another revision to the count. This measures engineering activity, with September shown as a partial month.
The increase was concentrated in working systems. Two deployments accounted for 1,835 of August's 1,846 commits. July had activity in more repositories but fewer revisions. The history shows sustained iteration concentrated in two products; repository count alone would miss it. Staffing, task mix and how changes are divided also affect the series, so it does not isolate an automation effect.
The operation around that work changed too. July added explicit review and staging-verification records. In August, a tested engineering method moved from one deployment into another. In September, the lab introduced a common source map and shared records for task ownership, handoffs and completion evidence, and codified scoping lessons from earlier builds. These changes make the work more inspectable and more of its method reusable.
The economic question runs through that history: can useful results grow faster than the human attention and total resources required to deliver them? The following frameworks describe what we are building around execution to make that possible, and the records that led us there.
Define the unit before counting it
A useful unit starts with a job someone needs completed and ends with an agreed, observable result. Its definition includes the starting information, the permitted actions, the conditions for success and the person who can accept it. A software repair might require the affected user flow to work in the released application. A recurring operational job might require an approved record update in the correct account. These are different families of work and need separate counts.
The full cost belongs to that boundary. It includes preparing the work, executing it, reviewing it, correcting failures and maintaining the result over a stated period. Human effort, model use and infrastructure can all contribute. Waiting affects how soon the result is useful, but elapsed time is not a timesheet. An agent running for an hour does not establish an hour of human effort saved.
This leads to a simple economic test: for a comparable family of jobs, does the total resource cost per accepted result fall while the quality bar holds? More attempts can be useful evidence of capacity. The test is what happens to completed work and everything required to obtain it.
The five frameworks are connected by what they produce. Scope supplies the definition; configuration makes it executable; verification checks the result; operation supplies evidence; reviewed reuse carries a tested improvement into later work. Some practices already operate inside our systems; others are being made explicit and reusable. The map below describes the intended connection, rather than claiming that every step is already joined in every deployment.
1. Scoping from the real operation
The first framework turns knowledge of a business into a checkable definition of work. It begins with an observed job: what triggers it, what the person opens, what they look for, whom they ask, where it waits and what comes out. Real requests and expected results become examples the system must satisfy. Rules, access and authority belong in the same record.
This came from a failure in our own delivery. We began one system with a list of abilities and filled in details ourselves. An August 3 retrospective found that the tool catalog had developed ahead of the business knowledge needed to use it. Later, real use exposed missing filters, unwritten rules and a mismatch between what a returned result meant to the engineer and to the user.
By September 18, those lessons had become a scoping pack: a named accepter, real request-and-response pairs, observed workflows, user-level access, written business rules and a checkable finish. It distinguishes the person sponsoring the system from the person who can accept its work. The pack is a developing framework, not yet a measured reduction in delivery cost.
Its economic mechanism is earlier resolution of uncertainty. A rule found before implementation can prevent the wrong behaviour being built, tested and replaced. The output is a scoping record that both implementation and verification can use.
3. Verification at the point of use
On July 23, one product workflow introduced an explicit staging-verification gate. In August, 147 distinct issues first reached it, and 138 had a linked pull request. In the associated engineering ledger, 483 of 499 work PRs had recorded review verdicts. The change made a requirement, its implementation and its internal check easier to trace together.
It also made revision visible. Only 48.7% of those reviewed August changes passed on the first verdict. That is a reason to include review in the work model: producing a candidate change is one step in completing the job.
One August 18 repair shows the remaining distance. The recorded agent-worker interval for investigation, reproduction, repair, tests and PR preparation was about 54 minutes. Clarification of the symptom to a verified distribution state took 10 hours and 35 minutes. During that interval, the operator corrected a claim that the build was already available. Other work ran concurrently; these are elapsed intervals, not human hours.
The third framework carries the original definition of success through implementation and release. Its evidence record joins the requirement, revision, checks and actual released state. Internal staging verification, distribution and the affected user's acceptance are separate observations. The finish must be the one agreed at scoping.
4. Operation as part of the result
The operating records show systems doing work after release. Between June 27 and September 25, one deployment recorded 21,579 batches of advertising changes marked successful across two execution logs, for 202 members. These included bid and budget changes, exclusions and campaign creation. Each batch counts as one operation; it is not a count of complete business jobs or a claim about profit.
A second deployment recorded 68 successful write actions in 51 conversation turns involving eight users between September 16 and 25. These included changes to business records, calendar events and work artifacts. The two applications record different action families, so their counts remain separate.
The fourth framework observes what the system did, the state it left and the resources needed to keep it working. Those records distinguish a feature that exists in code from a capability being used. They also supply failures and real requests that can challenge the checks written before release.
Building and maintaining the system consumes engineering resources. Running it consumes resources on behalf of its users. Both belong in a full economic comparison over a defined useful life. Product inference is a running cost; it is not the cost of the coding agents that built the product.
5. Reviewed reuse
An August 20 change in the second deployment explicitly referenced the first deployment's approach to separating fixed operating rules from configurable skills. It carried forward the contract-test pattern and provisioned skills through versioned assets, while adapting the implementation to the new system. This is a specific instance of method reuse across projects, not a claim that both products share an identical stack.
Inside the lab, the same question appeared when we moved an agent into a second vendor's harness. The latest Field Note records that the shared memory stayed in one place and both agents read it. It also records what did not transfer: enforcement tied to the original harness. A reusable component and a reusable guarantee are different things; the latter needs checking in its new setting.
The fifth framework makes that adoption deliberate. A failure supplies evidence; a proposed correction is reviewed, tested and versioned; another operation selects it and checks it against its own conditions. The retained asset can be a procedure, an evaluation, a configuration pattern or a component. Client information remains specific to its client.
That is where the economics can accumulate across deployments. The next job starts with some engineering and some failure knowledge already available. The contribution is the repeated work removed after adaptation, review and upkeep are counted.
What this changes
The operating change is visible in the records: more engineering activity was recorded across projects; review and internal verification are recorded; a tested method from one deployment is adapted in another; deployed systems carry out actions for their users. These are different observations, and together they describe more than a large engineering counter.
They also expose the next constraint. In the product workflow with a recorded start of building, median time to staging verification rose from 18.0 hours in August to 21.2 hours in September's partial period, despite higher daily throughput. The start event exists for only about 63% of verified issues, and staffing and task mix changed. Increasing execution capacity did not automatically shorten the whole path to a usable result.
Our mission is to decouple business growth from human headcount. Inside the lab, that means building a foundation that can carry more of the repeatable work: translating a real job into configuration, checking its result, observing it in operation and retaining improvements for the next deployment. Engineers still supply operational understanding, judgment and extensions. The aim is for each new operation to start with more of its engineering already established.
The frameworks in this note are the shape of that foundation, grounded in the work that produced them. We can already point to transferred methods, recorded checks and systems taking real actions. A comparable historical reduction in the full cost of accepted outcomes remains to be established: human attention, rework and maintenance must be counted alongside model and infrastructure cost. Applying the approach inside our own operation gives us a concrete place to keep testing it.
Measurement notes
The Git audit enumerated 46 repository candidates. The chart covers 32 lab-owned or corroborated client engineering repositories; 20 contain qualifying commits in the observation window. It includes relevant historical work in repositories now archived. Four internal operations repositories were examined separately; their histories are dominated by scheduled knowledge backups and do not enter the engineering series. Local work without a commit is outside the chart. Repositories are not projects, and Git identities are not a headcount measure.
Counts are unique non-merge commit objects reachable from each repository's current default branch, grouped by committer date from May 1 through the September 25 snapshot. Exact copies across repositories count once; this removed 70 duplicate rows in July. Equivalent changes copied under different commit identifiers can remain. Current ancestry is a view of retained history, not a historical deployment log; commit date is not release date. All contributors in the selected repositories are counted, including collaborators. The monthly data records the exact cutoff. May–August are complete calendar months; September is partial and is not extrapolated.
The issue-history audit was captured on September 25 at 08:09 UTC. Its explicit staging gate began on July 23, so earlier months do not provide a comparable baseline. Each issue counts once at its first recorded verification. Review verdicts and issue transitions are separate ledgers. The elapsed building-to-verification comparison covers only issues with both events; September's newer issues have had less time to reveal defects.
The advertising-operation snapshot was captured on September 25 at 07:07 UTC. It sums successful, non-test batches from two execution logs, deduplicating correlation identifiers within each source and excluding replayed chat writes and internal users. It does not independently deduplicate between the two logs. The second application's write count was captured at 07:29 UTC. Application-reported success is distinct from acceptance of a whole job, and the two action families are not pooled.
The repair interval is a dated reconstruction from execution and distribution records. The configuration and reuse examples come from repository changes and their recorded checks; the September scoping pack is a developing framework. Private source snapshots, extraction code and review records are retained for the analysis. Client identities, personal identities and work-item identifiers are omitted here.
Contact
If these questions are relevant to work you are running, get in touch. We reply within two business days.
Book a discovery call →