> Anyways, besides that, the README does clearly state "The Problem" and "The Idea" which outlines exactly why the author built this particular project.
I asked about the use case _because_ the readme states a problem but does not offer a solution to that problem as far as I could see.
I agree with all of this, and gource is an excellent example, but this is still "what" and builds no case for a "why". Not even an anecdote like "I told the agent this and it completely misunderstood and did the other thing so I built this which you can use to undo the work after the fact."
Because it’s fun and not everything has to exist for a reason other than that maybe? I built something in the same vein, and the way is because it’s neat. It serves no real purpose.
Tried exploring a small project i built with CC, but i don't see anything in the tree/terrain view (The edits/reads/writes do show up in the timeline). The project itself doesn't exist on my drive anymore, is that a requirement?
this is cool! i started tracking file changes across sessions with file hunk method on a binlog.. to see hot paths, or do partial reverts where files werent committed across my sessions. not for visual, but operational for the harness i use. approach lets you see the whole rollups on a period of days or minutes. think there are many use cases where you can run a side agent to check things / progress analyze risky areas as you go etc etcs .. all file change lookups are 3-5ms. script here: https://github.com/geeewhy/haicue-brew/tree/main/scripts
i wonder if i would be able to visualize with mindwalk
Haven't tried it yet, but I think we need something in that direction.
The terminal "Read file: xyz" mentions are not really followable.
It would be nice to easily see where the LLM is taking info from.
This is really cool! I’m becoming convinced the optimal UI to engage with agents, long term is going to be something spatial. No idea shape that even takes, though I really feel what you’ve made might be Xerox PARC days in terms of metaphor maturity, but there’s some real new seeds of “obvious in retrospect” ideas here. Thanks for conceiving of and building this!
That's great but im not sure what the use cases are. Did you have something in mind when building this to help the conception process ? I dont feel like i need to know what the agent did, never opened the session json. But there could be gold in there perhaps.
My original motivation is to compare the task-solving ability of LLMs by visualizing the agent's trajectory. This offers an alternative way to inspect the capabilities of LLMs and agent systems.
This reminds me of that community epsiode where they get the VR system and the dean has to walk through a maze, climb up several things so that they can go to a filing cabinet and then retrive a file. Yes, its cool to see and watch but it seems to be adding more friction than reducing it. Like who is going to spend that much time watching what their agents did when there are far quicker and efficient ways of scanning through changes and organizing code with better ergonomics?
Standard CLI version control tools like git diff, git log, or any built-in IDE diff viewer. Scrolling through a text summary of changes is inherently faster and more ergonomic than generating a 3D spatial visualization and watching an agent physically navigate through it.
(Though I disagree, not sure why this comment was flagged? vouched for it)
If you have a big codebase, text diff is not faster to see what was done here and there, then a visual overview. I don't know about this project, but experimented with other tools of this kind and am building one myself. With text diff - you have to parse lots of text and you cannot see on one glance that, oh, these changes are in the rendering, this is DB - and here was done something with the server connection. If done right, I can immediately or very quickly see what was changed - and also decide if the agent (or human) did work in the right spots or gone off track. Now doing this right is not easy, but reading lot's of text is definitely slower then seeing, oh in this area there was a change.
gource seems to be on of those tools that people forget about. I don’t know if it’s the name or just simply that it’s the kind of thing you run once and think “that’s nice - what do I do with it?”. It’s not something you run regularly so it slowly disappears from memory.
> It's pretty, but I can't think of anything I'd use it as a "tool" for. - https://news.ycombinator.com/item?id=21560013
Seems any time this sort of software comes up on, people can't let the use case be "this is aesthetically pleasing".
Anyways, besides that, the README does clearly state "The Problem" and "The Idea" which outlines exactly why the author built this particular project.
I asked about the use case _because_ the readme states a problem but does not offer a solution to that problem as far as I could see.
Use case is to monitor agents activity.
i wonder if i would be able to visualize with mindwalk
according to packages: https://github.com/cosmtrek/mindwalk/blob/master/web/package...
Thanks OP.
Like what?
If you have a big codebase, text diff is not faster to see what was done here and there, then a visual overview. I don't know about this project, but experimented with other tools of this kind and am building one myself. With text diff - you have to parse lots of text and you cannot see on one glance that, oh, these changes are in the rendering, this is DB - and here was done something with the server connection. If done right, I can immediately or very quickly see what was changed - and also decide if the agent (or human) did work in the right spots or gone off track. Now doing this right is not easy, but reading lot's of text is definitely slower then seeing, oh in this area there was a change.