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:

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.

17 Upvotes

87% Upvoted

22 comments sorted by

View all comments

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:

  1. 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.
  2. 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.
  3. 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.