En el caso de las órdenes de compraventa, parece que por problemas como la inyección de prompts podrían procesarse órdenes no intencionadas, así que funciones adicionales como limitar el activo objetivo o el monto de la orden parecen indispensables.
La sensación de que las redes sociales hacen perder el tiempo se parece más a la de las apuestas o las drogas: deja una sensación de "arrepentimiento" o "vergüenza".
Independientemente del contenido, creo que se siente más así porque, por el título de «una sola línea de prompt», lo que uno espera ver y el contenido del texto terminan siendo distintos.
Invierte el flujo donde el PRD y los documentos de diseño giraban alrededor del código: la especificación es la fuente original y el código es una expresión implementada en un lenguaje o framework específico
Se plantea el diagnóstico de que la brecha permanente entre especificación e implementación era difícil de cerrar solo reforzando documentación o procesos
Si las especificaciones ejecutables y el plan de implementación generan el código, la brecha desaparece y solo queda la transformación
La IA hace posible interpretar especificaciones complejas y elaborar planes de implementación, pero como la generación sin estructura provoca caos, SDD asegura la calidad con estructura precisa y guardrails
El mantenimiento es una acción de evolución de la especificación; la intención de desarrollo se expresa con lenguaje natural, activos de diseño y principios clave, y el código ocupa la posición de la última milla
El debugging prioriza corregir la especificación y el plan de implementación antes que arreglar código incorrecto, y el refactoring se redefine como reconstrucción de claridad
The SDD Workflow in Practice
La idea se refina en un PRD mediante interacción conversacional con la IA, y la IA concreta preguntas, casos límite y criterios de aceptación
Convierte requisitos y diseño en una actividad continua, y soporta trabajo de especificación basado en branches a nivel de equipo, además de revisión y versionado
Un agente de investigación explora compatibilidad de librerías, performance, seguridad y restricciones organizacionales (estándares de DB, autenticación, políticas de despliegue) y lo refleja automáticamente en la especificación
A partir del PRD genera un plan de implementación que mapea de forma trazable los requisitos y las decisiones técnicas, mientras la IA valida continuamente contradicciones, ambigüedades y omisiones
Cuando la especificación y el plan están lo suficientemente estables, comienza la generación de código, pero al inicio se usa generación exploratoria para validar la viabilidad
Los conceptos de dominio se convierten en modelos de datos, las user stories en endpoints de API y los escenarios de aceptación en tests
En operación, las métricas e incidentes actualizan la especificación para reflejarse en la siguiente regeneración; los cuellos de botella de performance se elevan a requisitos no funcionales y las vulnerabilidades a restricciones globales
Why SDD Matters Now
Punto de inflexión en capacidades de IA: ya puede generar de forma confiable código funcional desde especificaciones en lenguaje natural, y automatiza la parte mecánica de la traducción a implementación para potenciar exploración y creatividad
Explosión de complejidad: con muchos servicios, frameworks y dependencias, mantener la alineación entre intención e implementación se vuelve difícil, por lo que se necesita la alineación impulsada por especificaciones de SDD
Aceleración del cambio: en contextos de pivotes frecuentes, SDD maneja los cambios mediante regeneración sistemática en lugar de propagación manual entre documento, diseño y código
Como ejemplo, permite simulaciones what-if e implementación en paralelo, aportando agilidad en la toma de decisiones
Core Principles
Especificación = lenguaje común: la especificación es un artefacto de primer nivel, el código es una expresión de un stack específico y el mantenimiento es evolución de la especificación
Especificaciones ejecutables: con especificaciones precisas, completas y no ambiguas se genera un sistema funcional
Refinamiento continuo: no es una compuerta única, sino una verificación permanente de consistencia
Contexto basado en investigación: se recopilan de forma continua performance, seguridad y restricciones organizacionales para inyectarlas en la especificación
Feedback bidireccional: la realidad operativa se convierte en entrada para actualizar la especificación
Branching para explorar: desde una misma especificación se soporta generar múltiples implementaciones según objetivos de optimización como performance, mantenibilidad, UX o costo
Implementation Approaches
La práctica actual se centra en combinar herramientas existentes y mantener disciplina, y puede implementarse con los siguientes elementos
Asistente de IA para refinamiento iterativo de especificaciones
Agente de investigación para recopilar contexto técnico
Herramienta de generación de código para la transformación especificación→implementación
Control de versiones adaptado a un flujo de trabajo spec-first
Verificación basada en análisis de consistencia con IA sobre los documentos de especificación
El principio común es tratar la especificación como única fuente de verdad y el código como resultado exigido por la especificación
Streamlining SDD with Commands
/specify: convierte la descripción de una funcionalidad en una especificación estructurada y automatiza numeración automática, creación de branch y estructura de directorios basada en templates
/plan: analiza la especificación → revisa cumplimiento de la constitución → hace la traducción técnica → documenta modelo de datos, contrato de API y escenarios de prueba → genera validación quickstart
/tasks: lee plan.md y diseños relacionados para producir una lista de tareas ejecutables, además de marcar tareas paralelizables y agrupar paralelismo seguro
Ejemplo: funcionalidad de chat
Se presenta un flujo de ejemplo donde unas ~12 horas de trabajo documental en el enfoque tradicional se reducen a unos 15 minutos de configuración mediante automatización de especificación, plan y tareas
Entre los entregables se versionan en el branch la especificación, el plan de implementación y su fundamento, el contrato de API y modelo de datos, los escenarios quickstart y tasks.md
The Power of Structured Automation
Evita omisiones: los templates abarcan incluso requisitos no funcionales y manejo de errores
Trazabilidad de decisiones: toda elección técnica queda conectada a requisitos concretos
Documentación viva: como la especificación genera el código, es más fácil mantener la sincronización
Iteración rápida: ante cambios de requisitos, la regeneración del plan permite responder en minutos u horas
Template-Driven Quality
Evita la intrusión prematura de detalles de implementación: al enfocarse en WHAT/WHY y excluir HOW, induce a mantener el nivel de abstracción
Obliga a marcar incertidumbre: el marcador [NEEDS CLARIFICATION] impulsa no adivinar y formular preguntas explícitas
Autorrevisión basada en checklist: implementa una compuerta de calidad verificando completitud, claridad y criterios de aceptación medibles
Constitution gate: aplica checks de etapa previa (-1) como compuerta de simplicidad (≤3 proyectos), compuerta antiabstracción (uso directo del framework) y compuerta de integración primero (contratos y pruebas de contrato antes de implementar)
Gestión de detalle por capas: separa código o detalles excesivos en implementation-details/ para mantener legibilidad
Prioridad de testing: asegura verificabilidad con la regla de crear archivos y tests primero en el orden contrato → integración → E2E → unitario
Contención de supuestos y funciones especulativas: refuerza el control de alcance prohibiendo funcionalidades especulativas y explicitando precondiciones por etapa
The Constitutional Foundation
Adopta una constitución de desarrollo en memory/constitution.md con principios inmutables para mantener todas las implementaciones consistentes, simples y de alta calidad
Article I: Library-First — toda funcionalidad empieza como librería independiente para asegurar modularidad
Article II: CLI Mandate — toda librería expone una interfaz CLI con soporte para entrada/salida de texto y JSON, garantizando observabilidad y facilidad de prueba
Article III: Test-First — prohibido implementar antes de aprobar tests y confirmar fallo (red), bajo el principio de definir primero el comportamiento
Articles VII & VIII: simplicidad y antiabstracción — minimizar la cantidad de proyectos y confiar directamente en el framework para evitar sobreingeniería
Article IX: pruebas de integración primero — prioriza tests cercanos al entorno real y obliga a implementar pruebas de contrato antes de la implementación
Con la Phase -1 gate del template, el cumplimiento constitucional se vuelve una checklist, y las excepciones registran su justificación explícita en Complexity Tracking
Mediante el procedimiento de enmienda, la forma de aplicar los principios puede evolucionar, pero la filosofía central se mantiene
The Transformation
El objetivo no es reemplazar desarrolladores, sino potenciar la capacidad humana y mantener la alineación entre intención e implementación automatizando la traducción mecánica
SDD pone a la especificación a generar código, haciendo que especificación, investigación y código coevolucionen en un feedback loop cerrado como una transformación continua
Y también nos preguntaron sobre el tema relacionado con el experimento sobre la cantidad de iteraciones encadenadas del prompt.
La verdad es que, visto al revés, este es un elemento muy bueno para que el autor, dicho coloquialmente, haga trampa.
El acto mismo de desarrollar tiene muchísimas opciones posibles en la dirección que toma el proceso, y si se van acumulando prompts hacia una dirección en la que el uso de tokens se amplía más, esa cifra terminará creciendo todavía más como una bola de nieve.
En la investigación existe una filosofía llamada "Cumulative Science".
Al menos según mi criterio, todavía no he encontrado ni una sola vez una investigación sobre el uso de tokens para una sola instrucción,
por eso, en lugar de hacer de inmediato una investigación de N veces, me concentré en tratar una prueba y una conclusión claras sobre una sola vez,
y si la investigación continúa a partir de este experimento, entonces podrá seguirse con un estudio de N veces.
Explicado brevemente, trata sobre pruebas y resultados que muestran que la calidad del resultado cambia según el codebase que se le entrega a la IA.
Esto significa que, según la calidad y la dirección del codebase inicial, la calidad del código posterior puede mantenerse o seguir empeorando.
Es decir, el costo de refactorización en la etapa inicial de un proyecto y el costo de refactorización cuando el proyecto ya está bastante avanzado pueden ser muy distintos.
Si quien pregunta es desarrollador, quizá haya escuchado alguna vez la expresión “un portaaviones sobre un velero”.
La refactorización es un tema profundo, porque el momento en que debe realizarse, o la filosofía y el diseño que se aplican al inicio del proyecto, pueden hacer que el costo cambie de forma enorme.
En lugar de llevar la conclusión hacia algo inestable incluyendo eso como variable,
lo que hice fue realizar una prueba que al menos permite explicar con claridad que, “ah, si la calidad del codebase es buena, el uso de tokens se reduce”.
Quienes practican vibe coding abarcan desde personas no desarrolladoras hasta desarrolladores con experiencia. Según el nivel de conocimiento que tengan, la calidad del resultado puede variar enormemente, sin importar por completo el contenido de este texto.
A algunas personas, de forma natural, al usar cursor con .cursorrules como base, incluyendo reglas básicas de OOP y criterios para separar clases/métodos, puede funcionarles de una manera que casi no requiera refactorización;
pero en otras puede estar ocurriendo una producción de código de bajo nivel por una ausencia de comprensión incluso de los puntos principales más básicos.
Incluso ya existen muchos ejemplos previos de artículos y experiencias que recomiendan mantener una buena calidad de código mediante la configuración de reglas del proyecto.
Esto sugiere la posibilidad de que algunas personas ya estén obteniendo beneficios en términos de uso de tokens incluso sin una refactorización explícita.
Sin embargo, los casos anteriores no organizan una reducción clara del uso de tokens por unidad de ejecución a través de la definición de esas reglas. Por eso, en este texto se probó la diferencia en el uso de tokens según la calidad de la base de código y se resumieron los resultados.
Es decir, según la persona usuaria, la cantidad de refactorizaciones explícitas vuelve a convertirse por sí misma en una variable de 0 a n veces,
Y creo que sería bueno entender que la intención esencial de este texto es explicar: "¿por qué vale la pena preocuparse por una base de código de buena calidad?"
No termino de entender bien a qué se refiere en su comentario. Mi comentario era que, para comparar ambos métodos de manera justa, ¿no habría que comparar la cantidad total de tokens consumidos? ¿El refactoring también no consume tokens?
Además, lo que respondió no parece estar escrito en el artículo ni haber sido probado en el experimento. Da la impresión de que no está hablando de una comparación de tokens por consulta, sino de que, al hacer varias consultas, la sobrecarga del refactoring se diluye y, como se reduce la cantidad esperada de tokens por consulta, al final habría una ganancia en el total de tokens. Pero eso parecería válido solo si, al hacer varias consultas, la reducción de costos se mantuviera tal como usted piensa, y me parece que eso supone una situación muy ideal. No se puede garantizar que la reducción de costos por refactoring se mantenga independientemente de cuántas consultas vengan después, ni asumirlo sin hacer experimentos. Si quiere defender esa idea, bastaría con mostrar experimentalmente una reducción de costos en más de una consulta. Pero, ¿no hizo el experimento y la comparación solo una vez?
Además, esto es solo una suposición mía, pero si para un mismo objetivo (una salida final ideal) se repitieran infinitamente las consultas, en una situación ideal el código debería converger hacia la misma forma tanto con refactoring como sin él. (La salida final ideal sería única.)
Si esa es una suposición razonable, entonces, a medida que se repiten las consultas, la diferencia entre hacer o no refactoring se iría reduciendo, por lo que la ganancia de reducción de costo en tokens también parecería bajar gradualmente. Entonces, visto de manera más amplia, si esa ventaja de reducción de costos no se mantiene el tiempo suficiente, ¿no podría ocurrir que la diferencia en la cantidad total de tokens usados en las consultas no fuera significativa?
De repente me da la impresión de que con el coreano sí sería posible hacerlo así... al menos se podrían hacer rompecabezas...
Lo usaré bien solo para fines de screening.
En el caso de las órdenes de compraventa, parece que por problemas como la inyección de prompts podrían procesarse órdenes no intencionadas, así que funciones adicionales como limitar el activo objetivo o el monto de la orden parecen indispensables.
Lo siento;;
Me recuerda a Kiro IDE
Gracias.
Sí, yo también pienso lo mismo. T_T
El experimento estuvo muy entretenido; lo disfruté bastante.
Parece que tomaste clases para hacer títulos...
La sensación de que las redes sociales hacen perder el tiempo se parece más a la de las apuestas o las drogas: deja una sensación de "arrepentimiento" o "vergüenza".
Está interesante. Y también tiene sentido.
Independientemente del contenido, creo que se siente más así porque, por el título de «una sola línea de prompt», lo que uno espera ver y el contenido del texto terminan siendo distintos.
k9s - herramienta para administrar clústeres de Kubernetes con una interfaz de usuario de terminal
El enlace de presentación detallada de SDD en medio del texto está muy bueno. Abajo va un resumen hecho con IA.
Desarrollo guiado por especificaciones (Specification-Driven Development, SDD)
The Power Inversion
The SDD Workflow in Practice
Why SDD Matters Now
Core Principles
Implementation Approaches
Streamlining SDD with Commands
/specify: convierte la descripción de una funcionalidad en una especificación estructurada y automatiza numeración automática, creación de branch y estructura de directorios basada en templates/plan: analiza la especificación → revisa cumplimiento de la constitución → hace la traducción técnica → documenta modelo de datos, contrato de API y escenarios de prueba → genera validación quickstart/tasks: leeplan.mdy diseños relacionados para producir una lista de tareas ejecutables, además de marcar tareas paralelizables y agrupar paralelismo seguroThe Power of Structured Automation
Template-Driven Quality
[NEEDS CLARIFICATION]impulsa no adivinar y formular preguntas explícitasimplementation-details/para mantener legibilidadThe Constitutional Foundation
memory/constitution.mdcon principios inmutables para mantener todas las implementaciones consistentes, simples y de alta calidadThe Transformation
¡Se filtró el código fuente del Gran Hermano!
Y también nos preguntaron sobre el tema relacionado con el experimento sobre la cantidad de iteraciones encadenadas del prompt.
La verdad es que, visto al revés, este es un elemento muy bueno para que el autor, dicho coloquialmente, haga trampa.
El acto mismo de desarrollar tiene muchísimas opciones posibles en la dirección que toma el proceso, y si se van acumulando prompts hacia una dirección en la que el uso de tokens se amplía más, esa cifra terminará creciendo todavía más como una bola de nieve.
En la investigación existe una filosofía llamada "Cumulative Science".
Al menos según mi criterio, todavía no he encontrado ni una sola vez una investigación sobre el uso de tokens para una sola instrucción,
por eso, en lugar de hacer de inmediato una investigación de N veces, me concentré en tratar una prueba y una conclusión claras sobre una sola vez,
y si la investigación continúa a partir de este experimento, entonces podrá seguirse con un estudio de N veces.
Si estudias algo como ingeniería civil, ya se usa incluso en las clases de la universidad.
Además, en otro texto, ya había abordado las diferencias en el comportamiento de la IA según las diferencias del codebase.
(También fue presentado aquí en GeekNews: https://modgo.org/aineun-hyeonjae-kodeu-gujoyi-byeoge-maghyeoissda/)
Explicado brevemente, trata sobre pruebas y resultados que muestran que la calidad del resultado cambia según el codebase que se le entrega a la IA.
Esto significa que, según la calidad y la dirección del codebase inicial, la calidad del código posterior puede mantenerse o seguir empeorando.
Es decir, el costo de refactorización en la etapa inicial de un proyecto y el costo de refactorización cuando el proyecto ya está bastante avanzado pueden ser muy distintos.
Si quien pregunta es desarrollador, quizá haya escuchado alguna vez la expresión “un portaaviones sobre un velero”.
La refactorización es un tema profundo, porque el momento en que debe realizarse, o la filosofía y el diseño que se aplican al inicio del proyecto, pueden hacer que el costo cambie de forma enorme.
En lugar de llevar la conclusión hacia algo inestable incluyendo eso como variable,
lo que hice fue realizar una prueba que al menos permite explicar con claridad que, “ah, si la calidad del codebase es buena, el uso de tokens se reduce”.
Permítanme explicarlo de nuevo.
Quienes practican vibe coding abarcan desde personas no desarrolladoras hasta desarrolladores con experiencia. Según el nivel de conocimiento que tengan, la calidad del resultado puede variar enormemente, sin importar por completo el contenido de este texto.
A algunas personas, de forma natural, al usar cursor con
.cursorrulescomo base, incluyendo reglas básicas de OOP y criterios para separar clases/métodos, puede funcionarles de una manera que casi no requiera refactorización;pero en otras puede estar ocurriendo una producción de código de bajo nivel por una ausencia de comprensión incluso de los puntos principales más básicos.
Incluso ya existen muchos ejemplos previos de artículos y experiencias que recomiendan mantener una buena calidad de código mediante la configuración de reglas del proyecto.
Esto sugiere la posibilidad de que algunas personas ya estén obteniendo beneficios en términos de uso de tokens incluso sin una refactorización explícita.
Sin embargo, los casos anteriores no organizan una reducción clara del uso de tokens por unidad de ejecución a través de la definición de esas reglas. Por eso, en este texto se probó la diferencia en el uso de tokens según la calidad de la base de código y se resumieron los resultados.
Es decir, según la persona usuaria, la cantidad de refactorizaciones explícitas vuelve a convertirse por sí misma en una variable de 0 a n veces,
Y creo que sería bueno entender que la intención esencial de este texto es explicar: "¿por qué vale la pena preocuparse por una base de código de buena calidad?"
No termino de entender bien a qué se refiere en su comentario. Mi comentario era que, para comparar ambos métodos de manera justa, ¿no habría que comparar la cantidad total de tokens consumidos? ¿El refactoring también no consume tokens?
Además, lo que respondió no parece estar escrito en el artículo ni haber sido probado en el experimento. Da la impresión de que no está hablando de una comparación de tokens por consulta, sino de que, al hacer varias consultas, la sobrecarga del refactoring se diluye y, como se reduce la cantidad esperada de tokens por consulta, al final habría una ganancia en el total de tokens. Pero eso parecería válido solo si, al hacer varias consultas, la reducción de costos se mantuviera tal como usted piensa, y me parece que eso supone una situación muy ideal. No se puede garantizar que la reducción de costos por refactoring se mantenga independientemente de cuántas consultas vengan después, ni asumirlo sin hacer experimentos. Si quiere defender esa idea, bastaría con mostrar experimentalmente una reducción de costos en más de una consulta. Pero, ¿no hizo el experimento y la comparación solo una vez?
Además, esto es solo una suposición mía, pero si para un mismo objetivo (una salida final ideal) se repitieran infinitamente las consultas, en una situación ideal el código debería converger hacia la misma forma tanto con refactoring como sin él. (La salida final ideal sería única.) Si esa es una suposición razonable, entonces, a medida que se repiten las consultas, la diferencia entre hacer o no refactoring se iría reduciendo, por lo que la ganancia de reducción de costo en tokens también parecería bajar gradualmente. Entonces, visto de manera más amplia, si esa ventaja de reducción de costos no se mantiene el tiempo suficiente, ¿no podría ocurrir que la diferencia en la cantidad total de tokens usados en las consultas no fuera significativa?