Muita gente que começa a construir produto com IA faz o mesmo caminho, pedindo uma tela, olhando o resultado e pedindo ajustes até ficar bom. Eu também fiz muito isso, e com o tempo entendi que a tela é a parte que a IA faz melhor, e que o que dava errado estava antes dela, nas decisões que ninguém tinha tomado. Hoje o meu trabalho começa por essas decisões, escritas num documento que eu chamo de Atlas, e nesta nota explico o que ele é para quem nunca ouviu falar.
O problema que o Atlas resolve
Todo produto digital é feito de muitas pequenas decisões, como o que acontece quando alguém erra a senha, quem pode apagar um cadastro ou o que o sistema faz quando duas pessoas mexem na mesma coisa ao mesmo tempo. Num projeto comum, essas decisões ficam espalhadas, uma numa reunião, outra numa mensagem e outra só na cabeça de quem conversou com o cliente, e cada pessoa do time imagina o produto de um jeito diferente.
O resultado aparece tarde, quando quem desenhou esperava uma coisa, quem programou entregou outra e a diferença só surge no teste, que é a hora em que consertar já custa caro. Com a IA no meio isso piora, porque ela preenche sozinha cada decisão que faltou, sem avisar, e entrega algo que parece pronto e quebra no primeiro uso.
O que é o Atlas
O Atlas é um documento único que descreve o produto inteiro, em linguagem simples, antes de qualquer tela existir. A melhor comparação que conheço é a planta de uma casa, porque ninguém chama o pedreiro e pede “uma casa bonita” sem antes ter no papel quantos cômodos ela tem, o que fica em cada um, por onde as pessoas passam e qual parede não pode sair do lugar.
Ele é escrito sempre na mesma ordem. Primeiro vem a Constituição, com o que o produto é, as palavras que ele usa e as regras que nada pode quebrar. Depois vêm os objetos, que são as coisas que existem dentro do sistema, cada uma com os estados por que passa e com o que cada pessoa pode fazer com ela. Por último vêm os fluxos, que são os caminhos das pessoas pelo produto, e que não repetem as regras, só apontam para elas, porque uma regra copiada em dois lugares acaba ficando diferente nos dois.
Nada entra no Atlas por chute, então toda pergunta sem resposta fica marcada como pendente, com o nome de quem vai decidir. Quando o documento fecha, quem desenha parte dele para fazer as telas, quem desenvolve parte dele para construir, e qualquer mudança que aparecer no caminho volta para o mesmo lugar, em vez de virar uma conversa que ninguém registrou.
Por que funciona tão bem com IA
A IA constrói rápido qualquer coisa que você pedir, inclusive a coisa errada, então o que ela precisa de você são as decisões. Quando chego com o produto escrito, ela não tem o que inventar, porque a resposta para cada situação já está lá, e foi assim que no Subasta eu passei 45 minutos escrevendo o Atlas e a IA construiu o resto em poucas horas.
O Atlas também deixa as contradições à vista. A especificação e o protótipo ficam lado a lado, e quando os dois discordam a diferença fica anotada até alguém decidir, em vez de cada pessoa, ou cada IA, resolver do seu jeito sem contar para ninguém.
Quando a empresa inteira vira contexto
O Atlas sozinho já ajuda bastante, mas ele rende muito mais desde que passou a fazer parte de um ambiente maior. Nas minhas duas empresas, a Oroz e a Sincera, cada uma com o seu, a gente vem montando o que chamamos de OS da empresa, que é o contexto inteiro do negócio escrito em documentos e em skills. As skills são instruções que dizem para a IA o que fazer, como fazer e quais passos seguir para chegar a um resultado que eu já testei e sei que funciona.
Na prática, isso muda o tipo de pedido que eu faço. Em vez de explicar o produto de novo a cada conversa, eu peço para a IA seguir o processo, e ela já sabe que precisa ler o Atlas antes de mexer em qualquer coisa, como documentar um fluxo novo, como transformar esse fluxo em telas e como registrar o que mudou, porque cada um desses passos virou uma skill depois de dar certo pelo menos uma vez. Foi assim que transformei uma entrega em um processo, e o Atlas é a parte desse processo que cuida do produto.
Do papel ao teste
O passo mais recente que entrou foi o teste, e foi aí que o Atlas deixou de ser só um documento de planejamento. O teste técnico parte do próprio Atlas e tenta quebrar o sistema regra por regra, e cada problema encontrado vira um registro com print, organizado em levas para quem desenvolve. Depois vem o teste de usabilidade, com missões tiradas dos fluxos, para ver se uma pessoa de verdade entende o produto sem ajuda, e quando o problema é de texto a própria skill já sugere uma frase melhor.
Como os dois testes leem o mesmo Atlas que guiou o design e o desenvolvimento, a pergunta deixa de ser se o produto funciona e passa a ser se ele faz o que a gente decidiu que ia fazer, o que dá para responder com sim ou não.
Onde eu controlo menos
Na Oroz e na Sincera, eu ajudo a desenhar o ambiente inteiro, então é natural que o Atlas se encaixe nele. O teste mais difícil está na CodingIT, onde sou Head de Produto e UX e controlo bem menos do que existe em volta, e é lá que estou implementando o Atlas agora, para descobrir o quanto dele se sustenta quando não fui eu quem montou o resto.
Ainda não sei essa resposta, e é por isso que esta nota faz parte de uma série. O que já sei é que o Atlas deixou de ser um documento que escrevo antes de construir e virou a forma concreta de um processo que está crescendo nas duas empresas, e que cada projeto novo deixa esse processo um pouco melhor do que o anterior.
Escrito por Matheus Sá. Discorda ou quer complementar? Me escreve.