Pular para o conteúdo
Um desenvolvedor supervisiona um agente de IA que interage com um site, destacando a camada de limites e segurança entre eles.
Voltar para o Blog

O Dev Está Cavando o Próprio Desemprego Ao Conectar Agentes de IA ao Site do Cliente? O Que Morre e o Que Nasce

Equipe Golber.
11 min de leitura
Tecnologia

Entre na sua conta para curtir e guardar o que gostou.

Ouça este artigo

O Dev Está Cavando o Próprio Desemprego Ao Conectar Agentes de IA ao Site do Cliente? O Que Morre e o Que Nasce

0:00 / 13:33
1×
Sincronia do destaque
no ponto
Se a voz parecer atrás do trecho marcado, atrase o destaque
Um desenvolvedor supervisiona um agente de IA que interage com um site, destacando a camada de limites e segurança entre eles.

Quem constrói a ponte entre o agente de IA e o site do cliente está construindo a própria dispensa? Sim e não: morre o intermediário de pedido, nasce a camada de limites e responsabilidade. Com código, a tabela do que a camada garante e quem paga quando o agente erra.

Eu deixei o meu site pronto pra agente de IA usar. Escrevi sobre isso, expliquei como fazer em Next.js, e enquanto implementava me veio a pergunta incômoda: daqui a pouco o dono do site vai pedir direto pra IA "troca o banner, cria a promoção de sexta, sobe esses 40 produtos", e o programador some da conversa. Quem está construindo essa ponte somos nós. Estamos cavando o próprio buraco?

A resposta honesta tem duas partes, e as duas importam: sim, uma parte do nosso trabalho morre, e ela já estava morrendo antes disso. E não, quem constrói a ponte não é quem fica sem trabalho: quem fica sem trabalho é quem cobrava pelo pedido em vez de cobrar pela capacidade. Este post é sobre a diferença entre os dois, com o que já dá pra fazer hoje e a parte que ninguém coloca no slide de vendas: quem responde quando o agente erra.

  • A parte do trabalho que morre, e ela já estava morrendo

  • A camada invisível que um agente precisa pra mexer num site de verdade

  • Quem paga quando o agente apaga a loja inteira

  • Cobrar pelo pedido ou pela capacidade: o que decide o seu emprego

O que morre é o intermediário de pedido

O trabalho que desaparece é o de intermediário: o dev que recebe "muda o texto do banner", abre o editor, muda, publica e cobra por isso. Esse papel já vinha encolhendo desde que existe painel de conteúdo, e o agente só acelera. O que não desaparece é decidir o que o sistema permite, garantir que não quebre e responder quando quebrar.

Repare que a ameaça não é a IA escrever código melhor que você. É o dono do negócio deixar de precisar pedir. Essas duas coisas são diferentes, e a segunda é mais antiga: o WordPress já tirou do dev o "publicar um post pro cliente", o Shopify tirou o "cadastrar produto", o construtor visual tirou o "mudar a cor do botão". Em nenhum desses casos o mercado de desenvolvedor encolheu; o que aconteceu foi mais gente conseguindo ter site, e aí precisando de coisas que o painel não faz.

O agente é a próxima camada disso, com uma diferença importante: ele não é um formulário, é um executor. O painel do WordPress deixa o dono mudar o que o dev previu num campo. O agente tenta fazer o que o dono pediu, inclusive o que ninguém previu. É aí que o trabalho muda de lugar em vez de sumir.

A IA não tira o seu trabalho quando escreve código. Tira quando o cliente deixa de precisar pedir.

A camada invisível que o agente precisa

Pra um agente mexer num site de verdade, alguém precisa expor o que ele pode fazer, com limite e com registro. Não é "dar acesso ao admin". É escrever cada ação como uma ferramenta tipada, com quem pode chamar, o que pode mudar, quanto pode mudar de uma vez e o que fica gravado. Isso é trabalho de desenvolvedor, e não é pouco.

No meu site, o caminho técnico é o que descrevi em WebMCP no Next.js: em vez de o agente adivinhar cliques na tela, o site declara funções que ele pode chamar. A diferença entre "o agente controla o navegador" e "o agente chama a função que eu escrevi" é a diferença entre torcer e garantir. Um exemplo do formato, com as travas onde elas precisam estar:

// Ferramenta exposta ao agente: publicar promoção.
// O que o dono pede em linguagem natural entra aqui com limite.
registrarFerramenta({
  nome: "criar_promocao",
  descricao: "Cria uma promoção com desconto em uma categoria",
  parametros: {
    categoria: { tipo: "string", opcoes: CATEGORIAS_ATIVAS },
    descontoPercentual: { tipo: "number", minimo: 1, maximo: 30 },
    validadeDias: { tipo: "number", minimo: 1, maximo: 15 },
  },
  requerPapel: "dono",          // quem pode chamar
  exigeConfirmacao: true,        // humano aprova antes de valer
  limitePorDia: 3,               // teto de uso
  registrar: true,               // fica no log com quem pediu
});

Cada linha dessa é uma decisão de negócio virada em código: por que 30% e não 90%, por que 15 dias, por que confirmação. O agente não inventa nenhuma delas. E é exatamente isso que o dono do site não vai escrever sozinho, porque não é sobre saber programar: é sobre saber o que não pode acontecer com o negócio dele. O mesmo raciocínio aparece em comércio agêntico no Brasil, quando a loja precisa ser comprável por um agente sem virar terra de ninguém.

Quem responde quando o agente erra

Quando o agente do dono aplica 90% de desconto na loja inteira, apaga 300 produtos ou expõe dado de cliente, alguém responde. Não é a IA, não é o fornecedor do modelo, e o dono vai olhar pra quem montou a integração. Essa responsabilidade é o que transforma "conectar um agente" em serviço profissional em vez de favor técnico.

Isso não é hipótese distante. Em código gerado por IA, o relatório da Veracode com mais de cem modelos mostrou que 45% das amostras reprovaram em segurança, e os modelos maiores não foram melhores. Agente com poder de escrita num sistema real precisa das mesmas defesas que qualquer usuário perigoso: permissão mínima, limite por operação, confirmação no que é destrutivo, log de quem pediu o quê e um botão de desfazer.

Tem uma camada a mais, que é a de confiança do próprio modelo. Já existe modelo feito pra devolver decisão com probabilidade calibrada em vez de texto, que é o caso do Jev, da TypeSafe AI: em vez de o agente agir com a mesma cara de certeza esteja certo ou errado, ele devolve o quanto está seguro, e o seu código decide se age sozinho, confirma ou chama um humano. Quem desenha esse limiar é o dev. Quem vive com o resultado é o dono.

O que o dono pedeO que o agente faz sem camadaO que a camada garante
"Dá um desconto bom no verão"Interpreta "bom" e aplica o que acharTeto de 30%, só em categoria ativa, com confirmação
"Limpa os produtos antigos"Apaga em massa, sem voltaMarca como inativo, com desfazer em 30 dias
"Manda um e-mail pros clientes"Dispara pra base inteiraSó quem optou por receber, teto por hora, preview antes
"Muda o preço do frete"Quebra a margem sem avisarBloqueia abaixo do custo e avisa quem decide

Cobrar pelo pedido ou pela capacidade

Aqui está a parte que decide se você fica sem trabalho, e ela não é técnica. Quem vende pedido (uma alteração, uma hora, uma demanda) está vendendo exatamente o que o agente passa a fazer. Quem vende capacidade (o sistema faz isso sozinho, com segurança, e eu respondo por ele) está vendendo o que o agente exige pra existir.

É a mesma virada que eu já defendi em a IA não vai te substituir, mas já derrubou o preço do que você faz: o valor migrou da execução pra decisão e pra responsabilidade. E é por isso que o contrato de manutenção vale mais que o projeto: um site entregue e abandonado morre; um site que o dono opera sozinho, com um profissional garantindo os limites, é uma relação que dura anos.

Repare o que isso faz com o número de clientes possíveis. Enquanto o dev era o intermediário, cada cliente consumia horas suas todo mês, e você atendia poucos. Quando o dono opera sozinho dentro dos trilhos que você construiu, a sua hora vai pra construir trilho novo, e o mesmo dev sustenta muito mais gente. O mercado de quem pede encolhe. O de quem constrói o que permite pedir cresce.

Se o seu trabalho cabe num pedido, a IA vai fazer. Se ele cabe numa garantia, ela precisa de você.

O buraco é real, mas é outro

Pra não soar otimista demais: existe um buraco de verdade, e ele não é o do dev experiente que constrói a camada. É o da porta de entrada. O acompanhamento de Stanford com a folha de pagamento da ADP mostra, na atualização de agosto de 2026, o emprego de jovens de 22 a 25 anos em ocupações expostas à IA 19% abaixo do esperado, sem deslocamento generalizado e sem efeito nos experientes. A vaga que sumiu é a de quem fazia o pedido pequeno.

Então a frase honesta não é "estamos cavando nosso desemprego". É: estamos cavando o desemprego de uma função, e é a função pela qual a maioria de nós entrou no mercado. Quem está dentro migra pra camada de cima. Quem está chegando agora entra por outra porta, que é a que eu descrevi em IA não vai roubar seu emprego, quem sabe usar IA vai: entregar coisa inteira, com teste e no ar, em vez de tarefa cortada.

E tem o lado que ninguém lembra: quando pedir fica barato, pede-se mais. O dono que antes adiava três mudanças por mês porque "tem que chamar o rapaz" vai fazer trinta. Trinta mudanças por mês em cima de trilhos que alguém precisa ampliar, monitorar e consertar. É o mesmo padrão de um loop de agentes sem teste segurando: o volume aumenta, e com ele a necessidade de quem garante.

O que eu faria nos próximos 12 meses

  1. Expor uma ação, não o admin. Escolha a tarefa que o cliente mais pede e transforme numa ferramenta tipada com limite, confirmação e log. Uma só. É o protótipo do seu novo produto.

  2. Escrever o contrato antes da integração. O que o agente pode fazer, o que exige humano, quem responde por dano, como desfaz. Se isso não está escrito, você assumiu risco de graça.

  3. Cobrar por trilho e por garantia. Mensalidade de operação com limites, monitoramento e correção, não pacote de horas. O painel que sustenta esse modelo eu detalhei em o que mostrar no painel do cliente.

  4. Medir o que o agente faz. Quantas ações por semana, quantas precisaram de humano, quantas foram desfeitas. Esse número é o seu argumento de renovação e o seu alarme.

  5. Aprender a vender isso. Explicar pro dono por que o limite de 30% protege o negócio dele é venda, não suporte. Se essa parte trava, o problema é outro, e está em aprender a vender ou aprender a programar.

Se você tem clientes com site e está pensando em abrir essa porta pra eles sem virar refém do primeiro desastre, é exatamente o desenho que eu fecho numa sessão de consultoria técnica: quais ações expor, com que limites, o que exige confirmação e como cobrar por isso de um jeito que o cliente entenda o valor.

Perguntas frequentes

Conectar agentes de IA ao site do cliente elimina o programador?

Elimina o papel de intermediário de pedido, que já vinha encolhendo desde o WordPress. Não elimina quem define o que o sistema permite, monta os limites, garante que não quebre e responde quando quebra. Esse trabalho aumenta quando o volume de pedidos aumenta.

O dono do site não vai conseguir montar a integração sozinho?

Montar uma demonstração, sim. Definir o que não pode acontecer com o próprio negócio, traduzir isso em limites técnicos e responder por dano é outra coisa. A parte difícil não é o código, é a decisão de limite e a responsabilidade.

O que um agente precisa pra mexer num site com segurança?

Ferramentas tipadas em vez de acesso livre, permissão por papel, limite por operação, confirmação humana no que é destrutivo, registro de quem pediu o quê e uma forma de desfazer. Sem isso, é dar a chave do admin pra um estagiário sem supervisão.

Quem é responsável se o agente causar prejuízo?

O dono responde perante o cliente dele, e vai cobrar de quem montou a integração. Por isso o contrato precisa dizer antes o que o agente pode fazer, o que exige aprovação humana e como se desfaz um erro. Sem contrato, o risco é seu, de graça.

A IA está mesmo tirando vagas de programador?

O dado de Stanford com a ADP (agosto de 2026) mostra o emprego de 22 a 25 anos em ocupações expostas 19% abaixo do esperado, sem deslocamento generalizado e sem buraco nos experientes. O que encolheu foi a porta de entrada, não a profissão.

Como cobrar por esse tipo de trabalho?

Por capacidade e garantia, não por pedido: mensalidade de operação com limites, monitoramento, correção e evolução dos trilhos. Quem continua vendendo pacote de horas está vendendo exatamente aquilo que o agente passa a fazer sozinho.

Gostou?
Compartilhar

Quer mais conteúdo desse?

Receba toda semana o que escrevo sobre stack, IA aplicada e negócios solo. Zero spam, descadastro num clique.