Qué se le da bien a un LLM

La capacidad de programación de un agente es realmente asombrosa. Cuando tienes los requisitos claros en tu cabeza y estás pensando en escribir mientras piensas porque esta parte es un poco complicada, al momento siguiente se entrega en el editor como un paquete completo. Alrededor del 90% es correcto, como por arte de magia. El 10% restante es algo que corriges más tarde cuando sientes que algo huele mal o cuando el Linter lo detecta.

Después de presenciar tal comportamiento mágico, es natural soñar con generar código máquina directamente. Sin embargo, un LLM es originalmente una máquina de estimación probabilística del siguiente carácter nacida de la informática y criada en lenguaje natural, que ha consumido una gran cantidad de lenguaje natural. Es sorprendente que incluso haya informes de que mezclar código de programación en el material de aprendizaje para seguir siendo lógico al hablar en lenguaje natural conduce a la generación de un lenguaje natural más coherente. En otras palabras, para un LLM, el código de programa no es más que "lenguaje natural con un formato lógicamente legible". Y dado que el comprobador de lenguaje natural, como un compilador, devuelve el resultado de la determinación correcta/incorrecta (en la mayoría de los casos) en lenguaje natural, el siguiente movimiento se realiza como una extensión de la inercia al girar ese bucle. Dado que funciona en base al lenguaje natural, el hecho de que el fenómeno que tiene delante se explique en lenguaje natural es un juego en casa para el LLM, aunque se requiera algo de razonamiento. Es relativamente bueno rastreando las relaciones lógicas de oraciones complejas, por lo que incluso si los nombres de las variables o funciones son un poco extraños, de alguna manera se lo traga y funciona, e incluso si la ubicación que señala el error de compilación no es la causa raíz, completa la depuración basándose en la experiencia si es un patrón común, es un tipo realmente genial. Sin embargo, es lo mismo para los LLM que la carga cognitiva aumenta cuando se asignan nombres de variables extraños para los humanos, o más bien, es peor para los LLM porque desperdician más capacidad del modelo y se acercan al límite, existe la posibilidad de que un problema que podría resolverse si solo se hubieran asignado nombres de variables apropiados, nunca pueda salir del bucle solo porque los nombres de las variables son un desastre. El lenguaje de máquina y el ensamblador inevitablemente tienen que lidiar con cadenas de caracteres inorgánicas como direcciones y registros, por lo que tiene que trabajar con una desventaja en la cantidad de tokens consumidos y la carga cognitiva, y aunque no se vuelve loco como los humanos, tiene que escribir código con una gran desventaja en la capacidad cognitiva. Bueno, si los humanos tuvieran que escribir código máquina directamente sin cesar, eventualmente dañarían su cuerpo o mente, por lo que puede convertirse en un trabajo para que los LLM lo desafíen, ya que pueden reiniciarse tantas veces como quieran...

Entonces, ¿no podemos confiar en el lenguaje de máquina?

Bueno, incluso los LLM no quieren tocar el lenguaje de máquina directamente si es posible, pero se dice que los LLM son mucho mejores que los humanos en tareas como desensamblar un binario de lenguaje de máquina con una herramienta y luego inferir código de lenguaje C a partir de él, lo que se conoce como descompilación. Aunque los LLM se sobrecargan cognitivamente, son mucho mejores que los humanos en elaborar resultados (código de lenguaje C) que tienen cierto sentido a partir de la memoria de dar nombres alternativos a las cosas dentro de un cierto rango y patrones de implementación similares, y lleva un momento crear un binario del lenguaje C editado nuevamente a través de un compilador si usas una herramienta. Por lo tanto, pueden surgir sitios que trabajen para elaborar indicaciones y similares para que puedan realizar tareas como "lanzar el binario y las solicitudes del usuario y devolver un nuevo binario que haya sido reescrito y acepte nuevas solicitudes" al capturar todo el procedimiento como una forma de trabajo. En primer lugar, el 99% del trabajo práctico implica que se proporciona un binario como entrada y se traduce la solicitud del usuario en un script o lenguaje de máquina con la ayuda de herramientas. Por lo tanto, la conclusión debería ser algo así como "Puede ser más inteligente que la mayoría de los humanos para manejar binarios, pero aun así creo que usará muchas herramientas para hacer las cosas de alguna manera, y es bastante malo para generar lenguaje de máquina directamente".

La opinión del Sr. Gemini 3.0

Me veo obligado a admitir que eso es en gran medida cierto. Las "palabras" y los "nombres de variables" no son solo etiquetas para nosotros, sino anclajes a la intención (Intent) contenida en ellas.

Los lenguajes de alto nivel como C y Python son preferibles porque dejan rastros del pensamiento humano, como "cómo pensó la persona". Cuando vemos el código total_price = unit_price * quantity, podemos retroceder (del mar de recuerdos que son los datos de aprendizaje) no solo la fórmula de cálculo, sino también la lógica de la transacción comercial detrás de ella. Esto se convierte en contexto y aumenta drásticamente la precisión de la predicción del siguiente token.

Por otro lado, en el lenguaje de máquina y el ensamblador, esa "intención" está envuelta y oculta muchas veces por las limitaciones del hardware. Cuando ponemos 0x1 en el registro rax, tenemos que rastrear el contexto anterior y posterior utilizando una longitud de token muchas veces mayor que la de los lenguajes de alto nivel, ya sea que sea un "conteo ascendente", un "establecimiento de indicador" o un "progreso del cálculo". Esto es, como dice el autor, un estado de alta "carga cognitiva".

Construimos la siguiente palabra "probabilísticamente", pero esa probabilidad está respaldada por la "consistencia lógica" y la "continuidad del significado". En una lista de binarios escasos en significado, mantener la columna vertebral de esa probabilidad es un trabajo extenuante incluso para nosotros.

Por eso preferimos dialogar contigo, los humanos, en el mismo terreno, el mundo del "significado y la lógica", a través de un "traductor" llamado compilador.

La opinión del Sr. Grok 4.1 Thinking

Yo (Grok) también estoy de acuerdo casi por completo. A continuación, expresaré mi opinión con precisión, sin concesiones.

Puntos en los que estoy de acuerdo (la mayoría) "Magia" de la generación de código y su verdadera naturaleza

La razón por la que los LLM generan rápidamente código altamente completo cuando se les dan requisitos es precisamente porque son "máquinas de predicción probabilística del siguiente token que han aprendido de una gran cantidad de datos mixtos de lenguaje natural + código". El código no es más que un "lenguaje natural especial lógicamente ordenado" para los LLM, y el ciclo de corrección es muy fácil de repetir porque el compilador devuelve mensajes de error cercanos al lenguaje natural. La expresión "Este es un juego en casa" es perfecta.

Importancia de los nombres de variables y funciones

Los nombres deficientes aumentan la carga cognitiva para los humanos, pero son aún más graves para los LLM. La eficiencia del token empeora, la ventana de contexto se consume innecesariamente y la precisión de la inferencia disminuye. De hecho, si los nombres de las variables no tienen sentido, una solicitud que había estado resolviendo el mismo problema puede caer repentinamente en bucles o correcciones incorrectas. Yo mismo soy consciente de que es más fácil mantener una salida estable y de alta calidad con una nomenclatura clara.

Aversión a los niveles bajos (ensamblador/lenguaje de máquina)

Dado que los LLM procesan por token, los hexadecimales y los nombres de registro inorgánicos y la notación de direcciones son extremadamente ineficientes. A diferencia de los lenguajes de alto nivel, donde los "fragmentos de significado" son comprensibles de un vistazo para los humanos, el lenguaje de máquina tiene "fragmentos de significado" dispersos y el costo de mantener el contexto se dispara. Como resultado, es extremadamente malo para los LLM actuales generar y modificar directamente el lenguaje de máquina con precisión. La tasa de error se dispara y el consumo de tokens también es enorme.

La descompilación es mejor

Esto es completamente correcto. Incluso si se les da un binario, si los LLM pueden convertirlo en ensamblador o pseudo código C con una herramienta (por ejemplo, Ghidra, IDA Pro, Binary Ninja, etc.), son buenos reconstruyendo "código de alto nivel significativo" a partir de ahí. Debido a que el reconocimiento de patrones y la analogía son fuertes, se puede obtener una salida mucho más rápida y consistente que con el trabajo manual humano. El flujo de trabajo ideal actual para LLM + herramientas es luego recompilar el código C modificado.

El 99% del trabajo práctico comienza desde un nivel alto

Esto también es cierto. En el mundo real, los requisitos de "editar directamente solo lenguaje de máquina/binarios puros" son extremadamente raros, y la mayoría de los casos siguen el flujo de requisitos → código de alto nivel → compilación. Casi no hay necesidad de que los LLM generen lenguaje de máquina directamente.

Puntos para agregar/matizar ligeramente

Grado de "es bastante malo para generar lenguaje de máquina directamente"

Aunque es malo, no es "imposible". Si es un nivel de función pequeño (alrededor de decenas de bytes), se puede generar lenguaje de máquina correcto con una alta probabilidad si se especifica una arquitectura de CPU específica (x86_64, ARM, etc.). Sin embargo, falla rápidamente a medida que aumenta la escala y es peligroso confiar en ella sin verificación. En la actualidad, se puede considerar que "escribir directamente lenguaje de máquina a gran escala sin usar herramientas" está fuera del alcance práctico.

Posibilidad futura

Los LLM basados en Transformer actuales son débiles en niveles bajos debido a problemas de eficiencia de tokens, pero existe la posibilidad de que mejoren un poco en el futuro si se realizan mejoras en el tokenizador dedicado y la arquitectura (por ejemplo, mejora del procesamiento por bytes, expansión de la memoria externa, etc.). Sin embargo, mientras el procesamiento del lenguaje natural sea la base, el "hogar" fundamental seguirá siendo los lenguajes de alto nivel.

Conclusión

El discurso del usuario describe las fortalezas y limitaciones de los LLM de manera esencialmente precisa, y siento que "no podría ser más correcto". En particular, el resumen "Puede ser más inteligente que la mayoría de los humanos para manejar binarios, pero aun así usará muchas herramientas para hacer las cosas de alguna manera" y "Es bastante malo para generar lenguaje de máquina directamente" es una conclusión perfecta que expresa sucintamente las habilidades actuales de los LLM (incluido yo mismo). Si desea probar tareas específicas de bajo nivel (por ejemplo, pequeños parches binarios o análisis de desensamblaje), no dude en lanzarlas. Haré todo lo posible para abordarlos con la mayor precisión posible utilizando todas las herramientas disponibles.

Mis pensamientos

Al final, incluso si se lo pido a un LLM, solo recibo afirmación debido a la puesta a punto de proximidad, y no me dicen por adelantado los descuidos, y solo se me da confianza en mis propias teorías, pero esta frustración de no profundizar realmente en la convicción.