> but it doesn't refuse to write the code without first being told why it wouldn't be a better idea to do X first

Then don't ask it to write code? If you ask any recent high quality model to discuss options, tradeoffs, design constraints, refine specs it will do it for you until you're sick and tired of it finding real edge cases and alternatives. Ask for just code and you'll get just code.

They are way better at code-related tasks than design or strategy ones. Anything involving users or business strategy or a "why" is vague and misguided, they have no insight.

To be fair, they're primed to write code, even when you don't ask for it. I explicitly tell Claude "do not write code" when I don't want any, otherwise it'll spit some out just to say hello (world).

You need to be in plan mode. Not only can it not change code, its interaction with you is quite different. It will surface issues and ask you for choices.

"Here is some python code that printf's the travel recommendations you asked for, btw"

The more I read people saying that Claude is failing, the more I realize this is 90% a user problem. This is just an example, but I see it often.

Claude has a mode specifically for what you're talking about, it is actually very good (Opus 4.5) at planning and going through design without coding, it's called planning mode.

Listen, if you aren't constantly shift-tab or esc-esc during complex problems, and then struggling when it isn't working for you, rtfm, you'll get further and better results.

> But you still need to know how to do things properly in general, otherwise the results are bad.

Even that could use some nuance. I'm generating presentations in interactive JS. If they work, they work - that's the result, and I extremely don't care about the details for this use case. Nobody needs to maintain them, nobody cares about the source. There's no need for "properly" in this case.

I like the idea of ratchets, but the implementation needs to be good for them to work nicely.

> If it counts too few, it also raises an error, this time congratulating you and prompting you to lower the expected number.

This is a pain and I hate that part. It's one of the things that isn't even a big deal, but it's regularly annoying. It makes leaving things in simpler than removing them - the good act gets punished.

One way to make this better is to compare the count against the last merge base with the main branch. No need to commit anymore. Alternatively you can cache the counts for each commit externally, but that requires infra.

> linux booted directly without any LILO or GRUB (this was back in the days the kernel included its own boot loader)

You can still do that if your machine supports coreboot.

> AI can be a very effective tool for education if used properly. I have used it to create a ton of extremely useful visualizations

I feel like this is still underappreciated. Awesome meaningful diagrams with animations that I would take me days to make in a basic form can now be generated in under an hour with all the styling bells and whistles. It's amazing in practice because those things can deliver lots of value, but still weren't worth the effort before. Now you just tell the LLM to use anime.js and it will do a decent job.

Have you told the author your feedback? Nothing's going to change otherwise - they may think they did something helpful.

You may not be in the right state, but the point of that part of the website is that it's a donation link. It will drive some people to help. If it's at the cost of some others getting grumpy about too much messaging... that's probably still worth it.

> and still have the good sense to

The good sense is your judgement. At some point a real, direct, disruptive protest is going to be the right solution for a big enough group of people. Peaceful protests are just a "we're starting to get there" signal. It's not like politicians normally say "gee, lots of people don't like how I abuse power, I guess I'll stop now". It's all about being collectively upset enough about status quo.

> you should probably not question them

Don't question in an aggressive way. But feel free to ask why things are the way they are. If you do it while they have time and if they're good senior, they'll be happy to show you all the skeletons in the closet and explain why things are the way they are.

Be genuine about it though because we can all see through that method of questioning used to imply it's wrong.

It does look nice, I'll give it a go. Just wanted to say that "Git-out-of-the-way source control" is the best tiny description of JJ I've ever seen, because it's both true and the pun works perfectly. It brought me joy.

It uses it when you use the git backend, but not when you don’t.

Right now, the only other backend is at Google, so it’s not practical for most people. But it’s not an inherent part of jj, and that’s really important, actually.

For anyone that does not work at Google, it sounds like an implementation detail that does not matter.

Yes, at the moment it does not. But a well factored system is important for gaining future benefits. For example, I work at a startup that is building jj related tooling, and that the git stuff is separated out cleanly is what enables us to build better things than if it were so tied to git.

To complete the analogy, given that we haven't launched, yes, this is a theoretical benefit for now. But that doesn't mean it's useless. jj is still pre-1.0 software, there's a lot more work to do, and more interesting things coming down the pipeline. That matters, even if it's not relevant to every potential user just yet.

10 years of using Git and I never knew undo was what I craved. And the ability to rebase and edit commits in a single command.

Solves 90% of my problems so haven't felt like I needed any additional tooling on top of jj.

But I am curious is there some edge case on jj that I missed. That you folks are working on improving tooling for?

Just really curious about this new world with some better solutions to git.

I liked pijul a bunch too but lack of compat with git meant I can't use it for work... Haha real sad moment right there.

Not working on it (yet), but I wish the jj <-> github story was a little more ergonomic.

Additionally, I am really missing support for stacked diffs, ie, easily pushing a number of commits into one PR on github each such that they all show their incremental diff.

ezyang's gh stack was pretty useful, if a little bit fragile [0] and graphite.dev is also very nice, but paid software with a strong VC based motivation to become everyone's everything instead of a nice focused tool.

[0] https://github.com/ezyang/ghstack

I'm also not super happy with the default 3-way merge editor, but often cannot use vscode or other GUIs.

https://github.com/LucioFranco/jj-spr is one way to get stacked diffs on GitHub with jj, but also GitHub has at least claimed on X that native stacked diffs is coming so we'll see how that goes!

Git's plumbing is great. Git's porcelain is what sucks. JJ replaces the porcelain.

Git's plumbing also kinda sucks (in places). Some of the current limitations of jj in what syncing state between repos is due to things missing from git that they are having a hard working around, at least based on what I've seen browsing their tickets. That inability to push the really useful jj state upstream for pulling from any machine seems like a major pain point in jj right now (was one of the major issues referenced in a jujutsu intro guide last year linked on HN)

The same issue hit the initial efforts (that I think were the inspiration for jj) when the mercurial folks, recognising git had kinda taken over the market, experimented in making a mercurial frontend backed by the git db. Limitations like the diff format (mercurial's weave one is one the jj folks also want to add at some point) and the lack of a method for tracking phases (mercurial relies on this for clean history without throwing out commits), and lack of file move/copy tracking.

This comment made me reconsider my attitude about git a little bit. Thank you.