For the last decade, the advice was pretty consistent: learn to code. Code was the moat. It kept the people who could build things separated from the people who could only describe them. That moat just got filled in. And the people standing on the “other side” — the ones who actually understand the problems worth solving — are having a very good moment.
Sridhar Vembu, the founder of Zoho, put it plainly in a post that’s been circulating among engineers and product people alike. [1]
“Programming skills are the foundation (and we definitely don’t want to lose them), but deep domain knowledge is what customers pay for, along with reliability, security, support, and compliance.”
— Sridhar Vembu, Founder & CEO, Zoho
He’s not saying code doesn’t matter. He’s saying code was never the product. Understanding the problem was always the product. AI just made that obvious.
If you’re a business analyst, a product manager, a consultant, or anyone who has spent years developing genuine expertise in a domain — healthcare, finance, logistics, manufacturing, legal, whatever it is — this is your moment. Not because AI is coming to take the developers’ jobs and yours is safe by default. But because the thing you carry in your head, the mental model of how an industry actually works, is now the primary raw material for building software.
The entry barrier just collapsed
Here’s what’s changed. Building a working prototype used to cost months and hundreds of thousands of dollars. You needed a developer (or a team), a designer, a QA engineer, and probably a project manager to coordinate all of them. If you had an idea, you had to convince someone technical to bet their time on it before you’d ever see a line of code.
That’s gone.
Someone with a solid grasp of a problem domain can now spin up a functional prototype in a day — not a mockup, not a slide deck, but a working thing a real user can interact with. Getting to a production-grade product still involves stages AI can’t shortcut: security, compliance, edge-case handling, institutional trust. But the distance from idea to “is this even worth pursuing?” has shrunk from months to days.
In the age of AI, an idea is all you need.
Not a half-formed wish — a real idea, grounded in how a domain actually operates, where the friction is, and what a better version looks like. The implementation is increasingly a matter of iteration and verification, not deep programming knowledge.
The DORA 2025 report found that AI is already compressing requirements, design, and development into a single iterative cycle — moving teams from idea to functional prototype in days or hours. The bottleneck has shifted. It’s no longer “can we build it?” It’s “do we know what to build and why?”
So where does the business analyst fit?
The BA’s actual job has always been to translate the messiness of a real-world domain — edge cases, regulatory constraints, user behavior quirks — into something a technology system can act on. That’s knowledge work. And it’s exactly the work AI can’t do for you, because AI doesn’t know what it doesn’t know about your industry.
An LLM can generate a routing algorithm for last-mile delivery. What it can’t know is that traffic in a specific city breaks every heuristic after 4pm on Fridays, or that union rules in a particular region constrain what drivers can legally be asked to do. That knowledge lives in the domain. The BA holds it.
Business analysts are becoming AI-powered strategists — defining what questions to ask, curating insights from automated analysis, and validating whether AI output actually reflects business reality. Same role. Significantly more leverage.
The verification problem — and who solves it
DORA’s research is clear: time saved generating code gets reallocated to auditing it.[4] One developer put it plainly: less time writing, more time babysitting. This is the verification tax — and you can only pay it if you know what correct looks like. You can check syntax. You can’t check whether the system handles a healthcare claims workflow correctly if you don’t understand claims. Domain knowledge is the standard AI output gets verified against. Without it, the demo works fine and production encounters reality.
The SDLC used to start with “can we build it?” — now it starts with “what should we build?”
This is the most significant shift. For most of software history, technical feasibility was the first constraint. An idea had to survive the question “is this even possible?” before it got any serious investment. That filtered out a lot of ideas — not always the bad ones.
Now, almost anything is technically feasible. The new first constraint is domain clarity. Does the person proposing this idea actually understand the problem well enough to specify a solution? Can they distinguish between what users say they want and what would actually change their behavior? Do they know which edge cases will kill the product in a regulated environment?
This is a fundamentally different set of skills from what historically got rewarded in technology organizations. It looks a lot like what good business analysts do.
Domain knowledge without curiosity about what AI can now do is also a dead end. The opportunity isn’t “BAs stay the same and developers disappear.” It’s “BAs who understand AI’s capabilities can now prototype, test, and validate their own ideas — compressing the feedback loop in ways that were never possible before.” The people who figure out how to wield both will have an outsized impact.
What this means if you’re a BA or product-adjacent professional right now
A few things that seem worth acting on, rather than just thinking about:
Get comfortable with AI-assisted prototyping. You don’t need to learn to code. You need to learn how to specify clearly enough that AI tools can produce something useful, and how to evaluate what comes back. That skill — precise specification plus critical evaluation — is the new leverage point for domain experts.
Double down on the stuff AI genuinely can’t replicate. Stakeholder relationships, institutional context, the unwritten rules of how decisions actually get made in your industry — these don’t live in training data. They live in experience. Protect and cultivate that.
Start treating your domain knowledge as a product asset, not just background context. If you understand a domain well enough to see where the current tools are broken or missing, that’s no longer just a frustrated observation. That’s a starting point for building something. The gap between “I wish there was a tool that…” and actually shipping that tool is smaller than it has ever been.
The ceiling on what a single domain expert can create — without a large engineering team, without a massive budget — has moved dramatically. The question is whether the people with the deepest knowledge of real-world problems notice that before the generalists do.
Vembu’s bet at Zoho is that they will. His advice to engineers was to become domain experts. The implicit corollary: people who are already domain experts just got access to the tools that were previously gatekept by technical skill. That’s not a small thing.
The most interesting products of the next few years probably won’t come from teams who are best at prompting AI. They’ll come from people who understand a specific problem so deeply that they can tell when AI’s answer is wrong — and know exactly what right looks like. That’s always been the valuable part. The path to building is just faster now.
