Resumo
- Relato de experimento (Zero-context, N=5) mostrando que, após refatorar a estrutura do código (padrões Strategy e Factory, separação de arquivos, organização do
.cursorrules) com um prompt de uma linha, e depois executar o mesmo prompt de adição de funcionalidade, o uso de tokens de IA caiu significativamente. Os prompts e o código-fonte usados no experimento foram publicados, permitindo reprodução.
Dados principais
-
Claude-4 Sonnet: média de 390.159 → 242.265 tokens (−37,91%)
-
GPT-5: média de 315.839 → 233.634 tokens (−26,03%)
-
Critério: Total Tokens exibido pelo Cursor. Comparações absolutas entre modelos não são significativas (diferenças de contabilização por modelo).
Configuração (resumo)
-
IDE Cursor 1.6.6, modelos GPT-5 / Claude-4 Sonnet
-
Todos os prompts em Zero-context, com reinicialização completa do editor a cada rodada
-
Critério de sucesso: contabilizado como sucesso quando os requisitos eram implementados com um único prompt
Por que isso importa
-
“Boa estrutura de código” não só melhora a leitura para humanos, como também afeta tokens, custo e tempo para a IA, com evidência quantitativa
-
A divulgação dos prompts e do repositório garante reprodutibilidade (podendo ser aplicada diretamente no trabalho e em experimentos futuros)
Opinião pessoal
- Como usuário do Cursor, considero que isso propõe uma excelente metodologia, oferecendo uma abordagem essencial para economizar custos.
- Como o próprio texto menciona, a amostragem limitada é um ponto um pouco decepcionante.
34 comentários
Você fez curso de criar títulos, né..
Gostei bastante do experimento; foi muito interessante de acompanhar.
Obrigado.
Independentemente do conteúdo, acho que isso se deve ainda mais ao fato de que, por causa do título dizendo que é uma única linha de prompt, o que eu esperava ver e o conteúdo do texto eram diferentes.
Sim, eu também penso o mesmo. buá
Desculpe;;
Agradeço muito pelo interesse neste texto. Como o objetivo principal era a divulgação no exterior, o texto acabou sendo escrito em inglês, e isso parece ter causado vários tipos de problemas.
Por isso, compartilho um post organizado em coreano.
https://modgo.org/tokeun-sayongryang-37-91-reul-gamsosikin-dan-hanjuly…
Vou complementar com um resumo do conteúdo relacionado ao prompt usado adicionalmente.
De qualquer forma, isso tende a ser mais vantajoso para desenvolvedores na hora de escrever prompts voltados à melhoria estrutural. Como cada programa tem características diferentes, para obter melhorias eficientes é necessário ter algum nível de conhecimento em desenvolvimento.
Isso não significa, porém, que vibecoders não desenvolvedores não possam usar esse método. Pode haver diferença de eficiência, mas mesmo com comandos simples como "Dá uma organizada no código do projeto. Remove os códigos que não estão sendo usados.", a IA também separa e organiza arquivos e classes.
No entanto, como diferenças nos detalhes da melhoria estrutural podem gerar diferenças de eficiência, é preciso ter cuidado ao consultar os materiais.
É preciso colocar no prompt apenas o essencial, de forma lógica. Ou seja, quanto mais coisas você acrescenta ao prompt, mais ruído ele gera, e o código produzido como resultado também fica mais complexo e com mais ruído — é isso?
O ponto principal é que, após instruir a IA a refatorar a estrutura do código, a quantidade de tokens consumidos diminuiu.
Por outro lado, também dá para explicar que, se os comandos continuarem sendo dados enquanto o código estiver com defeitos estruturais, o uso de tokens aumenta.
Resumindo, a mensagem é que a estrutura do código-fonte precisa ser melhorada, e não que o prompt deva conter apenas o essencial de forma lógica.
Eu também achei esta introdução e o texto original prolixos demais, como se tivessem sido escritos por alguém que não escreve bem, então foi difícil ler durante o processo.
O ponto principal é
"adicione uma instrução de uma linha contendo uma restrição estrutural para reduzir tokens"
mais ou menos isso.
Como este texto tem um caráter mais próximo de uma pesquisa de "experimento",
todos os números incluídos aqui foram pensados para permitir que qualquer pessoa que leia este texto consiga "reproduzir" os resultados.
Por isso, registrei integralmente o código-fonte original utilizado e todos os procedimentos usados nos testes,
fazendo com que o foco do conteúdo esteja em fornecer informações para que todos os experimentadores possam obter os mesmos resultados.
Pela atmosfera que percebo nos comentários,
estou pensando se, daqui para frente, não seria melhor separar em dois textos: um com estilo de resumo em 3 linhas e outro para quem quiser saber os detalhes.
Se vocês puderem me dizer quais partes deste texto pareceram excessivamente complexas ou prolixas,
isso provavelmente vai me ajudar bastante na redação dos próximos textos.
Eu também tive uma impressão parecida.
Entendo qual foi a intenção de quem escreveu, mas acho que o texto ficou excessivamente complexo em comparação com o que foi feito.
Parece que ele quis incorporar ao máximo no texto os detalhes usados no experimento e por isso escreveu dessa forma,
mas acho que, se resumisse apenas os pontos principais, quem se interessa por esse tipo de tema provavelmente entenderia sem dificuldade.
Acho que ficaria melhor se cortasse sem medo os detalhes e condensasse só o essencial.
Eu achei a intenção e o resultado em si interessantes.
O argumento principal parece ser que um código-fonte melhor leva a um consumo menor de tokens,
e me parece que foi feito e executado um desenho experimental relacionado a isso.
Se eu listar apenas o que entendi sobre o experimento:
Acho que é isso.
E, se entendi corretamente, a conclusão parece ser que o código-fonte pré-processado por prompt tende, em geral, a consumir menos tokens.
É uma conclusão interessante, mas minha opinião sobre o experimento é a seguinte.
Não é uma comparação justa
Pelos números, parece que houve redução, mas acho que o correto seria comparar pelo número total de tokens necessários para processar o código-fonte.
Em outras palavras, o número de tokens usado no pré-processamento também deveria ser considerado.
Se o número de tokens usado para pré-processar for excessivamente grande, na prática isso acaba consumindo ainda mais tokens e perde o sentido; mesmo que seja pequeno, a diferença real no consumo de tokens provavelmente seria bem menor do que o texto sugere.
É preciso comparar o código-fonte antes e depois do pré-processamento
Se desconsiderarmos os tokens usados no pré-processamento, o consumo de tokens durante a consulta realmente parece ter diminuído de forma significativa.
Ainda assim, se fosse analisado exatamente que diferença no código-fonte causou esse resultado, o texto ganharia muito mais valor.
Porque isso significaria que seria possível otimizar o prompt de pré-processamento para maximizar essa diferença.
O autor diz que a refatoração da estrutura do código levou a esse resultado, mas eu não concordo e acho que ainda não dá para saber.
Porque pode haver redução no consumo de tokens mesmo quando se pede para a IA melhorar outros aspectos além da refatoração.
São necessários experimentos mais variados
Acho que seria preciso rodar o mesmo experimento em outras bases de código além da atual.
Porque é preciso avaliar se isso produz resultados bons de forma consistente ou não.
Mas entendo que, na prática, isso pode ser difícil de testar, então talvez seja melhor encarar isso apenas como referência.
Concordo totalmente. Críticas desse tipo são muito bem-vindas.
Ninguém vive sozinho no mundo, e as capacidades ou circunstâncias de cada pessoa são diferentes.
Eu também sou apenas um desenvolvedor e não consigo realizar todos os testes com recursos próprios.
Espero que este texto sirva como semente, gere um impacto positivo em muitas pessoas e se torne o ponto de partida para muitas pesquisas futuras.
O subtítulo não combina muito com o conteúdo. Reorganizando, algo como "é necessária uma análise mais clara dos fatores que levam à redução de tokens" parece mais adequado como subtítulo.
Concordo com muitos pontos deste conteúdo. No entanto, a natureza deste texto também inclui o elemento de "sugerir formas realistas de aplicação para quem está lendo".
Só de ver os comentários já deixados neste texto, já dá para perceber o clima; algo que eu também descobri recentemente é que, entre os usuários de AI, estima-se que haja muitos vibecoders não desenvolvedores.
Quando se obtém um grande resultado a partir de código ajustado diretamente pelo autor, sem passar pela AI,
isso pode facilmente ser visto como o autor exibindo sua habilidade de desenvolvimento e diminuindo o valor da capacidade da AI.
Por isso, passei a tratar o resultado por meio do elemento "prompt", que outros vibecoders também podem utilizar, com exemplos que qualquer pessoa consiga perceber na prática.
Espero que, dando continuidade a esta pesquisa, surjam estudos que possam detalhar ainda mais os fatores que influenciam o uso de tokens de AI.
Se, por meio de uma única alteração estrutural, obtiver-se o efeito de reduzir a taxa de consumo de tokens de n prompts, a quantidade de tokens reduzida será refletida ao longo dessas mesmas n execuções.
né um valor determinado pelo objetivo do projeto, pelo número de funcionalidades e pela quantidade e complexidade do código necessária para isso,e também, como os agentes recentes do Cursor / Claude Code vêm recebendo atualizações que reduzem a unidade de execução para resolver problemas de repetição infinita ou uso indiscriminado de tokens pela IA,
considero correto que o estudo sobre o valor de
nem relação à complexidade do projeto seja conduzido separadamente.O ponto que não deve ser ignorado aqui é que a melhoria da estrutura nunca é algo que acontece de forma absolutamente independente do desenvolvimento do código.
É algo que pode influenciar como contexto base por meio do prompt inicial ou de restrições como um ruleset de IA (
.cursorrules),e, no meio do ciclo de desenvolvimento do projeto, uma única melhoria estrutural não pode resolver tudo.
Ou seja, em vez de planejar melhorias de código em intervalos regulares, a direção mais adequada é induzir a estrutura correta como contexto base.
Além disso, parece correto que o estudo sobre a diferença entre existir ou não uma regra de instrução para indução estrutural como contexto base seja conduzido separadamente.
Resumindo o item 1,
a alegação de que o uso de tokens de um único prompt de melhoria estrutural deve ser somado ao cálculo é problemática.
Não entendi muito bem o que você quis dizer no comentário. O meu ponto era que, para comparar os dois métodos de forma justa, não deveríamos comparar o número total de tokens consumidos? Refatoração também não consome tokens?
Além disso, o que você respondeu nem está escrito no texto e também me parece não ter sido testado no experimento. Pelo que entendi, você quer dizer que, em vez de comparar os tokens por consulta única, ao fazer várias consultas o overhead da refatoração diminui e, como o número esperado de tokens por consulta cai, haveria ganho no total de tokens. Mas isso só valeria se, em várias consultas, a redução de custo continuasse como você imagina, o que me parece uma situação bastante idealizada. Não dá para garantir que a redução de custo causada pela refatoração será mantida independentemente do número de consultas seguintes, nem dá para assumir isso sem experimento. Se você quer sustentar esse ponto, acho que bastaria mostrar em experimento a redução de custo ao longo de mais de uma consulta. Mas o experimento não foi feito apenas uma vez e depois comparado?
Além disso, isso é só uma suposição minha, mas, se repetirmos indefinidamente as consultas para atingir o mesmo objetivo (a saída final ideal), em uma situação ideal o código deveria convergir para a mesma forma com ou sem refatoração. (A saída final ideal é única.) Se essa for uma suposição razoável, então, à medida que as consultas se repetem, a diferença entre ter ou não refatoração diminui, então o ganho de redução de custo em tokens também tenderia a cair gradualmente. Por isso, pensando de forma mais ampla, se esse ganho de redução de custo não se sustentar por tempo suficiente, talvez a diferença no número total de tokens usados nas consultas nem seja significativa.
E também me perguntaram sobre o experimento relacionado ao número de encadeamentos de prompts,
Na verdade, isso pode acabar sendo, no sentido mais coloquial, um bom elemento para o autor trapacear.
O próprio ato de desenvolver envolve muitas opções de caminho, e, se você acumular prompts em uma direção em que o uso de tokens aumente mais, esse número vai crescer ainda mais como uma bola de neve.
Na pesquisa, existe uma filosofia chamada
Cumulative Science.Como, pelo menos pelos meus critérios, eu ainda não encontrei sequer um estudo sobre uso de tokens em um único comando,
em vez de partir imediatamente para um estudo de N execuções, optei por focar em tratar de um teste sólido de uma única execução e de suas conclusões,
quanto ao estudo de N execuções, ele pode dar continuidade a esta pesquisa mais adiante.
Além disso, em outro texto, já tratei da diferença no comportamento da IA conforme as diferenças na codebase.
(Isto também já foi apresentado aqui no GeekNews: https://modgo.org/aineun-hyeonjae-kodeu-gujoyi-byeoge-maghyeoissda/)
Resumindo brevemente, ele aborda testes e resultados mostrando que a qualidade das saídas varia de acordo com a codebase fornecida como entrada para a IA.
Isso significa que, dependendo da qualidade e da direção da codebase inicial, a qualidade do código produzido em seguida pode se manter ou continuar piorando.
Ou seja, o custo de refatoração na fase inicial do projeto e o custo de refatoração de um projeto já bastante avançado podem ser muito diferentes.
Se a pessoa que perguntou for desenvolvedora, talvez já tenha ouvido a expressão "um porta-aviões sobre um veleiro" ao menos uma vez.
Refatoração é um tema profundo, em que o momento em que ela deve ser feita — ou os princípios e o design aplicados no início do projeto — podem alterar enormemente os custos.
Em vez de incluir isso como variável e chegar a uma conclusão instável,
foi realizado um teste que permite explicar com segurança pelo menos o seguinte: "ah, então quando a qualidade da codebase é boa, o uso de tokens diminui".
Vou tentar explicar de novo.
O espectro de quem pratica vibe coding é amplo, indo de não desenvolvedores a desenvolvedores experientes. Dependendo do nível de conhecimento que cada um possui, a qualidade do resultado pode variar enormemente, independentemente do conteúdo deste texto.
Alguém pode naturalmente trabalhar assumindo o uso do cursor e manter em
.cursorrulesconvenções básicas de OOP e regras de separação entre classes/métodos, operando de uma forma que quase não exige refatoração,enquanto outra pessoa pode estar produzindo código de baixo nível por simplesmente não compreender nem os pontos principais mais básicos.
Além disso, já existem muitos textos e relatos defendendo, de forma geral, que a qualidade do código deve ser mantida alta por meio da configuração de regras do projeto.
Isso sugere a possibilidade de que algumas pessoas já estejam obtendo ganhos em termos de uso de tokens mesmo sem refatoração explícita.
No entanto, os casos acima não organizam de forma clara a redução de uso de tokens por unidade de execução a partir da definição dessas regras. Por isso, neste texto foi testada a diferença no uso de tokens de acordo com a qualidade da codebase, e os resultados foram organizados.
Ou seja, dependendo do usuário, o número de refatorações explícitas volta a ser, por si só, uma variável de 0 a n vezes,
E acho que a intenção essencial deste texto pode ser entendida como uma explicação de por que vale a pena se preocupar com uma codebase de boa qualidade.
Sou o autor. Obrigado pelo feedback. Vou levar isso em consideração ao escrever o próximo texto.
Isso quer dizer que, ao incluir esse prompt também, o custo foi reduzido? Não tenho certeza se entendi corretamente o ponto principal.
Complementando, a estrutura do código precisa passar por uma melhoria estrutural com um modelo adequado ao projeto em questão. Como no conteúdo da resposta abaixo, se você pedir à IA sugestões de melhoria estrutural, ela indicará métodos apropriados de reorganização para aquele projeto.
Minha abordagem recomendada, pessoalmente, é não dar imediatamente um comando de refatoração estrutural para a IA; em vez disso, peça que ela proponha opções. Ela vai responder, e o ideal é conduzir a conversa até chegar a uma proposta suficientemente eficiente e, só então, pedir que aplique.
Uma dica adicional é, sempre que possível, concluir o trabalho antes que ocorra a sumarização de contexto (reinicialização do buffer de contexto). Se essa reinicialização for inevitável, é melhor pedir antes que sejam adicionadas regras de melhoria em
.cursorrules. Quando o contexto é reinicializado durante o trabalho, a probabilidade de a IA cometer erros aumenta.Só para constar, é um fato óbvio e bem conhecido que, quanto menor o tamanho do código-fonte de entrada, menor a quantidade de tokens consumidos. Foi por isso que o arquivo
.cursorignorefoi criado.De modo geral, quando se pede para a IA melhorar a estrutura, na grande maioria dos casos a quantidade de código-fonte tende a diminuir, então a ideia de que organizar por qualquer motivo reduz o custo parece uma afirmação plausível.
Este texto acrescenta a alegação de que, ao induzir uma boa estrutura, é possível obter uma redução adicional no uso de tokens.
Correto. Como também aparece no texto, é fato que, após a melhoria do código, o tamanho do código do projeto diminuiu.
No entanto, neste exemplo houve uma redução de cerca de 10% com base na contagem de caracteres, e isso, por si só, não explica a redução de 37,91% no uso de tokens.
Há um link para o repositório do código-fonte no texto, e qualquer pessoa pode reproduzir e testar por conta própria.
Eu mesmo não testei isso dessa forma,
mas acho que um prompt como
'Analise o código atual e melhore a estrutura para um formato que seja mais fácil para você gerenciar'
também não funcionaria?
A ideia central, ao que me parece, é que não basta passar à IA apenas os requisitos funcionais; orientar bem uma estrutura adequada e correta também pode ajudar a reduzir custos.
https://modgo.org/dib-rag-gaelreogtig-modeu-seuteurimeoreul-wihan-ciji…
Você mesmo criou este modo do DeepRAGgal?
Será que isso também foi feito com vibe coding?
Olá. Sou o dono do blog.
Está correto que fui eu mesmo quem criou diretamente o modo DeepRAGGal, e atualmente ele está em serviço por meio de um servidor pessoal. (Isso é necessário por causa da autenticação OAuth do Chzzk)
O desenvolvimento desse modo inclui trabalho com a Unreal Engine e, infelizmente, é difícil fazer vibe coding na parte da Unreal Engine.
Em vez disso, como o método de desenvolvimento do modo em si não é difícil, se você tiver interesse, pode aprender facilmente por meio do guia de desenvolvimento de mods (https://modgo.org/dib-rag-gaelreogtig-modeu-gaebal-part-1/).
Eu vi em outra comunidade que você publicou o mod, então era mesmo um texto escrito por quem criou aquele mod.
Eu não imaginava que você também tinha escrito até um post tutorial sobre o modo Blueprint; obrigado.
Você já era uma pessoa muito boa em desenvolvimento!
Ah, então você já tinha visto meu modo em outra comunidade.
Os textos que escrevi ainda têm várias limitações, mas ficarei feliz se puderem ajudar.
Ah, que irritação.
Se você nos disser qual parte o incomodou, responderemos com gentileza.
Confira o item sobre comentários em Como usar o site.
Por favor, fale de forma gentil e educada.
Se houver uma objeção, escreva apenas o conteúdo dela