Different type of creator, different type of bugs. I'd assume a human giving me a way to delete merged branches has probably had the same issue, solved the same problem and understands unspecified context around the problem (e.g protect local data). They probably run it themselves so bugs are most likely to occur in edge cases around none standard use as it works for them.

Ais are giving you what they get from common patterns, parsing documentation etc. Depending what you're asking this might be an entirely novel combination of commands never run before. And depending on the model/prompt it might solve in a way any human would balk at (push main to origin, delete .git, re-clone from origin. Merged local branches are gone!)

It's like the ai art issues - people struggle with relative proportions and tones and making it look real. Ai has no issues with tones, but will add extra fingers or arms etc that humans rarely struggle with. You have to look for different things, and Ai bugs are definitely more dangerous than (most) human bugs.

(Depends a little, it's pretty easy to tell if a human knows what they're talking about. There's for sure humans who could write super destructive code, but other elements usually make you suspicious and worried about the code before that)

When I write the code myself, I'm not worried that I snuck a `git reset --hard` somewhere.

I prefer tui's for two reasons. 1. Very used to vi keybindings 2. I like low resources software. I love the ability to open the software in less than a second in a second do what I needed using vi motions. And close it less than a second.

Some people will be like you save two seconds trying to do something simple. You lose more time building the tool than you will use it in your life.

It's not about saving time. It's about eliminating the mental toll from having to context switch(i know it sounds ai, reading so much ai text has gotten to me)

> an interactive page that can be navigated around with the keyboard

Or mouse / trackpad.

I really haven't seen anything better for making TUIs than Borland's Turbo Vision framework from 35ish years ago.

So the acronym is for Terrible User Interface? ;)

It's gotten more popular for sure, but it's definitely been around a long time. Even just on HN there have been conversation about gdb tui ever since I've been here (starting browsing HN around 2011). For anyone who works in embedded systems it's a very common term and has been since I got into it in 2008-ish. I would guess it was much more of a linux/unix user thing until recently though, so people on windows and mac probably rarely if ever intersected with the term, so that's definitely a change. Just my observations.

As someone who came up using Borland's Turbo Pascal, Turbo C, and Turbo Vision (their OOP UI framework), it was called CUI (character-based user interface) to distinguish from GUI, which became relevant as Windows became dominant.

I never heard "TUI" until the last few years, but it may be due to my background being Microsoft-oriented.

One of the only references I can find is the PC Magazine encyclopedia: https://www.pcmag.com/encyclopedia/term/cui

They aren’t the same thing. TUI refers to interactive ncurses-like interfaces. Vim has a TUI, ls does not

I’m fairly certain this terminology has been around since at least the early aughts.

I don't know when the term became widespread for gui-style terminal programs, but the wikipedia entry has existed for more than 20 years so I think it is an older term than you imply.

https://en.wikipedia.org/w/index.php?title=Text-based_user_i...

Sorry, but this 65 yo grey-beard disagrees. A TUI to me, back in the 80s/90s, was something that ran in the terminal and was almost always ncurses-based. This was back when I was still using ADM-3A serial terminals, none of that new-fangled PCs stuff.

[dead]

Testing. If you share something you've tested and know works, that's way better than sharing a prompt which will generate untested code which then has to be tested. On top of that it seems wasteful to burn inference compute (and $) repeating the same thing when the previous output would be superior anyway.

That said, I do think it would be awesome if including prompts/history in the repos somehow became a thing. Not only would it help people learn and improve, but it would allow tweaking.

To save time and energy?

If I'm understanding the problem correctly, this should be solved by pnpm [1]. It stores packages in a global cache, and hardlinks to the local node_packages. So running install in a new worktree should be instant.

[1]: https://pnpm.io/motivation

And these are things outside of our control.