Pedi pra IA revisar meu código e virou 48 issues

Até aqui eu não tinha escrito nenhuma linha de código do Owl. Tudo saiu do Claude, do plano ao app rodando no meu Mac.

Pedi uma revisão para saber se havia problemas no que ele fez sozinho e se ele gerava falhas durante a implementação. Também queria ver se ele conseguia se autovalidar olhando a visão geral, e não só uma funcionalidade pequena onde podia ter feito uma gambiarra que funcionava e quebrava outra coisa.

Do plano para as issues

Até então eu trabalhava em cima do plano. Fui fazendo ajustes nele para o Claude corrigir pequenas coisas. Não lembro exatamente quais, mas de tanto trabalhar só em cima de plano decidi abrir também o repositório.

Abrir o repositório acabou sendo positivo também pela organização. Com ele aberto, dava para transformar as fases do plano em issues e ir trabalhando nelas aos poucos. Achei essa maneira melhor do que um grande arquivo markdown com o plano.

Eram vários pontos, e cada ponto abria mais questionamentos e decisões. Corrigindo direto, é fácil se perder e não saber em que momento do progresso total você está.

Dividir em issues é como pegar tasks de um board. Cada uma é independente, tem escopo e regras bem definidos e não fica pegando contexto de outros problemas. Quando chega a vez de uma issue que pode ser afetada por outra, aí a gente olha como a resolução da antiga impacta nela e ajusta.

48 de uma vez

No dia 13 de agosto, o repositório ganhou um modelo de issue com descrição, passos para reproduzir, comportamento esperado e real, arquivos de apoio, ambiente e uma lista de fases para trabalhos maiores. Poucos minutos depois estavam abertas 48 issues, 23 bugs e 25 melhorias.

A lista de fases foi ideia minha. Pensei na issue como um card com escopo bem delimitado e o mínimo de dependências. Se uma implementação tem várias etapas, é como uma task com subtasks, e a issue representa isso. Assim eu evitava puxar em paralelo duas issues que dependessem uma da outra. Com o repositório aberto, qualquer um poderia encontrar o projeto e sugerir modificações.

Foi positivo. Consegui ter uma visão geral e mais concisa do que faltava para “finalizar” essa fase inicial. Depois disso o Owl ia rodar só em manutenção, e eu pararia a fase de concepção da ideia e de criação de funcionalidades para “lançar” o produto.

Não li todas por completo. Li uma versão resumida delas para entender se faziam sentido. Não precisava ir a fundo, porque quando uma fosse puxada para implementar eu ia me aprofundar e ver se fazia sentido de fato. Foi assim que uma delas foi fechada sem virar implementação, e outras viraram decisões para a ferramenta.

Onde a IA errou

A IA é muito boa para pegar vários contextos e agilizar um trabalho que seria de um humano, mas ainda falha, e falha muito. A revisão do próprio código foi um exemplo disso.

Eu não escrevi uma linha de código, e mesmo assim o código tinha falhas e bugs. O Claude teve controle total do repositório desde o começo, do planejamento ao lançamento, e revisava a cada coisa que implementava. Mesmo assim errou.

Não sei quantas interações são necessárias até ele parar de escrever falhas, ou de deixar de enxergá-las. Até hoje, quando chego com uma implementação e ele diz que finalizou e está tudo ok, eu peço para revisar olhando o plano inicial. Ele sempre encontra falhas na implementação que ele mesmo fez.

No próximo post, conto como comparei o Owl com outros apps de notch.