AI Productivity Needs a Verification Loop

An AI assistant can produce a page of analysis or a working-looking script in seconds. The interesting engineering question comes afterward: how much work remains before someone can responsibly use it? That gap between generated output and accepted work determines whether an AI tool creates useful capacity, quietly transfers effort to reviewers, or helps a mistake travel farther.

I think about this through the kinds of systems in my portfolio: tools that connect information to a practical next step. A useful assistant should make that connection easier to inspect. When it proposes code, a research direction, or a decision, the supporting evidence and the limits of its authority should travel with the proposal.

My argument is that AI productivity needs a verification loop: define an acceptable artifact, gather bounded evidence, generate a candidate, check it against independent criteria, and control what happens next. Safety belongs inside that loop because mistakes, privacy failures, and unauthorized actions are all ways an apparently efficient workflow becomes expensive.

Completion is the useful unit of productivity

Consider a small software change. Writing the patch is one activity. Understanding its interaction with existing behavior, checking edge cases, reviewing dependencies, and deciding whether it can be released are others. If an assistant accelerates the first activity while making the others harder, counting generated lines gives a misleading account of progress. The relevant unit is an accepted change with a known scope and a credible path to maintenance.

The same distinction applies to research. A readable summary of ten papers is an intermediate artifact. A useful technical conclusion needs a question, appropriate sources, a way to distinguish reported evidence from inference, and enough detail for another person to challenge it. More summaries can increase the burden if every paragraph requires someone to reconstruct its origin.

My VLM Tuner project connects data labeling, model training, and inference testing through GUI tools. Its demonstration uses Qwen2-VL-7B-Instruct and LoRA adapters. Those are distinct stages with distinct artifacts: a labeled dataset, a training configuration, an adapter, and predictions to inspect. That structure suggests a useful principle for AI tools generally: make intermediate state visible rather than compressing an entire workflow into a convincing final answer.

Likewise, the AI Materials Discovery project connects engineering constraints, public materials datasets, research retrieval, and proposed synthesis paths. A ranked candidate is useful, but its engineering relevance depends on the assumptions behind the ranking. A proposed synthesis path needs a different kind of scrutiny again. The boundaries between stages matter as much as the model inside each stage.

What productivity studies actually let us conclude

Evidence already gives us reasons to measure locally. In METR's July 2025 randomized study, 16 experienced open-source developers completed 246 real tasks in repositories they knew well. Allowing early-2025 AI tools increased completion time by 19% in that setting. Developers nevertheless estimated afterward that AI had made them faster. This is evidence about a particular population, task distribution, and generation of tools; it does not establish that AI slows all developers. It does show why perceived ease and measured throughput should be recorded separately.

A different setting produced a different picture. The 2023 working paper by Dell'Acqua and colleagues studied 758 consultants. On tasks chosen to fall within the model's capabilities, AI users completed more tasks, worked faster, and received higher quality ratings. On a task selected to fall outside that frontier, AI users were 19 percentage points less likely to reach the correct solution. These findings support examining the fit between a task and a human–AI workflow, rather than assigning a single productivity multiplier to the technology.

Neither study tells me what a particular research assistant will do with a particular dataset. That requires measurement of the actual workflow. My inference is that verification cost should be a design variable from the beginning. A system that produces smaller, better grounded artifacts may create more value than one that produces impressive volumes of material that nobody has time to review.

There is also a quality constraint. Finishing faster by accepting weaker evidence is a change in the standard of work. A fair comparison keeps the intended standard explicit, even when the assisted workflow reaches it through different steps.

Start with an acceptance contract

Before asking a model to do useful work, I would write a short acceptance contract: what artifact is required, what evidence must accompany it, and what the assistant may change. This need not become a lengthy specification. For a research task, it might require a comparison table with source locations, consistent units, unresolved disagreements, and a clear separation between measured and computed properties. For a code change, it might identify the expected behavior, preserved interfaces, relevant tests, and files within scope.

The contract should describe observable outcomes. “Improve the materials analysis” invites the model to decide what improvement means. “Produce a reproducible comparison of these candidate records against this reference, retain missing values, and document every conversion” provides a target that a reviewer can inspect. It also prevents the system from filling gaps merely to make the answer look complete.

I would include explicit stopping conditions. If required evidence is absent, the output can state that the comparison is unresolved. If two sources disagree, the assistant can preserve both claims and explain the difference. If a requested change needs access outside the allowed workspace, it can return a proposal. These are successful outcomes when they faithfully represent the state of the task.

Defining acceptance early changes generation itself. The assistant can organize its work around the eventual review: a small patch, a source-backed row, a reproducible calculation. The reviewer no longer has to invent the standard after seeing the answer, when polished presentation may already have shaped expectations.

Retrieval should preserve evidence, not just add context

The original retrieval-augmented generation paper by Lewis and colleagues combined a generative model with retrieved external passages. That architecture makes relevant information available during generation. It does not make every resulting claim true, nor does it establish that a retrieved passage supports a specific engineering conclusion. In a practical workflow, finding a document and validating the use of that document remain separate operations.

I would preserve evidence at the level of the claim. A useful record contains a source identifier, a precise location, the extracted value or statement, and any interpretation applied afterward. A DOI alone is insufficient when the paper contains several compositions, temperatures, or measurement conditions. The reviewer needs a short route from the output to the actual supporting material.

This also makes disagreement useful. Suppose two papers report different properties for nominally similar materials. The assistant should ask whether the composition, phase, processing history, or measurement method differs before averaging the numbers. A disagreement field can be more valuable than an apparently precise aggregate. When the difference cannot be resolved, the comparison should remain qualified.

Context length does not remove this need. Liu and colleagues' Lost in the Middle study found that performance on their retrieval and question-answering tasks depended on where relevant information appeared in long inputs. That result concerns the models and tasks tested, rather than every future long-context system. It motivates a practical evaluation question: can this workflow reliably use the evidence it retrieves?

My proposed answer is to keep context purposeful and evidence inspectable. Retrieve enough to understand a claim, preserve its surrounding qualifications, and provide targeted passages for the current question. Repeatedly handing the model an expanding document collection makes it harder to tell whether a failure came from retrieval, interpretation, or an unsupported leap.

A worked example: an engineering research brief

Imagine an assistant preparing an early screening brief for a lightweight structural component. This is an illustrative design exercise inspired by the scope of my materials project; the records, workflow, and time estimates here are hypothetical. It is not a report of a completed experiment or a claim that any candidate has been validated.

The brief asks for candidates that satisfy specified stiffness and density constraints relative to a chosen reference. Before searching, the engineer identifies which properties are mandatory, how missing values will be treated, and which environmental assumptions matter. The assistant may organize evidence and propose code in a separate working directory. It cannot purchase materials, send messages, launch laboratory equipment, or modify an authoritative engineering database.

The first artifact is a source manifest: dataset version, retrieved record identifiers, research documents, and the exact reference values selected for this comparison. The assistant then creates a normalized table that retains original values beside converted values. If density is reported in grams per cubic centimeter, the conversion to kilograms per cubic meter is explicit. Unknown density remains unknown; it does not become zero or an estimate silently inferred from a related compound.

Next comes a small analysis script. It applies the agreed constraints and computes the requested ratios from the normalized table. Its output distinguishes records excluded for failing a threshold from records excluded for insufficient evidence. That distinction matters: a material absent from the shortlist may be poorly documented rather than unsuitable.

Only then does the assistant draft a narrative explaining the shortlist, limitations, and questions for follow-up. A candidate might look attractive on stiffness per unit density while lacking evidence about manufacturability or performance in the relevant conditions. The brief should say so. It should not convert a screening score into a deployment recommendation.

If synthesis research is included, I would keep it as a literature map: which prior work discusses related compositions or routes, what assumptions connect it to the candidate, and what remains unverified. Moving toward laboratory execution would require a separate qualified review of the actual materials, process, facilities, and hazards. A fluent procedural draft does not supply that review.

Build checks that can disagree with the model

The example only becomes a verification loop when something outside the generator can reject its output. Asking the same model whether its answer is correct may catch a simple oversight, but it can also reproduce the original assumption. I would use deterministic checks for properties that can be expressed precisely and targeted human review for judgments that cannot.

For the normalization script, a hand-calculated fixture can check a unit conversion and a simple ranking. Other fixtures should include a missing mandatory property, a duplicated identifier, and a value exactly on the acceptance threshold. These cases test the agreement between the contract and the implementation. Tests that merely copy the generated formula into a second file provide much less independent evidence.

Source review needs its own strategy. I would inspect the reference baseline and every claim that materially changes the recommendation, then sample lower consequence extraction fields. Sampling should be recorded as sampling; it should not be described as complete validation. When an error appears, related fields deserve further inspection because one mistaken conversion rule may affect many rows.

Model-assisted critique can still help. A second pass might search for unsupported comparative language, omitted limitations, or mismatches between a table and its narrative. I would treat those flags as review aids. Multiple models can share source errors or reasoning patterns, so agreement between them cannot replace checking the underlying artifact.

For VLM workflows, the parallel is clear: inspecting predictions on conveniently chosen examples cannot establish general performance. A proposed evaluation should include held-out data, relevant failure cases, and checks for leakage between training and evaluation material. Keeping labeling, training, and testing visibly distinct makes those questions easier to ask before a polished demo becomes a broader claim.

Keep retrieved content away from authority

Safety becomes concrete when the assistant can act. A document may be useful evidence about a material or an API while having no authority to instruct the assistant. That distinction becomes fragile if the same language model both reads external content and decides which tools to invoke.

Greshake and colleagues' 2023 indirect prompt injection paper demonstrated how instructions placed in content retrieved by an LLM application could influence its behavior, including tool interactions and information disclosure. The important boundary is between data supplied by an external source and instructions authorized by the user. A relevant search result can still be untrusted input.

In the research example, a retrieved page might contain an instruction to upload the working folder or execute a helper script. The task requires extracting evidence from the page. It does not authorize those additional actions. I would enforce that limit through the application: restrict available tools, constrain output locations, and prevent the research process from obtaining secrets or credentials it does not need.

Labeling retrieved text as untrusted and instructing the model to ignore embedded commands can help communicate intent, but it is not a security guarantee. The stronger control is to limit what a mistaken decision can accomplish. A process without access to confidential files cannot upload those files through its ordinary tools. A research worker without deployment credentials cannot directly publish its draft as an official result.

I would separate the authority to propose from the authority to commit an effect. The assistant can prepare a patch or research brief, and a controlled release step can act on the accepted artifact. That step should display the concrete destination and changes. A generic approval prompt for a long, shifting action sequence offers the reviewer little useful control.

Privacy and review effort are product constraints

Even a read-only assistant can create harm by revealing information in its answer. Permissions therefore need to apply to retrieval and output, not just to write tools. In a shared document system, a search result should respect the requesting person's access. A broad backend account should not quietly turn the assistant into a route around document permissions.

For a personal or small-team workflow, I would start with the minimum necessary corpus and an explicit understanding of where its contents go. Model inputs, tool logs, cached documents, and generated artifacts can all contain sensitive material. Local inference changes some data flows, but it does not automatically solve access control, retention, or accidental inclusion of secrets in an output.

The NIST Generative AI Profile, published in July 2024, describes risks including confabulation, data privacy, information integrity, and human–AI configuration. Its voluntary framework is useful here as a reminder that factual accuracy is one part of system quality. A technically correct answer delivered to the wrong person is still a failure.

Review also has a human capacity limit. If the interface produces twenty similar drafts, long undifferentiated logs, and repeated low-value approval requests, the nominal reviewer can become a bottleneck or a rubber stamp. I would show a compact diff, the important evidence, unresolved questions, and the specific effect awaiting approval. The design goal is to make careful review feasible at the rate the system produces work.

Count the whole loop, including the repair

A useful accounting model adds preparation, generation, waiting, review, revision, and integration time. It should also record whether the final artifact met the agreed standard. Otherwise a fast rejected draft and a slow accepted result can appear interchangeable in the dashboard.

Here is deliberately hypothetical arithmetic for the research brief. Suppose a manual workflow takes 180 minutes. An assisted workflow uses 20 minutes to define the brief and prepare sources, 15 minutes of generation and tool waiting on the critical path, 50 minutes of verification, 25 minutes of revisions, and 10 minutes of integration. Its total is 120 minutes, giving a 60-minute saving under those assumptions. These numbers are illustrative; they are not measurements from my projects or an estimate of typical AI performance.

The same example reveals the sensitivity to repair. If a source-mapping mistake takes another 80 minutes to find and correct, the assisted total becomes 200 minutes. Generation speed has barely changed, but the result is now slower than the assumed manual baseline. Improving evidence handling could therefore matter more than making the drafting step twice as fast.

For an actual evaluation, I would distinguish elapsed delivery time from human effort. Waiting can sometimes overlap with other work, while review may consume scarce specialist attention. An assistant that saves a generalist an hour but creates an hour of expert review has shifted capacity between people. Whether that is useful depends on the goal and the available expertise.

Comparisons should use comparable tasks and include failures, abandoned attempts, and delayed corrections. Alternating assisted and unassisted work can be a practical starting point, although task differences and learning effects complicate interpretation. I would report that uncertainty alongside the result. A small local measurement can guide a workflow decision without pretending to establish a universal productivity law.

Make the loop improve the next task

The most valuable output of a failed check may be a better task definition. If reviewers repeatedly correct units, encode the conversion and retain the original values. If research claims repeatedly lose their qualifications, require the qualifying passage in the evidence record. If large patches are expensive to inspect, reduce the scope of each generated change. These are improvements to the surrounding system rather than requests for the model to be vaguely more careful.

I would keep a small collection of representative tasks and failure cases, with expected artifacts and review criteria. Revisit them when changing the model, retrieval configuration, permissions, or tools. A better model can still interact badly with a changed parser or a broader corpus. Evaluation should follow the deployed combination.

There is a useful connection to embodied AI: an interpretation is only useful when the next layer knows what it may do with it. In software and research, that next layer might update a repository, inform a design choice, or shape a laboratory plan. The consequences differ, but the need to preserve evidence and constrain authority remains.

The AI tools I want to build help people reach defensible decisions with less friction. That means producing artifacts whose assumptions are visible, whose important claims can be traced, and whose effects are bounded. When those properties make checking cheaper, safety and productivity support each other in a very practical way: less hidden uncertainty reaches the next person.

Sources and further reading

1. Becker et al., Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, July 2025, original preprint. A randomized study in a specific experienced-developer setting.
2. Dell'Acqua et al., Navigating the Jagged Technological Frontier, September 22, 2023 working paper, hosted by MIT Sloan. Task-dependent effects of AI assistance in consulting work.
3. Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, first submitted May 22, 2020. The research architecture underlying the retrieval discussion.
4. Liu et al., Lost in the Middle: How Language Models Use Long Contexts, first submitted July 6, 2023. Evidence about positional effects in the evaluated long-context tasks.
5. Greshake et al., Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection, first submitted February 23, 2023. Research on attacks carried through retrieved content.
6. NIST AI 600-1, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, July 2024. Voluntary guidance addressing generative AI risks and evaluation.