Live data from Hacker News

A Research Preview of Codex

openai.com

471–480 of 487 posts

Re: A Research Preview of Codex

#471
post #95

Earlier quoted context omitted.

> Parallel task execution: You can batch dozens of small edits (refactors, tests, boilerplate) and run them concurrently without context juggling. It's super nice to run a bunch of tasks at the same time (something that's really hard to do in Cursor, Cline, etc.) > It kind of feels like a junior engineer on steroids, you just need to point it at a file or function, specify the change, and it scaffolds out most of a P…

A single response can take a few seconds, but tasks with agentic flows can be dozens of back and forths. I've had a fairly complicated Roo Code task take 10 minutes (multiple subtasks).

How much of it did you read? Haha. That's not anything against you, I'm just pointing out to people that there will be a bunch of folks out there who will never care to read and learn. They just want to mash all the buttons until it works.

When I was a kid, that worked with Nintendo games sure...but I like to think I've matured beyond that...but I haven't read every little thing returned by the LLM in Roo Code myself, so maybe it's human nature.

Re: A Research Preview of Codex

#472

Some engineers on my team at Assembled and I have been a part of the alpha test of Codex, and I'll say it's been quite impressive. We’ve long used local agents like Cursor and Claude Code, so we didn’t expect too much. But Codex shines in a few areas: Parallel task execution: You can batch dozens of small edits (refactors, tests, boilerplate) and run them concurrently without context juggling. It's super nice to run…

> You still need to do a lot of work to get it production ready, but it's as if you have an infinite number of junior engineers at your disposal now all working on different things. One issue with junior devs is that because they’re not fully autonomous, you have to spend a non trivial amount of time guiding them and reviewing their code. Even if I had easy access to a lot of them, pretty quickly that overhead would…

You also have to provide accurate instructions.

I find most often times, "bugs" aren't with writing code that doesn't compile or doesn't have passing tests. The "bugs" come from not understanding the requirements and what it is you're building.

I'm not entirely sure AI will help this at all. People are generally bad at describing software and how they want it to work. They are inaccurate there or entirely omit things in the requirements.

Yes, though, it would be overwhelming to manage a bunch of AI agents. Context switching and redirecting, guiding, will be very difficult and not everyone's cup of tea.

If argue this isn't really a result of AI though. Many people are already in this boat today. The industry is set up in this way with contractors and outsourced devs that are at a junior level...because it's the attraction of cheap labor. Many businesses are attracted to this beyond programming. One of the questions is going to be, is the cost per token economics cheaper? So long as it's cheaper, AI coding agents will have a future. If it proves to not be cheaper (and this could take years to prove out), then I don't think it'll be as popular. I think people will need to go back to the drawing board on how we use AI agents or use AI for other purposes (like training, education, developer onboarding, code reviews, debugging, etc.)

Re: A Research Preview of Codex

#473

Earlier quoted context omitted.

They wrote "You still need to do a lot of work to get it production ready". So I would say it's not much better than real colleagues. Especially since junior devs will improve to a point they don't need your hand holding (remember you also were a junior at some point), which is not proven will happen with AI tools.

Counter-point A: AI coding assistance tools are rapidly advancing at a clip that is inarguably faster than humans. Counter-point B: AI does not get tired, does not need space, does not need catering to their experience. AI is fine being interrupted and redirected. AI is fine spending two days on something that gets overwritten and thrown away (no morale loss).

There's going to be a limit though. Plus you have to instruct them correctly.

B. Yea, that's true. I used to have over 4,000 GitHub contributions a year and it dropped to 1,000 as I got older and managed people. I used to be able to work 48 hrs straight but can't as much anymore...but you still have to be there to instruct the AI agent. It can't do it all on its own.

Re: A Research Preview of Codex

#474

Earlier quoted context omitted.

I'm definitely wary of the concept of dismissing courtesy when working with AI agents, because I certainly don't want to lose that habit when I turn around and have to interact with humans again.

Exactly. Courtesy and kindness are largely for the benefit of the giver. People who think “now I’m free to be the jerk I really am” worry me.

There's a very large gap between being super nice to a human and being a jerk.

I don't think it benefits me much by very politely suggesting that its approach may not work and emphasize on the good part of the idea it generates and it would be better if it could try to push in another direction for example X. Like I do when talking to junior engineers.

I usually just say, "This does not work because of ..., Y is good though, change your mind and assess X now". I can also say this when I'm not actually sure whether X works or not, without worrying about my words sending an intern / a junior engineer into days of struggling on a deadend.

Re: A Research Preview of Codex

#475
post #143

If you still don't think software engineering as a high paying job is over, I don't know what to tell you.

My counterargument: https://agifriday.substack.com/p/jevons

Short version: Jevons's paradox means that the more coding you automate away for developers (like with compilers in the past), the more in-demand those developers are. (Until AGI when all bets are off, of course.)

Re: A Research Preview of Codex

#476
post #360
post #127

In the preview video, I appreciated Katy Shi's comment on "I think this is a reflection of where engineering work has moved over the past where a lot of my time now is spent reviewing code rather than writing it." Preview video from Open AI: https://www.youtube.com/watch?v=hhdpnbfH6NU&t=878s As I think about what "AI-native" or just the future of building software loos like, its interesting to me that - right now - d…

> a lot of my time now is spent reviewing code rather than writing it. Reviewing has never been a panacea. It’s a best-effort at catching obvious mistakes, like a second opinion. Only with highly rigorous tests can reviewing give as high confidence as I trust another engineer or myself. Generally cadence of code output has never been a bottleneck for me, rather the opposite (if I had more time I’d write you a shorter…

> An army of automated junior engineers still can’t win over the complexity beast that yolo programming causes. At some point code mutations will cause more problems as side effects than what they fix.

This resonates a lot for me, completely agreed.

Re: A Research Preview of Codex

#477
post #127

In the preview video, I appreciated Katy Shi's comment on "I think this is a reflection of where engineering work has moved over the past where a lot of my time now is spent reviewing code rather than writing it." Preview video from Open AI: https://www.youtube.com/watch?v=hhdpnbfH6NU&t=878s As I think about what "AI-native" or just the future of building software loos like, its interesting to me that - right now - d…

++ Kind of my whole thesis with Graphite. As more code gets AI-generated, the weight shifts to review, testing, and integration. Even as someone helping build AI code reviewers, we'll _need_ humans stamping forever - for many reasons, but fundamentally for accountability. A computer can never be held accountable https://constelisvoss.com/pages/a-computer-can-never-be-held...

> A computer can never be held accountable

I feel like I've been thinking along similar lines recently (due to re-read this though!) but instead of "computer" am replacing it with "AI" or "Agents" these days. Same point holds true.

Re: A Research Preview of Codex

#478
post #127

In the preview video, I appreciated Katy Shi's comment on "I think this is a reflection of where engineering work has moved over the past where a lot of my time now is spent reviewing code rather than writing it." Preview video from Open AI: https://www.youtube.com/watch?v=hhdpnbfH6NU&t=878s As I think about what "AI-native" or just the future of building software loos like, its interesting to me that - right now - d…

Re:simulation Deebo does this for debugging: https://github.com/snagasuri/deebo-prototype

Thanks for sharing - wasn't familiar with Deebo!

Re: A Research Preview of Codex

#479
post #139

Earlier quoted context omitted.

automated visual fuzzy-testing with some self-reinforcement loops There's already library's for QA testing and VLM's can give critique on a series of screenshots automated by a playwright script per branch

Cool. Putting vision in the loop is a great idea. Ambitious idea, but I like it.

Yes, the above reply is more what I meant! Vision / visualization not just more automated testing.

Definitely ambitious!

Re: A Research Preview of Codex

#480
post #369

So there's this thing called "Setup Scripts" but they don't explicitly say these are equivalent to AWS Metadata and configured inside of Codex web interface - not a setup.sh or a package.json preinstall declaration. I wasted several hours (and lots of compute where Codex was as confused as I was) trying to figure out how to convince codex to pnpm install.

Codex engineer here. Can you elaborate on what was confusing? I would love to make it more clear.

I just found this thread while trying to figure out where to set the setup script. The docs should probably make that more clear.
Post reply on HN