La razón por la que los humanoides tienen un tamaño similar al de los humanos y una estructura articular parecida es para no tener que construir herramientas o líneas aparte para ellos.
Ya hicimos tonterías como implementar, operar y dar mantenimiento a un RAG corporativo, y con la llegada de los agentes y MCP, ¿no reflexionamos que en realidad no hacía falta hacer eso? ¿Por qué querríamos cometer el mismo error de otra manera?
La idea anticuada de que los agentes naveguen la web en lugar de los humanos no estará determinada tanto por la tecnología, sino por cuestiones políticas que tendrán una influencia mayor, porque amenazan el principal modelo de ingresos de Google, que ya es parte de la propia web.
Al final, webMCP no es más que una alternativa transitoria hasta que maduren los agentes de RPA. A este paso, hasta van a salir con que regresemos a xul.
Para los ingenieros que trabajan con IA, es un supuesto básico tan evidente que nunca ha sido ningún secreto oculto que en los modelos de lenguaje grandes (LLM), la 'creatividad' y la 'alucinación (Hallucination)' son, al final, el resultado de la misma predicción probabilística del siguiente token (Next-token prediction); sin embargo, el white paper lo exagera como si estuviera revelando un gran secreto.
Resulta algo decepcionante la lógica con la que critica la 'autocorrección' de múltiples agentes limitándola simplemente a una 'iteración homogénea (Homogeneous Iteration)' dentro del mismo contexto.
Si uno integra agentes inteligentes dentro del IDE y realiza prompt engineering avanzado en un entorno real de desarrollo, esa naturaleza probabilística del modelo, más que un 'defecto fatal insuperable', es solo una 'condición base' que debe tratarse como una constante al diseñar el sistema. En la práctica, ya se parte de la premisa de que el modelo puede salirse del contexto, y la forma de trabajar consiste en asegurar control real proporcionando contextos claramente separados o usando contextos de distinta escala.
Sin embargo, este white paper envuelve ese hecho obvio que cualquiera conoce con términos académicos grandilocuentes como 'error categórico' y 'desvío probabilístico', generando ansiedad innecesaria. El objetivo parece claro. Solo degradando por completo la autonomía de los LLM pueden maximizar el valor de la 'red de control determinista diseñada directamente por humanos (sistema SERA)' que proponen.
En última instancia, este texto se parece menos a un white paper con equilibrio técnico y más a un sales pitch sesgado, dirigido a tomadores de decisiones en entornos enterprise que temen los riesgos de las alucinaciones, para convencerlos de que 'adopten nuestro pipeline determinista hardcodeado en lugar de agentes incontrolables'.
El código del trabajo se lo dejo por completo a los agentes de IA, haciendo que el loop sea lo más largo posible.
Los proyectos personales por hobby los desarrollo yo mismo, sin usar asistentes de IA ni autocompletado con IA (...)
Me cambié de vim a vscode por la IA,
pero sentí que había perdido la alegría de desarrollar, así que volví a vim.
Uso la IA como asistente, y definitivamente siento que recuperé la alegría de programar.
Está escrito de forma complicada, pero al final lo que quiere decir es algo que también se aplica a las personas.
La cuestión es si un texto escrito por un tonto A se vuelve mejor solo porque el mismo tonto A lo vuelva a revisar.
Claro, en una minoría de casos existe la posibilidad de que mejore, y también existe la probabilidad de acertar todas las preguntas al azar y sacar puntaje perfecto en el examen de acceso universitario, pero en la mayoría de los casos no hace más que regresar al nivel promedio de A tras N intentos.
(No puedo decir que esté completamente de acuerdo con el Chapter 2.)
Aun así, como dice el paper, estaría bien que entendieran que cualquier what-ever Scaling Law es una ley de crecimiento temporal, no algo eterno.
Si hubieran leído bien el paper de OpenAI, ni siquiera dirían algo así.
La verdad, más que 100 papers como ese, bastaría con demostrar que alguien que afirma que "sí se puede" realmente se convierte en esa persona.
El problema es que solo están haciendo alquimia del "sí se puede".
Personalmente, siento de forma muy clara que la IA es bastante mala en mi área de especialidad. Supongo que para los expertos de otros campos pasa lo mismo. Claro que ayuda mucho. Aunque termino escribiendo documentos fastidiosos todo el día, de ninguna manera se compara con la productividad de antes.
La atención se forma por mayoría.
Los agentes de verificación solo necesitan pasar la función de evaluación.
La mayor parte del buen código industrial no está público.
El código open source es código hecho para mostrarse.
Hay que usarla teniendo siempre presente este punto.
Según los resultados de los experimentos de nuestro laboratorio, es un modelo que el equipo de Qwen, sin el verdadero equipo de Qwen, lanzó apresuradamente solo para ajustarse a los benchmarks e intentar manejar la ansiedad del mercado. Tiene una obsesión muy fuerte con las herramientas. Creemos que es un retroceso frente a la 3.5.
Fuera de las implementaciones en ciclos cortos, no me queda claro qué le queda a Agile.
El backlog y los sprints ya existían antes bajo otras formas, y mucha de la comunicación con el cliente no encaja con la realidad. Al final, creo que más que Agile, las mejoras en DevOps han traído más avances al desarrollo.
Al escribir software, el problema no es tanto la abstracción, sino la ambigüedad. El lenguaje natural es inherentemente ambiguo. Incluso puede tener múltiples interpretaciones. Por eso quizá los intentos de programar con lenguaje natural no funcionan bien.
Dadas estas circunstancias, ni soñar con que el lenguaje natural reemplace al código.
Este tipo de contenido parece una fijación con formas de trabajo del pasado. De todos modos, en esas partes la IA terminará haciéndolo mejor. Lo importante ahora es la experiencia de mejorar lo que no sale bien al usar la IA. Pero también creo que esto será algo temporal.
Puede variar según la persona, pero me parece que en temas de computación casi todos estudian de la manera que mencionas. En estos días también existe la opción de aprender con videos, así que habrá que hacerlo con el método de aprendizaje que mejor le funcione a cada quien.
Entonces, ¿cómo aprendieron un lenguaje de programación funcional puro? Hasta ahora he aprendido lenguajes de programación (C, Go, Python, etc.) con libros técnicos + proyectos paralelos, ¿está bien seguir ese mismo enfoque de aprendizaje también con los lenguajes de programación funcional?
La IA se siente como usar un taladro eléctrico, una motosierra o una excavadora. Desde que usamos celulares, hay mucha gente que ni siquiera recuerda su propio número de teléfono.
...Esto también podría verse como un deterioro, pero yo lo veo como eficiencia. Desde mi experiencia como desarrollador y en varios otros roles, considero que las herramientas de IA son también una oportunidad y una ayuda para salir del mundo exclusivo de los desarrolladores y tener una perspectiva más amplia. En una parte puede haber deterioro, pero ese espacio se llena con otras cosas.
Mi experiencia y la conclusión de varias personas era que la forma correcta de estudiar un lenguaje funcional era hacerlo con un lenguaje funcional puro.
Eso se decía cuando los lenguajes funcionales empezaban a ganar atención y también en la época en que recibían mucho interés, y yo estaba de acuerdo. Yo estudié con Erlang en sus primeros años, y en ese momento fue una experiencia bastante impactante y sorprendente.
Como Clojure salió hace bastante tiempo, me da curiosidad por qué se vuelve a hablar de Clojure.
Al principio, cuando salió Clojure, tuve la experiencia de reseñar un libro sobre el tema. Después vi algunas empresas que intentaron usarlo, pero la conclusión fue que no era fácil de utilizar en un entorno empresarial. Y cuando parecía que iba a quedar enterrado, me pregunto por qué vuelve a salir la conversación.
He usado Java desde sus inicios durante mucho tiempo, pero aunque la JVM sigue usándose bastante por razones como que en las grandes empresas ya hay mucho software desarrollado en Java, que (en el caso de Estados Unidos) gran parte de la fuerza laboral india domina Java, y que se enseña Java desde la preparatoria hasta la universidad, entre otras cosas, en mi opinión ya no encaja con la época actual. Me gusta Lisp, pero no encontré en el texto de arriba qué ventajas hacen que, en plena era de la IA, vuelvan a destacarse un lenguaje bastante minoritario y un enfoque de JVM que parece ir en declive.
La publicidad y el marketing ya eran así desde antes de internet, pero ahora, como ha cambiado lo que ve la gente y ya no se puede regular, abundan técnicas que rozan la estafa.
Como nunca he aprendido bien un lenguaje de programación funcional, estoy pensando en empezar con Clojure. ¿Cómo debería estudiarlo? Les agradecería mucho sus consejos.
Parece que Daniel Han, fundador de Unsloth, es un verdadero genio. Cada vez que sale un modelo de pesos abiertos, comparte análisis desde la arquitectura del modelo hasta bugs de tokenización, errores de cuantización y errores de plantillas, y de verdad es impresionante.
La razón por la que los humanoides tienen un tamaño similar al de los humanos y una estructura articular parecida es para no tener que construir herramientas o líneas aparte para ellos.
Ya hicimos tonterías como implementar, operar y dar mantenimiento a un RAG corporativo, y con la llegada de los agentes y MCP, ¿no reflexionamos que en realidad no hacía falta hacer eso? ¿Por qué querríamos cometer el mismo error de otra manera?
La idea anticuada de que los agentes naveguen la web en lugar de los humanos no estará determinada tanto por la tecnología, sino por cuestiones políticas que tendrán una influencia mayor, porque amenazan el principal modelo de ingresos de Google, que ya es parte de la propia web.
Al final, webMCP no es más que una alternativa transitoria hasta que maduren los agentes de RPA. A este paso, hasta van a salir con que regresemos a xul.
Eso se debe a que las dimensiones y las capas del modelo no quedaron "horneadas" de manera uniforme. Como siempre.
Para los ingenieros que trabajan con IA, es un supuesto básico tan evidente que nunca ha sido ningún secreto oculto que en los modelos de lenguaje grandes (LLM), la 'creatividad' y la 'alucinación (Hallucination)' son, al final, el resultado de la misma predicción probabilística del siguiente token (Next-token prediction); sin embargo, el white paper lo exagera como si estuviera revelando un gran secreto.
Resulta algo decepcionante la lógica con la que critica la 'autocorrección' de múltiples agentes limitándola simplemente a una 'iteración homogénea (Homogeneous Iteration)' dentro del mismo contexto.
Si uno integra agentes inteligentes dentro del IDE y realiza prompt engineering avanzado en un entorno real de desarrollo, esa naturaleza probabilística del modelo, más que un 'defecto fatal insuperable', es solo una 'condición base' que debe tratarse como una constante al diseñar el sistema. En la práctica, ya se parte de la premisa de que el modelo puede salirse del contexto, y la forma de trabajar consiste en asegurar control real proporcionando contextos claramente separados o usando contextos de distinta escala.
Sin embargo, este white paper envuelve ese hecho obvio que cualquiera conoce con términos académicos grandilocuentes como 'error categórico' y 'desvío probabilístico', generando ansiedad innecesaria. El objetivo parece claro. Solo degradando por completo la autonomía de los LLM pueden maximizar el valor de la 'red de control determinista diseñada directamente por humanos (sistema SERA)' que proponen.
En última instancia, este texto se parece menos a un white paper con equilibrio técnico y más a un sales pitch sesgado, dirigido a tomadores de decisiones en entornos enterprise que temen los riesgos de las alucinaciones, para convencerlos de que 'adopten nuestro pipeline determinista hardcodeado en lugar de agentes incontrolables'.
El código del trabajo se lo dejo por completo a los agentes de IA, haciendo que el loop sea lo más largo posible.
Los proyectos personales por hobby los desarrollo yo mismo, sin usar asistentes de IA ni autocompletado con IA (...)
Apago las funciones de IA de VS Code y uso Claude Code; definitivamente se siente más cómodo.
Me cambié de
vimavscodepor la IA,pero sentí que había perdido la alegría de desarrollar, así que volví a
vim.Uso la IA como asistente, y definitivamente siento que recuperé la alegría de programar.
Está escrito de forma complicada, pero al final lo que quiere decir es algo que también se aplica a las personas.
La cuestión es si un texto escrito por un tonto A se vuelve mejor solo porque el mismo tonto A lo vuelva a revisar.
Claro, en una minoría de casos existe la posibilidad de que mejore, y también existe la probabilidad de acertar todas las preguntas al azar y sacar puntaje perfecto en el examen de acceso universitario, pero en la mayoría de los casos no hace más que regresar al nivel promedio de A tras N intentos.
(No puedo decir que esté completamente de acuerdo con el Chapter 2.)
Aun así, como dice el paper, estaría bien que entendieran que cualquier what-ever Scaling Law es una ley de crecimiento temporal, no algo eterno.
Si hubieran leído bien el paper de OpenAI, ni siquiera dirían algo así.
La verdad, más que 100 papers como ese, bastaría con demostrar que alguien que afirma que "sí se puede" realmente se convierte en esa persona.
El problema es que solo están haciendo alquimia del "sí se puede".
Personalmente, siento de forma muy clara que la IA es bastante mala en mi área de especialidad. Supongo que para los expertos de otros campos pasa lo mismo. Claro que ayuda mucho. Aunque termino escribiendo documentos fastidiosos todo el día, de ninguna manera se compara con la productividad de antes.
La atención se forma por mayoría.
Los agentes de verificación solo necesitan pasar la función de evaluación.
La mayor parte del buen código industrial no está público.
El código open source es código hecho para mostrarse.
Hay que usarla teniendo siempre presente este punto.
Según los resultados de los experimentos de nuestro laboratorio, es un modelo que el equipo de Qwen, sin el verdadero equipo de Qwen, lanzó apresuradamente solo para ajustarse a los benchmarks e intentar manejar la ansiedad del mercado. Tiene una obsesión muy fuerte con las herramientas. Creemos que es un retroceso frente a la 3.5.
Fuera de las implementaciones en ciclos cortos, no me queda claro qué le queda a Agile.
El backlog y los sprints ya existían antes bajo otras formas, y mucha de la comunicación con el cliente no encaja con la realidad. Al final, creo que más que Agile, las mejoras en DevOps han traído más avances al desarrollo.
Al escribir software, el problema no es tanto la abstracción, sino la ambigüedad. El lenguaje natural es inherentemente ambiguo. Incluso puede tener múltiples interpretaciones. Por eso quizá los intentos de programar con lenguaje natural no funcionan bien. Dadas estas circunstancias, ni soñar con que el lenguaje natural reemplace al código.
Este tipo de contenido parece una fijación con formas de trabajo del pasado. De todos modos, en esas partes la IA terminará haciéndolo mejor. Lo importante ahora es la experiencia de mejorar lo que no sale bien al usar la IA. Pero también creo que esto será algo temporal.
Puede variar según la persona, pero me parece que en temas de computación casi todos estudian de la manera que mencionas. En estos días también existe la opción de aprender con videos, así que habrá que hacerlo con el método de aprendizaje que mejor le funcione a cada quien.
Entonces, ¿cómo aprendieron un lenguaje de programación funcional puro? Hasta ahora he aprendido lenguajes de programación (C, Go, Python, etc.) con libros técnicos + proyectos paralelos, ¿está bien seguir ese mismo enfoque de aprendizaje también con los lenguajes de programación funcional?
La IA se siente como usar un taladro eléctrico, una motosierra o una excavadora. Desde que usamos celulares, hay mucha gente que ni siquiera recuerda su propio número de teléfono.
...Esto también podría verse como un deterioro, pero yo lo veo como eficiencia. Desde mi experiencia como desarrollador y en varios otros roles, considero que las herramientas de IA son también una oportunidad y una ayuda para salir del mundo exclusivo de los desarrolladores y tener una perspectiva más amplia. En una parte puede haber deterioro, pero ese espacio se llena con otras cosas.
Mi experiencia y la conclusión de varias personas era que la forma correcta de estudiar un lenguaje funcional era hacerlo con un lenguaje funcional puro.
Eso se decía cuando los lenguajes funcionales empezaban a ganar atención y también en la época en que recibían mucho interés, y yo estaba de acuerdo. Yo estudié con Erlang en sus primeros años, y en ese momento fue una experiencia bastante impactante y sorprendente.
Como Clojure salió hace bastante tiempo, me da curiosidad por qué se vuelve a hablar de Clojure. Al principio, cuando salió Clojure, tuve la experiencia de reseñar un libro sobre el tema. Después vi algunas empresas que intentaron usarlo, pero la conclusión fue que no era fácil de utilizar en un entorno empresarial. Y cuando parecía que iba a quedar enterrado, me pregunto por qué vuelve a salir la conversación.
He usado Java desde sus inicios durante mucho tiempo, pero aunque la JVM sigue usándose bastante por razones como que en las grandes empresas ya hay mucho software desarrollado en Java, que (en el caso de Estados Unidos) gran parte de la fuerza laboral india domina Java, y que se enseña Java desde la preparatoria hasta la universidad, entre otras cosas, en mi opinión ya no encaja con la época actual. Me gusta Lisp, pero no encontré en el texto de arriba qué ventajas hacen que, en plena era de la IA, vuelvan a destacarse un lenguaje bastante minoritario y un enfoque de JVM que parece ir en declive.
La publicidad y el marketing ya eran así desde antes de internet, pero ahora, como ha cambiado lo que ve la gente y ya no se puede regular, abundan técnicas que rozan la estafa.
Como nunca he aprendido bien un lenguaje de programación funcional, estoy pensando en empezar con Clojure. ¿Cómo debería estudiarlo? Les agradecería mucho sus consejos.
Parece que Daniel Han, fundador de Unsloth, es un verdadero genio. Cada vez que sale un modelo de pesos abiertos, comparte análisis desde la arquitectura del modelo hasta bugs de tokenización, errores de cuantización y errores de plantillas, y de verdad es impresionante.