Usar IA para escribir una función aislada ya no describe la parte interesante del problema. El salto de verdad aparece cuando una tarea deja de ser «genera este fragmento» y pasa a ser «entiende este producto, encuentra la zona correcta, cambia lo necesario, conserva lo que funciona y demuestra que el resultado encaja». En ese punto el modelo no actúa como un teclado más rápido. Participa en un sistema de ingeniería que necesita contexto, permisos, memoria, comprobaciones y una definición razonable de terminado.
Durante la etapa en la que el proyecto todavía se llamaba Blupoli empezamos a experimentar con esta forma de trabajo de manera cada vez más deliberada. Hoy la identidad es Blupoli y el producto de juegos es Blupoli Puzzles, pero la pregunta que dio origen a este artículo sigue siendo la misma: ¿cómo aprovechamos la capacidad de los agentes sin convertir el repositorio en una sucesión de cambios rápidos que nadie entiende del todo? La respuesta que estamos construyendo no es un agente mágico, sino un ciclo donde cada participante deja evidencia que el siguiente puede inspeccionar.
«Equipo» no significa sustituir personas por modelos
Hablar de IA como equipo puede inducir a pensar en una organización completamente autónoma donde varios modelos reciben objetivos vagos y producen un producto terminado. No es así como lo entendemos. «Equipo» describe una distribución de trabajo: diferentes herramientas pueden investigar, implementar, comparar, revisar o preparar documentación, mientras una persona mantiene responsabilidad sobre dirección, prioridades y aceptación. La utilidad aparece cuando cada rol tiene una entrada, una salida y unos límites reconocibles.
Esa distinción evita una expectativa peligrosa. Un agente puede escribir mucho código, pero no posee por defecto el contexto acumulado del producto, la historia de por qué una convención existe o el criterio para saber si una experiencia resulta agradable. Puede recuperar parte de ese conocimiento si el repositorio lo expresa y puede encontrar evidencia para apoyar una decisión, pero no conviene confundir capacidad de producción con autoridad sobre el rumbo. El sistema funciona mejor cuando la autonomía técnica crece dentro de fronteras explícitas.
El contexto se convierte en infraestructura
Cuando una persona lleva meses en un proyecto, muchas decisiones viven en su memoria: qué carpeta es canónica, qué abstracción falló antes, qué componente sirve de referencia o qué atajo está prohibido porque ya provocó problemas. Un agente que entra en una sesión nueva no tiene esa continuidad a menos que se la proporcionemos. Por eso documentación, convenciones, tareas bien escritas y estructura de repositorio dejan de ser materiales secundarios. Pasan a formar parte del entorno de ejecución.
El objetivo no es documentarlo todo. Una enciclopedia enorme puede ser tan difícil de usar como no tener documentación. Nos interesa conservar aquello que reduce ambigüedad futura: arquitectura, fuentes de verdad, criterios de calidad, comandos de verificación, decisiones que se repiten y ejemplos buenos que puedan servir de precedente. Una instrucción breve que señala el documento correcto suele ser más valiosa que un prompt gigantesco que intenta volver a explicar el proyecto desde cero.
Una buena tarea contiene una definición observable de éxito
Los agentes se vuelven mucho más fiables cuando la tarea especifica un resultado verificable. «Mejora el catálogo» obliga a adivinar demasiado. «Haz que las tarjetas de los artículos traduzcan título, descripción y portada, conserva las rutas canónicas y ejecuta las comprobaciones editoriales» define una superficie concreta. Esa precisión no impide que el agente investigue o proponga una solución; reduce la cantidad de decisiones implícitas que podrían llevarlo a resolver otro problema distinto.
También es útil escribir lo que no debe cambiar. En un repositorio real hay áreas que funcionan, compatibilidad que preservar y trabajo concurrente de otras ramas. Marcar límites evita refactors oportunistas que aumentan el diff sin mejorar el objetivo. Una tarea preparada para agentes debería poder responder al menos cuatro preguntas: qué queremos observar al final, dónde están las referencias relevantes, qué restricciones son obligatorias y qué evidencia aceptaremos para considerar que el cambio está completo.
Git es memoria verificable, no solo control de versiones
Ramas, commits y pull requests encajan especialmente bien con trabajo asistido por agentes porque convierten cada propuesta en una unidad inspeccionable. Una conversación puede afirmar que algo fue corregido; un diff enseña exactamente qué cambió. Un agente puede explicar sus decisiones, pero el repositorio permite contrastar esa explicación con archivos, pruebas y resultados. Esa diferencia entre relato y evidencia es fundamental cuando la velocidad de producción aumenta.
Git también hace posible experimentar sin convertir cada intento en estado permanente. Podemos crear una rama, dejar que una herramienta explore una solución, comparar el resultado con la base y descartar el enfoque si empeora el sistema. El coste de probar baja porque volver atrás es sencillo. Al mismo tiempo, el historial conserva aprendizaje: un commit o una PR bien descrita puede servir a otro agente como precedente más adelante. La memoria ya no depende solo de recordar una conversación antigua.
Delegar y enrutar son operaciones diferentes
En la práctica hemos tenido que separar dos ideas que suelen mezclarse. Delegar significa repartir una parte del trabajo dentro del flujo que ya controla el contexto y el repositorio. Enrutar significa enviar una tarea a otra herramienta o agente que puede tener capacidades distintas, otro entorno o permisos diferentes. Ambas estrategias son útiles, pero sus riesgos no son los mismos.
Un agente externo puede ser excelente razonando sobre un algoritmo y resultar poco adecuado para editar el proyecto si no puede acceder a los archivos correctos o devolver un cambio revisable. Del mismo modo, un agente integrado puede modificar el repositorio con facilidad y no ser la mejor opción para una investigación especializada. El criterio no debería ser «qué modelo es más potente», sino «qué combinación de contexto, herramientas, permisos y evidencia necesita esta tarea».
Los permisos forman parte del diseño del sistema
La autonomía sin permisos es una demo; los permisos sin límites son un riesgo. Para que un agente pueda resolver trabajo real necesita leer aquello que importa y, en algunos casos, escribir, ejecutar comprobaciones o interactuar con servicios. Pero no todas las tareas justifican el mismo alcance. Una revisión puede necesitar solo lectura. Una actualización de contenido necesita escribir una rama, no administrar el repositorio entero. Una automatización de despliegue requiere controles distintos a un borrador editorial.
Tratar los permisos como parte del diseño obliga a formular mejor el trabajo. Si no sabemos qué capacidad mínima necesita una tarea, probablemente tampoco hemos delimitado bien su responsabilidad. La fricción que aparece cuando una herramienta no puede hacer algo también ofrece información: puede revelar que hemos mezclado pasos que deberían separarse o que dependemos de una acción manual sin haberla reconocido. El objetivo no es eliminar toda fricción, sino que cada permiso tenga una razón concreta.
La evidencia debe ser independiente de quien implementa
Uno de los riesgos de cualquier flujo rápido es aceptar como verificación la misma explicación que produjo la solución. Si un agente modifica un generador y después asegura que genera mejor, todavía falta una prueba que pueda contradecirlo. Tests, validadores, builds, snapshots, comparaciones y revisiones separadas sirven precisamente para introducir fuentes de evidencia que no dependen de la confianza en el implementador.
Esto es especialmente importante con IA porque el texto explicativo suele sonar convincente incluso cuando existe un detalle incorrecto. Un comando que falla es menos elocuente y más útil. Una ruta rota detectada por un gate vale más que un párrafo diciendo que los enlaces se revisaron. No todo criterio puede automatizarse, pero todo aquello que sí admite una comprobación barata debería intentar convertirse en parte repetible del sistema.
Los puzzles son un laboratorio perfecto para detectar falsas certezas
Blupoli Puzzles contiene problemas donde una salida puede parecer plausible y ser incorrecta. Un tablero generado puede respetar la forma visual y tener varias soluciones. Un solver puede encontrar una respuesta y no demostrar que sea única. Una dificultad «experta» puede usar un tablero grande y seguir siendo trivial. Esa combinación de apariencia convincente y propiedades ocultas se parece mucho al tipo de error que puede producir una implementación generada con rapidez.
Por eso los motores de puzzle nos han empujado hacia verificadores independientes. El artículo «Generar no es resolver» desarrolla esa idea desde el punto de vista algorítmico. En el flujo de agentes, la lección es más general: si una tarea puede producir una salida aparentemente correcta, necesitamos pensar qué mecanismo podría demostrar que no lo es. La capacidad de refutación forma parte de la definición de calidad.
Especializar roles reduce el sesgo de implementación
No esperamos que un único agente sea siempre la mejor opción para entender, construir y juzgar su propia solución. Separar roles puede mejorar el resultado incluso cuando todos usan tecnologías parecidas. Un agente de investigación puede reunir precedentes antes de tocar código. Otro puede implementar dentro de un alcance delimitado. Un tercero puede revisar el diff buscando supuestos rotos, rutas olvidadas o contradicciones con la documentación.
La ventaja no es teatralizar una organización humana, sino introducir preguntas diferentes. Quien implementa tiende a seguir el camino que ya eligió. Quien revisa puede empezar desde el comportamiento esperado y buscar dónde no se cumple. Esa independencia parcial aumenta la probabilidad de detectar problemas que el autor normalizó durante el trabajo. El mismo principio existe en revisión humana y adquiere todavía más valor cuando generar otra perspectiva es relativamente barato.
Paralelizar ayuda solo cuando las fronteras están claras
Varios agentes trabajando al mismo tiempo parecen una forma obvia de acelerar. A veces lo son. Pero el paralelismo tiene un coste de coordinación. Si dos tareas editan los mismos archivos o dependen de una decisión todavía abierta, la velocidad inicial se convierte en conflictos, duplicación o soluciones incompatibles. La pregunta correcta no es cuántos agentes podemos lanzar, sino qué trabajo puede progresar de manera realmente independiente.
Las mejores tareas paralelizables suelen tener fronteras naturales: investigar alternativas sin modificar código, preparar traducciones en archivos distintos, revisar una PR mientras otra rama aborda una función no relacionada, o dividir una migración por unidades que comparten contrato pero no superficie de edición. Cuando el acoplamiento es alto, a menudo es mejor secuenciar. La coordinación también es trabajo y conviene contabilizarla, aunque no aparezca como líneas de código.
Los documentos cercanos al código reducen la entropía
Cuanta más automatización introducimos, más útil se vuelve que las instrucciones operativas vivan cerca de aquello que gobiernan. Un repositorio que explica su arquitectura, sus comandos y sus convenciones puede orientar tanto a personas como a agentes. Si esa información está repartida entre chats antiguos, notas privadas y recuerdos, cada sesión empieza reconstruyendo una versión distinta de la realidad.
Eso no obliga a meter toda la gestión de producto dentro de Git. Sí sugiere que las decisiones necesarias para modificar el software deberían tener una representación accesible desde el flujo de desarrollo. En Blupoli intentamos acercar especificaciones, tareas y documentación técnica a los lugares donde pueden utilizarse. La documentación útil no es la que existe; es la que aparece en el momento en que una decisión necesita contexto.
El tamaño del contexto también es un recurso que hay que diseñar
Dar más información no siempre mejora una tarea. Un contexto enorme puede enterrar la restricción importante entre cientos de detalles irrelevantes. Además, recuperar, leer y razonar sobre material tiene coste. La evolución natural del sistema consiste en pasar de prompts cada vez más largos a mecanismos de descubrimiento: una instrucción pequeña indica dónde está la fuente de verdad y el agente consulta solo lo que necesita.
Esto favorece repositorios con buenos nombres, documentos específicos y referencias explícitas entre piezas. También obliga a eliminar contradicciones. Si dos guías describen convenciones distintas, un agente no puede saber cuál representa el estado actual sin otra señal. Mantener una fuente canónica y retirar instrucciones obsoletas es parte de la higiene del proyecto. La IA amplifica tanto una buena documentación como una mala.
La revisión humana cambia de forma cuando producir alternativas es barato
Antes, una parte importante del tiempo podía irse en materializar la primera versión de una idea. Cuando ese coste baja, la revisión se desplaza hacia comparar alternativas y detectar consecuencias. Podemos pedir dos enfoques, ver sus diffs y decidir cuál encaja mejor. Eso no elimina el criterio humano; lo concentra en una zona donde aporta más valor: prioridades, coherencia, simplicidad y experiencia de producto.
También aparece una responsabilidad nueva: no aceptar trabajo solo porque ya existe. Si generar una solución fue barato, descartarla debería ser psicológicamente más fácil. El sesgo de coste hundido puede empujarnos a pulir una implementación que partió de una premisa equivocada. Un buen flujo conserva la posibilidad de decir «no merece la pena» después de una exploración y trata ese resultado como aprendizaje, no como fracaso.
Hay tareas en las que un agente no es la herramienta adecuada
La adopción útil de IA también consiste en reconocer dónde no aporta. Una decisión de marca, una evaluación visual delicada o una conversación con usuarios puede necesitar contexto humano que no se reduce a archivos. Una modificación minúscula que una persona entiende perfectamente puede ser más rápida de hacer directamente que de preparar, delegar y revisar. Automatizar por principio añade ceremonia sin beneficio.
Nos interesa una regla práctica: usar agentes cuando pueden ampliar capacidad, explorar más espacio o ejecutar trabajo repetible sin degradar la trazabilidad. Evitarlos cuando la delegación cuesta más que la tarea, cuando no disponen de la evidencia necesaria o cuando el riesgo exige una responsabilidad que no puede transferirse. El objetivo no es maximizar el porcentaje de trabajo realizado por IA; es mejorar el sistema con el que construimos el producto.
La arquitectura del producto determina cuánto puede delegarse
Un repositorio modular es más fácil de modificar con agentes por la misma razón que es más fácil de modificar con personas: las responsabilidades están menos mezcladas. Si un motor de puzzle contiene reglas, navegación, presentación y persistencia en el mismo bloque, cualquier cambio exige comprender demasiadas cosas a la vez. Cuando existe un contrato claro entre motor, host y UI, una tarea puede limitarse a una frontera más pequeña.
Por eso el trabajo descrito en la arquitectura de motores de Blupoli Puzzles está directamente relacionado con la IA. La modularidad no se diseñó para agentes, pero los beneficia. Un agente puede actuar con más autonomía cuando el repositorio explica qué pertenece a cada capa y tiene pruebas que defienden el contrato. La buena arquitectura reduce la cantidad de contexto que hace falta para cambiar una parte con seguridad.
El repositorio empieza a comportarse como una interfaz de colaboración
Cuando muchas tareas pasan por agentes, la calidad del repositorio como «interfaz» se vuelve visible. Nombres, estructura de carpetas, scripts, mensajes de error, ejemplos y documentación determinan cuánto tarda un participante nuevo en orientarse. Un proyecto que solo puede modificarse correctamente después de una larga transmisión oral tiene una API humana implícita. Convertir parte de esa API en señales explícitas beneficia a cualquiera que llegue después.
Esto cambia también cómo juzgamos una mejora técnica. Un script que falla con un mensaje preciso puede ser más valioso que uno que simplemente devuelve código 1. Un test cuyo nombre explica el contrato enseña mientras verifica. Una tarea que enlaza al precedente correcto reduce búsqueda. Estas pequeñas decisiones aumentan la legibilidad operacional del proyecto y permiten que la velocidad de los agentes no dependa de tener siempre a la misma persona guiando cada paso.
El ciclo que estamos intentando consolidar
Nuestro modelo de trabajo puede resumirse en cuatro movimientos. Primero, contexto: definir objetivo, restricciones y fuentes de verdad. Segundo, ejecución: investigar o implementar en una unidad de cambio limitada. Tercero, evidencia: ejecutar tests, builds, validadores y revisar el diff. Cuarto, criterio: decidir si se acepta, se corrige o se replantea. Después, lo aprendido vuelve al contexto para que la siguiente tarea empiece mejor preparada.
La parte más importante es que el ciclo no termina con una respuesta del modelo. Termina cuando el estado del proyecto es comprensible. Puede haber código, documentación, una PR, un test nuevo o incluso una decisión de no cambiar nada. El producto de la tarea es una mejora verificable del sistema, no la cantidad de texto o líneas generadas durante el proceso. Esa definición protege contra la tentación de confundir actividad con avance.
Qué cambió al pasar de Blupoli a Blupoli
El cambio de marca no alteró esta forma de trabajo, pero amplió el problema. Blupoli podía imaginarse como una sola plataforma de puzzles; Blupoli pretende servir de identidad para varios productos y para la capa editorial que los conecta. Eso obliga a que las decisiones de arquitectura, contenido y automatización distingan mejor entre lo que pertenece a Blupoli Puzzles y lo que pertenece al ecosistema completo.
Para los agentes, esa separación hace todavía más importante el contexto. «Cambia la web» ya no identifica necesariamente una única aplicación. Una tarea debe saber si toca Blupoli Puzzles, el sitio principal, un paquete compartido o documentación. La evolución de la marca demuestra una idea que también se aplica al flujo de IA: cuando el sistema crece, los nombres y las fronteras dejan de ser detalles organizativos y se convierten en condiciones para trabajar con seguridad.
La velocidad útil deja un proyecto más fácil para la siguiente tarea
La métrica que más nos interesa no es cuántas líneas puede producir un agente en una tarde. Es si después del cambio el siguiente problema resulta más fácil de entender y verificar. A veces eso significa añadir una prueba. Otras, consolidar una fuente de verdad, eliminar una duplicación, documentar una convención o transformar una comprobación manual en un gate automático. La mejor aceleración no solo resuelve el presente; reduce fricción acumulativa.
Esta perspectiva también pone un límite sano a la generación masiva. Si cada tarea añade excepciones, instrucciones especiales y archivos duplicados, la productividad aparente crea un impuesto para el futuro. Queremos lo contrario: usar la capacidad de los agentes para hacer más trabajo y, al mismo tiempo, fortalecer la estructura que permite confiar en él. Velocidad y mantenibilidad no deberían ser objetivos opuestos si el ciclo incluye revisión y refactorización cuando hacen falta.
Lo que seguimos aprendiendo
No tenemos un modelo final de «equipo de IA». Las herramientas cambian, los niveles de autonomía evolucionan y cada repositorio revela restricciones distintas. Lo que sí se mantiene es una serie de principios que han sobrevivido a varias iteraciones: contexto pequeño pero canónico, tareas observables, permisos mínimos, cambios revisables, evidencia independiente, especialización cuando aporta otra perspectiva y una persona responsable de las decisiones de producto.
Blupoli seguirá siendo un lugar para poner esos principios a prueba con trabajo real. La ventaja de hacerlo dentro de un producto vivo es que los errores no pueden esconderse detrás de una demo. Una ruta rota, un puzzle malo o una traducción incoherente termina apareciendo. Eso obliga a que el sistema de agentes responda ante el mismo estándar que cualquier otra herramienta de ingeniería: no cuánto impresiona mientras trabaja, sino cuánto mejora el producto y la confianza con la que podemos seguir cambiándolo.
IA como equipo significa diseñar mejor el trabajo
Después de experimentar con agentes, la conclusión más útil no es que puedan hacer más cosas de las que esperábamos. Es que nos obligan a definir con mayor precisión cómo queremos que se haga el trabajo. Para delegar bien necesitamos nombrar fuentes de verdad, separar responsabilidades, escribir criterios de aceptación, automatizar verificaciones y conservar decisiones. Todo eso ya era valioso antes de la IA. La diferencia es que ahora sus beneficios aparecen de forma inmediata y repetida.
Por eso preferimos hablar de un sistema de colaboración y no de sustitución. Las personas aportan dirección, contexto amplio y criterio; los agentes aportan velocidad, exploración y capacidad de ejecutar tareas bien definidas; Git y las verificaciones aportan memoria y evidencia. Cuando esas piezas encajan, la IA deja de ser un generador de fragmentos y se convierte en una parte real del proceso de construir. No porque tenga la última palabra, sino porque el proyecto está preparado para trabajar con ella.