"the binding constraint has moved from can you build it to can you tell whether it’s right." The company I work for is currently trying to accelerate internal AI adoption, and recently laid off people to help force it. As I've written here before, this merely pools accountability (not removing it) and things will break in unexpected ways as people are not domain experts in these new areas added to their jobs. I wonde…
Domain expertise has always been the real moat
481–490 of 592 posts
Re: Domain expertise has always been the real moat
#482While I agree that domain expertise has always been a moat, I believe the author is missing something critical: there is a big difference between being able to verify the output of a system is correct, and being able to tell a system how to generate the correct output to begin with. Personal example: I had a software engineering colleague who was the best coder of financial management systems I've ever encountered. H…
>One of the things he told me, and that I also observed, was that the vast majority of financial experts (basically, the people in the accounting department of companies) had an extremely difficult time just telling him what the rules of any particular transaction should be We have internalized more knowledge than we can explain sounds like the textbook definition of Polanyi's paradox:"Polanyi's paradox, named in hon…
Re: Domain expertise has always been the real moat
#483Earlier quoted context omitted.
I think the answer is in the second sentence of the article. The most valuable person in this new world (using the author's own phrasing from the penultimate paragraph) is the one who is good at "building a working model of the domain in [their] head". Depending on the domain, this may either be the domain expert themselves, or someone else trained in formal logic, data structures and organizing information into cohe…
I'm this person, and I do find AI to be quite helpful, though I'm mostly just playing around at this point. I'm the daughter and granddaughter of programmers, and I learned the basics of how to code as a kid. I'm good at it and have a knack for it, but I didn't want to do it for 8+ hours a day and then spend my nights on it as well, so I didn't pursue it as a career. I did an undergraduate degree in Linguistics, whic…
I've frequently been credited as a person who can really string all the disparate elements of tacit knowledge together into a unified fabric in our particular subdomain, and helped a lot of people plug Swiss cheese gaps in their knowledge that way and come away with the feeling that it's all been tied together theoretically.
However, it's not immediately obvious to me how, in our LLM psychosis cultural moment, this facility shoots to the top of the value chain.
Re: Domain expertise has always been the real moat
#484It was never about the code. After spending the last 5 years building software for venture capital and private equity, this blog post really resonates with me. Writing code is by and far the _easiest_ part of my job; understanding the financial engineering and nuance behind what my company's customers need from us the tough part. We always joke that we'd rather hire a senior fund accountants and teach them to program…
You are wrong. Writing programs (atleast efficiently) is not the easiest part. It just appears to be once you get accustomed. Domain expertise is hard but not that hard compared to the insane mental discipline required to write efficient scalable code. Domain expertise is valuable and hard but I don't get this "domain expertise is harder than disciplined coding" mentality.
Coding is way easier.
Re: Domain expertise has always been the real moat
#485Earlier quoted context omitted.
You are wrong. Writing programs (atleast efficiently) is not the easiest part. It just appears to be once you get accustomed. Domain expertise is hard but not that hard compared to the insane mental discipline required to write efficient scalable code. Domain expertise is valuable and hard but I don't get this "domain expertise is harder than disciplined coding" mentality.
> Domain expertise is hard but not that hard compared to the insane mental discipline required to write efficient scalable code "efficient scalable code" is just as vague as good code. How are you going to know your code is scalable if you don't understand your domain? Scalability is not something you sprinkle onto code.
Sometimes you need two orders of magnitude. Sometimes you need five. Sometimes you need less than one.
Re: Domain expertise has always been the real moat
#486Earlier quoted context omitted.
> Domain expertise is hard but not that hard compared to the insane mental discipline required to write efficient scalable code "efficient scalable code" is just as vague as good code. How are you going to know your code is scalable if you don't understand your domain? Scalability is not something you sprinkle onto code.
Are you kidding me. What has domain got to do with efficiency and scalability. Efficiency is about using minimum cpu cycles or minimum memory or minimum network round trip or more generically using minimum/optimum resources to get something done. Scalability is about minimizing bottlenecks and linear scaling so one can just copy and execute by adding more nodes/resources and expect correctness and increased throughpu…
Re: Domain expertise has always been the real moat
#487Earlier quoted context omitted.
> Scalability is about minimizing bottlenecks and linear scaling so one can just copy and execute by adding more nodes/resources and expect correctness and increased throughput. Yes, technically, but note that this entire thing can be anything from crucial to completely worthless depending on the domain. You need insane scalability for a social network or a streaming service, you don’t need any real scalability for (…
Writing scalable and efficient programs are extremely hard. This matters for serious projects but for small projects, honestly who cares.
Re: Domain expertise has always been the real moat
#488"the binding constraint has moved from can you build it to can you tell whether it’s right." The company I work for is currently trying to accelerate internal AI adoption, and recently laid off people to help force it. As I've written here before, this merely pools accountability (not removing it) and things will break in unexpected ways as people are not domain experts in these new areas added to their jobs. I wonde…
Until AI can take responsibility I don't see the accountability issue being solved, hopefully this doesn't just mean humans become responsibility machines.
Re: Domain expertise has always been the real moat
#489Not just domain expertise. The hard part has always been marketing, distribution, risk appetite, motivation, grit, and patience. There are plenty of things which are "trivial" to produce with no moat and yet are still million dollar businesses. Kebab stands. Water bottles. Barber shops. Movers.
The market is big.
Re: Domain expertise has always been the real moat
#490Here's an example I encountered last week:
Someone in my neighborhood is a 75 year old chemical engineer who likes computers and got into Linux a few months ago. I see him from time to time when walking around, he's a nice guy and overall has a scientist's mindset. He doesn't make a lot of assumptions and tries to think things through but sometimes he has big blind spots in unfamiliar fields.
I helped him install Linux and also hook up an SSD to one of his older machines and now it flies.
On his own he had an old sound card that he wanted to use on that machine. He asked me if the card is compatible. I told him it almost certainly is because the Linux kernel has drivers for a ton of devices. His motherboard's built-in sound card was fine but he likes tinkering with audio in general.
He managed to physically install the card correctly but called me and said there's no sound playing. Then he says he spent 12 hours troubleshooting the issue, using ChatGPT and Googling for assistance.
Over the phone he told me he tried many different things. Installing, tweaking and configuration ALSA, PulseAudio and PipeWire related tools and tweaking everything you can imagine. Nothing worked, no matter what happened, it never played sound through his speakers.
He asked me if I could come over to help so I did.
In 30 seconds I solved the problem.
I went to his sound settings in his desktop environment and saw that his sound card was being picked up. I looked at the back of his machine and noticed this card had 2 black ports with the bigger style jack for headphones. There was no usual green port which is usually used for output. I shined a flashlight to look closer. One of the black ports was labeled headphones and the other was unlabeled. His was connected to the unlabeled one. I swapped it to the other port and everything worked right away.
All of that to say, as a software engineer I have second hand embarrassment that a trillion dollars invested into AI didn't think to respond with "did you double check to see which port you connected the speakers to?". I asked him if AI ever suggested that and he said no, it immediately went into polluting his system with a bunch of unnecessary tools and chasing incorrect rabbit hole after rabbit hole. AI understands nothing.