We are living through a strange moment in software.
For the first time, someone with no technical background can describe an application in plain language and receive something that looks finished. A landing page, a dashboard, a small product, all from a prompt. And for many people, that is enough. They can become a proud full-application maker without knowing how the technology works, what trade-offs were made, or how the thing was actually built.
That is not a criticism. It is a real capability, and it is changing what “building software” means for a lot of people.
But it also raises a question we should take seriously: what does it mean to become a developer?
The Difference Between Making and Becoming
There is a meaningful gap between shipping an outcome and developing a craft.
An app maker is goal-oriented. The prompt works, the interface loads, the demo impresses someone in a meeting. That is the finish line. The process behind it is invisible, and often irrelevant.
A developer is process-oriented. They are not satisfied when something merely works. They want to understand why it works, what assumptions were baked in, and where it will break under pressure. They do not treat the output as the end. They treat it as a starting point for the next question.
That disposition has a name: curiosity.
More Than a Personality Trait
We often talk about curiosity as a personality trait, something nice to have, like being a good communicator or a team player. In software, that framing undersells it.
Curiosity is the mechanism by which developers learn.
When a junior developer manually wrote boilerplate, hunted syntax errors, and traced bugs through unfamiliar code, they were not just doing labor. They were feeding curiosity with friction. Every mistake was a question. Every fix was a small answer. Over time, those answers stacked into mental models: how state flows, how systems fail, how small changes ripple through a codebase.
AI has removed much of that friction. That is mostly a good thing. But it also means the old path to curiosity, being forced into the details by necessity, is no longer automatic.
The curious developer still goes looking. The goal-oriented builder stops at the prompt.
What Curiosity Looks Like in Practice
Curiosity in a developer is not abstract. It shows up in specific behaviors:
- They ask “how” before “what.” Not just what the code does, but how it was structured and why that structure was chosen.
- They poke at working things. A feature that passes tests is not the end of the inquiry. They want to know what happens at the edges: empty inputs, slow networks, concurrent requests.
- They improve in small increments. Not because a manager asked, but because something felt slightly off and they could not leave it alone.
- They treat AI output as a hypothesis, not an answer. The generated code is a starting point for investigation, not a finished artifact to ship.
These are not senior-level behaviors. They are the behaviors that produce senior developers.
Why This Matters More in the AI Era
In my earlier writing, I have argued that AI is raising the floor of engineering and shifting the developer role from coder to orchestrator. I still believe that. But orchestration without understanding is just delegation. Delegation without curiosity is blind trust.
The non-developer who prompts their way to a working app often lacks the system familiarity to know when the output is wrong, incomplete, or fragile. They see the surface. The curious developer sees the structure beneath it.
This is why the “anyone can build an app now” narrative, while technically true, misses the point for our profession. Building is easier. Becoming a developer is not.
Becoming a developer requires a sustained interest in how things are built, not just that they were built. It requires caring about the process even when the outcome already looks good enough.
Curiosity Will Save Us
Here is the part I want to emphasize.
There will always be new developers, as long as there are curious people.
Not people who want to finish a project. Not people who want to impress with a demo. People who hear that something works and immediately wonder how. People who cannot look at a bug without wanting to trace it to its root. People who find satisfaction not in shipping, but in understanding a little more than they did yesterday.
AI will continue to change the tools. The floor will keep rising. The role will keep evolving. But the trait that separates someone who uses software tools from someone who grows into an engineer has not changed.
Curiosity is process-oriented. It does not chase outcomes. It chases understanding. And in an era where outcomes are cheap, that disposition is not a nice-to-have.
It is the thing that will save us as developers.
Photo by Christina @ wocintechchat.com on Unsplash.
A Note for Mentors and Leaders
If you are mentoring junior developers today, the question is not whether AI will replace the old learning path. It already has.
The question is whether you are creating space for curiosity.
That means encouraging questions that go beyond “does it work?” It means treating AI-generated code as material for investigation, not as finished work. It means valuing the developer who says “I want to understand this before we ship it” as much as the one who ships fastest.
We do not need to teach syntax the way we used to. But we need to protect, and actively cultivate, the curiosity that turns a person with tools into a person with craft.
The app makers will keep coming. That is fine. They will build things, and some of those things will matter.
The developers will come too, as long as we remember what actually makes one.