Live data from Hacker News

Domain expertise has always been the real moat

brethorsting.com

241–250 of 592 posts

Re: Domain expertise has always been the real moat

#241
post #227

Earlier quoted context omitted.

Maybe it makes software development easier, but a career as a professional software engineer harder.

I hope that after a short period of delusional expectations and layoffs from employers we're at least left with a more consistently competent set of professionals in our industry. Some people have imposter syndrome. Others are actually just imposters.

>layoffs from employers we're at least left with a more consistently competent set of professionals in our industry

It definitely won’t be CEOs and managers not firing their buddies

Re: Domain expertise has always been the real moat

#242
Whenever I read articles like this one that appear to be very generic and give advice about dealing with AI, I remind myself that he software industry is like the construction industry.

It will never be organized, never fully optimized, and it will always be custom — because it has to cater to the reality of wildly different tastes, contexts, and localities. There may be some good tools, raw materials that show up once in a while.

Re: Domain expertise has always been the real moat

#243
post #51
post #46

Earlier quoted context omitted.

I think a charitable interpretation is that from the perspective of AI, some domains are shallow (like chess), and some are deep (you can fill in the blank here).

What would fill in the blank be? Because this was actually kind of a test for me to address the question of "does AI just amplify domain knowledge?" In this case, it seems it didn't.

Stuff where all the info isn't available online.

For example, I used to do integrations for sports betting sites. AI is going to help with the basics, like understanding the default puck line is 1.5 in hockey. AI is not going to realize that Bet365 changes their API endpoints for each season, so you need to be ready to fetch the updated ones before the new season starts, whereas most other sportbooks have consistent endpoints that you don't need to keep updating.

How much domain knowledge is actually unavailable to AI is going to vary by domain, as will the value of that. Chess is probably one extreme, where all knowledge is public, whereas something like military R&D might be the other extreme where domain knowledge is tightly guarded.

Re: Domain expertise has always been the real moat

#244
post #128

Earlier quoted context omitted.

An idea that's beginning to solidify for me is that AI tools make software development harder . It's harder because they dramatically raise the bar for what's possible to do. An individual developer can take on significantly more challenging projects now, because the ultimate constraint has always been time and AI can help you get more done in the time available. But the stuff you can get done with that time is a who…

I worry this is looking at where the ball is now instead of where it's going. The recent disproof of an Erdos conjecture should put to rest the idea that LLMs will reach a skill ceiling before they reach superintelligence. I believe we are headed for a world of superintelligent AI where LLMs are much better at logical thinking than humans, the same way that chess engines are much better at chess than humans. In that…

Are you confident in putting a timeline on this prediction?

One of the reasons I'm increasingly skeptical of this prediction is that I've now lived past a few of the dates I heard people put on the achievement of this level of superintelligence in previous years.

Re: Domain expertise has always been the real moat

#246
I thought real moat of software is requiring virtually no extensive knowledge/experience of both system and domain. Copying taste and network effect is significantly difficult. The fact is venture backed startups with plenty of talents and resources has been rarely making their positions in the market before vibe coding. That's why people at 20s can compete with experts in various areas. Current backlash is due to creation of guys with just x years experiences in the industry we often see in other mature enterprises.

Re: Domain expertise has always been the real moat

#247

Earlier quoted context omitted.

Domain expertise combined with a QA mindset could replace SWE, but consistent QA mindset is rare

I agree that a consistent QA mindset is rare, but I'm not sure even if present if it's enough to replace an SDE. I very recently looked at the codebase of a vibe-coded app made by someone with domain expertise but no software dev experience. It was very clear to me that he had described it from his POV to an AI, and the AI had implemented features in a manner that technically worked, but made future maintenance or ex…

I have found this to be the case as well. As developers we are just really good stewards of the code because we obviously have knowledge to make sure that the code is engineered in a way that it can scale and grow without tech debt becoming unwieldy.

I found AI to be pretty bad with like a bare bones code base without solid patterns in place already. It works but it's just monolithic files galore. use effects hooks everywhere. Nasty state situations with poor data practices. Security vulnerabilities up the wazoo.

It's weird to have this conversion with them. Like yeah your code works but it's so tangled up it's hard to reason about where to start to begin to unwind it all sometimes.

It can be done but cleaning up someone else's slop is the exact reason why I hate AI. It was hard enough to review great code and be critical, honest, and fair but we knew it was an essential part of the process, helped build shared understanding, and was a way to learn from one another.

Whereas throwing in jumbled garbage to review just feels like a waste of our brain cells we spent decades earning by embracing the craft.

Re: Domain expertise has always been the real moat

#248
post #227

Earlier quoted context omitted.

Maybe it makes software development easier, but a career as a professional software engineer harder.

I hope that after a short period of delusional expectations and layoffs from employers we're at least left with a more consistently competent set of professionals in our industry. Some people have imposter syndrome. Others are actually just imposters.

> Some people have imposter syndrome. Others are actually just imposters.

I'm sorry to say, but AI coding assistants paved the way to professional imposters whose only skill is prompting a model to do something. I already had the displeasure of working with a software engineer who not only introduced a bunch of regressions that by mindlessly vibe-coding things against the requirements but also complained that not having credits to use the most expensive frontier models was, and I quote, "stifling my creativity".

Re: Domain expertise has always been the real moat

#249
post #128

Earlier quoted context omitted.

An idea that's beginning to solidify for me is that AI tools make software development harder . It's harder because they dramatically raise the bar for what's possible to do. An individual developer can take on significantly more challenging projects now, because the ultimate constraint has always been time and AI can help you get more done in the time available. But the stuff you can get done with that time is a who…

I worry this is looking at where the ball is now instead of where it's going. The recent disproof of an Erdos conjecture should put to rest the idea that LLMs will reach a skill ceiling before they reach superintelligence. I believe we are headed for a world of superintelligent AI where LLMs are much better at logical thinking than humans, the same way that chess engines are much better at chess than humans. In that…

I don't buy that at all.

It doesn't matter how great the LLMs get, the act of creating software using them will still require a great deal of skill.

Most people just don't think in terms of software.

Try asking a non-developer in your life what their dream software would be for their work, or their hobby. If they don't have what Nilay Patel calls "software brain" I'd be surprised if they came up with something actionable.

(For more on software brain see "THE PEOPLE DO NOT YEARN FOR AUTOMATION", which makes the point I"m making here but much, much better: https://www.theverge.com/podcast/917029/software-brain-ai-ba...)

You could give a non-developer the smartest LLM in the world and they wouldn't be able to create GitHub with it, because creating GitHub requires an enormous amount of understanding of what software developers need from a cloud source control tool.

Sure, you can argue that the LLM "knows" what GitHub needs already and can guide their human-user to that, but why would a human-user who doesn't understand the domain ask an LLM to do that in the first place?

Re: Domain expertise has always been the real moat

#250
post #128

Earlier quoted context omitted.

An idea that's beginning to solidify for me is that AI tools make software development harder . It's harder because they dramatically raise the bar for what's possible to do. An individual developer can take on significantly more challenging projects now, because the ultimate constraint has always been time and AI can help you get more done in the time available. But the stuff you can get done with that time is a who…

developers now are expected to randomly jump around projects and ship without friction. For employers it means they can move us around like pawns. Lot of companies have not reorged themselves to this new type of workforce thats much more malleable. it used to be that i pay your due at some enterpise and learn some corner of codebase really well and become go to person. that would give you job security.

> it used to be that i pay your due at some enterpise and learn some corner of codebase really well and become go to person. that would give you job security.I

I had the displeasure of working with those types. One of them replies to any question or challenge to a technical problem emerging from the PRs they posted with variants of "I've worked here for over a decade, this is how we do things". And then proceeds to argue things like defensive programming is a code smell because it means developers don't trust themselves.

I cannot envision any healthy, effective engineering environment where developers don't periodically switch between projects.

Post reply on HN