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

[El Toro]

Tämmöinen tuli vastaan:

Tämän sisällön näkemiseksi tarvitsemme suostumuksesi kolmannen osapuolen evästeiden hyväksymiseen.
Lisätietoja löydät evästesivultamme.

Hyväksy kolmannen osapuolen evästeet

Linkki: https://x.com/i/status/2037254607001559305

Tämän sisällön näkemiseksi tarvitsemme suostumuksesi kolmannen osapuolen evästeiden hyväksymiseen.
Lisätietoja löydät evästesivultamme.

Hyväksy kolmannen osapuolen evästeet

Linkki: https://x.com/i/status/2037254609455243503

 

[kvjanhun]

Nonni, sepäs on juuri, mitä itse koin tällä viikolla. Viikkolimitti riitti isohkoon refaktorointiin, mutta pari kertaa jyrähti 5 h seinä vastaan aika yllättäen. Kiva kiva. Noh, noilla kellonajoilla jää vielä ihan siedettävät ikkunat Suomessa käskyttää Claudea, mutta kyllähän tuo nyt vähän siltä haiskahtaa, että vähemmän saa samalla rahalla.

 

[Karhu III]

Claudella taitaa mennä hyvin. Liiankin hyvin. Tokenit kallistuvat.

Tarkoittaa että muiden on parannettava palvelua ja laskettava hintoja jos haluavat pysyä mukana.

 

[finWeazel]

Claudella taitaa mennä hyvin. Liiankin hyvin. Tokenit kallistuvat.

Tarkoittaa että muiden on parannettava palvelua ja laskettava hintoja jos haluavat pysyä mukana.

Ollaan varmaan lähes siinä kohtaa missä tulee extra kalliita palveluita. Anthropicin uudesta parhaasta mallista "prohibitive expensive to run at scale". Lienee iso malli ja vaatii enemmän laskentatehoa ja järeimmät raudat(ei mahdu vanhojen kiihdyttimien muistiin) Varmaan mennään siihen, että ne firmat jotka haluavat parasta maksavat paljon,... Kuluttajille jotka haluaa 20e/kk, 200e/kk tilauksen jääpi olemattoman pienet token-rajat tai pienempi malli käsiin.

Nvidialla oli vastaavaa raudasta, että vera rubin + lpu:lla saadaan latenssi painettua alas, mutta hinta per token pompsahtaa kun tarvitaan enemmän rautaa. Osa firmoista maksanee siitä, että vastaukset tulevat merkittävästi nopeammin versus toisilla ei ole niin kiire. Onhan siinä puolensa, jos maksat 500ke/vuosi devaajasta niin annat hänelle AI-avustimen joka iteroi 5-10x kertaa nopeammin vaikka tokenit maksavat ... paljon. Suomessa vastaava devaaja maksaa 50ke/vuosi ja tokenomics on aika erilainen kun tokenien hinta suhteessa palkkaan ihan eri tasolla kuin new york, piilaakso yms.

--

Clauden idioottimoodia voi näemmä väistellä sillä, että pakottaa pyynnöt aina .plan:in läpi. Ihan jokainen juttu "suunnittele ensin" vaikka oltaisiin jo suorittamassa aikaisemmin tehtyä suunnitelmaa.

edit. No ei toiminut väistely kovin hyvin. Redditissäkin alkaneet heräileen

I am 100% sure that Opus got extremely lobotomized, or is just not working correctly at the moment. I loaded a backup of my coding project, copy-pasted the exact same prompts that I used a week before, and the results are nowhere near last week's. It's seriously as if I were using some old 2022 version of ChatGPT, simple 1-sentence prompts give absolutely horrid results. For example: I gave it new x and y variables for a GUI element and told it to hardcode them in. I've been doing it like that for weeks and always used Sonnet for it. Now I need Opus, and even then, it doesn't do it. Sometimes it changes completely different variables in an unrelated script, sometimes it uses the wrong numbers, and other times it does nothing and says it's done...

How is this sh*t even legal??? I'm paying 110€ a month for an AI that at this point is on the level of a support chatbot... ANTHROPIC FIX YOUR PRODUCT!!!

I don't understand people saying Claude Code is working fine. Either they're doing Flappy Bird-level projects, or they're straight up anthropic paid actors. Because on anything real, the quality has dropped dramatically — it's not just "dumb", it's barely usable at this point.

Reddit - Netin sydän

www.reddit.com

 

[Karhu III]

Ollaan varmaan lähes siinä kohtaa missä tulee extra kalliita palveluita. Anthropicin uudesta parhaasta mallista "prohibitive expensive to run at scale". Lienee iso malli ja vaatii enemmän laskentatehoa ja järeimmät raudat(ei mahdu vanhojen kiihdyttimien muistiin) Varmaan mennään siihen, että ne firmat jotka haluavat parasta maksavat paljon,... Kuluttajille jotka haluaa 20e/kk, 200e/kk tilauksen jääpi olemattoman pienet token-rajat tai pienempi malli käsiin.

Nvidialla oli vastaavaa raudasta, että vera rubin + lpu:lla saadaan latenssi painettua alas, mutta hinta per token pompsahtaa kun tarvitaan enemmän rautaa. Osa firmoista maksanee siitä, että vastaukset tulevat merkittävästi nopeammin versus toisilla ei ole niin kiire. Onhan siinä puolensa, jos maksat 500ke/vuosi devaajasta niin annat hänelle AI-avustimen joka iteroi 5-10x kertaa nopeammin vaikka tokenit maksavat ... paljon. Suomessa vastaava devaaja maksaa 50ke/vuosi ja tokenomics on aika erilainen kun tokenien hinta suhteessa palkkaan ihan eri tasolla kuin new york, piilaakso yms.

Devaaminen on halpaa, mutta alihankinta kallista. Joten luultavasti alihankintaketju muuttuu AI-vetoiseksi mikä tuntuisi ihan järkevältä.

 

[user_timo]

@finWeazel Noin kokeilumielessä, miten Kimi 2.5 pärjäisi Amiga ASM:ssa sinun projektissa?
Halvat tokenit ainakin ollut Opencode zen kautta js hommissa, niin voisikohan tuo väittämäänsä lunastaa m68k hommiin.

 

[finWeazel]

@finWeazel Noin kokeilumielessä, miten Kimi 2.5 pärjäisi Amiga ASM:ssa sinun projektissa?
Halvat tokenit ainakin ollut Opencode zen kautta js hommissa, niin voisikohan tuo väittämäänsä lunastaa m68k hommiin.

En tiedä kimi:stä. Mua ei niin halvat tokenit kiinnosta kun oma aika ja maksimaalinen toimivuus tärkeämpää kuin eurot. Nyt kun tuo claude code hajos pähkinöiksi niin koodihommat tauolle ja katsotaan ens talvena uusiksi missä mallit ovat. Kesti leikkauspaikka tai ei niin kalastuskausi alkaa, toivottavasti kestää.

ChatGpt5.4 thinking kyykkäs teoreettiseen viisasteluun "käytä vähemmän rekistereitä" tyylisiä heittoja mutta kun yrittää pakottaa että miten toteuttaisit vähemmillä rekistereillä niin syvä hiljaisuus. Claude code max effort moodissa kyykkäsi isojen palasten kanssa ja piti käsin ohjata. Paras tapa oli käskeä tehdä benchmarkkeja ja niiden pohjalta optimoida. Claude code tuntuu tykkäävän jos on dataa/patterni minkä pohjalta tehdä.

Algoritmillinen kompleksisuus räjähtää aika hyvin assykoodissa kun miettii kokonaisuutta missä voi olla data eri koossa/tarkkuuksilla ja erilaisia tapoja organisoida asioita niin että vaikka muistiaccessit minimoituvat tai sitten jossain tapauksissa ei olekkaan juuri merkitystä muistiaccessilla versus tapa B kun data cachessa jne.

Toinen mikä noissa assyissa on, että ei ne koneet oikeen keksi niitä oikeita kikkoja mitä demoscenessä käytetään. Paras oli tuoda esimerkeillä kikat niin sitten kone osasi käyttää niitä mutta ei itsekseen keksinyt.

Devaaminen on halpaa, mutta alihankinta kallista. Joten luultavasti alihankintaketju muuttuu AI-vetoiseksi mikä tuntuisi ihan järkevältä.

Onhan tuossa sekin, että jos ihminen maksaa 50ke/vuosi ja siihen päälle 10ke/vuosi tokeneita niin se on palkasta 20%. Versus jos se tyyppi maksoi 500ke/vuosi ja 10ke/vuosi tokeneita niin kustannus oli vain 2% palkasta. Toisessa tilanteessa on paljon helpompi laittaa vajaa tonni tokeneihin kuukaudessa per devaaja ja toisessa puhutaan melko isostakin kustannuslisästä. Numerot nyt vähän sinnepäin kun palkathan nyt voi olla ihan mitä vaan, mutta ei piilaaksosta kummoista devaajaa saa alle 500ke/total comp:lla kun lasketaan että on samassa työssä yli 4v ja saa koko RSU potin kerättyä.

 

[user_timo]

Heitin tuolle vanhan scoopex.s asm school pätkän, jonka olin kirjoitellut mutta en muista toimiko koskaan.

Spoileri: bug review

Analyzing this Amiga 68k assembly rasterbar demo. Here's my bug review:
Critical Issues
1. Header Garbage (Offset $00-$27)
The file starts with 40 bytes of non-code data (f9fa f9fa + zeros) before the actual source. This may confuse assemblers unless properly stripped.
Minor Issues
2. Library Management
- Opens graphics.library, gets copper pointer, then immediately closes it
- Not a bug, but unusual - you're not using any graphics functions, just needed the copper pointer
3. Copper Wait Position Updates
move.b d7,waitras1      ; Updates VPOS at waitras1
move d7,d0
add #5,d0
move.b d0,waitras2      ; Updates VPOS at waitras2 (5 lines below)
- Works correctly: Only modifies the high byte (VPOS) of copper wait instructions
- Wait positions: $8007→$xx07 and $8107→$yy07 (HPOS stays at 3)
What's Actually Correct
✅ Proper frame sync using $dff005 (VHPOSR) 
✅ Saves/restores original copper pointer (d4) 
✅ Saves/restores INTENA properly 
✅ Copper list properly terminated with $ffff,$fffe 
✅ Mouse button exit check ($bfe001 bit 6) 
Potential Improvements
- Hardcoded values: Y-positions ($40, $f0) and bar height (5) are magic numbers
- No DMA/BLITTER wait: Could cause issues if DMA is active
- Screen stays black: Sets all colors but doesn't enable bitplanes
Verdict: The code is functionally correct for a simple rasterbar demo. The main concern is the 40-byte header at the start of the file.

 

[edup]

Toinen mikä noissa assyissa on, että ei ne koneet oikeen keksi niitä oikeita kikkoja mitä demoscenessä käytetään. Paras oli tuoda esimerkeillä kikat niin sitten kone osasi käyttää niitä mutta ei itsekseen keksinyt.

Lisää ne skilleinä sille. Tai jos et jaksa, pyydä Claudea itseään kirjoittamaan moinen skilli. Ei ainakaan tarvii sitten jatkossa painia niiden kanssa.

 

[finWeazel]

Lisää ne skilleinä sille. Tai jos et jaksa, pyydä Claudea itseään kirjoittamaan moinen skilli. Ei ainakaan tarvii sitten jatkossa painia niiden kanssa.

öh, en ymmärrä. Mulla on skilleinä kaikki sellainen missä on järkeä olla skilleinä. Kompleksisuus assyssä tulee ihan vaan siitä että on todella paljon tapoja tehdä asia, ei voi brute forcettaa kaikkea läpi. AI luovuttaa esim. rekisterioptimointien kanssa ja käyttää herkästi pinoa. Toinen on epäoptimaaliset muunlaiset rakenteet kun saman laskennan voi tehdä monella tavalla käyttäen eri käskyjä, taulukoita jne. Paras ratkaisu noihin oli benchmarkit ja sanoa että muista benchmark tulokset ja käytä niiden pohjalta optimaalista rakennetta. Pinonkäytöstä ei päässyt eroon muuten kuin pakottamalla, optimoimaan pieniä palasia kerrallaan kun kokonaisuus ei onnistunut. Amigapuolella sekin että 68000, 68020 ja 68060 prossut noin pääpiirteissään tykkää monessa asiassa ihan erilaisesta koodista ja 00,020,030 prossuilla itseään muutteleva koodikin on vaihtoehto. Lisää kompleksisuutta kun tarvii tehdä monta erilaista assyversiota koodista.

7bitplane copper chunky-ruutukikan keskittäminen sellainen, että siinä on seuraavalle frontier mallille hyvä paikka paukutella henkseleitä jos onnistuu.

Yksi kikka esim. addx käskyn käyttäminen interpolointiin joka on joissain tilanteissa aika näppärä.