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.
Inverte o fluxo em que o código era o centro e PRD/documentos de design eram auxiliares: a especificação é a fonte original, e o código é um artefato de expressão, implementado em uma linguagem/framework específico
Apresenta o diagnóstico de que o abismo permanente entre especificação e implementação era difícil de resolver apenas com reforço documental ou de processo
Se especificações executáveis e planos de implementação geram o código, o abismo desaparece e resta apenas a transformação
A IA torna possível interpretar especificações complexas e elaborar planos de implementação, mas como geração sem estrutura causa confusão, o SDD assegura qualidade com estrutura precisa e guardrails
Manutenção é o ato de evoluir a especificação; a intenção de desenvolvimento é expressa por linguagem natural, ativos de design e princípios centrais, e o código ocupa a posição de última milha
Depuração prioriza corrigir a especificação e o plano de implementação antes de corrigir código errado, e refatoração é redefinida como reconstrução de clareza
The SDD Workflow in Practice
A ideia é refinada em um PRD por meio de interação conversacional com a IA, e a IA detalha perguntas, edge cases e critérios de aceitação
Converte requisitos e design em uma atividade contínua, apoiando trabalho de especificação baseado em branches em nível de equipe, além de revisão e versionamento
Um agente de pesquisa explora compatibilidade de bibliotecas, desempenho, segurança e restrições organizacionais (padrões de DB, autenticação, políticas de deploy) e reflete isso automaticamente na especificação
A partir do PRD, gera-se um plano de implementação que mapeia requisitos e decisões técnicas de forma rastreável, enquanto a IA valida continuamente contradições, ambiguidades e omissões
Quando a especificação e o plano estão suficientemente estáveis, inicia-se a geração de código, mas no começo com geração exploratória para validar viabilidade
Conceitos de domínio se transformam em modelos de dados, user stories em endpoints de API e cenários de aceitação em testes
Na fase operacional, métricas e incidentes atualizam a especificação e influenciam a próxima regeneração; gargalos de desempenho são promovidos a requisitos não funcionais, e vulnerabilidades a restrições globais
Why SDD Matters Now
Ponto crítico da capacidade da IA: agora é possível gerar com confiabilidade código funcional a partir de especificações em linguagem natural, automatizando a parte mecânica da tradução da implementação e ampliando exploração e criatividade
Explosão de complexidade: com muitos serviços, frameworks e dependências, fica difícil manter a coerência entre intenção e implementação, tornando necessário o alinhamento guiado por especificação do SDD
Aceleração da mudança: em cenários de pivô frequente, o SDD lida com mudanças por meio de regeneração sistemática, em vez de propagação manual entre documento, design e código
Como exemplo, possibilita simulações what-if e implementações paralelas, oferecendo agilidade na tomada de decisão
Core Principles
Especificação = linguagem comum: a especificação é um artefato de primeira classe, o código é a expressão de uma stack específica, e manutenção é a evolução da especificação
Especificações executáveis: especificações em nível preciso, completo e não ambíguo geram sistemas funcionais
Refinamento contínuo: realiza validação constante de consistência, e não um gate único
Contexto baseado em pesquisa: coleta continuamente desempenho, segurança e restrições organizacionais, injetando isso na especificação
Feedback bidirecional: a realidade operacional vira entrada para atualização da especificação
Branching para exploração: a partir da mesma especificação, permite gerar múltiplas implementações conforme objetivos de otimização como desempenho, manutenibilidade, UX e custo
Implementation Approaches
Na prática de hoje, o essencial é combinar ferramentas existentes com manutenção de disciplina, e isso pode ser implementado com os seguintes elementos
Assistente de IA para refinamento iterativo de especificações
Agente de pesquisa para coleta de contexto técnico
Ferramenta de geração de código para conversão de especificação → implementação
Controle de versão adaptado a um workflow spec-first
Verificação baseada em análise de consistência por IA dos documentos de especificação
O princípio comum é tratar a especificação como fonte única da verdade e o código como artefato exigido pela especificação
Streamlining SDD with Commands
/specify: converte a descrição da funcionalidade em uma especificação estruturada e automatiza numeração automática, criação de branch e configuração de diretórios baseados em template
/plan: análise da especificação → revisão de conformidade com a constituição → tradução técnica → documentação de modelo de dados, contrato de API e cenários de teste → geração de validação de quickstart
/tasks: lê plan.md e os designs relacionados para produzir uma lista de tarefas executável, além de indicar tarefas paralelizáveis e agrupamento seguro para paralelização
Exemplo: funcionalidade de chat
Mostra um fluxo em que cerca de 12 horas de trabalho documental na abordagem tradicional são reduzidas para cerca de 15 minutos de configuração com automação de especificação, plano e tarefas
Entre os artefatos gerados estão especificação, plano de implementação e justificativas, contrato de API e modelo de dados, cenários de quickstart e tasks.md, tudo com versionamento na branch
The Power of Structured Automation
Evita itens faltando: templates cobrem até requisitos não funcionais e tratamento de erros
Rastreabilidade de decisões: toda escolha técnica fica ligada a requisitos concretos
Documentação viva: como a especificação gera o código, fica mais fácil manter sincronização
Iteração rápida: quando requisitos mudam, é possível responder em minutos ou horas com regeneração do plano
Template-Driven Quality
Evita a infiltração prematura de detalhes de implementação: ao focar em WHAT/WHY e excluir HOW, induz a manutenção do nível de abstração
Força marcação de incerteza: o marcador [NEEDS CLARIFICATION] induz proibição de suposições e perguntas explícitas
Auto-revisão baseada em checklist: implementa um gate de qualidade ao verificar completude, clareza e critérios de aceitação mensuráveis
Gate constitucional: aplica checks na fase prévia (-1), como gate de simplicidade (≤3 projetos), gate antiabstração (uso direto do framework) e gate de integração primeiro (contratos e testes de contrato primeiro)
Gestão hierárquica de detalhes: código e detalhes excessivos são separados em implementation-details/ para manter a legibilidade
Prioridade para testes: assegura testabilidade com regra de criação de arquivos e testes primeiro na ordem contrato → integração → E2E → unitário
Contenção de premissas e funcionalidades especulativas: reforça o controle de escopo com proibição de funcionalidades especulativas e explicitação de pré-condições por etapa
The Constitutional Foundation
Adota uma constituição de desenvolvimento em memory/constitution.md com princípios imutáveis para manter todas as implementações consistentes, simples e de alta qualidade
Article I: Library-First — toda funcionalidade começa como uma biblioteca independente, garantindo modularidade
Article II: CLI Mandate — toda biblioteca expõe uma interface CLI com suporte a entrada/saída em texto e JSON, garantindo observabilidade e facilidade de teste
Article III: Test-First — proíbe implementação antes da aprovação do teste e da confirmação da falha (red), aplicando o princípio de definir comportamento primeiro
Articles VII & VIII: simplicidade e antiabstração — reduzem sobre-engenharia com mínimo de projetos e confiança direta no framework
Article IX: Testes com integração primeiro — prefere testes próximos do ambiente real e força testes de contrato antes da implementação
Os gates da Phase -1 dos templates transformam a conformidade constitucional em checklist, e exceções registram justificativas explícitas em Complexity Tracking
Por meio de um processo de emenda, a forma de aplicar os princípios pode evoluir, mas a filosofia central é preservada
The Transformation
O objetivo não é substituir desenvolvedores, mas ampliar a capacidade humana e manter a coerência entre intenção e implementação por meio da automação da tradução mecânica
O SDD coloca a especificação para gerar o código, praticando uma transformação contínua em que especificação, pesquisa e código coevoluem em um loop de feedback apertado
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.
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".
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 .cursorrules convençõ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.
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.
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.
É necessário comparar o código-fonte antes e depois do pré-processamento.
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.
No vibe coding, o resultado não é concluído com um único prompt.
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 n em relação à complexidade do projeto seja conduzido separadamente.
Para ajudar na compreensão ao máximo, usei como exemplo a melhoria de código a partir de um código escrito pela IA com problemas estruturais, quando não há instruções adicionais.
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,
quando há uma regra de instrução para indução estrutural como contexto base, também existe a possibilidade de o uso total de tokens diminuir, e
como existe a variável de obtenção do resultado final por meio de n comandos de prompt,
a alegação de que o uso de tokens de um único prompt de melhoria estrutural deve ser somado ao cálculo é problemática.
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:
Foram preparados dois códigos-fonte para consultar a IA: o código-fonte original e outro código-fonte pré-processado via prompt (?)
No GPT5 e no Sonnet, cada um dos dois códigos-fonte foi executado 5 vezes, e o consumo de tokens foi comparado
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.
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.
Gostei bastante do experimento; foi muito interessante de acompanhar.
Você fez curso de criar títulos, né..
Em que a mídia social é uma perda de tempo, a sensação certa se parece mais com 'arrependimento' ou 'vergonha', como no jogo ou nas drogas
Interessante. Até faz sentido também.
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.
k9s - ferramenta para gerenciar clusters Kubernetes com uma interface de terminal
O link com a apresentação detalhada de SDD no meio do texto é muito bom. Abaixo está um resumo que fiz com IA.
Desenvolvimento Guiado por Especificação (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: converte a descrição da funcionalidade em uma especificação estruturada e automatiza numeração automática, criação de branch e configuração de diretórios baseados em template/plan: análise da especificação → revisão de conformidade com a constituição → tradução técnica → documentação de modelo de dados, contrato de API e cenários de teste → geração de validação de quickstart/tasks: lêplan.mde os designs relacionados para produzir uma lista de tarefas executável, além de indicar tarefas paralelizáveis e agrupamento seguro para paralelizaçãoThe Power of Structured Automation
Template-Driven Quality
[NEEDS CLARIFICATION]induz proibição de suposições e perguntas explícitasimplementation-details/para manter a legibilidadeThe Constitutional Foundation
memory/constitution.mdcom princípios imutáveis para manter todas as implementações consistentes, simples e de alta qualidadeThe Transformation
Vazaram os códigos-fonte do Big Brother!
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.
Se você faz algo como engenharia civil, isso já é usado até nas aulas da universidade.
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.
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.
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.
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.
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.
Parece que dar presentes inúteis está em alta... acho que vai ser legal para descobrir novos presentes inúteis.
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.