Como eu toco uma software house feita de agentes de IA

Sou engenheiro de software com 7 anos de experiência e toco uma software house em que quase todo o trabalho é feito por agentes de IA. Eu decido o que será construído, reviso e sou o único que faz merge na main. Este post explica como isso funciona e como o site que você está lendo virou a prova de que era possível.

Quase tudo abaixo vem dos repositórios da organização no GitHub; quando vem de mim, eu digo. As contagens são de 31 de outubro de 2026 e os horários estão em UTC.

A ideia: contextos pequenos, tudo escrito

Um agente trabalha melhor com um contexto curto e focado, então eu não mantenho conversas longas abertas. Uma sessão começa com o contexto vazio, carrega o seu papel, pega uma tarefa e lê só o que ela precisa. Quando a sessão fica pesada, eu a troco por uma nova. A regra que torna isso possível está no handbook compartilhado: tudo o que uma sessão futura precisar deve estar escrito no GitHub antes de a sessão acabar. Decisões e regras vão para o handbook, o andamento vai em comentários nos tickets, código e testes vão em pull requests, e o agente PO (product owner) guarda o seu estado de trabalho num arquivo de notas.

É isso que eu quero dizer com “o GitHub é a memória”. É uma escolha de projeto, e na minha opinião é mais barata e mais fácil de auditar do que uma conversa longa. É opinião: eu não medi o custo.

O time

A casa tem cinco tipos de participante:

• Eu, o dono. Trago as ideias, respondo perguntas, reviso e faço merge.
• O agente PO. Ele me entrevista, transforma uma ideia em tickets pequenos e mantém o backlog e o handbook honestos.
• O agente de design. Ele trabalha comigo na identidade visual e no desenho das páginas, e entrega documentos de design.
• Agentes de desenvolvimento. Dois deles trabalham a fila, um ticket por vez, com testes e documentação.
• O agente escritor. Ele me ajuda a escrever estes posts. Trabalha a partir dos repositórios e da minha entrevista com o PO, eu decido o que é dito, e ele faz o que eu peço e me auxilia.

Cada agente tem a sua própria identidade no git e um label nos pull requests, então o histórico mostra quem fez o quê. Os pull requests são abertos a partir da minha conta no GitHub, o que significa que o campo “merged by” mostra o meu nome até nos merges que um agente faz com o meu token. O label do agente é o sinal confiável.

Como um ticket anda

O trabalho passa por um board de projeto com oito status, e cada status tem exatamente uma parte que precisa agir em seguida: Backlog, Refining, Awaiting Input, Queue, In Progress, Dev Blocked, In Review e Done.

O status mais importante é o Queue. Um ticket na fila é uma especificação aprovada, e é isso que permite que os agentes trabalhem sem me perguntar a cada vez. O agente que refina o ticket decide quando ele está pronto, usando um checklist escrito: critérios de aceitação testáveis, tamanho S ou M, nenhuma pergunta em aberto que só eu possa responder e nenhum segredo ou serviço pago necessário. Se eu preciso responder algo, o ticket vai para Awaiting Input com uma pergunta clara.

Um agente de desenvolvimento pega um ticket criando uma branch de trava, que o GitHub só aceita uma vez, então dois agentes não conseguem pegar o mesmo ticket. Ele trabalha numa branch própria, abre um pull request e espera os checks: testes unitários, testes end-to-end, Lighthouse e varredura de segredos. Se um check falha, ele corrige. Depois de 3 tentativas falhas na mesma falha, ele para e marca o ticket como Dev Blocked. Um ticket que fica mais de 24 horas em In Progress é inspecionado pelo PO.

Para trabalhos maiores existem os épicos, que têm uma branch de integração. Os pull requests dos sub-tickets são mesclados nessa branch pelos agentes de desenvolvimento quando os checks estão verdes, e eu reviso o épico inteiro num único pull request para a main.

A prova de conceito: o site

O primeiro produto foi este site. O repositório foi criado em 30 de outubro de 2026 às 04:39. O épico com o MVP inteiro (as páginas Home, About e Contact em inglês e português, mais o workflow de deploy) foi mesclado na main às 15:28, ou seja, 10 horas e 49 minutos depois, medido da criação do repositório até o merge do pull request do épico.

Nove pull requests foram mesclados na branch do épico. Oito deles foram mesclados entre 4 e 11 minutos depois de abertos, o que eu medi pelos horários de abertura e de merge. O nono, o design da página Home, esperou 7 horas e 1 minuto pela minha revisão. Os agentes não foram a etapa mais lenta; foi a revisão, porque eu estava dormindo nesse intervalo. Os agentes continuaram trabalhando e esperando a minha revisão. Esse detalhe vem de mim, não do GitHub, que só mostra quando o pull request foi aberto e mesclado. Considero isso uma boa descrição do arranjo, já que a revisão é a parte que eu decidi manter.

O que a casa não é

Ela não é totalmente automática. Eu escrevo a direção, respondo as perguntas que os agentes não conseguem responder, reviso toda mudança que chega na main e decido o que é bom o bastante. Também não está livre de erros. A casa existe para tornar o trabalho visível, e por isso os erros podem ser vistos e corrigidos às claras.

No momento em que escrevo, os quatro repositórios que guardam a casa e o primeiro produto (o handbook, o template de projeto, o site e o perfil da organização) somavam 53 pull requests mesclados e 40 issues fechadas. Contei pela API do GitHub em 31 de outubro de 2026 e deixei de fora o repositório privado de notas do PO.

Escrevi este post com a ajuda do agente escritor, que trabalhou a partir dos repositórios e da minha entrevista com o PO. Eu dirigi o que ele diz, e eu o reviso e faço o merge pessoalmente. Os próximos posts vão contar, cada um, a história de um projeto, a partir do repositório dele.