Ideora

Inside the code

The code is still there.

Ideora doesn't hide code behind AI. Students who want to go deeper can open it, read it and change it themselves.

This is the answer to the sharpest objection anyone raises: isn't the AI just doing it for them?

See how it works
  • Never hidden

    The code is always available

  • Three ways out

    When a student breaks something

  • Every version kept

    Nothing is permanent

The code behind a Creation, open and editable in the Studio

And yes — they can break it

Editing is deliberately supported rather than hidden, because it is where a lot of the understanding happens. When something stops working, Ideora says so in plain language — “Line 24 — something isn't closed” — and offers three ways out. None of them require an adult.

  • Undo my change.
  • Back to the last working version.
  • Ask Ora to fix it.
The code behind a Creation, open and editable in the Studio

Nobody gets stuck.

That is a design promise, not a happy accident.

Why breaking things is the feature

Most school computing is arranged so students cannot break anything, which also means they cannot find out how anything works. Reversing that only works if getting unstuck is guaranteed — which is what version history and the three recovery routes are for. Tell students this in the first lesson. It changes how they behave for the rest of the year.

Every version is kept

  • Students can return to an earlier version whenever they need to.
  • Nothing a student does to their own Creation is permanent.
  • Experimenting costs nothing, which is the only way experimenting happens.

Point at it instead of describing it

Students can select something directly inside their running Creation and change it without having to explain where it is. Experimentation should feel natural — even the first time a student opens Ideora, and especially for a student who does not yet have the words for the thing they want changed.

A student selecting an element inside their running Creation

What students meet when they open the code

None of this is taught up front. It arrives when a student becomes curious, and Ora explains it about their own Creation rather than in the abstract.

Function
A named piece of code that does one job, which the rest of the program can ask for by name. Usually the first structure a student recognises, because the name tends to say what it does.
“That's the bit that does the countdown.”
State
What a program currently knows — the score, the level, whether the game has started. Most bugs students hit are about state changing when it should not, or not changing when it should.
“It thinks the game hasn't started yet.”
Component
A reusable piece of an interface, like a card or a button, defined once and used in several places. Changing it in one place changes it everywhere it appears.
“All the cards look the same because they are the same.”
Syntax error
Code that cannot run because something is written wrongly — a bracket unclosed, a quote unmatched. The commonest thing a student breaks, and the easiest to recover from.
“Line 24 — something isn't closed.”
Debugging
Working out why something does not do what you expected. It is the actual skill in programming, and it only develops in someone who has been allowed to break things.
“Why does it do that when I click twice?”
Version history
Every earlier state of a Creation, kept, so any of them can be returned to. It is what makes an ambitious change a reasonable thing to attempt.
“I can go back to when it worked.”

Questions about the code

  • It is optional. Nothing requires a student to open the code. It is there for the moment curiosity arrives, and Ora highlights the exact lines that matter rather than leaving them to search.

  • Every version is kept, so they can return to the last one that worked. They can also undo the change or ask Ora to fix it and explain what went wrong.

  • Standard web code — the same kind that runs real websites and apps. It is not a teaching language that has to be unlearned later.

  • No. Plenty never open the editor, and their Creations work perfectly. The code is there for the students who want it, at the moment they want it.

  • No. Each Creation is isolated, with its own code and its own data. Breaking your own Creation affects only your own Creation.

  • The Published version is what visitors have a link to. Editing in the Studio does not silently alter it.

See a student break something and fix it.

It is the most reassuring two minutes of the demo.