Live data from Hacker News

The Rise of the AI Engineer

latent.space

81–90 of 159 posts

Re: The Rise of the AI Engineer

#81
post #48
post #45

Earlier quoted context omitted.

(author here) There are at least 4 killer apps ($100m/yr revenue potential) so far: 1. Generative Text for writing - Jasper AI going 0 to $75m ARR in 2 years 2. Generative Art for non-artists - Midjourney has by some accounts $80m ARR 3. Copilot for knowledge workers - GitHub’s Copilot has roughly 50-80m ARR as well 4. Conversational AI UX - ChatGPT probably has >$100m ARR by now, Bing Chat has brought $m's worth of…

The longer HN continues to doubt in AI's deliverables, the bigger our revenues and our moats can grow. Don't tell them. (It's not that hard to hit $1M ARR with a good AI product. So many classes of new products and solutions have opened up.)

I’m sure I could find a similar comment about cryptocurrency or NFTs. There’s always snake oil salesmen.

Re: The Rise of the AI Engineer

#82

Earlier quoted context omitted.

> They want to train their LLM with some inventory facts like... So are they actually intending to retrain their LLM every time the inventory changes? Because, otherwise, how is it going to "know" the current state of the inventory? This is useless after a single sale or a single new delivery without retraining. (And it's likely useless before that anyways.) And if they already have a database of inventory data with…

I would expect the solution is to take the NL question and get GPT to transform it into a SQL (or similar) statement to extract the data. Then another call (or set of calls) to generate "reports" summarizing the data returned by the DB query.

At which point, maybe a "GUI-interface" will be cheaper to build and maintain in the long run.

Now if AI could automagically update inventory data with what's actually physically happening on the lot, that would be cool.

Re: The Rise of the AI Engineer

#84

Earlier quoted context omitted.

> They want to train their LLM with some inventory facts like... So are they actually intending to retrain their LLM every time the inventory changes? Because, otherwise, how is it going to "know" the current state of the inventory? This is useless after a single sale or a single new delivery without retraining. (And it's likely useless before that anyways.) And if they already have a database of inventory data with…

I would expect the solution is to take the NL question and get GPT to transform it into a SQL (or similar) statement to extract the data. Then another call (or set of calls) to generate "reports" summarizing the data returned by the DB query.

That's a very generous take. But that application would be far more useful than just car inventories (the limited application described) and not trained in the manner described (on inventory data). It would be trained on transforming natural language to SQL (or other) query languages, and the application of that is exactly what we're seeing with code generation applications of LLMs (to the extent they're presently useful).

Re: The Rise of the AI Engineer

#85
I think it's all just being more accessible for people like me to integrate into applications via AIs. With that said - the barrier for entry also lowered substantially in the last few years to a point where implementing your own neural network from scratch with Pytorch is something you can do in a few (took me a weekend) hours coming in blind, but reading the docs and scrolling some existing repositories.

I remember a decade ago taking a stab at it and being very much over my head. Not sure if i'm getting older and there's less magic going on around it or if it's the ecosystem/docs/examples/pytorch/jax/hours of youtube content/etc but somewhere in there, at least for me personally, it's gotten much more accessible.

Re: The Rise of the AI Engineer

#86

I think it's all just being more accessible for people like me to integrate into applications via AIs. With that said - the barrier for entry also lowered substantially in the last few years to a point where implementing your own neural network from scratch with Pytorch is something you can do in a few (took me a weekend) hours coming in blind, but reading the docs and scrolling some existing repositories. I remember…

Personally I think it's a combination of

a) much better resources being available than in the past, which explain concepts clearly and in relatively simple terms, and

b) much better tooling existing now than ever before, so many things that you used to need to do "by hand" are now taken care of by relatively standardized tooling. Even just automatic differentiation engines are a huge deal, not having to backprop "by hand" (first release of TensorFlow was 7 years ago, so if you looked at it a decade ago I'm assuming you had to implement backprop yourself). Beyond that another jump was from Tensorflow's delayed execution/compilation model (it really was a headache to work around its APIs/set up the computation graph) as well as just having a generally ugly API, to PyTorch's "literal" setup, where it feels like you're just writing regular Python code and performing operations "normally"

Re: The Rise of the AI Engineer

#87

There's a bit of snake oil in all of that. By any means ML is a very specialized subfield, where you need solid math basis and a deep understanding of the science behind it all. But I struggle to see the same thing for AI. If by "AI engineers" you mean someone who builds an LLM*, then it's very much just ML. If you mean someone who integrates with the LLM someone else built, then it's very much just backend work. Sur…

Well, and frontend work. ChatGPT wouldn't been anywhere near the product it is without the webterface.

As far as PayPal integration, no but it makes you the subject matter expert (SME) in the room above a room full of people who aren't, and maybe aren't even developers.

Re: The Rise of the AI Engineer

#88

Earlier quoted context omitted.

I would expect the solution is to take the NL question and get GPT to transform it into a SQL (or similar) statement to extract the data. Then another call (or set of calls) to generate "reports" summarizing the data returned by the DB query.

That's a very generous take. But that application would be far more useful than just car inventories (the limited application described) and not trained in the manner described (on inventory data). It would be trained on transforming natural language to SQL (or other) query languages, and the application of that is exactly what we're seeing with code generation applications of LLMs (to the extent they're presently us…

Existing LLMs are already pretty good at this, no? The tricky part is mapping however the NL question refers to the various types of data to the actual column names, which is where I'd imagine some prompt engineering (or pretraining) would be necessary.

Re: The Rise of the AI Engineer

#89

There's a bit of snake oil in all of that. By any means ML is a very specialized subfield, where you need solid math basis and a deep understanding of the science behind it all. But I struggle to see the same thing for AI. If by "AI engineers" you mean someone who builds an LLM*, then it's very much just ML. If you mean someone who integrates with the LLM someone else built, then it's very much just backend work. Sur…

If you have React engineers, why couldn't you have AI engineers?

I think the post is right to try to delineate the roles of "builds LLMs or other ML models" and "uses those models", as (as you noted) the skills required are very different (vs. "creates a JS framework" vs "uses a JS framework" are the same skills, just on another level).

"AI engineer" is, as you say, inaccurate, but as swyx says, it's least cringy of the alternatives.

> Sure, you might need a few days to understand a few concepts, I've integrated with Paypal in the past and that doesn't make me a payment for engineer.

No, but the post explicitly calls out the breadth of knowledge that the future AI engineers will have to have. It's not something you can pick up in a few days, even now, if you want to be on top of things.

I can look up some docs and hook up static file hosting on S3 and that doesn't make an AWS engineer. But there are people who full time work on providing solutions using AWS-everything and have built their entire careers (and companies) on top of that specialization.

The difference in scale is the difference in job description.

Re: The Rise of the AI Engineer

#90
I mean, I consider myself an effective "AI Integration Engineer" but I _have_ done an Andrew Ng ML Coursera course and also built a MLP in C++ from scratch. But none of that really matters when it comes to applying something like GPT or Stable Diffusion to a particular application. You just send appropriate text to a model via an API call.

I think "AI Integration Engineer" is a bit more of an accurate title because usually it's about integrating AI into existing products or domains. And "AI Engineer" by itself sounds a little bit like you might be claiming to be a PhD. But just a bit. I think it's fair enough to shorten it to AI Engineer though so we don't all have to type out "integration" over and over.

Post reply on HN