Lesson 1: The New Way to Write Code
Course: Coding with AI Assistants
Estimated time: 20 minutes
Difficulty: Beginner-Intermediate Builder
You sit down to implement a feature. Six months ago, you'd open a blank file and start writing. Now you open Cursor or Claude Code, describe what you want, and watch the code appear.
Most developers at this point are doing the same thing they always did, just with an autocomplete on steroids. They're still thinking line by line, syntax first. That's leaving most of the value on the table.
The shift that actually changes how fast you ship isn't getting better at prompting. It's changing what you're responsible for.
You're a Code Reviewer Now
The old model: you write code, you know it's correct because you wrote it.
The new model: you write specs, AI writes code, you verify it does what you intended and doesn't break anything you didn't think of.
This isn't a degraded role. It's actually harder in some ways and more valuable in others. A good code reviewer catches logic problems, security issues, edge cases, and architectural mistakes. A code writer who only thinks about making the current function work misses all of that.
The transition that needs to happen in your head: stop thinking of yourself as someone who types code and start thinking of yourself as someone who decides what code should exist and whether the code that exists is correct.
That's the mental shift. Everything else in this course is techniques for executing it well.
Specs Over Syntax
The limiting skill in AI-assisted coding is no longer your ability to remember API methods or write loops. It's your ability to describe what you want with enough precision that an AI can produce it correctly.
This is called writing a spec. It's not documentation. It's not a comment in your code. It's a clear description of what a piece of software should do, written before the software exists.
Good specs answer:
- What does this code do?
- What are the inputs and outputs?
- What are the edge cases?
- What should happen when something goes wrong?
- What shouldn't this code do?
When you give an AI a good spec, you get code that does what you intended. When you give it a vague request, you get code that does something, and then you spend an hour figuring out what it did and why it's wrong.
The investment in writing a clear spec upfront pays back in less time debugging AI output. It also forces you to think through the problem before anyone writes code, which is how you catch design flaws before they become implementation problems.
When AI Coding Helps (And When It Hurts)
This is the honest assessment most AI tool marketing skips.
AI coding helps most when:
- You're implementing something with a well-known pattern. Authentication flows, CRUD operations, form validation, API routes, webhook handlers - these have been implemented millions of times. The AI knows the right pattern cold.
- You're working in a framework or library with abundant documentation and community code. React, Next.js, FastAPI, Django, Express - well-represented in training data means fewer hallucinated methods.
- You're prototyping or exploring. AI is fast at generating a rough version of something so you can evaluate the approach before committing to it.
- You're writing tests. Given a function, AI writes comprehensive test cases faster than most developers do by hand.
- You're doing repetitive structural work. Migrating a schema, converting files to a new format, updating import paths across a project - tasks that are tedious but mechanical.
AI coding hurts most when:
- You don't understand the code it's producing. If you can't read the output and verify it's correct, you're shipping blind. This is dangerous, especially for security-sensitive code.
- You're working on something novel or highly specific to your business logic. AI doesn't know what "a valid order in our system" means unless you tell it. If your edge cases are business-domain specific, the AI will get them wrong without a very detailed spec.
- You're asking it to hold context across a very large codebase. AI coding tools have context windows. A 50,000 line project doesn't fit. It will produce code that conflicts with your existing patterns because it can't see all of them at once.
- You're in an unfamiliar codebase yourself. If you don't understand the code, you can't verify AI output. The speed advantage disappears because you're debugging instead of reviewing.
- You need production-grade security. AI-generated code often gets auth, input validation, and SQL injection prevention approximately right. "Approximately right" in security is wrong.
The pattern: AI is fast at the predictable parts, unreliable at the novel parts, and dangerous when you can't verify the output. Use it for what it's good at, review everything it produces, and stay engaged in the parts that require judgment.
The Shift in Practice: A Before/After
Here's what this looks like for a real task. Say you need to add rate limiting to an API route.
Before (code-first thinking):
Open the file. Look up the rate limiting library. Read the docs. Write the middleware. Test it. Realize you forgot to handle the case where the user is authenticated differently. Fix it. Test again.
After (spec-first thinking):
Write the spec:
Rate limit the /api/generate endpoint.
- Authenticated users: 10 requests per minute per user ID
- Unauthenticated users: 3 requests per minute per IP
- When limit is exceeded: return 429 with a JSON body { error: "rate_limit_exceeded", retry_after: X }
- X should be the number of seconds until their limit resets
- Use upstash/ratelimit, the client is already initialized at lib/ratelimit.ts
Give it to the AI, get working middleware, review it for correctness, test it. Total time: probably faster, but more importantly, the spec forced you to think about the unauthenticated case before writing code. That's a design problem you'd catch in review instead of after deployment.
The spec-first approach finds design flaws earlier. That's as valuable as the speed improvement.
Building Your Reviewer Instincts
The role shift to code reviewer only works if you develop actual reviewer instincts. Reading code you didn't write and evaluating whether it's correct is a skill. You develop it by practicing.
Start with these questions for every block of AI-generated code:
Does it do what I asked? Read the code as if someone else wrote it. Does it match your spec?
What happens when the input is wrong? Pass in null, pass in an empty string, pass in a value twice the expected size. Does the code handle it or crash?
Where's the happy path and where's the failure path? Can you trace both through the code?
Does it interact with any external service or database? If so, what happens if that service is down or returns an error?
Is there anything security-relevant here? User input going into a query? Auth checks that could be bypassed? API keys being logged?
You don't need to catch everything on first review. But developing the habit of asking these questions means you catch problems before users do instead of after.
Exercise: Rewrite a Recent Task as a Spec
Pick something you coded in the last month. A feature, a bug fix, a refactor. Take it and write a spec for it as if you were handing it to an AI to implement.
Your spec should include:
- What the code does (1-2 sentences)
- Inputs and their types/constraints
- Outputs and their types/constraints
- At least 2 edge cases the code should handle
- What should happen on failure
- What's explicitly out of scope
Then, in your AI editor, paste the spec and ask it to implement it. Compare the output to what you originally wrote.
The comparison is instructive. Where does the AI's version differ? Is its version better or worse? Did it catch something you missed? Did you catch something it missed?
Most developers who do this exercise come away with two things: a better understanding of what specs they need to write, and genuine respect for how much better the AI version is in some ways and how confidently wrong it is in others.
Key Takeaway
The most valuable skill in AI-assisted coding isn't prompting - it's learning to think in specs and review code you didn't write with genuine critical attention.
What's Next
You've got the mental model. Lesson 2 goes practical: which AI editor should you actually use? The differences between Claude Code, Cursor, Copilot, and Windsurf matter more than the marketing suggests, and the choice depends on how you work.