ok, tai vadinasi kiekvieną kartą gausi skirtingą kodą, jau pajudėjom kažkur
Žinutės
Filtrastaikomas
Šis puslapis nėra tiesioginis — žinutės atnaujinamos pagal tvarkaraštį. Paskutinį kartą atnaujinta . Kito atnaujinimo laukiama apie . Laikas rodomas Vilniaus laiku (EET).
su LLM niekad negausi 2 kart tokio pacio rezultato nuo 0
jei antrą kartą oneshotinsi, sukurs identiškai tokį pat kodą? Diff bus tuščias?
turiu memory 🙂 geriau uz dokumentacija
jeigu tu noresi pridet, nepaeis 😉
del to kad labai specifins stack
ir nemazai korekciju yra L0 memory layer kaip ji naudot
jei antrą kartą oneshotinsi, sukurs identiškai tokį pat kodą? Diff bus tuščias?
taip spec.txt
projekto aprasymas, todel oneshot'ino
ar šitam dashboardui, kurio linką davei turi tokią dokumentaciją, kad be source kodo sukurs identišką sistemą, jei paprašysiu tavo ai pridėti papildomą filtrą?
dokuemtnacija yra 2 tipu
context ir tiesiog projekto dokai
tai projekto dokai yra project shape
o context memory yra task shape
man kainuoja 500 output token kad atsimint kaip ir kodel taskas implementintas ~30k context
o ne 100 tool call pereit per 5000 MD failu
mano argumentas - tam, kad gauti identišką softą kiekvieną kartą kuriant su ai, turi turėti dokumentaciją, kuri bus platesnė, nei source kodas, kas yra nepraktiška
ti vat as irgi nesuprantu kaip galima vaibint neturint agent self improvement mechanizmo
😄
aš nesuprantu koncepto, kaip galima daryti softą neturint source kodo, o jį iš naujo generuojant iš atminties pagal specfikaciją
kaip sakiau, atsimins kaip dare, kaip klydo kur baige, pasiziures pora failu i kuriuos memory pointina ir papildys
čia ne agentas, čia dashboardas
as pateikiau pvz kaip atrodo Agentas be memory
bet matau nelabai supratai esmes 😄
ne to klausiu
tai jeigu tu be memory pasiimsi koda, tai nepadarys isvis su situ stack kuris cia naudojamas
nes datastar ismasto lievai 😉
jei šitoje lentoje noriu naują filtrą pridėti, kursi viską nuo nulio?
3h 200$ jeigu api tokenai
cqrs realtime, + golang
cia 10 klases mokiniai renkas 11 ir 12 klases valandas, validacijos ir t.t.
one shot su 3 feedback, ka patobulint ~3h
gal kokiam kalkuliatoriui ir sueitų, bet kažin ar kažkas sudėtingesnio paeitų
tai visokius
http://140.150.154.133:9999/ [el. paštas paslėptas] slaptas123
Prisijungimas · Ugdymo planai
Perskaityta
gali pamaigyt
kokio tipo apsus kursi šitaip?
todel ir kainuoja N+K tokenu isreversint
tai koks praktinis pritaikymas viso šito?
taip butent taip ir gyvena zmones be agent memory 😉
be source kodo bus naujas source kodas, bus naujas produktas, kuris skirsis nuo pradinio
[DEBT] 7 deferred · 0 open follow-ups · 0 broken pointers · 0 unreceipted · 0 into an archive · 0 waiting
atsimins ka dare, ir prates 😄
kas bus, kai reikės kokio pakeitimo?
patirtis
klaidos
yra memory verbaliniai konspekt
kaip nedaryti
jie universalus praktiskai visiems projektams
ir nepriklausomi nuo modelio 🙂
> ⏺ T1 done, gates green. T2 — the identity schema.
⏺ Red recorded. Writing the migration.
dar ir mutant testai yra ;]
⏺ The first mutant survived — and it found a real gap. Narrowing the index to (user_id) alone passed my test, because I checked "a
different user in the same tenant" when the case that discriminates is "the same user in a different tenant" — one person
belonging to two companies, which is the whole point of the table. Fixing the test.
⏺ Wave 1 complete (T1, T2). Continuing to T3 — the session store.
⏺ Now T3's tests, then the store.
⏺ T3's fence has the same too-narrow filter bug as T2, and my test pulled Role in from T4. Fixing both — the task boundary should
stay honest.
⏺ Now fixing T3's fence (same too-narrow filter), then implementing the store.
⏺ Red recorded. Writing the migration.
dar ir mutant testai yra ;]
⏺ The first mutant survived — and it found a real gap. Narrowing the index to (user_id) alone passed my test, because I checked "a
different user in the same tenant" when the case that discriminates is "the same user in a different tenant" — one person
belonging to two companies, which is the whole point of the table. Fixing the test.
⏺ Wave 1 complete (T1, T2). Continuing to T3 — the session store.
⏺ Now T3's tests, then the store.
⏺ T3's fence has the same too-narrow filter bug as T2, and my test pulled Role in from T4. Fixing both — the task boundary should
stay honest.
⏺ Now fixing T3's fence (same too-narrow filter), then implementing the store.
Rodoma paskutinė surinkta leidžiama būsena; pašalinimų suderinimas nebaigtas. Visas pokalbis — Telegram grupėje.