En 2006, Gerard Holzmann, ingeniero del Laboratorio de Propulsión a Chorro (JPL) de la NASA, destiló décadas de experiencia en sistemas críticos en solo diez reglas. Su objetivo era simple, crear código donde el error no fuera una opción, ya que de él dependían vidas y misiones multimillonarias.
Hoy, esas reglas son más vigentes que nunca. El motivo es paradójico, mientras más código generamos mediante Inteligencia Artificial, más nos alejamos de los principios de seguridad que Holzmann defendía. La IA es rápida y fluida, pero padece de una ceguera selectiva ante la fiabilidad.
Es por ello que a continuación, quiero revisar contigo estas 12 reglas fundamentales, basadas en el estándar de la NASA, adaptadas para el desarrollo moderno asistido por IA.
Control y Estructura
1. Mantén la linealidad
El código debe leerse de arriba a abajo. El anidamiento profundo y los saltos lógicos ocultos son enemigos de la verificación. Si necesitas un diagrama para entender una función, el diseño ha fallado.
La IA tiende a crear cadenas complejas de if/else. Pídele explícitamente que "aplane la lógica" y limite el anidamiento a un máximo de dos niveles.
2. Pon límites a cada bucle
Todo ciclo debe tener un techo explícito. No basta con asumir que "nunca excederá N". Un bucle infinito o descontrolado es un fallo estructural.
Revisa las lógicas de reintento (retries) y polling generadas por IA. Siempre pregunta: ¿Cuál es el máximo de iteraciones y qué ocurre si se alcanza?
Gestión de recursos y memoria
3. Sé dueño de tus recursos
Toda conexión abierta debe cerrarse. Todo recurso prestado debe devolverse. La gestión del ciclo de vida del recurso debe ser explícita, especialmente en las rutas de error.
La IA suele olvidar cerrar gestiones de archivos o conexiones de base de datos en los bloques catch. Sigue la ruta de ejecución y confirma siempre para garantizar que todo funciona de forma limpia.
4. Una función, un solo trabajo
Si no puedes describir lo que hace una función en una frase sin usar la conjunción "y", es demasiado grande. Holzmann limitaba las funciones a lo que cabe en una hoja de papel (60 líneas).
La IA tiende a generar funciones monolíticas para cumplir la tarea rápido. Establece un límite estricto de 40-60 líneas por función antes de lanzar el prompt.
Correctitud y observabilidad
5. Declara tus suposiciones (Asserts)
Las precondiciones y los invariantes no deben estar solo en la documentación, deben estar en el código mediante aserciones que fallen ruidosamente si se violan.
La IA omite la validación casi por defecto. Pide explícitamente: "Añade aserciones para las condiciones previas y posteriores".
6. Nunca silencies un error
El bloque except:pass es veneno para el software. Todo error debe ser manejado, registrado (logged) o propagado. Los fallos silenciosos corrompen el estado de forma invisible hasta que es demasiado tarde.
Revisa los bloques try-catch vacíos. Enforce una regla: todo error debe dejar rastro.
7. Limita el alcance del estado
Los datos deben vivir lo más cerca posible de donde se usan. El estado global es el camino más rápido hacia una sesión de depuración eterna.
La IA prefiere estados globales o de clase porque son más fáciles de generar. Exige que pase las dependencias de forma explícita.
8. Haz visibles los efectos secundarios
Si una función escribe en la DB o hace una llamada de red, debe ser evidente. No escondas mutaciones bajo nombres de funciones inocentes.
Separa la computación pura de las operaciones con efectos secundarios. Lo "peligroso" debe ser obvio y estar bien nombrado.
Abstracción y herramientas
9. Evita el exceso de capas
Cada capa de indirección hace más difícil responder a la pregunta: ¿Qué se está ejecutando realmente?. Favorece la composición clara sobre la elegancia críptica.
La IA tiende a sobre-ingeniar soluciones. Pregunta siempre: "¿Se puede escribir esto de forma más directa?".
10. Los avisos (Warnings) son errores
Holzmann exigía cero avisos del compilador desde el primer día. Un warning es un error futuro que tu herramienta ya detectó. No lo ignores.
Configura linters y analizadores estáticos en tu CI antes de que la IA empiece a escribir. Si no pasa el linter, no es código válido.
La relación con la IA
11. Lee cada línea
El código generado por IA no ha sido revisado por alguien que se preocupe por si funciona. Eres el ingeniero responsable. Trata cada output como el PR de un desarrollador brillante pero imprudente.
No hagas commit de nada que no hayas leído y comprendido en su totalidad.
12. Tests (TDD)
Si la IA no puede articular el comportamiento correcto en un test, los requisitos no están claros. Pedir "escribe los tests y luego la implementación" es infinitamente más seguro que pedir solo la función.
La IA optimiza para el "camino feliz". Los tests la obligan a razonar sobre casos de borde y modos de fallo.
Conclusión
Estas reglas pueden parecer incómodas al principio, pero en el desarrollo asistido por IA, la disciplina no es un obstáculo para la velocidad, es lo que permite que esa velocidad sea segura.
Referencia:
- Holzmann, G.J. (2006). The Power of Ten — Rules for Developing Safety Critical Code. NASA/JPL Laboratory for Reliable Software.
