Escreva o que precisa existir. O resto é fluxo.
Seu agente já escreve o código. O que falta é quem diga o que fazer, em qual repositório e sob qual critério.
rtb.Escrever código deixou de ser o gargalo. O processo em volta, não.
Um agente de IA lê o repositório, entende o padrão e implementa. Isso melhora sozinho a cada modelo novo. O que nenhum agente decide é o que é pronto, o que bloqueia, quem aprova e quem responde por uma mudança em produção, porque essas não são decisões técnicas, são decisões da sua empresa.
A ferramenta de IA implementa em minutos o que levava um dia. O que não mudou foi o resto: alguém precisa dizer o que fazer, em qual sistema, com qual critério, e conferir o que voltou.
O agente não sabe qual repositório recebe a correção, qual é a regra do projeto nem o que já foi decidido. Quem sabe é a pessoa, e ela reexplica tudo a cada tarefa.
Um time consegue produzir mais código do que consegue revisar. Sem processo de aceite na mesma proporção, o resultado é fila de pull request parado, trabalho feito que não vira entrega.
Deixar um agente entregar sozinho é confortável até ele tocar uma migração de banco, uma regra de autenticação ou o dado de um cliente. Confiança precisa de regra escrita, não de hábito.
O trabalho deixa de esperar por alguém disponível.
A execução acontece sozinha. As etapas de qualidade conferem. Você entra onde a decisão é sua, e só onde ela é sua. Mesmo projeto, mesma verdade, atualizada pelo trabalho real.
Do plano à entrega, sem alguém empurrando cada passo
Cinco passos. Os três do meio acontecem sem você; o primeiro e o último são onde a sua decisão vale.
Cada projeto tem seus repositórios cadastrados, com a branch base e os comandos que verificam o trabalho. A tarefa aponta para um deles, ou para dois, quando a entrega atravessa a stack.
Começa na sua máquina: você instala, aponta os projetos e ele puxa a tarefa, prepara o repositório certo, trabalha na branch e abre o pull request. Quando quiser que continue rodando de madrugada, é a mesma instalação num servidor.
Os comandos que o repositório declara (lint, testes, build) rodam antes de a tarefa mudar de etapa. O que falha volta com o motivo, e a volta é contada.
Revisão de código, testes, segurança: cada raia do seu fluxo pode ter um agente próprio, com competência própria. Quem revisa julga contra o critério de aceite escrito antes, não contra o que foi implementado.
Mudança de rotina, com tudo verde, segue sozinha. Mudança que toca migração, autenticação, contrato público ou dado de cliente espera uma pessoa. Sempre.
Decidir o que deve ser feito, e assumir o que vai para produção. É o trabalho que não delega, e é exatamente para ele que a automação abre espaço.
Quatro superfícies, uma verdade só
Cada tela responde a uma pergunta específica de quem a abre. Nenhuma delas é um painel para você montar.
O trabalho chega com o contexto dentro
A tarefa carrega o objetivo, o critério de aceite, o repositório alvo, a branch base e o que depende dela. É o que permite o agente começar sozinho, e é exatamente o que a pessoa recebe no terminal.
Concluir é parte de executar. Se o trabalho nasce da tarefa, o andamento é consequência, não uma segunda digitação.
O plano é a fonte do projeto, não um documento para transcrever
Você escreve o plano uma vez. O Runtable monta frentes, tarefas, ordem e dependências a partir dele, e é ali que o critério de aceite nasce, antes de qualquer linha de código existir.
A medida é o que foi aceito, não o que foi executado
A linha mostra onde o trabalho parou de andar: na execução, na verificação ou esperando aprovação. O motivo fica registrado no fluxo, não numa reunião.
Contar tarefas por hora premiaria volume, inclusive volume errado. Por isso a leitura é tempo até o aceite e retrabalho depois da entrega.
As datas saem do trabalho, não de uma planilha à parte
Ordem e estimativa das tarefas desenham a linha. Quando algo trava, o atraso aparece onde nasceu, com o dia em que travou e o que está esperando.
Autonomia só é aceitável com limite escrito
O que um agente pode fazer sozinho é dado do projeto, auditável, e não uma instrução dentro de um prompt. Estas são as regras que valem antes de qualquer configuração sua.
Migração de banco, autenticação, contrato público de API e dado de cliente exigem aprovação humana, em qualquer projeto, em qualquer configuração. Essa linha não tem chave para desligar.
O revisor recebe o critério de aceite, o código e o resultado das verificações. Não recebe a conversa de quem escreveu. Sem isso, a revisão vira confirmação do mesmo engano.
Se a mesma tarefa volta pela mesma etapa três vezes, ela para e chama uma pessoa, com o motivo da última recusa. Fluxo automático que não converge é custo invisível.
Tarefa sem repositório definido não é executada: vira impedimento com responsável. Agente parado é melhor que agente implementando no sistema errado.
Cada projeto escreve com a própria identidade. A chave de um cliente não alcança o repositório de outro, mesmo rodando na mesma máquina.
O painel mostra tempo até o aceite e retrabalho depois da entrega. Contar tarefas por hora premiaria volume, inclusive volume errado.
Transparência contínua no lugar da reunião de status
A parte interessada abre e entende em segundos o que saiu, o que está em andamento e o que vem, na linguagem dele, sem jargão de sprint, PR ou ticket.
Jira, Trello e Linear organizam o trabalho de quem executa. O Runtable executa o trabalho e organiza quem decide.
Comparativo do uso padrão de cada ferramenta, sem plugins nem integrações compradas à parte. Todas as três fazem bem o que se propõem, a diferença está em quem faz a tarefa andar.
O que o Runtable não é
Registrar isso agora evita que o produto se dilua depois, e evita que você adote esperando outra coisa.
Quem escreve o código é o agente que você já escolheu, rodando na sua máquina, com a sua credencial. O Runtable decide o que ele faz, em que ordem e sob quais garantias, e nunca manda comando, só contexto.
É feito para desenvolvimento de software em software house, multi-projeto e multi-conta. Servir "qualquer time" custaria exatamente o que o torna diferente.
Visibilidade existe para dar previsibilidade e destravar o trabalho, nunca para medir pessoa. Você não vai encontrar ranking, nome ao lado de número nem tempo de tela.
Trabalho autônomo só é aceitável com limite escrito. Por isso o que um agente pode aprovar sozinho é dado auditável do projeto, não uma instrução dentro de um prompt.
O que costumam perguntar antes de testar
Ele orquestra a execução. Quem digita o código é o agente de IA que você já usa, rodando onde você instalou (a sua máquina, para começar), com a sua credencial. O Runtable diz o que fazer, verifica o resultado e roteia a tarefa.
Não. O Runtable nunca manda comando para o agente, só texto: objetivo, critério de aceite e contexto. O binário executado é o que estiver instalado na sua máquina.
Cada projeto cadastra seus repositórios, e a tarefa aponta para um ou mais deles. Projeto de repositório único herda automaticamente. Tarefa sem alvo em projeto com vários não é executada, vira impedimento com responsável.
Antes de mudar de etapa, rodam os comandos que o próprio repositório declara. O que falha volta com o motivo. Depois disso, cada etapa de qualidade tem um agente que julga contra o critério de aceite escrito antes da implementação.
Mudança que toca migração de banco, autenticação, contrato público de API ou dado de cliente. São quatro vetos absolutos: valem em qualquer projeto e não têm configuração que os desligue.
Não. Começa na sua máquina, com um projeto, e já roda vários em paralelo. O limite é seu, declarado por repositório, por agente e por instalação. O servidor entra quando você quiser que o trabalho continue de madrugada e não fique preso ao seu computador ligado. É a mesma instalação, em outro lugar.
Não. Ele continua puxando trabalho no terminal com o mesmo comando, e a fila dele já vem filtrada pelo repositório em que está. É a mesma ferramenta nos dois modos: ele trabalhando, ou ela trabalhando por ele.
Não. Sprint é agrupamento opcional. Quadro, lista, backlog, linha do tempo e burndown são formas de olhar o mesmo trabalho, você usa as que fizerem sentido.
Do documento à entrega, sem empurrar cada passo.
Comece na sua máquina, com um projeto: escreva o que precisa existir, aponte o repositório e veja a primeira frente virar tarefa, entrar no quadro e chegar até o pull request. Onde você quer olho humano, cria a etapa. Onde não quer, o trabalho segue sozinho.