There’s a version of this take that leads with doom, the one where AI eats front-end development whole and leaves the rest of us writing prompts for a living. I don’t buy it. Not because AI isn’t impressive, but because the thing it keeps getting wrong is the part that actually matters.
Here’s what I’ve noticed: AI is excellent at generating plausible-looking code. It’s fast, it’s confident, and it will absolutely produce markup that renders. It just won’t always produce markup that’s right. And the gap between “renders” and “right” is exactly where your expertise lives.
Where the wheels fall off
Ask an AI to build a modal dialog. You’ll get something that opens and closes. What you probably won’t get, without careful prompting, is a component that traps focus, manages aria-hidden on the content behind it, responds correctly to the Escape key, and doesn’t blow up on iOS Safari. It’ll look done. It won’t be done.
That’s not a knock on the tooling. It’s a constraint that won’t disappear with a better model. Because knowing why those things matter requires knowing how assistive technology actually consumes a document, how browsers implement the accessibility tree, and what a real user running NVDA or VoiceOver experiences. You can’t prompt your way to that understanding. You have to have it.
The same holds for CSS. AI will write you a layout. Sometimes it’s even clean. But when the component breaks at a viewport nobody anticipated, or specificity fights start bubbling up two sprints later, you need someone who actually knows the cascade. Not someone who can describe the cascade in a system prompt.
The floor just got higher
Here’s the thing though: AI has absolutely changed the job. The tedious scaffolding work I used to spend an afternoon on, boilerplate components, repetitive utility functions, first-draft markup structures, I can knock that out in minutes now. That’s real, and it’s not going back.
What that means for us, as practitioners, is that the floor got higher. The rote stuff is cheap now. What you bring to the table has to be the judgment that sits above it: knowing when generated code is subtly broken, catching the semantic HTML mistake that a linter won’t flag, understanding why a particular ARIA pattern is wrong for this context even if it’s technically valid.
The people who will struggle are the ones who let AI handle the fundamentals and never built a foundation under it.
Sound markup isn’t a nice-to-have
I keep coming back to this: HTML is not an implementation detail. The document structure you ship is the contract with every browser, every crawler, every assistive device, and every future developer who touches the codebase. When that structure is wrong, everything downstream is wrong. No amount of CSS trickery or JavaScript patching covers it.
A <div> that looks like a button is still a <div>. A heading hierarchy chosen for visual reasons rather than semantic ones is still broken. These aren’t the things an AI catches consistently, and they’re not the things a junior developer without a strong foundation will catch either. They’re the things you catch, because you’ve spent years building an intuition for what well-formed markup feels like.
What this actually means for your practice
If you’re running a solo shop or small agency, this is mostly good news. AI handles more of the mechanical work. Your job is to be the engineer who knows what “done” actually means, and who can look at generated output and say, authoritatively, whether it clears the bar.
That requires maintaining the fundamentals. Reading specs. Keeping up with the accessibility guidance. Staying curious about what browsers are actually doing with your markup, not just whether it looks right in Chrome.
The developers who treat their HTML, CSS, and JavaScript knowledge as the foundation, rather than a fallback for when AI fails, are the ones whose work will age well.
I would love to hear how other developers are thinking about this balance. Let me know.