AI companies are trying way too hard to make us think that we can be the copilot now. 90% of the time (if not more) you definitely need to recode what the model spits to you. Vibe coders with no experience in coding are just creating work for coders that do know what they are doing
The Codex App
461–470 of 671 posts
Re: The Codex App
#462It is baffling how these AI companies, with billions of dollars, cannot build native applications, even with the help of AI. From a UI perspective, these are mostly just chat apps, which are not particularly difficult to code from scratch. Before the usual excuses come about how it is impossible to build a custom UI, consider software that is orders of magnitude more complex, such as raddbg, 10x, Superluminal, Blende…
>This requires calling native APIs (e.g., Win32), which is not feasible from Electron. Who told you that? You can write entire C libraries and call them from Electron just fine. Browser is a native application after all. All this "native applications" debate boils down to the UI implementation strategy. Maintaining three separate UI stacks (WinUI, SwiftUI, GTK/Qt) is dramatically more expensive and slower to iterate…
It baffles me how much the discourse over native apps rarely takes this into consideration.
You reduce development effort by a third, it is ok to debate whether a company so big should invest into a better product anyway but it is pretty clear why they are doing this
Re: The Codex App
#463Earlier quoted context omitted.
There is competition for Figma. Sketch. There's plenty of competition for VSCode too. Don't forget that these Electron apps outcompeted native apps. Figma and VSCode were underdogs to native apps at one point. This is why your supply side argument doesn't make any sense.
> There's plenty of competition for VSCode too. But there isn't, not if you include all the extensions and remember the price
So an Electron app won. Seems like Electron wasn't a hinderance.
Re: The Codex App
#464Earlier quoted context omitted.
> There's plenty of competition for VSCode too. But there isn't, not if you include all the extensions and remember the price
So an Electron app won. Seems like Electron wasn't a hinderance.
Sure, you can ignore that it was a hindrance just like you ignored ignored the previous point.
Re: The Codex App
#465I'm still waiting for the big pivotal moment in this space, I think there is a lot of potential with rethinking an IDE to be Agent first, and lots of what is out there is still lacking. (It's like we all don't know what we don't know, so we are just recycling UX around trying to solve it) I keep coming back to my basic terminal with tmux running multiple sessions. I recently though forked this https://github.com/tian…
There is little to no integration between deterministic IDE features(like refactorings) and LLMs. For example I don't want a statistical tool to rename a method by predicting tokens, I want it to use IDE features and not via another higher abstraction protocol like mpc, I want deeper integration. Sometimes I look at comments in code and think "why can't I have an agent checking if the content of a comment actually re…
Deep integrations are hard and the AI companies are just winging it when it comes to eating their own dog food. Their apps are bare bones, somewhat flaky, and overall not that impressive from a UX point of view.
It's very obvious that while their AI teams are top notch, their product teams are very middle of the road. Including design. Even though they apparently engaged Jony Ive, I can't actually see his 'touch' on anything they have. You'd expect them to have a much higher level of ambition when it comes to their own products. But they seem stuck getting even the basics shipping. I use Chat GPT for Desktop. It's alright but it seems to have stagnated a bit and it has some annoying bugs and flakiness. Random shit seems to break regularly with releases as well.
Another good example of the lack of vision/product management is the #1 and oldest use case for LLMs since day 1: generating text. You'd expect somebody to maybe have come up with the genius idea of "eh, hmm, you know, I wonder if we can do better than pasting blobs of markdown rendered HTML to and/from a word processor from a f**ing sidebar".
Where's the ultimate agentic word processor? The ultimate writing experience? It's not there. Chat GPT is hopelessly clumsy doing even the most basic things in word processors. It can't restructure your document. It can't insert/delete bits of text. It can't use any of the formatting and styling controls. It can't do that in the UI. It can't do that at the file level. It's just not very good at doing anything more than generating bits of text with very basic markdown styling that you might copy paste to your word processor. It won't match the styling you have. Last time I checked Gemini in Google docs it was equally useless. I don't have MS Office but I haven't heard anything that suggests it is better.
For whatever reason, this has not been a priority (bad product management?) or they simply don't have the creativity to see the rather obvious integration issues in front of them.
Yes making those is a lot of work and requires a bit of planning. But wasn't the point of agentic coding that that's now easy? Apparently not.
Re: The Codex App
#466Earlier quoted context omitted.
If you're using 5.2 high, with all due respect, this has to be a skill issue. If you're using 5.2 Codex high — use 5.2 high. gpt-5.2 is slow, yes (ok, keeping it real, it's excruciatingly slow). But it's not the moronic caricature you're saying it is. If you need it to be up to date with your version of a framework, then ask it to use the context7 mcp server. Expecting training data to be up to date is unreasonable f…
Perhaps if he was able to get Claude Code to do what he wanted in less time, and with a better experience, then maybe that's not a skill he (or the rest of us) want to develop.
Sure, that's fine. I wrote my comment for the people who don't get angry at an AI agents after using them for the first time within five hours of their release. For those who aren't interested in portending doom for OpenAI. (I have elaborate setups for Codex/Claude btw, there's no fanboying in this space.)
Some things aren't common sense yet so I'm trying my part to make them so.
Re: The Codex App
#467Earlier quoted context omitted.
So an Electron app won. Seems like Electron wasn't a hinderance.
Sure, you can ignore that it was a hindrance just like you ignored ignored the previous point.
Like how you ignored my point too?
If it was a hindrance, why did it win?
Seems clear to me that Electron's higher RAM usage did not affect adoption. Instead, Electron's ability to write once and ship in any platform is what allowed VSCode to win.
Re: The Codex App
#468It is baffling how these AI companies, with billions of dollars, cannot build native applications, even with the help of AI. From a UI perspective, these are mostly just chat apps, which are not particularly difficult to code from scratch. Before the usual excuses come about how it is impossible to build a custom UI, consider software that is orders of magnitude more complex, such as raddbg, 10x, Superluminal, Blende…
Why would widgets and buttons be better than a console, and or voice?
because not everything can be describe in code, language, or speech. if you're iterating on anything that requires refinement in terms of perception, you may need real time feedback.
Re: The Codex App
#469Earlier quoted context omitted.
>This requires calling native APIs (e.g., Win32), which is not feasible from Electron. Who told you that? You can write entire C libraries and call them from Electron just fine. Browser is a native application after all. All this "native applications" debate boils down to the UI implementation strategy. Maintaining three separate UI stacks (WinUI, SwiftUI, GTK/Qt) is dramatically more expensive and slower to iterate…
It baffles me how much the discourse over native apps rarely takes this into consideration. You reduce development effort by a third, it is ok to debate whether a company so big should invest into a better product anyway but it is pretty clear why they are doing this
There are cross platform GUI toolkits out there so while I am in team web for lots of reasons, generally it’s because web apps are faster and cheaper to iterate.
Re: The Codex App
#470Earlier quoted context omitted.
Sure, you can ignore that it was a hindrance just like you ignored ignored the previous point.
Like how you ignored my point too? If it was a hindrance, why did it win? Seems clear to me that Electron's higher RAM usage did not affect adoption. Instead, Electron's ability to write once and ship in any platform is what allowed VSCode to win.
> Like how you ignored my point too?
No, differently
> If it was a hindrance, why did it win?
Because reality is not as primitive as you portray it to be, you can have hindrances and boosts with the overall positive even winning effect? That shouldn't be that hard!
> Seems clear to me that Electron's higher RAM usage did not affect adoption.
Again, it only seems clear because you ignore all the dirt, including basic things (like here, it's not just ram, is disk use, startup speed, but also like before with competition) and strangely don't consider many factors.
> Instead, Electron's ability to write once and ship in any platform is what allowed VSCode to win.
So nothing to do with it using the most popular web stack, meaning the largest pool of potential contributors to the editor or extensions??? What about other cross platform frameworks that also allowed that??? (and of course it's not any platform, just 3 desktop ones where VSc runs)