A Apollo consegue transformar uma call de vendas numa spec e num pull request?

Numa call, um cliente pergunta se o produto consegue exportar pro formato dele até sexta. A sala concorda com a cabeça. A call termina. Aí o requisito começa sua morte lenta: ele mora na memória de uma pessoa até ela digitar num doc, o doc espera alguém ler, a leitura vira um ticket, o ticket espera uma sprint, e em algum ponto desses repasses o “até sexta” silenciosamente vira “no próximo trimestre”. Ninguém decidiu isso. Simplesmente vazou em cada emenda.

E aqui está a parte estranha. Quando a call terminou, a parte difícil já estava feita. O cliente tinha enunciado o requisito em voz alta, com as próprias palavras, com um dono implícito e uma data anexada. Tudo depois disso foi transcrição, roteamento e espera, trabalho de escritório fantasiado de processo.

É essa a ideia inteira, e o resto deste texto é o mecanismo. A transcrição já contém o requisito; o resto, a tarefa, a spec, a branch, o draft PR, é um pipeline, não uma reunião. O trabalho entre “eles falaram” e “um engenheiro pode revisar uma correção pra isso” é encanamento. E encanamento é uma coisa que um sistema operacional roda, pra uma pessoa não ter que rodar.

Primeiro, o que de fato vaza

Percorra o caminho ingênuo, o que quase toda empresa roda hoje, e conte os repasses.

A call acontece. Um vendedor, se for caprichoso, digita um resumo depois. O resumo vai pra um canal ou um doc. Uma pessoa de produto lê, eventualmente, e decide que vale a pena fazer. Ela escreve um ticket. O ticket é refinado, estimado, priorizado. Um engenheiro pega, lê o ticket e descobre que o ticket perdeu a nuance que o vendedor perdeu da call, então ele faz uma pergunta de esclarecimento, que volta por dois daqueles caminhos, passando por gente que lembra pela metade.

Cada seta nessa corrente é um lugar onde o requisito pode travar, encolher ou sumir.

Parece rigor. É quase só latência. A informação não ficou melhor enquanto viajava por cinco pessoas e quatro ferramentas, ficou pior, porque cada repasse é uma cópia com perda feita por alguém com a própria caixa de entrada pegando fogo. As palavras exatas do cliente, a parte que importava, estão paradas numa gravação que ninguém vai abrir de novo.

Então a pergunta não é “será que a IA consegue escrever código”. Todo mundo já vê que consegue. A pergunta é se o vão confuso, humano e multi-ferramenta entre a call e o código pode ser rodado como um pipeline. Porque é nesse vão que o trabalho de fato morre.

Extração: a transcrição é dado estruturado vestido de fantasia

O jeito ingênuo de capturar uma call é um resumo. Um parágrafo que um humano escreve de memória, horas depois, otimizado pra parecer caprichado num canal.

Resumos falham de um jeito específico: eles guardam o clima e largam os compromissos. “Call ótima, muito interesse, eles querem umas coisas de exportação” é uma frase que sobreviveu a mil pipelines e não construiu nada. O dono sumiu. O verbo sumiu. A data sumiu. O que sobra não pode ser executado, só rediscutido.

A transcrição não tem esse problema, porque ela nunca editorializou. É um registro de quem falou o quê. E enterrados nela estão exatamente os três campos que qualquer tarefa precisa: um dono (quem é responsável), um pedido (o que especificamente) e um prazo (até quando). “Você consegue ter a exportação em CSV até sexta?” não é um clima. É uma linha numa tabela que por acaso está vestida com a fantasia de uma frase.

O primeiro movimento, então, não é resumir a call. É lê-la do jeito que um parser lê um log, e puxar os compromissos como campos estruturados. Dono, pedido, prazo. A transcrição já contém o requisito; extração é só se recusar a deixá-lo preso na prosa.

É esse o passo que torna tudo o resto possível. Um resumo é um beco sem saída, um humano tem que reler pra agir sobre ele. Uma tarefa estruturada é um fio vivo: pode ser atribuída, agendada e entregue pro próximo estágio sem uma pessoa parada no meio redigitando.

Da tarefa à spec: nomear o que “pronto” significa antes de alguém construir

É aqui que a maioria dos sonhos de automação capota. Você tem uma tarefa, “construir exportação em CSV até sexta”, e a tentação é jogá-la direto num gerador de código e torcer.

Isso falha, e falha do mesmo jeito toda vez. Uma tarefa diz o que alguém quer. Ela não diz como é o pronto. “Exportar” quer dizer todos os campos ou os visíveis? Qual formato exatamente, o dialeto de CSV deles, com o separador deles, o formato de data deles? O que acontece com a linha que tem uma vírgula dentro? Um modelo que recebe uma tarefa vaga vai produzir, com toda a confiança, uma resposta vaga, e você vai ter automatizado a produção de trabalho que vai ter que ser refeito.

Então a tarefa vira uma spec primeiro. Não um romance, uma declaração curta e testável do requisito e dos seus critérios de aceitação. As colunas que precisam aparecer. O formato, nomeado com precisão. O caso de borda que tem que não quebrar. A spec é o contrato entre “o que eles pediram” e “o que é construído”, e ela existe pra que a coisa construída possa ser checada, não só torcida.

Uma spec também é o lugar natural pra um humano intervir de forma barata. Pegar um mal-entendido aqui custa uma edição de uma linha. Pegá-lo depois do código escrito custa uma reescrita. A spec é o último lugar onde uma suposição errada ainda sai de graça.

A transcrição já contém o requisito. A spec é só esse requisito, escrito com precisão suficiente pra que uma máquina, ou um recém-contratado, pudesse construir contra ele e um revisor pudesse dar nota.

O runner: um sandbox que propõe, nunca impõe

Agora a parte pra qual todo mundo quer pular: o código. A fantasia ingênua é o agente que lê a tarefa e empurra a correção pra produção enquanto você dorme.

Não construa isso. Um agente que pode dar merge do próprio trabalho na branch principal não é um funcionário, é um estagiário sem supervisão com acesso de commit, e na primeira vez que ele, com toda a confiança, mandar o dialeto de CSV errado pra todo cliente, você vai entender por que nenhuma empresa sã deixa nem seus melhores engenheiros darem push em produção sem revisão.

O formato certo é mais estreito e bem mais seguro. Um runner em sandbox, um espaço de trabalho isolado, amuralhado de qualquer coisa em produção, pega a spec, abre a própria branch e faz o trabalho ali. Quando termina, ele não faz deploy de nada. Ele abre um draft pull request: uma mudança proposta, parada ao lado do código, com o diff visível, a spec linkada e o nome de um humano na vaga de revisor.

Um draft PR é o portão de confiança que sustenta tudo, e vale ser exato sobre o porquê. Ele é visível, a mudança é um diff que uma pessoa pode ler linha por linha, não uma caixa-preta. Ele é reversível, nada está em produção, então nada está em risco. E ele é parado por padrão, ele vai exatamente até “é isso que eu faria” e nem um passo além. A autoridade do runner termina em “proposto”. A de um humano começa em “merge”.

Então a resposta pro título é sim, com uma borda deliberada. Uma call pode virar uma tarefa, uma tarefa uma spec, uma spec uma branch, e uma branch um draft PR, automaticamente, com o escritório no escuro. Mas para ali, na beirada do irreversível, e espera por uma pessoa. A transcrição já contém o requisito; o resto é um pipeline, até o único portão que nunca deveria ser automático.

Por que o portão é o ponto, não a limitação

É tentador ler a parada no draft PR como a parte inacabada, o lugar que a gente ainda não automatizou. É o contrário. É a parte que a gente automatizou de propósito pra ser manual.

Confiança não é um interruptor que você liga no primeiro dia. É um nível que um sistema sobe, um resultado verificado por vez. Um pipeline que abre draft PRs deixa você vê-lo trabalhar sem apostar a empresa nele. Você lê as primeiras cem propostas dele. As que estão certas, você dá merge em segundos, o que é cem vezes mais rápido do que escrevê-las. As que estão erradas, você manda de volta, e o erro foi pego num diff, onde é barato, em vez de em produção, onde não é. Com o tempo, pras coisas estreitas e bem especificadas que ele acertou de novo e de novo, a corda pode afrouxar. Mas ela afrouxa porque foi conquistada, não porque foi presumida.

Essa é a diferença entre um pipeline que você de fato rodaria e uma demo na qual você nunca confiaria. A demo dá merge automático e parece mágica por uma semana. O pipeline propõe, é revisado, e ainda está rodando um ano depois, porque cada passo perigoso tem um humano parado nele, e cada passo seguro foi entregue pra máquina.

A virada: a reunião nunca foi o trabalho

Dê um passo atrás do encanamento e olhe o que mudou pras pessoas.

O trabalho do vendedor deixa de ser “lembrar de escrever o resumo da call” e volta a ser “fazer uma call boa”. A pessoa de produto deixa de ser um roteador pra coisas que outras pessoas falaram e começa a decidir quais dos requisitos agora capturados de fato valem a pena construir. O engenheiro deixa de ler tickets com perda e começa a revisar propostas concretas, ler um diff e dizer sim ou não, que é a parte do julgamento dele que sempre foi a parte valiosa. Ninguém foi substituído. A camada de escritório entre eles foi.

Essa é a promessa silenciosa. Não que o software escreva o seu código, mas que a distância entre as palavras de um cliente e uma mudança revisável encolhe de semanas de repasses pra um pipeline que roda sozinho e aí para educadamente, segurando a porta aberta pra um humano passar e decidir. A transcrição já continha o requisito. Sempre conteve. A única coisa que algum dia ficou entre ele e uma correção foi a reunião que a gente insistia em marcar pra mover tudo na mão.

---

A gente está construindo isso na Apollo Space, um sistema operacional que trata o vão entre o que um cliente falou e o que um revisor pode aprovar como encanamento, não como a tarde de alguém. Se a parte mais exaustiva da sua semana é carregar requisitos de uma ferramenta pra outra, esse trabalho nunca foi o trabalho. Está na hora de você fazer a parte que era.