Still not clear to me what is meant by "ai" now? My sense is that it is a marketing term for LLM. Is that accurate? Do people now consider any ML project to be ai?
That's what I was alluding to, I don't think it defines ai, do you? These pieces seem like classical ML pieces to me plus LLM. Is that ai? Like from a technical standpoint, is it clearly defined?
AI is defined by algorithmic decision making. ML, a subset, is about using pattern matching with statistical uncertainty in that decision making. GenAI uses algorithms of classical ML, including deep learning based on neural networks, to encode the decode input to output, jargonized as a prompt. Whether diffusion or next token prediction, the patterns are learned during ML training.
AI is not totally encapsulated by ML. For example, reinforcement learning is often considered distinct in some AI ontologies. Decision rules and similar methods from the 1970s and 1980s are also included though they highlight the algorithmic approach versus the ML side.
There are certainly many terms used and misused by current marketing (especially the bitcoin bro grifters who saw AI as an out of a bad set of assets), but there actually is clarity to the terms if one considers their origins.
"AI is not totally encapsulated by ML" that's the part I haven't been able to put my fingers on. I understand that it's not encapsulated, ML is not intelligence, it's gradient descent. So what is in that set AI - {ML}?
Honestly it's a large enough library with enough weirdness and untested areas, footguns, and bugs that I'd deem it just as valid as React for example.
Why did tensor_parallel have output += mod instead of output = output + mod? (The += breaks backprop). Nobody tested it! A user had to notice it was broken and make a PR!
For an uni course I tried to fine tune Gemma in a few days, it wasn't easy because tutorials often were written with old version of hf libraries that now work differently, there's a lot of areas to improve, everything still seems kinda fresh and so it's a pain in the ass to deviate from simple walkthroughs to something tailored to your needs.
> Even when you live and breathe AI, the job titles can feel like a moving target. I can only imagine how mystifying they must be to everyone else.
> Because the field is actively evolving, the language we use keeps changing. Brand new titles appear overnight or, worse, one term means three different things at three different companies.
How can you write that and not realise “maybe this is all made up bullshit and everyone is pulling titles out of their asses to make themselves look more important and knowledgeable than they really are, thus I shouldn’t really be wasting my time giving the subject any credence”? If you’re all in on the field and can’t keep up, why should anyone else care?
I agree some analysis of job postings or pay distributions by title would’ve made this article stronger. The titles are less relevant than the job descriptions, which are task specific and not bullshit.
I thought this was going to be satire. Software engineer job titles are already pretty bogus (Senior Principal Distinguished Engineer, anyone?), and the AI trend has only created more jobs with nebulous descriptions around "doing AI".
They could just call it "Field Service Tech" like the rest of the universe. I understand using title inflation/deflation to keep pushing the engineer title (and pay expectation) into the dirt, but still, this is dumb.
Ehh, I don’t think folks are claiming to be active duty or former military personnel, which is the bar for stolen valor accusations in my book. I agree with the sentiment but not with the determination of finding fault. Folks hired for a specific role rarely pick their own job titles.
I assume if you are applying to AI roles, you use AI to find and possibly apply for you. So, we don't even need to understand what the titles mean because AI can do it for us.
I hope AI attracts all the people I hate to work with the most in software engineering. The pretenders, the hype chasers, the people looking for money, the ladder climbers. I hope they all become AI engineers and leave our profession alone.
Some already became "data scientists" and "ML engineers", I hope this AI wave takes the rest.
Seems about right. My official title at work is "AI Engineer". What does that mean exactly?
- I'm not a researcher and not fine tuning or deploying models on GPUs
- I have a math/traditional ML background, but my explanation of how transformers, tokenizers, etc work would be hand-wavy at best.
- I'm a "regular engineer" in the sense I'm following many of the standard SWE/SDLC practices in my org.
- I'm exclusively focused on building AI features for our product, I wear a PM hat too.
- I'm pretty tuned in to the latest model releases and capabilities of frontier models, and consider being able to articulate that information part of my job.
- I also use AI heavily to produce code, which is helpfully a pretty good way to get a sense for model capabilities.
Do I deserve a special job title...maybe? I think there's definitely an argument that "AI Engineering" really isn't a special thing, and considering how much of my day to day is pure integration work with the actual product, I can see that. OTOH, part of my job and my value at work is very product based. I pay a lot of attention to what other people in the industry are doing, new model releases, and how others are building things, since it's such a new area and there's no "standard playbook" yet for many things.
I actually quite enjoy it since there's a ton of opportunity to be creative. When AI first started becoming big I thought about doing the other direction - leveraging my math/ML background to get deeper into GPUs and MLOps/research-lite kind of work. Instead I went in a more producty direction, which I don't regret yet.
The author’s definitions suggest you should have “Applied” in your title, which I like, but my impression is that “applied” roles so vastly outnumber “creation of models” roles globally that it’s actually the latter that would benefit from a modifier. For now, you have to rely on context (mostly the nature of the company’s primary output) when trying to interpret something like a job posting or an acquaintance’s title.
It’s not that crazy to add a couple of domain-specific prediction heads to a BERT-family pretrained model and then do a quick fine tuning. By volume that’s less common but I would guess most people are just using things off the shelf and might not even consider themselves AI engineers. I have no frame of reference though.
We all know the AI part is largely meaningless because of the hype and nonsense, but what defines you as an engineer? When you consider that classical engineers are responsible for the correctness of their work, combining it with AI seems like a joke
> "When you consider that classical engineers are responsible for the correctness of their work"
Woah hang on, I think this betrays a severe misunderstanding of what engineers do.
FWIW I was trained as a classical engineer (mechanical), but pretty much just write code these days. But I did have a past life as a not-SWE.
Most classical engineering fields deal with probabilistic system components all of the time. In fact I'd go as far as to say that inability to deal with probabilistic components is disqualifying from many engineering endeavors.
Process engineers for example have to account for human error rates. On a given production line with humans in a loop, the operators will sometimes screw up. Designing systems to detect these errors (which are highly probabilistic!), mitigate them, and reduce the occurrence rates of such errors is a huge part of the job.
Likewise even for regular mechanical engineers, there are probabilistic variances in manufacturing tolerances. Your specs are always given with confidence intervals (this metal sheet is 1mm thick +- 0.05mm) because of this. All of the designs you work on specifically account for this (hence safety margins!). The ways in which these probabilities combine and interact is a serious field of study.
Software engineering is unlike traditional engineering disciplines in that for most of its lifetime it's had the luxury of purely deterministic expectations. This is not true in nearly every other type of engineering.
If anything the advent of ML has introduced this element to software, and the ability to actually work with probabilistic outcomes is what separates those who are serious about this stuff vs. demoware hot air blowers.
You're right in a descriptive manner, but I also think the parent comment's point is about correctness and not determinism.
In other engineering fields correctness-related-guarantees can often be phrased in probabilistic ways, e.g. "This bridge will withstand a 10-year flood event but not a 100-year flood event", but underneath those guarantees are hard deterministic load estimates with appropriate error margins.
And I think that's where the core disagreement between you and the parent comment lies. I think they're trying to say AI generated code-pushers are often getting fuzzy on speccing out the behavior guarantees of their own software. In some ways the software industry has _always_ been bad at this, despite working with deterministic math, surprise software bugs are plentiful, but vibe-coding takes this to another level.
(This is my best-case charitable understanding of what they're saying, but also happens to be where I stand)
> "I think they're trying to say AI generated code-pushers are often getting fuzzy on speccing out the behavior guarantees of their own software."
I agree, and I think that's the root of the years-long argument of whether programmers are "real" engineers, where "real engineering" implies a level of rigor about the existence of and adherence to specifications.
My take on this is though that this unseriousness really has little to with AI and entirely to do with the longstanding culture of software generally. In fact I'd go as far as to say that pre-LLM ML was better about this than the rest of the industry at-large.
I've had the good fortune to be working in this realm since before LLMs became the buzzword - most ML teams had well-quantified model behaviors! They knew their precision and recall! You kind of had to, because it was very hard to get models to do what you wanted, plus companies involved in this space generally cared about outcomes.
Then we got LLMs, when you can superficially produce really impressive results easily, and the dominance of vibes over results. I can't stand it either, and mostly am just waiting for most of these things to go bust so we can go back to probabilistic systems where we give a shit about quantification.
I think part of the issue with the lack of "real" quantification in the results of LLMs is that the output and problem domain is so ill-defined. With standard neural nets (and other kinds of ML) classifiers, regression models and reinforcement models all had very narrow, domain specific problems they were solving. It was a no-brainer to measure directly how your vision classifier performs against a radiologist in determining whether an image corresponds to lung cancer.
Now we've opened up the output to a wide variety of open-ended domains: natural languages, programming languages, images and videos. Since the output domain is inherently subjective, it's hard to get a good handle on their usefulness, let alone getting people to agree on that. Hence the never-ending discourse around them.
This seems to me patently absurd, because LLMs are not part of the probabilistic environment of the domain you're engineering; rather, you're injecting new probabilistic inputs into your system. That seems to me to be a wholly different category, and wildly misrepresents how an engineer is supposed to operate and think.
> "because LLMs are not part of the probabilistic environment of the domain you're engineering; rather, you're injecting new probabilistic inputs into your system"
You do this as a process engineer also. You don't have to have a human operator inserting the stator into the motor housing, you could have a robot do it (it would cost a lot more) and be a lot more deterministic.
After the stator is in the housing you don't need to have a human operator close it using a hand tool. You could do it robotically in which case the odds of failure are much lower. That also costs a lot.
You choose to insert probabilistic components into the system because you've evaluated the tradeoffs around it and decided it's worth it.
Likewise you could do sentiment analysis of a restaurant review in a non-probabilistic manner - there are many options! But you choose a probabilistic ML model because it does a better job overall and you've evaluated the failure modes.
Nicely said, I'm going to borrow some language here. I've talked a little to my coworkers about how it's possible the future of SWE looks more like "build a complex system with AI and test it to death to make sure it fits inside the performance envelope you require".
Hard to tell what you're even trying to say here. I am obviously responsible for the correctness of my work. "AI Engineer" does not generally mean "AI-Assisted Engineer", thought that was clear from my post.
Who cares? The word "engineer" is meaningless now and anyone can be a self-proclaimed engineer whenever they feel like it. Will anyone double check or even reject you for an engineering job when you are not? Absolutely not! Take a bootcamp, submit plenty of PRs correcting typos, and pass the interview with the help of AI and you basically made it, dreams come true!!
Agree 100%, even blue collar workers guard their profession. Hell, I was talking to a friend and they rejected her for a retail job because she had never worked in retail before. Engineering on the other hand has zero gatekeeping - it's a sign spinner job right now. Just do a few humiliation rituals like daily standup and you're the perfect candidate!
In Dubai, the poor underpaid folks cleaning the roads and gutters late at night are called "Cleaning Engineers" and "Garden Engineers". It's honestly sad, almost a mockery.
protecting it? ha! we’re just the first group of greater fools who thought it applied to us in the first place (hell, i became an “engineer” with an Associates degree!). just because we benefited from the prestige doesn’t always mean we’re actually held to the classical standards of engineers.
> what do you think of recent MIT news that 95% gen ai projects don't do anything valuable at all ?
Worth noting that a project that ends up “doing nothing” isn’t the same as a project that had/created no value.
Even some projects that in hindsight were deterministic lemons.
Assuming compute resources continue scaling up, and architectures keep improving, AI change now has an everything, everywhere, all the time, scope. Failing fast is necessarily going to have a substantial dimension.
Almost nobody here wanted to be an 'AI researcher' until late 2022 when the money started pouring into AI researchers.
Now with this article clearly defining each of these roles (AI researcher being the most serious out of the rest) everyone now suddenly wants to be one.
"AI" is a vast field which spans beyond deep learning and LLMs. Unless you are very serious and fully interested in actually advancing the field, don't bother.
Why not robotics or electrical engineer? Not cool enough?
Still not clear to me what is meant by "ai" now? My sense is that it is a marketing term for LLM. Is that accurate? Do people now consider any ML project to be ai?
You should read the post. You might find the “domain” discussion interesting.
That's what I was alluding to, I don't think it defines ai, do you? These pieces seem like classical ML pieces to me plus LLM. Is that ai? Like from a technical standpoint, is it clearly defined?
It’s not clearly defined. Nowadays by default it means generative AI (https://en.wikipedia.org/wiki/Generative_artificial_intellig...).
AI is defined by algorithmic decision making. ML, a subset, is about using pattern matching with statistical uncertainty in that decision making. GenAI uses algorithms of classical ML, including deep learning based on neural networks, to encode the decode input to output, jargonized as a prompt. Whether diffusion or next token prediction, the patterns are learned during ML training.
AI is not totally encapsulated by ML. For example, reinforcement learning is often considered distinct in some AI ontologies. Decision rules and similar methods from the 1970s and 1980s are also included though they highlight the algorithmic approach versus the ML side.
There are certainly many terms used and misused by current marketing (especially the bitcoin bro grifters who saw AI as an out of a bad set of assets), but there actually is clarity to the terms if one considers their origins.
"AI is not totally encapsulated by ML" that's the part I haven't been able to put my fingers on. I understand that it's not encapsulated, ML is not intelligence, it's gradient descent. So what is in that set AI - {ML}?
My heuristic has been
ML engineer => knows pytorch
AI engineer => knows huggingface
Researcher => implements papers
I know these heuristics are imperfect but I call myself an MLE because it’s closest to my skillset.
I saw "Hugginface" listed alongside C++, React, and SQL as skills on a resume recently. Wasn't quite sure what to make of that.
Honestly it's a large enough library with enough weirdness and untested areas, footguns, and bugs that I'd deem it just as valid as React for example.
Why did tensor_parallel have output += mod instead of output = output + mod? (The += breaks backprop). Nobody tested it! A user had to notice it was broken and make a PR!
For an uni course I tried to fine tune Gemma in a few days, it wasn't easy because tutorials often were written with old version of hf libraries that now work differently, there's a lot of areas to improve, everything still seems kinda fresh and so it's a pain in the ass to deviate from simple walkthroughs to something tailored to your needs.
Researcher = WRITES papers.
Should’ve included “Member of Technical Staff”
> Even when you live and breathe AI, the job titles can feel like a moving target. I can only imagine how mystifying they must be to everyone else.
> Because the field is actively evolving, the language we use keeps changing. Brand new titles appear overnight or, worse, one term means three different things at three different companies.
How can you write that and not realise “maybe this is all made up bullshit and everyone is pulling titles out of their asses to make themselves look more important and knowledgeable than they really are, thus I shouldn’t really be wasting my time giving the subject any credence”? If you’re all in on the field and can’t keep up, why should anyone else care?
I agree some analysis of job postings or pay distributions by title would’ve made this article stronger. The titles are less relevant than the job descriptions, which are task specific and not bullshit.
I thought this was going to be satire. Software engineer job titles are already pretty bogus (Senior Principal Distinguished Engineer, anyone?), and the AI trend has only created more jobs with nebulous descriptions around "doing AI".
I saw an "Exalted engineer" once, not kidding.
you might not be kidding, hopefully they were.
when you decide titles don't matter and let people choose their own, you get some titles that weren't created in total seriousness.
Senior Anything-But-C-Level-Compensation-Package Engineer.
I wanna just be a webmaster again.
I think you mean webmain.
How about promptmaster? ;)
AI-snake charmer.
Yeah, same. I was actually disappointed when I saw that they were taking the titles seriously
"Forward Deployed Engineer" is a bodyshop with LLM.
Pretty sure this title came from Palentir who got it from the military.
"Forward Deployed Software Engineer - This role includes working in locations that include risks of getting shot and possibly killed"
Weell, you probably don't want to serve "Backwards Deployed Engineers" to your clients
They could just call it "Field Service Tech" like the rest of the universe. I understand using title inflation/deflation to keep pushing the engineer title (and pay expectation) into the dirt, but still, this is dumb.
I also dislike the term. It feels concocted to evoke “tacticool” vibes.
Unless you’re pushing new firmware onto a drone in Ukraine, FDE is stolen valor.
Might I interest you in "In the trenches" and "war stories"?
Ehh, I don’t think folks are claiming to be active duty or former military personnel, which is the bar for stolen valor accusations in my book. I agree with the sentiment but not with the determination of finding fault. Folks hired for a specific role rarely pick their own job titles.
I assume if you are applying to AI roles, you use AI to find and possibly apply for you. So, we don't even need to understand what the titles mean because AI can do it for us.
I'm tempted to use /s, but then again...
I hope AI attracts all the people I hate to work with the most in software engineering. The pretenders, the hype chasers, the people looking for money, the ladder climbers. I hope they all become AI engineers and leave our profession alone.
Some already became "data scientists" and "ML engineers", I hope this AI wave takes the rest.
Seems about right. My official title at work is "AI Engineer". What does that mean exactly?
- I'm not a researcher and not fine tuning or deploying models on GPUs
- I have a math/traditional ML background, but my explanation of how transformers, tokenizers, etc work would be hand-wavy at best.
- I'm a "regular engineer" in the sense I'm following many of the standard SWE/SDLC practices in my org.
- I'm exclusively focused on building AI features for our product, I wear a PM hat too.
- I'm pretty tuned in to the latest model releases and capabilities of frontier models, and consider being able to articulate that information part of my job.
- I also use AI heavily to produce code, which is helpfully a pretty good way to get a sense for model capabilities.
Do I deserve a special job title...maybe? I think there's definitely an argument that "AI Engineering" really isn't a special thing, and considering how much of my day to day is pure integration work with the actual product, I can see that. OTOH, part of my job and my value at work is very product based. I pay a lot of attention to what other people in the industry are doing, new model releases, and how others are building things, since it's such a new area and there's no "standard playbook" yet for many things.
I actually quite enjoy it since there's a ton of opportunity to be creative. When AI first started becoming big I thought about doing the other direction - leveraging my math/ML background to get deeper into GPUs and MLOps/research-lite kind of work. Instead I went in a more producty direction, which I don't regret yet.
The author’s definitions suggest you should have “Applied” in your title, which I like, but my impression is that “applied” roles so vastly outnumber “creation of models” roles globally that it’s actually the latter that would benefit from a modifier. For now, you have to rely on context (mostly the nature of the company’s primary output) when trying to interpret something like a job posting or an acquaintance’s title.
It’s not that crazy to add a couple of domain-specific prediction heads to a BERT-family pretrained model and then do a quick fine tuning. By volume that’s less common but I would guess most people are just using things off the shelf and might not even consider themselves AI engineers. I have no frame of reference though.
We all know the AI part is largely meaningless because of the hype and nonsense, but what defines you as an engineer? When you consider that classical engineers are responsible for the correctness of their work, combining it with AI seems like a joke
> "When you consider that classical engineers are responsible for the correctness of their work"
Woah hang on, I think this betrays a severe misunderstanding of what engineers do.
FWIW I was trained as a classical engineer (mechanical), but pretty much just write code these days. But I did have a past life as a not-SWE.
Most classical engineering fields deal with probabilistic system components all of the time. In fact I'd go as far as to say that inability to deal with probabilistic components is disqualifying from many engineering endeavors.
Process engineers for example have to account for human error rates. On a given production line with humans in a loop, the operators will sometimes screw up. Designing systems to detect these errors (which are highly probabilistic!), mitigate them, and reduce the occurrence rates of such errors is a huge part of the job.
Likewise even for regular mechanical engineers, there are probabilistic variances in manufacturing tolerances. Your specs are always given with confidence intervals (this metal sheet is 1mm thick +- 0.05mm) because of this. All of the designs you work on specifically account for this (hence safety margins!). The ways in which these probabilities combine and interact is a serious field of study.
Software engineering is unlike traditional engineering disciplines in that for most of its lifetime it's had the luxury of purely deterministic expectations. This is not true in nearly every other type of engineering.
If anything the advent of ML has introduced this element to software, and the ability to actually work with probabilistic outcomes is what separates those who are serious about this stuff vs. demoware hot air blowers.
You're right in a descriptive manner, but I also think the parent comment's point is about correctness and not determinism.
In other engineering fields correctness-related-guarantees can often be phrased in probabilistic ways, e.g. "This bridge will withstand a 10-year flood event but not a 100-year flood event", but underneath those guarantees are hard deterministic load estimates with appropriate error margins.
And I think that's where the core disagreement between you and the parent comment lies. I think they're trying to say AI generated code-pushers are often getting fuzzy on speccing out the behavior guarantees of their own software. In some ways the software industry has _always_ been bad at this, despite working with deterministic math, surprise software bugs are plentiful, but vibe-coding takes this to another level.
(This is my best-case charitable understanding of what they're saying, but also happens to be where I stand)
> "I think they're trying to say AI generated code-pushers are often getting fuzzy on speccing out the behavior guarantees of their own software."
I agree, and I think that's the root of the years-long argument of whether programmers are "real" engineers, where "real engineering" implies a level of rigor about the existence of and adherence to specifications.
My take on this is though that this unseriousness really has little to with AI and entirely to do with the longstanding culture of software generally. In fact I'd go as far as to say that pre-LLM ML was better about this than the rest of the industry at-large.
I've had the good fortune to be working in this realm since before LLMs became the buzzword - most ML teams had well-quantified model behaviors! They knew their precision and recall! You kind of had to, because it was very hard to get models to do what you wanted, plus companies involved in this space generally cared about outcomes.
Then we got LLMs, when you can superficially produce really impressive results easily, and the dominance of vibes over results. I can't stand it either, and mostly am just waiting for most of these things to go bust so we can go back to probabilistic systems where we give a shit about quantification.
I agree with that.
I think part of the issue with the lack of "real" quantification in the results of LLMs is that the output and problem domain is so ill-defined. With standard neural nets (and other kinds of ML) classifiers, regression models and reinforcement models all had very narrow, domain specific problems they were solving. It was a no-brainer to measure directly how your vision classifier performs against a radiologist in determining whether an image corresponds to lung cancer.
Now we've opened up the output to a wide variety of open-ended domains: natural languages, programming languages, images and videos. Since the output domain is inherently subjective, it's hard to get a good handle on their usefulness, let alone getting people to agree on that. Hence the never-ending discourse around them.
This seems to me patently absurd, because LLMs are not part of the probabilistic environment of the domain you're engineering; rather, you're injecting new probabilistic inputs into your system. That seems to me to be a wholly different category, and wildly misrepresents how an engineer is supposed to operate and think.
> "because LLMs are not part of the probabilistic environment of the domain you're engineering; rather, you're injecting new probabilistic inputs into your system"
You do this as a process engineer also. You don't have to have a human operator inserting the stator into the motor housing, you could have a robot do it (it would cost a lot more) and be a lot more deterministic.
After the stator is in the housing you don't need to have a human operator close it using a hand tool. You could do it robotically in which case the odds of failure are much lower. That also costs a lot.
You choose to insert probabilistic components into the system because you've evaluated the tradeoffs around it and decided it's worth it.
Likewise you could do sentiment analysis of a restaurant review in a non-probabilistic manner - there are many options! But you choose a probabilistic ML model because it does a better job overall and you've evaluated the failure modes.
These things really aren't that different.
Nicely said, I'm going to borrow some language here. I've talked a little to my coworkers about how it's possible the future of SWE looks more like "build a complex system with AI and test it to death to make sure it fits inside the performance envelope you require".
This comment is excellent.
I will be thinking about this comment for a bit. Thanks for this perspective!
Hard to tell what you're even trying to say here. I am obviously responsible for the correctness of my work. "AI Engineer" does not generally mean "AI-Assisted Engineer", thought that was clear from my post.
Who cares? The word "engineer" is meaningless now and anyone can be a self-proclaimed engineer whenever they feel like it. Will anyone double check or even reject you for an engineering job when you are not? Absolutely not! Take a bootcamp, submit plenty of PRs correcting typos, and pass the interview with the help of AI and you basically made it, dreams come true!!
Yeah the term "engineer" has been diluted into oblivion, and we only have ourselves to blame for not protecting it.
In German you're not even an engineer if you don't sometimes wear a hard hat or hold a screwdriver.
Agree 100%, even blue collar workers guard their profession. Hell, I was talking to a friend and they rejected her for a retail job because she had never worked in retail before. Engineering on the other hand has zero gatekeeping - it's a sign spinner job right now. Just do a few humiliation rituals like daily standup and you're the perfect candidate!
In Dubai, the poor underpaid folks cleaning the roads and gutters late at night are called "Cleaning Engineers" and "Garden Engineers". It's honestly sad, almost a mockery.
In the US, we've had "sanitation engineer" as the euphemistic neologism for "worker paid to pick up your garbage bins" for 50(?) years.
protecting it? ha! we’re just the first group of greater fools who thought it applied to us in the first place (hell, i became an “engineer” with an Associates degree!). just because we benefited from the prestige doesn’t always mean we’re actually held to the classical standards of engineers.
> I pay a lot of attention to what other people in the industry are doing, new model releases, and how others are building things,
what do you think of recent MIT news that 95% gen ai projects don't do anything valuable at all ?
> what do you think of recent MIT news that 95% gen ai projects don't do anything valuable at all ?
Worth noting that a project that ends up “doing nothing” isn’t the same as a project that had/created no value.
Even some projects that in hindsight were deterministic lemons.
Assuming compute resources continue scaling up, and architectures keep improving, AI change now has an everything, everywhere, all the time, scope. Failing fast is necessarily going to have a substantial dimension.
You would need to compare that to the baseline value creation from non-AI projects.
Not sure the majority of projects do anything valuable at all.
Sounds kind of aggressive but probably the number is up there.
Almost nobody here wanted to be an 'AI researcher' until late 2022 when the money started pouring into AI researchers.
Now with this article clearly defining each of these roles (AI researcher being the most serious out of the rest) everyone now suddenly wants to be one.
"AI" is a vast field which spans beyond deep learning and LLMs. Unless you are very serious and fully interested in actually advancing the field, don't bother.
Why not robotics or electrical engineer? Not cool enough?