Algo cambió en 2026, y no fue el código. Los campistas siguieron aprendiendo Python. Cambiaron otras dos cosas, y ambas elevaron lo que estaba en juego.
La primera fue para quién construían.
En los años anteriores se trabajaba con clientes ficticios: una organización verosímil, inventada para el ejercicio, a la que no se podía decepcionar porque no existía. En 2026 se sustituyeron por clientes reales, y no pequeños. Once clientes empresariales: bancos, una autoridad portuaria, una autoridad del agua, departamentos de recaudación, un sistema nacional de seguridad social. Organizaciones con clientes reales, obligaciones reales y reputaciones reales, que publicaron un encargo, recibieron un desarrollo y luego lo juzgaron.
Esa sustitución lo cambia todo a partir de ahí. Un cliente ficticio no puede decirle a uno que su respuesta lo dejaría en ridículo. Un banco real sí puede, y lo hizo.
La segunda fue la credencial con la que se fueron.
Las cohortes anteriores terminaban con un certificado de Python de una institución o plataforma en línea acreditada. Este año los campistas presentaron el examen oficial de Python de freeCodeCamp, y más de 50 campistas obtuvieron la certificación en Python: una credencial reconocida mundialmente, verificable públicamente, con una URL de certificado para cada campista que aprobó.
La diferencia está en lo que la credencial le exige a uno. La certificación en Python de freeCodeCamp se obtiene completando un bloque sustancial de proyectos —unas trescientas horas—, y los proyectos de certificación, en particular, exigen aplicar todo el plan de estudios en lugar de limitarse a seguirlo. Al campista no le cuesta nada. Y termina en un enlace de verificación público que se puede compartir.
Esa combinación es poco común: una credencial gratuita, difícil de obtener y que cualquiera puede comprobar —un empleador, una universidad, un cliente— sin tener que fiarse de la palabra del campamento, ni de la del campista.
Además, sin hacer ruido, fue la mejor preparación que el campamento podía darles para lo que vino después. Una credencial basada en proyectos y un encargo empresarial real piden lo mismo: no si uno siguió la lección, sino si es capaz de construir la cosa.
Los equipos se organizaron como pequeñas empresas de tecnología. Cada uno tenía un cliente. Cada uno tenía un encargo publicado en un tablero que cualquiera podía leer. Y el plan de estudios se diseñó a la inversa: en lugar de avanzar por la sintaxis de Python hacia algún proyecto futuro, los facilitadores partieron de un producto terminado y retrocedieron hasta el Python que ese producto exigía. Uno aprendía un bucle porque su bot lo necesitaba, no porque los bucles tocaran a continuación.
El cambio empezó en una sesión de planificación, con una pregunta que sonaba a herejía. Can I be the devil's advocate for a moment? («¿Puedo hacer de abogado del diablo un momento?»), preguntó Telbert Pyke, facilitador del campamento y encargado de su soporte informático. Have we thought about feeding all of this information into one of these known AI. («¿Hemos pensado en volcar toda esta información en una de estas IA conocidas?»)
Vale la pena detenerse en lo que implica esa pregunta. Si un asistente de uso general ya puede responder la pregunta de un cliente, ¿qué construye exactamente un campamento lleno de adolescentes? La respuesta a la que llegó el programa —y que luego pasó veinte días demostrando— es que un modelo general responderá cualquier cosa, incluso cosas que ha inventado, y que una organización no puede poner su nombre en eso. Lo que construyeron los equipos no fue inteligencia. Fue rendición de cuentas: bots que sabían de dónde venían sus datos, rechazaban las preguntas ajenas a su competencia y lo derivaban a uno a una persona cuando lo que estaba en juego lo exigía.
Por qué las empresas lo construyen así
No es una simplificación didáctica. Es la razón misma por la que existen en la industria las arquitecturas de recuperación y las agénticas.
Un banco no puede desplegar un sistema que improvise un saldo. Un departamento de recaudación no puede desplegar uno que improvise una norma tributaria. En cuanto una institución tiene que responder por lo que dice su software, el patrón del chatbot de consumo —un solo modelo, respondiendo de memoria, en un solo paso— deja de ser desplegable. Lo sustituyen dos patrones, y ambos formaban parte de este plan de estudios.
La generación aumentada por recuperación convierte al modelo, de fuente de la respuesta, en la interfaz para llegar a ella. Los datos viven en un corpus que la organización posee y gobierna —circulares normativas, tarifas publicadas, leyes, tablas de tasas—, y el sistema consulta ese corpus antes de hablar y luego dice de dónde salió la respuesta. Su valor no está en que vuelva más listo al modelo. Está en que lo vuelve auditable: alguien puede preguntar de dónde salió una cifra y recibir un documento, no un encogimiento de hombros. Por eso la primera regla del campamento fue que un dato debe tener fuente antes de que el bot pueda decirlo, y por eso el Registro de Oro incluye una columna de última verificación.
La orquestación agéntica divide el trabajo en nodos con tareas definidas y traspasos explícitos —clasificar la solicitud, recuperar, comprobar el cumplimiento normativo, verificar, escalar— en lugar de pedirle a un solo modelo que lo haga todo a la vez. Cada paso puede acotarse, registrarse y probarse por separado, y cualquier paso puede negarse o derivar. Es la diferencia entre producir una respuesta y ejecutar un proceso, y un proceso es algo a lo que una organización sí puede ponerle controles.
Ambos patrones existen por la misma razón, y no es la sofisticación. Es la responsabilidad legal. La recuperación compra procedencia; la orquestación compra control. Juntas son lo que convierte un modelo de lenguaje en algo en lo que una institución regulada puede, de verdad, poner su nombre.
Por eso las mismas formas se repiten en cada desarrollo de este libro. W.E.S negándose a devolver un saldo sin un token válido. A.I.D.A. envolviendo una estimación de impuestos en un aviso legal obligatorio y derivando cualquier caso más difícil a una consola del personal. ASPIRE AI incorporando validadores de esquema de salida después de que sus agentes se enredaran en las pruebas. PILOT mostrando sus fuentes con la fecha en que se comprobó cada una por última vez, y pasando cualquier asunto de aduanas a un despachador humano.
Nada de eso son adornos de principiante. Son las prácticas de trabajo del sector, a las que llegaron unos adolescentes que tenían un cliente real y, por tanto, una razón real para necesitarlas.
Ese es un problema de consultoría, no un ejercicio de programación. Y es la razón por la que, a finales de agosto, varios equipos dirigidos por adolescentes pudieron plantarse ante un jurado técnico regional y responder a un interrogatorio sobre inyección de prompts.