AI makes software production easier. It does not make every generated change ready to ship.
This paper distinguishes three stages: Generated Output, Verified Outcome, and Accepted Outcome.
It argues that AI-generated code with unresolved dependencies, assumptions, interfaces, responsibilities, and decisions creates coordination debt that can absorb the gains from faster generation.
The response is not another approval queue between agents and humans. It is lifecycle assurance: establishing the working conditions and evidence needed for justified decisions while work is being performed.
A team that can generate ten implementations before lunch has gained extraordinary capability. Whether it has made ten times more progress depends on what happens next: which alternatives deserve attention, whether they fit the existing system, and what it takes to make one ready for release. In this context, cheaper experimentation is valuable. A growing inventory of unresolved work is not the same as achievement.
The distinction now has substantial empirical support. Demirer, Musolff, and Yang combine development records and AI-usage telemetry for more than 500,000 developers. Their September 2026 NBER working paper published by researchers from MIT and Wharton uses a matched event-study design to estimate changes following the adoption of successive coding-tool generations. The cumulative headline estimates are approximately 240% more commits, 80% more projects worked on, and 30% more releases.
The percentages cannot be divided into an acceptance rate. They compare changes in distinct quantities, each against its own baseline. A 30% increase in releases does not mean that 30% of generated code ships. Nor does the difference establish that the remaining work is defective. The study examines both larger deliverables and increased experimentation; its evidence attributes much of the attenuation to experimentation, including alternatives that are rewritten or abandoned. Selecting among alternatives can improve the final product.
More output from one activity cannot readily replace the work required in other activities. Their marketplace analysis also found increased software entries without a corresponding rise in total usage. It cannot fully distinguish between product limitations and the constraints on discovery and adoption. Shipping is distinct from creating customer value.
These findings are not a universal estimate of enterprise productivity. The study is observational and primarily covers open-source activity and software marketplaces. Its data offer limited direct coverage of proprietary enterprise software. Separately, peer-reviewed field experiments involving 4,867 developers found a 26.08 percent increase in completed tasks, with substantial statistical uncertainty and variation between experiments. This is evidence of useful task-level assistance, not an equivalent increase in accepted releases.
The inference for consequential software is therefore precise: evaluate the entire engineering process. Faster generation creates opportunity; realizing it requires the complementary capacity to select, integrate, verify, validate, and decide. Assurance does not guarantee market demand, but it can establish whether the engineering organization has a defensible basis to release what it has built.
Consequential software is defined as software whose failure or misuse can cause material harm to safety, health, security, essential operations, or financial integrity. The consequence depends on the intended use and operating context, not the codebase size. A small payment-authorization rule can be consequential; not every large enterprise application is. The relevant question is what the organization and its users are exposed to when the software behaves incorrectly.
The proposed progression is simple. The Generated Output is a candidate artifact, such as code, a requirement, a design, or a test. A verified outcome has satisfied the specified technical checks within an identified scope and configuration. An accepted outcome is an integrated release-level result judged ready to ship by the appropriate authority, with the required validation, evidence, and disposition of exceptions for its intended use. Many artifacts and verified contributions may compose an accepted outcome.
Verification is scoped evidence, not a universal guarantee. Established software engineering practices distinguish conformance to specified requirements from validation against stakeholder expectations and the intended environment. This study retains this distinction. Acceptance is not a substitute for either activity, and a recorded release or successful deployment is not automatically evidence of both.
The green component is not yet an accepted system.
Candidate work can arrive faster than an organization can integrate and evaluate it. This is a capacity problem, but not simply a shortage of reviewers. Unclear intent, overlapping changes, incompatible interfaces, unavailable environments, and uncertain decision ownership can all increase the effort required for each candidate. Adding another generation agent may enlarge the queue without addressing any of those constraints.
Coordination debt refers to the accumulated future work that arises when dependencies, assumptions, responsibilities, interfaces, and decisions are not resolved or represented as agentic work proceeds. Debt appears as repeated clarifications, duplicated implementations, stale analyses, integration repairs, reopened decisions, and evidence assembled after its context has been lost.
Therefore, a central coordinator is insufficient. It should limit unnecessary communication, preserve the authoritative state, and escalate the correct decisions without absorbing every detail. The objective is less avoidable coordination per accepted outcome, not maximum interaction between agents. Human-led engineering is the starting reference, not a permanently inferior comparison group.
Verification provides evidence of the defined properties. Assurance connects evidence to the intended outcome, the conditions under which work was performed, relevant obligations, unresolved uncertainties, and accountable decisions. Trust is a judgment made by people and organizations; assurance makes its basis, inspectable and transferable. It does not manufacture certainties. An Agentic Engineering Assurance Layer, interpreted architecturally as the Assurance Plane, should maintain these relationships across the lifecycle rather than add a final reporting step.
For consequential software subject to certification or regulated approval, demonstrating functionality is only part of the assessment. FAA software-approval guidance, for example, addresses both lifecycle data and evidence that a project follows its approved plans and procedures. FDA guidance for device-software submissions similarly recommends documentation of development practices, requirements, risk management, verification, and configuration history. The applicable pathway depends on the product, its intended use, and its regulatory context.
This establishes two complementary questions: does the work satisfy its technical and intended-use requirements, and was it developed through the required processes with sufficient supporting evidence? Neither question can replace the other. Certification readiness should emerge from the development record, not from a retrospective claim that the process must have been followed because the software appears to work.
This study proposes Effective Outcome Throughput as the value-weighted number of accepted release-level outcomes per unit of elapsed time. Effective Outcome Velocity is its executive shorthand under a stated human and compute envelope. Effective describes how the engineering system reaches acceptance; it is not a fourth work-product stage.
Finally, approval is not the ground truth. A system rewarded solely for acceptance can learn to produce persuasive briefings or exploit permissive reviews. Record the decision, the quality and independence of its evidence, and subsequent findings separately. The goal is justified acceptance, not the fastest route to a yes.
Kealu Labs is developing a research and implementation program around a practical objective: enabling organizations to develop consequential software and maintain the evidence required for its acceptance as one coordinated process. Kealu Vector, introduced in early access under the Vector Assurance Assist designation, is intended to implement the Agentic Engineering Assurance Layer. It governs how agentic engineering work is performed and evidenced, so that humans can trust and accept the resulting work.
For organizations subject to certification or regulated approval, the intended value is a shorter, more predictable path to assessment. This does not mean reducing the required rigor. It means reducing the avoidable work of discovering missed obligations, correcting process deviations, reconstructing evidence, and reconciling inconsistent records late in development.
Certification readiness is not certification. Process conformity alone does not establish product safety, security, correctness, or fitness for use. Kealu may coordinate customer-owned or third-party testing and verification systems, but it does not own their test methods, perform domain acceptance testing as the responsible party, certify correctness, or assume responsibility for the resulting software. Formal findings and approval decisions remain with the responsible organizations and authorized assessors.
No measured reduction in certification time is claimed here. Industrial evaluation should examine time to a review-ready baseline, evidence-preparation effort, late process findings, finding-closure time, and assessor clarification cycles, while preserving the same substantive assurance requirements. External approval time should be measured separately from the preparation work Kealu can influence.
Dr. Antonio Vasaiely is the Chief Product and Strategy Officer at Kealu Inc. Over the past 15 years, his work has spanned safety- and security-critical embedded software, distributed-systems engineering for autonomous vehicles, and product strategy across portfolios exceeding $3.3 billion. His research focuses on long-horizon agentic engineering, human-agent collaboration, and the organizational and technical conditions required to develop consequential software. This paper is a personal thought-leadership contribution carrying his affiliation with Kealu.