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, and still consider myself a teacher at heart. Being a teacher and mentor was never separate in my eyes from being a good programmer and engineer; on the contrary, teaching was a tool that helped me become better at my craft at every stage of the journey.
But in the last few years, and accelerating in the last few months, the landscape for teaching and learning has been changing at a scary pace. The advent of LLMs and "AI" coding assistants has drastically shifted how we acquire engineering skills in ways that we are definitely not prepared for.
All of that has prompted many thoughts and conversations, and I hope to distill some of them in this blog post.
In true Talmudic fashion, this post doesn't contain too many answers and will hopefully leave you with more questions than you started with. But asking the questions is how we start these conversations, and these conversations need to be happening if we are to do right by the coming generation of programmers and engineers.
Don't Spoon-Feed Me
As a student, whether in Yeshiva when I used to spend hours each day poring over dense Talmudic legal debates and esoteric Chassidic philosophy or later while learning Rails and React at the Flatiron bootcamp, I quickly realized an uncomfortable truth about skill acquisition.
My best, most profound learning never happened when a lesson went smoothly; it happened when I was painfully stuck, banging my head against a cryptic error message or wrestling with a concept that just wouldn't click (usually at 2 AM, fueled by cold coffee and sheer stubbornness).
When you strip away that struggle, you get rid of the growth. And when you get rid of the growth, the learning just doesn't happen.
Even if you memorize just enough to pass the test, "easy come easy go." Without that cognitive friction, the knowledge evaporates the moment you close your editor.
The best teachers and mentors I ever had understood this intuitively. When I was staring at a broken script knowing there was probably a stupidly easy fix, they didn’t just swoop in and drop the solution onto my screen (much to the vocal frustration of my sleep-deprived brain).
Instead, they wielded tools like the Socratic method. They would point to a specific line of code and start asking gentle, probing questions to expose my flawed assumptions.
They actively leaned into the friction to create just enough cognitive space for me to connect the dots on my own.
They understood a fundamental rule of our teaching craft: that good mentorship is not about getting to the code. The goal wasn't just to get the tests turning green today; it was to build the mental resilience required to debug the next inevitable failure tomorrow.
And it was these skills that I took with. me when it was my turn to become the teacher, whether it was teaching second graders at the Jewish Online School, as a TA at Flatiron, or when mentoring new teammates joining my team.
The Yes-Man in Your IDE
Fast forward to today, and our industry has largely outsourced that initial layer of mentorship to LLMs and coding assistants. And here is the uncomfortable truth: AI makes a terrible Socratic tutor.
If you’ve spent any serious time pairing (or even just chatting) with modern LLMs, you know they are pathological yes-men. Tell an AI you want to architect a distributed microservice mesh for a todo-list app with twelve active users, and it won't push back. It will chime in with "That is a brilliant insight!" and instantly spit out 400 lines of boilerplate.
AI defaults to blind trust. It rarely challenges a mistaken assumption, and when you ask it why a stack trace is blowing up, it immediately serves up a copypastable fix instead of helping you understand the underlying bug.
By acting like an algorithmic vending machine (error_in => fix_out), AI systematically removes all the cognitive friction from the development process.
In our rush for 10x velocity, we forgot a foundational rule of skill acquisition: friction is a feature, not a bug. That was a load-bearing friction we removed!
This isn't just philosophical speculation; there's hard data to back it up. A recent study by Anthropic (or dive into the raw paper here if you love parsing methodology) took 52 software engineers learning an unfamiliar programming library and split them into two groups: one with AI coding assistants, and one coding by hand.
The overall results were as damning as they were not surprising. The engineers who delegated their coding to AI suffered a 17% drop in conceptual mastery and debugging skills (the equivalent of two full letter grades!) often without completing their tasks meaningfully faster than the manual control group.
Why? Because when you offload the cognitive friction of getting painfully stuck, your brain never builds the deep neural pathways required to evaluate whether the generated code is actually any good.
Now, to be fair, there was some nuance in the data: a handful of the AI-assisted engineers actually outperformed the manual control group. But who were they? They were the developers who refused to trust the AI blindly. They treated the LLM like a study partner, asking probing follow-up questions and manually injecting their own friction back into the process.
For everyone else, the automated yes-man just quietly destroyed their understanding.
The Learner’s Dilemma: Manually Injecting Friction
This dynamic leaves junior developers in a massive bind.
Friends and mentees who are earlier in their career have complained that they feel stuck in a frustrating Catch-22:
On one hand, they have to pragmatically accept the reality that AI isn't going anywhere. If an LLM can generate working boilerplate from a single prompt, you can't just stubborn your way out of using it. Ignoring AI entirely feels irresponsible, considering that you will be using these tools heavily in your day-to-day workflows.
But on the other hand, if you rely on that autocomplete blindly, you get trapped in what's known as "superficial learning." You get a quick answer that allows you to pass a test suite or get a PR approved without truly understanding the mechanics under the hood. You miss out on the "deep learning" where the actual, career-sustaining growth happens.
In my experience, that superficiality is a direct pipeline to developer anxiety and impostor syndrome. True professional confidence doesn't come from hitting Tab to accept a prompt; it comes from code ownership and intense intellectual toil and sweat.
To survive this, diligent learners are now being forced to manually inject friction back into their workflows just to keep their brains from turning off.
A junior developer friend of mine has resorted to explicitly prompting their IDE with guardrail instructions like: "I want to learn how to code it myself, rather than copying and pasting, so enable that however you can."
They take notes by hand (yes, actual paper and pen!) and set physical timers just to recreate the safeguards of active listening that a tool designed for instant gratification systematically tries to bypass.
Why We Need the Messy Web of Context
This need for self-imposed struggle makes total sense when you look at Emily Bender and Alex Hanna’s book, The AI Con, which highlights why friction in information access is actually a feature, not a bug.
Think about what happens when you manually hunt down an obscure bug using a search engine.
You read messy documentation, scan through twelve-comment GitHub issue threads (usually ending with a maintainer closing it as "not a bug" in 2014), weigh the credibility of conflicting answers on Stack Overflow, and stumble across related gotchas along the way.
That messy web of meta-information is where real engineering context is built.
An AI chatbot flattens all of that rich, frustrating struggle into a single, authoritative-sounding (and occasionally "hallucinated") summary. It gives you the answer to your immediate problem while robbing your brain of the surrounding ecosystem knowledge required to solve the next one.
The Chavrusa Model: Pair Programming && The Adversarial Rubber Duck
This brings me to an ancient pedagogical model that survives to this day in Yeshivas (Talmudic academies) around the world, and one that software engineering desperately needs right about now.
In a traditional Yeshiva, you rarely see people sitting in silent isolation reading a book or passively listening to a lecture. Instead, the room is loud, energetic, and filled with people arguing fiercely in pairs.
This study partner system is known as a Chavrusa (from the Aramaic word for "friend" or "companion").
When you learn with a Chavrusa, your partner isn't there to read the text to you, nor do they nod along and sycophantically affirm how brilliant your theories are. A real Chavrusa regularly challenges your logic, pokes holes in your arguments, pushees back against shaky assumptions, and generally refuses to let you get away with intellectual laziness.
You don't master the Talmud by reading cliff notes or listening to a brilliant lecture (though there's some of that as well); you master it through Yegiah (a Hebrew term that translates to intense intellectual toil and sweat).
If you think about it (and as I mentioned in my 2021 RailsConf talk), pair programming is just the tech industry's recreation of the Chavrusa.
And here is the most important part of that system: it's not only the junior member of the pair who's learning in a true Chavrusa.
It doesn't matter if you are pairing with a 10-year staff engineer or a junior developer who just finished a bootcamp; the learning is always a two-way street!
When your partner acts as an adversarial rubber duck (one that actually talks back!), they force you to slow down, articulate your hidden assumptions, and defend your code logic from start to finish. Both of you gain from that friction, and both of you walk away with a significantly better mental model than you started with.
Rabbi Ḥama, son of Rabbi Ḥanina, said: What is the meaning of that which is written: “Iron sharpens iron, so a man sharpens the countenance of his friend” (Proverbs 27:17)? This verse comes to tell you that just as with iron blades, one sharpens the other when they are rubbed against each other, so too, when Torah scholars study together, they sharpen one another.
-Ta'anit 7a
In our rush for 10x velocity, we tried to replace human pair programming with AI copilots. But in doing so, we forgot a critical dependency: we exchanged the adversarial Chavrusa and Yegiah for a sycophantic robo-duck.
Empathetic Balancing Act
A common response I hear from the tech crowd is: "Well, let's just fix this with better system prompts! Let's build guardrails that instruct the AI to act like a Socratic tutor instead of just giving away the answer!"
There are plenty of tools attempting this right now, but I am deeply skeptical that technical guardrails can solve a fundamentally human problem.
First of all, relying on a prompt to withhold answers requires elite learner discipline. Some students can stick to it, but that level of willpower is rare, especially when your cognitive battery is hitting empty.
When a junior developer is staring at a cryptic NullPointerException at 2 AM and their brain is fried, a prompt asking them to "reflect on the lifecycle of the object" is getting bypassed immediately. If all it takes is typing /solution or opening a new browser tab to get the dopamine hit of copypastable code, not too many people I know will power through.
More importantly, LLMs are fundamentally architected to please. Even if you prompt-engineer them to be tough Socratic tutors, their core tuning means that the moment a user expresses genuine frustration, the AI folds like a cheap lawn chair and hands over the syntax anyway.
Why? Because an LLM lacks the quality most important in an educator: empathy.
Mentorship is a human pedagogical balancing act. A great mentor understands the fine line between productive struggle and demoralizing suffering. A good educator can read the room. They notice the heavy sighs, the mounting panic, and the sheer exhaustion.
Sure, as a student I learned best when I was given the tools to figure things out on my own. But sometimes I maxed out my energy on the stupid error message, and all of the leading questions my tutors were asking me felt like they were just causing me to circle and circle around the one insight that would make it all work, an insight my brain just couldn't reach.
That is the point a good teacher knows to step back, smile, say "Hey, JavaScript is just weird sometimes," and hand the exact line of code I needed to get unstuck so I could finally go get some sleep.
An algorithm cannot read a learner's emotional state. It cannot dynamically toggle between a challenging sparring partner and a supportive safety net. Code can never replicate that relationship.
The Unsolved Catch-22
So where does this leave us? If I’m being entirely honest, I have way more questions than answers right now (not exactly what you want to hear from a tech blog, I know!).
We are sitting on a massive, industry-wide Catch-22:
On one hand, it would be borderline professional malpractice to forbid junior developers from using AI. It is the modern IDE (which, back when I was learning to code, gatekeepers argued juniors shouldn't use either—I disagreed then and I disagree now). If juniors will be expected to use these tools on the job, it hardly makes sense not to train them to use them effectively.
On the other hand, the engineers getting that massive 10x velocity boost without introducing architecture-destroying bugs are the seniors who spent years writing code without it.
We know when an LLM is spinning its wheels on a false premise because we have a built-in BS-meter, hard-earned through years of manual debugging.
How does someone without that pre-AI experience build that intuition today? They won't get it from a sycophantic yes-man chat-bot assistant. And manually inventing your own cognitive friction requires a level of self-discipline that is hard to maintain on a tight deadline.
Maybe the future of onboarding relies on doubling down on human pair programming—having juniors shadow seniors for months on end to soak up that pre-AI intuition by proxy. After all, pair programming has always been one of the best onboarding methods, even before Claude. But not all companies are interested in the investment that full-time pairing requires in an industry often obsessed with shipping yesterday.
What I do know is that we cannot afford to ignore the problem or assume that better LLM models will magically fix our talent pipeline.
If we just hand junior developers an oracle and fail to preserve the empathetic, rigorous struggle of the Chavrusa, we are going to wake up in a few years to a terrifying system error: an industry with a massive, AI-generated codebase to maintain, and not enough senior engineers left who know how to maintain it.
What are you and your teams doing to keep productive friction alive? I'd love to hear your thoughts.
Top comments (43)
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.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.