Con agentes de por medio, confiar sale caro y comprobar sale barato. Esta semana atacamos un WordPress, medimos cuánto nos falta para dejar de leer código y conseguimos que Opus 5 deje de escribir comentarios. Y, ya que estamos delegando cada vez más cosas, nos preguntamos para qué vamos a necesitar desarrolladores.
IA en 540
01. Ahora cualquiera puede atacar tu web
El incidente entre OpenAI y Hugging Face demostró que los agentes ya pueden encontrar y encadenar ataques contra sistemas. Nos hizo pensar en cómo usar esa misma capacidad para descubrir vulnerabilidades antes de que alguien las explote.
Lo probamos con un WordPress de pruebas que replica una configuración real. Necesitábamos un modelo que aceptara tareas ofensivas dentro de un entorno controlado. Fable 5 limitaba estas peticiones, así que usamos GLM-5.2, un modelo abierto comparable a Opus 4.6 en tareas de seguridad, a través de OpenRouter y una versión de OpenCode preparada para pentesting.
Hemos recogido la prueba completa en este informe. El agente identificó 38 posibles vías de ataque y aprovechó un fallo en un plugin de calendario sin actualizar. Desde ahí encadenó 34 peticiones para recuperar la contraseña del administrador y entrar con esa cuenta, sin que tuviéramos que guiar cada paso.
Si nosotros hemos llegado hasta aquí, alguien que se dedique a atacar podría llegar mucho más lejos. Ahora que la IA permite aprovechar cualquier descuido con mucha más rapidez, vemos imprescindible incorporar revisiones de seguridad y mantener al día las versiones y los parches.
02. ¿Cuánto te falta para dejar de revisar cada línea?
Hace poco contamos que Uncle Bob ya no revisa el código que escriben sus agentes porque cada cambio supera una serie de comprobaciones deterministas. Para saber qué nos falta, hemos convertido su marco en una skill.
La skill comprueba si un repositorio puede verificar cambios sin depender de que una persona lea cada diff. Para ello mide nueve controles sobre especificación, tests y calidad del código. Puntúa cada uno de 0 a 4, señala el fichero y la línea que lo justifican y propone entre tres y cinco mejoras priorizadas por confianza y esfuerzo.
Hemos compartido la skill para que audites tu proyecto. La vamos a aplicar en los nuestros y compartiremos los resultados.
03. Que Claude Code no llene tu código de comentarios
Seguimos tratando de domar a Opus 5. Por mucho que las reglas le indiquen que no escriba comentarios, los añade y consigue justificarlos todos.
Siempre hemos preferido que el código se explique solo y sea la única fuente de verdad. Si un bloque necesita un comentario, solemos verlo como un fallo de expresión: antes mejoramos el nombre o extraemos un método. Los comentarios pueden quedarse desactualizados y acabar mintiendo.
Hemos convertido la regla en un hook de Claude Code. Se lanza antes de escribir y rechaza cualquier comentario nuevo, respeta los existentes y exige aprobación para las excepciones. Cuando una regla se puede comprobar, dejamos de pedírsela al agente y la convertimos en un control determinista.
Enlaces de interés
AirLLM: modelos enormes con poca VRAM
AirLLM carga el modelo por capas para reducir mucho la memoria necesaria durante la inferencia. Esto permite ejecutar modelos muy grandes en una sola GPU con poca VRAM, como Llama 3.1 405B en 8 GB.
Asientos Premium para ChatGPT Business
ChatGPT Business añade asientos Premium con cinco veces más uso, sin el límite de cinco horas. La suscripción para equipos se equipara así a las opciones que ya ofrece Claude Code y elimina uno de los principales inconvenientes de nuestra prueba de Codex: ser bastante más caro al tener que pasar enseguida a pago por uso.
OpenAI amplía Daybreak
Más organizaciones podrán acceder a los modelos avanzados de ciberseguridad de OpenAI a través de socios aprobados: Blue cubre flujos defensivos y Red trabajos más sensibles. Como vimos al probar GLM-5.2, la idea es poner esa capacidad de ataque en manos de los defensores para que encuentren y corrijan vulnerabilidades antes de que alguien las explote.
Una vuelta y media
Por Pablo Albizu
Hace unos meses vivimos un experimento en uno de nuestros clientes: quitar a los Product Managers de un equipo y acercar directamente a los desarrolladores a los stakeholders.
Unos meses después, el experimento ha funcionado pero no igual para todos.
Hay personas que se han adaptado perfectamente al nuevo rol de “product builders”. Hace tiempo se pasaron el “juego tecnológico” y lo que les motiva de verdad es el impacto en el negocio. Hablan con stakeholders, entienden hacia dónde van, gestionan prioridades, aterrizan el producto, levantan la mano si la cosa se tuerce y además lo ejecutan con IA.
El hombre orquesta. El mirlo blanco. Los Pogacar del ciclismo.
El problema es que no todo el mundo tiene la misma experiencia ni las mismas habilidades innatas. Una cosa es tener product mindset y otra es pedirles que gestionen: coordinar dependencias, comprometer fechas, perseguir temas, comunicar avances, detectar que algo se está torciendo antes de que sea demasiado tarde y responsabilizarse de que todo llegue a buen puerto.
Hay personas muy buenas técnicamente, y con muchísimo product mindset, que están sufriendo con el cambio. No porque no entiendan el negocio, sino porque de repente les estamos pidiendo habilidades de gestión, comunicación, coordinación y liderazgo que antes no eran una parte tan importante de su trabajo.
Así que, ante este panorama, tenemos dos alternativas.
La primera es diseñar nuestros equipos pensando que todos sus miembros deben ser ingenieros excepcionales capaces de moverse desde una conversación de negocio hasta la implementación. Equipos pequeños y muy productivos.
Luego llegará Paco con las rebajas: tendremos que pagar lo que cuestan esas personas, competir por ellas y aceptar que hemos reducido muchísimo el conjunto de gente que puede trabajar con nosotros.
Y, muy importante, comprobar que tenemos suficientes problemas a la altura de su ambición. Un equipo lleno de mirlos blancos también necesita trabajo para mirlos blancos. Pogacar quiere correr el Tour de Francia, no el Gran Premio Miguel Induráin de mi pueblo, Estella.
La segunda, aceptar equipos más heterogéneos y construir un nuevo proceso incluyendo la IA alrededor para que personas con capacidades distintas puedan funcionar bien juntas. Ni tan corto ni tan calvo.
Aquí aparece una posibilidad, podemos acabar teniendo ingenieros capaces de entender un problema, diseñar el producto y construir los sistemas de agentes que producen el software.
Y otros cuyo trabajo se parezca más a controlar y mejorar la cadena de producción: comprobar que el sistema funciona, asegurar la calidad del resultado y modificar el propio proceso cuando algo falla. Jamon Holmgren lo explica aquí perfectamente.
No son dos niveles del mismo trabajo, sino dos trabajos diferentes.
Y si realmente terminan siendo trabajos distintos, también tendrán distinto valor en el mercado: salarios, oportunidades, capacidad de negociación y carreras profesionales diferentes.
Quizá estemos viendo cómo una profesión empieza a dividirse en dos.
Enlaces de interés
In five years, everyone will be a product manager - Gojko Adzic
Equipos más pequeños, más autonomía y responsabilidades de producto cada vez más repartidas. La trampa: asumir el trabajo de un PM no significa saber hacerlo.
De desarrollador a Product Engineer
Una escalera de 12 pasos para pasar de ejecutar tickets a entender el negocio, hablar con usuarios, liderar discovery y responsabilizarse del producto.
5 comportamientos que definen a un Product Engineer - Javier Escribano
Cuando los desarrolladores dejan de ser los que construyen - Gorka Moreno
Si la IA permite que producto y negocio construyan directamente, quizá el trabajo del desarrollador pase a ser crear las herramientas y garantías para que puedan hacerlo.
"[...] podemos acabar teniendo ingenieros capaces de entender un problema, diseñar el producto y construir los sistemas de agentes que producen el software.
Y otros cuyo trabajo se parezca más a controlar y mejorar la cadena de producción: comprobar que el sistema funciona, asegurar la calidad del resultado y modificar el propio proceso cuando algo falla. [...]"
Esto creo que se está empezando a ver cada vez más claro, y pensando en etiquetas puede ser la diferencia entre las posiciones de Product Engineer y AI Engineer. Aunque como con tantas otras cosas yo creo que es un espectro, y tampoco sé si lo plantearía como dos trabajos separados porque puede llegar a haber bastante solape; supongo que terminará dependiendo de cada organización y de cada producto.
¡Gracias por la reflexiones Pablo!
Había entendido mal la pregunta. Ahora la entiendo: los devs se van a seguir necesitando, ahora el tema es "para qué". Gracias David por la aclaración!