Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Domain expertise has always been the real moat

brethorsting.com

Post reply on HN
Print view View original

501–510 of 592 posts

Re: Domain expertise has always been the real moat

#501

Post by dapperdrake »

andsoitis wrote: post #420
hn_throwaway_99 wrote: post #309

While 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…

> So often times he would sit down with these accounting folks and go through lots of example transactions he came up with, and from there he essentially built up the requirements spec. Right, so the spec is derived from examples, an interactive process that doesn’t require a programmer.

Talking to CPAs never gets you to Pacioli groups.

Talking to engineers and mathematicians gets you there.

Re: Domain expertise has always been the real moat

#503

Post by dapperdrake »

petra wrote: post #444
skydhash wrote: post #440

Earlier quoted context omitted.

The programmer skill is how to abstract the specs from all the examples. And then to formalize it. Actual coding is merely translation. And only beginners tend to focus on that.

Sounds very similar to what AI is good at.

No. AI sucks at formal languages and implications.

Lossy decompression probably won’t ever be really good at this. If it’s missing from the data, then it won’t be there.

The AI math proofs were probably already out there in tiny pieces and nobody got all of the pieces together. That is valuable. It’s different from making a piece that is missing. And the AI will just hallucinate.

Re: Domain expertise has always been the real moat

#504

Post by dapperdrake »

Npovview wrote: post #439
elendilm wrote: post #315

Earlier quoted context omitted.

Yes. The author stumbled on the p vs np problem but with humans. Verification is easy. Solving is the millennium prize question.

Agreed. But there is a new dynamic coming to place. Who can execute faster now that we have AIs? I think the combination of (Good SWE using AIs) collaborating with (Domain Expert using AIs) is the winning team. Things are accelerating on all fronts, the frontier may be jagged but AIs is making progress on all capabilites.

Additional iterations are valuable, if and only if we learn from additional iterations. Otherwise we are just spinning our wheels.

Re: Domain expertise has always been the real moat

#505

Post by RaftPeople »

zipy124 wrote: post #382
hn_throwaway_99 wrote: post #309

While 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…

I fully agree here. It's also not uncommon to have the reply for specific items be "Ahh, well that is a bit of an edge case see because of X and Y" and then you learn there are many many "special cases" to the point that they aren't that special anymore.

This comment brings back memories of a project.

We were working through many complex business flows and running into exactly what you describe in many areas. Some of the project people with less experience complained that we were spending too much time on exceptions and slowing down the project. We had to explain that when each exception happens 100 times a day with significant impact on business productivity, then it doesn't matter whether you call it an exception or not, it's important to solve for.

Re: Domain expertise has always been the real moat

#506

Post by dapperdrake »

physicsguy wrote: post #468
hn_throwaway_99 wrote: post #309

While 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…

I have found this with (mechanical) engineers. They know what they want to see but don’t understand the underlying details which are more mathematical than the average engineer is able to work with. So the people working on engineering software are often physicists or applied mathematicians.

Ran into this, as well.

And they were really annoyed at being asked math questions.

Re: Domain expertise has always been the real moat

#507

Post by dapperdrake »

Toutouxc wrote: post #316
hn_throwaway_99 wrote: post #309

While 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…

I agree with your point that people “from” the domain aren’t automatically equipped to start AI-building software in the domain, exactly because they often lack one of the most crucial software development skills — being able to (and having the desire to) describe a complex system with a finite set of deterministic rules. But I don’t think we should be calling these people “domain experts”. I think we should reserve…

Then there are almost no domain experts.

Re: Domain expertise has always been the real moat

#508

Post by emodendroket »

ElProlactin wrote: post #500
emodendroket wrote: post #473

Earlier quoted context omitted.

It just feels like I’m trying to nail spaghetti to the wall talking to you because you can’t make up your mind what your argument is. Either it still requires learning and skill to do it —- in which case these are self-taught software developers, which is not a new phenomenon —- or it’s so easy now that the work is completely deskilled, in which case we shouldn’t expect anyone to be able to charge for their work for…

It seems to me you're more interested in semantics than the substance of the discussion. Why not consider the possibility that AI is creating something new? I would argue that the non-developers who are able to use AI to build, ship and sell software aren't "self-taught software developers". The biggest reason is that they're effectively not learning how to code in any meaningful way. They don't need to. AI is gettin…

I bought a book however many years ago with no previous development experience and delivered a Web app people paid for and eventually honed that as an actual career, so I’m just not really seeing what’s a difference in kind here. I also disagree with the “democratization” frame because now developers are spending like $1000 per month on tokens at their jobs, which does the opposite of making things more accessible.

Re: Domain expertise has always been the real moat

#509

Post by LorenPechtel »

hn_throwaway_99 wrote: post #309

While 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…

I very much agree here--the true job of us programmers is determining exactly what the problem is. The domain expert will fail because they haven't attempted to refine the details enough, they probably don't have the skill to anticipate the edge cases.

I've spent most of my career working with the same people--even people who have some coding experience but they never catch the low probability stuff. Or even not so low probability: business procedures were that the customer was quoted an all-inclusive price. Try to work backwards, what is the pre-tax amount? Um, that's not guaranteed to have a solution. My concerns get ignored, I go ahead and implement with code that will catch the offending penny and label it roundoff correction. While I'm not sure what happened I think some auditor hit that. I ended up having to walk them through the calculation, okay, what's the answer here? Only when they couldn't solve the problem could they accept that what I had done was the only answer. (The actual odds of such a failure are equal to the tax rate. I had not originally worked that out, just saw success was not guaranteed.)

The domain experts make this sort of mistake routinely in dealing with code. AI won't fix that.

Re: Domain expertise has always been the real moat

#510

Post by vale95ntino »

I find the article interesting and (largely) correct in its analysis of how an individual can use AI. What I think is missing is that organizations (like enterprises, research labs, etc), have multiple people and multiple experts in different fields. So you can have BOTH the AI engineer and the domain expert in the field. Not only can you have this but this is actually common in most large companies. The difficulty lies in making the collaboration work and the information flow correctly so that the domain expertise of the expert can flow into the software product built by the engineer.

A mental model I use for this is that we have users, builders and experts when creating AI products. For most individual use cases a person is the user, builder and expert: I make a prompt about how to write code in a way that I like that I will later use. Coding agents moved into the direction of builders that were also experts in the field iterating on a product for third-party users. The next frontier will be finding the right patters for teams to capture expert knowledge handle the collaboration between engineer/builders and experts. Just having PMs handle that interaction will be a super bottleneck.

My cofounder and I are actually working on a project in that direction (https://www.getvalmar.com) --> we'd love any input on how engineers prefer performing feedback loops and getting input from subject matter experts :)

Post reply on HN