Ennen kuin poltat paljon tokeneita ison agentin parven myötä uudessa projektissa, vanha puusepän sanonta "Mittaa kahdesti, leikkaa kerran!" kannattaa tarkistaa muotoon "Tarkista helmesi N kertaa, toteuta kerran", jossa N on käytännössä niin monta kuin pystyt syömään. Olen huomannut, että parannuksia tulee yhä enemmän, vaikka ne olisivat hienovaraisia, mitä useammin ajat tätä peräkkäin Opus 4.5:n kanssa (huomaa, että seuraava kehotus on käytettävä vain SEN jälkeen, kun olet jo muuttanut alkuperäisen alennussuunnitelmasi helmiksi toisen kehotteen avulla, jonka annoin äskettäin hyvin pitkässä kirjoituksessani työnkulkuistani): "Lue uudelleen AGENTS dot md, jotta se on vielä tuoreena mielessäsi. Tarkista jokainen helmi todella huolellisesti – oletko varma, että se on järkevää? Onko se optimaalista? Voisimmeko muuttaa jotain, jotta järjestelmä toimisi paremmin käyttäjille? Jos on, tarkista helmet. On paljon helpompaa ja nopeampaa toimia "suunnittelutilassa" ennen kuin alamme toteuttaa näitä asioita! ÄLÄ YKSINKERTAISTA ASIOITA LIIKAA! ÄLÄ MENETÄ MITÄÄN OMINAISUUKSIA TAI TOIMINNALLISUUTTA! Varmista myös, että näihin helmiin sisällytämme kattavat yksikkötestit ja e2e-testiskriptit sekä yksityiskohtaiset lokituskirjaukset, jotta voimme olla varmoja, että kaikki toimii täydellisesti käyttöönoton jälkeen. Muista käyttää VAIN 'bd'-työkalua helmien luomiseen ja muokkaamiseen sekä helmien riippuvuuksien lisäämiseen. Käytä ultrathinkia." Aiemmin ajoin sitä vain kerran tai kaksi ennen toteutuksen aloittamista, mutta kokeilin äskettäin 6+ kertaa, ja se teki jatkuvasti hyödyllisiä parannuksia. Jos helmien asteittaiset parannukset alkavat tasaantua, voit kokeilla aloittaa kokonaan uuden CC-istunnon aloittaen: "Lue ensin KAIKKI AGENTS dot md -tiedostot ja README dot md -tiedostot todella tarkasti ja ymmärrä KAIKKI molemmat! Käytä sitten kooditutkimusagenttitilaa ymmärtääksesi täysin koodin, teknisen arkkitehtuurin ja projektin tarkoituksen. Käytä ultrathinkia." Ja sitten jatkan samalla kehotuksella kuin yllä, mutta alussa: "Muutimme äskettäin alennussuunnitelmatiedoston kasaksi uusiksi helmiä. Haluan, että tarkastelet ja analysoit nämä hyvin huolellisesti käyttäen 'bd' ja 'bv'." Mitä monimutkaisempi ja monimutkaisempi alennussuunnitelmasi on, sitä relevantimpi tämä tekniikka on. Jos sinulla on pieni, triviaali suunnitelma ja hyvin yksinkertainen projekti, tämä on selvästi liioittelua. Mutta siinä tapauksessa et todennäköisesti näe vähän asteittaisia parannuksia tai muutoksia jokaisella kierroksella, joten on melko ilmeistä, milloin on aika lopettaa. Muista: suunnittelutokenit ovat paljon harvempia ja halvempia kuin toteutustokenit. Jopa hyvin suuri, monimutkainen markdown-suunnitelma on lyhyempi kuin muutama merkittävä kooditiedosto, saati sitten kokonainen projekti. Mallit ovat paljon fiksumpia perustellessaan suunnitelmaa, joka on hyvin yksityiskohtainen ja monimutkainen, mutta silti tarpeeksi pieni mahtuakseen helposti kontekstiin (tämä on oikeastaan keskeinen oivallus pakkomielteisestä suunnittelusta ja miksi käytin 80 %+ ajastani siihen). Ja jos luotat GPT Prohun ja Extended Reasoningin kanssa web-sovelluksessa alkusuunnittelussa, kuten suosittelen vahvasti (eli luodaksesi ja parantaaksesi alennusta, jonka lopulta muutat helmiksi), saat ne käytännössä niin paljon kuin voit Pro-suunnitelmalla, joten hyödynnä se täysimääräisesti! Mikään muu malli ei voi koskea Pro:hun verkossa, kun se käsittelee syötettä, joka sopii helposti konteksti-ikkunaan. Se on todella ainutlaatuista. ...