Enfim, resolvi dar uma pausa na escrita do livro para escrever sobre um tema que, como muitos que acompanham as engineeringsessions já perceberam, me incomoda bastante.
DISCLAIMER: SEMPRE enfatizo que as críticas não são à tecnologia. Tirando o lado óbvio dos prejuízos ao meio-ambiente e à saúde mental ocasionados pelo hype de LLM.
É ÉLE-ÉLE-EME, nada de botar a culpa na conta da AI, que por sinal é uma área muito mais abrangente do que o hype vende.
Sem falar na carga pesada de propaganda do tipo "comprem meu produto", "façam meu treinamento", "assinem meu serviço" coisas que tentam deturpar (até) os próprios conceitos que fazem parte do núcleo base da tecnologia que tá sendo empurrada em nossa direção pelo hype.
DISCLAIMER 2: A Stack HOMOLOGADA do seu trabalho é(ou ao menos deveria ser) de utilização OBRIGATÓRIA do profissional de T.I. que faz parte dos times técnicos.
Logo, se vc veio aqui "se queixar que o Carlos tá a incentivar a não utilização de ferramentas de LLM no trabalho" pode dar meia-volta.
Não sou "hater de AI", aliás, nem acredito que esta persona exista no mundo profissional real.
Pois se não tem como evitarmos a utilização, não existe essa pessoa que vai chegar com os gestores e dizer "ME RECUSO A USAR!".
Cada um usa o que bem entender, traça a estratégia que achar mas adequada para sua própria vida profissional/carreira, ninguém precisa de "babá de tecnologia/stack" e cada um sabe aonde o calo aperta.
Apesar disso, não utilizar no trabalho ferramentas que não sejam homologadas pela sua organização é requisito básico de compliance.
"NÃO DÁ PRA DERROTAR QUEM JÁ TÁ NO CHÃO"
É ruim "bater em bêbado", quando o assunto é falhas de cybersegurança, ou as diversas reticências no que diz respeito aos desafios de manter um software gerado por ferramentas de LLM que auxiliam na codificação.
Então essas são outras coisas que NÃO irei abordar aqui.
"NÃO, ESTE HYPE NÃO É IGUAL AOS OUTROS"
Muitos comentam que "este hype é parecido com o de microsserviços" (por exemplo).
Não, não é.
Poderia ser só mais uma (boa) tecnologia para acrescentarmos à nossa stack e ao nosso trabalho.
O problema é que MUITA GENTE tenta vender como um "PARADIGMA", algo que vai "MATAR os Devs", ou substituir a engenharia de software como ela é hoje.
E é nessa parte que a propaganda me pega.
(Sob meu ponto de vista) Chega a ser ultrajante desconsiderar os avanços da engenharia depois de mais de 40 anos de história.
Existe um fluxo para a evolução e implementação da Engenharia.
Os últimos anos consolidaram um conjunto de processos, organização de times, metodologias, frameworks de trabalho, matérias relacionadas a automação, plataformas e maturidade das tecnologias que são base de tudo que é utilizado para a confecção de produtos digitais.
O fator preponderante do que nós vemos no mercado hoje, é o papel cada vez mais presente do método científico servir como base para as engenharias.
O embate entre quem se preocupa com a forma e "agradabilidade de leitura" do código(artesãos) e quem "só" deseja resolver os problemas(engenheiros) havia encontrado o chão comum: a ciência.
Dave Farley aborda o papel da ciência na evolução das engenharias aqui neste vídeo: Engineering for Software
Esse fluxo não sumiu(e nem vai tão cedo). Ele está aí e construir produtos digitais ainda obedece aos mesmos fundamentos.
Quando aquela pessoa Dev amiga (de verdade) diz pra você "utilize a LLM para auxiliar no código, mas tenha senso crítico", na realidade ela não está nada mais do que afirmando nas entrelinhas que você precisa estudar os fundamentos da engenharia moderna para poder implementar.
Isso não mudou, mesmo que a propaganda tente vender as técnicas de engenharia(Ágil,Cloud Native,DDD,BDD,TDD, etc.) usando outro nome.
"PARE DE TREINAR O MODELO DOS OUTROS E VÁ TREINAR O SEU CÉREBRO!"
Se você faz parte de times com pouca senioridade (tô falando da senioridade do TIME e não individual), muito provavelmente a utilização de codificação assistida por LLM vai acelerar o prejuízo e dívida técnica que o seu time naturalmente já iria produzir.
Então sabendo disso, você deve atuar para auxiliar na evolução do conhecimento de engenharia do seu time.
Este deveria ser o papel de quem é Senior++ e gestores, porém a situação atual pede que todas e todos que fazem parte da equipe tenham de procurar um papel de compartilhamento de conhecimento no time.
Neste caso, as ferramentas de AI também podem auxiliar.
Toda equipe, mesmo antes do hype, já deveria ter um contexto de gestão do conhecimento. Isso agora tem um papel muito mais forte.
"PROPAGANDA NÃO É FUNDAMENTO, SOFTWARE PROPRIETÁRIO NÃO É FLOSS(Free Libre Open Source Software)"
Propaganda não é fundamento, o "método de utilização do software do zezinho" não é o mesmo do software do pedrinho.
Aliás, nem as metodologias de desenvolvimento estão fincadas em pedra.
XP foi uma experiência que deu certo com o Kent Beck naqueles projetos, mas talvez não vá dar certo na sua organização.
Em resumo: ATÉ as experiências que deram certo no passado, muito provavelmente não irão fucionar no caso da sua organização.
Mas por que ressaltar isso?
O hype atual emula EXPERIÊNCIAS QUE NÃO DERAM CERTO no passado.
- focar em soluções proprietárias
- aproximar programação da linguagem humana
Não é "discurso de doidinho do GNU/Linux". O core das bigtechs/Cloud e principais produtos digitais do mercado é FLOSS. E o hype não tem como base FLOSS.
Ano passado(2025) as primeiras iniciativas mais relevantes começaram a aparecer, o problema é que está vindo meio tarde.
E para completar o ritmo de surgimento de "padrões" e "especificações" é frenético, a ponto de vermos a "morte" de padrões que não duram sequer 3 meses.
CUIDADO COM O SENIOR++ ENDOSER DO HYPE
Desde o surgimente do hype de LLM diversas pesquisas já demonstraram que isto acelera sua equipe(pro bem e/ou pro mal).
Se a equipe for boa, vai acelerar a qualidade boa da entrega.
Se a equipe for ruim, vai acelerar os problemas.
Essa lógica vale pros devs Seniors++ individualmente também.
A pessoa tem os fundamentos bem definidos na memória muscular, já têm bastante vivência de mercado. Daí fica fácil enxergar o grande valor que a ferramenta pode gerar no trabalho do dia-a-dia.
E isso é um problema.
Nós temos nossas experiências pessoais, porém da mesma forma devs e projetos crescem em conjunto, seja num time, seja numa organização, seja na comunidade de profissionais de tecnologia.
Dev senior consegue aproveitar, mas TEM DE SER SENIOR e não dá pra fingir que "todo time é repleto de seniors".
Não dá pra fingir que times com senioridade baixa não existem, se bobear são a grande maioria no mercado.
Então muito cuidado com Dev Sernior++ que está empolgado nas redes sociais. A experiencia desse tipo de pessoa NÃO É a mesma que a sua, principalmente se você tem pouca senioridade e ainda tem um caminho grande de estudo/trabalho para percorrer.
CONCLUSÃO DO DESABAFO
E é isso, este foi um desabafo que estava a correr na minha cabeça já tem umas semanas.
*Quando tiver tempo coloco as referencias,reviso e etc..
por enquanto fica só o texto cru.. ahahaha
Top comments (0)