๐ ๏ธ Mao na massa
A trilha onde voce constroi. Migra um caso real de loop para grafo com criterio (e sabe quando NAO migrar), modela o grafo do seu proprio negocio e do seu backlog, e sai com uma biblioteca de prompts prontos para desenhar, gerar e auditar grafos.
O que olhar: a primeira pergunta ja elimina a maioria dos casos โ se um loop ainda da conta, a resposta certa e melhorar o loop, nao migrar. "Monte o grafo" e a folha mais rara dessa arvore: e a excecao, nao a regra. Boa parte dos problemas que parecem exigir grafo se resolve com um verificador melhor, que e mais barato e mais rapido de construir.
Mapa da trilha
Conteudo detalhado
๐ Do loop ao grafo
A migracao passo a passo do resumo diario, com os sinais que autorizam migrar e o que medir antes e depois.
Tres sinais legitimos pra migrar: voce precisa rodar partes ao mesmo tempo; voce precisa de um revisor que nao veja como o trabalho foi feito; o contexto esta virando pantano e o agente perde a instrucao original.
Se nenhum dos tres esta presente, melhore o loop. Migrar sem um desses sinais e comprar complexidade de graca.
Os tres sinais resumem tudo que as trilhas 2 e 3 ja mostraram: paralelismo, contexto limpo e pantano de contexto.
Anote custo por execucao, tempo total, e uma medida de qualidade que voce consiga verificar โ antes de tocar em qualquer coisa.
Migracao sem linha de base e fe, nao engenharia. Sem numero de antes, nunca vai saber se o grafo valeu.
As tres medidas โ custo, tempo, qualidade โ sao as mesmas que voce vai comparar de novo la no topico 6.
Quebre o loop onde muda a responsabilidade, a ferramenta ou o contexto necessario. No resumo diario isso da tres nos naturais: quem busca, quem escreve, quem confere.
Cortar no lugar errado te da um grafo com nos artificiais que so complicam. Cortar no lugar certo te da nos que ja existiam escondidos no loop.
Mudanca de responsabilidade, de ferramenta ou de contexto โ qualquer uma das tres ja justifica um corte.
Antes de codar, defina o que cada aresta carrega: o pesquisador entrega notas (nao HTML bruto), o escritor entrega rascunho, o revisor devolve aprovado mais criticas.
Sem contrato explicito, cada no acaba mandando o que sobrou no proprio contexto โ e o pantano volta pela porta dos fundos.
Isso e o state schema em miniatura: nome do campo, formato, obrigatorio ou nao.
O revisor reprovando devolve pro escritor, com no maximo N voltas e um criterio de progresso.
Sem teto, a fatura e infinita โ o mesmo problema de loop sem condicao de parada, agora dentro de um no do grafo.
Teto de voltas + criterio de progresso, nao so teto de voltas. Sem progresso medido, N voltas gastam N vezes o mesmo erro.
Rode os dois em paralelo por alguns dias com as mesmas entradas e compare contra a linha de base do topico 2.
Se o grafo nao melhorou nenhuma das tres medidas, volte pro loop: voce comprou complexidade sem retorno.
Admitir que nao valeu e parte do trabalho, nao fracasso. Migracao e uma hipotese testada, nao uma crenca.
๐ Grafos de negocio e de tarefas
Modelar o que voce ja tem. O funil do negocio com varias metricas e o backlog com dependencia e bloqueio โ dois grafos que ja existem na sua empresa sem ninguem ter desenhado.
Campanha, trafego, landing, signup, ativacao, retencao, LTV, churn; nos sao estados do cliente e arestas sao taxas de conversao.
O funil ja e um grafo โ so ninguem costuma desenha-lo assim. Desenhar deixa visivel onde o cliente realmente perde.
Cada aresta e uma taxa de conversao mensuravel, nao uma seta decorativa.
Churn e custo de aquisicao voltam pro comeco do funil, fechando um ciclo dentro do grafo de negocio.
E essa volta que faz o sistema ter comportamento proprio โ e o que um agente miope, olhando so pra frente, nao ve.
Um funil sem a aresta de volta e uma foto; com ela, e um sistema dinamico.
"LTV sobre CAC precisa ser maior que 3" e uma relacao entre duas metricas, nao uma metrica isolada.
Um loop com objetivo unico nao consegue nem expressar essa relacao โ ele so enxerga a metrica que voce deu pra ele.
Restricao entre nos e outra forma de aresta โ invisivel pra quem pensa em metrica unica.
No backlog sao tres tipos de aresta: decomposicao (epico contem historia contem tarefa), dependencia (precisa terminar antes) e bloqueio (impede o inicio).
Confundir os tres faz o backlog virar uma arvore mentirosa. So a primeira e hierarquia; as outras duas transformam a arvore em grafo de verdade.
Decompor โ depender โ bloquear. Ferramenta de backlog que trata os tres iguais esconde informacao.
Conte quantas tarefas estao prontas ao mesmo tempo โ a largura do nivel do grafo de backlog.
E assim que voce dimensiona pessoas ou agentes de verdade, em vez de chutar quantos "cabem" no sprint.
Largura de nivel e a mesma ideia de fan-out โ quantos nos independentes existem nesse ponto do grafo.
Com o grafo do negocio ou do backlog escrito, um agente consegue propor alocacao, apontar o gargalo e simular o efeito colateral de uma mudanca.
Sem o grafo, o agente so opina sobre a metrica que voce citou โ ele nao enxerga o sistema, so o ponto que voce apontou.
O grafo escrito e o que transforma "pergunte pro agente" em "de o grafo pro agente". A diferenca e enorme.
๐ Biblioteca de prompts
Seis prompts prontos, testados no formato objetivo + bloco copiavel + como verificar. O modulo que voce volta pra consultar.
Voce descreve um processo em texto corrido e o agente devolve nos, arestas condicionais e o que passa em cada aresta, em JSON.
E o ponto de partida mais rapido pra sair de "processo na cabeca" pra "processo desenhado".
JSON de nos e arestas e o formato comum que os proximos prompts desta lista assumem como entrada.
O segundo passo do metodo de duas etapas: desenhe qualquer grafo, depois peca pro agente gerar o script que o executa.
E assim que se sai do diagrama pro codigo sem escrever orquestracao na mao โ o agente traduz, voce revisa.
Desenhar e gerar sao duas etapas separadas de proposito: desenhar e pensamento humano, gerar e trabalho mecanico.
Procura ciclo sem saida, aresta sem condicao, no sem teto de custo, juncao que nao confere cardinalidade e estado que vaza entre nos.
Sao os mesmos defeitos que a trilha 4 ensinou a reconhecer โ agora automatizados num unico prompt de checagem.
Auditoria de grafo e verificador de grafo โ o mesmo principio do modulo 2.2 aplicado a estrutura, nao ao resultado.
Dado um conjunto de objetivos automatizados, aponta quais se pressionam mutuamente e qual metrica de um e efeito colateral do outro.
Colisao entre loops (trilha 2, falha 3) so aparece quando alguem โ ou algo โ olha o conjunto. Esse prompt automatiza esse olhar.
Colisao vira visivel quando voce desenha a aresta entre dois loops โ e e essa aresta que o prompt procura.
Dado dois nos vizinhos, define o contrato da aresta entre eles: nome dos campos, formato, o que e obrigatorio e o que explicitamente NAO deve passar.
O que NAO deve passar e a parte que todo mundo esquece โ e a que evita o contexto virar sopa de novo dentro do grafo.
State schema formaliza o contrato que o topico 4 do modulo 5.1 ja pedia pra voce escrever a mao.
Inverte a ordem: primeiro como voce vai saber que deu certo, com um caso ruim de teste; so depois o prompt do agente.
E o fechamento do curso inteiro num unico habito: verificador primeiro, sempre โ loop, no ou grafo inteiro.
O mesmo principio do modulo 2.2, agora empacotado como prompt pronto pra usar em qualquer no novo que voce criar.