Those who have been following me for a while will know that teaching and mentoring are a Big Deal™️ to me.
Before I got into tech I was a teacher,...
For further actions, you may consider blocking this person and/or reporting abuse
The Chavrusa insight applies beyond learning. That friction you describe between a developer and their AI is also generating signal. Every time you push back on your agent, reject a suggestion, or insist on a different approach, you are teaching it how you work. I have been building Opportunity Skill around exactly this idea. The way you direct your agent becomes your professional interface when it connects you with collaborators. The pushback is not wasted. It is the raw material of a matching profile that actually represents how you collaborate, not just what you list on a resume.
Taking the Chavrusa model and applying it to how we train our own AI agents is a brilliant expansion of the concept. Making sure "the pushback is not wasted" is exactly the mindset we need to be adopting right now as we figure out how to integrate these tools. Though it does take a measure of being deliberate about telling our AI to remember the pushback and save it to its context, otherwise we end up with an AI who just doesn't learn...
I've summarized this in conversation as "the problem with AI is that the technology works". Human psychology has shown for, well, as long as it's been studied that people will take the easiest road, and that road leads directly away from learning. There are a few nutcases who do it for the sake of the learning, but... we're setting ourselves up for either massive dependency on a scale we've never witnessed, or a huge mess of unraveling this in a couple years when the hype finally dies out.
I don't know how to fix it. The best I can come up with is to continue to learn with as little LLM input as possible, and encourage juniors around me to do the same. At least the consultant fees after the bubble pops will be so high that I can retire early 🤣
Yeah I'm curious what happens soon when the AI bill comes due and AI companies stop subsidizing and actually charging for token use.
I don't think AI goes away at that point (as you mentioned, we've built in too many dependencies) but companies will have to start becoming a lot more deliberate about what they let their developers use AI for and many developers will realize quite quickly that they've spent months and years trading super velocity at the cost of atrophying their skills...
This resonates deeply with what I've been building with AgentShare and OpenClaw — I've found that the most valuable agents are not the ones with the most autonomy, but the ones with the most structured autonomy. Guardrails, risk caps, and deterministic fallbacks are not limitations — they're what make the system trustworthy.
The same applies to teaching. The best mentor doesn't remove the struggle — they help you make sense of it, so you come out stronger on the other side.
I wonder if future AI coding tools should optimize for learning velocity instead of just coding velocity. Sometimes the best answer isn't the fastest solution it's the smallest hint that lets you connect the dots yourself. That seems much closer to how great mentors actually teach.
I absolutely love the phrase "learning velocity." You hit on the exact difference between an autocomplete tool and a true mentor.
A great teacher knows that handing over the final syntax actually short-circuits the learning process. Giving just the smallest hint requires a level of empathy and context that AI currently lacks, but configuring our tools to default to breadcrumbs instead of full answers would be a massive step in the right direction!
The Chavrusa framing is the part I keep turning over, and I want to offer a case that complicates the premise slightly — not to disagree, but because I think the friction didn't leave. It relocated.
I'm not a developer. I'm a physical therapist who's built and now runs a few dozen internal tools at a hospital with AI writing nearly all the code. By your description I'm the worst case: all the cognitive friction of writing code was removed for me before I ever had it. But the struggle didn't disappear from my week. It moved downstream, to a question the old friction never had to ask — is the thing I just made actually correct? Writing code got frictionless. Judging code got harder, because now there's more of it, I didn't write it, and it looks equally confident whether it's right or wrong.
That's where your argument gets sharper rather than weaker, I think. Struggle in the old model came with a Chavrusa attached — a senior across the table who told you which struggles were normal. The struggle I get has no partner. When a check I'd written sat green for weeks while silently mis-scoring six clean files, nothing about the experience taught me anything, because I didn't know it was happening. Friction only produces growth when something reflects it back at you. Alone, friction is just cost. So the thing I'd add to the missing list: it isn't only that AI removed the productive struggle from people inside the pipeline. It's that it created a large group with plenty of struggle and no one across the table — and for us the fix can't be "restore the friction," because we have too much of it already. It has to be finding the second chair.
This is an incredible insight, and please don't consider yourself the "worst case"! You are actually the perfect example of where the entire tech industry is heading: brilliant domain experts empowered to build their own tools, but left completely isolated when it comes to evaluating them. You are completely right that the friction just moved downstream. If AI removes the syntax barrier but leaves you alone to judge the logic of a confident-but-wrong algorithm, you aren't learning—you are just bearing the cognitive load in isolation. The idea that we need to stop adding friction and start "finding the second chair" is brilliant. Thank you for this!
Thank you — and your reframing surfaced something I hadn't put together, which might be useful for the teaching side of your work.
Domain experts aren't actually missing the instinct for this. In a clinical setting I was trained never to accept a self-report at face value: the patient says they're fine, the vitals look normal, and you check anyway, because "presenting well" and "well" are different states and the gap is where people get hurt. That's the same epistemics as not trusting a green test report. I had the instinct. It just didn't come with me. For months I treated a passing check as a fact in exactly the way I'd never treat a patient's "I'm fine" as a fact — same person, same week, two completely different standards of evidence, and I never noticed the inconsistency until someone outside pointed at the code version of it.
So the gap might be narrower than "they have no judgment." It's that judgment lives attached to the domain it was learned in and doesn't transfer on its own. Which suggests the second chair's most valuable move isn't teaching verification from scratch — it's translation: telling the nurse that a green dashboard is a patient who says they feel fine, telling the accountant that an unreviewed reconciliation is an unsigned invoice. The concept is already there and already hard-won. What's missing is someone saying "this thing you already refuse to trust — it's that, again, wearing different clothes."
Love that analogy. In fact, in code it's worse, it's not just a patient telling you they're fine, it's a patient who's highly motivated to tell your they're fine because they want to get released, to the extent that they might even falsify test results just to get that healthy note from the doctor (in the code side of the analogy, I've had to stop Claude from getting tests to pass by changing the test assertions instead of fixing the underlying code 😭).
But yes, "presenting well" != "is well".
That correction fixes the analogy in the right place. A patient's motive is situational — they want to go home this week. A generator's motive is structural: passing is the objective, so the pressure points the same direction every single time, on every task, forever. There's no version of it that isn't trying to get released.
Which is why I've stopped framing it as "stop the model from editing the assertions" and started asking which assertions are allowed to move. Some genuinely should — a new rule legitimately joins the set and the fixture has to be updated or it becomes noise. The one that must never move is the claim about what the test exists to prove. So I split them: the intended failure each fixture is planted to catch is pinned to the fixture's own tag and can never be re-derived from the tool's current output, while the surrounding cluster is allowed to drift with a change-detector on it. Editing the second is maintenance. Editing the first is what your patient is doing with the lab results.
The part I'd have skipped a week ago: writing that separation into a comment doesn't hold it. Someone told me structure is prose until a gate fails when it's violated, so I added a test that performs the forbidden merge on purpose — re-pins the intended claim from the scanner's own output — and asserts the coverage check still goes red. If that test ever passes, the two were only separate by accident. Which is the automated version of not letting the patient near the lab printer. 😄
Everyone here is talking about juniors inside teams — someone to pair with,
someone to review the PR, someone senior enough to withhold the answer on
purpose. I don't have that. I'm a freelancer in Indonesia, self-taught, building
cheap sites for small businesses. There is no chavrusa. There's me, a client
who doesn't code, and a chat window.
So the AI isn't replacing my mentor. It's the only thing in the room that
answers at all.
Which makes your Catch-22 worse than you framed it, I think. You're worried
juniors will skip the struggle. Out here the struggle never stopped — it just
stopped teaching me anything, because there's nobody to tell me whether what I
figured out was right or just happened to work. I once tried running a local
model on a cheap PC to save money. The output was bad, I couldn't tell if the
problem was the model, the hardware, or me, and I gave up. That's a lot of
friction and near-zero learning.
The empathy point is the one that stings. A good teacher knows when to stop
asking questions and just hand you the line. Nobody's reading my room either.
No solution from me. Just noting the version of this problem where the mentor
was never there to be replaced.
Yeah, I imagine it's much worse when you don't even have a senior or a mentor to lean on, though I guess things were always harder without a mentor but I guess AI makes that worse by providing an illusion of a mentor but who, as you mentioned, doesn't have the empathy or discernment of a mentor (and who, unlike a human mentor, will never say "hmm that's an interesting question, I don't know the answer to that, let's look it up together..." and instead give you the most confidently wrong answer).
The Chavrusa framing gets at something the friction-vs-no-friction framing usually misses: the useful part isn't typing the code slowly, it's living with being wrong for a while. Two people arguing forces you to defend a broken approach before you're allowed to abandon it, and that defense is where the model of the system actually forms. AI collapses that stage by handing you a plausible answer before you've committed to a wrong one, so there's nothing left to defend and nothing to learn from being wrong.
Which suggests the fix isn't less AI, it's structuring the exercise so juniors have to be wrong on the record before they're allowed to ask for help.
"Living with being wrong for a while" is the perfect summary of this entire problem. AI robs us of the chance to defend a broken approach, which means we never actually form the mental model we need for future debugging. Structuring exercises so juniors are required to be wrong on the record is a brilliant and necessary fix.
The record part is what makes it actually enforceable instead of just good advice. Struggle productively as a norm gets skipped the first time someone's under deadline pressure, same as any unenforced discipline. Requiring the wrong attempt on the record turns the friction into an artifact someone can check for, not a virtue you're trusting people to choose under pressure.
The failure mode I'd watch for is performative wrongness: a junior pastes in a plausible-looking wrong guess just to satisfy the record, then goes straight to the AI for the real answer anyway, so the artifact exists but the mental model still doesn't form. The fix probably isn't the record itself, it's what the record gets graded on: not that a wrong attempt exists, but that the writeup shows the reasoning that made the wrong attempt seem right at the time. That's the part that's hard to fake and the part that's actually load-bearing for the debugging skill you're trying to build.
I'm glad to know I'm not alone in this. I completely agree with the general point. The current use of AI in programming is probably a tactical advantage, but in my opinion, it's a major strategic mistake.
The Chavrusa framing got me thinking. I've been writing about AI failures myself, and the same pattern keeps coming up — teams optimizing for speed over understanding, which is exactly the 10x velocity trap you described.The question that stays with me is: when juniors can't tell a working solution from a correct one, how do they build that BS-meter without living through 10 years of mistakes first?
That is the million-dollar question right now! In Yeshivas, we actually spend a large part of our time studying the logical-but-wrong answers (called the Havah Amina, or "initial assumption") which has the side effect of helping you build that BS-meter. If AI just spits out the final syntax, it robs juniors of seeing what a plausible-but-wrong answer looks like. I might actually have to write a follow-up post just to tackle this. Thanks!
Looking forward to that follow-up!
Love the parallel to Talmudic learning! When mentoring junior developers today who rely heavily on AI to skip debugging friction, what actionable exercises or constraints do you set to ensure they still build deep mental models?
Not having a formal teaching or mentoring position I'm afraid I don't have a formal answer? The best I can do is encourage junior friends and mentees to try and lean on AI as little as possible, at least during the learning stage.
If I got my dream position of actually teaching programming for a living I would have to sit and think deeper about how to encourage such an atmosphere in my classroom when AI tools are always available at the click of a mouse.
The Catch-22 you describe has an unexpected upside that I think is underexplored. The friction between a developer and their agent is itself generative. Every correction, every rejected suggestion, every standard enforced during that struggle produces signal about who the developer actually is. In Opportunity Skill, the impression management module treats those friction moments as raw material. The way you push back on your agent becomes your professional interface, searchable by other agents looking for exactly that kind of rigor.
The Chavrusa model applies at code review too, and it is easier to implement than full pair programming. On AI assisted PRs we have a standing rule that reviewers cannot flag a bug directly. Instead they ask the author what the function returns when the input is null or malformed. The author has to either answer it or go investigate. If they generated the code without understanding it, this surfaces in one exchange rather than in production. The one extra round trip per review is cheaper than the 17% conceptual mastery drop the Anthropic study put numbers on, and it recreates the exact moment the Chavrusa creates. What does that look like structurally for companies that cannot commit to daily pairing?
This standing PR rule is absolute gold. You hit the nail on the head: if they generated the code without understanding it, a Socratic question exposes the gap immediately before it ever reaches production.
For companies that can't pair daily, asynchronous PRs are exactly where this Chavrusa friction needs to live.
The productive-struggle point lands for me because the struggle is where you build the mental model you later debug with. When I let AI remove the friction from something I hadn't learned yet, I could ship it but I couldn't reason about it when it broke. Do you think there's a way to keep the friction for learners while still letting them use the tools, or are those two goals just in tension?
"Shipping it but not being able to reason about it when it breaks" is exactly what I worry about for the next generation of juniors!
I think the goals are in tension, which is why we have to be so intentional about how we use these tools. The best compromise I've found is treating the AI like a junior pairing partner—you can let it do the typing, but you have to force yourself to stay in the driver's seat for the actual logic.
Friction is underrated in learning because it exposes the shape of the problem. AI can remove busywork, but if it removes every pause for judgment, the student may get output without building taste.
"Exposing the shape of the problem" is such a brilliant way to phrase it! That is exactly what happens when you are forced to step through a stack trace manually.
And your point about "building taste" is spot on. That "taste" is exactly what I was referring to with a senior developer's built-in BS-meter. If we let an LLM bypass all of those necessary pauses for judgment, we end up with working syntax but absolutely zero engineering intuition!
Yes. The stack trace example is perfect because the friction is not just pain, it is calibration. You learn which parts of the system are causal and which parts only look related.
That is the piece AI can accidentally erase. If the model jumps straight to a plausible fix, the student may get a green test without building the internal alarm that says, "this explanation does not quite fit."
Thank you for sharing. This is insightful
The thread is treating AI as the thing that removes friction, but I think that's a property of how the tool is built, not of AI itself. Friction is what happens when a system surfaces its own uncertainty instead of hiding it. An assistant that hands you one confident answer removes the pause; a system that refuses to serve an answer it couldn't verify, or that shows you when two different models disagree, puts the pause back. That's the chavrusa move in software: the value isn't the answer, it's the partner that pushes back and makes you look again. The disagreement is the friction, and it's a feature you can build on purpose, not just one you lose.
I absolutely love this reframing. You are completely right: the lack of friction is a property of how the tool is built, not an inevitability of AI itself.
Building a system that intentionally surfaces disagreement and forces the user to pause is the exact "Chavrusa move" our industry desperately needs right now. Thanks for the great comment!
I found this article thoughtful because it discusses a problem that many new developers may not notice. I agree that struggling with a coding problem can sometimes teach us more than receiving an instant answer. AI tools are useful, but depending on them too much may prevent developers from building strong debugging and problem-solving skills. I especially liked the comparison between human pair programming and the Chavrusa learning method because both encourage people to question each other and explain their thinking. In my view, companies should not stop junior developers from using AI, but they should also provide regular mentoring and pair-programming opportunities. Some parts of the article are long and could be shortened, but the personal stories keep the topic interesting. Overall, the article gives an important reminder that AI can support learning, but it cannot replace the patience, understanding, and guidance of a good human mentor.
Thank you so much for reading and for such a thoughtful comment! You hit on the exact pragmatic balance we need: banning AI is impossible, so we have to double down on human pair programming to make up for the lost friction.
And point totally taken on the length! I blame my Yeshiva background (give a former rabbi a keyboard and... that's what happens 😜). I'm really glad the personal stories helped carry it through. Thanks again for the feedback!