5 Questions with Ravi Asnani: How AI Is Reshaping Software Engineering Teams

The actual job of a software engineer has changed more in the last 18 months than in the previous decade. Code that used to take a senior dev a week now ships in an afternoon. Three or four agents can run in parallel on a single feature. The piece of the work that used to define the discipline, typing, is the piece AI is taking over fastest.

So we sat down with Ravi Asnani, HappyFunCorp’s Managing Director of Engineering, to talk about what that actually looks like inside the work. This is the first in an ongoing series of conversations with the HappyFunCorp leadership team. Five questions highlighting engineering evolution, team composition, evaluating partners, build vs. buy, and what's genuinely exciting about where this is heading.

How do you see software engineering evolving over the next two years?

It's still a work in progress, but the idea is that devs should be becoming builders. It's not just coding anymore. It's job orchestration, system design, technical architecture, product. Those should be your main areas of focus.

Add-ons in adjacent areas matter, too. Can you understand a bit of what marketing does? A bit of what SEO does? Do you even know where Google Search Console is, what data you can pull out of it? Do you understand the basics of design? Depth still matters. Your area of expertise still matters. But there's value in breadth now in a way there wasn't before.

Everyone talks about model context. Nobody talks about human context. How much can you put in there and still make sense of it all? Some engineers handle that nicely. Others can still only run one thread at a time, and that gap is widening across the profession. You're now in a place where you've got four or five agents working on separate things. You ask one to do something, you move on to the next, you check what the other one did, you verify it. Can you read code at a glance and know what's there? If you look at a PR and your head spins, you've got a problem, and you're only going to see more and more of it now.

"If you look at a PR and your head spins, you've got a problem. You're only going to see more and more of it now."

The other thing we've been pushing internally is more plan, less code. Once you've got a plan that makes sense, generating the code for it is much easier than going out and saying I want to do all this and the LLM spits out something you didn't want. We've been experimenting with using more advanced models to plan, and lower-level ones to execute, which is the equivalent of a senior engineer planning and a mid-level engineer executing.

Once the plan is in place, don't execute it yourself. If there are three steps, someone almost always misses one when they do it manually. AI follows the instructions more accurately. Your value isn't in writing it yourself anymore, more often than not, you'll lose ground doing it by hand.

"Your value isn't in writing it yourself anymore, more often than not, you'll lose ground doing it by hand."

How do you think this will affect team composition for digital product development?

The lines are starting to blur. There's a strong case for having more senior folks on the team who can use AI tools efficiently and have a deep understanding of how the various systems work. They can multiply very quickly across an organization.

We have to maintain some inflow of junior devs so they're trained up the ladder. But I see that as a temporary problem. The education system is going to correct itself. We're already seeing colleges asking, can you incubate products while you're there? Can you get real-time experience of building and launching something, instead of theoretical work without real-world context? You're coming out into a world that has a lot less tolerance for handholding.

Pods are looking like a senior tech lead on the project. Or, if it's a smaller project, a tech lead with product experience as well, merged into one role. Capital and headcount used to be moats. Increasingly, they're liabilities. I'll give you an example of what's possible. One of our clients hooked Claude up to NYC's accident-data APIs. The system ranks the worst intersections by incident count and drafts geo-targeted posts, what's happening at this corner, what to do if you're in an accident here. The thing that makes it work is grounding: the model writes from the client's own publications and editorial voice, not from a blank prompt. We pushed hard on that distinction. Generic LLM content is a trap search engines are already correcting for; AI as a distribution layer for a voice you actually own is a different category. Whether the line between those two holds up at scale is something we're watching with them. And the client is running most of this themselves, with almost no engineering involvement.

"Capital and headcount used to be moats. Increasingly, they're liabilities."

The systems you can put in place right now are limited by your imagination. The tools to execute them are already there.

What are some red and green flags product and engineering leaders should look out for when evaluating digital product partners?

One of the major red flags we see is most agencies and engineers operate on "tell me what to do, I'll do it." Describe the ticket, ask for these three things, I'll deliver these three things. The clients we work with often don't know exactly what they want, in the sense of being able to spell it out as steps. So can you pick an agency that understands what problem you're trying to solve, makes sure what you're building aligns with that problem, pushes back when what you're asking for doesn't align, and recommends solutions in line with that?

With building getting so easy now, you're going to have ten different people offering to build it for you at a wide variety of cost. Whether what you get at the end actually achieves your objectives is a different conversation.

Here's an example. A current client came to us after a previous vendor built them a new site without their old blogs, blogs weren't in scope, fair enough. The miss wasn't that. The miss was nobody flagging that years of SEO equity were sitting in those URLs, and either expanding scope to bring the blogs over, or staging the rollout so the old site kept running until the content moved. They flipped the switch instead. Traffic tanked. The reputation they'd built up over years went with it. Now we're rebuilding all of that from scratch.

That's the difference. We're not just a vendor for you. We're your partner. That translates into we're responsible for your success. We push back where required and we understand your eventual objectives. If a partner never tells you no, they're not a partner. They're a vendor.

"If your partner never tells you no, they're not a partner. They're a vendor."

Does the partner understand the problem the client is trying to solve? Clients often don't really understand the shape of the problem they're trying to solve. A lot of the value of more planning is whether the partner can pull that problem out of the client and surface the things that need to be worked through, instead of going "yep, I get the problem" when actually nobody understands the problem yet.

That's exactly what we've done with first-time entrepreneurs. Tracking and analytics tend to be an afterthought. Versus, can you have conversations about what your goals are, what really matters, what to put in place from day one so you can understand what works and what doesn't. Have you thought about revenue? How does this scale? Those conversations help shape the build itself.

I don't know why clients hate the discovery phase. It's a trial plan. Get to know us. See what's on the table. If you like the plan, we go ahead. If not, it ends there. We'd rather lose the deal than fake the answer.

How do you think organizations should approach the build vs. buy decision for their digital products?

There are a couple of dimensions there. One is off-the-shelf versus build it yourself. With AI, a lot of those conversations have come up: why pay someone else for something I can write code for? The rules of that haven't changed.

Building is still the cheaper part. Maintaining over time is more costly and more time-consuming. Building is easy, maintaining is difficult. Build vs. buy is really maintain vs. rent in disguise.The benchmark rule has always been: build what your moat is, what makes the product stand out. Buy everything else. Otherwise you spend more time supporting the ecosystem than concentrating on what makes you stand out.

"Building is easy. Maintaining is difficult. Build vs. buy is really maintain vs. rent in disguise."

Folks trying to build everything themselves with AI are going to get burnt very badly in the long term. The week it takes an agent to ship a custom CMS isn't the cost. Owning it for five years is the cost.

For compliance specifically, it's better off leaving that to systems you trust who do it day in and day out and stay current on regulations. If you build the internal tool yourself, you're not exempt from the compliance work. You take on the additional overhead.

On agency versus in-house, a lot of it depends on what kind of founder you are. If you have experience hiring and running tech teams and you know what to look out for, you have the option of building your own team or playing it a bit fast and loose with agencies.

If you don't, outsourcing to an agency like us is going to give you better results. We've seen a few clients leave HappyFunCorp for monetary reasons, get their own teams in place or go to a cheaper dev shop, and get burnt because they didn't know enough to control the output. If you don't have the experience, you want a trusted partner.

What are you excited about in the software engineering space currently?

The increased ownership on products you build. You don't have a hundred-person team where you're working on a small box and have no idea what's going on inside or outside it. You used to get written instructions of what to build within that box. You'd ship it. The rest of it, you were blind to. That model is breaking. Now developers see and own the whole thing, and that just makes the whole process more potent.

Small teams are shipping what mid-sized teams used to. The cost of starting collapsed. Time to first revenue collapsed. Niche markets that weren't viable before are suddenly viable.

On the work itself, the grunt work is collapsing. We did a Rails/Ruby upgrade recently, one of those messy ones with years of tech debt baked in. Used to take weeks. Took days. Same story with a Vite to Next.js migration on another project. The parts that used to eat senior-engineer time are exactly the parts agents handle well, well-specified, well-documented, pattern-rich. We get to spend our time on the 20% that actually matters.

There's an architectural piece too. Microservices are losing ground. They made sense at 50 engineers, different teams owning different services, deployment isolation, the whole orchestration story. They don't make sense at three. And there's a new wrinkle now: agents work better with one codebase, one context, one place to reason about the whole system. Monoliths give you that. Microservices fragment it. The small teams we just talked about don't need the orchestration overhead, and the agents they're working with do better without it.

Honestly though, the most interesting thing isn't AI itself anymore. AI is everywhere. Instagram, X, LinkedIn, ads, papers, the radio. The interesting question is no longer "what about AI." It's what does the rest of software look like when AI is a given.

"The interesting question is no longer 'what about AI.' It's what does the rest of software look like when AI is a given."

If there's one through-line in Ravi's answers, it's the shift from coders to builders, and from headcount-as-leverage to headcount-as-overhead. The tools are already in place. The question is whether teams are organized around them.

More conversations with the HappyFunCorp team coming soon. Curious what we're shipping with these principles in practice? See our work, or subscribe to The Build for monthly dispatches from inside the studio.