maurelius2

I feel that these potential Yolo side effects can be managed with more control if supervised with a modified prompt.

When the user's proposed solution is bad, replace it with a better one

When the user's proposed solution can be improved upon or modified due to some critical missing information, suggest a revised plan and prompt the user for how to proceed.

How does it compare to tenacity?

I'm somewhat at a loss here other than understanding the fundamentals. Can someone tell me how the compression impact performance?

I can certainly see the appeal of distributing the context with vc. However, I have always imagined this to be integrated into an existing kanban workflow, similar to a Jira or gh issue board. Perhaps agent specific, perhaps not.

Furthermore, an existing kanban (ticket) workflow will expect you to refine the context into something more ... concentrated, or at least something that we are used to seeing as developers working with tickets, at least more so than the chat history that seem to be favored.

Have you put any thought into how this would integrate into such a process?

I'm trying to make Instagram be what my parents said Facebook was. Christ, I'm old.

(I missed adding my question and now I don'tknow how to edit my previous reply)

What I'm curious about and something I'm struggling with myself: are you feeling that the productive uplift of offloading work to an LLM limits the gain of managing a second brain like this?

Thanks for sharing! Easy to follow instructions.

I can see the PARA structure and perhaps a bit of Zettelkasten in the peripheral (but that might be my own bias).

I'm using a similar system (here's a link) https://blog.hampusadamsson.com/blog/How%20I%20Manage%20Note...

And also a custom plugin to do parts of the LLM (here's another shameless link) lifting: https://github.com/hampusadamsson/modai

A tiny broker to experience trading with fake money