341–350 of 592 posts
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…
The software generalist described in this post has domain expertise as well. In software. If you’re a great generalist software engineer today, you aren’t jumping to some random domain to escape AI. Software is your domain. You’re sticking with it as it expands and transforms.
Exactly, plus you now have a new superpower with AI — the ability to dig into and ramp up expertise in mostly any domain. I’d say the article gets it backwards.
This is a failure mode that senior engineers have seen a few times throughout their career: They know how certain choices will play out over time... and the kind of problems and roadblocks these choices might cause.
My friend is an electrical engineer and just passed a FIDE chess rating of 2000. Has played for 30 years, started the chess club in high school. Knows a little programming from the stuff he had to do with microcontrollers in college. I'm an infra/admin jack of all trades with a comp sci degree and have been a hobby programmer for 30 years. I have a Lichess rating of 1000 on a good day. We tried doing a chess bot comp…
I think this might be one of the worse examples of the dynamic, for the reasons already mentioned by others (programming a chess bot is really more of a programming exercise than a chess exercise), but it’s food for thought, so thanks for posting it. Some IRL domains are definitely more chess-y than others.
"So the most valuable person in this new world is the one who has both skills because they can verify at both layers. They know the generated code is sound and they know the answers it produces are true." This has always been true since the dawn of programming.
Whole TFA doesn’t take into account reason why software development was actually so valuable.
Single specialist in any domain is not that valuable. You may charge $200 for hour of his time sure. But to grow company you now need N specialists.
What software was doing was not making specialist obsolete replacing a specialist by encoding his knowledge - well many tried to do so but failed even in 80’s “expert systems”.
What software was doing was making it possible to structure specialist work, make it possible for a single specialist to serve more customers at the same time, make it possible to hand over work in a structured way to junior specialists, making it easier for senior to take over edge cases and spot check work of those junior specialists.
This setup allows company to not being tied to number of specialists to grow, this setup allows company to charge less per customer but take over more of the market share.
Whole premise that now each specialist will waste time dabbling in AI software development is ludicrous, especially if each specialist would be building his own tooling somehow.
I recently reviewed an app built mostly with vibe coding. The owner said it was almost ready to launch and just needed a quick check. After looking through it, the database design was a mess. Some features worked, some didn’t. I explained the missing pieces and why things were breaking. Like OP said, he’s the domain expert. I used billions of tokens last month alone. The tools are getting better fast. But giving AI t…
> I used billions of tokens last month alone. I use Claude Code (Opus 4.6 at max effort) all day long, and I genuinely don't understand how this is possible. Is that usage paying off? This is very likely due to my lack of understanding, but... how?
In the past few months, I've used agents to brute force and reverse engineer solutions to problems I would never have economically have figured out on my own. I did it by putting agents in loops, connected to hardware and the internet, reading technical documentation, and relentlessly trying.
The code was shit. But it's much better to start with working shit and make it correct than spend weeks frustrated that nothing works.
I get that being a domain expert and instantly knowing the output is shit is important, but even if the output looks great, the code can be shit, and it takes looking at the code and knowing something about it to figure that out.
The solution to shit output is not (always, sometimes it is) just another if statement.
Even in a very well specified OSS effort, where I have some expertise, and I carefully reviewed the AI's output every goddamn step of the way, bugs slip through that the agents confidently tell me can't happen, and when shown proof they… add just another if, instead of really questioning assumptions.
You either know what you're doing, or you don't.