Addy Osmani on why you shouldn’t outsource the learning

Addy Osmani recently published a piece titled "Don't Outsource the Learning," and I think it's one of the most useful pieces written about AI and learning to code this year. It's aimed at working engineers, but the argument lands hardest on the group Addy doesn't directly address: people who are actively learning. So I want to walk through it from that angle.

The short version of Addy's point: it's never been easier to let AI write the code while you skip the thinking. The bug gets fixed, the symptom disappears, and your mental model doesn't move. The result is what researchers have called cognitive debt: saving effort today, paying for it in capability tomorrow. The tools won't push back on this for you. They're optimized for closing tasks, not for making you a sharper engineer.

If you're working through Frontend Mentor challenges or learning software development more generally, this is worth taking seriously. Read Addy's full piece first if you haven't:

Don't Outsource the Learning, by Addy Osmani

Here's how I'd translate it for where you are in your learning journey.

The studies say what experienced developers already feel

Addy pulls together three pieces of research that all converge on the same point. Anthropic ran a trial where engineers learned a new Python library, half with AI and half without. Both groups finished at the same speed. The AI group bombed the follow-up comprehension quiz: 50% versus 67%. But the more interesting cut was inside the AI group. Engineers who used AI to ask conceptual questions scored above 65%. Engineers who copy-pasted scored under 40%. Same tool, very different outcome.

MIT's Your Brain on ChatGPT study found that 83% of people who'd written essays with an LLM couldn't quote a single line of what they'd written. A CHI 2026 paper found that having AI access at the start of a task anchors the whole problem framing, even when you do the rest of the work yourself.

The methodologies vary, but they point in the same direction. Using AI without an active intent to learn slowly undermines the thing you're trying to build.

This line from Addy deserves to be highlighted: The tool didn't determine the outcome. The posture did. That distinction matters a lot if you're learning, because your posture is the one variable that's fully under your control.

Note

Addy has written before about cognitive surrender. That's the moment an AI reviewer's verdict quietly replaces your own judgment. This piece is the solo version of that loop. If you find this article useful, that one's worth reading too.

The early stages are where this gets dangerous

When working engineers over-rely on AI, the cost is the erosion of existing mental models. When learners do it, the cost is harder to see because the mental models haven't formed yet. There's no foundation to erode. You're trying to build the first one.

I see this in our community. The pattern is consistent: when learners use AI to get unstuck immediately, they bypass the highest-value learning moments. The friction that comes with gaps in knowledge is exactly where the learning happens. Resolving issues, struggling through problems, sitting with code that won't do what you expect. That's where mental models are built, and there's no shortcut to that part, even though it may feel like AI is offering one.

What makes this hard is that AI is right there. Coding assistants live inside the editor now. The model is a keystroke away, eager to help. It takes real discipline to sit with friction when help is that accessible, but it's the people willing to slow down early who become the most proficient AI users later.

So here's what we recommend at Frontend Mentor:

In the early stages of your learning journey, type every line of code by hand. Use AI to answer questions, explain concepts, suggest improvements, query your code, and deepen your understanding. But you do the typing. The patterns, the boilerplate, the muscle memory of how a function, layout, or state update is structured: that has to live in your head, not in your assistant's autocomplete.

Stay away from agentic tools such as Claude Code, OpenCode, and Codex during this phase. They're powerful tools, but they're the wrong tools for someone still building the fundamentals. Wait until you can confidently build through our advanced and Guru level challenges by hand. At that point, you've got the mental models to review what an agent produces, push back where it's wrong, and steer it usefully. Before then, you're outsourcing the work you most need to do yourself.

If you want a more detailed staged framework for how AI use should change as you progress, we've written one: AI coding assistants for beginners.

What healthy AI use actually looks like on a challenge

"Posture matters" sounds reasonable in the abstract. It's more useful when you can picture what it looks like in practice. So here's how I'd think about it when you're stuck on a Frontend Mentor challenge at 11pm, and a Grid layout won't behave.

The unproductive prompt: "Here's my code, fix the layout."

That's outsourcing both the diagnosis and the fix. You get unstuck, and you learn nothing.

The productive version starts with you sitting with the problem first. Rubber duck it. If it's a JavaScript console error, read it. Properly. Then go back to the file, read through it line by line, and look at where the syntax or the logic might be wrong. If it's a CSS issue and an element isn't positioned where you expected, look at the parent, the box model, and the display values. Just spend time with it.

If you've thought about it and you're still stuck, asking the community is a good next step, both because you'll often get help and because the act of writing the question forces you to articulate the problem clearly. That skill alone is worth practicing.

Then, when you do go to AI, ask it to help you understand rather than to fix the code. "Here's my element, here's what I expected, here's what's happening. What am I missing about how Grid works in this context?" That's a prompt that teaches you something. The fix arrives as a side effect of the understanding.

To make this easier, every Frontend Mentor challenge now ships with AGENTS.md files calibrated to the difficulty level. At Newbie level, the AI is set up to refuse to write code for you and to teach you through the problem instead. At Guru level, it acts as a peer collaborator who'll challenge your approach. The principle is the same one Addy is making: AI should guide your thinking. We've built that into the defaults, so you don't have to police it yourself.

"If the AI can do it, why do I need to understand it?"

This is the question that I think trips up a lot of learners, and Addy answers it well. For some work, like boilerplate, throwaway scripts, and glue code, pure delegation is fine. The opportunity cost of memorizing YAML syntax is real.

For everything else, the answer comes down to four situations he lays out. When something breaks, somebody has to debug it. When the model is confidently wrong (and it will be), the only defense is enough expertise to spot it. When the foundation changes, things like framework updates, security reviews, and migrations, you can't re-prompt your way out. And when you leave the median path, the further you stray from problems that have been solved a million times on GitHub, the worse the AI gets.

That last point matters most for a career. The hard, undocumented problems are what justify a senior engineer's salary. They're also what hiring managers are increasingly trying to test for, because vibe-coded portfolios make the work harder to evaluate. We wrote about that side of it from the hiring perspective in how to evaluate developers in the vibe coding era.

The junior developer market is hard, and the way through it is the same

Zoom out from the individual developer, and the backdrop is stark. Employment for early-career software developers (ages 22 to 25) is down nearly 20% from its late-2022 peak, according to Stanford research analyzing payroll data. If you're trying to break in right now, these figures can be alarming.

The market is tough. There's more competition than there's been in years. Hiring strategies for entry-level talent have shifted significantly in the last three years. Widespread layoffs mean some developers with two or three years of experience are applying for junior roles to get back on the ladder. That's the reality.

It's still a strong industry to enter. Whether you want to be a software engineer at a company, build your own online products, or run a one-person business, the ability to build apps is an incredible skill that opens many doors. But to land an entry-level role today, you need to clearly show two things: that you can do something AI can't do alone, and that you'll add value quickly.

That second part is where AI fluency actually helps you. Employers want to hire people who are proficient with these tools, because that's how their teams already work. So you need to use them. The key is using them in a way that shows judgment, not dependence.

Your portfolio is now a different artifact

Portfolios used to be a reasonable proxy for skill. They're not anymore, at least not on their own. Anyone can build a credible-looking project in a weekend with Claude Code. So the bar has moved.

Here's how I think about portfolios now:

Use AI in your projects, and call out exactly how you used it. Don't pretend you didn't. Say which tools you used, what they helped with, where they got things wrong, and how you corrected them. The places where you spotted AI's mistakes and fixed them are some of the strongest evidence you can show. Spotting confident-but-wrong output requires real understanding. That's exactly what employers are trying to assess.

Ship something real, even if small. If you've got an idea you actually care about, build it, put it on a domain, and get some users. Even if those users are only you, your friends, and your family. A project where you've gathered feedback, added features, and removed features tells a far richer story than a static portfolio piece. You're demonstrating product judgment on top of your implementation skill.

Use our Product Challenges when you're ready to practice AI collaboration. These are intermediate-plus, specification-led challenges with no Figma designs. They're built specifically for strong AI collaboration because many engineers' day jobs now involve orchestrating AI agents. Our design-led challenges teach you to hand-build to a design and project brief. The product challenges teach you to direct AI through a product specification. Both are skills the market is asking for.

Two metrics, not one

The line Addy ends on is the one I want to leave you with. He's started ending coding sessions by asking himself: did I learn anything today, or did I just close issues?

For a learner, the equivalent question is: did I understand more after this challenge than before, or did I just produce a finished project?

Both metrics matter. Some days you ship and learn nothing, and that's fine. Some days you spend hours on a single concept and produce almost no code, and that's also fine. The problem is when "I produced something, but I'm not sure what I learned" becomes the answer for weeks at a time, without any real understanding compounding underneath.

Ship and learn are two separate metrics. Your future employer will only ever see the first one. The second is on you.

If you're not sure where to start, our learning paths walk you through challenges in an order that builds skills progressively. Pick one, hand-type every line, and use AI as a tutor rather than a co-author until you've got the mental models that let you do more. Once you're there, the same tools that were building cognitive debt start working in your favor.

The defaults won't make this choice for you, so make it early.