När når vi AGI?

Jag börjar nästan luta emot att tro att det inte kommer vara effektivitetshöjande på lång sikt. Koden som kommer ut är inte produktionsklar.

För att kunna göra den klart behöver man erfarenhet.

Och erfarenhet får man inte när man inte har skrivit kod själv.

Så det blir en catch-22 där så småningom som kommer bromsa utvecklingen.

LLM'er har mycket bredare användning än bara generering av kod. Men tar vi specialfallet mer generering av kod, kan man dra en parallell med införandet av kompilatorer.

I båda fallen har vi en högre nivås beskrivning där ett verktyg genererar en beskrivning (kod) på lägre nivå.

När kompilatorer blev mer vanliga så gjordes det fel emellanåt. Och genererade kod som var kass map utrymme och hastighet. Det förekom att ett program utvecklades i t ex Fortran för att utvecklarna sedan övergav källkoden och bara patchade i assemblerkoden. För att rätta felen, öka exekveringsprestanda och minska utrymmet.
Dvs ungefär där en del skulle säga att vi nu är.

Men kompilatorerna blev bättre och med tiden minskade assemblerkodning ned. Kompilatorerna gjorde nästan aldrig fel. Och genererad kod blev bättre än typisk manuellt skriven kod. Och produktiviteten ökade med att skriva i högnivåspråk. Kan väl också sägas att minne blev billigare och datorerna snabbare. Så problemen med minnesutnyttjande, och exekveringsprestanda minskade ned.

Det är väl inte otroligt att vi kommer se en liknande utveckling här. Dvs prompting skill bestämmer mer av kodens prestanda och egenskaper. Desto mer biblioteksfunktioner som är optimerade av människor som används desto bättre kvalitet på LLM-genererad kod. Det man kommer hamna i mer och mer är att LLM'erna hittar och integrerar biblioteksfunktioner.

Mycket handlar det om att göra dedicerade LLM'er som är speciellt bra på SW-utveckling. De behöver inte tränas på annat.

Men det kommer ju ta år. Så var det med kompilatorerna också.

Sedan skall man inte glömma att det tar år att ändra näringslivet. Det tar lång tid att utvärdera och ändra om i processer.

En del, både här i forumet, och på nätet menar att de kan hålla igång ett helt team av utvecklare i form av agenter och LLM'er. Går ju en del tokens för det. Men det verkar ju möjligt. Sedan lär det krävas en hel del skill i att skriva agenterna och prompterna.
OCH idag kanske detta fungerar för viss typ a kod som LLM'erna har tränats enormt på. Ska du skriva något där det knappt finns träningsdata på så går det troligen inte alls bra.

Men min kommentar handlade mycket om sådant som inte var ren kodgenerering.

Det beror på vad man menar med det. Med produktionsklar kod menas ofta kod som går att underhålla, dvs, den är lättläst för oss människor. Det uppnås ofta med objektorientering, ramverk, mönster och principer som clean code, m.m.

Om AI-agenterna kodar finns inte samma behov av lättläst kod. Visst, det kan inte vara total rappakalja men för en agent spelar det ingen roll om en funktion är på en halv skärmsida eller 8 skärmsidor. Det går ju t.o.m enklare/snabbare för en AI att analysera att större stycke "spaghetti" än din logiskt fulländade 7-lagers arkitektur. Den är svårare att analysera maskinellt.

Jag respekterar alla som fortfarande vårdar sin fina källkod. Det är ett fint hantverk och jag blir nostalgisk. Men tyvärr tror jag att ni är på väg att bli utrotningshotade.

Github kommer att bli ett museum där man kan se hur mjukvara skapades förr i tiden.

Tvärtom tror jag att det att LLMne inte klarar av en god struktur är ett stort problem.

Denna veckan fick jag en agent till att översätta en del (en liten komponent ) av en gammal winform till en blazor komponent.

Agenten klarade av att skriva samma hjälpfunktion exakt likadan i tre olika klasser. Det är precis den sorten beteende som blir problem för den när den ska refaktorera nästa gång.

Och vi kör ganska strikta regler och instruktioner till våra agenter.

Skillnaden är att en kompilator är deterministisk medan en LLM är ikke-deterministisk.

Och att den är ikke deterministisk är ett stort problem vid mjukvaruutveckling

Ja. Dock kan man ju tänk sig att en LLM dedicerad för kodgenerering har en switch att stänga av slumpen.

Man kan ju sänka temperaturen till 0 för att i princip eliminera slumpen vid valet av nästa token (greedy decoding).

Kode agenterna har ju mycket lägre temperatur än tex chat interfacena.

Men beroende på hvilken kontext agenten har (filer den läser, minnen, tidigare context osv) blir den ju ändå ganska stokastisk

Hade den möjlighet att göra rätt? Du tänker kanske på att en människa hade haft i minnet att den där funktionen fanns och borde återanvändas men du måste ibland bjuda agenterna på mer minne/kontext om det är relevant.

Du tycker inte att superintelligent IQ > 135 AGI ska klara av att lista ut sådant av sig själv?

Den kan lista ut det själv. Men oftast har folk inte betalat för den effort och minnesanvändning som krävs för att få tillräckligt mycket kontext. Plus att defaultinställningar är ofta optimerade för snabba svar mer än stor kontext. Din invändning är ungefär som att säga att din nya OLED skärm inte återger färgerna bra när du har ställt in datorn på att visa 256 färger. De högre agentlägena kräver mer och kan göra mer men de är inte gratis.

Stort tack ändå. Jag har läst på om de begrepp och författare du tar upp och har lärt mig nya saker. Jag tror att AI är det som Chalmers kalla en filosofisk zombie. Intelligent men "ingen hemma". Sådana människor finns inte i verkligheten, men de liknar verkliga människor med svår Alexitimi, alltså som inte kan sätta ord på sin subjektiva upplevelser och sina egna känslor. Kanske AI är på autismspektrat...

Ok duktigt, sen följer huvudfrågan om mänskligt medvetande inte bara är epifenomenalt. Därav uppstår den största skillnaden, då försvåras "autismen", AI blir fundamentalt korkad oavsett intelligent uppvisad förmåga.