Resumen
- Reporte de un experimento (Zero-context, N=5) en el que, tras refactorizar la estructura del código (patrón estrategia y factory, separación de archivos, organización de
.cursorrules) con un prompt de una sola línea, se ejecutó el mismo prompt de agregado de funcionalidad y se observó una gran reducción en el uso de tokens de la IA. Los prompts y el código fuente usados en el experimento están publicados, por lo que es reproducible.
Datos clave
-
Claude-4 Sonnet: promedio de 390,159 → 242,265 tokens (−37.91%)
-
GPT-5: promedio de 315,839 → 233,634 tokens (−26.03%)
-
Referencia: Total Tokens mostrado por Cursor. Comparar valores absolutos entre modelos no tiene sentido (hay diferencias en cómo cada modelo los contabiliza).
Configuración (resumen)
-
IDE Cursor 1.6.6, modelos GPT-5 / Claude-4 Sonnet
-
Todos los prompts en Zero-context, reiniciando por completo el editor en cada ronda
-
Criterio de éxito: se contabilizó como exitoso si el requisito se implementaba con un solo prompt
Por qué importa
-
Una “buena estructura de código” no solo facilita la lectura para las personas, también impacta en los tokens, el costo y el tiempo de la IA
-
La publicación de los prompts y el repositorio asegura reproducibilidad (se puede aplicar de inmediato en trabajo real y en experimentos posteriores)
Opinión personal
- Como usuario de Cursor, propone una metodología excelente que ofrece una forma clave de ahorrar costos.
- Como también se menciona en el texto, resulta un poco decepcionante que el muestreo no sea suficiente.
34 comentarios
Parece que tomaste clases para hacer títulos...
El experimento estuvo muy entretenido; lo disfruté bastante.
Gracias.
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.
Sí, yo también pienso lo mismo. T_T
Lo siento;;
Gracias por el gran interés en este artículo. Como el objetivo principal era su difusión en el extranjero, el texto se escribió en inglés, pero parece que eso ha generado diversos problemas.
Por ello, comparto una publicación resumida en coreano.
https://modgo.org/tokeun-sayongryang-37-91-reul-gamsosikin-dan-hanjuly…
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.
Hay que poner en el prompt solo lo esencial y de forma lógica. O sea, ¿mientras más cosas le agregas al prompt, más ruido introduces y por eso el código resultante también se vuelve más complejo y con más ruido?
El punto clave es que, después de indicarle a la IA que refactorice la estructura del código, se redujo la cantidad de tokens consumidos.
En sentido contrario, también podría explicarse que, si se siguen dando instrucciones cuando el código tiene defectos estructurales, el uso de tokens aumenta.
En resumen, la idea es que debe producirse una mejora en la estructura del código, y no significa que el prompt deba contener solo lo esencial de forma lógica.
A mí también me costó leerlo porque tanto esta introducción como el texto original se sienten demasiado largos y como si los hubiera escrito alguien a quien no se le da bien redactar,
pero la idea principal
sería algo como
"agrega una instrucción de una sola línea que incluya restricciones estructurales para reducir los tokens"
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.
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.
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.
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?
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.
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?"
Soy el autor. Gracias por sus comentarios. Los tendré en cuenta al escribir el próximo artículo.
¿Significa que al incluir también este prompt se redujo el costo? No estoy muy seguro de si entendí bien el punto principal.
Como comentario adicional, la estructura del código debe mejorarse con un modelo adecuado para ese proyecto. Como se menciona en la respuesta de abajo, si le consultas a la IA sobre cómo mejorar la estructura, te indicará un método apropiado de reorganización acorde al proyecto.
Mi recomendación personal es no darle a la IA una orden directa de reestructuración desde el inicio; mejor pídele primero que haga propuestas. Te dará una respuesta y, conforme avances en la conversación, podrás llegar a una propuesta lo suficientemente eficiente antes de pedirle que la aplique.
Un tip adicional es que, en lo posible, conviene completar el trabajo antes de que ocurra la summarization del contexto (reinicio del búfer de contexto). Si reiniciar el búfer de contexto es inevitable, es mejor pedir de antemano que agregue reglas de mejora a
.cursorrules. Si el contexto se reinicia durante el trabajo, aumenta la probabilidad de que la IA cometa errores.Como referencia, es un hecho obvio y bien conocido que, cuanto más pequeño sea el tamaño del código fuente de entrada, menor será la cantidad de tokens consumidos. Para eso se creó el archivo
.cursorignore.En general, cuando se le pide a una IA que mejore la estructura, en la gran mayoría de los casos el volumen del código fuente tiende a reducirse, así que parece una afirmación creíble decir que, por cualquier motivo que se le haga ordenar o limpiar, los costos bajan.
Este artículo agrega la afirmación de que, mediante una buena guía de estructura, se puede lograr una reducción adicional en el uso de tokens.
Es cierto. Como también se menciona en el artículo, después de mejorar el código, efectivamente se redujo el tamaño del código del proyecto.
Sin embargo, en este ejemplo hubo una reducción de alrededor del 10% según la cantidad de caracteres, y solo con eso no se puede explicar una disminución del 37.91% en el uso de tokens.
En el artículo está el enlace al repositorio del código fuente, y cualquiera puede reproducirlo y probarlo.
Yo no he hecho esta prueba personalmente,
pero creo que un prompt como:
"Analiza el código actual y mejora la estructura para que te resulte más fácil de gestionar"
también podría funcionar.
En esencia, creo que esto significa que, en lugar de transmitirle a la IA solo los requisitos funcionales, guiarla bien hacia una estructura adecuada y correcta puede ayudar a reducir costos.
https://modgo.org/dib-rag-gaelreogtig-modeu-seuteurimeoreul-wihan-ciji…
¿Hiciste tú mismo este modo de Deep Rock Galactic?
¿Esto también lo hiciste con vibe coding?
Hola. Soy el dueño del blog.
Sí, yo mismo hice el modo de DeepRAGGal, y actualmente está en servicio a través de un servidor personal. (Es necesario por la autenticación OAuth de CHZZK)
El desarrollo de ese modo incluye trabajo con Unreal Engine, pero por desgracia, hacer vibe coding en la parte de Unreal Engine es difícil.
En cambio, como el método de desarrollo del mod en sí no es difícil, si te interesa, puedes aprenderlo fácilmente a través de la guía de desarrollo del mod (https://modgo.org/dib-rag-gaelreogtig-modeu-gaebal-part-1/).
Vi que subieron el mod en otra comunidad, y de verdad sí era un texto escrito por la persona que creó ese mod.
No sabía que incluso había escrito un tutorial del modo Blueprint; gracias.
¡Desde el principio ya se notaba que era alguien muy bueno desarrollando!
Ah, ya habían visto mi modo en otra comunidad.
Los textos que he escrito tienen muchas carencias, pero me alegraría si pudieran ser de ayuda.
Ah, qué fastidio.
Si me dice qué parte le resultó molesta, le responderé amablemente.
Por favor revisa la sección sobre cómo comentar en Cómo usar el sitio.
Por favor, habla con amabilidad y cortesía.
Si tienes una objeción, escribe solo ese contenido.