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

231–240 of 309 posts

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

#231

Post by ivanbalepin »

chasd00 wrote: post #170
culi wrote: post #147

Earlier quoted context omitted.

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

I don’t know how to measure maintainability but the AI generated code I’ve seen in my projects is pretty plain vanilla standard patterns with comments. So less of a headache than a LOT of human code I’ve seen. Also, one thing the agents are good at, at least in my experience so far, is documenting existing code. This goes a long ways in maintenance, it’s not always perfect but as the saying goes documentation is like…

by "maintainability" and "rarely remembered by the engineer" i'm assuming the bigger concern (beyond commenting and sane code) is once everyone starts producing tons of code without looking - and reading(reviewing) code is, to me at least, much harder than writing - then all of this goes unchecked:

* subtle footguns

* hallucinations

* things that were poorly or incompletely expressed in the prompt and ended up implemented incorrectly

* poor performance or security bugs

other things (probably correctable by fine-tuning the prompt and the context):

* lots of redundancy

* comments that are insulting to the intelligence (e.g., "here we instantiate a class")

* ...

not to mention reduced human understanding of the system and where it might break or how this implementation is likely to behave. All of this will come back to bite during maintenance.

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

#232

Post by K0balt »

fragmede wrote: post #139
Ancalagon wrote: post #133

Earlier quoted context omitted.

This mirrors my experience exactly. Vibe coding straight up does not work for any serious code.

Todo web apps aren't serious code, I can buy that, but in your mind, what is? Are compilers "serious code"? https://www.anthropic.com/engineering/building-c-compiler Like, I'm sure it's just laundering gcc's source at some level, but if Claude can handle making a compiler, either we have to reframe a compiler as "not serious", or, well, come up with a different definition for what entails "serious" code.

Vibe coding doesn’t work for the imbedded system code that I am working on, which includes layered state machines, hardware drivers, and wire level protocol stacks. But supervised AI code generation definitely does work.

You need a highly refined sense of “smell” and intuition about architecture and data design, but if you give good specifications and clear design goals and architectural guidance, it’s like managing a small team but 12x faster iteration.

I sometimes am surprised with feature scope or minor execution details but usually whenever I drill down I’m seeing what I expected to see, even more so than with humans.

If I didn’t have the 4 decades of engineering and management experience I wouldn’t be able to get anything near the quality or productivity.

It’s an ideal tool for seasoned devs with experience shipping with a team. I can do the work of a team of 5 in this type of highly technical greenfield engineering, and I’m shipping better code with stellar documentation… and it’s also a lot less stressful because of the lack of interpersonal dynamics.

But… there’s no way I would give this to a person without technical management experience and expect the same results, because the specification and architectural work is critical, and the ability to see the code you know someone else is writing and understand the mistakes they will probably make if you don’t warn them away from it is the most important skillset here.

In a lot of ways I do fear that we could be pulling up the ladder, but if we completely rethink what it means to be a developer we could teach with an emphasis on architecture, data structures, and code/architecture intuition we might be able to prepare people to step into the role.

Otherwise we will end up with a lot of garbage code that mostly works most of the time and breaks in diabolically sinister ways.

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

#233

Post by sinuhe69 »

The article said they called for triple junior hire but cut 1000 jobs a month later, “so the number of jobs stay roughly the same”.

Certainly they didn’t mean 1000 junior positions were cut. So what they really want to say is that they cut senior positions as a way of saving cost/make profit in the age of AI? Totally contrary to what other companies believe? Sounds quite insane to me!

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

#234

Post by fragmede »

rTX5CMRXIfFG wrote: post #176
fragmede wrote: post #139

Earlier quoted context omitted.

Todo web apps aren't serious code, I can buy that, but in your mind, what is? Are compilers "serious code"? https://www.anthropic.com/engineering/building-c-compiler Like, I'm sure it's just laundering gcc's source at some level, but if Claude can handle making a compiler, either we have to reframe a compiler as "not serious", or, well, come up with a different definition for what entails "serious" code.

Ticketing, payroll, point of sale, banking, HFT, e-commerce, warehouse, shipping… how have you not thought of these

The ones I've thought of, and the one's you've thought of, and the ones Ancalagon has in their mind are three partially disjoint sets, but there's probably some intersection, which we can then use as a point of discussion. Given that "serious code" isn't a rigorously defined industry term, maybe you could be less rude?

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

#235

Post by sublinear »

halamadrid wrote: post #150

I pay $20 for OpenAI and codex makes me incredibly productive. With very careful prompts aimed at tiny tasks, I can review, fix and get a lot of things done. I’ll happily pay up to $2k/month for it if I was left with no choice, but I don’t think it will ever get that expensive since you can run models locally and it could have the same result. That being said, my outputs are similarish in the big picture. When I get…

Bro, nobody wants to hear about the hustle anymore. We're in the second half of this decade now.

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

#236

Post by rgblambda »

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

chasd00 did mention that this was for consulting projects, where presumably there's a handover to another team after a period of time. Maintainability was never a high priority for consultants.

But in general I agree with your point.

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

#237

Post by munch117 »

vidarh wrote: post #214
hackingonempty wrote: post #212

Earlier quoted context omitted.

I'd love to look at what you consider to be good prompts if you could provide a link.

You'd be surprised how low the bar is. What I'm seeing is down to the level of people not writing complete sentences. There doesn't need to be any "magic" there. Just clearly state your requirements. And start by asking the model to plan out the changes and write a markdown file with a plan first (I prefer this over e.g. Claude Code's plan mode, because I like to keep that artefact), including planning out tests. If…

> Just clearly state your requirements.

Nothing new here. Getting users to clearly state their requirements has always been like pulling teeth. Incomplete sentences and all.

If the people you are teaching are developers, they should know better. But I'm not all that surprised if many of them don't. People will be people.

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

#238

Post by lbreakjai »

nunez wrote: post #223
chasd00 wrote: post #170

Earlier quoted context omitted.

I don’t know how to measure maintainability but the AI generated code I’ve seen in my projects is pretty plain vanilla standard patterns with comments. So less of a headache than a LOT of human code I’ve seen. Also, one thing the agents are good at, at least in my experience so far, is documenting existing code. This goes a long ways in maintenance, it’s not always perfect but as the saying goes documentation is like…

I find it funny that we, collectively, are now okay with comments in the code. I remember the general consensus on this _not even two years ago_ being that the code should speak for itself and that comments harm more than help. This matters less when agentic tools are doing the maintenance, I suppose, but the backslide in this practice is interesting.

It's never been the consensus. As far back as I can remember, the wisdom was always to comment why the code does what it does if needed, and to avoid saying what the code does.

Saying that function "getUserByName" fetches a user by name is redundant. Saying that a certain method is called because of a quirk in a legacy system is important.

I regularly implement financial calculations. Not only do I leave comments everywhere, I tend to create a markdown file next to the function, to summarise and explain the context around the calculation. Just plain english, what it's supposed to do, the high level steps, etc.

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

#239

Post by vidarh »

nunez wrote: post #225
vidarh wrote: post #214

Earlier quoted context omitted.

You'd be surprised how low the bar is. What I'm seeing is down to the level of people not writing complete sentences. There doesn't need to be any "magic" there. Just clearly state your requirements. And start by asking the model to plan out the changes and write a markdown file with a plan first (I prefer this over e.g. Claude Code's plan mode, because I like to keep that artefact), including planning out tests. If…

Not surprising. Many folks struggle with writing (hence why ChatGPT is so popular for writing stuff), so people struggling to coherently express what they want and how makes sense. But the big models have come a long way in this regard. Claude + Opus especially. You can build something with a super small prompt and keep hammering it with fix prompts until you get what you want. It's not efficient, but it's doable, an…

This is exactly it. A lot of people use it that way. And it's still a vast improvement, but they could also generally do a lot better with some training. I think this is one of the areas where you'll unfortunately see a big gap developing between developers who do this well, and have the models work undisturbed for longer and longer while doing other stuff, and those who ends up needing a lot more rework than necessary.

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

#240

Post by vidarh »

munch117 wrote: post #237
vidarh wrote: post #214

Earlier quoted context omitted.

You'd be surprised how low the bar is. What I'm seeing is down to the level of people not writing complete sentences. There doesn't need to be any "magic" there. Just clearly state your requirements. And start by asking the model to plan out the changes and write a markdown file with a plan first (I prefer this over e.g. Claude Code's plan mode, because I like to keep that artefact), including planning out tests. If…

> Just clearly state your requirements. Nothing new here. Getting users to clearly state their requirements has always been like pulling teeth. Incomplete sentences and all. If the people you are teaching are developers, they should know better. But I'm not all that surprised if many of them don't. People will be people.

You're right, they should know better, but I think a lot of them have gotten away with it because most of them are not expected to produce written material setting out missing assumptions etc. and breaking down the task into more detail before proceeding to work, so a lot have never gotten the practice.

Once people have had the experience of being a lead and having to pass tasks to other developers a few times, most seem to develop this skill at least to a basic level, but even then it's often informal and they don't get enough practice documenting the details in one go, say by improving a ticket.

Post reply on HN