la sociedad subyacente está cambiando.
Esa fue una de las ideas de la charla de Max Buckley en AI Engineer Singapore, y se me ha quedado grabada desde entonces.
Durante décadas, la ingeniería de software se organizó en torno a la escasez. Escribir código era caro, los ingenieros eran escasos y las funciones requerían tiempo. Esta suposición moldeó la forma en que trabajaban los equipos. Priorizamos cuidadosamente porque cada característica tenía un costo de oportunidad enorme.
Pero la IA ha roto esa suposición.
A medida que los agentes codificadores se vuelven más capaces, el costo de implementación cae dramáticamente. Lo que antes llevaba semanas, ahora se puede crear un prototipo en días o incluso horas. Max, jefe de investigación de conocimientos en Exa después de pasar 12,5 años en Google, enmarcó esto como un cambio en la teoría de juegos: no se trata sólo de preguntar qué debes hacer, sino qué debes hacer cuando todos los demás también se comportan de esta manera e intentan ganar.
Y no puede optar por no participar en estos cambios. Estemos o no preparados para ello, las formas fundamentales de trabajar están cambiando.
Pero una implementación más barata no significa mejor software.
Ninguna cantidad de IA puede salvarnos de construir algo equivocado. De hecho, la IA puede empeorar ese problema. Cuando construir se vuelve más fácil, resulta mucho más fácil crear cosas que sean técnicamente impresionantes pero estratégicamente irrelevantes: más paneles, más flujos de trabajo, más herramientas internas, más aplicaciones que funcionan pero que no merecen existir.
Por eso creo que el criterio de ingeniería es cada vez más valioso.
Uno de los ejemplos de Max se quedó conmigo. En la antigua economía del software, los equipos debían reducir 30 ideas a 3 antes de construir algo. Con los agentes codificadores actuales, el proceso de decisión cambia. Puedes construir más, evaluar más, comparar más y descartar lo que no funciona con menos apego emocional.
El coste de intentarlo es menor y la experimentación se vuelve más atractiva.
Esto suena liberador, pero también crea un nuevo cuello de botella.
Si alguien puede crear un prototipo de una idea, la atención es ahora un recurso escaso. Eso también significa que debo agradecer a cada persona que lea esto. Su atención no es gratuita y espero haber hecho que este artículo valga la pena.
Recientemente asistí a la conferencia inaugural de ingenieros de inteligencia artificial en Singapur, celebrada del 15 al 17 de mayo de 2026. Reunió a oradores de empresas como Google DeepMind, Vercel, OpenAI, Exa, NanoClaw y otras. Este artículo detallará 3 puntos de 3 oradores que me llamaron la atención.
La IA no elimina la necesidad de una disciplina de ingeniería. Se trata de trasladar esa disciplina a una parte diferente del sistema.
El conocimiento técnico también está cambiando de forma.
Los modelos tienen una inteligencia irregular: pueden ser extremadamente buenos en algunas tareas, pero sorprendentemente malos en tareas cercanas que parecen igualmente fáciles para los humanos.
Los modelos a menudo conocen las respuestas a cosas complicadas, pero no las sacarán a la luz a menos que sepas qué preguntar.
Así que la cuestión ya no es sólo si podemos construir algo. Es si debería existir.
Jimmy Lai, director de Next.js en Vercel, compartió un sentimiento similar desde un ángulo diferente. Su punto era que la IA ha hecho que la creación sea barata, pero la propiedad más cara.
Cuando construir se vuelve más fácil, aumenta la cantidad de cosas que podemos crear. Pero cada prototipo que sobrevive se convierte en algo que alguien tiene que mantener, depurar, documentar, proteger y explicar. El costo de escribir la primera versión puede disminuir, pero el costo de poseer el sistema no desaparece.
Jimmy hizo tres predicciones que me llamaron la atención.
Primero, ahora estamos construyendo para agentes. Los agentes se están convirtiendo en un nuevo tipo de usuario de software. Un archivo README obsoleto ya no sólo es molesto para un ser humano. Es una alucinación esperando a suceder.
En segundo lugar, ahora estamos construyendo con agentes. Irónicamente, aunque ahora resulta más fácil poder construir algo que no se comprende del todo, la verdad es que los fundamentos no han cambiado y, de hecho, se han vuelto más importantes que nunca. Si te vuelves excelente construyendo con agentes y al mismo tiempo eres fuerte en los fundamentos, te vuelves imparable.
En tercer lugar, tenemos que aprender qué no poseer. Sólo porque puedas construir algo no significa que debas hacerlo. La facilidad de creación se ha convertido en una carga de mantenimiento.
Esto no significa que debamos enviar menos. Significa que deberíamos ser más intencionales respecto de lo que permitimos para sobrevivir. La ventaja es para los equipos que saben qué hace que su producto sea diferente, qué merece su atención y qué no deberían crear deliberadamente.
En un mundo donde la creación de software es barata, la concentración se convierte en un activo de ingeniería.
Finalmente, mi última conclusión clave provino de una charla sobre diseño.
Phil Hedayatnia de Airfoil dio una charla sobre cómo crear agentes de diseño que realmente tengan gusto en un mar de desechos de IA muy normales. No soy diseñador, por lo que normalmente pienso en el diseño en términos de lo que un buen diseño debería o no contener. Su charla me reformuló eso.
El diseño no trata de enseñarle a alguien qué hacer y no qué hacer. Eso es capacitación sobre resultados.
El buen diseño consiste en comprender cómo piensan las personas, cómo actúan y por qué ciertos flujos, elementos visuales y narrativas resuenan en ellas. Phil lo aludió a la psicología humana.
Se trata menos de mirar lo que la gente hace, sino de dedicar más tiempo a tratar de comprender por qué lo hicieron de esa manera y el proceso de pensamiento detrás de ello.
En otras palabras, el gusto no es una lista de verificación. Es un juicio aplicado al contexto.
Phil puso el ejemplo del tren bala Shinkansen y el billete del martín pescador. El tren tenía un problema: al salir de los túneles, creaba un fuerte “estruendo del túnel” provocado por el aire comprimido. Los ingenieros redujeron el ruido modelando la nariz del tren según el pico de un martín pescador. Un martín pescador puede sumergirse desde el aire al agua sin apenas salpicar porque su pico largo, estrecho y cónico reduce los cambios repentinos de presión. Los ingenieros aplicaron el mismo principio al tren, utilizando una nariz más larga y cónica para comprimir el aire de forma más gradual.
Lo que me gustó de este ejemplo es que no se trataba sólo de copiar la naturaleza. Se trataba de comprender por qué algo funcionaba y luego aplicar ese principio en un contexto diferente.
Y como la IA facilita la producción de resultados, la habilidad valiosa no consiste simplemente en saber cómo es un buen resultado. Es entender el por qué detrás de esto.
para terminar
En muchas de las charlas, hubo muchos temas recurrentes, como la creación de asistentes personales, la prueba de nuevas herramientas y el aprendizaje de cómo trabajar de manera más eficiente con los agentes. Pero debajo de todo eso, seguía surgiendo la misma idea: el código se está volviendo más barato, pero el juicio y el gusto no.
Para resumir mis 3 conclusiones clave:
La implementación ya no es el principal obstáculo. La IA le permite probar más ideas y reducir los costos de equivocarse. Pero eso hace que el juicio de ingeniería sea más crítico. Tenemos que decidir qué merece existir. La creación barata crea una carga de mantenimiento. Decide qué no poseer. En un mundo de producción abundante, cree productos con mejor sabor. Comprender el contexto detrás de por qué algo funciona.
La IA ha cambiado la forma en que creamos software, pero no ha eliminado la responsabilidad y la propiedad detrás de él.
Eso es todo de mi parte. Espero que esto haya valido la pena. Las charlas completas están en Youtube del ingeniero de IA aquí. Todas las fotografías de la conferencia fueron compartidas por los organizadores, 65labs. ¡Nos vemos en el próximo artículo!
