CodeFromScratch
Learning Web Development From Scratch With AI: What to Learn, What to Skip
Milos KnezevicMilos Knezevic10 Nov 2026 · 29 min read
Developer Experience & Career

Learning Web Development From Scratch With AI: What to Learn, What to Skip

AI writes code now, so what is still worth learning? Sort it into three boxes: learn deeply, learn to read, skip for now. With a real bug, a demo and a roadmap.

Here's the short answer first. Learn deeply the things you need to judge code: reading it, how a request travels between the browser and the server, the shape of data, reading errors and basic security. Learn just enough syntax and framework detail to read it, because the AI and the docs can type it for you. Skip big-company architecture until a real problem asks for it.

If you're a complete beginner, read this top to bottom, and please try the little exercise before you read my answer to it. If you've built a few things already, the parts for you are the order total bug, the live demo, and the section on using AI as a tutor instead of a ghostwriter. If you're experienced and you help juniors, there's a callout near the end about what they need from you now.

The problem: nobody can tell you what's still worth learning

Let me say the question out loud, because I think a lot of you carry it around quietly. You open a course. Lesson four is about three different ways to declare a variable. Then you open a chat window, describe a to-do app in two sentences, and a minute later you have one that works. So why would you spend a week on lesson four?

And the internet gives you two answers, both loud. One side says learning to code is over, just learn to prompt. The other side says nothing has changed, so grind the fundamentals like it's 2015 and ignore the tools. I think both are wrong, and both are wrong in a way that costs you months.

Here's where I stand, so you know who's talking. I work as a web developer, and I use AI for a big part of my work, day to day. I don't think AI will replace programmers. I think it changes how they work: fewer weeks of typing and debugging, more directing and checking. Whoever ignores that falls behind very fast, because these tools move fast. But directing only works if you understand what you're directing. That's this whole article in two sentences. The rest is about what "understand" actually means.

Even developers who use these tools all the time don't fully trust them. In Stack Overflow's 2025 Developer Survey, 84% of respondents said they use or plan to use AI tools in their development process, and yet more of them distrust the accuracy of those tools (46%) than trust it (33%). The most common frustration, named by 66%, was "AI solutions that are almost right, but not quite". Remember that phrase. Almost right is exactly the gap your learning has to close.

Why this feels impossible to answer right now

The cause isn't that AI is magic. It's that AI made one part of the job very cheap, and that part happens to be the part you can see.

When you watch someone program, what you see is typing. Syntax, brackets, the name of a function, the exact CSS property. That's the visible part, and it's what courses spend most of their time on, because it's easy to test: did you write the loop correctly or not. What you don't see is the other part. Deciding what to build. Noticing that a number is wrong. Asking who's allowed to see this data. Reading an error and knowing where to look. That part was always the hard part, and it's still yours.

So "what should I learn" gets confusing, because the stuff that's easy to teach got cheap, and the stuff that matters was never really on the syllabus. I felt that second half long before AI showed up. I finished courses and still felt like I knew nothing, because nobody connected the exercises to real work. I wrote about that in why courses leave you feeling like you know nothing. AI didn't create that gap. It just made it impossible to ignore.

Here's the comparison I keep coming back to. Think about driving with GPS. The GPS picks the route, so you don't need to memorise every street in the city anymore. That part really did get cheap. But you still need to drive. You need the rules of the road, you need to read the signs, and you need to notice when the GPS tells you to turn into a lake. Nobody says "I have GPS, so I'll skip learning to drive". AI is the GPS. The code it writes is the route. Learning to program is still learning to drive.

The path: sort every topic into three boxes

Instead of a giant list of technologies, I want to give you a sorting rule, because the tools will look different next year and a rule survives that. For any topic you meet, ask one question: if the AI got this wrong, would I notice, and what would it cost?

  • Learn deeply: mistakes here are invisible and expensive. The code runs, the page looks fine, and the bug is still there. A wrong total, another person's data on the screen, a password sitting in a log file. You only catch these if you understand them.
  • Learn enough to read: mistakes here are visible and cheap. A button in the wrong place, a CSS rule that doesn't apply, a function that got renamed in a new version. You see the problem, you check the docs or ask again, you fix it.
  • Skip for now: things you won't need until you have the problem they solve. Learning them early isn't wrong, it's just expensive, because without the problem you have nothing to attach them to, and they don't stick.

Notice that the rule is about cost and visibility, not about how hard a topic is. Some easy things land in the first box. Some hard things land in the third. Let's fill the boxes, starting with the one that matters most.

Box one: learn these deeply

These are the skills you'll use every single day, whether you type the code or an AI does. They're also the ones the AI can't do for you, because they're about judging its work. There are six of them: reading code, how a request travels, the shape of data, reading errors, the idea that the browser lies, and having an undo button. I'll spend the most time on the first one, because it's the one courses skip.

Reading code comes before writing it

Courses teach you to write code. In this new way of working you'll read far more code than you write, so reading is the skill to train first. Let me show you what I mean with a small test. Here's a function an AI could easily give you if you asked for "a function that calculates the order total from the form". Before you read my explanation, look at it and decide what it prints.

total.js
const fromForm = { price: "10", quantity: "3", shipping: "4.99" };

function orderTotal(fields) {
  const subtotal = fields.price * fields.quantity;
  return subtotal + fields.shipping;
}

console.log(orderTotal(fromForm));

Got your answer? Most people say 34.99. Ten times three is thirty, plus 4.99 for shipping. Here's what Node actually prints:

Terminal
node total.js
304.99

Three hundred and four dollars and ninety-nine cents. Let's walk through it line by line, because every line matters here.

The first line is the data as it arrives from a form. Look at the quotes. Everything that comes out of a form field is text, a string, even when the person typed a number. "10" in quotes isn't the number ten. It's the two characters 1 and 0. That's true even for an input with type="number": the browser still hands its value to your code as a string.

The function line takes fields, which is that object with the three values. Nothing surprising yet.

Then const subtotal = fields.price * fields.quantity. Here JavaScript quietly helps you. The star means multiply, and multiplying only makes sense for numbers, so JavaScript turns "10" and "3" into numbers and gives you 30. A real number. So far it looks like the code understands you.

And then return subtotal + fields.shipping, where the help stops. The plus sign has two jobs in JavaScript: adding numbers and gluing text together. When one side is text, gluing wins. MDN says it plainly: if one side is a string, the other operand is also converted to a string and they are concatenated. Concatenated just means glued end to end. So 30 becomes "30", it gets glued to "4.99", and you get "304.99".

That's the "almost right, but not quite" from the survey, in four lines. It runs. There's no error message. With shipping set to "0" it shows 300 instead of 30, and with the shipping field left empty it shows 30, which happens to look correct. Someone testing it quickly could easily wave it through. The AI didn't do anything stupid here. It did something very common, and the only defence is a person who can look at that plus sign and ask: is this adding, or gluing?

Why the obvious fix is still almost right

Here's the part that should make you want to learn this properly. When you paste that bug back to the AI and say "the total is wrong", a very common fix is to wrap the shipping in Number(), which converts text to a number:

total.js (the quick fix)
function orderTotal(fields) {
  const subtotal = fields.price * fields.quantity;
  return subtotal + Number(fields.shipping);
}

Now 4.99 works and you get 34.99. Done? Not quite. Number has rules of its own: empty or whitespace-only strings are converted to 0. So if the shipping field is left empty, Number("") is 0, not an error. An empty field silently becomes free shipping. And if someone types 4,99 with a comma, the way a lot of Europe writes decimals, Number gives you NaN. NaN means "not a number", and it spreads through every calculation it touches, so the total turns into NaN too. Each fix is almost right again. You have to know what you want before you can tell whether you got it.

What you want, written down: the checked version

Here's the version I'd accept. It's longer, and every extra line is a decision somebody made on purpose.

total-checked.js
function toAmount(raw, label) {
  if (raw.trim() === "") {
    throw new Error(`${label} is empty`);
  }
  const value = Number(raw);
  if (Number.isNaN(value) || value < 0) {
    throw new Error(`${label} must be a number, 0 or more`);
  }
  return value;
}

function orderTotal(fields) {
  const price = toAmount(fields.price, "Price");
  const quantity = toAmount(fields.quantity, "Quantity");
  const shipping = toAmount(fields.shipping, "Shipping");
  return price * quantity + shipping;
}

console.log(orderTotal({ price: "10", quantity: "3", shipping: "4.99" }));
console.log(orderTotal({ price: "10", quantity: "3", shipping: "" }));

Line by line again, because this is where the decisions live.

  • function toAmount(raw, label) has one small job: turn one form value into a number, or refuse. The label is only there so the error message can say which field is wrong. Without it you'd get "something is empty", which helps nobody.
  • if (raw.trim() === "") checks for an empty field. trim() removes spaces from both ends, so a field with only spaces in it counts as empty too. Delete this line and you're back to Number("") being 0. This line is the decision "empty is a mistake, not zero".
  • const value = Number(raw) is the conversion, done once, on purpose, in one place where you can see it.
  • if (Number.isNaN(value) || value < 0) catches anything that didn't convert, like "abc" or "4,99", and refuses negative amounts. Remove the value < 0 part and someone can order minus two items and get a discount you never offered.
  • return value means only clean numbers ever leave this function.
  • In orderTotal, every field now goes through the same door before any maths happens. And after that, the maths is the boring line you expected from the very start: price times quantity plus shipping.

Here's what it prints:

Terminal
node total-checked.js
34.99
Error: Shipping is empty
    at toAmount (total-checked.js:3:11)

I've cut the folder path and Node's internal lines from that output, nothing else. The first call prints 34.99. The second one stops with "Shipping is empty" instead of quietly charging nothing for shipping. A loud error while you're testing is a gift. A quiet wrong number in production is a bill.

warning

Two honest limits of this example. First, in a real shop the price never comes from the browser at all. Anyone can change a form value in the browser's developer tools, so the server looks the price up itself; the vibe coding article shows exactly that attack with a live demo. Second, for real money, don't do maths with decimals like 4.99. Computers store them in binary, and in JavaScript 0.1 + 0.2 comes out as 0.30000000000000004. Real systems keep amounts in whole cents (499 instead of 4.99) and only format them as dollars on the screen.

And all of this checking has to happen twice: once in the browser, so the person gets a quick, friendly message, and once on the server, because the browser is the one part of your app you don't control. That's the whole idea behind login form validation: why you check twice, and validating at trust boundaries with Zod shows the server side done properly.

Try it: the first draft against the checked version

Reading about it is one thing. Now try it. The form below runs both versions of the code. Leave the values as they are and press Calculate total with the first draft, then switch to the checked version and press it again. Then break it on purpose: empty the shipping field, type 4,99 with a comma, or set the quantity to -2. Watch what each version does with the same mistake.

Order total: first draft vs checked version

Notice that the first draft never complains. It doesn't know it's wrong, so it can't tell you. With minus two items it happily shows a total of -204.99. That's what makes this kind of bug dangerous: the code that should worry you most is often the code that looks the calmest.

One small exercise before you move on, because this is exactly how you train reading. The checked version accepts 2.5 as a quantity. Half a T-shirt. Which line would you change, and to what? Try it yourself before you ask an AI. Then ask it, and compare. If your answer and its answer are different, that's the most useful conversation you'll have this week.

The rest of box one: requests, data, errors, security and undo

Reading code is the first skill. The other five are what you need to know so you can read code and actually understand what it's doing to real people.

How a request travels

Every web app, however fancy, is a conversation. The browser asks, the server answers. Opening a page, sending a form, clicking a like button: each one is a request going out and a response coming back. Once you really see that, a lot of confusion goes away. Why can't the browser read the database directly? Because the database lives on the server's side of the conversation. Why do we check a form twice? Because the browser's side of the conversation can be faked. Why is the page slow? Usually because it's waiting for an answer. I put all of this in order, with a tiny server you can build yourself, in what is web development: a complete beginner's guide. If you only read one other article after this one, make it that one.

This belongs in box one because it decides where code runs, and where code runs decides who can see it and who can change it. An AI can put a secret key into code that ends up in the browser if nobody tells it not to. You can only stop that if you know which side of the conversation you're on.

The shape of data

Almost everything you'll build is data being moved around and shown. A list of posts. A cart with items in it. A user with a name and an email. In JavaScript that's arrays, which are ordered lists, and objects, which are bundles of named values. In a database it's rows in tables. If you can look at a piece of data and say what shape it is, a list of things, one thing with fields, or a list of things where each one holds another list, you can follow almost any code an AI hands you. I showed the most common use of that in render lists without repeating code: one template, a list of data, a loop.

Reading an error message without panicking

Errors are going to be a big part of your life, AI or not. AI tools will often show you an error with a guess about the cause attached, and you need to be able to read the error yourself to know if the guess makes sense. Here's a tiny program with a bug in it:

greet.js
const users = [{ name: "Emily" }, { name: "James" }];

function greet(index) {
  return "Hi, " + users[index].name;
}

console.log(greet(0));
console.log(greet(2));
Terminal
node greet.js
Hi, Emily
greet.js:4
  return "Hi, " + users[index].name;
                               ^

TypeError: Cannot read properties of undefined (reading 'name')
    at greet (greet.js:4:32)

Again I've cut the folder path and Node's own lines underneath. Read every error in the same three steps, always in this order.

  • What happened: "TypeError: Cannot read properties of undefined (reading 'name')". In plain words, you asked for .name on something that doesn't exist. Whatever sits just to the left of .name is undefined.
  • Where: greet.js:4:32 means the file greet.js, line 4, column 32. Node even draws a little arrow under the exact spot. The line "at greet" tells you which function you were in when it happened.
  • Why: now you think. On line 4, the thing to the left of .name is users[index], so users[index] was undefined. Which index? The second call passed 2. The array holds two users, and arrays count from 0, so the only valid positions are 0 and 1. Position 2 is empty.

Notice that the error told you the what and the where perfectly, and said nothing about the why. The why is always yours. An AI can often guess it too, but if you can't follow its reasoning, you can't tell a good guess from a confident wrong one. And the fix depends on what you want, which is the theme of this whole article. Should greet(2) be impossible, so the code that called it is the real bug? Or should it return a friendly "user not found"? Neither answer is right in general. You decide, and that decision is your job, not the tool's.

Security starts with one idea: the browser lies

You don't need to be a security expert to start. You need one idea, learned so deeply it becomes a reflex: anything that comes from the browser can be changed by the person using it. Form values, hidden fields, prices, user ids in the address bar. The server checks everything again, and the server decides who is asking. I built what is vibe coding around exactly this mistake, because it's the one AI-built apps make most often, and what separates hobby apps from real ones turns it into a checklist you can run against your own project.

And here's a mistake I made myself. When I started, I never once thought about what happens when a thousand real people have accounts on something I built. How do I protect their accounts from someone guessing passwords? What happens when they forget theirs? What do I do when my own bug hurts them? None of that crossed my mind. It doesn't need to scare you. It just needs to be on your list from the beginning, not after the first problem.

Git is your undo button

Version control sounds like something for big teams. It's actually the one tool that makes working with AI safe for a beginner. An AI agent can change a dozen files in one go. Without a saved point to go back to, one bad change can wreck code that worked an hour ago. Git gives you that saved point. Here's the whole routine, and it's only a handful of commands.

Terminal
git add -A
git commit -m "Order total works, before the refactor"
# let the AI make its change, then look at what it did:
git diff --stat
git diff total.js
git restore total.js
  • git add -A picks up every change in the project folder, and git commit saves all of it as a point in history, with a message. Write the message for future you: what works right now.
  • The line starting with # is a comment. Bash ignores it; it's only there to show you where the AI's work happens.
  • git diff --stat is the summary: which files changed and how many lines in each. If you asked for a fix in one file and the summary shows five, that's your first question for the AI.
  • git diff total.js shows the actual lines, with a minus in front of what was removed and a plus in front of what was added. This is where reading code pays off. You don't read the whole project again, only what changed.
  • git restore total.js throws away the uncommitted changes in that one file and brings back the version from your last commit. Careful: those changes are gone for good, so look at the diff before you restore. It also doesn't touch brand new files that git isn't tracking yet; a file the AI created stays where it is.

Run that sequence on the order total from earlier, with the quick Number() fix as "the AI's change", and the diff shows exactly one line with a minus and one with a plus. After the restore, the file is back to the committed version, bug and all, which is the point: you're back to a state you know. The git restore documentation lists every option if you need more than this.

info

Tested with: every code sample in this article was run with Node.js 24.14.1 and Git 2.53 on Windows, and the live demo was run in Microsoft Edge 157, including a 320 pixel wide frame. The advice about using AI doesn't depend on a particular tool; it works the same with a chat assistant or a coding agent.

Box two: learn just enough to read

This box is where AI really does save you weeks, and I'm happy to say so. These are things you should recognise and understand when you see them, but you don't need to be able to type them from memory.

  • Exact syntax. Whether it's forEach or for...of, where the semicolons go, the order of arguments in a function you use twice a year. Know what a loop is for and when you need one. Your editor, the docs and the AI will remember the spelling.
  • Every CSS property. Learn the box model, how flexbox and grid think, and how to make a page work on a phone. You don't need to memorise every property and every value.
  • Framework details. Learn what a component is, what runs on the server and what runs in the browser, and how data gets into a page. The exact names of functions change between versions, and that's exactly where AI answers are weakest, because they may come from an older version.
  • Regular expressions, build settings and config files. Know what they're for. Let the AI write the pattern, then test it against examples you chose yourself, including the ugly ones.
  • SQL beyond the basics. Learn SELECT, WHERE and JOIN, and what an index is for. Longer queries you can read, run against test data and ask questions about.

For the CSS part, two articles will get you to "I can read this" quickly: HTML and CSS for beginners: build your first web page for the foundations, and flexbox vs grid on real layouts for how layout actually gets decided.

There's one rule that makes box two safe: for anything you didn't write yourself, you either test it or check it against the official documentation. A function name that doesn't exist fails loudly, and that's fine, you'll see it. A function that exists but works differently in the newest version fails quietly. The docs tell you which version they describe. An AI's answer often doesn't.

Box three: skip it for now

Skip for now means not yet. It doesn't mean never, and it doesn't mean these things don't matter. It means you've got nothing to hang them on yet, so they won't stick, and the time is better spent in box one.

  • Microservices, Kubernetes and the architecture of very large companies. These solve the problems of hundreds of developers and huge traffic. A first real app with its first users needs one server, one database and backups.
  • Five frameworks at once. Pick one way to build, learn it until you can make something small without a tutorial open, and only then compare it with others.
  • Chasing every new AI tool. New ones appear constantly. Learn one well enough to direct it: how to give it context, how to ask for a plan, how to review what it did. That skill carries over to the next tool; the buttons don't.
  • Algorithm puzzles as your main training. If you're preparing for interviews at companies that test them, that's a separate goal and a fair one. For learning to build for the web, a real project teaches more than a hundred puzzles about prime numbers.
  • Your own login system for real users. Learn how sessions and password hashing work, absolutely. But for an app real people use, reach for a well-tested library. Understanding the idea is a great exercise; running a homemade one in production is a risk you don't need.

If you want to see which pieces I'd actually pick for a full app today, and why, modern full-stack development in 2026 walks through the whole stack. Read it as a map, not as a to-do list for this month.

Now, there's something that sounds like it contradicts this box, so let me clear it up. I believe a good programmer thinks three steps ahead: what happens with more users, what happens when something fails, what's the Plan B. That's true, and it doesn't clash with skipping Kubernetes. Thinking ahead costs you a sentence in your plan: "if this grows, the database is the first thing to watch". Building for a million users before you have ten costs you months. Think ahead always. Build ahead only when the problem shows up.

Use AI as a tutor, not a ghostwriter

Everything above assumes you use AI while you learn. Please do. The real question is how. A ghostwriter writes for you and you put your name on it, and you learn nothing. A tutor makes you do the work and helps when you're stuck. It's the same tool either way, and the difference is entirely in what you ask it.

Here's how I'd use it while learning, roughly in this order:

  • Try first, even badly. Write your own attempt before you ask. A wrong attempt gives you and the AI something concrete to talk about, and the gap between your attempt and the right answer is exactly the thing you need to learn.
  • Ask for a hint, not the answer. Something like: "Don't write the code. Tell me in one sentence what's wrong with my approach." One sentence is often enough.
  • Make it explain every line. When it does write code, ask what each line does and what breaks if you delete it. The second question teaches you more than the first.
  • Ask what it assumed. "List everything you assumed about the input and the user." The bugs usually live somewhere in that list.
  • Make it quiz you. "Ask me three questions about this code and don't give me the answers." If you can't answer them, you don't own that code yet.
  • Type the core yourself once. Not everything. But the heart of a feature, typed by your own hands one time, sticks in a way that pasted code never does.

Experienced developers use the same habits in a grown-up form: they talk the plan through first, then go step by step, and read what changed after every step. I described that routine in the vibe coding article, with the four questions I ask about every change.

And one realisation that took me a while. When the AI's answer isn't what I imagined, most of the time I could have asked better. It's a machine running maths over whatever you gave it. It can't know what's in your head, or what you saw on some other site last week. Learning to say exactly what you want is a programming skill in itself, and it's the same skill as writing good code: being precise about what should happen, and what must never happen.

tip

Be careful with what you paste. Never paste passwords, API keys, the contents of a .env file or real people's data into a chat with any AI tool. If you need help with code that uses a secret, swap in a fake value first. It's one habit worth having from day one, because once something is pasted, you can't take it back.

A roadmap for learning web development from scratch

Here's the order I'd learn web development in today. It's a guideline, not a course, and there are no deadlines on it, because everyone's pace is different. Each step ends with something small you can build, and each step says where AI fits in.

Step 1: HTML, CSS and how a page reaches the screen

What a page is made of, what the browser does with it, and how to make it readable on a phone. Start with building your first web page. Build one page about something you like, and make it work at phone width. Use AI to review your HTML for meaning and accessibility, not to write it for you.

Step 2: JavaScript, data and the page

Arrays, objects, functions, loops, events, and changing the page from code. This is where the order total lives. Build a list that renders from data, with a filter or a sort button. Use AI to explain lines and to quiz you, and do the exercise from this article before you ask it.

Step 3: forms and the server

Requests and responses for real, a tiny server, and checking input on both sides. Build a form that saves something on a server and refuses bad input in the browser and again on the server. Use AI to ask what it assumed, and compare its list with yours.

Step 4: a database, and who is asking

Rows and tables, one honest query, and signing in with a well-tested library instead of a homemade one. Build a list that belongs to the signed-in person, where one person can never see another's data, and write one test that proves it. This is where box one stops being theory.

Step 5: shipping it

Git, putting it online, environment variables for secrets, and reading logs when something goes wrong. Deploying full-stack apps to Vercel covers the putting-it-online part. Build: give it a real address and send it to one friend. Use AI for the mechanical checks, like listing every place where input enters your app, and keep the judgement calls for yourself.

The order matters more than the speed. And if you can, pick one real project that runs through all five steps, small and easy at first, harder each time. A simple shop page that grows into a shop with a cart. A list of your own things that grows into an inventory with accounts. That way every concept arrives attached to a reason, and that's what makes it stick.

About pace: you'll hear that you must study two or three hours every single day. I don't agree, especially at the start. Some days the code just won't go in, and forcing it teaches you to hate it. Take a day or two off when you need it, but don't let a break turn into a month, because without a rhythm nothing becomes a habit. One percent better a day, for a year, beats one heroic weekend and then nothing.

So that's all it is

Strip away the noise and it's simple. AI made typing cheap. It didn't make judging cheap. So you learn the things that let you judge: reading code, how a request travels, the shape of data, reading errors, the idea that the browser lies, and how to undo a bad change. You learn just enough of the rest to read it and test it. And you leave big-company architecture alone until a real problem asks for it.

The order total is the whole article in four lines. Anyone can get code that runs. The person who builds things that last, and the person worth hiring, is the one who looks at return subtotal + fields.shipping and asks: is this adding, or gluing?

info

If you're experienced and you help juniors: the review is where they learn now. When a junior opens a pull request an AI helped write, ask them to explain one function line by line and to say what breaks if a line goes. If they can, the tool helped them. If they can't, it wrote for them, and the kind thing is to say so early. Asking them to describe the expected behaviour as a test before any code exists trains exactly the box-one skills.

What to be careful about, and the Plan B

  • Tutorial hell moved into the chat window. Asking an AI forever feels like progress, the same way watching tutorials did. If you haven't built something you can explain with the chat closed, you're watching, not learning.
  • Confident and outdated. AI answers sound equally sure whether they're right or describe a version from two years ago. For anything tied to a framework or a library, check the version in the official docs.
  • Skipping box one because the output looks finished. The order total looked finished too. Looking finished isn't a test.
  • Comparing yourself to demos. Demos show the happy path in two minutes. Real apps are mostly the unhappy paths: empty fields, wrong input, slow networks, and people doing things you never expected.
  • Trying to keep up with everything. Learning while the tools change every month is tiring. Pick one tool, one stack and one project, and let the rest go past you for a while. It'll still be there.

And the Plan B. Some day the AI will be down, out of credits, or simply wrong in a way it can't see. Your Plan B is the boring stuff: the official docs, the error message read in three steps, a git restore, and a person you can ask. Not knowing something yet is fine. Plenty of people working in companies right now don't know everything and ask for help all the time. The difference is that they know what to ask, and after this article, you know a lot more about what to ask too.

What to learn next

If you're starting from zero, go to what is web development next and follow it in order, then build your first web page. If you've got the basics, read login form validation and then Zod at trust boundaries, because that's box one in practice. And if you'd like a second map from the people who write the browser docs, the free MDN Curriculum is organised the same way: core skills first, extensions later.

You can do this, and you have to. If you weren't capable, I wouldn't spend my time on you. Just don't give up, and you'll always have me on your side.