Puhutaanpa sitten Claude Coden viimeaikaisesta älykkyyden vähentämisongelmasta, palautteeni on, että sinulla on oltava keinot varmistaa ohjelmistokehityksen laatu, vaikka CC ei toimisikaan Kuinka tehdä se? Älkäämme puhuko siitä, miten se tehdään, puhutaanpa yleisestä vibe-viasta, joka on sokean laatikon avaamisen ongelma, joka kerta kun kyseessä on musta laatikko, haamu osui seinään saadakseen selville, että jotain on vialla, ja tunnelma on heti onneton Siitä puheen ollen, ratkaisu on periaatteessa selvä Mustan laatikon prosessin muuttaminen läpinäkyväksi prosessiksi sen sijaan, että koodaat välittömästi, käytä enemmän aikaa suunnitelmiin ja ratkaisuihin 1. Ratkaisu Jos maku ei ole oikea, peruskoodauksen laatu ei ole paljon parempi 2. Ratkaisuvaiheessa on monia keinoja, monimalliarviointi on terävä työkalu, älä usko CC-perheen sanoja, usko vertaisarviointiin 3 Kun koodi on kirjoitettu, lisätään toinen arvostelu kääntämisen ja toimintotyytyväisyyden perusteella Näitä menetelmiä voidaan laajentaa, mitä CC pelkää, minulla on myös loimia ja clineä. Toinen metafyysisempi kysymys on, milloin älykkyyttä on helppo vähentää, intuitio voi olla silloin, kun laskentateho on riittämätön, ja minusta tuntuu, että +8-vyöhykkeen työajalla voi olla suurempi todennäköisyys, joten vaihda aikavyöhykettä testattavaksi

Sanoakseni yhden havaintoni O3:sta, itse asiassa O3 ei ole hyvä johtamaan työtä, kuten antamaan sen tehdä aloitteen ratkaisujen suunnittelussa, eikä se tee tällaista työtä hyvin Joten missä se on hyvä? Se on hyvä ruiskuttamaan, kyllä, se ruiskuttaa Annat hänen aloittaa työn, laatu on keskinkertainen, mutta se on jumalakriitikko, ja kommentit ovat erittäin hyviä Jos mahdollista, mielestäni paras prosessi on opusoida ratkaisu, o3 tarkistaa, ja antaa sen tarkistaa koodin kirjoittamisen jälkeen Sanotko, että o3 kuuluu silmille ja matalalle kädelle? Siinä ei ole mitään väärää, mutta on oikein, että sinulla on korkeat silmät ja matalat kädet, haluamme sen silmät, jotka ovat hyviä löytämään sen, emmekä odota sen tekevän sitä