Marc-André MoreauNota: este artículo largo se escribió originalmente para el desafío de ensayos de The Pragmatic Engineer sobre cómo está cambiando la ingeniería de software.
Octubre de 2025. Claude Sonnet 4.5 acaba de salir, y todo el mundo en Devolutions está pasando por una formación en IA de Mindstone. El mensaje del CEO es claro: estamos dando todos los pasos necesarios para hacer de la empresa una organización nativa de la IA. A los empleados que no quieren formar parte de esta nueva «Devolutions 2.0» se les ofrece un paquete de salida voluntaria. Quienes se quedan tienen que comprometerse y apostar por completo por la IA con el resto de nosotros. Esta es la historia del cambio profundo que ocurrió en Devolutions, y de cómo una migración importante, estimada al principio en tres años, se completó en solo uno.
Devolutions es una empresa de software canadiense que ha crecido con sus propios medios, con la oficina principal en Lavaltrie, Quebec, y más de 250 empleados en todo el mundo. El nombre «Devolutions» viene de «Development Evolutions», de cuando el fundador, David Hervieux, hacía contratos de desarrollo de software, mucho antes del éxito comercial actual de nuestro producto estrella, Remote Desktop Manager (RDM). RDM es un gestor de conexiones: se encarga de lanzar conexiones con inyección de credenciales para protocolos como RDP, SSH, VNC, ARD, PowerShell, etc. Si algo acepta credenciales y se conecta, es muy probable que RDM ya lo admita.
Mi equipo es un poco especial: incluye a los desarrolladores de la oficina de Ottawa, pero también a desarrolladores en Estados Unidos, Alemania y Japón. Internamente lo llamamos el equipo de «arquitectura», porque somos responsables de construir muchos componentes reutilizables que usan otros equipos. La estructura es muy flexible, pero todo el mundo es muy autónomo, está motivado y es responsable. La mayoría de los equipos de Devolutions trabajan de forma presencial, no en remoto, en la oficina principal de Lavaltrie.
En cuanto a mí, soy el CTO de Devolutions. En una vida anterior fundé el proyecto FreeRDP. Soy Microsoft MVP en las categorías de Windows y PowerShell. Mi principal área de especialización son los protocolos de Windows, sobre todo para RDP y la autenticación. Tengo facilidad para la ingeniería inversa y para meterme en las entrañas de los sistemas. Me gusta experimentar con la tecnología para encontrar formas de encajar las piezas del rompecabezas y construir los productos que queremos.
Las aplicaciones de escritorio de Windows suelen quedarse atrás en el mundo de la IA: las herramientas más populares salieron primero sin compatibilidad con Windows y, cuando por fin llegó, fue parcial. Las aplicaciones de escritorio, a diferencia de las aplicaciones web, están en clara desventaja porque es mucho más difícil validarlas de forma automática con IA. A pesar de estos retos, conseguimos portar Remote Desktop Manager, una aplicación empresarial .NET enorme con miles de cuadros de diálogo de interfaz, a Avalonia, un framework de interfaz multiplataforma, en menos de un año. Aún más sorprendente es que la migración de Windows llegó al 100 % primero, por delante de otras plataformas con menos deuda técnica.
Comprimir tres años en uno
El gran proyecto de migración a Avalonia
Somos una empresa que prioriza el escritorio, y estamos comprometidos con hacer grandes aplicaciones de escritorio. Por eso patrocinamos Avalonia con 3 millones de dólares a lo largo de 3 años. La razón es sencilla: no queremos sacrificar la experiencia de la aplicación de escritorio usando una aplicación web disfrazada, como Electron, pero aun así tenemos que reducir la carga del desarrollo migrando a un framework de interfaz multiplataforma en .NET. Hemos acumulado mucho legado y muchas funciones avanzadas a lo largo de los años, así que no podemos permitirnos reescribirlo todo en un framework de interfaz nuevo entre dos versiones principales. Antes de la IA, estimamos el esfuerzo en al menos 3 años. Avalonia nos dio los medios para hacer una migración parcial, de modo que pudiéramos mezclar elementos de interfaz nativos con Avalonia.
Esta es la migración más ambiciosa que se ha intentado en Devolutions: más de 1.500 elementos de interfaz WinForms que se remontan a más de una década de trabajo, solo para RDM Windows. Las otras plataformas tienen muchos menos elementos de interfaz nativos. En octubre de 2025 estaba viendo cómo podíamos usar la IA para acelerar esto, porque en ese momento la migración seguía siendo sobre todo manual. Lo primero que hice fue crear un script que recorría los archivos fuente de nuestro monorepo para registrar el número de elementos de interfaz específicos de cada plataforma que había que migrar, desde el primer commit en el que se introdujo Avalonia. Ese número se convirtió en nuestra referencia, y cada plataforma tenía que bajarlo a cero eliminándolos a medida que se sustituían por Avalonia.
El recuento total de todas las plataformas juntas superaba los 5.800 elementos de interfaz por portar, y en ese punto el progreso era apenas de unos pocos puntos porcentuales en cada plataforma.
La fase del cañón de slop de IA
Los primeros intentos de acelerar la migración a Avalonia produjeron mucho slop de IA, del que yo era personalmente responsable en su mayor parte. Por suerte, la frustración fue solo temporal y, mirando atrás, fue un paso necesario para aprender. El verdadero valor de la fase del cañón de slop de IA fue dar un toque de atención a los desarrolladores que sabían lo que hacían, para que empezaran a añadir y mejorar las instrucciones para la IA y así cometiera menos errores.
Estos eran los retos:
- Yo no hacía mucha interfaz, así que no sabía lo que estaba haciendo
- Los modelos de IA de hace un año cometían muchos errores
- La IA no tenía las herramientas adecuadas para ver el antes y el después
RDM admite muchas entradas de conexión, sobre todo VPN que los usuarios pueden usar como dependencia de otra entrada de conexión. Por ejemplo, se puede tener una conexión RDP que lance automáticamente una VPN WireGuard si hace falta para conectarse al servidor RDP asociado. Decidí intentar portar primero la entrada de conexión VPN, con la esperanza de extraer suficientes instrucciones para que la IA se volviera buena portando todas las demás entradas VPN. Hicieron falta varios intentos, y tuve que pedir a compañeros que me ayudaran a arreglar cosas en una rama experimental. Después actualicé las instrucciones señalando al LLM los commits para que aprendiera de ellos. Tras un par de iteraciones así, las instrucciones eran lo bastante buenas como para portar automáticamente algunos otros tipos de entradas VPN, pero seguían exigiendo muchas correcciones.
El proceso se volvió semimanual: lanzaba una sesión en la que indicaba al agente que analizara y enumerara los siguientes tipos de entradas VPN más sencillos que podía portar. Los hacía en lotes de 10, luego lanzaba RDM a mano para hacer capturas antes y después, y las volvía a pegar en el agente de IA. Las capturas por sí solas ayudaban mucho a acertar el aspecto visual, pero muchos problemas solo aparecían al hacer clic y probar las cosas. Muchos elementos exigían detectar un software VPN concreto, instalado y utilizable, así que no era fácil probarlo todo. Migré unas cien entradas de conexión de esta forma. Según lo que yo sabía, funcionaba, pero muchos problemas pequeños se colaron y otros tuvieron que dedicar tiempo a corregirlos.
En ese punto hice una pausa, porque mi objetivo era poner en marcha el proceso de migración con IA: un único archivo Markdown de 5.000 líneas de instrucciones de WinForms a Avalonia, pulidas en esos primeros intentos, ya lo usaban con éxito algunos desarrolladores. La migración no iba a un ritmo vertiginoso, pero iba más rápido que antes. En el fondo sabía que estábamos a solo unos meses de que la persona adecuada acelerara el ritmo, después de haber entendido del todo cómo optimizar el proceso para pasar la mayor parte del tiempo revisando y haciendo correcciones rápidas, con la gran mayoría de la ejecución hecha por la IA. Imagine a alguien que prueba al estilo del control de calidad, que recorre cientos de cuadros de diálogo para validar cosas y que además tiene la confianza para corregir el código en lugar de limitarse a abrir un ticket. Por suerte, eso acabó ocurriendo.
La aceleración de la migración a Avalonia
A principios de abril de 2026, RDM Windows alcanzó el 25 % de la migración a Avalonia. A finales del mismo mes se alcanzó el hito del 50 %.
Durante el verano se avanzó de forma notable, hasta alcanzar el hito del 100 % en RDM Windows a principios de septiembre:
Esto se aleja mucho del ritmo de los primeros días de la migración. ¿Qué cambió?
- Se añadieron muchos componentes Avalonia compartidos y reutilizables para facilitar la migración
- Las personas que sabían lo que hacían se tomaron el tiempo de mejorar las instrucciones para la IA
- Un puñado de personas recorrió cientos de componentes de interfaz a la vez
Las migraciones originales con IA, las que introdujeron slop, también ayudaron a sacar a la luz una lista de problemas que necesitaban un trabajo de base limpio. Por ejemplo, aún no había un componente de selector de archivos multiplataforma, así que se hizo uno adecuado y se actualizaron las instrucciones para la IA para que lo usara. De lo contrario, la IA a menudo envolvía selectores de archivos específicos de una plataforma detrás de compilación condicional, y repetía eso varias veces sin reutilizar nada. Al principio tuvimos que dedicar tiempo a construir esos bloques necesarios, de mayor complejidad, antes de intentar ir más rápido.
Ese trabajo lo retomaron otras personas, que iban a «recoger las ganancias» migrando los componentes recién desbloqueados, de menor complejidad, y validándolos en lotes grandes. Esto es importante: aunque en teoría tenga cien componentes de interfaz que se pueden migrar, el trabajo solo está hecho cuando se eliminan los archivos fuente originales. Si no, nunca puede estar seguro del estado real del progreso.
Si observa las otras plataformas con atención, quizá note un gran aumento del porcentaje entre los hitos del 50 % y del 100 % de RDM Windows, en concreto en RDM Linux, que pasó del 12,7 % al 94,3 %. Muchos de los componentes migrados desde WinForms en RDM Windows podían reutilizarse tal cual en RDM Linux. Eso solo no bastaba, si no habríamos visto a RDM Linux llegar al 50 % (o más) antes. El cambio ocurrió cuando los desarrolladores de RDM Linux empezaron a recoger las ganancias de forma agresiva, sustituyendo cientos de los componentes Linux originales por los nuevos componentes Avalonia y validándolos en lotes grandes.
Cómo cambió el desarrollo de software
Hacer cambios con los que no se siente cómodo
Con mis primeros intentos de migrar WinForms a Avalonia con IA, no entendía de verdad lo que estaba haciendo. No soy desarrollador de interfaces, nunca lo fui y probablemente nunca lo seré (sin IA). Puede parecer contrario a la intuición, pero hay mucho valor en hacer cambios con los que no se siente cómodo. En el caso de la migración a Avalonia, la intención era pulir suficientes instrucciones para la IA como para automatizar la mayor parte del trabajo pesado, y dejar al desarrollador la revisión manual y las correcciones posteriores a la migración.
En 2025, Devolutions adquirió PowerShell Universal, y el creador del producto, Adam Driscoll, se unió a mi equipo. Poco después contratamos a otro desarrollador para trabajar en el producto, lo que en la práctica duplicó el tamaño del equipo original de una sola persona. PowerShell Universal (PSU) es una aplicación ASP.NET escrita en C# que permite a un administrador de TI convertir scripts en aplicaciones web plenamente funcionales, expuestas a los usuarios finales. También puede ejecutar scripts en una máquina remota mediante un agente.
Devolutions ya tenía un agente con funciones más avanzadas, incluidas capacidades de ejecución remota, así que no tardamos en planear sustituir el agente original de PSU, escrito en C#, por el Devolutions Agent existente, escrito en Rust. El reto era que los desarrolladores de PSU no sabían Rust, y los desarrolladores del Devolutions Agent no sabían PSU. En teoría era una integración sencilla. En la práctica, yo no veía progreso real, solo maquetas y demos, no pull requests que nos acercaran a algo que pudiéramos publicar.
Pedí a los desarrolladores de C# que hicieran algo con lo que no se sentían cómodos: limítense a hacer vibe coding de lo que necesiten en el código Rust, lo mejor que sepan, sabiendo cómo quieren que se consuma en PowerShell Universal. La intención importa: sabíamos que los cambios corresponderían a lo que ellos querían, aunque probablemente cambiaríamos la forma a través de varios ajustes. El punto de partida era una compilación funcional del Devolutions Agent que sabíamos, con certeza, que correspondía a lo deseado para PowerShell Universal. ¡Ni una maqueta ni una especificación de diseño!
Ayudé a revisar cómo se hacían las cosas, y hubo mucho ir y venir entre los desarrolladores de C# y de Rust, hasta que fijamos la forma en que el Devolutions Agent se conectaría a PowerShell Universal y se configuraría como host de ejecución remota para scripts de PowerShell. Este es uno de mis momentos de mayor orgullo: acelerar el desarrollo haciendo que desarrolladores cambiaran código que no entendían, porque entendían la intención mejor que quienes lo revisarían después.
¿Por qué funciona? Porque, como en muchas integraciones, los desarrolladores a menudo solo conocen bien su parte, pero no tienen un conocimiento profundo de aquello con lo que se integran. Este enfoque facilita que ambos lados iteren sobre el código real hasta llegar a un consenso. No importa lo buena que sea su maqueta: el código real siempre será mejor.
Cerrar el bucle de retroalimentación agéntica
La IA cambia muchas cosas, pero algunas reglas básicas permanecen. La IA solo es tan buena como las herramientas con las que puede trabajar. Si su IA no tiene ojos, no verá diseños visuales rotos: solo supondrá que hizo lo correcto. Si su IA no puede usar un depurador, instrumentará el código con registros para averiguar qué caminos se toman. En muchos casos, la falta de eficiencia no importa mientras al final lo resuelva por sí misma, o mientras haya un humano en el bucle para validar.
Si hay una lección que recordar de este año, es que conviene invertir en cerrar el bucle de retroalimentación agéntica de la IA para obtener los mayores beneficios. El bucle no estaba del todo cerrado para la migración a Avalonia de RDM, pero se compensó con desarrolladores que validaban e iteraban rápido sobre los cambios.
A principios de este año, adquirimos el proyecto de código abierto UniGetUI. UniGetUI es una interfaz de usuario sobre varios gestores de paquetes, como WinGet, Chocolatey, PowerShell, npm, pip, etc. El proyecto era originalmente solo para Windows, escrito en C# con WinUI. Ahora es plenamente multiplataforma con Avalonia, y se puede usar con Homebrew en macOS, o con los gestores de paquetes propios de cada distribución en Linux. Esta migración exigió varios intentos antes del primer éxito, y se hizo de forma muy distinta a la de RDM.
Yo negocié personalmente la adquisición de UniGetUI, que transfirió el mantenimiento y la propiedad del proyecto a Devolutions, sin la participación del autor original. Hice todo el trabajo inicial de la transición hasta que asignamos un desarrollador a tiempo completo al proyecto. Hice dos intentos de migrar UniGetUI a Avalonia de forma automática, y ambos fallaron, porque los LLM no conseguían averiguar cómo llamar correctamente a las API de Avalonia, y también porque yo no tenía las herramientas adecuadas para cerrar el bucle de retroalimentación con el agente de IA dándole ojos sobre el resultado.
En el tercer intento configuré el Avalonia Build MCP, que permitía al LLM obtener la documentación de las API con eficacia, e instrumenté la aplicación para que se pudiera usar con el Avalonia DevTools MCP. Ya tenía un uso correcto de las API de Avalonia, pero, lo más importante, el LLM podía lanzar la aplicación Avalonia para interactuar con ella e inspeccionar el resultado visual de una forma que se parece mucho al servidor MCP de Playwright para aplicaciones web. Lo dejé funcionar solo durante más de 24 horas, diciéndole básicamente a GitHub Copilot que siguiera. Al final tenía una primera versión funcional y utilizable de UniGetUI en Avalonia, bastante parecida a la original en WinUI.
Eso es lo que entregué al nuevo desarrollador que habíamos asignado a tiempo completo a UniGetUI. Con un par de semanas más de ajustes y correcciones de alguien que sabía trabajar con Avalonia mejor que yo, por fin conseguimos algo decente. Como cambiar el framework de interfaz es algo a lo que los usuarios son especialmente sensibles, tardamos unos dos meses en llegar al punto en el que podíamos borrar la versión WinUI original y quedarnos solo con la nueva interfaz Avalonia.
Pagar la deuda técnica
Devolutions Server es una aplicación ASP.NET que usa SQL Server sin un ORM. Ha sido así desde el principio y, como tiene mucho legado, no podemos «simplemente» añadir compatibilidad con otra base de datos como PostgreSQL. Para empeorar las cosas, la única persona de la empresa que conoce esta parte delicada de la aplicación está a punto de jubilarse (es nuestro antiguo CTO). Cuando se publicó Fable 5 el 9 de junio, vi la oportunidad perfecta de probar la migración a PostgreSQL, porque pronto ese conocimiento especializado de esa deuda técnica dejaría de estar disponible.
Creé con cuidado un plan en GitHub Copilot con Fable 5 y luego lancé el agente. Conseguí que funcionara a un nivel funcional mínimo en las primeras 24 horas. Después hice un análisis de brechas exhaustivo para encontrar los huecos que había que corregir, generé un plan nuevo con más cobertura de pruebas y más pruebas de extremo a extremo. Hice que GitHub Copilot usara su lienzo de navegador para cargar la aplicación web, iniciar sesión con un usuario de prueba, hacer clic por todas partes y validar que de verdad funcionaba. Incluso le hice pasar pruebas que implicaban esperar a que se ejecutaran tareas programadas. La noche del 12 de junio, cuando una directiva estadounidense de control de exportaciones obligó a Anthropic a retirar Fable 5 para todo el mundo, solo tres días después de su publicación, yo había completado el grueso del trabajo.
Aunque no tenía un conocimiento profundo de las bases de datos ni de esta parte de la aplicación, para entonces había pulido mi habilidad para hacer migraciones grandes y complejas con IA. Usé un análisis de brechas detallado y exhaustivo para averiguar qué había que hacer, qué había que corregir y qué no se comportaba como el original. Generé planes para añadir pruebas unitarias, pero también pruebas de integración, y lo combiné con pruebas de extremo a extremo en las que el agente de IA interactuaba con la aplicación. Lo que produje era útil y estaba demostrado que funcionaba hasta cierto punto, pero aún no se había revisado en profundidad.
Aquí es donde se pone interesante: nunca me había divertido tanto con nuestro antiguo CTO como durante el último año. Quedó muy impresionado con el progreso y se puso a corregir con Claude Code las cosas que encontraba. Le entregué mi rama después de llevarla al nivel que yo podía alcanzar, y él siguió desde ahí, con una perspectiva que yo no tenía. Hicieron falta unas semanas para encontrar de verdad todos los problemas sutiles que quedaban, pero formamos un equipo muy bueno y lo terminamos.
Mi recomendación, cuando se trata de pagar la deuda técnica en zonas de alto riesgo del código, es no escatimar en los tokens. Use los modelos más grandes y lance muchas revisiones enfocadas para sacar a la luz los distintos tipos de problemas que le preocupa que puedan ocurrir. Es muy fácil hacer que las cosas funcionen, pero hace falta mucho más tiempo y esfuerzo para hacerlas bien.
Cómo han cambiado las revisiones de código
¿Revisan humanos cada línea de código? No, porque no escala. Nadie puede revisar un flujo constante de pull requests enormes y seguir lo bastante concentrado como para detectar todos los problemas. La buena noticia es que un agente de IA nunca se cansa de detectar problemas. Las revisiones de código en Devolutions a menudo consistían en explicar los cambios a un compañero, y él hacía preguntas a cambio. Con la IA, puede hacer una primera revisión local de sus cambios y luego hacer que otro agente de IA haga una segunda revisión cuando abre la pull request.
Hay una anécdota graciosa sobre la revisión de código de GitHub Copilot: una vez alguien se «quejó» de que seguía encontrando problemas en sus pull requests y, como eran problemas legítimos, no podía discutirlos. Si todos esos problemas existen en el código, ¿por qué no puede informar de 50 de una vez, en lugar de 10 cada vez? La verdadera molestia era el bucle hasta que la revisión de código de la IA dejaba de encontrar problemas reales que corregir.
Para los cambios con un radio de impacto potencialmente grande, normalmente alguien presta más atención a los cambios. En lugar de ir línea por línea en la interfaz web de GitHub, nos resultó mucho más eficaz simplemente traer la rama en local para hacerle a la IA las preguntas que normalmente le habría hecho al autor de la pull request. Puede volcar todas sus preocupaciones y esperar a que la IA valide si los cambios coinciden con lo que espera. También es más fácil pedirle a la IA que explique cómo se hicieron los cambios, qué partes de la aplicación afectan y cómo. Después puede pedirle a la IA que envíe los hallazgos como comentarios en línea en la pull request.
Para evitar «aprobar de forma mecánica» las pull requests, tenemos ahora un proyecto piloto de aprobaciones automáticas de pull requests por la IA si los cambios cumplen ciertos criterios. No tiene sentido esperar a que un humano pulse un botón si el radio de impacto no es crítico.
Escalar la IA en Devolutions
La explosión de herramientas de IA
En enero de 2026 teníamos un equipo interno de campeones de la IA, con el papel de promover el uso de la IA compartiendo su propia experiencia con sus compañeros. Las instrucciones para la IA las mantenían unos pocos desarrolladores en el monorepo. El mensaje enviado a todo el mundo era que actualizaran las instrucciones para la IA, de modo que entendiera mejor el código, en lugar de resistirse a la IA y quejarse de que cometía demasiados errores. Internamente, la mayoría de los desarrolladores usaban Claude Code, y grupos más pequeños usaban GitHub Copilot, Cursor o Codex. Teníamos dos comités de IA: un comité de dirección con el liderazgo ejecutivo, para hablar de iniciativas de IA de más alto nivel o de proyectos de IA fundacionales, y un comité de «centro de excelencia» de IA con los campeones de la IA, más práctico y operativo.
La tentación de intentar estandarizar qué herramientas de IA ofrecemos está ahí, pero nos resistimos. Los desarrolladores tienen sus propias preferencias y no queremos obligarlos a usar una herramienta que no les gusta. Personalmente, nunca me gustó Claude Code y aposté por completo por GitHub Copilot. No puedo discutir con alguien que se siente productivo en una herramienta que yo mismo no usaría, aunque no pueda explicarlo de forma racional. Mi teoría es que la ganancia de productividad de las herramientas de IA es tan grande que la comparación se hace con las herramientas de antes de la IA, no entre herramientas de IA. En el momento en que alguien se siente eficaz con una herramienta de IA que encaja con su modelo mental y su flujo de trabajo, querrá quedarse con ella. Yo era un gran usuario de VS Code antes de la IA, así que naturalmente fui primero a GitHub Copilot. Muchos desarrolladores prefieren usar Claude Code en un terminal junto a su IDE principal (Visual Studio o JetBrains), y ven VS Code como un IDE más junto al que ya tienen.
Vivimos el primer «tiempo de inactividad» de IA cuando alcanzamos un límite mensual de 5.000 $, lo que nos obligó a mejorar nuestra cuenta con Anthropic para poder seguir. Hubo unos días en los que algunos usuarios de Claude Code pasaron temporalmente a GitHub Copilot mientras se resolvía el límite de nuestra cuenta. Esas cifras parecían grandes entonces para toda la empresa. Ahora son simplemente lo que un solo usuario intensivo puede consumir con facilidad. GitHub Copilot sigue usando el modelo de solicitudes premium que lo hacía increíblemente barato si sabía cómo usarlo con eficacia. Cursor es más caro, pero empezamos a ofrecérselo a nuestros desarrolladores web y al departamento de marketing por sus capacidades agénticas de navegador integrado, más avanzadas.
Un efecto secundario de la explosión de nuevas herramientas de IA es que nuestro proceso de gestión de proveedores se convirtió pronto en un cuello de botella. Con una herramienta de IA nueva e interesante que sale cada día, y un mensaje claro del CEO de que apostamos por completo por la IA, el número de solicitudes para evaluar productos nuevos de distintos proveedores creció más allá de lo que nuestros departamentos jurídico y de seguridad podían atender a tiempo. Aunque consiguiera recorrer todo el proceso para que se aprobara la herramienta, ¿qué pasa con las funciones nuevas que probablemente también deberían evaluarse de nuevo, como las funciones de aislamiento en la nube? ¿Y los modelos de IA nuevos que salen, pero que sirve un proveedor de inferencia nuevo que no se usaba cuando se hizo la evaluación original? Hemos simplificado el proceso, pero sigue siendo un problema hoy.
Las grandes guerras Markdown de la IA
¿Recuerda cuando las agent skills y AGENTS.md aún no existían, y cada herramienta usaba una convención distinta para los archivos Markdown? Me gusta llamarlo las «grandes guerras Markdown de la IA»: nombres de archivo, rutas, formatos distintos, etc. A menos que se hubiera estandarizado en una sola herramienta de IA, era inevitable chocar con el problema de las incompatibilidades. GitHub Copilot usaba .github/copilot-instructions.md, Claude Code usaba CLAUDE.md, con un posible anidamiento. «Comandos slash» reutilizables e instrucciones específicas de una ruta. Todos solo eran legibles por sus propias herramientas, hasta que las skills de Claude se convirtieron en agent skills que la mayoría de las herramientas adoptaban y leían desde las mismas rutas, todas excepto Claude. AGENTS.md se convirtió en la nueva norma, que Claude, otra vez, no leía, y que exigía CLAUDE.md en su lugar.
Al principio escribimos scripts para sincronizar y adaptar las agent skills y los archivos Markdown para la compatibilidad en nuestro monorepo, con un trabajo de CI que se ejecutaba cada vez que se modificaba uno de los archivos, pero eso hacía difícil iterar en local al actualizar las instrucciones. Al final pasamos a enlaces simbólicos de git, que son un verdadero fastidio en Windows porque los enlaces simbólicos necesitan una configuración especial para activarse correctamente. Empezamos a sacar las instrucciones del AGENTS.md y del CLAUDE.md principales hacia archivos Markdown más pequeños, y a extraer los flujos de trabajo reutilizables en sus propias agent skills. ¿Recuerda ese enorme archivo Markdown de 5.000 líneas para las migraciones a Avalonia? Se dividió en muchas agent skills más pequeñas, y las convenciones específicas de cada plataforma se extrajeron a sus propios archivos Markdown.
Siguen añadiéndose skills nuevas al monorepo principal de Devolutions: más de 25, solo ellas, son para tareas concretas relacionadas con Avalonia. Se añadieron agent skills para editar archivos de traducción. La versión original de esas skills hacía que el LLM leyera de forma ingenua archivos .resx muy grandes solo para cambiar una línea. Luego se reescribieron y se optimizaron para usar un script de ayuda, lo que bajó el coste de una edición de 1 $ a unos pocos céntimos, porque el LLM ya no necesitaba leer todo el archivo, solo la línea que quería editar.
El hackathon de agent skills
Aun así, la mayoría de las agent skills seguían siendo escritas por un puñado de personas dentro de la empresa, un problema recurrente que salía en nuestros comités de IA. La solución que se nos ocurrió fue organizar en marzo un hackathon de «agent skill» de IA para desarrolladores, a escala de toda la empresa. Habíamos hecho muchos hackathons en el pasado, pero el interés había bajado en los últimos años, con menos gente participando. Era hora de algo nuevo, con un formato distinto, para romper la «fatiga de los hackathons» que se había instalado.
Me tomé el tiempo de poner en marcha un repositorio dedicado a las agent skills, que los desarrolladores podían simplemente clonar y abrir en la herramienta que eligieran, con un README.md y algunas agent skills ya existentes para empezar. Redacté un buen AGENTS.md, con referencias de autoridad para escribir agent skills, y con instrucciones para usar scripts de PowerShell multiplataforma junto a SKILL.md como scripts de ayuda. TI había preinstalado PowerShell 7 en todas las máquinas, asegurándose de que los usuarios de macOS, Linux y Windows pudieran usar esas agent skills desde el primer momento.
En las semanas anteriores al hackathon hicimos varios anuncios para animar a los participantes a pensar en lo que les gustaría hacer, y a añadir de antemano su nombre y su idea de proyecto en un lienzo de Slack visible para todos. Arrancamos el día del hackathon con una breve llamada en la que presenté el repositorio git que había que usar, mostré algunas agent skills de ejemplo, cómo empezar y dónde encontrar instrucciones más detalladas. El objetivo era sencillo: clonar este repositorio, escribir una agent skill para lo que quiera y enviar una pull request cuando termine. No se preocupe por hacer la mejor agent skill ni la más compleja. Céntrese en terminar al menos una. Al final del hackathon, todo el mundo se sentiría cómodo escribiendo sus propias agent skills. Se acabaron las excusas. Las agent skills que necesitaban estar dentro de un proyecto concreto para funcionar podían desarrollarse en otro repositorio, siempre que se hiciera una copia en el repositorio git dedicado al hackathon para enviar la pull request.
Este enfoque de un solo repositorio git para el hackathon ayudó de verdad a que pareciera que todo el mundo trabajaba en lo mismo, de forma colaborativa, en lugar de que cada uno estuviera en su propio proyecto separado. Había mucha actividad en el canal de Slack del hackathon, con participantes que compartían enlaces a sus propias pull requests o hacían preguntas. Fue, con diferencia, el hackathon más exitoso que hemos tenido en años y, al final, se habían aportado 60 agent skills.
Extender la IA más allá de los desarrolladores
El éxito del hackathon de «desarrolladores» fue tan grande que llevó a organizar un hackathon «no-code» en mayo. Adaptamos un poco el formato, sobre todo en las herramientas, que pasaron a ser ChatGPT o Claude, aceptando GPT personalizados y otros tipos de instrucciones personalizadas de agentes de IA que funcionan mejor en los chatbots. Se reservaron salas de conferencias para el día, con organizadores que se pusieron a disposición para ayudar. Muchas personas que no son desarrolladores disfrutaron de verdad de poder tener a un experto que se tomaba el tiempo de ayudarles a lograr cosas que ni siquiera sabían que eran capaces de hacer.
No olvidemos que, incluso en una empresa de desarrollo de software, una parte enorme del negocio depende de personas que no son desarrolladores, y ellas también tienen que formar parte de la transformación con IA. Como desarrolladores, la brecha entre las herramientas de IA para desarrolladores y las de quienes no lo son nos resulta más evidente a nosotros que a las personas que no son desarrolladoras cuando miran nuestras herramientas. Con el prompt como nueva interfaz de usuario, ¿hay una forma de configurar herramientas de desarrollo para que las use nuestro equipo de marketing de producto? La respuesta, resulta, es que sí.
Para el contexto, muchas solicitudes internas a nuestro equipo de marketing de producto consisten en actualizar o cambiar el sitio web, y los cambios los hace el equipo de marketing web. Ya habíamos incorporado Cursor para los desarrolladores web por su navegador integrado, que se siente como «Inspeccionar elemento» de Chrome, pero infinitamente más potente. Puse en marcha un repositorio git nuevo, parecido al del hackathon, y escribí un conjunto de agent skills que permitían obtener y reflejar cualquier sitio web con facilidad, de modo que Cursor pudiera editar sitios estáticos y producir maquetas. Se acabaron Figma y las muchas idas y vueltas: se podía editar el sitio web real mediante un prompt, e incluso añadí una agent skill para exportar el sitio estático modificado en local a un único archivo .htm.
Eso permitió iteraciones mucho más rápidas con una copia del sitio web real con la que se podía interactuar, lo que se siente muy distinto de las capturas de pantalla, o incluso de las maquetas interactivas que simulan el sitio pero no se basan de verdad en él. Eso redujo de forma notable el número de traspasos y los procesos largos para hacer cambios en el sitio web. Lo mejor de todo: el desarrollador podía ahora pasar a Cursor el sitio estático modificado exportado para que los cambios se hicieran correctamente en el código fuente a partir del cual se construye el sitio.
Hoy, ese equipo es uno de los más avanzados en la adopción de la IA, y puede desencadenar ediciones del sitio web mencionando al bot de Cursor en una conversación de Slack. El sitio se modifica, se construye y se despliega de forma temporal, con un enlace que basta con abrir para ver si los cambios están bien. Si se aprueban, se fusionan y se despliegan de forma automática. Por supuesto, esto sería mucho más difícil para aplicaciones de escritorio y móviles como Remote Desktop Manager, pero si lo que desarrolla usa una pila web, tiene la ventaja de poder cerrar el bucle con mucha más facilidad en entornos aislados en la nube.
La nueva economía de construir software
Contratar sin aumentar la plantilla
En Devolutions no hubo despidos masivos por la IA. En su lugar, ofrecimos paquetes de salida voluntaria. En el otoño de 2025, solo unos pocos empleados decidieron aceptarlos. No queríamos que los empleados se sintieran atrapados en una «Devolutions 2.0» que quizá ya no fuera adecuada para ellos. En 2026 ofrecimos generosos paquetes de prejubilación, que aceptó la mayoría de los empleados que podían optar a ellos. Aunque el año aún no ha terminado, vamos camino de tener un número equilibrado de salidas y nuevas contrataciones, de modo que la plantilla total sigue igual. No hemos dejado de contratar, pero hemos dejado de sustituir. La IA ha sido un factor importante en la redistribución de la plantilla: cada nueva contratación apoya la nueva Devolutions, y cada salida nos aleja más de la antigua Devolutions.
Nuevos proyectos de IA en abundancia
Solo en 2026 he creado desde cero un gran número de proyectos nuevos e importantes, todos con la aplicación de GitHub Copilot. Mi portátil está ahora permanentemente despierto y ejecuta agentes la mayor parte del tiempo. Cuando vuelvo a casa, lo conecto y relanzo mis sesiones. Antes de dormir, me aseguro de que mis sesiones no estén inactivas y las mando a trabajos nocturnos. Cuando me despierto por la mañana, a menudo las pongo en marcha otra vez y, para cuando salgo hacia la oficina, ya han avanzado. Estoy seguro de que otros CTO están viviendo lo mismo: el tiempo es una moneda con los agentes de IA de larga duración. Todo ese tiempo muerto en el que no está delante del ordenador puede volverse de pronto productivo.
Todavía no estoy del todo seguro de lo sano que es esto a largo plazo, pero es la nueva realidad a la que intento adaptarme. Siempre he tenido muchas más ideas ambiciosas que tiempo y recursos para lograrlas, así que es muy emocionante y muy agotador a la vez. Antes me limitaba el hecho de que no podía apartar recursos críticos para construir un proyecto paralelo por un impulso. Ahora se reduce al tiempo que puedo dedicar a preparar un plan para lanzar un agente. Combine eso con un presupuesto de tokens ilimitado, y he construido más software en los últimos meses que en toda mi vida.
Esta es una lista breve de experimentos que funcionaron lo bastante bien como para que los limpiara para una publicación en condiciones. Todos se usan en producción, ya sea como herramientas o como componentes de uno de nuestros productos:
- Pinget: ports en C# y Rust de winget-cli (C++), hechos multiplataforma. Disponible como paquete NuGet para consumirlo en UniGetUI.
- psign: herramienta multiplataforma de firma de código en Rust que admite todos los formatos de archivo Authenticode, con compatibilidad con Azure Key Vault y Azure Artifact Signing.
- windbg-tool: herramienta de línea de comandos en Rust que usa el motor WinDBG, diseñada específicamente para permitir que los agentes de IA inspeccionen volcados de procesos, y que he usado para investigar BSOD en mi portátil.
Todos estos proyectos enormes se completaron en cuestión de semanas, por una pequeña fracción del coste que habrían tenido en el pasado. Históricamente, yo solo podía elegir unas pocas de estas ideas y planificar el trabajo a lo largo de varios meses o años para que lo hicieran otros. Creo que por eso a muchos directivos de nivel C les gusta tanto la IA: si está acostumbrado a determinar con mucha precisión lo que quiere que otros construyan, ajustado a sus requisitos, hablar con un agente de IA le resultará muy natural.
Ahora quemo un mínimo de 15.000 $ al mes en GitHub Copilot. Puede parecer mucho, pero sigue sin ser nada comparado con delegar ese tipo de trabajo a un equipo de desarrolladores a tiempo completo. No solo es más barato: normalmente puede evaluar la viabilidad en las primeras 24 horas y abortar pronto los experimentos condenados al fracaso. Antes, los recursos se ocupaban durante mucho más tiempo antes de chocar con un obstáculo insalvable imprevisto.
Construir software para la IA, no solo con IA
La IA puede escribir mucho código deprisa, pero solo debería considerarse bueno después de confirmar que se ejecuta correctamente al menos una vez. Las pruebas son la forma más sencilla de ejecutar código para asegurarse de que coincide con el comportamiento esperado, pero no todo es fácil de probar. Muchas partes de una aplicación pueden ser difíciles de automatizar o exigir un entorno real concreto. La buena noticia es que la IA ahora puede ayudarle a alcanzar niveles altos de capacidad de prueba con mucha más facilidad que antes.
Más allá de las pruebas, conviene invertir en construir herramientas diseñadas específicamente para un agente de IA. De mis tiempos de FreeRDP aún recuerdo las largas horas que pasaba haciendo un cambio, compilando, ejecutando un comando para conectarme a una máquina virtual de Windows, haciendo clic y escribiendo algo para disparar una función concreta de RDP en la que trabajaba, y viendo si funcionaba. Y otra vez, y otra vez.
Avancemos hasta hoy con IronRDP, el sucesor espiritual de FreeRDP, escrito en Rust en lugar de C. Es un esfuerzo de varios años que empecé en Devolutions mucho antes de la IA, sabiendo muy bien el esfuerzo gigantesco que hacía falta. El proyecto está muy activo, con muchos colaboradores internos y externos. Visto lo que la IA podía hacer, me propuse construir un cliente RDP agéntico con un solo objetivo: que mi agente de IA hiciera la parte aburrida y repetible que yo hacía a mano.
La estrategia es sencilla: ironrdp-agent lanza un proceso demonio para la conexión de escritorio remoto, que se puede controlar con llamadas IPC repetidas desde la CLI. El agente de IA puede entonces hacer capturas, interactuar con el escritorio haciendo clic y escribiendo, usar el portapapeles, ejecutar scripts, copiar archivos, etc. Eso significa que puedo hacer que mi agente de IA pase horas haciendo el trabajo pesado de probar de forma exhaustiva funciones que antes exigían interacción humana, mientras yo duermo.
¿A quién no le gusta despertarse con una larga lista de casos de prueba «manuales» confirmados como funcionales por la mañana? Así es como añadí la redirección del sistema de archivos para Windows en IronRDP. Copió estructuras complejas de archivos y directorios, y comprobó los hashes de los archivos antes y después. Incluso copió una ISO de 8 GB para confirmar que podía transferir archivos de más de 4 GB sin corromperlos.
La nueva realidad económica de la IA significa que hay un retorno de la inversión muy alto en construir herramientas pensadas específicamente para agentes de IA. Además, desarrollar esas herramientas es más barato que antes, así que no tiene que elegir. Con el desarrollo tradicional, el coste de construir herramientas de desarrollo complejas a menudo superaba las ganancias de productividad.
Lo que viene
Cerrar el bucle de retroalimentación de las aplicaciones de escritorio de Windows
La migración a Avalonia de RDM Windows no aprovechó un bucle de retroalimentación completo con el agente de IA, pero se compensó con desarrolladores que iteraban rápido en la fase de validación. La migración a Avalonia de UniGetUI se hizo sobre todo con un bucle de retroalimentación cerrado con el agente de IA durante 24 horas, seguido de un par de semanas de correcciones hechas por un desarrollador. La parte que no le he contado es que la única forma eficaz de cerrar el bucle de retroalimentación en una aplicación de escritorio de Windows, ahora mismo, es dejar que el agente de IA tome el control del ordenador.
Si instala la CLI winapp y las agent skills asociadas para la automatización de la interfaz en la aplicación de GitHub Copilot, puede hacer que el agente de IA lance su aplicación e interactúe con ella igual que lo haría con una aplicación web que se ejecuta en Playwright. El único problema es que Windows solo admite una aplicación con el foco de entrada a la vez, así que no puede hacer gran cosa mientras el agente de IA controla el ordenador. Por eso a menudo dejaba que las tareas largas de validación de interfaz se ejecutaran por la noche, cuando yo no estaba delante del ordenador.
El reto del próximo año será cerrar el bucle de retroalimentación de las aplicaciones de escritorio de Windows de una forma que permita a los agentes de IA lanzar y probar interfaces gráficas sin interrumpir nada. Un entorno completo de escritorio remoto podría funcionar, pero exige muchas herramientas adicionales para admitir el despliegue y la ejecución remotos. En cuanto a Windows Sandbox, sigue siendo RDP por debajo, pero por desgracia está limitado a una sola conexión a la vez, así que las sesiones simultáneas no serían posibles.
Con mi condición de Microsoft MVP puedo dar feedback directo a Microsoft, y espero encontrar una solución a este problema, quizá contribuyendo parte de la solución técnica con IronRDP. Será un área de atención para el próximo año, dados los aumentos de productividad que desbloquearía con los agentes de IA para nosotros.
Mis predicciones para el próximo año
Este último año ha tenido tanto que para mí se sintió como una década. Tantas cosas que en un pasado reciente parecían ingenuamente ambiciosas se han vuelto bastante fáciles de lograr en los últimos meses. No creo que estemos cerca de ver a la IA llegar a una meseta: simplemente sigue acelerando a un ritmo vertiginoso. Hace poco sentí un profundo malestar después de terminar en unas horas algo para lo que me habían dado una estimación de 4 meses de trabajo con métodos de desarrollo tradicionales.
Los flujos de trabajo agénticos sin un humano en el bucle se volverán más habituales: muchos más flujos se desencadenarán de forma automática en lugar de manual, y realizarán más acciones sin un humano en el bucle. Por ejemplo, actualizar la documentación de forma automática para que coincida con el código fuente de un producto. Encontrar problemas de seguridad de forma automática y abrir una pull request con una corrección provisional. Los humanos a menudo seguirán en el bucle en algún punto, pero en menos sitios.
El gasto en IA se convertirá en una parte permanente y significativa del presupuesto de una empresa: hace unos meses íbamos camino de 1 millón de dólares al año según los costes mensuales, pero desde entonces ha crecido hasta 2 millones de dólares al año. Seguimos sin planes de recortar nuestro gasto en IA. Tenga en cuenta que esto es para una empresa de 250 empleados, así que unos 8.000 $ por empleado. Espero que esta cifra solo siga creciendo, incluso cuando decidamos intentar optimizar los costes.
Lo que no cambió
En un mundo que cambia tan deprisa, ¿qué verdades permanecen?
Encontrar y configurar las herramientas adecuadas para el trabajo sigue importando: ¿quiere hacer ingeniería inversa de software escrito en C/C++? Tómese el tiempo de instalar Ghidra o IDA Pro, y de configurar un servidor MCP para exponer sus funciones a su agente de IA. Si no, en esencia conducirá un coche rápido con las ruedas pinchadas: no irá a ninguna parte, y desperdiciará muchos tokens intentándolo.
El conocimiento profundo de la arquitectura de software sigue siendo relevante: no confunda haber logrado un objetivo con haberlo hecho de la forma correcta. La IA es muy buena haciendo lo que usted pide, pero si solo tiene una comprensión superficial, está dejando muchas decisiones importantes al puro azar. La comprensión profunda es lo que le ayuda a orientar la IA en la dirección correcta, de modo que no tome atajos que puedan entrar en conflicto con los requisitos que pretende.
Construir la casa antes que los cimientos sigue siendo una mala idea: una buena parte del esfuerzo de la migración a Avalonia se dedicó a construir componentes adecuados que pudieran reutilizarse en varios sitios. Si hubiéramos empujado las migraciones que dependían de ellos, el agente de IA habría creado mucho código repetitivo y muchos auxiliares muy parecidos. Construir cimientos adecuados bajo una casa que ya está construida es posible, pero cuesta muchos tokens y mucho tiempo.
Lecciones aprendidas
He aprendido mucho durante el último año, pero si tuviera que reducirlo a una lista breve, esta es:
- La ejecución está comprimida: hay más valor en saber qué hacer que en hacerlo
- Conviene pagar activamente la deuda técnica para recuperar la agilidad perdida
- Invierta en herramientas que permitan a los agentes de IA cerrar el bucle de retroalimentación
- Las revisiones de código siguen existiendo, pero ahora se hacen con IA en distintos niveles
- Hacer cambios en código que no entiende puede acelerar el desarrollo
Espero que mi experiencia como CTO de Devolutions en este último año de IA haya sido relevante para su realidad sobre el terreno, y que haya aprendido algo de ella. ¡Tengo ganas del año que viene, en esta montaña rusa que no termina!