Amazons kodassistent kunde radera användares data

Det är lugnt, ingen skada skedd. Och hade det varit någon skada så hade nog dom flesta ej kunnat bevisa i domstol att det var just Amazons Q som var orsaken.

Enligt denna artikel: https://www.scworld.com/news/amazon-q-extension-for-vs-code-r... så rörde det sig om prompt injections vilket möjligtvis kunde ha nyanserats i artikeln gällande "skadlig kod"? Jag trodde först det hela handlade om faktisk skadlig kod i själva insticksmodulen (eng. "extension"). Detaljer spelar roll!

LLM:er är ju "skräddarsydda tärningskast" så även om du har en LLM som ska granska en annans LLM:s potentiella innehåll av skadlig kod och/eller prompts så är det fortfarande bara "slumpen baserat på träningsdata" huruvida den "upptäcker" det eller inte. Sedan är det återigen "slumpen" huruvida det upptäckta (falskt alarm eller inte) är korrekt eller något annat "statistiskt möjligt men ej med i den granskade koden". (="hallucinationer")

Jag älskar LLM:er men avskyr så kallad "vibbprogrammering" då det sistnämnda har starka incitament att inte kodgranska tillräckligt noga. Om Du skulle kodgranska allt från vibbprogrammering in i minsta detalj, då kunde du ju lika gärna ha skrivit det själv från början? (då det tappat sitt primära syfte: kodhastighet) Att schavottera fram standardkodsformuleringar (eng. "scaffolding boilerplate kod") är en annan sak.

Mvh,
WKF.

https://www.mbgsec.com/posts/2025-07-24-constructing-a-timeli...

Här låter det som att det varit två separata incidenter, en första där de lyckades få obegränsad(?) tillgång till repot (oklart hur det gick till), och sedan att de lade till sin elaka ändring direkt utan att behöva gå igenom någon granskningsprocess.

Som alltid när det kommer till allt så måste man vara nyanserad. Vi tillåter välbetalda programmerare att göra fel. Varför måste då AI vara helt felfri? Inte rimligt i verkligheten. Misstag kommer ske (för det är billigare), frågan är bara hur man äger sina misstag. Amazon fick bottenpoäng när de berättade publikt om incidenten omgående.

Det fetmarkerade är en del i det jag vill komma åt: Med "vibbprogrammering" så kan incitamenten öka ännu ytterligare till att vara ännu mindre noga eftersom tanken är att nyttja vibbprogrammering för att få mer gjort på kortare tid och möjligtvis på så vis vara konkurrenskraftigare (t.ex. billigare). Ju billigare något tenderar att bli, desto fler genvägar tenderar arbetstagare, uppdragstagare och/eller företag att ta - på gott och ont.

Kombinera detta sedan med den potentiella faktorn att troligen ingen vill ta på sig ansvaret över någon annans bortgång pga. kodslarv i samhällskritisk mjukvara som t.ex. ventilatorer, dialysmaskiner, mm. på sjukhus.

Om det primärt har vibbprogrammerats så blir det lättare att bara ansvarsfriskriva sig - både på företags- och individnivå. ("Sådana här incidenter är ju omöjliga att undvika, tragiskt oavsett!" - anmärk den indirekta nonchalansen här genom att ha valt snabbare slarv istället för långsammare och mindre sannolikare slarv)

Återigen: Du tappar i princip hela syftet med vibbprogrammering om du ska börja kodgranska in i minsta detalj. Då kan du lika gärna skriva själv från början och bara nyttja autocompletes (vilket jag personligen enbart gör med LLM:er såväl som "bollplank" i nätchatter med dem).

Personligen upplever jag en slags kräkframkallande känsla över vibbprogrammering då det finns en slags nonchalans mot slutresultatet och dess potentiella enorma skador i samhället om det når samhällskritisk mjukvara: "Skitsamma om det skiter sig, det gick fort och var ju billigt å smidigt å jag kunde ta helg tidigare denne fredag!"

(Detta är möjligen hur grafiska formgivare känner mot all dagens AI-baserade bildgenererande)

Mvh,
WKF.

Det kommer nog en flora av LLMs snart med olika constraints på sig. Olika säkerhetslösningar för olika LLM, men alla granskar sig själva (och testar) att det följs. Nu i början hade jag aldrig litat på det men efter några år kommer det vara vardagsmat.

Ta dagens ramverk som exempel. Inte många utvecklare som tänker på sql injections när de bygger hemsidor i Angular för ramverket tar hand det åt dem. Och gör det generellt bättre än medelutvecklaren eftersom ramverket är konsekvent och konstant.

Många tyckte code completion var trams när det kom för herrans massa år sedan. Men idag tror jag de flesta använder det. All teknik behöver mogna några år