Zizizizz

Just finished the Farseer Trilogy by Robin Hobb. I loved it!

You could at least write the READMEs

It also makes me think there's a divide on how many steps people choose or are able to see ahead.

They tell people who liked the journey that they're way is inefficient and you need only prompt to build, not seeing that in two years they're boss will be saying the same thing to them because they don't warrant the salary to pay them to do the same thing anyone with an idea can do.

I don't see an all encompassing one but I could see similar arguments being made in a courtroom around high capacity magazines. (I'm not saying I think the analogy is perfect, but there has been plenty of of lobbying that has stifled - to some - sensible gun regulation that could help reduce the severity of mass shootings. I still mostly fall on the side of the individual doing the action bearing mostly all of the responsibility but if the product you build makes it too easy to do awful things, I think there is some responsibility to go around.

A better analogy may have been the troubles Meta has faced around child protections on their platforms. Technically the abuse and problems have stemmed from individuals too, but they've in many respects enabled the situation by failing to moderate or flag warning signs. OpenAI is failing to moderate the models in similar ways.

I wonder if Glock, Smith & Wesson, Sturmn, Ruger and Co. would start panicking if that were to happen.

I agree they should though.

hisect (history and bisect)

Seekfold (seek and manifold)

Seekdex (seek and index)

Yep, that could happen as well. I suspect some engineers would be surprised how much work, time and effort it takes to build the relationships to market and sell to (along with all the other roles).

I hope that everyone agrees to collectively recognise we all need to still do some things together and the knowledge in our heads is still much more important.

I agree with you, it's the same experience I've had. But I've seen completely nontechnical people build some sites and become convinced themselves, and if those people control the purse then it doesn't matter as much what devs think the reality of agentic dev is. (Until they get burned enough times).

Sorry I meant ownership of it working when an alert goes off in production and having to fix it, not legal liability. I should have been more clear.

Sounds like a failure of imagination to me (I hope you're right). It doesn't have to be the CTO, it can be anyone who will sit there for the cheapest cost to read output while assuming the risk of it all working until they retire. Sounds glorious

I think there's an element of truth to what you're saying in respect to the feelings of frustration that people who are non-technical can compete with those who have spent decades of time and effort to learning the crafts of their trade.

What I also think they are thinking (because I am one of them) is not that we can produce value easier and quicker. It's that there's a devaluing of education and expertise to the point where organisations will become wise to the fact that you're able to produce much more quickly because you're just relaying what they want to your prompt. And because you're doing it on their time, can just copy your processes, get rid of you because they have their own ideas. (For personal projects and entrepreneurship this isn't applicable)

Let's take an example organisation with a team of 10 Devs. In the short term, they'll be able to build and provide value to the company and they will see the power that AI can bring. But with time they are now finding it harder to compete because everyone can build similar competitive services. So they try to reduce head count and those who control the purse are often not the devs so they reduce or remove the dev team because prompt engineering has gotten so good that they don't need your expertise anymore, they'll try it themselves.

So in the short term the organisation has all 10 devs producing a bunch of output. In the medium term, the company headcount can shrink because you no longer need to be aware of what is happening under the hood.

But because every business has this realisation, everyone will have the same ideas. So it will be harder to avoid being copied by competitors because ideas are no longer gate-kept by effort and expertise. SaaS will decline, in the medium to long term because you can vibe a replacement, in the long term the open models get good enough that the OpenAIs of the world aren't needed so the moat goes to the Nvidias of the world, then the hardware design can be automated/vibed, so the only moat is the land and raw materials. The manual labour will get flooded with knowledge worker refugees but that flood will probably force costs down there too.

In summary, I think they are mourning the feeling of being an expert and doing things others cannot, but I think more strongly they are looking at the "value" proposition and not seeing how it's sustainable.

I think both sides agree that building is much easier like you have articulated really well. I think they just take it a few steps further.

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.)

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)

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.

It feels like this every day

https://youtube.com/shorts/vGKC9LpGnOQ?is=iCG7qvAIL9oI5-_d

I like just or mise tasks as often my python projects contain many other language commands (SQL, docker, pnpm, etc ...).

I agree with you in respect to the greatest risks in that industry. Just thought it's worth mentioning that LLM's unsurprisingly are not immune to hallucinating cases. https://www.scientificamerican.com/article/why-lawyers-keep-...

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.

Zmx allows for similar features natively

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.

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 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'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.

https://fluxcd.io/ + helm + with a CI pipeline that pushes the docker images to a registry means that after the setup, anytime you push a new image and tag, k8s can automatically update without needing to do anything manual.

Yeah tell that to all the people who avoided the bare minimum of advice during COVID for their own beliefs and subsequently died.

You can name branches in JJ too, they're just called bookmarks.

git checkout main git pull git switch -c jira-234 ... git commit git push -u origin main

jj git fetch jj new main ... jj commit jj b(ookmark) c(reate) jira-234 -r @- jj b(ookmark) t(rack) jira-234@origin jj git push

I find it hard it hard to believe anyone apart from you would see this as remotely the same thing.

I use my own domain with Gmail

https://www.reddit.com/r/SaaS/comments/1g0m0um/how_to_set_up... is what I did.

Most English speakers speak faster than 120 wpm so that's probably why people, especially those who can't type at speeds like you can, prefer it.

I tried tig first, I think Lazygit is the ideal interface to me for it. I actually don't use it apart from tags now though as I switched to jj and jjui for 2026. I think everyone has their own tool that works for them so it's hard to go wrong with a lot of these tools