谁来承担 AI 软件工厂的成本？

A lower agent bill can mean several things. The team may have found a better model for the job, fixed a workflow that kept retrying, or stopped running checks that took too long. Looking at the invoice alone, those changes can look equally good.

For engineering leaders, the difficulty is knowing what the money bought. We want to reduce the cost of delivery, but we also have a backlog of maintenance that has never made it high enough on the priority list. Some of that work might now be affordable. Managing the factory means deciding where to spend more as well as where to cut back, with enough information to make those decisions before the monthly bill arrives.

There are seven areas I would build into the way the factory runs:

1. Visibility and ownership: Give teams cost data and the authority to act on it.
2. Intake: Assess the likely benefit before starting work.
3. Routing: Choose models based on the full cost of completing a task.
4. Determinism: Replace recurring model decisions with checks where possible.
5. Boundaries: Set budgets and stop unproductive loops.
6. Value: Account for maintenance that would otherwise remain undone.
7. Accountability: Keep the definition of done intact when budgets get tight.

1. Give teams cost data and control

Every model call, tool action, and workflow should report its cost against the task that caused it. Keep estimates distinguishable from actual charges, and include infrastructure, retries, review, and rework where they can be measured. Failed attempts belong in the calculation too. If ten comparable tasks consume a budget and only six succeed, reporting just the cost of the successful six makes the process look cheaper than it was.

FinOps gives us a useful way to organize this. Engineering teams manage their workflow budgets and decide how to improve their usage. Platform and FinOps teams provide the metering, allocation, dashboards, and budget enforcement. Leadership, product, and finance agree how much to invest and what results are expected. Teams need room to change a route or stop a wasteful workflow themselves, with a clear process for requesting more budget when the work warrants it.

Put the cost information where the team already works: alongside a workflow result, in a pull request summary, or in the team's review of delivery. Show the spend, remaining budget, and completion status. If dependency updates repeatedly hit the same broken build environment, the team can fix that environment instead of paying for another round of investigation on every update. A dashboard is useful when someone can act on what it shows.

2. Assess the work before starting it

At intake, establish what the work is worth and what happens if it stays undone. An urgent production fix and an exploratory feature will have different spending allowances. Record the expected benefit, the estimated cost, and the authorized budget separately. The estimate may change as the agent learns more; that should not automatically increase its permission to spend.

We already struggle to estimate unfamiliar engineering work. Delegating the estimate to an agent does not remove the uncertainty. A small fix can uncover a missing test environment or a dependency migration. Use comparable completed tasks as a starting point, explain where the comparison breaks down, and use a range when an exact figure would be guesswork.

For uncertain work, budget for investigation first. An agent can examine the failure, identify likely changes, and return with a revised estimate before implementation begins. If the task has turned into a migration, the team should make that decision explicitly. Otherwise, a modest investigation budget can become an open-ended commitment that nobody intended to make.

3. Choose models by the cost of completing the task

A routine classification and a difficult investigation do not need the same model by default. Try the least expensive approach that meets the requirements, but account for what happens when it fails. A cheaper call followed by repeated corrections and an escalation can cost more than using a more capable model from the start. Compare routes using completed work and the review effort it required.

Look at what the model is being asked to read as well. Entire build logs, large tool responses, and unused tool definitions all add to the input. Load tools when they are needed and filter results before sending them back. For a failed build, the relevant errors and enough surrounding context may be more useful than another copy of the entire log.

Caching can help with stable context, provided the workflow actually reuses it. Check whether changes to prompts or tool definitions are breaking that reuse. Test these changes on representative tasks before rolling them out, and look at quality and correction effort alongside the bill. A saving that creates more work for the reviewer may still be a poor trade.

4. Turn recurring decisions into checks

Some recurring model calls should eventually disappear. Checking for a required field, enforcing a defined dependency policy, or validating a generated file can often be handled by code. An agent can help work out the rule and write the check. Once the team has validated it, there is little reason to ask a model to make the same decision on every run.

For example, an agent handling dependency updates might uncover a compatibility requirement that keeps causing failures. The team can turn it into a check for future updates, leaving the agent to investigate exceptions. That check needs tests and an owner, just like any other part of the build system. A script generated during one successful run is not yet a maintained component.

There is a cost to making that conversion, so start with frequent calls and rules that are unlikely to change. Use workflow records to find repeated investigations and validations. Over time, the factory should carry forward what the team has learned rather than pay to rediscover it each time.

5. Set budgets and stop unproductive loops

An agent can keep rerunning a test or rewriting a patch without getting any closer to a solution. Set limits on retries, elapsed time, and spend in the execution system. Be precise about what happens at each limit. Blocking one tool may leave the agent free to use another, and limiting the number of calls says little about how expensive those calls can be.

The budget must include delegated work. Several agents should not each be allowed to spend the same remaining balance. Reserve funds when work is launched and reconcile them with actual usage afterward. Before adding agents, consider whether the task can be split usefully. Independent investigations may benefit from parallel work; changes to shared code may require enough coordination to consume the expected saving.

Before another attempt, check what has changed that gives it a better chance of succeeding. When the budget runs out, save the partial work and explain what remains unresolved. The team can then decide whether to continue, change the approach, or leave the task. Keep the status as incomplete until the acceptance criteria have been met.

6. Account for work that was never getting done

Consider a backlog of outdated documentation, neglected tests, and dependency upgrades. If agents start working through it, spending may rise. Claiming a saving against the human hours those tasks might have taken assumes someone was going to spend those hours. In many teams, the work would simply have stayed in the backlog.

For work the team already did regularly, compare the cost of reaching an equivalent result, including the human review and correction that remain. For newly undertaken maintenance, report what is now covered and what it costs to sustain. Updated dependencies or tests around a previously untested component can justify spending without needing to be translated into hypothetical hours saved.

Be clear about which benefits have been observed and which are still expected. Closing a known maintenance gap is measurable; assigning a cash saving to an incident that might never happen is much harder to defend. Leadership may decide that broader maintenance coverage is worth a larger budget. That should be a visible investment decision, with someone responsible for checking whether it pays off.

7. Keep the definition of done intact

An instruction to minimize cost leaves too much unspecified. The agent also needs an agreed scope, acceptance criteria, required checks, and a budget. Enforce those checks in the workflow and reserve enough budget to run them. If implementation uses up the allowance before verification, the result is an unverified change. The team needs to see that status rather than discover it during review or after deployment.

Review cost alongside completion rates, rework, and quality. When a workflow becomes cheaper, check what changed. It may have eliminated unnecessary calls, moved work onto a reviewer, or omitted something the task required. Those have different consequences, even when they produce the same reduction in model spend. Teams need the detail and authority to correct the problem without waiting for a finance review.

The responsibility for those choices stays with engineering leadership. Give teams budgets they can manage, let them spend more on maintenance when the benefit is clear, and require evidence that the work is complete. Before accepting a cost reduction, ask the team to show what they changed and what still gets done.

If today’s saving becomes tomorrow’s incident or someone else’s backlog, you have not reduced the cost. You have only changed who pays.