Live data from Hacker News

A Research Preview of Codex

openai.com

311–320 of 487 posts

Re: A Research Preview of Codex

#311

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…

This may be unpopular/counter-intuitive to say, but in a capitalist world this is probably the best outcome IF (and I'm not saying I can predict the future) we expect the profession to die/be obsolete from a society POV - in such a world restricting juniors before they commit a whole career to that profession and invest too much resources into it is actually the outcome we probably want. Better than the alternative of even more mass unemployment later. If that's the case then giving people that info early, and avoiding more hiring/training now stops potential mal-investment of money and people's time into training/hiring/building careers in/etc.

It stops juniors investing their life/time/energy in a field that is shrinking and that will increasingly "not be worth it" w.r.t effort put in given their longer time horizon. This is how capitalism when working correctly can obsolete jobs somewhat charitably - it does it by closing the door on entry level jobs ideally when people have little to lose and haven't yet invested a lot of their life into it. For example they may still be young enough to re-train; or may be dismayed from entering the field due to disruption/chatter and so do something more appropriate in the new world.

Being hired in a sinking and increasingly more competitive field may actually be considered a "winner's curse" outcome, in that you will be in a industry highly competitive that is slowly sinking and is stressful with low opportunities for pay rises compared to other industries/skill sets - this is definitely playing your career in "hard mode". Most of all you will feel your skills, and value is useless relatively to people who got into more jobs with more scarcity playing life in "easy mode" with less stress and anxiety. In a few years time people getting into other fields may feel they "dodged a bullet" comparing themselves to others that did.

Being able to pivot while you are still young and ageism isn't a barrier yet is definitely something to consider remembering careers these days are multi-decades long. I feel for your kid now, and I do for mine, but I would rather than try something different in their 20's vs say their 40's when they have a mortgage, a family to feed, and/or other commitments and ageism makes it harder to pivot/re-train into another career. I don't wish my kids to feel the anxiety I and many people I know are feeling later in life especially for a career that requires constant effort to maintain and keep relevant in. I'm not recommending my kids learn what I do at all for example.

Re: A Research Preview of Codex

#312
post #157

is the point of this to actually assign tasks to an AI to complete end to end? Every task I do with AI requires atleast some bit of hand holding, sometimes reprompting etc. So I don't see why I would want to run tasks in parallel, I don't think it would increase throughput. Curious if others have better experiences with this

The example use-cases in the videos are pretty compelling and much smaller scope.

“Here’s an error reported to the oncall. Give a try fixing it” (Could be useful even if it fails)

Refactor this small piece I noticed while doing something else. Small-scoped stuff that likely wouldn’t get done otherwise.

I wouldn’t ask LLMs for full-features in a real codebase but these examples seem within the scope of what they might be able to accomplish end-to-end

Re: A Research Preview of Codex

#313
post #54

So it's looking like it's only running in the cloud, that is it will push commits to my remote repo before I have a chance to see if it works? When I'm using aider, after it make a commit what I do, I then immediately run git reset HEAD^ and then git diff (actually I use github desktop client to see the diff) to evaluate what exactly it did, and if I like it or not. Then I usually make some adjustments and only after…

This takes all the soul out of programming, not sure why anyone likes to use llms like this.

Re: A Research Preview of Codex

#314

Earlier quoted context omitted.

It's happening to Hollywood right now. In the past three years, since roughly 2022, the majority of IATSE folks (film crew, grips, etc.) have seen their jobs disappear to Eastern Europe where the labor costs one tenth of what it does here. And there are no rules for maximum number of consecutive hours worked.

How do? Perhaps if you film in Eastern Europe (which I realize does happen a bit), but even if your crew is foreign, if you’re filming in the US they’re still subject to US labor law. Being willing to ignore labor law also happens but is a bit beyond “offshoring”.

The film production company flies the cast of actors out to Serbia or whatever and relies on Serbian crews.

Prior to 2022 they'd fly out the entire crew from the US and all the workers would be American and Canadian. Union, highly paid. Now they're using local (non-American) labor.

Amazon and Apple taught the foreign talent how to do grip work so they didn't have to hire expensive American workers anymore.

There are far fewer productions happening domestically within the US now. The numbers are 30% of what they once were.

Re: A Research Preview of Codex

#315

I believe that code from one of these things will eventually cause a disaster affecting the capital owners. Then all of a sudden you will need a PE license, ABET degree, 5 years working experience, etc. to call yourself a software engineer. It would not even be historically unique. Charlatans are the reason that lawyers, medical doctors, and civil engineers have to go through lots of education, exams, and vocational…

I wish but I dont think we could be any futher away from professionalizing like engineering/law/accounting/medicine. There was a deliberate effort to flood the field and lower salaries and developers were so full of hubris and thought there was infinite demand for their labor and went along with it and still are. Maybe some are learning given the job market the last few years. Despite software being in everything and…

Obviously there is no way to really predict when this would happen, but I don't think it will be up to developers to decide whether it happens or not. In Texas for example, the legislature forced engineering to be professionalized (or regulated) in an emergency session after a school in a well off area exploded in a gas explosion (https://en.wikipedia.org/wiki/New_London_School_explosion#In...).

I also do not think this is limited to software engineering. Medical doctors and accountants have faced the squeeze in recent years too. There are tons of (bad) DO med schools opening up across the country that will be flooding the field before long, nurse practitioners and physicians assistants get to do more and more work that only doctors got to do, and more and more accounting is being offshored. The question is when things get so bad that even the powerful decide to actually do something about it.

Re: A Research Preview of Codex

#316

Earlier quoted context omitted.

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.

If you have 10PMs and 90 devs today, and go to 8 "hybrid" PMs + 2 specialized PMs, you're probably still creating backlog items faster than that team can close them.

So you end up with some choices:

* do you move at the same speed, with fewer people?

* do you try to move faster, with less of a reduction in people? this could be trickier than it sounds because if the frequency of changes increases the frequency of unintended consequences likely does too, so your team will have to spend time reacting to that

I think the companies that win will be the second batch. It's what happens today, basically, but today you have to convince VCs or the public market to give you a bunch of more money to hire to 10x the team size. Getting a (one-off?) chance to do that through tooling improvements is a big gift, wasting it on reducing costs instead of increasing growth could be risky.

Re: A Research Preview of Codex

#317
post #186

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…

Case 1.3: No AGI, tools increase productivity a lot, you have a bigger team and you make them more productive. In the meantime, while everyone else was scared of hiring, you got a bunch of stuff done to gain a lead in the market.

You get high EV because everyone else in your market voluntarily slowing down is a gift-wrapped miracle for you.

(Even in an AGI-soon case - you spent a bit more (let's be serious here, we're not talking about spending our entire bankroll on 18months of new hires here) in short term to get ahead, then you shift people around or lay them off. Your competitors invested that money into R&D? What does that even mean if it didn't involve hiring and AGI happens soon anyway?)

----

(Case 3: AGI soon, you don't need yourself anymore - it's hard to imagine a sufficiently advanced "AGI" that someone only replaces software devs but leaves the structure, management, and MBA-trappings of modern exchange and businesses alone.)

Re: A Research Preview of Codex

#318

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.

The people who will come out the other side are domain focused people with the engineering chops to understand the system end to end, and the customer skills to understand what needs to be built.

Yes. everyone will eventually have the job title of "problem solver"

Re: A Research Preview of Codex

#319
post #54

So it's looking like it's only running in the cloud, that is it will push commits to my remote repo before I have a chance to see if it works? When I'm using aider, after it make a commit what I do, I then immediately run git reset HEAD^ and then git diff (actually I use github desktop client to see the diff) to evaluate what exactly it did, and if I like it or not. Then I usually make some adjustments and only after…

This takes all the soul out of programming, not sure why anyone likes to use llms like this.

Because from a business point of view, they just want a feature to be built, they really care about the code if it works.

Re: A Research Preview of Codex

#320

Earlier quoted context omitted.

Hiring of juniors is basically dead these days and it has been like this for about 10 years and I hate it. I remember when I was a junior in 2014 there were actually startups who would hire cohorts of juniors (like 10 at a time, fresh out of CS degree sort of folks with almost no applied coding experience) and then train them up to senior for a few years, and then a small number will stay and the rest will go elsewhe…

> But at the same time, to be fair, this was a way easier task in the early 00s The best junior I've hired was a big contributor to an open source library we were starting to use. I think there's still lots of opportunity for honing your skill, and showing it off, outside of schools.

Agreed. One of my mentors early on was a self taught engineer and honestly I'd trust him a lot more than some of the engineers with degrees
Post reply on HN