Eternal Journal

ML Engineering vs Quick feature building

This is a topic that in the recent times has invited a lot of controversial thoughts and opinions. After the advent of highly competent LLMs, everyone has been on the edge of vibe coding everything when they often overlook years of engineering put into place by the team that built the SaaS. While building a product from scratch is not as rigorous as it used to be, what matters is how you redefine the branches of the tree that has already been built gazillion times earlier.
We as engineers have a problem to solve, and hence all the angles need to be considered. Here we will talk about common things that are ignored while taking an ML engineer into consideration from a business vantage point.

Ignorance

Basics once again. What is the difference between software engineering and ML engineering. ML is a huge, huge subset of Software engineering. While building a product is, again, not as demanding, further enhancing the product becomes very necessary. When operating a business, if your target audience is someone who is loving your product, they by default expect you to engineer good updates at regular intervals. Knowing the audience becomes immensely important especially if you have the first mover advantage in any field.
A good ML engineer knows:

The above factors tend to reinforce 'ear-to-ear' spread of the service that is offered by an org, and hence we gain new customers.
Ignorance surely might be bliss, in retrospect, it becomes blight when the service in the long run is overlooked.

Importance

With the onslaught of LLMs passing benchmarks and going up the scale every day, coding amongst other laborious tasks, has been democratized. Everyone can now, essentially code. Everyone can now essentially 'build' the multi dollar product of MNCs that they had been selling for decades. However, there is a catch. You can't replicate their years of engineering on their services even when you have years of experience as a coder via just vibe coding.
Exactly why an ML engineer is necessary, and so, because so, even when the whole idea of a product is directly proportional to how densely ML is being utilized, a 'tool' mindset can only take you so far. To micro-optimize the characters, refactor the math behind the peformance, think in terms of data, making the patterns obvious enough for the service to catch up, is something that can only be perceived by an ML, an experienced ML engineer. Only he is clairvoyant enough to see the patterns and make a decision on how the masses including the outliers be treated, so as to return the maximum shareholder value.

We don't want to build an Akinator, we want an extremely specific, catered to our and only our audiences, so that the general audience, who have no relevance outside the importance, do not end up with our service like this:

Chevrolet AI

RnD

When a service becomes necessary af for the company to remain relevant in their field and multiple competitors have now established their foothold, it becomes important to constantly come up with new stuff about what's so necessary for your product, why should they choose you, what do you offer different when all of them offer the same. Well there are 2 solutions, you eliminate the competition, or you invest heavily into research. Given that you aren't in mood for 1st solution, it becomes necessary to try new things, achieve convergence and grow out more 'branches' that your competitors can't presently offer, and hence gain a share advantage in the space.
All the reduction in the API prices of LLMs today, such as Llama-4(that offers 10M context length in scout), that you see today are because of heavy research put by DeepSeek as a competitor. When you stop innovating and focus solely on the business perspective where your only goal is to bag multiple clients, it creates a room for multiple competitors to challenge the authority and the product itself which in turn, challenges the first mover advantage once again.\

Thus, a good investment into research, once you have established your foothold in the arena, becomes an alleviating ladder for your services especially when your product revolves around ML. Since model drifting is very real, any sufficiently advanced ML system will fracture in ~2 years when new data is brought into account. A new architecture, a new subsystem, a whole new cycle of solving the problem via ML techniques with time is necessary to keep the machines running.

You don't want the client to call you and say that your services have degraded after a year and hence we're switching to an alternative 🤷‍♂️

Finally I think I've said enough. It's your business, decide for yourself :)