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.
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.
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.
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?
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"
La API de Web Codecs en sí ya tiene muy buen rendimiento, así que todas las librerías web de medios destacan por su performance. Por eso se siente un poco ambiguo considerarlo TypeScript puro.
Vaya, ahora incluso Delphi y C++Builder van a incluir componentes de desarrollo con IA.
Delphi se siente como una especie de hogar emocional para mí, así que cada vez que salen novedades termino leyéndolas.
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.
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…
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.
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?
Una capa sobre otra
Soy el autor. Gracias por sus comentarios. Los tendré en cuenta al escribir el próximo artículo.
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"
De repente desaparecieron todos los puntos.
Conclusión
Usar IA ayuda a reducir costos
a través de mejoras en la productividad, pero
no genera dinero por sí solo.
Con algo como Node.js, cuando quieres vincularlo a otra aplicación se vuelve bastante molesto, así que ojalá fuera un poco más fácil.
La API de Web Codecs en sí ya tiene muy buen rendimiento, así que todas las librerías web de medios destacan por su performance. Por eso se siente un poco ambiguo considerarlo TypeScript puro.
Viendo el benchmark, curiosamente el rendimiento no es malo.
Vaya, ahora incluso Delphi y C++Builder van a incluir componentes de desarrollo con IA.
Delphi se siente como una especie de hogar emocional para mí, así que cada vez que salen novedades termino leyéndolas.