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?
Como este texto tiene un carácter más cercano a una investigación de "experimento",
todas las cifras incluidas aquí están enfocadas en permitir que cualquier persona que lea este texto pueda "reproducir" los resultados.
Por ello, se registraron tanto el código fuente original utilizado como todos los procedimientos empleados en las pruebas,
para proporcionar información que permita que todos los experimentadores obtengan los mismos resultados.
Por la impresión que me da el tono de los comentarios,
me hace pensar que de ahora en adelante quizá debería separar en dos textos: uno con un resumen de 3 líneas,
y otro para quienes quieran conocer los detalles.
Si me dicen qué parte de este texto les pareció excesivamente compleja o demasiado extensa,
creo que me sería de gran ayuda para escribir los próximos textos.
Estoy completamente de acuerdo. Este tipo de crítica es más que bienvenida.
Nadie vive solo en el mundo, y las capacidades o circunstancias de cada persona son diferentes.
Yo también no soy más que un desarrollador, y no puedo realizar todas las pruebas por mi cuenta asumiendo el costo personalmente.
Espero que este texto sirva como semilla, tenga una buena influencia en muchas personas y se convierta en el punto de partida de muchas investigaciones posteriores.
Hay necesidad de comparar el código fuente antes y después del preprocesamiento.
El subtítulo no coincide del todo con el contenido. Si se reorganiza, parece más adecuado algo como: "se necesita un análisis más claro de los factores que provocan la reducción de tokens".
Hay muchas partes de este contenido con las que estoy de acuerdo. Sin embargo, la naturaleza de este texto también incluye el elemento de "proponer formas realistas de aplicación para quienes lean este artículo".
De hecho, incluso viendo solo los comentarios de esta publicación se puede percibir el ambiente; yo también lo supe hace poco, pero se estima que entre los usuarios de IA hay muchas personas no desarrolladoras que hacen vibe coding.
Si el autor termina logrando grandes resultados a partir de código ajustado directamente por él mismo, sin pasar por la IA,
es fácil que eso se vea como una forma de presumir habilidades de desarrollo y de menospreciar las capacidades de la IA.
Por eso, se terminó abordando un ejemplo cuyo resultado cualquiera pueda percibir, usando el elemento del "prompt", que puede ser aprovechado por quienes hacen vibe coding.
Espero que, a partir de esta investigación, continúen estudios que permitan desglosar con más detalle los factores que influyen en el uso de tokens de IA.
El vibe coding no produce un resultado final completo con un solo prompt.
Si mediante una sola modificación estructural se logra reducir la tasa de consumo de tokens de n prompts, la cantidad reducida de tokens se refleja a lo largo de esas mismas n ejecuciones.
n es una cifra determinada por el objetivo del proyecto, la cantidad de funciones, así como la cantidad y complejidad del código necesario para ello,
y además, como recientemente los agentes de cursor / claude code han recibido actualizaciones que dividen el trabajo en unidades más pequeñas para resolver problemas como los bucles infinitos o el uso indiscriminado de tokens por parte de la IA,
considero que el estudio del valor de n en relación con la complejidad del proyecto debe hacerse por separado.
Para facilitar al máximo la comprensión, utilicé como ejemplo una mejora de código a partir de código con problemas estructurales generado por la IA cuando no hay instrucciones adicionales.
Lo que no debe pasarse por alto aquí es que la mejora de la estructura no es en absoluto una acción que ocurra de manera independiente del desarrollo del código.
Es algo que puede influir como contexto base mediante el prompt inicial o restricciones como el ruleset de IA (.cursorrules),
y una sola mejora estructural durante el ciclo de desarrollo del proyecto no puede resolverlo todo.
Es decir, en lugar de planificar mejoras de código en intervalos regulares, una mejor dirección es guiar correctamente la estructura como contexto base.
Además, parece correcto que el estudio sobre los casos con y sin reglas de instrucciones para orientar la estructura como contexto base se realice por separado.
En resumen sobre el punto 1,
cuando existen reglas de instrucciones para orientar la estructura como contexto base, existe la posibilidad de que disminuya el uso total de tokens, y
dado que existe la variable de obtener el resultado final mediante n instrucciones de prompt,
la afirmación de que debe sumarse y calcularse el uso de tokens de una sola instrucción de prompt para mejora estructural resulta imprecisa.
Yo también lo sentí de forma parecida.
Entiendo cuál era la intención de quien escribió el post, pero creo que, para lo que hizo, el texto quedó excesivamente complejo.
Parece que lo redactó así porque quiso incorporar al máximo en el texto los detalles usados en el experimento,
pero creo que, si resumiera brevemente solo lo esencial, quienes estén interesados en este tema probablemente igual lo entenderían.
Me parece que sería mejor si recortara sin miedo los detalles y dejara solo los puntos clave.
A mí la intención del autor y el resultado en sí me parecieron interesantes.
La idea principal parece ser que un mejor código fuente lleva a un menor consumo de tokens,
y que en torno a eso diseñó y llevó a cabo el experimento.
Si enumero solo lo que entendí del experimento:
Preparar dos versiones: el código fuente que se le iba a dar a la IA y ese mismo código fuente preprocesado con un prompt (?)
Ejecutar ambos códigos fuente 5 veces cada uno en GPT-5 y Sonnet, y comparar el consumo de tokens
Eso es lo que me parece.
Y si entendí bien, la conclusión sería que el código fuente preprocesado con prompt tiende, en general, a consumir menos tokens.
Es una conclusión interesante, pero mi opinión sobre el experimento es la siguiente.
No es una comparación justa
En números parece que bajó, pero creo que lo correcto sería comparar la cantidad total de tokens usada para procesar el código fuente.
Es decir, también debería considerarse la cantidad de tokens usada para el preprocesamiento.
Si la cantidad de tokens usada para preprocesar fue excesivamente grande, en la práctica se habrían consumido más tokens y el resultado perdería sentido; e incluso si fue pequeña, la diferencia real de consumo probablemente sería bastante menor de lo que sugiere el texto.
Hace falta comparar el código fuente antes y después del preprocesamiento
Si se excluyen los tokens usados en el preprocesamiento, parece que el consumo de tokens durante la consulta sí se redujo de forma significativa.
Sin embargo, si se analizara qué diferencia exacta en el código fuente provoca esa variación, el texto tendría mucho más valor.
Porque eso significaría que se podría optimizar el prompt de preprocesamiento para maximizar esa diferencia.
El autor dice que la refactorización de la estructura del código produjo este resultado, pero yo no estoy de acuerdo; creo que todavía no se puede saber.
También podría haber una reducción en el consumo de tokens si se hicieran mejoras en otras partes distintas de la refactorización.
Hace falta experimentar más y con mayor variedad
Creo que habría que repetir el mismo experimento no solo con el código actual, sino también con otras bases de código.
Porque hay que determinar si esto da buenos resultados de forma consistente o no.
De todos modos, entiendo que en la práctica esto puede ser difícil de probar, así que creo que conviene tomarlo solo como referencia.
Comparto además un resumen del contenido relacionado con el prompt utilizado.
Por lo visto, esto resulta especialmente útil para que los desarrolladores redacten prompts orientados a mejorar la estructura. Como cada programa tiene características distintas, para lograr mejoras altamente eficientes se necesita cierto nivel de conocimiento de desarrollo.
Eso no significa que los vibe coders no desarrolladores no puedan usar este método. Aunque pueda haber diferencias de eficiencia, incluso con instrucciones simples como "Por favor, ordena un poco el código del proyecto. Elimina el código que no se usa.", la IA también separa y organiza archivos y clases.
Eso sí, como las diferencias en el nivel de detalle de la mejora estructural pueden generar diferencias en la eficiencia, es importante tener cuidado al consultar el material de referencia.
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?
Como este texto tiene un carácter más cercano a una investigación de "experimento",
todas las cifras incluidas aquí están enfocadas en permitir que cualquier persona que lea este texto pueda "reproducir" los resultados.
Por ello, se registraron tanto el código fuente original utilizado como todos los procedimientos empleados en las pruebas,
para proporcionar información que permita que todos los experimentadores obtengan los mismos resultados.
Por la impresión que me da el tono de los comentarios,
me hace pensar que de ahora en adelante quizá debería separar en dos textos: uno con un resumen de 3 líneas,
y otro para quienes quieran conocer los detalles.
Si me dicen qué parte de este texto les pareció excesivamente compleja o demasiado extensa,
creo que me sería de gran ayuda para escribir los próximos textos.
Estoy completamente de acuerdo. Este tipo de crítica es más que bienvenida.
Nadie vive solo en el mundo, y las capacidades o circunstancias de cada persona son diferentes.
Yo también no soy más que un desarrollador, y no puedo realizar todas las pruebas por mi cuenta asumiendo el costo personalmente.
Espero que este texto sirva como semilla, tenga una buena influencia en muchas personas y se convierta en el punto de partida de muchas investigaciones posteriores.
El subtítulo no coincide del todo con el contenido. Si se reorganiza, parece más adecuado algo como: "se necesita un análisis más claro de los factores que provocan la reducción de tokens".
Hay muchas partes de este contenido con las que estoy de acuerdo. Sin embargo, la naturaleza de este texto también incluye el elemento de "proponer formas realistas de aplicación para quienes lean este artículo".
De hecho, incluso viendo solo los comentarios de esta publicación se puede percibir el ambiente; yo también lo supe hace poco, pero se estima que entre los usuarios de IA hay muchas personas no desarrolladoras que hacen vibe coding.
Si el autor termina logrando grandes resultados a partir de código ajustado directamente por él mismo, sin pasar por la IA,
es fácil que eso se vea como una forma de presumir habilidades de desarrollo y de menospreciar las capacidades de la IA.
Por eso, se terminó abordando un ejemplo cuyo resultado cualquiera pueda percibir, usando el elemento del "prompt", que puede ser aprovechado por quienes hacen vibe coding.
Espero que, a partir de esta investigación, continúen estudios que permitan desglosar con más detalle los factores que influyen en el uso de tokens de IA.
Si mediante una sola modificación estructural se logra reducir la tasa de consumo de tokens de n prompts, la cantidad reducida de tokens se refleja a lo largo de esas mismas n ejecuciones.
n es una cifra determinada por el objetivo del proyecto, la cantidad de funciones, así como la cantidad y complejidad del código necesario para ello,
y además, como recientemente los agentes de cursor / claude code han recibido actualizaciones que dividen el trabajo en unidades más pequeñas para resolver problemas como los bucles infinitos o el uso indiscriminado de tokens por parte de la IA,
considero que el estudio del valor de n en relación con la complejidad del proyecto debe hacerse por separado.
Lo que no debe pasarse por alto aquí es que la mejora de la estructura no es en absoluto una acción que ocurra de manera independiente del desarrollo del código.
Es algo que puede influir como contexto base mediante el prompt inicial o restricciones como el ruleset de IA (.cursorrules),
y una sola mejora estructural durante el ciclo de desarrollo del proyecto no puede resolverlo todo.
Es decir, en lugar de planificar mejoras de código en intervalos regulares, una mejor dirección es guiar correctamente la estructura como contexto base.
Además, parece correcto que el estudio sobre los casos con y sin reglas de instrucciones para orientar la estructura como contexto base se realice por separado.
En resumen sobre el punto 1,
la afirmación de que debe sumarse y calcularse el uso de tokens de una sola instrucción de prompt para mejora estructural resulta imprecisa.
Yo también lo sentí de forma parecida.
Entiendo cuál era la intención de quien escribió el post, pero creo que, para lo que hizo, el texto quedó excesivamente complejo.
Parece que lo redactó así porque quiso incorporar al máximo en el texto los detalles usados en el experimento,
pero creo que, si resumiera brevemente solo lo esencial, quienes estén interesados en este tema probablemente igual lo entenderían.
Me parece que sería mejor si recortara sin miedo los detalles y dejara solo los puntos clave.
A mí la intención del autor y el resultado en sí me parecieron interesantes.
La idea principal parece ser que un mejor código fuente lleva a un menor consumo de tokens,
y que en torno a eso diseñó y llevó a cabo el experimento.
Si enumero solo lo que entendí del experimento:
Eso es lo que me parece.
Y si entendí bien, la conclusión sería que el código fuente preprocesado con prompt tiende, en general, a consumir menos tokens.
Es una conclusión interesante, pero mi opinión sobre el experimento es la siguiente.
No es una comparación justa
En números parece que bajó, pero creo que lo correcto sería comparar la cantidad total de tokens usada para procesar el código fuente.
Es decir, también debería considerarse la cantidad de tokens usada para el preprocesamiento.
Si la cantidad de tokens usada para preprocesar fue excesivamente grande, en la práctica se habrían consumido más tokens y el resultado perdería sentido; e incluso si fue pequeña, la diferencia real de consumo probablemente sería bastante menor de lo que sugiere el texto.
Hace falta comparar el código fuente antes y después del preprocesamiento
Si se excluyen los tokens usados en el preprocesamiento, parece que el consumo de tokens durante la consulta sí se redujo de forma significativa.
Sin embargo, si se analizara qué diferencia exacta en el código fuente provoca esa variación, el texto tendría mucho más valor.
Porque eso significaría que se podría optimizar el prompt de preprocesamiento para maximizar esa diferencia.
El autor dice que la refactorización de la estructura del código produjo este resultado, pero yo no estoy de acuerdo; creo que todavía no se puede saber.
También podría haber una reducción en el consumo de tokens si se hicieran mejoras en otras partes distintas de la refactorización.
Hace falta experimentar más y con mayor variedad
Creo que habría que repetir el mismo experimento no solo con el código actual, sino también con otras bases de código.
Porque hay que determinar si esto da buenos resultados de forma consistente o no.
De todos modos, entiendo que en la práctica esto puede ser difícil de probar, así que creo que conviene tomarlo solo como referencia.
Parece que regalar cosas inútiles está de moda... podría estar bueno para descubrir nuevos regalos inútiles.
Comparto además un resumen del contenido relacionado con el prompt utilizado.
Por lo visto, esto resulta especialmente útil para que los desarrolladores redacten prompts orientados a mejorar la estructura. Como cada programa tiene características distintas, para lograr mejoras altamente eficientes se necesita cierto nivel de conocimiento de desarrollo.
Eso no significa que los vibe coders no desarrolladores no puedan usar este método. Aunque pueda haber diferencias de eficiencia, incluso con instrucciones simples como "Por favor, ordena un poco el código del proyecto. Elimina el código que no se usa.", la IA también separa y organiza archivos y clases.
Eso sí, como las diferencias en el nivel de detalle de la mejora estructural pueden generar diferencias en la eficiencia, es importante tener cuidado al consultar el material de referencia.
Es una buena opción si necesitas trabajar con información geoespacial.