After this lesson, you will be able to: Name the categories of work AI cannot do for you in 2025, system design thinking, complex debugging, understanding what the code does, and recognize when to put the AI down and do the work yourself.
Claude, Cursor, and Copilot are powerful. Treating them as engineers, though, ships subtle bugs and stalls your growth. This lesson is the counterweight to the rest of this subtrack: where AI breaks down, where it makes you worse instead of faster, and which skills are still entirely on you. Knowing the limits is what separates developers who use AI well from developers who outsource their judgment to it.
Set the bar honestly first. In 2025, current frontier coding models are good at: writing boilerplate that follows obvious patterns, explaining what unfamiliar code does, suggesting reasonable next steps, catching shallow bugs and security issues, refactoring code into a different style, generating tests for well-defined functions, and translating between languages or frameworks. All of that is real and valuable. The rest of this lesson is about everything that's NOT on that list.
System design is choosing between options whose tradeoffs only show at scale, under failure, or over time. Should you use Postgres or DynamoDB? Should auth live in middleware or a service? Should you cache at the CDN, the application, or the database? Should this feature be a separate microservice? Asking AI 'design this system' produces a plausible-sounding answer that ignores YOUR constraints, your team size, your traffic profile, your budget, your reliability requirements, your operational tolerance. The AI gives you a generic answer; the right answer is specific to context only you have. You can use AI as a sounding board (explain a choice and ask what you might be missing). You cannot substitute AI for the actual decision.
AI is good at 'why doesn't this compile.' It is bad at 'this race condition surfaces in production every 1000 requests but never in dev.' The hard bugs require: forming a hypothesis, designing a small experiment to test it, reading the actual server logs / database state / user behavior to falsify the hypothesis, and iterating. AI doesn't have access to your production state. It doesn't know what changed last Tuesday at 3 pm. It can't ssh into the prod box. It can suggest categories of bugs to look for (helpful), but the actual diagnosis is something you do.
If you ship code you don't understand, every future bug in that code is a mystery you have to debug from scratch. Every PR review on it is one you can't defend. Every refactor of it is one you can't safely make. The skill AI most threatens is the skill that compounds over time, building a model of how a system works in your head, line by line, until you can predict its behavior without running it. The discipline that protects against this: read every line you commit. If you can't explain a line in your own words, you don't understand it yet. Either ask AI to explain it until you do, or write it yourself.
Product decisions, user-facing copy, error messages, edge-case handling priorities, what's 'good enough,' when to ship vs polish, these are judgment calls AI is bad at because they require knowing your users, your business goals, and what success looks like for THIS feature. AI will happily generate the wrong feature, beautifully. Knowing what to build is your job, not the AI's.
If any of these describe your last week, pull back: **(1)** You've committed code you couldn't explain in detail to a reviewer. **(2)** You start every coding task by opening an AI tab before opening the file. **(3)** When AI is offline, you feel unable to start. **(4)** You can't remember the syntax of a language you use daily. **(5)** You've shipped a bug that a 10-minute read of your own code would have caught. The fix isn't 'use AI less.' It's 'use AI deliberately', for the parts it's good at, with verification, while keeping the skills it can't develop for you in daily practice.
Sign in and purchase access to unlock this lesson.