¿Has visto a esos indie devs con 20 agentes de IA trabajando al mismo tiempo? Tres diseñadores, dos de QA, un PM, cuatro desarrolladores, dos expertos en marketing, un abogado, un contador, un asesor financiero, un psicólogo para el equipo, un agente que organiza las juntas, otro que toma notas, uno que revisa las notas y otro que revisa al que revisó las notas.
Y, por supuesto, el CEO: un agente que dirige todo el proyecto desde una carpeta en la computadora.
Mientras tanto, el side project todavía no tiene usuarios.
Yo también uso agentes y orquestadores, y me divierte jugar con ellos. Pero después de muchas iteraciones llegué a algo que no sale en esos videos: más agentes no es más trabajo hecho. Es más trabajo que revisar. Y esa revisión no se la puedes dejar al mejor modelo, ni siquiera en su modo más potente.
Darle la tarea es apenas el principio
Al inicio es fácil pensar: "Este modelo sabe muchísimo. Le doy la tarea y listo". Puede hacer cosas impresionantes. También puede tomar decisiones que no le pediste, agregar funciones que nadie necesita y convertir algo simple en un desastre.
Me ha pasado. Le pido un cambio y, cuando reviso, hay tres funciones extra. Una vez un agente armó toda una galería web para enseñarme qué había cambiado, cómo y por qué.
Yo no pedí una galería. Quería que terminara la tarea original. Se gastó un montón de tokens en algo que no necesitaba y, para acabarla, la primera versión salió horrible.
Quizá eso tenía sentido para el modelo. Para el producto no tenía ninguno, ni para quien lo iba a usar.
Así que mi trabajo no termina cuando doy la instrucción. Empieza antes, cuando decido qué problema quiero resolver y qué se queda como está. Y sigue después de que el agente dice "listo", cuando me toca entender qué hizo y si es lo que quería.
Dos agentes pueden coincidir y aun así estar equivocados
Trabajo con un orquestador que me deja dividir una tarea entre varios agentes. Pueden ser hasta diez, aunque casi nunca necesito tantos. Cada uno tiene que tener una razón para estar ahí: uno construye, otro revisa, otro busca errores o checa si metimos complejidad de más.
Funciona. Un segundo agente encuentra cosas que el primero pasó por alto. Pero también leo esas revisiones, porque dos agentes pueden coincidir y aun así estar equivocados. Te confirman que el código funciona sin notar que esa función nunca hizo falta. O resuelven perfecto un problema que no era el de verdad.
Ahí ningún agente me reemplaza. Yo conozco el proyecto y sé lo que intento construir.
Tampoco todos los modelos sirven para lo mismo. Mi reparto ahorita: Codex con GPT Images para los assets, Claude Opus 5.5 para la lógica de programación y Grok 4.7 en Cursor para ajustes rápidos de estilos. No llegué a eso el primer día. Tuve que probar cada uno y ver cómo respondía, y seguro cambiará con los próximos modelos.
El gusto sigue siendo tuyo
Esta es la parte que más me importa.
Los modelos siguen mejorando, pero creo que van a pasar años antes de que la IA imite de verdad el gusto de una persona. Y el gusto es subjetivo. Lo que a mí me encanta a ti te puede chocar, viendo exactamente la misma pantalla.
Dos desarrolladores pueden usar el mismo modelo, de la misma empresa, y terminar con productos completamente diferentes, porque cada uno decide distinto qué se queda y qué se va.
A mí me pasa mientras trabajo. Veo una primera versión y todavía no sé decir qué le falta. Cambio algo, pruebo otra idea y poco a poco entiendo qué buscaba. Cada vuelta cambia cómo veo el resultado.
Por eso no delego la revisión. Los agentes me pueden dar opciones y ayudarme a probarlas. Cómo se siente el producto, qué detalles me convencen, cuándo por fin cuadra: eso lo decido yo.
La IA no sabe cuándo callarse
Para mí la IA es como una persona ultrainteligente que parece acordarse de todo sobre casi cualquier tema. Te da ideas, escribe código y encuentra soluciones que no se te habían ocurrido.
Pero muchas veces no sabe cuándo callarse.
Es como ese amigo que tiene de todo y siempre quiere contarte lo que hizo con ello. Lo escuchas y piensas: "Sí, qué impresionante, pero ¿de verdad necesitabas gastar tanto tiempo y dinero en eso?".
Le pides una solución y te la da, más una función extra, otra capa y una explicación de todo lo que hizo.
Así que cambié la pregunta. Mi primer instinto era "crea esto", "agrega aquello", "dale una función más". Ahora, después de ver lo que propone, le pregunto:
"De todo esto que quieres crear, ¿qué podríamos quitar?"
Y le pido que revise antes de tocar nada: qué depende de ese código, qué dejaría de funcionar, si seguimos resolviendo el problema original. Si solo le digo "quita esto", puede hacerlo tal cual y nunca revisar qué se rompe.
A veces descubre que el proyecto ya tenía una forma de hacerlo. Otras, encuentra código que agregó y que se puede ir sin romper nada.
Cada iteración se vuelve una regla
Un buen resultado me puede tomar 15 o 20 iteraciones, a veces menos. Cada una me deja cachar un error, explicar mejor lo que necesito o darme cuenta de que quiero otra cosa.
Esas lecciones terminan en el harness: las instrucciones, herramientas y reglas que guían cómo trabajan los agentes. Casi todas las mías hablan de lo que no quiero:
- No agregues funciones que no te pedí.
- No crees páginas o reportes extra a menos que sean necesarios.
- No elimines código sin revisar qué depende de él.
- No des una tarea por terminada sin comprobar que funciona.
- No compliques la solución más de lo necesario. Más código no es un mejor resultado.
Me sirven para no gastar la siguiente iteración limpiando trabajo que nunca pedí.
Antes de agregar otro agente
Sigo descubriendo cuántos agentes usar, qué tarea darle a cada modelo y cómo coordinarlos. Algunas tareas necesitan varias revisiones. Muchas solo necesitan una instrucción clara.
El número de agentes no hace bueno un proyecto. Lo hace bueno alguien que revisa, decide y se atreve a quitar.
Por eso, antes de agregar otro agente, otra función o más código, me detengo y pregunto:
¿Qué podemos quitar sin perder lo importante?