How I Learn AI Frameworks While Running a Company

The Treadmill Problem

AI in 2025 moves faster than any individual can track comprehensively. New model families release every few weeks. New frameworks emerge monthly. Benchmarks that meant something six months ago are now obsolete. For someone running a company, the question isn't "should I keep up?" — it's "which subset of this river of new information is actually worth my time?"

I've tried several approaches to this problem. Here's the system that has worked consistently over the last two years.

The Two-Tier System

Tier 1 — Broad awareness (2 hours per week): A curated reading routine that gives me awareness of what's happening without requiring deep engagement with everything. My current sources: Hugging Face daily papers digest, The Batch from deeplearning.ai, and the top 3 upvoted posts on r/MachineLearning each Friday. This takes about 90 minutes per week and gives me enough signal to know what I need to dig into further.

The key discipline: I read headlines and abstracts, not full papers, for everything in Tier 1. If something makes me think "this might change how I'd approach [specific problem we're working on]," I flag it for Tier 2. Everything else gets a skim and a mental note.

Tier 2 — Deep learning (4 hours per week, protected time): Thursday mornings are blocked on my calendar for learning — no client calls, no internal meetings, no async interruptions. This time goes to whichever Tier 1 flag was most significant that week, plus one ongoing topic I've designated as the quarter's "depth focus."

Current quarter focus: multimodal model architectures, specifically how vision-language models handle grounding — mapping language concepts to spatial positions in an image. This is directly relevant to SmartON's scene understanding capability and the next phase of MIRA's development.

Learning by Building

Reading and watching videos is necessary but not sufficient for technical depth. Every significant new framework or technique I want to understand, I build something with it before I'd say I understand it.

The builds don't need to be large. When I was learning how Transformers.js handled Web Worker communication for Dhiya NPM, I built a minimal working example in 200 lines before writing production code. This revealed two behaviors that the documentation didn't mention clearly and would have caused bugs in the production implementation.

The rule I follow: before I'd explain a new technique to a colleague, I should have built something that fails in an interesting way. Interesting failures are how you learn the edge cases that documentation writers assume you'll discover on your own.

Knowing When to Go Deep vs. Skim

Not every new development warrants deep engagement. The signal I use: would this change a decision I'm about to make, or a decision I expect to make in the next six months? If yes, go deep. If it's interesting but not decision-relevant, skim and note it.

Practical examples of decisions that triggered deep learning recently:

• We were deciding between LangChain and LlamaIndex for a new document processing pipeline → 4 hours of hands-on comparison, wrote a decision memo
• A new vision-language model released with claimed SOTA on several benchmarks → skimmed the paper, noted the benchmark numbers, flagged for potential evaluation in 3 months when it's more stable
• Chrome announced updates to the built-in AI API → 2 hours deep dive because Dhiya NPM directly integrates with this