Há alguns meses que não escrevo código pessoalmente. Nem uma linha. Nem scripts, nem correções, nem refatorizações feitas à mão.
Em vez disso, escrevo tickets. Objetivos, resultados esperados, critérios de aceitação. Como um Product Owner no Jira, só que quem assume o ticket não é uma pessoa. É uma IA. Reformula o que entendeu, abre uma branch, entrega o trabalho e apresenta os resultados. Iteramos até concluir corretamente a tarefa.
E não avançamos um ticket de cada vez. Avançamos com cinco, dez, quinze e, por vezes, vinte em paralelo.
O que é um Agentic Development Environment?
Um Agentic Development Environment (ADE) não é um IDE com IA acrescentada. É um ambiente concebido para os agentes de IA fazerem o trabalho por si, com o utilizador como árbitro em vez de executor.
Num IDE clássico, está no centro: edita, testa e cria commits. A IA sugere. Num ADE, descreve a intenção, a IA faz o resto e valida o resultado. A unidade de trabalho muda radicalmente: já não é o ficheiro, é o ticket.
Porquê um kanban e não um chat?
A maioria dos produtos de IA para programadores são chats. Funcionam bem para utilização individual, mas deixam de funcionar assim que tenta executar várias tarefas em paralelo:
- Um chat é linear; um projeto tem estrutura de árvore.
- Um chat esquece o contexto entre sessões; um ticket conserva-o.
- Um chat não pode dizer «esta tarefa está bloqueada por aquela»; um kanban pode.
- Um chat não se relê a si próprio; um ticket serve como especificação, registo de execução e memória de longo prazo do projeto.
O kanban é o formato natural desta forma de trabalhar. Um cartão = uma intenção. Um estado = uma situação do trabalho (Por fazer, Em curso, A aguardar revisão, Falhou, Concluído). Uma coluna «Em curso» com quinze cartões já não é um modo degradado: é o modo normal.
Como podem avançar quinze tickets em paralelo
A peça que torna isto tecnicamente possível são os worktrees de Git. Cada ticket é executado no seu próprio worktree: uma cópia isolada do repositório, na sua própria branch, sem interferir com as outras. Quinze tickets, quinze worktrees, quinze branches. Sem conflitos de estado durante a execução.
No final, cada ticket é integrado por rebase sobre a branch base antes de ser reintegrado. Se a base avançou enquanto um agente trabalhava, repetimos os testes sobre a versão após o rebase: é a única forma de evitar que dois tickets que passam isoladamente produzam uma integração quebrada.
Os hooks de Git como rede de segurança
Quando a IA produz código em grande escala, precisa de redes de segurança automatizadas . Os hooks de Git tornam-se essenciais: lint, formatação, verificação de tipos, testes unitários; tudo é executado no pre-commit. Se um hook falha, o commit falha e o agente diagnostica, corrige e tenta novamente.
Nada de --no-verify. Nunca. O hook não é uma sugestão: é o contrato com a branch.
O que acontece se algo falhar na mesma?
Nenhum sistema é infalível. Quando um agente erra, quando um teste passa localmente mas falha na CI, quando uma publicação corre mal, não corrigimos à mão. Abrimos um ticket. Um ticket que pede a outro agente para procurar a causa raiz ao longo do pipeline. O ADE torna-se a sua própria rede de segurança: pode diagnosticar-se a si mesmo.
Parece contraintuitivo, mas é isso que torna a orquestração sustentável. Sem esse ciclo, volta à armadilha clássica de «vou corrigir isto rapidamente à mão» e perde o benefício da orquestração em quinze minutos.
Dois meses em produção
Este sistema funciona há dois meses. Dois meses em que construo Singularity com Singularity. O produto utiliza-se a si próprio diariamente, em produção, num projeto real com utilizadores reais.
A aceleração real ronda as 50× no trabalho que antes fazia à mão. E sei que ainda estou muito abaixo do limite. O limite já não é a minha velocidade a escrever nem a capacidade de manter cinco assuntos na cabeça ao mesmo tempo: é a qualidade das minhas especificações. Essa é a única coisa que continua a ser 100 % humana.
Perguntas frequentes
Um ADE substitui completamente um IDE?
Não. Singularity inclui um terminal e um editor de código nativos: pode intervir à mão a qualquer momento. O objetivo não é proibir o código humano, é torná-lo opcional. Na maior parte do tempo, já não precisa de o fazer.
Como lida a IA com um ticket mal escrito?
Mal. É precisamente por isso que a qualidade do ticket importa. Um agente de IA bem orquestrado reformula o que entendeu antes de começar a programar, e valida o contrato. Se a reformulação não estiver correta, corrige-a antes de iniciar a execução.
O que acontece quando dois tickets alteram os mesmos ficheiros?
Cada ticket é executado no seu próprio worktree, por isso a execução em si não gera conflitos. Na reintegração, o segundo ticket faz rebase sobre o resultado do primeiro. Se surgir um conflito, a IA propõe uma resolução fundamentada e decide.
Até que ponto pode confiar no código gerado?
Tanto quanto confia nos seus hooks e testes. O código não recebe um passe livre por ter sido escrito por uma IA: passa pelas mesmas redes de segurança que qualquer outro código. Se o conjunto de testes for fraco, a orquestração irá expô-lo rapidamente.
Funciona em qualquer projeto?
Quanto melhor testado estiver o projeto, mais eficaz será a orquestração. Num projeto sem testes, a IA entrega rapidamente, mas terá de rever mais. Num projeto bem equipado (hooks, CI, testes), a relação entre intervenção humana e IA favorece a velocidade muito depressa.
Singularity estará disponível em breve
Singularity é a aplicação que construímos para utilizar este ADE diariamente. Um cliente nativo para macOS, Windows e Linux.
Para compreender a filosofia do produto por trás de tudo isto, leia o manifesto.