O que é um DAG de tarefas?

É um grafo dirigido sem ciclos: cada subtarefa aponta para aquelas que dependem dela, e nenhum caminho volta ao ponto de partida. Serve para descobrir o que precisa esperar e o que pode rodar em paralelo.

Por que não executar as subtarefas em sequência, uma de cada vez?

Funciona, mas desperdiça tempo. Se imagem, layout e SEO só dependem do texto, executar os três em paralelo termina no tempo do mais lento, e não na soma dos três.

O que acontece se uma subtarefa falhar no meio do grafo?

Só o ramo que dependia dela para. As subtarefas de outros ramos continuam, e a que falhou é reexecutada ou escalada para uma capacidade maior sem reiniciar o trabalho já aprovado.

Como uma frase vira um site: a decomposição em grafo

"Crie uma landing page para o meu curso" não é uma tarefa. São seis, com dependências entre elas, e três podem rodar ao mesmo tempo.

Você escreve: “crie uma landing page de captação para o meu curso”.

Para um chatbot, isso é um prompt. Para um orquestrador, é um problema de dependências, e resolver a ordem certa é metade do trabalho.

Uma frase, seis tarefas

A frase esconde seis entregas distintas, cada uma com um ofício diferente:

copy       (redação)      → headline, argumento, chamada
imagem     (visual)       → depende do copy
design     (layout)       → depende do copy
seo        (busca)        → depende do copy
código     (implementação)→ depende do design
publicar   (deploy)       → depende do código e do seo

Escrito assim, uma coisa fica evidente: imagem, design e SEO não dependem uns dos outros. Todos os três dependem só do copy. Então, assim que o texto for aprovado, os três podem sair ao mesmo tempo.

Isso é um DAG: directed acyclic graph, grafo dirigido sem ciclos. Cada nó é uma subtarefa, cada seta é uma dependência, e nenhum caminho volta para trás.

Ondas, não fila

Da estrutura do grafo sai naturalmente a ordem de execução, em ondas:

Onda	Roda	Por quê
1	copy	não depende de nada
2	imagem · design · seo	dependem só do copy
3	código	depende do design
4	publicar	depende de código e seo

Quatro ondas em vez de seis passos. E a onda 2 leva o tempo da subtarefa mais lenta, não a soma das três.

Um plugin genérico de IA executaria isso como uma fila, porque não sabe o que depende do quê, porque só tem o texto do seu pedido.

Por que o tipo de artefato muda o grafo

O grafo não é o mesmo para tudo. Um artigo de blog começa com pesquisa; uma landing page começa com o copy. Um plugin tem uma etapa que nenhum dos dois tem: validação de sintaxe antes de instalar, porque um erro de PHP derruba o site.

plugin:  spec → [hooks · código · interface] → validação → instalar
tema:    briefing → [layout · tokens] → templates → validação → ativar
artigo:  pesquisa → copy → [imagem · schema · seo · revisão] → publicar

Cada tipo tem o seu template. É o que separa “gerar texto sobre um assunto” de “entregar um artefato que funciona”.

O que dá quando algo falha

Aqui está o ganho menos óbvio. Se o código é reprovado na revisão, o que precisa ser refeito?

Só o código, e o publicar, que depende dele. O copy segue aprovado. A imagem segue aprovada. O SEO segue aprovado.

Num sistema linear, falhar no passo cinco costuma significar recomeçar. Num grafo, falhar em um nó afeta apenas o ramo abaixo dele. O trabalho aprovado não é jogado fora.

É isso que torna viável ter uma porta de qualidade rígida: reprovar sai barato quando reprovar não custa o trabalho inteiro.

O que isso significa para quem contrata

Quando alguém diz “a IA construiu a página”, vale perguntar o que aconteceu no meio.

Se a resposta é “um modelo gerou tudo de uma vez”, você tem um bloco monolítico: quando uma parte está errada, refaz-se tudo e a parte boa se perde no caminho.

Se a resposta é “cada pedaço foi feito pelo especialista do ofício, em paralelo quando dava, e revisado separadamente”, você tem um processo, que erra em pedaços pequenos e corrige em pedaços pequenos.

Não é a inteligência de cada passo que decide a qualidade final. É saber quais passos existem, e qual espera qual.