- Con la llegada de las herramientas de programación con LLM, se derrumbó la premisa básica del desarrollo de software que llevaba décadas vigente, y la capacidad clave pasó de escribir código a definir problemas y diseñar estructuras
- Ahora el núcleo del desarrollo ya no es ‘escribir bien código’, sino la capacidad de ‘hablar’: imaginar problemas y explicarlos con claridad
- Las estructuras de código limpias, los README bien organizados y la documentación ya no son señales confiables de diligencia o experiencia; de hecho, cuanto más perfectos parecen, mayor es la posibilidad de que sean slop
- A medida que la distinción superficial entre código generado por IA y código escrito por humanos se vuelve prácticamente imposible, los criterios que determinan el valor del código pasan de la calidad a la responsabilidad, el origen y la humanidad
- Los incentivos de colaboración y compartición que sostenían el ecosistema FOSS se están debilitando, y más que el código mismo, la confianza, la gobernanza y la capacidad de curación se vuelven los activos más importantes
- Estas herramientas son amplificadores poderosos para desarrolladores experimentados, pero para principiantes pueden convertirse en un genio peligroso capaz de quitarles la oportunidad de construir una comprensión básica
Introducción: el aforismo de Linus Torvalds y su inversión
"Talk is cheap. Show me the code"
- En 2000, esta frase de Linus Torvalds simbolizaba la idea de que las palabras no valen nada si no se demuestran escribiendo código real
- En ese entonces, por más claro que fuera un plan de desarrollo, implementar un programa complejo exigía enormes cantidades de esfuerzo, tiempo y aburrimiento repetitivo
- El verdadero cuello de botella no era la tecnología sino el límite humano: el ancho de banda cognitivo, el tiempo y la energía individuales, y el costo biológico de tener que escribir código línea por línea mientras se mantenía un sistema entero en la cabeza
- Como resultado, la mayoría de las ideas terminaban amontonadas en una lista de deseos para “algún día”, y desaparecían sin siquiera intentarse
25 años después: los LLM lo cambian todo
- En 2025, Linus Torvalds integró código generado por IA en uno de sus proyectos personales y comentó: “¿Es mejor que lo que habría escrito yo a mano? Por supuesto”
- Desde la perspectiva de alguien que lleva décadas construyendo software, el autor afirma sin rodeos que el desarrollo de software tal como lo conocíamos ya terminó
- Como parte de una generación que vivió de primera mano innumerables transiciones, desde el dial-up hasta el gigabit, de Basic a Node.js, y de SourceForge a GitHub, reconoce con claridad que este cambio no es una moda pasajera sino una ruptura cualitativa
El colapso de los criterios para evaluar la calidad del código
- Antes, al evaluar proyectos FOSS, eran criterios importantes la antigüedad del proyecto, la frecuencia de commits, la consistencia de la estructura del código y la calidad del README y la documentación
- Los comentarios concisos y la documentación bien organizada se interpretaban como señales de consideración del desarrollador y atención hacia otros desarrolladores
- Pero ahora que los LLM pueden generar de una sola vez páginas de documentación muy pulidas, README excesivamente detallados, interfaces limpias y patrones y comentarios ordenados, esas señales han dejado de ser válidas
- Como resultado, se vuelve difícil distinguir por la apariencia si un repositorio fue hecho por una persona no técnica con vibe coding o si es el resultado diseñado por un desarrollador experto
- De hecho, cuanto más perfecto parece, más razonable es sospechar que podría tratarse de una generación de una sola toma y de bajo esfuerzo
- Sin una revisión y un análisis minuciosos de nivel experto, cada vez es más difícil separar el wheat del slop
- Por eso, más que el código en sí, pasan a importar más factores como quién lo hizo, por qué lo hizo, qué historial tiene esa persona o entidad, y si existen gobernanza y planes de mantenimiento; es decir, su procedencia
El cambio en el valor del esfuerzo
- Antes, para producir 10,000 líneas de código de alta calidad con resultados significativos, un desarrollador experimentado necesitaba largos periodos de concentración y mejoras repetidas
- La cantidad de líneas nunca fue una medida de calidad, pero 10,000 líneas bien refinadas sí implicaban tiempo, concentración, paciencia, experiencia y cierto nivel de gestión de proyecto
- Un LLM puede generar ahora ese tipo de resultado en apenas unos segundos y ocuparse de todo el flujo técnico de trabajo, desde pruebas hasta configuración del sistema y despliegue
- Cuando también intervienen la experiencia y el juicio humanos, el resultado puede alcanzar una calidad suficientemente alta para uso real
- En lo personal, el autor ha vivido repetidamente la experiencia de terminar en días, e incluso en horas, trabajos que antes tomaban semanas o meses
- Y eso fue posible solo con un CLI simple de agente LLM, sin
AGENT.mdni una orquestación compleja de múltiples agentes - El costo fisiológico, cognitivo y emocional que antes se pagaba para obtener resultados de software se ha reducido en varios órdenes de magnitud
- Ese tiempo y esa holgura cognitiva recuperados se reinvierten en pensamiento de ingeniería, diseño de arquitectura, discusión, experimentación y expansión de la imaginación
- La vieja frase “programar es 90% pensar y 10% tipear” ya no es una metáfora, sino una realidad
La definición de slop y el valor del código
- Si incluso alguien que nunca escribió una sola línea de código puede producir software a escala industrial en segundos, ¿cuál es entonces el valor del código como producto en sí?
- La postura de “quiero solo código puramente humano, no código de IA” es, si se mira la realidad, casi una broma irónica
- Ya existen suficientes ejemplos de grandes desastres causados por código escrito por humanos, como la caída de TI de CrowdStrike (2024), la inmovilización del Boeing 737 MAX, el escándalo de la oficina postal del Reino Unido, la brecha masiva de datos en India y la filtración de datos de Equifax
- Una parte considerable del código que los humanos escriben cada día en todo el mundo ya está en el límite en términos de calidad
- Sigue siendo difícil considerar el desarrollo de software como una disciplina profesional que haya alcanzado un nivel objetivo de madurez
- A médicos o ingenieros civiles se les exige formación rigurosa, licencia y responsabilidad por los resultados de su trabajo, pero en el desarrollo de software casi no existe nada comparable
- La sociedad actual funciona sobre sistemas de código mal diseñados, pegados a medias y excesivamente inflados
- Si uno quisiera hacer una afirmación provocadora, podría decir que el slop hecho por IA al menos suele tener forma limpia, documentación bien organizada y consistencia sintáctica
- Se extiende la percepción de que leer frases y mensajes sin alma generados por LLM que inundan internet es, literalmente, un desperdicio de activación de neuronas en la amígdala
- Sin el proceso creativo humano y sin la mezcla de perfecciones y defectos que lo acompaña, el lenguaje, la literatura, el arte y la música dejan esencialmente de ser disfrutables
- Aquello que puede generarse infinitamente e instantáneamente, sin esfuerzo, se vuelve algo a lo que a los humanos les cuesta enormemente asignar valor
El código no es arte
- El código, por naturaleza, siempre fue un medio para un fin, nunca un fin en sí mismo
- El usuario final no lee el código, no necesita leerlo, ni le interesa el código como tal
- Para el usuario no significa nada que los cientos de sistemas detrás de un portal estén implementados en cierto lenguaje, framework o arquitectura
- El código está completamente oculto y el usuario solo experimenta, a través de la UX, los resultados y efectos que ese código produce
- El criterio para distinguir si un código de IA funcionalmente equivalente es slop o no es la estructura de responsabilidad (
accountability) y si hubo intervención humana - Un PR subido por una persona a un repositorio open source, independientemente de la calidad del código, recibe de forma natural empatía y valor porque se asume que contiene tiempo y esfuerzo humanos
- En cambio, un PR generado por un LLM muchas veces provoca como primera reacción “¡slop!”, sin importar la calidad, porque no permite medir de inmediato el esfuerzo humano que contiene
- Al mismo tiempo, la carga de leer y verificar ese código crece de forma desproporcionada y exponencial en comparación con su costo de producción
- Al final, no es más que una variación entre infinitas generadas sin esfuerzo y sin una procedencia o contexto significativos
- En este punto, nuestra realidad se parece cada vez más a “La biblioteca de Babel” descrita por Borges
El futuro del FOSS
- FOSS es probablemente uno de los mayores bienes públicos que ha creado la humanidad
- En el origen de FOSS estaba la premisa histórica de que el software era extremadamente caro y solo una minoría de especialistas podía crearlo
- En todo el mundo, solo una fracción muy pequeña de personas podía hacer software, mientras que el resto no tenía más opción que usar el resultado
- Ahora, incluso para necesidades muy de nicho, un experto puede crear rápidamente pequeñas librerías ajustadas exactamente a lo que necesita
- Más aún, si alguien es medianamente hábil, ya vivimos en una época en la que cualquiera puede hacer por vibe coding pequeñas herramientas para uso personal
- El cambio que se vio en StackOverflow también está avanzando, aunque más lentamente, en el software en general
- Esto parece sacudir de frente el núcleo mismo de las motivaciones humanas, las condiciones sociales y los incentivos de participación que sostenían la colaboración y el compartir en FOSS
- Si se considera la explosión cámbrica de proyectos FOSS que se viene a una escala sin precedentes
- Entonces, en los proyectos FOSS de alta calidad que logren sobrevivir y prosperar, es muy probable que la gobernanza experta, la curación y las estructuras de confianza valgan más que el código mismo
Los dos extremos que no ven el bosque por mirar los árboles
- Incluso en la época sin resaltado de sintaxis, IDE ni todo tipo de herramientas, los humanos ya habían creado software de un nivel asombroso
- Y, por el contrario, incluso ahora que sobran herramientas y recursos, se sigue produciendo software pésimo
- Un desarrollador capaz, expresivo y atento a la calidad consigue buenos resultados usando LLM u otras herramientas a su manera
- En cambio, un desarrollador incapaz de explicar problemas y desinteresado por la calidad produce malos resultados use o no use LLM
- Tanto los creyentes extremos del vibe coding “agentic” como quienes rechazan por completo los LLM siguen obsesionados con los árboles sin ver el bosque
- Claramente existe un punto medio práctico en el que una persona con experiencia, criterio, capacidad de pensamiento y expresión elige los trade-offs adecuados para obtener el resultado deseado
- El vibe coding también es un punto de entrada importante para que personas no técnicas toquen software por primera vez, experimenten, se diviertan y desarrollen capacidades
- Pero quienes depositan una fe ciega en el vibe coding están perdiendo de vista el elemento central que hace que los humanos se tomen en serio un producto: la finitud
- Como resultado, terminan construyendo una gigantesca biblioteca borgeana en la que incluso ellos mismos pueden perderse, un mar de slop producido por agentes complacientes
- A los productos generados infinitamente sin esfuerzo y sin una procedencia significativa es extremadamente difícil asignarles valor o tomarlos en serio
- Los humanos, por naturaleza, no manejamos bien la oferta infinita, especialmente la infinitud de opciones
- Por otro lado, los detractores de los LLM muchas veces no logran ir más allá del argument from incredulity
- Niegan la tecnología solo porque personalmente no les gusta, porque no obtuvieron el resultado deseado, porque no cumplió sus expectativas o simplemente porque se cansaron de ella
- Pero eso pierde poder de persuasión frente al hecho de que existe una cantidad considerable de personas que usan la misma herramienta con eficacia y tienen experiencias completamente opuestas
- Las implementaciones tontas y dañinas impulsadas por el hype, el frenesí y la codicia son, sin duda, una realidad y una preocupación seria
- La burbuja de negocios de IA probablemente podría convertirse en una de las burbujas más grandes de la historia
- Aun así, la expansión de la tecnología de IA FOSS es claramente una señal esperanzadora
- Equiparar a los malos actores, los juegos de métricas o las implementaciones absurdas con las capacidades fundamentales y físicas de estas tecnologías es algo irracional
El costo humano
- Desde la perspectiva de desarrolladores e ingenieros con experiencia, estas tecnologías de IA funcionan como un apoyo muy poderoso y eficaz
- Pero para aprendices en etapa inicial y juniors que recién están entrando al sector, plantean un problema completamente distinto
- Si no hay bases sólidas y aún no se ha formado una comprensión intrínseca y sutil de los sistemas y del proceso de desarrollo de software, esta tecnología se parece más a un genio poco confiable y peligroso
- Pedir código y recibirlo, pedir cambios y obtenerlos al instante, parece cómodo a primera vista
- Pero pronto el usuario queda atrapado en una base de código cuyo funcionamiento no entiende, y pasa a depender del genio una y otra vez para resolver problemas
- Si esa dependencia se repite, desaparece el propio entorno de aprendizaje en el que podrían formarse de manera natural las capacidades más básicas y fundamentales, con el riesgo incluso de una degradación cognitiva
- Como resultado, surge la posibilidad de que aparezca toda una generación de juniors que nunca logre convertirse en seniors de verdad
- La preocupación real es que las nuevas generaciones de aprendices pierdan la oportunidad de adquirir la experiencia necesaria para distinguir objetivamente qué es slop y qué no lo es
- Un problema aún más serio es la posibilidad de que incluso quienes dominan estas herramientas pierdan la motivación para mentorizar y entrenar a juniors de manera básica
- Esto implica un riesgo que va más allá del desarrollo de software: empujar a los humanos hacia la delegación total de su agencia y toma de decisiones a cajas negras
Conclusión: ahora la palabra vale más que el código
- Incluso para quienes han desarrollado siempre a mano, ahora es más importante la capacidad de leer código y evaluarlo críticamente que la capacidad de dominar sintaxis y teclear línea por línea
- Por supuesto, esta última sigue siendo una habilidad importante, y la capacidad de leer código eficazmente se forma en última instancia sobre esa base
- Aun así, el flujo cotidiano de trabajo del desarrollo de software ya se ha invertido por completo
- Un desarrollador experimentado que sabe expresarse, es decir, que puede imaginar, explicar, definir problemas, diseñar arquitectura y hacer ingeniería, tiene una ventaja desproporcionadamente mayor que nunca frente a quien no puede hacerlo
- El conocimiento de un lenguaje, una gramática o un framework específicos ya no es el principal cuello de botella
- Las restricciones fisiológicas y físicas que antes limitaban a los desarrolladores ya no actúan como obstáculos decisivos
- Las máquinas capaces de producir grandes volúmenes de código al instante ya son herramientas comoditizadas a las que cualquiera puede acceder al nivel de
pip install - En la práctica, también desaparece la necesidad de entrenamiento especializado aparte o de aprender un nuevo lenguaje o framework
- Lo que se requiere es solo el viejo pensamiento crítico, capacidades humanas básicas y una mínima capacidad operativa para manejar esta máquina
- Como resultado, las metodologías tradicionales de desarrollo de software y la separación de roles —Waterfall y Agile, desarrollador y tester, senior y junior— están atravesando cambios fundamentales
- Las fronteras tradicionales se están integrando en bucles iterativos “agentic” inimaginablemente rápidos, comprimidos y difusos
- En consecuencia, también están cambiando rápidamente las dinámicas de personas, organizaciones y comunidades públicas alrededor del desarrollo de software, así como los incentivos humanos que sostenían el compartir y la colaboración
- Casos como el fin del bug bounty de curl, la introducción de lineamientos sobre uso de IA en Zulip y la política explícita de IA de Ghostty lo muestran
- Por primera vez en la historia, la buena palabra (
talk) se convierte en un factor con un valor exponencialmente mayor que el buen código - El impacto de este cambio será profundo y, al mismo tiempo, muy disruptivo
10 comentarios
"Incluso alguien que nunca ha escrito una sola línea de código puede generar código a escala industrial en cuestión de segundos" -> Si construyes un edificio de departamentos con palitos de madera, ¿eso cuenta como escala industrial?
Me gustaba esa frase de Torvalds... los tiempos cambiaron por completo.
Siento una profunda empatía con eso de que "el propio entorno de aprendizaje desaparece". En un mundo donde el costo de acceder al conocimiento es casi cero, ¿qué forma tomará ahora la educación?
La realidad es que, en la mayoría de las contrataciones, siempre exigen experiencia de N años o más en lenguajes como Java.
"Hablar" y "escribir" son cosas distintas.
De hecho, parece que hay que escribir mejor que hablar.
🐎🐎🐎🐎🐎
Aiba de Kimino, zukyundokyun~
Hasta hace apenas unos años, cuando ibas a reuniones de colegas de la empresa o a encuentros de desarrolladores, solían menospreciar a los ingenieros que no tenían habilidad pero hablaban de más (obsesión irreflexiva, tipo early adopter, por las tecnologías y palabras clave de moda; a lo mucho, solo experiencia usando frameworks y librerías, sin haber construido nunca por su cuenta ni siquiera lo básico...) llamándolos "lenguaprogramadores"... pero ahora los "lenguaprogramadores" se han convertido en la realidad de los desarrolladores. Uf, cómo han cambiado los tiempos.
Opiniones de Hacker News
Hoy le pedí a Codex que escribiera pruebas unitarias para Redux
Al principio se veían bien y lo dejé pasar, pero después, cuando volví a revisarlas para agregar yo mismo más tests, encontré decenas de partes que me hicieron pensar: “¿qué es esto?”
Corrían, pero estaban hechas un desastre. Y eso que era código simple
Tengo experiencias parecidas cada vez que uso IA: por fuera parece aceptable, pero cuando intentas extenderlo es un desastre total, así que al final me toca arreglarlo todo
El problema con la frase “el código es barato” es que generarlo es barato, pero mantenerlo es caro
Generar miles de líneas al día es como acumular deuda con la tarjeta de crédito. Parece gratis hasta que después te llega la cuenta
No sé si podamos influir directamente, pero sí me gustaría ver qué pasó
Por cierto, el enfoque de pruebas de Redux está resumido en la documentación oficial
Primero hay que definir la metodología de testing y, con base en eso, pedirle algo al modelo
Hay que tener cuidado porque la IA asume arbitrariamente lo que no se especifica
En el fondo, lo importante son las pruebas. No hay que juzgar código generado por IA a puro instinto; hay que validarlo con tests
El valor del código es proporcional al nivel de sus pruebas. Pasarlo con un simple “LGTM” es como manejar una moto con los ojos cerrados
A veces sale bien, pero otras veces sale completamente mal
Por ejemplo, le di el caso de uso correcto, el código estaba mal, y cuando fallaron las pruebas, la IA reescribió las pruebas
O sea, existe el riesgo de que defina por sí sola qué cuenta como éxito
Una vez levanté dos instancias de Claude, una para las pruebas y otra para la implementación, pero la configuración era demasiado engorrosa
Por eso creo que esta es una de las razones por las que esta tecnología se impone a la fuerza en los equipos
Igual que con la migración a la nube, el costo real aparece después. Solo que esta vez probablemente será mucho más rápido
Si lo explicamos con la analogía del ensamblaje de autos:
quien solo arma piezas siguiendo una especificación sí tiene motivos para preocuparse de que lo reemplace un brazo robótico
Pero quien experimenta con diseños, crea prototipos y programa el brazo robótico tiene menos de qué preocuparse respecto a la automatización
Muchas objeciones responden con “la IA también automatiza ese segundo papel”, pero en la práctica creo que muchas veces se confunde el primer trabajo con el segundo
Porque puede depurar, cambiar de rumbo y dar instrucciones concretas
Un usuario común solo repite “esto no funciona, arréglalo”
Así que la forma del trabajo va a cambiar, pero el trabajo en sí no va a desaparecer
Si la IA puede imitar eso, entonces también podría reemplazarme
En una economía con poca competencia, una “imitación suficientemente convincente” ya podría bastar
Aunque el resultado de la IA sea pésimo, si garantiza ingresos y salida, ya es suficiente
El mundo siempre ha tolerado la “basura distribuida”. Mira Windows
En realidad había muchas partes automatizables, y tal vez mi ego llevaba tiempo sobreestimándose
Pero los LLM de hoy son mucho más generales, así que pueden asumir cualquier clase de trabajo
Si a un brazo robótico le dices “mejora el diseño de este auto para este año”, se detiene; pero una IA sí puede dar una opinión
Si la IA puede encargarse de todo el proceso, desde idea → diseño → construcción → pruebas → evaluación,
entonces esto es una innovación esencialmente distinta de las tecnologías del pasado
Decir que “la era de escribir código a mano terminó” es una exageración
Ese tipo de exageración es una táctica para sacudir la profesionalidad de la gente y activar el FOMO
No hay que asustarse; hay que confiar en el propio criterio
Aunque sí es cierto que la tecnología cambia la manera de practicarla
Al final, lo importante es la capacidad de equilibrar rendimiento, costo, calendario y calidad
Siempre hay mucha resistencia a la afirmación de que “la ingeniería se terminó”,
pero desde mi punto de vista, en productos grandes escribir código representa solo entre 10% y 20% del total
El resto es diseño, experimentación, análisis, comunicación, etc., y es difícil que un LLM reemplace esa parte
Más bien, la colaboración y la coordinación se vuelven más complejas, y muchas veces el LLM empeora eso
Por eso lo correcto es ver la IA no como sustituto, sino como herramienta
Ellos dijeron que “se terminó una forma de desarrollar de décadas”, no que la ingeniería se terminó
Si escribir código es 10~20%, eso significa que el resto, la ‘conversación’, se volvió más importante
Como dijo Linus: “hay que mostrar que el código funciona como se pretende”
Es fácil escribir unas cuantas líneas con un LLM, pero modificarlas de forma segura sigue siendo difícil
Según dicen, a Liz Fong-Jones de Honeycomb también le pasó este tipo de error
Cuando las empresas empiecen a seguir el ROI de los LLM, se van a topar con la realidad
Ahora mismo estamos en la cima del hype cycle de Gartner, y parece que pronto bajaremos al valle de la desilusión
Gracias a Claude empecé a refactorizar rápido, pero en cierto momento me quedé completamente atorado
La razón fue que yo mismo no sabía qué quería
Si el modelo de datos no está claro y aun así le dices “sigue escribiendo”, el resultado es muy malo
programar es una actividad de corto plazo, pero la ingeniería de software es un proceso de largo plazo
La IA acelera lo primero, pero no puede reemplazar lo segundo
La premisa de “un plan de desarrollo claro y know-how de implementación” no es realista
Programar en sí mismo ya es una actividad de planificación, y el lenguaje es una gran herramienta para pensar
Por eso hay una división en la manera de ver a los LLM: quienes ven el lenguaje como herramienta de pensamiento y quienes lo ven como simple herramienta de ejecución
Los primeros ven el valor de la programación en sí, y los segundos quieren esconder el código
Al final es una cuestión de elección: ¿vas a construir bien el modelo conceptual desde el principio o vas a terminar en un infierno de depuración más adelante?
Las herramientas actuales no están hechas para lo primero. Hay una brecha grande de tooling
Algunos están combinando ambas para trabajar de maneras nuevas
El significado original de “Talk is cheap” es que “hablar es fácil y no vale mucho”
Pero “Code is cheap. Show me the talk.” da a entender que vale todavía menos que eso, y desde el principio me resultó molesto
Y al leer el texto, vi que mi intuición no estaba equivocada
El autor no es ignorante sobre código. También participa activamente en open source
La idea es simple: antes era caro implementar en código un buen diseño,
pero ahora eso se abarató, así que la calidad del diseño importa más
“Talk is cheap, show me the code”
Lo central es el modelo mental del desarrollador, más que el código
El código es solo un subproducto de ese modelo, y sin interpretación humana no tiene sentido
Esta perspectiva también influye mucho en cómo se usan los LLM
Me cuesta estar de acuerdo con la frase “se terminó la forma de trabajar de décadas”
En 2005, 2015 y 2025 las formas de desarrollo ya eran distintas
Siempre ha habido cambios, así que la premisa de que “fue igual durante décadas” es equivocada
Las herramientas mejoraron, pero la manera de trabajar del desarrollador siguió siendo parecida
el neovim actual es muchísimo más potente que aquello
Hay una tendencia a subestimar el progreso gradual de los últimos 30 años
En esa época la mayor parte de la información se obtenía de libros en papel o ingeniería inversa
La frase que más me hace sentido es “Talk is even cheaper, still show me the code”
La IA promete una productividad 10 veces mayor, pero casi nunca veo resultados reales de ese nivel
Gracias a la IA la complejidad se volvió más tolerable, pero aun así escribir apps en React sigue siendo doloroso
También sigue siendo difícil lidiar con APIs no deterministas
Aun así, sí es una ventaja perder menos tiempo en typos o buscando ejemplos
Pero por la falta de capacidad de razonamiento y los límites de conocimiento, programar sigue siendo tedioso
luego lo convierte a caracteres ANSI y lo sobreescribe en la terminal —
en realidad implementó de forma complicada algo que podría hacerse fácilmente con curses
Frases como “Code is cheap. Show me the talk.” ahora se usan demasiado como anzuelo para clics
El texto en sí no está mal, pero no tiene nada nuevo
No solo las empresas se cuelgan de la moda de la IA; también los blogueros y los influencers
Si le pones un título provocador a cualquier texto a favor o en contra de la IA, se vuelve tendencia en HN o Reddit
Por cierto, el origen de esta frase está en este tuit y
esta página de memes
Por fin alguien expresó bien ese punto medio realista entre los extremos
Los LLM no son dioses ni desastres. Son herramientas
Puedes criticar la extracción de rentas de empresas como OpenAI, Google y Microsoft
y al mismo tiempo aprovechar modelos locales como Qwen o Mistral
Los LLM en la nube no permiten E2EE por razones de seguridad, así que no son apropiados para entornos corporativos
Pero gracias a los LLM locales, ahora una sola persona puede hacer trabajo de nivel enterprise
Con una sola Mac Mini puedes encargarte de consultas a bases de datos, integración de APIs y automatización
Si no estás en una organización enorme, un senior generalista puede reemplazar a tres mid-levels
Claro, sigo teniendo muchas objeciones sobre la reducción de empleos, el copyright y demás,
pero los LLM locales ya se volvieron parte de mi toolkit principal
Parece un texto que me gustaría mostrarles a las personas que están en modo de "fe".