Imagina un equipo de finanzas esperando un espacio para gestionar reclamaciones de facturas: una cola, documentos justificativos, reglas de asignación y conexión con el sistema contable. En este escenario ilustrativo, la funcionalidad antes consumía semanas de capacidad de desarrollo. Ahora una persona de ingeniería coordina agentes que generan la estructura de implementación, pruebas y configuración de despliegue en horas, utilizando componentes y contratos establecidos.

No es una publicación en producción sin supervisión. Esa misma tarde, ingeniería y los responsables del dominio ya han revisado el comportamiento, validado los supuestos de integración y aprobado y publicado un piloto acotado en producción. Pero el cambio económico es claro: crear una versión creíble de una funcionalidad conocida exige mucho menos esfuerzo de implementación. Un competidor con herramientas similares puede hacer lo mismo.

La pregunta difícil ya no es si alguien puede crear la cola y sus botones. Es si ese espacio ayuda a resolver las reclamaciones que bloquean dinero, decisiones y relaciones con clientes. Cuando construir deja de ser la ventaja competitiva, ¿qué la sustituye?

Imagina a un ingeniero revisando un pull request generado por un agente. Modifica el cliente de pagos, la configuración de reintentos, las pruebas y la documentación del despliegue. El ingeniero aprendió a trabajar de otra forma: seguir la solicitud fallida en los registros, reproducir el problema, editar cada archivo y ganar confianza paso a paso, de manera deliberada. Ahora la solución propuesta ya está en la pantalla.

La primera reacción no es necesariamente entusiasmo ni desconfianza. Puede ser simplemente: "Así no es como yo solía hacer esta tarea". En esta escena ilustrativa, la incomodidad no tiene que ver con si el ingeniero sabe leer el código. Tiene que ver con no haber vivido la experiencia de construirlo. Se ha acortado una ruta conocida hacia la comprensión, pero comprender sigue siendo necesario.

Esa tensión va mucho más allá del software. Cuando una herramienta produce el trabajo que antes demostraba nuestra experiencia, tenemos que separar el método de la responsabilidad. El cambio útil no es "hazlo todo tú mismo" ni "deja que el agente se encargue de todo". Es un principio más exigente y duradero: aprovecha la capacidad que te ofrece, hazte cargo de la verificación.

Para la campaña interna Give Campaign de Microsoft este octubre, creé un proyecto de código abierto que ayuda a los voluntarios a preparar tarjetas digitales de ánimo para familias vinculadas con Ronald McDonald House. La idea es sencilla: ofrecer una forma considerada de compartir unas palabras de apoyo durante una campaña activa, sin que crear una tarjeta sea complicado.

El proyecto se llama Words of Encouragement eCard. Convierte la actividad de escribir tarjetas en una experiencia web accesible y multilingüe.

Los agentes no eliminan la fricción de la entrega​

Los agentes de IA pueden leer un repositorio, escribir código, ejecutar pruebas y abrir una solicitud de extracción. Es una capacidad impresionante, pero no hace que el sistema de ingeniería que los rodea sea más fácil de navegar. Hace que cada inconsistencia de ese sistema sea más fácil de reproducir a gran velocidad.

Un agente con acceso a un entorno grande y sin documentación enfrenta las mismas preguntas que un ingeniero nuevo: ¿qué plantilla está aprobada? ¿Cómo se implementa un servicio? ¿De dónde vienen los secretos? ¿Qué comprobaciones son obligatorias? ¿Quién es responsable de esta dependencia? ¿Qué es seguro cambiar? Un modelo capaz puede inferir algunas respuestas, pero la inferencia no es un modelo operativo confiable para software de producción.

El viernes 17 de julio de 2026 impartí un webinar en el canal de YouTube de Microsoft Reactor llamado Agentic DevOps Meets Accessibility: Inclusive Delivery with AI & Agents. La grabación ya está disponible para que la veas cuando quieras. La sesión está en inglés.

El verdadero cambio no es aprender menos, es aprender de forma diferente​

Cada vez que una nueva tecnología facilita el acceso a la información, resurge la misma preocupación: ¿dejarán las personas de aprender por completo? Se suponía que las calculadoras harían innecesaria la aritmética. Se suponía que los buscadores harían innecesario recordar datos. La IA plantea ahora la misma pregunta, a una escala mucho mayor, porque puede explicar un concepto, redactar un ensayo y llevar a cabo tareas de varios pasos por su cuenta.

La preocupación interpreta mal lo que realmente está cambiando. La IA está transformando la rapidez con la que las personas pueden acceder a la información y producir un primer borrador de una respuesta. No está transformando el proceso subyacente mediante el cual un ser humano construye una comprensión real, desarrolla juicio o se vuelve capaz de resolver problemas que nunca antes había visto. Ese proceso sigue siendo lento, exige esfuerzo y sigue siendo profundamente humano.

Por qué entender sigue importando cuando la IA puede escribir el código​

Nunca ha sido tan fácil convertir una idea en software funcional. Describe lo que quieres en lenguaje simple, y una herramienta de IA puede generar una página web, un script, una integración con una API o incluso un agente de varios pasos que realiza acciones en tu nombre. Para cualquiera que se haya sentido excluido del software por no saber programar, ese cambio es real y bienvenido.

Pero hay una diferencia entre software que funciona y software que entiendes. La IA puede producir lo primero en segundos. Solo tú puedes producir lo segundo, y solo si sabes lo suficiente sobre cómo funciona realmente el software para leer lo que la IA te entregó, cuestionarlo y corregirlo cuando esté equivocado.

Por qué el próximo capítulo de FinOps no consiste en encontrar un modelo más barato. Se trata de diseñar sistemas que no desperdicien los tokens que ya tienen.

Un líder financiero abre la factura mensual de la plataforma de IA de la empresa y encuentra un número que no coincide con ninguna historia que alguien pueda contar. El uso creció de forma moderada. La factura creció de forma marcada. Nadie cambió a un modelo más caro. Nadie aprobó una nueva integración que alguien recuerde. La partida simplemente creció por sí sola, de la misma manera en que solían crecer las facturas de la nube antes de que alguien construyera una disciplina para vigilarlas.

Pregúntale al equipo de ingeniería qué pasó y la respuesta rara vez tiene una sola causa. Son cien pequeñas decisiones: un prompt de sistema que creció cada vez que alguien añadió una nueva regla, un paso de recuperación que trae diez documentos cuando dos bastarían, un agente que reintenta una llamada a una herramienta fallida cinco veces antes de rendirse, un flujo de trabajo que pasa una conversación entre tres agentes especializados y reenvía todo el historial en cada traspaso. Ninguna de estas decisiones parecía costosa por separado. Juntas, son la factura.

El cuello de botella se movió y la mayoría de los equipos no lo ha notado​

Durante décadas, escribir código fue la parte cara. Leerlo era casi gratis en comparación. Un desarrollador pasaba horas produciendo un cambio y un revisor pasaba minutos confirmándolo. Esa proporción dio forma a todo: nuestras herramientas, nuestros procesos y nuestra idea de quién estaba ocupado y quién esperaba.

Los agentes invirtieron esa proporción. Un agente capaz ahora produce una rama completa con código, pruebas y documentación en el tiempo que toma escribir una buena descripción de la tarea. Escribir se volvió barato. Leer no.

Ocho bloques de construcción que convierten un modelo capaz en un sistema que entrega trabajo real: agentes, subagentes, habilidades, contexto, memoria, prompts, notebooks y proyectos.

La mayoría cree que está usando IA generativa cuando abre una ventana de chat y escribe una pregunta. Está usando la parte menos interesante de todo esto. El chat es la puerta de entrada, no la casa.