<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Spec-Driven-Development on Avenger Developer</title><link>https://www.theavenger.dev/tags/spec-driven-development/</link><description>Recent content in Spec-Driven-Development on Avenger Developer</description><generator>Hugo -- gohugo.io</generator><language>es</language><copyright>© 2026 Adrián Díaz Cervera</copyright><lastBuildDate>Sun, 14 Jun 2026 08:00:00 +0200</lastBuildDate><atom:link href="https://www.theavenger.dev/tags/spec-driven-development/index.xml" rel="self" type="application/rss+xml"/><item><title>Adoptar IA en el Desarrollo: Spec Driven Development</title><link>https://www.theavenger.dev/posts/adoptar-ia-desarrollo-sdd/</link><pubDate>Sun, 14 Jun 2026 08:00:00 +0200</pubDate><guid>https://www.theavenger.dev/posts/adoptar-ia-desarrollo-sdd/</guid><description>&lt;p&gt;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 &lt;em&gt;qué&lt;/em&gt; y el &lt;em&gt;cómo&lt;/em&gt;, pero nadie pensó en el impacto sobre el resto del sistema.&lt;/p&gt;</description></item></channel></rss>