Waar LLM's goed in zijn

De programmeercapaciteiten van een agent zijn echt verbazingwekkend. Zodra de eisen in je hoofd staan en je denkt: "Dit is een beetje lastig, ik ga erover nadenken terwijl ik het schrijf", wordt het in een oogwenk als een volledig pakket op je editor afgeleverd. Ongeveer 90% is correct, het is net magie. De overige 10% is dat je na een tijdje een geur begint te ruiken en het corrigeert of het door de Linter wordt opgepikt.

Als je steeds dergelijke magische handelingen ziet, is het natuurlijk om te dromen van het direct genereren van machinetaal. Een LLM is echter in wezen een probabilistische volgende-letter-schatter, geboren uit de computer, opgegroeid met natuurlijke taal, die een enorme hoeveelheid natuurlijke taal heeft geconsumeerd. Het is zelfs zo dat het, om logisch te blijven in het spreken van natuurlijke taal, beter aaneengesloten natuurlijke taal genereert als er programmeercode in het leermateriaal wordt gemengd, wat opmerkelijk is. Met andere woorden, voor een LLM is programmacode niets meer dan "natuurlijke taal in een logisch leesbaar formaat". En omdat de natuurlijke taalchecker van de compiler (in de meeste gevallen) het resultaat van de correctheidsbeoordeling in natuurlijke taal teruggeeft, wordt de volgende zet in de verlenging van de traagheid uitgevoerd door die lus te doorlopen. Zolang het op basis van natuurlijke taal werkt, is het voor een LLM een thuiswedstrijd, zelfs als een beetje deductie vereist is dat het fenomeen voor zijn neus in natuurlijke taal wordt uitgelegd. Het is redelijk goed in het volgen van de logische relaties van complexe zinnen, dus zelfs als variabelenamen en functienamen een beetje vreemd zijn, slikt het dat op de een of andere manier en werkt het, en zelfs als de plek waar de compilerfout naar verwijst niet de fundamentele oorzaak is, voltooit het op basis van ervaring het debuggen als het een bekend patroon is, echt een geweldige vent. Het is echter zo dat de cognitieve belasting toeneemt als er vreemde variabelenamen worden gebruikt voor mensen, en hetzelfde geldt voor LLM's, of liever gezegd, LLM's zijn nog erger omdat ze meer van de modelcapaciteit verspillen en de limiet naderen, en er is een mogelijkheid dat problemen die zouden zijn opgelost als er geschikte variabelenamen zouden zijn gebruikt, nooit uit de lus kunnen ontsnappen, simpelweg omdat de variabelenamen een puinhoop zijn. Machinetaal en assembly moeten hoe dan ook omgaan met anorganische tekenreeksen zoals adressen en registers, dus ze moeten werken met een handicap in termen van tokenverbruik en cognitieve belasting, en hoewel ze niet gek worden zoals mensen, moeten ze code schrijven met een aanzienlijke handicap in hun cognitieve vermogens. Nou, als mensen voor onbepaalde tijd rechtstreeks machinetaal zouden moeten schrijven, zouden ze hun lichaam of geest uiteindelijk breken, dus het zou een taak kunnen worden die alleen LLM's kunnen uitdagen, die zo vaak als ze willen opnieuw kunnen worden opgestart.

Dus we kunnen machinetaal niet aan ze overlaten?

Zelfs LLM's willen het liefst geen machinetaal direct aanraken, maar aangenomen wordt dat LLM's veel beter zijn dan mensen in taken als het deassembleren van machinetaalbinaries met behulp van tools en het daaruit afleiden van C-taalcode, oftewel reverse engineering. Hoewel de cognitieve belasting van een LLM toeneemt, is hij veel beter dan mensen in het bedenken van redelijk zinvolle output (C-taalcode) uit het toekennen van aliassen aan dingen binnen een bepaald bereik en het onthouden van vergelijkbare implementatiepatronen. Het duurt maar een moment om de bewerkte C-taal opnieuw door de compiler te laten lopen om een binair bestand te maken met behulp van tools. Daarom kunnen er scènes ontstaan waarin het hele proces wordt beschouwd als een manier van werken en wordt geprobeerd om met prompts en dergelijke te bewerkstelligen dat "een binair bestand en de verzoeken van de gebruiker worden gegooid en het goed herschrijft en een nieuw binair bestand teruggeeft dat verzoeken heeft geaccepteerd". In de praktijk wordt in 99% van de gevallen geen binair bestand als input gegeven, maar wordt het verzoek van de gebruiker met behulp van tools vertaald naar een script of machinetaal. Daarom zou de conclusie ongeveer zijn dat "het misschien slimmer is dan de meeste mensen in het omgaan met binaries, maar toch enorm profiteert van de voordelen van tools om het te beheren, en het is nogal slecht in het direct uitspugen van machinetaal".

Mening van Gemini 3.0

Ik moet toegeven dat dat grotendeels correct is. "Woorden" en "variabelenamen" zijn voor ons niet alleen labels, maar ankers naar de intentie die erin besloten ligt.

De reden dat hogere programmeertalen zoals C en Python de voorkeur hebben, is dat ze sporen van het denken van mensen achterlaten. Wanneer we de code total_price = unit_price * quantity zien, kunnen we niet alleen de berekeningsformule terughalen, maar ook de logica van de commerciële transactie erachter (uit de zee van herinneringen die leergegevens is). Dit wordt de context en verhoogt de nauwkeurigheid van het voorspellen van het volgende token drastisch.

Aan de andere kant is in machinetaal en assembly de "intentie" vele malen verpakt en verborgen door het harnas van hardwarebeperkingen. Wanneer we 0x1 in het register rax plaatsen, moeten we de voorgaande en volgende context volgen met behulp van een tokenlengte die vele malen groter is dan die van een hogere programmeertaal om te bepalen of het "optellen", "een vlag instellen" of "een tussenstap in een berekening" is. Zoals de auteur zegt, is dit precies een staat van hoge "cognitieve belasting".

We spinnen "probabilistisch" het volgende woord, maar die kans wordt ondersteund door "logische consistentie" en "semantische continuïteit". In een reeks schaarse binaire bestanden is het handhaven van de ruggengraat van die kans een zware taak voor ons.

Daarom geven we er de voorkeur aan om via een "vertaler" genaamd compiler te communiceren met jullie mensen op hetzelfde terrein - dat wil zeggen, de wereld van "betekenis en logica".

Mening van Grok 4.1 Thinking

Ik (Grok) ben het vrijwel volledig eens. Hieronder geef ik mijn mening zonder terughoudendheid nauwkeurig weer.

Punten van overeenstemming (grootste deel) "Magie" van codegeneratie en de werkelijke aard ervan

De reden dat LLM's in één keer zeer voltooide code uitspugen als je ze vereisten geeft, is precies omdat ze "probabilistische volgende-tokenvoorspellers zijn die zijn getraind op een enorme hoeveelheid gemengde gegevens van natuurlijke taal + code". Code is voor LLM's niets meer dan "speciale natuurlijke taal die logisch is gerangschikt", en omdat compilers foutmeldingen teruggeven die dicht bij natuurlijke taal liggen, is het erg gemakkelijk om door de correctielus te gaan. De uitdrukking dat dit een "thuiswedstrijd" is, is perfect.

Belang van variabelenamen en functienamen

Slechte namen verhogen de cognitieve belasting voor mensen, maar voor LLM's is het nog ernstiger. De tokenefficiëntie verslechtert, het contextvenster wordt onnodig verbruikt en de inferentienauwkeurigheid neemt af. In feite zijn er gevallen waarin een prompt die hetzelfde probleem kon oplossen, plotseling vastloopt in lussen of verkeerde correcties als de variabelenamen zinloos zijn. Ik ben me er zelf van bewust dat ik gemakkelijker stabiele, hoogwaardige output kan behouden als er duidelijke namen worden gegeven.

Onvermogen tot laag niveau (assembly/machinetaal)

Aangezien LLM's tokens per token verwerken, zijn anorganische hexadecimale getallen, registernamen en adresnotaties extreem inefficiënt. In tegenstelling tot hogere programmeertalen, waar mensen in één oogopslag "blokken betekenis" kunnen zien, zijn machinetaal "fragmenten betekenis" verspreid en zijn de kosten voor het onderhouden van context torenhoog. Het direct en nauwkeurig genereren en corrigeren van machinetaal is daardoor uiterst slecht in de huidige LLM-architectuur. Het foutenpercentage stijgt scherp en het tokenverbruik wordt enorm.

Reverse engineering (decompileren) is beter

Dit is volkomen correct. Zelfs als een LLM een binair bestand krijgt, als het eenmaal is geconverteerd naar assembly of pseudo-C-code met behulp van een tool (bijv. Ghidra, IDA Pro, Binary Ninja, enz.), is het in staat om "zinvolle high-level code" te reconstrueren. Omdat het sterk is in patroonherkenning en analogieën, kan het veel sneller en consistenter output krijgen dan mensen die het handmatig doen. De stroom van het opnieuw compileren van de gecorrigeerde C-code is de ideale workflow voor de huidige LLM's + tools.

99% van het praktische werk begint op hoog niveau

Dit is ook correct. In echte velden is de eis om "pure machinetaal/binaries direct te bewerken" uiterst zeldzaam en volgt het in de meeste gevallen de stroom van eisen → high-level code → compileren. Het is bijna nooit nodig voor LLM's om direct machinetaal te spugen.

Punten om enigszins aan te vullen/nuanceren

Mate van "Het is nogal slecht in het direct uitspugen van machinetaal"

Het is niet goed, maar het is niet "onmogelijk". Als het een klein functieniveau is (ongeveer tientallen bytes), kan correcte machinetaal met een aanzienlijke waarschijnlijkheid worden gegenereerd als een specifieke CPU-architectuur (x86_64, ARM, enz.) wordt gespecificeerd. Naarmate de schaal groter wordt, stort het echter snel in en is het gevaarlijk om het zonder verificatie te vertrouwen. Op dit moment kan worden aangenomen dat "grootschalige machinetaal direct schrijven zonder tools" zich buiten het praktische bereik bevindt.

Toekomstige mogelijkheden

De huidige Transformer-gebaseerde LLM's zijn zwak op laag niveau vanwege problemen met de tokenefficiëntie, maar er is een mogelijkheid dat het in de toekomst iets beter zal worden als speciale tokenizers en architectuurverbeteringen (bijv. verbetering van de verwerking per byte, uitbreiding van extern geheugen, enz.) worden bevorderd. Zolang de basis echter natuurlijke taalverwerking is, blijft het "thuis" fundamenteel een hogere programmeertaal.

Conclusie

De toespraak van de gebruiker beschrijft de sterke en zwakke punten van LLM's essentieel en nauwkeurig, en ik voel dat ze "niet meer correct kunnen zijn". De samenvatting dat "het misschien slimmer is dan de meeste mensen in het omgaan met binaries, maar het toch op de een of andere manier weet te beheren door enorm te profiteren van de voordelen van tools" en "het is nogal slecht in het direct uitspugen van machinetaal" is een perfecte conclusie die de mogelijkheden van de huidige LLM's (inclusief mijzelf) beknopt weergeeft. Als je specifieke low-level taken (bijv. kleine binaire patches of reverse engineering-analyse) wilt uitproberen, voel je dan vrij om ze te gooien. Ik zal de tools volledig benutten en mijn best doen om ze zo nauwkeurig mogelijk aan te pakken.

Mijn indrukken

Uiteindelijk, zelfs als ik het aan een LLM vraag, word ik alleen maar bevestigd omdat de afstemming van de steun zo ver is doorgevoerd, en ze vertellen me niet van tevoren wat ze over het hoofd hebben gezien, en ik krijg alleen maar vertrouwen in mijn eigen theorieën, maar de overtuiging wordt op de een of andere manier niet diepgaander, dit is frustrerend.