Código é barato. Agora mostre a sua fala
(nadh.in)- Com o surgimento das ferramentas de codificação com LLM, a própria premissa básica do desenvolvimento de software, sustentada por décadas, entrou em colapso; mais do que escrever código, a competência central passou a ser definir o problema e projetar a estrutura
- Agora, o núcleo do desenvolvimento está migrando de “saber escrever bem código” para a capacidade de “falar” — imaginar o problema e explicá-lo com clareza
- Estruturas de código limpas, READMEs bem organizados e boa documentação já não são mais sinais confiáveis de diligência ou experiência e, paradoxalmente, quanto mais perfeitos parecem, maior a chance de serem slop
- À medida que a distinção visual entre código gerado por IA e código escrito por humanos se torna praticamente impossível, surgem responsabilidade, procedência e humanidade como critérios que definem o valor do código mais do que a qualidade em si
- Os incentivos à colaboração e ao compartilhamento que sustentaram o ecossistema FOSS estão enfraquecendo, e confiança, governança e capacidade de curadoria passam a ser ativos mais importantes do que o próprio código
- Essas ferramentas são amplificadores poderosos para desenvolvedores experientes, mas para iniciantes podem se tornar um gênio perigoso, capaz de roubar a oportunidade de construir entendimento básico
Introdução: o aforismo de Linus Torvalds e sua inversão
"Talk is cheap. Show me the code"
- Em 2000, essa frase de Linus Torvalds simbolizava a postura de que palavras não têm valor se não forem comprovadas com código real
- Na época, por mais claro que fosse o plano de desenvolvimento, implementar um programa complexo exigia enorme esforço, muito tempo e repetição entediante
- O verdadeiro gargalo não era a tecnologia, mas os limites humanos: largura de banda cognitiva, tempo e energia individuais, além do custo biológico de manter sistemas inteiros na cabeça enquanto se escrevia código linha por linha
- Como resultado, a maioria das ideias acabava acumulada numa “lista de desejos para algum dia” e desaparecia sem sequer ser tentada
25 anos depois: os LLMs viram tudo de cabeça para baixo
- Em 2025, Linus Torvalds fez merge de código gerado por IA em seu projeto pessoal e comentou: “É melhor do que o que eu escreveria à mão? Claro que é”
- Do ponto de vista de alguém que desenvolve software há décadas, o autor afirma categoricamente que o desenvolvimento de software como conhecíamos já acabou
- Como parte da geração que viveu diretamente inúmeras transições — do dial-up ao gigabit, de Basic a Node.js, de SourceForge ao GitHub — ele reconhece com clareza que essa mudança não é uma moda passageira, mas uma ruptura qualitativa
O colapso dos critérios de avaliação da qualidade de código
- No passado, ao avaliar projetos FOSS, fatores como idade do projeto, frequência de commits, consistência da estrutura do código, qualidade do README e da documentação eram critérios importantes
- Comentários concisos e documentação bem organizada eram vistos como sinais de consideração do desenvolvedor e cuidado com outros desenvolvedores
- Mas, agora que LLMs conseguem gerar de uma vez só páginas de documentação bem acabadas, READMEs excessivamente detalhados, UIs limpas, padrões organizados e comentários caprichados, esses sinais deixaram de ser confiáveis
- Como resultado, ficou difícil distinguir apenas pela aparência se um repositório foi feito por alguém não técnico com vibe coding ou se é o resultado de projeto de um desenvolvedor experiente
- Paradoxalmente, quanto mais perfeito algo parece, mais se deve suspeitar de que seja um artefato gerado em one-shot com pouco esforço
- Sem revisão e análise minuciosas em nível especialista, fica cada vez mais difícil separar o trigo do slop
- Assim, mais do que o código em si, passam a importar fatores de procedência como quem fez, por que fez, qual histórico esse agente tem, se há governança e plano de manutenção
A mudança no valor do esforço
- Antes, para produzir 10.000 linhas de código de alta qualidade com resultado significativo, um desenvolvedor experiente precisava passar por longos períodos de foco e repetidas iterações de melhoria
- O número de linhas nunca foi, por si só, métrica de qualidade, mas 10.000 linhas bem refinadas significavam investimento de tempo, concentração, paciência, especialização e certo nível de gestão de projeto
- Um LLM consegue gerar esse tipo de resultado em poucos segundos, cobrindo todo o fluxo técnico, de testes e configuração do sistema até implantação
- Quando a especialização e o julgamento humano entram em conjunto no processo, o resultado pode atingir qualidade alta o bastante para uso real
- Pessoalmente, o autor relata ter repetido a experiência de concluir em dias — às vezes em horas — trabalhos que antes levariam semanas ou meses
- Isso foi possível apenas com uma CLI simples de agente LLM, sem AGENT.md nem orquestração complexa com múltiplos agentes
- O custo fisiológico, cognitivo e emocional antes pago para obter um resultado de software caiu em várias ordens de grandeza
- O tempo e a folga cognitiva assim obtidos são reinvestidos em pensamento de engenharia, projeto de arquitetura, discussão, experimentação e expansão da imaginação
- O velho ditado “programar é 90% pensar e 10% digitar” deixou de ser metáfora e virou realidade
A definição de slop e o valor do código
- Quando até alguém que nunca escreveu uma linha de código pode gerar código em escala industrial em segundos, qual é o valor do código enquanto artefato?
- Dizer “quero apenas código puramente humano, não código de IA” é, diante da realidade, quase uma piada irônica
- Já existem exemplos suficientes de grandes incidentes causados por código escrito por humanos, como a falha de TI da CrowdStrike (2024), a paralisação do Boeing 737 MAX, o escândalo dos Correios do Reino Unido, o megavazamento de dados na Índia e o vazamento da Equifax
- Uma parcela considerável do código que humanos escrevem diariamente no mundo está no limite em termos de qualidade
- Ainda é difícil considerar o desenvolvimento de software um campo profissional objetivamente amadurecido
- Médicos e engenheiros civis exigem formação rígida, licença e responsabilidade pelos resultados práticos; no desenvolvimento de software, quase não há nada equivalente
- A sociedade de hoje opera sobre sistemas de código mal projetados, remendados de forma improvisada e excessivamente inflados
- Num argumento mais provocativo, seria possível dizer que o slop feito por IA ao menos costuma vir com forma limpa, documentação organizada e consistência sintática
- Cresce a percepção de que ler frases e mensagens sem alma geradas por LLM que inundam a internet é, literalmente, quase um desperdício de ativação dos neurônios da amígdala
- Sem o processo criativo humano, com suas perfeições e imperfeições, linguagem, literatura, arte e música se tornam essencialmente impossíveis de apreciar
- Aquilo que pode ser gerado infinitamente e instantaneamente, sem esforço, torna-se extremamente difícil de avaliar como algo valioso para seres humanos
Código é diferente de arte
- O código, em essência, sempre foi um meio para um fim, nunca um fim em si mesmo
- O usuário final não lê código, não precisa lê-lo e não se importa com ele
- Para o usuário, não importa em qual linguagem, framework ou arquitetura foram implementados os centenas de sistemas que rodam por trás de um portal
- O código é algo completamente oculto; o que o usuário experimenta, via UX, são apenas os resultados e efeitos produzidos por ele
- O critério que distingue se um código de IA funcionalmente idêntico é slop ou não está na estrutura de responsabilidade (accountability) e no grau de intervenção humana
- Um PR enviado por uma pessoa a um repositório open source, independentemente da qualidade do código, naturalmente recebe empatia e valor baseados no tempo e no esforço humano investidos
- Já um PR gerado por LLM frequentemente desperta a reação imediata de “slop!”, independentemente da qualidade, porque não é possível estimar de pronto o esforço humano contido nele
- Ao mesmo tempo, a carga de ler e verificar esse código cresce de forma desproporcional, exponencial, em comparação com o custo de produzi-lo
- No fim, ele é apenas uma entre infinitas variações geradas sem esforço, sem procedência ou contexto significativos
- Nesse ponto, nossa realidade se aproxima cada vez mais da “Biblioteca de Babel” descrita por Borges
O futuro do FOSS
- O FOSS talvez seja um dos maiores bens públicos já criados pela humanidade
- O ponto de partida do FOSS era uma época em que software era extremamente caro e só podia ser produzido por um pequeno grupo de especialistas
- Apenas uma fração minúscula da população mundial podia criar software; o restante não tinha alternativa senão usar o que era produzido
- Agora, mesmo para necessidades extremamente de nicho, um especialista consegue criar rapidamente pequenas bibliotecas ajustadas exatamente ao que precisa
- Mais do que isso, chegamos a uma era em que qualquer pessoa com alguma esperteza pode fazer seus próprios pequenos utilitários para uso pessoal com vibe coding
- A mudança que aconteceu no StackOverflow está avançando, mais lentamente, mas de forma semelhante em todo o software
- Isso parece abalar frontalmente o núcleo das motivações humanas, condições sociais e incentivos de participação que sustentavam a colaboração e o compartilhamento no FOSS
- Considerando a explosão cambriana de projetos FOSS que virá em escala sem precedentes
- Os projetos FOSS de alta qualidade que sobreviverem e prosperarem provavelmente terão como ativos mais importantes governança especializada, curadoria e estruturas de confiança, mais do que o código em si
Os dois extremos que veem a árvore e perdem a floresta
- Mesmo na época sem syntax highlighting, IDEs e toda sorte de ferramentas, os humanos já criavam software em nível impressionante
- Por outro lado, mesmo agora, com abundância de ferramentas e recursos, software ruim continua sendo produzido
- Desenvolvedores competentes, expressivos e preocupados com qualidade conseguem usar LLMs ou qualquer outra ferramenta à sua maneira e produzir bons resultados
- Em contraste, desenvolvedores que não sabem explicar problemas e não se importam com qualidade produzem resultados ruins, com ou sem LLM
- Tanto os crentes extremos no vibe coding “agentic” quanto os que rejeitam totalmente os LLMs acabam presos às árvores sem enxergar a floresta
- Existe claramente um ponto intermediário prático em que pessoas com experiência, especialização, capacidade de raciocínio e expressão escolhem trade-offs adequados para obter os resultados desejados
- O vibe coding também pode ser um ponto de entrada importante para que não técnicos toquem software pela primeira vez, experimentem, se divirtam e desenvolvam capacidade
- Mas os que depositam fé cega nisso ignoram o elemento central que faz humanos levarem um artefato a sério: a finitude
- Como resultado, estão construindo uma enorme biblioteca borgiana na qual eles mesmos podem facilmente se perder, em meio a um mar de slop criado por agentes bajuladores
- Artefatos gerados infinitamente sem esforço e sem procedência significativa são extremamente difíceis de valorizar ou levar a sério
- O ser humano, por natureza, não lida bem com oferta infinita — especialmente com infinitas opções
- Por sua vez, os críticos dos LLMs muitas vezes não vão além de um argumento por incredulidade
- Negam a tecnologia em si porque não gostam dela pessoalmente, não obtiveram o resultado desejado, tiveram expectativas frustradas ou simplesmente se cansaram dela
- Mas isso perde força diante do fato de que há muita gente usando a mesma ferramenta com eficácia e tendo experiências opostas
- Implementações estúpidas e nocivas, impulsionadas por hype, frenesi e ganância, são reais e motivo sério de preocupação
- A bolha de negócios de IA provavelmente será uma das maiores bolhas da história
- Ainda assim, a difusão de tecnologias FOSS de IA é claramente um sinal promissor
- Equiparar maus atores, jogos de métricas e implementações absurdas às capacidades fundamentais e físicas que essas tecnologias têm é irracional
O custo humano
- Do ponto de vista de desenvolvedores e engenheiros experientes, essas tecnologias de IA funcionam como instrumentos auxiliares muito poderosos e eficazes
- Mas, para aprendizes em estágio inicial e juniors que estão apenas entrando no setor, surge um problema completamente diferente
- Se faltam fundamentos e ainda não se formou uma compreensão intrínseca e sutil dos sistemas e do processo de desenvolvimento de software, essa tecnologia se aproxima de um gênio pouco confiável e perigoso
- Pedir código e recebê-lo, pedir mudanças e vê-las aplicadas imediatamente parece conveniente à primeira vista
- Mas logo o usuário fica preso em uma base de código cujo funcionamento não entende, dependendo continuamente do gênio para resolver problemas
- Se essa dependência se repete, o próprio ambiente de aprendizado em que capacidades fundamentais poderiam se formar naturalmente desaparece, com risco até de decadência cognitiva
- Como resultado, surge a possibilidade de toda uma geração de juniors que nunca consegue se tornar sênior de forma significativa
- A preocupação real é que a geração em aprendizado perca a chance de adquirir a especialização necessária para distinguir objetivamente o que é slop e o que não é
- Mais grave ainda: até os profissionais experientes que dominam essas ferramentas podem perder a motivação para orientar e treinar juniors de forma básica e formativa
- Isso traz um risco que vai além do desenvolvimento de software: o de levar os humanos a delegarem integralmente agência e tomada de decisão a caixas-pretas
Conclusão: agora a fala vale mais que o código
- Mesmo para desenvolvedores que sempre programaram à mão, a capacidade de ler código e avaliá-lo criticamente agora se torna mais importante do que dominar sintaxe e digitar linha por linha
- Claro, esta última ainda é uma habilidade importante, e a capacidade de ler código com eficácia se apoia, no fim das contas, sobre essa base
- Ainda assim, o fluxo cotidiano de desenvolvimento de software já foi completamente invertido
- Um desenvolvedor experiente que sabe se expressar bem — alguém que consegue imaginar, explicar, definir problemas, projetar arquitetura e fazer engenharia — tem agora uma vantagem desproporcionalmente maior do que nunca sobre quem não consegue
- Conhecimento de linguagens, gramáticas e frameworks específicos deixou de ser o principal gargalo
- As limitações fisiológicas e físicas que antes prendiam desenvolvedores também já não funcionam como obstáculo decisivo
- Máquinas capazes de gerar grandes volumes de código instantaneamente agora são ferramentas comoditizadas, acessíveis a qualquer um no nível de um
pip install - Na prática, também deixa de ser necessário treinamento especializado separado ou aprender novas linguagens e frameworks
- O que se exige é apenas o velho pensamento crítico, capacidades humanas básicas e o mínimo de habilidade operacional para lidar com essa máquina
- Como resultado, metodologias e divisões de papel tradicionais no desenvolvimento de software — Waterfall e Agile, desenvolvedor e testador, sênior e júnior — estão passando por transformações fundamentais
- As fronteiras tradicionais estão sendo integradas em loops iterativos “agentic” inimaginavelmente rápidos, comprimidos e borrados
- Com isso, também mudam rapidamente as dinâmicas entre pessoas, organizações e comunidades públicas em torno do desenvolvimento de software, assim como os incentivos humanos que sustentavam o compartilhamento e a colaboração
- Casos como o fim do bug bounty do curl, a introdução de diretrizes de uso de IA no Zulip e a política explícita de IA do Ghostty mostram isso
- Pela primeira vez na história, boa fala (talk) passa a ter um valor exponencialmente maior do que bom código
- Os efeitos em cadeia dessa mudança são profundos e, ao mesmo tempo, altamente disruptivos
10 comentários
"uma situação em que até mesmo alguém que nunca escreveu uma única linha de código consegue produzir código em escala industrial em poucos segundos" -> se você construir um prédio de apartamentos com palitos de salgadinho, isso conta como escala industrial?
Eu gostava daquela frase do Torvalds... os tempos mudaram completamente, né.
Também sinto uma profunda identificação com a ideia de que "o próprio ambiente de aprendizagem desaparece". Num mundo em que o custo de acesso ao conhecimento está perto de zero, que forma a educação passa a ter agora?
Na realidade, na maioria dos processos de contratação, quase sempre exigem N+ anos de experiência em linguagens como Java.
"Fala" e "texto" são coisas diferentes.
Na verdade, parece que é mais importante escrever bem do que falar bem.
🐎🐎🐎🐎🐎
Kimi no Aiba faz zkyung do kyung~
Há apenas alguns anos, quando eu ia a encontros com colegas de empresa ou grupos de desenvolvedores, costumavam menosprezar engenheiros que não tinham competência, mas só sabiam falar (uma obsessão irrefletida de early adopter por tecnologias e palavras-chave da moda, e no máximo experiência de uso de frameworks e bibliotecas, sem nunca ter construído nem o básico por conta própria...) chamando-os de "linguageiros"... Agora, os "linguageiros" viraram a realidade dos desenvolvedores. Ah, como os tempos mudaram.
Opiniões do Hacker News
Hoje pedi ao Codex para escrever testes unitários para Redux
No começo pareceu aceitável e deixei passar, mas depois, quando fui revisar para adicionar testes eu mesmo, encontrei dezenas de trechos que me fizeram pensar “o que é isso?”
Rodava, mas estava uma bagunça. E era código simples
Tenho experiências parecidas sempre que uso IA — por fora parece ok, mas quando tento expandir vira um desastre e no fim eu preciso arrumar tudo
O problema com a frase “código é barato” é que gerar é barato, mas manter é caro
Gerar milhares de linhas por dia é como acumular dívida no cartão de crédito. Parece de graça, mas a fatura chega depois
Não sei se há algo que possamos influenciar diretamente, mas gostaria de ver o que aconteceu
Aliás, a abordagem de testes do Redux está descrita na documentação oficial
Primeiro é preciso definir a metodologia de testes e, com base nisso, fazer o pedido ao modelo
É preciso cuidado porque a IA assume arbitrariamente o que não foi especificado
No fundo, o ponto central são os testes. Não se deve julgar código de IA no olhômetro; é preciso validar com testes
O valor do código é proporcional ao nível dos testes. Passar por cima com um “LGTM” é como pilotar uma moto de olhos fechados
Em alguns casos funciona bem, em outros sai tudo errado
Por exemplo, dei um caso de uso correto, o código saiu errado, e quando o teste falhou a IA simplesmente reescreveu o teste
Ou seja, existe o risco de ela mesma definir o que conta como sucesso
Uma vez subi duas instâncias do Claude, uma para os testes e outra para a implementação, mas configurar isso foi trabalhoso demais
Por isso acho que essa é uma das razões pelas quais essa tecnologia está sendo empurrada para dentro das equipes
Como na migração para a nuvem, o custo real aparece depois. Só que desta vez acho que vai aparecer bem mais rápido
Fazendo uma analogia com montagem de automóveis,
quem apenas monta peças de acordo com a especificação tem motivo para se preocupar com um braço robótico tomando seu lugar
Mas quem experimenta projetos, faz protótipos e programa o braço robótico se preocupa menos com automação
Muitas objeções dizem que “a IA também vai automatizar esse segundo papel”, mas na prática acho que muita gente confunde o primeiro trabalho com o segundo
Porque consegue depurar, mudar de direção e dar instruções específicas
O usuário comum só repete “isso não funciona, conserte por favor”
Então a forma do trabalho vai mudar, mas a profissão em si não vai desaparecer
Se a IA conseguir imitar isso, ela pode me substituir
Numa economia com pouca concorrência, uma ‘imitação convincente’ já pode ser suficiente
Mesmo um resultado horrível de IA basta, desde que garanta receita e exit
O mundo sempre tolerou ‘lixo distribuído’. Basta olhar para o Windows
Na prática havia muita coisa automatizável, e pelo visto meu ego andou superestimado esse tempo todo
Mas os LLMs de hoje são muito mais gerais e podem assumir qualquer classe de trabalho
Se você mandar um braço robótico “melhorar o design do carro deste ano”, ele vai travar, mas a IA pode opinar
Se a IA puder executar todo o processo de ideia → projeto → construção → teste → avaliação,
então isso é uma inovação essencialmente diferente das tecnologias do passado
Dizer que “a era de escrever código à mão acabou” é exagero
Esse tipo de exagero é uma forma de abalar a confiança profissional das pessoas e provocar FOMO
Não entre em pânico; confie no seu próprio julgamento
Mas é verdade que a tecnologia muda a forma de praticar
No fim, o importante é a capacidade de equilibrar desempenho, custo, prazo e qualidade
Sempre há muita resistência à afirmação de que “a engenharia acabou”,
mas, do meu ponto de vista, em produtos de grande escala escrever código é só uns 10~20% do total
O resto é projeto, experimento, análise, comunicação etc., e é difícil para os LLMs substituir isso
Na verdade, colaboração e coordenação ficam ainda mais complexas, e muitas vezes os LLMs pioram isso
Por isso faz mais sentido ver a IA como ferramenta, não substituta
Eles disseram que “acabou a forma de desenvolver das últimas décadas”, não que a engenharia acabou
Se escrever código é 10~20%, isso significa que o restante da ‘conversa’ ficou ainda mais importante
Como diz o Linus, “mostre que o código funciona como pretendido”
Escrever algumas linhas com LLM é fácil, mas modificá-las com segurança continua difícil
Dizem que a Liz Fong-Jones, da Honeycomb, também já cometeu esse tipo de erro
À medida que as empresas acompanharem o ROI dos LLMs, vão cair na real
Agora estamos no topo do ciclo de hype da Gartner, e parece que em breve vamos descer para o vale da desilusão
Graças ao Claude, refatorei rápido por um tempo, e então em certo momento simplesmente travei
O motivo foi que eu não sabia o que queria
Quando o modelo de dados não está claro e você só diz “continue escrevendo”, o resultado fica muito ruim
programar é uma atividade de curto prazo, mas engenharia de software é um processo de longo prazo
A IA acelera a primeira, mas não substitui a segunda
A premissa de “um plano de desenvolvimento claro e know-how de implementação” não é realista
Programar em si já é um ato de planejamento, e a linguagem é uma excelente ferramenta de pensamento
Por isso existem visões diferentes sobre os LLMs — há quem veja a linguagem como ferramenta de pensamento e quem a veja apenas como ferramenta de execução
Os primeiros enxergam valor na própria programação, os segundos querem esconder o código
No fim, é uma questão de escolha: construir bem o modelo conceitual desde o início ou cair depois no inferno do debugging
As ferramentas atuais não estão ajustadas para a primeira abordagem. Há uma lacuna grande de tooling
Alguns estão combinando as duas coisas e trabalhando de uma forma nova
O significado original de “Talk is cheap” é que “falar é fácil e não tem valor”
Mas “Code is cheap. Show me the talk.” sugere algo ainda mais sem valor do que isso, então já me incomodou desde o começo
E quando li o texto, vi que minha impressão estava certa
O autor não é ignorante em relação a código. Também atua bastante em open source
A ideia é simples — antes era caro implementar um bom projeto em código,
agora ficou barato, então a qualidade do projeto importa mais
“Talk is cheap, show me the code”
O que importa é o modelo mental do desenvolvedor mais do que o código
O código é só um subproduto desse modelo e, sem interpretação humana, não tem significado
Essa visão também influencia bastante o uso de LLM
É difícil concordar com a frase “o jeito como fazemos isso há décadas acabou”
O modo de desenvolver em 2005, 2015 e 2025 já era diferente
Sempre houve mudança, então a premissa de que “foi igual por décadas” está errada
As ferramentas evoluíram, mas a forma de trabalhar do desenvolvedor continuou parecida
o neovim de hoje parece muito mais poderoso do que aquilo
Existe uma tendência de subestimar o progresso gradual dos últimos 30 anos
Naquela época, a maior parte da informação vinha de livros em papel ou engenharia reversa
A frase “Talk is even cheaper, still show me the code” me representa mais
A IA promete produtividade 10x, mas quase nunca vejo isso na prática
Graças à IA, a complexidade ficou mais suportável, mas ainda assim escrever apps em React é sofrido
Lidar com APIs não determinísticas também é difícil
Ainda assim, é bom gastar menos tempo com typos ou procurando exemplos
Mas, por causa da falta de capacidade de raciocínio e dos limites de conhecimento, programar continua tedioso
e depois converte isso em caracteres ANSI para sobrescrever no terminal —
na prática, uma implementação complicada de algo que daria para fazer de forma simples com curses
Frases como “Code is cheap. Show me the talk.” agora estão sendo abusadas como isca de clique
O texto em si não é ruim, mas não traz nada de novo
Não são só as empresas que surfam a onda da IA; blogueiros e influenciadores também fazem o mesmo
Basta colocar um título provocativo em qualquer texto positivo ou negativo sobre IA para isso virar tendência no HN ou no Reddit
Aliás, a origem dessa frase é este tweet e
esta página de meme
Finalmente alguém expressou bem o meio-termo realista entre os extremos
LLM não é deus nem catástrofe. É uma ferramenta
Dá para criticar a extração de renda de empresas como OpenAI, Google e Microsoft
e ainda assim usar modelos locais como Qwen ou Mistral
LLM em nuvem torna E2EE impossível em termos de segurança, então não é adequado para ambientes corporativos
Mas, graças aos LLMs locais, agora uma pessoa sozinha consegue fazer trabalho em nível enterprise
Com um único Mac Mini, dá para cuidar de consultas em banco de dados, integração de API e automação
Se não for uma organização grande, um sênior generalista pode substituir três pessoas de nível pleno
Claro que ainda tenho muitas queixas sobre redução de empregos, problemas de direitos autorais etc.,
mas os LLMs locais já viraram parte do meu kit de ferramentas principal
Parece um texto que eu gostaria de mostrar para pessoas que estão na "fé".