Live data from Hacker News

The Codex App

openai.com

541–550 of 671 posts

Re: The Codex App

#541

Earlier quoted context omitted.

Also interesting that they are both only for macOS. I’m feeling a bit left out on the Windows and Linux side, but this seems like an ongoing trend.

I'm so sick and tired of the macOS elitism in the AI/LLM world.

It's just realism.

MacOS is unix under the hood so the models can just use bash and cli tools easily instead of dealing with WSL or Powershell.

MacOS has built-in sandboxing at a better level than Windows (afaik the Codex App is delayed for Windows due to sandboxing complexities)

Also the vast majority of devs use MacBooks unless they work for Microsoft or are in a company where the vast majority of employees are locked to Windows for some reason (usually software related).

Re: The Codex App

#542

Earlier quoted context omitted.

I guess it shows how geriatric I am with desktop app development these days, but does no one use Qt anymore? Wasn't the dream for that to be a portable and native platform to write GUI apps? Presumably that could abstract away which bullshit Microsoft framework they came out with this week. I haven't touched desktop application programming in a very long time and I have no desire to ever do so again after trying to l…

And GTK4 is even very usable from Rust too. It’s not a bad development experience, but these companies probably find 100 webdevs for every system programmer.

Come on GUI apps are not systems programming, what's with this title inflation.

Re: The Codex App

#543
post #451

Earlier 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…

React Native is able to build abstractions on top of both Android and iOS that uses native UI. Microsoft even have a package for doing a "React Native" for Windows: https://github.com/microsoft/react-native-windows It's weird that we don't have a unified "React Native Desktop" that would build upon the react-native-windows package and add similar backends for MacOS and Linux. That way we could be building native apps…

React Native desktop on Linux isn't a thing, the GTK backend is abandonned.

So if you want a multiplatform desktop app also supporting Linux, React Native isn't going to cut it.

Re: The Codex App

#544
post #321

Somewhat underwhelmed. I consider agents to be a sidetrack. The key insight from the Recursive Language Models paper is that requirements, implementation plans, and other types of core information should not be part of context but exist as immutable objects that can be referenced as a source of truth. In practice this just means creating an .md file per stage (spec, analysis, implementation plan, implementation summa…

An idea just came into my mind. What if an agent could spawn other agents and provide them with immutable resource files and a 'chrooted' mutable directory those spawned agents could use recursively to prepare immutable resources for other recursively called sub-agents. The immutability and chrooting could be enforced by the harness.

Re: The Codex App

#545

It 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…

It is not that easy to build such app from scratch ... it all requires a lot of work, even with AI help. I think the most important is to provide easy to use UI first, and if speed or some missing features will be blockers for further innovation step then maybe native app will be at some point created.

Re: The Codex App

#546
post #496

Earlier quoted context omitted.

The gap here is that the company has the money and native apps are so clearly better. With an interactive app a company like OpenAI could really tweak the experience for Android and iOS which have different UX philosophies and featuresets in order to give the best experience possible. It's really a no brainer imho.

> the company has the money It's not about money. It's not a tradeoff in cost vs quality - it's a tradeoff in development speed. Shipping N separate native versions requires more development time for any given change: you must implement everything (at least every UI) N times, which drastically increases the design & planning & coordination required vs just building and shipping one implementation. Do you want to move…

So, this certainly was a valid argument. But it seems to me that the whole value proposition behind these agentic AI coding tools is to be able to move beyond this. Are we very far from being able to define some Figmas and technical specs and have Codex generate the UIs in 5 different stacks? If that isn't a reality in the near future, then why should we buy AI Tools?

Re: The Codex App

#547
I'm sorry, but the music on the demo video is the most atrocious nonsense. I know it's crazy, but it makes me hate the app. openAI is falling off hard.

Re: The Codex App

#548
post #453

It 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…

Devex tooling is so much better in web, you can ship much faster, and speed to market matters more than making a native app. Apple dev tooling and build speed sucks a ton in comparison, and don't get started with windows

This is the reason. When an app changes so often, across different platforms, you don't want to support people lagging behind on old versions.

I'm not saying native is better or worse, but this will be why.

Re: The Codex App

#549
post #284

People's mileage may vary, but in my instance, this was so bad that I actually got angry while trying to use it. It's slow and stupid. It does not do proper research. It does not follow instructions. It randomly decides to stop being agentic, and instead just dumps the code for me to paste. It has the extremely annoying habit of just doing stuff without understanding what I meant, making a mess, then claiming everyth…

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…

TBH, "use a package manager, don't specify versions manually unless necessary, don't edit package files manually" is an instructions that most agents still need to be given explicitly. They love manually editing package.json / cargo.toml / pyproject.toml / what have you, and using whatever version is given in their training data. They still don't have an intuition for which files should be manually written and which files should be generated by a command.

Re: The Codex App

#550

Earlier quoted context omitted.

C++ works, but compared to other languages it's often no longer the most productive choice for UI work. Modern UI code is mostly glue and state management, where fast iteration matters more than squeezing out maximum performance. And when performance does matter, there are also newer, safer languages. For teams comfortable with C++ or with existing C++ libraries to integrate, it can of course still be a strong choice…

But desktop C++ isn't difficult or slow to write... It seems odd to me that the software world has gone in the direction of "quick to write - slow to run". It should be the other way around. Things of quality (eg. paintings by Renaissance masters) took time to create, despite being quick to observe. It also seems proven that releasing software quickly ("fast iteration") doesn't lead to quality - see how many releases…

The part that takes time in UI isn’t wiring up components, it’s the small changes like something is a pixel to the right or that gap is two pixels wide. Changing those in a C++ project means recompiling and that adds up to significant overhead over a day of polishing the UI. If C++ was able to get builds out in less than a second, this wouldn’t be an issue. People value performance in their own tools more than the tools of their customer.
Post reply on HN