PRISM•MO
The fear educators often have
Mention AI in a programming classroom and the same worry comes up. Fundamentals are being skipped. Students are reaching for a model before they understand the language they are writing. The submitted artefact looks stronger than ever. The grasp behind it feels thinner.
The list of fundamentals at risk is not in dispute. Syntax. Logic and control flow. Problem decomposition. Debugging and testing. Code structure and maintainability. The question is what happens to those skills when most of the typing is done with help from a model.
The concern is fair. If students only prompt, copy, and submit, fundamentals stop being practised. They do not stop mattering. They become harder to see.
AI does not remove the need for understanding
A student who does not understand programming fundamentals can still hand in working code. AI will provide it. What that student cannot reliably do is read the code back, judge it, or move it on. The submission looks complete. The understanding underneath it is not tested by anything in the file.
Without fundamentals, a student tends to struggle to:
- spot flawed logic in a model's first reply
- recognise when the chosen approach does not fit the brief
- adapt the code when requirements change
- debug behaviour that was not expected
- explain why the solution works at all
AI can produce plausible code even when understanding is weak.
Weak AI use and strong AI use
The difference between students who benefit from AI and students who are carried by it shows up early in the development process. One pattern leaves a trace of decisions. The other leaves only an output.
Prompt, copy, submit
- asks the model for a whole answer
- pastes the reply with little change
- writes the README to fit the code, not explain it
The output looks complete. The thinking behind it is unclear, and often missing.
Prompt, interpret, adapt, test, account for
- brings a first attempt to the model, not a blank prompt
- reads the reply, keeps some, rejects some, changes some
- tests, fixes, and notes what changed and why
AI sits inside a visible development process. The student can account for what shipped.
The real question: not whether students use AI, but whether they understand enough to use it well. Fundamentals are what make the difference between the two patterns above.
Fundamentals matter more as AI use increases
The instinct that AI reduces the need for fundamentals reverses once you watch students use it for any length of time. Stronger grounding is what lets a student guide a model rather than depend on it. Weaker grounding turns every reply into something to accept on trust.
Students with stronger fundamentals tend to:
- ask clearer technical questions of the model
- recognise weak, off-brief, or misleading replies
- choose between alternatives that would all run
- refactor the result instead of accepting it as final
- test and validate behaviour against the brief
Fundamentals are what turn AI from a shortcut into a development tool. The students who do well with AI are not the ones who lean on it hardest. They are the ones who can argue with it.
The assessment problem
The problem is not that fundamentals no longer matter. The problem is that they are no longer reliably visible in the final submission. Working code, on its own, no longer tells the marker whether the student understood the logic, the structure, or the decisions behind it. Plausible code can be produced without any of those things.
The gap: the artefact still looks like evidence of fundamentals. With AI in the room, it is no longer a reliable source of that evidence. The marker has to read for it elsewhere.
What fundamentals look like in practice
In AI-assisted programming work, fundamentals show up through the development process rather than the final file. Each one leaves a trace, if the student is asked for it.
Breaking the task apart
Splitting the brief into smaller problems before reaching for a model. Visible in early notes, draft pseudocode, and the shape of the first prompts.
Choosing the right structures
Picking suitable conditions, loops, and data structures. Visible in commit history and in short notes against the relevant lines of code.
Finding and fixing errors
Identifying what broke and why. Visible in error messages logged, fixes applied, and the reason recorded against each fix.
Checking against the brief
Confirming the code does what the brief asked. Visible in tests, manual checks, and a note on what was confirmed and how.
Organising the solution
Keeping the code readable and maintainable. Visible in file layout, naming, and short justifications for the structure chosen.
Accounting for trade-offs
Explaining what was kept from AI replies, what was rejected, and what would change with more time. Visible in the reflection.
The point: these are not separate from AI-assisted development. They are what make AI-assisted development markable.
How to make fundamentals visible
To assess fundamentals when AI is in the mix, the marker needs evidence of how the student worked, not only what they produced. The good news is that the evidence is already being generated by the tools students use. Most of it just is not being captured.
- initial attempts, before the model was opened
- Git commit history with honest messages
- debugging notes tied to specific errors
- AI prompt and revision trails, kept and rejected
- short decision logs against specific lines
- explanations linked to particular code changes
None of this asks the student for a separate document. It asks them to commit as they go, write short notes alongside the code, and account for AI use in the README that already sits in the repo.
Where PRISM fits
The PRISM Workflow gives this evidence somewhere consistent to land. Five stages, named for the move the student is making at each point in the build. Each stage carries part of the trace the marker is reading for.
Problem
The brief restated by the student. Shows whether the task and the constraints were understood before any code was written.
Respond
A first attempt before the model is used. Shows the student's starting point, in their own logic and structure.
Interact
Prompts, replies, and what the student kept, rejected, or changed. Shows iteration, debugging, and how AI was used.
Synthesize
The final code, with a short account of how it was built from the earlier attempts and the AI exchanges.
Make visible
A short reflection linking decisions to what the student now understands, and what they would still change.
Where each fundamental lands
The six fundamentals above do not need a separate place to be assessed. They show up across the PRISM stages, inside the README the student is already writing.
| Fundamental | Workflow stage | Where it shows up |
|---|---|---|
| Decomposition | Problem, Respond | Restated brief, early plan, first attempt |
| Logic | Respond, Synthesize | First attempt, final code, decision notes |
| Debugging | Interact, Synthesize | Errors logged, fixes applied, reasons recorded |
| Testing | Synthesize | Tests, manual checks, evidence in the README |
| Structure | Synthesize | File layout, naming, short justifications |
| Evaluation | Make visible | Reflection on trade-offs and next changes |
What does not change: not the criteria, not the tools, not the artefact the student submits. Only what that artefact is allowed to carry, and where the marker reads each fundamental from.
What this changes for the marker
The shift is small in the artefact and large in what the artefact carries. The code is the same. The README is the same file. The fundamentals the marker is reading for are the same. The evidence base is wider, and the work of inferring is replaced with the work of reading.
Fundamentals are inferred
- does the code run
- does it match the brief
- does it look like the student's work
Understanding is guessed from the output. If the code works, the fundamentals are assumed to be there.
Fundamentals are observed
- how the solution developed, commit by commit
- which decisions the student made, and why
- where AI was used, and what was done with the reply
- what broke, and how it was fixed
- what the student would change next time
Understanding is read from the trace. The criteria do not change. The evidence base does.
The challenge is no longer just teaching programming fundamentals. It is making sure we can see them in action.
What to do next
One assignment is enough to start with. Pick a task students already submit with a README and a repo. Structure the README so the development process is visible. Mark against the criteria the module already uses, reading for fundamentals through the trace rather than the artefact alone.
- Pick a task students already hand in with a README and a repo.
- Add the PRISM sections to the README template for that task.
- State, in the brief, that AI use is expected and that the README carries the evidence of fundamentals.
- Mark against the criteria you already use, reading the README for the fundamentals the artefact alone no longer shows.