upvote
Tig is a nice and long-maintained git tui you might enjoy, then!

If nothing else maybe for inspiration

reply
how do you trust the code claude wrote? don't you get anxiety "what if there's an error in tui code and it would mess up my git repo"?
reply
I don’t even trust myself to not mess up my git repo
reply
I'm not GP, but I have backups, plus I always make sure I've committed and pushed all code I care about to the remote. I do this even when running a prompt in an agent. That goes for running most things actually, not just CC. If claude code runs a git push -f then that could really hurt, but I have enough confidence from working with the agents that they aren't going to do that that it's worth it to me to take the risk in exchange for the convenience of using the agent.
reply
> how do you trust the code claude wrote?

If that's something you're worried about, review the code before running it.

> don't you get anxiety "what if there's an error in tui code and it would mess up my git repo"?

I think you might want to not run untrusted programs in an environment like that, alternatively find a way of start being able to trust the program. Either approaches work, and works best depending on what you're trying to do.

reply
> If that's something you're worried about, review the code before running it.

It takes more, not less, time to thoroughly review code you didn't write.

reply
Depends. If I was the one coming up with the implementation anyways, it's basically just the "coding" part that was replaced with "fingers hitting keyboard" and "agents writing to disk", so reviewing the code certainly is faster, you just have to "check" it, not understand it from scratch.

If we're talking receiving random patches where first you have to understand the context, background and so on, then yeah I agree, it'll take longer time probably than what it took for someone to hammer with their fingers. But again, I'm not sure that's how professionals use LLMs right now, vibe-coding is a small hyped world mostly non-programmers seem to engage in.

reply
> you just have to "check" it, not understand it from scratch.

How can you "check" that which you don't "understand"?

> I'm not sure that's how professionals use LLMs right now

I'm a professional and I can tell you how I use LLMs: I write code with their assistance, they don't write code for me.

The few times I let Claude or Copilot loose, the results were heartbreaking and I spent more time reviewing (and then discarding) the code than what it took me to later write it from scratch.

reply
> How can you "check" that which you don't "understand"?

??? I do understand, since I literally just instructed it, how would I otherwise? I'm not letting the LLM do the design, it's all me still. So the "understand" already exists before the LLM even finished working.

> I'm a professional and I can tell you how I use LLMs: I write code with their assistance, they don't write code for me.

Hey, welcome to the club, me too :) I don't write code, I write English prose, yet nothing is vibe coded, and probably I'll end up being able to spend more time than you thinking about the design and architecture and how it fits in, because actual typing is no longer slowing me down. Yet again, every line is reviewed multiple times.

It's more about the person behind the tools, than the tools themselves I think ultimately. Except for Copilot probably, the times I've tried it I've just not been able to produce code that is even slightly up to my standards. It's a breeze with Codex though (5.2), and kind of hit and miss with Claude Code.

reply
I push my branches daily, so I wouldn't lose that much work. If it breaks then I ask it to fix it.

But I do quickly check the output what it does, and especially the commands it runs. Sometimes it throws all code in a single file, so I ask for 'good architecture with abstractions'.

reply
I see this regularly: "I use GitHub to backup my local repos."

If `gh repo ...` commands get run you can lose everything instantly. You can force push and be left with a single blank commit on both sides. The agent has full control of everything, not just your local data.

Just set up Rclone/restic and get your stuff into a system with some immutability.

reply
Force pushing doesn't actually remove anything from the remote repository, only changes some references for which commits the branches point to. Plus, any forks on github will be completely unaffected. It's not perfect, since Github doesn't seem to offer any history of such reference alterations (a la the reflog), but it's still a valuable offsite backup from a developer's perspective.
reply
Okay, fair enough re force pushing (though `gh repo delete` is still an option). I suppose for a sufficiently active codebase copies of it will exist elsewhere. Just seems odd to me that people aren't backing up anything else on their computers otherwise they could trivially just include their git-based projects.
reply
Isn't it this case no matter who wrote the code? How do you ever run anything if you're worried about bugs?
reply
When I write the code myself, I'm not worried that I snuck a `git reset --hard` somewhere.
reply
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)

reply
It makes a difference whether an AI or a human wrote it. AIs make more random, inconsistent errors or omissions that a human wouldn’t make. AIs also don’t dog-feed their code the way human developers of tools usually do, catching more errors or unfit/missing logic that way.
reply
I assume that whatever I type can be also flawed and take precautions like backups etc
reply
It's a git repo. What's sort of mess-ups are you worried about that you can't reflog your way out of (or ask claude code to fix)? It's certainly possible to lose uncommitted work, but once it's been committed, unless claude code goes and deletes .git entirely (which I've had codex do, so you'd better push it somewhere), you can't lose work.
reply
Can you explain TUI? I have never heard this before
reply
Terminal User Interface, contrasting with a Graphical User Interface (GUI). Most often applied to programs that use the terminal as a pseudo-graphical canvas that they draw on with characters to provide an interactive page that can be navigated around with the keyboard.

Really, they're just a GUI drawn with Unicode instead of drawing primitives.

Like many restrictions, limiting oneself to just a fixed grid of colored Unicode characters for drawing lends itself to more creative solutions to problems. Some people prefer such UIs, some people don't.

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

reply
That’s an excellent way to explain it. I’m already in the shell doing stuff. Whenever I can stay there without sacrificing usability, it’s a big boost.
reply
"It's not about saving time, it's about eliminating the mental toll from having to context switch"

This broke my brain! Woah!

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

reply
Eg: lazygit https://github.com/jesseduffield/lazygit?tab=readme-ov-file#... https://github.com/sxyazi/yazi https://github.com/darrenburns/posting or I guess Vim would be a prominent example.

Peoples definitions will be on a gradient, but its somewhere between CLI (type into a terminal to use) and GUI (use your mouse in a windowing system), TUI runs in your terminal like a CLI but probably supports "graphical widgets" like buttons, bars, hotkeys, panes, etc.

reply
So the acronym is for Terrible User Interface? ;)
reply
TUI is peak UI, anyone who disagrees just don't get it. Every program listens to the same keybindings, looks the same and are composable to work together. You don't get that clicking buttons with the mouse. It's built to get the work done not look pretty.
reply
No it's not.
reply
Terminal UI.
reply
It's definitely an acronym that got popular in the last year or so, though I'm sure there are people out there who will pretend otherwise. I've been in the industry 15+ years now and never heard it before. Previously it was just UI, GUI, or CLI.
reply
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.
reply
My friends and I have been actively in the "CLI/TUI" since middle school. Anyone tinkering on linux that used tiling window managers is already very familiar with the domain.
reply
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

reply
[flagged]
reply
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.

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

reply
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.
reply
Exactly. A CLI is a single line - like edlin. A TUI takes over all or most of the screen, like edit or vi or emacs.

Norton Commander (or Midnight Commander) is probably the quintessential example of a powerful TUI; it can do things that would be quite hard to replicate as easily in a CLI.

reply
We might've been caught on different parts of the wave. I checked Ngrams out of curiosity

https://books.google.com/ngrams/graph?content=TUI&year_start...

Basically it was never used, then it was heavily used, and then never used, and then in the early 00s it took off again.

That'd explain why you used it, I never did, and now young kids are.

reply
Thanks for looking that up! It makes sense, of course - the line starts to drop in 1984, with the release of the Macintosh, and hits a trough around the launch of Windows 95.

It's not a term I recall hearing at all when I started using computers in the mid-'80s - all that mattered back then was "shiny new GUI, or the clunky old thing?" I really thought it was a retroneologism when I first heard it, maybe twenty years ago.

reply
I don't think that search is very valid - the TUI group travel companies are likely much more mentioned than Terminal User Interface. They are pretty big around the world and have an airline, cruises, hotels etc.
reply
In the case of Git, I can warmly recommend Magit as a TUI. Not only does it make frequent operations easier and rare operations doable -- it also teaches you Git!

I have a draft here about one aspect of Magit I enjoy: https://entropicthoughts.com/rebasing-in-magit

reply
The amount of little tools I'm creating for myself is incredible, 4.6 seems like it can properly one/two shot it now without my attention.

Did you open source that one? I was thinking of this exact same thing but wanted to think a little about how to share deps, i.e. if I do quick worktree to try a branch I don't wanna npm i that takes forever.

Also, if you share it with me, there's obviously no expectations, even it's a half backed vibecoded mess.

reply
This is how I solve the dependencies with Nix: https://gist.github.com/whazor/bca8b687e26081e77d818bc26033c...

Nix helps Claude a lot with dependencies, it can add stuff and execute the flake as well.

I will come back to you with project itself.

reply
I’ve been wanting similar but have instead been focused on GUI. My #1 issue with TUI is that I’ve never liked code jumps very smooth high fps fast scrolling. Between that and terminal lacking variable font sizes, I’d vastly prefer TUIs, but I just struggle to get over those two issues.

I’ve been entirely terminal based for 20 years now and those issues have just worn me down. Yet I still love terminal for its simplicity. Rock and a hard place I guess.

reply
What's the point of open sourcing something you one shot with an LLM? At that point just open source the prompt you used to generate it.
reply
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.

reply
To save time and energy?
reply
The deps question is huge, let me know if you solve it.
reply
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

reply
What are some examples of useful TUI you made? I'm generally opposed to the concept
reply
That sounds like a complete waste of time and tokens to me, what is the benefit? So each time you do something, you let Claude one shot a tui? This seems like a waste of compute and your time
reply
They said each time they want something to be easier, not each time they do something. And they didn’t mention it has to be one-shot. You might have read too quickly and you’ve responded to something that didn’t actually exist.
reply
On the contrary. Once these tools exist they exist forever, independently of Claude or a Claude Code subscription. IMO this is the best way to use AI for personal use.
reply
Now that I think about it, if Claude can put most useful functions in a TUI and make them discoverable (show them in a list), than this could be better than asking for one-liners (and forgetting them) every single time.

Maybe I'll try using small TUI too.

reply
yeah! they should focus on more productive pursuits, like telling people online what to do with their time and resources.
reply
And these are things outside of our control.
reply