Delegating work to AI produces results quickly. It lets me finish more in the same amount of time and attempt work I would not previously have started. I experience those changes every day. But the help I receive today and the ability I retain tomorrow deserve separate attention. Becoming adept at receiving results may be different from becoming a better judge of them.
When building an AI product, I want to ask two questions together. Did this task end well? What did the person learn for the next similar task? We should evaluate the automation that produces good results alongside the design that supports human learning. I want tools to provide more appropriate help as the people using them develop.
Assisted performance and learning are different outcomes
University of Pennsylvania researchers compared AI support for mathematics learning among nearly a thousand high school students in Turkey. Both a general chatbot and a version providing teacher-designed hints improved performance on practice tasks. On a subsequent exam without AI, however, the general-chatbot group performed 17 percent worse than the group that had not used AI. The hint-based version largely mitigated that harm.1
A finding from mathematics education cannot be applied unchanged to every workplace task. It does, however, clarify a distinction that product evaluation needs. Performance with AI and a person's ability after that experience should be evaluated separately. Looking only at today's output can conceal differences between designs.
Some days, finishing is the priority. On others, learning matters. The same person can have different purposes for different tasks. A product should use a purpose already established and clarify it only when necessary. When learning is the goal, it can provide opportunities to reason and explain. When completion is the priority, automation can proceed under agreed criteria.
Set the criteria before receiving the result
Suppose an agent is asked to build a feature. If the person starts deciding what counts as correct only after reading the implementation, there is a great deal to review. Establishing success conditions and important constraints beforehand makes both execution and review more specific. Conditions that can be tested can be written in an executable form.
The person need not settle every technical choice in advance. They define the purpose and acceptable scope, then review the important assumptions in the agent's proposed plan. Criteria established before execution keep human intentions represented while automation does the work.
When the plan changes, record what changed and why. That record can inform the next similar task. If the conditions differ, revise the earlier criteria. The repeated experience is one of consulting a previous decision and making a new judgment that fits the present circumstances.
Necessary intervention should reach the result
When the result arrives, present the significant choices and the reasons for changes first. A person can question an incomplete explanation or revise a part where another approach fits better. They should also be able to see how their revision affected the output and its validation.
Explaining the reasoning themselves may help. Michelene Chi and colleagues studied how students' explanations of principles and conditions while learning from examples related to understanding and problem solving.2 In code review, an application would be articulating the reason for accepting or revising a consequential choice. A product can combine reading an explanation with explaining the reasoning behind one's own decision.
This need not involve writing a long explanation every time. New or consequential choices warrant more attention. Repeated tasks can use criteria already established. The product can also provide a way to revisit the reason for a decision later. The purpose is to check understanding where it matters, rather than maximize the amount of writing.
Record outcomes and decision quality separately
After the work ends, its actual outcome needs attention. But recording a good outcome as proof of a good decision can distort evaluation. Psychologists call the tendency to assess the same decision differently depending on how it turned out outcome bias.3
A record should distinguish information available at the time from information learned later. Did an anticipated risk occur? Was available evidence overlooked? Did a new condition emerge afterward? Distinguishing a favorable outcome from sound reasoning at the time makes a record useful for future judgment.
Those records can make the next review more specific. If the same constraint is repeatedly overlooked, make it clearer in the plan. If people repeatedly misunderstand a result, adjust the explanation. Difficulties in understanding, as well as corrections, can inform improvements to the tool.
Tools should adapt as people develop
Recording observable behavior serves this purpose better than assigning a fixed type to a person. Examine the tasks in which they revised a plan, the explanations that prompted repeated questions, and what happened after a condition changed. Use those observations to adjust how the next task is explained and reviewed.
If separating comparison criteria helped someone detect errors, try that presentation again on similar work. Check whether the benefit persists. A person's decision history should support their next judgment and improve the tool's way of helping. The objective differs from personalization that repeatedly supplies a preferred answer.
People should be able to understand and revise these adjustments too. Show which tasks receive closer review and which proceed automatically under agreed criteria. When the work or its purpose changes, change that allocation. The way a tool provides assistance should itself be open to review.
Support for learning needs a limit on burden
Asking a question before a task, reviewing a plan, explaining a result, and revisiting it later can each sound reasonable. Requiring all of them for every task would make everyday use difficult. The amount and timing of attention need to be considered across the whole workflow.
In an experiment with 199 participants, people preferred the conditions that effectively reduced overreliance on AI less.4 Features that support learning or review therefore need to be evaluated for burden as well. Design intervention frequency and stopping conditions together so people can concentrate on consequential judgments.
Evaluation should cover several outcomes: whether a person detects important errors, can explain a choice later, applies what they learned to a similar new task, and experiences changes in completion time and workload. The proportion of plans revised captures only one behavior. That number alone cannot establish improvement in a person's overall ability.
What changes in the next task
When similar feature work comes around, a person may explain the previous reasoning, recognize changed conditions, and establish a new criterion. That is evidence of something learned from the experience. If the agent uses earlier questions and revisions to provide a more suitable plan and explanation, their way of working together has improved too.
Most implementation and testing can still be automated. The person understands the choices that need them and examines their consequences. That experience then informs the next task's criteria and the tool's support. A product should help people understand and judge better as AI becomes more capable. Improving together begins with checking whether those changes actually occur.
Notes
[1] Hamsa Bastani et al., Generative AI without guardrails can harm learning: Evidence from high school mathematics, PNAS 122(26), e2422633122, 2025. Author's open manuscript. Distinguishes AI-assisted practice performance from exam performance without AI. ↩
[2] Michelene T. H. Chi, Miriam Bassok, Matthew W. Lewis, Peter Reimann, Robert Glaser, Self-Explanations: How Students Study and Use Examples in Learning to Solve Problems, Cognitive Science 13(2), 145–182, 1989. ↩
[3] Jonathan Baron, John C. Hershey, Outcome Bias in Decision Evaluation, Journal of Personality and Social Psychology 54(4), 569–579, 1988. ↩
[4] Zana Buçinca, Maja Barbara Malaya, Krzysztof Z. Gajos, To Trust or to Think, Proceedings of the ACM on Human-Computer Interaction 5, CSCW1, Article 188, 2021. Examines reductions in overreliance alongside subjective evaluations. ↩