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ä.

 

[edup]

ö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ä.

Mä ymmärsin että sulla on tiedossa olevia kikkakolmosia, joita sovelletaan demoskenessä, ja joista oletettavasti on siis ihan valmiita esimerkkejä näyttää Claudelle. Jos sä lisäät moiset esimerkit sinne skilleihin, tai pyydät Claudea itse tekemään sen, olettaisin tuon auttavan noissa merkittävästi.

 

[finWeazel]

Mä ymmärsin että sulla on tiedossa olevia kikkakolmosia, joita sovelletaan demoskenessä, ja joista oletettavasti on siis ihan valmiita esimerkkejä näyttää Claudelle. Jos sä lisäät moiset esimerkit sinne skilleihin, tai pyydät Claudea itse tekemään sen, olettaisin tuon auttavan noissa merkittävästi.

Ei assembler-käskyjen lisääminen skillseihin ole järkevää. Parempi tapa tehdä kuten minä tein, benchmarkit, benchmark-tuloksista koostaa prosessorispesifisiä .md tiedostoja. Promptissa missä optimoi prosessorille X assykoodia niin käskee noudattaa prosessorin X ohjetiedostoa. Samoilla vaivoilla teetätin myös c-referenssikoodit mitä verrattiin assya vastaan. gcc osaa toisinaan tehdä niin hyvää ettei kannata assyksi lähteä tekemään tai riittää joku pieni inline assy sen sijaan että tekis kaiken assylla.

Ohjetiedostot hyvin koostettuja niin niissä on jaoteltu asiat loogisesti. Samalla tapaa olen muutenkin tehnyt amiga-ohjelmointiin agentille ohjeita, hw-rekisterit, blitter, copper jne. Erillisiä pienempiä hyvin tehtyjä tiedostoja jotta kontekstin koko pysyisi järkevänä. Agentit tuntuvat toimivan paremmin jos saa fokusoitua sen sijaan että heittää kaiken aina sisään.

---

Nyt näyttää reddit täyttyneen claude code has become stupid postauksista. Eilen oli ketjuja harvakseltaan, nyt claude code reddit täynnä allaolevaa

 

[BongisKhan]

Tänään olen laittanut Clauden töissä tositoimiin. Opus 4.6 Max thinking päällä.

Välillä menee ihan hienosti, välillä taas jää pitkäksi aikaa luuppaamaan jotain "Actually, I need to ... No that's not right... But ..."

Ehkä kaikista eniten huvittaa tuo uusi taipumus laiskotteluun. Claude vähän väliä on silleen "Huh huh, johan tässä on paiskittu! Pitäskö lopetella tältä erää?". Toinen lemppari on tää "Vaihtoehto A on ihan täysi kriittinen kokonaisuuden kannalta ja blokkaa edistymistä tusinassa eri jutussa, mutta sen selvittely vaatii aika paljon työtä ja nysväystä. Eikö siis mentäisi mieluummin paljon helpompaan vaihtoehto B:hen ja murehdita tuota nysväystä myöhemmin?"

Voi Claude. Nyt olisi hyvä aika pikkuhiljaa saada ns. paskasi yhteen, tai mun tulee olemaan erittäin vaikea suositella sinua ylemmilleni tämän pilotin päätteeksi.

 

[finWeazel]

Tänään olen laittanut Clauden töissä tositoimiin. Opus 4.6 Max thinking päällä.

Välillä menee ihan hienosti, välillä taas jää pitkäksi aikaa luuppaamaan jotain "Actually, I need to ... No that's not right... But ..."

Ehkä kaikista eniten huvittaa tuo uusi taipumus laiskotteluun. Claude vähän väliä on silleen "Huh huh, johan tässä on paiskittu! Pitäskö lopetella tältä erää?". Toinen lemppari on tää "Vaihtoehto A on ihan täysi kriittinen kokonaisuuden kannalta ja blokkaa edistymistä tusinassa eri jutussa, mutta sen selvittely vaatii aika paljon työtä ja nysväystä. Eikö siis mentäisi mieluummin paljon helpompaan vaihtoehto B:hen ja murehdita tuota nysväystä myöhemmin?"

Voi Claude. Nyt olisi hyvä aika pikkuhiljaa saada ns. paskasi yhteen, tai mun tulee olemaan erittäin vaikea suositella sinua ylemmilleni tämän pilotin päätteeksi.

Eilen yritin koodauttaa sarjaporttiliikennettä amigan ja pc:n välillä claude code, max effort. Alkoi väittämään että amigan serial.device on epävakaa. Teki 'koodit suoraa rautaa vasten, edelleen epävakaa. Alkoi löytymään vikaa clauden tekemästä python appsista joka ei lähettänyt paketteja oikein ja johti korruptioon isojen tiedostojen kanssa. Kyseenalaistin, että olikohan tässä nyt järkeä tehdä rautaa paukuttava koodi kun vika oli sun python koodissa eikä amigan serialdevice-kirjastossa. Claude sanoi vapaasti suomennettuna "näinhän se näyttää olevan, mutta minkäs teet ja tässä ollaan". Ärsyttää tuo miten claude code:sta on tullut nenäkäs epäpätevyyden lisäksi. Huomannut myös laiskottelua ja huonojen vaihtoehtojen ehdotelua siitä huolimatta, että claude.md:ssa seisoo että aina valitaan hyvälaatuinen vakaa ratkaisu, teknista velkaa ei hyväksytä jne.

Oli viimonen niitti kun ei triviaali sarjaporttikoodikaan onnistunut. Jos joku muu valmistaja on lähellekään samoilla tonteilla anthropicin kanssa niin en anthropicin palveluita enää ostaa. Jos kertoisivat että on vikaa ja korjataan tai palvelua huononnettu koska konesalikapasiteetti ei riitä maksa tuplat niin toimii paremmin niin olisin paremmilla mielin. Eniten ärsyttää että paskotaan palvelu ja teeskennellään ettei mitään ole tapahtunut.

Huomannut myös tuon, että yksi sessio voi olla edelleen tosi fiksu ja toinen tyhmä kuin saapas. Ei .plan ominaisuudella tyhmyyden kiertäminen toiminut. Nyt pitää mikromanageroida claudea tyhmissä sessioissa niin paljon, että nopeammin ja helpommin tekee koodit käsin kuin agentin avulla. Eilen painoin uninstallia vaikka on 2vk vielä 200$/kk tilausta jäljellä. Ei tuota paskakasaa enää viitsi yrittää käyttää, ajan voi käyttää paremminkin.