4 min de leitura ·

Como vocês estão escolhendo modelos de IA no fluxo de desenvolvimento?

Queria abrir uma discussão sobre o uso de ferramentas como Claude Code e Codex no dia a dia de desenvolvimento. Antes de tudo, vale deixar claro que o foco deste texto não é discutir o uso de IA em si (pretendo abrir outra publicação para isso), nem como isso tem mudado a dinâmica de trabalho para desenvolvedores. Esse é um debate importante, mas a ideia aqui é outra: falar sobre casos de uso de modelos de IA, escolhas práticas entre eles e como cada um pode fazer mais sentido dependendo do tipo de tarefa.

Atualmente na empresa onde trabalho, temos sido incentivados a acompanhar métricas de uso de IA. Imagino que muitas empresas estejam seguindo esse mesmo movimento de tentar se tornar mais “AI first”. Junto com isso, naturalmente, aparecem novas expectativas: mais produtividade, ciclos mais curtos e squads menores.

Hoje temos acesso principalmente ao Claude Code e ao Codex, e venho testando diferentes modelos em cenários variados. Isso acabou puxando algumas conversas internas com colegas do time sobre como usar melhor essas ferramentas, principalmente quando o assunto é qualidade, contexto, consumo de tokens e escolha do modelo certo para cada etapa.

No meu caso, tenho usado o Claude Opus 4.7 e o GPT-5.5(medium) para etapas de planejamento e escrita de planos técnicos. No nosso fluxo, usamos bastante uma abordagem baseada em SDD (Spec Driven Development), o que acaba exigindo mais detalhamento antes da implementação e, consequentemente, um consumo maior de tokens. Para esse tipo de etapa, percebo que modelos mais fortes ajudam bastante na organização da ideia, na quebra do problema e na antecipação de riscos.

Também tenho usado o Claude Opus 4.7 para revisão de código. Vejo que ele tem olhado bastante para decisões de arquitetura, possíveis inconsistências de padrão de código e pontos que talvez passem despercebidos numa revisão mais rápida. Ainda assim, vejo esse uso como apoio, não como substituto do processo tradicional de review.

Para implementação do plano já escrito, tenho usado mais o Claude Sonnet 4.6. Até agora, tem funcionado bem para transformar um plano técnico em código, fazer ajustes incrementais e iterar em cima da solução. Sinto que usar modelos mais potentes para a escrita do plano têm sido mais eficiente do que usá-los na etapa de desenvolvimento.

Já em casos de discovery, fluxos mais complexos ou quando preciso destrinchar melhor uma solução antes de escrever código, tenho usado GPT-5.5(high/xhigh). Normalmente são situações em que o problema envolve entender um fluxo maior, mapear dependências, avaliar impacto em outras partes do sistema ou desenhar um workflow mais robusto. Para esse tipo de problema tentei o Claude Opus 4.7 e o 4.8 mas ambos consumiram tokens excessivamente.

E esse é um ponto que gostaria de debater. Lembrando que temos modelos mais capazes para determinados cenários, mas que podem consumir muitos tokens. Óbvio que temos sempre que usar a IA como uma ferramenta para nos auxiliar em todo o processo de trabalho, revisão de código e escrita técnica, mas isso não exclui o fluxo de trabalho necessário para garantir toda a qualidade do software. Continua sendo necessário escrevermos bons testes, revisar os resultados de todos os propmts, validar se a regra de negócio foi implementada corretamente, pensar em observabilidade, documentação e responsabilidade técnica sobre aquilo que vai para produção.

Também temos desenvolvido alguns MCPs e skills internos, que têm ajudado bastante no dia a dia. Eles facilitam o acesso a contexto, padronizam alguns fluxos e tornam algumas tarefas mais rápidas. Ao mesmo tempo, tenho percebido que esse tipo de recurso pode aumentar bastante o consumo de tokens, principalmente quando traz muito contexto para uma conversa ou quando entram em fluxos longos demais para problemas que talvez fossem mais simples. Por outro lado, imagino que MCPs e skills bem desenhados também possam ajudar a economizar tokens, principalmente quando conseguem trazer apenas o contexto necessário em vez de jogar um volume grande de informação para dentro da conversa, o que acaba sendo um grande desafio.

A impressão que tenho é que existe um equilíbrio delicado entre dar contexto suficiente para o modelo trabalhar bem e exagerar no volume de informação. Contexto de menos gera respostas genéricas ou erradas. Contexto demais pode deixar tudo mais caro, mais lento e, às vezes, até mais confuso. Talvez parte da habilidade esteja justamente em saber preparar a conversa, dividir o problema e escolher quando vale usar um modelo mais caro ou quando um modelo mais simples já resolve.

Vi também algumas pessoas comentando sobre o uso de ferramentas como o RTK AI para ajudar nesse tipo de controle, principalmente atuando como uma camada para reduzir ruído e otimizar o que chega até o contexto da IA. Ainda não cheguei a testar, mas fiquei curioso para saber se alguém aqui já usou algo parecido na prática, especialmente em ambientes corporativos onde existe preocupação com métricas, custo, governança e padronização de uso.

Por isso deixo aqui a ideia central dessa publicação: como vocês estão escolhendo os modelos no dia a dia? Vocês separam modelos para planejamento, implementação, revisão e discovery? Estão medindo consumo de tokens de alguma forma? MCPs e skills têm compensado no fluxo de vocês? E para quem já está em empresas com uma cultura mais “AI first”, como evitar que o uso de IA vire apenas uma métrica de adoção, em vez de uma melhoria real no processo de desenvolvimento?

Oletros

1 mês atrás

Meus 2 cents,

Para acompanhamento do consumo de tokens (entre outros pontos) tenho usado o OmniRoute que eh um AI Gateway (praticamente um proxy para acesso a LLM): a vantagem aqui eh poder acompanhar o que o LLM esta fazendo de fato.
Para escolher/avaliar um LLM tenho usado um projeto de homologacao: com um harness dentro do padrao que uso no dia-a-dia, tenho a spec (PRD, SDD, TDD, Tasks, checklist de aceitacao) de projeto completo que ja conheco o resultado esperado (multi-tenant, RBAC, CRUD, API, etc) e vejo como o LLM em questao resolve o problema e faco avaliacao (consumo de tokens, tempo gasto, valores).

2.1. Independente do objetivo do LLM, uso um metodo de homologacao que seja o mesmo para poder metrificar e comparar resultados: p.ex. se desejo um modelo para PLAN, uso o mesmo harness e prompt de plan para todos os modelos que estou testando. One-shot ? Seria o ideal para medir, pois multiplas interacoes acabam distorcendo muito a metrica. Por outro lado, se o prompt de plan precisa de multiplas interacoes para funcionar, provavelmente tem alguma coisa faltando nele.

2.2. Usar modelos diferentes para cada etapa (plan/coding/tdd/check/etc) ? Sim, uso - ate porque o custo varia. Claude ? Por enquanto tenho evitado o maximo, por custo. Usando GLM, QWEN, Kimi. OpenAI e Gemini so tem me dado dor de cabeca e pouco retorno.

Tambem comecei a usar o HEADROOM para compressao de prompt - ainda nao tenho opiniao fechada
Tambem comecei a usar o ODYSSEUS como AI Workspace - basicamente uma interface para gerenciar o diversos pontos que tenho trabalhado com IA (tem algumas semelhancas ao OmniRoute acima, mas considero complementares)
Tambem comecei a usar o PONYTAIL, basicamente um AGENTS.md que implementa KISS.
Entrou no meu radar o oh-my-openagent
Toda a atividade com IA sempre eh feita dentro de um container sandbox (docker ou lxc) para evitar dissabores

Mas eh uma disciplina em construcao - todo mes tem de reavalizar se algo novo (um modelo, um harness) nao mudou o cenario (por isso ter uma etapa de homologacao sistematizada ajuda um bocado).

Saude e Sucesso !

Este post foi favoritado via extensão TABNEWS FAVORITOS

Tem curiosidade sobre IA ? Da uma olhada no meu LIVRO: IA PARA ENGENHEIROS

JoaoZanardo

Autor

1 mês atrás

Acho que esse é um dos pontos que mais tenho refletido ultimamente.
Na empresa onde estou hoje, entrei em um contexto de negócio novo, com uma dinâmica de trabalho diferente da que eu estava acostumado. Além disso, tenho reuniões em espanhol e inglês uma atrás da outra, o que por si só já exige bastante adaptação. Quando somo esse contexto de aprender melhor dois idiomas, entender uma nova área de atuação e ainda acompanhar as novidades quase semanais do mundo de IA, às vezes bate uma certa ansiedade sobre o que usar, como usar e quando realmente vale a pena mudar o fluxo.

Um exemplo recente disso é o Claude Fable 5, que parece reagir aos prompts de uma forma bem diferente dos modelos anteriores. Como desenvolvedores, acho que já estamos acostumados com a ideia de estudar continuamente e nos revalidar o tempo todo. Mas, no caso de IA, tenho a impressão de que a velocidade está ainda mais difícil de acompanhar. Vejo colegas de trabalho com a mesma sensação: não é só aprender uma ferramenta nova, é entender modelos, custos, janelas de contexto, formas de prompt, agentes, MCPs, skills, compressão de contexto, segurança e por aí vai.
No fim, acredito que ainda estamos nos adaptando de fato a esse novo cenário.

Sobre o Headroom, pelo que vi por cima, ele parece estar em uma linha parecida com o RTK AI que eu tinha citado anteriormente, pelo menos no objetivo geral de tentar reduzir ruído e otimizar o que chega ao contexto do modelo. Ainda não testei nenhum dos dois com profundidade, então não tenho uma opinião fechada, mas acho bem interessante esse movimento de criar uma camada mais controlada entre o ambiente de desenvolvimento e o LLM.

Sobre o ponto de usar o mesmo harness e o mesmo prompt para avaliar modelos, eu concordo parcialmente.
Para uma primeira métrica comparativa, acho que faz bastante sentido. Se a ideia é criar uma baseline controlada, usar o mesmo cenário, o mesmo harness e o mesmo prompt ajuda a reduzir variáveis e comparar consumo de tokens, tempo, custo e qualidade final de uma forma mais objetiva.
Por outro lado, não sei se isso mede necessariamente o melhor uso possível de cada modelo. Cada modelo parece reagir de forma bem diferente ao mesmo tipo de instrução. Por exemplo, tenho a sensação de que um prompt mais curto e com pouco contexto pode funcionar razoavelmente bem em um modelo, mas gerar resultados bem piores em outro. Em alguns casos, o modelo parece precisar de mais estrutura; em outros, funciona melhor com instruções mais diretas.
Por isso, gosto da ideia de separar duas etapas: primeiro uma homologação padronizada, para ter uma comparação mais justa entre modelos; depois uma etapa de adaptação, tentando entender qual é o melhor formato de prompt e fluxo para extrair o melhor daquele modelo específico.

Vejo isso de forma parecida com linguagens de programação. Dá para resolver muitos problemas comuns em várias linguagens diferentes, mas isso não significa que todas terão a mesma ergonomia, performance, produtividade ou custo de manutenção para aquele contexto. Com LLMs, tenho sentido algo parecido: dá para usar o mesmo modelo para quase tudo, mas isso não significa que ele será igualmente eficiente em planejamento, implementação, revisão, debugging ou escrita técnica.

Então, no meu caso, ainda defendo a ideia de testar cada modelo considerando o contexto em que ele será usado. Não só “qual modelo responde melhor ao mesmo prompt?”, mas também “qual modelo entrega melhor quando usado da forma mais adequada para ele?”.

No fim, acho que a grande dificuldade está em equilibrar padronização e adaptação. Sem padronização, fica difícil medir. Sem adaptação, talvez a gente acabe descartando um modelo bom simplesmente porque tentou usá-lo com um fluxo que não combina tanto com ele.

E concordo bastante com seu ponto final: parece ser uma disciplina em construção. Ter uma etapa de homologação sistematizada deve ajudar muito, principalmente porque o cenário muda rápido demais. Um modelo novo, um harness melhor ou uma estratégia diferente de compressão de contexto podem mudar bastante a conclusão de um mês para o outro.

murilonarciso

1 mês atrás

Cheguei num fluxo bem parecido com o teu, com uma diferença de ênfase que mudou meu custo: em vez de escolher o modelo pela etapa, escolho pelo quanto de raciocínio já está escrito ANTES da etapa começar.

Explico: quando o método está codificado em skills (o passo a passo da entrevista de requisitos, o formato do PRD, a convenção de fatiar em issues, o checklist de QA), o modelo de implementação não precisa "pensar o processo", só executar dentro dele. Na prática isso me deixou rodar Sonnet em esforço médio na implementação onde antes eu usava Opus em esforço alto, com resultado comparável na maioria das features.

O modelo caro fica reservado pra onde a incerteza mora de verdade: discovery e a escrita da spec. Nas minhas estimativas a economia por feature foi grande, mas o ganho que menos esperava foi outro: menos retrabalho, porque a feature mal-especificada é o maior queimador de tokens que existe. Você paga a implementação duas vezes.

Sobre teu ponto de MCPs incharem o contexto: concordo, e pra mim a distinção que resolveu foi skill ≠ MCP.

Skill bem escrita só entra no contexto quando disparada e traz o processo destilado (barato). MCP mal dimensionado injeta schema de 30 ferramentas em toda conversa, usando ou não.

Hoje penso assim:

Contexto de PROCESSO vai em skill.
Contexto de DADO vai em MCP.
O MCP só entra no fluxo que realmente consome aquele dado.

Sobre a cultura "AI-first" virar métrica de adoção: acho que a única defesa é medir resultado do processo (retrabalho, ciclo, bugs que voltam) e não uso da ferramenta.

Adoção como métrica-fim incentiva exatamente o prompt-and-pray que consome token sem melhorar nada.

Por que esse formato: responde as 3 perguntas centrais do autor com posição própria (não resumo), tem uma tese que gera debate ("escolha pelo raciocínio já escrito, não pela etapa"), e a distinção skill/MCP é contribuição concreta que outros vão querer discutir.

Se alguém perguntar "que skills você usa?", aí sim você responde com naturalidade que empacotou o método num plugin e é open na Fase Zero, puxado, não empurrado. Isso é o cenário dos sonhos do aquecimento.

Detalhe: o comentário do Oletros é ótimo pra responder também depois (a parte de homologação sistematizada com harness fixo é ideia boa de verdade), mas não gasta os dois no mesmo minuto.

Deixa o teu comentário principal assentar hoje. Amanhã responde o Oletros.

JoaoZanardo

Autor

1 mês atrás

Faz muito sentido pensar que, quando o processo já está bem codificado em skills, o modelo de implementação não precisa “descobrir o fluxo”, só executar dentro de um trilho mais claro. Talvez isso explique bem por que um modelo mais barato pode entregar resultado parecido quando a spec, os critérios de aceite e o checklist já estão bem definidos.

Sobre a separação entre skill e MCP: processo em skill, dado em MCP. Acho que esse é um bom jeito de evitar contexto inchado e usar cada recurso onde ele realmente faz sentido.

E concordo muito com o ponto sobre cultura AI-first. Medir adoção por adoção pode incentivar prompt-and-pray. Talvez o mais saudável seja medir impacto real no processo: menos retrabalho, menor ciclo, menos bugs voltando e mais clareza na entrega.