Episode 35
How To Design Generative AI Features For Adobe Acrobat (& Break Into Machine Learning Engineering Roles) - w/ Nikhil
One of the twenty most-watched Ready Set Do episodes on YouTube right now.
Most AI conversations skip the part where someone has to build the thing inside an actual product with real users and real constraints. Nikhil talks through what it looks like to design generative AI features for Adobe Acrobat and how that kind of work maps to machine learning engineering roles.
Who this is for
- You are breaking into a new lane and need proof before the story looks obvious.
- You would rather hear Nikhil's version while the mess is still fresh than get another polished hindsight sermon.
Key takeaways
- Design Generative AI Features For Adobe Acrobat (& Break Into Machine Learning Engineering Roles) - w/ Nikhil
- Most AI conversations skip the part where someone has to build the thing inside an actual product with real users and real constraints.
- It is a useful episode if you have been staring at the AI wave and wondering how to get from interested to useful.
Need the cleaner version?
I pulled the sharpest parts of this lane into a guide so you do not have to reconstruct the answer from memory later.
Read the complete transcript
The edited transcript keeps the speakers' ideas, timestamps, and specific details while removing repetition and filler.
Transcript-backed moments
A few lines worth stealing before you hand over the full hour.
Nikhil Pendse says a machine-learning career cannot be built through one lane alone. Candidates need coding ability, subject knowledge in machine learning and deep learning, and practical projects. Courses provide vocabulary and theory, but building exposes integration problems, software-engineering gaps, and the difference between understanding an algorithm on paper and making it useful.
Data structures and algorithms still matter because a machine-learning engineer is also a software engineer. Models must be connected to applications, data, services, and production constraints. Nikhil does not argue that every role has the same coding bar, but says foundational engineering makes it easier to build, debug, and maintain ML systems.
He is comfortable with beginners hacking together a prototype from reusable components. Building backward from a desired result can be an effective way to learn. The limit appears when no ready-made component fits, performance matters, or the system must be rebuilt from the ground up; then foundations stop being optional.
Hackathons show the tradeoff clearly. Participants from software, analytics, or another field may assemble a machine-learning prototype in one day by reading references and connecting tools. That can demonstrate an idea to users or investors, but a prototype is not automatically a secure, reliable, or deeply understood production system.
Nikhil studied electronics and communication engineering in India and entered machine learning through his undergraduate capstone. The project helped him join a data-science and machine-learning team after graduation. His route is evidence that a non-CS major can cross over, but it still involved sustained technical work rather than a title change alone.
Show notes
Most AI conversations skip the part where someone has to build the thing inside an actual product with real users and real constraints. Nikhil talks through what it looks like to design generative AI features for Adobe Acrobat and how that kind of work maps to machine learning engineering roles. It is a useful episode if you have been staring at the AI wave and wondering how to get from interested to useful.
More in Break In
Same mess. Different guest. Pick the next conversation that feels closest to your real life.