Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Codex App

openai.com

Post reply on HN
Print view View original

511–520 of 671 posts

Re: The Codex App

#511

Post by dworks »

varshar wrote: post #481
dworks wrote: post #404

Earlier quoted context omitted.

Recursive Language Models by Alex Zhang/MIT

@dworks: Good insights. Thanks! If you add a dialectic between Opus 4.5 and GPT 5.2 (not the Codex variant), your workflow - which I use as well, albeit slightly differently [1] - may work even better. This dialectic also has the happy side-effect of being fairly token efficient. IME, Claude Code employs much better CLI tooling+sandboxing when implementing while GPT 5.2 does excellent multifaceted critique even in co…

adding another external model/agent is exactly what I have been planning as the next step. in fact i already paste the implementation and test summaries into chatgpt, and it is extremely helpful in hardening requirements, making them more extensible, or picking up gaps between the implementations and the initial specs. it would be very useful to have this in the workflow itself, rather than the coding agent reviewing its own work - there is a sense that it is getting tunnel visioned.

i agree that CC seems like a better harness, but I think GPT is a better model. So I will keep it all inside the Codex VSCode plugin workflow.

Re: The Codex App

#512

Post by pimterry »

AdamN wrote: post #496
gloosx wrote: 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…

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 slower to get "native feel", or do you want to ship fast and get N times as much feature dev done? In a competitive race while the new features are flowing, development speed always wins.

Once feature development settles down, polish starts to matter more and the slowdown becomes less important, and then you can refocus.

Re: The Codex App

#513

Post by reverius42 »

theknarf wrote: post #502
gloosx wrote: 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…

There are such implementations for React Native: https://reactnative.dev/docs/out-of-tree-platforms

Re: The Codex App

#514

Post by ag220906 »

minton wrote: post #379
josephg wrote: post #375

Earlier quoted context omitted.

I'd love to see some opensource projects actually do a good job of this. Its a lot of work, especially if you want: - Good cross platform support (missing in filepilot) - Want applications to feel native everywhere. For example, all the obscure keyboard shortcuts for moving around a text input box on mac and windows should work. iOS and Android should use their native keyboards. IME needs to work. Etc - Accessibility…

But Electron doesn’t hit that bar even

yep, you're right to call that.

Re: The Codex App

#516

Post by embedding-shape »

bandrami wrote: post #374
embedding-shape wrote: post #306

Earlier quoted context omitted.

> You don't need to use microsoft's or apple's or google's shit UI frameworks. E.g. see https://filepilot.tech/ That's only for Windows though, it seems? Maybe the whole "just write all the rendering yourself using metal/gl/dx" is slightly harder than you think.

I mean, every cross-platform commercial DAW manages to do it? Bitwig, Renoise, Reaper, even VCV.

[delayed]

Re: The Codex App

#517

Post by blitzar »

stitched2gethr wrote: post #452
prodigycorp wrote: post #382

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

Talking LLMs off a ledge is a skill we will all need going forward.

Re: The Codex App

#518

Post by [deleted] »

aurareturn wrote: post #467
eviks wrote: post #464

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

[deleted]

Re: The Codex App

#519

Post by miroljub »

spiderice wrote: post #52
miroljub wrote: post #8

Given the prevalence of Opencode and its ability to use any model and provider I don't see reason why would anyone bother with random vendors half-assed tools.

For starters, money. There is no better value out there that I'm aware of than Claude Code Max. Claude Code also just works way better than Opencode, in my experience. Though I know there are those that have experienced the exact opposite.

I find Claude Code bloated and a bit clunky. Those same Claude models work better in Opencode, where I can also combine them with other providers.

The fact that Anthropic recently started blocking their coding plans usage from other tools is telling. They are in the phase where they realize they can't compete in an open field and need to go back behind their fortress gates and hope to endure a siege from the stronger opponents.

Post reply on HN