We don't see any indication that the LLM companies are slowing down and go for better code.
Instead it just looks like a cash grab until the AI bubble bursts.
And so many more. I tried codex and it was lacking in many UX aspects. Remember we got from a text-paragraph-only terminal to this at breakneck speed.
And they can't seem to go two whole months without scrolling breaking in some new way.
Eg - I asked for a recipe and it says leave x for y time - there's actually deeplinks that link to your clock timer with the time preset! And to change quantities, there's input boxes in the response that update all quantities accordingly.
Many such cases of use-case specific UX
I’m in the process of dumping codex for more open harnesses that don’t add problematic new features every week. Because Anthropic insists that I have to use their harness with the subscription, eventually I’m either going to wrap `claude -p` to get away from the crappy TUI or else I’ll just unsubscribe and use other models. Their bad UX has alienated me as a paying customer.
Listed a few in my other comment
Like of course codex is the most powerful and "just" run `npx blah blah` but no, I'm not running randomly piped code on my personal computer and even if I didn't care about privacy it means I can only run this locally with my laptop on. "leave your laptop on and access from your phone" is not a good idea. It only adds to the surface area of confusion. Ux no good.
Went too far? Oops, it's not accessible from the Claude Code UI anymore! You can get the agent to dredge up the info from the session logs, but you'd better hope they put the pieces together correctly.
Also, you can't rewind to a steering message. Want to make sure you can rewind to it? Wait for the agent to settle, or stop them, enter your message, and hope you don't throw them off their current train of thought.
To see a proper rewind UI, see how Pi does it: Every message is available, forked conversation history is preserved. It has its own issues, but is miles ahead of Claude Code in this regard.
https://finance.yahoo.com/sectors/healthcare/articles/godfat...
Progress is spiky and not guaranteed. The capital costs have also ballooned to the point where the rate has to level out
That's a pretty bold use of "has to". None of the financing behind AI seems sane, yet it continues to defy rational expectations. Reminds me of the comment "the market can remain irrational longer than you can stay solvent". It's not the exact meaning but has the same feeling. The circular financing going on does not help anything either
I think that's exactly the standpoint of Yann LeCun.
I think newer models are more likely to produce the usuable output, almost always, but its still not great. The frequency in which you get usable results leads one to believe that quality is improving.. No usability is improving but the result is still meh.
Also put an llm in an environment without an lsp or compiler to check against and let me know how capable you think they are on their own. The "loop" is doing a lot of heavy lifting here.
This is partly due to the multiplicative scaling factor -- the number of tokens; the number of transformer layers; the number of features; etc.
I suspect that for models to have a step upgrade either/both of 1) a new/improved architecture model; and 2) better training of smaller parameter models are needed. I say the latter as I think that with the larger weights there is a lot of unused/redundant parameters.
in the last 2 weeks or so: - scrolling stopped working - subagents no longer work (main agent doesn't get notified when they finish) - subagents don't work (a subagent can't make its own agent even if instructed to do so)
what's going on? I thought coding was solved?
That is exactly why it is so bad. Tokens spent generate code. Large amounts of code is a liability.
I use nixos and use a little wrapper that wraps Codex CLI in Docker. Run codex-box /path/to/project and it starts or reuses a container with only that project bind-mounted, keeping login and history in a separate volume. It uses tmux for detaching and reattaching
https://gist.github.com/entropie/8f30b9e33e9412fda3adf2f7507...
But I am not satisfied. I am trying to find a really lightweight container/VM for macOS that eats very less RAM on its own and expands as needed. Because I really don't want to run an agent outside a container on my mac.
Maybe thats just the tool nerd in me that just wants the perfect tool for every job.
The thing that really validated this point was when I recently tried Codex again. Out of the box it was OK, but not great. I swung over the memory apparatus and had it import directives from my existing Claude install and it was almost immediately quite useful in its own right and, especially, as a counterpoint to Claude when dealing with some fairly complex operational issues.
This blogpost describes a similar thing: https://bxt.rs/blog/easy-sandboxing-on-linux-with-bubblewrap...
Maybe it's like online services/tools. Use them until they are VCed and gone pivoting and then move to another tool.
But maybe being able to code up a feature at the drop of a hat has turbo-charged their ability to make bad UX decisions.
The latter requires modifying existing, badly architectured and tightly coupled code that will almost definitely break something somewhere else if touched, so what do you do? Just keep adding new code on top and hope for the best.
This is not a new phenomenon by any means, but AI amplifies it by 100x.
You install an update. Oops, they added a sandbox that doesn't work inside a docker container, it's stopped working.
You install an update. Oops, you can't log in inside a docker container any more, it's stopped working.
You install an update. Oops, they started catching the copy+paste shortcut and replaced it with one that doesn't work.
You revert a broken update. Oops, the update changed the format of your login details, the old version can't read them, gotta log in again.
You install an update. Oops, can't scroll with the mouse wheel any more.
Not showstopping bugs (if you're used to persuading broken oauth logins to work) but it certainly makes updating an "ugh, what have they broken this time?" experience.
The problem is hardly anyone gives a shit if they can pump out stuff that makes them look like they are good at stuff.
Vanity before engineering.
One goes to Github and one notices, the dev is done by LLMs, issue triage is done by bots, and the commenting is done by the bots. (btw, the triage mostly means closing them or playing the "this is dupe of that" game while noone gives a flying fuck about any of the issues). Another good one is "not planned". You report a breaking/critical change and "not planned". What demorlised me is attitude of OpenCode devs/maintainers. I think the Open in it more of the "Open" in OpenAI than in FOSS. That's when I started reducing my dependency on this harness whihc was slowly becoming my pretty much full time harness.
Claude Code turned on the remote-control server by default with an update (no explanation or notification). BUT Claude Code didn't break the expectation that the hooks and the commands you run inherit your environment. So it was hard to notice.
Whereas when Codex App server became enabled by default, and as per OpenAI, it was never contractual that hooks run in the client's environment. Sure, let's break long-standing expectations of where code runs when you run a CLI--it was never contractual, you see. Now you have to figure out how to turn this crap off, just to UNBREAK your workflow!
This is why it's apples and oranges here, with Claude Code and Codex.
That's why I didn't mind it when Pi added native MCP capabilities. What dismayed me was they didn't other tools like subagents, and other stuff. I mean why do I have to scour the Interwebs to find something that doesn't possibly screw everything up for me.
I have a feeling harness usage will finally move to lots of harnesses with usage clusters - as in not X million harness for X million devs/users but a lot and people will use what suits them, and if not a more inclined coder will fork/make one just for them. In all their faults LLMs have made this a possibility.
We were overbuilding trivial parts of the software like the Romans overbuilt small bridges.
Modern engineering is about making the thing that barely works. If you disagree, learn a little bit about bit narrow the tolerances of modern cars and bridges are.
> [...] vs something that's rickety
A 100 percent of modern bridges are rickety. There has been dozens of high profile incidents because of this.
> Just because you built something that might fall apart at any moment doesn't mean it's been engineered with narrow tolerances.
Here the software they are building falls apart in ..say.. two days of use, but can be updated in 5 seconds at close to zero marginal cost. The software is useful enough that people keep updating and using it. This iteration gives them a competitive advantage over the safer choice of rigorously testing every new thing for several weeks.
Buildings typically use a safety factor of 1.5 to 2.0, and cars typically use a safety factor of 2.0 to 3.0. These things are being built twice as strong as they need to be. I wouldn't call that narrow.
And with software, we're at a point where it can't even properly do what it needs to. If we were overbuilding it, damn software wouldn't crash so much.
Not even close.
For example, a BMW X5 weighs about 2200 Kgs without passengers, and it's GVWR is 2800 Kgs.
If you have five people and heavy bags, you can comfortably exceed the GVWR. You can absolutely break control arms and suspension components in that scenario if you go over a speed bump or hit a pothole (which are real things that exist in the real world, like people doing something unintended and crashing software).
If this needed a 2x safety factor, there would have been no way to build this car.
Even the toughest cars like land cruisers are limited in this way.
The same story for Google's products - their products were always buggy even before AI. And so is the case for Microsoft.
I think the reasonable argument is that AI or not, software problems are hard problems to solve. And software is constantly evolving. AI isn't a magic wand. It also depends a lot on the humans using it, including prompting and context supplied to it.
Drawing a massive conclusion from a tiny, unrepresentative sample is just hasty generalization.
Given how rare it was previously, and how little it was cultivated by shortsighted management, I’m not surprised with all the slop we see today.
The truth is there’s nothing stopping someone from using these tools to remove dead code, simplify project structure, remove dependencies, etc. but I don’t see it happening very often. I have done it a bunch myself though so it’s absolutely possible, it’s all a matter of investment and prioritization.
it's embarrassing when every claude code release has obvious bugs in it like telling you to upgrade when you're on the latest version or codex opening visible powershell windows for every command that pop up on your screen
like 5 minutes of human testing would catch this obvious shit but obviously they don't bother because vibes are the future and stuff? idk
Legit bugs still open 6 months on.. It's a bit ironic