Hace unos días respondí a Theo en X. Defendía que, para trabajar con código, las ventajas de los modelos más capaces justifican ampliamente su costo. Pienso que está equivocado. Para él, que está en el top de la profesión, capaz la diferencia de costo se justifica. Pero el 90% de los que escribimos código no vive en ese escenario, y para esa mayoría los modelos de este nivel alcanzan de sobra. No porque la diferencia de capacidad no exista, sino porque no todos hacemos el mismo trabajo ni necesitamos lo mismo.
En mi caso, cada vez uso más los modelos disponibles a través de NaN.Builders y estoy más que contento con los resultados. Pero en vez de arrancar por el modelo, prefiero arrancar por el trabajo: hablo de desarrollo de sistemas para empresas, con usuarios reales y necesidades que no terminan cuando el código compila.
La tarea tiene una historia
Buena parte de mi trabajo consiste en mejorar un producto que ya existe. Agregar algo que falta, ajustar un flujo que resulta incómodo o resolver un problema sin romper lo que otros usan todos los días.
Porque una solución puede ser técnicamente correcta y, aun así, complicarle el trabajo a quien la usa todos los días. Ese juicio no lo delego: el modelo puede proponer, pero soy yo quien decide si un cambio mejora lo que hace la gente o se lo complica.
Por eso cada tarea llega con historia: decisiones que ya tomé, restricciones que siguen vigentes, criterio de negocio y trabajo que no quiero volver a explicar desde cero. La capacidad del modelo importa. Pero también importa cómo llega a la tarea: qué contexto tiene, qué decisiones debe respetar y cómo comprobamos que resolvió lo que necesitábamos.
Cómo organizo ese trabajo
Ahí es donde me interesa hablar del entorno que rodea al modelo. Uso Gentle AI™ como harness: la estructura desde la que organizo y conduzco el desarrollo con IA. No para reemplazar mi criterio de producto, sino para llevar esas decisiones al trabajo concreto y no perderlas por el camino. En la práctica, configura el ecosistema alrededor del agente: los flujos, las habilidades y el contexto con el que entra a un proyecto.
Cuando estoy en el trabajo diario dentro de Pi, Gentle-Shell me ofrece un espacio para seguir lo que está pasando: los cambios, las tareas, el estado de la sesión. No decide por mí si una solución sirve, pero hace más visible el trabajo que tengo que revisar antes de incorporarlo al producto.
Engram™ cubre la parte que más fácil se pierde entre una sesión y la siguiente. Conserva decisiones, descubrimientos y correcciones para que el trabajo pueda continuar con una historia. En un producto que sigue creciendo, esa continuidad me ayuda a no volver a discutir lo mismo ni a perder por qué una decisión tenía sentido. Eso sí: que una decisión esté guardada no la vuelve eterna. El producto cambia, y lo que tenía sentido ayer puede dejar de tenerlo hoy.
Con todo esto sobre la mesa, una aclaración: ninguna de estas piezas decide qué es lo mejor para el producto. Si una propuesta del modelo no mejora lo que hace la gente que lo usa, todavía no resolví la tarea.
Aclaro mis vínculos: soy maintainer de Gentle AI™ y embajador de NaN.Builders. Las uso, me involucro y banco a la gente que las construye. Así que neutral no soy. Lo que sí puedo contar es cómo me funcionan cuando hay trabajo de verdad para sacar adelante.
Dónde entran los modelos
Después de contar cómo organizo el trabajo, puedo ser más preciso con los modelos. Dentro de esa forma de trabajar, los modelos disponibles a través de NaN.Builders me están dando buenos resultados. Esa es mi experiencia cotidiana, no una comparación controlada ni una afirmación de que todos los modelos rinden igual.
Eso no significa que el harness borre los límites de cada modelo. Cuando un modelo no alcanza para una tarea, no alcanza. Lo que me da una buena forma de trabajar es otra cosa: una tarea delimitada, el contexto relevante para resolverla y una manera de verificar el resultado antes de incorporarlo. Sin garantías universales: ni de que todo salga bien, ni de que cada límite se note temprano. Lo que sí queda es registro de las correcciones y la posibilidad de seguir avanzando sin arrancar cada vez desde cero.
Qué necesito, entonces
Al final, no busco que la IA decida por mí qué producto construir. Busco capacidad suficiente para el trabajo real: que el modelo resuelva lo que tengo que entregar, con contexto y con control de lo que se incorpora.
Y también necesito saber reconocer cuándo la capacidad no alcanza. A veces la respuesta es el modelo más potente, y ahí el costo se justifica. Pero ese caso es la excepción, no la regla. Otras veces lo que falta no es más modelo, sino mejor contexto y una forma de trabajar que conserve las decisiones. Elegir bien entre esas dos situaciones es parte del trabajo. Y por eso sigo en desacuerdo con Theo: la discusión no es qué modelo usás, es qué trabajo tenés entre manos. El mío, como el de la mayoría, se resuelve con contexto, criterio y una buena forma de trabajar. El modelo entra después.