Agentes de programação estão cada vez mais capazes de implementar tarefas individuais de software. Dê a um agente um repositório, uma issue clara e contexto suficiente, e ele frequentemente conseguirá inspecionar o código, modificar arquivos, escrever testes e produzir uma implementação funcional.
O problema mais difícil começa um nível acima.
O que acontece quando precisamos implementar uma funcionalidade inteira com dez tarefas relacionadas? Algumas podem rodar em paralelo, outras dependem das demais, algumas exigem decisões de arquitetura e outras afetam áreas em que mudanças autônomas não deveriam ser permitidas.
Nesse ponto, o desafio deixa de ser apenas:
Um agente de IA consegue escrever o código?
A pergunta mais útil passa a ser:
Como transformar uma iniciativa de software em unidades de trabalho que agentes consigam executar, validar, revisar e integrar com segurança?
Este artigo propõe um fluxo completo para implementar um épico usando agentes de IA, minimizando a intervenção humana sem remover os controles exigidos pelo risco das mudanças.
A arquitetura central é esta:
┌─────────────────────┐
│ Epic │
│ intent + constraints│
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ Task dependency │
│ graph │
└──────────┬──────────┘
│
┌───────────────┴───────────────┐
│ │
▼ ▼
┌──────────────┐ ┌──────────────┐
│ Task A │ │ Task B │
└──────┬───────┘ └──────┬───────┘
│ │
▼ ▼
┌─────────┐ ┌─────────┐
│ Planner │ │ Planner │
└────┬────┘ └────┬────┘
│ │
▼ ▼
┌─────────┐ ┌─────────┐
│ Builder │ │ Builder │
└────┬────┘ └────┬────┘
│ │
▼ ▼
┌─────────┐ ┌─────────┐
│Reviewer │ │Reviewer │
└────┬────┘ └────┬────┘
│ │
└───────────────┬───────────────┘
▼
┌─────────────────────┐
│ Epic integration PR │
│ + CI │
└──────────┬──────────┘
│
human approval
│
▼
main
As ferramentas específicas podem ser trocadas. O que importa é o fluxo de trabalho.
O épico como fonte de intenção
Um épico é útil porque oferece aos agentes uma descrição compartilhada do que o sistema deve realizar.
Ele deve conter pelo menos:
- objetivo;
- problema ou contexto do produto;
- escopo e exclusões explícitas;
- requisitos;
- tarefas ou histórias de usuário;
- critérios de aceitação;
- dependências e riscos;
- métricas de sucesso.
Eu evitaria tratar o épico como a “fonte da verdade” absoluta.
É melhor entendê-lo como a fonte central de intenção, requisitos e restrições da iniciativa.
O repositório ainda contém a realidade técnica do sistema. APIs, esquemas, decisões de arquitetura, infraestrutura, testes e restrições existentes podem revelar informações ausentes do épico.
Essa distinção se torna importante quando os agentes começam a tomar decisões.
Imagine que uma tarefa diga apenas:
Adicione suporte a novas tentativas ao processamento de pagamentos.
Um agente poderia perguntar:
- Quais falhas permitem novas tentativas?
- Quantas tentativas são permitidas?
- Elas devem ser síncronas ou assíncronas?
- O que acontece com a idempotência?
- O provedor de pagamentos pode receber a mesma requisição duas vezes?
- Novas tentativas estão fora do escopo de algum meio de pagamento?
A tarefa pode não responder a essas perguntas.
O épico fornece os limites de produto e arquitetura necessários para respondê-las sem duplicar o contexto inteiro em cada issue.
Uma implementação prática é representar o épico como uma issue principal do GitHub e suas tarefas como sub-issues. Isso mantém o planejamento perto do código e permite referências cruzadas entre issues, pull requests, commits, diagramas, arquivos e decisões técnicas.
A granularidade das tarefas importa mais que a quantidade de prompts
Um erro comum ao montar fluxos com agentes é entregar um objetivo muito amplo diretamente a um agente de programação:
Implemente todo o épico de cobrança.
Um modelo capaz ainda pode avançar, mas fica difícil acompanhar a lógica da execução.
O agente precisa, ao mesmo tempo:
- descobrir a arquitetura;
- interpretar os requisitos;
- tomar decisões de projeto;
- modificar vários domínios;
- manter as dependências consistentes;
- validar o comportamento;
- entender o que está dentro e fora do escopo.
O problema não é apenas o tamanho da janela de contexto.
É a quantidade de decisões que precisam permanecer coerentes durante toda a execução.
Um fluxo melhor reduz a complexidade de cada execução.
Quando uma tarefa é suficientemente granular?
Uma regra útil é:
Uma tarefa é suficientemente granular quando representa uma entrega coesa, pode ser implementada e validada de forma independente e produz um pull request que pode ser compreendido, testado e revertido sem depender de mudanças não declaradas.
O tamanho da tarefa não deve ser medido principalmente por linhas de código ou quantidade de arquivos.
A propriedade mais importante é a coesão.
Por exemplo, adicionar um campo a uma API pode exigir mudanças em:
esquema do banco
↓
entidade de domínio
↓
serviço
↓
endpoint da API
↓
testes
Isso ainda pode ser uma única tarefa coesa.
Várias camadas são afetadas, mas todas implementam a mesma capacidade vertical.
Por outro lado, uma mudança em apenas três arquivos pode ser ampla demais se combinar:
autenticação
+ regras de cobrança
+ processamento de eventos
+ alterações de infraestrutura
As perguntas úteis são:
- A tarefa tem um único resultado observável?
- Ela representa uma capacidade coesa?
- Pode ser validada independentemente?
- As principais decisões de arquitetura já foram resolvidas?
- O diff pode ser revisado como uma unidade lógica?
- A mudança pode ser revertida independentemente?
Esta última pergunta é especialmente útil:
Um revisor consegue entender e validar este diff como uma única mudança lógica?
Se a resposta for não, a tarefa provavelmente precisa ser decomposta.
Separar investigação de implementação
Tarefas se tornam especialmente perigosas quando misturam incerteza e implementação.
Considere:
Escolha uma arquitetura de processamento assíncrono e implemente-a.
Isso contém pelo menos dois tipos de trabalho fundamentalmente diferentes:
- decidir qual arquitetura deve existir;
- implementar essa arquitetura.
Uma decomposição melhor seria:
Tarefa 1 — Investigar alternativas de processamento assíncrono
Tarefa 2 — Registrar a decisão de arquitetura
Tarefa 3 — Implementar o produtor de eventos
Tarefa 4 — Implementar o consumidor de eventos
As primeiras tarefas reduzem a incerteza.
As posteriores executam uma decisão já tomada.
Essa distinção também facilita controlar o comportamento dos agentes. Podemos permitir uma investigação ampla sem conceder implicitamente autorização para modificar a arquitetura.
Verificar a prontidão antes de implementar
Antes de uma tarefa chegar ao Builder, o fluxo deve verificar se ela está realmente pronta para implementação.
Uma lista prática é:
- Há um resultado claramente definido.
- O escopo e as exclusões são explícitos.
- Os critérios de aceitação são verificáveis.
- As dependências estão declaradas.
- Não há decisão importante de arquitetura pendente.
- A mudança representa uma capacidade coesa.
- Há uma estratégia objetiva de validação.
- A mudança pode gerar um pull request independente.
- A mudança pode ser revertida sem remover trabalho não relacionado.
- O diff esperado é razoavelmente delimitado ou seu tamanho está justificado.
Isso não precisa se transformar em regras numéricas rígidas.
Uma migração de esquema gerada com 2.000 linhas pode ser mais simples do que uma mudança de autenticação com 100 linhas.
Coesão, independência e verificabilidade importam mais que o tamanho bruto.
Uma tarefa, um ambiente de execução isolado
Quando as tarefas podem rodar simultaneamente, o isolamento do sistema de arquivos se torna necessário.
Uma estratégia simples é:
Epic
│
├── integration/epic-payments
│
├── task/payment-retry
│ └── worktree A
│
├── task/payment-webhook
│ └── worktree B
│
└── task/payment-events
└── worktree C
Cada Builder recebe:
- sua própria branch Git;
- seu próprio worktree Git ou contêiner;
- o pacote de contexto da tarefa atual;
- os comandos de validação relevantes.
Isso impede que dois agentes modifiquem diretamente o mesmo diretório de trabalho.
Porém, não elimina conflitos de integração.
Dois agentes isolados ainda podem modificar, de forma independente, a mesma API, modelo de dados ou subsistema. Os worktrees estão isolados operacionalmente, mas as mudanças podem entrar em conflito semântico na integração.
O orquestrador precisa entender as dependências e a ordem de integração das tarefas.
Modelar explicitamente as dependências
Um épico não deve ser tratado como uma lista plana de tarefas.
É melhor representá-lo como um grafo de dependências.
Por exemplo:
┌───────────────┐
│ Add DB schema │
└───────┬───────┘
│
┌─────────┴─────────┐
▼ ▼
┌────────────────┐ ┌────────────────┐
│ Write producer │ │ Create API │
└───────┬────────┘ └───────┬────────┘
│ │
▼ │
┌────────────────┐ │
│ Write consumer │ │
└───────┬────────┘ │
└──────────┬─────────┘
▼
┌────────────────┐
│ Integration │
│ validation │
└────────────────┘
Uma tarefa pode ter metadados explícitos como:
id: payment-consumer
blocked_by:
- payment-schema
- payment-producer
O orquestrador executa nós independentes simultaneamente e aguarda as dependências dos demais.
Isso é muito mais seguro do que pedir a vários agentes que trabalhem no épico e esperar que descubram a ordem correta sozinhos.
Planner, Builder e Reviewer
O fluxo usa três papéis principais.
Planner: planejamento
O Planner investiga antes da implementação.
Suas responsabilidades incluem:
- inspecionar o código relevante;
- identificar componentes afetados;
- conferir dependências;
- identificar riscos;
- propor uma abordagem de implementação;
- definir etapas de validação;
- detectar se a tarefa precisa ser dividida.
O Planner não deve modificar arquivos de produção nessa fase.
Sua entrega deve ser um plano de execução, não uma implementação.
Um resultado típico seria:
Módulos afetados:
- payments/service.ts
- payments/repository.ts
- payments/service.test.ts
Implementação:
1. Classificar erros transitórios do provedor para novas tentativas.
2. Adicionar novas tentativas com espera exponencial e limites.
3. Preservar a chave de idempotência entre as tentativas.
4. Adicionar testes para falhas que permitem e não permitem novas tentativas.
Validação:
- suíte de testes unitários
- testes de integração de pagamentos
- lint
- typecheck
Risco:
- garantir que pagamentos recusados nunca sejam tentados novamente
Essa saída passa a integrar o contexto do Builder.
Builder: implementação
O Builder executa a tarefa aprovada.
Suas responsabilidades são intencionalmente mais restritas:
- implementar a mudança planejada;
- atualizar ou criar testes;
- executar as validações necessárias;
- fazer commit das mudanças;
- abrir ou atualizar o pull request.
O Builder não deve redefinir silenciosamente os critérios de aceitação nem ampliar o escopo por ter descoberto algo interessante durante a implementação.
Se a implementação revelar um problema importante de arquitetura, a ação correta costuma ser encaminhar a descoberta ao orquestrador.
Reviewer: revisão
O Reviewer avalia o resultado de forma independente.
Ele deve inspecionar:
- o diff real;
- os critérios de aceitação;
- os testes;
- as saídas de validação;
- as restrições de arquitetura;
- possíveis regressões.
A revisão deve se basear no comportamento esperado, não apenas na explicação do Builder sobre o que implementou.
Essa distinção importa porque, sem ela, Builder e Reviewer podem compartilhar a mesma suposição incorreta.
O Reviewer deve retornar problemas concretos como:
BLOCKING
A lógica de novas tentativas também repete PaymentDeclinedError.
Critério de aceitação:
Apenas falhas transitórias do provedor permitem novas tentativas.
payments/service.ts:87
Em vez de:
A implementação não parece muito correta.
Constatações objetivas permitem ciclos automatizados de correção.
Orquestração interna e externa
Há duas formas gerais de coordenar os agentes.
Orquestração interna
Um agente principal delega trabalho usando um ambiente nativo de múltiplos agentes.
Conceitualmente:
agente principal
│
├── agente Planner
├── agente Builder
└── agente Reviewer
O ambiente gerencia as execuções filhas e devolve os resultados ao agente principal.
Isso é útil quando a delegação está intimamente ligada ao processo de raciocínio do agente principal.
Orquestração externa
Um processo separado controla execuções independentes de agentes.
Por exemplo:
orquestrador
│
├── processo de agente -- tarefa A
├── processo de agente -- tarefa B
└── processo de agente -- revisão A
As execuções se comunicam por saídas estruturadas, arquivos, Git, APIs ou outro mecanismo durável.
A orquestração externa é especialmente útil quando precisamos de:
- fluxos determinísticos;
- worktrees ou contêineres separados;
- concorrência explícita;
- novas tentativas;
- limites de tempo;
- filas de tarefas;
- estado persistente de execução;
- agentes independentes de provedor.
A arquitetura deste artigo favorece a orquestração externa para o fluxo principal, mas permite que agentes individuais usem subagentes internos quando isso for útil.
Dar a cada tarefa apenas o contexto necessário
O épico contém informações globais.
Isso não significa que cada agente deva receber o épico inteiro, todas as conversas anteriores e todos os logs de implementação.
Em vez disso, o orquestrador deve montar um pacote de contexto da tarefa.
Por exemplo:
epic:
objective: Add asynchronous invoice processing
constraints:
- existing synchronous API must remain compatible
task:
id: invoice-event-producer
objective: Publish an event after invoice creation
acceptance_criteria:
- exactly one event is emitted after a successful transaction
- failed transactions must not emit events
dependencies:
completed:
- invoice-event-schema
architecture:
- ADR-014-event-bus.md
relevant_files:
- src/invoices/service.ts
- src/events/publisher.ts
validation:
- npm test -- invoices
- npm run typecheck
instructions:
- AGENTS.md
O pipeline passa a ser:
Epic
↓
seleção de contexto
↓
contexto específico da tarefa
↓
execução isolada
↓
resultado validado
↓
integração do épico
Janelas de contexto longas são úteis, mas devem ser tratadas como capacidade disponível, não como uma meta de preenchimento.
Mais contexto não significa automaticamente contexto melhor.
Contexto excessivo pode introduzir:
- informações obsoletas;
- instruções conflitantes;
- detalhes irrelevantes de implementação;
- suposições antigas de arquitetura;
- objetivos concorrentes.
A engenharia de contexto, portanto, faz parte da orquestração.
A pergunta não é:
Quanta informação o modelo consegue receber?
É:
Qual é o contexto mínimo suficiente para tomar esta decisão corretamente?
Definir autonomia como uma política de risco
Reduzir a intervenção humana não significa dar permissões irrestritas aos agentes.
O fluxo deve definir quais ações são seguras para execução automática e quais exigem aprovação.
Uma política possível seria:
Autônomas
Agentes podem executar estas operações no ambiente isolado da tarefa:
- editar código da aplicação;
- adicionar ou atualizar testes;
- executar testes, linters e análise estática;
- criar commits;
- abrir pull requests;
- aplicar correções solicitadas pelo Reviewer dentro do escopo aprovado.
Autônomas com validação adicional
Mudanças nesta categoria só podem prosseguir automaticamente quando regras específicas de validação forem atendidas:
- atualizações de dependências;
- migrações de banco não destrutivas;
- mudanças de contratos de API;
- mudanças de configurações compartilhadas;
- mudanças que afetam vários domínios ou serviços.
Aprovação humana obrigatória
Exemplos incluem:
- deploys em produção;
- migrações destrutivas;
- acesso ou alteração de segredos;
- alterações de infraestrutura;
- mudanças de autenticação ou autorização;
- operações de cobrança;
- transformações irreversíveis de dados;
- integração final na branch principal.
Essas categorias não devem ser constantes universais.
Uma migração que adiciona uma coluna anulável pode ser rotineira em um sistema e perigosa em outro com bilhões de linhas.
A abstração correta, portanto, não é uma lista fixa de ações.
É uma política de risco.
O ciclo completo de implementação
Agora podemos juntar as peças.
1. Criar o épico
A pessoa ou o processo de produto define:
objetivo
problema
escopo
fora do escopo
requisitos
critérios de aceitação
riscos
métricas de sucesso
Nesta etapa, a ênfase está em o que precisa ser alcançado, não em como cada parte será implementada.
2. Decompor o épico
Um processo de planejamento converte o épico em tarefas.
Cada tarefa é verificada quanto a:
coesão
independência
testabilidade
reversibilidade
incerteza de arquitetura
Se houver incerteza importante de projeto, criam-se tarefas de investigação antes das de implementação.
3. Construir o grafo de dependências
As dependências são declaradas explicitamente.
Por exemplo:
A ──► C ──► E
│
└──► D ──► E
B ───────► E
As tarefas A e B podem começar imediatamente.
C e D aguardam A.
E aguarda todo o trabalho anterior.
O orquestrador agora tem informação suficiente para determinar um paralelismo seguro.
4. Criar a branch de integração do épico
Uma branch é criada a partir da branch de destino atual:
main
│
└── epic/invoice-processing
As branches das tarefas partem de um estado apropriado da integração.
Épicos longos devem sincronizar periodicamente com a branch de destino para evitar que a integração se afaste demais de main.
5. Montar o pacote de contexto da próxima tarefa
O orquestrador seleciona apenas as informações necessárias:
resumo do épico
+ descrição da tarefa
+ critérios de aceitação
+ decisões de arquitetura
+ dependências concluídas
+ arquivos relevantes
+ instruções do repositório
+ comandos de validação
+ restrições de risco
Essa é a entrada inicial do Planner.
6. Executar o Planner
O Planner inspeciona o repositório e produz um plano.
Os resultados possíveis são:
READY
NEEDS_SPLIT
BLOCKED_BY_ARCHITECTURE
BLOCKED_BY_DEPENDENCY
Apenas tarefas READY prosseguem automaticamente.
Essa etapa é uma fronteira importante entre o planejamento do projeto e a geração de código.
7. Criar um ambiente isolado para o Builder
O orquestrador cria:
branch da tarefa
+
worktree Git ou contêiner
+
contexto específico da tarefa
Por exemplo:
worktrees/
├── payment-retry/
├── payment-webhook/
└── invoice-events/
Builders independentes podem executar simultaneamente sem compartilhar o mesmo sistema de arquivos.
8. Executar o Builder
O Builder recebe:
contexto da tarefa
+
resultado do Planner
+
instruções do repositório
Ele implementa a mudança e executa as validações necessárias.
O resultado deve incluir informações estruturadas como:
status: completed
commit: a814ed3
validation:
unit_tests: passed
integration_tests: passed
lint: passed
typecheck: passed
files_changed:
- src/payments/service.ts
- src/payments/service.test.ts
notes:
- preserved existing idempotency behavior
O esquema exato não é o mais importante.
A saída estruturada é.
Um orquestrador não deveria precisar interpretar uma redação para descobrir se os testes passaram.
9. Abrir o pull request da tarefa
Cada tarefa produz um pull request direcionado à branch de integração do épico:
task/payment-retry
│
▼
epic/payment-improvements
│
▼
main
O PR deve permanecer revisável de forma independente.
A CI executa novamente fora do ambiente local do Builder.
Isso oferece duas camadas independentes de validação:
validação do Builder
+
validação da CI
10. Executar o Reviewer
O Reviewer recebe:
requisitos da tarefa
+
critérios de aceitação
+
diff
+
resultados dos testes
+
restrições relevantes de arquitetura
E retorna constatações estruturadas.
Por exemplo:
status: changes_requested
findings:
- severity: blocking
file: src/payments/service.ts
line: 87
reason: declined payments are being retried
criterion: only transient failures may be retried
Ou:
status: approved
findings: []
11. Executar o ciclo de correção
Se o Reviewer encontrar um problema bloqueante:
Reviewer
↓
Builder
↓
validação
↓
Reviewer
O ciclo continua dentro de limites predefinidos.
Um detalhe operacional importante: as novas tentativas não devem ser infinitas.
Depois de um número definido de ciclos sem sucesso, a tarefa deve ser escalada.
Por exemplo:
tentativa 1 → revisão reprovada
tentativa 2 → revisão reprovada
tentativa 3 → revisão reprovada
↓
encaminhamento para uma pessoa
Falhas repetidas também são informação útil. Podem indicar uma tarefa mal especificada, decomposta incorretamente ou com um problema de arquitetura ainda não resolvido.
12. Integrar na branch do épico
Quando:
Builder validation = passed
CI = passed
Reviewer = approved
A tarefa pode ser integrada à branch do épico de acordo com a política de autonomia do projeto.
Isso pode liberar tarefas posteriores no grafo de dependências.
O orquestrador agenda o trabalho recém-disponível.
13. Executar a validação do épico
A aprovação de cada tarefa isoladamente não prova que o épico funciona como um todo.
Quando todas as tarefas necessárias estiverem integradas, o fluxo executa validações mais amplas:
suíte completa de testes
testes de integração
testes de ponta a ponta
testes de contrato
verificações de migrações
verificações de segurança
verificações de desempenho
O conjunto exato depende do projeto.
Essa etapa detecta problemas que a validação de tarefas individuais não alcança.
Por exemplo, duas tarefas corretas isoladamente podem implementar suposições incompatíveis.
14. Validar os critérios de aceitação do épico
O Reviewer final avalia o resultado integrado em relação ao épico original, não às tarefas individuais.
A pergunta muda de:
Implementamos a tarefa 7 corretamente?
Para:
O sistema agora atende ao resultado definido pelo épico?
Essa distinção importa.
Um fluxo pode concluir todas as tarefas e ainda não alcançar o comportamento desejado do produto se a decomposição tiver sido incompleta.
15. Aprovação humana e merge final
Se a integração final atender aos critérios, o fluxo produz um pull request do épico:
epic/payment-improvements
│
▼
main
Esse é um ponto apropriado para exigir aprovação humana.
A pessoa já não precisa implementar nem revisar manualmente cada pequena alteração de código.
Sua atenção se concentra onde agrega mais valor:
requisitos
arquitetura
risco
exceções
integração final
Essa é uma interpretação mais realista de desenvolvimento com humanos no ciclo do que exigir supervisão de cada chamada de ferramenta de um agente.
Escolher modelos por papel
Não é necessário usar o mesmo modelo em todas as etapas.
Papéis diferentes têm requisitos computacionais diferentes.
O Planner pode se beneficiar de raciocínio mais forte, pois precisa entender arquitetura e dependências.
O Reviewer pode precisar de capacidade semelhante para identificar inconsistências sutis.
Um Builder executando uma mudança muito restrita talvez não exija o mesmo modelo.
Conceitualmente:
Orchestrator ── alta capacidade de raciocínio
Planner ── alta capacidade de raciocínio
Reviewer ── alta capacidade de raciocínio
Builder ── selecionado conforme a complexidade da tarefa
Isso também abre espaço para fluxos independentes de provedor.
Uma camada de orquestração pode usar OpenCode, Codex, Claude ou outros ambientes de agentes de programação sem mudar fundamentalmente a arquitetura descrita aqui.
O modelo se torna um componente de execução, em vez de ser o próprio fluxo.
Medir o fluxo
Um processo estruturado pode ser medido.
Métricas úteis incluem:
- tokens consumidos por tarefa;
- tokens consumidos por papel de agente;
- tempo de execução por tarefa;
- tempo total de execução do épico;
- número de novas tentativas;
- tentativas malsucedidas do Builder;
- problemas apontados pelo Reviewer;
- falhas de CI;
- tarefas concluídas sem intervenção humana;
- encaminhamentos para humanos;
- custo por pull request;
- custo por épico.
Essas métricas não devem servir apenas para minimizar o uso de tokens.
Elas ajudam a responder a perguntas mais úteis.
Por exemplo:
Adicionar um Planner reduz implementações malsucedidas?
Um Reviewer mais forte reduz defeitos de integração?
Certos tipos de tarefa são encaminhados para humanos com frequência?
A partir de qual tamanho de tarefa a conclusão autônoma deixa de ser confiável?
A execução paralela está realmente reduzindo o tempo de entrega?
Assim, decisões sobre agentes e modelos podem se basear no desempenho do fluxo, e não apenas na intuição.
O fluxo como máquina de estados
Quando tudo isso está explícito, o problema de orquestração se torna surpreendentemente mecânico.
Uma tarefa pode passar por estados como:
PENDING
↓
READY
↓
PLANNING
↓
BUILDING
↓
VALIDATING
↓
REVIEWING
│
├── changes requested ──► BUILDING
│
├── blocked ────────────► ESCALATED
│
└── approved
↓
MERGED
O épico tem seu próprio ciclo de vida:
PLANNING
↓
EXECUTING
↓
INTEGRATING
↓
VALIDATING
↓
AWAITING_APPROVAL
↓
COMPLETED
É nesse ponto que o desenvolvimento assistido por IA começa a se parecer menos com uma interface de chat e mais com um sistema distribuído de entrega de software.
E essa provavelmente é a abstração mais útil.
Considerações finais
O problema mais interessante do desenvolvimento assistido por IA está deixando de ser a própria geração de código.
É a orquestração.
Um fluxo autônomo precisa responder a perguntas como:
- Em que o agente deve trabalhar?
- Qual contexto ele deve receber?
- Que trabalho pode acontecer em paralelo?
- Quais decisões já foram tomadas?
- Como a implementação será validada?
- Quem revisa o resultado?
- O que acontece quando o Reviewer discorda?
- Quais ações podem ocorrer automaticamente?
- Onde é necessária aprovação humana?
- Como mudanças independentes se tornam uma funcionalidade coesa?
Modelos melhores tornarão execuções individuais mais capazes.
Eles não eliminarão a necessidade de responder a essas perguntas.
Um fluxo robusto não deve partir da suposição de que um modelo suficientemente poderoso pode receber um projeto inteiro e simplesmente “se virar”.
O sistema deve reduzir a ambiguidade antes da execução.
Isso significa:
intenção clara
+ tarefas coesas
+ dependências explícitas
+ contexto relevante mínimo
+ execução isolada
+ validação objetiva
+ revisão independente
+ autonomia baseada em risco
+ integração controlada
O objetivo não é retirar as pessoas da engenharia de software.
É deslocar a atenção humana da supervisão da implementação rotineira para decisões em que julgamento, contexto de produto, arquitetura e risco realmente importam.
Com esses limites explícitos, agentes de IA deixam de ser assistentes isolados de programação e passam a ser componentes de um pipeline de entrega de software.