Esta startup manteve Claude e Codex e passou a papelada para a IA local

Uma pessoa desenvolvedora pede a um agente de programação que corrija um bug em um serviço. Antes disso, o agente precisa achar o chamado original, recuperar algumas decisões de produto e descobrir quais requisitos ainda valem. Depois da correção, alguém precisa transformar o que falta fazer em chamados visíveis para design ou suporte. A mudança no código é só parte do trabalho, mas tudo pode acabar no mesmo modelo pago.

A Grayhat Developers, empresa de software com menos de 40 pessoas, descreveu o que aconteceu quando separou essas tarefas em um preprint de 5 de novembro de 2026. A equipe havia testado modelos de hospedagem própria no desenvolvimento e observou que substituir seus agentes comerciais tornava mais lentas ou difíceis algumas tarefas no repositório. Manteve os agentes nas mudanças complexas e levou parte da busca de documentos, da preparação de contexto e da sincronização de chamados para um serviço local.

A pergunta interessante para outra equipe pequena é por onde começar. O caso da Grayhat oferece um ponto de partida concreto, uma estimativa que merece ser destrinchada e um erro de adoção que pode derrubar o piloto antes que a equipe aprenda algo sobre a qualidade do modelo.

Antes de mexer no código, a correção paga um pedágio de contexto

A Grayhat usava Outline para documentação, Plane para acompanhar o trabalho e ERPNext para informações da organização. A equipe já hospedava esses serviços em uma máquina do escritório e conectava a gestão de identidade pelo Authentik. Hospedava ali também os conectores do Model Context Protocol, ou MCP. Uma segunda máquina cuidava da inferência. A separação tinha um objetivo prático. Os sistemas de documentos e chamados podiam continuar atendendo pelas interfaces de sempre enquanto os modelos consumiam recursos em outro equipamento.

O processo do artigo inclui repasses feitos por pessoas. Alguém usa o modelo interno para buscar e condensar informações da wiki ou do rastreador. Pode colocar os trechos relevantes em um arquivo no repositório para o agente de programação. Depois do trabalho no repositório, uma pessoa leva os próximos passos ao assistente interno, transforma-os em rascunhos de chamados e envia ao rastreador. O artigo deixa a comunicação direta entre agentes como trabalho futuro. Uma pessoa já consegue inspecionar a informação na fronteira e decidir o que deve passar.

Os pontos de repasse no fluxo da Grayhat. Ilustração original da Telli.sh com base no estudo de 5 de novembro.

Imagine que um cliente reporte linhas repetidas numa exportação. O relato original tem uma referência privada da conta e uma transcrição sem relação com o bug. Um assistente local pode achar as regras atuais de exportação, a equipe responsável pelo serviço e a solução provisória anterior. A pessoa engenheira pode então redigir um resumo com exemplo sintético e contagem esperada de linhas. O agente de programação recebe o que precisa para reproduzir o problema. O material sensível fica nos sistemas internos porque uma pessoa escolheu o que atravessaria a fronteira.

Mantenha os links originais junto ao rascunho interno. Quando os requisitos divergem, quem revisa consegue ver se a regra proposta veio de uma decisão recente ou de uma solução provisória antiga. Um resumo local que deixa as fontes para trás recria o problema que pretendia resolver. A próxima pessoa fica tentando descobrir em qual descrição confiar.

A equipe comprou capacidade e estimou quanto do trabalho poderia mudar de lugar

Os autores relatam um gasto-base comercial de cerca de US$ 325 por mês. São aproximadamente US$ 175 por sete vagas no Claude, US$ 140 por sete assinaturas do Codex e US$ 10 em créditos. Relatam também mais de 25,93 bilhões de tokens registrados nos serviços. O artigo não estabelece que esses tokens pertencem ao mesmo período de cobrança dos US$ 325. Use os números para entender o que cada um mede. A divisão entre eles não estabelece um preço por token.

A equipe estimou que transferência de contexto, documentação e coordenação de projetos correspondiam a 30–40% da carga de IA comercial. Segundo a estimativa, o sistema local poderia absorver cerca de 90% dessa categoria. A multiplicação dá 27–36% da carga comercial total. Aplicada aos US$ 325, a faixa equivale a cerca de US$ 88–117 por mês. São estimativas de carga de trabalho e custo equivalente do estudo de 5 de novembro. O artigo não realizou um experimento controlado comparando faturas antes e depois.

A estimativa da Grayhat parte de uma parcela da carga e chega a um custo equivalente. Ilustração original da Telli.sh.

A distinção importa quando a cobrança é por pessoa. Se sete pessoas ainda precisarem das assinaturas para trabalho complexo, o uso pode cair sem mudar a próxima fatura. O ganho pode vir como capacidade para outras correções, menor pressão dos limites ou menos compras excedentes. Uma equipe cobrada por requisição talvez veja uma mudança mais cedo, mas novas tentativas e filas lentas podem consumir parte da economia aparente. Se for preciso comprar GPU e pagar alguém para mantê-la disponível, inclua isso na comparação.

Escolha uma unidade que você consiga conferir. Contar rascunhos de chamados é fácil, mas um chamado refeito do zero por quem lidera o projeto traz pouca evidência de economia. Meça resumos e chamados aceitos e anote revisões que mudam o sentido da tarefa. Quando os revisores conseguirem reconhecer uma entrega aceitável com consistência, acompanhe o esforço necessário para produzi-la.

A segunda interface mudou quem precisava configurar o sistema

A primeira implantação usou LobeHub. A equipe de engenharia recebeu instruções para conectar a própria interface às ferramentas internas. Segundo os autores, as demonstrações promissoras não viraram uso frequente. Cada pessoa precisava descobrir qual conector selecionar, onde ele estava e como entrar. Cada decisão extra dificultava a chegada à primeira resposta útil.

A segunda interface da Grayhat centralizou a configuração das ferramentas de trabalho. Figura 2 de “Create Your Own Work Stack”, de Saad Ahmed Bazaz, Talha Amjad, Abdurrehman Subhani, Sohaib Ahmed Bazaz e Abdullah Aamir, CC BY 4.0.

A equipe mudou para uma implantação LibreChat configurada de forma centralizada. Usuários viam as ferramentas prontas e podiam se autenticar no acesso. Os autores contaram oito comentários sobre configuração e adoção inicial em 11 entrevistas estruturadas sobre a primeira versão. Na segunda versão, receberam três comentários dessa categoria em retornos não estruturados no Discord. Os números vêm de métodos diferentes. Ajudam a localizar o problema de adoção inicial, mas não medem quanto a adesão cresceu nem quantas pessoas deixaram de ter dificuldades.

Desenhe a primeira sessão em torno da menor tarefa real. Quem entra para consultar os critérios de aceitação de um chamado precisa ver se o rastreador está conectado e qual conta está ativa. Quem quer redigir três chamados deve poder revisá-los antes de enviar. Ensinar a configurar conectores antes que as pessoas encontrem o próprio trabalho pode fazer a equipe medir paciência em vez de utilidade.

A configuração centralizada traz outra responsabilidade. Alguém precisa manter a lista de conectores aprovados, renovar credenciais e explicar quem pode alterar permissões. Sem isso, uma configuração errada pode afetar todo mundo. A vantagem é corrigir um problema recorrente de configuração uma vez e levar a solução a todas as pessoas que usam o serviço.

Dê ao sistema local tarefas com uma pessoa responsável pela entrega

A triagem de chamados é um primeiro candidato prático. O assistente interno pode agrupar relatos duplicados e propor um resumo com links para os chamados de origem. A pessoa responsável pelo projeto decide se são de fato duplicados e se a descrição unificada perdeu alguma condição. O assistente pode redigir um comentário explicando o agrupamento. Com alguém claramente responsável pela atualização, fica mais fácil acompanhar o que ocorreu.

Manutenção da documentação é outro trabalho. Imagine que uma mudança transfira uma configuração de uma tela para outra. O assistente pode achar as páginas de ajuda desatualizadas, identificar quais edições do produto elas cobrem e preparar edições. Uma pessoa editora verifica a navegação atual e publica as mudanças corretas. Um modelo remoto mais forte agrega pouco quando o desafio está em acessar as páginas internas atualizadas e respeitar o escopo de cada artigo.

Programação complexa é o caso oposto. Uma migração de banco pode exigir examinar contratos de dados antigos, mudar mais de um serviço e validar como reverter a operação. A Grayhat viu seu sistema local de teste ter dificuldades em tarefas maiores de repositório, sobretudo quando o modelo precisava de amplo contexto e inferência rápida. O estudo descreve o equipamento, os modelos e a experiência da equipe. Isso dá base para testar a própria carga localmente antes de ampliar o escopo.

Use um fluxo restrito para uma tarefa que combine formatação simples e dados sensíveis. Enviar um rascunho para fora da rede ainda pode expor informações, mesmo se as ferramentas originais rodarem no escritório. Se houver repasse remoto, aprove o destino e produza só o artefato mínimo necessário. Enquanto o resultado interno não tiver aprovação, deixe-o na fila interna. Um tempo limite deve aparecer como erro, sem transferências inesperadas.

Um piloto curto separa o trabalho útil das tarefas de infraestrutura

1. Defina três entregas. Escolha um resumo com links para chamados, uma edição de documentação e um chamado em rascunho. Escreva uma frase para cada um com quem o aceita e qual evidência é exigida. Guarde um exemplo reprovado junto a um bom, incluindo erros fáceis de passar batido.
2. Meça o caminho atual. Em uma semana de trabalho comum, conte exemplos concluídos, correções relevantes e tempo gasto para buscar contexto. Quando possível, associe o uso comercial aos fluxos. Anote se retirar as tarefas mudaria de fato o número de licenças ou o excedente cobrado. Registre à parte o trabalho que a equipe deixou de fazer.
3. Conecte uma ferramenta interna. Comece com acesso de leitura em um projeto identificado. Confirme que uma pessoa autorizada consegue recuperar um chamado conhecido e alguém de fora do projeto não consegue. Limite o piloto a poucas pessoas que já fazem o trabalho escolhido. Dê a elas um caminho claro para concluir manualmente quando a ferramenta falhar.
4. Compare rascunhos antes de autorizar gravação. Peça à mesma pessoa que aceite ou rejeite as entregas pelos mesmos critérios. Registre links que apontam para o chamado errado, fatos antigos e conclusões sem respaldo. Acrescente prévia, aprovação e registro durável antes de permitir que o assistente altere um rastreador real.
5. Veja o que mudou de lugar. Compare trabalho aceito, tempo de revisão, uso ativo e faturas reais. Some o tempo de manutenção da máquina, a indisponibilidade e mudanças de conectores. Inclua a ajuda de configuração dada diretamente. Um aplicativo que só funciona depois de dez minutos de orientação individual ainda tem custo de adoção.

Se você já oferece um modelo local a desenvolvedores, rode o teste junto do tráfego normal. A fila aparece quando várias pessoas começam ao mesmo tempo. Um serviço rápido para uma solicitação ainda pode fazer três pessoas esperar. Dê às tarefas urgentes uma forma de mostrar progresso e voltar ao processo manual de sempre. Assim, o piloto continua usável enquanto a equipe entende onde essa carga cabe.

O apêndice da Grayhat dá uma noção de escala. A máquina das ferramentas tinha 16 GB de RAM. A máquina de inferência separada tinha 32 GB e uma RTX 4080 com 16 GB de VRAM. A equipe relata que acrescentou monitoramento de rede, agendamento e uma fonte de alimentação ininterrupta conforme as necessidades operacionais apareceram. São dados úteis para o orçamento de um piloto. Eles refletem a operação de um serviço do qual outras pessoas dependem, além do custo de obter uma resposta do modelo.

Decida onde aplicar a próxima hora de trabalho de IA

A ideia reaproveitável é separar a preparação de contexto do raciocínio especializado e atribuir uma pessoa responsável a cada repasse. Comece com uma tarefa que se repete e produz algo que a equipe já sabe revisar. Meça quanto trabalho custa aceitar a entrega e decida se o caminho local merece outra tarefa. O caso da Grayhat permite fazer essa avaliação preservando as ferramentas de programação que continuam justificando seu espaço.

Fontes

• Preprint da Grayhat Developers, 5 de novembro de 2026
• Artigo completo, com estimativas de carga, infraestrutura e Figura 2
• Imagem original da Figura 2
• Licença CC BY 4.0 da figura do artigo

---

Para manter um registro pesquisável das conversas por trás de um repasse de trabalho, crie uma conta na Telli.sh.