AI & automation
The children of the prompt
They may learn to talk to machines before they learn to build their own solutions.
AI & automation
They may learn to talk to machines before they learn to build their own solutions.
A student gets an assignment.
Opens a laptop.
Copies the question.
Adds: "Explain it step by step."
Seconds later, an answer appears.
Clean.
Structured.
Sometimes even with a neat conclusion.
One question remains.
What did the student learn between asking the question and getting the answer?
I have nothing against this imaginary student.
At that age, I'd probably have been tempted to do exactly the same thing.
When I started learning software development, understanding an error sometimes meant hours of research.
Reading the documentation.
Comparing answers on forums.
Trying one solution.
Then another.
Sometimes spending an entire evening on a semicolon or a configuration detail.
It wasn't always a valuable learning experience.
Sometimes it was just annoying. π
Today, an assistant can explain an error in plain language, offer examples and adapt to your level.
That's a remarkable opportunity.
But it also changes our relationship with difficulty.
There's a difference between asking for help and outsourcing the whole process of thinking.
In the first case, you want to understand.
In the second, you mostly want a result.
Both can be useful in different situations.
An experienced developer doesn't need to reinvent every function to prove they know how to code.
But for a beginner, some struggles are valuable.
Getting a condition wrong.
Understanding why a loop never ends.
Finding a counterexample that disproves your first idea.
Those are ways of developing intuition.
If a machine always handles those steps, it can become difficult to tell what we truly understand.
Imagine a young developer generating an entire app with an AI assistant.
It launches.
The interface looks great.
The buttons work.
Excellent.
Now ask them why the data is organised that way.
How permissions are checked.
What happens if two users update the same record.
Or how to recover the service after an outage.
If they can't answer, it doesn't mean they have no talent.
It means the product they obtained and the knowledge they possess aren't yet the same thing.
I explored that distinction in The code I no longer understand.
Banning every AI tool seems like an overly simple answer.
Pretending the tools don't exist won't make them disappear.
But treating every generated result as proof of learning would be just as misleading.
We could ask students to explain their reasoning.
Critique an AI-generated response.
Spot an error.
Defend a decision.
Or occasionally complete an exercise without assistance, simply to find out what they can do independently.
The point wouldn't be to punish tool use.
It would be to make sure the student can still think both with the tool and without it.
This isn't only a school problem.
Working developers can become dependent on instant answers too.
When I ask an AI to suggest a solution, I try to keep a habit: read what it produces and verify the parts that really matter.
Not because I need to write every line myself.
But because when something breaks, I'm the one who needs to understand why.
Speed is useful.
Understanding remains a responsibility.
Not necessarily.
Every generation has tools the previous one didn't.
Calculators didn't eliminate mathematics.
Search engines didn't eliminate the need to evaluate information.
And AI won't automatically eliminate curiosity.
But none of these tools guarantees that we learn to use them well.
That depends on what we choose to teach.
I hope the children growing up with AI assistants will build things we couldn't even imagine.
I also hope they'll experience the joy of finally understanding a problem after struggling with it.
That moment when the solution becomes obvious.
Not because a screen has just displayed it.
But because they can actually see why it works.
The next generation may find it easy to get answers.
Our challenge will be teaching them not to give up on questions.