DEV Community: Fazedor de Codigo

Modelo ou harness? O modelo define o teto, mas o harness decide o resultado

Emerson Delatorre — Thu, 30 Jul 2026 13:06:38 +0000

Por que o melhor agente de IA não é necessariamente aquele que usa o modelo mais poderoso — e como contexto, ferramentas, memória, validação e ciclos de feedback passaram a decidir o desempenho real.

Introdução

Durante boa parte da evolução recente da inteligência artificial, escolher uma tecnologia significava comparar modelos: qual raciocina melhor, qual escreve código com mais precisão, qual possui a maior janela de contexto ou qual lidera determinado benchmark.

Essa comparação continua importante. O problema é que ela se tornou insuficiente.

Quando usamos um modelo de linguagem de grande escala — ou LLM, do inglês large language model — dentro de um agente, o resultado não depende apenas dos parâmetros aprendidos durante o treinamento. Depende também de quais informações o modelo recebe, das ferramentas disponíveis, de como os resultados dessas ferramentas retornam ao contexto, de quando o agente tenta novamente, de como verifica seu próprio trabalho e até de quem decide que a tarefa terminou.

Esse sistema ao redor do modelo é chamado de harness: a camada de execução e controle que transforma um modelo, essencialmente capaz de receber entradas e produzir saídas, em um agente capaz de observar um ambiente, usar ferramentas, manter estado e executar tarefas. A própria Anthropic ressalta que avaliar um agente significa avaliar conjuntamente o modelo e seu harness; a OpenAI, ao descrever o Codex, também trata o harness como o agente loop, as ferramentas, o sandbox e a lógica de execução que tornam o modelo operacional. (Anthropic)

Então, qual possui maior relevância?

Para capacidade bruta, o modelo. Para desempenho real, confiabilidade e custo de um agente, o conjunto modelo–harness. Em aplicações de produção, o harness frequentemente se torna tão importante quanto o modelo — e, em alguns critérios, mais importante.

Modelo e harness não fazem o mesmo trabalho

O modelo é o mecanismo de inteligência probabilística. Ele interpreta instruções, produz texto, raciocina sobre problemas, escreve código e decide qual ação parece mais adequada.

O harness é o sistema que organiza essa inteligência. Ele pode incluir:

instruções de sistema e montagem do contexto;
ferramentas, APIs e suas descrições;
memória de curto e longo prazo;
acesso a arquivos, terminal, navegador e bancos de dados;
planejamento, delegação e uso de subagentes;
limites de tempo, custo e quantidade de interações;
validação, testes, tentativas adicionais e critérios de parada;
sandbox, permissões, auditoria e observabilidade.

Um modelo sozinho pode sugerir um comando. O harness decide se ele pode executá-lo, em qual diretório, com quais permissões, durante quanto tempo e o que fazer com o resultado.

A analogia mais útil é pensar no modelo como o motor de um carro de corrida. O harness inclui transmissão, pneus, direção, freios, telemetria e equipe de boxes. Um motor excelente em um veículo mal projetado não transforma potência em velocidade. Por outro lado, o melhor chassi do mundo não fará um motor fraco competir com a Fórmula 1.

Por isso, o desempenho de um agente pode ser representado de forma mais honesta assim:

Resultado observado = f(modelo, harness, tarefa, ambiente e orçamento)

Não se trata de uma soma simples. Há uma interação: um harness pode ampliar determinada capacidade do modelo, desperdiçá-la ou até limitá-la.

O modelo ainda importa — e muito

Um dos estudos recentes que mais diretamente separa essas variáveis é o Claw-SWE-Bench, publicado como preprint em 2026. O trabalho utiliza tarefas de engenharia de software baseadas em problemas reais de repositórios e realiza dois experimentos complementares: mantém o harness fixo enquanto troca os modelos e, depois, mantém modelos fixos enquanto troca os harnesses.

Com o mesmo harness e nove modelos diferentes, a escolha do modelo produziu uma variação de 29,4 pontos percentuais na taxa de resolução. Ou seja: trocar apenas o modelo continua alterando substancialmente a capacidade do agente. (arXiv)

Essa é também a lógica da área “Bash Only” do SWE-bench Verified. Para comparar modelos de maneira mais justa, todos são executados com o mesmo mini-SWE-agent, em um ambiente mínimo e com o mesmo loop de interação. Fixar o harness é justamente o que permite atribuir a diferença observada ao modelo, em vez de misturar inteligência, ferramentas e estratégias de execução. (Swebench)

O modelo tende a ser o principal gargalo quando a tarefa exige uma capacidade que ele simplesmente não possui: compreender uma arquitetura complexa, deduzir uma causa não evidente, escrever um algoritmo difícil ou seguir restrições numerosas e contraditórias.

Nenhuma quantidade de orquestração cria magicamente uma capacidade ausente. O harness pode fornecer uma calculadora, mas não garante que o modelo saiba formular o cálculo correto.

O harness pode mudar quase tanto quanto o modelo

No outro eixo do Claw-SWE-Bench, os pesquisadores mantiveram o modelo fixo e trocaram cinco harnesses. A diferença chegou a 12,5 pontos percentuais com um modelo e a 27,4 pontos percentuais com outro. Nesse segundo caso, a mudança de harness teve impacto comparável à variação observada ao trocar modelos. (arXiv)

A importância da interface já aparecia no trabalho do SWE-agent, de 2024. Os autores criaram uma Agent-Computer Interface — uma interface computadorizada desenhada especificamente para as necessidades do agente — com comandos para navegar pelo repositório, visualizar e editar arquivos e executar testes. O sistema atingiu 12,5% de resolução no SWE-bench, resultado que, naquele momento, superava consideravelmente abordagens não interativas. O ponto central do paper não era apenas “usar um modelo melhor”, mas adaptar o ambiente à maneira como o modelo observa e atua. (arXiv)

Isso acontece porque um agente trabalha em ciclo fechado: ele age, observa o resultado, atualiza seu estado e decide a próxima ação. Pequenas escolhas do harness podem se acumular durante dezenas de interações. Uma saída de terminal truncada incorretamente, uma ferramenta descrita de forma ambígua ou um teste que nunca é executado pode colocar todo o restante da trajetória na direção errada.

Em produção, o harness pode dominar custo e eficiência

A taxa de acerto não é a única métrica relevante.

O preprint The Scaffold Effect in Coding Agents comparou dois modelos em três harnesses de código aberto, utilizando um subconjunto de 50 tarefas do Terminal-Bench Pro. As diferenças de resolução entre harnesses ficaram entre zero e oito pontos percentuais, enquanto a troca de modelo produziu diferenças de quatro a dez pontos. Para precisão, portanto, os dois fatores tiveram magnitudes próximas, com leve vantagem para o modelo naquele experimento.

A situação mudou completamente quando os autores avaliaram eficiência. Dependendo do harness, o consumo de tokens por tarefa resolvida variou em até 40 vezes. Token é a unidade de texto processada e normalmente utilizada para medir consumo e cobrança das APIs. Os harnesses também apresentaram padrões próprios de falha: um desistia mais cedo, outro continuava até atingir o limite de interações e outro gastava tempo em ciclos nos quais nenhuma nova ação era executada. (arXiv)

Isso significa que dois agentes com taxas de acerto semelhantes podem ter custos, latências e necessidades de supervisão completamente diferentes.

O estudo possui limitações importantes: avaliou apenas dois modelos, três harnesses e 50 tarefas, e a maioria das diferenças de resolução não foi estatisticamente conclusiva. Ainda assim, a variação de custo foi suficientemente grande para mostrar que escolher somente pelo nome do modelo pode levar a uma decisão operacional ruim. (arXiv)

Um harness melhor não significa um harness mais complexo

Reconhecer a importância do harness não é uma defesa de arquiteturas cheias de agentes, planejadores, memórias, roteadores e dezenas de ferramentas.

O paper Agentless apresentou uma abordagem deliberadamente simples para problemas de software: localizar o trecho relevante, produzir uma correção e validar o patch. Sem permitir que o modelo controlasse livremente uma sequência complexa de ações, o sistema alcançou 32% no SWE-bench Lite, com custo médio reportado de US$ 0,70 por problema. O resultado mostrou que um fluxo estruturado e previsível pode superar agentes mais sofisticados em tarefas bem delimitadas. (arXiv)

A Anthropic chegou a uma conclusão semelhante trabalhando com equipes que construíam sistemas de IA: as implementações mais bem-sucedidas frequentemente utilizavam padrões simples e combináveis. A recomendação é começar pela solução mais simples e aumentar a autonomia apenas quando a tarefa realmente exigir flexibilidade. Agentes acrescentam capacidade, mas também aumentam custo, latência e superfícies de falha. (Anthropic)

Portanto, harness engineering não significa “adicionar mais camadas”. Significa projetar a menor estrutura capaz de corrigir os modos de falha observados.

Um harness também pode atrapalhar um modelo melhor

Há outro detalhe importante: o mesmo harness não funciona igualmente bem para todos os modelos.

A Anthropic relatou que reinicializações periódicas de contexto ajudavam o Claude Sonnet 4.5 a não encerrar tarefas longas prematuramente. Ao aplicar a mesma estratégia ao Claude Opus 4.5, o problema já não aparecia, e as reinicializações se tornaram peso desnecessário. O mecanismo havia sido criado para compensar uma limitação específica de determinado modelo. Quando o modelo mudou, a premissa do harness ficou obsoleta. (Anthropic)

O preprint Rethinking the Evaluation of Harness Evolution for Agents fornece um alerta ainda mais direto. Em um experimento sem acesso a testes de unidade, um processo automático de alteração do harness reduziu o desempenho do GPT-5.4 de 75,3% para 69,7%. Quando os harnesses otimizados foram avaliados em tarefas separadas das utilizadas durante a otimização, o ganho médio ficou em apenas 0,6 ponto percentual, indicando risco de sobreajuste ao benchmark. (arXiv)

Em outras palavras: harness também precisa de engenharia, avaliação e manutenção. Um conjunto crescente de regras inventadas a partir de poucos erros pode engessar modelos mais capazes ou ensinar atalhos que não se generalizam.

Afinal, qual tem maior relevância?

A resposta depende do gargalo.

Quando o agente não consegue formular a solução, mesmo tendo acesso ao contexto correto, às ferramentas necessárias e a resultados verificáveis, o gargalo provavelmente está no modelo.

Quando o agente conhece a solução, mas busca os arquivos errados, perde informações, usa mal ferramentas, repete ações, interrompe o trabalho cedo demais ou entrega sem validar, o gargalo provavelmente está no harness.

Quando qualidade, custo, latência, segurança e esforço humano precisam ser considerados simultaneamente, a unidade correta de decisão não é o modelo. É o par modelo–harness.

Uma formulação prática é:

O modelo define a fronteira de capacidade. O harness define o ponto de operação dentro dessa fronteira.

Isso explica por que um modelo menor, em uma tarefa restrita e com ferramentas bem projetadas, pode superar um modelo maior executado de maneira ingênua. Mas também explica por que melhorar indefinidamente o harness encontra um teto: em algum momento, a limitação passa a ser o raciocínio do modelo.

O componente de maior alavancagem: feedback verificável

Dentro do harness, o elemento de maior impacto costuma ser o ciclo de feedback verificável.

Não basta pedir que o modelo “revise com atenção”. É melhor fornecer um mecanismo externo que determine se a ação realmente produziu o resultado esperado:

testes automatizados para um agente de código;
consulta ao banco de dados para confirmar que uma reserva foi criada;
validação de esquema para dados estruturados;
navegador automatizado para testar uma interface;
checagem de fontes e citações para um agente de pesquisa;
aprovação humana para ações financeiras ou irreversíveis.

A distinção fundamental é entre o que o agente declara ter feito e o estado real do ambiente. A Anthropic recomenda que avaliações de agentes considerem esse estado final, além da transcrição produzida pelo modelo. Já a OpenAI descreve ambientes, ferramentas de observabilidade, testes e ciclos de feedback como parte central da engenharia necessária para agentes trabalharem de maneira confiável por longos períodos. (Anthropic)

É o feedback que transforma uma geração probabilística em um processo iterativo: tentar, observar, corrigir e verificar.

Como aplicar isso na prática

1. Comece pela tarefa, não pelo ranking de modelos

Construa uma suíte de avaliação com exemplos reais do seu domínio. Defina o que significa sucesso, quais erros são inaceitáveis e quanto podem custar latência, tokens e intervenção humana.

2. Crie primeiro o harness mais simples possível

Teste uma chamada direta. Depois, adicione contexto recuperado, ferramentas ou um workflow determinístico. Só introduza autonomia, múltiplos agentes ou memória persistente quando os erros demonstrarem essa necessidade.

3. Separe os experimentos

Para comparar modelos, mantenha prompt, ferramentas, orçamento, contexto e critérios de parada fixos. Para comparar harnesses, mantenha o modelo e suas configurações fixos. Sem esse controle, qualquer melhoria fica difícil de atribuir.

4. Analise trajetórias, não apenas respostas finais

Registre chamadas ao modelo, uso de ferramentas, consumo de tokens, tentativas, erros e estado final do ambiente. Pergunte onde ocorreu a primeira decisão incorreta. Frequentemente, o erro final é apenas consequência de contexto ruim ou feedback incompleto em uma etapa anterior.

5. Escolha o sistema pela fronteira qualidade–custo–risco

O melhor sistema não é necessariamente o de maior taxa de acerto. Pode ser aquele que atinge o nível de qualidade necessário com menor custo, menor latência e menor necessidade de supervisão. Em produção, versão do modelo, prompt, ferramentas, políticas, memória e avaliadores devem ser tratados como um único artefato implantável.

Conclusão

Ainda precisamos de modelos melhores. Eles continuam elevando o teto de raciocínio, planejamento, compreensão e geração. Ignorar o modelo seria tão equivocado quanto imaginar que um motor fraco pode vencer apenas com boa aerodinâmica.

Mas também não é mais tecnicamente correto avaliar um agente apenas pelo modelo que aparece em sua página comercial.

As evidências mostram que trocar o harness pode produzir variações de desempenho comparáveis às de uma troca de modelo. Além disso, o harness pode dominar custos, latência, padrões de falha, segurança e necessidade de supervisão — dimensões que determinam se um protótipo realmente pode entrar em produção.

A decisão madura não é “modelo ou harness”. É:

Qual combinação de modelo, contexto, ferramentas, controle e feedback resolve esta tarefa de forma correta, verificável e economicamente sustentável?

O modelo fornece inteligência. O harness transforma essa inteligência em trabalho. E as avaliações mostram se o conjunto realmente funciona.

Referências

Claw-SWE-Bench: A Benchmark for Evaluating OpenClaw-style Agent Harnesses on Coding Tasks — Mengyu Zheng e colaboradores, arXiv, 2026. Utilizado para comparar, sob condições controladas, a variação causada pela troca de modelos e pela troca de harnesses. (arXiv)

The Scaffold Effect in Coding Agents: Harness Choice as a Hidden Variable in Coding-Agent Evaluation — Naman Vats e Oleg Golev, arXiv, 2026. Base para a discussão sobre custo por tarefa resolvida, latência e padrões de falha específicos de cada harness. (arXiv)

SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering — John Yang e colaboradores, arXiv, 2024. Utilizado para explicar como interfaces desenhadas para agentes influenciam navegação, edição e validação de código. (arXiv)

Agentless: Demystifying LLM-based Software Engineering Agents — Chunqiu Steven Xia, Yinlin Deng, Soren Dunn e Lingming Zhang, arXiv, 2024. Utilizado como evidência de que workflows simples e estruturados podem competir com agentes complexos. (arXiv)

Meta-Harness: End-to-End Optimization of Model Harnesses — Yoonho Lee e colaboradores, Stanford, MIT e KRAFTON, arXiv, 2026. Referência sobre otimização automática de contexto, memória e código do harness, incluindo ganhos de desempenho e eficiência. (arXiv)

Rethinking the Evaluation of Harness Evolution for Agents — Yike Wang e colaboradores, Allen Institute for AI e University of Washington, arXiv, 2026. Utilizado para apresentar riscos de sobreajuste, feedback autorreferente e degradação provocada por alterações inadequadas no harness. (arXiv)

SWE-bench Verified — Bash Only: Comparing Language Models — SWE-bench. Utilizado como exemplo de comparação entre modelos com um harness fixo. (Swebench)

Harness engineering: leveraging Codex in an agent-first world — Ryan Lopopolo, OpenAI, 2026. Utilizado para discutir ambientes legíveis para agentes, organização de contexto, observabilidade e ciclos de feedback. (OpenAI)

Building effective agents — Anthropic, 2024. Utilizado para fundamentar a recomendação de começar com padrões simples e acrescentar complexidade apenas quando necessária. (Anthropic)

Demystifying evals for AI agents e Scaling Managed Agents: Decoupling the brain from the hands — Anthropic, 2026. Utilizados para definir agent harness, explicar avaliações baseadas no estado real do ambiente e demonstrar como premissas do harness podem ficar obsoletas conforme os modelos evoluem. (Anthropic)

Preço por token não é custo por tarefa: a inversão que muda a economia dos modelos de raciocínio

Emerson Delatorre — Sat, 20 Jun 2026 16:15:08 +0000

Modelos aparentemente baratos podem consumir mais tokens, executar mais etapas e terminar com uma conta maior — especialmente em agentes de programação e outros fluxos de trabalho longos.

Uma API, ou interface de programação, permite que uma aplicação envie solicitações ao modelo e receba respostas. Normalmente, a cobrança considera tokens — pequenas unidades em que textos e códigos são divididos durante o processamento.

Em uma chamada simples, o custo pode ser representado aproximadamente por:

C = n_{e n t r a d a} \times p_{e n t r a d a} + n_{s a ı ˊ d a} \times p_{s a ı ˊ d a} ‘

Aqui, (n) representa o número de tokens consumidos e (p), o preço de cada tipo de token. O custo de inferência — isto é, de executar um modelo já treinado para produzir uma resposta — depende tanto do preço unitário quanto do volume consumido.

A tabela do fornecedor mostra principalmente o (p). Mas a aplicação paga por:

(p \times n)

Nos modelos de raciocínio, a saída pode incluir tokens de pensamento: computação intermediária usada antes da resposta visível. Dependendo da API, esses tokens podem não aparecer para o usuário, embora sejam contabilizados e cobrados como tokens de saída. No conjunto avaliado pelo estudo, todos os fornecedores cobravam os tokens de raciocínio pela tarifa de saída.

Em sistemas com várias interações, a fórmula fica ainda mais extensa. É preciso contabilizar entradas novas, saídas, tokens de raciocínio, leituras e gravações de cache e o número de turnos executados. Cache de prompt é o mecanismo que reutiliza partes já processadas do contexto por um preço reduzido. Ele ajuda, mas não transforma históricos crescentes em consumo gratuito.

O que o estudo encontrou

Os pesquisadores avaliaram oito modelos de raciocínio em 12 conjuntos de tarefas: nove testes de turno único, envolvendo matemática, ciência, conhecimento, programação e chat, além de três ambientes com agentes capazes de usar ferramentas e interagir com sistemas ao longo de vários turnos. Entre os benchmarks estavam AIME, GPQA, LiveCodeBench, MMLU-Pro, GAIA, Cybench e Terminal-Bench 2.0.

Com oito modelos, existem 28 pares possíveis. Multiplicando-os pelas 12 tarefas, o estudo obteve 336 comparações. Em 106 delas — 32% — o modelo com menor preço listado produziu maior custo real. A maior inversão observada chegou a 28 vezes. (arXiv)

A Figura 1, na página 2 do anexo, deixa a inversão especialmente visível. O GPT-5.4 tinha preço listado de US$ 17,50 por milhão de tokens na métrica adotada pelo trabalho, contra US$ 3,50 do Gemini 3 Flash. Apesar disso, os gastos agregados do experimento foram de US$ 509 e US$ 705, respectivamente. Esses valores são o total daquela bateria de testes, não uma previsão universal para qualquer aplicação.

A ordem também mudou conforme a tarefa. A taxa de inversão foi de 11% no ArenaHard e chegou a 57% no MMLU-Pro. Em Cybench, um ambiente de segurança com várias interações, o Kimi K2.6 foi listado como 72% mais barato que o GPT-5.4, mas terminou com aproximadamente o dobro do custo. Nenhum modelo permaneceu universalmente como o mais barato ou o mais caro.

Essa dependência do workload — o conjunto real de tarefas da aplicação — é a principal razão pela qual benchmarks genéricos não substituem testes internos.

“Overthinking”: quando o modelo pensa demais

Em tarefas de turno único, o principal responsável pela inversão foi o volume de tokens de pensamento. O estudo chama esse comportamento de overthinking, ou raciocínio excessivo: o modelo executa uma deliberação muito maior do que a necessária para chegar à resposta.

Em um exemplo de MMLU-Pro, o Gemini 3 Flash consumiu mais de 60 mil tokens de pensamento, enquanto o GPT-5.4 utilizou apenas 25 para a mesma questão. O exemplo é extremo, mas ilustra por que uma diferença de cinco vezes no preço unitário pode desaparecer rapidamente.

A atribuição estatística do estudo indicou que, entre os pares com inversão em tarefas de turno único, mais de 95% da diferença de custo estava associada aos tokens de pensamento. Em outras palavras, nesses casos não era a tarifa que explicava a conta: era o comportamento de consumo do modelo.

Isso não significa que raciocinar seja ruim. Computação adicional pode melhorar resultados difíceis. O problema aparece quando não há proporcionalidade entre o esforço utilizado e o valor produzido.

“Overacting”: agentes que executam etapas demais

Em agentes de IA, o problema muda de forma. Um agente não entrega apenas uma resposta: ele planeja, chama ferramentas, lê resultados, corrige erros e tenta novamente. Cada ciclo é um turno de interação.

O estudo encontrou casos em que um modelo precisou de sete turnos e outro de 57 para identificar o mesmo risco em um código. Em uma das comparações de Cybench, o número de turnos respondeu por mais de 80% da inversão de custo.

Há ainda um efeito acumulativo. Se cada nova chamada inclui a conversa anterior, o contexto cresce a cada turno. Com incrementos de tamanho semelhantes, o volume total reapresentado ao modelo se aproxima de:

1 + 2 + 3 + \dots + T = \frac{T ( T + 1 )}{2}

Ou seja, o crescimento pode se aproximar de uma curva quadrática em relação ao número de turnos. A página 18 do anexo mostra que, nos agentes avaliados, o custo aumentou mais do que linearmente porque o histórico era reenviado sucessivamente. Cache, sumarização e truncamento podem reduzir esse impacto, mas precisam ser projetados e medidos.

Para assistentes de programação, isso é particularmente relevante. Ler arquivos, executar testes, interpretar erros e editar novamente são ações úteis, mas um agente que entra em loop pode consumir muito mais do que outro que encontra rapidamente a causa do problema.

O valor de Shapley como ferramenta de diagnóstico

Para explicar a diferença entre dois modelos, os autores aplicaram o valor de Shapley, uma técnica da teoria dos jogos cooperativos. Em termos simples, ela estima quanto cada fator contribui para um resultado ao avaliar sua participação em diferentes combinações possíveis.

É como investigar uma conta alta separando o efeito da tarifa, do volume utilizado e do número de viagens. A técnica evita atribuir toda a culpa ao último fator observado quando vários elementos interagem.

O trabalho separou oito componentes: total de turnos; médias de tokens novos de entrada, saída, cache e pensamento por turno; e os preços de entrada, saída e cache. A soma das contribuições explica integralmente a diferença de custo entre os sistemas comparados.

Na prática, uma empresa não precisa implementar imediatamente toda a matemática de Shapley. O insight operacional é mais direto: registre separadamente preço, tokens de cada categoria, cache, turnos e tentativas. Sem essa decomposição, a fatura informa quanto foi gasto, mas não explica por quê.

O custo é uma distribuição, não um número fixo

Mesmo depois de selecionar o modelo e congelar o prompt, o custo não fica completamente estável. Modelos generativos podem seguir caminhos de raciocínio diferentes em execuções repetidas.

No estudo, o custo realizado para o mesmo par de modelo e consulta variou até 9,7 vezes entre execuções. A Figura 5, nas páginas 7 e 8, mostra distribuições longas e irregulares tanto em matemática quanto em tarefas com agentes.

Isso torna a média insuficiente para planejamento financeiro. Um produto precisa observar também percentis:

p50: custo mediano, representando uma execução típica;
p90 ou p95: patamar que cobre a maior parte das solicitações;
p99: cauda extrema, relevante para limites de segurança e proteção de margem.

No próprio estudo, a taxa média de inversão ficou próxima de 32%, mas atingiu 39,6% no quantil 40. O modelo aparentemente mais barato pode, portanto, perder a vantagem em diferentes regiões da distribuição de consumo.

Para um SaaS com cobrança mensal fixa, isso afeta diretamente o COGS, ou custo dos serviços vendidos. Usuários que acionam consultas difíceis, grandes repositórios ou longos ciclos de ferramentas podem consumir mais receita do que geram, mesmo que o custo médio inicial pareça saudável. Essa preocupação também aparece explicitamente na discussão do Reddit. (Reddit)

Custo sozinho também não escolhe o melhor modelo

O estudo mede gastos, mas não incorpora qualidade ao ranking principal. Além disso, utiliza um único nível de esforço de raciocínio por modelo e uma fotografia de preços registrada em 1º de maio de 2026. Os próprios autores reconhecem que mudanças de tarifa, configuração e qualidade podem alterar os resultados específicos.

A métrica mais útil para produção não é apenas custo por chamada, mas custo por resultado bem-sucedido:

C u s t o p or s u cesso = \frac{C u s t o t o t a l d a s e x ec u c \c o ~ es}{N u ˊ m ero d e t a re f a s co n c l u ı ˊ d a s corre t am e n t e}

Um modelo barato que falha e exige nova tentativa pode ser mais caro que um modelo premium que resolve o problema de primeira. Por outro lado, usar sempre o modelo mais sofisticado em tarefas triviais também desperdiça recursos.

A consequência natural é o model routing: direcionar cada solicitação ao modelo mais adequado à sua dificuldade, escalando para opções mais fortes quando necessário. O Reddit aponta exatamente esse dilema entre usar modelos fracos para problemas complexos e modelos caros para trabalhos simples. (Reddit)

Como aplicar isso na prática

Construa um conjunto representativo de tarefas. Separe consultas simples, médias e difíceis, além de fluxos de turno único e agentes com ferramentas. Não use somente benchmarks públicos.
Execute os candidatos repetidamente. Mantenha prompts, ferramentas, limites e ambiente equivalentes. Uma única execução não revela a variabilidade observada pelo estudo.
Registre telemetria por solicitação. Inclua versão do modelo, tokens de entrada, saída e raciocínio, leituras e gravações de cache, turnos, chamadas de ferramentas, novas tentativas, latência, custo e sucesso.
Compare distribuições e resultados. Analise custo médio, mediana, p90, p95, taxa de sucesso e custo por tarefa concluída. Evite selecionar modelos somente por US$/milhão de tokens.
Imponha limites arquiteturais. Defina orçamento de tokens, máximo de turnos, detecção de loops, sumarização de histórico, interrupção antecipada e escalonamento para outro modelo. Teste o impacto desses controles na qualidade.
Reavalie periodicamente. Preços, versões, políticas de cache e comportamento dos modelos mudam. Um roteamento eficiente hoje pode deixar de ser eficiente após uma atualização.

Conclusão

O preço listado continua sendo útil, mas é apenas um multiplicador. O custo real nasce da combinação entre tarifa e comportamento: quanto o modelo pensa, quantas ações executa, quanto contexto reapresenta e quantas tentativas precisa fazer.

O estudo mostra que essa diferença não é marginal. Na versão atualizada, quase um terço das comparações apresentou inversão de preço, com casos extremos de até 28 vezes. Em tarefas simples, o vilão costuma ser o excesso de tokens de pensamento. Em agentes, são os turnos adicionais e o crescimento do histórico. E, mesmo mantendo modelo e prompt fixos, a conta ainda pode variar significativamente.

A decisão economicamente correta, portanto, não é escolher “o modelo mais barato”. É escolher o modelo com melhor custo por resultado no seu workload, observando também qualidade, latência e risco de cauda.

Referências

The Price Reversal Phenomenon: When Cheaper Reasoning Models Cost More — Lingjiao Chen, Chi Zhang, Yeye He, Ion Stoica, Matei Zaharia e James Zou. Versão 2, arXiv, revisada em 28 de maio de 2026. Fonte principal para metodologia, resultados, atribuição de custos e limitações. (arXiv)

The Price Reversal Phenomenon — versão 1 — Resumo original publicado em março de 2026. Usado para identificar a origem dos números “78% mais barato” e “22% mais caro” reproduzidos no Reddit. (arXiv)

A model listed 78% cheaper cost 22% more to actually run. Unit price isn’t your bill — Discussão na comunidade r/cursor. Usada como contexto sobre COGS, seleção de modelos, monitoramento e roteamento em aplicações reais. (Reddit)

A nova corrida das fábricas de software: SpaceX compra Cursor enquanto a Factory lança o Factory 2.0

Emerson Delatorre — Tue, 16 Jun 2026 13:53:46 +0000

Por trás de dois anúncios quase simultâneos — a aquisição do Cursor pela SpaceX e o lançamento do Factory 2.0 — está uma mudança estrutural: a IA para desenvolvimento de software deixou de ser apenas uma ferramenta de produtividade individual e passou a disputar o controle do ciclo inteiro de engenharia.

A aquisição da Anysphere, empresa por trás do Cursor, pela SpaceX por um valor implícito de US$ 60 bilhões marca um dos movimentos mais agressivos da nova fase da inteligência artificial aplicada à programação. Em documento 8-K enviado à SEC em 16 de junho de 2026, a Space Exploration Technologies Corp. informou que sua subsidiária X67 Inc. será incorporada à Anysphere, com o Cursor sobrevivendo como subsidiária integral da SpaceX. A transação será paga em ações da Classe A da SpaceX, ainda depende de condições de fechamento e aprovações regulatórias, e tem conclusão esperada para o terceiro trimestre de 2026. (Comissão de Valores Mobiliários)

A operação não surge do nada. Em abril, o Cursor já havia anunciado uma parceria com a SpaceX para acelerar o treinamento de seus modelos, afirmando que seu avanço estava limitado por capacidade computacional e que passaria a usar a infraestrutura Colossus da xAI para escalar seus modelos de programação. (Cursor) Agora, a SpaceX transforma essa parceria em integração vertical: produto, distribuição para desenvolvedores, modelos de IA, infraestrutura de treinamento e ambição empresarial passam a ficar sob o mesmo guarda-chuva.

A Reuters descreveu a compra como uma tentativa da SpaceX de ampliar sua presença no mercado de ferramentas corporativas de IA, especialmente em um setor no qual Cursor, OpenAI e Anthropic competem pela automação do trabalho de desenvolvimento de software. Segundo a reportagem, o Cursor vinha crescendo rapidamente desde sua fundação em 2022, com cerca de US$ 2,6 bilhões em receita B2B anualizada, além de apoio de investidores como Andreessen Horowitz, Thrive, Nvidia e Google. (Reuters)

O ponto central é que a SpaceX não está comprando apenas um editor de código. Está comprando uma interface de trabalho para engenheiros, um canal de distribuição para empresas, uma camada de dados sobre como software é produzido e uma posição estratégica no mercado de “AI coding agents”. A AP destacou que o Cursor se tornou um dos produtos mais associados à ascensão do chamado “vibe coding”, tendência em que assistentes de IA assumem parcelas crescentes do trabalho de programação. (AP News)

Enquanto isso, a Factory apresentou o Factory 2.0, com uma tese complementar: o futuro não será definido apenas pelo melhor agente de código, mas por “fábricas de software” inteiras. No anúncio publicado em 15 de junho de 2026, a empresa afirma que aumentar a produtividade de engenheiros individuais já não basta; o próximo salto viria de sistemas interconectados, nativos de agentes, capazes de operar de ponta a ponta no ciclo de desenvolvimento. (Factory.ai)

A Factory define a “software factory” como um sistema que começa em sinais externos — bugs, conversas internas, feedback de clientes e requisitos de negócio — e transforma esses sinais em mudanças planejadas, desenvolvidas, testadas, revisadas, protegidas, implantadas e monitoradas. O monitoramento, por sua vez, gera novos sinais, fechando um ciclo contínuo de aprendizado operacional. (Factory.ai)

Essa diferença é essencial. O Cursor representa a força da experiência individual do desenvolvedor: um ambiente de programação aumentado por IA. A Factory 2.0 representa a industrialização do processo: agentes coordenados, fluxos padronizados, governança, auditoria, implantação soberana e aprendizado contínuo dentro da organização.

No anúncio do Factory 2.0, a empresa aponta três pilares para essa nova categoria: independência de modelos, permitindo escolher ou rotear automaticamente entre diferentes modelos de IA; inteligência soberana, com opções como cloud, BYOK, data plane próprio, ambientes europeus ou air-gapped; e aprendizado contínuo, em que cada revisão, incidente, automação e análise de segurança alimenta o sistema como um todo. (Factory.ai)

A leitura estratégica é clara: o mercado está se dividindo entre quem controla a interface do desenvolvedor e quem controla o sistema operacional da engenharia. A SpaceX quer o primeiro — e, com xAI e Colossus, também quer controlar a infraestrutura que torna esses agentes melhores. A Factory quer o segundo: transformar o SDLC em uma linha de produção observável, governável e progressivamente autônoma.

Essa disputa também muda o papel dos engenheiros. Em vez de apenas escrever código, equipes técnicas passam a projetar os sistemas que escrevem, revisam, testam, implantam e monitoram software. A Factory afirma explicitamente que a função dos engenheiros tende a crescer: eles deixam de ser os únicos “custodiantes” da construção do software e passam a ser responsáveis por construir as fábricas que constroem software. (Factory.ai)

Para empresas, a implicação é profunda. A decisão de adoção de IA em engenharia deixa de ser uma escolha de ferramenta — qual editor usar, qual assistente contratar, qual modelo é mais barato — e passa a ser uma decisão de arquitetura organizacional. Quem controla contexto, permissões, rastreabilidade, logs, revisão, deployment e feedback controla o ativo mais valioso da engenharia moderna: o aprendizado acumulado sobre como a organização constrói software.

A aquisição do Cursor pela SpaceX é, portanto, um sinal de consolidação. O lançamento do Factory 2.0 é um sinal de expansão categorial. Juntos, os dois movimentos mostram que a IA para programação está saindo da fase de autocomplete inteligente e entrando na fase de infraestrutura crítica. A pergunta deixou de ser “qual IA escreve código melhor?” e passou a ser “quem vai operar a fábrica onde o software é produzido?”.

A resposta ainda está em aberto. Mas uma coisa parece definida: a próxima guerra de plataformas não será apenas por modelos, GPUs ou IDEs. Será pela cadeia inteira de produção de software — do primeiro ticket ao incidente em produção.

Do "Ok" ao "Termonuclear": Elevando a Barra do Code Review com IA

Emerson Delatorre — Thu, 28 May 2026 23:05:32 +0000

Se você programa profissionalmente, provavelmente já usa IA para gerar trechos de código, preencher boilerplates ou acelerar refatorações pequenas. Mas se a sua rotina de revisão automatizada ainda se resume a caçar vírgulas perdidas, discutir nomenclatura ou repetir checklist cosmético, você está deixando muito dinheiro — e muita sanidade mental — na mesa.

A revisão automatizada com IA só fica realmente poderosa quando deixa de perguntar “o código compila?” e passa a perguntar “esse design merece existir?”. É aqui que entra a mentalidade de Code Review Termonuclear: uma revisão agressiva, estrutural e ambiciosa, voltada para cortar complexidade antes que ela se espalhe pelo projeto.

Essa abordagem ganhou força no ecossistema do Cursor por meio da skill Thermo-Nuclear Code Quality Review, divulgada em discussões recentes sobre agentes de programação. A ideia central é simples: em vez de usar o agente como um linter mais educado, você o instrui a agir como um revisor sênior que questiona arquitetura, fronteiras de tipos, modularidade, testabilidade e acúmulo de complexidade.

Neste artigo, vou reconstruir essa abordagem de forma prática e atualizada para o Cursor, usando os mecanismos corretos da ferramenta hoje: Project Rules, User Rules, Agent Skills e Bugbot.

Por que a maioria dos agentes de IA falha no code review?

Quando você entrega um diff — as linhas alteradas em uma branch — para um LLM convencional, ele tende a se comportar de forma tímida. O agente olha apenas para o trecho alterado, verifica se a sintaxe parece plausível e, no máximo, aponta um detalhe local.

Esse comportamento é insuficiente.

Um bom revisor não avalia apenas a linha adicionada. Ele pergunta:

Essa mudança reforça ou enfraquece a arquitetura?
O código novo espalha exceções e condicionais pelo sistema?
O tipo usado representa a realidade do domínio ou só silencia o compilador?
A implementação ficou mais testável ou mais acoplada?
Existe uma refatoração menor que eliminaria uma categoria inteira de problemas?

A revisão termonuclear começa justamente nesse ponto. Ela usa o diff como ponto de partida, mas não se limita a ele. O objetivo é fazer o agente olhar para o entorno do código e identificar sintomas de deterioração estrutural.

Princípio central: não aprove código apenas porque ele funciona. Código que funciona, mas piora o design, está comprando dívida técnica com juros compostos.

O que torna uma revisão “termonuclear”?

Uma revisão termonuclear não é uma revisão grosseira. Ela é rigorosa, explícita e estrutural. O agente recebe critérios claros para rejeitar soluções frágeis, mesmo quando elas parecem funcionar no curto prazo.

Abaixo estão os padrões mais importantes.

1. A regra das mil linhas

Arquivos muito grandes são ruins para humanos e para agentes de IA.

Quando um arquivo passa de 1.000 linhas, ele normalmente deixa de representar um conceito claro e começa a acumular responsabilidades. Isso torna a navegação mais lenta, a revisão mais cara e o contexto mais difícil de carregar em uma conversa com IA.

A regra não deve ser interpretada de forma infantil. Não significa quebrar arquivos mecanicamente só para reduzir o número de linhas. Significa questionar por que aquele arquivo ficou tão grande.

Boas perguntas para o agente fazer:

Esse arquivo mistura orquestração, regra de negócio, validação e acesso a dados?
Existe uma fronteira natural que permitiria separar responsabilidades?
O nome do arquivo ainda descreve bem tudo o que ele contém?
A divisão proposta melhora a leitura ou apenas espalha a complexidade?

A divisão de arquivos deve criar contexto, não esconder bagunça.

2. Combate a código espaguete e condicionais ad hoc

Um dos sinais mais claros de deterioração arquitetural é o crescimento de condicionais específicas:

if (user.type === 'admin') {
  // regra especial
} else if (user.type === 'partner') {
  // outra regra especial
} else if (featureFlag && user.region === 'BR') {
  // exceção dentro da exceção
}

Esse tipo de código costuma surgir como solução rápida. O problema é que cada nova exceção torna a próxima mudança mais arriscada.

Uma revisão termonuclear deve questionar se a lógica deveria estar em outro formato, como:

uma state machine;
um objeto de política;
uma tabela de decisão;
uma estratégia por tipo de usuário;
uma camada explícita de domínio;
uma configuração declarativa em vez de condicionais imperativas espalhadas.

O objetivo não é trocar if por abstração desnecessária. O objetivo é impedir que exceções locais virem arquitetura acidental.

3. Fronteiras de tipos rígidas

Em TypeScript, um agente de IA tende a usar atalhos para fazer o código “passar”. Os atalhos mais comuns são:

any
unknown
as SomeType
Partial<T>
Record<string, any>

Esses recursos não são proibidos em absoluto, mas devem ser tratados como sinais de alerta.

A revisão deve perguntar:

O tipo representa o contrato real ou apenas evita erro do compilador?
Esse any está escondendo uma integração mal modelada?
Esse as é inevitável ou está mascarando uma inconsistência?
A propriedade é realmente opcional ou virou opcional para evitar corrigir o fluxo?

Um erro muito comum é transformar dados obrigatórios em opcionais:

interface User {
  id?: string;
  email?: string;
}

Se id e email são obrigatórios para o sistema funcionar, o tipo deve expressar isso:

interface User {
  id: string;
  email: string;
}

Opcionalidade artificial espalha incerteza. E incerteza espalhada gera código defensivo, condicionais redundantes e testes mais frágeis.

4. Orquestração paralela vs. sequencial

Outro ponto que uma revisão comum costuma ignorar é a execução sequencial desnecessária.

Exemplo ruim:

const profile = await loadProfile(userId);
const permissions = await loadPermissions(userId);
const preferences = await loadPreferences(userId);

Se essas operações são independentes, elas podem rodar em paralelo:

const [profile, permissions, preferences] = await Promise.all([
  loadProfile(userId),
  loadPermissions(userId),
  loadPreferences(userId),
]);

Uma revisão termonuclear deve procurar esse tipo de desperdício. Nem toda sequência é errada, mas toda sequência independente merece ser questionada.

5. Testabilidade como critério de aprovação

Este é um ponto que muitas skills de revisão deixam fraco: testes.

Não basta perguntar se o código está “limpo”. O agente precisa perguntar se o código é testável.

Critérios úteis:

A regra de negócio pode ser testada sem subir infraestrutura?
Existem pontos de costura para substituir dependências externas?
A mudança adiciona comportamento sem adicionar teste?
O teste cobre o caso feliz e os casos de borda relevantes?
A refatoração preserva cobertura de comportamento?

Um bom code review automatizado não deve aprovar uma mudança crítica em backend, autorização, pagamentos, dados, integrações ou regra de negócio sem questionar testes.

O conceito de “code judo”

Uma das ideias mais fortes da revisão termonuclear é o code judo.

No judô, você usa a força do adversário para derrubá-lo com o mínimo de esforço. No código, um movimento de judô é uma refatoração pequena que elimina uma classe inteira de problemas.

Exemplos:

remover uma camada de helper em vez de criar mais um helper;
substituir múltiplos booleanos por um estado explícito;
trocar condicionais espalhadas por uma tabela de decisão;
mover uma regra para o tipo correto em vez de duplicá-la nos consumidores;
deletar uma abstração genérica que só é usada em um lugar;
transformar um fluxo implícito em uma interface clara.

A pergunta que o agente deve fazer é:

Existe uma mudança menor e mais profunda que elimina complexidade em vez de apenas reorganizá-la?

Essa pergunta é a diferença entre uma revisão cosmética e uma revisão arquitetural.

Como aplicar isso no Cursor hoje

Aqui é importante atualizar o vocabulário.

O Cursor já teve exemplos populares baseados em .cursorrules, mas o caminho recomendado atualmente para regras de projeto é usar Project Rules dentro de .cursor/rules. Para instruções globais, use User Rules. Para workflows especializados e reutilizáveis, use Agent Skills. Para revisão automática de Pull Requests, use Bugbot.

Abaixo está o fluxo atualizado.

Opção 1: Project Rules em `.cursor/rules`

Use Project Rules quando quiser regras específicas de um projeto e versionadas junto com o repositório.

Crie a pasta:

mkdir -p .cursor/rules

Depois crie um arquivo de regra:

touch .cursor/rules/code-review-termonuclear.mdc

Exemplo de conteúdo:

---
description: "Revisão rigorosa de qualidade de código para mudanças antes de PR"
alwaysApply: false
---

#### Revisão Termonuclear de Código

Use esta regra quando eu pedir revisão de código, auditoria de branch, preparação para Pull Request ou refatoração arquitetural.

#### Objetivo

Atue como um revisor sênior extremamente rigoroso. Não limite a análise ao diff. Use o diff como ponto de partida para avaliar arquitetura, modularidade, fronteiras de tipos, testabilidade e complexidade acidental.

#### Critérios obrigatórios

1. Modularidade e coesão
   - Funções, classes, componentes e módulos devem ter responsabilidade clara.
   - Aponte arquivos que misturam UI, regra de negócio, validação, persistência e orquestração.
   - Questione arquivos acima de 1.000 linhas quando não houver justificativa arquitetural forte.

2. Fronteiras de tipos
   - Aponte `any`, casts desnecessários e `unknown` usado como fuga de modelagem.
   - Questione propriedades opcionais que deveriam ser obrigatórias.
   - Prefira contratos explícitos para entradas, saídas e integrações.

3. Complexidade estrutural
   - Procure condicionais ad hoc, flags espalhadas e branches especiais.
   - Sugira state machines, policy objects, tabelas de decisão ou estratégias quando isso reduzir complexidade real.
   - Evite abstrações genéricas sem uso concreto.

4. Testabilidade
   - Aponte ausência de testes quando houver mudança em regra de negócio, backend, permissões, dados ou integrações.
   - Verifique se dependências externas podem ser isoladas.
   - Prefira testes de comportamento a testes que apenas congelam implementação.

5. Code judo
   - Procure uma refatoração pequena que elimine uma categoria inteira de problemas.
   - Priorize deletar complexidade antes de adicionar camadas.

## Formato da resposta

Organize a revisão nesta ordem:

1. Resumo executivo
2. Achados críticos
3. Riscos arquiteturais
4. Problemas de tipagem
5. Lacunas de teste
6. Sugestões de refatoração
7. Movimento de code judo recomendado

Para cada achado, explique:

- o problema;
- o risco;
- onde aparece;
- como corrigir.

Evite comentários cosméticos se houver problemas estruturais mais importantes.

Agora você pode chamar essa regra no Agent do Cursor quando quiser uma revisão mais pesada.

Exemplo:

Revise as alterações da branch atual usando a regra code-review-termonuclear. Procure problemas de arquitetura, tipagem, testabilidade e complexidade acidental.

Ou referenciando arquivos específicos:

Revise @UserService.ts e @UserController.ts usando nossa regra termonuclear. Quero foco em modularidade, fronteiras de tipos e testes.

Opção 2: User Rules globais

Use User Rules para preferências gerais que devem valer em todos os projetos.

No Cursor:

Abra Cursor Settings.
Vá em Rules.
Adicione suas instruções em User Rules.

Exemplo:

Responda de forma direta, técnica e objetiva.
Ao revisar código, priorize arquitetura, tipagem, testes e manutenibilidade.
Evite comentários cosméticos quando houver problemas estruturais mais importantes.
Sempre que possível, proponha uma simplificação que delete complexidade em vez de apenas reorganizá-la.

Atenção: User Rules são úteis para orientar o Agent/Chat, mas não devem ser tratadas como substitutas de Project Rules. Também não é seguro prometer que elas serão aplicadas automaticamente em todo fluxo de edição inline. Para regras críticas de projeto, prefira .cursor/rules.

Opção 3: Agent Skills

Rules são boas para diretrizes persistentes. Skills são melhores para workflows especializados.

Uma Skill do Cursor é um pacote reutilizável de instruções, conhecimento e, quando necessário, scripts auxiliares. Ela normalmente é definida por um arquivo SKILL.md e pode ser acionada pelo Agent quando aplicável ou invocada manualmente pelo usuário.

No caso da revisão termonuclear, você pode usar a skill oficial como inspiração ou criar uma versão própria.

Estrutura possível:

.cursor/skills/thermo-code-review/
  SKILL.md

Exemplo simplificado de SKILL.md:

---
name: thermo-code-review
description: Revisão termonuclear de qualidade de código com foco em arquitetura, tipagem, testes e simplificação estrutural.
---

#### Thermo Code Review

Use esta skill quando o usuário pedir uma revisão rigorosa de código, auditoria antes de PR ou análise estrutural de uma branch.

#### Procedimento

1. Identifique os arquivos alterados.
2. Leia o diff como ponto de partida, não como limite da análise.
3. Avalie modularidade, fronteiras de tipos, testes e complexidade.
4. Procure arquivos grandes demais e responsabilidades misturadas.
5. Sugira pelo menos um movimento de code judo quando houver oportunidade real.
6. Separe achados críticos de sugestões opcionais.

#### Barra de aprovação

Não aprove código que:

- adiciona `any` sem justificativa;
- transforma campos obrigatórios em opcionais por conveniência;
- mistura regra de negócio com UI ou infraestrutura;
- adiciona comportamento relevante sem teste;
- aumenta complexidade estrutural sem necessidade;
- cria arquivos gigantescos sem fronteira clara.

Uso no Agent:

/thermo-code-review
Revise a branch atual antes do PR. Quero uma auditoria dura, com foco em arquitetura, tipos, testes e oportunidades de simplificação.

Essa abordagem é melhor do que entupir uma única regra global com dezenas de instruções. Skills funcionam bem quando você quer um modo de operação específico e reutilizável.

Opção 4: Bugbot para revisão automática de Pull Requests

Se o objetivo é revisar Pull Requests automaticamente, use o Bugbot.

Rules e Skills ajudam dentro do Agent do Cursor. Bugbot é mais adequado para revisão de PR, porque analisa diffs, deixa comentários e pode ser configurado com regras específicas do repositório.

Crie um arquivo:

mkdir -p .cursor
touch .cursor/BUGBOT.md

Exemplo:

# Regras de revisão do Bugbot

Priorize problemas que possam gerar bug, regressão, risco de segurança, inconsistência de dados ou aumento relevante de dívida técnica.

#### O que procurar

- Mudanças em regra de negócio sem teste.
- Uso de `any`, casts desnecessários ou tipos que escondem contratos reais.
- Campos opcionais que deveriam ser obrigatórios.
- Condicionais ad hoc para casos especiais.
- Código sequencial quando operações independentes poderiam rodar em paralelo.
- Arquivos acima de 1.000 linhas sem justificativa clara.
- Captura genérica de erro que engole exceções.
- Mudanças em autenticação, autorização, pagamentos, dados ou integrações sem cobertura adequada.

#### Como comentar

Para cada achado, explique:

1. qual é o problema;
2. por que isso importa;
3. qual correção concreta você recomenda.

Evite comentários de estilo se não houver risco real.

Esse arquivo não substitui revisão humana. Ele funciona como uma primeira barreira automatizada, especialmente útil para capturar problemas antes que o PR chegue ao revisor principal.

Como usar no dia a dia

Antes de abrir um Pull Request

No Agent do Cursor:

Revise a branch atual usando nossa regra termonuclear. Foque em arquitetura, tipagem, testes, arquivos grandes e code judo. Não quero comentários cosméticos.

Ao revisar arquivos específicos

Revise @UserService.ts, @UserController.ts e @UserRepository.ts. Procure responsabilidades misturadas, tipos fracos, lacunas de teste e oportunidades de simplificação.

Ao pedir uma refatoração

Refatore este fluxo para reduzir condicionais ad hoc. Antes de alterar, proponha duas alternativas: uma conservadora e uma com code judo.

Ao endurecer a barra de qualidade

Não aprove a solução se ela depender de any, cast desnecessário, campo opcional artificial ou ausência de teste em regra de negócio.

Onde essa abordagem falha

A revisão termonuclear é poderosa, mas precisa de calibragem.

1. Pode gerar falsos positivos

Um agente ambicioso vai sugerir mudanças que nem sempre compensam. Isso é aceitável desde que os achados sejam fáceis de descartar.

É melhor ter um revisor automatizado que encontra problemas reais e às vezes exagera do que um agente tímido que só comenta formatação.

2. Pode incentivar abstração demais

Nem todo if precisa virar strategy. Nem toda função precisa virar classe. Nem todo arquivo grande precisa ser dividido imediatamente.

A regra correta não é “abstraia tudo”. A regra correta é “remova complexidade acidental”.

3. Pode ignorar contexto de produto

Às vezes, uma decisão técnica aparentemente estranha existe por causa de uma restrição de negócio, legado, prazo ou compatibilidade.

Por isso, a revisão automatizada deve ser tratada como input técnico, não como sentença final.

4. Pode ficar verbosa demais

Prompts longos e repetitivos desperdiçam contexto. Uma boa regra deve ser específica, mas não redundante. O ideal é dividir responsabilidades:

User Rules para preferências globais;
Project Rules para padrões do repositório;
Skills para workflows especializados;
Bugbot para revisão automática de PR.

Conclusão: suba a régua dos seus agentes

Automatizar code review com IA não é transformar o agente em fiscal de estilo. É transformar o agente em uma camada extra de julgamento técnico.

A revisão termonuclear é valiosa porque muda a pergunta central. Em vez de perguntar “isso funciona?”, ela pergunta:

“Essa mudança melhora ou piora a capacidade do sistema de evoluir?”

Esse é o tipo de pergunta que separa um assistente de código comum de um revisor de engenharia realmente útil.

Se você usa Cursor, o caminho mais sólido hoje é combinar quatro mecanismos:

Project Rules em .cursor/rules para padrões versionados do projeto;
User Rules para preferências globais de interação;
Agent Skills para workflows especializados, como revisão termonuclear;
Bugbot para revisão automatizada de Pull Requests.

Com essa combinação, você deixa de depender de prompts soltos e passa a construir um sistema de revisão consistente, repetível e cada vez mais alinhado ao padrão técnico do seu time.

Referências

POCOCK, Matt. Vídeo demonstrativo sobre Code Review Termonuclear. Disponível no Twitter (X): https://x.com/mattpocockuk/status/2059934011124826124?s=20
Cursor Team - "Thermonuclear Code Quality Review" Skill.
https://github.com/cursor/plugins/blob/main/cursor-team-kit/skills/thermo-nuclear-code-quality-review/SKILL.md
Repositório Open Source Sandcastle.
https://github.com/mattpocock/sandcastle

Engenharia de Harness: O Segredo para Agentes de IA que Realmente Entregam Código

Emerson Delatorre — Wed, 29 Apr 2026 18:40:40 +0000

Se você já usou ferramentas como Claude, ChatGPT ou agentes de código para trabalhar no seu repositório, provavelmente já viveu esta montanha-russa emocional: na primeira interação, o agente é um gênio, criando uma função complexa em segundos. Mas, na décima interação de um projeto maior, ele começa a ignorar regras arquiteturais, "esquece" as bibliotecas que você usa e, de repente, seu projeto está quebrado.

Mas por que agentes de Inteligência Artificial tão capazes ainda falham de forma tão dramática em tarefas do mundo real?

A resposta curta: o gargalo não é a inteligência do modelo, é a infraestrutura ao redor dele. É aqui que entra a Engenharia de Harness (ou Harness Engineering), uma disciplina recém-nascida que tem mudado radicalmente como interagimos com os LLMs na engenharia de software.

Recentemente, uma equipe da OpenAI focada em Engenharia de Harness construiu um projeto inteiro gerando um milhão de linhas de código em 1.500 pull requests, e tudo isso com zero código escrito manualmente por humanos. Como? Eles pararam de tentar deixar o modelo mais "esperto" e começaram a focar em construir o mundo ideal para ele operar.

Vamos desmistificar as ideias-chave da Engenharia de Harness e entender como transformar agentes limitados em engenheiros de software autônomos.

1. O que é, afinal, um "Harness"?

Na corrida da IA generativa, todo mundo estava obcecado com a Engenharia de Prompt (a arte de dar a instrução textual perfeita). Mas isso só funciona para tarefas de um único turno.

O Harness (que pode ser traduzido como "arreio" ou "andaime") é a camada de ambiente que governa a execução do agente. É o sistema invisível que define quais ferramentas ele pode executar (como buscar arquivos ou rodar comandos), de onde ele tira conhecimento e como ele valida os próprios erros.

(Pausa para a Regra Sem Jargão: Pense no Harness como as **barreiras laterais de uma pista de boliche. O modelo de IA é a bola rolando em alta velocidade. Sem o Harness, qualquer desvio joga a bola na canaleta, resultando em um código que não compila. O Harness garante que a IA bata na barreira e volte para a pista, acertando os pinos no final).

2. O Fim do "Arquivo de Regras Gigante" (Divulgação Progressiva)

Quando os desenvolvedores percebem que o agente está errando a arquitetura, o instinto inicial é criar um arquivo AGENTS.md colossal. Eles jogam todo o histórico do projeto, todas as dependências e bibliotecas num arquivo só para o agente ler.

O resultado? Isso falha de forma espetacular. Quando tudo no contexto é "urgente e importante", a atenção da IA dilui e ela erra a tarefa principal.

A solução da Engenharia de Harness é a Arquitetura de Contexto via Divulgação Progressiva (Progressive Disclosure). Em vez de um arquivo de mil linhas, o projeto deve ter um mapa compacto que apenas aponta para pastas estruturadas contendo regras específicas (ex: design docs e planos de execução).

(Sem Jargões: É como **ir a um restaurante. O cardápio não te dá a receita completa e o modo de preparo de todos os pratos na primeira página. Ele te dá uma lista enxuta. Se você quiser saber os ingredientes de um prato específico, você pergunta ao garçom. O agente de IA deve fazer o mesmo: navegar dinamicamente pelas pastas sob demanda em vez de tentar decorar tudo de uma vez).

3. O Repositório como o "System of Record"

Aqui vai uma verdade inconveniente: o seu agente de IA não acessa suas planilhas ágeis e não leu sua última conversa no Slack.

Um dos preceitos mais vitais expostos pelas práticas da OpenAI é tratar o seu repositório de código como o System of Record (A Única Fonte da Verdade).

Se uma regra arquitetural, a lista de funcionalidades (feature lists) ou a documentação de um débito técnico não estiver detalhada em um documento estruturado dentro do código, o agente vai alucinar tentando adivinhar as regras. O ambiente do agente se torna autossuficiente: planos efêmeros, contratos de sprint e status de qualidade devem estar em formato de texto junto ao código, sendo lidos constantemente a cada nova tarefa do agente.

4. Guardrails e o Autoconserto da IA

Agentes erram, não importa o quão bom seja o modelo. A Engenharia de Harness não busca impedir o erro, mas criar Ciclos de Feedback de Observabilidade, onde o próprio ambiente denuncia o erro para a IA se arrumar.

(Sem Jargões: O código é cercado por "Linters" e "Testes Estruturais", que são como um **corretor ortográfico do Microsoft Word de alta precisão. Quando o agente tenta subir algo quebrando as camadas da arquitetura, essas ferramentas barram o arquivo automaticamente e devolvem um erro explícito à IA. O agente lê o erro, percebe o que quebrou e reescreve a funcionalidade sem que o humano precise intervir).

Em resumo, a automação age não como uma catraca burra, mas fornecendo contexto de como arrumar o problema, criando uma telemetria valiosa para a autonomia do código.

Conclusão: Uma Nova Fronteira

O que a revolução liderada por times de vanguarda na OpenAI e Anthropic nos mostra é uma profunda mudança de paradigma para engenheiros. O gargalo da confiabilidade foi diagnosticado.

O desenvolvedor de amanhã passará muito menos tempo digitando linhas manuais e se dedicará profundamente à arquitetura do ambiente. A missão passará a ser a criação de excelentes Harnesses — com pipelines contínuos de autoavaliação, documentação navegável por robôs e escopos bem delineados.

A IA assumirá as linhas de código brutas, mas os engenheiros criarão as pistas para que elas finalmente consigam rolar com velocidade e direção certas.

Dominando o Claude Code: O Guia Definitivo Passo a Passo (com Exemplos Práticos)

Emerson Delatorre — Sun, 26 Apr 2026 19:37:31 +0000

Olá de novo, Fazedores de Código! Aqui é o Emerson Delatorre. Se no nosso papo anterior nós arranhamos a superfície dessa ferramenta incrível, hoje nós vamos colocar a mão na massa de verdade. A pedido de vocês, mergulhei fundo na palestra do Boris (o criador do Claude Code na Anthropic) e trouxe um manual prático, cheio de detalhes, exemplos reais e o passo a passo exato que ele demonstrou no palco.

Preparem seus terminais, porque vamos transformar a forma como vocês interagem com o código.

Passo 1: O Setup Otimizado (Preparando a Casa)

Antes de sair codificando, você precisa ajustar as ferramentas do seu CLI (Command Line Interface, aquela "tela preta" do terminal). O Claude Code possui comandos curtos (que começam com /) para facilitar sua vida.

Como fazer:
Logo após instalar a ferramenta (com npm install -g @anthropic-ai/claude-code), Boris recomenda rodar os seguintes comandos:

/terminal-setup: Ativa o Shift+Enter para pular linhas no terminal sem enviar o comando antes da hora (o que poupa o uso de barras invertidas irritantes).
/theme: Permite escolher o modo claro, escuro ou até temas para daltônicos.
/install-github-app: Instala um aplicativo que permite que você marque @claude diretamente nas issues (tarefas) ou Pull Requests do seu repositório.
/allowed-tools: Personaliza quais ferramentas precisam da sua aprovação manual para rodar (ótimo para evitar que ele te pergunte toda hora se pode ler um arquivo inofensivo).
Dica Ninja para MacOS: Vá em Configurações > Acessibilidade > Ditado, configure um atalho rápido e simplesmente fale seus prompts em vez de digitar.

Passo 2: O Ponto de Partida – Perguntas e Respostas (Q&A)

A forma mais fácil de começar e extrair valor imediato (sem precisar configurar nada) é fazer perguntas sobre o seu projeto (Codebase Q&A). Seus dados ficam na sua máquina e você ganha um guia turístico do seu próprio código.

Como fazer:
Use o símbolo @ para mencionar arquivos ou pastas específicas para que o Claude as leia.

Exemplos Práticos demonstrados:

"Como o @RoutingController.py é usado?"
"Por que o método recoverFromException recebe tantos argumentos? Olhe o histórico do git para responder." (Sim, ele lê o histórico, o blame e os PRs antigos!)
"O que eu enviei para produção na semana passada?" (Excelente para se atualizar numa segunda-feira de manhã).

Passo 3: Encadeamento e Direcionamento (O "Think Hard")

Uma vez confortável, você não vai apenas perguntar, vai mandar fazer. O segredo aqui é especificar o seu fluxo de trabalho, encadeando múltiplas ações em uma única frase.

Exemplos Práticos:

"Proponha algumas correções para a issue #8792, **em seguida* implemente a que eu escolher."* (Isso cria um ponto de controle seguro para você revisar).
"Identifique casos extremos (edge cases) não cobertos em @app/tests/SignupTest.ts, **em seguida* atualize os testes para cobri-los. Pense bastante (Think hard)."* (O "think hard" diz ao Claude para gastar mais tempo raciocinando antes de agir).
"Faça o commit, o push e abra o PR." (Ele encadeia operações completas do Git de uma vez só).

Você também pode ensinar ferramentas da sua empresa a ele. Se você tem um script interno no terminal chamado barley, basta dizer: "Use a CLI barley para checar logs de erro; use -h para descobrir como usá-la." Ele vai ler o manual de ajuda e executar a tarefa.

Passo 4: Como Montar o `CLAUDE.md` Corretamente

Programadores se amarram em padrões, e o CLAUDE.md é a forma de garantir que a IA não quebre os padrões da sua equipe. É aqui que você dá contexto persistente: coisas que o Claude deve lembrar em todas as sessões.

A Estrutura de Pastas (Hierarquia):

/CLAUDE.md: Regras globais da sua empresa.
~/.claude/CLAUDE.md: Suas regras pessoais para todos os seus projetos.
CLAUDE.md (na raiz do projeto): Regras do time, que você deve salvar no Git.
CLAUDE.local.md: Suas anotações pessoais do projeto (que o Git ignora).

Como preencher o arquivo:
Escreva como se estivesse orientando um desenvolvedor júnior que acabou de entrar na equipe.

"Sempre use pnpm, nunca use npm."
"Rode os testes usando make test, não use pytest."
"Nosso estilo de código usa indentação de dois espaços."
"Quando você fizer um commit, use o padrão de conventional commits (mensagens com prefixos como fix:, feat:, etc.)."

Dica Prática: Você não precisa abrir o arquivo para editar. Apenas digite o atalho # no terminal, escreva a regra, e o Claude perguntará em qual arquivo ele deve salvar isso.

Passo 5: Multi-Agentes (O Exército de Claudes em Paralelo)

Aqui é onde a cabeça explode. Segundo Boris, rodar o Claude em paralelo muda completamente o volume de entregas que você consegue fazer. O modelo mental correto é: Cada aba do terminal rodando o Claude é um engenheiro diferente trabalhando para você.

Por que pedir para um engenheiro fazer cinco coisas em série (uma depois da outra) se você tem cinco engenheiros disponíveis? Crie um agente para consertar os testes, outro para escrever a documentação e um terceiro para refatorar o código base. Eles não vão brigar ou atrapalhar o trabalho do outro.

Como usar Multi-Agentes na prática (4 Métodos):

Múltiplas abas / Múltiplos clones: Você simplesmente clona o mesmo repositório em pastas diferentes e abre uma aba do terminal para cada um.
Git Worktrees: Esta é uma funcionalidade poderosa do Git.
- (Sem jargões): O "Git Worktree" permite que você tenha várias "filiais" (branches) do mesmo projeto abertas em pastas diferentes ao mesmo tempo, sem precisar clonar tudo de novo. O núcleo (.git) é compartilhado, mas os arquivos visíveis são diferentes. Você bota um Claude trabalhando em uma pasta (branch A) e outro em outra pasta (branch B).
SSH + tmux:
- (Sem jargões): SSH é como você acessa um servidor remoto de forma segura. O "tmux" é um programa que divide a tela preta desse servidor em vários "quadradinhos" independentes. Você pode colocar um Claude rodando em cada quadrado remotamente.
GitHub Actions:
- (Sem jargões): É o sistema de automação do GitHub. Você configura robôs para rodarem tarefas automaticamente quando alguém envia código. Você pode disparar várias dessas ações (jobs) em paralelo, e dentro de cada uma, o Claude Code resolve um problema diferente através do Claude Code SDK (versão focada em automação de código, não interação via terminal).

O Lembrete do Fazedor de Código

O objetivo do Claude Code não é substituir o seu cérebro de desenvolvedor. Como o próprio Boris destacou na sessão de perguntas e respostas, você continua sendo a pessoa que decide o que deve ser construído.

Você escreve a especificação, o Claude rascunha a obra pesada e você faz a revisão de código no final. Usem essa ferramenta para ganhar tempo, padronizar projetos via CLAUDE.md e automatizar o tédio. O design refinado do software continua sendo de responsabilidade de vocês!

Um abraço, e bom código!

SDD e o Fim do "Vibe Coding": O Futuro do Desenvolvimento Guiado por IA

Emerson Delatorre — Fri, 10 Apr 2026 18:04:24 +0000

Fala, pessoal! Muito prazer, aqui é o Emerson Delatorre. Tive a honra de bater um papo sensacional no canal D.E.P.L.O.Y. com o Felipe sobre um tema que está virando a nossa área de cabeça para baixo: o uso de Inteligência Artificial no desenvolvimento de software. Como desenvolvedor, criador do Fazedor de Código e professor, eu vejo muita gente perdida nessa transição.

Hoje, a produtividade trazida pela IA é inegável, com empresas relatando aumentos absurdos de entregas. Mas existe uma armadilha perigosa no meio desse caminho. Vamos falar sobre como domar a IA usando o Spec-Driven Development (SDD) e por que você precisa abandonar o código na base do "achismo".

A Armadilha do "Vibe Coding"

A primeira vista, a IA parece mágica. Surge então o conceito de Vibe Coding (codificação por intuição).

Você joga um prompt (comando) vago na ferramenta — "faça uma landing page linda com cores frias e sem erros" —, aceita o código gerado e reza para funcionar. Pense nisso como delegar a fundação de um prédio para um estagiário muito confiante, mas sem nenhuma planta ou supervisão. Ele vai entregar algo rápido, mas que pode desmoronar na primeira ventania.

O resultado do Vibe Coding em larga escala é catastrófico. As IAs perdem o contexto, alucinam sob pressão e criam um débito técnico gigantesco. Não é à toa que já temos relatos de milhares de bugs (falhas no código) introduzidos por IAs que chegaram sorrateiramente aos ambientes de produção.

A IA não substitui a base técnica. Ela te acelera, mas quem dita as regras do jogo e avalia a qualidade da entrega é você.

O Santo Graal: Spec-Driven Development (SDD)

Para não cairmos na armadilha do estagiário sem supervisão, precisamos do SDD (Spec-Driven Development).

O SDD é uma metodologia de desenvolvimento guiada por especificações. Antigamente, nós tínhamos o PRD (Product Requirements Document - um documento de requisitos que detalha o que o produto deve fazer, como um manual de instruções antes da fabricação), que muitas vezes ficava obsoleto rápido.

Com o SDD, temos uma inversão de valores: o código deixa de ser a única fonte da verdade, e a especificação legível por máquina assume esse papel. O código se torna quase descartável e recriável; a especificação é o que importa.

Como o SDD se integra com outras metodologias:

TDD (Test-Driven Development): Desenvolvimento orientado a testes. Pense nisso como criar o gabarito da prova antes de responder às questões. O teste falha primeiro, você cria o código para ele passar e depois melhora (Red, Green, Refactor).
BDD (Behavior-Driven Development): Desenvolvimento orientado a comportamento. Define cenários práticos do tipo "Quando o usuário fizer X, o sistema deve fazer Y".

O SDD cria o artefato principal. Baseado nele, geramos os cenários do BDD. A partir dos cenários, criamos os testes do TDD. E, finalmente, geramos o código. É uma cordinha de segurança que garante que a IA só caminhe por onde você determinou.

As Fases Práticas do SDD

Trabalhar com SDD exige um fluxo bem definido, precedido por uma fase de Research (pesquisa e "brainstorming" com a IA para formar uma base de conhecimento). O ciclo oficial é:

Especificação: Uma descrição de alto nível da intenção da feature (funcionalidade). É o "o que" vamos fazer.
Plano Técnico: Decisões de arquitetura. É o "como" vamos fazer (quais tecnologias, configurações, contratos de API).
Decomposição em Tarefas: Quebrar o plano em pequenas tarefas sequenciais e dependentes. É como fatiar um bolo inteiro em pedaços mastigáveis para a IA não se engasgar.
Validação e Implementação: Você age como o engenheiro revisor. Se o plano e as tarefas fazem sentido, você aprova. Só então o agente de IA começa a implementar o código, e você o valida (geralmente através de testes automatizados).

E o Projeto Legado? (O Famoso "Brownfield")

É fácil aplicar SDD em um projeto novo e do zero (Greenfield). Mas e quando entramos num Brownfield?

Um Brownfield é um projeto legado, antigo, que funciona como um campo minado: qualquer passo errado pode quebrar a aplicação inteira. Como aplicar SDD sem pedir para a IA reescrever o sistema inteiro (o que gastaria dinheiro e geraria o caos)?

Usamos a estratégia de Spec Untouched (Especificação Intocada) e Spec Anchor (Especificação Âncora):

Spec Âncora: Criamos uma regra central e rigorosa sobre a estrutura do projeto legado para que a IA entenda os limites.
Foco Orgânico: Criamos especificações e documentações apenas para o raio de impacto da nossa alteração. À medida que o time trabalha, a base de código vai ganhando cobertura e organização organicamente, sem loucuras.

Ferramentas do Ofício

Para orquestrar tudo isso, não podemos fazer tudo na mão. Aqui estão algumas ferramentas fundamentais que comentei na live:

Ferramenta	O que faz	Analogia
GitHub SpecKit	Orquestra especificações usando um documento "Constituição" para guiar a IA, de forma agnóstica (funciona com vários modelos).	É o gerente de projetos rígido que não deixa ninguém sair das regras da empresa.
Claude Code (CLI)	Assistente direto no terminal (Command Line Interface - a telinha preta de comandos) para executar workflows e automatizações complexas.	O operário de elite que constrói a infraestrutura diretamente no canteiro de obras.
G-Stack	Um workflow completo onde diferentes agentes de IA (um CEO, um Revisor) avaliam o projeto de forma autônoma.	Uma sala de reunião virtual onde robôs discutem a qualidade do seu trabalho.
Taíl	Um registro e gerenciador de contextos e habilidades de IA, que já faz análise de segurança e performance.	Uma loja de aplicativos apenas para "superpoderes" seguros para a sua IA.

O Futuro do Desenvolvedor: O Arquiteto de Intenções

Estamos saindo da era de ficar horas digitando código no teclado. Nosso papel está mudando para Arquiteto de Intenções.

Nós saímos do foco micro (o "como" escrever a linha de código) para o foco macro (o "que" precisa ser resolvido e qual o impacto no negócio). Se antes programar era escrever estruturas de repetição em um papel na faculdade, hoje é criar um contexto perfeito para que um modelo avance 80% do trabalho chato, deixando os 20% cruciais da validação e arquitetura nas suas mãos.

As ferramentas de IA são excelentes, mas lembre-se: a responsabilidade pelo que vai para o repositório é e sempre será sua. Estude a base técnica, invista no seu inglês, crie sua rede de contatos e mantenha seu GitHub organizado. A régua do mercado subiu, e quem souber orquestrar essas inteligências de forma responsável vai ditar o ritmo dessa nova era.

Fonte:

Como Construir um Blog com Astro e Inteligência Artificial (Sem Perder o Controle do Código)

Emerson Delatorre — Thu, 05 Mar 2026 14:56:08 +0000

Se você já teve um artigo técnico retirado do ar sem explicações por uma plataforma de terceiros, sabe que a melhor solução é ter o seu próprio espaço. Mas como construir um blog do zero de forma rápida e, o mais importante, com código de qualidade?

Neste artigo, vamos explorar como utilizar o Astro em conjunto com assistentes de Inteligência Artificial para criar um blog. Mais do que apenas gerar código aleatório, vamos aplicar o que o mercado anda chamando de "Vibe Code" — mas com uma dose pesada de Engenharia de Software real.

1. Esqueça o "Vibe Code", Pense em Engenharia

O termo "Vibe Code" (desenvolver software conversando de forma solta com a IA) está na moda, mas projetos sérios exigem mais do que isso. Para que a inteligência artificial não alucine e gere um código impossível de manter, precisamos dar contexto e estruturar bem o começo do projeto.

É aqui que entra o SpecKit.

Sem Jargões Deixados Para Trás: O SpecKit é um projeto de código aberto do GitHub que funciona como um "arquiteto de software" para a sua IA. Ele te obriga a seguir uma linha rígida de especificações, montando uma documentação prévia antes de escrever qualquer linha de código.

2. Escrevendo a "Constituição" do seu Código

A primeira etapa do nosso desenvolvimento não é programar, mas sim criar um arquivo de Constituição. Pense nisso como as "leis sagradas" que a IA deve seguir durante todo o projeto.

Para garantir a qualidade e a manutenibilidade do nosso blog, definimos as seguintes regras para a IA:

Astro v5.18.0: Especificamos a versão exata do framework para evitar que a IA use dependências defasadas.
Boas Práticas Rigorosas: Exigimos a aplicação de Clean Code, SOLID, YAGNI e Object Calisthenics.
Nota rápida (Sem Jargões): Esses são conjuntos de regras e filosofias de programação que forçam o código a ser simples, limpo e orientado a objetos. O YAGNI (You Aren't Gonna Need It), por exemplo, diz para não criarmos funcionalidades até que elas sejam estritamente necessárias.

Para adicionar essa camada de regras, utilizamos diretrizes (guidelines) customizadas do GitHub Copilot focadas em TypeScript e desenvolvimento no Astro.

3. Estratégia de Modelos: O Cérebro e os Músculos

Quando lidamos com LLMs (Grandes Modelos de Linguagem), a Janela de Contexto — a "memória de curto prazo" da IA — enche rápido. Se passar de 50% ou 60% da capacidade, a IA começa a cometer erros e "alucinar".

Por isso, dividimos o trabalho em duas frentes:

O Planejador (Claude Opus): Usamos um modelo poderoso e robusto (como o Opus) para ler a documentação, entender a Constituição e criar as especificações e tarefas (tasks). O resultado é um planejamento contendo modelagem de dados e requisitos funcionais para um MVP.

Nota (Sem Jargões): MVP (Minimum Viable Product) é a versão mais básica do seu projeto que já funciona e entrega valor.

O Operário (Codex): Como o Opus tem um custo computacional muito alto, trocamos para um modelo mais leve, rápido e especializado em código (como o Codex) no momento de implementar as tarefas na prática.

4. Sub-agentes e Implementação Paralela

Com a especificação pronta, a mágica da automação acontece. A ferramenta não precisa executar uma tarefa por vez; ela utiliza Sub-agentes trabalhando em paralelo.

Sem Jargões Deixados Para Trás: Sub-agentes são como vários "mini-programadores virtuais" que a IA principal contrata para fazer partes diferentes do trabalho ao mesmo tempo. Enquanto um configura o Tailwind (ferramenta de estilo) , o outro cria os utilitários de data e hora.

Ao final da execução paralela dessas dezenas de tarefas (foram 37 no total!) , obtivemos um build de sucesso. A IA entregou um blog funcional, com página inicial, listagem de artigos, sistema de tags e até uma página "Sobre" baseada no perfil do autor.

Dica Bônus para Estudantes

Construir projetos auxiliados por IA consome tokens (a moeda de processamento das IAs), o que pode ser caro. Se você é estudante, acesse o GitHub Student Developer Pack. Ele oferece acesso gratuito a ferramentas premium, incluindo o GitHub Copilot Pro e créditos em infraestrutura de nuvem.

Conclusão

Usar IA para gerar aplicações não significa abandonar as boas práticas. Ao utilizar ferramentas como o SpecKit e impor regras arquiteturais (Clean Code, SOLID), nós transformamos o que seria um amontoado de código gerado aleatoriamente em um produto de software escalável, mantendo o controle total do nosso ambiente e do nosso conteúdo.

Referências

github / spec-kit

💫 Toolkit to help you get started with Spec-Driven Development
🌱 Spec Kit

Define what to build before building it — with any AI coding agent.

An open source toolkit for building high-quality software with any AI coding agent — a ready-to-use spec-driven process (or bring your own), endlessly extensible, community-driven, and built for your whole organization.

English · 简体中文

Table of Contents
🤔 What is Spec-Driven Development?

Spec-Driven Development flips the script on traditional software development. For decades, code has been king — specifications were just scaffolding we built and discarded once the "real work" of coding began. Spec-Driven Development changes this: specifications…
View on GitHub
Astro

Astro builds fast content sites, powerful web applications, dynamic server APIs, and everything in-between.

astro.build

GitHub Student Developer Pack - GitHub Education

The best developer tools, free for students. Get your GitHub Student Developer Pack now.

education.github.com

Desvendando a Caixa Preta: O Guia Definitivo de IA e Machine Learning

Emerson Delatorre — Tue, 03 Mar 2026 13:50:23 +0000

1. Introdução: O Que Acontece Debaixo do Capô?

Vivemos um momento singular na história. Ferramentas de Inteligência Artificial estão em todos os lugares, dos nossos celulares aos sistemas corporativos mais complexos. Mas existe um abismo entre usar a tecnologia e entender como ela funciona.

A maioria das pessoas trata a IA como uma "caixa mágica": você faz um pedido e ela cospe um resultado. O problema é que, se você não sabe como a mágica é feita, você fica refém dela. Este artigo é o seu convite para levantar o capô do carro, sujar as mãos de graxa (metaforicamente!) e entender as engrenagens que estão movendo o mundo. Vamos transformar conceitos complexos em algo que você possa explicar na mesa do jantar.

2. A "Cebola" da Tecnologia

Primeiro, vamos organizar a sopa de letrinhas. Muita gente usa os termos abaixo como sinônimos, mas existe uma hierarquia clara, como camadas de uma cebola:

Inteligência Artificial (IA): é o termo "guarda-chuva". Qualquer técnica que permita a um computador imitar o comportamento humano (raciocínio, visão, fala) entra aqui.
Machine Learning (Aprendizado de Máquina): é o motor principal. Aqui, o sistema não segue apenas regras fixas escritas por um humano; ele aprende a identificar padrões analisando dados.
Deep Learning: Uma camada mais profunda do Machine Learning, inspirada nos neurônios humanos, capaz de aprender com dados muito complexos.
IA Generativa (LLMs): A "estrela do momento" (como o GPT, Gemini, Claude). Diferente das anteriores, que apenas analisam ou classificam, esta aqui cria conteúdo novo (texto, imagem, código).

A Mudança de Mentalidade

Na programação tradicional, a regra é clara e rígida: "Se o cliente gastou mais de R$ 100, dê 10% de desconto". É determinístico.

No Machine Learning, você muda o jogo. Você não dá a regra. Você joga uma montanha de dados para o computador (histórico de vendas, perfis de clientes) e diz: "Descubra o padrão de quem costuma comprar mais". A máquina cria a regra para você baseada no comportamento real.

3. Os Três Sabores do Machine Learning

Como a máquina aprende? Existem três "escolas" principais de ensino, aplicáveis a qualquer setor:

3.1. Aprendizado Supervisionado (O Aluno com Gabarito)

Você entrega os dados já "rotulados" com a resposta certa.

Como funciona: Você mostra 10 mil fotos de gatos e diz "isso é gato", e 10 mil de cachorros e diz "isso é cachorro".
No Mundo Real: Previsão de preços de casas (baseada em tamanho e localização), filtros de spam no e-mail ou diagnóstico médico por imagem.

3.2. Aprendizado Não Supervisionado (O Detetive)

Você entrega os dados bagunados, sem rótulos, e pede para a máquina organizar.

Como funciona: A máquina analisa os dados e agrupa o que é parecido, encontrando estruturas que o olho humano não veria.
No Mundo Real: Segmentação de clientes para marketing (agrupar por hábitos de compra), recomendação de filmes em streaming ou detecção de fraudes em cartão de crédito (encontrando transações que fogem do padrão).

3.3. Aprendizado por Reforço (A Tentativa e Erro)

Analogia Sem Jargão: É como treinar um pet ou ensinar uma criança a andar de bicicleta. Se a ação for boa, o sistema ganha uma "recompensa" (pontos). Se for ruim, ganha uma penalidade.
No Mundo Real: Robôs aprendendo a andar, carros autônomos ou IAs que jogam xadrez e videogames.

4. O Ciclo de Vida: Cuidado com o "GIGO"

Antes de confiar em qualquer IA, lembre-se do conceito mais importante de dados:

Conceito-Chave: GIGO (Garbage In, Garbage Out).
Traduzindo: "Lixo entra, lixo sai". Se a sua empresa ou projeto alimentar a IA com dados ruins, desatualizados ou enviesados, o resultado será uma decisão errada, não importa quão cara ou moderna seja a tecnologia.

O sucesso não está no algoritmo, está na qualidade dos dados que você fornece.

5. Por Dentro da IA Generativa (LLMs)

Como o ChatGPT ou o Gemini conseguem escrever um poema ou resumir um livro? Eles não "leem" como nós.

5.1. Tokenização: Tudo vira Lego

A IA quebra o texto em pedacinhos chamados Tokens.

Sem Jargão: Imagine um Lego. A palavra "Inconstitucionalissimamente" pode ser quebrada em várias pecinhas menores. O modelo cobra e processa por "pecinha", não por palavra inteira.

5.2. Embeddings: O Mapa Matemático

Depois de virar token, a palavra ganha uma coordenada numérica.

Sem Jargão: É como um GPS de significados. A palavra "Rei" fica matematicamente próxima de "Rainha". A palavra "Médico" fica perto de "Hospital". É assim que a IA sabe quais conceitos estão relacionados, calculando a distância entre eles.

5.3. Mecanismo de Atenção (Attention Mechanism)

É o segredo do sucesso. O modelo consegue pesar a importância de cada palavra em uma frase longa para manter o contexto.

Exemplo: Na frase "O banco fechou porque o dinheiro acabou", a IA sabe que "banco" se refere à instituição financeira, não ao assento de praça, por causa da relação com a palavra "dinheiro".

6. O Lado Sombrio: Riscos e Cuidados

Nem tudo é perfeito. Seja você um estudante ou um CEO, precisa estar atento a dois perigos:

Alucinação: A IA pode inventar fatos com total confiança. Ela é treinada para ser convincente, não necessariamente para ser verdadeira. Regra de ouro: Sempre verifique a informação.
Privacidade: Dados inseridos em ferramentas públicas muitas vezes são usados para treinar o modelo.

7. O Guia de Decisão: Qual ferramenta usar?

Para fechar, um guia rápido para você saber qual tecnologia aplicar no seu problema:

Seu Objetivo	Ferramenta Indicada	Exemplo Prático
Prever um número ou classificar algo com base no passado.	Machine Learning Supervisionado	Prever vendas do próximo mês ou risco de crédito.
Criar conteúdo, resumir textos ou interagir via chat.	IA Generativa (GenAI)	Escrever e-mails de marketing, criar imagens ou resumir reuniões.
Descobrir padrões ocultos ou anomalias em dados brutos.	Machine Learning Não Supervisionado	Identificar perfis de clientes ou falhas em máquinas na fábrica.

Conclusão: O Novo Normal

Entender a distinção entre Machine Learning tradicional e IA Generativa, e saber os riscos de alucinação e privacidade, deixa de ser um diferencial técnico e passa a ser uma competência essencial de alfabetização digital.

Agora você possui um "framework" mental. Da próxima vez que ouvir falar sobre uma nova IA revolucionária, você não será apenas um espectador passivo deslumbrado com a mágica. Você saberá olhar para as engrenagens, questionar a qualidade dos dados (GIGO) e decidir se aquela é, de fato, a ferramenta certa para o problema que você precisa resolver.

De 3 Dias de Trabalho para 15 Minutos: O Segredo da Automação com IA

Emerson Delatorre — Tue, 03 Mar 2026 13:47:32 +0000

Fala, pessoal! Fazedordecodigo por aqui.

Na nossa ltima aula, ns tocamos em um ponto que o sonho de consumo de qualquer profissional: parar de gastar horas copiando e colando dados de planilha para transformar dias de trabalho braal em minutos de processamento com Inteligncia Artificial.

Se voc daqueles que gasta sua sexta-feira gerando relatrios no Word e mandando e-mail, pare tudo. Vou resumir aqui o mtodo que ensinei para transformar um analista cansado em um "Engenheiro de Prompt" de elite.

O Problema: A "Sofrncia" Manual

Comecei a aula trazendo um cenrio bem real. Imaginem a rotina clssica de uma rea de qualidade ou manuteno:

Baixar dados de 10 mquinas na unha.
Validar linha por linha no Excel.
Calcular o OEE (Eficincia Global do Equipamento).
Identificar onde estamos perdendo dinheiro.
Escrever um relatrio no Word.
Disparar e-mail para a gesto.

Tempo gasto: Cerca de 3 dias de trabalho "picado" ou aquelas 3 horas ininterruptas de foco total que a gente nunca tem.

Minha proposta na aula: Fazer tudo isso em 15 minutos.

Como? No mgica, mtodo. E apresentei a vocs o meu framework favorito: o CICLO.

A Estrutura Mestra: O Framework CICLO

Para garantir que a IA no v "alucinar" e entregue exatamente o que precisamos, ensinei o acrnimo CICLO. Vamos relembrar cada etapa:

1. C - Contexto (O Contrato)

Aqui definimos o "palco".

Exemplo:"Voc um Analista de Manuteno da indstria qumica. Sua meta analisar a eficincia dos equipamentos crticos..."

Se a gente no d o contexto, a IA fica igual quele estagirio genial que acabou de chegar no prdio e no sabe nem onde fica o banheiro. Potencial alto, direo zero.

2. I - Input (A Entrada de Dados)

Aqui entra a regra que bati na tecla com vocs: Garbage In, Garbage Out (Lixo entra, Lixo sai).

Se a planilha vier com clulas vazias ou erros de digitao (como um caractere estranho no meio do nome de uma cidade, como vimos acontecer), o resultado ser ruim.

Ao: Instru vocs a limparem os dados antes ou pedirem para a IA validar a integridade logo de cara.

3. C - Cascade (Processamento em Etapas)

Essa a grande sacada que mostrei. No peam para a IA "fazer tudo de uma vez". Dividam o problema em etapas lgicas, onde o resultado da Etapa 1 alimenta a Etapa 2.

Etapa 1: Ingesto e validao.
Etapa 2: Clculo de mtricas.
Etapa 3: Anlise de causa raiz.
Etapa 4: Recomendaes.

Isso cria um fluxo de pensamento que reduz erros drasticamente.

4. L - Output (A Sada)

Como queremos receber isso? Poema? Cdigo? Tabela?

No nosso exerccio, pedi um Relatrio Executivo em Markdown.

Para quem no lembra: Markdown aquela formatao simples de texto (usar ** para negrito, # para ttulos). A IA adora porque leve e estruturado.

5. O - Optimize (Otimizao Oculta)

A camada final onde a IA revisa o prprio trabalho, verificando consistncia dos clculos e se o tom de voz est adequado (profissional, direto, sem enrolao).

O Desafio Tcnico: A Porta do Quarto (Janela de Contexto)

Durante a aula, surgiu uma dvida excelente sobre manter o histrico da conversa ou abrir um chat novo. Usei uma analogia que gosto muito:

"Imaginem a porta do quarto de vocs. Ela tem uns 70cm de largura. Se voc tenta passar um sof de 2 metros (muita informao/histrico longo), ele no passa."

Isso a Janela de Contexto.

O Problema: Conforme conversamos com a IA, a memria dela enche. Chega uma hora que, para caber coisa nova, ela comea a "esquecer" ou resumir o comeo da conversa.
Minha Recomendao: Tarefa nova? Chat Novo. Copiem o prompt mestre, colem em um chat limpo e subam os dados novos. Isso garante que a IA est com a "mente fresca".

Dica de Ouro: Chats Temporrios

Tambm discutimos sobre evitar "sujeira" no cache (o famoso bug onde a IA para de responder). A dica que surgiu foi usar Chats Temporrios ou abas annimas para tarefas pesadas e repetitivas, evitando que o sistema tente carregar histricos gigantes desnecessrios.

Por que a IA respondeu diferente para cada um?

Vimos um caso curioso onde duas pessoas rodaram o mesmo prompt , mas tiveram resultados diferentes (uma IA foi prestativa, a outra mandou um "se vira" mais rgido com erros). Por que isso acontece?

Probabilidade: Os modelos de linguagem ( LLMs ) no so calculadoras exatas. Eles trabalham com probabilidade, "chutando" a prxima palavra. s vezes, o caminho muda levemente.
Temperatura: Configuraes internas de criatividade do modelo.
Verso: Diferenas de licena ou verso (GPT-4 vs GPT-3.5) impactam drasticamente a capacidade de raciocnio.

Resumo da pera

Conceito

O que eu quero que vocs levem

|
|

Framework CICLO

o roteiro para o prompt perfeito. Usem sempre.

|
|

Garbage In/Out

Dados ruins geram respostas ruins. Validem antes.

|
|

Janela de Contexto

Tarefa recorrente exige Chat Novo. No acumulem lixo.

|
|

Markdown

Peam o output assim para terem relatrios bonitos e rpidos.

Concluso

Pessoal, provei na aula que automao no sobre saber programar, sobre saber pedir e estruturar o raciocnio. Sair de 3 dias de trabalho para 15 minutos inteligncia operacional.

Como eu disse no final: isso viciante. Depois que voc comea a automatizar, no consegue mais ver uma tarefa manual sem sentir aquela agonia para criar um prompt e resolver logo.

Levem esse conhecimento para o dia a dia e pratiquem. Semana que vem a gente aprofunda em anlise de dados!

Fiquem com Deus e bom trabalho!

]]>

Gemini 3: O Google Parou de "Ler Texto" e Começou a "Ler o Ambiente"

Emerson Delatorre — Tue, 03 Mar 2026 13:46:24 +0000

Introduo: Chegou a Era do "Faz pra Mim"

Fala, galera de tecnologia! Aqui o FazedorDeCodigo.

Vocs lembram quando a gente ficava impressionado porque a IA conseguia escrever um poema (meio ruim) sobre batatas? Pois , isso to 2023. Estamos em novembro de 2025, e o Google acabou de chutar a porta com o lanamento do Gemini 3.

Eu li a documentao tcnica e os anncios oficiais para que voc no precise ler (mas os links esto l no final, e eu recomendo!). A grande manchete aqui no apenas "mais velocidade" ou "mais parmetros". A mudana filosfica: o Google afirma que a IA evoluiu de apenas processar o que voc escreve para entender a sua inteno.

Sabe aquele estagirio que voc precisa explicar 10 vezes a mesma coisa? O Gemini antigo era assim. O Gemini 3 promete ser aquele colega snior que voc fala "preciso de um relatrio" e ele pergunta "pro financeiro ou pro marketing?", porque ele entendeu o contexto. Vamos mergulhar no que muda na prtica.

2. Raciocnio "Deep Think": O Detetive Digital

Uma das novidades mais badaladas o novo modo de raciocnio profundo (que o Google chama de Deep Think ou Chain-of-Thought).

O que isso sem "tecniqus"?

Imagina que voc pede para uma criana resolver uma equao de segundo grau. Se ela s chutar o nmero, vai errar. Se ela pegar um papel, escrever a frmula de Bhaskara e resolver passo a passo, a chance de acerto enorme.

O Raciocnio Profundo exatamente isso: antes de te responder, o Gemini 3 "para para pensar". Ele quebra sua pergunta complexa em etapas menores, resolve uma por uma e depois te entrega a resposta.

Na prtica: Voc no precisa mais fazer aquela "engenharia de prompt" (que basicamente ter que falar igual rob para o rob te entender). Voc fala natural, e ele se vira nos 30 para estruturar a lgica.

3. Interfaces Generativas: A Morte do "Apenas Texto"

Essa aqui explodiu minha cabea. O Gemini 3 introduz o conceito de UI Generativa (Interfaces de Usurio Generativas).

At ontem, voc pedia algo no Google e recebia uma lista de links ou um bloco de texto. Agora, o modelo consegue gerar interfaces visuais e interativas na hora, especificamente para voc.

Sem Jarges Deixados Para Trs:

Pense na UI Generativa como um chef de cozinha pessoal. Antes, voc pedia uma receita e ele te dava um papel (texto). Agora, ele cozinha o prato na sua frente (cria a ferramenta).

Exemplo: Se voc est procurando "melhores tnis para correr a So Silvestre", ele no vai s listar modelos. Ele pode desenhar, na hora, uma tabela comparativa interativa ou um widget onde voc filtra por preo e tipo de pisada, criado ali, no momento da busca.

4. Agentes e a Plataforma "Antigravity"

Para a galera de desenvolvimento e corporativo, o Google lanou uma prvia do Antigravity. uma plataforma focada em Agentes de IA.

O que um Agente?

Se o ChatGPT/Gemini "padro" uma enciclopdia falante, um Agente um funcionrio que tem mos. Ele no s sabe as coisas, ele faz coisas. Ele pode entrar no seu sistema, rodar um cdigo, mandar um e-mail e agendar uma reunio.

O Gemini 3 traz agentes capazes de planejar e executar tarefas de programao autnoma. A ideia que ele consiga lidar com tarefas de vrias etapas (multi-step) sem voc ter que ficar segurando na mo dele a cada clique.

5. Contexto Profundo e Multimodalidade Real

Por fim, a capacidade de Contexto Profundo recebeu um upgrade massivo. O Gemini 3 consegue engolir PDFs gigantes (tipo, 80 pginas de "juridiqus" ou relatrios tcnicos) e manter o fio da meada.

Alm disso, a multimodalidade (a capacidade de entender texto, udio, vdeo e imagem ao mesmo tempo) est mais fluida.

Fazendo Analogia:

Imagine que voc est numa festa barulhenta. Uma IA antiga s conseguia ler as legendas do que as pessoas falavam. O Gemini 3 consegue ver a expresso facial da pessoa, ouvir o tom de voz sarcstico e ler a legenda, tudo junto, para entender que quando algum disse "Adorei sua camisa", na verdade estava sendo irnico. isso que chamam de "ler o ambiente" (reading the room).

Isso permite coisas como jogar um vdeo de 20 minutos para ele e pedir um resumo que realmente faa sentido, conectando o que foi falado com o que apareceu na tela.

6. Concluso: Menos Prompt, Mais Ao

O resumo da pera com o Gemini 3 : a barreira de entrada diminuiu. A tecnologia est finalmente se adaptando a ns, humanos bagunados e cheios de nuances, em vez de ns termos que aprender a falar "prompts".

Seja com interfaces que se desenham sozinhas ou com raciocnio que resolve problemas matemticos complexos, o Google est sinalizando que o futuro da busca no "procurar", "resolver".

Agora, se me do licena, vou pedir pro Gemini 3 tentar explicar para a minha tia no WhatsApp por que ela no deve clicar em links de sorteio de cafeteira. Se ele conseguir isso, a sim eu digo que a AGI chegou!

Um abrao e at a prxima compilao!

Referncias (Fontes Obrigatrias)

Para escrever este artigo, analisei profundamente os dados oficiais e as notas de lanamento de 18 e 19 de Novembro de 2025:

]]>

Esqueça o "Ctrl+C, Ctrl+V": Como eu ensinei a criar seu "Clone Digital" com Templates de Prompt e Lógica Condicional

Emerson Delatorre — Tue, 03 Mar 2026 13:45:41 +0000

Ei, pessoal! Aqui é o Fazedor de Código.

No último dia 14 de novembro, ministrei um treinamento sobre Engenharia de Prompt Avançada. Falamos sobre algo que eu vejo todo santo dia: gente brilhante presa em tarefas repetitivas. Lembra daquele relatório que você precisa compilar toda semana? Ou daquela análise de dados em que o processo é sempre o mesmo, só mudando os valores?

Nós aprendemos técnicas avançadas de prompt, mas senti que alguns ainda estavam no "cri-cri" na hora de aplicar no dia a dia. Por isso, hoje vamos subir mais um degrau. Vamos parar de criar prompts únicos e começar a construir sistemas. Vou mostrar como criar o seu "Clone Digital" usando Prompt Templates e Lógica Condicional.

O Problema: A "Tirania" do Trabalho Repetitivo

O cenário que eu descrevi em nosso último encontro é clássico: um colega precisa "confrontar 3 tabelas de fretes diferentes, calcular divergências e gerar um relatório" toda semana. Outro "extrai dados, organiza em 6 colunas, classifica e faz um resumo".

O processo é sempre o mesmo. Só mudam os dados. É aqui que a maioria para. Mas nós vamos além. A solução é o Prompt Template.

O que é um Prompt Template

Pense em um Prompt Template como eu expliquei: uma "receita de bolo profissional". A receita (o método) é sempre a mesma, o que garante um resultado de alta qualidade. Você só muda os ingredientes (os dados).

Seu template é a sua "receita" e ele tem 3 componentes essenciais:

Estrutura Fixa (A Espinha Dorsal): O nosso bom e velho framework CTFT (Contexto, Tarefa, Formato e Tom). Isso nunca muda.
Placeholders (Os "Espaços em Branco"): São os marcadores onde seus dados variáveis vão entrar. Como dizer à IA: "Aqui vai entrar o relatório".
Lógica Condicional (O "Cérebro" do Clone): É aqui que damos ao template o poder de tomar decisões.

Dando um Cérebro ao seu Clone: A Mágica da Lógica Condicional

Aqui é onde eu separo os novatos dos profissionais. "Lógica Condicional" parece assustador, mas quem usa a função SE no Excel já entende.

Jargão Explicado: Lógica Condicional é dar instruções do tipo "Se... Então...". Exemplo: "Se a despesa for maior que 5.000, então marque para 'Aprovação Gerencial'. Senão, marque 'Aprovação Automática'."

Níveis de Complexidade:

Nível 1: O "Sim ou Não" (Se... Então... Senão): Lógica binária para dois caminhos.
Nível 2: O "Cardápio de Opções" (Quando... Faça): Para múltiplas condições claras.
Nível 3: O "Labirinto" (Condicionais Aninhadas): Uma regra dentro de outra. Como uma árvore de decisão.
Nível 4: A "Linha de Montagem" (Para Cada... Aplique): É o uso de Loops (Iteração). Você diz à IA: "Para cada linha desta planilha, aplique estas regras".

Conclusão: Pare de Ser um Operador, Comece a Ser um Arquiteto

O futuro do trabalho com IA não é sobre quem faz o melhor prompt único, mas sobre quem constrói os melhores sistemas de automação.

O "dever de casa" de vocês é identificar essa tarefa repetitiva e começar a construir sua biblioteca de templates. Comece simples, pelo Nível 1. Com o tempo, você terá um exército de "clones digitais" trabalhando para você.

DEV Community: Fazedor de Codigo

Modelo ou harness? O modelo define o teto, mas o harness decide o resultado

Introdução

Modelo e harness não fazem o mesmo trabalho

O modelo ainda importa — e muito

O harness pode mudar quase tanto quanto o modelo

Em produção, o harness pode dominar custo e eficiência

Um harness melhor não significa um harness mais complexo

Um harness também pode atrapalhar um modelo melhor

Afinal, qual tem maior relevância?

O componente de maior alavancagem: feedback verificável

Como aplicar isso na prática

1. Comece pela tarefa, não pelo ranking de modelos

2. Crie primeiro o harness mais simples possível

3. Separe os experimentos

4. Analise trajetórias, não apenas respostas finais

5. Escolha o sistema pela fronteira qualidade–custo–risco

Conclusão

Referências

Preço por token não é custo por tarefa: a inversão que muda a economia dos modelos de raciocínio

O que o estudo encontrou

“Overthinking”: quando o modelo pensa demais

“Overacting”: agentes que executam etapas demais

O valor de Shapley como ferramenta de diagnóstico

O custo é uma distribuição, não um número fixo

Custo sozinho também não escolhe o melhor modelo

Como aplicar isso na prática

Conclusão

Referências

A nova corrida das fábricas de software: SpaceX compra Cursor enquanto a Factory lança o Factory 2.0

Do "Ok" ao "Termonuclear": Elevando a Barra do Code Review com IA

Por que a maioria dos agentes de IA falha no code review?

O que torna uma revisão “termonuclear”?

1. A regra das mil linhas

2. Combate a código espaguete e condicionais ad hoc

3. Fronteiras de tipos rígidas

4. Orquestração paralela vs. sequencial

5. Testabilidade como critério de aprovação

O conceito de “code judo”

Como aplicar isso no Cursor hoje

Opção 1: Project Rules em .cursor/rules

Opção 2: User Rules globais

Opção 3: Agent Skills

Opção 4: Bugbot para revisão automática de Pull Requests

Como usar no dia a dia

Antes de abrir um Pull Request

Ao revisar arquivos específicos

Ao pedir uma refatoração

Ao endurecer a barra de qualidade

Onde essa abordagem falha

1. Pode gerar falsos positivos

2. Pode incentivar abstração demais

3. Pode ignorar contexto de produto

4. Pode ficar verbosa demais

Conclusão: suba a régua dos seus agentes

Referências

Engenharia de Harness: O Segredo para Agentes de IA que Realmente Entregam Código

1. O que é, afinal, um "Harness"?

2. O Fim do "Arquivo de Regras Gigante" (Divulgação Progressiva)

3. O Repositório como o "System of Record"

4. Guardrails e o Autoconserto da IA

Conclusão: Uma Nova Fronteira

Dominando o Claude Code: O Guia Definitivo Passo a Passo (com Exemplos Práticos)

Passo 1: O Setup Otimizado (Preparando a Casa)

Passo 2: O Ponto de Partida – Perguntas e Respostas (Q&A)

Passo 3: Encadeamento e Direcionamento (O "Think Hard")

Passo 4: Como Montar o CLAUDE.md Corretamente

Passo 5: Multi-Agentes (O Exército de Claudes em Paralelo)

O Lembrete do Fazedor de Código

SDD e o Fim do "Vibe Coding": O Futuro do Desenvolvimento Guiado por IA

A Armadilha do "Vibe Coding"

O Santo Graal: Spec-Driven Development (SDD)

Como o SDD se integra com outras metodologias:

As Fases Práticas do SDD

E o Projeto Legado? (O Famoso "Brownfield")

Ferramentas do Ofício

O Futuro do Desenvolvedor: O Arquiteto de Intenções

Como Construir um Blog com Astro e Inteligência Artificial (Sem Perder o Controle do Código)

1. Esqueça o "Vibe Code", Pense em Engenharia

2. Escrevendo a "Constituição" do seu Código

Opção 1: Project Rules em `.cursor/rules`

Passo 4: Como Montar o `CLAUDE.md` Corretamente