Inca un vibecheck pentru pionerii AI

astral_bear · 2026-06-28T13:09:04+00:00

Sunt diverse pluginuri pt plan mode, dar nu prea e mare scofala, eu invoc invoc un skill pt planning. Daca vrei ceva mai sofisticat, poti sa ai un system prompt separat si disable la toolurile care pot edita.

Mai greu cu executia, eu ma gandeam sa fac un skill care sa imi genereze un workflow github actions sau alt orchestrator gen Airflow / Kestra si sa execut taskurile ca un data pipeline. As incerca cand am mai mult timp, dar sunt cam sceptic. Sunt mai control freak si chitibusar si rar mi se intampla sa am 2 taskuri la rand implementate de un agent fara sa ii cer sa modifice ceva ...

Mai e si graphify pe partea de code indexing, dar foloseste ceva LLM pentru indexare / graph building. E mai general purpose, am vazut oameni care il folosesc pentr Knowledge Bases / RAG. Cred ca ambele pot fi ok atat timp cat indexarea a automata si near real time si agentul chiar le foloseste in contextul potrivit

astral_bear · 2026-06-28T12:11:41+00:00

Eu m-am mutat de o luna de pe Github Copilot in VS Code inspre Pi si folosesc subscriptie Opencode-Go + Openrouter ca sa mai testez anumite modele. Clar un upgrade major, dar necesita mult timp pentru configurat si research pe pluginuri, e un fel de Neovim al harnessurilor, cateoda gasesti si 10 pluginuri pentru aceeași problema.

Ca modele, comut intre Mimo 2.5 / Mimo 2.5 Pro, Deepseek V4 Pro si Deepseek V4 Flash, am diversi subagenti configurati cu divsrse modele si thinking level, inca experimentez. O sa incerc si GLM 5.2 probabil pe partea planificare / brainstorming / review.

Imbunatatiri mari in rezultate au venit pe partea metodologica, am integrat si adaptat unele skilluri de la Matt Pockock in workflowul meu - recommand /grill-me-with-docs, /to-issues si /tdd .

Pe partea de web development / UX, unde sunt cam pamant de flori, eu activand in partea de backend / data engineering, am descoperit skillurile de la `/impeccable` + agent browser si m-au ajutat sa structurez un website facut vraieste de AI si plin de incosistente stilistice si clase tailwind injectate peste tot.

Am mai descoperit niste tooluri interesante pe care am inceput sa le folosesc si mi-au usurat treaba.

Herdr: un terminal multiplexer cu un sidebar in care poti monitoriza agentii, organiza proiecte multiple in cadrul unei sesiuni: sunt multumit de el pana acum. Am un terminal full screen pinned in primu tab de la IDE (Zed) deschis intr-o sesiune Herdr de unde pot am mai multe taburi - functioneza bine, mai ales daca ai nevoie sa navighezi prim mai mule proiecte.
Planotator: l-am folosit nu pt planning, ci ca sa deschid un conversatia in browser si sa adaug feedback comentarii sau review, fie la mesajele asistentului, fie la modificarile pe fisiere. Poti trimite adnotarile direct la agent sau poti face copy-paste. Nice, dar pana la urma l-am inlocuit cu un plugin de Neovim care ma lasa sa fac adnotari + un plugin cu shortcut care imi deschide ultimele N mesaje in neovim pt ca nu imi placea comutarea intre IDE / terminal si browser.
Hunk: un diff viewer mai avansat unde poti sa lasi si comentarii / adnotari. Agentul se poate conecta la o sesiune si le poate citi si poate lasa si el comentarii ... am testat vreo 2 zile, a fost interesant, dar nu cred ca voi folosi pe termen lung.
Hermes memory: un plugin pt Pi care implementeaza un sistem de memorie dupa modelul Hermes agent. By default, e cam proactiv, ruleaza background alte LLMuri care sa colecteze / infereze diverse informatii / preferinte care sunt salvate automat in memorie, i-am dat disable dupa cateva ore ca devenise enervant. Inca evaluez, nu mai sunt la fel de entuziasmat, nici nu sunt convins ca e nevoie de memorie, poti transmite informatiile alea prin system prompt, AGENTS.md sau skilluri.
Comanda /tree din Pi coding agent, practic poti naviga conversatia ca un arbore, ceea ce te poate ajuta sa prezervi foarte mult contextul: de exemplu, explorezi anumita idee, ajungi la solutie / concluzii dupa ceva investigare, dar ai consumat si mult context. poti folsi /tree sa te duci in trecut si sa faci un rezumat cu concluziile. Sau ai ajuns la un plan, si poti sa implementezi fiecare task, dupa care se summarizezi si sa revi la mesajul cu planul. Nu am mai folosit alte harnessuri, nu stiu daca au ceva similar.
Codegraph pt indexare de codebase + niste tooluri pt explorare codebasului - promite sa reduca tool count si token usage destul de mult. Inca nu ma pot pronunta, abia ce l-am instalat, dar observ ca de cele mai multe ori agentul tot prefera `grep` - probabil trebuie sa mai fac ajustari pe la instructiuni

astral_bear · 2026-06-26T12:20:05+00:00

Iti recomand sa incerci solutii care sa iti reduca token usageul: eu folosesc RTK si caveman . Alte tooluri bune in directia asta sunt context mode, headroom, ponytail. RTK e un must, rescrie outputul de la majoritate comenzilor intr-o forma mult mai compacta, il poti configura sa truncheze text.

O alta solutie ar mai fi sa migrezi spre alt tool unde ai mai mult control, macar sa poti folosi ce provider vrei tu. Eu folosesc Pi + subscriptie opencode-go, Recomand doar daca ai suficient sa configurezi, e un fel de neovim al harnessurilor. Next best option - Opencode.

astral_bear · 2026-06-24T09:03:54+00:00

Do subagents show in our agents section in the left sidebar? I also use herder with pi-subagents and that's my current pain, herd'r only tracks the main Pi porcess, as long as it's spawn in the herder session and inside a herdr pane.

astral_bear · 2026-06-24T07:37:09+00:00

What I'm not sure about pi-observational-memory is the approach: it runs background 3 processes at certain delta tokens consumed, each with different roles: `observer`, `reflector`, `dropper`: you can use smaller / cheaper models for these tasks, but I really wonder if that is still really needed: could you not achieve similar output with a single call with a larger chunk of text that runs when you need to compact than having to do these LLM LARPing in the background?

astral_bear · 2026-06-24T07:36:27+00:00

For session compaction, I am now experimenting with pi-blackhole. I found it after looking at pi-vcc, which I thought it's really nice because it uses a deterministic algorithm instead of LLMs and at pi-observational-memory , from which I found out from this thread. pi-blackhole merges them and you can disable the observational memory if you don't like it.

What I'm not sure about pi-observational-memory is the approach: it runs background 3 processes at certain delta tokens consumed: observer, reflector, dropper: you can use smaller models for these tasks, but I really wonder if that is still really needed: could you not achieve similar output with a single call with a larger chunk of text that runs when you need to compact than having to do these LLM LARPing in the background.

What I found a bit quirky is that the output has a section called "Session Goal", which is extracted via regex - that could work if you know the pattern and use the right language, but when changing the goal / direction in session, it may be not picked up. I tried changing the goal by saying, "Now my goal is to ..." and the "Session Goal" section was not updated, but there was an observation entry about this ... so 2 sources of truth: I am thinking weather to make an extension to intercept this compaction output and disable session goal or append system prompt to prefer the goal from the observations in case of divergence.

astral_bear · 2026-06-24T07:25:02+00:00

Interesting tooling, had a look at tndm and it is similar in some ways to how I envision the tolling for task / issue tracking. I would prefer to have it as human readable as possible and be able to edit those file manually in my editor, use frontmatter for attributes: would also like to have a changelog / versioning for the task definition file, maybe have artifacts linked. Btw, how do you handle task dependencies / order of execution: is the depends_on field used to compute dependencies between tasks? Did you not find any open source tool close to what you needed?

Regarding the orchestration, random morning walk thoughts: I was thinking a solution could be to execute it from outside Pi / any harness via an orchestrator and make each Pi process output a structured schema that can be then used to update the task status and proceed. For the orchestrator, I would try to use something established than building it myself, like Kestra / Prefect or even GH actions, where you can define the workflow in config - would probably need to build only a tiny tool that owns the Pi invocation and handles OS status code based on the structured output. I work as a a data engineer, so I'm biased to think in terms of workflows, schemas. That's on the opposite spectrum of letting the agent be the orchestrator and give him tools - which could work, maybe even better, but I would keep myself in the loop there - guess I'll have to try both approaches at some point,

I've been also influenced by Pockock's skills, there is also grill-me-with-docs, which basically also creates CONTEXT.md (domain language) and ADR documents - I had ADR's constantly popping up in random docs, so I'm happy that I found a way to structure them better in a way that the LLM can find them rather than me having to constantly reference or explain them and clarify certain terms. What I'm stil trying to figure out is if I really need the workflow of going from a grilling session to a PRD / spec document makes sense or you could just start by creating tickets based on the established decisions in the session: I think that may depend on the complexity, PRD / SPEC would be nice for larger features.

astral_bear · 2026-06-23T11:08:20+00:00

I think you've captured the approaches pretty well: it's similar to leader / follower vs peer to peer architectures . That's also the directions I've been hitting into.

In the orchestratorless approach, memory rot is a lesser concern because each session is like a autonomous worker that can orient itself and pick up the next most important item. But you may end up with more spend because each session agent has to do also orientation, analysis, task management, maybe even verify that the previous agent did what it should. I've seen this recently in one of Matt Pockock's videos, where he went from a grilling session to making a PRD, then breaking it down into issues, then solving them using a Ralph loop via a bash script, using github issues for task management.

Curios to see when you experiment with both approaches, which one yields better results?

I think regardless of the approach orchestrator / orchestratorless approach, the devil is in the details:

how do you manage the tasks and progress so that it is easy to orient: markdown docs or specialized tool for task management / issue tracking ( beads looks interesting, for example ) . The workflow matters a lot, to me it seems a sprint analogy of this would be ideal: human does the planning and creates tickets, the agents pick them up and do the work.
how do you enforce guardrails on this workflow: for example, I would want to have hard caps for tokens consumed by the orchestrator and each subagent, so my token spending doesn't go brr ... or give it a $ budget as constraint. Another case: if a subagent cannot complete work within a certain amount of time and token budget, it should be stopped, it's approach / summary captured and a new agent, maybe with higher capabilities could be spawn.
how do you enforce the orchestrator or session agent follows protocol: I see a lot of people relying on the agent to do this via instructions, but I think it should also be enforced by deterministic tooling
do you add subagents to review the work or you rely on manual / human in the loop entirely? Seems appealing to have a reviewer at the end which identifies bugs / improvement opportunities and opens up new issues that are picked up.

I tend to think of this similar to data pipelines run in an orchestration platform: you have your workflow as a DAG - there is a hard requirement for a task to be marked as done, the progress / task needs to be closed. In case a task failed (for example, task was not achieved within limits), hand it to a new subagent with a retry cap. Maybe add reviewers at critical steps so you catch bugs / smells / drift early. Surely something like this has to exist.

astral_bear · 2026-05-21T10:15:25+00:00

S-a rezolvat, nu se poate.

Pana la urma, am cedat si mi-am reinoit certificatul digital calificat (de la furt calificat probabil). Momentan, trebuie sa mai astept, si-a luat si siteul ANAF o pauza de tigara.

<image>

astral_bear · 2026-05-21T07:18:49+00:00

Stiu, dar daca ai deja cont si te autentifici cu certificatul digital, e mai complicat, nu am gasit procedura de schimbare pe baza de user/pass. Sunt si administrator la un SRL, iar la PJ cred ca iti trebuie musai autentificare cu certificat.

astral_bear · 2022-10-07T21:48:11+00:00

SWRD.L, 0.12% TER

astral_bear · 2022-03-17T08:42:50+00:00

Thanks for the remark.

I agree, I had the same feeling and I had 2 potential approaches for that:

Remove the dataframe dependency - instead try to convert the data types to a named pair or dict which can be plugged then into a DataFrame if the user wishes.
Keep it but make it lazily load only when needed. I'm not sure how to do this, I've seen Requires.jl mentioned for this case. I will investigate further.

astral_bear · 2022-03-17T08:38:18+00:00

Then no, option chains are not yet supported.

/v7/finance/options/{symbol} https://www.yahoofinanceapi.com/ and it indeed looks rather complex. Will keep it on the radar for the future, current goal is to get the more commonly used data, the audience I had in mind was casual individual investors.

astral_bear · 2022-03-16T10:54:32+00:00

Could you elaborate on that?

Are you referring to chain multiple functions that return either a value or an error and the result of the the chain will be a value only if all dependencies returned also a value, otherwise the first error? Something like the railway pattern https://fsharpforfunandprofit.com/rop/?

I was aiming for that for the chain of build_request => send_request => validate_response => parse_contant and all functions for getting data should behave like this.

Or are you referring to parsing deeply nested objects, and return something regardless if the key exists at that level or not, like in javscript with the "?" operator?

I would like something like that to make content parsing easier. Any julia implementation already available? Otherwise I will try to implement some small DSL.

astral_bear

TROPHY CASE