Don't outsource the struggle
Be a driver, not a passenger.
The worst way to use AI is to ask it to do the work.
The problem isn’t because the output will be bad. Increasingly it’s pretty good, and that’s the problem.
If the output was obviously broken, then you’d notice, fix it and learn something along the way. But if it’s good enough, then you haven’t learned a thing.
Desirable Difficulties
In the 1990s, Robert Bjork ran a series of studies that upended how psychologists thought about practice. He found that the conditions that feel most productive (easy repetition, fluent recall) often produce the weakest retention. Difficulty was not the enemy of learning. Certain kinds of difficulty were the mechanism, and he called them desirable difficulties.
Difficulty that forces retrieval or that makes you generate an answer before seeing it is desirable difficulty and builds durable knowledge. Difficulty that comes from unclear instructions or a wasted search? That’s just a waste of time.
Which kind of difficulty does AI remove?
Friction
I’ve written before about friction. There are different types of friction - which of them are desirable difficulties.
Mechanical friction
This is the boring tedious stuff. Remembering the syntax for initializing a multi-dimensional array that you rarely use. Remembering the API incantation. The glue code that needs to be written. None of these things really teach you anything new1.
This isn’t a desirable difficulty. Let the LLM do the boring work.
Navigational friction
Finding your way around a codebase can be a pain in the ass. A modern IDE will allow you to navigate to the interface easily, but then you’ll hop through implementations until you find the right one, then step back and go into the dependency injection mush to ensure you’ve found the right file and eventually you’ll find that one example to know how the pattern works.
This one is a desirable difficulty. Once you understand how the system is wired you’ve got fantastic context for the codebase.
Use the LLM as a guide. Don’t just let the LLM go and make the edits, ask it to give you context. For example, “help me trace where this behaviour lives. Show me the files involved and explain the flow before we change the code”.
Comprehension friction
Understanding what the code does is the core job of software engineering.
This is where learning starts. If you skip it, you get familiarity with the output without understanding of the system. That is the engineering equivalent of being able to recite a proof without knowing why any of the step’s work.
Failing to do this, will leave you becoming a cargo-cult engineer.
Don’t outsource the comprehension struggle.
Use the LLM to validate this understanding. For example, give the LLM your own understanding and have it critiqued. Or even ask for the LLM to quiz you on a particular question (“Test my knowledge of the Foo subsystem by asking me questions”).
Design friction
Choosing an approach. Rejecting the alternatives. Seeing trade-offs. Noticing what each option makes harder three months from now.
Amplify this. This is the biggest learning opportunity. And if you skip it, well see Nineteen Features, Zero Architecture!
You need trade-offs here. Don’t ask the LLM to just produce a design. Instead ask for multiple designs and work through the trade-offs yourself. For each, understand what it makes easier or harder and most importantly make a choice yourself!
Verification friction
Code has been written, but does it work? There are two questions here. Does the code do what it’s supposed to do? And does what it’s supposed to do match what stakeholders actually need?
An LLM can help with the first. It can stress-test your assumptions and prove behaviour with unit tests. The trap: if the LLM writes the code and writes the tests, you’ve automated both sides of the verification loop. Bainbridge flagged this already: humans who only supervise automation lose the very skills they need when the automation eventually fails.
An LLM can’t help with the second. You need a mental model not just of the architecture, but of the why. Software is about solving problems for people. Don’t outsource that.
Articulation friction
Writing the PR description. Explaining your reasoning. Naming what you are not sure about.
This is how private thinking becomes visible. The act of articulation is part of the work. Offloading it entirely means you never find out whether your understanding is as solid as you assumed.
Use the LLM to sharpen your thinking, not to do it for you.
Accountability friction
If you’re using an LLM you must own the result and be able to defend it. AI must never be used to remove this friction.
If you are responding to PR comments automatically with AI, then you need to own what it says.
Accountability is the ultimate desirable difficulty!
The implementation-monkey failure mode
There is a version of AI-assisted engineering that feels like productivity but produces no learning.
The engineer receives a ticket. They paste it into a chat window. They accept the diff. They patch the errors the linter finds. They ship the code. The ticket closes. Win!?
However, in this version the engineer is just a passenger for the journey. They haven’t built any additional capability and won’t grow as an engineer2.
Driver vs. Passenger
I believe there are two different approaches to using AI.
In the passenger mode, you give the AI tasks, and it gives you artifacts. In this model, the AI is doing all the work, and you’re just hitching along.
In the driver mode, you use AI to understand the terrain, generate options and test your assumptions. In driver mode, you are controlling the shape of the work, and you’re using AI to compress the parts that do not build judgement and amplifying the bits that do.
Be a driver!
What this means for organisations
It’s a system! Banning AI or policing prompts won’t produce the right results. You’ve got to make the journey mode visible and make the passenger mode uncomfortable.
What might that look like?
Plans before implementation - ask an engineer to explain what they are building before they build it.
PR checklists should include options - make sure that significant pieces of work have the trade-offs behind choices laid out and explained.
What did you learn - PR reviews don’t have to be solely about correctness; the mentorship aspect is also important (Thoughtworks described reviews as the bundling of mentorship, consistency, correctness and trust).
Prompt examples in team documentation - Show the difference between prompts that directly produce artifacts versus those that produce understanding.
Conclusion
The goal is not to make work frictionless.
The goal is to remove the friction that wastes attention and preserve the friction that builds judgement. Bjork’s desirable difficulties are still desirable. The undesirable ones are still worth eliminating. The job is to know the difference.
Use AI, but be a driver, not a passenger.
I used to think it was useful to know all this kind of syntax, but since it’s now easily lookup-able, I don’t think there’s much value in it.
I suppose they will be super good at LLM usage though!