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

IBM tripling entry-level jobs after finding the limits of AI adoption

fortune.com

Post reply on HN
Print view View original

241–250 of 309 posts

Re: IBM tripling entry-level jobs after finding the limits of AI adoption

#241

Post by thegrim000 »

chasd00 wrote: post #116

Some stats are trickling out in my company. Code heavy consulting projects show about 18% efficiency gains but I have problems with that number because no one has been able to tell me how it was calculated. Story points actual vs estimated is probably how it was done but that’s nonsensical because we all know how subjective estimates and even actuals are. It’s probably impossible to get a real number that doesn’t hav…

Hint: Make sure the people giving you the efficiency improvement numbers don't have a vested interest in giving you good numbers. If so, you can not trust the numbers.

Reminds me of my last job where the team that pushed React Native into the codebase were the ones providing the metrics for "how well" React Native was going. Ain't no chance they'd ever provide bad numbers.

Re: IBM tripling entry-level jobs after finding the limits of AI adoption

#242

Post by thegrim000 »

layer8 wrote: post #34

The title is a bit misleading. Reading the article, the argument seems to be that entry-level applicants (are expected to) have the highest AI literacy, so they want them to drive AI adoption.

"AI is going to wipe out junior developers!"

They actually hire more junior developers

"Uhh .. to adopt AI better they're hiring more junior developers!"

Re: IBM tripling entry-level jobs after finding the limits of AI adoption

#243

Post by easterncalculus »

thegrim000 wrote: post #242
layer8 wrote: post #34

The title is a bit misleading. Reading the article, the argument seems to be that entry-level applicants (are expected to) have the highest AI literacy, so they want them to drive AI adoption.

"AI is going to wipe out junior developers!" They actually hire more junior developers "Uhh .. to adopt AI better they're hiring more junior developers!"

This cope is especially low quality with the context that this is just another purge of older workers at IBM.

Re: IBM tripling entry-level jobs after finding the limits of AI adoption

#244

Post by bluGill »

joquarky wrote: post #205
bluGill wrote: post #100

Earlier quoted context omitted.

they are good at some weird problems - but also write some really bad code and sometimes come up with wrong answers.

That's why you write tests.

There are whole classes of problems that tests can't catch.

Re: IBM tripling entry-level jobs after finding the limits of AI adoption

#245

Post by belter »

ChadMoran wrote: post #165
belter wrote: post #110

Earlier quoted context omitted.

Details would help your argument. Since many did the same thing, before the AI wave... Is the business 3 months old now?

It's not an argument, it's a fact.

Its also a fact my stopped clocked will show the correct time two times a day :-)

Re: IBM tripling entry-level jobs after finding the limits of AI adoption

#246

Post by ineedasername »

Twirrim wrote: post #217
ineedasername wrote: post #209

Earlier quoted context omitted.

Same ? Not quite as good as that. But google’s Gemma 3 27B is highly similar to their last Flash model. The latest Qwen3 variants are very good, to my need at least they are the best open coders, but really— here’s the thing: There’s so many varieties, specialized to different tasks or simply different in performance. Maybe we’ll get to a one-size fits all at some point, but for now trying out a few can pay off. It a…

I get tolerable performance out of a quantized gpt-oss 20b on an old RTX3050 I have kicking around (I want to say 20-30 tokens/s, or faster when cache is effective). It's appreciably faster on the 4060. It's not quite ideal for more interactive agentic coding on the 3050, but approaching it, and fitting nicely as a "coding in the background while I fiddle on something else" territory.

Yeah, tokens per second can very much influence the work style and therefore mindset a person should bring to usage. You can also build on the results of a faster but less than SOTA class model in different ways. I can let a coding tuned 7-12b model “sketch” some things at higher speed, or even a variety of things, and I can review real time, and pass off to a slower more capable model to say “this is structural sound, or at least the right framing, tighten it all up in the following ways…” and run in the background.

Re: IBM tripling entry-level jobs after finding the limits of AI adoption

#247

Post by techsocialism »

jerlam wrote: post #8

Probably not on the IBM jobs site yet, where the number of entry level jobs is low compared to the size of the company (~250k): https://www.ibm.com/careers/search?field_keyword_18[0]=Entry... Total: 240 United States: 25 India: 29 Canada: 15

[dead]

Re: IBM tripling entry-level jobs after finding the limits of AI adoption

#248

Post by selimthegrim »

geraneum wrote: post #66
small_model wrote: post #42

They hire juniors, give them Claude Code and some specs and save a mid/senior devs salary. I believe coding is over for SWE's by end of 2027, but will take time to diffuse though the economy hence still need some cheap labour for a few years, given the H1-B ban this is one way without offshoring.

I want the big_model take.

These are just the draft tokens.

Re: IBM tripling entry-level jobs after finding the limits of AI adoption

#249

Post by kelipso »

pickettd wrote: post #136
Morromist wrote: post #131

Earlier quoted context omitted.

I hear this every day, and I'm sure its true sometimes, but where is the tsunami of amazing software LLM users are producing? Where are the games that make the old games look like things from a bygone era? Where are the updates to the software that I currently use that greatly increase it capabilities? I have seen none of this. I get that it takes a long time to make software, but people were making big promises a ye…

Reddit and GitHub are littered with people launching new projects and appear to be way more feature-rich than new tool/app launches from previous years. I think it is a lot harder to get noticed with a new tool/app new because of this increase in volume of launches. Also weekend hackathon events have completely/drastically changed as an experience in the last 2-3 years (expectations and also feature-set/polish of wor…

Specifically about custom CUDA kernels, I’ve implemented them with AI that significantly sped up the code in this project I worked on. Didn’t know how to code these kernels at all, but I implemented and tested a couple of variations and got it running fast in just two days. Basically impossible for me before AI coding (well not impossible but it would have taken me many weeks, so I wouldn’t have tried it).

Re: IBM tripling entry-level jobs after finding the limits of AI adoption

#250

Post by smileysteve »

culi wrote: post #147
chasd00 wrote: post #116

Some stats are trickling out in my company. Code heavy consulting projects show about 18% efficiency gains but I have problems with that number because no one has been able to tell me how it was calculated. Story points actual vs estimated is probably how it was done but that’s nonsensical because we all know how subjective estimates and even actuals are. It’s probably impossible to get a real number that doesn’t hav…

More interesting imo would be a measure of maintainability. I've heard that code that's largely written by AI is rarely remembered by the engineer that submitted even a week after merging You're almost "locked in" to using more AI on top of it then. It may also make it harder to give estimates to non-technical staff on how long it'd take to make a change or implement a new feature

> engineer that submitted it

This is a poor metric as soon as you reach a scale where you've hired an additional engineer, where 10% annual employee turnover reflects > 1 employee, much less the scale where a layoff is possible.

It's also only a hope as soon as you have dependencies that you don't directly manage like community libraries.

Post reply on HN