# The changing function of work

Work Economics · 31 October 2026

A business can take on more work only if it can carry that work through to a usable result. When each additional job consumes another block of a person’s execution time, growth inherits the limits of that time. At X-Arc, we study how that relationship changes when agents carry more execution and people concentrate on defining outcomes, resolving exceptions and improving the system.

Our mission is to decouple business growth from human headcount. The practical question starts with a unit of work: what does the next completed result require from a person, from the machine and from the operation around them? If those requirements change, the same people may be able to support a larger business.

This note follows that dependency from human execution toward a system whose capacity can increasingly be allocated through compute. An anonymous engineering sample supplies the measurements. It shows changes in production flow; the broader argument explains what would have to change for that flow to become sustained capacity.

## Keep the result comparable

A unit of work needs an observable finish. For a recurring report, that might mean the correct period, reconciled figures and delivery to the intended recipient. For a software repair, it means the affected behaviour works in the released application. The result includes its quality conditions, permissions and any agreed period of support.

Our earlier note on [the economics of completed work](https://x-arc.ai/notes/economics-of-work/) established this boundary. Here, it lets us reason about change: keep the kind of result and its acceptance conditions comparable, then examine the resources needed to produce it. A harder job or a lower quality bar changes the comparison.

The responsibility we delegate can grow as the system becomes more capable. A person may first request a draft, later delegate a checked report, and eventually delegate the recurring reporting process. The scope of delegation grows while the measured unit remains the accepted report. We include the work required to keep the process running. If the result itself changes, it needs a separate baseline.

## Where the dependency moves

Consider an operation in which a person interprets every request, directs each step, checks the result and repairs the failures. A faster generation tool can shorten a step, while the whole job continues to require that person’s attention at each handoff. Capacity remains closely tied to the time they can supply.

Deep implementation changes the responsibility given to the system. The required outcome, business context, permitted actions and evidence of success travel with the work. Agents can execute, inspect the result and revise it within that boundary. Human input becomes necessary where the definition is incomplete, authority is missing or judgment cannot yet be encoded adequately.

From direction to bounded execution

![A defined outcome enters an execution and checking loop. The system returns a result with evidence. Unresolved decisions return to human judgment, which can refine the definition. Schematic, not a claim of full automation.](https://x-arc.ai/assets/work-functions/dependency.svg)

A conceptual division of responsibility. Dashed arrows show execution or feedback that depends on the result; solid arrows show the defined input and returned output. Human judgment resolves questions the system cannot settle.

There are therefore 2 parts to carry forward: defining the outcome and producing it through delivery and maintenance. Clear scoping reduces avoidable uncertainty in execution. Repeatable checks, or gates, let the system reject and repair known kinds of failure. Their usefulness depends on what they actually detect, including defects that could survive a passing check.

The relationship changes when additional executions stop requiring proportional additional human intervention. Human judgment remains an input, while more routine execution depends on machine capacity. A correction that becomes a reliable check can help subsequent jobs; its development and upkeep still belong in the cost.

## The parameters keep changing

This function is specific to a kind of work, a technology level and a system around it. Its parameters include human attention per accepted result, machine resources per result, the frequency and cost of retries, and the time spent waiting between steps. Improving any one of them can expose a different limit.

A more capable model may complete a larger portion of the job or need fewer attempts. Better context may remove clarification and rework. A reusable component may eliminate repeated implementation. A dependable check may allow routine repairs to proceed without a person. Each change has a distinct effect, and each needs evidence against the same result.

Price and consumption also move separately. A lower price per token reduces the cost of a fixed workload; a system that consumes more tokens may still cost more per accepted result. Memory capacity limits what can run together, and inference speed affects how quickly model-dependent steps finish. These resources can be measured and priced, but they are different quantities.

Capacity within the same attention budget

![Illustrative relationship, not measured data: lower human attention required per additional accepted result allows more results within the same attention budget. Both relationships retain setup attention.](https://x-arc.ai/assets/work-functions/capacity.svg)

Illustrative relationships for comparable work at a fixed quality bar. Lower attention per additional result creates room for more work; the lines are not fitted to the production sample.

We also need to distinguish spreading setup cost across more jobs from reducing the attention required by the next job. Both can improve average cost. The second determines whether another stream of work fits into the same human attention budget. A new engagement adds output only when its scope, exceptions and ongoing support fit without displacing existing work.

## What production records show

Software delivery gives us a measured example of why these definitions matter. The records reveal changes in batching and work moving between stages. They do not yet measure the shift from human effort to machine resources.

We reconstructed activity across an active engineering portfolio in 2 consecutive 10-day windows in October 2026. Original revisions, the saved edits in the histories, rose from 1,386 to 1,424, an increase of 2.7%. Integrated changes, the work proposals merged into the codebase, rose from 310 to 412, or 32.9%. Changes recorded as reaching production for the first time rose from 245 to 315, or 28.6%.

Activity and delivery move differently

![Relative movement between consecutive 10-day windows. Each earlier count is indexed to 100. Original revisions increased 2.7 percent, integrated changes 32.9 percent, first-production changes 28.6 percent, while deployment events fell 36.8 percent. Units differ by row.](https://x-arc.ai/assets/work-functions/throughput.svg)

Measured counts, indexed separately to the earlier window. Open circles mark the baseline; filled circles mark the later window. The rows measure different stages and use different units.

Deployment events moved in the other direction, from 19 to 12. Each event carried an average of 12.9 first-production changes in the earlier window and 26.3 in the later one. This describes a change in batching. Counting deployment events alone would have suggested a decline while the count of included changes rose.

The production total also contains work prepared earlier. Of the later window’s 315 first-production changes, 121 had already been integrated before that window began. That is 38.4% of the observed total. The remaining 194 were integrated during the window, though their implementation may also have started earlier.

Production carries earlier work forward

![Of 315 changes reaching production in the later 10-day window, 121 were integrated before that window and 194 during it. Integration date does not establish when implementation started.](https://x-arc.ai/assets/work-functions/cohort.svg)

Later-window production inclusions, split by integration date. A delivery count includes work prepared before its observation window, so it cannot all be attributed to new activity.

These are concrete measurements of movement through a production process. Changes vary in size and purpose, and first inclusion in production does not establish that a feature was enabled or accepted by its users. The records do not measure a 28.6% increase in business value, nor isolate the contribution of AI. They show why the unit, its stage and its history must stay attached to the number.

## From throughput to capacity

A period with higher recorded throughput is evidence worth investigating. Sustainable capacity also has to account for the work left behind. If incoming work grows faster than verified delivery, the queue expands. A faster execution stage can then produce longer waits for review or release. The limiting resource has moved, and adding more execution may add little to completed output.

Quality must be observed at the finish we promised. Passing a code review, surviving release and satisfying the original request answer different questions. A system that completes more work while producing more escaped defects has changed the result as well as the rate. The production counts above do not establish better final quality.

The decisive next measurement is human intervention per accepted result: scoping, direction, review, exception handling and maintenance, alongside machine usage and elapsed delivery time. Human attention and elapsed time need separate records because work can run or wait while a person does something else. Comparable work also needs comparable time in use for defects to appear.

This makes the growth claim testable. Over successive periods, the same people should be able to support more accepted work within a comparable total attention budget, while the quality conditions hold, queues remain manageable and total cost stays understood. Longer working hours would be another input, not evidence that the dependency had changed. Sustained changes in those relationships would establish what a burst of activity cannot.

## The business consequence

As more execution becomes a property of a repeatable system, a business gains another way to increase capacity: improve that system and allocate additional machine resources. People continue to supply the understanding, authority and judgment the work requires. Their attention can reach further when fewer routine executions need to return to them.

The target evolves with the technology. A stronger model can change which responsibilities can be delegated; a better system can change how much supervision they need. The useful question at each stage is what the next accepted unit now costs in attention, compute and time, and what still limits it. Changing that function lets the same people carry more accepted work. It removes one constraint on business growth; demand, support and other operations must develop alongside it.

## Measurement notes

The snapshot covers 20 complete days in October 2026, split into adjacent 10-day windows. Calendar dates and identifying portfolio details are withheld; window lengths, definitions and aggregate counts are retained in the [measurement data](https://x-arc.ai/notes/functions-of-work/data.json). The calendar mix differed. Task mix, contributor allocation and work-item size were not controlled, so this is an observational comparison.

Original revisions count non-merge commits, including code and documentation, deduplicated within the audited histories. Integrated changes count merged work pull requests, excluding release-promotion wrappers. First-production changes count work pull requests traced to their first inclusion in a successful production deployment; deployment events are successful runs corroborated by production evidence. These are engineering records, with different units, rather than equal-sized features or accepted business outcomes.

The chart sets each earlier-window count to 100 to compare relative movement. It does not combine those units into a score. Average changes per deployment divide first-production inclusions by verified deployment events; the displayed values are rounded to 1 decimal place. The cohort split uses integration time, not the start of implementation. Earlier work may also be present in the first window.

Human effort, complete machine expenditure, feature activation and end-user acceptance were not measured consistently across this sample. Review checks and product-quality observations use different populations and do not supply a common quality-adjusted output series. The conceptual figures describe relationships to test; they are not curves fitted to these observations. Private source records and extraction methods are retained separately.

## Contact

If these questions touch your work, we would love to hear from you.

[Book a discovery call →](https://x-arc.ai/#contact)