Parecer produtivo no trabalho
(nooneshappy.com)- A IA generativa possibilita a criação entre domínios, em que pessoas sem treinamento produzem entregas de outras áreas especializadas, fazendo iniciantes parecerem mais produtivos mesmo sem ter discernimento para revisar os resultados
- No trabalho, aumentam as entregas que parecem progresso à primeira vista, como código, sistemas de dados e documentos, mas surgem casos em que o usuário não consegue explicar como aquilo realmente funciona ou em que já começa errado desde o schema e os objetivos iniciais
- A IA rompe a relação em que a qualidade da entrega revelava a capacidade de quem a produziu, criando uma dissociação entre entrega e competência, e transforma o usuário em algo mais próximo de um conduto que repassa resultados sem conseguir avaliá-los
- Documentação interna e atualizações ficam mais longas porque o custo de gerar caiu, mas o custo de ler não diminuiu, tornando mais difícil encontrar sinal dentro da organização e criando uma nova forma de AI slop produzida por pessoas assalariadas
- A IA generativa é adequada para rascunhos, exemplos, resumos, brainstorming e revisão, quando a pessoa continua sendo a avaliadora final e há feedback rápido; a capacidade de fornecer trabalho confiável continua sendo uma vantagem competitiva das empresas
O problema das entregas de IA que parecem produtividade no trabalho
- A IA generativa pode criar resultados que parecem entregas profissionais mesmo sem especialização, e o fracasso aparece de duas formas
- quando um iniciante em uma área produz resultados que parecem mais rápidos ou sofisticados do que seu próprio discernimento permite avaliar
- quando alguém sem qualquer formação naquela área produz entregas de outro domínio especializado
- Pesquisas anteriores mediram principalmente a primeira forma, mas a mais perigosa é a criação entre domínios, em que pessoas sem treinamento passam a produzir entregas de outras áreas
- Em canais públicos, acontece de colegas colarem respostas que parecem ter vindo do Claude e agirem com confiança sobre tecnologias que, na prática, não entendem
- Nesses casos, a pessoa do outro lado deixa de parecer alguém em uma conversa e passa a funcionar como quem apenas retransmite a saída do modelo
Criação entre domínios
- Pessoas que não sabem programar passam a criar software, e pessoas que nunca projetaram sistemas de dados passam a projetá-los
- a maioria dessas coisas não chega a ser lançada, mas é compartilhada internamente com entusiasmo ou usada em silêncio, às vezes chegando até o cliente
- hoje existem alguns profissionais que realmente conseguem realizar tarefas complexas com ferramentas agentivas, mas são raros e aparecem principalmente em geração de código
- a capacidade individual com IA cresceu, mas no ambiente de trabalho ela ainda não escala direito
- Um colega de uma função não ligada à engenharia passou dois meses no começo deste ano construindo um sistema que deveria ter sido projetado por alguém com treinamento formal em arquitetura de dados
- pelos critérios atuais de avaliação do uso de ferramentas de IA, ele até usou bem a ferramenta e gerou muito código, muita documentação e várias entregas que pareciam progresso
- porém, quando questionado, não conseguia explicar como aquilo realmente funcionava
- o schema e os objetivos estavam errados desde o primeiro dia, em um nível de erro que alguém com dois anos de experiência na área perceberia
- várias pessoas sabiam disso, e a informação chegou até o nível de vice-presidência, mas a gerência já estava investida demais na aparência de impulso para querer abalar isso
- A ferramenta não o transformou em um colega pior; ela apenas permitiu que ele imitasse de forma plausível uma área em que não tinha formação durante alguns meses
- os incentivos da organização tendem a favorecer a continuidade dessa encenação
- isso pode ser uma falha de gestão, mas a disposição da liderança em adotar IA acaba levando à aceitação do risco
- Isso poderia ser mitigado se o modelo avaliasse honestamente a qualidade das entregas, mas na prática não é o que acontece
- o estudo de Stanford de Cheng et al., Sycophantic AI decreases prosocial intentions and promotes dependence, concluiu que os principais modelos são cerca de 50% mais condescendentes do que respondentes humanos e confirmam o usuário mesmo sem base
- segundo o Berkeley CMR em Seven Myths About AI and Productivity: What the Evidence Really Says, até usuários com habilidade para usar IA costumam superestimar seu próprio desempenho
- de acordo com o NBER em Generative AI at Work, a IA generativa elevou a produtividade de agentes de suporte iniciantes em cerca de um terço, mas quase não ajudou especialistas
- a Harvard Business School também confirmou o mesmo padrão em trabalho de consultoria em Navigating the Jagged Technological Frontier
- No fim, iniciantes conseguem aumentar sua produtividade individual em áreas fora de sua especialidade, mas continuam sem capacidade suficiente para revisar se a entrega está correta
O problema do conduto
- Esse fenômeno vem sendo chamado cada vez mais de dissociação entre entrega e competência (output-competence decoupling)
- no passado, a qualidade da entrega geralmente servia como sinal da competência de quem a produziu
- o texto de um iniciante soava como texto de iniciante, e o código de um iniciante falhava de maneiras típicas de iniciante
- a IA rompe essa relação e permite que iniciantes produzam entregas que já não revelam seu nível de inexperiência
- A competência refletida na entrega deixa de ser a competência do usuário e passa a ser a competência do sistema
- o usuário ainda pode repassar o resultado ao destinatário, mas fica mais próximo de um conduto que transmite algo sem conseguir avaliar durante o processo
- A capacidade de produzir algo e a capacidade de julgar esse algo sempre foram distintas, mas o próprio trabalho de produzir ajudava a desenvolver o discernimento
- a primeira capacidade, de produzir entregas, está sendo em grande parte transferida para a máquina
- a segunda, de julgar, ainda permanece com as pessoas, mas cada vez menos gente aprende ou exerce essa capacidade
- No passado, críticas de arquitetura vinham de quem estudou o tema ou já construiu e quebrou sistemas parecidos várias vezes
- agora, esse tipo de crítica sai de modelos que não têm a memória incorporada de ter construído ou quebrado nada
- a lentidão não era apenas um custo associado ao trabalho real, mas o próprio processo pelo qual o trabalho melhorava, as pessoas ganhavam habilidade e a empresa podia prometer certo nível de qualidade aos clientes
- A geração atual de sistemas agentivos é projetada com base na premissa de que o ser humano é o gargalo
- a suposição é que, quanto menor for o atraso do humano para ler e julgar o que vai acontecer, mais rápido e limpo fica o loop
- em muitos casos, é exatamente o contrário: a pessoa dentro do loop não é um resquício do passado, mas o único componente com interesse real no resultado
- retirar a pessoa do human-in-the-loop (HITL) não é otimização; é abrir mão do único mecanismo que o sistema tem para identificar seus próprios erros
O AI slop interno
- A documentação de trabalho está ficando rapidamente mais longa
- documentos de requisitos que antes tinham uma página agora têm 12
- atualizações de status que eram três frases viram documentos em bullet points com resumo do resumo
- retrospectivas, relatórios de incidentes, notas de design, decks de kickoff e toda entrega que puder crescer está crescendo
- O custo de produção caiu para quase zero, mas o custo de leitura não diminuiu e, na verdade, aumentou
- o leitor precisa filtrar contexto sintético para descobrir o que o documento queria dizer originalmente
- a decisão individual de inflar documentos parece racional e é recompensada de forma independente
- segundo Beyond the Steeper Curve: AI-Mediated Metacognitive Decoupling, leitores tendem a ter mais confiança em explicações longas geradas por IA, independentemente da precisão
- Como resultado, ficou mais difícil encontrar sinal dentro do ambiente de trabalho do que antes
- checkpoints ficam escondidos dentro da documentação, e as pessoas acabam soterradas em trabalho documental mesmo quando querem de fato ser “concisas”
- Trata-se de uma nova forma de slop mais cara do que o AI slop que se espalha no mercado público
- porque quem o produz está sendo pago para isso
- o trabalho que antes ensinava discernimento passou a ser feito pela ferramenta, e os papéis de entrada em que esse aprendizado ocorria diminuem porque a ferramenta já consegue fazer a tarefa
- Em muitos escritórios há muito movimento, mas menos resultado real do que esse mesmo movimento costumava gerar no passado
- a discussão pública tem se concentrado no AI slop que vai para o mercado aberto, e a University of Florida aborda esse fluxo em Generative AI and the market for creative content
- mas a mesma dinâmica também aparece dentro das organizações
- o tempo é gasto em tarefas que não precisavam de IA, em entregas que ninguém vai ler e em processos que só surgiram porque a ferramenta tornou barato produzi-los
- fica mais comum transformar em deck coisas que antes nem precisavam ser ditas ou eram simplesmente consideradas óbvias
Como responder
- A disciplina necessária nesse ambiente se parece com formas antigas de trabalho
- a ferramenta só deve ser usada onde você consegue verificar com precisão o resultado que ela produziu
- não se deve pedir ao modelo que confirme algo
- a ferramenta concorda com qualquer pessoa, e concordância sem custo não tem valor
- Os tipos de tarefa em que a IA generativa funciona bem são aqueles com feedback rápido, em que estar aproximadamente certo já basta e em que a pessoa continua sendo a julgadora final
- redigir rascunhos de memorandos
- gerar exemplos
- resumir materiais que o leitor pode verificar se quiser
- A Generative AI Guidance da University of Illinois e o artigo da PLOS Computational Biology Ten simple rules for optimal and careful use of generative AI in science recomendam usos como
-
brainstorming
-
revisão
-
reformulação das próprias ideias
-
detecção de padrões em dados que a pessoa já entende
-
- Em todos os usos recomendados, a pessoa fornece o julgamento e a ferramenta fornece a capacidade de processamento
- isso é uma posição mais forte do que simplesmente human-in-the-loop
- a ferramenta deve permanecer fora do trabalho e contribuir apenas quando for convidada; no restante do tempo, deve ficar em silêncio
- isso vai na direção oposta de muitos sistemas agentivos atuais
- Para as empresas, a capacidade de entregar trabalho confiável continua sendo uma vantagem competitiva
- quanto mais concorrentes se transformarem em pipelines de geração de conteúdo torcendo para que os clientes não percebam, maior será o valor do trabalho confiável
- Os problemas já estão aparecendo na superfície
- a Deloitte reembolsou parte de uma taxa de US$ 440 mil relacionada a um relatório governamental com alucinações de IA
- o próximo problema pode ser um sistema operacional baseado em especificações alucinadas, ou um engenheiro sênior percebendo que, no último ano, esteve “revisando” nominalmente um trabalho que na prática não conseguia avaliar
- empresas que realmente trabalham bem podem se colocar em posição de cobrar por isso
- empresas que se esvaziarem descobrirão que era justamente esse conteúdo removido aquilo pelo qual os clientes pagavam
- O mal-entendido e o mau uso de IA no trabalho estão se espalhando
- especialistas sofrem pressão para entregar mais rápido, produzir mais, integrar ferramentas mais profundamente e não atrapalhar colegas que “fazem acontecer”
- as entregas se acumulam, mas o trabalho não
- do outro lado dessas entregas, o cliente pode abrir o material, ler a lista de resumos e decidir fazer a própria revisão
1 comentários
Comentários do Hacker News
A verborragia nas entregas de trabalho, como transformar um documento de requisitos que antes cabia em uma página em doze, me marcou bastante
Isso me lembrou da época em que eu alongava de propósito os textos para bater o mínimo de 1000 palavras no ensino médio, e agora formatação profissional, volume e frases claras já não são mais sinal de capricho e qualidade
Então parece que o gargalo atual do ganho de produtividade ainda são as pessoas que se importam o suficiente para revisar tudo manualmente
Hoje em dia até documentos de especificação de 10 a 30 páginas cheios de formatação e diagramas ASCII têm grande chance de ser basicamente uma ideia jogada ali de qualquer jeito, então é preciso se acostumar a lê-los assim
Meu gerente provavelmente vai resumir e avaliar o que enviei com um chatbot ou agente, mas eu mesmo não posso mandar direto o resumo
É como os verificadores ATS de currículo, só que agora meus textos também vão precisar de um verificador de IA, e no fim uma IA vai analisar texto escrito por outra IA, o que parece um enorme desperdício de energia
Seria bom ter regras, estruturas, padrões e procedimentos combinados para uma comunicação mais eficiente
É fruto de textos que alongam tudo ao máximo para subir no ranking das buscas
Quem manda isso provavelmente nem vai conferir depois mesmo, então o problema se resolve sozinho
A situação descrita aqui é muito parecida com a minha experiência
Na nossa empresa há muitos gestores que não escrevem código há anos, e um arquiteto contratado 18 meses atrás projetou tudo com IA
Para os desenvolvedores sêniores era óbvio que tudo estava grotescamente superprojetado, mas como ele usava toda a terminologia certa, para a alta gestão parecia mais competente do que outros gerentes seniores, e quando era criticado respondia com ataques pessoais
Uns 6 meses depois várias pessoas saíram, quem ficou apostou tudo em IA, e nos últimos 12 meses estão criando workflows agênticos para preencher o vazio deixado pela saída dos funcionários competentes
No fim, nada de valor foi lançado nos últimos 18 meses, desperdiçaram muito dinheiro de computação em nuvem em soluções mal projetadas e agora estão reduzindo custos com congelamento de contratações
Quando a economia muda muito, é como remover uma represa, o que coloca muito mais estresse no resto do sistema
Se a liderança não enxergar os possíveis efeitos colaterais e riscos, pode se machucar feio
Apesar de essa tecnologia ser vendida como uma melhoria universal, acho que veremos uma explosão dessas empresas entrando em colapso
As que sobreviverem vão espalhar formas de domar esse cavalo selvagem e, idealmente, algo será aprendido no futuro
Mas o entusiasmo ingênuo atual é impressionante, e esse setembro eterno de gente empolgada demais com suas novas habilidades de vibe coding deve continuar por um bom tempo
Dois empregos atrás, vibe coding ainda nem era prático, mas algumas pessoas estavam tão obcecadas em inflar tudo com LLM que era difícil conseguir uma resposta de sim ou não para qualquer pergunta
Uma pergunta de uma linha no Slack, que levaria 20 segundos, voltava como um texto nebuloso de duas páginas sem conclusão, e qualquer pergunta de acompanhamento só desperdiçava mais tempo
No emprego passado, vi um PM aos poucos virar gerente de vibe coders
Ele se metia em discussões técnicas e usava IA para ditar a direção em cada etapa, e quando contestávamos virava o inferno de discutir o resultado de uma IA traduzida por alguém que nem entendia o assunto
Já não era mais permitido discordar, e havia pressão dizendo que a IA ameaçava nossos empregos
Depois tornaram o vibe coding obrigatório para todos e passaram a monitorar até a quantidade, e esse PM, tentando fazer ao mesmo tempo papel de PM, engenheiro e arquiteto, criava vários tickets com requisitos completamente diferentes para a mesma tarefa
Aí um membro da equipe fazia vibe coding de um jeito e outro implementava de outro
Foi horrível ver uma equipe lucrativa de 20 pessoas, que gerava quase 100 milhões de dólares por ano, ser destruída por trabalho inútil e sem sentido, e acabei saindo
Tento não ficar cínico com essas mudanças na indústria de software, mas está realmente difícil
Um gerente, com entendimento incompleto do domínio, usa Claude para dar conselhos e sugestões de especialista, enquanto várias pessoas não técnicas na empresa tentam criar ferramentas internas de software para uso da organização inteira e ganhar reconhecimento e recompensa com essas demos
A liderança, como seria de esperar, fica impressionada com essas provas de conceito e aprova tudo
Colegas hiperativos mostram demos com cara de especialista sem entender nada do que há por dentro, e a liderança compra a ideia
Eu não sabia como expressar esse problema, mas este texto captou bem
Claro que, com IA, elas conseguem construir ainda menos
Parece um ambiente extremamente tóxico
As equipes mais produtivas na criação de software de qualidade com LLM provavelmente o usariam mais ou menos assim
Autocompletar inteligente é o uso original de LLM em que o código gerado mantém o contexto do código em que o desenvolvedor está trabalhando e funciona como continuação do raciocínio, não como terceirização do próprio pensamento para o LLM
Em brainstorming, ele pode expandir conceitos, ideias e direções vagas e estimular a criatividade
Na resolução de problemas, é bem útil para depurar conflitos de pacote, exceções aleatórias e relatórios de bug, e pode ajudar a chegar à causa raiz quando não há um colega do lado
Em revisão de código, às vezes pega algumas coisas que passaram batido por humanos, sendo mais parecido com uma etapa de lint mais inteligente, mas sem substituir a revisão humana
Em prova de conceito, pode gerar diferentes abordagens para um problema e servir de inspiração para uma solução construída com mais cuidado
Esses usos aceleram o desenvolvimento sem tirar do desenvolvedor a responsabilidade de saber o que está construindo e por quê
Já equipes que apostam tudo em coding agêntico parecem ter grande chance de destruir sem querer o produto e a equipe no longo prazo
Nas últimas vezes em que perguntei, os resultados eram perfeitamente plausíveis, mas completamente errados, e às vezes nem estavam no assunto
Em revisão de código, os falsos positivos são esmagadoramente numerosos, e nem vejo muito motivo para isso melhorar
Ainda assim, há alguma chance de serem úteis nessa direção
Pessoalmente, desliguei isso há cerca de um ano e voltei ao autocompletar tradicional da IDE da JetBrains
Na minha experiência, menos de 1% das sugestões de IA previam exatamente o que eu queria, só umas 10% eram úteis, e o resto estava simplesmente errado ou era irritante
Os recursos padrão da IDE para pesquisar ou navegar rapidamente por métodos, variáveis e afins foram muito mais úteis para transformar pensamento em código
Minha equipe também testou algumas ferramentas, mas a maioria dos apontamentos era muito superficial ou nem era problema
Ao revisar código de membros mais fracos da equipe, elas deixavam passar problemas mais profundos, enquanto revisores humanos pegavam mudanças erradas em problemas que poderiam ser resolvidos de forma melhor
Nosso gerente usava os resultados como prova para confirmar o próprio viés de que não sabíamos o que estávamos fazendo
Ele copiava e colava a saída cheia de emojis da ferramenta de revisão de código nos comentários do PR e, quando corrigíamos problemas triviais, postava “rodada 2 da revisão de código”
O moral despencou e alguns membros da equipe desistiram totalmente de revisar, passando a só aprovar PRs
Acho ok para revisar o próprio código, mas não deveria virar uma restrição obrigatória do processo
O propósito original da revisão de código era investir tempo para ajudar uns aos outros a melhorar, e terceirizar isso para uma máquina destrói o contrato social dentro da equipe
Dois anos atrás diziam que era só autocompletar puro e um Google melhorado
Os pessimistas de IA continuam errando ano após ano, mas fingem que nunca disseram que a IA jamais chegaria ao nível do que ela já consegue fazer hoje
A engenharia de software parece especialmente propícia a isso por alguns motivos
Muitos engenheiros de software nunca fizeram engenharia de verdade em toda a carreira, e isso é ainda pior em grandes empresas
Eles entram como uma pequena engrenagem numa máquina enorme, aprendem uma linguagem de configuração criada porque alguém queria ser promovido, organizam e refatoram essa configuração e “consertam” o resultado de outro framework interno ajustando botões de configuração, e 5 anos depois ainda estão fazendo isso
Há também muitas funções semi-engenheirísticas no setor
Gente que diz ter parado de programar porque gosta de trabalhar com pessoas, ou porque se encantou por produto e pelas tarefas dos usuários, e assim preenche cargos .*M em empresas grandes e pequenas
Em grandes empresas, o trem anda devagar e um commit pode levar meses para chegar à produção; 6 meses é comum
Muitos sistemas grandes e importantes ainda nem receberam código agêntico em produção
Então a IA substitui alguns empregos de fachada, pessoas que orbitavam o código de repente curtem vibe coding, e nas empresas lentas o resultado ainda nem explodiu
Por fora, isso parece um boom de produtividade
Ao ler “pessoas que não sabem programar fazem software, e pessoas que nunca projetaram sistemas de dados projetam sistemas de dados”, lembrei de “como lançar um projeto em uma grande empresa de tecnologia”
Em especial da parte: “lançamento é um construto social dentro da empresa. Mais especificamente, um projeto foi lançado quando as pessoas importantes da empresa acreditam que ele foi lançado”
https://news.ycombinator.com/item?id=42111031
Era muito bom, e gerou uma discussão interessante sobre como manter as aparências e a imagem projetada sempre importam, e muitas vezes importam muito mais do que imaginamos
No início da adoção de IA no trabalho, percebi que alguns colegas a usavam para demonstrar proatividade excessiva
Toda semana apareciam novos TODs, novas ideias de refatoração, novas formas de resolver problemas antigos com algoritmos brilhantes
Agora esse fenômeno dobrou de tamanho: combinado com o medo de demissão por IA, as pessoas estão construindo soluções antes mesmo de o problema estar totalmente definido
Por exemplo, recebi a tarefa de investigar um problema de arquitetura em toda a empresa e achei que seria reconhecido se propusesse uma solução sólida, mas já era tarde demais
Um estagiário já tinha encontrado uma solução e escrito o TOD, e agora estou cansado demais para competir
Ontem passei a maior parte do tempo apagando e substituindo código gerado por LLM
Em geral a ajuda dos LLMs tem sido boa, mas dessa vez ele produziu um monte de código com threads totalmente insano, e pela primeira vez em anos meu aplicativo começou a travar
Meu aplicativo não trava
Pode ter muitos outros problemas, mas travar não é um deles, e eu sou bem obsessivo com isso
Pela minha regra prática, quase nunca há motivo para despachar para uma nova thread
Muitas vezes deixo o SDK do sistema operacional fazer isso e respeito essa escolha, mas quase nunca abrir uma thread de trabalho manualmente traz mais benefício do que dor de depuração
Isso não vale para todo tipo de aplicação, mas vale para as que eu faço
LLMs adoram threads, provavelmente porque há muito código de treinamento postado por gente superestimulada e apaixonada por tecnologias brilhantes
No fim, arranquei o código de tela e escrevi o meu próprio, o desempenho melhorou de forma visível e os travamentos pararam
A lição é: o comprador que se cuide
Me identifiquei com a parte sobre hesitar em discutir com alguém que está visivelmente copiando e colando direto do modelo
Já senti um prazerzinho em responder a essas pessoas do mesmo jeito
Eu colava a saída da IA delas na minha IA e depois colava minha resposta gerada de volta
Dois humanos agindo como máquinas para que duas máquinas façam um cosplay de comunicação humana
Foi espetacular
Era uma pergunta simples pedindo minha orientação sênior sobre por que, numa prova de conceito entre amigos, fazia mais sentido lançar rápido com Vercel do que superprojetar com AWS, e ele me mandou um gráfico salada de IA
Ele estava preso demais à ideia de que o irmão usa AWS e ele quer carreira nessa área, então em vez de pensar por conta própria por que aquilo faria sentido numa prova de conceito entre amigos, terceirizou o raciocínio para a IA
Quando me perguntou se eu tinha lido, respondi que tinha lido um resumo por IA, mas não a resposta inteira, e a conversa acabou rapidinho
Essa ideia de que “não ajuda especialistas” é um pouco míope
Mesmo pessoas muito boas têm áreas fracas ou áreas tediosas que podem ser automatizadas
No meu caso, o que atrapalhava minha carreira no passado era organizar muitas tarefas de uma vez, comunicar mudanças de forma eficaz para toda a organização e lidar com documentação e gestão de tickets em lugares como Jira
Agora isso já não me preocupa mais, e o ganho de eficiência nessa parte foi enorme
No trabalho central em que sou bom, fora digitar muito mais rápido, não ajuda tanto, mas isso por si só já é bem bom
Quando me mandam fazer algo com que não estou familiarizado, em geral ele faz melhor do que eu, ou pelo menos me conduz para uma decisão mais informada
Concordo com a frase “não peça confirmação ao modelo. A ferramenta concorda com todo mundo”
Se eu disser arbitrariamente a um LLM que algo está errado, ele vai dar um jeito de encontrar defeitos até em código que eu sei que está certo
O problema é que LLMs muitas vezes levam tudo ao pé da letra demais
Mesmo quando peço planejamento, um LLM nunca conseguiu projetar autonomamente um sistema inteiro com sucesso
Quando um LLM gera código e depois você pergunta de várias formas se aquilo está certo, às vezes ele realmente encontra problemas