"Du trenger ikke å kunne koding? Hvorfor hackere tar imot 'vibe coding'-bølgen med gåsehud Etter hvert som flere og flere vibrerer koder, kommer det en tid hvor vi virkelig må være forsiktige, spesielt de som lager blokkjede-relaterte tjenester med vibe-koding. La oss se på hvordan dette vil endre koden til alle selskaper i fremtiden. Den største fordelen med vibe-koding er at selv om jeg ikke vet hvordan jeg skal utvikle det selv, kan jeg bare gjøre det via Prompting. Spesielt når det gjelder front-end-utvikling, blir effektiviteten og virkningen av vibe-koding verifisert i den grad at man kan si at vibe-koding nesten har spist opp hele markedet. Selvfølgelig utvikler vibe-koding seg også veldig raskt, og det blir mer sofistikert og bedre for hver dag, men problemet er at hvis en maskin i stedet for et menneske skriver koden alene på et tidspunkt, er det umulig å vite hvilken kode som er i den og hvor feilen er. Hvis du noen gang har drevet med vibe-koding, har du sannsynligvis lagt merke til følgende fenomen. 1️⃣ Jeg klarte det, men problemet med å endre selv de delene jeg ikke hadde gjort, ble endret 2️⃣ Jeg bestilte den, men minnepoolen er for full, så jeg hører ikke på deg lenger (så jeg må kutte den av og la den virke) 3️⃣ Jeg fikser en feil, men det er et problem som er løst. (Og hvis du ikke er utvikler, vet du ikke hvor eller hvordan det er ødelagt) Case 3 er en del som ofte oppstår, spesielt når man jobber med en veske i stedet for en front. Dette er en av grunnene til at jeg kun gjør det lokalt og ikke deployerer mens jeg koder vibber. Selv om du koder på overflaten, finnes det ingen måte å verifisere om det faktisk fungerer som det skal (noen ganger fyller AI bare inn det synlige og fungerer ikke hvis det er vanskelig å gjøre det som et menneske), og hvis et problem oppstår, er det ingen måte å verifisere om problemet er riktig løst. Problemet er at titusenvis av linjer kode brukes, og personen som instruerte og utførte arbeidet har ikke mulighet til å "verifisere" mellom AI og AI. Det største problemet for dem som har ansatt utviklere som ikke-utviklere til å jobbe, er sannsynligvis at hvis utvikleren sier «nei», «kan de ikke bevise at det vil fungere». Når det gjelder AI, sier den ikke «nei», men hvis du fortsetter å gjøre det som ikke fungerer, vil du gjøre det ved å lure deg med en militær tankegang. Med andre ord, til syvende og sist må arrangøren som utfører prompting også vite hvordan man utvikler seg til en viss grad for å kunne bruke AI-en riktig. Og det største problemet vi står overfor er at vi ikke lenger trener juniorutviklere. Med andre ord, hvis det går mer enn fem år uten at juniorer lenger er opplært fordi de foretrekker seniorer som er flinke til å håndtere AI og får jobb, kan vi leve i en tid hvor vi er helt avhengige av AI og må gjøre noe med kode vi ikke kan, eller vi må kanskje nærme oss det i form av «stol på og stol». Dette er spesielt ødeleggende for økosystemer som blokkjededer, hvor kode og midler er bundet sammen på ett sted. Dette betyr at i det øyeblikket en smart kontrakt med en enkel feil blir en distribusjon, kan midlene allerede bevege seg fritt. Og faktisk, når det gjelder hackere, forventes det mange fenomener som tjener på å jakte på og utnytte kun disse unike svakhetene ved AI. 🔰Personlige tanker Så ikke vibe-kode? Ikke egentlig. Dette er fordi du må fortsette å se og prøve det selv for å se hvor langt du kan gå. Men når det gjelder vibe-koding, er det fortsatt et verktøy, likt AI-agenter og LLM-er tidligere. Jeg tror nøkkelen er å vite hvor langt verktøyet kan gå og hvor det kan brukes.