La IA generativa está reduciendo el coste marginal de producir código. Un desarrollador puede pedir una implementación inicial, una migración, una prueba unitaria o un script de automatización y obtener una propuesta en muy poco tiempo. Esa reducción cambia la economía del desarrollo, pero no elimina la economía del software. El coste de escribir una línea puede bajar; el coste de poseerla, entenderla, ejecutarla, asegurarla y retirarla sigue existiendo.
Ese matiz es el centro del debate. Durante años, decir “sí” a una petición de producto, a una integración puntual o a una excepción arquitectónica implicaba asumir que el equipo tendría que dedicar una cantidad relevante de tiempo humano a escribir el cambio. En la era de la IA, esa fricción inicial se reduce. El riesgo es confundir “barato de generar” con “barato de mantener”.
El artículo de GitHub Engineering, The cost of saying yes has changed, plantea una idea especialmente útil para equipos cloud y plataformas de ingeniería: las organizaciones necesitan actualizar su marco de decisión. No todo lo que ahora puede implementarse rápido debe aceptarse sin más. La pregunta ya no es solo cuánto cuesta construir algo, sino cuánto cuesta incorporarlo al sistema vivo que tendremos que operar durante años.
El coste visible ha bajado, el coste invisible no
Cuando un equipo evalúa una nueva funcionalidad, suele ver con claridad el coste de implementación. Hay historias de usuario, estimaciones, ramas, pull requests, revisiones y despliegues. En cambio, los costes posteriores suelen quedar más dispersos: más superficie de ataque, más documentación, más alertas, más casos límite, más permisos, más dependencias y más rutas de soporte.
La IA afecta sobre todo al primer bloque. Puede acelerar la escritura de código, generar pruebas iniciales, sugerir documentación y ayudar a refactorizar. Pero no asume automáticamente la responsabilidad de que ese código encaje con la arquitectura de la plataforma, respete las restricciones regulatorias, sea observable, se pueda depurar en producción o no incremente la carga cognitiva del equipo.
En entornos cloud esta diferencia es crítica. Un cambio pequeño puede crear recursos persistentes, identidades administradas, secretos, permisos, colas, topics, funciones serverless, endpoints públicos o nuevas dependencias de red. Aunque la implementación tarde poco, su presencia en producción puede condicionar costes, cumplimiento y operación durante años.
Nota: En software, “barato” casi nunca significa únicamente “barato de escribir”. Significa barato de cambiar, operar, proteger, explicar y eliminar.
Decir sí ya no significa lo mismo
Antes de la adopción extendida de asistentes de IA, la capacidad de desarrollo era una restricción natural. Muchas ideas no se ejecutaban simplemente porque no había tiempo suficiente. Esa limitación actuaba como filtro, aunque fuera imperfecto. Si algo requería varios sprints, la organización se veía obligada a discutir su valor.
Con IA, ese filtro pierde fuerza. Un prototipo puede prepararse mucho más rápido. Una integración con una API externa puede parecer trivial. Un nuevo servicio puede nacer antes de que exista una conversación seria sobre ownership, operación y retirada. El coste de decir sí se desplaza desde el momento de creación hacia el ciclo de vida completo.
Esto no significa que haya que decir no por defecto. La IA permite explorar opciones con más rapidez y puede reducir el coste de aprendizaje. El problema aparece cuando los prototipos se convierten en producción sin pasar por una evaluación explícita de sostenibilidad técnica.
En equipos intermedios y senior, la pregunta relevante debería cambiar de “¿podemos construirlo?” a “¿queremos ser responsables de esto?”. Esa segunda pregunta incluye dimensiones que una generación automática de código no resuelve: soporte, seguridad, compatibilidad, escalabilidad, cumplimiento, experiencia operativa y coste de retirada.
Un marco práctico para evaluar cambios en la era de la IA
Un buen marco de decisión no debe bloquear la velocidad. Su objetivo es distinguir entre cambios realmente baratos y cambios que solo parecen baratos porque la IA ha comprimido la fase de escritura. Para ello, conviene evaluar cada propuesta en varias capas.
1. Coste de comprensión
El primer coste de propiedad es entender el cambio. Un fragmento de código asistido por IA puede ser correcto en apariencia, pero si introduce patrones ajenos al equipo, abstracciones innecesarias o dependencias poco conocidas, incrementa la carga cognitiva. Cada futuro incidente exigirá que alguien lea, razone y modifique esa pieza.
La IA puede proponer soluciones sofisticadas incluso cuando el problema no las requiere. Esto es especialmente delicado en plataformas cloud, donde una solución “elegante” puede implicar varios servicios gestionados, colas intermedias, funciones asíncronas y políticas de identidad. Si el equipo no puede explicar el diseño en una revisión técnica sencilla, probablemente no está preparado para operarlo.
Una regla útil es exigir que el autor del cambio, incluso si se apoyó en IA, pueda defender tres aspectos:
- Por qué esta solución es la mínima razonable.
- Qué alternativas se descartaron.
- Cómo se depurará en producción.
2. Coste de operación
El código no termina en el merge. En cloud, cada cambio debería responder cómo se despliega, cómo se observa, cómo se escala y cómo falla. Si introduce un nuevo recurso, también introduce métricas, alertas, límites, cuotas y potencialmente costes variables.
Un ejemplo típico es una funcionalidad que procesa eventos en segundo plano. Generar el código de consumo puede ser rápido, pero operarlo requiere definir idempotencia, reintentos, colas de errores o dead-letter queues, correlación de trazas y semántica de duplicados. La IA puede ayudar a escribir esas piezas, pero la organización debe decidir los estándares.
Este punto conecta con un patrón recurrente en aplicaciones modernas: separar la respuesta inmediata de los procesos largos. Cuando una operación no puede completarse dentro del ciclo síncrono de una petición, conviene diseñarla explícitamente como trabajo asíncrono, con estado observable y mecanismos de recuperación. En aplicaciones que incorporan IA, esta separación puede ser todavía más importante porque las ejecuciones pueden depender de modelos, herramientas externas o servicios con latencia y disponibilidad variables.
3. Coste de seguridad
Cada “sí” amplía o modifica la superficie de ataque. Puede añadir un endpoint, un permiso, una dependencia, una integración con terceros o una nueva ruta de datos. En sistemas cloud, los cambios pequeños suelen tener implicaciones de identidad y red que no siempre se ven en el diff principal.
La IA puede generar código que funcione, pero no necesariamente conoce el contexto de amenazas de la organización. Puede sugerir permisos excesivos, almacenar datos sensibles en logs, omitir validaciones o introducir dependencias que requieran una revisión adicional. Por eso, las revisiones de seguridad no deberían relajarse porque el código venga asistido por IA; deberían reforzarse en los puntos donde la automatización aumenta el volumen de cambios.
El modelado de amenazas es una herramienta especialmente útil para actualizar el coste de decir sí. No tiene que ser un ejercicio pesado para cada pull request, pero sí debe aparecer cuando un cambio introduce nuevas fronteras de confianza, datos sensibles, automatización con privilegios o interacción con modelos.
Advertencia: Si una funcionalidad generada o acelerada con IA necesita permisos amplios para funcionar, no es barata. Solo ha desplazado el coste hacia seguridad, auditoría y respuesta ante incidentes.
4. Coste de dependencia
Un cambio aparentemente pequeño puede introducir una dependencia nueva: una librería, un SDK, un servicio gestionado, una API externa o un modelo específico. La dependencia no es mala por definición; muchas veces es precisamente lo que permite acelerar. Pero toda dependencia tiene un coste de versión, soporte, compatibilidad, licenciamiento y reemplazo.
En proyectos basados en IA generativa, este punto es especialmente delicado. La facilidad para invocar modelos desde código puede llevar a incorporar capacidades de LLM en lugares donde una regla determinista, una búsqueda tradicional o una heurística simple habría sido suficiente. La generación de código ayuda a conectar servicios, pero no decide si la dependencia de un modelo es adecuada para ese caso de uso.
Cuando se trabaja con lenguajes como .NET, Python o TypeScript, una prueba de concepto con un modelo generativo puede ser muy rápida. El reto aparece al pasar a producción: control de latencia, límites de consumo, costes por llamada, evaluación de calidad, seguridad del prompt y versionado del comportamiento. La IA puede ayudar a construir la integración, pero el equipo sigue necesitando criterios de operación y gobierno.
5. Coste de retirada
Uno de los costes más olvidados es eliminar el cambio. Decir sí debería incluir una respuesta a la pregunta “¿cómo lo apagamos?”. Esto aplica a features, integraciones, modelos, permisos y recursos cloud. Si no existe una ruta de retirada, el cambio queda incorporado como deuda estructural.
La IA puede multiplicar el número de experimentos, y eso es positivo si la plataforma está preparada para experimentación reversible. Feature flags, despliegues progresivos, entornos efímeros, telemetría por variante y límites de coste son mecanismos que reducen el riesgo. Sin ellos, cada experimento exitoso a medias puede quedarse como residuo permanente.
La retirada también incluye datos. Si una funcionalidad empieza a recopilar nuevos eventos o atributos, hay que definir retención, clasificación, acceso y borrado. El código puede generarse rápido, pero las obligaciones sobre los datos sobreviven al pull request.
Un ejemplo: aceptar una integración “pequeña” con IA
Imaginemos un equipo que mantiene una plataforma interna en Azure. Producto solicita una funcionalidad para resumir incidencias de soporte usando un modelo generativo. Un asistente de IA puede ayudar a preparar rápidamente una Azure Function que recibe el ID de incidencia, consulta el sistema de tickets, llama a un modelo y guarda un resumen.
A primera vista, el cambio parece pequeño. Hay una función, una llamada HTTP y una escritura en base de datos. Pero la evaluación completa revela más dimensiones.
La función necesita identidad para leer tickets. Esa identidad debe tener permisos mínimos y estar auditada. El resumen puede contener datos personales o información sensible, por lo que debe definirse dónde se almacena, durante cuánto tiempo y quién puede verlo. La llamada al modelo tiene coste variable y puede fallar por límites de cuota, latencia o disponibilidad. El resultado puede ser incompleto o incorrecto, así que la interfaz debe comunicar que es una ayuda y no una fuente definitiva. Además, si el sistema de tickets cambia su API, alguien tendrá que mantener la integración.
Un cambio así puede seguir siendo una buena idea. La diferencia es que el “sí” ya no se justifica por la rapidez del prototipo, sino por una decisión consciente de propiedad.
El equipo podría documentar el cambio con una plantilla ligera:
## Evaluación de propiedad técnica
### Cambio propuesto
Generar resúmenes automáticos de incidencias de soporte mediante un modelo generativo.
### Owner
Equipo de plataforma interna.
### Recursos afectados
- Azure Function para orquestación.
- Identidad administrada con acceso de lectura al sistema de tickets.
- Almacenamiento de resúmenes en la base de datos operacional.
- Servicio de modelo generativo mediante endpoint aprobado.
### Riesgos principales
- Exposición accidental de datos sensibles en prompts o logs.
- Coste variable por volumen de incidencias.
- Resúmenes incompletos o incorrectos.
- Dependencia de disponibilidad del proveedor del modelo.
### Condiciones para producción
- Permisos mínimos validados.
- Logs sin contenido sensible.
- Métricas de latencia, errores y coste por llamada.
- Feature flag para desactivar la funcionalidad.
- Revisión de seguridad antes del despliegue general.
### Plan de retirada
Desactivar feature flag, detener invocaciones al modelo y conservar resúmenes existentes según política de retención.
Lo importante de esta plantilla no es su formato, sino el cambio de conversación. La revisión deja de centrarse solo en si el código compila y empieza a preguntar si el sistema puede absorber responsablemente la nueva capacidad.
La revisión de código también cambia
Si el código asistido por IA aumenta el volumen de cambios, la revisión humana debe evolucionar. Revisar línea por línea sigue siendo necesario, pero no suficiente. El revisor debe evaluar intención, encaje arquitectónico y coste de propiedad.
Una revisión moderna debería distinguir entre tres preguntas:
- ¿El código hace lo que dice hacer?
- ¿Lo hace de una forma coherente con los estándares del sistema?
- ¿El cambio debería existir en esta forma?
Esta última pregunta es la más difícil porque no siempre se responde desde el diff. Requiere entender producto, arquitectura, seguridad y operación. Por eso, los equipos con plataformas maduras suelen complementar el pull request con ADRs ligeros, checklists de producción o revisiones de diseño para cambios que cruzan ciertos umbrales.
Un ejemplo de checklist mínimo para cambios cloud asistidos por IA podría ser:
## Checklist para cambios asistidos por IA en cloud
- [ ] El autor entiende y puede explicar el código generado o modificado.
- [ ] No se introducen permisos más amplios de los necesarios.
- [ ] Las dependencias nuevas están justificadas.
- [ ] Existen métricas y logs suficientes para operar el cambio.
- [ ] Los logs no contienen secretos, prompts sensibles ni datos personales innecesarios.
- [ ] El cambio tiene mecanismo de apagado o retirada.
- [ ] El coste variable esperado está estimado o acotado.
- [ ] Los casos de fallo están definidos y probados.
Este tipo de checklist no pretende convertir cada cambio en un proceso burocrático. Su valor está en recordar que el coste de escribir ya no es el principal cuello de botella. La responsabilidad técnica se mueve hacia la capacidad de sostener lo que aceptamos.
Seguridad de identidad: el coste oculto más frecuente
En Azure y en arquitecturas cloud en general, una gran parte del coste de propiedad aparece en identidad. Un cambio que necesita acceder a otro servicio debe autenticarse, autorizarse y auditarse. Si se resuelve con permisos amplios “para avanzar”, la deuda se acumula rápido.
La IA puede sugerir configuraciones funcionales, pero no necesariamente alineadas con principios como mínimo privilegio, separación de responsabilidades o defensa en profundidad. Por ejemplo, puede proponer una configuración que permita más acciones de las requeridas porque es la forma más rápida de evitar errores de autorización. En desarrollo esto puede pasar desapercibido; en producción se convierte en riesgo.
Este problema no es exclusivo de la IA, pero la IA lo amplifica porque reduce la fricción para crear integraciones. Cada integración adicional aumenta la importancia de gobernar identidades, accesos y redes.
Para equipos cloud, el criterio práctico es claro: ningún cambio es barato si requiere relajar controles de identidad sin una justificación explícita y revisable.
Cómo decidir cuándo decir sí
Decir sí sigue siendo necesario. La innovación exige aceptar cambios, experimentar y aprender. La diferencia es que la IA obliga a formular mejores criterios. Un cambio puede considerarse realmente barato cuando cumple varias condiciones:
- Es fácil de entender.
- Tiene owner claro.
- Usa patrones conocidos por el equipo.
- No amplía de forma significativa la superficie de ataque.
- Puede observarse en producción.
- Tiene coste variable estimado o acotado.
- Puede retirarse sin afectar al núcleo del sistema.
Cuando esas condiciones no se cumplen, el cambio no debe descartarse automáticamente, pero sí debe tratarse como una inversión. Eso implica más diseño, más revisión y quizá una implementación gradual. La IA puede seguir ayudando, pero dentro de un marco que haga visible el coste completo.
Un buen “sí” en la era de la IA suena menos como “el código ya está generado” y más como “entendemos qué estamos incorporando al sistema, quién lo operará, cómo fallará, cuánto puede costar y cómo lo retiraremos si deja de tener sentido”.
El nuevo trabajo de los equipos técnicos
La reducción del coste de creación no elimina el trabajo de ingeniería; lo desplaza. Menos tiempo escribiendo boilerplate debería traducirse en más tiempo pensando en límites, contratos, observabilidad, seguridad, datos y operación. La ventaja competitiva no estará solo en generar más código, sino en decidir mejor qué código merece existir.
Esto requiere una cultura técnica distinta. Los equipos deben sentirse autorizados a cuestionar cambios aunque sean fáciles de implementar. Los líderes deben evitar medir productividad únicamente por volumen de entrega. Y las plataformas internas deben ofrecer caminos seguros para que decir sí no implique reinventar controles en cada equipo.
La IA cambia el coste de decir sí porque hace que muchas ideas parezcan inmediatamente ejecutables. Pero la madurez técnica consiste en recordar que el software no se mide por lo rápido que aparece en el repositorio, sino por lo bien que sobrevive en producción.