Why does AI-generated imply "not bothered" to you? If I take all of my design docs/specs, all of the existing repo, and I tell an agent that I'd like to make a readme that contains things X, Y, and Z, what's the problem?
Rejecting slop doesn't imply rejecting all AI-generated text wholesale.
> Why does AI-generated imply "not bothered" to you?
1. AI generated text is just hard to read and verbose, if you worked so hard on your docs/specs, why would you want your README to be unreadable?
2. There's so much garbage written with AI that I'm just going to assume yours also is. Would you sign up to a gym with broken windows? It could be the best gym ever, but I wouldn't count on it.
The problem is that it’s market or care and respect. If you can’t even be bothered to while a simple readme communication your intentions, what else can’t you be bothered doing properly?
It’s a marker that the project is likely to be low-effort slop, which may or may not just be abandoned at the deep of a hat.
Because AI-generated README means that the person doesn't care about the audience. It means that the author never read the README themselves to see that the "load-bearing ground truths" actually reflect what the project is about, and not some hallucinated bullshit.
There's a famous Jobs story in which he insisted that even the insides of the computers be made beautiful. Because that shows care. Now people are arguing that even the outsides can be as ugly as they want, who cares.
I’ve been using JetBrains IDEs for over a decade but rarely open them anymore because working on several worktrees concurrently is extremely frustrating and wasteful. Their AI strategy is all over the place and they always wanted to sell their opaque and overpriced tokens, which made no sense. I hope they get their act together.
Yeah, their worktree implementation was very recently hacked in, and it really doesn't work well. The IDE project list duplicate entries for every worktree, IDE project settings don't transfer across worktrees, and every time I switch to another worktree it asks me again what project I want to open, instead of just opening the same solution I have opened.
It's wild that a set of IDEs that are generally fairly good just completely fail in this basic workflow. I really wonder what went through the minds of the product owners and developers that implemented this.
I canceled my subscription after like 12 years because I realized all the things that made it great aren’t really needed anymore. The “it just works” tooling, refactoring, jumping around code, etc.
Now my agents mainly write code under my direction and I review it either in the harness or on GitHub.
I hadn’t opened it in ages and when I did need an IDE something like Zed was more than sufficient.
I thought so too until I learned that there is a dedicated worktree switcher hidden away as a tab in the GitHub pain. Now I can open each worktree in a separate window as if it were its own project. Maybe that's not everyone's ideal work though, but it's exactly what I want 99% of the time.
But I don't use it for AI assistant development, it's definitely meant for humans and not AI agents.
I also have to work in multiple workspaces simultaneously, and it drives me up the wall every time one of my IDE windows freezes (sometimes even just from inserting a Tab), because now ALL of them are frozen.
The problem with all the AI IDE's is you can't use them with most enterprise/teams accounts, you have to use API which can cost upto to 10x more over an enterprise plan. I really like JetBrains, used them for a LONG time, but just find myself doing 99% of my day to day with iterm and sublime now.
Didn't JetBrains release JetBrains Air recently? This looks like it's basically the same basic premise, except implemented differently. What's their strategy here, are they just launching competing products?
At a guess, they are uncertain about the long term financial viability of selling their full IDEs, and development is cheap, so they are throwing up what they can to see what sticks, and will kill what doesn’t.
It seems that Air is a strategic product, and Thinkrail is more of an experiment.
While they are both "agentic development tools", it seems that Air is mostly concerned with managing multiple agents, whereas Thinkrail is about spec-first development.
To me the main difference is that there is no staging (so no stashing needed), and conflicts are first class citizens. In practice this means that you can usually halt your work halfway, switch a commit, rebase everything onto head and continue working even if one of the branches off your commit has conflicts. In git you would have to resolve those before the rebase can finish.
Since conflict resolution these days mostly boils down to “hey LLM, resolve conflicts” this is much nicer.
Also jj tracks every change to the repo so undo works much better and is more readable than reflog
No, jj is not a wrapper around git. It is a source control system of its own that has git as one of at least two production backends. This distinction matters because git wrappers don't tend to have fundamental concepts of their own like the operation and evolution logs.
NGL Jetbrains has massively helped my developer journey and be a great tool for many many years. I don’t open it that often anymore, but I see that they’re trying hard to stay relevant, which is probably not easy as probably the whole market moved against you.
Yeah, now that agents are doing most of the work, and we want to give them as much freedom as possible to run code, take screenshots, click on things, etc, it really doesn't make much sense to have a setup where all of this happens on your local computer. IMO it makes more sense to have this hosted somewhere, and then have UIs that make this visible to you on your devices.
This sounds like a short-term strategy at best
You only need an agent to click things long enough to build an API on top of the thing it's clicking on. And running a full windowed virtual machine is expensive!
I'd also caution against saying things like llms are doing most of the work I don't think that's true. And where it is true it shouldn't be. These things are still new tech and they need a lot of hand holding and oversight still.
Exactly. They sit in their little world in my homelab and I control everything through networking and virtualization restrictions. They run on a beefy VM, can spawn their own VMs (Ubuntu, Debian, Fedora, Arch, Windows, even macOS on an old mac mini), run their own browsers, access their own secrets, etc. There's no way I would go back to agentic development on my local machine anymore.
I am curious about Pi, but my experience with a seemingly more fully-featured Hermes has been endless tinkering and fixing minor issues. Have your experience been at all similar?
I've been using it without thinking much about it for 3 months now. Have yet to run into any bugs or strange behaviors. But bear in mind I'm using oh-my-pi, not Pi. I found the latter to be mostly useless in terms of what I needed for my day to day work. I'm sure I could tinker with it to get it right, but that's literally what oh-my-pi is doing for you. And like I said, zero problems thus far.
Looks interesting, but they need to clean up the claudese in those bullet points holy crap. It's like they purposely want the "what you get" section to be as obtuse as possible.
This is moving in the direction towards a final interface, very good.
There aren't enough digital french cleat systems.
The true benefit of a French cleat isn't storage or organizing the way a fiddly pegboard and hanger approach uses, it's the ability to move all tools for a specific project onto a single rail without having to fiddle around, reducing friction for engaging and re-engaging with a project.
That's what it is, it's basically two boards with angled cuts to match. One mounted to the wall, the other to the thing you want to hang from the wall. No fasteners needed other than for those two attachments (or more if you use more boards). Gives you some flexibility in arranging things in a shop (or, that's my reason for using it with our 2-car garage).
I do not get the appeal of web-based GUIs now that we have LLMs.
Migrating my screenwriting software[0] from OpenTUI to Roc thought me what were once rough edges that take a lot of time are now just a prompt away from a solution.
It now uses 10x less RAM, bundle is half the size, and my initial implementation is 700-800 fps for scrolling and 200 fps for writing.
Granted, a TUI is less complex than a full-blown GUI, but I built a Roc Iced platform just as easily that abstracted Iced flux away
JetBrains UIs aren't web-based, unless this is an exception.
JetBrains tools are heavier and can take a few seconds to launch, but they also have some of the most responsive typing out there. They did some good work on zero-latency typing modes when that was a big topic and they were very good at typing latency relative to most editors.
They will never be the right tool for the personality type that gets angry when their IDE takes a few seconds to launch at the beginning of the day or when an application takes more than 1GB of RAM, but I am not that type of person so I enjoy them.
I think the TUI people are well served by vim or emacs and should just stay there and be happy.
The rest of your post feels like an injected ad for your project underneath a topic where it's not relevant
This post is about a TypeScript repo, which is what I commented on. It may as well be a necessity since Pi is using a JS runtime as well. It has nothing to do with JetBrains and everything to do with the codebase in the link.
It also has nothing to do with TUI vs. GUI, since my comment addressed both (anecdotally).
If anything, your mentioning of their performance work is exactly my point.
I do code -- the app logic. I also am well aware of what the infrastructure code does, I just don't type any of it myself.
Even if I wanted not to code it I couldn't. LLMs are still incapable of creating code up to any decent standard.
Also, while I do the get the joy of programming, we sometimes forget to focus on the user. You being happy to have typed the whole thing once, and have it run everywhere via the magic of browsers may not be the best strategy if this means your user's lap will be overheating.
In the end as much as I like coding I would prefer my users' experience to be the best it can be. LLM assisted code delivers this better and faster than hand-typing it all (which in turn is better than completely vibecoding it)
(100% AI according to Pangram btw)
Rejecting slop doesn't imply rejecting all AI-generated text wholesale.
1. AI generated text is just hard to read and verbose, if you worked so hard on your docs/specs, why would you want your README to be unreadable?
2. There's so much garbage written with AI that I'm just going to assume yours also is. Would you sign up to a gym with broken windows? It could be the best gym ever, but I wouldn't count on it.
I can do it. Anyone can do it. Probably better for my/their own needs than someone else’s agent can.
The README is meant to communicate substance and intent. Without the latter it’s an overly-verbose landing page.
If it is blatant unfixed llmese, then it means that no effort whatsoever was put into making this text.
It’s a marker that the project is likely to be low-effort slop, which may or may not just be abandoned at the deep of a hat.
There's a famous Jobs story in which he insisted that even the insides of the computers be made beautiful. Because that shows care. Now people are arguing that even the outsides can be as ugly as they want, who cares.
Then I’ll probably hear about it again from someone I trust. I don’t need to be the first in my circle to test if this one is different.
It's wild that a set of IDEs that are generally fairly good just completely fail in this basic workflow. I really wonder what went through the minds of the product owners and developers that implemented this.
Now my agents mainly write code under my direction and I review it either in the harness or on GitHub.
I hadn’t opened it in ages and when I did need an IDE something like Zed was more than sufficient.
But I don't use it for AI assistant development, it's definitely meant for humans and not AI agents.
https://www.jetbrains.com/air/
While they are both "agentic development tools", it seems that Air is mostly concerned with managing multiple agents, whereas Thinkrail is about spec-first development.
Since conflict resolution these days mostly boils down to “hey LLM, resolve conflicts” this is much nicer.
Also jj tracks every change to the repo so undo works much better and is more readable than reflog
I guess they'll just copy submodules too. Kind of feels like there's little point using it if it's just going to copy Git's mistakes.
So I’m willing to give it a try.
EDIT: found it at https://thinkrail.ai/blog/thinkrail-sdd/
---
Also... why bun?! I just finished purging it from all my systems, ha! It'd be cool to have plain pnpm support.
I'd also caution against saying things like llms are doing most of the work I don't think that's true. And where it is true it shouldn't be. These things are still new tech and they need a lot of hand holding and oversight still.
Also, reading through their "SPECS".... https://github.com/JetBrains/thinkrail/blob/d299f20d2ba014f3... or https://github.com/JetBrains/thinkrail/blob/d299f20d2ba014f3...
How is this llm-vomit "specs that are ground truth" etc.?
This is exactly what I was missing
There aren't enough digital french cleat systems.
The true benefit of a French cleat isn't storage or organizing the way a fiddly pegboard and hanger approach uses, it's the ability to move all tools for a specific project onto a single rail without having to fiddle around, reducing friction for engaging and re-engaging with a project.
JetBrains, explain concisely why this isn't written in C/C++/Rust?
Migrating my screenwriting software[0] from OpenTUI to Roc thought me what were once rough edges that take a lot of time are now just a prompt away from a solution.
It now uses 10x less RAM, bundle is half the size, and my initial implementation is 700-800 fps for scrolling and 200 fps for writing.
Granted, a TUI is less complex than a full-blown GUI, but I built a Roc Iced platform just as easily that abstracted Iced flux away
[0]: https://blisswriter.app/
JetBrains tools are heavier and can take a few seconds to launch, but they also have some of the most responsive typing out there. They did some good work on zero-latency typing modes when that was a big topic and they were very good at typing latency relative to most editors.
They will never be the right tool for the personality type that gets angry when their IDE takes a few seconds to launch at the beginning of the day or when an application takes more than 1GB of RAM, but I am not that type of person so I enjoy them.
I think the TUI people are well served by vim or emacs and should just stay there and be happy.
The rest of your post feels like an injected ad for your project underneath a topic where it's not relevant
It also has nothing to do with TUI vs. GUI, since my comment addressed both (anecdotally).
If anything, your mentioning of their performance work is exactly my point.
Even if I wanted not to code it I couldn't. LLMs are still incapable of creating code up to any decent standard.
Also, while I do the get the joy of programming, we sometimes forget to focus on the user. You being happy to have typed the whole thing once, and have it run everywhere via the magic of browsers may not be the best strategy if this means your user's lap will be overheating.
In the end as much as I like coding I would prefer my users' experience to be the best it can be. LLM assisted code delivers this better and faster than hand-typing it all (which in turn is better than completely vibecoding it)