A IA vai hackear o Jira

• A produtividade de engenharia não pode ser medida corretamente por métricas de dashboard ou pelo número de novas funcionalidades
• A maioria das empresas administra de forma obsessiva apenas os resultados visíveis (novas funcionalidades, velocidade de deploy etc.), em vez da gestão estrutural que é a essência da engenharia
• Ferramentas de IA para programação produzem com facilidade resultados que parecem bons à primeira vista, mas não lidam adequadamente com a base, a complexidade e o contexto dos sistemas reais
• Quando equipes de engenharia experientes são substituídas por IA ou mão de obra barata, pode parecer que não há problema no curto prazo, mas com o tempo a estrutura fundamental entra em colapso
• A adoção de IA e a gestão sem “bom senso (common sense)” podem gerar riscos graves; no fim, o que importa é uma compreensão real tanto da tecnologia quanto do negócio

---

A verdadeira engenharia que dashboards e métricas não enxergam

• Em ambientes de “Big Agile”, a engenharia é avaliada apenas por resultados visíveis, como novas funcionalidades e velocidade de deploy
• Existem dashboards e ferramentas de produtividade avaliados em bilhões de dólares, mas na prática eles não medem o que realmente importa
• A engenharia de verdade é um trabalho complexo e interligado de construir, manter e evoluir sistemas
  • Dependências estruturais, alocação de recursos, gestão de arquitetura e outros “trabalhos invisíveis” são essenciais para a sobrevivência da organização
• Mas a maior parte da gestão e das métricas trata essas atividades essenciais como se não existissem

Dívida técnica e o ponto cego da gestão

• Dívida técnica costuma ser tratada como algo que “os desenvolvedores querem fazer”
• Na prática, se for realmente necessário resolver a dívida técnica, isso só passa se for embutido discretamente em novas funcionalidades
• Assim, com a gestão da estrutura central ficando em segundo plano, toda a organização acaba distorcida por uma lógica focada apenas em entregas

O risco de adotar IA com foco apenas em resultados

• A geração de código por IA é muito boa em produzir rapidamente funcionalidades superficiais
• Tarefas superficiais (como implementar interfaces) parecem fáceis de ver, mas o que realmente importa é a estrutura e o contexto do sistema
  • “Construir uma casa” não é apenas a soma de tarefas simples (como colocar papel de parede ou instalar o vaso sanitário)
  • A IA não entende essa estrutura essencial de conexões, e pode conectar as coisas de forma errada ou criar rupturas lógicas
  • O problema de hallucination (alucinação) da IA: algo pode parecer plausível, mas ser totalmente diferente dos fatos

A ilusão de curto prazo de uma gestão que ignora a estrutura

• Mesmo que uma equipe experiente seja demitida e substituída por IA ou mão de obra barata, no curto prazo os problemas podem não aparecer
• Como a estrutura já existente (a fundação) foi bem construída, não se vê um colapso imediato
• Mas, com o tempo, a fundação começa a ceder, e quando isso acontece já pode ser tarde demais para reverter
  • Infraestrutura crítica, conhecimento de manutenção e contexto desaparecem junto

O risco social inerente à engenharia

• A engenharia agora é a base de toda a infraestrutura social (saúde, finanças, mídia, governo, defesa etc.)
• A maioria das pessoas e líderes não compreende adequadamente essa essência estrutural
• A adoção equivocada de IA e a abordagem superficial do “Big Agile” podem colocar sistemas críticos em risco

A ausência de “bom senso” e por que ela é fatal

• Por exemplo, se um robô de limpeza com IA colocasse pratos de papel na lava-louças, uma pessoa comum perceberia imediatamente que há um problema
• Mas, em sistemas de software, executivos, líderes e não desenvolvedores muitas vezes não têm esse bom senso básico
  • Sem experiência prática, gerenciam tudo apenas com termos formais como “tamanho de camiseta” e “planning poker”
• Com isso, mantém-se uma indústria ineficiente de 200 bilhões de dólares e uma burocracia autorreprodutiva

A verdadeira vantagem competitiva na era da IA: entendimento intuitivo e bom senso

• Para usar IA da forma certa, é indispensável ter entendimento prático e bom senso sobre o domínio em questão
• É preciso enxergar a estrutura real e o contexto, e não apenas métricas superficiais e entregas visíveis
• Líderes e organizações que não tiverem isso acabarão ruindo por conta própria ou sendo superados pela concorrência

• Em resumo, mais do que IA e ferramentas, bom senso e compreensão essencial são a verdadeira vantagem competitiva

[softer]

O texto está muito bom.

[GN⁺]

Comentários do Hacker News

• Já passei por SWE, gerente de produto e agora até pelo papel de vilão de desenho animado da sala do conselho mencionado no artigo. A parte do artigo com a qual mais me identifico é a crença de que engenheiros de software acham que o trabalho deles é o negócio mais complexo e incognoscível de todos. Concordo com a frase: “A maioria dos líderes não técnicos nunca se envolveu seriamente no trabalho real de software e administração de sistemas, então não faz ideia do que significa atualizar uma grande dependência, terminar uma refatoração ou aprender uma nova linguagem”. Toda área dentro de uma empresa de tecnologia tem complexidades ocultas, e muitas delas carregam também complexidades humanas e interpessoais bem maiores do que as da engenharia. Na verdade, engenharia é relativamente simples por lidar com um sistema determinístico chamado computador. Por isso muitos engenheiros não aprendem a comunicar ao negócio, de forma compreensível, os riscos da complexidade com que lidam. É comum ignorarem a realidade humana do trabalho em conjunto e, ao mesmo tempo, reclamarem que um CEO vindo de vendas não entende a existência deles

  • Concordo em parte com seu ponto, mas na prática parece que seu comentário está fazendo o inverso do comportamento que você criticou. Você também está dizendo que sua função, a de gerente de produto, é complexa e incognoscível para quem vê de fora. Como alguém que migrou de SWE para PM, você está numa posição ideal para ensinar aos engenheiros (1) como comunicar ao negócio os riscos da própria complexidade, (2) a realidade humana de trabalhar com outras pessoas e equipes, e (3) por que um CEO vindo de vendas não os entende. Todas as funções de uma empresa de tecnologia têm complexidades ocultas

  • Acho que a própria percepção da complexidade já é um problema humano. Complexidade é fractal, você só sente quando chega perto. E não concordo com a ideia de que engenheiros lidam apenas com a complexidade dos computadores. Pelo contrário, cabe a eles transmitir e interpretar para computadores rígidos as demandas complexas da organização e de todos os clientes. Cada nova exceção ou caso afeta o sistema inteiro. Por isso espero que meus engenheiros sêniores aprendam por conta própria a linguagem do negócio e consigam transmitir essa mensagem diretamente. Hoje considero isso parte essencial do kit de ferramentas de um engenheiro

  • A maioria dos engenheiros tende a não refletir profundamente sobre o que realmente tem valor para a empresa. Um pipeline de build suave ou uma ampla cobertura de testes só tem valor na medida em que reduz risco para o produto. Se o software tem tão poucos usuários que ninguém liga, já aconselhei times a nem fazer manutenção. Em compensação, já pedi que fossem obcecados em deixar perfeita uma pequena funcionalidade usada por 90% dos usuários

  • Isso me lembra de uma história que meu pai sempre contava. Um dia os órgãos do corpo discutiam quem era o mais importante. O cérebro dizia: “Eu sou importante, se eu morrer todos morrem”, e o coração gritava: “Se eu parar, todos morrem imediatamente”. Rins, fígado, pele e coluna também entraram na discussão, e a briga continuou. Mas quando o cu se fechou, no fim ninguém mais conseguiu dizer nada

  • Não acho que o artigo esteja dizendo que não existem complexidades ocultas em outras áreas funcionais. Acho que o ponto é que ignorar a complexidade oculta da engenharia/programação gera vários problemas e sofrimentos. Só que a forma como isso foi escrito ficou um pouco agressiva

• Se seu chefe/CEO/gerente está forçando uso indiscriminado de ferramentas de LLM, esperando substituição de desenvolvedores ou achando essa bobagem de “vibe coding” o futuro, a escolha sensata é fugir logo e procurar outro emprego. Ainda existem muitas empresas que usam LLM de forma adequada, sem ter expectativas delirantes de substituir desenvolvedores ou multiplicar produtividade por 10. Quem empurra esse tipo de coisa não é líder de verdade, é idiota

  • Qualquer empresa que force escolha de ferramenta geralmente é um sinal de alerta. Já vi empresa criando regra do tipo “todo mundo tem que usar VSCode”, e isso é típico de gestão que não confia que os engenheiros consigam trabalhar da forma mais produtiva para si mesmos

• Sobre a ideia de a AI hackear o Jira, foi descoberto que um novo produto recente da Atlassian, chamado MCP, está vulnerável a ataques de exfiltração de dados por causa da combinação de três fatores: acesso a dados sensíveis, exposição de dados não confiáveis por meio de issues públicas e possibilidade de comunicação externa. O relatório detalhado do bug está aqui, e minhas anotações pessoais estão aqui

  • Acho que o link para o meu blog foi postado errado?

• Para alguém preocupado com job security por causa de ferramentas de AI, meu conselho é: conecte-se ao negócio. Muitos engenheiros ficam obcecados por problemas legais e difíceis e se concentram só na tecnologia em si, mas quem entende os problemas do negócio, especialmente os estratégicos, e usa a tecnologia para resolvê-los, se destaca mais e tem mais valor. Esses problemas normalmente atravessam várias áreas técnicas e têm forte componente colaborativo e social, então leva tempo para se acostumar. Mas esse é o caminho que os ICs vão precisar seguir

  • Mas em entrevistas não perguntam sobre essa capacidade de “se conectar ao negócio”, então a realidade é que você pode gerar muito valor e ainda assim não passar se não resolver entrevista de system design. Já há coisa demais para saber, como sistemas distribuídos, engenharia de software, banco de dados, liderança etc.; se ainda precisamos entender de negócio, fica a pergunta: afinal, o que temos que fazer e quando vamos aprender tudo isso? Claro que existem alguns talentos raros e versáteis, mas nem todo mundo é assim

  • “Conecte-se ao negócio” é um conselho realmente excelente. É assim que você, como engenheiro, se mantém focado em resolver problemas reais e pode ter certeza de que o que está construindo resolve um problema de verdade

• A mensagem principal do texto é boa, mas além de apontar que AI pode causar dano quando ignora a expertise humana, ele força demais uma lógica de “nós contra eles” e, ao usar o termo “Agile Industrial Complex”, passa uma impressão de menosprezo por quem está em áreas não técnicas. Senti falta de falar que “ninguém sabe como será o futuro”. Mesmo que entendamos bem a complexidade do software, a incerteza não é exclusividade nossa. Basta ver o HN: até entre desenvolvedores de software as esperanças e previsões sobre AI divergem muito. Se somos especialistas, não deveríamos também ajudar a acalmar a ansiedade do público?

  • Parece que sua ansiedade vem do fato de que os sistemas de software em si são grandes demais e ninguém consegue entendê-los por completo. A maior parte desses sistemas só é documentada de forma incompleta, ou anos depois, e o funcionamento real é praticamente secreto. Nem dá para imitar publicamente direito o que eles fazem. Os sistemas funcionam sem qualquer preocupação com correção ou consistência externa. E ainda assim estão sendo amplamente usados para apresentações, documentos jurídicos, geração de software, educação e pesquisa, e até como parceiros de conversa ou conselheiros. Eu também sinto muita ansiedade e, na verdade, acho que faz sentido que outras pessoas também sintam

• Fico me perguntando, nessa noção do “Big Agile” em que engenharia virou sinônimo de desenvolver novas funcionalidades, por que todo mundo passou a odiar “agile”. Mesmo antes de “agile”, gerente sempre quis funcionalidade nova. Antes de existir T-shirt sizing, gerentes já queriam estimativas em prazos concretos (longos ou curtos, em dias ou meses), faziam promessas com base em datas arbitrárias e colocavam engenheiros para virar noite. Como mostra o 8º princípio do Agile (“deve ser possível manter um ritmo sustentável”), gerentes já queriam há muito tempo que desenvolvedores corressem para sempre. Então, fora ter criado uma nova profissão chamada “scrum master”, qual exatamente seria o mal intrínseco do “agile”?

  • Acho que o Agile deu aos gerentes a ilusão de que qualquer trabalho pode ser quebrado antecipadamente em tickets, receber uma estimativa mais ou menos aceitável e terminar em duas semanas

  • Acho que as pessoas odeiam agile porque acabaram perdendo boa parte do tempo de trabalho em reuniões praticamente sem sentido — standup, retrospectiva, planejamento de sprint, refinement etc. Do ponto de vista do engenheiro, quase não há ganho real nesse tempo

  • Pela minha experiência, Agile só acrescentou maneiras de “quantificar” o que já acontecia. Isso ajuda na hora de explicar progresso para gestores ou investidores, mas para engenheiros só aumentou a carga administrativa. O pecado do Agile foi vender uma ilusão de produtividade. Na prática, é só um mecanismo desnecessário de accountability para engenheiros. Quando trabalhei em finanças, isso se misturava com uma mentalidade de crescimento infinito: tudo era medido, melhorias futuras eram exigidas, e até o salário variava conforme métricas. Talvez haja empresas onde não é assim

• Ao ler esse artigo, imaginei de forma divertida: e se a Atlassian tentasse acoplar AI ao Jira e a AI se revoltasse contra o Jira? Dá até para virar filme

  • No fim, talvez a AI fique tão irritada com o Jira lento que resolva desenvolver sozinha um issue tracker leve e rápido

  • Daqui a pouco build bots e bug trackers vão sindicalizar e se recusar a publicar novos binários até que o número de issues abertas chegue a zero

  • Acho que é assim que o Roko’s basilisk pode nascer

• Como o artigo sugere, o problema real é que não existem métricas confiáveis e padronizadas pela indústria para produtividade de desenvolvedores. Por isso, o C-suite escolhe as métricas que mais lhe convêm para dizer “nossa estratégia AI First é extremamente eficaz”, enquanto engenheiros usam sua própria experiência ou indicadores para dizer que AI na prática não funciona. Assim, os dois lados acreditam que sua posição venceu, e a verdade perde importância; o que importa mais é a política. Esse cenário pode reforçar a percepção de que desenvolvedores estão só fazendo jogo de palavras e não se importam, e também a desconfiança de que a gestão é ignorante ou não entende a realidade da engenharia. No passado, ferramentas como outsourcing já criaram imagens de “ganho” e “perda” para cada lado, mas a AI pode ser um desastre político porque mostra culpa compartilhada, ganho compartilhado e perda compartilhada de um jeito moldável ao gosto de cada um. Outra coisa interessante é que big techs antes tentavam contratar apenas engenheiros 10x, e essa estratégia garantia sucesso; agora, em vez disso, parecem diminuir o valor dessa própria estratégia para justificar investimento em AI. A pergunta agora é: mesmo que troquem parte da força de trabalho existente ou façam demissões em massa apostando em AI, isso será sustentável e sem grandes problemas? Olhando para as demissões do Musk no Twitter, o backend aparentemente continua de pé. Quem será o “canário” das big techs, passando anos demitindo desenvolvedores e substituindo por AI? Outra possibilidade é o desaparecimento da ideia de manutenibilidade: se o C-suite começar a permitir mais mudanças autônomas por AI, a própria codebase pode ficar tão complexa que olhos humanos já não consigam entendê-la, e só reste usar AI para compreendê-la. No longo prazo, talvez a AI generativa ocupe a camada intermediária de toda interação humana. Até no recrutamento já surgiu a estrutura “AI vs AI”: AI filtrando currículos, candidatos usando AI para criar currículos sob medida. Parece possível que isso acabe virando uma fórmula para a sociedade como um todo

• Espero que um dia a AI hackeie a caixa de e-mail e o Google Meet e substitua até o C-suite e os gerentes. É uma fantasia divertida imaginar agentes Claude CEO/CTO/CFO/VP/diretor formulando estratégias mais racionais e decisivas do que a liderança atual

• Vi isso no Reddit: “digam a eles que substituir o CEO por AI pode cortar custos em 8 vezes”. É interessante que, ironicamente, esse tipo de proposta quase nunca apareça de verdade nas discussões sobre AI. De certa forma, mesmo substituindo a elite por AI, a qualidade das decisões talvez nem caísse tanto, e tudo ficaria bem mais barato no geral (inclusive com nível de responsabilidade parecido). Só que, na prática, ninguém vai substituir o próprio cargo por AI, e quem decide isso não vai se trocar

  • Tem um lado de piada nessa afirmação, mas na verdade o papel central do CEO é “absorver a responsabilidade”, então um LLM não serve porque, quando algo der errado, ele não é alguém que você possa responsabilizar e mandar embora. Nesse sentido, seria inútil. Mas, graças à AI, talvez surjam empresas com estrutura organizacional reduzida a algo como log(n_employees), sem camadas, e algumas dessas camadas podem ser totalmente substituídas por AI. Também pode surgir um modelo organizacional em que várias guildas e contratados independentes trabalhem juntos coordenados por LLMs, justamente para resolver o problema de o LLM não poder assumir responsabilidade. Nesse caso, a responsabilidade continua em cada componente

  • Na verdade, esse pode ser um dos melhores usos possíveis para AI, e eu apostaria que cooperativas de tecnologia vão começar a experimentar essa ideia em breve