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

601–610 of 671 posts

Re: The Codex App

#601

Post by anaisbetts »

OlympicMarmoto wrote: post #265
namelosw wrote: post #255

Earlier quoted context omitted.

The situation for Desktop development is nasty. Microsoft had so many halfassed frameworks and nobody knows which one to use. It’s probably the de facto platform on Windows IS Electron, and Microsoft use them often, too. On MacOS is much better. But most of the team either ended up with locked in Mac-only or go cross platform with Electron.

This is another common excuse. You don't need to use microsoft's or apple's or google's shit UI frameworks. E.g. see https://filepilot.tech/ You can just write all the rendering yourself using metal/gl/dx. if you didn't want to write the rendering yourself there are plenty of libraries like skia, flutter's renderer, nanovg, etc

That'll work great until your first customer from a CJK or RTL language writes in, "Hey, how come I can't type in your app?", or the blind user writes in "Hey how come your app is completely blank?" then you'll be right in the middle of the "Find Out" phase

These strategies are fine for toy apps but you cannot ship a production app to millions or even thousands of people without these basics.

Re: The Codex App

#602

Post by kaffekaka »

angiolillo wrote: post #567
manuelmoreale wrote: post #539

Earlier quoted context omitted.

> it's a tradeoff in development speed Doesn't this get thrown out the window now that everyone claims you can be 10x, 50x, 100x more productive with AI? Hell people were claiming you can ask a bunch of AI agents to build a browser from scratch, so surely the dev speed argument no longer applies.

Even if we assume a developer is actually 10x more productive with AI, if you triple their workload by having them build 3 native apps now you're only 3.33x more productive.

No, you would be ten times as productive. You would ship three different apps 3,3 times faster than you previously only shipped one.

The productivity comparison must be made between how long it takes to ship a certain amount of stuff.

Re: The Codex App

#603

Post by GorbachevyChase »

gloosx wrote: post #451
OlympicMarmoto wrote: post #220

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…

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

Wouldn’t maintaining the different UI stacks be something a language model could handle? Creating a new front end where the core logic is already defined or making a new one from an existing example has gone pretty fast for me. The “maintenance“ cost might not be as high as you think.

Re: The Codex App

#604

Post by threecheese »

hmokiguess wrote: post #289
hollowturtle wrote: post #283

Earlier quoted context omitted.

Agree, another improvement i'd like along the lines or renames is lsp suggestions for method names, enums, functions, etc The llm should be able to autocomplete given lsp available symbols, this way it would avoid far less hallucinated methods

Claude, at least, already supports LSP servers though. https://code.claude.com/docs/en/plugins-reference#lsp-server...

After using CC in VSCode a bit, I find it makes liberal use of Pylance, both proactively (in-thread) as well as during the lifecycle (guessing via hooks). It’s almost annoying how, and I’d like to figure out how to get it to use repos lint rules.

Re: The Codex App

#605

Post by IhateAI »

deaux wrote: post #422
IhateAI wrote: post #410

Earlier quoted context omitted.

I'm not making any guesses, I happen to know for a fact what it costs. Please go try to sell inference and compete on price. You actually have no clue what you're talking about. I knew when I sent that response I was going to get "but Kimi!"

Okay, so you are claiming "every single one of those 8 providers, along with all others who don't serve openrouter but are at similar price points, are subsidizing by more than 50%". That's an incredibly bold claim that would need quite a bit of evidence, and just waving "$500k in gpus" isn't it. Especially when individuals are reporting more than enough tps at native int4 with <$80k setups, without any of the scalin…

Imagine thinking that $80k setups to run Kimi and serve a single user session is evidence that inference providers are running at cost, or even close to it. Or that this fact is some sort of proof that token pricing will come down. All you one-shotted llm dependents said the same thing about Deepseek.

I know you need to cope because your competency is 1:1 correlated to the quality and quantity of tokens you can afford, so have fun with your Think for me SaaS while you can afford it. You have no clue the amount of engineering that goes into provide inference at scale. I wasn't even including the cost of labor.

Re: The Codex App

#606

Post by IhateAI »

anon373839 wrote: post #420
IhateAI wrote: post #410

Earlier quoted context omitted.

I'm not making any guesses, I happen to know for a fact what it costs. Please go try to sell inference and compete on price. You actually have no clue what you're talking about. I knew when I sent that response I was going to get "but Kimi!"

The numbers you stated sound off ($500k capex + electricity per 3 concurrent requests?). Especially now that the frontier has moved to ultra sparse MoE architectures. I’ve also read a couple of commodity inference providers claiming that their unit economics are profitable.

You're delusional, I didn't even include the labor the install and run the damn thing. More than 500k

Re: The Codex App

#607

Post by Sammi »

tomashubelbauer wrote: post #500
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…

I am using GPT-5.2 Codex with reasoning set to high via OpenCode and Codex and when I ask it to fix an E2E test it tells me that it fixed it and prints a command I can run to test the changes, instead of checking whether it fixed the test and looping until it did. This is just one example of how lazy/stupid the model is. It _is_ a skill issue, on the model's part.

Non codex gpt 5.2 is much better than codex gpt 5.2 for me. It does everything better.

Re: The Codex App

#608

Post by tomashubelbauer »

Sammi wrote: post #607
tomashubelbauer wrote: post #500

Earlier quoted context omitted.

I am using GPT-5.2 Codex with reasoning set to high via OpenCode and Codex and when I ask it to fix an E2E test it tells me that it fixed it and prints a command I can run to test the changes, instead of checking whether it fixed the test and looping until it did. This is just one example of how lazy/stupid the model is. It _is_ a skill issue, on the model's part.

Non codex gpt 5.2 is much better than codex gpt 5.2 for me. It does everything better.

Yup, I find it very counter-intuitive that this would be the case, but I switched today and I can already see a massive difference.

Re: The Codex App

#609

Post by sideeffffect »

realusername wrote: post #543
theknarf wrote: post #502

Earlier quoted context omitted.

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.

https://reactnative.dev/docs/out-of-tree-platforms says otherwise

React Native Skia allegedly runs on Linux too

Re: The Codex App

#610

Post by dudeinhawaii »

chandureddyvari wrote: post #405
jtrn wrote: 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…

Agreed, had the same experience. Codex feels lazy - I have to explicitly tell it to research existing code before it stops giving hand-wavy answers. Doc lookup is particularly bad; I even gave it access to a Context7 MCP server for documentation and it barely made a difference. The personality also feels off-putting, even after tweaking the experimental flag settings to make it friendlier. For people suggesting it’s…

Curious, are you doing the same planning with Codex out-of-band or otherwise? In order to have the same measurable outcome you'd need to perhaps use Codex in a plan state (there's experimental settings - not recommended) or other means (explicit detailed -reusable- prompt for planning a change). It's a missing feature if your preference is planning in CLI (I do not prefer this).

You are correct in that this mode isn't "out of the box" as it is with Claude (but I don't use it in Claude either).

My preference is to have smart models generate a plan with provided source. I wrote (with AI) a simple python tool that'll filter a codebase and let me select all files or just a subset. I then attach that as context and have a smart model with large context (usually Opus, GPT-5.2, and Gemini 3 Pro in parallel), give me their version of a plan. I then take the best parts of each plan, slap it into a single markdown and have Codex execute in a phased manner. I usually specify that the plan should be phased.

I prefer out-of-CLI planning because frankly it doesn't matter how good Codex or Claude Code dive in, they always miss something unless they read every single file and config. And if they do that, they tip over. Doing it out of band with specialized tools, I can ensure they give me a high quality plan that aligns with the code and expectations, in a single shot (much faster).

Then Claude/Codex/Gemini implement the phased plan - either all at once - or stepwise with me testing the app at each stage.

But yeah, it's not a skill issue on your part if you're used to Plan -> Implement within Claude Code. The Experimental /collab feature does this but it's not supported and more experimental than even the experimental settings.

Post reply on HN