Dinesh Mittal

About

I have spent 26 years in engineering across Samsung, Qualcomm, Intel, OLA Krutrim and Palo Alto Networks, working hands-on in embedded systems as well as platform and infrastructure engineering.

Today I am a co-founder of NeoSmith AI, where we build codebase-specific small language models and a routing layer that sends each task to the cheapest model that can do it well. I write here about AI infrastructure, platform engineering and the economics of running both.

More about me →

years in engineering

26

companies, from embedded to cloud

6

NeoSmith AI · Palo Alto Networks · OLA Krutrim · Intel · Qualcomm · Samsung

Writing

• 23 Sept 2026 · 2 min read

  Why my notes and my website live in two separate repos

  One private vault for everything I think, one site for what I choose to share, and a small script as the only bridge between them.

• 20 Sept 2026 · 1 min read

  Formatting reference (sample, archive before launch)

  A sample post showing headings, lists, code, tables and quotes, so you can see how each renders. Set its status to archived before launch.

All writing →

Experience

1. 20XX – Present

   Co-founder · NeoSmith AI

   Building codebase-specific small language models with a hybrid routing layer, so engineering teams get useful AI assistance at a lower cost per task.

   • SLMs
   • Inference
   • Routing

2. 20XX – 20XX

   IT Infrastructure Platform Engineering · Palo Alto Networks

   [Scope, team size, and one outcome with a number.]

   • Platform engineering
   • Infrastructure

3. 20XX – 20XX

   [Role] · OLA Krutrim

   [Scope, team size, and one outcome with a number.]

   • AI cloud

4. 20XX – 20XX

   [Role] · Intel

   [Scope, team size, and one outcome with a number.]

5. 20XX – 20XX

   [Role] · Qualcomm

   [Scope, team size, and one outcome with a number.]

   • Embedded

6. 20XX – 20XX

   [Role] · Samsung

   [Scope, team size, and one outcome with a number.]

Download CV (PDF) →

How I work

1. 01

   Cost is a design input

   Unit economics belong in the architecture review, not in the post-launch surprise. I ask what a request costs before asking how fast it is.

2. 02

   From silicon to service

   Having worked from embedded systems to cloud platforms, I look for the layer where a problem is cheapest to fix, which is often not the layer where it shows up.

3. 03

   Platforms are products

   Internal platforms succeed when engineers choose them. That means clear interfaces, honest documentation, and measuring adoption instead of mandating it.

4. 04

   Small teams, clear ownership

   Most delivery problems are ownership problems. I prefer fewer, smaller teams with explicit boundaries over large groups with shared responsibility.

Services