A descrição de cargo está virando um arquivo de spec

Abra uma descrição de cargo para um papel que você já contratou. “Dono do relatório semanal de receita.” “Bom comunicador.” “Confortável com ambiguidade.” Agora tente executá-la. Você não consegue. Não há nada ali que uma máquina conseguisse executar, nada que você conseguisse testar, nada que diria a você numa dada terça-feira se o trabalho foi feito. Uma descrição de cargo é uma lista de desejos escrita para um humano, e funciona só porque o humano silenciosamente preenche os mil detalhes que ela deixa de fora.

No momento em que você tenta entregar esse mesmo papel a um agent, a lista de desejos desmorona. E o que a substitui se parece muito com um arquivo que um engenheiro commitaria.

Para um agent, um cargo vira uma spec versionada e testável, e isso muda como você desenha cada trabalho, inclusive os humanos.

O que uma descrição de cargo silenciosamente assume

Uma descrição de cargo é o documento escrito mais casualmente da empresa, e a gente se safa por causa de uma suposição: o leitor é uma pessoa que já sabe como o mundo funciona.

“Dono do relatório semanal de receita” assume que o leitor sabe o que é receita, onde os números vivem, o que “semanal” significa nesta empresa, quem precisa do relatório, o que conta como um bom, e o que fazer quando um número parece errado. Nada disso está na página. É tudo carregado para dentro pelo humano, de graça.

Esse import gratuito é o truque inteiro. É também a razão pela qual descrições de cargo não compõem, não transferem, e silenciosamente apodrecem. Duas pessoas leem a mesma linha e fazem o trabalho de dois jeitos diferentes. Alguém sai, e a metade do papel que vivia só na cabeça dele sai com ele. Você não consegue dar diff de uma descrição de cargo contra a do trimestre passado, porque nunca houve uma versão precisa contra a qual dar diff.

Uma descrição de cargo é um contrato escrito numa linguagem que só humanos conseguem executar, e só mal.

Toleramos tudo isso porque, para uma pessoa, geralmente funciona. Pessoas são surpreendentemente boas em preencher gaps. Entregue um parágrafo vago a um novo contratado competente e ele vai reconstruir a intenção, perguntar por aí, observar o que os outros fazem, e convergir em algo razoável dentro de algumas semanas. A vagueza não é um bug para humanos. É uma feature na qual nos apoiamos.

O jeito ingênuo: entregue ao agent o mesmo parágrafo

Então aqui está o primeiro movimento óbvio, o que quase todo mundo tenta. Você tem um agent agora. Você tem uma descrição de cargo. Entregue um ao outro.

Ele falha, e falha de um jeito que ensina exatamente o que estava faltando.

O agent não sabe o que “bom” significa, então produz algo plausível e confiantemente errado. Ele não sabe onde os números vivem, então adivinha ou faz quarenta perguntas. Ele não sabe que “semanal” significa segunda 9h antes do sync de liderança, então roda na sexta. Ele não tem opinião sobre o que fazer quando uma cifra parece estranha, então ou silenciosamente shipa o número ruim ou para e espera. Cada gap que a descrição de cargo deixou para um humano preencher, o agent deixa vazio, e um gap vazio é um defeito.

Essa é a mesma falha que todo time encontra na primeira semana em que tenta delegar trabalho real a um agent. O instinto é culpar o modelo: ele não é esperto o suficiente, ele alucinou, ele não “entendeu”. Mas o modelo não é a coisa que está subespecificada. O papel é. Você entregou um documento engenheirado para um leitor que preenche gaps a um leitor que não preenche, e então agiu surpreso quando os gaps apareceram.

A correção não é um agent mais esperto. A correção é um documento melhor.

O documento melhor é uma spec

Observe o que você de fato faz para fazer o agent ter sucesso, e você vai descobrir que não está mais escrevendo uma descrição de cargo. Você está escrevendo uma spec.

Você para de dizer “dono do relatório semanal de receita” e começa a dizer o que o relatório é: estes inputs, destas fontes, transformados deste jeito, entregues a estas pessoas neste horário, neste formato. Você anota o que torna um bom, as checagens que ele deve passar antes de shipar, os números que devem reconciliar, as coisas que nunca deveriam aparecer. Você anota o que fazer nas bordas: se uma fonte atrasa, se uma cifra pula mais que algum threshold, se dois sistemas discordam. O parágrafo vago vira um objeto preciso com inputs, outputs, critérios de aceitação e tratamento de falha.

Esse objeto tem um nome em engenharia. É uma spec.

E no instante em que o papel é uma spec, ele herda tudo o que specs já têm. Você pode versioná-lo, o papel do mês passado e o papel deste mês são dois commits, e você pode ler o diff. Você pode testá-lo, rode o agent contra um input conhecido e cheque o output contra os critérios de aceitação, do mesmo jeito que um unit test checa uma função. Você pode revisá-lo antes de shipar, porque é um artefato escrito que uma segunda pessoa pode ler e aprovar. Você pode reutilizá-lo, a spec para “relatório semanal de receita” numa empresa é um ponto de partida para a próxima, em vez de conhecimento tribal que sai pela porta.

A descrição de cargo ingênua não tinha nenhuma dessas propriedades. Nenhuma. A gente só nunca notou, porque o leitor humano estava silenciosamente fornecendo todas elas na cabeça, re-derivando a intenção, segurando os edge cases, julgando o próprio output, carregando o histórico de versões como memória. Mova o trabalho para um agent e essa maquinaria oculta tem que virar explícita. A spec é como ela se parece quando vira.

A ideia-chave é simples. Para um agent, um cargo vira uma spec versionada e testável, e o ato de escrever essa spec é o ato de finalmente dizer o que o trabalho de fato era.

A spec é viva, não um formulário único

Há uma armadilha aqui, e vale nomeá-la antes de alguém cair nela. Uma spec soa como mais papelada, uma descrição de cargo mais longa e mais rígida que você escreve uma vez e arquiva. Não é isso, e uma spec arquivada é uma spec morta.

A razão pela qual uma spec vence uma descrição de cargo é que ela roda num loop. O agent faz o trabalho contra a spec. Você lê o output. Quando o output está errado, você não retreina uma pessoa ao longo de seis meses, você edita a spec e re-roda. O critério de aceitação que o agent falhou vira um novo teste. O edge case que ninguém antecipou vira uma nova branch na seção de tratamento de falha no momento em que ele te morde uma vez.

Uma descrição de cargo é escrita no momento da contratação e então congelada, derivando cada vez mais longe da realidade a cada mês até virar ficção. Uma spec é o oposto. Ela fica mais precisa com o tempo, porque toda surpresa que o trabalho lança nela é dobrada de volta. O papel que você não consegue bem descrever no dia um vira, cinquenta correções depois, um papel que você descreveu com precisão, e a descrição é executável.

É por isso que “a descrição de cargo está virando um arquivo de spec” não é uma metáfora. É uma mudança literal no tipo de documento que um papel é, e no que você pode fazer com ele. Você não gerencia uma spec dando feedback numa avaliação trimestral. Você a gerencia do jeito que gerencia qualquer artefato vivo sob version control: você edita, você testa, você shipa, você observa, você edita de novo.

O que isso faz com os trabalhos humanos

Aqui está a parte que nos surpreendeu, e é a razão pela qual achamos que isso importa para além dos agents.

Uma vez que você escreveu uma spec real para a metade-agent de um papel, a metade-humana desse mesmo papel de repente parece subdefinida em comparação. Você acabou de provar que você consegue dizer precisamente o que é um bom output, quais são os inputs, o que fazer nas bordas. Então por que a versão humana sempre foi um parágrafo vago? Especificar o agent força uma clareza que, acontece, os humanos mereciam o tempo todo.

Isso não significa transformar pessoas em máquinas que rodam uma spec. Significa o oposto. Quando a parte mecânica e especificável de um papel, a parte que você consegue anotar como inputs, outputs e critérios de aceitação, é capturada numa spec que um agent consegue rodar, o que resta nas mãos do humano é a parte que nunca foi especificável de início. Julgamento sobre quais números de fato importam neste trimestre. Gosto sobre o que “bom” deveria significar conforme a empresa muda. A decisão de jogar a spec fora inteiramente porque a situação mudou por baixo dela. As relações, a leitura de contexto, o saber-quando-a-regra-está-errada.

A spec captura a parte de um trabalho que você consegue anotar. O ponto de capturá-la é liberar a parte que você não consegue.

Para um agent, um cargo vira uma spec versionada e testável. Para um humano, o papel vira tudo o que não está na spec, e esse é um trabalho melhor do que o que ele tinha, porque as partes de menor alavancagem dele acabaram de sair do seu prato.

A virada: o org chart sempre foi um rascunho

Nós costumávamos pensar que uma empresa era um conjunto de pessoas em caixas. Não pensamos mais. Uma empresa é um conjunto de papéis, e as pessoas são como atualmente os rodamos. O org chart não é a empresa, é uma implementação dela, o jeito como um trabalho foi alocado este ano.

Quando os papéis eram parágrafos vagos, você não conseguia ver isso. O papel e a pessoa estavam soldados, porque o papel só existia na cabeça da pessoa, executado do jeito particular da pessoa. Torne o papel uma spec e a solda quebra. O papel vira uma coisa por direito próprio, anotada, testável, melhorável, que uma pessoa roda hoje e pode ser rodada diferente amanhã. O humano para de ser o papel e começa a ser o autor dele: o que decide o que a spec deveria dizer, julga se ela ainda está certa, e a reescreve quando o mundo se move.

Isso não é um rebaixamento. É a coisa de maior alavancagem que uma pessoa numa empresa pode fazer, ser dona da spec de como o trabalho funciona, em vez de ser o único lugar onde o trabalho está anotado. O trabalho deixa de ser ser o papel e vira desenhar o papel. E desenhar um papel bem, decidir o que “bom” significa e quando a regra deveria dobrar, é exatamente o trabalho que nenhuma spec consegue fazer por você. É o trabalho que vale a pena manter.

As descrições de cargo na sua gaveta sempre foram rascunhos de algo mais preciso. A gente só nunca teve um leitor rígido o suficiente para nos forçar a terminá-las.

---

É isso que estamos construindo na Apollo Space, um sistema operacional onde os papéis são anotados bem o suficiente para rodar, para que as pessoas que costumavam ser o trabalho possam desenhá-lo em vez disso. A primeira spec que você escrever para um agent vai parecer trabalho extra. Então você vai relê-la e perceber que é a primeira descrição honesta do trabalho que você já teve.