Software development has always been a craft learned through repetition, failure, and the slow accumulation of hard-won experience. You write a function, it breaks, you debug it at 2 AM, and somewhere in that painful process, the knowledge of why it broke gets permanently etched into your brain. This experiential learning—the frustration, the discovery, the eventual understanding—forms the foundation that separates developers who can ship reliable software from those who merely assemble code.

AI coding assistants have fundamentally altered this equation. Tools like GitHub Copilot, Claude, and ChatGPT can generate syntactically correct, sometimes elegant solutions to problems in seconds. For experienced developers who already understand the underlying principles, these tools accelerate their work without compromising their judgment. For junior developers still building that foundational knowledge, however, AI code generation presents a genuine risk: the opportunity to skip the very struggles that create competent engineers.

The Forklift Analogy

Consider the difference between a forklift and weightlifting. Both move heavy objects from one place to another, but their purposes diverge completely. The forklift exists to accomplish a task efficiently. Weightlifting exists to transform the person doing the lifting. Using a forklift to move boxes is sensible; using a forklift to “work out” defeats the entire purpose.

Production code generation with AI operates the same way for junior developers. When an inexperienced developer prompts an AI to write a function they don’t understand, they’ve accomplished the task—code exists, tests might pass—but they’ve bypassed the cognitive struggle that would have taught them why that solution works. They’ve used the forklift when they needed the weights.

The distinction matters because software development isn’t just about producing code. It’s about building mental models of systems, understanding failure modes, recognizing patterns across different problem domains, and developing the intuition to know when something feels wrong even before you can articulate why. These capabilities emerge from direct engagement with problems, not from reviewing solutions someone (or something) else produced.

The Collapsing Mentorship Infrastructure

This situation might be manageable if junior developers had strong support systems to compensate for reduced hands-on struggle. They don’t. The traditional pathways through which new developers absorbed knowledge have deteriorated significantly over the past several years.

Consider what’s happened to informal technical community spaces. Twitter, whatever its flaws, once served as a genuine hub for developer knowledge sharing. Senior engineers posted threads explaining subtle architectural decisions. Framework authors discussed tradeoffs in their designs. Junior developers could follow and learn from people building systems they admired. That ecosystem has largely fragmented. The platform’s transformation drove away many technical contributors, leaving spaces dominated by promotional content and engagement farming rather than substantive technical discussion.

Remote work has introduced its own complications. The shift to distributed teams eliminated countless informal learning opportunities that previous developer generations took for granted. The hallway conversation where a senior engineer mentions “that reminds me of a bug I saw in 2018.” The overheard code review discussion that teaches you about edge cases you hadn’t considered. The ability to tap someone on the shoulder and ask “does this approach make sense?” These micro-interactions accumulated into substantial knowledge transfer over time. Remote work hasn’t made mentorship impossible, but it has made it require deliberate effort rather than happening organically.

Layoffs across the tech industry compounded these problems. Companies that spent 2021 and 2022 hiring aggressively reversed course when interest rates rose and funding dried up. The resulting workforce reductions often hit junior positions hardest while also eliminating the senior engineers who would have mentored them. Teams became leaner and more focused on immediate delivery, with less bandwidth for the patient guidance that developing engineers require.

Junior developers entering the industry now face a perfect storm: fewer mentors, fewer informal learning opportunities, and a powerful tool that makes it easy to skip the productive struggle that builds lasting competence.

The Specific Problem with AI-Generated Production Code

There’s an important distinction between different uses of AI in a developer’s workflow. Using AI to explain a concept you don’t understand? That requires active engagement—you have to process the explanation, connect it to what you know, and verify it makes sense. Using AI to help debug an issue by describing your problem and getting diagnostic suggestions? That’s collaborative; you’re still the one reasoning about the code. Using AI to generate test cases? That works because you have to evaluate whether the tests actually cover meaningful scenarios.

Production code generation is different. When you prompt an AI to write the implementation and then paste its output into your codebase, you skip the reasoning process entirely. You don’t learn why the AI chose that data structure. You don’t understand the edge cases it handled (or missed). You don’t develop intuition about what makes the solution elegant versus brittle. You get working code and no residue of understanding.

The downstream effects multiply. Code reviewers can’t effectively evaluate code that the author doesn’t understand. Senior developers reviewing a junior’s pull request rely on the author being able to explain their decisions and respond thoughtfully to questions. When the code was AI-generated and the author merely transcribed it, that collaborative review process breaks down. The reviewer either has to understand the code better than the person who “wrote” it, or they have to rubber-stamp work they can’t properly evaluate.

Organizations shipping code that neither the author nor the reviewer deeply understands creates accumulated risk. The code might work today, but nobody knows why it works, what assumptions it encodes, or how it will behave when conditions change. Technical debt accrues invisibly because the people who could have understood the tradeoffs never developed that understanding.

What Productive AI Usage Looks Like

None of this argues against using AI tools entirely. The question is which uses create leverage versus which uses create atrophy. Consider these different modes of engagement.

Asking AI to explain unfamiliar code or concepts requires you to evaluate the explanation against your understanding and identify gaps. This is active learning. The AI functions like a patient, infinitely available teaching assistant who can adjust explanations to your level. You come away with better understanding than you started with.

Using AI to suggest approaches to a problem you’re stuck on can break through blocks without eliminating your engagement with the solution. You still have to evaluate whether the suggested approach makes sense, adapt it to your specific context, and understand it well enough to maintain it. The AI helps you past the obstacle; you still do the climbing.

Generating documentation or test cases with AI assistance can be productive because these artifacts force you to engage with the code’s behavior. Writing tests means understanding what the code should do. Writing documentation means articulating the code’s purpose and limitations. Even if AI helps draft these artifacts, you have to evaluate them against the reality of your implementation.

The problematic pattern emerges specifically when AI generates the core implementation and you accept it without the cognitive work of understanding it. This is the forklift scenario: the task gets done, but you don’t develop the capabilities that doing the task should build.

The Vibe Coding Illusion

A counterargument has emerged: prompt engineering itself constitutes a valuable skill. “Vibe coders”—people who build software primarily through iterative AI prompting rather than traditional programming—can sometimes produce output indistinguishable from what experienced developers create. If a junior developer or even a non-programmer can prompt their way to working software, does the distinction between “real” programming and AI-assisted generation even matter?

The answer depends on what happens next. Vibe coding works remarkably well for certain categories of problems: straightforward CRUD applications, well-documented integrations, implementations that follow established patterns. A skilled prompt engineer can iterate with Claude or GPT-4 to produce functional code faster than many developers could write it manually. The output looks professional. The tests pass. The feature ships.

The fracture appears when something goes wrong. Production systems fail in ways that require understanding the code’s actual behavior, not just its intended behavior. A vibe coder facing a mysterious performance regression, a race condition that only manifests under load, or a security vulnerability buried in generated code has limited options. They can try prompting their way to a fix—sometimes successfully—but they lack the mental model to reason about why the system behaves as it does. They’re debugging through trial and error rather than through understanding.

This limitation reveals what prompt engineering actually optimizes for: translating intent into working code when the problem is well-defined and the solution space is familiar. Prompt engineering does not build the ability to recognize when the AI’s solution encodes assumptions that don’t hold in your specific context. It does not develop intuition for architectural decisions that will matter six months from now. It does not create the judgment to know when generated code is subtly wrong in ways that won’t surface until production.

Consider a parallel from another field. Someone with no medical training can use WebMD to identify that their symptoms might indicate strep throat and that antibiotics are the typical treatment. For straightforward cases, this produces the same outcome as visiting a doctor. But the non-expert cannot distinguish strep from the rare presentation of something more serious. They cannot evaluate whether the standard treatment applies to their specific situation. They cannot reason from first principles when the textbook case doesn’t match their reality. The knowledge gap remains even when the output appears equivalent.

Vibe coding creates a similar situation. The prompt engineer and the experienced developer might produce identical code for a given feature. But only one of them understands what they produced, can maintain it confidently, can extend it in ways the AI didn’t anticipate, and can debug it when it fails unexpectedly. Output equivalence is not capability equivalence.

This matters particularly for people using vibe coding as an entry point into software development. The approach can be genuinely valuable for building prototypes, automating personal workflows, or creating tools where “good enough” truly is good enough. Problems arise when vibe coding becomes the only mode of engagement with code, when it substitutes entirely for developing actual programming knowledge. The person who vibe-codes their way through their first year in industry, shipping features successfully while building no underlying understanding, has optimized for the wrong metric. They’ve demonstrated output while accumulating capability debt.

Prompt engineering is a real skill with genuine value. But it’s additive to programming knowledge, not a replacement for it. The developers who will thrive long-term are those who can both write code from scratch and leverage AI effectively—who understand the systems well enough to evaluate AI output critically and prompt effectively because they know what good solutions look like.

What This Means for Junior Developers

If you’re early in your career, the temptation to lean heavily on AI code generation makes complete sense. You’re under pressure to deliver. Your more experienced colleagues seem to use these tools extensively. Generating code faster feels like competence. But consider what you’re optimizing for: speed today, or capability over your career?

The most valuable skill you can develop isn’t writing code quickly. It’s building accurate mental models of complex systems. It’s recognizing patterns across different problems. It’s knowing when something feels wrong before you can explain why. These capabilities emerge from struggle, from debugging code at 3 AM, from writing implementations that fail and having to understand why. You cannot shortcut this process without shortchanging yourself.

This doesn’t mean abandoning AI tools. It means using them in ways that enhance your learning rather than substitute for it. Explain to the AI what you’re trying to accomplish and ask it to explain approaches, not generate implementations. When you’re stuck, describe your problem and ask for guidance on debugging strategies. Use AI to review your code and explain what you might be missing. These modes keep you in the cognitive loop while still leveraging AI’s capabilities.

The goal isn’t to work harder than necessary out of some masochistic principle. The goal is to recognize that certain struggles produce growth, and growth is what your career depends on. You’re investing in yourself every time you work through a hard problem manually. You’re divesting from yourself every time you let AI do the thinking you should be doing.

What This Means for Senior Developers and Organizations

If you lead or mentor junior developers, recognize that the landscape has shifted. The informal knowledge transfer mechanisms that helped previous generations develop no longer operate the same way. Remote work requires deliberate effort to create learning opportunities that used to happen organically. The pressure to ship quickly works against the patient guidance that developing engineers need.

Make mentorship explicit rather than assuming it will happen naturally. Create structures for regular pairing sessions, code review discussions, and architectural conversations. Share your reasoning, not just your conclusions. When you make a decision, explain the tradeoffs you considered and why you chose as you did. Junior developers need exposure to your thinking process, not just your outputs.

Be thoughtful about how your team uses AI tools. Creating policies that ban AI entirely is probably counterproductive and definitely unenforceable. But you can establish expectations about what kinds of AI usage are appropriate for different experience levels and different types of work. Encourage junior developers to use AI as a learning accelerant rather than a thinking replacement.

Create explicit space for productive struggle. Not every task needs to be completed as quickly as possible. Some assignments should specifically challenge junior developers to work through problems that stretch their capabilities, even if AI could produce a solution faster. Frame these as learning opportunities, not hazing rituals.

The Stakes

The software industry has spent decades developing its current level of collective capability. That capability lives in people—in the accumulated experience, judgment, and intuition of working engineers. It doesn’t persist automatically; it has to be transmitted to each new generation of developers through mentorship, struggle, and practice.

AI code generation, used carelessly, threatens to disrupt that transmission. We could produce a generation of developers who can prompt AI effectively but can’t reason about systems deeply, who can generate code quickly but can’t debug it when it breaks, who can appear productive while accumulating technical debt invisibly. The tools work well enough that this failure mode won’t be obvious until the cumulative effects become severe.

There’s a deeper irony here worth considering. The AI models generating code today learned from decades of human-written software—code produced by developers who wrestled with problems directly, who debugged their own mistakes, who built genuine understanding through struggle. That corpus of training data represents the accumulated craft of generations of engineers who learned the hard way. What happens when the next generation of training data consists largely of AI-generated code, written by developers who never deeply understood what they were shipping? The models learn from the outputs of the previous models, filtered through users who couldn’t evaluate quality. Each iteration drifts further from the hard-won knowledge that made the original training data valuable. Garbage in, garbage out—but on a generational timescale, where the degradation compounds invisibly until the foundation has rotted away.

This isn’t an argument against AI tools. It’s an argument for using them wisely, with clear awareness of what different usage patterns build versus what they atrophy. The forklift is genuinely useful for moving heavy objects when the goal is moving heavy objects. The gym is genuinely useful for building strength when the goal is building strength. The question is always: what are you actually trying to accomplish here?

For junior developers, the answer should usually be: building lasting capability. Choose your tools accordingly.

---

This post was inspired by Zac Sweers’ excellent article “Forklifts Require Training”, which explores these themes in depth. If you found this perspective valuable, his original piece is worth reading in full.