AI First Development

Tengo la sensación de vivir en dos mundos diferentes en este momento, y quiero aclarar mi posición sobre el uso de la IA en el desarrollo de software. Por un lado, hablo con ingenieros senior que trabajan en aplicaciones en producción y que están entusiasmados con usar la IA para reforzar su arquitectura. Por otro lado, hablo con desarrolladores senior que son escépticos sobre el uso de agentes en el desarrollo de software porque temen el “slop de IA” y el código mal generado. Elegí ser entusiasta sobre los agentes de coding con IA por varias razones que quiero explicar aquí.

Los agentes de IA no son solo una herramienta de productividad

Trabajar con agentes de coding te obliga a pensar en términos de delegación. Necesitas definir claramente los entregables que necesitas. Una buena delegación es una habilidad, y es difícil entrenarla con humanos porque requiere años de management para entender cómo delegar correctamente. Lo sé muy bien porque soy (¿era?) muy malo en management de equipos. Tiendo a resolver los problemas por mí mismo en lugar de coordinar al equipo para que ayude. Así que soy la primera víctima de eso.

Gracias a la IA y a los agentes de coding, he aprendido un montón sobre la buena delegación. Al principio pedía demasiado o demasiado poco: “Cambia este botón a azul” es demasiado pequeño para delegar. “Añade más tests” es demasiado. Necesitas encontrar el punto justo para tus agentes.

• Para el problema de “demasiado pequeño”:

  • Agrupa tus peticiones. Pide un montón de pequeños cambios a la vez; tómate el tiempo de listar todos tus cambios y enviarlos.

• Para el problema de “demasiado grande”:

  • Divide la tarea en pasos lógicos.
  • Añade más detalles en el brief sobre cómo escribir los tests. Apunta a ejemplos que funcionen bien.
  • Pide resultados medibles: un enlace a la página para hacer QA, un test verde para verificar, etc.

Para volver a mi punto: deja de tratar la IA como una herramienta y empieza a repensar la forma en que trabajas como desarrollador. Delega más creando sistemas de validación robustos en los que puedas confiar.

Piensa así:

“¿Qué pasa si añado 50 desarrolladores senior al equipo ahora mismo? ¿Cómo los staffeo? ¿Cómo les paso las specs de producto? ¿Cómo trackeo el progreso? ¿Dónde deberían hacerme preguntas, y cuándo? ¿Cómo valido el trabajo? ¿Dónde está la documentación para ellos? ¿Cómo aprenden colectivamente para evitar cometer los mismos errores dos veces?”

Lo que significa un desarrollador 10x

Un desarrollador hoy debería ser capaz de trabajar en 8 a 10 aplicaciones al mismo tiempo en lugar de en 1 o 2. Eso significa ser capaz de mantener más contexto en la cabeza. Es muy difícil saber exactamente lo que pasa en 10 aplicaciones diferentes cuando no has trabajado directamente en ellas. Necesitas poner sistemas en su sitio para asegurarte de trackear todo lo que pasa como input y output de las aplicaciones. Es solo ingeniería de software:

• Documentación limpia: crea sistemas que actualicen automáticamente la documentación con cada cambio de código para que sepas exactamente lo que hacen las APIs.
• Suite de tests robusta: +90 % de cobertura de tests, sin tests flaky, fixtures masivas que representen datos del mundo real, y velocidad de la suite de tests.
• Reportes de bugs: ser capaz de entender los bugs en producción, replicarlos localmente, arreglarlos, desplegar, y escribir los aprendizajes en una documentación central para evitar volver a cometer este error.
• Chaos monkey: ejecuta agentes localmente para hacer fuzz test a las aplicaciones e intentar encontrar puntos ciegos y casos de uso no cubiertos.
• Servidores de QA: asegúrate de poder hacer QA de cada rama individualmente en entornos aislados para probar varias funcionalidades al mismo tiempo.
• Revisiones de código limpias: necesitas ser capaz de revisar todo el código que se sube a producción. Usa un agente que haga una primera pasada de code review.

Ahora tienes las herramientas para crear tales sistemas y tener confianza en toda tu infraestructura.

Cada cambio es información

A veces escucho esto: “¿Por qué usar un LLM para cambiar el color de un botón?” El problema con estos pequeños cambios es que vienen de “canales no monitorizados”. Eso significa que el problema es sistémico, no atómico. Si, en una videollamada con el equipo de producto, alguien dijo que este cambio es necesario, eso significa que no hay tracking del porqué. El porqué es importante porque este mismo tipo de cambio puede aplicarse a otras partes de la aplicación más adelante, y si tienes un sistema de memoria en su sitio con tus agentes, serán capaces de recordarlo y anticipar estos cambios. Todo es cuestión de memoria y patrones. Cuanto más guardes, menos tendrás que repetirte más adelante. PD: no me malinterpretes, si un cambio de color es necesario en algún sitio, probablemente sea un cambio de design system para aplicarse en todas partes para mantener la consistencia en la UI. Solo estaba haciendo el punto sobre los “pequeños cambios”.

Orquestación de agentes

El verdadero tema ahora es la orquestación, y todo el mundo está intentando construir buenos sistemas alrededor de su infra. OpenClaw, PaperClip y tantos otros están intentando resolver el problema. Estoy entusiasmado con NanoClaw porque creo que es la mejor base sobre la que construir. Aislamiento Docker por defecto, muy ligero, y un code base completo que es fácil de revisar. Subiré más actualizaciones sobre mi setup de NanoClaw pronto, pero probablemente sea el camino a seguir.

La respuesta es: todavía no hay una respuesta clara. Todos estamos intentando descifrarlo.

Producto primero

Tengo la suerte de venir de un background de producto. Siempre quise crear productos y resolver problemas (puedes aprender más sobre mi background aquí). Luego “tuve” que codear y crear sistemas robustos para que estos productos pudieran crecer. Pero nunca me gustó codear. Me gustaba el resultado, no el proceso. Y ahora podemos crear un proceso que genera código limpio y valida el resultado mientras mantiene el sistema sano. Es la mejor época para estar vivo como desarrollador senior. Me gusta enfatizar el hecho de que no me gusta codear. Escribir código a mano no debería estar permitido más. Nunca me sentiré frustrado por no escribir código. Quiero pensar en sistemas y arquitectura, no en detalles granulares. El código ya no tiene un valor real, pero tus salvaguardas de IA sí.

Quién está en peligro

Sigo pensando que los desarrolladores estarán más demandados que nunca antes porque la demanda de software es infinita. Dicho esto, se le pedirá a cada desarrollador que gestione mucho más que antes. Los juniors romperán cosas, y espero muchas brechas de seguridad y de datos viniendo de código de IA no supervisado corriendo en producción. Las empresas tendrán entonces dos opciones: contratar gente senior (cualquiera con +10 años de experiencia en el campo) y empujar formación avanzada a los juniors para mantenerlos sin romper producción.

Ok, pero quién está en peligro:

• Cualquier desarrollador que intente acaparar algún tipo de información estará fuera de juego muy pronto. Los agentes de coding ya ayudan a los equipos de producto a entender el code base y ver lo que existe o no, el flujo de datos, las condiciones, y pueden hacer preguntas al code base en lugar de a los desarrolladores.
• Cualquier product manager que intente justificar entregas tardías con “los desarrolladores son más lentos de lo esperado en esta tarea” no podrá hacerlo más. Tienen que asegurarse de que las specs de producto iniciales sean claras porque esa es la raíz de todo. Al no ser ya la ejecución el bottleneck, pasa a las specs claras y al QA, que es trabajo del equipo de producto.
• A los desarrolladores que les gusta codear no se les debería permitir hacerlo en un entorno profesional, sino solo como hobby. No puedes estar perdiendo tiempo tecleando caracteres en un teclado cuando deberías estar concentrado en arquitectura, estrategias de refactoring, consistencia de datos, cobertura de tests, entornos de QA, y muchas más tareas de alto nivel. No tienes permitido escribir cartas a mano para coordinar un equipo cuando tienes Slack. Pero puedes hacer poesía perfectamente los fines de semana.
• Los desarrolladores que no dedican al menos 3h a 4h a la semana a leer noticias sobre tech, herramientas e IA.
• Los desarrolladores que no tienen side projects donde pueden empujar los límites de la IA y romper cosas sin ningún impacto real en producción. Los desarrolladores tienen que probar nuevas herramientas y técnicas de context engineering para mantener el ritmo.
• Los desarrolladores que no son capaces de comunicarse claramente con los otros equipos.

Es duro escuchar a alguien decir “Joder, ¿por qué este botón no funciona? Es inaceptable” cuando este botón es un sprint de 3 semanas que hiciste con 3 rondas de QA y “todo iba bien”. Hasta que un comercial hizo una demo a un cliente con datos muy random y rompió la funcionalidad, perdiendo la confianza del cliente justo delante de sus ojos. Como desarrollador, tienes que enfrentarte a estas situaciones y encontrar soluciones para arreglar el problema y garantizar que no volverá a pasar. Los desarrolladores ya no pueden esconderse del mundo real porque el mundo viene a por ellos con argumentos claros. Una persona de producto puede perfectamente preguntar a un code base “¿Por qué esta funcionalidad se rompe cuando hago esto?” y sacar un plan perfecto sobre los tests faltantes y los puntos ciegos que el desarrollador se perdió en primer lugar.

Conclusiones

En realidad es muy gracioso que publiqué este artículo hace casi 10 años, y nada ha cambiado, la ingeniería de software sigue manteniendo los mismos fundamentos: How to become a good software engineer.