It's funny. We do a podcast about weird prompts, and somehow we keep ending up back at AI coding. But the tools keep changing what "weird" means, so here we are.
And this one's not the usual "will AI replace us" panic. Daniel's got something more specific.
He does. So Daniel's been watching his own Python skills and he's feeling the slippage. Every Claude release is a genuine step forward — not hype, not a benchmark trick — and he's crossed the trust threshold where he supervises more than he codes. That's the first thing. The second is he's watching people enter the field who have never written a line from scratch. Pilots spend years hand-flying before they touch an autopilot. These new developers start on autopilot. And then there's the personal question — TypeScript. He started using Claude for it, never learned the fundamentals, and now he's wondering whether you can work backwards from AI-generated code to real understanding. So he's asking: how do you maintain manual coding fluency when the tools are this good, and how do you learn to fly when you've only ever used the autopilot?
That TypeScript part is the one that gets me. I've been there with matplotlib — I Google the same five function signatures every single time, and if Claude disappeared tomorrow I'd be in trouble for about a week and then I'd be fine. But Daniel's describing something deeper. He never had the signatures to forget.
So let's start by being precise about what Daniel is actually worried about, because it's not what most people think. This isn't the "AI will replace developers" conversation. He's not worried about his job. He's worried about his mind.
And that's the distinction that makes this worth an episode. The usual automation anxiety is about external replacement — the machine does your work, you get fired. Daniel's describing internal atrophy. The machine does your work, you stay employed, and your brain slowly unlearns things you used to know. That's a harder problem to see coming, and a harder one to fix.
Because nobody notices until you need it. You don't feel the loss day to day. You feel it the moment Claude goes down, or gives you something subtly wrong, and you realize you can't spot the error because you haven't exercised that muscle in six months.
And there's a second layer he's pointing at that I think is new. The beginner who starts on autopilot. That's not atrophy — you can't atrophy what you never had. It's something else. It's building a career on a foundation of generated code and hoping the foundation holds.
The core tension here is simple and uncomfortable. Agentic AI tools — Claude Code, Cursor, Copilot — are improving so fast that the optimal strategy for productivity is to delegate more. But the optimal strategy for skill retention is to do it yourself. Those two things are in direct conflict, and the gap between them is widening with every release.
And Daniel's specific situation matters for understanding why this isn't one-size-fits-all. He's an experienced developer feeling his existing skills slip. That's a different problem from the newcomer who never had skills to lose. Both groups exist right now, simultaneously, and they need different things.
The experienced developer needs deliberate practice — structured, intentional manual coding to keep the neural pathways from pruning. The newcomer needs something more fundamental. They need to build the pathways in the first place, while using the very tools that make building them seem unnecessary.
I think the aviation analogy Daniel reached for is exactly the right lens. To understand why this is different from previous automation fears, we need to look at what pilots actually do.
So the FAA has a rule. Three landings in ninety days. That's the regulatory floor — if you haven't performed at least three takeoffs and landings in the preceding ninety days, you cannot act as pilot in command while carrying passengers. That's not a suggestion. That's the government acknowledging that manual flying skills decay on a measurable timeline.
And what's important is the context around that rule. The pilots subject to it already have hundreds, usually thousands of hours of manual flight time before they ever engaged an autopilot. They built a thick base. The three-landings rule is maintenance, not construction. It's acknowledging that even a thick base erodes.
The FAA's own data shows pilots aren't hand-flying enough to stay sharp. Airlines encourage maximum autopilot usage for fuel efficiency — the autopilot flies more precisely, burns less fuel, and reduces wear on the aircraft. So you have commercial pilots who might hand-fly for two minutes on takeoff and two minutes on landing, and everything in between is automation. Over a long-haul career, that adds up to remarkably little manual time.
And there have been incidents. The Air France 447 crash in 2009 — the autopilot disconnected due to iced-over pitot tubes, the aircraft reverted to manual control at high altitude, and the pilots, who had thousands of hours of experience, couldn't recognize and recover from a basic aerodynamic stall. They held the nose up for nearly four minutes while the stall warning blared. The automation had handled high-altitude flight for so long that their manual stall recovery instincts had degraded.
That's the nightmare version of what Daniel's describing. The moment the tool fails in a way that requires deep understanding, and the understanding isn't there anymore.
But here's where Daniel's analogy gets more interesting — and more uncomfortable. The Air France pilots had manual training. It degraded. Daniel's second group, the newcomers starting on autopilot, never had it. That's structurally unprecedented in aviation. You cannot become a commercial pilot without hundreds of hours of manual flight. Nobody gets a type rating by watching the autopilot fly.
And in programming, there's no FAA. There's no regulatory body saying you must write a thousand lines of Python from scratch before you're allowed to use Copilot. The market doesn't require it. The employers don't require it. The tools actively discourage it by getting better every quarter.
The 2025 Stack Overflow Developer Survey put some numbers on this. Sixty-two percent of professional developers now use AI tools daily. But only twenty-eight percent reported understanding the generated code completely. That gap — between use and comprehension — is the thin base Daniel's talking about. And it's widening with each tool release because each release generates more complex, more abstracted code that's harder to fully understand.
Sixty-two percent using, twenty-eight percent understanding. That means roughly half the people using these tools daily are regularly shipping code they don't fully grasp. That's not a moral failing. It's the rational response to tools that work well enough. But it's also a structural vulnerability.
And the Claude-specific timeline makes this acceleration concrete. Claude 3.5 Sonnet shipped in June 2024. Claude 4 arrived late 2024. Claude 4.5 early 2025. Claude 5 is rumored for late 2025. That's roughly eighteen months of jumps where each step was meaningfully better at code generation — not just benchmark scores, but the real experience of trusting the output enough to not double-check every line.
Daniel said he's past the trust threshold. That's a real psychological shift. When you first use these tools, you verify everything. Then you verify most things. Then you verify the tricky parts. Then you verify when something looks off. Each step is rational — the tool earns your trust — but each step also reduces the number of times you engage deeply with the code.
And that's where the thin base becomes dangerous. An experienced developer who stops verifying still has a mental model of what correct code looks like. They might miss a subtle bug, but they won't miss a fundamental architectural error. A developer who never built that mental model — they don't know what they don't know. The code compiles, the tests pass, it ships. The failure mode is silent.
The thing about a thin base is you don't feel thin. The tool fills in the gaps so seamlessly that you feel competent. You're shipping features. You're getting promoted. The external signals all say you're doing great. The internal structure is the thing that's hollow, and nobody sees it until it collapses.
There's a parallel in medicine, actually. When I was practicing, we had a saying about diagnostic skills and technology. The CT scan is incredible — it shows you things you could never palpate or auscultate. But the physicians who trained after CT scans became ubiquitous had worse physical exam skills. They'd order the scan before they'd really examined the patient. Most of the time, that was fine. The scan was better than their hands anyway. But occasionally, the scan was unavailable, or the scan was misleading, and the physician who couldn't do a thorough physical exam missed something the old-timers would have caught.
Same structure. The tool is better than the manual skill in most cases. The rational choice is to use the tool. But the tool's availability isn't guaranteed, and its output isn't infallible, and the manual skill is what catches the edge cases.
So if the problem is structural — a thin base that never gets thicker — the question becomes: can you build that base backwards?
That's the TypeScript question. Daniel started using Claude for TypeScript before he learned the language. He's been generating complex type definitions, generic interfaces, conditional types — all the hard parts of TypeScript — without ever having written a basic function from scratch. Can you work backwards from that to real understanding?
I think you can, but it requires a deliberate strategy that almost nobody is teaching. The natural instinct is to just keep generating code and hope you absorb it through exposure. That doesn't work. The Stanford Center for Educational Computing published a study earlier this year that looked at exactly this. Learners who used AI to generate code and then just moved on retained very little conceptual knowledge. But learners who used AI to generate code and then spent equal time having the AI explain and modify that code — they retained about forty percent more.
Forty percent more conceptual knowledge. The key was what they're calling the explanation loop. Not just reading the generated code, but interrogating it.
And the protocol is surprisingly simple. After Claude generates a block of TypeScript, you ask it to explain every line as if you're a beginner. Not a summary — line by line. Then you ask it to remove one key concept — say, generics — and show you what breaks. Then you ask it to quiz you on why the original approach was correct. You're turning the AI from a code generator into a Socratic tutor.
The "remove one concept and show me what breaks" step is the one I think does the most work. It forces you to understand what each piece is doing. If you remove generics and the code still works, you learn that the generics were decorative in that case. If removing them causes a type error three files away, you learn something about how TypeScript's type system propagates. Either way, you're building the mental model.
For TypeScript specifically, the type system is the hardest part to learn from scratch. Claude can generate complex generic types that would take a manual learner months to understand — conditional types, template literal types, mapped types with key remapping. The stuff that makes experienced TypeScript developers reach for the documentation.
So here's a concrete technique. Have Claude generate a type definition — something complex, the kind of thing you'd actually use in a real codebase. Then cover the screen. Manually rewrite the type from memory. Then compare. Where did you diverge? Why did Claude choose that approach? What constraint were you missing?
That's the coding equivalent of what instrument flight instructors call partial panel training. You cover up the primary instruments and force the pilot to fly using only the backup instruments. It's disorienting and frustrating and it builds a kind of understanding that normal flight never does.
The "cover the instrument panel" technique. You're forcing your brain to reconstruct the logic rather than recognize it. Recognition and reconstruction use different neural pathways. Recognition feels like understanding, but it's shallower. Reconstruction is where the learning actually happens.
This connects back to Daniel's Python atrophy problem, which is a different thing. For Python, he had the skills and they're fading. The solution there isn't the explanation loop — he already understands the concepts. What he needs is deliberate manual practice on small, meaningless problems.
Codewars katas, Advent of Code, personal projects done entirely without AI. The key is that the problems have to be small enough that the AI isn't tempting. If you're building a production feature and the AI can do it in thirty seconds, you're going to use the AI. That's rational. But if you're solving a five-line string manipulation puzzle, there's no productivity argument for delegating it.
I think the most dangerous thing here isn't the AI itself. It's the loss of productive friction. Debugging is where most real learning happens in programming. You write code, it doesn't work, you figure out why, and in the process you build a mental model of the system that's far richer than what you'd get from working code. When the AI generates working code on the first try, you skip the debugging step entirely. You get the solution without the struggle, and the struggle was the point.
The struggle was the point. That's exactly it. The frustration of a bug you can't find, the hour spent tracing through stack traces, the moment where you finally understand what's happening — that's not an unfortunate side effect of programming. That's how the learning happens. The AI removes the friction and, in doing so, removes the mechanism by which expertise develops.
There's a meta-skill here that I think is the real thing to cultivate. Experienced developers develop a kind of spidey sense for when generated code looks wrong. It's not always articulable — you look at a block of code and something feels off. The variable naming is inconsistent, or the control flow has an unusual shape, or the error handling is in the wrong place. You can't always say exactly what's wrong, but you know to look closer.
That spidey sense comes from having written thousands of lines of code manually. You've internalized the patterns. You know what correct code looks like because you've produced it and debugged it and fixed it. The developer who has only ever generated code never develops that sense. They don't know what "off" looks like because they've never spent enough time with "on."
The skill to cultivate isn't just writing code. It's reading code critically. And reading code critically requires understanding what correct code looks like, which requires having written it. It's circular, but the circle is real.
Which brings us to the practical question. If you're Daniel, or someone in Daniel's position, what do you actually do? I think there are three distinct strategies for three distinct situations.
Let's hear them.
First, for the experienced developer feeling atrophy — Daniel and Python. The fix is deliberate manual practice on problems where the AI isn't the rational choice. Small, constrained, meaningless problems. The goal isn't the solution. The goal is keeping the neural pathways from pruning. Fifteen minutes a day is probably enough. The FAA only requires three landings in ninety days, and that's a minimum — but it's not nothing.
Second, for the developer learning a new language through AI — Daniel and TypeScript. The fix is the explanation loop. Generate, then interrogate. Ask the AI to teach you what it just did. Remove concepts and see what breaks. Rewrite from memory. Turn the black box into a tutor. The AI is good at explaining code if you ask it to. Most people just never ask.
Third, for the newcomer who started on autopilot. This is the hardest case, because they don't know what they don't know. The fix is probably structured curriculum done manually, alongside the AI work. Not instead of it — the AI is too useful to abandon — but as a parallel track. Learn the fundamentals the old-fashioned way while continuing to use the tools for productivity. It's less efficient in the short term. It's insurance in the long term.
The parallel track idea is important. You don't have to choose between productivity and learning. You just have to recognize that they're different activities with different goals, and allocate time to both. Most developers are allocating a hundred percent of their coding time to productivity and zero percent to deliberate skill development. That's the imbalance.
The market won't fix this. The market rewards productivity. It doesn't reward deep understanding until the moment deep understanding is urgently needed, and by then it's too late. This is a problem each developer has to solve for themselves, on their own time, against the incentives of their employer and their tools.
That's the part I find unsettling. The incentives all point toward atrophy. Use the AI more, ship faster, get promoted. The costs of atrophy are deferred and invisible until they're catastrophic. It's a classic short-term versus long-term tradeoff, except the long-term cost might be your ability to do the job at all without the tool.
I keep thinking about what happens in five years. If the optimal path to productivity and the optimal path to skill development keep diverging, what does the developer who optimized purely for productivity look like? Can they still debug a production incident when Claude is down? Can they evaluate a candidate during a hiring interview without the AI whispering in their ear? Can they even read code anymore, or have they become pure prompt engineers?
Prompt engineer is a real job title now, and I don't mean that dismissively. But it's a different job than software engineer. A prompt engineer specifies intent and evaluates output. A software engineer understands the system that produces the output. Those are overlapping but distinct skill sets, and the industry is pretending they're the same thing.
They're not. And the pretense is going to get harder to maintain as the tools get better. Claude 5, whenever it arrives, will be better than Claude 4.5. The trust threshold will keep rising. The need for manual intervention will keep falling. The window for "learning by doing" will keep shrinking.
The uncomfortable question Daniel's really asking is: if the tools are this good, and getting better, is manual coding fluency even worth maintaining? Or is it like knowing how to navigate by the stars — beautiful, impressive, and completely unnecessary for getting where you're going?
I don't think we're there yet. But the trajectory points that way. And the people who maintain fluency may become a niche — like manual transmission drivers or analog photographers. Not extinct, but not the default. The difference is that manual transmission drivers aren't responsible for systems that can fail catastrophically when the automation disengages.
Hilbert: Nineteen ninety-eight. I was teaching instrument rating at a flight school in Salina, Kansas. Little place, two Cessnas, a beat-up simulator that smelled like old coffee. My specialty was partial panel — you cover the attitude indicator and the heading indicator, leave them with nothing but airspeed, altimeter, vertical speed, and the turn coordinator. Most students panic for about ten minutes and then their scan adjusts.
Hilbert: Everyone talks about the three landings in ninety days rule, but the real problem isn't the landings. It's the cross-check. When you're flying instruments, you're constantly scanning six instruments in a pattern — attitude, altitude, airspeed, heading, vertical speed, turn coordinator — and you loop through them every few seconds. If you stop doing it for two weeks, your scan degrades. Your eyes start fixating on one instrument. You stare at the attitude indicator while your airspeed bleeds off and you don't notice until the stall warning goes off.
Hilbert: That's exactly what I see happening with developers and AI. They stop scanning the code. They fixate on the output. The AI gives them something that looks right, and they stop checking the other instruments. The type checker, the runtime behavior, the edge cases. Their scan pattern atrophies.
Hilbert: I failed a student in ninety-eight. Kid could fly the plane perfectly under the hood — simulated instrument conditions, zero visibility, smooth as anything. Two hundred hours of instrument time. But he had twelve hours of visual flight. Twelve. He couldn't land the plane without the autopilot. He'd line up on final, disconnect the automation, and the plane would wander all over the sky. He had no feel for it. No intuition for what the aircraft was doing when the computers let go.
Hilbert: That's your TypeScript developer. They can generate conditional mapped types with template literal inference. They cannot write a for loop from memory. They have two hundred hours of instrument time and twelve hours of visual flight. And the checkride examiner isn't going to care how pretty your types are when the automation disconnects and you have to put the thing on the runway by hand.
The scan pattern. That's going to stick with me.
It's the same structure exactly. The cross-check is the developer's equivalent of reading code — scanning across the type system, the runtime, the edge cases, the error handling. And if you only ever look at the output, you lose the scan.
Hilbert's student had two hundred hours of instrument time and twelve hours of visual. That ratio — that's what the Stack Overflow survey is measuring, in a different way. Sixty-two percent using AI daily, twenty-eight percent understanding completely. The ratio of generation to comprehension.
The student could fly through a thunderstorm on instruments. He was competent in the automated mode. He just couldn't land the plane without it. The moment the task required manual intervention, the competence collapsed.
That scan pattern idea — I'm going to be thinking about that for a while. And it raises a question we can't answer today, but we should sit with. If the optimal path to productivity and the optimal path to skill development keep diverging, what happens to the developers who optimize purely for productivity for five years? Do they become unemployable without AI? Or does the industry restructure around the assumption that AI is always available, the way aviation restructured around the autopilot being the default?
Aviation restructured, but it kept the manual training requirement. The autopilot is the default, but every pilot can still hand-fly. Programming has no equivalent requirement, and no obvious mechanism for creating one. The market won't demand it until there's a catastrophe, and by then the people who could have prevented it won't have the skills anymore.
As AI coding tools approach the trust threshold where they're right ninety-five-plus percent of the time, the incentive to maintain manual skills will approach zero for most developers. The ones who maintain fluency may become a niche — like manual transmission drivers or analog photographers. A beautiful skill. But you won't need it to get where you're going.
Daniel asked how to learn to fly without the autopilot in the code editor. The uncomfortable answer might be that in ten years, knowing how to code without AI might be like knowing how to navigate by the stars. Beautiful. Impressive. And not how anyone gets anywhere anymore.
But we're not in ten years. We're in now. And right now, the manual skills still matter — not for every commit, but for the moments when the automation fails or lies or simply doesn't know. The question is whether individual developers will maintain those skills against every incentive not to.
The cutting-room floor detail I keep coming back to is from that Stanford study. The forty percent retention improvement from the explanation loop — that's not just a nice-to-have. That's the difference between building a mental model and just accumulating generated code. And the protocol is free, it's built into the tools everyone already has, and almost nobody uses it. The AI can teach you what it just did. You just have to ask.
Thanks to our producer Hilbert Flumingtop for keeping the cross-check sharp.
This has been My Weird Prompts. If you enjoyed this, leave us a review wherever you get your podcasts — it helps. You can find every episode at my weird prompts dot com, or email us at show at my weird prompts dot com.
We'll be back soon.
