PaperlayerView exact revision on arXiv

Source-linked AI summary

What Should a Software Team Spend on Agents? Simulation-Based Cost Optimization of Mixed AI-Human Teams

Steffen Herbold

arXiv:2610.20394v1cs.SE

TL;DR

The paper asks how software teams should divide costs between human developers, agents, and production bugs as agent adoption grows amid rising costs. It simulates mixed teams across 432 scenarios and finds that agent capability and project context matter more than token price for choosing a cost-effective team.

  • Problem

    With software agents rapidly adopted amid spiraling costs, it is unclear how teams should divide spending between developers and agents to deliver required work at the lowest total cost.

    Source: §1 · p. 2

  • Method

    The authors simulate teams with eight agent roles and use evolutionary search across 432 scenarios to find cost-optimal configurations.

    Source: §1 · p. 2, §7 · p. 56

  • Results

    Agent capability matters more than token price, and whether mixed teams cost less than human-only teams depends on context; highly capable agents make development cheaper.

    Source: §1 · p. 3, §7 · p. 56

  • Takeaways & Limitations

    There is no single optimal team for AI-native software development; team configurations depend on project context and agent capabilities.

    Source: §7 · p. 56

    The model assumes repeated freeze inspections are independent of earlier inspections, an optimistic assumption because reviewers may miss the same bug again.

    Source: §3.12 · p. 31

Abstract

from arXiv · show

Context: AI agents are rapidly adopted in software development, but their token costs are rising and it is unclear how much a team should spend on agents, and on which tasks. Objective: We determine how teams should divide spending between human developers and AI agents to deliver the features a project demands at the lowest total cost. Method: We model mixed teams of human developers and AI agents with eight specialized roles as a discrete-time stochastic process covering bug injection and detection, technical debt, human supervision of agents, and release cycles with feature freezes. Using Monte Carlo simulation and evolutionary search, we determine cost-optimal teams for 432 scenarios varying developer capability, project velocity, debt dynamics, agent capability and price, and bug costs, and compare them with a human-only baseline. Results: Escaped bugs are the dominant cost driver, and 61% of the agent budget goes to finding bugs. Agent capability matters more than token price, since higher-quality outputs reduce downstream quality assurance costs. In teams with capable agents, human developers mostly fix bugs and leave the implementation of new features to the agents. Teams with high-capability agents are typically cheaper than human-only teams, but low-capability agents offer no consistent advantage. At realistic velocities, the optimal teams still spend more on developers than on agents. Conclusions: There is neither a universal token budget per developer nor a universal agentic team structure. As in traditional development, this depends on many factors and teams need to be carefully tailored to the project context to achieve the optimal cost-quality trade-off.

1 Introduction

The paper examines how to compose human developers and AI agents to meet project demand at the lowest total cost, accounting for labor, agent, and production-bug costs. It models interacting bug, quality, debt, architecture, escalation, documentation, and cost dynamics, allocating human capacity through an ordered sprint cascade with feasibility checks.

1 Introduction

  • The research asks how teams should allocate human and agent work to meet project demand at lowest total cost, assuming humans own code quality and design while agents implement, fix bugs, and provide QA under supervision.The model also accounts for the human effort required to supervise agents, provide design feedback, and resolve their failures.Source: §1 · p. 2

3 Model description

  • The simulation models sprint-level feature work, bug injection and detection, technical debt, tests and documentation, and release cycles in which unfixed bugs escape to production.Feature freezes switch the active agent composition toward quality assurance and bug fixing; tests increase bug detection likelihood, while technical debt can accumulate with development work.Source: §1 · p. 2, §3.2 · p. 8, §3.4.1 · p. 9

3.1 Roles

  • The model distinguishes eight agent roles so teams can optimize both agent spending and its allocation, using evolutionary search to find cost-optimal compositions across scenarios.Costs include agent token use, developer salaries, and bugs reaching production.Source: §1 · pp. 2–3

1 Introduction

  • Agent capability matters more than token price: capable agents need less supervision and create fewer bugs, while weaker agents are not consistently cheaper than human-only teams.More optimistic capability assumptions show significant potential cost savings.Source: §1 · p. 3
  • With the most capable and cheap agent tiers, developers spend a median 88–90% of coding time fixing bugs, while few agents are assigned to bug fixing.The finding concerns coding time in the tested scenarios, not all developer work time.Source: §1 · p. 3
  • Human-developer costs exceed agent costs in most scenarios, but the simulations favor greater human spending except at extreme or high velocities; agents can also enable speeds beyond human-only teams.The simulations report that high or extreme velocities can force stronger reliance on agents.Source: §1 · p. 3
  • Escaped bugs, especially security bugs, remain the largest cost factor, while quality assurance often dominates agent spending because preventing bugs saves money.The simulations describe feature acquisition as comparatively cheap and preserving quality as expensive.Source: §1 · p. 3

2 Related work

  • The authors identify a gap in prior software-project simulations: existing models did not account for AI agents, motivating a framework for modeling human developers and AI agents co-evolving software.The paper distinguishes its focus on optimal team structures, costs, and product quality from work on how humans and AI collaborate or define processes.Source: §2 · pp. 3–4

3.5 Configuration parameters

  • Configuration parameters cover bug injection, bug detection and quality degradation, debt and related dynamics, and role-specific agent costs.The configuration also includes architecture, escalation, and documentation parameters.Source: Table 5 · p. 13, Table 6 · p. 13, Table 7 · p. 13

3.6 Sprint transition function

  • A ten-step, fixed-order sprint transition cascades developer time through overhead and support demands before dividing remaining capacity between bug fixes and features.During feature-freeze sprints, feature implementation stops and remaining capacity goes to bug fixing; coding effort is modeled as independent of technical-debt level.Source: §3.6 · p. 13, Step 1 — Human capacity allocation · pp. 14–15
  • The feasibility check requires enough developer capacity for communication and agent monitoring under perfect documentation, but is necessary rather than sufficient.Early monitoring can still exceed available capacity because documentation coverage starts below its ceiling; architecture-review or escalation shortfalls reduce efficiency but do not prevent implementation.Source: Step 1 — Human capacity allocation · p. 15

Step 2 — Debt penalties

The model combines technical, architectural, and escalation debt into a measure that reduces team productivity. Architectural and escalation queues are scaled against the team’s ideal sprint capacity.

Step 2 — Debt penalties

  • Architectural debt includes work at any stage of the architecture pipeline, with queue levels normalized against the team’s ideal review throughput.A normalized queue of 1 represents a full sprint of work to drain; at that level or higher, architectural degradation is maximal.Source: Step 2 — Debt penalties · pp. 15–16
  • Escalation debt reflects unresolved interventions that indicate agent oversight demands and degrade coordination quality.The escalation queue is normalized by the team’s maximum escalation throughput.Source: Step 2 — Debt penalties · p. 16
  • The combined-debt multiplier equals 1 at zero debt and falls to δmin at Deff = 1, affecting feature speed, bug injection and fixing, code review, and agent escalations.δmin sets the maximum negative impact, while δexp controls the rate of decay.Source: Step 2 — Debt penalties · p. 16

Step 3 — Feature arrival and implementation

New backlog arrivals can be implemented in the sprint they arrive. The model prioritizes approved architecture work for agent capacity, then uses human capacity before agents for feature implementation.

Step 3 — Feature arrival and implementation

  • New feature arrivals are added before implementation, making them available to be worked on in the same sprint.Human and agent implementation then drain the backlog.Source: Step 3 — Feature arrival and… · p. 16
  • Agent capacity first serves approved architecture proposals; for features, developers are served first and agents implement what remains.The model uses developer capacity first because their salaries are paid regardless.Source: Step 3 — Feature arrival and… · pp. 16–17
  • Architecture implementation consumes agent capacity but does not count as user-visible feature delivery; each proposal uses five features’ worth of capacity.Technical debt linearly reduces feature implementation, which is capped at the available backlog.Source: Step 3 — Feature arrival and… · p. 17

Step 4 — Test suite update

The Test Development Agent expands the cumulative test suite before bug detection, subject to a coverage ceiling. Newly written tests can therefore improve coverage during the same sprint.

Step 4 — Test suite update

Step 5 — Bug injection and detection

Step 5 models bug injection and detection across development and feature-freeze sprints, with detection staged through testing, code review, and security audit.

Step 5 — Bug injection and detection

  • Agent bug injection rises with accumulated debt, while human-implemented features use a fixed per-feature bug rate.The model randomizes injected bug counts with a Poisson distribution and assigns bugs to security, major, or minor types.Source: Step 5 — Bug injection and detection · pp. 17–18
  • Detection runs tests first, then reviews surviving bugs, then audits surviving security bugs; inspected code depends on the release-cycle phase.Development sprints inspect current-sprint features, whereas feature-freeze sprints re-inspect the current release cycle.Source: Step 5 — Bug injection and detection · pp. 18–19
  • The test suite detects bugs during development sprints but is not rerun during feature freezes because it already ran on each implemented change.The test detection rate is based on test coverage.Source: Step 5 — Bug injection and detection · pp. 18–19
  • Code-review effectiveness diminishes when the number of features to review exceeds the number of agents.The model represents this with a logarithmic degradation function.Source: Step 5 — Bug injection and detection · p. 19
  • Detected minor and major bugs increment the known-bug queues, with that count serving as an intermediate value before Step 7 fixes bugs.Test and review detections are drawn as binomial counts using their corresponding detection probabilities.Source: Step 5 — Bug injection and detection · p. 19

Step 6 — Architecture queues

Architecture work flows from feature-generated change requests through agent proposals and human review into a queue for implementation in the next sprint.

Step 6 — Architecture queues

  • Implemented features generate Poisson-distributed architecture change requests that enter the change-request queue.The arrival rate is farch,chg per feature implemented that sprint.Source: Step 6 — Architecture queues · p. 19
  • Architecture Agents drain change requests into design proposals, while human review capacity reduces the review queue.Each resolved request produces one proposal.Source: Step 6 — Architecture queues · p. 20
  • Proposals reviewed and approved this sprint enter the architecture implementation queue for Feature Implementation Agents to implement next sprint.Source: Step 6 — Architecture queues · p. 20

Step 7 — Bug fixing

Bug fixing uses a shared severity-and-status priority order, with human fixes preceding agent fixes and the two phases differing in how their budgets are determined.

Step 7 — Bug fixing

  • Both fixing phases prioritize release security bugs, known security bugs, release major bugs, known major bugs, release minor bugs, then known minor bugs.Source: Step 7 — Bug fixing · p. 20
  • Human developers spend a debt-independent bug-fixing budget first, fixing one bug per budget unit.Source: Step 7 — Bug fixing · p. 20
  • Bug Fixing Agents then use a shared budget scaled by agent count and reduced as technical debt accumulates, with one unit consumed per bug fixed.The agent rate is scaled by the debt amplifier δD.Source: Step 7 — Bug fixing · p. 20
  • Because human fixes take priority, a well-staffed team can keep the known-bug queue short even when δD is low.Source: Step 7 — Bug fixing · p. 20

Step 8 — Escalation queue

Step 8 adds a human-resolution queue for escalations from supervised agent work, with escalation arrivals increasing as debt accumulates.

Step 8 — Escalation queue

  • Agents generate human escalations at rate ρesc per completed supervised work item.Source: Step 8 — Escalation queue · p. 21
  • Escalation-producing work includes agent implementation, architecture changes, and agent bug fixes, but excludes human work and review or artifact-checking services.Test and documentation agents' artifacts are reviewed with their associated code rather than escalated.Source: Step 8 — Escalation queue · p. 21
  • Accumulated debt increases escalation arrivals through the factor (2 − δD), and resolved escalations reduce the queue.Source: Step 8 — Escalation queue · p. 21

Step 9 — General maintenance

After implementation, testing, and bug fixing, maintenance agents provide indirect value by reducing technical debt and improving documentation, which lowers developers’ cognitive load when supervising agents.

Step 9 — General maintenance

  • Maintenance agents act after feature implementation, testing, and bug fixing, reducing debt and improving documentation rather than directly delivering features or fixing bugs.Their documentation reduces the cognitive load of human developers supervising agents.Source: Step 9 — General maintenance · p. 21
  • Feature implementation and bug fixing increase technical debt, while Refactoring Agents reduce it.The passage identifies these as activities driving technical debt over time.Source: Step 9 — General maintenance · pp. 21–22
  • Developer Documentation Agents add up to one document per completed feature, increasing documentation coverage in the next sprint.The document count is capped at the completed-feature count.Source: Step 9 — General maintenance · p. 22

Step 10 — Release event

This section describes how the simulation models release escapes, feature value, and human and agent costs, and how it evaluates and searches team configurations under throughput and simulation uncertainty. It also notes simplifying assumptions about technical debt and freeze-time bug detection that limit the model’s realism.

Step 10 — Release event

  • At each release, detected-but-unfixed and undetected bugs escape to production, enter the repair queue, and the bug queues reset for a new cycle.When no release fires, release updates are skipped; the release uses post-fixing queue values for that sprint.Source: Step 10 — Release event · p. 22

3.7 Objective functions

  • The objective combines feature throughput with escaped-bug, human-personnel, and agent costs to evaluate development configurations.Feature value is approximated by average features delivered per sprint; quality cost is a weighted sum of escaped bugs by type.Source: §3.7 · p. 22, §3.7.1 · p. 23, §3.7.2 · p. 23

3.7.3 Human personnel costs

  • Human cost is salary prorated over the simulation horizon, while agent cost reflects completed work for demand-driven roles and per-sprint charges for three flat-rate roles.Charging for actual work captures under-utilization; flat-rate roles can continue to incur costs when additional agents no longer improve outcomes.Source: §3.7.3 · p. 23, §3.7.4 · pp. 23–24

3.8 Monte Carlo protocol

  • Each configuration is evaluated across independent Monte Carlo runs, with mean costs used as estimates and 95% percentile bootstrap confidence intervals quantifying uncertainty.Runs randomize outcomes through processes such as feature arrivals and bug detection; human cost is deterministic for a given staffing level.Source: §3.8 · pp. 24–25

3.9 Search problem

  • The search minimizes expected cost per delivered feature subject to keeping pace with incoming feature demand, using evolutionary search because exhaustive configuration search is infeasible.The evolutionary algorithm mutates candidate configurations and uses selection to improve the population.Source: §3.9 · p. 25, §3.11 · pp. 26–27, §3.11.4 · p. 29

3.10 Selection under Monte Carlo noise

  • Configurations with overlapping 95% confidence intervals are treated as statistically indistinguishable, with larger teams removed only when a smaller team also measures better.The preliminary indistinguishable set is re-simulated with more replications before selection is applied again.Source: §3.10 · p. 26

3.11 Search strategy

  • Initial candidates are sampled within staffing, release, freeze, and role-capacity bounds; constraint handling prefers feasible configurations, then lower cost among those meeting throughput.Candidates may be sampled even if they fail the throughput constraint, allowing the search to approach the admissible region from outside.Source: §3.11.1 · pp. 27–28, §3.11.2 · p. 28

3.12 Limitations of the simulation’s scope

  • The simulation simplifies development by using fixed effort and cost assumptions, omitting cost growth with system size, and treating human effort as debt-independent.The authors note that omitting system-size cost growth may underestimate costs for larger systems over time.Source: §3.12 · pp. 30–31
  • Human effort estimates account for coping with existing code complexity, but the model does not capture how technical debt slows developers over time.Modeling human test generation and debt reduction would require additional assumptions about how developers allocate time between those activities and implementation or bug fixes.Source: §3.12 · p. 31
  • The model assumes freeze-time reviews detect previously missed bugs as readily as newly injected bugs, an optimistic assumption because reviewers may miss the same bug again.The authors consider this assumption plausible given LLM stochasticity and the option to use different models across inspection phases; they note that data to estimate reduced detection probability is unavailable.Source: §3.12 · p. 31

4 Experimental setup

The experimental setup uses a common two-year green-field simulation and Monte Carlo protocol to compare optimized mixed teams with a human-only baseline across 432 scenarios. It specifies the staffing, release, search, and baseline configurations, including how the baseline is evaluated when no configuration meets required throughput.

4.1 Human-only baseline

  • The human-only baseline sets agent counts to zero, optimizes staffing and release decisions, and reserves developer capacity for quality assurance in a simplified model without debt dynamics.Human bug detection replaces agent supervision, while developers implement features and fix bugs themselves.Source: §4.1 · p. 32

4.2 Scenarios

  • The study evaluates 432 scenarios by combining five orthogonal aspects, using low, medium, and high settings plus stress tiers for project dynamics and agent costs and throughput.The stress tiers are very high project dynamics and pessimistic agent costs and throughput.Source: §4.2 · p. 33, §4.3 · p. 41

4.2.1 Human developer parameters

  • Human parameters assume 40 hours per FTE per week, one hour of communication overhead per team member, and 2.5 weekly hours of agent-monitoring overhead.Feature implementation time is set at 4, 2, and 1 hours for low, medium, and high tiers; bug-fix time is 60, 30, and 15 minutes, respectively, and human QA detection is 0.8 across tiers.Source: §4.2.1 · pp. 33–34

4.2.2 Project dynamics parameters

  • Project-demand tiers use issue rates from actively maintained popular open-source projects, with an additional stress tier of 1,000 issues per week.The project sample comprised 1,000 projects; the estimates may not represent closed-source projects, and the extreme tier stresses the architecture pipeline.Source: §4.2.2 · pp. 34–35

4.2.3 Debt dynamics parameters

  • Debt assumptions vary by tier: comprehension slowdowns are 40%, 34%, and 0%, while debt increases per feature or bug fix are 2%, 6%, and 13%.The throughput fraction retained at maximal debt is 0.94, 0.77, and 0.60 across low, medium, and high debt-penalty settings.Source: §4.2.3 · p. 36

4.2.4 Agent costs and throughput parameters

  • Agent costs and capabilities are estimated from task assumptions and benchmarks, with an added pessimistic tier combining low-tier capability with ten times the high-tier cost.The pessimistic tier is intended to test whether conclusions about agent-heavy teams persist under less favorable assumptions.Source: §4.2.4 · pp. 37–39

4.2.5 Bug impact parameters

  • Escaped-bug costs are parameterized for simple web applications, enterprise systems, and safety-critical systems, with expected costs rising substantially across tiers.Minor bugs are estimated at $100, $150, and $250; security incidents at $48,000, $1.0 million, and about $120 million for low, medium, and high tiers, respectively.Source: §4.2.5 · pp. 39, 41, Table 14 · p. 41

4.3 Experiment configurations

  • All scenarios share a green-field initial state, one-week sprints, and a two-year horizon, with 100 replications during search and 1,000 for re-simulation.The common setup is intended to make differences attributable to scenario parameters rather than experimental configuration.Source: §4.3 · p. 42
  • Staffing levels ranged from a quarter-FTE to ten FTE, allowing part-time teams for low-arrival projects and larger teams only when they reduced costs.The stated range also sufficed for the very high project tier, where monitoring capacity limits supervised agents.Source: §4.3 · p. 42
  • Release cadences covered every sprint, biweekly, monthly, and quarterly releases, while freezes ranged from zero to two weeks and feature-versus-bug work varied in 10% steps.The throughput constraint required delivery of at least 98% of arriving features; continuous delivery allowed no freeze.Source: §4.3 · p. 42
  • The evolutionary search allocated 20,000 candidate evaluations per scenario, using 2,000 for the initial pool and 180 generations of 100 offspring with 100 elite configurations.Re-simulation of indistinguishable candidates occurred afterward and was outside this budget.Source: §4.3 · p. 42
  • 10,890 human-only configurations were evaluated exhaustively across human, project, and bug-cost settings, with the highest-throughput option marked inadmissible when none met the throughput constraint.The baseline varied staffing, release cadence, freeze length, and developers’ bug-fixing and quality-assurance shares; agent performance and debt dynamics do not affect it.Source: §4.3 · pp. 42–43

5 Results

Across the simulated scenarios, escaped bugs dominate costs, and agent value depends on capability and project context. The optimal teams devote much of the agent budget to quality assurance, while capable agents are often cheaper than human-only teams.

5.1 Search convergence

  • The final indistinguishable set has a median of 62 optimal mixed-team configurations, compared with 2 for the human-only baseline after re-simulation and tie-breaking.The authors attribute the larger mixed-team option set to its greater number of degrees of freedom.Source: §5.1 · p. 45, Table 16 · p. 46
  • All 432 searches converged, with elite turnover ending at 5% and incumbent cost changing 0.04% per generation; reported costs are precise to about 2%.All searches found a configuration meeting the throughput constraint, while 9 of 36 human-only enumerations were inadmissible at very high velocity.Source: §5.1 · pp. 44, 46

5.2 Cost drivers

  • Escaped bugs are the largest cost driver: high bug-impact projects cost 72.6 times the low-impact tier, while higher-capability agents can lower total costs despite higher token prices.Even in the low bug-impact tier, escaped-bug costs are close to feature-implementation costs.Source: §5.2 · p. 47, Table 17 · p. 48, Figure 3 · p. 48
  • Debt dynamics increase costs by up to 4.8 times; project dynamics have a smaller, nonmonotonic effect, with the very high tier costing 1.3 times the high tier.Higher debt dynamics mainly increase escaped bugs; the very high project tier may produce outlier releases with bugs that cannot all be caught and fixed in time.Source: §5.2 · p. 47

5.3 Composition of costs

  • With medium- and high-tier agents, developers devote 88–90% of coding time to bug fixing overall; bug fixing remains predominantly human work under the simulation assumptions.Developers spend a median 75% and 80% of development-sprint coding time on bug fixing with medium- and high-tier agents, respectively.Source: §5.3 · pp. 49–50
  • 61% of agent spending goes to quality assurance: Security Audit Agents receive 33%, Code Review Agents 24%, and Test Development Agents 4%; Feature Implementation Agents receive 28%.Security Audit spending rises with bug impact and depends on agent capability.Source: §5.3 · pp. 49–50
  • 88.9% of optimal teams use four-sprint releases and 99.1% use a two-sprint feature freeze; developers’ costs exceed agent costs in 65% of teams.The median agent-to-developer cost ratio is 0.32, and higher project velocity shifts spending toward agents.Source: §5.3 · pp. 49–50, Figure 4 · p. 51

5.4 Comparison with human baseline

  • 71.6% of scenarios favor teams with agents, with a median human-only-to-agent-team cost ratio of 1.93; high-tier agents are cheaper in 98.8% of scenarios, unlike low or pessimistic tiers.The low and pessimistic tiers are cheaper than the baseline in 55.6% and 44.4% of scenarios, respectively.Source: §5.4 · pp. 51–52, Table 18 · p. 52

6 Discussion

The optimal balance between developer and agent spending depends on project conditions, especially bug costs and project velocity. Agent capability, rather than token price, shapes whether agents are worthwhile and how work is divided.

6.1 Answer to the research question

  • Bug costs and project velocity increase agent spending, while higher debt dynamics require better agents or stronger human involvement.Capability matters more than token price because better agents inject fewer bugs and require less supervision, outweighing higher token costs.Source: §6.1 · pp. 53–54
  • Capable agents shift developers’ coding time to bug fixing (88–90%) while agents implement features and find bugs, receiving 61% of agent budget for security audit, code review, and test development.Feature implementation agents receive 28% of the agent budget on average; Fig. 7 breaks optimal agent costs down across the eight roles.Source: §6.1 · p. 54, Figure 7 · p. 54
  • At realistic velocities, developer costs exceed agent costs for 65% of optimal teams, with a median agent-to-developer cost ratio of 0.32; higher velocities shift spending toward agents.Project velocity shapes agent spending, while agent capability determines whether agents are worth using at all.Source: §6.1 · p. 55

6.2 Revisiting the token budget

  • Token spending above half of developer costs depends on project conditions: it is more common with high velocity, capable agents, and cheap bugs, and less common with low velocity, less capable agents, or expensive bugs.High agent-to-developer cost ratios can signal poor value; the authors favor total cost per delivered feature, including production bugs, over token consumption as an efficiency measure.Source: §6.2 · p. 55

6.3 Implications for practice

  • For practice, prioritize agent capability over token price and use quality assurance spending to prevent downstream costs from escaped bugs.The simulations tie agent value to capability to deliver bug-free code and detect bugs; scaling implementation and quality-assurance agents may make some high-velocity projects achievable.Source: §6.3 · p. 55
  • Monitor technical debt because agents tend to increase it, potentially raising long-term costs if it is not managed..Source: §6.3 · p. 55

7 Conclusion

The study uses simulation and evolutionary search to identify low-cost team configurations across project contexts. It concludes that no single team or token budget is optimal, and that results warrant validation against real projects.

7 Conclusion

  • There is no single optimal AI-native team: highly capable agents make development cheaper, while low-capability agents offer no consistent advantage, and realistic-velocity teams still spend more on developers.Escaped bugs are the main cost driver; agent spending shifts toward agents only at high velocities, and total cost per delivered feature is a better efficiency measure than token consumption alone.Source: §7 · p. 56
  • The model should be validated against real agent-using projects, especially for agent bug-detection capability and escaped-bug costs, on which results depend most strongly.The authors also identify possible extensions for intent and cognitive debt and for simplifying assumptions; changing agent capabilities and token prices motivate reevaluating team compositions.Source: §7 · p. 56

Declarations

The author reports no funding or relevant competing interests. The study has no applicable ethics approval requirements, and code and experimental results are available.

Declarations

  • No funding was received for the study.Source: Declarations · p. 56
  • The author declares no relevant competing interests; the sole author carried out the study’s conceptualization, methodology, software, analysis, and writing.Source: Declarations · p. 56
  • Ethics approval and consent were not applicable because the study involved no human participants or animals; code and experimental results are available online.Source: Declarations · pp. 56–57

Related papers

Loading 2610.20394v1…