Nuestra máquina de delegar se hace mayor, la CI empieza a doler y adelantamos el feedback para trabajar mejor con agentes. Y una pregunta que empieza a ser muy real: si gastar más en IA puede aumentar la capacidad de un equipo, ¿acabaremos presupuestando tokens como hasta ahora presupuestábamos horas?
IA en 540
01. La Maquineta se hace mayor
Con La Maquineta sacamos más trabajo sin estar pendientes del flujo: ataca la épica con sus tareas y cuando necesita algo, te busca. Por eso la hemos extendido a todo el equipo del proyecto. El mensaje ha sido “usadla por defecto y reportad lo que no funcione”.
Eso ha acelerado su evolución. Su repositorio ha recibido entre 30 y 40 PRs en una semana y ahora se le pueden asignar tareas sueltas, corre en Linux, soporta stacks de PRs y se ve mejor qué está haciendo.
Extenderla ha forzado a que el proceso de definición sea el mismo para todos. Con cuatro personas cada una podía preparar la épica a su manera. Con todo el equipo delegando en ella, no.
Para eso estamos montando versiones propias de tres skills de Matt Pocock (grill-me, to-spec y to-tickets) que trabajan la definición y la convierten en tareas comprobables. Lo contaremos cuando esté cerrado.
02. La CI, ahora duele
El gasto en CI se nos está disparando en algunos proyectos. Vamos más rápido, abrimos muchas más PRs que antes (hasta 50 en un día) y los minutos de GitHub Actions incluidos se agotan en los primeros diez días del mes. Hay dos opciones: asumirlo o revisar qué tiene sentido seguir haciendo en la CI.
Antes metíamos de todo en la CI porque no dolía. Ahora toca decidir qué se lanza en cada fase (local, draft PR, PR, tras merge, manual), si todo o solo una parte, y cuántas veces: si algo rompe dos de cada mil ejecuciones, no merece correr en cada PR.
Esto es lo que estamos probando:
Subimos las PRs en draft con jobs distintos dentro y fuera del draft.
Cuando una PR se actualiza, cancelamos la ejecución en curso.
Lo que ya se comprobó en local no se repite en la PR. Se comprueba tras el merge, por si la integración rompe algo.
Autorrebaseamos antes de mergear para proteger main, y cada rebase relanza la CI entera. Quizá pueda esperar al merge.
Optimizamos build, tests y linting, porque cada minuto se multiplica por el número de ejecuciones.
03. XP ya lo dijo: el feedback, constante y temprano
Cuanto antes sabes que algo va mal, más barato es corregirlo. Extreme Programming lo llamó feedback rápido y con la IA aplica más que nunca: si delegas una tarea larga y solo miras el resultado, te ha costado tiempo, tokens y retrabajo.
Estamos adelantando el feedback en varios puntos:
Al definir la tarea, un subagente refuta los criterios de aceptación buscando contradicciones y criterios no comprobables.
Mientras el agente trabaja, otro vigila cómo razona y le da feedback (el patrón Hawk Agent). Claude Code está experimentando algo similar con los observer agents.
También probamos el advisor de Claude Code: el agente para y consulta a un modelo igual o más capaz. Sonnet trabajando y Opus aconsejando.
Adelantamos a local lo que corría en la CI. Rachel Laycock lo defiende en el blog de Martin Fowler: con la IA multiplicando el código, revisar en la PR no escala. Si el feedback vale, acércalo al momento de decidir.
Enlaces de interés
Uncle Bob duda de su propio harness
Uncle Bob lleva meses defendiendo un harness de herramientas deterministas para agentes (Gherkin, tests, métrica CRAP, mutation testing) y, viendo cuánto han mejorado los modelos, empieza a pensar que quizá los está sobrerrestringiendo, y mucho.
Runway presenta Solaris
Runway, empresa de IA generativa de vídeo e imagen conocida por sus modelos GenAI, presenta el primero de su familia Interface World Models: genera la interfaz de una app o web en tiempo real mientras el usuario interactúa, un fotograma por cada clic o arrastre, sin código intermedio.
¿Y si a las empresas de IA les interesa parecer peligrosas? - MultiVersial
Tras una semana de dimisiones y mensajes apocalípticos sobre frenar la IA, Carlos Molina plantea que a OpenAI y Anthropic les conviene amplificar el peligro: el riesgo justifica regulación con barreras de entrada y financiación estatal como cuestión de seguridad nacional.
Knowledge Compressor - GitHub Next
Compresión de documentación técnica guiada por agentes: saca preguntas sobre el original, comprime y comprueba que siguen respondiéndose. Deja los tokens a la mitad sin apenas perder respuestas. Cuando la documentación que damos a los agentes crezca y se reutilice, el recorte ahorra en cada sesión.
Una vuelta y media
Por Pablo Albizu
Unas cervezas, una barbacoa de empresa y un buen melón: ¿y si las horas extras ahora pueden hacerlas los agentes?
2025, un equipo enfocado en el desarrollo de una nueva versión de una aplicación móvil para llegar a Black Friday. Pico de trabajo, tocaba apretar y meter horas extra.
2026, mismo equipo, mismas fechas, reto parecido: rediseñar por completo la app. Solo cambiaba una cosa: ahora tenían La Maquineta, una máquina capaz de delegar la ejecución de tareas en la IA.
Ahora, pueden dejar a la IA trabajando unas horas el fin de semana sin aumentar en la misma proporción las horas metidas por el equipo. Lo hicieron, pero una persona agotó la capacidad contratada. Gasto extra ese fin de semana: 100€. Lo pagamos y punto, pero ¿y si hubiesen sido 5.000€?
De momento, tenemos bastante claro que las licencias de IA son herramientas de trabajo y su coste va dentro de nuestras tarifas. Pero si mañana puedo gastar 5.000€ más y conseguir que un equipo tenga bastante más capacidad durante unas semanas, ya no tengo tan claro que estemos hablando de lo mismo.
De hecho, puede ser el propio cliente el que diga: “estas dos semanas meted mucha más caña con los agentes y si hay que gastar 10.000€ más, gastadlos”.
Y esto no va solo de consultoría. Una empresa de producto puede hacer exactamente lo mismo con sus propios equipos.
Hasta ahora teníamos claro que si metías IA dentro de una funcionalidad aparecía un coste variable: cuanto más la usaban tus clientes, más tokens gastabas. Puede pasar lo mismo cuando construyes la propia funcionalidad.
Antes, para sacar más trabajo, necesitabas más personas o más horas. Ahora tienes otra palanca. Podemos añadir a la habitual jornada laboral horas de trabajo que hacen los agentes. Las personas siguen teniendo que dirigir, revisar y validar ese trabajo, y en un pico como este seguramente también toque meter alguna hora más, pero el rendimiento de esas horas es mucho mayor. La relación directa entre horas y output (output, no valor) se ha roto.
Eso sí, para poder decir “gastemos 10.000€ más” primero tienes que haber construido una máquina capaz de convertir ese dinero en trabajo útil. No basta con comprar más tokens y esperar que salga más software.
Nosotros llevamos tiempo trabajando precisamente en construir esa máquina y nos hemos encontrado con una consecuencia que afecta directamente a nuestros economics.
¿Empezaremos a estimar el trabajo no solo en horas, sino también en tokens? ¿Tendremos un apetito en tiempo y en gasto de IA?
¿Tendrán los equipos un presupuesto para agentes que puedan abrir o cerrar dependiendo de cuánto quieran acelerar?
¿Hasta qué punto podremos convertir más gasto en IA en más capacidad del equipo?
Como diría mi padre: con dineros, caramelos. Habrá que ver cuántos.
Enlaces de interés
Uber gasta 36.000$ al año en IA por ingeniero - Estrategia de Producto
Simón pone números al gasto de Uber en herramientas de IA. 36.000$ por ingeniero y año. Lo de los 100€ igual dura poco.
¿La IA en desarrollo va a ser pay-to-win? - Gorka Moreno
Gorka tira del mismo hilo, pero en dirección contraria: gastar más no significa producir proporcionalmente más. Rendimientos decrecientes, nuestros números en 540 y cuánto estamos pagando realmente por los tokens que consumimos.