i've been through a few hype cycles as well, but this one looks just as big as the invention of the internet, at the very very least (IMHO it's much much more than that).
My way of coping with it is to just go with the flow and learn all the new technics there is to learn, until the machine replaces us all.
random fact : duke nukem had this weird configuration bug where maxing sensitivity on the microsoft sidewinder strafe axis could make you go much faster than possible by moving in diagonal ( the sum of strafe + forward combined to a larger vector). That lead to everyone in our cybercafe buying one :)))
sidenote : are we going to still see new languages appear after AI becomes the one that writes the code ?
I'd say that for a new language to appear in that new world, it would need to offer new compile-time properties that AI could benefit from. Something like expressing general program properties / invariants that the compiler could check and the AI could iterate on.
looking at the feature parity page, i realized how big openclaw ecosystem has become. It's completely crazy for such a young project to be able to interface with so many subsystems so fast.
At this rate, it's going to be simply impossible to catchup in just a few months.
Not my experience too and i'm on claude code. I'd be really curious to see what when wrong in OP case. Maybe too much indication ? Could it be that it used a fast model instead of the deep ones ?
Anyways, I think one area where Codex and Claude Code falls short is that they do not test the changes they made by using the app.
In this case, the LLM should ideally render the page in a real browser, and actually click on the buttons to verify. Best if the LLM test it before the changes, and then after so that it is the same. Maybe it should take a screenshot of before the change, then take a screenshot after. And match.
Yeah, if you have these tools in place to validate it's changes you can quickly iterate with it to the right results. But think through how it's making UI changes and it becomes obvious quickly why it can make absolutely wrong and terrible guesses about the implementation details, it can't _see_ what it's doing, or interact with it, it's just pattern matching other implementations its seen.
Here's a document produced by Claude Code using my Showboat testing tool this morning to help explore SeaweedFS (a local S3 clone) - it includes trying things out with curl and getting screenshots from Chrome using my Rodney tool: https://github.com/simonw/research/blob/main/seaweedfs-testi...
You can easily do this, at least with Claude Code. Ask it to install and use Playwright to confirm rendering and flow. You're correct that it is a failing to not do this. When you do, it definitely helps cut down on bugs.
EDIT: Sorry, just noticed you said "real browser". Haven't tried this but Playwright gets you a long way down the road.
At least in France, the general work legislation is generous enough that people in the industry don't feel the need to unionize. We've got 5 weeks holidays per year, plus additional ones if your work contract has more than 35hours of work per week.
Needless to say, burnouts are pretty rare. When they do, it's mostly because of toxic management which can't fire you because of legislation, so they just make your life miserable until you snap. I've also seen it happen in some startups where people have to take super long holidays after a successful exit because they've worked insane hours. However it was mostly self inflicted.
Whereas french did celebrate US planes bombing nazis on their soil.
reply