El envío de hoy es una traducción de un post de Felipe Talavera, My Week in New York: The Future of Code Arrived Early.

Felipe, con quién coincidí durante mi etapa Flywire siendo él VP de Ingeniería, fue uno de sus primeros empleados, liderando toda la escalada técnica y organizacional de la empresa durante más de 10 años hasta su exitosa salida a bolsa en el NASDAQ en Mayo de 2021.

Siempre a la vanguardia de la tecnología, cuando Felipe habla, hay que estar atento a lo que dice. Es por eso que cuando vi su post comentando sus aprendizajes sobre desarrollo de software con IA, supe que no iba a perder el tiempo al leerlo.

Si quieres entender hacia dónde se dirige el desarrollo de software guiado por IA, te recomiendo encarecidamente que le des una lectura.

Sin más, aquí lo tenéis. ¡Disfrutadlo!

La semana pasada en Nueva York se dejó ver un esbozo de cómo evolucionará nuestra industria en los próximos 6-12 meses. Dos conferencias, AI Engineer CODE NYC y AI Native DevCon junto con una cantidad absurda de meetups ocurriendo al mismo tiempo, pintaron un retrato muy nítido de la transformación que está redefiniendo cómo construimos software.

Las charlas fueron solo el comienzo. Las conversaciones informales, con builders, escépticos y exploradores de todo tipo, amplificaron todo por diez. De ese torbellino, ciertos momentos cristalizaron. Aquí están las charlas que se me quedaron grabadas, cada una una ventana a estas nuevas “leyes de la física” del software que se están escribiendo en tiempo real.

Parte 1: Cuando el código se convirtió en sal (El cambio filosófico)

La charla de Chris Messina, “Code as Commodity”, fue el fundamento perfecto para toda la semana. El inventor del hashtag comparó el código con la sal: tan valiosa en su día que a los soldados romanos se les pagaba con ella (de ahí “salario”), y que ahora es un commodity que habilita posibilidades completamente nuevas. Su confesión dejó huella: “He hecho más commits de código en los últimos seis meses que en los últimos 20 años.”

Si el código se convierte en commodity, ¿qué se vuelve realmente valioso? Para Messina: gusto, criterio, fluidez cultural, orquestación y narración. Su advertencia sobre la estética genérica de la IA, “inmediatamente reconocible y descartable”, fue un eco constante durante toda la semana.

Partiendo de esta base, la metáfora del almacén de Ryan Carson nos ofreció un nuevo marco mental para este escenario. Imagina miles de cubos blancos brillando en un almacén oscuro, cada uno con un fantasma (un agente) leyendo instrucciones que llegan por tubos neumáticos. “Tu trabajo no es estar dentro del cubo,” dijo Carson. “Tu trabajo es diseñar la red de tubos.” Y lo respalda con hechos: migró 40.000 líneas de código a un framework nuevo en tres días porque “el código es barato, las ideas son lo que importa”.

Este giro filosófico alcanzó su punto máximo con la charla de Steve Yegge y Gene Kim y la declaración incendiaria del primero: “Si estás usando un IDE a partir del 1 de enero, eres un mal ingeniero.” Su metáfora del buzo lo dejó claro: no le des a un buzo un tanque de oxígeno más grande (más contexto)… envía un equipo de buzos especializados. La visión de Yegge sobre lo que viene a continuación es aún más radical: “Los agentes de código actuales son sierras y taladros: potentes pero manuales. El futuro son máquinas CNC: sistemas automatizados gigantes donde los ingenieros ya no miran el código directamente.” No solo estamos cambiando cómo escribimos código; nos dirigimos a un mundo donde el código se vuelve invisible para sus creadores.

A continuación, Swyx establecía el listón de la calidad en esta nueva era con su declaración de guerra contra el “slop”. Su ley, que el gusto necesario para combatir el slop es un orden de magnitud mayor que el necesario para producirlo, se convirtió en mantra. ¿Lo opuesto al slop? “Kino”: calidad cinematográfica que exige gusto y criterio humanos.

Parte 2: Reality check empresarial (La escala lo cambia todo)

Las charlas del mundo enterprise bajaron el hype a la realidad operacional. Topo Pal, de Fidelity Investments, ofreció probablemente el caso de estudio más sorprendente: una institución financiera gigante experimentando activamente con código generado por IA. La clave estuvo en su enfoque pragmático: “¿Estoy listo para usar IA para escribir software que maneja dinero? Todavía no. ¿Para desarrollar herramientas internas? 100%.”. Y su alerta: “La velocidad increíble a la que producen los agentes de IA ejercerá presión en nuestros procesos de entrega” evidenció que hasta las empresas más conservadoras luchan por seguir el ritmo de la IA. Cuando instituciones centenarias empiezan a desplegar herramientas internas “vibe-coded”, la revolución no viene: ya está aquí.

Sneha Tuli, Microsoft, compartió un dato brutal: el 5% de todos los PRs de Microsoft ya son revisados por IA. Pero la frase clave fue: “Más contexto no siempre significa mejores decisiones; puede confundir a la IA.” El humano sigue siendo imprescindible: la IA sugiere, nosotros decidimos.

Lisa Orr, Zapier, mostró cómo la IA democratiza el desarrollo: su agente “Scout” permite que los equipos de soporte solucionen el 40% de los bugs directamente. “Soporte es quien más cerca está del dolor del cliente,” explicó. Esto no va de reemplazar a los desarrolladores: va de empoderar a cualquiera a arreglar lo que se encuentre.

McKinsey explicó por qué las empresas están viendo solo un 5-15% de mejora: los procesos Agile tradicionales generan fricción. ¿Su solución? Pasar de equipos “dos pizzas” a “pods de una pizza”, unidades más pequeñas y autónomas que realmente puedan operar con velocidad IA.

Desde Stanford, Yegor Denisov-Blanch aportó datos que lo ponían todo en perspectiva: la higiene del entorno está directamente ligada a las ganancias de productividad de la IA. Su ejemplo, una empresa con un 14% más de PRs pero 2,5 veces más retrabajo, y un ROI negativo, evidenció que adoptar la IA sin ajustar procesos es peligroso.

Dex Horthy, de Human Layer, lanzó quizá el insight técnico más importante: el rendimiento del modelo se degrada mucho cuando llenas el contexto por encima del 40%. Su mantra: “No externalices tu pensamiento” resonó durante el evento: la IA amplifica lo que has pensado… o lo que no.

Parte 3: La revolución del vibe coding (Nuevas formas de trabajar)

Todos estos cambios filosóficos se manifestaron en nuevos métodos de trabajo. La charla de Kitze separó dos conceptos: “vibe coding” (naïf) y “vibe engineering” (intencional). La diferencia está en el contexto técnico. “Los managers llevan haciendo vibe coding toda la vida”, bromeó, pero su defensa del voice coding como herramienta para “pensar en voz alta” apuntó a un cambio fundamental en la forma de comunicarnos con las máquinas.

Dan Shipper, de Every, enseñó cómo luce una adopción del 100% de la IA: 99% del código generado por la inteligencia artificial, un solo desarrollador manteniendo aplicaciones completas en producción, nuevas incorporaciones productivas desde el día uno. Su clave: hay una diferencia de 10x entre adoptar la IA al 90% o al 100%. Pero su observación más radical fue sobre el término “ingeniería compuesta” (“compounding engineering”): “En la ingeniería de software tradicional, cada funcionalidad hace que la siguiente cueste más. En la ingeniería compuesta, cada funcionalidad hace que la siguiente cueste menos.” No solo están usando IA: están rediseñando el desarrollo de software para que acelere a medida que escala.

Beyang Liu, de Sourcegraph, puso palabras a la realidad diaria: “Ahora pienso en mi editor como un ‘readitor’.” Ya no editas: lees y revisas. Incluso “metieron anuncios en la terminal” para hacer accesibles los agentes, una solución pragmática a un problema real.

Parte 4: La paradoja de la calidad (Redefiniendo el ‘suficientemente bueno’)

La velocidad del desarrollo con IA ha generado una crisis de calidad que los ponentes abordaron de frente.

Jake Nations, de Netflix, presentó el marco de trabajo más sobrio de la semana: RPI: Research, Plan, Implement como fases separadas. “La IA es el botón fácil definitivo,” advirtió, pero en Netflix aprendimos a mantener límites claros entre comprender el problema (Research), diseñar la solución (Plan) y construirla (Implement). Saltarse cualquiera de esas fases hace que la IA amplifique la complejidad incorrecta. Cuando dijo “Estamos lanzando código que no entendemos”, no lo hizo como reproche, sino como advertencia. Si permites que la IA reduzca todo a una sesión de vibe coding, lo que pierdes es claridad arquitectónica, aunque ganes velocidad.

Neal Ford, de Thoughtworks, propuso fitness functions arquitectónicas: en vez de probar si el código funciona, prueba si es correcto, mediante invariantes que siempre deben cumplirse. Su enfoque de “Architecture as Code” trata las decisiones arquitectónicas como especificaciones ejecutables, evitando la fragilidad que aparece a escala enterprise.

Jennifer Sand y Brandy Pielech, de Codential, llevaron esta idea aún más lejos con su sistema de verificación basado en invariantes. Identificaron tres categorías de problemas “intestables”: demasiado difíciles (condiciones de carrera), demasiado costosos (rendimiento a escala) y demasiado complejos (explosiones combinatorias de estado). ¿Su solución? Definir invariantes desde el principio y verificar que la IA los respete. Cuando las pruebas tradicionales no encuentran bugs, no significa que no existan, significa que no estás buscando en los lugares correctos.

Eno Reyes, de Factory, expuso una verdad pragmática: “Un ‘slop test’ es mejor que ningún test.” Su insight clave no iba de bajar estándares, sino de cerrar los ciclos de verificación: “El limitador no es la capacidad del agente, sino los criterios de validación de la organización. Saca algo verificable rápido, aprende de ello, itera.” Describió un ciclo virtuoso: “Mejores agentes mejoran el entorno, y un mejor entorno mejora a los agentes.” Y su observación, “un solo ingeniero con criterio firme puede cambiar la velocidad de todo un negocio”, mostró cómo los estándares individuales moldean los resultados del equipo. Pero esos estándares deben centrarse en ciclos rápidos de verificación, no en tratar de lograr la perfección a la primera. En la era de la IA, gana el ciclo de retroalimentación más rápido.

Incluso a nivel de kernel, Natalie Serrino, de Gimlet Labs, mostró los extremos de la optimización con IA: un modelo multiplicando por 71.000 su velocidad al descubrir que una operación no hacía nada y que bastaba con devolver la entrada. Puro reward hacking, pero también una muestra de cómo la IA encuentra soluciones que a los humanos jamás se nos ocurrirían.

Las nuevas reglas del juego

Después de una semana intensa, varios patrones quedaron claros:

• La velocidad es la nueva calidad. Lanza en días, no en meses. Lo perfecto, en el futuro, nunca gana a lo suficientemente bueno ahora.

• Una persona puede ser un equipo. Pero necesita gusto, criterio y capacidad de orquestación.

• El testing cambia por completo. De “¿funciona?” a “¿es correcto?”. De test unitarios a invariantes.

• El contexto es todo… y nada. Más contexto a menudo hace que las cosas funcionen peor. 200K tokens son suficientes si sabes qué incluir.

• La adopción es binaria. La diferencia entre adoptar la IA al 90% frente al 100% es un 10x, no un 10%.

Qué significa para ti

La elección ya no es si adoptar IA. Ese tren ya partió. La elección es si estar entre el 5% que está construyendo el futuro o el 95% que está intentando entenderlo.

Empieza con estas verdades de estas charlas:

• Acepta que el código es un commodity. Lo valioso es el gusto, el criterio y la orquestación. (Messina)

• Visualiza tus agentes como fantasmas en un almacén. Tu trabajo es diseñar la red, no estar en el cubo. (Carson)

• Haz vibe engineering, no solo vibe coding. (Kitze / Pal)

• Define invariantes antes de escribir código. (Ford/Codential)

• Lanza algo —lo que sea— en días, no semanas. El ciclo más rápido gana. (Todos)

El futuro del desarrollo no está llegando, ya está aquí, solo que está repartido de forma desigual.