It has now been a month since I started playing with Claude Code “for real” and by now I’ve mostly switched to Codex CLI: it is much snappier—who would imagine that a “Rewrite in Rust” would make things tangibly faster—and the answers feel more to-the-point than Claude’s to me.
The bit about not setting up an end-to-end feedback cycle is the thing I keep running into too. When you skip that step, the agent one-shots stuff that looks right but breaks in subtle ways.
Codex CLI just got lifecycle hooks (still behind a feature flag) that help with exactly this. SessionStart can validate your environment and deps before the agent starts, and Stop can run your test suite after it's done. So even if you don't look at the code, you at least know it passes. Wrote up the full config here https://reading.sh/codex-cli-has-hooks-now-stop-stuffing-agents-md-c181465fe271
Also related to your point about the Rust rewrite making Codex snappier. I'm finding the same thing. The difference is noticeable enough that I'm using it as my daily driver now.
FWIW, you might enjoy reading the ELisp "Introduction to Programming in Emacs Lisp" and/or "ELisp Reference" manuals, as they are very much in the spirit of empowering users — including complete beginners — to get more out of their computer, not unlike what you're trying to revive with EndBASIC. But you probably knew that.
Peeking at ticket.el code a bit, it's not bad code though yes some duplication.
The deepest difference from idiomatic Emacs wrappers seems to be it jumps to programmatic parsing too early. E.g. `ticket--list-tickets' runs the CLI populating a temp buffer, parses the buffer and discards it — and there are several more functions like this. A more Emacs-ish approach, closer to say Dired or Magit is to keep the buffer, activate a mode (`ticket-browser-mode'?), and defer parsing to mode's commands. E.g. sorting/filtering could actually reorder/fold text in the buffer, not just return a data structure used for rendering new text.
P.S. peeking at tk's source a bit, it's not pure Bash either - there is a lot of AWK parsing into hashes, sorting etc. to implement things like `dep tree`...
(I'm still AI-shy and undecided, so not implying your use of AI is "wrong" in any way. Rapid prototyping is cool.)
Yeah it's almost pointless to tell the robot to refactor to reduce code duplication, too. The abstractions they'll come up with are inevitably deranged and don't generalize well (e.g. a bunch of one-off "helper functions" that just move the mess elsewhere without reducing LOC or being meaningfully generic, sometimes even more bloated because they'll fill it up with "if use case A else if use case B...)
In the end you'll have to clean it up yourself, which cuts deep into the supposed time savings.
They seem fine for throwaway prototypes and one-off utilities, and I get a lot of use out of them in that capacity. But the technical debt they produce is comedic at best.
> In the end you'll have to clean it up yourself, which cuts deep into the supposed time savings.
Yes, but you can tell the robot to do the cleanups too! It takes deep thinking on your part to know how to structure the code (just as it did before, but it's something I did _not_ do in this project). If you state that, the agent seems to do a good job at applying the cleanup/simplification.
It does, sort of, but I typically end up doing some of it myself. And you have to remember that deep thinking and careful specifying is a non-negligible timesink.
The bit about not setting up an end-to-end feedback cycle is the thing I keep running into too. When you skip that step, the agent one-shots stuff that looks right but breaks in subtle ways.
Codex CLI just got lifecycle hooks (still behind a feature flag) that help with exactly this. SessionStart can validate your environment and deps before the agent starts, and Stop can run your test suite after it's done. So even if you don't look at the code, you at least know it passes. Wrote up the full config here https://reading.sh/codex-cli-has-hooks-now-stop-stuffing-agents-md-c181465fe271
Also related to your point about the Rust rewrite making Codex snappier. I'm finding the same thing. The difference is noticeable enough that I'm using it as my daily driver now.
FWIW, you might enjoy reading the ELisp "Introduction to Programming in Emacs Lisp" and/or "ELisp Reference" manuals, as they are very much in the spirit of empowering users — including complete beginners — to get more out of their computer, not unlike what you're trying to revive with EndBASIC. But you probably knew that.
Peeking at ticket.el code a bit, it's not bad code though yes some duplication.
The deepest difference from idiomatic Emacs wrappers seems to be it jumps to programmatic parsing too early. E.g. `ticket--list-tickets' runs the CLI populating a temp buffer, parses the buffer and discards it — and there are several more functions like this. A more Emacs-ish approach, closer to say Dired or Magit is to keep the buffer, activate a mode (`ticket-browser-mode'?), and defer parsing to mode's commands. E.g. sorting/filtering could actually reorder/fold text in the buffer, not just return a data structure used for rendering new text.
P.S. peeking at tk's source a bit, it's not pure Bash either - there is a lot of AWK parsing into hashes, sorting etc. to implement things like `dep tree`...
(I'm still AI-shy and undecided, so not implying your use of AI is "wrong" in any way. Rapid prototyping is cool.)
Yeah it's almost pointless to tell the robot to refactor to reduce code duplication, too. The abstractions they'll come up with are inevitably deranged and don't generalize well (e.g. a bunch of one-off "helper functions" that just move the mess elsewhere without reducing LOC or being meaningfully generic, sometimes even more bloated because they'll fill it up with "if use case A else if use case B...)
In the end you'll have to clean it up yourself, which cuts deep into the supposed time savings.
They seem fine for throwaway prototypes and one-off utilities, and I get a lot of use out of them in that capacity. But the technical debt they produce is comedic at best.
> In the end you'll have to clean it up yourself, which cuts deep into the supposed time savings.
Yes, but you can tell the robot to do the cleanups too! It takes deep thinking on your part to know how to structure the code (just as it did before, but it's something I did _not_ do in this project). If you state that, the agent seems to do a good job at applying the cleanup/simplification.
It does, sort of, but I typically end up doing some of it myself. And you have to remember that deep thinking and careful specifying is a non-negligible timesink.