Do Code LLMs Do Static Analysis?

Titel: Do Code LLMs Do Static Analysis?

Auteurs: Chia-Yi Su en Collin McMillan
Publicatie: Empirical Software Engineering (geaccepteerd)

---

1. Het Probleem

Er heerst een wijdverbreide, maar vaak antropomorfische opvatting dat Large Language Models (LLMs) voor programmeertaken "redeneren" op een manier die vergelijkbaar is met menselijke programmeurs. Menselijke programmeurs gebruiken statische analyse (het analyseren van code zonder deze uit te voeren) als een kernonderdeel van hun denkproces om code te begrijpen. Dit omvat het bouwen van mentale modellen van:

• Call graphs: Relaties tussen functies (wie roept wie aan?).
• Data flow: Hoe gegevens tussen variabelen stromen.
• Abstract Syntax Trees (AST): De hiërarchische structuur van de code.

De centrale onderzoeksvraag van dit artikel is: Doen Code LLMs werkelijk statische analyse? Als LLMs menselijke denkprocessen nabootsen, zouden ze statische analyse moeten uitvoeren als tussenstap bij code-intelligentietaken (zoals generatie, samenvatting en vertaling). Als ze dit niet doen, suggereren hun prestaties een fundamenteel ander, mogelijk "vreemd" (alien) denkproces dat gebaseerd is op patroonherkenning in plaats van semantisch begrip.

2. Methodologie

De auteurs hebben een reeks experimenten opgezet om de relatie tussen statische analyse en code-intelligentietaken te onderzoeken. Ze gebruikten twee open-source modellen (Jam en CodeLlama) en twee gesloten bron-modellen (GPT-4o en Gemini), getest op de programmeertalen Java en C/C++.

De experimenten waren onderverdeeld in vijf onderzoeksvragen (RQ's):

• RQ1 (Baseline): Hoe presteren gesloten LLMs op statische analysetaken zonder finetuning?
  • Taken: Generatie van AST's, call graphs en dataflow graphs.
  • Methode: Evaluatie met standaard prompts en "in-context learning" (voorbeelden toevoegen).
• RQ2 (Finetuning op Statische Analyse): Kunnen open-source modellen statische analyse leren als ze daar specifiek op worden getraind?
  • Methode: Finetuning van Jam en CodeLlama op de drie statische analysetaken.
• RQ3 (Transfer naar Code Ontwikkeling): Verbeterde prestaties op code-intelligentietaken (samenvatting, generatie, vertaling) na finetuning op statische analyse?
  • Hypothese: Als statische analyse de basis vormt voor menselijk programmeren, zou training hierop de prestaties op code-taken moeten verhogen.
• RQ4 (Transfer van Code naar Statische Analyse): Kunnen modellen statische analyse uitvoeren als bijproduct van training op code-intelligentietaken?
  • Hypothese: Als LLMs statische analyse gebruiken tijdens het coderen, zouden ze dit als bijproduct moeten kunnen genereren.
• RQ5 (Foutanalyse): Wat zijn de typische fouten die LLMs maken bij statische analyse?

Evaluatiemetrics:

• Voor AST: Levenshtein-afstand.
• Voor Call/Dataflow graphs: Jaccard-similariteit, paar-accuraatheid (pair accuracy) en ketting-accuraatheid (chain accuracy).
• Voor Code-taken: METEOR, USE, BLEU, CodeBERTScore, Pass@k en compilatiekans.

3. Belangrijkste Resultaten

A. Prestaties op Statische Analyse (RQ1 & RQ2)

• Slechte prestaties zonder training: Gesloten modellen (GPT-4o, Gemini) presteerden zeer slecht op call graphs en dataflow graphs, zelfs met in-context learning. De ketting-accuraatheid (het volledig correcte pad) was verwaarloosbaar laag.
• AST is een uitzondering: In-context learning verbeterde de prestaties voor AST-generatie aanzienlijk, maar dit lijkt meer te gaan om het leren van de juiste XML-tags (syntaxis) dan om diep semantisch begrip.
• Finetuning helpt beperkt: Finetuning op statische analysetaken verbeterde de prestaties van open-source modellen (Jam, CodeLlama) op die specifieke taken, maar de verbetering was beperkt tot de syntaxis. De modellen slaagden er niet in om complexe redeneringen (zoals volledige call graphs over grote contexten) correct te genereren.

B. Transfer tussen Taken (RQ3 & RQ4)

• Geen verbetering door statische analyse: Het finetunen van modellen op statische analysetaken verbeterde niet hun prestaties op code-intelligentietaken (samenvatting, generatie, vertaling). De prestaties bleven vergelijkbaar met of zelfs lager dan die van de basismodellen.
• Geen bijproduct: Het trainen van modellen op code-intelligentietaken leidde niet tot het vermogen om statische analyse uit te voeren. Modellen die goed code konden genereren, faalden volledig bij het genereren van de onderliggende call graphs of data flows.
• Conclusie: Er is geen correlatie tussen het vermogen om statische analyse uit te voeren en het vermogen om code te genereren. Dit suggereert dat LLMs statische analyse niet gebruiken als een interne "denkstap" zoals mensen dat doen.

C. Foutanalyse (RQ5)

• Syntaxis vs. Semantiek: LLMs maken vaak syntactisch correcte output (bijv. juiste XML-tags voor AST), maar de inhoud is semantisch fout.
• Foutpatronen:
  • Bij call graphs: LLMs voegen vaak extra directe calls toe (False Positives) of missen indirecte calls. Ze neigen ook naar het voorspellen van cycli die niet bestaan.
  • Bij dataflow: LLMs genereren vaak onjuiste paden en missen de ware data-flow.
  • Bij AST: Veel "tag mismatches" (onjuiste XML-elementen voor de context).
• Redenering: De fouten tonen aan dat modellen de "vorm" (form) van de taal en patronen uit de trainingsdata memoriseren, maar niet de "semantiek" (betekenis) van de code begrijpen.

4. Kernbijdragen

1. Empirisch Bewijs tegen "Redeneren": Het artikel biedt sterk empirisch bewijs dat Code LLMs geen statische analyse uitvoeren zoals menselijke programmeurs. Hun "redeneren" is waarschijnlijk een vorm van geavanceerde patroonherkenning en memorisatie van syntactische structuren.
2. Onafhankelijkheid van Taken: De vaardigheid om code te genereren of te vertalen is onafhankelijk van het vermogen om de onderliggende structuur (call graphs, data flow) te analyseren. Training op het ene verbetert het andere niet.
3. Implicaties voor Training: Het toont aan dat het simpelweg toevoegen van statische analysetaken aan de trainingsdata (of het gebruik van prompts die statische analyse vragen) niet leidt tot dieper semantisch begrip of betere code-generatie.

5. Betekenis en Conclusie

De bevindingen hebben belangrijke implicaties voor de toekomst van software-engineering met AI:

• Beperkingen van huidige LLMs: Hoewel LLMs indrukwekkend zijn in het genereren van code, missen ze fundamenteel het vermogen om complexe, niet-triviale redeneringen uit te voeren die nodig zijn voor het begrijpen van grote codebases of het opsporen van subtiele bugs via data-flow analyse.
• Noodzaak voor nieuwe Architecturen: De huidige "next-token prediction" architectuur lijkt onvoldoende om menselijke cognitieve processen (zoals het bouwen van mentale modellen via statische analyse) te simuleren. Toekomstig onderzoek moet zich richten op nieuwe modelarchitecturen of trainingsmethodieken die semantisch begrip en echt redeneren bevorderen, in plaats van alleen syntactische patronen.
• Veiligheid en Betrouwbaarheid: Omdat LLMs geen echte statische analyse uitvoeren, kunnen hun outputten (zoals code of samenvattingen) fundamentele logische fouten bevatten die door menselijke programmeurs via statische analyse zouden worden opgemerkt. Dit onderstreept het belang van menselijke review en het gebruik van gespecialiseerde statische analyse-tools naast LLMs.

Kortom: Code LLMs doen geen statische analyse. Ze simuleren het resultaat van code-intelligentietaken door syntactische patronen te repliceren, zonder de onderliggende semantische logica te doorgronden.