I Am Three Minds About AI

I want room for all three

I am three minds about AI. The builder in me wants to put it to work. The scientist wants to know what the result actually demonstrates. The citizen wants to know who will benefit, who will carry the mistakes and whether anyone has asked them.

I need all three when the decision matters. You may recognise the argument inside yourself. You can welcome help with a difficult task while worrying about becoming dependent on it. You can admire a demonstration and still ask whether the person signing the contract understands its limits. There is no obligation to choose a permanent side and defend everything sold under its name.

My concern begins when one of those perspectives silences the others. The builder can become impatient with questions. The scientist can keep asking for another study after there is enough evidence for a careful first step. The citizen can describe a legitimate harm so broadly that no improvement seems acceptable. Each can also correct something the others overlook.

When you ask whether I am optimistic about AI, I want to know which decision we are making. I might use AI to help someone understand an unfamiliar document. Before I approved an automated payment or changed an organisation's staffing, I would need a different level of evidence. My enthusiasm should respond to the evidence and the consequences of each.

The builder needs the scientist

A study published in Nature Human Behaviour on 26 October 2026 illustrates the problem. Its published sample comprised 487 consultants completing data-science tasks. AI improved assisted performance, without evidence of better subsequent unaided technical answers. The result limits what we can infer about learning from a better finished answer.

A better answer can be valuable even if it teaches me little. I may need a completed output and a competent reviewer, with no ambition to master the subject that afternoon. A training exercise carries a different promise. If I am meant to develop the ability to work without the same help next time, the finished answer cannot be the only evidence of progress.

Imagine asking an assistant to build a financial model, then trying to explain why changing one assumption changes the conclusion. Whether you can follow that relationship tells you something the spreadsheet's appearance cannot. If you get stuck, you have a specific question to work on before relying on the model.

Where the assistance helped

In a study of 5,172 customer-support agents, Erik Brynjolfsson, Danielle Li and Lindsey Raymond reported an increase in issues resolved per hour of “15% on average, with substantial heterogeneity across workers.” In ordinary language, the benefit varied considerably between workers. The researchers also found evidence of learning that persisted during outages. One workplace cannot settle the question for every occupation.

A smaller experiment complicates the story. Anthropic researchers studied 52 developers learning an unfamiliar library. Subsequent quiz averages were 50% with AI and 67% without it, a 17-percentage-point gap. The task was short, the research was provider-affiliated and the paper was a preprint. It does not establish universal deskilling.

I see no contradiction in taking both findings seriously. A tool can support learning in one setting while allowing a person to bypass it in another. If you want to understand the difference in your own work, examine what you are doing with the assistance. Are you making a prediction before seeing the answer? Do you check the reasoning and test a different assumption, or do you simply copy the answer into another document?

For the builder, that means choosing a task with a clear purpose and deciding what would count as useful help. I would record the work the tool creates as well as the work it saves, including time spent correcting it. I can enjoy building it while leaving that judgement open.

The scientist also owes the builder a fair hearing. It is easy to demand impossible certainty while ignoring the faults in the existing process. People make errors, leave tasks unfinished and struggle to access expertise. A proposal should face a comparison with the current approach, including its costs and failures. It should not have to compete with an imaginary version of human work in which nothing goes wrong.

I use People First, Problem Second, AI Last to keep that comparison grounded. Start with the person whose work or life needs to improve. Define the problem well enough to recognise progress. Then choose the assistance. Applied here, the method asks whether the person needs a faster answer, a stronger understanding or both, before selecting a tool and calling the exercise a success.

The invoice still has to add up

Consider a hypothetical customer-service team handling a disputed invoice. The customer's bill uses one currency, while a supplier's supporting record uses another. Both are clearly labelled. An assistant may find the relevant lines quickly and compose a courteous reply. The employee accepting that reply still needs to establish which amount belongs to which currency, whether a conversion is required and which transaction record controls the calculation.

A useful assessment would include that discrepancy. Ask someone who knows the work to judge whether the response settles the customer's concern and uses the right records. A formal-sounding letter that repeats the wrong amount should fail. So should a correct calculation explained so badly that the customer still cannot tell what they owe. The team needs an agreed standard for both.

This is a proposed exercise; the studies above cannot predict how much it would help this team. Use approved records, preserve their labels and ask the employee to explain the decision after closing the tool. If the exercise exposes a confusing invoice process, fixing that process may deserve priority. More assisted replies would not settle which record should govern the bill.

The citizen wants a say in the bargain

The citizen in me is least satisfied by an average productivity figure. If a team produces more, I want the discussion to include workload, pay, opportunities to learn and who remains accountable for mistakes. Those are choices for people and institutions to make. A model's capabilities cannot decide them on our behalf.

Better evidence alone cannot give a worker more influence over a purchase or make an employer share the benefit fairly. That requires a conversation about authority and terms. I want staff involved before a change is presented as settled, with a way to report problems and challenge an incorrect assessment.

There is also a cost to endless hesitation. A cautious policy can leave people doing avoidable work or deny them useful assistance. I would set a clear boundary around an initial use, identify who can stop it, and agree what evidence would justify continuing. People affected by a mistake should not have to discover that boundary after the mistake reaches them.

The decision I would be willing to make

Start with a task small enough that the people doing and receiving the work can inspect the result together. Ask what currently goes wrong and what a satisfactory result would look like. Agree whether the purpose is faster completion, learning or both. That agreement matters when the first promising results arrive: it should stop us from redefining success to suit the result.

For an initial comparison, use approved examples of similar difficulty and count the time spent preparing, checking and correcting them. Where practical, have someone judge acceptability without knowing which method produced the draft. Ask the employee to explain an important decision without AI as a separate check. A small exercise can expose questions; it cannot certify safety or justify cutting staff.

The next conversation should concern the work that changed. Did someone else's review queue grow? Could the employee explain an error and repair it? If time was saved, what will happen to it? Keep the inputs, criteria, tool version and corrections so a later reviewer can understand the decision. Name who can stop the use if the conditions change.

I can be enthusiastic about the result and still decline the proposed terms. A successful demonstration does not oblige me to accept a staffing plan, a price or an unexplained transfer of responsibility. That is where my three minds become useful to one another: they help me decide what I am actually agreeing to.

Questions you may still have

Must I understand everything the model does internally?

You need enough understanding to use the result responsibly for the task. You may need to check the inputs and method, recognise when the result could fail or consult a qualified reviewer. Reproducing every internal computation is a different demand. Define the practical knowledge your responsibility requires before judging whether you have it.

How can a junior colleague challenge an impressive demonstration?

Ask to see a case with a missing input or an answer the team can independently verify. Frame the question around the acceptance criteria and the customer's needs. A leader can make that easier by inviting questions before endorsing the proposal and by explaining how concerns will be resolved.