At the start of one’s career, it’s very easy to fall into the trap that the hard part of AI is the model. Days and months are spent chasing that better score, the fancy demo and convincing yourself that the accuracy once the high accuracy is achieved, the impact will follow. More often than not, the results of such a pursuit are disappointing.
It’s been an interesting practical observation of the experts that AI systems which impact millions are rarely the ones with the best architecture. The ones that survive contact with reality, messy inputs, edge cases that pop up at 2am are the ones we hear about.
The core mindset shift is simple: stop building models and start building systems. The model makes a small component, but the system is what eventually brings the whole value to the user.
The problem then shifts to finding cases where success is measurable and not where making the model “smarter” is the goal. “Make it smarter” isn’t a product goal. “Reduce time-to-resolution for support tickets,” “catch risky transactions earlier,” “summarize clinical notes without missing key contraindications” are goals. This forces you to understand what really matters and the realisation soon sinks in that the highest leverage work is attached to a real decision and not a cool output.
Now come to the part where the real winners live and what most people tend to ignore: Data. In my personal experience, most AI projects fail not because the model is weak but because the data is misunderstood. The way data is interpreted is often so subjective that some intricate labels mean totally different things to different teams. Definitions drift. A field that used to mean “unknown” suddenly means “not collected.” If you want impact, you need to start treating data like a product with an owner. A certain level of basic discipline is required. Things like schema checks, versioned datasets, clear label definitions, and the ability to answer without guessing or wondering where exactly a particular feature comes from. Trust me, this work isn’t glamorous but lays the foundation for sure.
As a young engineer myself, there is something we resist. Prototyping. Ship something basic before you ship something fancy. Baselines are not embarrassing and in fact act as stabilizers. A rules engine, a simple classifier, a retrieval-first approach for language tasks, even a “human-only” baseline that documents what happens without automation, all give us a reference point. They also give us a fallback. When your advanced model inevitably misbehaves, a baseline can keep the system safe while you fix the problem.
I’ve been talking about the smaller picture but now it’s important to talk about the big picture objective for AI at scale i.e. designing for failure. Traditional software failures are very obvious. The code may throw errors or crash altogether. AI on the other hand can be confidently wrong and “hallucinate”. It can degrade over time as the world changes and its scope is so large that people can use it for use cases unaccounted for. If you want millions of users, you need guardrails: moments where the system can abstain, route to a human, fall back to a safer default, or shut off automation instantly. You need auditability: logs of inputs, outputs, model
versions, and key signals used. You need monitoring not as an afterthought, but as part of the product.
Finally, the AI effect depends on integration. If your system lives in a separate dashboard, you’ve built an art installation. Real AI is embedded where decisions are made. It saves clicks. It reduces mental effort. It shows up at the moment it can change an outcome.
In my own work across the healthcare and finance sectors, the biggest lessons were rarely about swapping architectures. They were about the messy reality around the model: inconsistent labels, shifting definitions, operational constraints, and the difference between “correct” and “safe.” That’s the work that scales.
The punchline is clear: young engineers don’t need permission to build AI that impacts millions. But they do need a different target. Don’t aim to build a smart model. Aim to build a reliable system. The model is the spark. The system is the engine. Build the engine.
Penned by – Tanmay Gulati, Software Engineer, MarketAxess
