(Este é o material apresentado no meetup do Claude Code em Seul, em 17 de dezembro. Consulte a apresentação completa neste link.)
Objetivo de “consultoria interna” da equipe AX da Corca
- Estabelecer boas práticas de engenharia agêntica na Corca e criar um terreno fértil para evoluí-las continuamente em conjunto.
- Na Corca, “práticas de engenharia agêntica” são definidas como “métodos práticos para usar agentes de IA de forma a aumentar ao mesmo tempo a qualidade e a produtividade do software”.
- Fazer com que a capacidade de engenharia se torne outra competência central da Corca.
- Para isso, começamos ajudando a equipe Moonlight.
Situação do Moonlight
- Moonlight é o principal produto da Corca e se apresenta como “um colega de IA para ler artigos científicos junto com você”.
- “Conversar com PDFs” é uma ideia que existe desde o comecinho do ChatGPT. Entre tantos produtos concorrentes, ela sobreviveu, e agora está no início da curva J (com crescimento recente explosivo de usuários chineses).
- Houve muitos erros e acertos até chegar aqui, mas a principal vantagem competitiva foi manter, “de qualquer forma”, a velocidade e o ritmo de desenvolvimento de funcionalidades.
- Algumas decisões iniciais para ganhar velocidade
- typescript strict: false
- Minimização de testes automatizados
- Permissão para duplicação e hardcoding
- Sem divisão rígida de funções. Quase todos os membros da equipe (6 de 7) implementam com agentes de código e abrem PRs
- Depois de entrar em órbita, a dívida técnica começou a pesar aos poucos
- O produto ficou mais complexo, a equipe ganhou muitos novos integrantes e, ao mesmo tempo, havia muitos experimentos rodando em paralelo
- A velocidade de melhoria do produto foi desacelerando gradualmente, e a sensação de insegurança foi aumentando
- A carga de code review ficou concentrada em algumas pessoas e começaram a surgir erros grandes e pequenos
Tarefas imediatas para a equipe AX
- [Produto] Vamos fazer a qualidade do Moonlight melhorar, ao mesmo tempo em que a velocidade para adicionar e melhorar funcionalidades aumenta!
- [Equipe] Vamos fazer com que qualquer pessoa consiga mexer no código do Moonlight com mais facilidade e sinta menos estresse após o deploy!
- [Cultura] Para alcançar 1 e 2, as equipes Moonlight e AX devem colaborar para descobrir, aplicar, aprimorar e espalhar gradualmente pela empresa boas práticas de engenharia agêntica!
→ Entendemos que a maior parte disso seria resolvida se os agentes de código passassem a dar respostas melhores
O que é preciso para que os agentes deem respostas melhores?
[1] Fazer com que sigam um bom caminho desde o começo
- Se a qualidade da base de código é alta, isso traz vantagens em três aspectos
- Menos contexto desnecessário precisa ser incluído (Less is More)
- O agente tende a seguir os bons padrões já existentes
- É possível induzir um viés para aumentar a probabilidade de que a resposta seja amostrada de regiões do código pré-treinado em que se concentram códigos de alta qualidade
- Há muitos estudos mostrando que inserir contexto de alta qualidade leva a respostas melhores.
- (Hipótese pessoal) Se você enviar uma solicitação ao agente em uma base de código onde a ordem dos imports é organizada, não será mais provável que o código pré-treinado com imports organizados seja, no geral, de qualidade mais alta?
- No blog da Anthropic: “Só de fazer usar fontes interessantes, outros elementos do design também melhoram.”
[2] Impedir que sigam um caminho errado
- É possível bloquear caminhos errados com várias ferramentas de análise estática, como verificação de erros de tipo, erros de linter, testes automatizados, detecção de código morto, checagem de tamanho de arquivos, checagem de complexidade, imposição de dependências, imposição da proporção entre código de teste e código de produção etc. (fazendo o agente repetir o trabalho até passar nos critérios)
[3] Pedir principalmente o que fazem bem
- Pessoas, LLMs e algoritmos têm pontos fortes diferentes. Escolher com sabedoria o que usar em cada momento economiza tempo e custo
- ex) pedir para não esquecer chaves de i18n vs pedir para rodar um script que encontra chaves de i18n ausentes
- Quem faz bem o quê e em que momento muda com o tempo e depende do domínio do problema. Criar o hábito de manter esse “feeling” atualizado dentro do próprio domínio é vantajoso
- ex) quando sair um modelo novo, testá-lo com seu próprio benchmark, seguir exemplos famosos das redes sociais
[4] Ajudar no que não fazem bem
- Ainda assim, é sempre preciso confirmar se realmente não fazem bem. A menos que delegar seja arriscado ou excessivamente ineficiente, é melhor que IA/algoritmos façam o máximo possível em vez de pessoas. (Afinal, o custo de tokens tende a ficar tão barato quanto conta de luz.)
- Se realmente não conseguirem? Faça outra LLM revisar
- ex) da forma mais simples: “Isso foi escrito por um desenvolvedor iniciante...”
- Para que a IA trabalhe melhor, é preciso oferecer um ambiente em que a IA possa trabalhar melhor. Em outras palavras, aquilo que o agente (atual) provavelmente não faz bem (aqui) deve ser complementado por pessoas, algoritmos e outros agentes
Pontos de atenção
- O Moonlight é um foguete que acabou de começar a voar; a equipe AX é uma visitante que veio de fora
- Devíamos evitar a todo custo o cenário em que alguém de fora chega, “faz algo” e vai embora
- O esforço por qualidade não deveria atrapalhar (na medida do possível) o desenvolvimento de funcionalidades
- Decidimos misturar, em proporção adequada, trabalhos que não mudam muito a forma habitual de trabalhar com iniciativas mais desafiadoras, mas eficazes
→ Imaginamos um cenário em que as equipes AX e Moonlight descobrem e aplicam “juntas” práticas adequadas à equipe e ao produto, enquanto a qualidade do código, a qualidade do produto e a capacidade da equipe melhoram ao mesmo tempo
Principais resultados das últimas 4 semanas
[1] Bons hábitos estão se consolidando e bons padrões estão sendo descobertos
- Subir todos os dias commits de micro-refatoração (tidying) sem necessidade de revisão de PR
- Prompts para seguir commits exemplares do passado (como suporte a novos modelos) e prompts para descobrir e reunir esses padrões
- Uma SKILL de code review incorporando a persona de um sênior
[2] Começamos a medir e visualizar métricas de qualidade de código. O número de erros/avisos em relação às linhas de código está caindo rapidamente
- As métricas de qualidade do código às vezes diminuem gradualmente, às vezes de forma dramática
- O fato de o tidying melhorar a base de código um pouco a cada dia foi essencial para criar confiança de que, em algum momento, daria para enfrentar grandes refatorações e trabalhos maiores
- Aplicando knip pacote por pacote, também removemos códigos antigos e não utilizados
- Métricas devem sempre ser complementares. É muito melhor ter 5.000 erros em um código de 100 mil linhas do que 1.000 erros em um código de 1.000 linhas. Por isso, em vez de olhar apenas a contagem bruta, analisamos a taxa de erros por linha para definir indicadores de gestão mais saudáveis
- O número de linhas significativas, excluindo comentários e espaços em branco, foi medido com tokei
[3] Corrigimos um problema de vazamento de memória que persistia havia mais de 1 ano
- Mobilizando ao máximo várias ferramentas e técnicas de prompting, incluindo repomix, conseguimos resolver, após algumas tentativas, um problema de memory leak que durava havia mais de um ano
- Estamos felizes porque parece que agora dá até para reduzir o tier das instâncias de servidor
[4] Surgiram estruturas de abstração, prompts e scripts que tornam mais fácil e seguro adicionar/remover experimentos que rodam em paralelo toda semana
Como resultado, a qualidade do código continua subindo, o desenvolvimento de funcionalidades ficou mais seguro e mais rápido, e a capacidade de engenharia (agêntica) da equipe vem aumentando de forma consistente — esses três fatores estão funcionando em ótima sintonia
Tentativas e erros
- Claro que não deu certo desde o começo. Inicialmente queríamos fazer duas coisas ao mesmo tempo
- Introduzir de uma vez mudanças de alto valor, ainda que mais arriscadas: ativar strict, adotar regras rígidas de eslint, apagar todo o código morto de uma vez etc.
- Avançar com segurança, mesmo em passos menores: deixar um commit de tidying por dia etc.
- Mas o primeiro caminho era assustador demais para “conseguir” fazer, e o segundo era sem graça demais para que as pessoas “quisessem” fazer
- Então mudamos para isto
- Tornar as coisas desafiadoras mais seguras (ativar
tsc strictarquivo por arquivo, corrigir e depois desligar; aplicar eslint com o mínimo de regras; usar knip um pacote por vez etc.) - Tornar as coisas seguras mais valiosas (como criar prompts que sugerem tidying com base nas mudanças recentes)
- Tornar as coisas desafiadoras mais seguras (ativar
- Ainda há muitas tarefas pela frente
- ativar
typescript: strict - adotar zod para alinhar contratos entre servidor e cliente
- introduzir regras de eslint mais rigorosas
- aumentar a cobertura de testes automatizados
- bloquear caminhos errados com uma variedade maior de ferramentas de análise estática
- ativar
- Estamos avançando juntos, com constância, e sem jamais ir devagar
One More Thing: meu hábito de aprendizado + depuração
Numa situação como essa, aprende-se muito perguntando à IA e também a especialistas, fazendo validação cruzada. Esse processo também está sendo registrado em PRs e issues no GitHub e no Slack, para compartilhar com a organização
- Alguém sabe algo que eu não sei
- Como essa pessoa adquiriu esse conhecimento/essa experiência? Por quais sinais ela identificou esse problema?
- Descobrir meus erros, bugs ou antipadrões da base de código
- Quais foram as causas que tornaram esse problema inevitável? Como melhorar a estrutura para errar menos da próxima vez e detectar erros mais cedo?
Encerramento
- Se fizermos a IA dar respostas melhores, uma parte considerável dos problemas da equipe de produto pode ser resolvida
- Melhorando a qualidade da base de código (seguir um bom caminho desde o começo) e introduzindo várias ferramentas (bloquear caminhos errados)
- Vamos ajudar os membros da equipe a elevar sua capacidade de engenharia agêntica (pedir o que fazem bem, ajudar no que não fazem bem)
- Ao colaborar com a IA de forma inteligente, se a capacidade da equipe aumentar e um bom ambiente for construído, “melhorar a qualidade” e “aumentar a velocidade de adição/melhoria de funcionalidades” podem perfeitamente acontecer ao mesmo tempo
- Em vez de trazer algo bom “de fora” para ajudar, vamos descobrir e tentar “por dentro”, juntos. Vamos medir, visualizar, celebrar e aprender uns com os outros
3 comentários
Até saiu uma matéria sobre o meetup.
[Reportagem] "Nasce na Coreia o usuário nº 1 do Claude"… visitamos o evento de meetup da Anthropic
https://n.news.naver.com/mnews/article/092/0002402940
Cerca de 1,8 milhão de won por mês, caramba.
Parece que isso também pode ser significativo como uma forma de ajudar a participação ativa e o crescimento de desenvolvedores juniores.
Ah, isso mesmo haha, estamos trabalhando duro nessa frente também.