Últimamente escucho mucho la misma idea: "el software se volvió un commodity desde que llegó la IA."
No estoy de acuerdo. Lo que se volvió commodity es escribir código. Y eso no es lo mismo que construir software o un producto digital.
La distinción importa más de lo que la mayoría cree — y confundir las dos cosas ya está generando consecuencias reales y caras para empresas que deberían saberlo.
Escribir código vs. construir software
Pensá en la construcción. Tenemos mejores herramientas y métodos que nunca. Un albañil hoy trabaja más rápido y con menos esfuerzo físico que hace cincuenta años. ¿Eso significa que la construcción se volvió commodity?
Obvio que no. El costo de hacer bien una obra nunca estuvo en poner ladrillos. Estuvo en el diseño, la ingeniería, la planificación y los errores caros que aparecen cuando algo de eso falla.
En software pasa exactamente lo mismo. El costo nunca estuvo en tipear código. Estuvo en:
- Decidir qué construir y — igual de importante — qué no construir
- Diseñar una arquitectura que no se convierta en un problema en 18 meses
- Entender el dominio del negocio lo suficientemente bien como para modelarlo correctamente
- Integrar con sistemas que ya existen, cada uno con sus propias particularidades y restricciones
- Hacer que algo sobreviva en producción mientras un equipo lo sigue iterando
La IA no resuelve nada de eso. De hecho, hace que algunas de esas cosas sean más riesgosas.
¿Qué dicen los datos?
Esto no es solo una opinión. El último reporte de DORA encontró que la adopción de IA aumenta la efectividad individual de los desarrolladores — pero también aumenta la inestabilidad en los deploys. Los devs producen más, pero los sistemas se rompen más. Estamos viendo más outages globalmente, no menos.
¿Por qué? Porque la IA permite hacer cambios más grandes de una sola vez. Y sabemos hace años — por investigaciones sobre continuous delivery y lean software development — que los batch sizes grandes en cambios de código generan exactamente esto: más failures, más rollbacks, más incidentes.
Es uno de los patrones más documentados en software delivery. Los cambios pequeños e incrementales son más seguros. La IA incentiva el comportamiento opuesto al hacer trivialmente fácil generar cientos de líneas de código de una sola vez.
El problema de la excavadora
Hay una analogía que captura esta dinámica perfectamente.
Dale una excavadora a alguien sin experiencia en obra. Va a mover tierra mucho más rápido que cualquiera con una pala. También va a romper cañerías, cortar cables y comprometer cimientos sin darse cuenta.
La herramienta amplifica la capacidad, pero también amplifica el error.
Un operador experimentado usa la excavadora para hacer trabajo preciso y controlado — porque entiende lo que hay bajo tierra antes de empezar a cavar. Sabe lo que no puede ver. Un operador sin experiencia solo ve la velocidad.
Lo mismo pasa con el desarrollo asistido por IA. Un ingeniero experimentado usa IA para acelerar tareas bien entendidas — escribir boilerplate, generar scaffolds de tests, explorar APIs. Sabe dónde están los riesgos y mantiene a la IA lejos de esas zonas. Un desarrollador menos experimentado usa IA para todo, incluyendo las partes que requieren juicio, contexto y conocimiento de dominio que el modelo simplemente no tiene.
El costo real que están pagando las empresas
Lo que estoy viendo en conversaciones con founders y equipos de ingeniería es que esta confusión ya está generando consecuencias reales.
Empresas que creen que están ahorrando en desarrollo en realidad están acumulando deuda técnica a velocidad récord. Sí, están entregando más rápido — pero están entregando sistemas frágiles que cuestan más mantener, más extender y más arreglar cuando inevitablemente se rompen.
Algunos patrones que me encuentro constantemente:
- Decisiones de arquitectura tomadas por prompts: Elecciones estructurales críticas delegadas a una IA que optimiza para "código que funciona" en vez de sistemas mantenibles
- Sin testing de integración: Código generado por IA que funciona aislado pero falla cuando se conecta con infraestructura real
- Complejidad invisible: Codebases que se ven limpios en la superficie pero tienen acoplamiento profundo, lógica duplicada y ningún principio de diseño coherente
- Falsa confianza en la velocidad: Equipos que miden productividad por líneas de código o PRs mergeados, no por resultados entregados
La ironía es dolorosa: las empresas que más intentan recortar costos de ingeniería con IA son muchas veces las que están creando los problemas más caros para su futuro.
Por qué la buena ingeniería vale más que nunca
Acá está la verdad contraintuitiva: la mala ingeniería se volvió más barata de producir. Y eso hace que la buena ingeniería valga más que nunca.
Cuando cualquiera puede generar código con un prompt, el diferenciador ya no es el código en sí. Es todo lo que lo rodea:
- Pensamiento de producto: Entender qué necesita realmente el usuario vs. lo que dice que quiere
- Arquitectura: Diseñar sistemas que acomoden cambios sin colapsar
- Madurez operativa: Construir para observabilidad, confiabilidad y degradación controlada
- Expertise en integración: Hacer que las cosas funcionen juntas en el mundo real, no solo en un demo
- Juicio de ingeniería: Saber cuándo usar IA y cuándo pensar por vos mismo
Estas habilidades no se commoditizan con IA. Se amplifican — pero solo en manos de personas que ya las tienen.
¿Qué deberían hacer los founders y CTOs?
Si estás construyendo un producto, así es como tenés que pensar sobre IA e ingeniería:
Usá IA para acelerar, no para definir arquitectura. La IA es excelente generando implementaciones para problemas bien definidos. Es terrible tomando decisiones técnicas estratégicas.
Medí resultados, no output. Líneas de código, PRs mergeados y features entregados no significan nada si el sistema es frágil y caro de mantener. Seguí estabilidad de deploys, frecuencia de incidentes y tiempo de recuperación.
Invertí en juicio de ingeniería. La habilidad más valiosa en un mundo aumentado por IA es saber qué construir, cómo estructurarlo y dónde están los riesgos. Eso viene de la experiencia, no de los prompts.
Cuidá los batch sizes. Si la IA le está ayudando a tu equipo a hacer cambios más grandes en un solo deploy, estás intercambiando velocidad a corto plazo por inestabilidad a largo plazo. Mantené los cambios chicos e incrementales, sin importar qué tan rápido la IA pueda generar código.
No confundas código barato con software barato. El código es la parte fácil. Lo caro es todo lo demás — y esa parte se volvió más importante, no menos.
El punto central
El software no es un commodity. Escribir código sí. Y la brecha entre esas dos cosas es donde las empresas construyen algo duradero o se cavan un pozo del que no pueden salir.
La IA es la herramienta más poderosa que tuvimos para desarrollo de software. Como cualquier herramienta poderosa, amplifica todo a lo que la apuntás — incluyendo tus errores. Las empresas que van a ganar son las que entienden esta distinción e invierten en consecuencia.
La pregunta no es si estás usando IA. Es si tenés el juicio de ingeniería para usarla bien.
