Kodacode 1.3 reúne quatro modos de trabalho do agente em um único cliente para desktop

O agente escreveu o código e alterou uma dezena de arquivos, e então começa o trabalho conhecido: abrir as mudanças, verificar cada edição, executar os testes e depois descobrir por que a automação em CI terminou com um texto estranho em vez de um status normal. O Kodacode 1.3 tenta reunir esse processo fragmentado em um só lugar. Agora, o agente consegue trabalhar com aplicativos por meio da interface, abrir páginas em um navegador integrado, mostrar suas próprias alterações e ser executado em um pipeline com resultados legíveis por máquinas.

O valor prático aqui não está em mais uma janela de chat. Os desenvolvedores recebem um ciclo de trabalho mais coeso: atribuir uma tarefa, acompanhar as ações do agente, revisar o diff e encaminhar o resultado para a ferramenta seguinte. As equipes de produto ganham a possibilidade de montar rapidamente um protótipo interativo com os componentes do projeto. As equipes de automação recebem fluxos visuais com requisições HTTP, ferramentas MCP, condições e aprovação humana obrigatória.

O agente vai além do editor

O modo Computer Use permite que o Kodacode veja a tela, encontre a janela necessária, clique em elementos da interface, role páginas e insira texto. Ele está disponível no aplicativo para desktop e nos plugins de IDE no modo Agent.

Um exemplo simples: é necessário transferir dados de um painel interno para uma planilha, mas o painel não oferece uma API adequada. O agente pode abrir o aplicativo, encontrar o registro, copiar os valores e preencher o formulário. Antes, uma tarefa desse tipo exigiria uma automação separada para o navegador ou a execução manual de todo o trabalho.

Também foi adicionado um navegador integrado. Os links são abertos dentro do cliente para desktop, um trecho selecionado da página pode ser enviado diretamente ao agente e, para verificação, estão disponíveis pesquisa, seleção de elementos e capturas de tela. Isso reduz as trocas entre o chat, o navegador e o editor, embora, por si só, não torne confiáveis as ações do agente.

É justamente nesse ponto que a supervisão se torna importante. Um agente visual pode clicar no botão errado, interpretar incorretamente o estado da interface ou continuar trabalhando depois que uma janela inesperada aparece. Por isso, operações de publicação, pagamento, exclusão de dados ou alteração de configurações não devem ser delegadas sem confirmação humana.

Alterações e protótipos aparecem ao lado da conversa

O cliente para desktop passou a oferecer visualização das alterações em dois níveis: para toda a conversa e para uma mensagem específica. Isso ajuda a separar o resultado de uma determinada tarefa das mudanças acumuladas. O diff funciona até mesmo em pastas sem Git: o próprio aplicativo acompanha as alterações feitas pelo agente.

A área de trabalho pode ser dividida entre o chat e a visualização de arquivos. Ela oferece a árvore do projeto, realce de sintaxe e a possibilidade de anexar um trecho específico à solicitação seguinte. Em uma sessão longa, isso é mais útil do que a pergunta genérica “O que você alterou?”: o desenvolvedor pode apontar diretamente para a linha problemática e pedir a correção exata daquele ponto.

Os protótipos interativos são outro cenário de uso. O agente pode montar várias telas usando os componentes e estilos existentes no projeto, enquanto a equipe compara as versões móvel e para desktop. Isso não substitui uma revisão de design, mas acelera o teste de uma hipótese antes que os desenvolvedores comecem a refinar a implementação.

Flows e CLI tornam o agente parte do sistema

O Flows é um construtor visual de automações semelhante ao n8n ou ao Zapier, mas com a possibilidade de um agente executar etapas individuais. Um fluxo pode ser iniciado manualmente, por agendamento, por webhook ou por outro fluxo. Há suporte para ramificações, loops, operações com arquivos, HTTP, MCP e pausas para aprovação.

Por exemplo, um processo matinal pode coletar notícias, filtrá-las, preparar um rascunho e aguardar a aprovação de um editor. A palavra-chave é “aguardar”: a revisão manual está integrada ao próprio processo, em vez de depender da promessa da equipe de não publicar o resultado automaticamente. O Flows ainda está em beta, portanto é sensato complementar processos críticos com registros e verificações em um sistema externo.

O modo headless foi ampliado para CI. A CLI pode receber um fluxo de solicitações via stdin, retornar eventos como JSON delimitado por linhas, informar o consumo de tokens e encerrar com um código inequívoco. O código 0 indica sucesso; um código diferente de zero indica que a tarefa não foi concluída. Um limite de etapas ajuda a interromper uma execução presa em um loop; quando o limite é atingido, são retornados o motivo da interrupção e o código 2.

A conclusão prática é começar testando a CLI em uma verificação segura, como uma análise de alterações sem permissão de escrita. Depois, é preciso conectar o JSON transmitido em tempo real aos registros de CI, definir um limite de etapas e verificar o tratamento de todos os códigos de saída. Computer Use e Flows devem ser introduzidos em seguida, começando por operações reversíveis e exigindo confirmação antes de qualquer ação externa.