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
Žinutės
Šis puslapis nėra tiesioginis — žinutės atnaujinamos pagal tvarkaraštį. Paskutinį kartą atnaujinta . Kito atnaujinimo laukiama apie . Laikas rodomas Vilniaus laiku (EET).
ti vat as irgi nesuprantu kaip galima vaibint neturint agent self improvement mechanizmo
😄
čia ne agentas, čia dashboardas
as pateikiau pvz kaip atrodo Agentas be memory
bet matau nelabai supratai esmes 😄
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
taip butent taip ir gyvena zmones be agent memory 😉
[DEBT] 7 deferred · 0 open follow-ups · 0 broken pointers · 0 unreceipted · 0 into an archive · 0 waiting
atsimins ka dare, ir prates 😄
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.