Hypothetically, in 100,000 years, if human activity has led to the death of everything not human on this planet and we ourselves are on the brink (effectively leading Earth to go back to square one) would you rather that, or humans end in 50,000 years but through conservation and study made way for other life on this planet that will eventually conquer space and some of the mysteries of the universe.
Obviously the timelines are insane but just as a thought experiment, I would suspect we would get different answers depending on who you ask, and thus the study, understanding and conservation of other life that shows a form of intelligence becomes much more important to some, whilst human preservation at the expense of all else is more important to others.
(I also recognise you aren't saying that by the way, but it's what came to mind when I read your comment. I personally think we have more than enough resources to do both. I'd also imagine we will learn more about ourselves and what's possible in medicine by studying other species.)
It honestly makes working with git so easy and fast that I would say it's the ideal way to interact with git. I highly recommend checking it out for a month if you're someone who would use git commands in the shell. I don't know how fast and visually clear the gui interfaces like the ones built into VS Code or Sublime Merge are but as someone who uses a terminal test editor having a tool like this has been fantastic.
Something else to try if you're a fan of alternative git interfaces is Jujutsu. It's CLI, and it's more of its own interface, but it's very Git-compatible, other than submodules. You pull from and push to Git remotes.
I actually use Jujutsu and jjui now but used lazygit for years. Jjui still isn't as polished as lazygit (I've added quite a few lazygit keymaps like opening the bookmark as a PR, untracking or restoring files in the current change) but it's close.
That said, I think lazygit is much faster than plain jj CLI commands. I just use JJ for undo and merge conflict resolution for the most part. (2026 was my year of JJ and I am loving it, but I can't say I don't miss lazygit's speed and niceties like showing ci/cd build statuses on each branch/bookmark)
IMO mise tasks are fairly close to the ideal polyglot task runner, because features like argument definitions can be used as progressive enhancements. That means I can write the task logic in shell scripts that can be called without mise, and when I integrate them into mise, I don't have to manually write extra wrappers or duplicate anything. That's my pet peeve with most similar tools, so I can't recommend mise enough!
Using them for coding makes it easy to self check its work (assuming those pieces of work are "verifiable").
As proofreading will still need to happen, what do you think the appetite for lawyers is to do this kind of work? Do you think it will drive fees down significantly? Empower younger lawyers at firms who probably are the ones doing this checking for the partners? (Or will that just create a further divide).
I'm genuinely asking as I am not in law but all my family is and it's nice to see someone here that's thought about the impacts in that space.
With access to good databases and tool use, hallucinations are basically a thing of the past (and very easy to verify). The hallucination issue typically comes from people using free ChatGPT or similar - tech usage and literacy is often poor and there's a lack of understanding of the risks of using something without proper legal database tools. Most lawyers would not have the faintest idea of what tool use in the context of an LLM even means. It's still seen as a magic box rather than a tool for real work.
Will it drive down fees significantly? Doubt it, there's not enough pressure on them, and the industry is resistant to change. Firms don't want to make a big deal about using it because clients will then ask why they're not getting a discount.
Will it empower younger lawyers? Not as much as I'd like. I'm very fortunate to have an employer that lets me use Claude Code for my work (to a limited extent). I think for 99.9% of lawyers it's not an option available to them, through a mix of concerns around AI usage and concerned IT departments. There could be great benefits, but it would rely on having to break out of traditional private practice which would make it difficult to get enough work.
I think in the near term LLMs will have much the same impact on the legal industry as it has on the software industry.
I still look at the files I want to change so that it doesn't go off and grep the entire project unnecessarily, burning tokens or getting the wrong idea.
So I still use a ton of fzf.lua to find the files to change and I have just added some keybinds to copy the open file path to the clipboard so that I can paste the path of the file to change it into opencode.
Code diffs I definitely look at locally with delta via lazygit or jjui. codediff.nvim is also good for resolving conflicts.
The main thing I've changed is just using JJ so merge conflicts can be resolved later by me manually without it blocking bringing in new changes.
If I just hand over the thinking entirely and don't know what has changed until I'm looking at it in GitHub I feel that removes the need for me entirely as by that point I'll be biased and will be less likely to change things to how I'd like them to be.
I would imagine why the types were chosen could easily be explained in the commit message. The goal presumably (at least how I do it) is so that if I'm touching quite a lot of the code base, the reviewer has the _option_ of being taken through the narrative of the change like they might explain if they were talking to you. If you don't want to be told what the changes are and how they tie together, then just click on review changes and review it all at once. It's not about the clean history, it's about making the reviewer's life easier with larger features.
The commits might get squashed anyways so the history on main won't necessarily match what's on the feature branch.
You can commit before you raise a pull request, I don't quite understand that point but I might just be missing something about your workflow that's different to mine.
I work via tickets so I don’t take care of the commits in my branch (if I would there would only be one commit). So what I expect the reviewer to do is review the whole diff. I help by commenting the changes to explain the design and the implementation.
Commits on a PR branch are usually my thinking outline, not for someone else to step through.
That's fair enough! I think the flow will be more universally beneficial if things like this become more mainstream. https://github.github.com/gh-stack/ because then big prs aren't necessary if they can be reviewed incrementally so long as they can stand on their own.
I've used it in the past and personally loved it. Just bumping a yaml file in a git repo to the image tag I wanted deploying was a godsend and nearly automated. I can't speak to your experience though which I am certain is valid and a real problem. We just never had those kind of issues so we could either revert to an earlier tag that worked or publish a new image with the required resolution steps.
Obviously the timelines are insane but just as a thought experiment, I would suspect we would get different answers depending on who you ask, and thus the study, understanding and conservation of other life that shows a form of intelligence becomes much more important to some, whilst human preservation at the expense of all else is more important to others.
(I also recognise you aren't saying that by the way, but it's what came to mind when I read your comment. I personally think we have more than enough resources to do both. I'd also imagine we will learn more about ourselves and what's possible in medicine by studying other species.)
reply