If nothing else maybe for inspiration
WTF has happened to software development, that anyone thinks they need "AI" for that? Any self-respecting half-way decent IDE has had parameterized templates for that since at least the mid-1990s. (They used to be called "Wizards" on Windows, or "Experts" in the Borland tools.)
Select "File", "New", "[Whatever]", answer a few questions in a (series of) dialog(s), click "Finish", and hey presto!, you had a new project, templated according to your preferences, with the UI scaffolding all finished. (Mostly GUI, of course, since that was the hot new thing back then; but could just as easily have been TUI, and I suppose some had that too.)
All done locally on your stonking new 486 266 Mhz / 16 MB. No need to burn half the planet to run some LLM "in the cloud", i.e. on someone else's machine in a datacenter somewhere. Jeebus fuck, does one have to be labelled "old curmudgeon" just for thinking there's something seriously wrong going on here nowadays?
When I use AI to write code, I have absolutely no guarantee about what it just did, so I have to read through it all carefully.
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)
Ahem... But yeah, then I -- or we, I and my team at the time -- (somewhat, at least rudimentarily) learned git.
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.
It takes more, not less, time to thoroughly review code you didn't write.
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.
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.
??? 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.
If the input is English prose, how is it not "vibe coded"?
Nope, it takes way less. Else PR reviews would take as long as coding, which they obviously don't.
Writing 1000 lines, figuring out the nuances of the domain, fixing bugs, testing, takes way more time that reading and reviewing the resulting code.
Besides, you can even ask another agent to review it. Different brand of agent even.
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'.
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.
I have a draft here about one aspect of Magit I enjoy: https://entropicthoughts.com/rebasing-in-magit
Makes more sense, too: Although you run TUI apps in it, the terminal itself is inherently more of a CLI than a TUI. Makes "terminal" rather misleading, IMO.
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.
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)
This broke my brain! Woah!
Or mouse / trackpad.
I really haven't seen anything better for making TUIs than Borland's Turbo Vision framework from 35ish years ago.
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.
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
Here's a blog post from 2014 [1] mentioning it.
Sometimes, we're the one in today's 10000, sometimes it's someone else [2]
[1] https://khanifnasrudin.blogspot.com/2014/11/text-based-user-... [2] https://xkcd.com/1053/
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.
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.
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.
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.
Maybe I'll try using small TUI too.