Det var dags att testa vad en state-of-the-art LLM skulle säga om min programkod. Så med lite hjälp packade jag ihop ett C-program på totalt 17000 rader, och bad den komma med förslag på förbättringar och hitta potentiella säkerhetsproblem.

En del saker gjorde den faktiskt rätt.

1. Den förstod att programmets parametrar både kan komma från kommandoraden och en konfigurationsfil, så när den la till en parameter blev den delen faktiskt rätt.

2. Den hittade att jag använde sscanf på ett ställe, vilket onekligen bör tas bort. Kanske ingenting man behöver en LLM för, och inget den egentligen får någon poäng för. Å andra sidan körs det här programmet av användaren själv på sitt eget konto. Är indatat till sscanf rätt så funkar det, är det fel så funkar det inte. Om det sedan blir en core-dump är inte riktigt relevant.

Men så var det allt det negativa.

1. Parametern den la till användes faktiskt aldrig. Vilket jag förstår, för den ändring som skulle krävas för att införa den här parametern på rätt sätt i programmets huvudlogik skulle kräva en total omskrivning av flera tusen rader kod. Vilket jag som har läst de tekniska specarna vet, vilket i sin tur är anledningen till att den här parametern inte redan finns. Dessutom kan man få samma effekt på andra sätt.

2. På flera ställen varnade den om minnesläckor, buffer overflow och liknande. Det var typ "funktion a kan läcka minne, om inte funktion b som anropas i början faktiskt gör rätt". Funktion b som den också fick tillgång till, och som är typ 5 rader lång. Gör funktion b rätt, på precis det sätt som LLM-en tyckte att den behövde göra? Jajamensan. Ändå blev det en varning, som jag fick ägna tid åt att förstå och sedan avfärda.

3. På ett par ställen var det liknande varningar, baserade på att den inte förstod var det inkommande datat kom från, eller vart utdatat tog vägen. Grundproblemet är samma som ovan, den klarade inte av att höja blicken lite.

4. Det mest irriterande var att den påstod ett par saker som helt enkelt inte är sanna. Programmet har till exempel en sprintf där formatsträngen har en "%c", som i sin tur får värdet 0. Det har funkat i decennier på ett dussin olika Unix-versioner. Ändå påstod den att sprintf slutar när den ser en noll-byte, så det här skulle bli fel. Nej. Den slutar när formatsträngen har en noll-byte. Att ha %c med värdet 0 så att det blir en null-byte i utsträngen funkar hur bra som helst.

5. Den gav även en bunt mer generella råd, som att se till att variabler initieras när de skapas. Ni vet, det där jag skrev om för två år sedan. Och visst, den skulle säkert kunna komma med några konkreta förslag både på det och early returns osv. Men, de gånger jag gjort det själv har jag tittat på koden med lite nya ögon, analyserat hur den faktiskt används (det där som LLM-en precis avslöjat att den inte klarar av), och då hittat en bugg eller två för något obskyrt specialfall. Därför måste jag ändå göra sådana ändringar för hand. Även den där parametern som den la till är en grej jag hellre gör själv, eftersom det inspirerar till att abstrahera den hanteringen för att få bort redundansen när samma sak ligger på två helt olika ställen. Efteråt är koden bättre, inte bara längre. Vilket i sin tur gör att nästa parameter skulle bli trivial att lägga till. Jag minskar den tekniska skulden, jag ökar den inte.

Sammantaget fick den ur sig en mix av värdelöshet och lögner. Det som hade varit praktiskt att få en datoranalys av är ett kommunikationsprotokoll, med en fråga typ "om två eller fler program körs parallellt och kommunicerar på det här sättet, kan något av dem hamna i en evig loop?". Men eftersom den inte ens kan analysera hur data skickas från funktion a till funktion b, är en sådan fråga minst sagt en bit bort.

Så nej, jag kommer inte använda någon LLM i år heller, till någonting överhuvudtaget. Men nu har jag provat i alla fall. Även om de verkar vara användbara för andra, är de till exakt noll nytta för mig.