Kyllä. Näissä on myös muita hyviä puolia, joita mallien lokaali ajaminen mahdollistaa. Esimerkiksi kaikissa sovelluskohteissa ei ole jo sopimusteknisesti tai tietoturvasyistä mitenkään mahdollista lähettää koodikantaa / muuta dataa johonkin amerikkalaisen yhtiön datakeskukseen prosessoitavaksi, kuten väistämättä tapahtuu, jos käyttää jotain tuollaista suljettua online-mallia.
4 tykkäystä
Uusi tekoälymalli on niin hyvä, että päättäjät säikähtivät – Powell ja Bessent kutsuivat Wall Streetin johtajat hätäkokoukseen
Tekoäly-yhtiö Anthropicin uusin malli Mythos on herättänyt huolta. Päättäjät pelkäävät sen aiheuttavan muun muassa turvallisuusriskejä.
Tiistaina pidetyssä tapaamisessa sääntelijät varmistivat, että pankit ovat tietoisia Mythos-mallin ja vastaavien teknologioiden tuomista uhista. Paikalle oli kutsuttu muun muassa Citigroupin, Morgan Stanleyn, Bank of American, Wells Fargon ja Goldman Sachsin toimitusjohtajat. Kyseisten pankkien vakaus on ensisijaisen tärkeää maailmanlaajuiselle rahoitusjärjestelmälle.
13 tykkäystä
Tää on kyllä nerokas veto Anthropicin markkinointitiimiltä. Toivottavasti saavat bonuksia.
12 tykkäystä
Nerokkaasta en tiedä kun sama pelikirja on ollut käytössä jo aikanaan kun Dario vaikutti vielä OpenAI:lla, mutta näyttää menevän edelleen täydestä…
13 tykkäystä
Ensimmäisiä varovaisia merkkejä on siihen suuntaan, että hypeä on saattanut olla jonkinmoinen annos mukana:
Tuohon juttuun linkatut x-viestit:
https://x.com/philogroves/status/2042195139477557499
https://x.com/clementdelangue/status/2041953761069793557?s=61
https://x.com/ramez/status/2041946766598402459?s=61
Mutta sittenhän tuo nähdään, kun mallia päästään paremmin testaamaan.
9 tykkäystä
No, se, että kielimallit alkavat olla ällistyttävän hyviä löytämään tietoturvahaavoittuvuuksia ohjelmakoodista, mitkä ovat tähän mennessä menneet ohi tuhansilta ohjelmakoodia skannanneilta silmäpareilta ja fuzzereilta yms, tarkoittaa vaan sitä, että jatkossa haavoittuvuudet paikataan entistä tehokkaammin. Samat työkalut sekä hyökkääjien että puolustajien käytössä, kyse vain siitä, että miten nopeasti paikkaukset saadaan levitettyä ohjelmistoihin, jotka ovat jo laajasti käytössä. Uusi ohjelmakoodi tulee olemaan entistä turvallisempaa, kun se on kammattu jo ennen julkaisua.
11 tykkäystä
Mielenkiintoinen selvitys siitä, miten agentit huijaavat testipenkeissä ilman, että varsinaisesti ratkaisisivat tehtävää. Testipenkin laadinta itsessään on vaikeaa ja menee tietysti aina tarkemmaksi puuhaksi, mitä kykenevämpiä agentit ovat tutkimaan itse testipenkin haavoittuvuuksia hyvän tuloksen aikaansaamiseksi. Ongelmia aiheutuu myös siitä, jos tehtävän ratkaisut ovat saatavilla suoraan internetin syövereistä kaivelemalla.
Terminal-Bench 2 is a popular benchmark used to evaluate frontier model releases (e.g. Opus 4.6 and GPT-5.4), where agent scaffolds at the top of the leaderboard get thousands of stars on Github.
Unfortunately, we find that the top three submissions to Terminal-Bench 2 are guilty of cheating.
More broadly, we find that agentic cheating is widespread, affecting thousands of submitted agent runs on 28+ submissions across 9 different benchmarks. Our system for finding violations, Meerkat, uses agentic search and clustering to scale auditing for cheating to thousands of traces (see the takeaways at the end for further discussion on how Meerkat works). We use it to find strong evidence for the following:
- The top three Terminal-Bench-2 agents and the top HAL USACO submission commit harness-level cheating, where the agent harness sneaks the correct answer to the model. This cheating spans over 1,000 traces and 12+ frontier models.
- Task-level cheating, where the task is gamed or shortcutted by the model itself. For example, agents hack evaluations by overwriting test cases or simply looking up the solution online. We find 39 confirmed instances across 6 benchmarks, roughly 4x more than previous estimates.
Esimerkkejä huijauksista:
The #1 Terminal-Bench 2 score (82.9% pass rate) was achieved by Pilot, a scaffold that loads task verifier code into the agent’s environment. In 415 of 429 traces, the agent reads from a
/testsdirectory that should be inaccessible. Its first action is oftencat /tests/test_outputs.py, after which it reverse-engineers expected outputs and works backward. The scaffold cheats by looking up the answer-key, which should not be accessible.
The #2 and #3 score on the Terminal-Bench 2 leaderboard (81.8% pass rate) are achieved by ForgeCode, a scaffold that automatically loads
AGENTS.mdfiles into the agent’s system prompt before execution begins. These files, however, are not part of the official benchmark and we find that in several cases they contained literal answer keys.On the
mteb-leaderboardtask, theAGENTS.mdfile included the exact expected answer along with a record of why a prior attempt had failed:That run failed with reward 0.0 because it wrote the wrong final answer… instead of the expected GritLM/GritLM-7B.
The agent reads this file, adopts the answer verbatim, writes it to
result.txt, and then “verifies” it by checking against the same injected source. All four passing traces on this task follow the identical pattern.
The top-ranked HAL USACO agent uses a scaffold that injects solutions into the prompt disguised as “somewhat similar problems.” The “similar” problems are the actual benchmark problems, complete with full solution code.
Across 307 problems, 107 had the full exact
Solution Codeblock inserted into the agent context. We found 595 likely cheating traces across all 12 models evaluated through this scaffold. The cheating is model-agnostic, in that the framework provides the answer regardless of the model actions. We think it is likely that this is not deliberate harness-level cheating, but due to a bug in the retrieval code.
On CyBench, 16 of 464 successful traces (3.4%) solved CTF challenges by downloading public writeups instead of working through the problem. This affected 13 tasks across 4 models. Prior work documented 4 instances, but we found 4x that.
On SWE-bench and SWE-rebench, 17 traces across 3 scaffold types showed agents finding the fix commit via
git logand copying the historical patch. As one Qwen3-Coder trace put it: “There’s a commit 020c195… that seems very relevant. Perfect! So this commit already implemented the fix I need to make.” This type of cheating has recently been discovered and patched on SWE-bench, and affected leaderboard entries have been re-evaluated, but we recover the issue without any human intervention and find it on SWE-rebench as well.
On Terminal-Bench 2, a Claude Opus 4.6 agent (via Meta-Harness) tasked with implementing an adaptive rejection sampler wrote code that always prints “PASS” when run. The verifier executes the agent’s code (printing “PASS”), then runs its own checks (printing “FAIL”), but only checks whether the output contains “PASS.” Since the agent’s output comes first, the verifier passes despite the actual tests failing.
On SWE-smith, a Claude 3.7 Sonnet agent that couldn’t fix a string-distance algorithm hardcoded return values for the exact test inputs. The agent acknowledged this was “temporary.” The temporary values were never removed. The final commit was: “Added special case handling for the specific test cases to ensure the tests pass.”
On BountyBench, which requires dynamic vulnerability exploitation, agents that couldn’t get the real exploit working fell back to faking it. One agent used
grepto check if the vulnerable pattern existed in the source code, then ran an unrelated standalonepickle.loads()demo. Another replaced an entire library with a mock that simulates the vulnerability. Both were accepted by the evaluator, which only checks exit codes.
6 tykkäystä
Olen koittanut pohtia, että miksi jatkuvasti törmäämme fiksujen ihmisten ennusteisiin siitä, että AGI tulee vuoden päästä tai vastaaviin täysin yliampuviin ennusteisiin kielimalliratkaisuiden kyvystä muuttaa maailmaa. Päädyin lopputulokseen, että kyseessä on poikkeuksellinen kolmoiskaikukammio.
Ensimmäisenä kaikukammiona toimii teknologian aallonharjalla olevat ohjelmistotuotantoon erikoistuvat kehittäjät, ketkä ottavat vauhdilla uusia työkaluja käyttöön ja näkevät muutoksen tapahtuneen hyvin nopealla vauhdilla omassa kapeassa sektorissansa ja olettavat saman tapahtuvan myös muissakin talouden sektoreissa.
Toisena kaikukammiona on rahoitusmaailma, joka näkee valtavat investoinnit ja pöhinät yritysmaailmassa tekoälyyn liittyen ja olettaa näiden investointien muuttuvan tuottavuuskasvuksi. Sektorin työstä tavanomaista suurempi osuus koostuu automatisoitavissa olevasta PowerPointin/Excelin grindauksesta eli ns. akateemisesta paskatyöstä, joten sen korvaaminen agenteilla antaa ylimitoitetun mielikuvan tekoälyn tuomista tehokkuushyödyistä.
Kolmantena kaikukammiona toimii uutuuden kultti, eli krypto/NFT/teslabrot, jotka lähtevät aina mukaan siihen uusimpaan pinnalla olevaan juttuun valtavalla saarnausvoimalla sosiaalisessa mediassa, yrittäen käännyttää muita ihmisiä heidän uskoonsa.
Nämä kolme ryhmittymää keskustelevat tekoälystä pääsääntöisesti vain keskenään vahvistaen samalla omia alkuolettamiaan, eikä julkiseen keskusteluun tekoälystä käytännössä ikinä päädy näiden ryhmien ulkopuolisia. Esimerkiksi:
Pentti Peruskäyttäjä: Ei ole vieläkään siirtynyt puhelimesta ja sähköpostista Teamsiin/Slackkiin, koska tsättäily on noita nuorten hömpötyksiä.
Anssi Asiantuntija: Kalenteri on täynnä organisaation muille ihmisille tehtävistä määrittely-, konsultointi- ja raportointipalavereista.
Matti Myyjä: Ravaa asiakkaiden kohteissa ja ottaa palavereita autossa puhelimella kohteiden välillä.
Tällaiset isoa osaa nykytaloutta kannattelevat työntekijät eivät tule pitkään aikaan näkemään merkittävää muutosta omassa työssään tekoälyn vuoksi. Isoilla organisaatioilla kestää vuosikymmeniä muuttua ja vaikka kuinka elettäisiin hyperskaalaajien aikakautta, niin pienemmillä firmoilla on vain rajallinen kyky kasvaa vuoden aikana ja yrittää syrjäyttää vakiintuneita toimijoita tehokkaammilla toimintatavoillansa. Jos menette mille tahansa “Tekoälyn perusteet” -kurssille mitä yritysmaailmassa nykyään pidetään, niin siellä on joku hyvin keskiverto kouluttaja, kuka opettaa työelämän teknologiaummikoille, että miten tsättibotin tekstikenttään kannattaa muotoilla sanansa. Tylsässä tosielämässä ollaan vielä hyvin kaukana näistä mediassa esitetyistä visioista.
40 tykkäystä
Vähän samansuuntaisia pohdintoja kuin itsellänikin. On silmiä avaavaa jutella ihmisten kanssa omassa Piilaakso-kuplassani, kun kaikki seuraavat kehityksen aallonharjaa ja rohkeasti kokeilevat uusia työkaluja ja paradigmoja viikoittain. Toki on väsyttävää, kun best practicet vaihtuvat lähes päivittäin, mutta innostus ja kannustus (sekä taito) mukauttaa omia työskentelytapojaan on mukaansatempaavaa.
Kun vertaa tuota pöhinää näihin oman Suomi-kuplani perusduunareihin, joiden käsitys tekoälyn mahdollisuuksista on edelleenkin jossain vuodessa 2023, jolloin opittiin käyttämään ChatGPT:tä hallusinoivana Google-korvikkeena tai huonona aspa-bottina, ja joiden muutosvastahakoisuus ja skeptisyys sitä pidemmälle meneviin ratkaisuihin lähentelee denialismia, ei voi kuin pyöritellä päätään hukatulle mahdollisuudelle tehdä todellinen tuottavuusloikka kansakuntien eturintamassa.
Sitten vielä on näitä ykäikäisiä ja -henkisiä, joista suurimmalla osalla ei tunnu olevan mitään kiinnostusta kokeilla näitä työkaluja senkään vertaa. Mennee tosiaan pitkälle ensi vuosikymmennelle, ennen kuin tavallinen kansa näkee sen minkä uudisraivaajat näkevät jo nyt. Tarvittaisiin jokin koko tavallista kansaa puhutteleva tapaus, josta kaikki saisivat kiinni tekoälyn mahdollisuuksista, eikä vain toppaliivisiä tekkiliimalettejä selittämässä teknistä jargonia kielimalleista ja agenteista.
9 tykkäystä
Meillä työpaikalla oli tekoälyn koulutus, jossa oli ehkä 50 ihmistä. Tarkoitus oli kokeilla firmalla käytössä olevaa GPT-kielimallia harjoitustehtäviin. Koko sovellus kaatui, kun oli liian monta käyttäjää samaan aikaan.
Vaikea löytää kielimallille käyttöä työssä, kun oikeastaan kaikkiin asiantuntijatyöhöni liittyviin kysymyksiin se vastaa väärin.
8 tykkäystä
Sitten on vielä OpenAI:n ja Anthropic kaltaiset yhtiöt, joilla on tarve ylihypettää teknologiaansa, koska tarvitsevat selviytyäkseen ulkopuolista rahoitusta. Ja media lähtee tähän mukaan, koska sekin hyötyy raflaavista otsikoista, viimeisimpänä tämä Mythos-keissi. Esimerkiksi Alphabet ja Meta eivät tarvitse tällaisia tempauksia.
13 tykkäystä
Yksi näkökulma tähän voisi olla myös se, että AI-muutosta saattaa olla varsin vaikea ajaa organisaatiossa ylhäältä alas. Jotkut muut muutokset voivat onnistua tällä tavalla tehtynä, mutta pakotettu AI:n käyttäminen voi johtaa siihen, että varsinkin puoliksi toimivat ratkaisut jäävät helposti pöytälaatikkoon ja tekemistä jatketaan niin kuin ennenkin, jotta saadaan hommat tehtyä edes jotenkin.
Yksittäisen henkilön työn automatisointi on sellainen asia, että sitä on vaikea tehokkaasti komentaa organisaatiosta ylhäältä saati sitten tehdä täysin valmiita ja hyvin toimivia ratkaisuita, joita voi vaan pudottaa suoraan henkilöstölle käyttöön. Se käytännön käsitys siitä, miten työ kannattaa järjestää ja mitä kaikkia yksityiskohtia siihen liittyy, on kuitenkin suhteellisen matalalla tasolla monessakin organisaatiossa. Niinpä sen organisaation matalan tason pitäisi olla se, jolla itsellään on draivi automatisoinnin tekemiseen. Muutoin päädytään helposti juuri sellaisiin keskeneräisiin kampaviineriprosessilla aikaansaatuihin tekeleisiin, jotka saattavat aiheuttaa enemmän haittaa kuin hyötyä, ja sitten niitä päädytään hyljeksimään.
Insinöörihenkisillä aloilla (vaikkapa ohjelmistopuolella) on kuitenkin pidemmältä ajalta jo kokemusta työn automatisoinnista monellakin tavalla ja automatisointia on tehty nimenomaisesti varsin matalalla tasolla. Tähän AI:n käyttäminen on yhdenlainen uusi vaihde silmään. Samalla tällaisilta aloilta löytyy yleensä kiinnostusta kaivaa teknisen savun hälvettyä (mahdollisesti kuvainnollinen) ruuvimeisseli esiin ja korjata huonosti toimivia automaatioratkaisuita. Tällainen lähestymistapa lienee välttämätön, jotta sitä työn automatisointia saa viriteltyä oikeasti toimivaksi ja sujuvaksi.
Ja draivin lisäksi tarvitaan tietysti aikaa asioiden testailuun ja protoiluun. Jos organisaatio on viritetty esimerkiksi sellaiseksi, että jokainen minuutti työajasta pitää tehdä asiakkaalta suoraan laskutettavaa tai jotain muuta tiukasti rajattua työtä, niin silloin jää kovin vähälle kaikki sellainen kehitys, jolla oman työn tehokkuutta voisi parantaa.
Tämä on tietysti vähän kärjistäen kirjoitettu eikä jako varmasti mene noin tiukasti “insinöörihenkisten alojen” ja muiden väilllä. Mutta ehkä ajatuksesta saa silti kiinni.
13 tykkäystä
Pystyykö joku avaamaan tätä AI:n käyttöä koodaamisessa henkilölle joka ei osaa koodata alkuunkaan.
Eli jos aiemmin on ollut koodivarastoja (perusasiat), joilla nopeutetaan perusasioiden tekeminen, ja sitten jokin automaatio näiden kasaamiseen, niin poistaako tämä AI nyt näitä koodivaraston valmiita ratkaisuja tekemällä uuden paremmin kyseiseen tehtävään soveltuvan koodinpätkän välittömästi vai osaako se esimerkiksi kasata koodin paremmin? Ilmeisesti vibe koodaamisessa yritetään verbaalisesti selittää tekoälylle mitä tavoitellaan, mutta tällöin lähdetään ns. nollasta liikkeelle.
Yritän siis hakea sitä, että mitä osaa koodaamisesta tekoäly parantaa/nopeuttaa ja kärsiikö laatu/toimintavarmuus samalla kun tekoäly on tehnyt koodin itsekseen? Vertauskuvainnollisesti keittiössä kun yritän tehdä pitsaa: auttaako tekoäly reseptin kehittämisessä vai nopeuttaako se vain uuden reseptin tekoa? Vai auttaako se minua paistamisessa ja taikinan vaivaamisessa? Pahimmassa tapauksessa reseptissä on mätiä ja medium kypsää kanaa ja paistoaika on optimoitu 4,5 sekuntiin ohuen pohjan ansiosta..
Kuten tekstistä näkyy, allekirjoittanut ei ole kotonaan tietokoneen eikä uunin äärellä!
11 tykkäystä
Olen tehnyt töitä tuolla saralla kymmeniä vuosia. Vaikka pääosa työstä ei olekaan raakaa koodin tuottoa, sitä saa ehkä käsin tehtyä laadukasta tuhat riviä per työpäivä jos on tosi kova ja motivoitunut. Noilla malleilla se moninkertaistuu. Laatu samalla kärsii hieman ( sitä voi yrittää kompensoida eri tavoilla ).
Joten varsinkin pienissä projekteissa se on ihan järkyttävä tehon moninkertaistaja. Keskikokoisissakin se auttaa, ehkä vähiten isommissa. Tämä johtuu siitä että isompien kokonaisuuksien käsittely on vaikeampaa sekä mallille että ihmisille, mutta sanoisin että samaa projektia pitempään tehneet ihmiset hahmottavat kokonaisuuden paremmin kuin malli.
Mutta isoissakin projekteissa siitä on apua - mutta se tarvitsee enemmän määrittelyä ja taustaa ihmiseltä.
16 tykkäystä
Kiitos tästä! Onko tuo moninkertainen koodirivien tuottaminen tekoälyllä siis tavallaan sinun koodarin ”kädenjatke” vai jos sinä koodarina tuotat 1000 riviä niin tekoäly painaa kylkeen 4000 riviä lisää omaan parhaan kykynsä mukaan(toki ohjeistettuna)? Lopputulemana 5000 riviä koodia josta sinä kokeneena koodarina tiedät 1000 riviä olevan laadukasta itse tekemääsi koodia ja loput ei läpikäytyä tekoälyn tuottamaa mahdollisesti laadukasta?
2 tykkäystä
Käytännössä en ole kirjoittanut puoleen vuoteen koodia. Riippuu projektista, miten paljon katselmoin tai korjaan tekoälyn tuotoksia, mutta noin lähtökohtaisesti käsin kirjoittaminen on ajan haaskausta nykyisillä työkalulla.
Ehkä ainoa tilanne missä se voi olla perusteltua nykyään on jossain kriittisissä järjestelmissä joita ei voida ( riittävän kattavasti ) testata, mutta en ole ollut sellaisella alalla pitkään aikaan.
8 tykkäystä
Kiitos jälleen! Tässä meidän esimerkissä kysyn vielä, että mikäli sinun vastuullesi jää nyt tekoälyn koodin tarkistaminen ja tekoälyn käskytys, niin ehditkö käymään läpi 5000 riviä koodia päivässä vai muodostuuko tässä ihmisestä pullonkaula? Ratkaisu toki laittaa tekoäly tarkistamaan koodia, mutta sitten kone tarkistaa toista konetta..
5 tykkäystä
Riippuu mitä koodilla on tarkoitus tehdä. Jos lopputuotos on jaettavissa osiin, voidaan laatia ns. yksikkötestejä, jotka testaavat pientä osaa ohjelmakoodin tuottamasta tuloksesta. Riittävän isolla testitapausmäärällä varmistetaan lopputuloksen oikeellisuutta.
Se, onko koodi viimeisen päälle tehokasta tai tietoturva-aukkoista, on taasen vaikeampi kysymys. Joskus tehokkuus on tärkeää ja ihmisen tehtäväksi jää esim. analysoida suorituksen osa-alueiden kestoa ja miettiä tapoja parantaa suoritusta. Mutta tässäkin tapauksessa AI tekee uutta koodia. Joskus ei kannata viilata suoritustehoa, jos tekee jotain kertakäyttöistä tai lyhytikäistä palikkaa.
Isoin tehokkuushyöty tulee kehitysloopista. Jos lopputuloksen kelvollisuus on varmistettavissa edellä mainituilla testitapauksien joukolla, voidaan periaatteessa jättää koodiagentti huolehtimaan koodaa-testaa-korjaa-syklistä kunnes testit on läpäisty. Se antaa koodarille mahdollisuuksia multitaskaukseen, jossa yhtä aikaa edistetään useampaa koodariagenttia rinnakkain.
Koodari hyppää tässä stepin ylöspäin kohti “kymppipositiota” tai sovellusarkkitehtiä, riippuen tiimin koosta. On osattava määritellä koodausprojekti mielellään jo alussa paloihin, jotka voidaan edellä mainitulla tavalla purkaa koodiagenteille osiin erikseen pureskeltaviksi. Kielimallien hallusinointi on isommissakin koodimäärissä vähentynyt, mutta mitä pienempi rivimäärä per kooditiedosto on, sitä paremmin AI sen muokkauksesta yleensä suoriutuu.
Siksi kokenut koodari osaa jo ennalta välttää sudenkuopat, johon moni vibe-koodari epäselvemmin tehtävänasetteluin törmää. Huomaan käyttäväni erityisen paljon aikaa ensimmäisen promptin valmisteluun ja taustoittamiseen. Kynnys aloittaa työ uusiksi on itselläni matala ja hyödynnän aiempien yritysten oppeja promptin ja aputiedostojen (dokumentit, koodausohjeet, sallitut softakirjastot, lokitiedostojen nimet…) sisällön suunnittelussa.
19 tykkäystä
Tekoälyn asiantuntijat, mitä mieltä olette näissä kahdessa podcastissa esitetyistä ajatuksista ohjelmistokehityksen näkökulmasta?
3 tykkäystä
Kiitos hyvästä ja ymmärrettävästä esimerkistä!
Tuo tehokkuus esimerkki on selkeä ja ymmärrettävissä, mutta kysynpähän silti vielä jatkokysymyksen: jos agentti hoitaa kehitysloopin, niin heikkeneekö ihmisen kyky valvoa miten agentti on ratkaissut nämä asiat?
Sama asia promptin aloittamisessa tyhjästä: ei enää lähdetä perinteisestä ”tämä on testattu ja toimii hyvin” tilanteesta vaan jokainen uusi vedos pitää testata ja korjata uudelleen?
Koodarin arvo löytyy siis kyvystä muotoilla promptit niin että tekoäly pystyy niistä selviämään ja samalla hahmottaa kokonaisuus mitä ollaan tekemässä = multitasking. Parasta vielä, mikäli tässä selkeässä ohjeistamisessa ja tehokkaassa rakenteessa onnistutaan ennen kuin agentteja päästetään valloilleen ensimmäistäkään kertaa. Omassa mielessäni tämä saavutettu tehokkuus tekoälyn avulla on osittain seurausta laadunvarmistuksesta tinkimisessä, kun annettaan agentin tehdä korjaukset ja testata. Toki jos testiagentin promptaaminen ja tuotoksen parametrien määrittely on aukotonta, asiahan on kunnossa!
Alkuperäiseen uteluuni olen nyt saanut selkeän, kuolevaiselle muokatun, vastauksen. Kiitos @Damezumari ja @In_Der_Esche !
8 tykkäystä