AI-koodausavustimet, keskustelua AI-avustetusta koodaamisesta/skriptaamisesta/dokumentoinnista/...

[Karhu III]

Tuo on oikeasti hyvä tilanne. Voipi tehdä vaikka kaikenlaista mahdollisesti hyödyttävää työtä siivoamisesta tulevaisuusjuttuihin. Yksi mikä vois olla kiinnostava niin kokeilla tehdä Mojo:lla kiihdytykset cudan sijaan. Aika mielenkiintoinen häkkyrä ja pääsee nvidian ikeestä pois. Toki toimii hyvin nvidiallakin. Mulla ollut mielenpäällä että vois mojolla olla kiva kokeilla jotain demoefektityylisiä kerneleitä jotka kiihdyttyis ... valtavasti ...

Mojon taustalla chris lattner joka ei liene tarvi esittelyjä(llvm, clang, swift,...) Mojossa ideana tehdä pythonin näköisellä erittäin hyvin rinnakkaistuvaa koodia mitä voi ajella cpu(simd,avx,...)/gpu/... kiihdyttimillä

Mojo 🔥: Powerful CPU+GPU Programming

Mojo is a programming language that unifies high-level AI development with low-level systems programming. Write once, deploy everywhere - from CPUs to GPUs - without vendor lock-in.

www.modular.com

No siis mulla on ihan sama tarkoitus, mutta Mojon sijasta käytössä on ILGPU. Eli C#:llä kirjoitetaan kernelit ja ILGPU sitten kääntää ne ajon aikana natiiviksi koodiksi. Ihan vain siksi että olisi helpompi ylläpitää ja optimoida eikä tarvitsisi liimailla C++:lla kirjoitettuja C-kirjastoja C#-ohjelmaan.

Tosin voisi se nyt olla Mojokin kun ollaan AI-aikakaudella. Ne syyt miksi halusin pois natiivista CUDA- ja C-koodista eivät enää päde

 

[Karhu III]

Koodaus alkaa olla ratkaistu ongelma. Tämänhetkiset tulokset ennen kuin laitan yöksi jauhamaan:

Scenario	Portable encode-only	nvJPEG encode-only	Difference
Mono rst16 parallel	0.566 ms	0.335 ms	1.69x slower
4:4:4 rst16 parallel	1.250 ms	0.441 ms	2.83x slower
4:2:0 rst16 parallel	0.777 ms	0.462 ms	1.68x slower
Planar 4:2:0 rst16 parallel	0.757 ms	0.462 ms	1.64x slower

 

[El Toro]

Olen nyt koodannut samaan aikaan omaa peliprojektia.

Jokin aika sitten kaivoin vanhan peliprojektini esiin, olin viikkoja optimoinut sitä ja FPS oli ~300, pari promptia ja oltiin tuhannessa hienompien efektien kera. Tuli jotenkin masentunut fiilis siitä, osaanko enää mitää paremmin kuin nämä mallit? Voisikin nyt laittaa 5.5 jauhamaan sitä, kun tässä ei muutakaan käyttöä keksi.

 

[Karhu III]

Viimeöinen JPEG-optimointi oli sitten kosahtanut blue screeniin. Grayscale menee jo 1,1x vauhtia, värikuvat vielä 1,5x nopeudessa.

 

[finWeazel]

Viimeöinen JPEG-optimointi oli sitten kosahtanut blue screeniin. Grayscale menee jo 1,1x vauhtia, värikuvat vielä 1,5x nopeudessa.

CUDA:han kääntyy ptx-assembleriin. Osa taloistahan optimoi nvidialle suoraan assylla kun sen kautta voi tehdä kikkoja mitä varsinainen cuda kääntäjä korkeamman tason kielestä ei tee. AI vois kokeilla analysoida assyt(jos et tee jo näin) ja antaa AI:n kirjoittaa parempaa koodia hot looppeihin. Voi olla hauska harjoitus jos on tokeneita mitä poltella pois.

 

[Karhu III]

CUDA:han kääntyy ptx-assembleriin. Osa taloistahan optimoi nvidialle suoraan assylla kun sen kautta voi tehdä kikkoja mitä varsinainen cuda kääntäjä korkeamman tason kielestä ei tee. AI vois kokeilla analysoida assyt(jos et tee jo näin) ja antaa AI:n kirjoittaa parempaa koodia hot looppeihin. Voi olla hauska harjoitus jos on tokeneita mitä poltella pois.

Hyvä idea tämäkin. ILGPU kääntää koodin, ja annoin AI:lle tehtäväksi auditoida sen lähdekoodit ja sitä kautta etsiä voisiko koodi olla tehokkaampaa tai voisiko tuottaa tehokkaampaa koodia. Mitään kriittistä ei löytynyt, mutta ILGPU:n auditoinut AI antoi vinkkejä JPEG-koodin optimointiin ja sitä kautta löytyi tuloksia. Nyt joissain tapauksissa ollaan nopeampi kuin NVidian kirjasto.

Yes, faster cases from this run:

1920x240 mono:

nvJPEG: 0.183 ms
portable mono-rst16-current: 0.107 ms
ratio 0.58x, so portable is about 1.7x faster.


1920x240 planar 4:4:4:

nvJPEG: 0.281 ms
portable best/current rows around 0.225-0.239 ms
ratio around 0.80x-0.85x, so portable is faster.


1280x720 mono:

nvJPEG: 0.207 ms
portable best current row: 0.169 ms
ratio 0.82x, so portable is faster.


Where nvJPEG still wins:

1920x1080 mono:

nvJPEG: 0.278 ms
portable rst16-current: 0.316 ms
ratio 1.14x, close but still slower.


1920x1080 planar 4:4:4:

nvJPEG: 0.445 ms
portable current best around 0.703 ms
ratio 1.58x, still meaningfully slower.

 

[finWeazel]

Hyvä idea tämäkin. ILGPU kääntää koodin, ja annoin AI:lle tehtäväksi auditoida sen lähdekoodit ja sitä kautta etsiä voisiko koodi olla tehokkaampaa tai voisiko tuottaa tehokkaampaa koodia.

Ehkä agentin vois saada mcp-serverin avulla suht järkevällä vaivalla profiloimaan koodia ja sitäkautta lisää paikkoja mitä voisi optimoida. Yksi vaihtoehto:

MCP server for GPU profiling with NVIDIA Nsight Systems (nsys). Requires NVIDIA Nsight Systems installed and available in PATH. Python 3.10+ is also required.

https://lobehub.com/mcp/korovkoalexander-nsys_profiler_mcp

Amigakoodeissa oli tosi hyödyllistä teettää assemblerilla microbenchmarkkeja. AI paljon ennemmin uskoi/oppi miten optimoida benchmarkkien kuin esim. käskykannan manuskan+kellojaksojen pohjalta.

 

[Karhu III]

Ehkä agentin vois saada mcp-serverin avulla suht järkevällä vaivalla profiloimaan koodia ja sitäkautta lisää paikkoja mitä voisi optimoida. Yksi vaihtoehto:

https://lobehub.com/mcp/korovkoalexander-nsys_profiler_mcp

Amigakoodeissa oli tosi hyödyllistä teettää assemblerilla microbenchmarkkeja. AI paljon ennemmin uskoi/oppi miten optimoida benchmarkkien kuin esim. käskykannan manuskan+kellojaksojen pohjalta.

Koitin asentaa mutta tuli 404. Mutta mitäpä tuolla tekisi.

Size        Mode                nvJPEG    Portable    Ratio
1920x240    mono auto            0.244    0.149        0.61x
1280x720    mono auto            0.912    0.233        0.26x
1920x1080    mono auto            0.396    0.402        1.02x
1920x240    planar 4:4:4 auto    0.842    0.245        0.29x
1280x720    planar 4:4:4 auto    0.440    0.717        1.63x
1920x1080    planar 4:4:4 auto    1.004    0.971        0.97x

Jostain syystä 1280x720 värikuva on hidas. Ehkä joku potikka mennyt väärään asentoon. AI saa tutkia.

Pari juttua tulee mieleen. Ensinnäkin, valmiskoodin markkina-arvo on täysin romahtanut. Ja toisekseen, myös lähdekoodin arvo on romahtanut. Sillä on edelleen käyttöarvo, mutta aion kirjoituttaa toteutuksesta jonkinlaisen planin tai vastaavan, jonka perusteella AI voi myöhempinä vuosina rekonstruktoida koodin uudelleen.

 

[Karhu III]

No niin, 3D käyttö oli piikannut kesken benchmarkin mutta alkaa tämä olla selvä peli.

 

[finWeazel]

Koitin asentaa mutta tuli 404. Mutta mitäpä tuolla tekisi.

Löytää missä pullonkaula ja onko utilisaatio oikeasti lähellä 100%. GPU:t aika monimutkaisia härpättimiä jos haluaa maksimitehot ulos. AI jos saa loopattua konkreettinen mittaus mihin aika menee, katsoo koodit mukaanlukien assyn ja korjaa pullonkaulan arkkitehtuuri/koodioptimoinnilla niin toimii paremmin kuin jos on vähemmän tietoa käytössä.

Toki jpeg kuormana ei haastavammasta päästä, konesalitasolla allaolevassa lainauksessa. Aika paljon suorituskyky lisääntyy pelkillä softaoptimoinneilla vuodesta toiseen. Toisessa ääripäässä kiinalaiset optimoi deepseekkiä varten ptx-assyllle ison osan koodeistansa. Kuulemma piilaaksossa tekevät samaa vaikka eivät asiaa mainosta.

xAI’s GPU fleet is running at about 11% utilization, exposing how hard it is for AI labs to fully use expensive Nvidia hardware.

Certain companies go all-in on their software stack and are able to get utilization rates exceeding 40%, beyond the typical 35-45% rate. Meta and Google are such examples where the utilization rate is up to 43% and 46%, respectively.

xAI Is Reportedly Using Just 11% of Its 550,000 NVIDIA GPUs, While Meta and Google Squeeze Out 43-46% From Their Fleets

xAI is reportedly able to utilize just over 10% of its entire NVIDIA GPU fleet, as report suggests lackluster AI software stack optimizations.

wccftech.com

Pari juttua tulee mieleen. Ensinnäkin, valmiskoodin markkina-arvo on täysin romahtanut. Ja toisekseen, myös lähdekoodin arvo on romahtanut. Sillä on edelleen käyttöarvo, mutta aion kirjoituttaa toteutuksesta jonkinlaisen planin tai vastaavan, jonka perusteella AI voi myöhempinä vuosina rekonstruktoida koodin uudelleen.

Joutuu aika moni firma menemään samaan malliin kuin miten open sourcella tehdään rahaa. Siinä kohtaa kun AI korvaa devops/tuki/security/... porukan ja ylläpito liki ilmaista agenttuen avulla niin palvelumallillakin rahastaminen alkaa muuttumaan haastavaksi.

Oracle, Sap yms. varmaan ekana ongelmissa. Kukaan osta niiden kötöstyksiä kun halvemmalla voi tehdä paremman firmakohtaisen ja kustomoidun. Todnak. palasetkin open sourcessa kun miksipä niitä koodeja piilottelemaan enää nykymaailmassa: https://www.forbes.com/sites/donmuir/2026/02/04/300-billion-evaporated-the-saaspocalypse-has-begun/

 

[finWeazel]

Taidan olla ainoa. OpenAI 5.5xhigh codex app:ssa oli eilisen claude tyylisessä idioottimoodissa ja jatkuu tänään. Ei onnistu yksinkertaisetkaan asiat, väittää että hyvä on vaikka täysin selviä virheitä. Ei löydä virheitä yksikkötesteillä joiden pitäisi olla triviaaleja kirjoittaa. Vaikka promptaisi kuinka tarkasti tai pienissä palasissa niin silti tulee sekundaa ulos minkä korjauttamiseen menee enempi aikaa kuin käsin koodaamiseen.

Noh, kauanhan tätä iloa kestikin että codex oli hyvä. Pikkuhiljaa alkaa pää hajoamaan pilveen mikä voi toimia ihan miten vain. Ei voi lokaalit ottaa (toimivaa) pilveä kiinni tarpeeksi nopeasti, että saisi järjestelmän mikä toimii päivästä toiseen samalla tavalla.

Ehkä väliajan ratkaisu olisi vuokrata gpu:ta pilvestä ja ajaa siellä "itse" isompaa open source mallia. Maksaa kyllä, mutta olis ainakin sama palvelutaso päivästä toiseen.

--

Olisko openai:llakin loppunut konesalikapasiteetti. Codex app lataukset katosta läpi. 6 miljoonan pinnasta hetkessä 160 miljoonaan.

 

[heebo1974]

Taidan olla ainoa. OpenAI 5.5xhigh codex app:ssa oli eilisen claude tyylisessä idioottimoodissa ja jatkuu tänään. Ei onnistu yksinkertaisetkaan asiat, väittää että hyvä on vaikka täysin selviä virheitä.

Siis näinkö tekoäly toimii, kun datakeskusresurssit loppuvat ? Eli vastausten laatu romahtaa ? Luulin, että vain vastausaika hidastuisi.

 

[finWeazel]

Siis näinkö tekoäly toimii, kun datakeskusresurssit loppuvat ? Eli vastausten laatu romahtaa ? Luulin, että vain vastausaika hidastuisi.

Riippuu. Voivat hidastaa niin että asiakkaan x pyynnöt menevät harvemmin laskentaan. Voivat myös kerätä isompia könttiä ja ajaa könttiä kerralla jolloin vastaus tulee hitaammin mutta samassa konesaliajassa enemmän tokeneita. Ihan selkeästi on ruuhka-aikoja missä vastaukset tulevat todella hitaasti versus amerikanaikaa viikonloppuisin aamuyöstä tuntuu että vastaukset tulevat todella nopeasti. Amerikanaikaa perjantaina iltapäivästä matelee,...

Normikäyttäjälle ei ole luvattu mitään tiettyä konfiguraatiota mallista niin voivat taustalla vähentää ajattelun määrää, kvantisoida mallia pienemmäksi tai ajaa jopa ihan eri mallia. Asiakkaalle luvattu koodinimi mutta ei tarkkoja parametreja. Koodaus llm:t eivät aja vain dataa kerran läpi ja vastaus ulos vaan monia rinnakkaisia ajattelupolkuja joista valitaan paras. Ajattelua edellisen parhaan pohjalta iteroidaan uusiksi kunnes on hyvä vastaus olemassa. Ajattelunmäärää pudottamalla menee koneaikaa vähemmän mutta vastaus vähemmän pureskeltu tai claude coden tapauksessa usein nopalla heitetty. Nopalla heittäessä koko ajatteluprosessi jätetään välistä kun malli kuvittelee tietävänsä suoraan vastauksen.

Kai perusongelma on, että on kyky tuottaa laadun X tokeneita A kappaletta. Kun asiakasmäärä joka käyttää palvelua menee katosta läpi niin tokeneita laadulla X tarvittaisiin paljon enemmän kuin A. Tässä kohtaa helppo lipsahtaa siihen, että tuotetaan huonompilaatuisia halvempia tokeneita kun ei pokka kestänyt kertoa ettei voida ottaa uusia asiakkaita sisään tai nostaa tokenien hintaa kysynnän tasolle tai hidastaa palvelua niin paljon että käyttäjät menevät takajaloilleen kun vastauksessa menee tunteja minuuttien sijaan.

 

[Makis]

Onko noissa malleissa vaihtoehtoa, että dataa ei käytetä jatkokoulutukseen vai onko lokaalit mallit ainoa vaihtoehto?

E. Olihan tuolla asetuksissa ruksi, jolla ilmeisesti tuon voi kieltää.

 

[finWeazel]

Onko noissa malleissa vaihtoehtoa, että dataa ei käytetä jatkokoulutukseen vai onko lokaalit mallit ainoa vaihtoehto?

E. Olihan tuolla asetuksissa ruksi, jolla ilmeisesti tuon voi kieltää.

Pääperiaate on että jos maksat niin voi kieltää datan käytön koulutuksessa eikä sun koodit jää pilveen jemmaan. Ilmaisessa asiakas ja asiakkaan data on maksuväline. Random kiinaserverit ja pikkuputiikit voipi tehdä mitä huvittaa kun panokset erilaiset kuin google, microsoft jne.

Huvittaa "en halua mun dataa käytettävän jatko-opetuksessa" ajatus ylipäänsä kun viimeisestä mun itse tekemästä koodirivistä kuukausia aikaa. Ollaan jo siinä pisteessä, että tarvii olla melko spesifi juttu että koodisalaisuus on oikeasti salaisuus eikä joko triviaalisti tai vähän yrittämällä generoitavissa promptilla. Vois kuvitella, että kaikki huvikseen tai open sourceen tai microsoft/apple/google sdk:ta jne. tekevät haluaisivat koodejansa käytettävän opetuksessa, että mallit tekisivät entistä paremmin open sourcea/harrasteprojekteja/sdk:ta. Suljetun koodin päivät on luetut.

Datat toki salaisuuksia jo ihan gdpr:n pohjalta mutta eipä tällaisia datoja muutenkaan pitäisi devaajien koneilla olla. Testidata != asiakasdata.

 

[Makis]

Siihen voi olla monta syytä. Teet vaikka asiakkaalle, joka ei halua että koodit leviää mihinkään. Se on ihan sama onko se tarpeen vai ei, voit valita tehdä projektin ja tehdä kuten asiakas sanoo tai keksiä muuta hommaa. Ja kyllä noita erinäisiä algoritmeja on tullut tehtyä, joita voi pitää liikesalaisuutena. Jos meinaa käyttää näitä työkaluja mihinkään niin nuo algoritmithan lipsahtaa helposti koulutusdataan.

Se että tekee jotain diibadaabaa ja sitten huvittaa kun joku ei voi levittää koodeja julkisesti ei kyllä lakkaa hämmästyttämästä.

 

[finWeazel]

Siihen voi olla monta syytä. Teet vaikka asiakkaalle, joka ei halua että koodit leviää mihinkään. Se on ihan sama onko se tarpeen vai ei, voit valita tehdä projektin ja tehdä kuten asiakas sanoo tai keksiä muuta hommaa. Ja kyllä noita erinäisiä algoritmeja on tullut tehtyä, joita voi pitää liikesalaisuutena. Jos meinaa käyttää näitä työkaluja mihinkään niin nuo algoritmithan lipsahtaa helposti koulutusdataan.

Se että tekee jotain diibadaabaa ja sitten huvittaa kun joku ei voi levittää koodeja julkisesti ei kyllä lakkaa hämmästyttämästä.

Ymmärrän tuon toki, mutta mun pointti oli se, että hitainkin aika pian tajuaa että koodin hinta lähenee nollaa kun saa kyhättyä viikoissa projekteja joiden tekemiseen meni ennen kuukausia/vuosia. Väitän että tämä johtaa myös siihen, että open sourcesta tulee löytymään entistä parempia ratkaisuja esim. projektinhallinta, tukibotit, tuntikirjaus, toiminnanohjausjärjestelmät jne. Kyllähän noita maksavien asiakkaidenkin himmeleitä rakennetaan paljon open sourcen päälle tai vaikka kuinka iso osa android puhelimesta on open sourcea.

Algoritmi jos löytyy esim. tieteellisestä paperista niin ei koneella mene kauaa kirjoitella toteutusta. Viime vuonna jo tylytti llm:t suurimman osan ihmisisä matematiikassa ja algoritmityylisissä koodauskisoissa, suurin osa koodereista ei edes pääsis noihin kisoihin mukaan saati sitten pärjäisi niissä. Vähän rapsuttelee niin kaikki keksitty viimeistään 60-luvulla.

Suljettua koodia tulee olemaan aina, jos ei muualla niin jossain sotateollisuuden niche kontekstissa. Mainstream koodaus mitä suurin osa porukasta tekee,... toinen tarina

 

[Makis]

Sillä ei ole niin mitään väliä mihin ollaan menossa. Isot ei-softafirmat ei tule muuttumaan nopeasti. Meillä pitää vaihtaa edelleen 3kk välein salasana, vaikka siinä ei ole mitään järkeä, koska jotkut asiakkaat vaativat että noudatamme tiettyä standardia, jossa tuo on määritelty. Mikähän on helpointa, noudattaa tuota, saada asiakas vaihtamaan mieltään vai muuttaa standardia?

Tässä on ihan sama homma. Et ole tainnut teollisuusasiakkaiden kanssa ikinä työskennellä jos kuvittelet että joku iso teollisuusfirma muuttaa tällaisia periaatteita nopeasti. Hyvä jos viidessä vuodessa tapahtuu mitään muutosta. Miksi muuttaisivat? Ei siitä ole heille mitään hyötyä että koodit leviää kaikille.

"Kyllähän noita asiakkaidenkin himmeleitä rakennetaan open sourcen päälle" -> entä sitten? Ei se edelleen tarkoita että niitä muutoksia pitäisi kaikille jaella.

Mitä algoritmeihin tulee, niin esimerkiksi biosignaaleja uusille laitteille tulkitsevia algoritmeja tuskin noin vain tulee AI:sta jos ei ensin selitä aika tarkkaan miten se toimii - ja jälkimmäinen on se juttu, jota ei haluta levittää. Vai osaatko selittää tarkasti miten vaikka Ouran sormuksen algoritmit toimii? Saatko AI:n kirjoittamaan ne?

 

[edup]

Ajatuksessa että koodin leviämisellä ei olisi väliä, koska koodin arvo lähestyy nollaa, on perustavanlaatuinen ongelma.

Suurimmassa osassa tapauksista yhtälailla se mitä backendissa tehdään, kuin miten, on suojattavaa. Vuotanut koodi paljastaa molemmat. Siihen sitten päälle se, että nykymaailmassa siellä kontekstissa on usein kaikenlaista muutakin kuin vain se koodi tai sen speksit. Siellä voi olla kokonaisia Jira-boardeja, isojakin datasettejä, firman sisäistä viestinvaihtoa, tai ihan mitä tahansa muuta.

 

[finWeazel]

Sillä ei ole niin mitään väliä mihin ollaan menossa. Isot ei-softafirmat ei tule muuttumaan nopeasti.

Suomi only things,... Isossa maailmassa eri tavalla. Yksi syy siihen miksi piilaakso vei alustatalouden(meta, microsoft, facebook, uber, lyft, apple, google, openai, anthropic jne jne). Ei tarvi kovin iso ennustaja olla, että arvaa suomen laahaavan perässä. En siis suomea käyttäisi benchmarkkina sen suhteen miten nopeasti maailma liikkuu ja mihin maailma tulee menemään.

Piilaaksossa isoissa firmoissa AI avustimet ... kaikilla ... käytössä. All In. Nopeet syö hitaat. Myös pankeissa, esim. goldman sachs mistä on ollut juttua.

--

Oura on hyvä esimerkki kun oura nimenomaan on signaalinkäsittelyn osalta all in AI:ssa eikä ihmisen käsinkirjoittamaa heuristiikkaa. Ouran etu ja tämä suoraan ouran perustajien suusta on iso laadukas datamäärä jolla voidaan ruokkia AI:ta. Ouran MOAT on data eikä koodi. Ouran innovaatiot tulevat AI:n avulla seulomalla datasta signaalia. Oura on myös ollut agressiivinen patenttien kanssa, esim. samsungin sormusta ei saa amerikassa myydä kun oura puolusti patenttejaan.

 

[Makis]

No, jos soitan Ouralle niin antavatko ne AI-algoritmit, joilla seulovat sitä dataa? Yksi tuttu jonka kanssa välillä käydään lounaalla (kun satutaan samaan aikaan ruokalaan) on tuolla projektipäällikkönä joten ihan outo firma tuo ei ole.

Se mitä Piilaakson jätit tekevät on aivan yhdentekevää meidän kannalta. Koko bisnesmalli on alusta asti ollut erilainen. Tällä hetkellä teollisuusfirmoissa AI:n sallivuus riippuu aika pitkälle yksittäisistä henkilöistä. Keskijohto varsinkin on riskejä välttelevää tyyppiä. Kun et anna tehdä mitään uutta niin et tee sellaisia virheitä, joista tulee potkut. Ja en muuten puhu suomalaisista firmoista. Useimmat asiakkaat on ulkomailta.

Joku Google tai Amazon jos ilmoittaa ehtoja, niin siinä isotkin firmat joutuu joko suostumaan tai käyttämään jotain muuta. Noille firmoille ne omat säännöt on tärkeämmät kuin joku yksittäinen asiakas.

 

[finWeazel]

Se mitä Piilaakson jätit tekevät on aivan yhdentekevää meidän kannalta.

maailma on erilainen paikka kun miettii kokonaisuutta eikä omaa napaa. Jos luet ajatuksella mun postauksen niin puhun koodauksesta yleensä ja koodauksen tulevaisuudesta. Pienet nichet erikseen,...

Oura olisi ilman patentteja paahdettu leipä, patentit ja niiden puolustaminen pitävät samsungin ja kiinalaiset poissa amerikan sormusmarkkinoilta. Oura ei kaikilla markkinoilla puolusta patentteja. Oura ilman ai:ta ei olisi mahdollinen nykyisen tuotteen toimivuudella.