Como evitar as “granadas de slop”

22 de setembro de 2026 · Matt Senter

O conselho que dou aos meus clientes é simples: Você não consegue competir sem a ajuda da IA. Também não consegue competir produzindo slop de IA. Use as ferramentas e mantenha a experiência necessária para usá-las direito.

Tobi Lütke, CEO da Shopify, descreveu recentemente como “granadas de slop” o resultado de IA repassado a colegas sem revisão. O exemplo dele incluía e-mails inchados que deixam para o destinatário o trabalho de extrair a informação útil. Alguém se sente produtivo enquanto outra pessoa herda a limpeza.

É uma boa descrição. Mas quando isso acontece dentro de uma organização, minha primeira pergunta é o que a gestão decidiu recompensar, que experiência ela manteve e se alguém está medindo o trabalho que aparece depois que alguém clica em “concluído”.

Uso IA intensivamente para construir software. Não tenho interesse em voltar a um mundo em que digito manualmente cada linha de código. A combinação que recomendo é gente experiente com ferramentas de IA potentes, e a contribuição humana começa antes de o agente escrever qualquer coisa. Alguém precisa escolher uma abordagem, estabelecer as restrições e reconhecer uma solução que valha a pena construir.

O problema de gestão vem primeiro

A Shopify cortou cerca de 10% da força de trabalho em julho de 2022, com Lütke reconhecendo que havia superestimado a permanência do boom de e-commerce da pandemia. Em maio de 2023, ele anunciou outra redução de aproximadamente 20% junto com a venda da Shopify Logistics. Esse segundo anúncio também destacava as oportunidades da era emergente da IA. Foram decisões de liderança sobre o rumo, o quadro de pessoal e as prioridades da empresa.

Em abril de 2025, Lütke tornou o uso de IA uma expectativa básica, incorporou-o às avaliações de desempenho e entre pares, e passou a exigir que times que pedissem mais pessoas ou recursos explicassem por que a IA não daria conta. O memorando dele também defendia explicitamente multiplicar a habilidade humana com IA. Concordo com esse princípio.

Esses fatos não provam que as demissões da Shopify causaram suas granadas de slop, nem que engenheiros experientes foram substituídos em massa por operadores de prompt sem formação técnica. Mas mostram por que a questão da gestão importa. Quem define a política de pessoal e as expectativas sobre o uso de IA também assume a responsabilidade de fazer essa combinação funcionar.

Minha objeção é a um modelo operacional que pede aos funcionários que demonstrem adoção de IA sem dar o mesmo peso ao julgamento, à verificação e à manutenção necessários para transformar o resultado gerado em trabalho útil. Antes de perguntar se a IA consegue fazer um trabalho, a gestão deveria perguntar o que é preciso para entregar o resultado corretamente. Não são a mesma pergunta.

Um agente consegue produzir um pull request? Ótimo. Quem sabe se ele resolve o problema certo? Quem verifica as implicações arquiteturais? Quem responde por ele quando quebra? Quanto do dia de outro funcionário vai sumir revisando e consertando aquilo?

Funcionários continuam responsáveis pelo que entregam. Mas quando as pessoas passam repetidamente umas às outras um trabalho que não conseguem avaliar, eu vejo um problema de desenho organizacional, não apenas um conjunto de funcionários decepcionantes. A liderança não pode ficar com o crédito dos ganhos de produtividade e tratar a limpeza como um problema de talento.

Apertar Enter não é engenharia

Não há nada de errado em pessoas sem formação técnica usarem IA para construir coisas. Baixar a barreira para experimentar é uma das partes mais empolgantes desta tecnologia. Quem antes não conseguia levar uma ideia além do rascunho agora pode explorar um protótipo funcionando, e acho isso fantástico.

Um protótipo e um sistema em produção são responsabilidades diferentes, no entanto. Alguém ainda precisa entender o que foi construído, de quais premissas aquilo depende e que evidência mostraria que essas premissas estão erradas.

Colocar uma pessoa entre um agente e o botão de deploy não garante automaticamente supervisão significativa. Essa pessoa precisa do conhecimento para contestar o agente, do tempo para investigar o trabalho dele e da autoridade para rejeitar o resultado. Caso contrário, a etapa de aprovação é cerimonial.

Essa não é uma preocupação apenas de quem desconfia da IA. A própria orientação do GitHub alerta que seus agentes podem produzir código incorreto ou inseguro, recomenda revisar e testar o resultado e diz que a revisão de código por IA deve complementar, e não substituir, a revisão humana.

A aprovação cega é um problema de “entra lixo, sai lixo”, mas o lixo não está necessariamente confinado ao prompt. Pode ser um requisito incompleto, uma restrição ausente, um incentivo para ir rápido demais ou um processo de revisão que se resume a perguntar ao mesmo sistema se ele fez um bom trabalho. A solução é empregar gente que saiba quando discordar.

Engenharia é saber como, não só pedir o quê

Há uma diferença substancial entre dizer a um agente o que um produto deve fazer e saber como esse produto deve ser implementado. “Construa um sistema que processe estes registros” descreve um resultado. Diz muito pouco sobre arquitetura, carga esperada, orçamento de memória, fronteiras de segurança ou comportamento quando algo falha.

Um bom engenheiro assistido por IA fornece essa direção que falta. Ele pode dizer ao agente para seguir os padrões de código já estabelecidos no projeto, reutilizar uma abstração existente, escolher uma estrutura de dados adequada ou evitar um algoritmo que fica proibitivamente caro conforme a entrada cresce. Escrever instruções para o repositório só é útil se alguém souber o que essas instruções devem dizer.

Isso não significa ditar cada detalhe de implementação nem supor que a primeira ideia do humano tem de ser melhor. Quero que o agente sugira alternativas e questione premissas. Mas alguém precisa entender o suficiente para avaliar essas alternativas em vez de aceitar a explicação que soar mais confiante.

“Deixe eficiente” não substitui entender eficiência. “Deixe seguro” não é um modelo de segurança. São aspirações até que alguém as traduza em requisitos concretos e verifique que a implementação os cumpre.

O O grande não foi embora

Considere um exemplo simples: casar registros entre duas coleções usando identificadores únicos. Uma implementação poderia varrer repetidamente a segunda coleção para cada registro da primeira. Com duas coleções de n registros, isso pode exigir n² comparações. Como alternativa, para identificadores de tamanho fixo, construir uma busca baseada em hash pode levar o casamento a tempo esperado O(n), ao custo de O(n) de memória adicional. Isso é um compromisso entre tempo e espaço, não uma questão de preferência de formatação.

As duas implementações podem produzir a resposta certa numa demonstração pequena. A pergunta de engenharia é o que acontece sob a carga que o produto realmente precisa suportar. Quantos dados vai processar? Quanta memória está disponível? É uma operação ocasional ou algo que acontece a cada requisição?

Um operador experiente pode dar ao agente uma direção útil: “Evite varrer a coleção inteira para cada registro. Construa uma tabela de busca, considere seu custo de memória e meça a implementação com os tamanhos de entrada que esperamos.” Essa instrução vem de entender o problema, não de descobrir um prompt mágico.

O mesmo entendimento deveria evitar a otimização desnecessária. Não quero um agente transformando uma operação trivial num arcabouço elaborado só porque alguém mandou maximizar o desempenho. Quero que o operador entenda complexidade de tempo, complexidade de espaço e os requisitos reais bem o suficiente para escolher uma solução adequada.

A ciência da computação não virou opcional porque as instruções agora são escritas em português. Mudamos a forma como pedimos software. Não mudamos as propriedades que tornam o software correto, eficiente ou sustentável.

Às vezes você precisa mandar construir uma máquina de estados

Suponha que eu esteja construindo um processo de importação em segundo plano que pode estar na fila, em execução, concluído, com falha ou cancelado. Uma implementação plausível acompanharia o progresso com um punhado de flags separadas. Mas esse desenho precisa impedir combinações contraditórias, como um job estar ao mesmo tempo em execução e concluído.

Uma máquina de estados finitos dá a esse fluxo um conjunto explícito de estados e transições definidas entre eles. Em vez de espalhar pela aplicação as decisões sobre o que pode acontecer a seguir, consigo modelar quais eventos têm permissão para mover o processo de um estado a outro. Esses são os conceitos básicos por trás da notação de máquinas de estados: estados, eventos e transições.

O agente pode propor essa abordagem por conta própria. Ótimo. Mas pode não propor, e a pessoa que o dirige precisa reconhecer quando o problema pede isso. Às vezes a instrução útil é: “Implemente isto como uma máquina de estados finitos. Defina as transições legais, trate o cancelamento explicitamente e teste o que acontece quando um evento de conclusão chega depois do cancelamento.” É escolher um modelo para o comportamento do sistema.

Máquinas de estados finitos, statecharts e outros autômatos pertencem à caixa de ferramentas técnica do operador humano. Não porque toda funcionalidade precise de um modelo formal, mas porque o operador deveria reconhecer quando um deles esclareceria o problema e quando acrescentaria complexidade desnecessária. Saber o nome de um padrão não basta. É preciso entender onde ele se aplica, o que ele garante e o que ele deixa em aberto.

E “use uma máquina de estados” não é um encantamento que torna a implementação correta. Continuo tendo de examinar as transições e testar o comportamento. O valor está em ter dado ao agente uma estrutura sobre a qual consigo raciocinar, em vez de aceitar um arranjo de condições só porque passou no teste do caminho feliz.

Interação humano-computador também não é opcional

A ciência da computação não é a única especialidade de que ainda precisamos. Interação humano-computador também importa, e não estou disposto a tratá-la como um acabamento opcional só porque um agente gera uma tela tão rápido quanto gera o código por trás dela.

Espero que uma parte cada vez maior da internet se torne agent-first. Mas continuo construindo produtos que as pessoas precisam entender e usar. Essas pessoas precisam saber o que está acontecendo, o que suas escolhas significam, se uma ação deu certo e como se recuperar quando algo dá errado. Visibilidade, consistência, controle do usuário e prevenção de erros são princípios consolidados de design de interação, não preferências decorativas.

“Faça uma boa interface” é mais ou menos tão útil quanto “deixe o algoritmo eficiente”. Um profissional competente consegue dar ao agente uma direção muito mais precisa: organize a informação em torno da tarefa do usuário, preserve a navegação familiar, distinga ações principais de destrutivas e torne compreensíveis os estados de progresso e de falha. A acessibilidade acrescenta requisitos concretos de implementação, incluindo operação por teclado, foco visível, rótulos com significado e mensagens de status acessíveis.

Pegue o processo de importação em segundo plano do exemplo da máquina de estados. Acertar os estados internos é só parte do trabalho. Também quero que a interface distinga entre aguardando início, importando, parcialmente concluído, cancelado e com falha. Quem usa não deveria precisar deduzir essas diferenças a partir de um indicador girando.

Minhas instruções ao agente poderiam ser: “Preserve as seleções do usuário depois de uma falha. Explique quais registros foram importados e quais não. Não mostre mensagem de sucesso enquanto a operação não tiver de fato terminado. Mostre se o cancelamento ainda é possível e deixe explícito o comportamento de nova tentativa.”

Isso é orientação de implementação, não um pedido de cores mais bonitas. Continuo tendo de usar a interface resultante, testar os estados relevantes e observar se as pessoas a entendem. Uma captura de tela caprichada não é evidência suficiente de que a interação funciona.

O mesmo vale para as interfaces dos próprios agentes. Trocar menus por conversa não elimina a necessidade de comunicar escopo, progresso, incerteza e consequências. Eu diria que um agente atuando em vários sistemas torna essas decisões de design mais importantes, não menos. O humano ainda precisa de uma forma de entender, interromper, corrigir e aprovar o trabalho.

Uma internet agent-first não é uma internet irrelevante para humanos. Enquanto houver pessoas dirigindo o trabalho e convivendo com suas consequências, alguém precisa projetar essa relação.

Apertar Enter não é estratégia de segurança nem de privacidade

Qualidade de código é só parte da responsabilidade. Um agente também pode pedir acesso a arquivos, executar comandos, interagir com serviços e gerar código com vulnerabilidades. A própria orientação do GitHub alerta explicitamente sobre resultados incorretos ou inseguros e sobre a necessidade de revisão e testes cuidadosos.

Antes de aprovar uma ação, quero o operador perguntando o que ela pode acessar, o que pode alterar e para onde os dados podem ir. Esta tarefa exige credenciais de produção? Aqueles logs de depuração podem conter informações de clientes? Por que uma operação que só precisa ler dados tem permissão para modificá-los ou apagá-los?

Não são detalhes para depois que a demo funcionar. A OWASP identifica excesso de funcionalidade, de permissões e de autonomia como fontes de risco em sistemas agênticos. Suas recomendações incluem limitar capacidades, aplicar privilégio mínimo, exigir aprovação para ações de alto impacto e implementar a autorização fora do modelo em vez de confiar que ele decida o que é permitido.

Quem aprova cegamente cada pedido não está avaliando esses riscos de forma significativa. Mas a resposta também não é simplesmente contratar alguém experiente e esperar que perceba tudo. Dê a essa pessoa um ambiente com fronteiras impostas pelo sistema, controles de acesso adequados e um processo de revisão que não dependa de vigilância perfeita.

É por isso que me importo com o entendimento do operador. Ele precisa ajudar a projetar as salvaguardas, não apenas ocupar a cadeira em frente ao botão de aprovar.

Conformidade faz parte da engenharia

Um produto que funciona numa demo não é necessariamente um produto que uma organização consegue operar com responsabilidade. Alguém também precisa entender que informação ele manipula, quem pode acessá-la, quais obrigações se aplicam e que evidência a organização precisa para demonstrar que seus controles funcionam.

Dependendo do negócio, isso pode incluir SOC 2, PCI DSS e HIPAA. São tipos diferentes de obrigação e de mecanismo de garantia, não três selos intercambiáveis:

SOC 2 é um exame independente de controles frente aos Trust Services Criteria aplicáveis. Esses critérios incluem gestão de mudanças: autorizar, documentar, testar, aprovar e implementar alterações no sistema. Um agente gerar um build bem-sucedido não estabelece que a organização seguiu esse processo.
PCI DSS estabelece requisitos técnicos e operacionais de segurança para dados de contas de pagamento. Seu escopo pode incluir sistemas e prestadores de serviço que afetam a segurança do ambiente de dados do portador do cartão, e não apenas um banco de dados que armazene números de cartão diretamente. Entender esse escopo faz parte de projetar e operar o sistema com responsabilidade.
HIPAA, onde se aplica a entidades cobertas e parceiros de negócio, traz requisitos de proteção de informações eletrônicas de saúde protegidas. Sua Security Rule inclui análise de risco, controles de acesso, controles de auditoria e acordos adequados com parceiros de negócio. Essas responsabilidades não somem porque um assistente de IA ajudou a escrever a aplicação.

Não espero que todo desenvolvedor seja advogado de conformidade ou auditor. Espero que um time experiente reconheça quando esses requisitos afetam um desenho e traga a especialidade adequada antes de publicar. “Ninguém contou ao agente” é uma falha de requisitos, não uma isenção.

Para mudanças relevantes em produção, quero uma trilha de auditoria que conecte o pedido à implementação, aos testes, à revisão, à aprovação e ao deploy. O que mudou? Por quê? Qual versão foi revisada? Quem aprovou, com que autoridade? O que de fato chegou à produção?

Esse registro deve ser produzido enquanto o trabalho acontece, não reconstruído depois a partir da memória de alguém e do resumo animado de um agente. Um registro dizendo “aprovado” estabelece que alguém clicou num botão. Por si só, não estabelece que houve uma revisão significativa.

Uma aprovação é uma decisão, não uma tecla

Apertar Enter sem revisar as consequências pode colocar em risco a organização, seus clientes e a pessoa que aprova a ação. Pense num agente propondo enviar logs de produção para um serviço externo para depurar. Antes de aprovar esse pedido, alguém precisa determinar o que há nesses logs e se aquele destino é permitido. A conveniência da correção proposta não responde a nenhuma das duas perguntas.

Também pode haver consequências para o funcionário que contorna salvaguardas obrigatórias. A orientação do HHS sobre políticas de sanção da HIPAA, por exemplo, discute consequências que vão de advertências a demissão, deixando a resposta adequada a cargo da organização e das circunstâncias. Não é uma afirmação de que toda aprovação equivocada deva custar o emprego de alguém. É um lembrete de que uma aprovação pode carregar responsabilidade profissional.

Mas a gestão não pode atribuir essa responsabilidade com justiça sem fornecer o conhecimento, o tempo, a informação e a autoridade necessários para exercê-la. Dar a alguém uma fila de aprovações que ele não consegue avaliar, medi-lo pela rapidez com que a esvazia e depois culpá-lo pelo resultado não é delegação responsável.

A própria interface de aprovação precisa sustentar a decisão. Para um deploy, quero que quem revisa veja a mudança real, o ambiente de destino, os resultados de teste relevantes, os riscos em aberto e o plano de recuperação. Não quero que “Prosseguir? S/n” faça as vezes de uma explicação do que está prestes a acontecer.

Tampouco quero um fluxo que exija aprovação humana para cada ação inofensiva. Meu objetivo é automatizar trabalho de baixo risco dentro de limites estabelecidos e reservar a atenção humana para decisões que exigem julgamento. Acrescentar mais botões não é o mesmo que acrescentar mais supervisão.

A Ford precisou reconstruir a experiência que havia perdido

A Bloomberg noticiou em junho de 2026 que a Ford havia contratado 350 engenheiros veteranos nos três anos anteriores, incluindo ex-funcionários e engenheiros de fornecedores. Eles ajudavam a resolver problemas de qualidade, a treinar profissionais mais jovens e a melhorar ferramentas de IA que haviam ficado aquém. Era uma história sobre engenharia veicular e sistemas de qualidade, não uma afirmação de que a Ford recontratou 350 desenvolvedores de software para limpar código de aplicação gerado por IA.

Essa é a lição que eu levaria para uma empresa de software. Antes de tirar um engenheiro caro de uma planilha, entenda o que aquela pessoa contribui além do resultado visível. Pergunte o que ela evita, o que ela percebe cedo e o que o resto do time depende que ela entenda. Depois, considere o que ferramentas melhores poderiam ajudá-la a realizar.

Pare de confundir salários menores com custos menores

A gestão quer cortar custos de mão de obra. Eu entendo. Também toco negócios, e não estou sugerindo que empresas gastem dinheiro sem esperar retorno. Mas eu avaliaria esse retorno contra o custo de entregar e manter um produto útil, e não simplesmente contra o salário atrelado a cada pessoa que trabalha nele.

Um amigo me mandou há pouco uma descrição de vaga para uma posição presencial de engenharia de software em Nova York. Exigia mestrado e seis anos de experiência de mercado e anunciava US$ 200 mil. A combinação não fazia sentido para mim. Para o calibre de engenheiro que eu quereria dirigindo desenvolvimento assistido por IA de consequência real, eu estruturaria a posição de outro jeito.

Primeiro, eu tiraria a exigência de mestrado, a menos que fosse uma posição de pesquisa em que essa formação realmente importasse. Quero saber o que a pessoa construiu, quais decisões difíceis assumiu e se entende as consequências dessas decisões. Exigir conhecimento de ciência da computação não é a mesma coisa que exigir um diploma específico.

Ela consegue explicar por que escolheu uma arquitetura em vez de outra? Consegue reconhecer uma fronteira de segurança, raciocinar sobre desempenho e projetar um sistema que se comporte de forma sensata quando algo falha? Consegue dirigir um agente até uma boa implementação e rejeitar uma aparentemente bem-sucedida que não atende aos requisitos reais?

São essas as capacidades pelas quais eu contrataria. Depois, eu orçaria cerca de US$ 350 mil de salário anual, com até US$ 2 mil por mês para assistência de IA, e esperaria que o processo seletivo comprovasse que a pessoa justifica esse investimento.

Esse é meu orçamento proposto para um cargo de alto impacto, não uma afirmação de que toda posição de engenharia deva pagar o mesmo. Oferecer salário maior também não isenta a gestão da responsabilidade de avaliar candidatos direito. O ponto é competir de forma agressiva pela experiência de que a estratégia depende, em vez de supor que uma assinatura de IA torna essa experiência menos valiosa.

Dê ao engenheiro um orçamento sério de ferramentas

A verba mensal de US$ 2 mil seria um orçamento total de ferramentas de IA, não o preço de uma única assinatura nem a obrigação de gastar cada dólar. Para um caso de uso aprovado, penso em algo como um plano Claude Max reembolsado mais uso adicional. A Anthropic oferece uso pago acima da cota incluída no plano, com controles de gasto.

A conta e a forma de uso ainda precisam caber nos requisitos de segurança, privacidade e contratuais da organização. Reembolsar uma assinatura pessoal não resolve essas questões. O time precisa escolher o arranjo adequado às informações e aos sistemas envolvidos.

Com a verba cheia, são US$ 24 mil por ano em IA ao lado de um salário de US$ 350 mil, ou US$ 374 mil em salário e ferramentas antes de benefícios, encargos do empregador, bônus, participação e outros custos indiretos. As ferramentas custam menos de 7% do salário. Eu julgaria essa despesa pelo que ela permite ao engenheiro entregar.

Numa comparação deliberadamente simplificada de salário e ferramentas, US$ 374 mil são 1,87 vez US$ 200 mil. Se a combinação mais cara entregar mais de 1,87 vez mais trabalho útil e comparável, seu custo por unidade desse trabalho é menor. É uma ilustração da economia envolvida, não uma previsão. Uma comparação real precisa dos custos completos dos dois lados.

A ambição é transformar um desenvolvedor 10x num desenvolvedor 100x. Esses números descrevem o que quero perseguir, não um multiplicador de produtividade garantido. Eu esperaria que um engenheiro escolhido com cuidado e bem equipado superasse uma estratégia de contratação baseada em achar alguém mais barato e supor que a IA fornecerá o julgamento que falta, mas verificaria essa expectativa pelo trabalho entregue.

Nada disso torna desenvolvedores juniores descartáveis. Quero que aprendam ao lado de gente experiente, usando IA enquanto desenvolvem o conhecimento para questioná-la. O erro caro é remover seus mentores e atribuir a eles responsabilidades que ainda não estão preparados para assumir porque a gestão decidiu que um agente forneceria a experiência.

Uma organização para humanos e agentes

Esta é a combinação em torno da qual estou construindo com o Orgabot: humanos e agentes de IA ocupando papéis definidos numa organização, com fluxos de trabalho que especificam responsabilidades, permissões, verificações e aprovações. A ideia é tornar o modo de trabalhar da organização explícito o bastante para que o trabalho autônomo aconteça dentro de limites que signifiquem algo.

A distinção que me importa é entre aquilo sobre o que um agente pode raciocinar e aquilo que o software ao redor precisa impor. Planejamento e implementação flexíveis convivem com controles sobre acesso a ferramentas, aprovações obrigatórias, resultados de testes e evidência de auditoria. A exigência de obter aprovação não deveria ser uma sugestão num prompt que o agente possa reinterpretar.

Para uma mudança relevante em produção, o fluxo que quero começa com uma pessoa qualificada estabelecendo o objetivo e as restrições. Agentes podem investigar, propor abordagens, implementar a mudança e ajudar com testes e revisão. As pessoas responsáveis então avaliam a evidência adequada ao risco antes de a mudança aprovada seguir para produção.

Quero a aprovação atrelada à versão efetivamente revisada. Se a implementação mudar de forma relevante depois, ela deve passar de novo pela revisão necessária. Também quero um registro claro do pedido, do trabalho realizado, das verificações executadas, das decisões tomadas e do resultado do deploy.

É isso que projetar o Orgabot pensando em conformidade significa para mim: fazer das responsabilidades e das evidências parte do processo. Não significa instalar uma ferramenta e declarar a organização em conformidade. A organização ainda precisa estabelecer suas obrigações, configurar os controles adequados e demonstrar que eles funcionam.

A contribuição humana importa do começo ao fim. Alguém precisa reconhecer a necessidade de uma máquina de estados, contestar um algoritmo caro, proteger uma fronteira de privacidade, identificar um requisito regulatório aplicável ou explicar por que uma interface vai confundir as pessoas. Essas responsabilidades podem caber a vários profissionais experientes. Um organograma deveria deixar clara essa titularidade.

Como eu evitaria granadas de slop

Monte o time para a responsabilidade, não para a aprovação. Atribua o trabalho de consequência a alguém capaz de avaliar o resultado e continuar responsável por ele depois do deploy. Contrate por entendimento demonstrado, não apenas por um diploma, um currículo longo ou entusiasmo com o modelo mais recente. Dê a quem tem menos experiência supervisão e um caminho para desenvolver esse entendimento.

Defina o sucesso antes de gerar a solução. Escreva o comportamento de que você precisa, as restrições que não podem ser violadas e a evidência exigida para aceitar o trabalho. Inclua os casos de falha. Um agente produzir código e depois produzir testes que concordam com esse código não basta; a verificação precisa voltar aos requisitos originais.

Faça a revisão ser real e financie-a à altura. Reserve tempo para inspecionar mudanças, questionar premissas, testar integrações e conferir a experiência real do usuário. Use IA para apoiar essas atividades, mas não faça da aprovação de outro modelo a única base para confiar no resultado. A pessoa responsável precisa poder parar o processo sem ser tratada como obstáculo à produtividade.

Meça o trabalho inteiro. Conte o tempo gasto esclarecendo, gerando, revisando, consertando, publicando e dando suporte ao trabalho, junto com o custo das ferramentas. Compare isso com o resultado entregue. Uma tarefa não é mais eficiente porque uma pessoa terminou mais rápido enquanto três colegas absorveram a diferença.

Nada disso exige rejeitar a IA nem andar devagar de propósito. Exige ser honesto sobre o que “pronto” significa.

A gestão é dona das condições

Lütke tem razão em se opor a um trabalho que cria mais trabalho para outra pessoa. Minha objeção é tratar esse comportamento como separável do quadro de pessoal, dos incentivos e dos padrões ao redor. A estratégia de IA de uma empresa inclui quem usa as ferramentas, o que essas pessoas entendem e o que a gestão espera que elas verifiquem.

Entendo querer cortar custos de mão de obra. Eu buscaria isso por meio de melhores resultados por dólar, mesmo quando isso significar gastar mais com um engenheiro específico. Contrate por experiência demonstrada, pague o suficiente para disputá-la e ofereça as ferramentas e as condições de trabalho que fazem essa experiência valer.

Cortar a capacidade de avaliar o trabalho enquanto se amplia a capacidade de gerá-lo é um jeito muito eficiente de produzir granadas de slop. Você não consegue competir sem a ajuda da IA. Também não consegue competir produzindo slop de IA. A gestão é dona das condições que determinam qual dos dois resultados ela vai obter.