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

181–190 of 487 posts

Re: A Research Preview of Codex

#181

Post by rboyd »

kypro wrote: post #117
criddell wrote: post #112

Earlier quoted context omitted.

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…

> 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? They'll probably just need to learn for longer and if companies ever get so desperate for senior engineers then just take the most able/experienced junior/mid level dev. But I'd argue before they do that if companies can't find skilled labour domestically they should cons…

India coming online just in time for AI is awkward

Re: A Research Preview of Codex

#182

Post by lispisok »

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…

A lot of people are deeply invested in these things being better than they really are. From the OpenAI's and Google's spending $100s of billions EACH developing LLMs to VC backed startups promising their "AI agent" can replace entire teams of white collar employees. That's why your experience matches mine and every other developer I personally know but you see comments everywhere making much grander claims.

Re: A Research Preview of Codex

#183

Post by [deleted] »

asdev wrote: post #152
alvis wrote: post #35

I used to work for a bank and the legal team used to ping us to make tiny changes to the app for compliance related issues. Now they can fix themselves. I think they’d be very proud and happy

I promise you the legal team is not pushing any code changes

[deleted]

Re: A Research Preview of Codex

#185

Post by Daishiman »

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…

> 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 this type of drudgery. Professional painters and designers spend most of their time replicating ideas that are well fleshed-out. Musicians spend most of their time rehearsing existing compositions.

There is a point to be made that these repetitive tasks are a prerequisite to come up with creative ideas.

Re: A Research Preview of Codex

#186

Post by _bin_ »

al_borland wrote: post #172
_bin_ wrote: post #156

Earlier quoted context omitted.

This is a bit of a game theory problem. "Training senior engineers" is an expensive and thankless task: you bear essentially all the cost, and most of the total benefit accrues to others as a positive externality. Griping at companies that they should undertake to provide this positive externality isn't really a constructive solution. I think some people are betting on the fact that AI can replace junior devs in 2-5…

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 2: You quit training juniors and let AI do the work.

Case 2.1: AGI soon, you have saved yourself a bundle of cash and remain mostly in in line with the market.

Case 2.2: no AGI, you are in the same bidding war for talent as everyone else, the same place you'd have been were you to have spent all that cash to train engineers. You now have a juicier balance sheet with which to enter this bidding war.

The only way out of this, you can probably see, is some sort of external co-ordination, as is the case with most of these situations. The high-EV move is to quit training juniors, by a mile, independently of whether AI can replace senior devs in a decade.

Re: A Research Preview of Codex

#187

Post by echelon »

voidspark wrote: post #169
echelon wrote: post #113

Earlier quoted context omitted.

The never ending march of progress. It's probably over for these folks. There will likely(?, hopefully?) be new adjacent gradients for people to climb. In any case, I would worry more about your own job prospects. It's coming for everyone.

It's his daughter. He is worried about his daughter first and foremost. Weird reply.

I'm sorry. I was skimming. I had no idea he mentioned his kid.

I was running a quick errand between engineering meetings and saw the first few lines about hiring juniors, and I wrote a couple of comments about how I feel about all of this.

I'm not always guilty of skimming, but today I was.

Re: A Research Preview of Codex

#188

Post by dorian-graph »

_bin_ wrote: post #156
criddell wrote: post #112

Earlier quoted context omitted.

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…

This is a bit of a game theory problem. "Training senior engineers" is an expensive and thankless task: you bear essentially all the cost, and most of the total benefit accrues to others as a positive externality. Griping at companies that they should undertake to provide this positive externality isn't really a constructive solution. I think some people are betting on the fact that AI can replace junior devs in 2-5…

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.

Re: A Research Preview of Codex

#189

Post by layer8 »

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 share your worries, but the time horizon for the supply of senior engineers drying up is just too long for companies to care at this time, in particular if productivity keeps increasing. And it’s completely unclear what the state of the art will be in 20 years; the problem might mostly solve itself.

Re: A Research Preview of Codex

#190

Post by electrondood »

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…

> doing the basic job of knowledge workers

If you extrapolate and generalize further... what is at risk is any task that involves taking information input (text, audio, images, video, etc.), and applying it to create some information output or perform some action which is useful.

That's basically the definition of work. It's not just knowledge work, it's literally any work.

Post reply on HN