LLMs definitely can do this. The output tends to be overly positive though, claiming that any sort of rough draft you give them is "great, almost ready for publishing!". But the feedback you can get on clarity, narrative flow, weak spots... _is_ usually pretty good.
Now, following that feedback to the letter is going to end up with a diluted message and boring voice, so it's up to you to do with the feedback whatever you think best.
I never ask the LLM to evaluate my text in terms of being good or bad. Instead I try something like this:
"In this section I tried to explain X, I intended to sound in Y and Z fashion, and I want a reader to come out with ateast W impression. Is the text achieving these goals? Do I communicate my ideas clearly and consisely, or are they too confuse and meandering?"
I typically get useful feedback. I preface specifically asking it to not rewrite, simply pointing the bits that it finds faulty and explaining why.
Of course the prompt is different is I am writing, for example, technical documentation, or if it is an attempt at creative writing.
I started playing with NixOS recently in a VM and... while I don't have much experience with it yet, it feels _great_ for the many reasons described in the article. I really like configuring a file and knowing that the rest of the system aligns to whatever that file says: no more, no less.
The language is "interesting" and I haven't had to learn it in depth yet. Claude and Codex really make it easier to get started with Nix's weirdness -- but that's unfortunate because I feel I'm not going to learn the "real thing" otherwise. And this difficulty makes me curious about Guix though because, even though I'm not LISP expert either, at least I can read it.
Anyway. I'm just shy to "dig deeper" on NixOS because my servers are FreeBSD and I'm already feeling the temptation to swap them with NixOS, which would feel like a betrayal to these long-lived installations... ;-P
I feel like if you want to learn Nix with some hand-holding, resist the urge to use Claude Code or Codex, but instead just use the chatbot in the browser or something. Ask it questions, explicitly copy and paste in errors as they come up, and manually copy and paste out the generated stuff.
I found that this gives a good compromise of being able to learn Nix relatively well, but still having a "tutor" to help when things get tricky. I'm reasonably ok at Nix now, and can generally figure out what I need to do without AI assistance, but I'm glad I had ChatGPT when I was getting started with it.
> and (partly as a result) it's fairly resource inefficient (often uses 1GB of RAM or more. For a TUI).
That's (one of the reasons) why I'm favoring Codex over Claude Code.
Claude Code is an... Electron app (for a TUI? WTH?) and Codex is Rust. The difference is tangible: the former feels sluggish and does some odd redrawing when the terminal size changes, while the latter definitely feels more snappy to me (leaving aside that GPT's responses also seem more concise). At some point, I had both chewing concurrently on the same machine and same project, and Claude Code was using multiple GBs of RAM and 100% CPU whereas Codex was happy with 80 MB and 6%.
Performance _is_ a feature and I'm afraid the amounts of code AI produces without supervision lead to an amount of bloat we haven't seen before...
I think you’re confusing capital c Claude Code, the desktop Electron app, and lowercase c `claude`, the command line tool with an interactive TUI. They’re both TypeScript under the hood, but the latter is React + Ink rendered into the terminal.
The redraw glitches you’re referring to are actually signs of what I consider to be a pretty major feature, a reason to use `claude` instead of `codex` or `opencode`: `claude` doesn’t use the alternate screen, whereas the other two do. Meaning that it uses the standard screen buffer, meaning that your chat history is in the terminal (or multiplexer) scrollback. I much prefer that, and I totally get why they’ve put so much effort into getting it to work well.
In that context handling SIGWINCH has some issues and trickiness. Well worth the tradeoff, imo.
Codex is using its app server protocol to build a nice client/server separation that I enjoy on top of the predictable Rust performance.
You can run a codex instance on machine A and connect the TUI to it from machine B. The same open source core and protocol is shared between the Codex app, VS Code and Xcode.
I had a nasty slow claude code startup time at one point something like 8s, a clean install sorts it all out. Back up your mcp config and skills and you're good.
That's the same reason I don't like Opencode, but Codex doesn't use the alternate screen. I remember it did when it was very very new, but now it doesn't.
Ah nice, good to know. I hadn’t used codex in a while. I actually really like opencode and its ui, just wish it didn’t clear the screen on exit. It could at least redraw whatever was last in the chat, that would be better than nothing.
I think Go might be a better choice but not for that reason at all.
Go could implement something like this with no dependencies outside the standard library. It would make sense to take on a few, but a comparable Rust project would have at least several dozens.
Also, Go can deliver a single binary that works on every Linux distribution right out of the box. In Rust, its possible but you have to static compile with muslc and that is a far less well-trodden path with some significant differences to the glibc that most Rust libraries have been tested with.
My personal opinion is that I like Rust much more than Go, but I can’t deny that Rust is a big, and more dauntingly to newcomers, pretty unopinionated language compared to Go.
There are more syntax features, more and more complex semantics, and while rustc and clippy do a great job of explaining like 90% of errors, the remaining 10% suuuuuck.
There’s also some choices imposed by the build system (like cargo allowing multiple versions of the same dep in a workspace) and by the macro system (axum has some unintuitive extractor ordering needs that you won’t find unless you know to look for them), and those things and the hurdles they present become intuitive after a time but just while getting started? Oof
LLMs should know that, for maybe a CRUD app, there should be taken care of security at various layers, i.e. input validation in controllers. Knowledge from popular frameworks that communicate security boundaries should be transferable for them, even if everything is custom code. Very confusing to me how they manage to completely ignore so much of it. I guess they are too good following suit of a productivity minded vibe coder.
Frankly I don't think one even needs to learn it, if you know a bunch of other languages and the codebase is good. I was able to just make a useful change to an open source project by just doing it, without having written any lines of Go before. Granted the MR needed some revisions.
Rust is my favorite, though. There are values beyond ease of contribution. I can't replicate the experience with a Rust project anymore, but I suspect it would have been tougher.
agents don't really care and they're doing anywhere between 90-100% of the work on CC. if anything, rust is better as it has more built-in verification out of the box.
Rust is accessible to everyone now that Claude Code and Opus can emit it at a high proficiency level.
Rust is designed so the error handling is ergonomic and fits into the flow of the language and the type system. Rust code will be lower defect rate by default.
Plus it's faster and doesn't have a GC.
You can use Rust now even if you don't know the language. It's the best way to start learning Rust.
The learning curve is not as bad as people say. It's really gentle.
Java (incl. Scala, Closure, Groovy, Jython, etc.) is better suited to running as a server. Let agents write clean readable code and leave performance concerns to the JIT compiler. If you really want you can let agents rewrite components at runtime without losing context.
Erlang would offer similar benefits, because what we're doing with these things is more message passing than processing.
Rust is what I'd want agents writing for edge devices, things I don't want to have to monitor. Granted, our devices are edge devices to Anthropic, but they're more tightly coupled to their services.
There is literally no reason to write it in a JVM language in 2026 when better options exists. Either Go for simplicity and maintaininability or Rust to get the most out of the machine works.
Also, it'll be hard for them to lure good people to work on that thing. Absolutely no one is getting excited to write, vibe, or maintain Java.
I am not thrilled to use java, but it really does what it says on the tin. A customer copied the jar file I sent them to their as400 and it just worked. There is nothing quite like it.
Hi go binary, unfortunately you don't exist, because there is no cross compiler for that platform. Also please don't crash if you ever do get cross compiled, since the target system doesn't understand your utf8 strings.
I run many instances of Claude Code simultaneously and have not experienced what you are seeing. It sounds like you have a bias of Rust over Typescript.
No, they are describing a typical experience with the two apps. Just open both apps, run a few queries, and take a look at the difference in resource management yourself. It sounds like you have a bias of Claude Code over Codex.
Uh, it sounds like you're having trouble understanding that people in this thread are talking about two wildly different "claude code" applications. Those who are claiming the resources issues don't apply to them are referring to the cli application, ie: `claude` and those are saying things like "Just open both apps..." are surely referring to their GUI versions.
No, I've never used the GUI version. I literally just had to close and reopen the terminal running the Claude Code CLI on my Mac yesterday because it was taking too many resources. It generally happens when I ask Claude to use multiple sub agents. It's an obvious memory leak.
Somebody blamed this comment on LLMs, and maybe/probably it is, but I think the first sentence is spot-on so I thought it was worth replying to.
Dealing with the corner cases ends up teaching you a lot about a language and for an ancient language like the shell, dealing with the corner cases also takes you through the thinking process of the original authors and the constraints they were subject to. I found myself in this situation while writing EndBASIC and wrote an article with the surprises I encountered, because I found the journey fascinating: https://www.endbasic.dev/2023/01/endbasic-parsing-difficulti...
> I delayed upgrading to 15.0 after it was released, but last weekend I finally did it, and it left me wondering why I hadn't done it sooner, because it went quickly and smoothly.
I haven't done that yet because I think I'd want to switch to pkgbase but that makes me nervous. Did you go with that option or continued to use the sets?
Why not create a boot environment and try out FreeBSD 15 with pkgbase ? If the experiment is successful just make the boot environment the default otherwise throw it away...
With such powerful tools I find it fascinating that FreeBSD users are not more willing to experiment !
I haven't switched to pkgbase. Yet. I don't intend to for the time being. I set up a VM to test it, but I haven't gotten around to actually testing it.
But excited to try it out ASAP! I haven’t made the leap to 15 on my server yet (in part because I can’t decide whether to go with pkgbase or not…), but sharing data more easily with VMs will surely be nice.
> in part because I can’t decide whether to go with pkgbase or not…
pkgbase is optional in FreeBSD 15 BTW.
One way to upgrade the base system and another to upgrade packages just feels inconsistent to me and pkgbase finally resolves that. I've not had any problems with pkgbase. I love it and would highly recommend it.
If we have been complaining about bloat before, the amount of bloat we are going to witness in the future is unfathomable. How can anyone be proud of a claim like "It's 3M+ lines of code across thousands of files." _especially_ when a lot of this code is relying on external dependencies? Less code is almost always better, not more!
I'm also getting really tired of claims like "we are X% more productive with AI now!" (that I'm hearing day in and out at work and LinkedIn of course). Didn't we, as an industry, agree that we _didn't_ know how to measure productivity? Why is everyone believing all of these sudden metrics that try to claim otherwise?
Look, I'm not against AI. I'm finding it quite valuable for certain scenarios -- but in a constrained environment and with very clear guidance. Letting it loose with coding is not one of them, and the hype is dangerous by how much it's being believed.
I mostly agree with you but I AM super productive with AI. I'm working on a side-project and have built in 2-3 months what my quite productive team of 3-4 people would take 4-6 months to build in 2016. And I'm not talking to generative slop but real production grade code that I have reviewed+approved or manually refactored before merging. Like you I'm not impressed by these toy projects but the productivity gain is very real. At least has been for me.
I don't disregard what you are saying and believe that being more productive with sufficient quality is _possible_.
But how do you measure it? All the metrics I see being chased (metrics that were never accepted as productivity measurements before) can be gamed with slop, and so slop is what we'll get.
I’ve eyerolled way less with Codex CLI and the GPT models than with Claude.
reply