Ett paketförslag utan färsk registerkontroll är ett minne, inte en uppslagning. Modellen återger vad som var vanligt i träningsdatan. Därför uppstår två olika fel: paketet finns inte alls, eller det finns men är fel val i dag. Båda avgörs på några minuter före installationen — och blir dyra att upptäcka efteråt, eftersom ett beroende är den svåraste raden att ta bort.
Utan färska källor minns modellen namn — den slår inte upp dem
Ett språkmodellsvar som inte använder registret eller någon annan aktuell källa bygger på mönster i text modellen har sett. Paketnamn förekommer ofta i den texten — i kodexempel, svar på forum, blogginlägg och dokumentation. Att generera ett namn som ser ut som ett paketnamn är därför lätt, och det säger ingenting om huruvida namnet motsvarar något som går att installera.
Det gäller även när modellen råkar ha rätt. Utan en redovisad källa kan du inte se om namnet hämtades från registret eller genererades ur samma mönster som ett påhittat. Tonfallet avslöjar inte skillnaden. Det gör däremot en länk till registerposten, publiceraren och det släpp som förslaget bygger på.
Lägg till tidsaspekten. Träningsdata har en horisont, och paketvärlden rör sig snabbare än den. Ett bibliotek kan sedan dess ha bytt namn, delats upp, ersatts av något inbyggt i språket eller slutat underhållas. Ett verktyg med nätåtkomst kan överbrygga glappet, men bara om det faktiskt hämtar aktuell registerdata — nätåtkomst i sig gör inte svaret färskt.
En agent som kan söka i registret kan kontrollera paketet före förslaget. Be då om register-URL, publicerare och datum för senaste släpp. Att i stället köra installationen är ingen säker kontroll: ett lyckat kommando betyder bara att något med namnet finns, inte att det är rätt paket, underhållet eller rimligt licensierat.
Fel ett: paketet finns inte
Det ofarliga utfallet är att installationen misslyckas direkt. Du får ett felmeddelande, konstaterar att namnet var påhittat och letar vidare. Kostnaden är några minuter.
Det obehagliga utfallet är att den lyckas. En studie från USENIX Security visar att påhittade paketnamn kan återkomma, vilket gör ett ledigt namn förutsägbart för den som vill publicera skadlig kod under det. Registret vet inte att namnet uppstod i ett modellsvar. Risken börjar dessutom före importen: npm kör installationsskript, och pip kan köra paketets byggbackend vid installation från en källdistribution.
Det här är också skälet till att felet inte kan hanteras som ett stavfel. Ett namn du aldrig har sett förut ska kontrolleras mot det officiella registret innan det körs, inte testas genom att installeras och se vad som händer.
Ett namn du inte känner igen
- Slå upp det i ekosystemets officiella register — inte via en sökmotor, där ett förfalskat projekt kan ranka högt.
- Titta på vem som publicerar och om paketet pekar på ett källkodsförråd som faktiskt innehåller den kod som distribueras.
- Var särskilt uppmärksam på namn som ligger nära ett känt paket — en bokstav, ett bindestreck eller ett prefix ifrån.
- Måste du inspektera paketet, packa upp det utan att köra det eller använd en förbrukningsbar, isolerad miljö utan projektets hemligheter och värddatorns autentiseringsuppgifter. En vanlig virtuell Python- eller Node-miljö är ingen säkerhetssandlåda.
Fel två: paketet finns, men är fel val
Det vanligare felet är tråkigare och märks senare. Paketet existerar, gör ungefär det du bad om, och passerar därför obemärkt in i bygget. Problemet visar sig först månader senare, när det ska uppgraderas eller bytas.
Ingen av de här bristerna syns i diffen. Där står bara en rad i manifestet och en import. Det är därför granskningen av beroenden måste ske när valet görs, inte när koden läses.
Fyra kontroller före installationen
Kontrollerna nedan tar tillsammans några minuter och besvarar frågorna i den ordning som är billigast. Faller den första behövs ingen av de andra.
Lägg märke till att ingen av kontrollerna kräver att du förstår paketets kod. De handlar om vem som står bakom det, hur levande det är och vad det förpliktigar er till — frågor som inte blir enklare av att läsa implementationen.
Frågan före paketet: behövs det alls?
En modell som ombeds lösa ett problem svarar gärna med ett bibliotek, eftersom det är så problem löses i den text den har läst. Men en del av de föreslagna beroendena ersätter något som redan finns i språket eller ramverket, eller några rader du hade kunnat äga själv.
Det finns ingen skarp gräns, och den ska inte heller sättas dogmatiskt. Poängen är att frågan ställs. Modellen ställer den inte åt dig, och den föreslår sällan spontant att du klarar dig utan.
Prompten som gör förslaget kontrollerbart
Du kan inte prompta bort behovet av källkontroll. Men du kan be om ett svar som är lätt att kontrollera i stället för ett som är lätt att lita på. Det följer samma tanke som promptguiden: be om det verifierbara, inte om det som låter komplett.
Jag behöver lösa [problemet] i [språk och miljö].
Föreslå två alternativ och beskriv vad som skiljer dem — inte bara vilket du föredrar.
Säg också om problemet går att lösa med standardbiblioteket eller några rader egen kod, och vad man i så fall förlorar.
För varje paket: ange register-URL, publicerare, senaste släppdatum, licens och direkta beroenden. Skilj på uppgifter du har hämtat från registret och sådant du antar. Gissa inte namn.
Jag kontrollerar uppgifterna mot registret själv — skriv dem så att källan och kontrolltidpunkten går att se.
Sista raden ändrar mer än den ser ut att göra. Den flyttar svaret från rekommendation till underlag, och den gör det naturligt för modellen att skriva "jag är osäker på om det här paketet fortfarande underhålls" i stället för att välja den formulering som låter mest hjälpsam.
Den svåraste raden att ta bort
Nästan all annan AI-genererad kod går att ändra i efterhand. En funktion kan skrivas om, en modul kan flyttas, en dålig abstraktion kan rivas när någon orkar. Ett beroende beter sig annorlunda: när det väl finns i bygget växer det in i koden på ställen ingen planerade, och kostnaden för att byta stiger med varje månad.
Det är hela argumentet för att lägga minuterna före installationen i stället för i granskningen. Kodgranskningsguiden frågar om nya beroenden behövdes, men vid det laget är importen redan skriven och koden byggd runt den. Verktygsguiden beskriver kontextfilen som verktygen läser — där hör era regler för biblioteksval hemma, så att förslagen kommer rätt formulerade från början.
Modellen får gärna föreslå. Den är ofta bra på att komma på vilka kategorier av lösningar som finns, och betydligt sämre på att avgöra vilken ni ska leva med. Det beslutet — och risken i det — är fortfarande ert.