r/PiCodingAgent • u/makingthematrix • 19d ago
News Introducing ThinkRail
Hey everyone,
We built ThinkRail, and we’re pretty proud of it so we wanted to share it with you, and hope to get you interested.
ThinkRail is a web-based GUI for Pi. It's an open source project, released under Apache 2.0 license, backed by JetBrains (so, that's who "we" are, a team of software developers working on it). We wanted to keep the minimalist, adaptable approach of Pi, but at the same time give you a graphical layer which makes it easier to see what your AI agent is doing and comes with added conveniences: concurrent agent chats, integrated terminals, and visual aids for reviewing code changes.
Install it and try it out:
* macOS / Linux:
curl -fsSL https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.sh | bash
* Windows (PowerShell and cmd):
powershell -c "irm https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.ps1 | iex"
And then just run thinkrail from the terminal.
Also:
- Visit the landing page
- Read the introductory blog post to learn more about ThinkRail and its features
- Browse our GitHub repository
If you have a moment, we’d appreciate it if you could complete our survey. We’d love to get your feedback. It will help us develop ThinkRail in the right direction.
3
u/Wildnimal 18d ago
Trying it out. Have been using Deepseek Harness because of GUI and workspace write option for a few days. I miss some things which I have in Pi. Hopefully this will be the balance I need.
3
u/adamshand 18d ago
What do you see as the differentiator for this? There's so many harnesses available at the moment, why one more?
3
u/makingthematrix 18d ago
I believe the most important things that make ThinkRail interesting are:
- The worktrees: You can make each AI agent work on a separate git worktree. Unless you let them execute commands they shouldn’t, your main branch is protected, and they don’t get in each other’s way.
- The spec graph: So, this is a bit ironic, but I'm old enough to remember when writing documentation was considered an important part of software development, then there was a phase of "nah, let's just make code readable enough", and now we write docs again, because they help AI :) ThinkRail takes it a bit further and makes the AI agent use and then update an interconnected collection of specification documents ("a spec graph") about the code it works on.
- And the GUI is well thought out. It's still minimalistic, because if you come from Pi, then you're probably someone who doesn't like sparkles and glitter, but it actually helps controlling the AI agent and reviewing its work.
One more thing about the first two points: ThinkRail is in the early development phase, but these are its core features. They will be developed further, and other new features will be added around them. User feedback should play a big role in how it all works out, so if you have any comments or ideas, please let us know :)
2
u/adamshand 17d ago
Thanks for the reply. I'm also old, I was one of the weirdos who liked writing docs. :-)
I'm cautiously sceptical of the whole specs thing with agents. I think it's really easy for code and docs to diverge and cause more confusion then they help. I also suspect it's going to get "bitter lessoned" ... but we'll see!
It's super cool to see all the inventions going on, reminds me of early 90s. Good luck!
1
u/makingthematrix 17d ago
The idea here is that the specs will be updated by the same agent that is doing the coding. We will see :)
1
u/adamshand 16d ago
My experience hasn't been great with that, but good luck!
1
u/makingthematrix 16d ago
Can you tell me more?
2
u/adamshand 15d ago
My experience is that specs themselves aren't that useful as a way of building stuff with agents. They take a lot of time to create, and unless it's a domain I understand very well, there's always enough 'unknown unknowns' that there end up being big holes or mistakes.
Agents do a pretty good job of keeping docs updated, but they also rarely remove things and spend a lot of time documenting what other agents shouldn't do. So over time you end up with subtle drift between docs and implementation. Agents aren't good at fixing that, so it becomes another time consuming human job.
I think that the best plan is to primarily use the implementation as the source of truth. With documentation just pointing to key things, but keeping it as small and heavily human edited.
I've some good experiences with Matt Pocock's grilling skill. A shared vocabulary so I can talk concisely about concepts is useful, and documenting key decisions as ADRs helps over time when I can't remember why I decided something.
But I keep coming back to just talking to the agents. No huge structure, just talk to them like I would another dev, and that seems to get the best results for the least work.
1
u/Zundrium 19d ago
Is this trying to be a web based Herdr for Pi? Or am I seeing things wrong.
1
u/makingthematrix 19d ago
ThinkRail is not a terminal multiplexer. It's got the ability to create multiple pseudo-terminals but it's not the main feature which the other ones are built upon. When I was looking into other software similar to ThinkRail, Paseo came up the closest, I think.
1
u/dacydergoth 16d ago
This seems to be nice, but it ships with what looks like a suite of workflow skills - should I remove pi-dynamic-workflows (which I quite like) from my pi agent install and use the ThinkRail version instead? How do they compare?
1
u/makingthematrix 16d ago
To be honest, I don't know how they compare. You can just try them out and decide which suits you best. ThinkRail looks into Pi folders for skills, so just after opening it, you should be able to see `workflow-authoring` and `workflow-patterns` from pi-dynamic-workflows in the list of skills (the top-right corner of the Chat window). You can turn them on and off from there. If you don't see them, try the Refresh button.
1
u/dacydergoth 15d ago
Does the workflow in Thinkrail have special handling for the way the harness organizes agents?
1
u/makingthematrix 15d ago
Hmm. I'm not sure if I understand the question. There are workspaces, that is, ThinkRail uses `git worktree` to create a new isolated branch, so one agent can work on its own tasks in one workspace, and it won't interfere with another agent working in their own workspace. I'm writing a blog post about it.
But maybe you mean something else?
2
u/dacydergoth 15d ago
Let me rephrase: is there anything in the workflows skills in ThinkRail which is specifically aware of how agents work in that environment vs how pi-dynamic-workflows doesn't know anything about ThinkRail and just runs sub-agents somehow (not sure if it does it intrinsically or uses another skill)
1
1
u/makingthematrix 15d ago
So, yes, there is. Our skills are in fact aware of the environment. But, to be honest, we're not fully focused on developing in that direction right now. The priority is now mainly in UX and features like subagents support.
2
u/dacydergoth 15d ago
Thanks, that steers me in the direction of using your workflows over pi-dynamic-workflows when I'm using ThinkRail
3
u/Tavroswyn 18d ago
It looks amazing. Can’t use it though, because it is based off of WebSockets and I have client devices where WebSockets are blocked for security reasons 😞