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

A Research Preview of Codex

openai.com

Post reply on HN
Print view View original

241–250 of 487 posts

Re: A Research Preview of Codex

#241

Post by oytis »

odie5533 wrote: post #234
dorian-graph wrote: post #188

Earlier quoted context omitted.

This hyper-fixation on replacing engineers in writing code is hilarious, and dangerous, to me. Many people, even in tech companies, have no idea how software is built, maintained, and run. I think instead we should focus on getting rid of managers and product owners.

As a dev, if you try taking away my product owners I will fight you. Who am I going to ask for requirements and sign-offs, the CEO?

Your architect, principal engineer etc. (one spot-on job title I've seen is "product architect"), who in turn talks to the senior management. Basically an engineer with a talent and experience for building products rather than a manager with superficial understanding of engineering. I think the most ambitious teams have someone like this on top - or at least around

Re: A Research Preview of Codex

#242

Post by alfalfasprout »

dakiol wrote: post #224
johnjwang wrote: post #80

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…

[flagged]

TBH the people I see parroting the LLM=junior engineer BS are almost always technically incompetent or so disconnected at this point from what's happening on the ground that they wouldn't know either way.

I've been using the codex agent since before this announcement btw along with most of the latest LLMs. I literally work in the AI/ML tooling space. We're entering a dangerous world now where there's super useful technology but people are trying to use it to replace others instead of enhance them. And that's causing the wrong tools to be built.

Re: A Research Preview of Codex

#243

Post by blibble »

awestroke wrote: post #50
skovati wrote: post #40

I'm curious how many ICs are truly excited about these advancements in coding agents. It seems to me the general trend is we become more like PMs managing agents and reviewing PRs, all for the sake of productivity gains. I imagine many engineers are like myself in that they got into programming because they liked tinkering and hacking and implementation details, all of which are likely to be abstracted over in this n…

At the end of the day, it's your job to deliver value. If a tool allows you to deliver more faster, without sacrificing quality, it's your responsibility to use that tool. You'll just have to make sure you can fully take responsibility for the end deliverables. And these tools are not only useful for writing the final code

> At the end of the day, it's your job to deliver value. If a tool allows you to deliver more faster, without sacrificing quality

I guess that's LLMs ruled out then

Re: A Research Preview of Codex

#244

Post by ericghildyal »

ai-christianson wrote: post #149
tough wrote: 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.

I used Cline to build a tiny testing helper app and this is exactly what it did!

It made changes in TS/Next.js given just the boiletplate from create-next-app, ran `yarn dev` then opened its mini LLM browser and navigated to localhost to verify everything looked correct.

It found 1 mistake and fixed the issue then ran `yarn dev` again, opened a new browser, navigated to localhost (pointing at the original server it brought up, not the new one at another port) and confirmed the change was correct.

I was very impressed but still laughed at how it somehow backed its way into a flow the worked, but only because Next has hot-reloading.

Re: A Research Preview of Codex

#245

Post by deadmutex »

odie5533 wrote: post #234
dorian-graph wrote: post #188

Earlier quoted context omitted.

This hyper-fixation on replacing engineers in writing code is hilarious, and dangerous, to me. Many people, even in tech companies, have no idea how software is built, maintained, and run. I think instead we should focus on getting rid of managers and product owners.

As a dev, if you try taking away my product owners I will fight you. Who am I going to ask for requirements and sign-offs, the CEO?

Perhaps the role will merge into one, and will replace a good chunk of those jobs.

E.g.:

If we have 10 PMs and 90 devs today, that could be hypothetically be replace by 8 PM+Dev, 20 specialized devs, and 2 specialized PMs in the future.

Re: A Research Preview of Codex

#246

Post by atonse »

criddell wrote: post #112
johnjwang wrote: post #80

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…

If you aren't hiring junior engineers to do these kinds of things, where do you think the senior engineers you need in the future will come from? My kid recently graduated from a very good school with a degree in computer science and what she's told me about the job market is scary. It seems that, relatively speaking, there's a lot of postings for senior engineers and very little for new grads. My employer has hired…

I feel for your daughter. I can totally see how tools like this will destroy the junior job market.

But I also wonder (I'm thinking out loud here, so pardon the raw unfiltered thoughts), if being a junior today is unrecognizable.

Like for example, that whatever a "junior" will be now, will have to get better at thinking at a higher level, rather than the minute that we did as juniors (like design patterns and all that stuff).

So maybe the levels of abstraction change?

Re: A Research Preview of Codex

#247

Post by blibble »

hintymad wrote: post #179
johnjwang wrote: post #80

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…

It looks we are in this interesting cycle: millions of engineers contribute to open-source on github. The best of our minds use the code to develop powerful models to replace exactly these engineers. In fact, the more code a group contributes to github, the easier it is for the companies to replace this group. Case in point, frontend engineers are impacted most so far. Does this mean people will be less incentivized…

> Does this mean people will be less incentivized to contribute to open source as time goes by?

personally, I completely stopped 2 years ago

it's the same as the stack overflow problem: the incentive to contribute tends towards zero, at which point the plagiarism machine stops improving

Re: A Research Preview of Codex

#248

Post by KaiserPro »

rowanG077 wrote: post #195
Daishiman wrote: post #185

Earlier quoted context omitted.

> P.S., I think the current trend is a wakeup call to us software engineers. We thought we were doing highly creative work, but in reality we spend a lot of time doing the basic job of knowledge workers: retrieving knowledge and interpolating some basic and highly predictable variations. Unfortunately, the current AI is really good at replacing this type of work. Most of the waking hours of most creative work have th…

I disagree. AI have shown to most capable in what we consider creative jobs. Music creation, voice acting, text/story writing, art creation, video creation and more.

> AI have shown to most capable in what we consider creative jobs

no it creates shit thats close enough for people who are in a rush and dont care.

ie, you need artwork for shit on temu, boom job done.

You want to make a poster for a bake sale, boom job done.

Need some free music that sounds close enough to be swifty, but not enough to get sued, great.

But as an expression of creativity, most people cant get it to do that.

Its currently slightly more configurable clipart.

Re: A Research Preview of Codex

#249

Post by alfalfasprout »

Workaccount2 wrote: post #22
prhn wrote: post #12

Is anyone using any of these tools to write non boilerplate code? I'm very interested. In my experience ChatGPT and Gemini are absolutely terrible at these types of things. They are constantly wrong. I know I'm not saying anything new, but I'm waiting to personally experience an LLM that does something useful with any of the code I give it. These tools aren't useless. They're great as search engines and pointing me i…

>What am I missing? That you are trying to use LLMs to create giant sprawling codebase feature packed software packages that define the modern software landscape. What's being missed is that any one user might only utilize 5% of the code base on any given day. Software is written to accommodate every need every user could have in one package. Then the users just use the small slice that accommodates their specific ne…

> I have now created 5 hyper narrow programs that are used daily by my company to do work. I am not a programmer and my company is not a tech company located in a tech bubble. We are a tiny company that does old school manufacturing.

OK, great.

> That you are trying to use LLMs to create giant sprawling codebase feature packed software packages that define the modern software landscape. What's being missed is that any one user might only utilize 5% of the code base on any given day. Software is written to accommodate every need every user could have in one package. Then the users just use the small slice that accommodates their specific needs.

With all due respect, the fact that you made a few small programs to help with your tasks is wonderful but this last statement alone rather disqualifies your expertise to make an assessment on software engineering in general.

There's a great number of reasons why codebases get large. Complex problems inherently come with complexity and scale in both code and integrations. You can choose to move the complexity around but never fully get rid of it.

Re: A Research Preview of Codex

#250

Post by spongebobstoes »

_bin_ wrote: post #186
al_borland wrote: post #172

Earlier quoted context omitted.

That sounds like a dangerous bet.

As I see it, it's actually the only safe bet. Case 1: you keep training engineers. Case 1.1: AGI soon, you don't need juniors or seniors besides a very few. You cost yourself a ton of money that competitors can reinvest into R&D, use to undercut your prices, or return to keep their investors happy. Case 1.2: No AGI. Wages rise, a lot. You must remain in line with that to avoid losing those engineers you trained. Case…

An interesting thing to consider is that Codex might get people to be better at delegating, which might improve the effectiveness of hiring junior engineers. Because the senior engineers will have better skills at delegating, leading to a more effective collaboration.
Post reply on HN