En el artículo anterior vimos cómo las Skills nos permiten que un agente revise el trabajo de otro, reduciendo el cuello de botella del ingeniero. Pero el análisis acabó con una conclusión incómoda: la skill detectó 9 issues, dos de ellos críticos — datos de dominio perdidos en runtime — y no fueron errores del agente. El agente implementó exactamente lo que se le pidió. El problema estaba en los requisitos: se describió el qué y el cómo, pero nadie pensó en el impacto sobre el resto del sistema.
A raíz del primer artículo, continuamos con la serie sobre cómo integrar la IA dentro de nuestro flujo de trabajo. En el primer artículo vimos la importancia de darle contexto para que la IA se aproxime al resultado deseado, pero es algo que siempre está supervisado por una persona que se encarga de revisar cada uno de los pasos que da. Esto provoca que, al final, siempre haya un cuello de botella en el ingeniero que supervisa la IA.
La IA ha dejado de ser un hype. Hemos pasado de que la usaban cuatro valientes a que hoy en día prácticamente nadie en el sector se queda al margen. Se habla mucho de que seremos la última generación de desarrolladores que hemos escrito código de verdad, de que la IA lo puede hacer todo… pero ¿cuál es la realidad hoy? ¿Cómo la podemos ir integrando de forma sensata? En esta serie de posts voy a ir contando cómo lo uso yo en mi día a día con proyectos .NET.
En el mundo del desarrollo de software moderno, la seguridad y el rendimiento no deben ser una ocurrencia tardía, sino pilares fundamentales desde el inicio del proyecto. Ignorar estos aspectos puede llevar a vulnerabilidades críticas y a un deterioro del rendimiento que afecte directamente la experiencia del usuario y, en última instancia, la viabilidad de un producto. Una de las estrategias más efectivas y sencillas para mitigar estos riesgos es la implementación de Rate Limiting.
Recientemente se ha lanzado .NET 9, que no es una versión de soporte extendido (LTS). Ya compartí mi opinión sobre el tema del versionado y cómo lo gestionamos en ocasiones en el artículo que escribí para CompartiMOSS hace un tiempo. Si me preguntáis si en los proyectos en los que trabajamos vamos a migrar a .NET 9, mi respuesta es un rotundo SÍ.
