
When figures such as Linus Torvalds talk openly about using AI in software work, it lands differently from another flashy product launch. Teachers can dismiss hype; it is harder to dismiss a shift in professional practice. If experienced programmers are starting to use AI to draft, inspect or accelerate parts of development, then school Computing needs to respond carefully. That does not mean throwing out programming. It means being clearer about what programming education is for.
For many schools, the first step is simply understanding the trend accurately. Vibe coding explained for teachers offers a useful starting point, but curriculum planning needs to go further. GCSE and A-Level Computing should still teach students to write code. However, they should now place greater emphasis on code reading, debugging, verification and judgement in AI-assisted development.
Why it matters
Linus Torvalds matters here not because one individual sets the curriculum, but because he represents serious software engineering. When respected developers use AI pragmatically, they signal that the profession is changing in method, not abandoning standards. Software still has to run correctly. It still needs to be secure, maintainable and understandable. The difference is that more code may begin life as a machine-generated draft rather than as a human’s first attempt.
That matters for schools because many classroom tasks still reward only line-by-line production from memory. In real development, though, programmers increasingly spend time reviewing suggestions, tracing behaviour, spotting errors, refining prompts, checking assumptions and testing outputs. Those are all teachable school skills. They are also assessable, if departments design tasks with care.
What is changing
Professional programming is changing in pace and workflow. Developers can now generate boilerplate quickly, compare alternative implementations and ask tools to explain unfamiliar syntax. A student who has only been trained to produce code from scratch may be underprepared for that environment.
Yet the fundamentals are not changing nearly as much as headlines suggest. Programmers still need to understand sequence, selection, iteration, data structures, decomposition and abstraction. They still need to reason about state changes in a program. They still need to know when code is inefficient, fragile or simply wrong. AI can generate plausible rubbish at speed. That makes human judgement more important, not less.
This is similar to wider shifts in AI use across education. As discussed in ChatGPT turns 3: education impact review, the settled question is no longer whether AI exists, but how professional practice adapts around it. Computing should be one of the subjects best placed to respond intelligently.
Keep coding fluency
It would be a mistake to conclude that, because AI can generate code, students no longer need to learn to program. Coding fluency still matters for three reasons.
First, students cannot evaluate code they do not understand. If an AI produces a sorting routine, the student still needs enough knowledge to recognise whether it is correct, efficient and appropriate. Secondly, writing code remains one of the best ways to reveal misconceptions. A learner who cannot construct a loop or define a function independently probably does not yet understand the concept securely. Thirdly, fluency builds confidence. Students who have wrestled with syntax and logic themselves are more likely to challenge an AI response rather than accept it passively.
So the goal is not less programming. It is better-balanced programming. Students should still write small programs unaided. They should still practise core constructs until they become familiar. But that work should increasingly sit alongside tasks where the code already exists and the challenge is to interpret, improve or verify it.
Read and critique code
A stronger curriculum response begins with code reading. In many classrooms, students spend far less time reading code than writing it. That is the wrong balance for the world they are entering. A developer may spend most of the day understanding existing systems, following logic through branches, finding where a bug originates or checking whether a generated function really does what the comment claims.
Teachers can respond with simple shifts. Give students a short program and ask what it does before asking them to edit it. Ask them to trace variable values line by line. Present two versions of a solution and ask which is clearer, safer or easier to maintain. Show them AI-generated code with one subtle logic error and ask them to identify the fault. These tasks build habits of attention and scepticism.
This also fits neatly with department conversations about AI policy and classroom routines. Articles such as January INSET AI policy sprint pack can support leaders in setting expectations, but the subject-level response must be rooted in disciplinary practice. In Computing, that means treating code as text to be read critically, not merely produced.
Debugging first
Debugging may be the practical skill that now deserves the greatest emphasis. In an AI-assisted world, broken code will not disappear. If anything, students may encounter more of it, because code can be generated faster than it can be checked.
A strong debugging curriculum teaches students to form hypotheses, isolate variables, inspect outputs and test incrementally. Instead of staring at a screen and guessing, they learn to ask disciplined questions. What was the program supposed to do? What did it do instead? Which input reproduces the problem? At what point does the state become wrong?
Teachers can make this concrete by building bug-hunting into regular lessons. A Year 10 class might receive a short Python program that almost works but fails on boundary values. An A-Level class might compare two implementations of a search routine, one correct and one with an off-by-one error. The key is that students explain their reasoning, not just patch the line by luck.
Verification and evidence
The next shift is towards verification, testing and evidence. If AI can produce convincing code quickly, then students need stronger habits for proving whether a solution is trustworthy. That means writing sensible test cases, considering normal and edge-case inputs, and justifying claims with evidence rather than confidence.
This is where Computing can become more rigorous, not less. A student should be able to say, “I believe this function works because I tested empty input, typical input and maximum expected input, and here are the results.” They should also be able to explain limitations. Perhaps the program handles integers but not negative values. Perhaps it works correctly but inefficiently on large data sets. These are the kinds of judgements that matter in modern development.
Discover the power of Automated Education by joining out community of educators who are reclaiming their time whilst enriching their classrooms. With our intuitive platform, you can automate administrative tasks, personalise student learning, and engage with your class like never before.
Don’t let administrative tasks overshadow your passion for teaching. Sign up today and transform your educational environment with Automated Education.
🎓 Register for FREE!
There is also a useful crossover here with broader school AI readiness. Annual AI acceptable use policy refresh checklist can help schools define safe and transparent use, but subject teachers still need to teach what good evidence looks like when AI has been involved in producing an answer.
Rethink assessment
If departments accept this shift, coursework, homework and exams should change too. Not every task should ask students to write a whole solution from scratch under timed conditions. Some should ask them to annotate code, identify weaknesses, improve readability, design tests or evaluate an AI-generated approach.
Homework can include short code reviews in which students explain what a program does and where it may fail. Class assessments can present flawed solutions and ask for corrections with justification. Mock exams can include trace tables, debugging logs or testing plans alongside traditional programming items. None of this lowers standards. In many cases, it raises them by demanding deeper understanding.
Schools may also want to align this work with staff development. INSET day AI workshop: three micro-routines is useful for building confidence with practical routines, especially where teachers are at different starting points.
Skills industry values
Employability in Computing has never been only about syntax. Industry still values people who can understand a problem, communicate clearly, work methodically and judge quality. AI does not remove those expectations. It sharpens them.
A student who can read unfamiliar code calmly, explain why a generated answer is unreliable, construct a sensible test plan and improve a messy solution is likely to be useful in any future technical role. So is a student who knows when not to trust automation. These are durable strengths. They transfer across programming languages, tools and platforms.
For departments worried about future-proofing, that is reassuring. The curriculum does not need to chase every new model release. It needs to strengthen the habits that remain valuable even as tools change. GPT-5 watch: week 1 readiness pack may help schools monitor developments, but curriculum design should stay anchored in enduring disciplinary thinking.
A department plan
A practical response this year does not require a full rewrite of schemes of work. Start by auditing existing units. How many lessons ask students to read code, trace it, debug it or test it? How many reward only production? If the balance is heavily skewed, adjust one unit at a time.
In Key Stage 4, add regular code-comprehension starters and bug-fix tasks. In post-16 classes, introduce structured evaluation of generated code, including discussion of correctness, efficiency and maintainability. Build testing evidence into project expectations. Review homework so that some tasks ask for explanation and critique, not just finished output. Finally, agree department language for AI-assisted work: when it is allowed, how it must be acknowledged, and what independent understanding looks like.
This is a manageable shift. It keeps programming at the centre while recognising that professional programming is becoming more hybrid. Students still need to know how to code. They also need to know how to doubt, inspect and verify.
To sharper debugging and wiser coding decisions ahead!
The Automated Education Team