| ▲ | globalnode an hour ago | |||||||
This article is wrong. LLM's encode all the domain knowledge you could possibly want. As a software dev I can query an LLM, become a domain expert in a short amount of time, and then code up a solution. If people think their niche is safe from automation, think again. Even the people who think theyre the masterminds at the top. Edit: Yes "expert" was too strong a word. Proficient would be better. A lot of the barrier to entry in a field is just not understanding the domain. | ||||||||
| ▲ | jodacola 36 minutes ago | parent | next [-] | |||||||
I won't over-generalize here, because maybe your statement is true in some cases, but I will provide a counterpoint: this is not true (in my experience) in real estate title insurance and escrow services. I've consulted for and led large teams for real estate title insurance and escrow companies for many years, and the domain expertise is so incredibly deep, nuanced, and multivariate (especially depending on jurisdiction) that building valuable and viable products in the space is incredibly difficult - before LLMs, and even now, with LLMs. Without getting too deep into it, I'm pretty bullish on AI (and have been very close to it and deep in it for a long time, while also very apprehensive about the effects it'll have on society), and I can tell you, from extensive attempts from myself and many on my teams to leverage the latest frontier LLMs to bring deep domain experience to bear to help drive valuable products: we have not yet seen success. It's not helping engineering folks, it's not helping product folks. It's creating a ton of questionable output and hasn't resulted in real ROI, and it's not capable of accurately answering deep domain questions without hallucinations or assuming what works in one jurisdiction works in all. I've seen success in many other areas, but not this domain - and, importantly, the regulatory environment in which title insurance operates is incredibly complex and strict, meaning you can't just YOLO LLM output into production (as much as we'd love to try so we can learn at a faster clip). And the kicker: we've found the way for us to build the best products is still going out into the field, sitting with escrow and title folks, watching them work, asking them questions, and designing for the real world, the regulatory nuances, the local client nuances, etc. You can't get that from an LLM. | ||||||||
| ||||||||
| ▲ | foobarbecue an hour ago | parent | prev | next [-] | |||||||
You might /think/ you've become a domain expert, but you haven't. | ||||||||
| ||||||||
| ▲ | ramshanker an hour ago | parent | prev | next [-] | |||||||
Once someone taught me "you can do xyz reading a book, but you cant do surgery by reading a book". Now replace the book with LLM. This is what "domain expertise" look like for some domain. | ||||||||
| ▲ | milkshakes an hour ago | parent | prev | next [-] | |||||||
> become a domain expert in a short amount of time how does that work exactly? | ||||||||
| ▲ | epolanski 29 minutes ago | parent | prev [-] | |||||||
I don't believe this. I work in e-commerce and warehouse management. We have put lots of effort at documenting the domain, creating precise unambiguous language, glossaries, E2Es written as user stories etc, etc. And still models are simply not able to translate Jira tasks to clear specs, even for this well understood and common use case. Also, they don't understand how changes in one part of the business domain will impact other parts. They can get it right 9 times out of 10, but even that is too little and compounds to deeply wrong implementations. And they don't understand or know the people involved in these processes and what they REALLY care for or what the real priorities are. Very often political. And that's not even mentioning the code, that ends up with the lack of proper abstractions or harness. Or the lack of push back against bad ideas at business or code level. | ||||||||