Every few months, someone announces that programming is over. AI writes code, so why learn to write code? The question is fair, especially if you are seventeen and choosing what to study for the next ten years.
But the question is also badly framed. AI did not make software easier to build. It made the first draft cheaper, which moved the bottleneck somewhere else. And the bottleneck is where the jobs are.
The worry is not stupid
Let us be honest about what is disappearing. The entry-level work that consisted of translating a clear specification into predictable code is under pressure. CRUD endpoints, admin dashboards, form validation, simple migrations, glue scripts, test scaffolding. Tools do these quickly, and they do them well enough that a senior can review instead of writing.
That work was never the whole job, but it was a large part of how juniors learned the job. You built a hundred boring screens, and somewhere in between you learned how systems fail. If that apprenticeship shrinks, the path from student to competent developer gets less obvious.
So the fear is not irrational. It is just aimed at the wrong target. The risk is not "AI writes code". The risk is "nobody trains the next generation because the training work was automated".
What AI actually automates
AI is good at tasks with a clear target and a fast feedback loop. Given a function signature and a description, it produces plausible code. Given an error message, it suggests a fix. Given a schema, it writes a query.
It is weak at things where the target is unclear, the context is messy, or the cost of being wrong is high:
- Deciding what to build, and what not to build.
- Understanding why a production system behaves differently from the test environment.
- Recognizing that the requirement itself is the bug.
- Taking responsibility when something breaks at 2 a.m.
Those are not soft skills bolted onto programming. They are the job. Writing code is how you express decisions, not a substitute for making them.
The part that got harder to fake
When code is cheap, correctness becomes the scarce good. That changes what a junior is expected to demonstrate.
Before, "I can build a login page" was a meaningful signal. Now anyone can generate one in a minute. The interesting question is whether you can explain:
- Why the session cookie is
HttpOnlyandSameSite=Lax. - What happens when the database is down during login.
- How you would rate-limit password attempts without locking out legitimate users.
- Where the password hash is stored, and why it is not encrypted.
The AI can produce the page. It cannot be accountable for the page. That gap is the job.
This is why "prompt engineer" as a career is mostly a misunderstanding. Prompting is a skill, not a profession. The profession is still engineering, with a new tool in the loop.
Fundamentals still compound
There is a tempting shortcut: skip the theory, let AI handle the details, and focus on shipping. It works until it does not.
The developers who benefit most from AI are the ones who can tell when it is wrong. That ability comes from fundamentals:
- Networking. DNS, TCP, TLS, HTTP. Why the request times out, and which layer to blame.
- Operating systems. Processes, memory, file descriptors. Why the container dies with exit code 137.
- Data structures and algorithms. Not to invert a binary tree on demand, but to know why a list scan inside a loop is slow.
- Databases. Indexes, transactions, isolation. Why the query is fast in staging and slow in production.
- Debugging. Reading logs, forming hypotheses, isolating variables.
None of this is obsolete. It is the difference between using a tool and being used by it.
Why vocational students have an advantage
If you are in SMK or a similar vocational track, the usual advice is to compete with university students on algorithms. That is a bad fight. Compete where the context is physical and local instead.
AI is very good at text. It is less useful when the problem is a printer that only works on one VLAN, a client whose router resets every afternoon, or a POS system that must keep running during a power cut. Those problems require presence, diagnosis, and trust.
Vocational strengths that remain valuable:
- Setting up and maintaining networks, servers, and devices.
- Talking to a small business owner and translating their problem into a system.
- Working with constraints: old hardware, slow internet, no budget.
- Handling the last mile: deployment, backup, support, documentation.
The last mile is where most software projects actually fail. It is unglamorous, it is local, and it is hard to automate.
The new junior checklist
If you are starting now, the goal is not to avoid AI. It is to be the person who can use it without losing the ability to think.
- Learn one language deeply. Not the syntax, the ecosystem: package manager, testing, debugging, profiling, deployment.
- Be able to explain every line you ship. If you cannot, you do not own it yet.
- Write tests before trusting generated code. Tests are how you turn a suggestion into a claim.
- Read code more than you write it. Open source projects, your own old code, the framework you use.
- Learn Linux and the command line. Almost every production problem eventually lands there.
- Learn SQL properly. Joins, indexes,
EXPLAIN, transactions. It outlives every framework. - Practice writing. Incident notes, pull request descriptions, documentation. Clear writing is now a leverage multiplier.
- Ship something end to end. Auth, database, deployment, backup, monitoring. One real system teaches more than ten tutorials.
Failure modes to avoid
Tutorial hell, version two. Watching AI build things feels like learning. It is not. If you never struggle with a bug, you never build the instincts to fix one.
Trusting plausible output. Generated code looks confident. It can invent APIs, ignore edge cases, and quietly change behavior. The compiler catches some of it. Tests catch more. Nothing catches everything except understanding.
Skipping the boring parts. Security, backups, error handling, and migrations are exactly the parts AI is most likely to get subtly wrong, because they depend on context it does not have.
Outsourcing judgment. The moment you stop asking "is this correct?" you are no longer engineering. You are copying.
A realistic twelve-month plan
If you are a student with limited time, this is a reasonable shape:
| Months | Focus |
|---|---|
| 1–2 | One language, one database, command line, Git |
| 3–4 | Build a small app with auth and tests, deploy it on a VPS |
| 5–6 | Add logging, backups, and a reverse proxy; break it on purpose and fix it |
| 7–8 | Read an open source project you use; fix a small issue |
| 9–10 | Learn performance basics: indexes, caching, profiling |
| 11–12 | Write about what you built, and rebuild one part better |
The point is not the list. The point is that every item produces evidence: a repository, a write-up, a working deployment. In a market where everyone can generate code, evidence of judgment is the differentiator.
What if you do not want to code?
IT is bigger than programming, and AI increases demand for people who can run the systems AI depends on. Networking, infrastructure, security, support, data, and technical operations are all real paths.
The common thread is the same: understand the system, verify the output, take responsibility. Those skills transfer whether you end up writing Go, managing a fleet of laptops, or running a small ISP.
For teachers and parents
If you are advising a student, resist two extremes. "AI will do everything, so don't bother" is wrong. "AI is cheating, ban it" is also wrong, and it prepares nobody for the workplace they will enter.
The useful position is in between: let students use the tools, then ask them to explain the result. Grade the reasoning, not the typing. And make sure they still touch real systems: a server, a network, a database that can break.
Honest uncertainty
Nobody knows how this plays out. Predictions about AI and employment have been wrong in both directions. It is possible that junior roles shrink for a few years while companies figure out the new shape of teams. It is also possible that cheaper software creates more software, and therefore more work.
What is safe to bet on is less exciting: fundamentals, judgment, communication, and the ability to verify. Those have survived every previous wave of abstraction, from compilers to frameworks to cloud.
AI is a power tool. The job is still to know what to build, to check whether it works, and to be the person who answers when it does not.
That job is not going away. It is just getting harder to bluff.