- A afirmação de que a IA aumenta a produtividade de engenheiros em 10 a 100 vezes não é realista
- Ao usar ferramentas de IA para programação de forma aprofundada na prática, percebe-se que o ganho de eficiência é limitado, e explosões temporárias de produtividade só ocorrem em tarefas repetitivas e simples
- Os gargalos do desenvolvimento de software (code review, colaboração, planejamento etc.) não podem ser superados com IA, e uma melhora de 10x no trabalho como um todo é impossível
- O mito do engenheiro 10x surge de várias motivações, como distorção de métricas, interesses do setor ou até a criação de ansiedade dentro das organizações
- Manter seu próprio jeito de desenvolver e o prazer no trabalho leva a resultados melhores no longo prazo e a uma cultura organizacional mais saudável
Ceticismo em relação ao mito do engenheiro 10x com IA
Ansiedade de produtividade e experiência prática com ferramentas de IA
- Em plataformas como LinkedIn e Twitter, vem se espalhando o discurso de que a IA aumenta a produtividade dos engenheiros em 10 a 100 vezes, e muitos desenvolvedores sentem ansiedade por medo de ficar para trás
- O autor também colocou em uso real vários agentes de geração de código com IA (Claude Code, Cursor, Roo Code, Zed etc.), mas, embora fossem convenientes em tarefas simples e repetitivas, não houve transformação fundamental em trabalhos complexos do mundo real
- Em JavaScript (especialmente React), dá para escrever rapidamente código repetitivo (boilerplate)
- Mas, quando há padrões próprios da base de código ou bibliotecas incomuns, a IA não consegue acompanhar direito
- Em linguagens como Terraform, o desempenho cai porque a IA não está tão familiarizada
- Por causa de alucinações (hallucination), ela pode gerar bibliotecas inexistentes e até provocar vulnerabilidades de segurança
- A capacidade de entendimento de contexto da IA ainda é limitada. Quanto mais complexa é a base de código real, mais surgem prompts repetidos, erros e perda de tempo
- Como resultado, o autor usa IA em scripts pequenos ou tarefas não essenciais, enquanto trabalhos complexos ou importantes continuam sendo feitos manualmente
O problema de quantificar a produtividade no desenvolvimento de software
- A alegação de que a produtividade pode aumentar 10 a 100 vezes com IA é uma métrica distante da realidade
- Produtividade 10x ou 100x não significa apenas mais linhas de código, mas sim que um trabalho que levaria 3 meses (desenvolvimento completo, code review, QA etc.) terminaria em 1 semana e meia
- No desenvolvimento de software, há vários gargalos: planejamento, estimativa de story points, correção de bugs, code review, espera para deploy, testes e QA
- Para atingir esse objetivo, cada uma dessas etapas teria de ficar 10 vezes mais rápida na mesma proporção
- Na prática, o tempo gasto com codificação em si é pequeno, e muito do esforço vai para entendimento, design, revisão e comunicação
- Realisticamente, code review, colaboração, comunicação e QA não podem ser encurtados com IA
- Nos trabalhos reais de engenharia, os gargalos estão nas pessoas, nos processos e na comunicação
- LLMs (large language models) reduzem o tempo de digitar no teclado, mas tempo para qualidade de código, testes e revisão continua sendo necessário
- Mesmo que a IA aumente temporariamente a velocidade de escrita de código, o aumento de taxa de erros, padrões de código inadequados e re-prompting fazem com que isso não tenha impacto decisivo no aumento da produtividade total
- Uma produtividade 10x é, na prática, um objetivo quase impossível
A realidade e os limites do engenheiro 10x
- Sobre a existência de um "engenheiro 10x", o autor considera que isso é possível de forma temporária e limitada
- O maior motivo é a capacidade de evitar trabalho desnecessário que se acumula com experiência, como impedir desenvolvimento desnecessário ainda na fase de planejamento, melhorar a experiência de desenvolvimento e investir em documentação
- Mas nem todo engenheiro encontra esse tipo de situação o tempo todo
- Engenheiros excepcionais podem evitar trabalho desnecessário ou aumentar a eficiência da organização inteira ao melhorar sistemas, mas, na prática, quase não existem casos de desempenho sustentado de 10x
- Ferramentas de IA para programação não contribuem muito para evitar trabalho desnecessário
- Pelo contrário, recomendações da IA podem levar a implementações excessivas ou sugerir arquiteturas erradas
- Codificar mais rápido nem sempre significa ser um engenheiro melhor
O contexto e as motivações por trás do mito da IA 10x
A maioria das alegações de "produtividade 10x" vem de fatores como os seguintes:
- Engenheiros bem-intencionados que cometem erros de medição
- Com ferramentas de IA, é possível viver momentos curtos de eficiência explosiva (ex: escrever automaticamente regras customizadas de ESLint)
- Mas, quando esse tipo de tarefa se repete, a diferença de produtividade acaba diminuindo rapidamente
- O fascínio técnico e a adaptação a um ambiente novo podem causar, no começo, uma ilusão exagerada de eficiência
- Incentivos e partes interessadas
- Fundadores de startups de IA, investidores e outros atores costumam citar números exagerados em busca de sucesso comercial
- Engenheiros e executivos também podem mencionar produtividade inflada para atender às expectativas dentro da organização
- Objetivos maliciosos
- Alguns executivos espalham afirmações exageradas com a intenção de criar ansiedade nos engenheiros e evitar agitação interna, como trocas de emprego ou pedidos de aumento
- O medo de que qualquer pessoa possa ser facilmente substituída por IA se repete ciclicamente (de forma parecida com debates passados sobre coding bootcamps)
O desempenho real da IA em open source e projetos práticos
- A maioria dos casos sobre ganho de produtividade com IA mostra uma distância entre quem escreve sobre isso e o engenheiro cuja produtividade teria aumentado.
- Casos de uso de ferramentas de IA comprovados diretamente por engenheiros reais mostram um retrato realista, sem exageros
- Em projetos open source, os resultados do uso de IA muitas vezes aparecem como abaixo do esperado ou até como casos de fracasso
- Em demos públicas ou casos reais de engenheiros, às vezes a IA parece mágica, mas, na maior parte do tempo, não é tão diferente do velho "gerador de texto"
Um valor mais importante do que a "produtividade": manter seu próprio jeito de desenvolver
- Usar IA pode, às vezes, permitir escrever código mais rápido, mas o autor ainda valoriza mais o prazer de programar em si
- Se você não gosta de programar com IA ou não acha isso prazeroso, tudo bem abrir mão de parte da produtividade
- Mesmo aceitando algum nível de ineficiência, trabalhar do jeito que combina com você gera resultados melhores e mais saudáveis no longo prazo
- Quando se trabalha com prazer, é possível ter melhor capacidade de resolver problemas, de projetar soluções e de colaborar com colegas
- Prazer e imersão são mais importantes para a produtividade de longo prazo e para a qualidade do código, e perseguir produtividade à força aumenta o risco de burnout
- Por outro lado, se programar com IA for realmente divertido e útil, vale usar isso ativamente
Conselhos para uma cultura organizacional saudável
- Ao adotar ferramentas de IA, criar expectativas irreais e ansiedade em todos os engenheiros prejudica a produtividade da organização
- A obsessão por maximizar produtividade leva a queda de qualidade, deterioração da base de código e perdas de longo prazo
- O ideal é dar autonomia e confiança suficientes aos engenheiros e permitir que cada um escolha o uso de IA da forma que mais se adequa a si
- Dentro da organização, é importante oferecer oportunidades de uso de IA, mas com um ambiente que garanta autonomia
- Se LLMs e a inovação em programação com IA realmente entregarem produtividade 10x, os próprios desenvolvedores vão descobrir isso naturalmente
Conclusão
- A revolução do engenheiro 10x causada por IA está mais para mito; na prática, não existe uma receita secreta sendo ignorada
- O mais importante é confiar na própria habilidade e no próprio jeito de trabalhar
- SNS (especialmente LinkedIn e Twitter) ampliam mitos exagerados, então não há problema em ignorá-los
10 comentários
Será que realmente teve gente que interpretou 10x como literalmente 10 vezes? Eu naturalmente achava que era um exagero de marketing/autopromoção, então é desconcertante ver gente levando isso tão a sério.
Mesmo que não seja exatamente 10x, existem muitas organizações que têm uma convicção séria sobre Nx. Substituir custo de mão de obra por custo de IA e esperar resultados ainda maiores... Isso também não é uma ilusão sem fundamento, porque quando um PM quer testar rapidamente algo como um PoC simples ou uma ferramenta para trabalho repetitivo, isso sai num instante. Então, será que existe desenvolvedor que acredita nisso...? Na minha opinião, dependendo da situação em que cada um se encontra, o clima do setor está disseminado o suficiente para gerar uma sensação real de insegurança. Acho que esse tipo de discussão séria é necessário, nem que seja para a comunicação com cargos não técnicos e com líderes de organização.
Claro que não estou negando que isso ajude na produtividade. (No nível atual da IA, neste momento) acho óbvio que esse negócio de 10x não faz sentido, e como o conteúdo do post original era justamente afirmar categoricamente que "não chega a 10x", achei isso bem estranho e por isso escrevi o comentário, mas parece que a forma como expressei isso não foi muito boa.
Assim como você diz que a produtividade da IA é um exagero usado para marketing/autopromoção, acho que esse texto também contém um certo exagero.
Por isso, o ponto sobre se realmente existia alguém interpretando 10x literalmente como 10 vezes me pareceu meio como procurar pelo em ovo, então imagino que isso tenha causado antipatia.
Parece que você respondeu sem ler o texto original. Em nenhum momento do original alguém estava levando isso tão a sério assim...
O fato de o DataTube.tv, de busca de ideias virais para YouTube desenvolvido pelo autor, também ter um volume de uso "dezenas de vezes" maior que o Viewtrap obviamente seria uma expressão exagerada para marketing/autopromoção, certo?
Talvez por ser online, ou talvez isso já seja do seu jeito, mas a maioria dos comentários foi escrita com um olhar bem crítico.
Espero que você consiga enxergar isso com uma perspectiva um pouco mais aberta.
Acho que, se existe exagero em torno da IA, também existe o oposto, então não tenho muitos pensamentos sobre o texto em si...
Este comentário é de arrepiar; dá medo de verem até posts antigos que a pessoa escreveu e virem comentar, ainda mais tendo se cadastrado hoje mesmo
Vi seu comentário e, mesmo olhando para o meu histórico, não acho que exista sequer um comentário realmente constrangedor. O problema é enxergar as coisas com um olhar crítico? Para viver bem, é preciso não fazer comentário nenhum, como você...?
Hã? Eu até converti o número 10x em quantidade de meses... entendo se a expressão "fazer pose de sério" te incomodou. As dezenas de vezes do Datatube são um valor quantitativo. Bem, de qualquer forma, nem estou operando isso...
Comentários no Hacker News
Não entendo por que só a área de engenharia de software fica obcecada com o mito da produtividade "10x"; em engenharia mecânica, elétrica, civil ou química esse conceito não existe
Um grande engenheiro é alguém capaz de reduzir riscos e projetar sistemas dentro de várias restrições
Projetar é o processo de entender o domínio por meio de modelos e compreender o alcance e os limites desses modelos
Não existe "10x"; só existe assumir responsabilidade por bons sistemas
Se existisse um engenheiro de software "10x", seria alguém que evita incidentes como vazamento de dados; eu preferiria ver esse tipo de evento acontecer 10 vezes menos
Também concordo com boa parte deste texto
Sou um grande fã de desenvolvimento com ferramentas de AI, mas as alegações de produtividade 10x nunca me convenceram
Graças aos LLMs, algumas tarefas como digitar código ficaram de 2 a 5 vezes mais rápidas, mas isso é só uma parte do trabalho total
Na prática, muitos engenheiros acham que certas tarefas podem ficar 20% a 50% mais rápidas, mas concordam que isso não se traduz em aumento de 20% na produtividade total, muito menos em 10x
Claro, quem usa AI muito bem pode sentir um ganho maior que 0,2x, mas por causa da complexidade intrínseca do desenvolvimento de software, 10x é irrealista na maior parte dos casos
Quando uso AI, preciso ficar supervisionando o tempo todo, então não sinto que a eficiência seja tão alta
Às vezes as sugestões do Copilot encaixam perfeitamente no que eu estava pensando e isso impressiona, mas no geral ele parece menos um desenvolvedor júnior muito habilidoso e mais um "desenvolvedor sênior bêbado", que não escuta direito
Metade do código gerado nem compila e, mesmo quando compila, não funciona direito
Pela minha experiência, a AI não gera um aumento gigantesco de produtividade em criação, mas ajuda muito em descoberta, aprendizado, destravar problemas e escrita de código repetitivo
Mas a verdadeira mudança acontece em projetos paralelos
Antes eu estava cansado demais para dedicar tempo a trabalhos extras; agora, mesmo sem código perfeito, consigo transformar ideias em realidade com mais rapidez e menos esforço mental
Também dá para experimentar habilidades de engenharia com AI com liberdade, sem restrições de prazo, privacidade ou ferramentas
Acho que até as pessoas chamadas de "engenheiros 10x" terão ganhos modestos de produtividade com AI
Os melhores desenvolvedores que conheço têm duas capacidades essenciais: memória absurda e conhecimento detalhado de toda linguagem/biblioteca; e uma criatividade quase milagrosa com grande capacidade de resolver problemas
É impressionante como chegam a soluções originais e elegantes, as mais adequadas ao problema, mesmo sem saber fórmulas ou teoria
Quando fazem pair programming com AI, a AI precisa de tentativas e iterações sem fim para chegar a uma solução parecida e, no fim, só atrasa o gênio humano
Mas o espectro de capacidades é tão amplo que, no meu caso, a AI realmente pode significar um ganho de 10x
Minha formação não é em software, e por causa do perfeccionismo eu programo muito devagar; com AI, consigo fazer rapidamente uma primeira versão ruim e isso é útil para concretizar ideias
Também sou a favor do desenvolvimento com assistentes de AI e acho que ganhos de velocidade de 2x a 10x podem existir em alguns contextos
Mas, na maioria das vezes, "produtividade 10x" é usado de forma exagerada para significar que o processo inteiro de implementação de uma funcionalidade, do começo ao fim, ficou 10 vezes mais rápido
Na realidade, muitas partes do processo total de desenvolvimento, além da codificação, não ficam 10 vezes mais rápidas
Ainda assim, em ambientes realmente pequenos ou de trabalho solo, dá para pular muitos processos incômodos, então na prática pode haver um grande ganho de velocidade
Nesse contexto, estamos entrando numa era em que times pequenos e desenvolvimento individual ganham competitividade de repente
Obrigado pelo comentário do Simon
Esse comentário sim passa a sensação de que a pessoa realmente leu o texto
Reconheço que, em alguns trabalhos especializados em certas linguagens ou ferramentas, ganhos reais de 2x de produtividade estão acontecendo
Durante décadas sonhei com a automação do desenvolvimento de software, e sinto que os LLMs realizaram esse sonho de um jeito completamente diferente
Ferramentas anteriores como CASE, UML e IDE prometiam "deixar você focar na lógica real", mas os LLMs simplesmente geram código executável imediatamente a partir de linguagem natural
Muitos desenvolvedores se sentem ansiosos porque os antigos ritos de passagem estão ruindo, e há medo de ficar para trás nesse novo mundo, um tipo de síndrome do impostor
Agora voltamos a perguntar o que afinal é engenharia de software
O LLM é a forma definitiva daquelas antigas ferramentas CASE, mas tudo aconteceu rápido demais, de forma confusa e disruptiva
Pessoas que não conhecem a "linguagem sagrada" do engenheiro de software agora também ganharam poder, e muitos engenheiros acabam se perguntando, em um nível fundamental: "o que exatamente eu estou fazendo agora?"
Agora finalmente entendo como os artistas devem ter se sentido ao ver stable diffusion
O código feito por AI no fim das contas frequentemente está errado, cheio de bugs, convenções estranhas e coisas inúteis
Consertar tudo isso às vezes leva tanto tempo quanto fazer do zero
Mesmo tentando vários modelos ou refinando prompts, ainda parece que o código de alta qualidade que eu realmente quero continua fora de alcance
É como no stable diffusion: quem não presta atenção talvez nem perceba que há algo estranho; da mesma forma, quem não entende bem de código gerado por AI pode nem notar que há problemas
Recentemente olhei um código esquisito escrito por um colega e vi que não funcionava nem no debugger e estava cheio de problemas; ele confessou que "só foi codando no feeling"
Quando olho para o mundo recentemente, sinto que o capital continua destruindo o trabalho
Salários baixos, condições ruins, vigilância, pressão por métricas, empresas antiéticas e contratos de curto prazo: a realidade da maioria dos trabalhadores está piorando cada vez mais
Até aqui fomos protegidos demais para sentir isso de verdade, mas agora nós também estamos diante de um futuro instável
"Engenharia de software" no fim vai virar trabalho de consertar
vibeMuitas profissões podem ser substituídas por software, mas já existia uma realidade em que gestores evitavam contratar SWE se eles não conseguissem provar valor concreto
Com a adoção de AI, gestores vão gerar em massa códigos que eles não entendem e, quando tudo quebrar três anos depois, vão chamar os SWEs de volta para consertar
É até provável que aumentem os empregos de alta dificuldade e alto valor voltados a corrigir justamente esses "problemas que a AI não consegue resolver"
Os LLMs geram código diretamente, sem modelos formais nem diagramas
Eu preferiria que a AI criasse esse tipo de projeto formal e diagramas
Esse tipo de ferramenta ajuda na compreensão do código e a deixar o design mais claro
Seria ótimo se a AI também desse suporte a essa parte
O gargalo do desenvolvimento de software não é a velocidade de digitação nem a geração, e sim a verificação e a compreensão
Mesmo se um LLM funcionasse perfeitamente, sem falar besteira nem ter alucinações, um desenvolvedor responsável ainda precisaria revisar o código linha por linha
Como seres humanos não conseguem entender código 10 vezes mais rápido, na prática pode levar ainda mais tempo voltar por cima de código gerado automaticamente e decifrar as intenções ocultas
A expressão "produtividade 10x" só faz sentido quando se entrega a saída sem verificar o código, ou quando se está lidando com código extremamente simples em que erros não importam
Em software de produção, onde erro vira desastre, a capacidade cognitiva humana continua sendo o gargalo; como os LLMs só transferiram o peso da escrita para a revisão, eles acabam sendo negativos para a produtividade geral
Essa discussão me passa a sensação de que desenvolvedores medianos estão expondo a própria produtividade
Se você entende a tecnologia do projeto e sabe dividir bem o trabalho, consegue prever a complexidade do código com antecedência e passar para a AI tarefas em unidades apropriadas
A AI não é mágica; ela tem um limite superior de complexidade que consegue escrever
Se você entende bem esse limite e a tecnologia do projeto que está construindo, pode decompor os componentes abaixo desse limite e instruir a AI de acordo
Esse método funciona bastante bem
Isso é praticamente uma tautologia
Se você simplifica as instruções para a AI funcionar bem, claro que ela vai funcionar bem
Mas, na prática, você precisa mastigar instruções detalhadas demais para a AI e, ainda assim, revisar tudo cuidadosamente sem conseguir confiar no resultado
Na verdade, o próprio trabalho de quebrar tudo em pedaços e explicar para a AI pode ser mais trabalhoso do que escrever o código diretamente
Se a AI der a resposta certa de primeira por sorte, há ganho de eficiência; mas, realisticamente, você acaba iterando várias vezes ou refazendo tudo, desperdiçando tempo e esforço
O código bonito e bem estruturado da AI muitas vezes está errado na prática, e isso é perigoso
A parte realmente difícil e demorada é projetar as partes complexas
As partes triviais você só precisa fornecer, mas resolver as partes complexas é o que realmente consome tempo
Dá para sentir, por trás desse comentário, a nuance de "você acha que é um desenvolvedor acima da média?"
Pode ser exatamente o contrário
Enquanto desenvolvedores fracos só ficam submetendo auto-PRs inúteis e se maravilham com o resultado gerado pela AI, desenvolvedores com padrões mais altos podem não se impressionar
Na prática, como é difícil distinguir pessoas confiáveis sem trabalhar junto com elas, eu prefiro manter uma posição neutra
Tanto a AI quanto os humanos têm limites
No fim, o que importa é a tediosa gestão de projetos
Se você tiver requisitos adequados, design e informação suficiente, e quebrar tudo em pequenas unidades de trabalho, pode mandar a AI "implementar a issue #42 do GitHub" e ficar vendo TV enquanto acompanha
Mas se disser "faça o Facebook", claro que vai dar tudo errado
Outra área em que a AI me ajudou muito foi encontrar bugs
Trabalho principalmente com simulações numéricas, e um problema em que eu fiquei preso por dias — um erro de escala numa fórmula causado por alguns parênteses ausentes — foi resolvido rapidamente quando expliquei ao ChatGPT os arquivos e o sintoma
Às vezes a AI faz exatamente o papel de apontar com clareza aquilo que eu deixei passar
Isso não me transforma num desenvolvedor 10x, mas, se bem usada, dá para sentir um efeito muito positivo
Comigo é parecido
Gerar código com AI é só ok, mas para debugging é um salto enorme de produtividade
É como um "rubber duck" extremamente inteligente
(Perspectiva de desenvolvedor hobbyista) graças aos LLMs, desenvolver tarde da noite, quando o cérebro já não funciona direito, ficou muito mais fácil
Também economizei incontáveis horas graças à AI
Para mim é algo em algum lugar entre 10x e infinito
Não me considero um engenheiro 10x
O motivo de eu ser mais produtivo que meus colegas na empresa é design de sistemas e o fato de eu não seguir cegamente tickets mal definidos com exigências de negócio ambíguas
O motivo de a AI não conseguir simplificar meus colegas é que ela não muda o hábito deles de complicar tudo desde o início
A AI não resolve esse problema
Como meu salário na empresa não é o dobro do dos meus colegas, penso assim
Adotar ferramentas de AI não vai mudar essa realidade
Este texto define um padrão alto demais com essa ideia de "10x" e depois registra a tentativa pessoal do autor de ultrapassá-lo
Por isso acho que ele dividiu os apoiadores de AI em três grupos: pessoas enganadas, pessoas vendendo algo e gestores mal-intencionados explorando a ansiedade alheia
Pessoalmente, considero a reclamação sobre "hallucination" um leve "sinal"
Acho que falar sobre
hallucinationé realmente necessárioO debate sobre LLMs está indo para extremos demais, entre "é completamente inútil" e "vai substituir desenvolvedores"
Por exemplo, o Claude 4 Sonnet já respondeu incorretamente que o Godbolt estava errado em um assunto relacionado à compilação com clang
Mesmo assim, essa sessão como um todo foi de grande ajuda, então basta lembrar que é preciso manter senso crítico sobre os resultados
Alucinações realmente existem, e é preciso estar sempre atento aos resultados
Obrigado por deixar o comentário; os seus textos sobre AI me ajudaram a superar a síndrome do impostor
No texto, a classificação era apenas para quem afirmava ter conseguido sucesso "10x" em sequência, não era uma generalização sobre todos os apoiadores de AI
Fico curioso para saber se você encontrou algum método realmente livre de alucinações
Especialmente com Terraform e afins, os LLMs inventam propriedades inexistentes; em JS e afins, ao usar bibliotecas mais raras, ainda erram bastante
Se reclamar de "hallucination" é sinal, então esse tipo de pensamento também é um sinal…
(refutação curta)
Esse critério de 10x é marketing exagerado comum em toda a indústria
Ex.: afirmação do Sam Altman sobre 10x
promoção de produtividade do Cursor AI
desenvolvedor 10x com AI-augmented
Suponha que uma pessoa que não sabe criar webapps leve 6 semanas, estudando 4 horas por dia (120 horas), para conseguir fazer um
Se, em vez disso, usando AI como Claude Code, ela fizer o mesmo webapp em dois dias de fim de semana (12 horas), então houve um aumento de produtividade de 10x
Isso é bem parecido com o que aconteceu comigo na prática
Antes eu não conseguia fazer certas coisas por falta de motivação ou energia; com AI, agora consigo realizá-las ao longo de um fim de semana
Mas o primeiro método inclui aprendizado, então pode ajudar quando você quiser mudar alguma coisa depois
Na verdade, se você mandar uma AI como Claude Code scaffoldar um webapp fora do mundo React, o resultado é uma bagunça
Alguém sem experiência em desenvolvimento de apps não vai conseguir montar facilmente um app bem-acabado num fim de semana
Basta o primeiro usuário fazer login para tudo quebrar
No longo prazo, acho que essa aritmética não faz sentido
No começo você até cria o app rapidamente com LLM, mas aos poucos sua capacidade de manutenção piora e, em algum momento, você já não consegue mais colocar todo o sistema complexo na "janela de contexto" e gerenciá-lo
No fim, a produtividade pode até se aproximar de zero
Você terceirizou completamente o cérebro e a experiência de aprendizado, então o app surgiu, mas quase não houve crescimento nem aprendizado
Você pretende colocar isso em produção imediatamente?
Na prática, não são coisas comparáveis
Já é difícil medir o resultado de um desenvolvedor 1x, então multiplicar isso é mais sem sentido ainda
Sinto que a AI aumenta muito a "produtividade de side quests"
A AI é perfeita para aquelas coisas que eu vinha adiando por preguiça, como criar mockups, escrever testes, extrair bibliotecas e fazer documentação
Mesmo que ela não reduza o tempo de criar funcionalidades, ao incluir essas tarefas auxiliares o resultado final fica um pouco mais próximo do ideal
Espero que esse trabalho extra também reduza o tempo de encontrar bugs no futuro
(Experiência pessoal)
Isso vale só para o meu caso, mas na minha empresa é comum que o código de teste feito com LLM fique acoplado demais ao código de implementação
Há abuso pesado de padrões como test spies
Como resultado, surgem muitos testes ambíguos que não verificam o comportamento do ponto de vista do usuário, e sim só detalhes internos da implementação
Os testes quebram com frequência demais a cada mudança de implementação e, em vez de aumentar a produtividade, acabam virando um peso
Isso não é apenas um problema dos LLMs; desenvolvedores que já eram ruins em escrever testes acabam piorando ainda mais com LLM
Para quem tem pouca experiência com TDD e com testes bem projetados, o LLM amplifica esse tipo de antipadrão
Gostei da expressão "produtividade de side quests"
AI não parece "mil cortes mortais", e sim "uma vida nova feita de mil curativos"
Concordo com a ideia de "side quests"
Na verdade, a grande mudança foi conseguir criar com AI ferramentas e funcionalidades que eu nem teria feito sem ela
Não se trata apenas de economizar duas semanas, e sim de fazer surgir algo que antes nem existiria
As expectativas em relação aos LLMs estão acima da realidade, mas na prática eles são muito úteis em vários contextos
Em termos de "nível de zoom", quanto mais você desce do "vibe coding" mais solto para algo como "faça esta função", melhores tendem a ser os resultados
Além da geração de código, eles também são eficazes para vários usos, como aprender novas tecnologias
Se meu papel envolve muitas reuniões ou muito trabalho de gestão, a ajuda dos LLMs diminui
Acho que, no futuro, os LLMs também poderão ser usados em workflow de PR, organização de commits e reordenação de etapas
Na verdade, mesmo que fosse usado só para rebater engenheiros que vivem dizendo, sem pensar, que algo "não dá" ou é "impraticável", já parece que teria um efeito de x10.
Já vi com frequência essa cena de tratarem pessoas não técnicas como ignorantes e dizerem categoricamente que algo não dá para fazer.