Desarrollo

Llevo unas semanas dándole vueltas al ritmo al que estamos desarrollando software desde que herramientas como GitHub Copilot, Claude Code y compañía se han sentado con nosotros en la mesa. Y sí, aceleran. A estas alturas negarlo sería como discutir que el fuego quema o que una daily mal llevada puede durar más que una migración de SharePoint.

Pero también me está quedando cada vez más claro que esa aceleración tiene trampa. La IA te ayuda a escribir código más rápido, sí, pero también puede empujarte a una especie de desconexión peligrosa: empiezas a aceptar cambios que “parecen bien”, confías en que lo que ha generado hace lo que crees que hace, y cuando quieres darte cuenta estás conduciendo un coche a toda velocidad sin tener realmente las manos en el volante.

Este artículo cierra una serie de tres. Los anteriores cubren qué es Spec Driven Development y qué es Context Engineering. Si llegas aquí sin leerlos, la comparación que sigue va a ser menos útil.

Si ya los has leído, la pregunta que probablemente tienes es: ¿cuándo uso uno, cuándo uso el otro, y qué pasa cuando los combino? Aquí va la respuesta.

Si llevas un tiempo trabajando con IA, seguramente habrás visto en algún README, en algún hilo de Twitter o en alguna charla de meetup el consejo universal: “dale más contexto a la IA”. Lo dice todo el mundo con esa convicción de quien ha descubierto el agua caliente.

Y sí, dar contexto ayuda. El problema es que “dar contexto” como gesto vago no es lo mismo que hacerlo bien. Y hacerlo bien tiene nombre, tiene disciplina, y ese nombre no es el que circula por ahí.

Si llevas unos meses siguiendo el ruido de Twitter/X, LinkedIn y los blogs de las grandes plataformas, habrás visto que el término Spec Driven Development aparece cada vez más. GitHub lo usa para presentar Spec Kit. Microsoft lo menciona en su documentación de Azure Verified Modules. InfoQ le dedicó un artículo largo a principios de 2026.

Detrás del buzz hay algo concreto. SDD no es un invento reciente ni un eufemismo para “escribir documentación”. Tiene historia, tiene una mecánica clara y, con los agentes de código actuales, cobra un sentido que antes era difícil de aprovechar.

Con la evolución de herramientas de desarrollo que hacen uso de la IA como GitHub Copilot, Claude Code, Cursor y compañía, es natural preguntarse si el rol del developer está en peligro de extinción.

Desde luego, ya no desarrollamos, o no deberíamos desarrollar, código a mano como antes. Ahora nos apoyamos en estas herramientas para generar código de manera más eficiente y mucho más rápida. Y en este contexto he visto multitud de artículos, posts y reflexiones donde hay quien afirma que el rol del developer está muerto, o que va a morir, o que va a ser sustituido por la IA; y, contrariamente, hay quien afirma que no, que todo es puro alarmismo.

Como todos tienen su propia opinión y, ya sabéis, las opiniones son como los culos, con perdón, todos tenemos una, voy a compartir la mía. Y lo haré desde mi experiencia actual: la de un developer que lleva más de 20 años desarrollando en equipo y que ha vivido la evolución desde los editores de texto hasta las modernas herramientas de IA.

La mayoría de demos con agentes funcionan muy bien hasta que aparece el primer problema real: hay que persistir contexto, exponer capacidades por HTTP, desacoplar eventos, aguantar reinicios y, además, mantener el sistema operable por un equipo backend normal.

Ahí es donde Dapr Agents resulta interesante. No tanto por la palabra “agent”, sino porque aterriza el problema sobre piezas de plataforma que ya conocemos: state stores, pub/sub, workflows, APIs y sidecars.

En este artículo voy a contar cómo encaja esa idea en un proyecto real: D&D Copilot, un juego conversacional con backend en ASP.NET Core, frontend en React y una capa de NPCs que ya adopta varios conceptos de Dapr Agents aunque la aplicación esté implementada en .NET.

Para los desarrolladores de .Net, es habitual usar el archivo Startup.cs, que viene por defecto en ciertas plantillas de proyecto, entre ellas las de proyectos de Web y de Api, para realizar determinadas tareas que deben ejecutarse al inicio, como determinar los orígenes de las variables de entorno/configuración, añadir servicios al contenedor de dependencias, etc. e incluso aprendimos a añadirlo en proyectos de consola donde no viene por defecto. Pero, al crear un proyecto de Web y de Api con .Net 6, podemos apreciar que ya no existe este fichero Startup.cs. ¿Y ahora dónde ponemos nuestra configuración?

Azure Durable Functions es una gran extensión de las Azure Functions que nos permite generar «recetas» o definir procesos que involucren diferentes Azure Functions para llevar a cabo una tarea cuyo resultado conjunto no pueda ser resuelto por una de ellas debido a su complejidad. De esta forma, una Durable Function comienza con un «Orquestador» que definirá las reglas o el flujo que deben seguir en la actuación de las diferentes Azure Functions involucradas . Hasta aquí todo es relativamente sencillo pero, ¿qué ocurre cuando el proceso incluye a su vez subprocesos complejos? Es aquí donde aparecen las Suborquestaciones y os lo enseño en este artículo con código y en el vídeo incluído al final.

En un artículo reciente os hablé de cómo unir dos listas de elementos en C# con Linq eliminando los duplicados y en este artículo os traigo una pequeño tip muy simple que es cómo reemplazar un elemento de una lista.

En muchas ocasiones es necesario combinar dos listas de elementos del mismo tipo de objeto sin tener la certeza de que puedan o no existir duplicados. Realizar esta combinación es, a priori, una tarea sencilla puesto que podemos resolverla usando un bucle y realizando todas las comprobaciones pertinentes pero, ¿es la forma más elegante y legible? Gracias a Linq podemos resolver esta tarea, y otras muchas, sin necesidad de escribir grandes cantidades de código y haciéndolo mucho más legible y mantenible.