(author of <a href="https://www.latent.space/p/ai-engineer" rel="nofollow noreferrer">https://www.latent.space/p/ai-engineer</a> here)<p>this is a fantastic followup post spelling out the toolkit of the AI Engineer. I have a version of this in my notes but didnt want to publish it for fear of being too biased by ommission, plus it's generally good to leave others to fill in the blanks on some things. the Projects list is particularly great - one could build a course around these few things and be reasonably confident that you have the base skills of a competent "AI Engineer" (that, for example, any PM or founder could ask to do an AI project and they'd be well equipped to advise/make technical decisions).<p>don't miss Andrej Karpathy + Jim Fan's take on the AI Engineer role: <a href="https://twitter.com/karpathy/status/1674873002314563584" rel="nofollow noreferrer">https://twitter.com/karpathy/status/1674873002314563584</a><p>for those who dont like Twitter, i cleaned up the audio of our AI Engineer conversation with Jared Palmer, Alex Graveley, Joseph Nelson, and other self identifying AI Engineers here: <a href="https://mixtape.swyx.io/episodes/the-rise-of-the-ai-engineer-twitter-space" rel="nofollow noreferrer">https://mixtape.swyx.io/episodes/the-rise-of-the-ai-engineer...</a><p>it's a fun time for those who want to carve out a space for themselves specializing in this stuff.
"Build, don't train" is poor advice for a prospective "AI Engineer" title. It should be "Know when to reach for a new model architecture, know when to reach for fine-tuning / LoRA training, know when to use an API." Only relying on an API will drastically reduce your product differentiation, to say nothing of the fact that any AI Engineer worth that title should know how to build and train models.