Learning to use AI should give us more control over our work. It is an appealing thought. We can venture into software development that seemed out of reach yesterday, ask about an unfamiliar technology, and try it on the spot. The sense that we can do more is real.

But making progress on a job and exercising judgment as we do it do not always go together.

That gap came up in a conversation with CJ, PROTHENTIA’s CTO. This was not a discussion about people who resist adopting AI. It was about what happens around people who are using it enthusiastically.

CJ described seeing roughly three kinds of relationship in the work around him. Drawing on those observations, we can think of them as three modes of collaboration. In a directing mode, a person shapes the work, makes the judgments, and combines AI systems as components. This is closer to CJ’s own approach. In a co-creating mode, the questions and the conception of the work itself evolve through dialogue. The relationship is not only about seeking answers, but also about exploring together what to ask and what to create. Then there is a following mode: accepting AI’s proposals while one’s own criteria for judgment remain unclear.

This is neither an established taxonomy nor a way to assign people permanent types. The same person’s mode of collaboration may change between familiar work and a first attempt at software development. Directing is not being ranked above co-creating, or vice versa. Nor does AI taking the lead necessarily mean a person is merely following. Can they maintain their own criteria and question the direction when needed? The focus is on the relationship that takes shape in the work.

What, Exactly, Have We Handed Over?

There is nothing inherently wrong with letting AI lead. If only people who can map the entire route at the entrance are allowed to proceed, few more people will ever venture into unfamiliar work. The question is what else we hand over when we ask for directions.

Did we delegate writing the code? Deciding what to build? Or, without noticing, the judgment that the finished result is good enough?

Here, we would like to take the conversation a step further.

Must we be able to write every line of code ourselves in order to exercise judgment? We might instead be able to decide what we want to achieve, check whether it works as expected, and pause when something unexpected happens. With that loop in place, it should be possible to remain an active participant while delegating much of the implementation. Conversely, even if we feel we understand an explanation, it becomes hard to say where our own judgment entered the process if we keep adjusting the criteria for success to fit AI’s proposals.

A purpose, criteria for judgment, cues that something is wrong, and opportunities to pause or intervene. We would first want to ask whether any of these are missing from the flow of work. That is a more testable question than deciding that a person lacks ability.

Make the Judgments Visible, Not Just the Answer

One way to think about this problem predates AI by decades.

Cognitive apprenticeship is an educational approach that makes expert judgment visible to learners. In a 1991 essay, Collins and colleagues described experts demonstrating how they approach a task, observing and coaching learners as they work, providing support at difficult points, and gradually reducing that support as learners gain proficiency.

Being handed a finished product tells us little about where someone hesitated, what informed a choice, or what prompted a revision. Might those intermediate steps become easier to skip in collaboration with AI, precisely because the answers arrive so quickly?

Asking AI to narrate its thinking does not, by itself, solve this problem. A plausible explanation is not evidence that a judgment was correct. Rather than requesting a running account of an inner process, it may be more useful to make the alternatives, the grounds for a choice, and the points at which results will be checked available for examination.

For example, someone might initially define the conditions for success together with AI. Next time, they could write those conditions first and ask AI to point out omissions. Familiar parts could be delegated, with support brought back when an unfamiliar condition arises. These are possible ways to adjust the arrangement.

Cognitive apprenticeship was not a study of LLM use. Whether this adaptation works still needs to be tested. Nor must the goal be defined as eventually doing everything without AI. If support helps someone judge what to delegate and where to check, there is no obvious reason they should have to stop using it.

Put Verification Outside the Conversation

The conversation with CJ also raised another question: if something does not make sense, why move ahead instead of asking about it?

It matters. Yet asking more questions may not be enough. We can ask the same AI to explain its answer and find reassurance in the explanation. The conversation becomes more thorough, while still leaving us with no way to check correctness outside it.

TiCoder, a research system for code generation, creates a different point of contact. AI proposes tests, and a person checks whether they match the intended behavior. Those tests are then executed to narrow down the candidate code. The person is not only deciding whether an explanation sounds convincing; they are also judging what should happen for a given input.

The 2024 paper includes a user study in which 15 participants worked on small Python tasks. Among participants who mostly had programming experience, performance in identifying correct code improved under particular conditions. This cannot be read as proof of learning gains for beginners or of safety in real-world work. People can still misjudge the expected behavior, and tests can still miss important conditions.

Even so, the design implication is concrete. Rather than asking someone to understand an entire program at once, redesign the interaction around units of behavior they can judge. Then feed the results of execution back into the next judgment.

Providing more explanations and creating more opportunities to check are different things. Could that distinction be built into the environment for collaboration?

What We Might Try Next

Before assigning a new task to AI, a person could briefly write down the result they expect and what must not happen. They could then work with AI to decide how to check it and compare the outcome with those expectations. Agreed specifications and known correct examples would also serve as criteria. Conditions they cannot judge would be put on hold rather than allowed through without understanding. If something does not match, they could consider together whether the instructions, the implementation, or the checking method needs revisiting. Next time, they could change the conditions slightly and adjust where support is provided.

This is a proposal for a trial, developed from the conversation, not a procedure already shown to work. Requiring a pause every time may simply make work more burdensome. Continually questioning familiar tasks is not, in itself, autonomy.

We would want to look beyond the number of questions or interventions. Can a person notice when a result is different from usual? Can they stop, check, and change direction when necessary? Is support expanding the range of situations in which they can make those judgments?

AI moving the work forward and people ceasing to think should not be treated as the same thing. There may be ways of organizing work that keep the two apart.

Beyond the entrance, it seems we need more than smarter AI. We need a relationship in which we can draw on that intelligence while developing our own judgment. How might we design one?