At a parents’ meeting, a mother told me about her son. He attends a vocational school, where he studies programming. His year of study is roughly equivalent to the eleventh grade at a general secondary school. According to her, about half of his group had decided to change their planned profession after the sudden arrival of widely available AI tools. There had even been a discussion about disbanding the group. Should he leave programming too?
I told her not to panic. I also made a half-serious joke: sometimes a junior or mid-level developer is cheaper than the stream of AI tokens a company would spend trying to replace one. Behind the joke is a serious point. Software does not arrive at a business as a single perfect answer to a prompt. Someone has to understand the problem, keep the context together, make the result work with existing systems and take responsibility when it fails. Companies are discovering how valuable that person remains.
🧠My answer to the mother: Software development is not a dead end. Her son should continue learning to program, become skilled at using AI in his work and, if it interests him, learn to build AI-enabled systems and work deeply with data. I see a strong future over the coming decade for developers who combine those abilities and keep learning.
What struck me about her story was not that teenagers were afraid of a new tool. Fear is understandable when a tool appears to do, in seconds, something a student has spent years learning. What worried me was the speed with which that fear had turned into a decision to abandon a profession before the students had seen what the profession really involves. If a young person enjoys building software, this is a moment to broaden the craft, not walk away from it.
🧩 First, separate a job title from the work
People often use “programmer”, “coder”, “software developer” and “software engineer” as if they were the same job. They overlap, but the distinction matters when someone says that AI has “replaced programming”.
Producing a function from a detailed specification is one task. Deciding what should be built, translating an ambiguous need into requirements, choosing data structures and interfaces, testing failure cases, protecting private information, deploying safely and maintaining the system are other tasks. AI may make the first task faster in some settings. That does not remove responsibility for the rest. It can also create more software to review and maintain.
The distinction appears in the latest U.S. Bureau of Labor Statistics occupational projections. For 2025–2035, BLS projects 10.2% employment growth for software developers and a 7.3% decline for computer programmers as separately classified occupations. It projects 34.6% growth for data scientists and 21.0% for information security analysts. Notice where the expansion sits: building systems, working with data and keeping technology dependable. These are directions a student can reach from a strong programming foundation. BLS occupational projections
The World Economic Forum’s 2025 Future of Jobs report finds that surveyed employers expect software and application developers, AI and machine-learning specialists, and big-data specialists among faster-growing roles through 2030. The mother’s son does not have to choose between programming and AI. Programming can be the route into making AI useful.
A parent can therefore ask a better question than “Will programmers exist?” Ask: Which part of making useful software does my child enjoy enough to practise deeply, and what evidence can they show that they can do it?
| Task | What AI may help with | What the learner must still demonstrate |
|---|---|---|
| A small feature | Drafting code, examples and alternatives | Clear requirements, integration, tests and review |
| A data pipeline | Generating queries and transformations | Correct measures, access controls, lineage and quality checks |
| A user interface | Prototyping components and copy | Accessibility, user research, behavior under edge cases |
| A bug fix | Suggesting hypotheses or patches | Reproduction, root-cause reasoning and regression evidence |
| A release | Summarising changes and drafting notes | Authorization, deployment checks, rollback and ownership |
🤖 What the AI evidence actually says
AI coding assistance is real. In one controlled GitHub study, 95 professional developers built a JavaScript HTTP server with or without Copilot. The group using Copilot completed the task faster on average. A student should learn to use that advantage. GitHub’s study
A different randomized study by METR followed 16 experienced open-source developers doing 246 tasks in repositories they knew well. With the early-2025 AI tools in the study, they took 19% longer on average. Experienced developers had to understand the surrounding system and check proposed changes. The two studies tell me that knowing how to work with AI is a skill of its own. METR study
Anthropic’s analysis of its coding tools shows how much coding work people already hand to AI and how often they return to review and iterate. That is the kind of partnership a new developer should learn: ask a tool to move quickly, then bring enough knowledge to see what it has missed. Anthropic Economic Index: software development
đź’° Why a developer can still be the better investment
My token joke was really about the difference between a demonstration and a working product. Imagine a small company asking an AI agent to add a booking feature. In a demo, the agent produces an attractive screen in minutes. Then the company discovers that its existing customer records use different names, bookings can be changed by phone, two staff members may edit the same slot, and an error can send a customer to the wrong place. The prompt was easy. Understanding the business was the work.
Now imagine a junior developer who has spent a week with the staff. She asks how a booking is confirmed, which record is authoritative and what should happen when a customer cancels. She writes a modest first version, uses AI to accelerate routine code, tests the difficult cases and returns the next day to fix what users find. The manager is not choosing between “a human” and “AI”. The manager is choosing who will make the system useful and keep it working.
AI services also have an operating cost. A company may pay for models, integrations and repeated runs, then pay people to check and repair the output. In some workflows a junior or mid-level developer who knows the context can be better value than a long chain of model calls. In others, the developer and AI together will be faster than either alone. That is why I told the mother that the appearance of cheap generated code is not the same thing as the end of a development job.
For her son, the implication is encouraging and demanding at the same time. He should learn to produce a first version faster with AI, while developing the judgment to ask what the customer needs, where the data come from and how the result will be maintained. The tool can write a draft. The developer turns it into a dependable service. When he can do both, he is much more valuable than someone who refuses AI or someone who can only copy its answer.
🧱 What to learn before specialising in AI
Before I suggest any new tool to the student, I would tell him something older developers already know: the job has never stood still. Over the last twenty years, teams have moved through new web frameworks, mobile platforms, cloud services, data systems, security expectations and ways of shipping software. A developer who learned one language at school could not simply keep the same textbook open for an entire career. We learned a concept, used it, watched a better tool appear and learned again.
AI makes this rhythm more visible. When a model writes a function in seconds, the beginner may feel that the months spent learning syntax were wasted. They were not. Without that foundation, it is hard to see why the function fails, what it assumes or whether it fits the rest of the application. It is like being handed a powerful workshop machine before learning to read a drawing or recognize a bad joint. The machine changes how much work one person can do; it does not remove the need for craft.
This is also why I encouraged the mother to think beyond the word “programmer”. Her son can learn to use AI to speed up ordinary development, then move toward building AI-enabled features himself. That may mean connecting a model to a product, preparing trustworthy data, testing answers, designing a useful interface or working with a team that develops models. He does not have to choose all of those routes today. A school programming specialization gives him a starting language for exploring them.
I would ask him to keep a simple habit: every few months, identify one change in his field, learn enough to build a small example and explain what the new approach solves better than the old one. A student who can do that with AI now will be ready to do it again when the next shift arrives. The point is not to chase every announcement. It is to become comfortable learning, fixing mistakes and improving a real piece of work.
The first layer is ordinary software competence. AI can generate syntax, but a student still needs to explain why a program behaves as it does. That includes variables, data structures, control flow, functions, error handling, debugging, version control and basic algorithms. It also includes the habit of reading documentation and tracing a problem rather than repeatedly asking for a new answer.
The second layer is systems thinking. A useful application stores and retrieves data, authenticates users, handles failures, logs events, protects secrets, tests changes and can be deployed or rolled back. A student does not have to master every cloud platform. They should be able to describe one small application end to end and explain what would happen if the database were unavailable or a user entered unexpected input.
The third layer is data competence. “Work with AI” is often a data problem before it is a model problem. Students should be able to define a measure, inspect a dataset, write basic SQL, handle missing values and document where information came from. When the student eventually builds an AI feature, these habits will help him make it useful for a real person rather than only impressive on a screen.
The fourth layer is responsibility. A developer learns to protect passwords and personal information, give people only the access they need, and check what a system does when something goes wrong. The student can practise this in school projects by using invented data, explaining who is allowed to change a record and showing how an error is corrected. Responsibility becomes a normal part of building, not a separate lecture added at the end.
The fifth layer is communication. A developer needs to ask what the user is trying to accomplish, show a prototype, explain trade-offs and document what is still uncertain. Many early-career candidates can demonstrate syntax. Fewer can demonstrate that they can receive a messy request, turn it into a testable result and explain why it is safe to use.
These layers can be learned in parallel, but the order of dependency matters. A learner who cannot debug a simple non-AI application will struggle to diagnose an AI system whose behavior is probabilistic and whose data may be imperfect.
🧪 A 26-week learning and evidence plan
The plan assumes the student has schoolwork and cannot treat career preparation as a full-time job. A manageable commitment might be three focused sessions each week: one for concepts, one for building and one for reviewing. The exact hours should fit the family and school timetable. Each phase ends with an artifact that a teacher, mentor or potential employer can inspect.
Weeks 1–4: Build a small program without AI first
Choose a problem that matters to the student: a sports-club schedule, a study tracker, a local event list or a household inventory. Write a one-page problem statement with a user, a task and three acceptance tests. Build a minimal version in a language taught at school. Keep the code in version control and write a README explaining how to run it.
Use AI only after making a first attempt. Ask it to critique tests or explain an error, then verify the explanation against the code. The artifact is a working program with a short change log: what the student wrote, what AI suggested and what was accepted or rejected. The decision point is basic interest. Does the student enjoy making the program work, or only watching an instant demonstration?
Weeks 5–8: Add data and make the result reproducible
Add a small, lawful, non-sensitive dataset. Define the meaning of each field, handle missing or inconsistent values and write at least five tests. If the project uses a database, include a simple schema and a query that answers a real question. Make setup reproducible for another computer.
The artifact is a data dictionary, tested data flow and a brief explanation of a wrong result the learner found and fixed. The decision point is whether data work feels engaging. A student who enjoys cleaning, modeling and explaining data may prefer data engineering or analytics; one who enjoys interfaces may choose product software.
Weeks 9–12: Use an AI coding tool with a verification protocol
Now use an AI assistant for a bounded feature. Give it a specification that contains expected behavior, edge cases and constraints. Review every generated change. Run tests, inspect dependencies and record any false claim or unsuitable shortcut. Rebuild one small part without the tool so the student can demonstrate independent understanding.
The artifact is a pull request or equivalent change set with a test log and a one-page record of where AI helped. The student can show a teacher which suggestion saved time, which one failed and what he changed. That is a much better conversation about AI than arguing over whether using it counts as “real programming”.
Weeks 13–18: Explore one adjacent specialization
Choose one branch. A data branch might create a scheduled data pipeline with checks and a dashboard. A security branch might threat-model the application and close a vulnerability. A user-experience branch might test accessibility and revise the interface with feedback. An AI branch might build a small retrieval tool using only approved public documents, measure whether answers are grounded and display when it does not know.
The artifact is a focused second project with a clear comparison against the first version. The student should be able to explain what went wrong and what changed. Specialization is a hypothesis to test, not a permanent identity chosen at 16 or 17.
Weeks 19–22: Work with another human
Find a teacher, school project, club or volunteer organization willing to state a small need. Agree on scope, deadline, access and who will review the result. Avoid handling sensitive personal data. Deliver a demo and written handover. Ask the user what was confusing and revise one thing.
The artifact is an accepted outcome with human feedback, not just a GitHub repository. It shows the part of software work that is easy to overlook: listening, negotiation, usability and accountability.
Weeks 23–26: Review the evidence and choose the next step
Put the projects into a two-page portfolio: problem, user, decision, architecture, tests, AI use, limitations and next improvement. Ask three people with different perspectives to review it. Compare possible next routes: further software study, an apprenticeship, a data pathway, security, design, product work or a broader academic programme.
The final conversation can focus on a practical question: “Which next opportunity fits what this learner has enjoyed and demonstrated?” A six-month portfolio gives the family something visible to discuss with teachers, developers and potential employers.
| Review question | Evidence to inspect | Action if weak |
|---|---|---|
| Can the student explain the code? | Live walkthrough without AI | Rebuild a smaller feature |
| Can another person run the project? | README and setup test | Improve documentation and dependencies |
| Does the work solve a real need? | User feedback or acceptance test | Narrow the problem and retest |
| Are AI outputs checked? | Tests, review notes, rejected suggestions | Add a review protocol |
| Is there a preferred branch? | Energy and quality across projects | Try one different branch before committing |
đź‘Ş What should a worried parent do this month?
Start with a conversation that separates fear from interest. Ask the student what they liked about software development before the AI headlines arrived. Was it logical puzzles, making a useful tool, visual design, working with data, collaboration or the promise of a particular salary? These answers point to different experiments.
Then speak with the school about the group’s future. Ask whether disbanding it was discussed, what the school plans to do now, which languages and tools are taught and how AI will be included in programming projects. Students need a reason to see the programme as current and connected to the work they hope to do.
Look at real local opportunities with the student. Review apprenticeships, university requirements, junior vacancies and portfolio examples in the country where the learner may work. U.S. projections are a useful counterweight to panic, but local hiring, language requirements and work authorization will shape the actual route. If the target job market changes, repeat the check.
Make that review concrete. Choose ten recent entry-level opportunities from several employers, not ten copies of the same advertisement. Create a small table with the role, location, education or apprenticeship route, required language, actual tasks, tools, portfolio evidence and application deadline. Mark each requirement as already demonstrated, learnable in a semester or dependent on a later qualification. Do not treat an advertisement as proof that a vacancy will remain open, and do not assume every employer means the same thing by “junior”. The exercise reveals what the student can practise now and which school subjects matter for the next step.
Ask one working developer and one hiring manager to review the portfolio against the table. They may disagree. Record why: a developer may emphasize debugging and readable code, while a hiring manager may emphasize teamwork and evidence that the candidate can complete a task. Revise one project rather than buying another course immediately. In a weak local market, consider supervised internships, open-source contributions, school partnerships and adjacent data or testing roles as routes to experience. Check that any unpaid opportunity is lawful, appropriately supervised and genuinely educational.
Do not force a teenager to promise lifelong loyalty to one label. A vocational software programme can be a strong base for adjacent work, but changing direction can also be sensible when evidence shows a better fit. The aim is to preserve options while making the next choice informed.
🧠What I would say to the student himself
If I had the chance to speak with him after that meeting, I would ask him to show me something he has built. It could be tiny: a page that helps classmates find an assignment, a script that organizes files or a program that solves a problem at home. I would ask what was difficult, what he changed and what he wants to build next. Those answers would tell me much more than a prediction about the number of programmers in ten years.
I would also tell him that half a class changing direction can feel like evidence that the profession is over. It is evidence that people are anxious. They have seen impressive demonstrations and are making a decision before they have had time to understand how those systems are built or used in a company. He can make a more informed decision by learning the tools, trying them on his own projects and speaking with developers who do this work every day.
There is an exciting possibility hidden inside the fear. The student who studies programming today can become the person who designs an AI application tomorrow. He can prepare the data it needs, decide how it should behave, connect it to a real product and improve it when users discover a problem. If he enjoys that work, why would he leave at the very moment his field is opening a new chapter?
I would ask his school to embrace the change as well. Keep the programming fundamentals, and let students use current AI tools openly in projects where they must explain their choices. Give them data to work with, real users to interview and a chance to revise a product after feedback. A vocational programme becomes stronger when it teaches the tools employers are adopting and the judgment needed to use them well. An anxious group needs a convincing new project, not only reassurance.
My advice to the mother remains simple: support his interest, help him meet people in the profession and encourage him to build. If he learns AI as a developer rather than watching it from outside, works seriously with data and continues to update his skills, I see no reason to treat software development as a career dead end over the next decade.
✅ My message to the family: Stay with the programming path if he enjoys creating software. Add AI and data skills to it. Let the work he builds, not his classmates’ fear, guide the next decision.
For a learner who discovers a strong interest in the data branch, the Professional Certificate in Data Engineering for Business Analytics offers a structured way to practise data definitions, tested pipelines, quality monitoring and handover alongside the programming work he already does.
About the author
Igor Dmitriev is the founder and CEO of MTF Institute. This article develops the question and perspective he brought from a parents’ meeting. Read his faculty profile or connect via his LinkedIn profile.