This is demonstrably false for many use cases. For one broad example, LLMs have shown incredible performance on many NLU and NLP tasks, that are not currently possible using other techniques.
That's why the word "engineer" is in the title and it isn't "prompt writer" or "ChatGPT user".
It's highly unlikely that anyone taking this effort seriously is copying and pasting from ChatGPT, rather than using the API and building pipelines as part of a broader system.
Instruction-fine-tuned LLMs like ChatGPT require creating, validating, and maintaining prompts. Finding ways to use them safely is also not easy - prompt injection and hallucination are just 2 potential pitfalls - there are many more.
Denigrating this effort as "AI monkey" is myopic at best, but really just comes across as a signal that someone is terrified of being replaced by this new tech. With that attitude, they will be.
Writing prompts and engineering together = prompt engineer. The engineering depends on the prompt and the prompt depends on the engineering. Just like an ML engineer, or a QA engineer, or [anything] engineer. How specific the job title gets really depends on hiring criteria and daily job function.
Otherwise, the job title would be "prompt writer".
Your point is what, that existing engineering titles cover this effort? Sure, you can just call all of it software engineering, but sometimes it's useful to be more specific. The LLMs are so powerful now that this new, more specific title makes sense to me, and clearly those using this new title. We'll see how it pans out over the next few years.
This is an unhelpfully cynical take.
The job title has "engineer" in it, so a more charitable interpretation is more serious than "AI monkey".
Using LLMs to solve real problems is not easy. Making sure that you don't introduce regressions while making improvements is difficult, and requires building and evaluating a dataset, and the necessary pipelines. It may also include diversification of LLM providers, and creating the necessary abstractions. A fundamental understanding of how LLMs work, ability to compare different architectural approaches, along with typical data engineering and software development skills would be required.
What if you want to use the LLM for Question/Answer systems that requires working with embeddings? What if you want to find a way to process data locally without sending sensitive data to the LLM provider?
If you're interested in increasing EVOO consumption for the health benefits based on polyphenols, look into Moroccan olive oil, as it has very high polyphenol levels - as high as 30x regular EVOO.
Replicant | https://replicant.ai/ | QA Lead, Fullstack, Deep Learning, Data Engineering, and Telephony Engineering positions | San Francisco, CA or REMOTE
Replicant is a Conversational AI technology that works out of the box to solve customer problems over the phone. We craft great conversations by combining Machine Learning, Artificial Intelligence, and linguistic conversational design into the fastest, smartest, and most expressive Thinking Machines you’ve ever spoken with.
We're a small team (~20 people) tackling a big industry with many eyes on it, using powerful technology. Our team comes from a diverse background of industry and the arts, and we are distributed across the US and Canada.
Our stack includes TypeScript (browser and node), JavaScript, Postgres, Redis, Python (3.x), and Pytorch Infrastructure is Google Cloud (though we also use AWS and Azure) and most services run in k8s (Kubernetes)
We're hiring:
* QA Lead - own quality engineering, E2E testing, automation, and testing conversations on the phone
Replicant | https://replicant.ai/ | QA Lead, Fullstack, Deep Learning, Data Engineering, and Telephony Engineering positions | San Francisco, CA or REMOTE
Replicant is a Conversational AI technology that works out of the box to solve customer problems over the phone. We craft great conversations by combining Machine Learning, Artificial Intelligence, and linguistic conversational design into the fastest, smartest, and most expressive Thinking Machines you’ve ever spoken with.
We're a small team (~20 people) tackling a big industry with many eyes on it, using powerful technology. Our team comes from a diverse background of industry and the arts, and we are distributed across the US and Canada.
Our stack includes TypeScript (browser and node), JavaScript, Postgres, Redis, Python (3.x), and Pytorch
Infrastructure is Google Cloud (though we also use AWS and Azure) and most services run in k8s (Kubernetes)
We're hiring:
* QA Lead - own quality engineering, E2E testing, automation, and testing conversations on the phone
How confident are you that the results will indicate a level of impairment, rather than a particular concentration of THC?
Other substances contained in cannabis have significant synergistic effects with THC; are you going to look for other cannabinoids and the presence of terpenes?
I don't have a book recommendation for you (what helped me was the standard documentation and about a year of daily dev time), but an observation:
Your team is likely using an overly restrictive tsconfig.json. No-implicit-any, for example.
Make it less restrictive, and you then have typing and no penalty for punting on it until later.
If using an IDE, the effort into defining types is immediately rewarded with autocomplete for API/backend AND client code, and we even export the types for use by a Monaco editor inside an internal app.
I'm in the same boat. At this point, "growing pains" is not a legitimate excuse for this level of incompetence. I (wrongly) assumed that since Coinbase is based in SF and funded by YC, that they would not be able to get away with this level of negligence. This reflects very poorly on YC and specifically YC leadership.
Serious question for YC insiders: has YC leadership made any effort to advise Brian on this, and how poorly this negligence reflects on YC as a whole, or does no one care because they're getting such a high return on their investment?
Lots of advice here is to go after pain points, or enter competitive markets, or to question your team dynamics. I have a different perspective:
Set up a studio, where the team builds a new "thing" every 2 weeks. Then, 2 months later you have 4 things, and you can pick the one that inspired the team the most.
Given your cash position, you should be able to easily float 2 months while building a bunch of different things.
I'm basically a twilio engineer now. I do a lot of telephony, but no one wants to run and scale their own stack, so everyone ends up building against REST apis. Twilio has some of the best features around reliably placing calls, sending texts, and the most enjoyable developer experience of any api I've ever used, including outside of telephony. I've built a 100% serverless contact center, among other things. Twilio Sync RT infra is also fantastic. Their WebRTC service was total shit through 2014 but is better now.