Ask a junior developer to explain what happens after a submit button is clicked. Most can’t give a clear answer. For those who can, you’ll probably hear something like:
“An API call is made to the back-end server and a response is returned.”
Fair enough.
But probe a little further. Ask how the browser packages that request. Ask what HTTP method is being used. Ask where authentication comes into play. Ask how the server processes the request before the data ends up in a database.
That’s usually where the silence begins.
This isn’t because junior developers are lazy or incapable. We are not producing bad developers. We are producing developers with missing context.
Somewhere along the way, we’ve started teaching abstractions before foundations.
Many boot-camps and online tutorials optimize for outcomes. The promise is simple: build a portfolio, get job-ready, land your first role. React fits perfectly into that narrative because the results are immediate. You can build something impressive very quickly.
The problem is that many learners are introduced to frameworks before they understand the systems those frameworks abstract away.
They learn React before HTTP.
Components before servers.
State management before databases.
Authentication libraries before authentication itself.
And while there’s nothing inherently wrong with React, teaching it too early often creates developers who know what to do, but not necessarily why they’re doing it.
The consequences usually show up later.
Many developers fall into what is commonly called “tutorial hell”, following along with project videos, copying code line by line, and feeling productive until it’s time to build something independently. Suddenly, the confidence disappears because understanding was mistaken for familiarity.
The same concern exists with AI-assisted development.
To be clear, I’m not against AI. I use it regularly. Tools like ChatGPT, Claude, and Codex can significantly improve productivity. The issue arises when they replace thinking instead of supporting it.
Debugging used to force developers into uncomfortable situations. You had to read documentation, search for solutions, experiment, fail repeatedly, and eventually understand the root cause of a problem. That struggle wasn’t wasted effort; it was training.
If every obstacle is immediately outsourced to an AI assistant, we risk skipping the very experiences that develop engineering judgment.
This is especially concerning because software development isn’t just about producing working code. As developers grow, they are expected to make decisions, evaluate trade-offs, anticipate failure points, and understand the implications of the systems they build.
That level of competence isn’t developed through prompting alone.
If I were designing a web development curriculum, this is the order I’d teach things:
- HTML/CSS
- JavaScript fundamentals
- Browser fundamentals
- HTTP and APIs
- Basic back-end concepts
- Databases
- Authentication and authorization
- Then React
By the time students reach React, they wouldn’t just know how to use useEffect; they would understand why data fetching exists in the first place. They wouldn’t just know how to submit forms; they would understand what happens after the submit button is clicked.
React isn’t the problem.
AI isn’t the problem.
The problem is that we’re moving people through the foundations too quickly and expecting the gaps to fill themselves over time.
Sometimes they do.
Often, they don’t.
So I’ll end with this question:
Are we gatekeeping, or are we teaching the next generation of developers to build without truly understanding what they’re building?
