A mesma construção, com a tampa aberta.
A maioria das pessoas nunca sai do primeiro modo: descrevem o que querem e o Codi põe no ar. Este é o outro. O âmbito, os documentos de desenho, o quadro de tarefas, o modelo por trás de cada passo e o próprio repositório estão todos abertos, e cada alteração chega como um pull request com o seu nome no botão de integrar.
O Codi escolhe o modelo certo para cada passo em vez de forçar tudo por uma única subscrição.
Suficiente para definir uma ideia e ver a primeira execução real antes de haver cartão.
Feito para quem tem de responder pelo código.
Não para uma demonstração, nem para uma equipa que não vai rever nada. O modo dev assume que alguém é dono deste produto e que lhe vão perguntar o que mudou.
Três coisas que uma janela de chat não faz.
Isto é um sistema com memória, plano e regra de paragem, e é isso que separa trabalho entregue de uma boa sugestão.
Lê antes de escrever
As suas convenções, os seus comandos de teste e os seus hábitos de revisão são aprendidos no repositório, não adivinhados a partir de um prompt.
Delega e depois revê
Planear, implementar e rever são trabalhos distintos entregues a especialistas diferentes, e quem revê não é quem escreveu o código.
Pára de propósito
A condição de paragem é acordada antes de uma rotina correr sozinha, por isso o trabalho termina numa decisão em vez de se arrastar até alguém reparar.
Por dentro de uma execução.
O que se segue é a parte que a maioria das ferramentas esconde: como um pedido se torna um branch que integraria sem hesitar.
Aprende como o seu repositório funciona
Antes da primeira alteração, o Codi regista como a aplicação corre, como é testada e que convenções o código realmente segue, em vez das que o README diz seguir.
Uma equipa, não um prompt
O trabalho é dividido por agentes com funções estreitas. Cada um devolve um artefacto e o Codi continua responsável pelo resultado que lhe chega.
Funciona onde já trabalha
Acompanhe uma execução enquanto acontece, siga as tarefas no quadro, ou ignore ambos e reveja o pull request no GitHub como faria a qualquer contribuidor. O trabalho não fica preso num chat que não consegue pesquisar.
O que recebe, contado.
Os números que descrevem o produto, e não um gráfico de crescimento.
Acessíveis com uma única chave de workspace.
As execuções do construtor e os pedidos ao AI Gateway saem do mesmo número.
Enterprise, com termos definidos consigo.
As operacionais.
As perguntas gerais estão respondidas na página inicial. Estas são as que surgem quando já está mesmo a considerar.
Tenho de usar o modo dev?+
Não. É o mesmo produto de qualquer forma. A maioria das pessoas descreve o que quer, aprova o que recebe e nunca abre nada disto. O modo dev existe para quem prefere ler o plano a ouvir falar dele, e pode entrar nele num projeto que começou no outro modo.
O meu repositório precisa de ter testes?+
Não, mas ajuda. Onde existe uma verificação, o Codi fá-la passar antes de dizer que o trabalho está pronto. Onde não existe, escreve o teste junto com a alteração para que a execução seguinte tenha algo contra o que se provar.
Como aprende as nossas convenções?+
A partir do próprio repositório: padrões existentes, histórico de commits, configuração de lint e formatação, e os comandos que o projeto já usa. Escreve o que encontrou num mapa que pode ler e corrigir.
E se eu rejeitar o pull request?+
O branch fica para inspecionar ou apagar, e a rejeição passa a ser contexto. O Codi não reabre a mesma alteração, e uma rejeição repetida pára a rotina em vez de tentar indefinidamente.
Posso parar uma execução a meio?+
Sim. Pare-a a partir da própria execução e o trabalho interrompe-se no passo atual com o recibo intacto. Nada fica meio integrado, porque integrar é uma decisão separada que sempre foi sua.
Funciona em repositórios privados?+
Sim. Funciona através do acesso ao GitHub que lhe conceder e pode ser limitado a repositórios específicos em vez de a toda a organização.
Que linguagens e frameworks suporta?+
Não está limitado a uma lista fixa. Como lê o seu projeto em vez de encaixar um template, o limite prático é o repositório conseguir descrever como se constrói e como é verificado.
Uma frase chega para começar.
Sem migração, sem reescrita, sem um processo novo para adotar primeiro.