Every few weeks, somebody announces that learning to program is becoming pointless.
The argument usually sounds reasonable at first. AI can already generate functions, tests, interfaces, and entire applications. The models will keep improving. Why spend years learning what a machine can produce in a few minutes?
I understand the temptation.
Learning software development can be frustrating. You spend hours reading documentation, only to discover that the example uses an older version of the library. You fix one error and reveal three more. You finally understand a concept, then meet someone online who explains that your entire approach is wrong.
If AI can skip all of that and take us directly to working software, why would anyone choose the slower path?
Because producing an answer and knowing whether the answer is good are different skills.
AI is making the first one cheap. The second one still takes work.
The first prompt is usually the easy one
Ask an image model to design a small modern kitchen.
Keep the prompt vague and the first result will probably look convincing. The cabinets match, the lighting feels natural, and the layout appears reasonable.
At first glance, the model nailed it.
Then give it the room’s actual constraints.
The kitchen is 2.8 meters wide. The plumbing cannot move. There is a window on the back wall and a radiator underneath it. The refrigerator door needs enough clearance to open fully. The dishwasher has to sit near the sink. Two people should be able to move around without constantly getting in each other’s way.
Now ask for another design.
The new image keeps the style but blocks the window. You correct the window, and the refrigerator no longer opens properly. You fix the refrigerator, and the model moves the sink away from the plumbing. Another attempt looks perfect until you realize one of the cabinets is physically impossible to open.
The first image was easy because there were thousands of acceptable answers. The model only needed to produce something that looked like a modern kitchen.
The room specifications reduce those possibilities. The result now has to be attractive while also fitting a real space and respecting decisions that cannot be casually changed.
Software works the same way.
“Build me a project management application” leaves the model plenty of room. It can generate a sidebar, task cards, a settings page, and some sample users. The result may be good enough for a demo after one prompt.
Then the actual requirements appear.
Guests can comment but cannot create tasks. A user can belong to several workspaces with different permissions in each one. Deleting an account must preserve historical activity without exposing personal information. Notifications should behave differently for direct mentions and group mentions.
Each new requirement narrows the number of acceptable implementations.
The agent adds workspace permissions but breaks invitations. It fixes invitations and accidentally allows guests to see private projects. It handles deletion correctly but leaves old profile photos in an audit log.
None of this means the first demo was fake. The model generated real software and saved real time.
The mistake is treating the speed of the first attempt as evidence that the remaining work will be equally fast.
A demo needs to look convincing for a few minutes. A product has to survive specific requirements, conflicting expectations, strange inputs, and users who do things nobody planned for.
We also discover many specifications while building. A feature can match the original request and still feel wrong once we use it. The difficult decisions often appear after the first version exists.
AI gets us to those decisions sooner. That is useful.
It does not make the decisions for us, and it does not remove the tedious work of making every constraint fit at the same time.
The model looks smartest when I know the least
When I ask an AI model about a subject I understand well, its limitations are easy to see.
The answer may sound polished, but I notice the missing edge case. I can tell when it recommends a library that does not fit the project. I recognize the moment it invents an API or describes browser behavior that has never worked that way.
Sometimes the answer is mostly correct but subtly useless. It explains what the code does without understanding why the system was designed that way. It fixes the visible problem while breaking an assumption elsewhere.
I can catch those mistakes because I have context.
Then I ask the same model about a field I barely understand, and suddenly it seems brilliant.
The answer is clear. The terminology sounds appropriate. The explanation has enough detail to feel researched. I have no immediate reason to doubt it because I do not know where the weak points are.
The model did not become more accurate when I changed subjects. I became less qualified to notice its mistakes.
There is a name for a version of this problem: the Gell-Mann amnesia effect.
Michael Crichton used it to describe what happens when someone reads a newspaper article about a subject they understand. Imagine opening a newspaper and finding an article about JavaScript. You have worked with JavaScript for years, so the errors are obvious. The writer misunderstands how the runtime works, confuses a framework with the language, and repeats claims that a working developer could disprove in five minutes.
You finish the article thinking, “This is complete bullshit.”
Then you turn the page and read about giraffes. You know nothing about giraffes, so the article sounds informative. You accept it without carrying over any of the skepticism created by the JavaScript article.
AI produces the same effect.
When I ask about my own field, I can see the errors. When I ask about something unfamiliar, I forget how confidently the model was wrong five minutes earlier.
The problem may be worse with AI because the answer responds to me personally. A newspaper article cannot defend itself. A model can respond to every objection with another page of fluent reasoning. Each follow-up answer can increase my confidence without increasing the model’s accuracy.
This is especially uncomfortable because one of AI’s biggest advantages is that it lets us work outside our existing expertise. I can ask an agent to write code in a language I have barely used. I can have it configure infrastructure I have never worked with or implement an authentication protocol I only vaguely understand.
It may produce something that works.
“Works” is carrying a lot of weight in that sentence.
Does it work because the design is sound? Does it work because the test covered one happy path? Does it work until a user sends an unexpected input? Does it work while quietly creating a security problem I do not know enough to recognize?
I am most dependent on the model in the exact situations where I am least capable of checking it.
That does not mean I should avoid using it. It means I need to stop confusing fluency with correctness.
The confidence of the answer cannot be my verification. If the subject matters, I need evidence outside the conversation.
Learning is how you earn judgment
People sometimes treat programming knowledge as a collection of facts that can now be retrieved from a model.
Why memorize syntax when AI can generate it? Why learn algorithms when a model can select one? Why study databases when an agent can build the schema?
I agree with the first question more than the others. Memorizing syntax has never been the most interesting part of programming. I still forget basic details in languages I have used for years. Looking things up is normal.
But learning is not mainly about storing syntax.
It changes what I notice.
If I understand how indexes work, I can recognize a query that will become painful as the table grows. If I understand HTTP, I can question a strange caching bug instead of randomly changing client code. If I have spent time learning about authentication, I know that “just add login” is not a small request.
The model can explain all those topics. It can also generate code for them. I still need enough understanding to ask whether its choices make sense.
This is why I dislike the idea that developers should only learn concepts they know they will use.
How could I know what will become useful before I understand it?
I might never write SIMD code in production. Spending an hour learning what SIMD does can still teach me what kinds of problems benefit from processing many values at once. Years later, that knowledge may be the reason I recognize a performance opportunity.
I might never build a compiler. Learning how parsing and type checking work can still help me understand the tools I use every day.
Not every subject needs months of study. Sometimes an afternoon is enough to add a new shape to the mental map. That shape sits there until a future problem matches it.
I would rather know something I never use than repeatedly decide that understanding is unnecessary.
AI is also the best learning tool I have had
There is an irony here. AI gives us new ways to avoid learning, but it is also ridiculously good at helping us learn.
Before these models existed, getting started in an unfamiliar area had a specific kind of friction.
I often did not know the correct vocabulary. Search engines work well when you know what to search for. They are less helpful when your question is basically, “There is a weird thing happening somewhere around this part of the system. What is that called?”
Documentation has the same problem. Good documentation usually assumes that I already know which page I need. Technical books are useful, but I may need several chapters before reaching the one concept blocking me today.
With AI, I can begin with a badly formed question.
I can ask for a simple explanation, then request a more technical one. I can paste in code and ask how the concept appears there. If the explanation assumes knowledge I do not have, I can stop and ask about that missing piece.
I can be wrong in private for as long as necessary.
That is a massive improvement over pretending to understand a discussion because everyone else seems several steps ahead.
AI can also meet me at the level I need. If I want the broad idea, it can give me that. If I want to see memory layouts or walk through each operation, it can keep going.
Of course, it may teach me something incorrectly. The earlier problem has not vanished.
I deal with that by treating the model as a tutor I can question, not an authority I must obey. I ask it to explain the same idea in different ways. I compare the answer with official documentation. I write a small program and see what happens.
The ability to run the example matters. Programming gives us unusually direct feedback. The code compiles or it does not. The test passes or it fails. The benchmark supports the claim or makes it look silly.
This is one reason learning through small projects works so well. An explanation can sound convincing for pages. A concrete experiment has less patience for bullshit.
Knowing more does not mean reading everything
There is a possible overreaction to all of this.
If AI can make mistakes, maybe developers should inspect every generated line. Maybe every change requires the same review we would give security-critical code.
I do not think that scales, and I do not think it is necessary.
AI has made code cheap enough to use as scratch paper.
I can generate a temporary script to reorganize files. I can ask for a throwaway benchmark or have an agent build several versions of a feature so I can compare them. I can generate code that exists only to test whether an idea is possible.
Reading every line of that code would defeat much of the point.
The amount of verification should depend on what the code can damage.
If a one-time script operates on copied data inside a temporary directory, I may run it, inspect the output, and move on. If the same script is about to modify production records, I want to understand exactly what it will do.
Code that helps me test a theory can be disposable. Code that controls authentication, payments, user data, or permissions needs much more attention.
This is not a perfect classification. Software has a habit of turning supposedly harmless code into important infrastructure. A script written for one afternoon somehow ends up running every night for three years.
Still, risk gives us a better starting point than treating every generated line as equally important.
Tests help too, but they do not remove the need for understanding. A model can write a function and then write tests that confirm its own misunderstanding. Ten green checkmarks only prove that the implementation agrees with the tests.
I want tests that attack the assumptions, especially when I did not write the implementation myself.
Sometimes I ask another model to review the first model’s work. That can catch obvious problems, although models share enough habits that agreement between them does not guarantee much.
For important work, I still want a human who understands the area.
Experience shows up when the obvious answer is wrong
One of the best uses of AI coding agents is diagnosis.
An agent can search a repository much faster than I can. It can add logging, trace calls, compare implementations, and build a custom tool to test one theory. Even when it does not solve the problem, it can shorten the investigation.
It can also waste hours pursuing a plausible explanation that does not match the evidence.
This is where experienced engineers keep proving their usefulness.
Experience is not a magical ability to know every answer. It is often the ability to feel uncomfortable with the answer everyone else has accepted.
A performance problem appears, and the agent blames the obvious component. The experienced engineer notices that the timing does not fit. A bug looks like a database issue, but someone remembers that the browser behaves strangely under one specific condition.
That knowledge may come from a book. More often, it comes from having lost an afternoon to a similar problem five years ago.
The agent does not need to replace that engineer to be useful. It can build the tools the engineer needs, run experiments, and eliminate bad theories.
I care less about whether the model independently reaches the answer than whether it helps us reach evidence.
The distinction matters. If I expect the agent to be an autonomous expert, every failure looks like proof that AI is useless. If I use it as a fast and flexible tool, it can still save hours while being wrong about the final diagnosis.
That is how I use these systems now.
Sometimes the agent solves the whole problem. Sometimes it produces the little diagnostic program that lets me solve it. Both outcomes are useful.
Better environments beat better prompts
People spend a lot of time trying to discover the perfect prompt.
Prompts matter, but the environment around the agent matters more than most prompting tricks.
A repository with fast tests gives the agent immediate feedback. Clear interfaces reduce the number of assumptions it must make. Useful error messages keep it from wandering through unrelated parts of the codebase.
Documentation helps when it explains decisions rather than listing file locations. An agent can search for a file. It has a harder time discovering the unwritten reason a team rejected an apparently simpler design two years ago.
This work also helps human developers.
That is why I see AI as another reason to invest in good engineering practices rather than an excuse to abandon them. The same setup that helps a new employee contribute safely helps an agent.
If an agent repeatedly makes the same mistake, I do not want to add a sentence to a giant instruction file and hope it remembers. I want a test, a type constraint, a lint rule, or an API that makes the mistake difficult.
Good engineering turns knowledge into systems.
That was true before AI. It matters more when code can be generated at a much higher rate.
A weak process lets us create bugs faster. A strong process gives us more chances to catch them before users do.
Curiosity is still a competitive advantage
The fear around AI encourages two bad reactions.
One is total rejection. The tools make mistakes, so some developers decide there is nothing worth learning from them.
The other is surrender. The tools are improving, so some developers decide there is nothing worth learning except how to use them.
Both reactions give up too much.
I want to understand the tools and the systems they modify.
I want to know how an agent works, where it gets confused, and which tasks it handles well. I also want to understand databases, operating systems, networking, browsers, and whatever unfamiliar subject my next project forces me to confront.
I will never know all of it. That used to bother me more than it does now.
AI makes the size of the unknown feel less threatening because I have somewhere to begin. I can ask the stupid question, build the tiny example, and continue until I know enough to make a decision.
That is a reason to become more curious.
The developers who keep learning will be harder to fool. They will know when a model’s confidence exceeds its evidence. They will ask better questions and build better checks around the answers.
They will also get more from the tools because they can direct them toward problems worth solving.
I do not want AI to think for me
I want AI to help me think.
That may sound like a small distinction, but it changes how I use it.
If I ask a model to make every decision, I become dependent on answers I cannot evaluate. The software may work, but I do not know why. When it fails, I have nowhere to begin except asking the same system that created the problem.
If I use the model to explore, explain, search, and test, I remain involved in the process. I learn enough to understand the tradeoffs. I can reject the first answer and ask for something better.
This approach is slower than blindly accepting everything an agent produces.
It is still much faster than working without the agent.
That is the balance I want. I do not need to choose between writing every character manually and handing the project to a machine. Most useful work happens somewhere between those extremes.
AI can remove a lot of tedious effort from programming. I am happy to let it.
I do not want it to remove the part where I understand what I am building.
That part is the job.