- Ferramentas de programação com base em IA, como LLMs, já ocupam um lugar essencial no trabalho real de desenvolvimento de software
- Muitas pessoas próximas acreditam que IA é uma moda passageira, mas o autor enfatiza que, no desenvolvimento, já passou da hora de mudar de ideia
- Agentes de programação automatizam tarefas repetitivas e tediosas, permitindo que desenvolvedores foquem em trabalho mais significativo
- Há controvérsias sobre qualidade, propriedade e suporte de ferramentas para código gerado por IA, mas em sua maioria elas apenas repetem problemas já existentes no ambiente de desenvolvimento
- Uma postura passiva em relação à adoção de LLMs não é adequada, e tudo indica que mudanças tecnológicas ainda mais importantes estão chegando
Introdução: IA, programação e ceticismo
- Recentemente, executivos de empresas de tecnologia têm mostrado tendência a impor a adoção de ferramentas baseadas em LLM, mas isso é uma estratégia errada
- Entre os desenvolvedores inteligentes ao redor do autor, alguns veem a IA como uma moda passageira, como os NFTs, e não a levam a sério
- Porém, na prática, a adoção de LLMs já provocou grandes mudanças na área de desenvolvimento
- O texto se concentra no significado dos LLMs dentro do desenvolvimento de software, sem entrar em outras áreas como arte, música ou escrita
Agentes de LLM e formas modernas de uso
Nivelando a discussão: LLMs do passado vs. agentes atuais
- Está se espalhando um ambiente de agentes de LLM mais evoluídos, diferente da época de 6 meses a 2 anos atrás, quando se usava ChatGPT ou Copilot de forma simples
- Hoje, desenvolvedores deixam agentes explorarem e modificarem livremente a base de código, automatizando criação de arquivos, compilação, testes e iteração
- Isso inclui fornecimento da árvore de código e de código de fontes externas, extração de informações com ferramentas Unix, interação com Git e execução de várias ferramentas de desenvolvimento
- A lógica real de manipulação de código em si é código de sistema simples
- Fazer copy-paste de código do ChatGPT como antigamente é como não experimentar a mudança essencial
Efeitos positivos dos LLMs
- O código simples e repetitivo que surge na maioria dos projetos pode ser gerado facilmente por LLMs
- LLMs são bons em recuperar informações sem precisar ficar pesquisando ou conferindo documentação, e não sofrem com ineficiência causada por fadiga
- Quando a dificuldade para começar a desenvolver uma funcionalidade vinha da barreira de entrada de uma nova linguagem ou ambiente, os LLMs ajudam muito a reduzi-la
- Refatoração de testes de manutenção, tratamento de dependências e outras tarefas chatas do desenvolvimento podem ser deixadas para LLMs
- Assim, desenvolvedores podem dedicar mais energia a áreas importantes e criativas
Contra-argumento à ideia de que “não dá para entender o código gerado por LLM”
- É natural que o código mesclado pela equipe seja lido e ajustado ao estilo do projeto
- O código produzido por LLMs é previsível em termos algorítmicos, e o resultado pode ser entendido e revisado
- Se faltar capacidade para revisar código repetitivo, provavelmente também haverá dificuldade para lidar com código bagunçado escrito por humanos
Como enxergar o problema das “alucinações” da IA
- Agentes de LLM executam lint, compilação e testes, corrigindo informações falsas e reforçando a confiabilidade
- Em muitos ambientes, o problema das alucinações já foi resolvido em certa medida
- Para usar isso de forma eficaz, é preciso confiar mais no processo automatizado do que em supervisão minuciosa constante
Crítica de que “código de IA tem baixa qualidade”
- O custo de serviços de LLM é menor que o salário de um estagiário (ex.: Cursor.ai por US$ 20/mês)
- Desenvolvedores seniores têm o papel de aumentar a produtividade tanto de estagiários pouco experientes quanto de código gerado por LLM
- Capacidade de usar agentes de programação, tooling e desenho de prompts também forma uma nova área de habilidade técnica
- Há confusão sobre “quem faz qual parte do trabalho”, mas no fundo cabe ao desenvolvedor a direção, validação e julgamento
A polêmica de que “IA vai mal em Rust”
- Limites de compatibilidade com certas linguagens ou ferramentas são um desafio de ecossistemas específicos
- Em linguagens amigáveis para LLMs, como Go, o aproveitamento de IA é muito alto
- Problemas de encaixe com Rust não representam um limite dos LLMs como um todo; é preciso uma estratégia adaptada a cada linguagem
Artesanato de software (craft) e programação no mundo real
- O objetivo do desenvolvimento de software é resolver problemas práticos
- A obsessão desnecessária com qualidade de código vira yak-shaving, o que traz ineficiência ao trabalho real
- Tarefas repetitivas e incômodas devem ser delegadas aos LLMs, enquanto desenvolvedores concentram suas capacidades nas partes de geração de valor
Aceitar a mediocridade do código de IA
- Na maioria dos casos, não há problema se grande parte do código for apenas mediana
- O importante é elevar a qualidade nas partes críticas e, nas demais, transformar a redução de custo via LLM em vantagem
- Código de LLM é mais seguro nas partes repetitivas e, em áreas algorítmicas, pode oferecer abordagens mais amplas que as humanas
Opinião sobre a visão de que “a AGI ainda está longe”
- O autor não se interessa pela discussão sobre AGI; o que importa é se funciona na prática
- O critério de decisão imediato é desempenho real e ganho de produtividade
Polêmica sobre substituição de empregos
- Assim como aconteceu com a adoção de open source, os LLMs também são uma tecnologia que provoca mudança e desaparecimento de profissões
- Desenvolvedores de software também precisam reconhecer que, como em outras indústrias, são alvos de automação
- Ainda não está claro se essa mudança será benéfica ou prejudicial no fim, mas a mudança em si é inevitável
Questões de plágio/direitos autorais
- A IA está se tornando uma grande ameaça para o campo das artes visuais
- Na prática, LLMs realmente conseguem gerar em massa resultados com qualidade industrial
- Para desenvolvedores de software, é difícil levantar a questão do plágio
- Historicamente, desenvolvedores já foram pouco sensíveis a direitos autorais e preferiram compartilhamento e reprodução à proteção de propriedade intelectual
- A discussão sobre reutilização de partes de código não passa de uma espécie de desculpa específica
Uso mais recente de LLMs e velocidade da mudança
- O uso de agentes assíncronos baseados em LLM e de trabalho em paralelo aumenta muito a produtividade
- Mesmo desenvolvedores excelentes usam LLMs para revisão e melhoria de código, experimentando utilidade real em um ambiente não estático
- Áreas ligadas à confiança, como acesso a infraestrutura importante, ainda precisam ser tratadas com cautela
Conclusão: mudança tecnológica e superação do ceticismo
- Diferentemente dos céticos tradicionais da IA, o autor mantém uma visão conservadora, mas sente na prática que a mudança já aconteceu
- Chegou a hora de desenvolvedores de software superarem contra-argumentos ultrapassados e aceitarem a mudança real
- LLMs e programação baseada em IA devem provocar uma mudança estrutural profunda no setor, assim como fizeram os smartphones e a internet
4 comentários
Definitivamente é útil para escrever scripts simples de uso único. Economiza muito tempo.
Também é útil em casos que precisam ser resolvidos, mas nos quais não dá para investir muito tempo. Ainda assim, por enquanto, embora em geral seja útil, não consegue substituir completamente uma pessoa. Não dá para saber o quanto vai evoluir no futuro, mas, neste momento, como assistente, está num nível mais ou menos utilizável.
Seja fanático por IA ou cético, quando a pessoa vai para o extremo dá vontade de manter distância.
Sempre dá uma canseira ver gente gritando "a singularidade está chegando".
Opinião no Hacker News
Se você tentou escrever código com LLMs há 6 meses e falhou, isso só quer dizer que fez diferente da maioria dos desenvolvedores que hoje usa LLMs seriamente. Mas eu sempre fui cético com esse coro dizendo que a tecnologia é revolucionária. Há 6 meses também diziam que, se você não usasse o LLM mais recente, estava desatualizado e não sabia usar direito; no fim, todo mundo acabou admitindo que os LLMs antigos não eram lá essas coisas. Parece só uma repetição do fenômeno do 'menino da IA apareceu'. Agora dizem de novo que a produtividade no trabalho vai disparar, mas fico me perguntando com base em quê eu deveria acreditar que desta vez a afirmação é verdadeira. Aposto que daqui a 6 meses vão dizer mais uma vez que os produtos de LLM que usamos até agora eram ruins.
Um gráfico exponencial parece ter a mesma curva em qualquer ponto do tempo. Durante um bom tempo os computadores melhoraram absurdamente ano após ano, e isso não significa que o computador que você comprou era lixo, mas sim que a tecnologia estava de fato avançando muito rápido. A ideia aqui é que essa fadiga que você sente, de tudo estar sempre melhorando, é justamente resultado de um progresso realmente revolucionário.
Se você pedisse ajuda a um ser humano a cada 6 meses do nascimento até os 30 anos, em que momento ficaria impressionado? Isso varia conforme a pessoa e a tarefa, mas com o passar do tempo cada vez mais gente acabaria admirando essa capacidade. A evolução dos LLMs parece a velocidade de ver uma criança crescer. Eu mesmo não usava LLMs antes, mas desde o o3 e o Gemini 2.5 Pro passei a usar sempre. Se você ainda não se impressionou depois de testar os modelos mais recentes, aposto que vai se impressionar dentro de 3 anos.
tptacek não fazia esse tipo de afirmação 6 meses atrás. Os LLMs vão melhorando com o tempo e, de vez em quando, também rompem barreiras em coisas que antes não funcionavam. Nos últimos 6 meses foi o ponto em que a 'programação baseada em agentes' começou a funcionar de verdade. Ter a mentalidade de 'como dizem a cada 6 meses que melhorou, não vou levar a sério' pode prejudicar sua capacidade de avaliar tecnologia corretamente.
Há quem diga que a essência do problema está no 'ponto de inflexão'. Algumas pessoas só colam código no ChatGPT e saem insatisfeitas, enquanto outras obtêm resultados muito melhores com agentes que conseguem ver todo o contexto do código. No fim, não é só o LLM em si que importa, mas também a diferença de fluxo de trabalho.
Gosto do argumento do Thomas, mas acho que ali também existe um erro essencial que muita gente comete. Programadores habilidosos precisam acumular muita experiência para usar bem LLMs, e o próprio Thomas construiu essa especialização ao longo do tempo. Mas talvez sejamos a última geração que cresceu sem apoio de LLM. Fico me perguntando como um iniciante recém-saído da escola vai sair do 'vibe coding' e desenvolver habilidade de verdade. No passado, as pessoas evoluíam construindo com as próprias mãos; agora corremos o risco de simplesmente delegar todo o projeto e a montagem ao robô, sem aprender como as ferramentas e os materiais realmente funcionam. A crítica é que talvez passemos a entender até a carga de um telhado apenas no 'feeling'.
Há quem diga que as vantagens dos agentes de IA ficam claras quando um especialista consegue ler, entender e integrar o código do LLM à base de código. Mas se todo mundo programar com IA, como vamos formar de fato os 'editores' capazes de ler código cada vez mais complexo, identificar riscos, saber o que e como testar e manter na cabeça a arquitetura da base inteira? Hoje, essas habilidades exigidas de um editor são algo que se aprende escrevendo código diretamente por muito tempo. Se o iniciante terceiriza o raciocínio, não tem chance de desenvolver essas capacidades. Surge também a preocupação sobre de onde virão os profissionais experientes. Como professor, é amargo ver que deveres e tarefas já viraram algo que passa no LLM sem reflexão nenhuma. Parece que vamos precisar de uma nova forma de desenvolver competência, mas ainda não está claro qual seria, e fica a dúvida sobre como iniciantes vão virar especialistas nesse mundo.
A resposta contrária é: se todo mundo só usar calculadora, como vai aprender matemática? A ideia é fazer os alunos praticarem bastante à mão e aprenderem a essência primeiro, para só depois introduzir LLMs como se introduz uma calculadora.
Alguém comenta que isso lembra o conto "Profession", de Isaac Asimov. Nele, a maioria das pessoas recebe capacidades e profissões diretamente do computador; com isso trabalham bem, mas não desenvolvem inovação nem criatividade. Só uma minoria incompatível com essa tecnologia aprende de verdade e acaba sendo o único grupo capaz de fazer a arte avançar.
Pela minha experiência, LLMs são mais parecidos com um programador em par e, para iniciantes, funcionam quase como um engenheiro sênior. Além de código, são excelentes como tutores para explicar princípios e processos. Para sêniores, oferecem várias vantagens: revisão de código, brainstorming de ideias, tratamento de boilerplate e mais. Do ponto de vista de um especialista, dá para focar diretamente nos 10% difíceis do trabalho e delegar o resto ao LLM, economizando tempo. Se o iniciante só copiar código sem interesse nem curiosidade, isso é problema do desenvolvedor; para quem quer aprender ativamente, LLM é um recurso de aprendizado de altíssimo nível. Nesse sentido, para iniciantes este é o melhor momento da história.
Esta thread inteira parece mostrar as etapas psicológicas clássicas do tipo 'o problema não existe – existe, mas não é grande coisa – ah, existe mesmo, então vamos nos adaptar'. Dá a impressão de que tocaram em um dos problemas realmente centrais.
Também concordo que, se um iniciante depender totalmente do LLM para pensar, vai ter dificuldade para crescer. Ainda assim, eu vivo aprendendo coisas novas com LLM. Lanço perguntas sobre APIs que conheço só vagamente, leio os resultados e aprendo os conceitos; em geral, também acabo mexendo no código e refatorando. Há poucos dias fiquei curioso sobre o funcionamento interno de signals, o LLM me deu exemplos e fui analisando junto. Se houver curiosidade, ele pode ser um tutor inacreditável. Júnior não deveria simplesmente fazer 'vibe coding'; o importante é ter postura ativa de aprendizado. Se não tiver, a responsabilidade é da própria pessoa e, numa realidade já irreversível, ainda existem muitos caminhos de crescimento para quem tiver curiosidade.
Alguém relata ter usado recentemente algo como o agente do Claude 4 em vários casos: uma grande base de código em C (novos recursos, correções de bugs), um pequeno projeto em Rust, um pequeno frontend e até um frontend novo com documentação básica de API. Em todos os casos, a experiência foi um fracasso completo. Recebia diffs errados, passava argumentos errados para ferramentas, falhava em funcionalidades básicas, fazia refatorações sem sentido de centenas de linhas e ainda deixava refactors inacabados que bagunçavam toda a base. Em frameworks JS ricos em dados como Svelte e solidJS, o resultado também foi ruim. A pessoa diz não entender qual seria, na prática, a grande força desses agentes tão elogiados; parece mais exagero de marketing.
Há quem pergunte como os prompts foram escritos. Em geral, quando se divide uma funcionalidade em tarefas menores e mais detalhadas para pedir ao LLM, ele funciona muito melhor. Tarefas individuais de 10 a 200 linhas costumam sair bem; acima disso, começam as tarefas de continuação e a frustração. O nível atual é de uma autonomia parecida com a de um estagiário inteligente, mas sem experiência. Projeto completo e planejamento difícil continuam sendo trabalho humano.
Hipótese: até quem promove agentes acaba entregando apenas código espaguete e não se importa, porque para essas pessoas só a produtividade aumentou. Quase não se vê caso real de sucesso detalhando ferramentas e métodos concretos; e isso poderia até ser documentado pela própria IA, mas nem isso acontece.
Dizem que muitos posts sobre agentes parecem peças promocionais. Há dinheiro demais concentrado no mercado de IA, e lembranças de campanhas de marketing anteriores só aumentam a desconfiança. A pessoa testou vários produtos de agentes e viu pouca melhoria real. No HN, como também há muitos pessimistas que temem a IA, quando a discussão esquenta acaba surgindo um clima de que, se há problema, a culpa é do usuário. Um usuário chegou a dizer que 'só dá para experimentar direito usando IA a mil dólares', o que pareceu propaganda.
Se você limitar as mudanças do LLM a código pequeno, arquivo único ou blocos de menos de 50 linhas, fica bem mais fácil de gerenciar.
Para quem aprendeu a programar desde os anos 90, já é espantoso por si só que agora seja possível dar entradas vagas e ambíguas a um computador e ainda assim receber resultados significativos. Parece ficção científica viver num mundo em que um nível de ambiguidade humano gera saídas claras e úteis.
Por outro lado, muitas vezes até quando você dá uma entrada muito clara, o computador a interpreta de forma ambígua para transformá-la em um problema mais fácil de resolver.
Eu acho que essa ambiguidade dos LLMs é exatamente o que os torna atraentes para conversar com documentação. Não preciso ficar reformulando várias buscas até encontrar a informação que quero, e isso economiza bastante tempo no geral.
É realmente uma era impressionante; há quem diga que fica maravilhado com a realidade uma ou duas vezes por semana.
Alguém lembra que era fã de Star Trek: The Next Generation e ficava imaginando a diferença entre o computador da Enterprise e o Data. O computador da nave conseguia organizar conhecimento, resumir e executar tarefas, algo muito parecido com a IA atual; já o Data era um robô com habilidades individuais. O fato de o Data ter limitações em humor, arte e outras áreas da sensibilidade humana lembra bastante a arte de IA de hoje. Vêm à tona também lembranças das sutilezas de ambientação e desenvolvimento do começo da série.
Entrei neste setor justamente pela ideia de dar instruções claras à máquina e obter exatamente o que eu queria. Dijkstra já enfatizava há muito tempo a ambiguidade da linguagem humana e a importância das 'linguagens formais' criadas para superá-la. No fim, há um olhar meio amargo sobre 2025: a era do 'prompt engineering' e do 'vibe coding', em que passamos o tempo discutindo com o computador e corrigindo sua forma. Recomenda-se a leitura de EWD667: The Humble Programmer.
Há quem questione se as pessoas que defendem capacidades ilimitadas da IA generativa conseguem mostrar provas reais. Se GAI ou agentes fossem de fato tão poderosos, isso deveria ficar evidente em resultados como abrir uma empresa só com IA e produzir código de altíssima qualidade em pouco tempo. Mas não há sinais disso. Até agora, o uso mais útil continua sendo gerar texto e arte que humanos possam tomar por significativos. Na experiência de startups que testaram isso no trabalho real, às vezes serve para explorar APIs ou encontrar informação conveniente, mas no saldo geral o desperdício de tempo foi maior. Já passou da hora de, em vez de apenas dizer que é 'bom', mostrar diretamente resultados produzidos de forma genuína pela IA.
Há quem veja uma divergência de perspectiva. Sempre existiu um limite entre mudanças viáveis na prática, com boa relação esforço/retorno, e tarefas que ficam largadas no backlog; ferramentas de IA reduzem esse custo-limite e tornam mais tarefas tentáveis. Por isso, quem fala em 'produtividade 5x' destaca o aumento do volume de código efetivamente processado, enquanto o cético entende que o valor essencial do negócio não mudou tanto. Recomenda-se também O paradoxo da produtividade da IA.
Outra pessoa pergunta que tipo de prova concreta se quer ver. A exigência é por capacidade infinita ou por utilidade realista? Ninguém está dizendo que isso é totalmente onipotente; a ênfase é que fica útil quando usado por quem entende corretamente seus limites e pontos fortes. Como exemplo, citam um histórico recente de commits em cloudflare/workers-oauth-provider e perguntam se pelo menos não daria para concordar que existe alguma utilidade.
Muita gente já usa, na prática, código gerado por LLMs. Há relatos de PRs com uso de LLM entrando em produção há meses. O conselho é que, se você ainda não encontrou utilidade, talvez simplesmente não tenha aprendido a usar direito.
Quando vejo gente divulgando que LLM quase não funciona, parece que estou assistindo ao marketing operar em tempo real. Empresas em que eu confiava antes também ficaram decepcionantes por se inclinarem demais à promoção de IA. A mensagem passa a ser: se o benefício for real, então vá lá e use você mesmo.
Surge a metáfora de 'vender picaretas na corrida do ouro'. A crítica é a uma estrutura de marketing que, em vez de provar a eficácia da ferramenta, tenta apenas convencer as pessoas de que existe ouro.
Há críticas à postura de ignorar o problema das licenças de código no GitHub. Alguns desenvolvedores dizem 'não ligue para copyright', mas partir da premissa de que todos os programadores são criminosos habituais de violação de direitos autorais é uma generalização errada. Muitos, incluindo quem comenta, não têm nada a ver com pirataria em larga escala e, pelo contrário, se esforçam para respeitar o copyleft e o espírito do open source. É possível ver o SciHub como um bem público e, ao mesmo tempo, respeitar o copyleft pretendido por desenvolvedores individuais. Copyright não é uma questão simplesmente de ser a favor ou contra. Ignorar essa diversidade e esse contexto para condenar tudo em bloco, ou justificar o desprezo por licenças, é que seria a atitude intelectualmente preguiçosa.
Programadores muitas vezes não entendem bem de direito, especialmente da common law dos EUA. A tradição jurídica foi escrita ao longo de muito tempo assumindo interpretação racional por seres humanos e, mesmo que ferramentas de IA sejam projetadas para distribuir ou evitar responsabilidade, no fim a lei vai encontrar alguém para responsabilizar e punir. A previsão para depois do boom da IA seria: 1) empresas e governos tentam diluir responsabilidade, 2) surgem incidentes de efeitos colaterais, como acidentes de carro, algoritmos discriminatórios e vazamento de dados, 3) os tribunais devolvem a responsabilidade a humanos com multa ou punição, 4) outras empresas passam a limitar IA por medo do risco. Nesse fluxo, ferramentas de IA acabam sobrevivendo apenas dentro da esfera da responsabilidade humana.
Há mais de 25 anos como desenvolvedor de software livre, alguém diz gostar de várias licenças. Tem também um cônjuge diretor e artista visual, mas afirma claramente que não toca em conteúdo relacionado a IA e o considera lixo. Não quer ter contato com isso.
O desafio tipo Konwinski Prize, que paga US$ 1 milhão se um LLM open source resolver mais de 90% de issues inéditas do GitHub, parece interessante. Veja a competição Konwinski Prize. Até agora, mesmo os melhores modelos estão em 0,09, muito longe de 0,9, então isso ainda estaria muito distante de uso prático. Mesmo que open source fique um pouco abaixo dos modelos comerciais, escrever código de forma independente com LLM ainda parece quase impossível. Eles produzem muito lixo, mas continuam tendo utilidade, nem que seja pela necessidade de avaliação e gerenciamento.
Mesmo que a IA assuma tarefas repetitivas de boilerplate, agora o que se repete é a revisão entediante desse código gerado por IA, e no fim a atividade fica menos divertida, toma tempo parecido e ainda traz menos compreensão.
Quem defende desenvolvimento com IA parece, no fundo, gostar mais de revisão de código do que de programar. Pode ser gosto pessoal, mas para alguns isso é algo sofrível por si só.
Em termos exatos, revisar grandes quantidades de código costuma levar menos tempo do que escrever esse código do zero. Principalmente quando ele passa nos testes; e como o próprio LLM também pode gerar testes, isso reduz a carga.
Claude, Gemini e afins são muito mais rápidos do que eu programando sozinho e, mesmo relendo duas vezes, ainda gasto menos tempo do que gastaria escrevendo tudo.
Antes, escrevíamos código para tarefas repetitivas de 'yak shaving'; agora a realidade é revisar uma depilação malfeita do 'iaque'.
No geral, haverá inevitavelmente maior gasto de energia e emissões de carbono.
Surge uma conversa sobre tradução automática e reconhecimento de voz. Do ponto de vista de alguém quase surdo, essa tecnologia é usada o dia inteiro. Antes era impossível aproveitar dramas dos anos 80 sem legendas, mas com LLMs como Whisper agora dá para extrair legendas de vídeos, e isso parece um milagre: algo antes apenas imaginado virou realidade.
O estado da arte mais recente em reconhecimento de fala e tradução ainda é dominado por modelos especializados de tarefa única, mas a diferença está diminuindo rápido, e LLMs permitem uma variedade muito maior de tarefas. (Exemplo: leaderboard de reconhecimento de fala.) LLMs abrem um campo de possibilidades bem amplo.
Durante anos, várias tentativas de reconhecimento de voz, como Dragon, foram impressionantes, mas incômodas no uso real. A combinação de Whisper com LLM foi o primeiro momento em que isso trouxe utilidade concreta. Ainda não é perfeito, mas o trabalho manual caiu para um décimo, e para anotações pessoais já chega a ser confortável a ponto de nem validar mais.
Ainda assim, a pessoa não confiaria apenas em tradução por LLM para tarefas realmente de alto risco, como contrato de trabalho em outro país ou depoimento à polícia. Conversão de voz em texto já existia antes; dá para sentir o avanço, mas ainda é algo do cotidiano e de baixo risco, longe do nível de uso em negociações interplanetárias de romances de ficção científica.
Outra pessoa diz sentir que os avanços recentes estão finalmente cumprindo promessas que via quando criança na ficção científica. Dias atrás, numa cidade desconhecida, fotografou um cardápio, extraiu manuscrito em chinês, traduziu na hora para o inglês e ainda aprendeu a pronúncia do prato desejado para fazer o pedido. A convicção é de que, há 2 anos, isso ainda seria impossível.
Há quem considere tradução o caso de uso perfeito para LLMs. Eles conseguem refletir conceitos sociais, contexto cultural, cultura popular e referências raras, além de gerar várias versões adaptadas a diferentes idiomas e culturas. A convicção é que, nisso, eles já estão muito à frente da tradução tradicional.