Tenés que romper tu vieja forma de hacer software

Cada gran ola tecnológica trajo una nueva generación de empresas. El desktop, internet, el cloud, mobile. Cada una cambió las herramientas, pero también cambió las formas de trabajar, las estructuras y los negocios que eran posibles.

La inteligencia artificial generativa sigue exactamente ese patrón. Nueva tecnología, nueva forma de trabajo, nuevas organizaciones, nuevos negocios.

Las compañías que entiendan este cambio de verdad, que se rediseñen alrededor de esto y que aprendan a operar así, van a ser estructuralmente mejores. Las que lo posterguen van a pasar años intentando alcanzar algo que para otros ya es presente.

Este paper se organiza en cuatro ejes que se conectan entre sí:

Cómo se construye software hoy — el cambio en la forma de producir.
People — qué cambia en los skills, los equipos, las dinámicas y el liderazgo.
Gobierno — cómo se controla todo esto para que escale sin romperse.
Arquitectura — cómo la plataforma se convierte en un sistema pensado para agentes y contexto.

I. Cómo se construye software hoy

En los últimos 18 meses, la industria de desarrollo de software y construcción de productos digitales pasó por dos fases que cambiaron todo.

La primera fue la posibilidad de generar código usando lenguaje natural. Esto le dio a cada desarrollador algo parecido a superpoderes. Un ingeniero pasó de saber algunos lenguajes de programación a saberlos todos. Pasó de tener dudas sobre cómo armar una arquitectura a tener la mejor respuesta disponible, y hasta la posibilidad de que se la construyan en gran parte. Esto dio una velocidad de producción nunca antes vista. Los equipos ganaron velocidad, pero al mismo tiempo se alejaron del código.

Esta dinámica creció exponencialmente cuando apareció la posibilidad de darle contexto —código previo, documentación, reglas del sistema— para que los superpoderes sean mucho más precisos. Es lo que muchos llaman vibe coding: describís lo que querés, el sistema lo genera, iterás rápido. Funciona. Acelera. Pero tiene un límite: el desarrollador sigue operando en modo local, en su máquina, saltando entre prompts y validaciones.

La segunda fase es donde cambia todo.

Si tomás el vibe coding que cada ingeniero practica en su máquina local y lo replicás en la infraestructura, el múltiplo de construcción ya no depende de cuántas personas están usando esto en su computadora. Depende de especificar con máximo detalle lo que se quiere construir y procesarlo a otra escala. Esta práctica se llama SDD: Spec-Driven Development.

Las especificaciones son funcionales y técnicas. Las funcionales también se construyen con AI, aprovechando su capacidad para generar casuísticas de borde y detalle profundo de cada una. Eso permite que la especificación técnica siga el mismo criterio y sea más precisa por el nivel de detalle funcional que recibe. Sobre esas specs operan agentes. Un orquestador interpreta la especificación, la fragmenta y la distribuye a agentes especializados: uno genera código, otro testea, otro valida seguridad, otro documenta. La construcción deja de ser lineal. Se vuelve paralela, escalable y coordinada.

La velocidad ya no está en el código. Está en la capacidad de eliminar burocracias en los procesos que permiten diseñar y definir el producto, para que los agentes produzcan. Está en armar procesos iterativos más rápidos y decisiones más simples.

Esto hace que equipos de Producto, UX y Tecnología cambien la forma de construir. Cambian sus herramientas, sus dinámicas, las expectativas entre roles y áreas. El resto ya es un efecto dominó que impacta en prácticamente todas las áreas de la empresa.

Y en ese contexto, People se convierte en un enabler clave para que esto suceda. Nuevas herramientas, nuevas dinámicas, nuevos superpoderes. Todo eso requiere nuevos skills. Y si los skills cambian, cambia cómo medimos, cómo nos desarrollamos y cómo organizamos a las personas.

II. People

Si la forma de construir software cambió, entonces cambia lo que esperamos de las personas que lo construyen.

Durante décadas, dominar múltiples lenguajes de programación era señal de seniority. Tenía sentido: cuanto más sabías, más podías construir. Hoy eso cambia. ¿A quién le importa si programo en 7 lenguajes diferentes? La inteligencia artificial abstrae esas diferencias.

El centro de gravedad se movió. Ahora realizar especificaciones técnicas y funcionales a bajo nivel que permitan a diferentes agentes construir su parte es exactamente proporcional a la calidad de producto de software que vas a conseguir. El diseño de software y el grado de especificación pasan a ser el rol clave que define la calidad del output de un enjambre de agentes.

Hay algunas creencias populares de moda que interpretan que con vibe coding o código generativo las respuestas técnicas del copiloto son suficientes para construir software. Software sí, software y productos de escala, no. En este tipo de productos, la ingeniería tiene un rol central en definir cómo se construye: qué arquitectura usar, qué trade-offs tomar, cómo estructurar los datos, cómo asegurar resiliencia, pensar la latencia, estrategia de redes entre servicios que incluso cambia según servicios Cloud y un sinfín de configuraciones que son claves y definen la performance, calidad de producto, servicio y software. En resumen, la capacidad de elegir correctamente estrategias y herramientas pasa a ser determinante en el resultado final.

Ejecutar con precisión todo este proceso de diseño exige un nivel de profundidad técnica mucho más alto y alineado con lo funcional que antes.

Esto hace que sea más fácil obtener éxito en diseños más chicos que iteran a gran velocidad bajo squads de 3-4 personas, con procesos mucho más simples y acuerdos más rápidos que en equipos de tamaño y procesos tradicionales donde participan incluso más cantidad de áreas y donde los acuerdos tardan aún más.

Estructuras que cambian

Para ganar máxima velocidad en el uso de esta nueva forma de construir software, necesitamos cambiar nuestras estructuras. Este nuevo framework de trabajo logra su punto más óptimo cuando un equipo logra tener un liderazgo que antes ocupaba más del 50% de su tiempo en reuniones para liderar 8-10 personas y en negociaciones con otras áreas, recopilando información por falta de detalle en el diseño, y ahora ocupa apenas un 30% de su tiempo en orquestar su squad. El resto de su tiempo se agrega al diseño técnico funcional y a mantener la performance del contexto que consumen los agentes que generan código.

Si nos abstraemos y pasamos de un equipo de 8-12 personas a micro-squads de 3-4 personas que incluso producen varias veces más de lo que producen los squads tradicionales, entonces donde antes tenías un squad de 12 ahora tenés 3 de 4. Y si este cambio lo trasladás a toda la estructura de ingeniería, producto y UX, la estructura organizacional cambia por completo.

La matriz de competencias cambia

Este cambio genera dos efectos inmediatos. La matriz de competencias que permite evaluar a las personas cambia, y la suma de esto con todo lo anterior genera un impacto cultural que requiere convicción para sostenerlo.

Asumamos que para cada rol existente en la empresa tenés un job description: rol, área, seniority, responsabilidades. Si llevás esto a una matriz, vas a tener una grilla donde se cruzan seniority y competencias con definiciones claras. Es decir, el comportamiento esperado de un ingeniero junior no es el mismo que el de un SR, un líder o un manager. Esto se replica en todas las áreas, roles y niveles.

En la forma de trabajo anterior, esas competencias eran otras. Hoy cambian, y este cambio tiene que estar alineado con la nueva forma de construir software y con las nuevas dinámicas del equipo.

Dar claridad sobre estos cambios de expectativa permite que la transición sea más ordenada. Hace que las sesiones de performance review y el feedback sigan una línea coherente, y permite construir planes de capacitación y adaptación alineados con lo que realmente necesitan las personas para que todo el framework funcione.

Nuevas métricas

Este ajuste también habilita nuevas métricas. Empiezan a aparecer indicadores relacionados al uso de copilotos, a la cantidad de software generado por persona o por equipo, al nivel de reutilización de contexto, a la cantidad de iteraciones que un feature necesita para llegar a producción por problemas en la especificación técnica o funcional, y a la calidad del output generado por los agentes.

Todo esto forma parte de una nueva forma de operar: medir, aprender, ajustar, ejecutar y volver a medir. Un ciclo continuo que cada vez requiere menos tiempo para diseñar, validar e iterar productos.

People como función estratégica

Y en ese contexto, People deja de ser un área de soporte y pasa a ser un enabler directo de este sistema. Su rol es acompañar la transformación, ajustar las expectativas, rediseñar las competencias y asegurar que la organización evolucione al ritmo que exige esta nueva forma de construir.

III. Gobierno

Como líder de tecnología, no solo te toca diseñar todo este cambio estructural. También toca hacerlo con un gobierno acorde al desafío.

Si la forma de construir software cambia y la organización empieza a operar con inteligencia artificial en el centro, toca estandarizar la creación de agentes, ordenar la información, ofrecer plataformas de instalación de tools homologadas, controlar el gasto para medir retorno de inversión y eficiencia, y muchas cosas más.

Porque este cambio no sucede solo en ingeniería. Se expande a toda la organización.

Equipos de tecnología usan AI de forma intensiva, continua, estructural. Pero al mismo tiempo, equipos de negocio empiezan a usar copilotos, automatizaciones y herramientas que también generan valor. Y en muchos casos, sin darse cuenta, empiezan a construir software.

Ahí aparece la primera tensión. Cuando distintas áreas comienzan a construir con inteligencia artificial sin un marco común, el resultado es desorden. Diferentes herramientas, distintos niveles de seguridad, uso ineficiente de recursos y riesgo de fuga de información.

Por eso el primer paso es centralizar el control.

El gateway centralizado

Toda la inteligencia artificial de la organización tiene que pasar por un mismo punto. Un gateway que permita observar, regular y optimizar el tráfico.

Este gateway permite detectar uso indebido, identificar posibles fugas de información sensible, entender patrones de consumo, segmentar ambientes y controlar costos. Permite saber quién usa qué, cuánto consume y qué impacto genera.

También habilita algo clave: decidir qué modelos usar en cada contexto. Modelos más económicos en entornos de prueba, modelos más potentes en producción. El costo deja de ser un efecto colateral y pasa a ser una variable gestionada.

El marketplace interno

Pero el control técnico no alcanza. Si querés que esto escale, tenés que ordenar la adopción.

Ahí aparece el concepto de marketplace interno. Un espacio donde todas las herramientas de inteligencia artificial que se pueden usar en la organización están previamente homologadas por seguridad y compliance.

Para las personas, la experiencia es simple: acceder, elegir e instalar. Pero detrás hay una capa de control que asegura que cada herramienta sea segura, medible y alineada con la estrategia de la compañía. Esto no solo reduce riesgo. Acelera la adopción correcta.

La lógica financiera

Y permite algo que antes era muy difícil: entender la inversión. Cada herramienta, cada licencia, cada consumo de tokens pasa a ser trazable. Se puede entender cuánto se invierte, dónde se invierte y qué impacto tiene.

La inteligencia artificial puede hacer que el costo de construir software suba en términos absolutos. Pero al mismo tiempo multiplica la capacidad de producción. Entonces el costo por unidad de output baja. La eficiencia deja de medirse en ahorro y pasa a medirse en amplificación.

El microsquad de acompañamiento

Ahora bien, hay un problema nuevo que aparece en los bordes. Cuando los equipos de negocio empiezan a construir sus propias automatizaciones, aparecen micro-softwares fuera del control tradicional. Conexiones, scripts, pequeños sistemas que resuelven problemas reales, pero que pueden generar riesgos si no están bien diseñados.

Para eso aparece una nueva figura: el microsquad de acompañamiento. Un equipo técnico que no bloquea, sino que guía. Que ayuda a decidir cuándo una solución se puede construir con herramientas existentes y cuándo necesita un desarrollo más estructurado. Este equipo permite mantener el equilibrio entre autonomía y control, y asegura que la velocidad no rompa el sistema.

Sin gobierno, hay velocidad pero hay caos. Con gobierno, hay velocidad, control y consistencia. En definitiva, el gobierno de la inteligencia artificial no es un freno. Es lo que permite que todo esto escale de verdad.

IV. Arquitectura

Todo lo anterior necesita un lugar donde vivir.

Si cambiamos la forma de construir software, si cambiamos cómo trabajan las personas y si diseñamos un gobierno para que esto escale, entonces la arquitectura deja de ser un contenedor de servicios y pasa a ser el sistema que habilita todo esto.

La arquitectura ya no está pensada solo para correr software. Está pensada para que humanos, modelos y agentes trabajen en conjunto.

El contexto como asset de primer orden

Cada pieza de software que construís ya no solo entrega funcionalidad. También genera información: decisiones, reglas, estructuras, comportamiento. Todo eso pasa a ser contexto que otros agentes van a necesitar para poder operar correctamente.

Por eso aparecen los MCPs. Protocolos que permiten exponer ese contexto de forma estructurada para que los agentes lo puedan consumir. Sin esto, los agentes trabajan a ciegas. Con esto, el sistema empieza a tener coherencia.

El gateway de IA como plano de control

A medida que la inteligencia artificial se integra en toda la plataforma, necesitás una capa que te permita observar y gobernar ese consumo. El gateway de IA cumple ese rol.

Centraliza el tráfico, permite logging, caching, rate limiting, fallback entre modelos. Pero más importante aún, te da visibilidad. Te permite entender cómo está funcionando el sistema en cada momento.

Agentes como entidades de plataforma

Los agentes dejan de ser piezas experimentales y pasan a ser entidades de plataforma. Eso implica definir estándares: cómo acceden al contexto, cómo registran trazas, cómo se conectan entre sí, cómo se protegen frente a alucinaciones.

Cuando esto está bien definido, los agentes dejan de ser código suelto y pasan a ser componentes que podés componer, escalar y reemplazar sin reinventar el sistema cada vez.

CI/CD cognitivo

El pipeline deja de ser solo un proceso de build y deploy. Pasa a ser un sistema que también interpreta especificaciones, las fragmenta y activa agentes para construir. La ejecución deja de ser procedural y pasa a ser cognitiva. Y eso cambia cómo pensás la infraestructura entera.

Ambientes para agentes

Si los agentes construyen a una velocidad mucho más alta, los mecanismos de validación tradicionales no alcanzan. Necesitás ambientes específicos para agentes, con mayor observabilidad, trazas de decisión, replay de interacciones y tráfico sintético que represente escenarios reales.

El objetivo es simple: que la validación escale al mismo ritmo que la construcción.

Cuando juntás todo esto, la arquitectura deja de ser estática. Pasa a ser un sistema vivo que evoluciona con cada iteración. Un sistema donde el contexto crece, los agentes mejoran y la capacidad de construir se multiplica.

Software, people, gobierno y arquitectura dejan de ser capas separadas y pasan a ser partes de un mismo sistema.

Conclusión

Lo que vimos a lo largo de estos ejes requiere valentía para tomar la decisión de hacerlo, pero más valentía requiere saber qué vas a dejar de hacer para priorizarlo.

La forma de escribir software cambia. La forma de trabajar cambia. La forma de organizar equipos cambia. La forma de medir cambia. Y cuando todo eso cambia al mismo tiempo, cambia la compañía y se mueve a un nuevo paradigma. Por tanto, si algo en la cadena no cuadra, no trates de encajarlo: simplemente, sacalo.

Y como en cada ola tecnológica, aparecen distintos tipos de organizaciones.

Las que nacen en este paradigma y lo adoptan como su forma natural de operar. Las que entienden lo que está pasando y toman decisiones rápido, asumiendo el riesgo de cambiar para moverse de cuadrante. Y las que NO lo hacen, quedan en una eterna "transformación digital".

Esto ya sucedió antes. La distancia entre las empresas tradicionales que llevan décadas montadas en "transformación digital" es por la falta de valentía de tomar verdaderas decisiones. Cuando la evolución de la tecnología es más rápida que la adopción, vivís eternamente en transformación digital.

La buena noticia es que se puede hacer el cambio, pero primero hay que saber soltar, tomar coraje y disfrutar de que el cambio te hará radicalmente mejor. Porque al final, no se trata de usar inteligencia artificial. Se trata de animarse a construir producto y negocio de una manera diferente. Y las compañías que lo hagan van a ser, simplemente mejores.