- Las herramientas de programación basadas en IA, como los LLM, ya ocupan un lugar esencial en el desarrollo de software real
- Muchas personas cercanas creen que la IA es una moda pasajera, pero el autor insiste en que, al menos en desarrollo, ya es momento de cambiar de opinión
- Los agentes de código automatizan tareas repetitivas y aburridas, permitiendo que los desarrolladores se enfoquen en trabajo más significativo
- Aunque existen debates sobre la calidad, propiedad y soporte de herramientas del código generado por IA, en su mayoría solo repiten problemas ya presentes en los entornos de desarrollo tradicionales
- Tener una actitud pasiva frente a la adopción de LLM no es lo correcto, y todo indica que se acerca un cambio tecnológico aún más importante
Introducción: IA, programación y escepticismo
- Últimamente, los ejecutivos de empresas tecnológicas tienden a imponer la adopción de herramientas LLM, pero esa es una estrategia equivocada
- Entre los desarrolladores inteligentes que rodean al autor, algunos consideran que la IA es una moda pasajera como los NFT y no se la toman en serio
- Sin embargo, en la práctica, la adopción de LLM ya provocó grandes cambios en el ámbito del desarrollo
- El texto se enfoca en el significado de los LLM dentro del desarrollo de software y no aborda otras áreas como arte, música o escritura
Agentes LLM y formas modernas de uso
Poner el nivel al día: los LLM del pasado vs. los agentes actuales
- Se está expandiendo un entorno evolucionado de agentes LLM, muy distinto a la época de hace 6 meses a 2 años, cuando solo se usaban ChatGPT o Copilot de forma simple
- Hoy, los desarrolladores permiten que los agentes exploren y modifiquen libremente el código base, automatizando la creación de archivos, compilación, pruebas e iteración
- Esto incluye soporte para entregar árboles de código y código de fuentes externas, extraer información con herramientas Unix, interactuar con Git y ejecutar diversas herramientas de desarrollo
- La lógica real de manipulación del código en sí es código de sistema bastante simple
- Seguir copiando y pegando código desde ChatGPT, como antes, equivale a no experimentar el cambio esencial
Efectos positivos de los LLM
- En la mayoría de los proyectos, el código simple y repetitivo puede ser generado fácilmente por un LLM
- Los LLM son buenos para recuperar información sin necesidad de buscar o revisar documentación, y no sufren la ineficiencia causada por el cansancio
- Cuando empezar a desarrollar una función era difícil por la barrera de entrada de un nuevo lenguaje o entorno, los LLM pueden reducir mucho ese obstáculo
- Refactorizar pruebas de mantenimiento, manejar dependencias y otras tareas molestas del desarrollo pueden delegarse al LLM
- Así, el desarrollador puede dedicar más energía a las áreas importantes y creativas
Réplica a la idea de que “no puedes entender el código generado por LLM”
- Es natural que el código que se fusiona en el equipo se lea directamente y se ajuste al estilo correspondiente
- El código que produce un LLM es predecible en términos algorítmicos, por lo que el resultado puede entenderse y revisarse
- Si alguien no tiene la capacidad de revisar código repetitivo, probablemente tampoco podrá digerir código desordenado escrito por desarrolladores humanos
Cómo ver el problema de las “alucinaciones” de la IA
- Los agentes LLM ejecutan lint, compilación y pruebas para corregir información falsa y ganar confiabilidad
- El problema de las alucinaciones ya está resuelto hasta cierto punto en la mayoría de los entornos
- Para usarlos con eficacia, hace falta confiar en el proceso automatizado más que vigilarlos al detalle
Crítica de que “el código de IA es de baja calidad”
- El costo de los servicios LLM es menor que el salario de un pasante (por ejemplo, Cursor.ai cuesta $20 al mes)
- Un desarrollador senior cumple la función de elevar la productividad tanto de un pasante poco competente como del código generado por LLM
- La capacidad de usar agentes de código, el tooling y el diseño de prompts también forman parte de una nueva área de habilidad técnica
- Hay confusión sobre quién se encarga de qué trabajo, pero en el fondo el desarrollador sigue siendo responsable de la dirección, la validación y el juicio
La controversia de que “la IA rinde mal en Rust”
- Las limitaciones de compatibilidad con ciertos lenguajes o herramientas son una tarea pendiente de ecosistemas específicos
- En lenguajes amigables con los LLM como Go, el aprovechamiento de la IA es muy alto
- Los problemas de compatibilidad con Rust no representan una limitación general de los LLM; hace falta una estrategia adaptada a cada lenguaje
La artesanía (Craft) y la programación práctica
- El desarrollo de software tiene como objetivo resolver problemas prácticos
- Obsesionarse innecesariamente con la calidad del código es una forma de "yak-shaving", y en el trabajo real termina siendo ineficiente
- Las tareas repetitivas y tediosas deben delegarse a los LLM, para que el desarrollador concentre sus capacidades en las zonas donde se crea valor
Aceptar la mediocridad del código de IA
- En la mayoría de los casos, no pasa nada si el código no es extraordinario
- En las partes importantes se debe elevar la calidad, y en las demás conviene aprovechar el ahorro de costos mediante LLM
- El código generado por LLM es más seguro en las partes repetitivas y, en el área algorítmica, puede tener un enfoque más amplio que el humano
Opinión sobre la idea de que “todavía estamos lejos de la AGI”
- Al autor no le interesa demasiado el debate sobre la AGI; lo único importante es si funciona en la práctica
- El criterio para decidir hoy es el rendimiento real y el aumento de productividad
La controversia sobre el reemplazo de empleos
- Igual que ocurrió con la adopción del open source, los LLM son una tecnología capaz de transformar o eliminar ocupaciones
- Los desarrolladores de software también deben reconocer que, como en otras industrias, ellos mismos son objeto de automatización
- No está claro si este cambio será beneficioso o perjudicial al final, pero el cambio en sí es inevitable
Problemas de plagio y copyright
- La IA se está convirtiendo en una gran amenaza para el mundo del arte visual
- En la práctica, los LLM pueden generar en masa resultados que cumplen con calidad de nivel industrial
- A los desarrolladores de software les cuesta mucho cuestionar el problema del plagio
- Desde antes, los desarrolladores han sido poco sensibles al copyright y han preferido compartir y reproducir más que proteger la propiedad intelectual
- El debate sobre la reutilización de fragmentos de código no pasa de ser una excusa muy particular
Uso reciente de LLM y velocidad del cambio
- El uso de agentes asíncronos basados en LLM y el trabajo en paralelo ha mejorado mucho la productividad
- Incluso desarrolladores sobresalientes usan LLM para revisar y complementar código, y ya están experimentando utilidad real en un entorno no estático
- En áreas donde hay temas de confianza, como el acceso a infraestructura crítica, todavía hace falta actuar con cautela
Conclusión: cambio tecnológico y superación del escepticismo
- A diferencia de los escépticos tradicionales de la IA, el autor mantiene una postura conservadora pero aun así percibe el cambio real
- Ya es momento de que los desarrolladores de software dejen atrás objeciones anticuadas y acepten el cambio realista
- Se proyecta que los LLM y la programación basada en IA impulsarán un cambio estructural profundo en la industria, como lo hicieron los smartphones e internet
4 comentarios
Definitivamente es útil cuando quieres escribir un script simple de un solo uso. Ahorra muchísimo tiempo.
También sirve en casos que hay que resolver, pero en los que no puedes invertir mucho tiempo. Eso sí, aunque por ahora en general es útil, todavía no puede reemplazar por completo a una persona. No sé cuánto vaya a avanzar en el futuro, pero por ahora, como asistente, está más o menos en un nivel bastante usable.
Tanto si son creyentes de la IA como si son escépticos, cuando se van a los extremos me dan ganas de evitarlos.
Cada vez que los veo gritando "la singularidad se acerca", de verdad es agotador.
Opinión de Hacker News
Si intentaste escribir código con un LLM hace 6 meses y fracasaste, eso solo significa que lo estabas usando de forma distinta a como lo hacen la mayoría de los desarrolladores que lo aprovechan en serio. Pero yo sigo sintiendo escepticismo frente a quienes insisten en que esta tecnología es revolucionaria. Hace 6 meses también decían que si no usabas los LLM más recientes estabas atrasado y que no los sabías usar bien, pero al final ahora todos parecen admitir que los LLM de antes eran malos. Se siente como el fenómeno del "ahí viene el niño de la IA" repitiendo excusas una y otra vez. Esta vez dicen otra vez que la productividad sube de forma radical, pero me pregunto con qué base se supone que debemos creer que ahora sí es verdad. Mi predicción es que en otros 6 meses volverán a decir que los productos LLM actuales también eran malos.
La gráfica de una función exponencial se ve parecida en cualquier punto del tiempo. Durante un buen tiempo las computadoras mejoraron muchísimo cada año, y eso no era porque la computadora que acababas de comprar fuera basura, sino porque la tecnología de verdad avanzaba muy rápido. La idea es que esa fatiga que sientes porque todo sigue mejorando podría ser, precisamente, el resultado de un progreso realmente revolucionario.
Si desde los 0 hasta los 30 años le pidieras ayuda a un ser humano cada 6 meses, ¿en qué momento te sorprendería? El punto en que te asombrarías dependería de la persona o de la tarea, pero con el tiempo cada vez más gente terminaría impresionada por sus capacidades. El avance de los LLM se siente parecido a ver crecer a un niño. Yo antes tampoco usaba LLM, pero desde o3 y Gemini 2.5 Pro los uso siempre. Si todavía no te impresionan después de probar los modelos más nuevos directamente, apostaría a que dentro de 3 años sí lo harán.
tptacek no estaba haciendo esta afirmación hace 6 meses. Los LLM van mejorando con el tiempo, y a veces incluso logran romper barreras en cosas que antes simplemente no funcionaban. En los últimos 6 meses es cuando la "programación basada en agentes" realmente empezó a funcionar. Adoptar una mentalidad de "como cada 6 meses dicen que mejoró, no lo voy a tomar en serio" puede terminar dañando tu capacidad para evaluar bien una tecnología.
Hay quien opina que la esencia del problema está en el "punto de inflexión". Algunas personas solo pegan código en ChatGPT y quedan decepcionadas, mientras que otras obtienen resultados mucho mejores usando agentes que pueden ver todo el contexto del código. Al final, no solo importa el LLM concreto, sino también la diferencia en el flujo de trabajo.
Me gusta el argumento de Thomas, pero creo que incluso ahí hay un error fundamental que mucha gente comete. Un programador hábil necesita acumular mucha experiencia para usar bien los LLM, y Thomas también fue construyendo esa especialización con el tiempo. Pero quizá somos la última generación que creció sin apoyo de LLM. Me pregunto cómo alguien que apenas salió de la escuela podrá dejar atrás el "vibe coding" y desarrollar habilidades reales. Antes uno crecía construyendo cosas con sus propias manos, pero ahora existe el riesgo de simplemente delegar todo el diseño y ensamblaje a un robot sin aprender cómo funcionan de verdad las herramientas o los materiales. El problema es terminar entendiendo incluso la carga de un techo solo "por intuición".
Hay quien dice que las ventajas de los agentes de IA se vuelven claras cuando un experto puede leer el código generado por LLM, entenderlo e integrarlo en la base de código. Pero si todos programan con IA, entonces ¿cómo vamos a formar a verdaderos "editores" capaces de leer código cada vez más complejo, detectar riesgos, saber qué y cómo probar, y mantener en la cabeza la estructura completa de una base de código? Hoy esas habilidades necesarias para editar bien se adquieren escribiendo código directamente durante mucho tiempo. Si un principiante terceriza el pensamiento, no tiene oportunidad de desarrollar esas capacidades. También preocupa de dónde van a salir los futuros expertos. Desde la perspectiva de un profesor, es amargo ver que las tareas ya pasan con LLM sin mucha reflexión. Parece que hará falta una nueva forma de desarrollar habilidades, pero todavía no se me ocurre cuál, y sigo preguntándome cómo los principiantes van a convertirse en expertos en un mundo así.
La respuesta sería: si todos usan calculadora, ¿entonces cómo se aprende matemáticas? La idea es que a los estudiantes primero hay que hacerlos practicar lo suficiente a mano y aprender la esencia del asunto, y solo después introducir el LLM como si fuera una calculadora.
Alguien comenta que esto le recuerda al cuento corto "Profession" de Isaac Asimov. En él, la mayoría de la gente recibe sus capacidades y profesiones directamente de una computadora, y por eso trabaja bien, pero no desarrolla ninguna innovación ni creatividad. En cambio, solo unos pocos incompatibles con ese sistema aprenden de verdad y terminan siendo el único grupo capaz de hacer avanzar el arte.
En mi experiencia, el LLM se parece más a un programador en pareja y, para un principiante, actúa casi como un ingeniero senior. No solo genera código: también funciona excelentemente como tutor explicando principios y procesos. Para un senior ofrece varias ventajas, como revisión de código, lluvia de ideas y manejo del boilerplate. Desde la perspectiva de un experto, puedes concentrarte tú mismo en el 10% difícil y delegar el resto del trabajo simple al LLM, con el consiguiente ahorro de tiempo. Si un principiante no tiene interés ni curiosidad y solo copia código, ese es problema del desarrollador. Para quien sí quiere aprender activamente, el LLM es un recurso de aprendizaje de primer nivel. En ese sentido, para los principiantes esta es la mejor época posible.
Todo este hilo parece mostrar las etapas psicológicas clásicas de "el problema no existe – sí existe, pero no es gran cosa – ah, sí existe de verdad, adaptémonos". Da la impresión de que se tocó uno de los problemas realmente centrales.
Yo también coincido en que, si un principiante depende por completo del LLM para pensar, le costará desarrollar habilidad. Aun así, en mi caso aprendo cosas nuevas todo el tiempo gracias al LLM. Le planteo problemas sobre APIs que conozco vagamente, leo el resultado y así voy entendiendo conceptos; además casi siempre termino modificando y refactorizando el código. Hace unos días, por ejemplo, tenía curiosidad por el funcionamiento interno de signals, así que el LLM me dio ejemplos y los analizamos juntos. Si tienes curiosidad, puede ser un tutor increíble. Un junior no debería limitarse a hacer "vibe coding"; lo importante es mantener una actitud activa de aprendizaje. Si no lo hace, es su responsabilidad; y como esta realidad ya no tiene vuelta atrás, mientras exista curiosidad, hay camino para crecer.
De hecho, hace poco intenté usar algo como el agente de Claude 4 en varios casos: una gran base de código en C (funciones nuevas, corrección de bugs), un proyecto pequeño en Rust, un frontend pequeño y un frontend nuevo con documentación básica de API. En todos los casos la experiencia fue un fracaso total. Entregaba mal los diff, pasaba argumentos incorrectos a las herramientas, fallaba en funciones básicas, refactorizaba cientos de líneas sin sentido, y dejaba refactors incompletos que terminaban arruinando la base de código. Incluso en frameworks JS con muchos datos como Svelte o solidJS, los resultados fueron malos. De verdad no entiendo cuál sería la fortaleza real de esos agentes que tanta gente elogia; más bien se siente como exageración de marketing.
Alguien pregunta cómo redactas los prompts. En general, si divides una funcionalidad en tareas más pequeñas y detalladas para pedírselas al LLM, suele funcionar mucho mejor. Las tareas individuales (de unas 10 a 200 líneas) las ejecuta bien, pero más allá de eso solo vienen tareas de seguimiento y decepciones. En este momento su nivel de autonomía es como el de un interno inteligente pero sin experiencia. El diseño global complejo y la planificación siguen siendo trabajo humano.
La hipótesis es que quienes promocionan agentes en realidad también producen puro código espagueti, pero no les importa porque sienten que igual aumentó su productividad. Hay pocos casos donde alguien publique ejemplos concretos de éxito, incluyendo herramientas y método; y eso mismo incluso podría documentarlo la propia IA, pero ni siquiera hacen eso.
También se dice que muchos textos sobre agentes parecen artículos promocionales. Hay demasiado dinero metido en el mercado de IA, y eso hace que cueste más confiar, especialmente recordando campañas de marketing anteriores. Yo mismo he probado varios productos de agentes y la mejora real ha sido poca. En Hacker News más bien abundan los pesimistas que temen a la IA, así que cuando hay mucha discusión termina instalándose la idea de que el problema debe ser culpa del usuario. Un usuario incluso dijo que "hay que gastar 1000 dólares de verdad en IA para experimentar bien su potencial", lo cual huele a publicidad.
Si haces que el LLM limite los cambios a código pequeño, un solo archivo o bloques de menos de 50 líneas, se vuelve mucho más manejable.
Como alguien que aprendió a programar desde los 90, me sigue pareciendo asombroso el simple hecho de poder darle a una computadora una entrada ambigua e imprecisa y obtener a cambio un resultado útil. Vivir en un mundo donde una ambigüedad al nivel humano produce una salida clara y aprovechable se siente como ciencia ficción.
En cambio, a veces incluso si le das una entrada muy clara, la computadora la interpreta de forma ambigua para convertirla en un problema más fácil de resolver.
Yo creo que justo esa ambigüedad de los LLM es lo que los vuelve atractivos para conversar con documentación. Ya no hace falta reformular varias veces una búsqueda para encontrar la información que quieres, y eso ahorra mucho tiempo en conjunto.
También hay quien expresa que este es de verdad un tiempo asombroso, y que una o dos veces por semana se sorprende de lo real que se siente todo esto.
Alguien recuerda que era fan de Star Trek: The Next Generation, y que le impresionaba imaginar la diferencia entre la computadora de la Enterprise y Data. La computadora de la Enterprise podía organizar conocimiento, resumir y ejecutar tareas, muy parecido a la IA actual, mientras que Data estaba planteado como un robot con capacidades individuales. El hecho de que Data tuviera límites en humor, arte y otros terrenos emocionales humanos se parece bastante al estado actual del arte generado por IA. También le trae recuerdos de esos matices en la ambientación y el desarrollo al inicio de la serie.
Yo entré a esta industria porque me gustaba poder darle instrucciones claras a una máquina y obtener exactamente lo que quería. Dijkstra ya había subrayado desde hace tiempo la ambigüedad del lenguaje humano y la importancia de los "lenguajes formales" creados para superarla. Y ahora, en 2025, nos toca discutir con computadoras y corregirles la redacción en la era del "prompt engineering" y el "vibe coding", lo cual se ve con algo de ironía. Recomiendan leer EWD667: The Humble Programmer.
Me pregunto si quienes afirman que la IA generativa tiene capacidades ilimitadas pueden mostrar evidencia real. Si GAI o los agentes fueran de verdad tan poderosos, deberían poder demostrarlo fundando una empresa solo con IA y produciendo en poco tiempo código muy pulido y a gran escala. Pero no hay señales reales de eso. Hasta ahora, el uso más útil ha sido generar texto y arte que a los humanos les parecen significativos. En la experiencia de startups que intentaron aplicarlo al trabajo real, solo sirve de vez en cuando para explorar APIs o encontrar información cómodamente. En el balance general, ha sido más pérdida de tiempo que otra cosa. Ya llegamos al punto en que, en vez de seguir diciendo que "es bueno", deberían mostrar directamente resultados hechos puramente por IA.
Hay quien cree que aquí las perspectivas están cruzadas. Siempre existió un umbral entre los cambios viables (los que valen la pena por costo-beneficio) y las tareas que se quedan olvidadas en el backlog; las herramientas de IA bajan ese costo umbral y hacen posible intentar más cosas. Por eso quienes hablan de "productividad 5x" resaltan que aumentó la cantidad de código procesado, mientras que los escépticos creen que el valor esencial para el negocio no cambió mucho. También recomiendan La paradoja de la productividad de la IA.
Alguien pregunta qué tipo de evidencia concreta querrías ver. Si buscas capacidades infinitas o simplemente pruebas de utilidad realista. En la práctica, nadie sostiene que esto sea completamente omnipotente; el punto es que resulta útil cuando lo usa alguien que entiende bien sus límites y fortalezas. Incluso se menciona como ejemplo el historial de commits reciente de cloudflare/workers-oauth-provider para preguntar si al menos podríamos aceptar que tiene alguna utilidad.
De hecho, mucha gente ya usa internamente código generado por LLM. Se comparte la experiencia de PRs hechos con apoyo de LLM que llevan meses entrando en producción. Y también el consejo de que, si tú todavía no le encuentras utilidad, quizá sea porque aún no aprendiste a usarlo correctamente.
Cuando veo a quienes casi hacen propaganda diciendo que los LLM no tienen gran efecto, me da la sensación de estar viendo marketing en acción. Incluso empresas en las que antes confiaba se han volcado demasiado a promocionar IA, y eso decepciona. La idea dominante termina siendo: si de verdad hay beneficios, ve y pruébalo tú mismo.
Surge la metáfora de "vender picos en una fiebre del oro": en vez de demostrar directamente la eficacia de la herramienta, el marketing se dedica a convencer a la gente de que hay una mina de oro.
Hay críticas a la actitud de ignorar el problema de las licencias del código en Github. Algunos desarrolladores dicen que "no hay que preocuparse por el copyright", pero generalizar que todos los programadores son delincuentes que violan derechos de autor es incorrecto. Muchos desarrolladores, incluyéndome, no tenemos nada que ver con la piratería a gran escala y, de hecho, intentamos respetar el espíritu del copyleft y del software open source. Uno puede ver a SciHub como un bien público y, al mismo tiempo, respetar el copyleft que un desarrollador individual quiso aplicar. El copyright no se divide simplemente entre estar a favor o en contra. Ignorar esa diversidad y ese contexto para condenar a todos por igual, o para justificar que se ignoren las licencias, sí es una actitud intelectualmente floja.
Muchas veces los programadores entienden mal el derecho, especialmente el common law estadounidense. La tradición jurídica está escrita asumiendo desde hace mucho tiempo que los humanos la interpretarán de manera razonable; aunque las herramientas de IA estén diseñadas para difuminar o evadir la responsabilidad, al final la ley encontrará a una persona a quien responsabilizar y castigar. La realidad después del boom de la IA probablemente sea: 1) empresas y Estados intentan diluir responsabilidades, 2) ocurre algún incidente por efectos secundarios (accidentes automovilísticos, algoritmos discriminatorios, filtraciones de datos, etc.), 3) los tribunales devuelven la responsabilidad a un humano e imponen multas o sanciones, 4) otras empresas perciben el riesgo y restringen la IA. En ese flujo, las herramientas de IA están destinadas a sobrevivir solo dentro del marco de la responsabilidad humana.
Llevo más de 25 años desarrollando software libre y disfruto trabajar con distintas licencias. Mi pareja también trabaja como directora y artista visual, pero yo no toco contenido relacionado con IA y lo considero basura. Dejo clara mi postura: no quiero ni toparme con eso.
Resulta interesante un desafío como el Konwinski Prize, que ofrece 1 millón de dólares si un LLM open source resuelve más del 90% de issues novedosos de Github. Recomiendan ver la competencia Konwinski Prize. Por ahora, incluso los mejores modelos apenas logran 0.09 y no 0.9, así que todavía están lejísimos del uso real. Aunque el open source esté un poco por debajo de lo comercial en rendimiento, sigue siendo casi imposible que un LLM escriba código de forma independiente. Produce mucha basura, sí, pero aun así tiene utilidad, aunque solo sea por la necesidad de evaluar y gestionar lo que genera.
Aunque la IA haga por ti el trabajo repetitivo de escribir boilerplate, ahora lo que se repite es la revisión aburrida de ese código generado por IA, y al final deja de ser divertido, toma más o menos el mismo tiempo y además se entiende peor.
Quienes defienden el desarrollo con IA parecen disfrutar más revisar código que escribirlo. Puede ser una preferencia personal, pero en sí mismo me parece una actividad dolorosa.
Dicho con precisión, revisar grandes cantidades de código normalmente toma menos tiempo que escribirlo uno mismo, sobre todo si ese código pasa los tests; además, como los tests también pueden generarse con LLM, la carga disminuye.
Claude, Gemini y otros son mucho más rápidos que yo escribiendo código, y aun revisándolo dos veces sigo tardando menos que si lo escribiera yo.
Antes usabas código para esas tareas repetitivas tipo "yak shaving"; ahora la realidad es revisar afeitados de "yak" desganados y mal hechos.
En general, parece inevitable un mayor consumo de energía y emisiones de carbono.
También hay conversación sobre traducción automática y reconocimiento de voz. Desde una posición cercana a la discapacidad auditiva, alguien dice que usa esta tecnología todo el día. Antes no podía disfrutar series de los 80 sin subtítulos, pero ahora usa un LLM como Whisper para obtener subtítulos de video y siente como un milagro que algo que antes solo imaginaba ya sea real.
El SOTA más reciente en reconocimiento de voz y traducción todavía suele estar dominado por modelos especializados de tarea única, pero la brecha se está cerrando rápido y los LLM permiten hacer muchas más cosas. Recomiendan, por ejemplo, este leaderboard de reconocimiento de voz. Los LLM abren posibilidades mucho más amplias.
Durante años se probaron distintos sistemas de reconocimiento de voz, como Dragon, y aunque todos parecían impresionantes, resultaban incómodos en uso real. La combinación de Whisper con LLM fue el primer punto en que apareció utilidad práctica de verdad. Aún no es perfecto, pero la necesidad de corregir a mano se redujo a una décima parte, hasta el punto de que para notas personales ya ni lo verifica.
Aun así, todavía no confiaría exclusivamente en traducción con LLM para tareas realmente de alto riesgo, como contratos laborales en otro país o declaraciones policiales. Ya existía antes la conversión de voz a texto, y aunque el progreso técnico se siente claramente, por ahora sigue siendo algo cotidiano y de bajo riesgo, no algo al nivel de novelas de ciencia ficción o negociaciones interestelares.
Otro comenta que siente que los avances recientes por fin están cumpliendo promesas que veía en la ciencia ficción cuando era niño. Hace pocos días, en una ciudad desconocida, tomó una foto del menú de un restaurante, extrajo caligrafía china, la tradujo al inglés al instante y hasta aprendió a pronunciar el plato que quería pedir. Está convencido de que eso era imposible hace solo 2 años.
Para alguien más, la traducción es precisamente el caso de uso perfecto para los LLM. Piensa que los LLM pueden reflejar conceptos sociales, contexto cultural, cultura popular y referencias poco comunes, y además producir distintas versiones adaptadas a varios idiomas y culturas. Está convencido de que en este terreno ya van muy por delante de la traducción tradicional.