# Build First. Understand What You Build. Then Use AI to Build Faster. > Source: > Published: 2026-08-14 02:30:57+00:00 A few months ago I noticed something that bugged me enough to eventually write a book about it. AI coding tools are genuinely good now. Copilot, Claude, Cursor — you can describe a feature and watch working code appear in seconds. That's not hype, it's just true. But I kept running into the same pattern, in my own work and in conversations with other developers: there's a growing gap between being able to generate code and being able to tell whether that code is actually good. Not broken — broken is easy. It throws an error, you notice, you fix it. I mean the quieter failure mode: code that runs, looks reasonable, and is subtly wrong in a way you only catch if you already understand what "right" looks like. An unindexed database column that's fine at 10 rows and falls over at 100,000. An authorization check that works for the happy path and quietly leaks data the moment a null slips through. A component with three pieces of state where one would do. AI won't stop you from shipping any of that. It'll happily generate it, confidently, in about four seconds. So when I sat down to write a frontend development book, I made a deliberate call that I think goes against how most "AI coding" content is currently being written: no AI at all until the fundamentals are solid. HTML, CSS, JavaScript, React, Next.js — built by hand, understood completely, mistakes made and debugged the slow way. Only once that foundation exists does the book bring in Copilot, Claude, and Cursor — and even then, the framing isn't "here's how to prompt your way to a finished app." It's "here's how to read what the AI gives you and decide, yourself, whether it's actually right." The line I kept coming back to while writing it: Build first. Understand what you build. Then use AI to build faster. I didn't want a reader finishing the book thinking "now I know how to get AI to build things for me." I wanted them finishing it thinking "now I understand how these things get built, and I can use AI without handing over my ability to think and decide as a developer." The book's capstone is a small app — a Recipe Box — built three separate times: once by hand with vanilla HTML/CSS/JS, once in React, once in Next.js. Watching the same problem solved three different ways ended up being a better teacher than I expected going in. It makes the differences between the tools obvious instead of abstract. I just finished a second book that continues the same project into the backend — servers, databases, authentication, real deployment — applying the same rule. Backend mistakes are quieter and more expensive than frontend ones, so if "understand before you accelerate" matters anywhere, it matters there most. I'm genuinely curious how other developers here are navigating this. Are you teaching or learning AI-assisted development in a similar fundamentals-first order, or has it worked better for you to learn the tools alongside the basics from day one? I don't think there's one obviously correct answer yet — it's early enough that we're all sort of figuring it out in public. I wrote about this in more depth in a two-book series if anyone wants to dig further — [Frontend](https://leanpub.com/ai-assisted-frontend-development) and [Backend](https://leanpub.com/ai-assistedbackenddevelopment), each walking through the same idea from a different layer of the stack. Would love to hear how this lands with people living this exact tension day to day.