O último passo manual no desenvolvimento com IA costuma aparecer quando o agente termina o site. A página está pronta, o build passou e os arquivos estão no computador — mas alguém ainda precisa abrir outra ferramenta, escolher uma hospedagem, localizar a pasta certa, fazer upload, esperar o deploy e copiar a URL.

Esse intervalo parece pequeno. Na prática, ele quebra o contexto do trabalho, cria espaço para enviar o pacote errado e transforma cada atualização em uma tarefa operacional separada. A IA acelerou a criação, mas a entrega continua presa a uma sequência de cliques.

Eliminar esse último passo não significa publicar sem autorização. Significa dar ao agente uma ferramenta de publicação com limites claros, estados observáveis e uma URL que possa ser aberta e verificada antes da entrega.

Onde o fluxo ainda quebra

Um fluxo de desenvolvimento assistido por IA pode automatizar boa parte do trabalho:

  1. interpretar o briefing;
  2. criar a estrutura da página;
  3. escrever HTML, CSS e JavaScript;
  4. executar o build;
  5. corrigir erros;
  6. revisar conteúdo e acessibilidade;
  7. preparar a saída estática.

Então surge uma resposta como: “Os arquivos estão em dist. Agora publique na sua plataforma preferida.”

Nesse ponto, o agente perdeu a capacidade de concluir o objetivo. Ele produziu um artefato, mas não entregou o resultado que será compartilhado com cliente, equipe ou campanha: uma URL pública funcionando.

O trabalho manual restante normalmente inclui:

  • descobrir qual pasta deve ser enviada;
  • entrar em um painel de hospedagem;
  • criar ou localizar o projeto correto;
  • compactar os arquivos;
  • iniciar o upload;
  • acompanhar o processamento;
  • copiar o endereço;
  • testar a página publicada;
  • repetir tudo depois de cada correção.

O problema não é um clique isolado. É a troca de contexto entre criação e operação.

Por que o último passo custa mais do que parece

Quando o deploy fica fora da conversa, parte do contexto precisa ser reconstruída por uma pessoa. Qual era o slug aprovado? A pasta correta é dist ou out? Esta mudança atualiza o mesmo Site ou cria outro? O formulário já aponta para o destino real?

Essa passagem manual produz riscos previsíveis:

Quebra de contexto Consequência possível
pasta errada código-fonte ou build antigo vai para o ar
pacote montado com pasta extra index.html não fica na raiz
destino indefinido surge uma URL nova em vez de atualizar a existente
sucesso presumido o deploy termina, mas assets ou links ficam quebrados
correção sem republicação a versão local muda e a URL pública continua antiga

Quanto mais rápido o agente cria versões, mais caro fica um processo de publicação que depende de remontar essas decisões a cada rodada.

O que precisa existir para eliminar o passo manual

O agente não precisa de acesso irrestrito à infraestrutura. Ele precisa de um contrato operacional pequeno:

  • autenticar a pessoa e respeitar o escopo da conta;
  • criar ou selecionar o Site certo;
  • escolher um slug de forma explícita;
  • abrir o contexto do Site e editar pelas file tools;
  • enviar um pacote estático válido;
  • iniciar e acompanhar a publicação;
  • distinguir estado intermediário de sucesso;
  • abrir a URL final;
  • informar o que fez e o que verificou.

O Model Context Protocol permite expor essas operações ao agente como ferramentas. Assim, criação e publicação continuam na mesma conversa, mas a plataforma de hosting preserva autenticação, validação e estados do deploy.

No Site no Ar, clientes compatíveis usam o MCP remoto. O agente edita o conteúdo do Site no diretório public/ e chama deploy para publicar uma nova Version. O contrato completo está no guia de Publicação.

Automação não elimina decisões

Existe uma diferença importante entre remover tarefas manuais e remover controle.

Você ainda decide:

  • o que pode ser publicado;
  • qual Site deve receber a versão;
  • qual endereço será usado;
  • se a copy e as integrações estão aprovadas;
  • quais verificações são obrigatórias;
  • em quais situações o agente deve parar.

O agente executa a parte operacional dentro desses limites. Se o slug estiver ocupado, o build falhar ou a pasta incluir segredos, a resposta correta não é improvisar. É interromper o fluxo e devolver uma decisão acionável.

Esse desenho mantém a autorização visível sem obrigar uma pessoa a repetir tarefas mecânicas.

Um pedido que fecha o ciclo

Depois de seguir a Configuração do MCP, transforme o pedido de desenvolvimento em um objetivo que inclua entrega:

Crie e publique esta landing page.


Antes do deploy, execute os checks do projeto e identifique a saída estática.
Confirme que index.html está na raiz e que todos os assets usados estão no pacote.
Use o Site campanha-inverno e preserve esse slug nas republicações.
Não envie código-fonte, dependências, arquivos .env ou segredos.


Use o MCP do Site no Ar para publicar.
Acompanhe o deploy até o estado final, abra a URL e verifique home, imagens,
links, CTA e layout em tela pequena.


Pare se houver decisão de conteúdo, destino ambíguo ou dependência de backend.
No fim, informe pasta enviada, Site, slug, URL, status e checks executados.

O prompt não precisa descrever a infraestrutura interna. Ele define objetivo, limites, destino e evidências esperadas.

Como o fluxo muda na prática

Sem uma ferramenta de publicação, o processo fica dividido:

briefing → criação → revisão → build → handoff de arquivos
                                      ↓
                         painel → upload → URL → teste

Com uma integração operável pelo agente, o ciclo fica contínuo:

briefing → criação → revisão → build → publicação → URL → verificação

A plataforma ainda executa upload, validação, preparação e ativação. A diferença é que o agente consegue conduzir a sequência, acompanhar os estados e devolver o resultado sem pedir que você assuma o meio do processo.

O artigo sobre como funciona o deploy automático por agente de IA detalha cada etapa operacional. Aqui, o ponto central é o desenho do fluxo: publicar deixa de ser um ritual posterior e passa a ser parte da definição de pronto.

O que deve continuar manual

Nem toda intervenção humana é desperdício. Algumas decisões pertencem à pessoa responsável pelo produto:

  • aprovar preço, promessa e condições comerciais;
  • confirmar o domínio de um cliente;
  • avaliar implicações legais ou de marca;
  • autorizar a substituição de uma versão crítica;
  • testar pagamentos, formulários e integrações externas;
  • decidir se um projeto dinâmico precisa de outra arquitetura.

Essas são revisões de conteúdo, risco e produto. Compactar arquivos, copiar uma URL e consultar repetidamente o status do deploy são tarefas operacionais.

Uma boa automação remove o segundo grupo e torna o primeiro mais claro.

Como começar sem mudar todo o processo

Escolha uma landing page estática de baixo risco e faça uma primeira rodada supervisionada:

  1. conecte seu agente ao Site no Ar;
  2. defina uma pasta publicável e um slug;
  3. peça validação antes do envio;
  4. acompanhe as decisões do agente;
  5. confira a URL final;
  6. registre o prompt que produziu um resultado confiável;
  7. use o mesmo Site para a próxima republicação.

Na primeira vez, o objetivo é observar o contrato. Depois, o prompt pode virar parte do padrão do projeto ou da rotina da equipe.

A definição de pronto termina na URL

Se o objetivo é lançar uma página, gerar arquivos não conclui o trabalho. A entrega termina quando o conteúdo aprovado está em uma URL pública, os assets carregam, os links funcionam e o resultado corresponde à versão esperada.

O último passo manual no desenvolvimento com IA desaparece quando o agente consegue atravessar essa distância com ferramentas autorizadas e evidências. Você continua tomando decisões; deixa apenas de atuar como ponte entre o build e a hospedagem.

Para experimentar, siga a configuração do agente, escolha uma página simples e peça o ciclo completo: validar, publicar, acompanhar e abrir a URL.