De los modelos se habla mucho. Del entorno casi nada. Y en el trabajo diario es el entorno lo que decide.
Lo que se describe aquí no es un producto ni algo que vendamos. Es la respuesta a la pregunta que más nos hacen en las conversaciones, sobre todo gente que trabaja con IA: cómo lo tenéis montado.
El editor es el escenario#
Se trabaja en un editor de código normal, no en una ventana de chat del navegador. Esa es la diferencia individual más importante.
Una ventana de chat en el navegador solo ve lo que le pegas. Un asistente dentro del editor ve los archivos, puede ejecutar comandos, leer resultados y deducir de ahí el paso siguiente. La diferencia entre "explícame cómo cambio esto" y "cámbialo, ejecuta las pruebas y enséñame el resultado" no es comodidad, es otra forma de trabajar.
Dos familias de modelos, a propósito#
En paralelo corren asistentes de dos casas distintas. No es indecisión sino la palanca de calidad más eficaz que hemos encontrado.
Los modelos de la misma familia cometen errores parecidos. Cuando el constructor y el revisor vienen de la misma casa, el revisor pasa por alto de forma fiable justo lo que pasó por alto el constructor. Comparten los puntos ciegos.
Si haces correr un modelo de otra familia sobre el mismo trabajo, con el encargo expreso de refutarlo, vuelven hallazgos distintos. No más hallazgos, distintos. Ese es ya nuestro camino estándar para todo lo que no es trivial: uno construye, un segundo ataca, y sigue hasta que no vuelve nada sustancial.
Recetas en vez de explicar otra vez#
La segunda capa son recetas para procedimientos recurrentes. Un despliegue, un artículo de blog, el alta de un cliente, una revisión de servidor.
El sentido no es la automatización. El sentido es que cada receta lleva dentro las trampas en las que ya caímos. Para publicar una web, por ejemplo, lleva dentro el orden de comprobaciones que tocan antes de conmutar.
Ese conocimiento si no desaparece. Vive en la cabeza de alguien que ese día no está. En una receta está escrito y se sigue la próxima vez, también por un asistente que no conoce la historia de fondo.
Barreras que no preguntan con educación#
La tercera capa es la que más disgustos nos ha ahorrado. Son bloqueos duros que impiden técnicamente ciertas acciones en vez de desaprobarlas.
La diferencia es decisiva. Una instrucción como "no uses nunca esta herramienta contra un servidor" es un ruego. Funciona casi siempre y algún día no, porque está en una sesión larga bajo mucho otro texto.
Una barrera que intercepta el comando y lo rechaza con un motivo funciona siempre. Esas barreras están en los sitios con mayor alcance del daño: en todo lo que puede sobrescribir un servidor, en el correo saliente, en acciones que borran.
La lección de fondo es más general que la herramienta: una regla sin cumplimiento forzoso es una nota. Cuando lo mismo ha pasado dos veces, el texto al respecto queda refutado y hace falta un mecanismo.
y la memoria por debajo#
Todo eso cuelga de la memoria descrita en otro artículo de esta serie. Conserva decisiones, errores y patrones durante meses, y entre sesiones.
El efecto práctico: un error cometido una vez y anotado vuelve como aviso en la siguiente ocasión que encaja, sin que nadie tenga que acordarse. Esa es la diferencia entre un sistema que aprende y uno que empieza de cero cada lunes.
Qué de esto es trasladable#
No le reconstruimos este montaje a nadie, sería absurdo. Pero tres cosas de aquí valen independientemente de las herramientas.
Primera: el asistente va donde está el trabajo, no al lado. Segunda: revisar lo tiene que hacer alguien distinto del que construye, y cuanto más distinto mejor. Tercera: lo que ya salió mal necesita una barrera, no un recordatorio.
El resto es gusto y costumbre.
