3Understand what the material does

An educational resource is open when someone else can download it, understand it, modify it and improve it. The article «Mantener la “A” de abierto en los REA en tiempos de IA» (Keeping the “O” of open in OER in times of AI), which the National Centre for Curriculum Development in Non-Proprietary Systems (CEDEC) devotes to open educational resources (OER), warns that a resource with hundreds of lines of code that nobody understands, not even the person who inserted them, has stopped being open in essence, even if its licence says otherwise. In his talk «Crear REA con eXeLearning en tiempos de IA» (Creating OER with eXeLearning in times of AI), Martín Núñez Calleja puts it this way: «We have the source code. But not the understanding».

The problem is a practical one, since a resource that works today may stop working after a browser update, and if nobody understands how it is made, it cannot be fixed either. The same article proposes a simple rule: if what the code does cannot be explained in two sentences, the resource is not yet ready to be published.

Meeting this recommendation does not require knowing how to program, since it is enough to be able to say three things about the material in ordinary words: what it does, what it stores and whether it communicates with any external service. An explanation of this kind would be the following: «The simulator calculates the acceleration of a body on an inclined plane from the chosen angle and material, and draws the forces. It stores no data and does not connect to any service».

The way to obtain it is to ask the AI itself, in plain language, and then check that it matches what can be observed when using the material. If the artificial intelligence (AI) states that nothing is stored and the material remembers the previous day’s answers, the explanation is not correct and it must be clarified before publishing. The VCER evaluation includes this request in its point 3.

The CEDEC article proposes four questions to detect problematic code without needing to understand it line by line:

• Whether it can be read. Legitimate code has recognisable words, spaces and lines of reasonable length. A line of hundreds of characters without spaces, with letters and numbers mixed together, indicates that the code is obfuscated.
• Whether it refers to external addresses. It is advisable to look for the web addresses that appear in the code and investigate those that are not recognised.
• Whether it asks for permissions. Access to the camera, the microphone, the location or the clipboard is only acceptable when the material justifies it with a clear educational purpose.
• Whether its author can explain it. This is the two-sentence rule.

All four can be entrusted to the AI, which can locate the addresses and permissions in the code. The same article summarises these criteria in a traffic light that classifies code as safe, moderately risky and dangerous.

Code generated by AI without comments works like a black box. When it includes comments in natural language, other people can understand, modify and maintain it more easily. It is advisable to ask for this from the start, with the comments in the language of the material and with understandable variable names. One example is the inclined plane with friction simulator, by Antonio González García, whose code is in a single file, divided into labelled sections and commented in Spanish.

Code compressed into endless lines is reason enough not to publish, with the exception of well-known libraries, which are usually distributed that way. When the material is a project with several files, it is advisable to add a document explaining how it is organised and what each file is for. This is what Pablo G. Guízar does in the repository of his Solar System Quiz, which describes the program’s architecture, the path of the data and the function of each file.