Insights sobre Desenvolvimento com IA Após Dois Meses em uma Big Tech

Contexto

O gatilho para este artigo foram algumas reuniões individuais com o meu líder de equipe. Ele estava curioso sobre como eu uso ferramentas de IA, crio meus próprios Harnesses e estruturo meu fluxo de trabalho de AI Coding. Principalmente porque venho entregando requisitos rápido e com qualidade, já atuando como responsável principal por alguns projetos. Então, aproveitei a oportunidade para organizar meu fluxo diário com IA. Atualmente, meu foco no grupo é desenvolvimento de Agentes, mantendo ao mesmo tempo a lógica de negócio existente no backend.

Anteriormente, compartilhei fluxos parecidos no Xiaohongshu. O contexto na época era que o GPT-5.4 e o Opus 4.6 já conseguiam concluir tarefas muito bem quando recebiam um contexto preciso e restrições razoáveis. A ascensão do Harness Engineering fez todo mundo perceber uma coisa: você consegue controlar melhor modelos poderosos adicionando restrições.

Por exemplo, Skills como o Superpowers oferecem uma implementação mais pesada, girando principalmente em torno de Spec e TDD, ajudando as pessoas a organizarem e avançarem nas tarefas com mais facilidade.

Mas fazer isso tem suas desvantagens. A sensação mais óbvia é: o consumo de Tokens vai pelas alturas. Skills como o Superpowers contêm muitos Workflows usados para restringir a próxima ação do modelo. Mesmo que, de uma perspectiva global, certa etapa não seja mais necessária — por exemplo, se o contexto já for suficiente para começar a implementar direto —, o modelo pode continuar executando o processo predeterminado.

Com o lançamento de novos modelos, vi muitos desenvolvedores começando a compartilhar que praticamente não usam mais esses Skills tão pesados. Um dos principais motivos é que, com o aumento da capacidade dos modelos, algumas restrições e processos que antes achávamos úteis estão virando ruído para eles. Por exemplo, quando a OpenAI lançou o Astra, eles publicaram um post no blog explicando justamente como limpar Skills e system prompts desnecessários para melhorar a experiência de uso do modelo.

Então, neste artigo, vou juntar minhas práticas dos últimos meses para compartilhar alguns métodos que estão funcionando bem para mim hoje, discutindo como usar melhor os vários Agentes para aumentar a eficiência no desenvolvimento diário.

1. Meus Skills e Prompts Mais Usados

Como divido minhas ferramentas atualmente:

Hoje, uso principalmente Codex + GPT-5.6 Sol para implementação de código e Astra para planejamento. Antes do lançamento do Astra, o trabalho de planejamento ficava basicamente com o GPT-5.6 Sol Max.

Para requisitos simples, uso pi + DeepSeek V4 Flash na implementação; a revisão adversarial de soluções e o Code Review ficam principalmente por conta do Claude 5 Fable. Em projetos pessoais, também uso o GPT-6 Pro via web para o design principal das soluções.

Meus Skills Mais Usados

1. think: Skill do tw93, usado principalmente para alinhamento de soluções e brainstorming.
2. grill me / grill with docs: Usado principalmente para esclarecer requisitos. Por meio de perguntas contínuas, ele esclarece objetivos, restrições e trade-offs, e depois os consolida em um ADR ou CONTEXT.md, conforme a necessidade do processo de desenvolvimento. Me ajuda a descobrir pontos que passaram batido no alinhamento inicial.
3. implement: Usado junto com o grill, faz parte do pacote de Skills do Matt Pocock, serve para implementar planos ou Issues bem definidos.
4. ponytail: Usado para limpar o over-design da IA, reduzindo a dificuldade do Review. Uso bastante porque o GPT-5.6 Sol frequentemente exagera no design.
5. handoff: Organiza o contexto atual em arquivos, facilitando a continuação da tarefa em novas sessões. Geralmente uso para passar o bastão do Codex para o Claude Code ou para o pi agent.
6. check: Usado para code review, normalmente na hora de abrir MRs.
7. Skills consolidados do trabalho e de projetos pessoais: Principalmente SOPs de processos reutilizáveis, como testes end-to-end. Minha sugestão é: no dia a dia, se um processo se repete mais de três vezes, peça para o Codex ajudar a transformá-lo em um Skill para reuso direto depois.

Meus Prompts Mais Usados

Hoje em dia, raramente escrevo blocos gigantes de Prompt por conta própria. Quando preciso, geralmente deixo o Codex organizar para mim. Por exemplo, depois de várias rodadas de discussão, se quero passar o contexto atual para o GPT Pro desenhar a solução, peço para o Codex gerar um Prompt de handoff completo primeiro.

Além disso, uso com frequência os seguintes tipos de Prompts bem curtos.

Às vezes, eles alcançam aquele efeito de "uma frase que vale por mil". Eu os entendo como "atalhos de pensamento" do modelo.

Não são fórmulas mágicas, mas metodologias altamente padronizadas no conhecimento humano. Durante o treinamento, o modelo viu uma quantidade enorme de artigos, códigos, documentos de design e discussões relacionadas. Por isso, muitas vezes não há necessidade de escrever centenas de linhas de Workflow à mão; basta dizer qual método de pensamento ele deve adotar. Aqui estão alguns prompts que achei muito eficazes na prática:

• Primeiros Princípios: Não continue otimizando em cima da solução atual, volte a perguntar como esse problema realmente deveria ser resolvido. Por exemplo, se uma interface está lenta, você pode dizer:

Não continue o design com base na solução já estabelecida de "adicionar cache Redis". Analise a partir dos primeiros princípios por que esta interface está lenta e qual é a solução mínima necessária.

O foco do modelo muda de "como o Redis deve ser projetado" para:

O gargalo está no SQL, na rede, na serialização, na contenção de locks ou em cálculos repetidos? Se adicionar um índice no SQL resolver, por que introduzir o Redis?

Esse tipo de Prompt é ideal quando você suspeita que "a pergunta em si pode estar errada".

• Revisão Adversarial: Não procure motivos para validar minha solução, tente provar que ela está errada.

O jeito comum de pedir seria:

Me ajude a ver se tem algum problema nesta solução técnica.

Pode ser alterado para:

Faça uma revisão adversarial desta solução, priorizando encontrar contra-exemplos que possam derrubar as premissas principais.

Supondo que sua solução seja "introduzir locks distribuídos para resolver requisições duplicadas", o modelo não vai apenas te dizer como configurar o timeout do lock, mas começará a questionar:

Requisições duplicadas realmente precisam de exclusão mútua? A idempotência da interface não resolveria? E se o serviço de lock cair? E se o lock expirar antes da execução da regra de negócio terminar? Será que introduzimos um novo ponto de falha distribuído para resolver um problema local?

Esse tipo de Prompt é especialmente útil para revisões de solução e Code Reviews.

• Experimentos de Ablação: O sistema ter melhorado não significa que tudo o que você adicionou foi útil.

Por exemplo, você fez três otimizações de uma vez:

Depois de adicionar índices, cache Redis e consultas em lote, a latência da interface caiu de 800ms para 100ms.

Nesse momento, você pode pedir diretamente:

Desenhe experimentos de ablação para essas três otimizações, a fim de determinar de onde vêm os ganhos reais.

O modelo vai desenhar grupos de controle em torno de diferentes combinações, partindo do Baseline, comparando apenas a adição de índices, índices + cache, índices + cache + consultas em lote, etc.

No final, ele pode descobrir que:

Apenas adicionar índices já reduziu a latência de 800ms para 120ms; as outras duas soluções complexas contribuíram com apenas 20ms.

Assim, você sabe com mais clareza qual código vale a pena manter e qual complexidade pode ser desnecessária.

• Navalha de Ockham: Quando os efeitos forem semelhantes, priorize soluções com menos premissas e menor complexidade.

Por exemplo, o Agente projeta uma solução assim:

Kafka + Redis + Lock Distribuído + Máquina de Estados + Compensação Agendada.

Você pode adicionar uma frase:

Revise este design usando a Navalha de Ockham, removendo todos os mecanismos não essenciais, desde que os requisitos sejam atendidos.

Muitas vezes, ele acaba concluindo que:

O cenário atual envolve apenas gravações em um único banco de dados; uma transação com um índice único já é suficiente.

Essa frase é especialmente útil para os Coding Agents atuais, porque os modelos tendem a exagerar no design em nome da "completude".

• Alta Coesão, Baixo Acoplamento: Revise as responsabilidades e fronteiras do código.

Por exemplo, se você notar que um OrderService já tem 2000 linhas, pode perguntar:

Revise as fronteiras de responsabilidade do OrderService seguindo os princípios de alta coesão e baixo acoplamento, não divida apenas por dividir.

O modelo geralmente começa a checar:

Por que o serviço de pedidos lida simultaneamente com estoque, cupons, SMS, pagamento e relatórios? Qual lógica pertence de fato ao domínio de pedidos e qual deveria ser delegada a outros módulos por meio de interfaces estáveis?

Isso ativa não apenas uma simples "divisão de arquivos", mas todo um conjunto de julgamentos sobre modularização, ocultação de informação, direção de dependências e divisão de responsabilidades.

Por isso, raramente escrevo mais coisas como:

Passo 1 analisar requisitos, Passo 2 verificar premissas, Passo 3 buscar alternativas, Passo 4...

O modelo já aprendeu muitas metodologias maduras. Prefiro dizer diretamente a ele:

Reanalise a partir dos primeiros princípios, faça uma revisão adversarial da solução atual; os mecanismos principais devem ser validados por experimentos de ablação; a solução deve seguir a Navalha de Ockham, e o código deve manter alta coesão e baixo acoplamento.

Por trás dessas poucas dezenas de palavras, cinco ações cognitivas diferentes estão sendo especificadas:

Redefinir o problema → Atacar as premissas → Validar as contribuições → Eliminar a complexidade → Organizar as fronteiras do sistema.

Na minha visão, essa é também uma mudança no Prompt Engineering na era dos novos modelos: em vez de escrever um processo de pensamento fixo e completo para o modelo, é melhor usar metodologias precisas para dizer a ele "de que forma pensar" e, então, complementar com as restrições realmente necessárias para a tarefa atual.

2. Meu Fluxo Diário de Desenvolvimento

Depois de receber um requisito, geralmente passo o contexto relevante para o Agente primeiro, como PRD, atas de reunião, históricos de chat e feedbacks de usuários, e depois uso o grill para alinhar o requisito com ele.

Muitas vezes, esses materiais não formam um requisito completo e consistente. O PRD pode estar desatualizado, algumas restrições podem ter sido adicionadas em reuniões, prioridades ajustadas no chat. Meu próprio entendimento do requisito também pode incluir algumas premissas não ditas.

Deixo o Agente entender esses materiais combinados com a Wiki da equipe e o código existente, e então esclarecer objetivos, fronteiras e trade-offs que afetam a implementação por meio de perguntas contínuas. Algumas questões consigo responder na hora, outras exigem voltar e confirmar com o pessoal de produto ou colegas envolvidos.

Aqui, mantenho um equilíbrio: quando as dúvidas restantes não mudam mais significativamente a direção da implementação e os critérios de aceite, o desenvolvimento pode começar.

Não exijo que ele planeje todos os detalhes de implementação antecipadamente, senão o próprio alinhamento de requisitos vira um processo extremamente pesado.

As conclusões após o alinhamento são consolidadas em um Spec ou CONTEXT.md, registrando principalmente o problema a ser resolvido desta vez, o escopo, as decisões-chave e os critérios de aceite. Isso também facilita que os Agentes responsáveis pela implementação e revisão posteriores compartilhem o mesmo contexto, sem precisar reler todas as conversas anteriores.

Com a solução definida, deixo o Agente principal decidir como executar com base na complexidade da tarefa. Requisitos simples são implementados direto; os complexos são divididos em Issues com fronteiras claras, que podem ser aceitas de forma independente. Apenas as partes que podem seguir sozinhas são passadas para subagentes, para desenvolvimento paralelo em worktrees diferentes, sendo finalmente integradas pelo Agente principal.

O Agente de codificação conclui os testes primeiro. Quando ele acha que está pronto para entregar, introduzo outros Agentes para uma revisão cruzada adversarial, dependendo da complexidade da tarefa. Os problemas encontrados são devolvidos de forma unificada ao Agente de codificação principal, ou seja, o Codex, que corrige e revalida.

Antes do meu próprio Review, também realizo testes end-to-end.

Atualmente, não leio todo o código gerado linha por linha; olho principalmente os resultados dos testes e a lógica de negócio central. Há uma premissa importante aqui: o escopo de cada MR é pequeno o suficiente, e os fluxos completos de negócio são validados gradualmente conforme o desenvolvimento avança.

MRs pequenos mantêm as mudanças que exigem compreensão e julgamento dentro de limites controláveis a cada vez; os testes end-to-end ajudam a verificar se essas mudanças se sustentam quando colocadas nos fluxos reais de negócio. Durante o Review manual, foco em confirmar a lógica de negócio e se os resultados dos testes existentes são suficientes para apoiar essa entrega.

3. Como Construir Testes End-to-End Amigáveis a Agentes

A IA já é muito boa em escrever casos de teste, frequentemente gerando centenas de linhas de testes para um Bugfix (especialmente o 5.6 sol). Muitas vezes, escrever mais testes não é um problema em si, mas, após o deploy e o lançamento, ainda encontramos erros inesperados.

Na minha prática, um problema central é: não fornecer ao Agente um ambiente de testes end-to-end, dando a ele a chance de descobrir esses problemas durante as etapas de codificação e autoteste.

Se conseguirmos construir esse ambiente, permitindo que o Agente execute tarefas convenientemente a partir do ponto de entrada real do ambiente de testes, verificando tudo até chegar aos resultados que o usuário precisa, podemos deixar o código escrito por IA rodar em sistemas reais com tranquilidade.

No desenvolvimento real, construí um conjunto de ambientes de teste de desenvolvimento end-to-end para o nosso negócio. O Agente consegue consultar tabelas de banco de dados, logs e conectar-se a máquinas para investigar problemas com facilidade.

Todo o processo de construção é, essencialmente, deixar o Agente extrair meus processos diários de autoteste de desenvolvimento, integrando ferramentas e capacidades dispersas: o que pode ser transformado em ferramenta vira MCP ou CLI; os processos reutilizáveis são escritos em Skills.

Isso realmente exige um certo esforço inicial, mas não tenha medo do trabalho. Uma vez construído, acelera significativamente o desenvolvimento, reduz retrabalho e a chance de problemas em produção, e você não precisa ficar o dia inteiro preocupado se o código escrito pela IA vai causar algum incidente.

Em torno dos testes end-to-end amigáveis a Agentes, fiz basicamente quatro coisas:

1. Deixar o Agente conhecer o ambiente: Como suportar a inicialização do ambiente de testes com um clique, criação de dados de teste, esclarecimento das versões atuais, contas de teste e permissões, além de fornecer capacidades de limpeza e reset.
2. Deixar o Agente operar os sistemas de negócio: Executar fluxos reais de negócio via navegadores, APIs ou CLIs.
3. Deixar o Agente consultar facilmente tabelas de banco de dados e logs: Confirmar resultados de armazenamento via MCP de banco de dados somente leitura, localizar problemas através de Skills do sistema de logs e consultas de Trace.
4. Reutilizar processos tediosos, porém estáveis: Transformar operações estáveis em scripts, organizar pontos de entrada e métodos de troubleshooting em Skills, reduzindo intervenções manuais repetitivas e idas e vindas no chat.

Com base nesse trabalho, aqui estão alguns métodos que considero eficazes atualmente:

1. Automação de Navegador: Quando os sistemas de negócio exigem operações no navegador, recomendo o navegador open-source ego lite. É prático de usar e rápido. Combinado com pi agent + DeepSeek V4 Flash, os testes podem ser concluídos de forma relativamente rápida, reduzindo o tempo de teste.
2. Unificar Operações em uma CLI: Integrar Skills reutilizáveis, MCPs configurados e scripts escritos em uma CLI de teste unificada, oferecendo capacidades para checagem de ambiente, preparação de dados, execução de cenários, consulta de resultados e limpeza. Isso também pode virar uma ferramenta interna de produtividade. Atualmente, transformei esse conjunto em uma CLI, e ela também facilita muito o troubleshooting quando surge algum problema.
3. Deixar as Ferramentas Servirem Diretamente ao Aceite: Consultas no banco servem para confirmar estados, logs e Traces servem para explicar falhas, mas os resultados esperados ainda devem vir dos contratos de negócio. Não deixe o Agente assumir que algo está correto só porque viu o que o sistema retornou. Sob lógicas de negócio complexas, o sistema pode perfeitamente retornar um resultado que parece razoável, mas não está em conformidade. As ferramentas nos ajudam a obter evidências, não a definir as respostas corretas por nós.
4. Se o Próprio Produto for um Agente, Verifique Também a Qualidade das Respostas: Se o produto testado for um Agente, além de checar se os fluxos de negócio rodam até o fim, a qualidade das respostas também precisa ser considerada. É o que costumamos chamar de Agent Eval, que não vou detalhar aqui.

4. Como Revisar Código Escrito por IA

As seções anteriores compartilharam como fazer a IA escrever código de alta qualidade, mas, no fim das contas, o desenvolvedor continua sendo o principal responsável pelos requisitos de negócio.

Sem Review, sistemas grandes facilmente apresentam problemas.

E você definitivamente não quer ser acordado no meio da noite para um On-call e descobrir que o culpado foi um código escrito por IA.

Sobre o Review, estas são minhas principais práticas atuais:

1. Olhe primeiro os critérios de aceite, depois os resultados dos testes: Primeiro, cheque os critérios de aceite fornecidos pelo Agente, depois compare com os resultados dos testes end-to-end anteriores para confirmar se as expectativas foram atendidas e se nada foi esquecido. Não olhe apenas quantos testes passaram, mas veja se esses testes validaram o que esse requisito realmente importa.
2. Siga os fluxos de negócio para ver a implementação, focando energia nas partes de alto risco: Checo principalmente permissões, mudanças de estado, concorrência, retentativas, consistência de dados e partes críticas como migração e rollback. Para CRUDs com padrões estáveis, dá para gastar menos tempo — tem uma parte disso que eu nem olho mais hoje em dia.
3. Verifique especificamente abstrações e mecanismos recém-adicionados: Para novas abstrações e mecanismos, uso pensamentos como a Navalha de Ockham para pedir que a IA revise novamente: elas são realmente necessárias? Existe uma implementação mais simples? Trouxeram complexidade demais para resolver um problema local?
4. Considere Criar Bots de Review Dedicados Quando Houver Muitos MRs: Se houver muitos MRs no grupo, um Bot de Review dedicado pode ser projetado para lidar com a revisão cruzada. Diferente de chamar diretamente o pi agent / Claude Code para uma revisão adversarial, como mencionei antes, aqui o foco é combinar as informações de alteração do Git com processos de revisão pré-desenhados, formando uma capacidade de revisão repetível voltada especificamente para MRs.

5. Alguns Resumos e Reflexões

Meu gargalo mais óbvio no desenvolvimento atual é a velocidade de Review.

Os Agentes conseguem empurrar várias tarefas simultaneamente, mas minha velocidade de entender o negócio, julgar soluções e confirmar entregas não aumenta na mesma proporção. Se você apenas deixá-lo escrever mais, provavelmente só vai acumular mais código esperando revisão.

Por isso, o que quero melhorar em seguida é fazer com que problemas repetitivos sejam descobertos e corrigidos antes de chegarem às minhas mãos.

Problemas que podem ser encontrados por checagem de tipos, testes e asserções de negócio devem ser tratados pelo próprio Agente durante o desenvolvimento, tanto quanto possível; aqueles que exigem meu julgamento concentram-se em saber se os requisitos foram entendidos corretamente, se a lógica de negócio principal se sustenta e quais riscos não validados restam nessa alteração.

Bots de Review dedicados podem ajudar nessas tarefas, mas o valor deles depende de reduzirem omissões de problemas relevantes e a carga manual, e não apenas de quantos comentários eles fazem.

Isso também torna meu entendimento sobre Harness gradualmente mais concreto: além de dar aos Agentes o contexto correto, eles também precisam de ambientes capazes de executar tarefas e de bases para julgar os resultados.

Organizei operações feitas repetidamente nos meus autotestes diários em CLIs, scripts e Skills, deixando que ele mesmo rode os sistemas, cheque os resultados e encontre evidências de falhas. Em tarefas semelhantes no futuro, essas capacidades podem continuar sendo usadas e, gradualmente, passadas para outros colegas reutilizarem.

Ao mesmo tempo, esse fluxo de trabalho também precisa de "subtrações" regulares.

Algumas etapas existem para compensar deficiências de uma determinada geração de modelos. Quando os modelos mudam, os benefícios dessas etapas devem ser reavaliados. Tarefas simples vão direto ao ponto; tarefas complexas ganham planejamento, divisão e revisão cruzada. Por exemplo, após as atualizações do Astra, removi algumas restrições excessivamente rígidas do AGENTS.md. Os modelos iteram, e nossos fluxos de trabalho precisam iterar junto.

Claro, testes e Reviews podem reduzir a incerteza, mas os humanos ainda precisam fornecer os critérios de aceite corretos. Mesmo que o código e os testes batam entre si, ambos podem ter entendido os requisitos errado juntos. Testes end-to-end cobrem apenas comportamentos em ambientes e cenários selecionados; tráfego, concorrência e distribuição de dados em ambientes de produção ainda podem trazer novos problemas.

Como desenvolvedor que começou a trabalhar há pouco tempo, ainda espero aprender mais conhecimento profissional na área através do trabalho. No entanto, a IA realmente reduziu algumas oportunidades de pisar na bola pessoalmente. Algumas experiências valiosas, que antes vinham de enfrentar problemas e investigar causas, agora podem se resumir à IA dizendo:

"Eu errei, estou corrigindo agora."

Por isso,

Agora reservo parte do meu tempo diário de desenvolvimento para aprendizado e reflexão, enquanto penso: quais habilidades são realmente necessárias para os profissionais de P&D na era da IA.

Este artigo registra um conjunto de métodos que explorei gradualmente no meu negócio durante meus primeiros meses. Seu escopo de aplicação e suas deficiências, ainda estou descobrindo.

Todo mundo pode começar escolhendo um caminho de autoteste que costuma fazer, tentar deixar o Agente executá-lo de forma independente, preservar as evidências e, em seguida, consolidar as etapas que funcionaram.

Devido a requisitos de confidencialidade da empresa, muitos detalhes não puderam ser incluídos no artigo. Espero que este texto sirva de pontapé inicial para trocarmos ideias, e adoraria ouvir as boas práticas de todo mundo no desenvolvimento real~