The problem is not AI use, it is delegation without learning
Benjamin Davies' paper is not an anti-AI paper. The point is sharper than that. AI is harmful in the model when it becomes a substitute for the learner doing the task, not when it helps the learner do the task.
The setup is simple. A student faces a sequence of tasks. For each task, he can work or delegate to AI. Working is costly, but it builds skill. Delegating is easy, but it builds no skill. A teacher chooses the task sequence to maximize the student's skill growth, knowing the student is myopic and will choose the action that looks best right now.
That last assumption matters. The student does not fully price the future value of skill. He sees effort cost today and output today. If AI gives him the output without the effort, the skill-building part of the assignment is lost. The teacher's job becomes incentive design.
For a quant desk, this is familiar. The issue is not whether a junior uses Copilot, ChatGPT, or an internal coding assistant. The issue is whether the junior is still learning how to frame the problem, decompose the task, debug the edge cases, and understand the data. If the assistant writes the script while the junior only approves it, the work got done but the junior may not have moved much.
How the model turns curriculum into an incentive-design problem
Davies models tasks by "effort intensity." Effort-intensive tasks reward applying known methods. Think of implementing a clean volatility estimator from a clear spec, writing a parser, or reproducing a textbook backtest. Skill-intensive tasks reward choosing the right method. Think of deciding which microstructure filter matters, which transaction cost model is defensible, or why a factor decay pattern might be an artifact.
Without AI, the optimal curriculum has a natural shape. Early tasks are more effort-intensive because the student has little skill. The teacher wants the student to exert effort, and effort is more attractive when it visibly drives output. Later tasks become more skill-intensive because the student has accumulated enough skill to use effort well. Skill and effort are complements in the model. Once the student knows more, effort becomes more productive.
AI changes the teacher's problem. A task that was meant to induce effort now has an outside option. The student can delegate. So the teacher cannot just choose the task sequence that would maximize learning if the student always worked. She has to choose tasks that make working privately attractive enough relative to delegation.
That is the clean mechanism in the paper. AI adds an incentive constraint to curriculum design.
The main result: AI forces distortion away from the first-best learning path
The main result is that the teacher must distort the curriculum when delegation is available. The first-best path is no longer feasible if the student would rather hand off some tasks to AI.
The distortion is specific. The teacher makes earlier tasks more skill-intensive than the first-best curriculum would prescribe. This sounds counterintuitive. If a weak learner needs practice, why give harder, more skill-based work earlier?
In the model, the answer is incentive compatibility. The teacher is trying to make work attractive enough that the student does not delegate. The second-best curriculum ends up with effort intensity that first rises and then falls, rather than smoothly declining over time. The student still learns, but less than in the first-best case.
This is useful because it avoids vague claims about "AI making people lazy." The model says something narrower. When delegation is easy, the training designer may need to choose tasks that are not locally ideal for learning, simply to keep the learner engaged in effortful production. That lowers skill formation relative to the first-best curriculum.
Why better AI can widen skill gaps between strong and weak learners
The most practitioner-relevant extension is the case where AI complements effort. This is closer to how good coders use coding assistants. They do not just delegate a whole project. They use the tool to speed up boilerplate, search syntax, generate tests, or compare implementations.
Davies captures this with an AI quality parameter that does two things. It raises the payoff from full delegation, and it also raises the marginal product of effort. Better AI therefore has two opposing effects.
For high-skill students, the complementarity dominates. They know what to ask, what to reject, and where the assistant is likely to fail. Better AI makes their effort more productive, so they learn faster in the model.
For low-skill students, the delegation temptation can dominate. They cannot easily supervise the output or use the assistant as a true complement. Better AI makes it more attractive to skip the hard part. In the model, their learning can slow down.
That result fits a pattern many technical teams will recognize. Strong juniors get faster. Weak juniors can become dependent. The tool is the same, but the user's starting skill changes whether AI is a scaffold or a bypass.
What this implies for quant desks training juniors with coding assistants
The paper does not give an off-the-shelf training program. It does give a useful design lens. Treat assistant access as part of the incentive system, not just as tooling.
A few practical implications follow:
- Start with tasks where the junior must make visible choices, not just produce code. Ask for problem framing, assumptions, failure modes, and a short audit trail of rejected approaches.
- Separate "AI allowed" from "AI does the task." A junior can use AI for syntax or tests while still owning the decomposition and validation.
- Make early reviews focus on reasoning under constraints. If the code runs but the junior cannot explain why the data join is safe, the task did not train the right skill.
- Give stronger juniors more freedom sooner. They are more likely to use the assistant as a complement. Weaker juniors may need tighter task boundaries and more oral checks.
The key is not banning AI. A ban can push usage underground and removes a tool juniors will use later anyway. The better policy is to define which part of the task must remain human effort. For a quant researcher, that usually means hypothesis formation, data skepticism, model choice, and interpretation of results.
Why we could not backtest this on our data
We could not backtest this paper in the usual sense because it is not an asset-pricing claim. It does not propose a signal, a portfolio rule, or a market mechanism with return predictions. The outcome is human skill accumulation, not PnL or forecast error.
Our internal data would also be a poor fit. Coding assistant logs do not cleanly tell us whether a junior delegated the hard part or used the tool for support. Skill growth is slow, reviews are subjective, and assignment difficulty is endogenous. The juniors who get harder tasks are usually the ones managers already trust.
That does not weaken the paper's contribution. It just means the right empirical test would look more like a training experiment than a backtest.
Where the model is too stylized for direct workforce policy
The model is deliberately spare. The student is myopic. The teacher only cares about skill. Tasks vary along one main dimension. AI delegation is cleanly separated from work. Real desks are messier.
Juniors care about reputation, deadlines, compensation, and not looking stuck. Managers care about shipping research, not only training. Tasks are multi-dimensional. A backtest can teach data handling, statistical judgment, software design, and product intuition at the same time. AI use is also hard to classify. A prompt that looks like delegation may be a way to compare approaches. A hand-written script may still be copied from old code without much understanding.
The model also does not say much about teams. In a quant group, learning often comes from code review, post-mortems, shared libraries, and arguments over why a result is not real. Those social mechanisms can either offset delegation or hide it.
Still, the paper gives a clean warning. If we hand juniors coding assistants and measure only completed tickets, we should not be surprised when some of them learn less than expected. The next training review should ask a simple question: which part of this task forced the junior to think before the machine answered?