Idea principal

El artículo que describe el motor de contexto trasladado a ChatGPT se preparó dentro de ese motor: ideas persistidas, fuentes ingeridas, puntos ciegos identificados, tareas creadas y después terminadas, primera versión producida, releída y luego retomada en V2 desde el mismo contexto. El sistema no se probó con un escenario construido para él; se le encargó hacer el trabajo para el que existía.

La diferencia no es de rigor, sino de naturaleza de la prueba. Una demostración elige sus datos y su recorrido — verifica que el camino previsto funciona. Un trabajo real trae lo que nadie había previsto: una idea que llega en desorden, una contradicción entre dos notas, una reanudación varios días después, un volumen que no estaba anticipado. Son esas situaciones las que deciden si un sistema aguanta.

Por qué es importante

Esto cambia lo que se puede afirmar al final. Tras una demostración, sabemos que el sistema hace lo que le hemos pedido mostrar. Tras un trabajo real llevado hasta el entregable, la pregunta "¿funciona?" queda cerrada, y la siguiente pasa a ser la de la escala — lo cual es un avance, porque recae sobre un uso y no sobre una capacidad.

Y aporta una disciplina práctica: elegir como primer uso de un sistema aquel que de todas formas hay que producir, en vez de un caso de manual que no cuesta nada abandonar.

Matices y límites

Un solo trabajo real no agota los regímenes de uso. Producir un artículo en unos días no dice nada del comportamiento de un contexto alimentado durante varias semanas, ni de una semana de campo intensa — y el artículo lo reconoce explícitamente.

Y la prueba está sesgada por su operador: quien ha construido el sistema esquiva sin pensarlo aquello que sabe frágil. El trabajo es real, el usuario no del todo.

Preguntas abiertas

• ¿Cómo distinguir, en un sistema puesto a prueba por su autor, lo que se debe al sistema y lo que se debe a los rodeos que hace sin verlos?