← Últimos artículos
🤖 AI

From Prompt to Process: a Process Taxonomy and Comparative Assessment of Frameworks Supporting AI Software Development Agents

Este artículo introduce una taxonomía de procesos y una rúbrica de puntuación de seis dimensiones para evaluar comparativamente seis marcos emergentes de desarrollo de software con IA, revelando una convergencia hacia artefactos persistentes y revisión humana, al tiempo que destaca un compromiso estructural entre la profundidad del proceso y la portabilidad, junto con riesgos críticos como la deriva de especificaciones y la dependencia de la plataforma.

Autores originales: Sanderson Oliveira de Macedo

Publicado 2026-06-04
📖 6 min de lectura🧠 Análisis profundo

Autores originales: Sanderson Oliveira de Macedo

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que has contratado a un aprendiz brillante y superrápido para que te ayude a construir una casa. Este aprendiz es un agente de codificación de IA. En el pasado, podrías haber simplemente gritado: "¡Construye una pared!", y esperar lo mejor. A veces la pared era genial; otras veces, estaba torcida, hecha con los ladrillos equivocados o construida en el lugar equiván.

Este artículo sostiene que simplemente gritar instrucciones (prompts) ya no es suficiente. Necesitamos marcos de trabajo (frameworks) —que son como libros de reglas detallados, planos y sistemas de gestión— para guiar a estos aprendices de IA. El autor, Sanderson Oliveira de Macedo, analizó seis "libros de reglas" populares actualmente utilizados en la industria para ver cómo organizan el trabajo.

Aquí tienes un desglose de los hallazgos del artículo utilizando analogías simples:

1. El Problema: De "Gritar" a "Gestionar"

En los viejos tiempos, hablabas con la IA una frase a la vez. Era como jugar al juego del "teléfono descompuesto" donde el mensaje se pierde. La IA olvidaba lo que habías dicho hace cinco minutos, o inventaba hechos (alucinaciones).

El artículo dice que estamos pasando a una nueva era donde la IA no solo chatea; la IA trabaja. Planifica, edita archivos, ejecuta pruebas y corrige sus propios errores. Pero sin un gerente, este trabajador autónomo puede volverse caótico. Los "marcos de trabajo" que estudia el artículo son los gerentes que le dicen a la IA:

  • Qué construir (Especificación).
  • Qué sabe ya sobre el proyecto (Contexto).
  • Quién hace qué (Roles).
  • Cómo construirlo (Ejecución).
  • Cómo comprobar si es correcto (Validación).
  • Si puede trabajar en diferentes sitios de construcción (Portabilidad).

2. Los Seis Libros de Reglas (Los Frameworks)

El autor eligió seis "libros de reglas" específicos para compararlos. Piensa en ellos como diferentes estilos de gestión:

  • GitHub Spec Kit y OpenSpec: Estos son como arquitectos. Insisten en que escribas un plano perfecto (una especificación) antes de que la IA coloque un solo ladrillo. Se centran mucho en el plan y pueden trabajar con muchas herramientas de IA diferentes.
  • Método BMAD: Este es como un departamento de RR.HH. corporativo. Divide el trabajo en roles específicos (Gerente de Producto, Arquitecto, Desarrollador, QA) y asigna a la IA para que actúe como estas diferentes personas. Es muy estructurado pero puede ser pesado.
  • Get Shit Done (GSD): Este es como un asistente personal que solo trabaja para un jefe específico (una herramienta de IA concreta). Es excelente organizando la memoria y el enfoque de la IA, pero no es muy flexible si quieres cambiar de jefe.
  • Spec Kitty: Este es como un sitio de construcción con vallas de seguridad. Aísla el trabajo de la IA en un área separada (un "worktree") para que no pueda romper accidentalmente el edificio principal. Fuerza a un humano a inspeccionar el trabajo antes de que se integre.
  • Reversa: Este es el ingeniero inverso. En lugar de construir una casa nueva desde cero, observa un edificio viejo y en ruinas (código legado) e intenta averiguar los planos originales para que la IA pueda repararlo.

3. El Gran Descubrimiento: El Intercambio de "No hay Almuerzo Gratis"

El hallazgo más importante del artículo es que ningún libro de reglas es perfecto.

El autor creó un sistema de puntuación (una rúbrica) para calificar estos marcos de trabajo. Aquí está la analogía:

  • Algunos marcos son como Navajas Suizas: son ligeros, portátiles y funcionan en todas partes, pero no tienen una herramienta profunda y especializada para cada trabajo. Son excelentes planificando pero débiles comprobando el trabajo.
  • Otros marcos son como Grúas de Construcción Pesadas: son increíblemente potentes, tienen controles de seguridad estrictos y procesos profundos, pero son difíciles de mover y solo funcionan en lugares específicos.

El Intercambio (Trade-off): Cuanto más profundamente gestiona un marco de trabajo el proceso (comprobando cada paso, asignando roles), más difícil es mover ese marco a una herramienta de IA diferente. No puedes tener el proceso más profundo y la mayor portabilidad al mismo tiempo con las herramientas actuales.

4. Los Peligros Ocultos (Riesgos)

El artículo también advierte sobre "riesgos en el sitio de construcción" que estos marcos aún no han resuelto por completo:

  • Deriva (Drift): El plano (especificación) puede decir "ladrillo rojo", pero la IA construye una "pared azul" de todos modos, y nadie lo nota hasta que es demasiado tarde.
  • Confianza Ciega: Podemos confiar demasiado en el trabajo "terminado" de la IA, incluso si parece bueno pero en realidad está roto por dentro.
  • Extensiones Frágiles: Estos marcos suelen depender de complementos creados por la comunidad. Si la persona que hizo el complemento deja de actualizarlo, todo el sistema podría romperse.
  • Bloqueo (Lock-in): Algunos marcos están tan ligados a una herramienta de IA específica que, si esa herramienta cambia sus reglas, todo tu proceso se desmorona.

5. ¿Qué sigue? (La Agenda de Investigación)

El artículo concluye que estamos en la fase del "salvaje oeste". Tenemos herramientas geniales, pero no tenemos suficientes datos para saber cuál funciona mejor a largo plazo.

El autor sugiere que debemos dejar de solo mostrar demostraciones geniales y empezar a hacer ciencia real:

  • Medir los pasos intermedios: No te limites a comprobar si el código final funciona; comprueba si el plan de la IA y el plano eran buenos.
  • Probar la memoria: ¿Realmente lee la IA los archivos correctos, o está adivinando?
  • Observar a los equipos: Ver cómo se desempeñan los equipos humanos reales a lo largo de meses, no solo de días.

Resumen

El artículo es un mapa del panorama actual de las herramientas de software de IA. Nos dice que, si bien hemos pasado de "chatear con la IA" a "gestionar equipos de IA", aún no hemos encontrado al gerente perfecto. Tenemos que elegir entre herramientas que sean flexibles y fáciles de mover, o herramientas que sean profundas y rigurosas pero difíciles de cambiar. El futuro reside en construir mejores formas de medir si estas herramientas realmente están mejorando el software, no solo haciéndolo más rápido.

¿Ahogado en artículos de tu campo?

Recibe resúmenes diarios de los artículos más novedosos que coincidan con tus palabras clave de investigación — con resúmenes técnicos, en tu idioma.

Probar Digest →