Earlier quoted context omitted.
Nevermind syntax, what's a variable? function? class? What's the difference between int/float/boolean string? Nevermind more advanced concepts like O(1) vs O(n). But when the vibe coder just needs to prompt "the page loads really slowly. plz fix" and the LLM can go in, add an index to the right SQL table, add a limit and pagination, so what if I can tell you the difference between PostgreSQL's dialect of SQL vs MySQL…
It only takes two or three unreviewed prompts like "the page loads slow, plz fix" for you to end up with a tangled mess that even the agents can't productively work with. Take a look at the Reddit forums for vibe-coders - now that a bunch of them have been hacking on things for 3+ months there's a growing awareness there that you hit a wall. Here's the first post I found from just searching "reddit vibe coding wall",…
Domain expertise has always been the real moat
291–300 of 592 posts
Re: Domain expertise has always been the real moat
#292Earlier quoted context omitted.
Lol the worst pattern
Strangler fig is one of the best, with one of the worst names
Facades and stranglers are massively useful patterns, and help explain concepts to the layman.
Personally I've never been patterns over everything, so I'm not going to now knee jerk and say no patterns ever.
There's a time and a place for everything.
edit Fuck. A reread on that and I sound like AI. Updated
Re: Domain expertise has always been the real moat
#293Earlier quoted context omitted.
> ...to deliver a multi-tenant application that has to deal with high TPS or whatever. There's a whole world of opportunity that lives below complex multi-tenant applications that have to deal with high TPS. > At least at present you're positing there's no need for carpenters because the home gamer can knock together a table or birdhouse at home. This is an extreme, straw man argument. And here's the thing: I don't k…
Why is anyone paying for these apps if any idiot can do it with a few prompts?
With all due respect, this sounds like just another version of the arrogant, scared attitude that seems to be more and more prevalent among software folks these days.
Is it really hard to imagine that there are tech-savvy people who are smart and motivated but don't have training as software developers, who are now capable of using AI to build and ship things?
In other words, AI doesn't allow any "any idiot" to build commercially useful software. What it does is allow smart people who aren't software developers and who don't want to become software developers professionally to, with a much shorter learning curve and on a much faster time scale, take their ideas and build and ship functional software.
Re: Domain expertise has always been the real moat
#294It 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…
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.
Re: Domain expertise has always been the real moat
#295Re: Domain expertise has always been the real moat
#296It 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.
"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.
Re: Domain expertise has always been the real moat
#297It 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.
Not all code has to be efficient scalable code. I know some domain experts that were not programmers. They picked up enough Python or Swift + UIKit (this was pre-LLMs) and their applications are now widely used in their domain. In some cases, they contracted some software companies in the past to do the work. However, they did not understand the problem domain well, requiring the domain expert to iterate with them over and over. In the end it was more efficient to let the domain expert to learn enough programming do it with some guidance from experienced programmers.
Also remember that a lot of domain-specific apps do not need to be huge. E.g. I was once at a factory in the 90ies and they needed to do time-consuming calculations for a particular expensive machine. So, someone who worked at the factory wrote a small program in Excel + I think VBA. This accelerated their work extremely and probably saved them 10,000s or 100,000s in manual labor. It was easy for a non-programmer to write, because they knew all the details of the machine and the calculations, since they had done it over and over again. But it's not a enterprise web app or anything and it does not matter if the program runs in 1 or 4 seconds.
By the way, I also consider efficiency to be a specific knowledge domain, or architecting a very large project. So in the end it really depends on how narrow or wide your definition of 'programming' or 'coding' is.
Re: Domain expertise has always been the real moat
#298The 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.
Re: Domain expertise has always been the real moat
#299It 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…
Sounds like you need a senior familiar with finance/accounting and a family to feed. Email me!
Re: Domain expertise has always been the real moat
#300"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.
A SWE who has always worked in DevTooling companies will always be preferred by DevTooling companies over a generalist. A SWE who has always worked in AdTech will always be preferred by AdTech companies over a generalist. etc etc.
Software fundamentals - though useful - are table stakes skills at this point. No business wants to deal with the headache of on-ramping employees who have never worked in a specific domain or industry because it takes too long for a generalist employee to build the intuition needed to understand that segment of the industry.