- Los relatos de éxito con herramientas de LLM suelen omitir criterios de comparación como las condiciones del proyecto, la experiencia del usuario y la cantidad de trabajo posterior, lo que dificulta evaluar su utilidad real
- En los debates sobre MCP, uso de herramientas y agentes, la actitud de tachar a los críticos de “personas que no han mirado en profundidad” se parece a las antiguas discusiones sobre crypto
- Los LLM y los agentes son no deterministas, así que es difícil asumir que una forma que funcionó ahora para el mismo problema seguirá funcionando igual un minuto después
- La famosa afirmación de que Claude Code “se encarga de bugs legacy” también recibió 1.8 mil me gusta y 204 reposts sin incluir el tamaño de la base de código, el tipo de bug ni la forma de gestión
- Incluso desde la perspectiva de alguien que ha usado varias herramientas en la práctica, los LLM se parecen más a máquinas estadísticas no deterministas; aunque cuando funcionan se sienten mágicos, es difícil afirmar que sean magia o ingeniería
Por qué es difícil comparar testimonios sobre experiencias con LLM
- Las experiencias a favor y en contra de las herramientas de LLM suelen compartirse como fragmentos aislados, por lo que es difícil verificar si todos hablan de las mismas condiciones
- A menudo se omite la naturaleza del proyecto y de la base de código
- No queda claro si se trata de un proyecto greenfield, una base de código madura o una base de código propietaria
- La experiencia del usuario tampoco es fácil de comparar de forma simple
- No se sabe si esa experiencia se aplicó al mismo dominio, la misma base de código o el mismo lenguaje
- La cantidad de trabajo adicional necesario, como revisión, corrección, despliegue y cierre, también influye mucho en la evaluación
- Aunque una persona proporcione toda esa información, si no se conocen las condiciones de los demás, la comparación entre experiencias sigue siendo limitada
- A esto se suma el no determinismo de los sistemas LLM y los agentes
- No se puede asumir que una forma que funcionaba ahora para el mismo problema funcionará también un minuto después
- La experiencia de un ingeniero senior en un proyecto React greenfield y la de un diseñador no desarrollador en una base de código propietaria en OCaml se vuelven aún más difíciles de comparar cuando cambian el modelo y el agente
- Incluso con el mismo modelo y el mismo agente, los resultados pueden variar en cada ejecución, lo que dificulta una comparación simple
La brecha entre el discurso sobrecalentado y el uso real de las herramientas
- La reacción de tratar a los críticos de los LLM como “personas que no han visto lo suficiente de MCP y las herramientas” muestra el sobrecalentamiento del debate sobre IA
- Como ejemplo de “industry leaders” aparece una afirmación de Steve Yegge sobre Claude Code
- Dice que Claude Code manejó con fuerza durante varios días bugs legacy en una base de código antigua
- Incluye expresiones como que Claude Code avanza sin que uno tenga que elegir directamente el contexto
- También incluye que, mientras se sigan aprobando las operaciones bancarias, la corrección de bugs llega hasta el despliegue en producción y se revisan los logs de usuarios
- También en este caso falta información necesaria para evaluar
- No se conoce el tamaño de la base de código
- No se sabe qué tipo de bug era
- No queda claro si hubo gestión adicional
- Tampoco se revelan el lenguaje de programación ni el framework
- Aun así, esa afirmación recibió 1.8 mil me gusta y 204 reposts
- Los escépticos y críticos tampoco es que no usen las herramientas
- Hay un proyecto lateral diseñado íntegramente con v0 de Vercel
- Sin saber Swift, se creó una app de monitoreo en SwiftUI con Claude Code
- Se hizo un póster de evento con Midjourney
- Se hizo vibe-coding de un MCP server en Elixir, pero no se usó phoenix.new
- La experiencia real de uso se resume como “funciona solo al 50% durante el 50% del tiempo”
- Los LLM son máquinas estadísticas no deterministas y, aunque cuando funcionan pueden sentirse mágicos, no son magia ni ingeniería en sí mismos
- El discurso sobre los LLM tiende a tratarlos solo como una de dos cosas: magia o ingeniería
1 comentarios
Opiniones en Hacker News
Me frustra que la gerencia de mi trabajo haya escuchado cosas como mejoras de productividad de 10x. Algunas de esas afirmaciones también vienen de early adopters internos.
Pero las expectativas se inflaron demasiado. Una de las razones es la ley de Amdahl: en la práctica paso mucho más tiempo pensando y comunicándome con otras personas, que son los clientes de mi código, que programando. Aunque programar se vuelva 10 veces más rápido, la mayor parte del trabajo no lo hará, y la productividad total mejorará más bien alrededor de un 10 a 15%. No es algo despreciable, pero no es 10x.
La sensación de usar un LLM para tareas de pensamiento se parece a cuando aprendí a usar la búsqueda web hace más de 20 años. Los motores de búsqueda hacían posible acceder a información cuando sabías qué estabas buscando; ahora los LLM ayudan a descubrir qué deberías buscar en primer lugar, y además hacen la búsqueda. Tareas que antes clasificaba como difíciles por el esfuerzo y la incertidumbre ahora se vuelven triviales.
Ahora hago cerca de 1/3 de mis búsquedas web con ChatGPT o3, y ya me cuesta renunciar a eso.
También tiene un efecto psicológico: ayuda a ordenar ideas inmaduras y actúa como un rubber duck, así que muchas tareas se sienten mucho menos pesadas, y eso por sí solo ya marca una gran diferencia.
Si le das a un senior un flujo de trabajo con LLM bien ajustado, no me sorprendería que sea tan productivo como 10 juniors de la era previa a los LLM. Incluso un mal desarrollador puede quitarle tiempo al senior y volver negativa la productividad, así que en ese caso el multiplicador se acerca al infinito.
Incluso los juniors decentes suelen quedar atados a tareas repetitivas de bajo nivel, y los LLM ya pueden hacer mejor ese tipo de trabajo.
Por eso entiendo cuando dicen que los empleos realmente podrían desaparecer.
La ola de IA me recuerda al movimiento de principios de los 2000 para tercerizar masivamente al extranjero a los ingenieros de software. Había expectativas enormes entre los directivos, y sobre el papel sonaba razonable, pero la mayoría terminó en grandes fracasos y casi todos los puestos volvieron a EE. UU.
Mucha gente ignora que los ingenieros de software hacen muchísimas tareas pequeñas que mantienen unido el conjunto. A la IA le falta mucho de eso. No quiero decir que a los extranjeros les falte eso, pero las barreras de idioma, las diferencias horarias y las diferencias culturales generaron problemas parecidos. La calidad del código y su mantenibilidad se desplomaron, y hubo que tirar muchos de los entregables hechos por empresas de outsourcing.
En las bases de código que manejo ya se está acumulando residuo de IA. Es muy difícil detectar estas cosas que pasan en las revisiones de código, porque en un diff se ven razonables. El problema es el código duplicado que no se ve y abstracciones raras que, vistas a alto nivel, no tienen ningún sentido.
Yo pertenezco justamente al grupo del que se queja el autor. Desde la época en que solo existía ChatGPT y su rendimiento tampoco era gran cosa, he lanzado productos greenfield nada triviales. Al principio usaba Claude y copiaba y pegaba entre el chat web y XCode; después descubrí Cursor.
Cursor dejaba muchos errores de compilación molestos, pero aun así mi productividad era al menos 3 veces mayor. Ahora que los agentes mejoraron y salió Claude 4, casi no escribo código directamente, y no me molesta. Me incliné más hacia un rol de arquitecto/manager y, cuando hace falta, dirijo al agente con conocimiento especializado.
Llevo unos meses en una startup exigente y todavía no he escrito ni una línea de código a mano. Antes de crear un PR audito todo personalmente y lo pruebo a fondo, pero Cursor + Sonnet es absurdamente potente en esa base de código. No hablo de métricas sin sentido como líneas de código, sino de que, cuando expertos de esa base de código llegan con bugs raros, yo, siendo nuevo en ese dominio, puedo acotarlos en 5 a 30 minutos; por eso estoy convencido de que soy el empleado más productivo.
Incluso tuve que apartarme después de terminar haciendo trabajo de desarrollador frontend, algo que había evitado durante toda mi carrera, porque Claude me permitía arreglar pequeños problemas visibles. Esto no es vibe coding: hay un proceso de investigación, planificación y exploración cuidadosa, y de preparar todo para que el agente tenga éxito. También requiere conocimiento del dominio. Pero realmente me sorprende que haya gente que no logre extraer la misma utilidad, y siento que salen dos artículos como este cada semana.
Haces afirmaciones difíciles de creer y no compartes ni una sola prueba. Incluso creaste una cuenta desechable para que sea imposible verificar tu identidad y comprobar tus afirmaciones.
Por eso suena a broma.
Eso no significa que desaparezca la necesidad de curación. Eso sigue siendo mi responsabilidad, y también es parte de lo que debería enseñar un doctorado. Tratar de forma precisa y reflexiva por qué se hace X y qué se quiere mostrar con Y, y la capacidad de descomponer todos los pasos y explicárselos a otra persona, son soft skills enormes. Ahora son todavía más importantes, porque los agentes no tienen un modelo persistente del mundo y, aunque usen compresión inteligente, olvidan rápidamente el objetivo de la interacción.
Si estoy comunicándome con precisión, puedo usar Claude Code para organizar trabajo computacional de formas que antes eran imposibles.
Si te importa la calidad, no es más fácil que programar, pero es distinto y exige otros modismos.
Donde los agentes sí son realmente útiles es en refactorizaciones mecánicas a gran escala. En vez de pensar en una macro perfecta de vim o en un script de reescritura de AST, se lo dejo al agente.
En promedio, ¿qué tan largos son los prompts, y las pruebas unitarias también las escribe el LLM?
Personalmente, creo que estás pintando la experiencia demasiado bonita.
Personalmente, no termino de entender esto.
Una enorme cantidad de trabajo en la industria de servicios de todo el mundo, en la práctica, se parece mucho a mover datos manualmente de una hoja de Excel a otra, o de un CRM/correo electrónico a Excel. Casi todas las grandes empresas tienen cientos o miles de empleados de tiempo completo haciendo esto todos los días, y una buena parte está tercerizada. Creo que por cada ingeniero de software hay al menos 100 personas haciendo este tipo de trabajo de pipelines manuales de datos.
Por lo tanto, para que los LLM creen un valor enorme no necesitan ser extraordinariamente buenos en OCaml. Solo tienen que ser un poco mejores que las personas en Excel. Donde MCP realmente ayuda es en que permite conectar estos sistemas con facilidad. Muchos errores en estas tareas aparecen al intentar meter todo el trabajo en el contexto de una sola vez. Si con MCP se pueden traer correos, extraer datos y luego, también con MCP, cargarlos línea por línea en el CRM, según mi experiencia la tasa de alucinaciones es muy baja. Como mínimo, está al nivel de un empleado junior sobrecargado.
Quizá ese también era el punto del texto, pero en estos casos de uso la no determinación no es un problema. Porque las personas involucradas tampoco son deterministas. Se pueden crear sistemas y procesos que impongan calidad sobre sistemas no deterministas, por ejemplo sistemas humanos.
Por último, seguí de cerca tanto las criptomonedas como los LLM, y en términos de utilidad y adopción no me parecen parecidos. Lo más cercano es la adopción de los smartphones. Cuando salió el primer iPhone, muchos amigos no técnicos decían que no necesitaban un smartphone, pero en pocos años todos tenían uno. Con los LLM pasa algo parecido. Ahora casi todos mis amigos no técnicos los usan para fines muy variados.
Dicho eso, la reacción social sí forma parte de una corriente de culto a la tecnología, y es comprensible que muchos ingenieros con años de experiencia estén cansados. Es fácil encontrar afirmaciones poco realistas, y las peores vienen de los CEO de empresas de IA.
Al mismo tiempo, muchísima gente es prácticamente analfabeta informática. Puedo imaginar lo emocionante que debe parecerles a quienes casi nunca han tenido contacto ni siquiera con automatizaciones básicas. La “computadora que habla” a la que estamos acostumbrados por la ciencia ficción casi se está volviendo realidad.
Hace unos años, antes de la IA, trabajé en aprendizaje automático y procesamiento de lenguaje natural, y lo más llamativo es que esto se volvió muchísimo más mainstream que cualquier otra cosa que haya pasado en ese campo. Eso también significa que hay mucha más gente con poca experiencia diseñando sobre la base de inferencia estadística. Por un tiempo, será como el Viejo Oeste en todos los sentidos: opiniones, implementaciones exitosas e ideas realistas de proyectos por aprender.
Se puede ver así: ahora puedes decirle a ese amigo que llega con una idea de app digna de una novela que la construya él mismo. Eso, al menos, beneficia a todos.
También puede haber componentes de inversión emocional en la empresa, como el instinto de supervivencia para no ser despedido, la ambición de hacerlo mejor, o la ética y el criterio para reportar por otros canales a un jefe raro.
Un LLM no va a llamar a otro nodo de la organización para confirmar cuando ve que un valor parece extraño por razones fuera del contexto. Por ejemplo, una situación en la que ayer fue un feriado bancario excepcional y el valor debería ser 0. Puede que garantizar que esos números sean correctos valga tanto como el salario anual de un empleado de tiempo completo. Y también tiene valor que, cuando no son correctos, haya alguien a quien culpar, despedir o mandar a prisión.
Lo que realmente se podía automatizar ya fue automatizado. Creo que la IA va a causar una gran disrupción, pero soy muy escéptico ante la idea de que la mayoría de los trabajos administrativos sean “trabajos de email” o entrada de datos. No coincide con mi experiencia, y también trabajé en grandes empresas burocráticas de esas que la gente de aquí diría que están atrapadas en el pasado.
Soy programador retirado. Me cuesta imaginar confiar código generado probabilísticamente a sistemas críticos para una misión. Podría entenderlo si casi siempre estuviera bien y solo necesitara pequeños ajustes, pero no tengo experiencia directa con eso.
Mi punto principal es que los LLM son sorprendentes en áreas que no son programación, como brainstorming, ideación libre, completar detalles de investigación o hacerme preguntas que me obligan a reflexionar. Los trato como un compañero de pensamiento. Cometen errores, pero se pueden detectar fácilmente verificando con otras fuentes o pidiéndole a otro LLM que revise las conclusiones.
Construí algo en menos de 24 horas, algo que me habría tomado meses siquiera empezar, y mucho más tiempo llegar a una versión tan pulida como la actual. Lo más impresionante es que hace más rápido cosas que yo ya podía hacer. Aún más impresionante es que también hace, por mucho menos dinero y tiempo, cosas que yo simplemente no podía hacer y para las que habría tenido que contratar a alguien o tercerizar, con ciclos de iteración más rápidos que comunicarse con otra persona.
No es perfecto y a veces es increíblemente frustrante. Aunque le diga explícitamente que no lo haga, hardcodea valores, o miente diciendo que hizo cierto cambio cuando en realidad modificó otra cosa completamente no relacionada. Aun así, en mi opinión es un game changer.
Es especialmente fácil y peligroso dejarse desorientar por un LLM cuando intentas extraer conocimiento en un área nueva. Con un buscador común puedes ver los sitios fuente y evaluar su confiabilidad, pero con un LLM no tienes eso. La salida puede ser, en la práctica, cualquier cosa, y no estoy de acuerdo con que los errores necesariamente sean fáciles de detectar.
Por supuesto reviso el código que escribe, pero casi todos los días me sorprenden su inteligencia y precisión. No tiene nada que ver con las criptomonedas.
Si usas la salida de un LLM sin criterio, la estás usando mal, pero también está mal usar sin criterio la salida de un humano.
Dicho eso, los LLM no son magia, y me preocupa que la gente use copilot o modelos de agentes para ocultar malas prácticas de ingeniería y termine acumulando más boilerplate en lugar de enfocarse en eficiencia, seguridad y rediseños importantes a largo plazo.
El problema es que hay que darle al LLM contexto sobre lo que estoy haciendo, y en el chat estilo ChatGPT uno no le da ese contexto, o resulta tedioso hacerlo. Ahí es donde Claude Code cambia el juego.
Por ejemplo, supongamos que tienes un archivo PCAP en el que cada paquete UDP contiene varios mensajes. ¿Cómo filtrarías por IP, puerto, protocolo y tiempo? Usas un LLM y verificas la salida. ¿Cómo encontrarías la cantidad de paquetes con patrones A, AB, AAB, ABB, etc.? Usas un LLM y verificas la salida. ¿Cómo crearías un PCAP de prueba que solo contenga esos paquetes? Usas un LLM y verificas la salida.
Como también puede leer código, francamente puede inferir mucho mejor lo que intentas hacer, porque tu trabajo no es tan especial. En cualquier caso, el simple hecho de poder decir “escribe pruebas unitarias para todas las funciones anteriores” ya te ayuda a verificar por tu cuenta.
Hay una frase que dice: “Como la mayoría de los escépticos y críticos, uso estas herramientas todos los días. Y funcionan más o menos un 50% en el 50% de los casos”, pero yo uso LLM casi a diario en el trabajo desde hace alrededor de un año y resuelven cerca del 90% de mis problemas.
Es muy difícil determinar si hay que tomar en serio estas quejas sobre IA/LLM, o si hay que verlas como patrones de uso irracionales de algunos usuarios. Por ejemplo, nunca he alimentado a un LLM con una base de código esperando que funcione mágicamente. Hago preguntas directas y concretas dentro de los límites de mi propio entendimiento, y aplico las soluciones deliberadamente de una forma que pueda probarse.
Si alguien se acerca de otra manera y luego se queja del LLM, tiendo a pensar que lo está usando mal. Y se está perdiendo una magia real, pequeña, útil y bastante consistente.
Yo también uso gpt y Claude todos los días mediante Cursor. gpt o3 es bastante bueno para búsquedas de conocimiento general. Claude se desmorona con frecuencia, pero también he visto bastantes casos en los que, mientras desperdicia tokens presumiendo, toca puntos relacionados con el problema real.
Los modelos son tontos; más que genios idiotas, son simplemente idiotas. Aun así, a veces aciertan con algo relevante. Si tú sabes a grandes rasgos qué debería pasar y tratas al LLM como un terrier cazarratones en un campo de granja, puedes sacarle provecho.
Esa cifra de 90% también suena un poco sospechosa.
Este texto se lee como si estuviera molesto por la imprecisión del discurso, pero esa imprecisión, francamente, está mucho más extendida entre los detractores que entre los partidarios. Los partidarios normalmente tienen que lidiar todos los días con sus defectos y limitaciones.
Concluir que todo alrededor de los LLM es pensamiento mágico parece bastante arrogante. En los últimos cinco años, problemas que antes eran casi intratables, como la traducción, la transcripción y la generación de código hasta cierta escala, quedaron resueltos total o casi totalmente.
Google Translate, Whisper y los generadores de código existen desde hace bastante tiempo sin LLM.
Sobre eso de que “las criptomonedas volvieron”, para mí las criptomonedas son un salvavidas. Porque en el país donde vivo no puedo abrir una cuenta bancaria por razones que no puedo controlar ni arreglar
Así que, si las criptomonedas no te sirven, me alegro por ti. Para mí y para millones como yo es una cuestión de vida o muerte
Con los LLM pasa lo mismo: para algunas personas son magia; para otras, una herramienta determinista y confiable; y al mismo tiempo también son magia. Acabo de clasificar y ordenar cientos de facturas. Sí, es magia
Por eso es difícil encontrar algo útil que las criptomonedas puedan hacer en la economía legal. Fueron diseñadas para posibilitar transacciones que los gobiernos no quieren o no pueden facilitar. En algunos casos tienen aplicaciones humanitarias, y también muchas aplicaciones ilegales
“Tenías que haber estado ahí para creerlo” https://x.com/0xbags/status/1940774543553146956
La fiebre por la AI está pasando ahora por una etapa parecida. Cualquier crítica se descarta como algo dicho por un tonto que no entiende nada
Si las usas como moneda, quienes quieren hacer pump and dump con las monedas y usarlas para ganar dinero son tus enemigos. Te conviene que sean estables, no una montaña rusa de subidas y desplomes
Creo que en el mundo cripto hay más mentiras deliberadas y menos valor que obtener, pero en ambos casos hay personas que podrían beneficiarse de verdad y que, por la deshonestidad y la distorsión, se dan la vuelta antes siquiera de cruzar el umbral. Y en ambos casos existen ejemplos de valor real hoy
Algo relacionado: últimamente me irrita la forma en que se usa el término AGI, y a veces incluso el término AI. Sobre todo en artículos científicos, donde esperaría que todo estuviera bien definido, o al menos el uso dentro de ese artículo
¿Por qué no podemos crear una definición de qué es AGI? Así se podría demostrar lógicamente si una AI encaja en esa definición. Aunque en la práctica no parezca demasiado útil, en teoría sería mucho más útil que usar el término sin significado
Ahora se siente como una especie de vía de escape. Wikipedia dice que es “un tipo de AI que iguala o supera la capacidad humana en casi todas las tareas cognitivas”. ¿Cómo se mide eso? Si no se puede demostrar que un sistema tiene esa propiedad, ¿de qué sirve?
Es un poco de desahogo, pero espero que aun así se entienda en parte
Es parecido a cómo, para mí, “crypto” sigue siendo criptografía y no criptomonedas. A veces la corriente principal simplemente tiene otra opinión
“AI es aquello que todavía no se ha logrado hacer”[1]
Hace poco empezamos a usar LLM en la empresa, y la primera tarea fue transcribir 20 mil llamadas de clientes y luego extraer la siguiente información
Una investigación que antes tomaba semanas terminó en unas horas. Ayudó a definir una nueva estrategia y generó valor de negocio real
Veo a los LLM simplemente como motores de procesamiento de lenguaje natural, y para ese uso son excelentes. Es cierto que algunos exageran, pero eso no cambia el hecho de que en nuestro caso fueron realmente útiles. No entiendo por qué hay tantos textos de “los LLM son malos”. Si no te sirven, simplemente pasa de largo. ¿Por qué alguien tendría que demostrarle algo a alguien? Es solo una herramienta
Este tipo de textos son importantes para enfriar las expectativas. Cuando la gente vende LLM, por lo general no habla de resumir llamadas de soporte al cliente, sino de vender la idea de que se puede despedir al personal de soporte
Durante años, la mayoría de las traducciones en la web no tenían contexto. Ahora pueden tenerlo
Figuras confiables y razonables del mundo tecnológico, conocidas por sus opiniones prudentes, han reportado mejoras considerables en tareas de programación al usar varias formas de AI generativa
¿Qué significa considerable aquí? Algo entre 5% y 100%, es decir, un nivel que no se puede ignorar
Como mínimo, es seguro decir que la AI generativa es, o puede ser, una herramienta bastante beneficiosa para un número considerable de personas
Para que ese juicio sea razonable no hace falta revelar todos los detalles, como la cantidad de CPUs, líneas de código o bytes procesados