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

361–370 of 671 posts

Re: The Codex App

#361

Post by adithyassekhar »

SunshineTheCat wrote: post #17
strongpigeon wrote: post #5

Genuinely excited to try this out. I've started using Codex much more heavily in the past two months and honestly, it's been shockingly good. Not perfect mind you, but it keeps impressing me with what it's able to "get". It often gets stuff wrong, and at times runs with faulty assumptions, but overall it's no worse than having average L3-L4 engs at your disposal. That being said, the app is stuck at the launch screen…

Same here. From my experience, codex usually knocks backend/highly "logical?" tasks out of the park while fairly basic front-end/UI tasks it stumbles over at times. But overall it does seem to be consistently improving. Looking to see how this makes it easier to work with.

Backend, regardless of language or framework are often set in stone. There's a well defined/most used way for everything. Especially since most apps when reduced is CRUD. Frontend by the nature of how frontend works, can be completely different from project to project if one wants to architect it efficiently.

Re: The Codex App

#362

Post by indigodaddy »

mdrzn wrote: post #27

Maybe it's because I'm not used to the flow, but I prefer to work directly on the machine where I'm logged in via ssh, instead of working "somewhere in a git tree", and then have to deploy/test/etc. Once this app (or a similar app by Anthropic) will allow me to have the same level of "orchestration" but on a remote machine, I'll test it.

Not going to solve your exact problem but I started this project with this approach in mind

https://github.com/jgbrwn/vibebin

Re: The Codex App

#363

Post by herval »

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…

It’s just irrelevant for most users. These companies are getting more adoption than they can handle, no matter how clunky their desktop apps are. They’re optimizing for experimentation. Not performance.

Re: The Codex App

#364

Post by indigodaddy »

theLiminator wrote: post #110
embirico wrote: post #50

Earlier quoted context omitted.

(I work on Codex) One detail you might appreciate is that we built the app with a ton of code sharing with the CLI (as core agent harness) and the VSCode extension (UI layer), so that as we improve any of those, we polish them all.

Any chance you'll enable remote development on a self-hosted machine with this app? Ie. I think the codex webapp on a self-hosted machine would be great. This is impotant when you need a beefier machine (with potentially a GPU).

Not going to solve your exact problem but I started this project with this approach in mind

https://github.com/jgbrwn/vibebin

Re: The Codex App

#365

Post by indigodaddy »

daxfohl wrote: post #245

It would be nice if it didn't have to be all local. I'd love a managed cluster feature where you could just blast some workloads off to some designated server or cluster and manage them remotely, share progress with teammates, etc. (Not "cloud" though; I'd still want them on the internal network). I imagine something like that is in the works.

Not going to solve your exact problem but I started this project with this approach in mind. It is exposed to the Internet though on a VPS or server but using caddy basic auth in front of the coding url

https://github.com/jgbrwn/vibebin

Re: The Codex App

#366

Post by boppo1 »

dworks wrote: 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…

Which paper?

Re: The Codex App

#367

Post by ttul »

I had been procrastinating putting in the effort to find a decent web designer to redesign our company’s website because I couldn’t stomach the hours I would need to put in to educate them about our messaging and to slowly go around and around iteratively to get the design nailed.

Last week, I decided to try building the site myself using Codex (the terminal one). I chose Astro as the framework because I wanted to learn about it. I fed it some marketing framework materials (positioning statements and whatnot) and showed it some website designs that we like. I then asked it to produce a first cut and it one-shotted a pretty decent bit of output.

AGI is definitely a few more years away, because I’ve since invested probably 30 hours of iteration to make the site into something that is closer to what I eventually want to launch. But here’s the thing: I never intended for Codex to produce THE final website. But now I’m thinking, “maybe we can?” On my team, we have just enough expertise and design know-how to at least know what looks good and we are developers so we definitely know what good code looks like. And Codex is nailing it on both those fronts.

As I said, we’re far from AGI. There’s no way I can one-shot something like this. It requires iteration with humans who have years of “context” built up. But maybe the days of hiring a designer and just praying that they somehow get it right are behind us.

Re: The Codex App

#368

Post by AlexCoventry »

theLiminator wrote: post #110
embirico wrote: post #50

Earlier quoted context omitted.

(I work on Codex) One detail you might appreciate is that we built the app with a ton of code sharing with the CLI (as core agent harness) and the VSCode extension (UI layer), so that as we improve any of those, we polish them all.

Any chance you'll enable remote development on a self-hosted machine with this app? Ie. I think the codex webapp on a self-hosted machine would be great. This is impotant when you need a beefier machine (with potentially a GPU).

What are the benefits of using the codex webapp?

Re: The Codex App

#369

Post by ttul »

ttul wrote: post #367

I had been procrastinating putting in the effort to find a decent web designer to redesign our company’s website because I couldn’t stomach the hours I would need to put in to educate them about our messaging and to slowly go around and around iteratively to get the design nailed. Last week, I decided to try building the site myself using Codex (the terminal one). I chose Astro as the framework because I wanted to le…

PS: Yes, I spent several hours on the weekend getting Codex to add animations, sound effects, and a mini game to our home page hero graphic. That was fun. I look forward to the creativity that people unleash with tools like this in the coming months.

Re: The Codex App

#370

Post by pama »

markbao wrote: post #317
pama wrote: post #251

Earlier quoted context omitted.

My main take is exactly the opposite. Why not build everything with a simple text interface (shell command) so the models learn to use these tools natively in pretraining. Even TUI like codex-cli or claude code are needless abstractions for such use cases and make full automation hard. You could add as many observability or input layers for humans as you want but the core should be simple calls that are saved in hist…

TUI is easy to train on, but hard to use for users. Part of the reason it’s easier to have LLMs use a bunch of Unix tools for us is that their text interface is tedious and hard to remember. If you’re a top 5% expert in those tools it doesn’t matter as much I guess but most people aren’t. Even a full-featured TUI like Claude Code is highly limited compared to a visual UI. Conversation branching, selectively applying…

I use headless mode (-p) and keep my named shell histories as journals (so no curses/TUI or GUI). But session management or branching could improve at the tool level and allow seamless integration with completion tools, which could be a simple fast AI looking at recent sessions or even be visual, say for navigating and extending a particular complex branch of a past session. It is not too hard to work with such shell-based flows within Emacs for me, but it would be nice if there was some standardization effort on the tool fronts and some additional care for future automation. I dont want my AI clicking buttons if it can be precise instead. And I certainly want multithreading. I think of AI more as an OS; it needs a shell more than it needs windows at this point in time.
Post reply on HN