Forem: Navin Varma

We've Been Here Before: Leading Engineers Through the AI Wave

Navin Varma — Mon, 13 Apr 2026 12:01:40 +0000

These are my personal thoughts, experiences, and opinions, and they do not reflect the views of the company I work for.

Last month I was reading a Hacker News thread about a blog post called "We might all be AI engineers now". The comments were honest in a way you don't get from your favorite LLM chatbot.

Between that thread and my own X & LinkedIn feeds, the terms keep piling up. Forward Deployment Engineering. Agentic Engineering. Token Cost Optimization. Context Engineering. AI Safety Engineering. If I'd shown this thread to the version of me from 2021, I'd assume it was science fiction.

I've had this exact feeling before across various times in my career now that I'm reflecting on this strange sense of deja vu. In 2001, I was a student in India living through the dot-com bubble burst from across the ocean. In 2007, I was an early-career software engineer in India's IT services industry, on the receiving end of the follow-the-sun model, watching global delivery models get stitched together in real time. By 2010, the mobile app boom had everyone convinced that if you didn't have an app, you didn't have a business. By 2014, every company was scrambling to get their infrastructure "into the cloud." The vocabulary changed each time, the anxiety was real each time, and the people who came out ahead weren't the ones who predicted the future. They were the ones who recognized the pattern.

I wrote about this feeling of acceleration back in January in AI Saturation and touched on it again in Software Engineering as a Craft. Three months later, I want to reflect on how time and again, we get reminded of how humans react to changing winds. The more I witness the evolution of AI, the more I realize the playbook for leading through it isn't new. It's been written before by leaders who navigated transitions just as pathbreaking as this one. This post dives into my perspective of learning some interesting things from the past while keeping an eye on how we evolve into the future.

The Internet: When it was cool to be on the "Web"

I remember the late '90s as a teenager growing up in the fledgling world of software services in India. You could sense how everyone was joining Engineering colleges that proliferated all over India, especially across South India. You had students scoring the top ranks all choosing Electronics and Communication Engineering (ECE) or Computer Science and Engineering (CSE). The more "core subject" person chose something like Electrical and Electronics Engineering (EEE) or more niche like Chemical Engineering, Textile Engineering and so on. However, the Y2K problem had sent demand for computer-literate workers through the roof in India, and suddenly everyone was enrolling in NIIT evening classes the same way the generation before had lined up for typewriting courses. Over in the US, every business needed a website, a "web strategy," and a "webmaster" (remember that title?). Entire consulting practices sprang up overnight to help brick-and-mortar businesses figure out HTML. Pretty much everyone who did a non-CS degree still pivoted to an IT job in software factories using labor arbitrage to their advantage. Well, we've come a long way since then in retrospect.

Most of those web companies failed. This was not because the technology was bad, but because they'd confused having a website with having a business. The ones that survived, Amazon selling books, Google organizing information, Yahoo providing email and news solved a real problem for real people. The technology was the enabler but not the product in and of itself. The leaders I admired during that time and those who led through changing times shared a common trait: they asked "why are we building this" or "what problem does this solve?" before they asked "how does this technology work?" They were paying attention to the new tools to learn how to support their teams through transformation. They refused to let the tools drive the business strategy.

A scene from a campus in Mysore, February 2007. From my personal archives, taken during my short stint there. This was the epicenter of India's IT boom, where thousands of fresh graduates were being minted into software engineers every quarter.

Global Delivery: When your work spanned Time Zones

The global delivery model (aka offshore development) wave of the mid-2000s was different because it wasn't really about technology at all. It was about operating models, about economies of scale, tapping into labor arbitrage and financial macroeconomics. Your team wasn't down the hall anymore. They were in Dublin or Bangalore or Hyderabad or Manila, and depending on which time zone got priority, your meetings were either at 7 AM or 9 PM.

I have lived this from both sides, which gives me a perspective I don't think everyone has. If you did not realize it by now in this post, I grew up in India during the outsourcing boom of mid-90s to mid-2000s. I watched relatives and friends build careers in IT services companies that were scaling people at breakneck speed. The company I first worked for is currently at employee number ~353,500. I was ~71,500 about 20 years ago. Later I moved to the US and experienced the other side of it, working on teams that were figuring out how to collaborate across 12-hour time zone gaps. The fear of missing out on both sides was something else. I still remember getting a DM from someone in Atlanta at 7:30am their time, when I was closing out my day at 5pm after my evening tea. People in the US focused on getting the project completed with the same quality as what they would have done in-house. People in India worried about being treated as interchangeable if this project did not go well, or cost-overruns threatened future contracts. And managers everywhere were dealing with communication overhead, quality concerns, and the dreaded "follow the sun" model that sounded brilliant in a boardroom but was complicated in practice.

The good leaders I worked with during that time understood something important. They invested in communication infrastructure before they invested in headcount. Shared documentation, clear ownership, regular face time even if it meant someone was on a video call at an unreasonable hour. They treated distributed teams as a design constraint, not a cost optimization. The leaders who treated offshoring purely as a cost-cutting exercise got exactly what they paid for. The ones who saw it as a way to access global talent and build something more resilient? Those organizations are still thriving. It is funny that the age of AI takes us back to the same principles. I still remember in my new hire training, an off-the-cuff remark made by a trainer about "document everything, so if you get hit by a bus, the project continues". That's not what a starry eyed new grad wants to hear, but it was the reality of operating a world where humans are replaceable cogs in a larger system that chases the bottom line.

Mobile Apps: Adjusting to a whole new era of smartphone apps

Apple launched the iPhone in 2007 and the App Store in 2008, which triggered the smartphone app wave. It felt like the dot-com boom all over again but in your pocket. Every business needed a mobile app. It didn't matter if you were a restaurant, a dry cleaner, or a bank. "There's an app for that" became the mantra and entire companies were built around the idea that mobile was going to eat everything.

I remember the explosion of new titles here too. "Mobile Developer" became its own specialization overnight. You had iOS developers, Android developers, and then cross-platform developers arguing about whether PhoneGap or Titanium or later React Native was the right way to build. App marketplaces created a whole new distribution model that startups could ride without needing a sales team. And the gold rush of apps, most of which were terrible, reminded me of all those dot-com websites that existed just to exist. I still remember seeing my favorite Snake game in Nokia get replaced by Tic Tac Toe or Chess as the default game to play. The concept of games never went away, but the mode of delivery and interactivity birthed a new frontier for businesses wanting in on action.

What struck me most was how the best companies during that era didn't just build an app and call it done. They rethought their product for the new form factor. The ones who just shrunk their website into an app got mediocre results. The ones who understood that mobile was a different context, different attention span, different interaction and data model, they built things that actually worked. Every country did not have access to these devices nor did the internet penetration really go so quickly, so you had to adapt to tracking metrics differently and build for your audience. It's a lesson I keep coming back to now, because a lot of what I see with AI integration today feels like the "just shrink the website into an app" phase.

Cloud Migration: When "Just move it to AWS" was the popular answer

The cloud migration wave of the mid-2010s is the one I experienced most directly, first as a hands-on engineer and then as a team leader working on K-12 compliance software. "Lift and shift." "Cloud-native." "Serverless." Customers were wary of the move to the cloud, it meant a loss of control or maybe a doubt around trusting a third party with their most important data. Eventually, they came back to the same question: "Why isn't this in the cloud yet?". When an industry deals with transformations in technology, the first reaction is to not trust the thing. Eventually, the new normal is to expect everything to follow the new pattern of work.

That era had its own explosion of new titles. Centralized DevOps teams popped up everywhere. "DevOps Engineer" became a real job title that hadn't existed a few years prior. AWS certifications became the new resume standard. Companies were hiring cloud architects before they'd even decided what to migrate. I remember a specific conversation with a VP of Engineering, "We need to provision AWS accounts as soon as possible and move everything to it". I was sceptical about the team's experience with cloud infrastructure. It was marketed as an opportunity to learn. It reminded me of when you buy a brand new Mercedes-Benz for your first behind-the-wheel driving lesson. Or in my case, it reminded me of when I bought a $100 guitar to learn how to play (P.S: I've probably tried learning it with a start/stop cycle of 50 times).

Coming back to that cloud migration story, I moved on before I could see how that particular story ended. I recall every company was playing whack-a-mole with massive on-prem to cloud migrations. Meanwhile, cloud-native companies entered the fray without any legacy baggage, and acquisitions and mergers drove a lot of the strategy for incumbents. Cloud data centers continued to be built for the day when the great on-prem migration would come. Entire data center industries came up where companies operate private clouds by renting out server space. It became an inflection point where build vs. buy conversations started driving capital expenditure in ways they hadn't before.

This feels like the same story in a different decade. Cloud computing really was better for most workloads, but the genuine shift got distorted by urgency and hype into a mandate without a plan. The leaders who got it right treated migration as a multi-step transformational journey, not one quarter's OKR. They ran experiments, picked the right workloads first, invested in training before migration tooling, and were okay with some things staying on-prem. However, doing nothing and sticking to old ways led to eventual disintegration as the industry moved to newer frontiers. You were discussing and debating strategy when the market transformed around you.

AI in 2026: Where we are now

I'm looking at my feeds right now and it's a fire hose. AI Safety Engineering. Local LLMs you can run on a Mac Mini (I've been doing this myself). Cloud API providers for every conceivable AI service. Token cost optimization as an emerging discipline. Agentic use case prioritization frameworks. Agentic engineering as a job family. Forward Deployment Engineers who sit between the AI model and the customer. Every week there's a new infrastructure, a new framework, a new model release, a new attempt at trying to pivot cloud offerings into the AI era. My LinkedIn feed looks like a word cloud of terms. The irony is Generative AI in itself has caused so much AI saturation hitting LinkedIn, X, Medium and so many other places. I'm surprised by how much AI saturation there is, the abundance of information is indeed something that provides a great opportunity to filter the signal from the noise.

This feels familiar because the pattern is always the same. A real technological shift creates genuine new capabilities, which creates a gold rush of new companies and job titles, which creates the FOMO feeling about falling behind, which creates pressure to adopt everything at once. The leaders who navigate this well are the ones who resist that last part.

Thoughts on navigating a new era

I don't have it all figured out. I didn't live through the pre-Internet computing world, so that may offer lessons for students of history and is something I'd like to read up on (comments welcome on any reading material!). But having watched four of these cycles play out in my career, I'm thinking of a few things to keep me and the people around me grounded.

I'm treating AI in my daily workflows as a strategy, and baking in evals at every step of the way. This is the same idea as distributed teams being a strategy with clear contracts, or cloud infrastructure being one with metrics around costs driving decisions. The question I keep coming back to is "what problem are we solving, and does AI actually help us solve it better?". Sometimes the answer is yes. Sometimes being clear about what you want to build into the spec or finding an off-the-shelf library gets you further.

I'm advocating for experimentation time for my team, I try to keep inspiring them into trying things out and blocking dedicated time for self-learning. One of the biggest mistakes I saw leaders make during the cloud migration era was not giving their teams time to learn before expecting them to deliver. I'm trying not to repeat that but it is hard as the days go by. Sometimes sounding the alarm seems too heavy-handed, but I recognize that lifelong learning is a skill by itself. I wrote about this in my post on the craft of engineering, I really like the idea that everyone starts at zero.

On the topic of taking risks, I'm being deliberate about which ones to make. During the cloud migration wave, companies that did not pay attention to their core user base but pivoted a 100% to the new technology ended up doing badly at both. I'm wary of applying that same thinking. It seems wise to pick specific use cases where AI adds clear value and getting good at those before chasing every new thing that comes out this week. Deterministic outcomes in certain industries matter more than probabilistic outcomes. Moving with a sense of urgency is good, and I'm thriving in a world where the constraint is no longer the ability to produce something, but making it really useful is an interesting challenge to live through.

I keep watching for what I think of as the naive "follow the sun" trap. Follow the sun is a legitimate operating model. Many global companies run it successfully today. The early versions assumed you could hand work off across time zones without losing context often leading to things breaking. The companies that made it work invested heavily in documentation, handoff rituals, shared tooling. The ones that just split epics across time zones and hoped for the best ended up slower with more bugs. I see some interesting parallels with how teams are choosing between traditional software delivery and pivoting to embed agents into workflows. As of today, human in the loop tasks requiring judgment, context, or institutional knowledge are being revisited to see how they should evolve. The companies that invest in the scaffolding around this, clear specs, guardrails, human review loops, will get the value. The ones that skip that work will be in the same predicament around how the cloud migration occurred.

The dust always settles

In January, I wrote that I thought we had about two years before the dust settles in this evolution around our software engineering craft. I still believe the world has changed for better, and we're discovering new ways of working, while the two years seem very far away. Every quarter seems more exciting than the past one. Every major industry shift I've lived through followed a similar pattern. There's an explosion of activity followed by a period where things consolidate with winners and losers in technology, processes and patterns. Eventually a new steady state where the real value becomes clear and the noise fades.

The pioneers of new technology often displaced some of the old players, some adapted to survive in the new world. The shift of the landscape though was permanent. The path from "everything is changing" to "here's how we actually work now" did not take days. It took months, if not years, and the breakneck pace of innovation took a solid 12 months to become structured with formalized set of learnings.

I don't know what the steady state looks like for AI as it transforms the world. Nobody does, and I'm skeptical of anyone who claims to. But I do know the playbook for getting there: filter the noise, invest in your people, manage your risks deliberately, and give yourself permission to not adopt everything at once.

We've been here before, we are living through it again now and I'm pretty clear that we'll be here again in the future. The specific technologies change but the leadership challenge stays remarkably consistent: stay curious enough to learn, disciplined enough to focus, and patient enough to let the dust settle.

If you're an engineering leader feeling overwhelmed by the pace of change right now, give yourself time to take a breath. The moment feels similar to what leaders went through in 1999, 2007, 2010, and 2014. It means something real is happening. It also means the most important thing you can do right now is think clearly to navigate through a changing landscape. I was a practitioner in the past transformational shifts, I'm a leader of people and technical strategy in this one. The path forward is bright for those who see light in the possibilities. How you see the world and how you can navigate change may define how you lead your teams. What an exciting time to be building!

This post was originally published on nvarma.com. Follow me there for more on software architecture, engineering leadership, and the craft of building things that last.

Vibecoding a Video Editing Pipeline

Navin Varma — Mon, 06 Apr 2026 12:01:29 +0000

Canva's AI-generated hero image for this post. It crammed every location into one impossible geography. CLIP would score this a 10.

These are my personal thoughts, experiences, and opinions, and they do not reflect the views of the company I work for.

Last week I wrote about driving the California coast and finding clarity. That was a reflective post. This one is about nerding out this weekend on all things AI video editing, LLMs and iMovie version.

I came home from that trip with 27 video files across two cameras with about 17.5 GB of footage. My main driver phone is a Samsung Galaxy S24 Ultra and last Thanksgiving, I got a Xtra Muse vlog camera for 4K scenic shots. During that trip, our first stop was my favorite Pier 39 sea lions after which we took a couple of different views of the Golden Gate Bridge on a rare fog-free day. The next day we went on to 17-Mile Drive and Pebble Beach. This was the California Coast in all its glory waiting to be explored, and my opportunity to capture it unedited in some of the most amazing scenery I have seen.

It has been on my mind on how a lot of people are using AI tools to do these content creation pipelines, and my curiosity got the better of me that I had footage to experiment with. My requirement was a simple 90-second highlight reel and a couple of YouTube Shorts. Since I was exploring a bunch of Local AI for edge apps prototyping, my guess was it would be quite a breeze to edit these videos. I don't have OpenClaw just yet, so this was my deep dive into learning traditional video editing in case things didn't work out. I've done sound recording and mixing semi-professionally, so how hard can video be? It turns out, it's quite the skill to learn.

Defaulting to ComfyUI

My first instinct was ComfyUI. I've written about using it recently and it felt like the right tool. I thought I could use image-to-video workflows to enhance the footage, or at least use it for some creative transitions.

I opened Google AI search and started brainstorming. I realized quickly that this wasn't a generation problem. I didn't need to create new footage. I needed to sift through 17 GB of existing footage and find the good parts. ComfyUI is a Swiss Army knife for image and video generation, but for selection and editing? This was the wrong tool.

Next Up: Gemma 4 and TurboQuant

Google had just released TurboQuant alongside Gemma 4, and I was itching to try local multimodal inference. The idea I had was to extract frames from every video into a folder, feed them through Gemma 4's vision model locally on my Mac Mini, and have it pick the most scenic shots.

I spent an evening chatting with Gemini about this approach. I even wrote a director.py script that loaded gemma-4-E4B-it-4bit through mlx-vlm, fed it batches of 35 frames resized to 112x112, and asked it to pick the best ones. It sort of worked. But "sort of" is a generous way to describe a script that was slow, it hallucinated filenames, and couldn't reliably distinguish a parking lot from Pebble Beach at thumbnail resolution.

The core problem was that I was using a vision language model for a task that didn't need language. I didn't need the model to describe what it saw. I needed it to score how scenic each frame was. That's a similarity match problem, not a problem solved using conversational AI.

Pivoting to a Claude Code project

I haven't really tried out Google's Vertex AI in depth, or explored Antigravity's capabilities. I'd been going back and forth with a Gemini 3.1 Pro chat, learning a lot about Gemma 4, quantization, and multimodal inference. But I kept running into hurdles. There were model loading quirks. There was a 35-image batch limit beyond which my Mac Mini M4 Pro (24GB) would go bust. The 112px resolution was killing all the detail I needed. After a couple hours of this, I decided to pause and rethink.

What if I just pivoted to load Claude Code in the folder of raw videos and described what I wanted?

I opened a new Claude Code session with Opus 4.6, gave it access to ~/Movies/SFO_PebbleBeach/raw/, and explained my goal. Within the first exchange, Claude corrected my typo on something as I was describing my need. It pointed out that mlx-lm is text-only, that for vision I needed mlx-vlm, and that for "find nature/scenery frames" CLIP is the right primary tool, not a VLM. "CLIP (Contrastive Language–Image Pre-training) builds on a large body of work on zero-shot transfer, natural language supervision, and multimodal learning. "

That was the moment I discovered a lot about prior art (pun intended). I've dabbled a bit before in the early days of AI tech coming out but always went to Cloud AI providers to experiment, this was the first time I had a real world use case to run through it.

Discovering CLIP

If you haven't used CLIP for something like this, it's quite simple. Once you give it a frame and a text prompt, it tells you how similar they are.

So instead of asking a language model "is this scenic?", you need to encode the frame and compare it against prompts like "dramatic Pacific Ocean cliffs" and "Monterey cypress trees on rocky shore". The same kind of thing I'd add as positive prompts in ComfyUI LoRA nodes. Then you need to compare against negative prompts like "blurry photo" and "car dashboard". The difference between the positive and negative similarity scores gives you a single number: how scenic is this frame?

Running on Apple Silicon MPS, CLIP processes frames so fast it makes VLM inference look like it's stuck in an infinite loop (at least on my machine).

Custom rigging a 10-Stage Pipeline

Claude didn't just suggest CLIP. It designed a full 10-stage pipeline and wrote every script. I vibed all the way with nods like I knew what I was doing (I was not :>|). I was just describing what I wanted and iterating on the output.

Here's what Claude listed as what the pipeline does:

Probe every raw file with ffprobe to inventory codecs, resolutions, and framerates
Detect shots using PySceneDetect's adaptive detector, so clips align with actual camera cuts
Extract 3 representative frames per shot (10%, 50%, 90%) instead of the brute-force 1-fps approach
Score frames with CLIP against scenic prompts, plus classical CV signals (Laplacian sharpness, HSV colorfulness, brightness, face detection)
Filter for shake and blur using optical flow variance
Tag locations using GPS from the Samsung files and CLIP zero-shot for the Xtra Muse (which had no GPS)
Select clips for a 90s reel and two 30s shorts, balancing score, location diversity, and chronological order
Normalize each clip to a common format (4K30 HEVC for the reel, 1080x1920 H.264 for shorts)
Concatenate into final outputs
Verify specs, durations, and that the raw folder was never modified

The scoring formula was described as a weighted combination:

frame_score = 0.35 * clip_scenic
            + 0.20 * sharpness
            + 0.15 * colorfulness
            + 0.15 * nature_ratio
            + 0.10 * brightness
            - 0.40 * has_face * (1 - nature_ratio)

That last term is clever. It penalizes faces, but waives the penalty when the scenery dominates. So a wide shot of the Golden Gate Bridge with a few tourists in the corner keeps its score. A selfie gets rejected.

Some surprising learnings

Python's scientific ecosystem is really good for this. I didn't need any exotic AI tooling for most of the pipeline. Claude chose OpenCV's Laplacian variance for blur detection, Hasler-Süsstrunk colorfulness, HSV color masks for nature detection, Farneback optical flow for shake. These are computer vision techniques from the 2000s and they worked perfectly. The AI involvement (CLIP) was just one stage out of ten.

Location tagging with CLIP zero-shot actually worked. The Xtra Muse camera had no GPS data, so Claude suggested using CLIP to match frames against location-specific prompts like "Golden Gate Bridge" and "Pebble Beach golf coastline". It wasn't perfect (Pier 39 and Pier 41 look similar from the water), but it was good enough to ensure location diversity in the reel.

The EXIF correction was its own mini-adventure. The Xtra Muse had timestamps from June 2000 instead of March 2026. Off by 25 years, 9 months, and 6 days. Claude walked me through the exiftool date shift since I've forgotten the exact format after spending most of my college days tagging photos on my Macbook Pro. It caught me when I accidentally ran a write instead of a dry run, and helped me recover from the backup. Somehow my trip footage is from the future and the past simultaneously.

The final edit involving a human and a robot

The pipeline output a 90-second reel and two shorts. This was quite impressive for a vibe coded adventure. It had its flaws though, and I definitely wanted to edit this a bit more.

I imported everything into iMovie for the final pass. I trimmed a couple of clips where the pipeline chose a good scenic shot but caught the tail end of a camera movement. I removed one clip of Golden Gate Bridge that was technically scenic but felt out of place in the flow. This is the kind of editorial judgment that's hard to score numerically.

For the soundtrack, I turned to Gemini. My last YouTube video (a Waymo ride through SF) got hit with a copyright notice for the music, and I didn't want to deal with that again. Gemini generated "The Road and the Sea", a track that fit the mood without any licensing headaches.

The final step was to put it all together and upload to YouTube and declare victory. (yay!)

Learning through pain

I went into this wanting to edit a video. I came out thinking differently about when to reach for which AI tool.

Gemma 4 and local VLMs are impressive, but they're conversational tools. I found that they are great at describing and reasoning about images but terrible at scoring thousands of them quickly. I spent an evening learning this the hard way, and I don't regret it. I understand quantization and multimodal inference better now than I did before.

CLIP is the right tool when you need similarity, not understanding. If your question is "does this match my description?", CLIP answers it faster and more reliably than any chat model. I think a lot of people reach for an LLM when a simpler model would do the job better. I know I did.

The other thing that surprised me was how much of the pipeline didn't need AI at all. Laplacian blur detection, optical flow for shake, HSV color masks for nature. These are well established computer vision techniques. They were perfect for this job. The right answer often isn't the newest model. Sometimes it is just expanding your knowledge of the different prior art that came before all the new hotness.

Vibecoding works for pipelines for a weekend project. I described what I wanted. Claude built the stages that I reviewed, iterated, and run until I got my output. The output was ten Python scripts, an orchestrator, CLIP prompts, ffmpeg encoding flags from a single session. I couldn't have written optical flow shake detection from scratch that quickly. But I could describe what a good highlight reel looks like, and honestly, that was enough.

https://www.youtube.com/watch?v=GjoOt8SQe3w

The video's up on YouTube now. Here I present almost ninety seconds of California coastline, some selected by math, some by neural nets and the rest hand finished by a human. It's a bit like mixing a track in GarageBand. The tools lay down the structure, but you still have to trust your ear for the final cut. I'm already thinking about what to automate next time.

This was not a perfect journey, but it was satisfying to have enjoyed it and finish on a high of completing it. Just like my ride down Pebble Beach on a clear sunny March weekend.

This post was originally published on nvarma.com. Follow me there for more on software architecture, engineering leadership, and the craft of building things that last.

The Constant Coastline

Navin Varma — Thu, 26 Mar 2026 12:01:22 +0000

These are my personal thoughts, experiences, and opinions, and they do not reflect the views of the company I work for.

This past weekend, I packed up the family and drove to San Francisco. No agenda, no itinerary synced to a calendar, and almost no Slack notifications. Okay, there was one I was a little too eager to respond to. But mostly, it was just the open road, some good music, and a few days with the people I love most.

We hit the Golden Gate Bridge on a rare fog-free day. We had ice cream at Ghirardelli Square. We drove the 17-Mile Drive through Pebble Beach and picked up dark chocolate treats from All About the Chocolate in Carmel-by-the-Sea. We stopped at the Mystery Spot in Santa Cruz, because honestly, some days you need a place where gravity doesn't make sense to remind you that the world is more playful than your inbox suggests.

The Golden Gate Bridge, completely fog-free. If you know San Francisco, you know how rare this is.

There's a lot of uncertainty in the world right now. In tech, in geopolitics, in the economy. If you're in a leadership role, you feel the weight of it constantly. The decisions that need to be made, the ambiguity of what's next, the responsibility of guiding people when you have an idea of the path but are leaning on your best judgement to do what's right for everyone around you, knowing full well you can't please all the people all of the time. It builds up. Quietly, persistently, until one morning you realize you've been carrying tension you didn't even name.

I've learned over the years that one of the most important things I can do for myself, and by extension for my team, is to step away. Not escape. Step away. There's a difference. Escaping is avoidance. Stepping away is choosing to create space so you can come back with clarity.

The Constant Coastline

The first time I drove to Pebble Beach was in 2004, and the Pacific Ocean was just a stunning backdrop to a day trip with family. I came back in 2010 as a grad student, slightly older, slightly more aware of the world. In 2019, I visited again, and the photo from that trip is still the one on my homepage today. Since then, I've returned every time family or friends visit from out of town. It's become one of those places I keep coming back to.

Pebble Beach, July 2010. Grad student, web developer, part-time DJ, no gray or balding hair. Same rocks, same waves.

Here's what gets me every time: the coastline hasn't changed, but I've grown and evolved. The same rocks, the same waves, the same Lone Cypress clinging to its cliff. But the person standing there looking at it has gone from college kid to grad student to engineer to engineering leader, through job changes, cross-country moves, losing loved ones, navigating a pandemic, and now leading teams through a significant transformation. Twenty-two years of evolution. The rocks didn't move an inch.

The Lone Cypress at Pebble Beach. There's something about a tree that's been standing alone on a rock for 250 years that puts your quarterly review worries into perspective.

I think about this a lot. We spend so much energy keeping pace with change. New frameworks, new org structures, new strategies, new market conditions. And that's exciting, honestly, because it means we're building in a time where the possibilities keep expanding. But it also means we rarely pause. Standing at the cliffs of Pebble Beach, I'm reminded that the ocean doesn't know what quarter it is. Those rocks were there before your company existed and will be there long after. It's a scale reset. It recalibrates what "urgent" actually means.

Simple Things, Big Returns

I don't think you need to fly to Hawaii or book a silent retreat to find this kind of reset. For me, it's always been simple things. A long drive with music playing, the kind of songs that pull you back to a specific year and a specific feeling. Visiting places that hold memories from earlier chapters of my life. Making new memories of artisan chocolates or a fancy restaurant you've never been to. Showing someone a place you love and watching them see it for the first time. These are small acts, but they reconnect you to a version of yourself that existed before the job title, the responsibilities, and the constant hum of notifications.

The coastline along 17-Mile Drive. No filter, no edit. Just the Pacific doing what it's been doing for millions of years.

This heat wave weekend was one of those rare Northern California days where the sky was perfectly clear and the air was warm. We drove with the sun-roof down. We spotted sea lions on the docks at Pier 39. My wife pointed out wildflowers on the cliffs. And for a few hours, I wasn't thinking about roadmaps or deadlines or the latest industry disruption. I was just present. The world felt enormous and still and exactly as it should be, even as headlines everywhere insisted otherwise.

The Pause Is a Leadership Skill

We talk a lot about resilience, about grit, about pushing through. And those are real. But I've found that some of my best decisions as a leader came not from pushing harder, but from stepping back far enough to see the full picture. It's hard to evaluate a situation clearly when you're inside the pressure of it. Distance, even a weekend's worth, changes the perspective.

What does that look like in practice? It means not checking email on the drive. Not "just quickly" responding to a message at every stop. Actually disconnecting. Actually being in the place you drove to, with the people you brought along. It means trusting your team to hold things down, and trusting yourself to come back sharper for having been away.

I don't know if everyone feels this way when they stand at the edge of the Pacific and look out at the horizon. But I suspect many of you do. We just don't say it out loud often enough, especially in professional circles where "always on" is still treated like a badge of honor.

What I Brought Back from the Coast

The world will keep spinning with its uncertainty and noise. Your inbox will be there on Monday. The hard decisions won't go away. But you'll face them differently when you've stood at the foot of the Golden Gate Bridge on a clear day and remembered that the world, for all its chaos, is still breathtakingly beautiful. The things that evolve fastest need you the most. The things that never change ground you the most. Knowing the difference is what keeps you steady.

Remember to take a step back from time to time, play your favorite music loud, let your favorite places remind you what being steady feels like.

This post was originally published on nvarma.com. Follow me there for more on software architecture, engineering leadership, and the craft of building things that last.

How to Build Free Local AI with Ollama for Small Businesses in March 2026

Navin Varma — Mon, 16 Mar 2026 05:30:24 +0000

My wife is a freelancer looking to start her own home lifestyle business. She'd been using the free tier of ChatGPT to help with things like summarizing research and drafting emails, and kept hitting the limits. "Can I buy the subscription?"

Now, as a good husband, I should have just bought her the subscription. But as an even better husband, I taught her how to set up her own chatbot locally on her Dell laptop. 16 GB of RAM, no fancy GPU, and it cost her exactly zero dollars in software.

No subscription. No data leaving the machine. Each model has its own limits on how much text it can take in, and you figure that out by trial and error, but there's no one charging you per question.

Stop, this post is not for you if:

You're a developer or technical user who already knows what a local LLM is
You're comfortable with Docker, APIs, and model quantization
You're looking for an advanced fine-tuning or deployment guide

(But if you're technical, skip to the end. There's something there for you.)

This post is for everyone else. People who have less technical knowledge but want to start using AI on their own data without uploading it somewhere else. Small business owners, freelancers, anyone who cares about privacy and doesn't want to pay a monthly subscription just to summarize emails or draft replies. We're going to install Ollama, pick the right model, and build a working email summarizer, all in about 30 minutes.

Note: The model recommendations and comparisons in this post are based on what's available on Ollama as of March 2026. This space moves fast, so newer models may be available by the time you read this.

What this will cost you

Let's start with a comparison of the math.

	Ollama (local)	ChatGPT Plus	Claude Pro	Gemini Advanced
Monthly cost	$0	$20/user	$20/user	$20/user
Annual cost (3 users)	$0	$720	$720	$720
Annual cost (5 users)	$0	$1,200	$1,200	$1,200
Data privacy	Everything stays on your machine	Sent to OpenAI's servers	Sent to Anthropic's servers	Sent to Google's servers
Internet required	No	Yes	Yes	Yes
Quality	Very good for everyday tasks	Excellent	Excellent	Excellent

Ollama is free, open-source software that runs AI models directly on your computer. The tradeoff is that local models aren't as powerful as the frontier models from the big providers, but for summarizing emails, answering questions about your data, and drafting replies, they're more than good enough.

Think of it as building your own rig. You explore what's possible locally, figure out what you actually need, and then decide if paying for a cloud service makes sense for the tasks that require more horsepower.

Why people are concerned about uploading their data

This is the other reason to run AI locally, and it's worth spelling out.

When you paste text into a cloud AI service, that text travels over the internet to someone else's servers. Even if the provider promises not to train on your data, the data still leaves your building. For some businesses, that's a problem:

Accountants and bookkeepers handle client financial data like tax returns, bank statements, and payroll. Sending that to a third party, even encrypted, introduces risk.
Law firms are bound by attorney-client privilege. Pasting case details into a cloud AI arguably breaches that duty of confidentiality.
Healthcare practices deal with HIPAA. Most cloud AI tools are not HIPAA compliant, and violations carry criminal penalties.
Any business with proprietary information like pricing strategies, customer lists, or internal communications should think twice about where that data goes.

With Ollama, the answer is simple: your data never leaves your machine. There's no cloud, no API key, no account, no telemetry. The model runs in memory on your computer and disappears when you close it.

What you need (and don't need)

Here's the part that surprises most people: you don't need a fancy GPU. Modern AI models run on regular CPUs and standard laptop RAM.

Mac (Apple Silicon: M1, M2, M3, M4)

RAM: 8 GB works (16 GB is better)
GPU: Not needed. Apple's unified memory handles it automatically
Storage: ~10 GB free for the app and one model
Performance: Expect 15–25 words per second on 8 GB, faster on 16 GB

Mac (Intel)

RAM: 16 GB recommended
GPU: Not needed, but responses will be slower (3–8 words per second)
Practical limit: Stick to smaller models (7B parameters or less)

Windows PC

RAM: 8 GB minimum, 16 GB recommended
CPU: 4 cores or more, made in the last 5–6 years
GPU: Not needed. If you happen to have an NVIDIA graphics card, it'll speed things up, but it's not required
Storage: ~10 GB free

Linux

Same requirements as Windows. Ollama runs natively.

The bottom line: if your computer was made after 2020 and has at least 8 GB of RAM, you can run a local AI model right now.

Picking the right model

This is where most tutorials lose people. Ollama has dozens of models available and the names mean nothing to a normal person. Here's what you actually need to know.

Models are measured in "parameters" (the B stands for billions). More parameters generally means smarter but slower and hungrier for RAM. For a small business, you want the sweet spot: smart enough to be useful, small enough to run on your hardware.

Recommended models by use case

Model	Size	RAM needed	Best for	Speed on 8 GB RAM
Phi-3 Mini	3.8B	~3 GB	Quick summaries, simple Q&A, drafting short replies	Fast
Llama 3.1	8B	~5 GB	Email summarization, longer writing, general assistant	Good
Mistral	7B	~5 GB	Processing lots of text quickly	Fast
Gemma 3	4B	~3 GB	Conversational Q&A, customer-facing tone	Fast
Qwen 3	4B	~3 GB	Multilingual support, good with non-English text	Fast
DeepSeek-R1	8B	~5 GB	Complex reasoning, technical questions	Moderate

Models for searching your data (RAG)

If you want to build a "chat with your data" system, you'll also need an embedding model. This is a small, fast model that helps the system find relevant passages in your files.

Model	Size	RAM needed	Purpose
nomic-embed-text	137M	~274 MB	Converts your documents into searchable vectors
mxbai-embed-large	335M	~500 MB	Higher quality embeddings, slightly more RAM

My recommendation

Start with Llama 3.1 (8B). It's the most popular model on Ollama for a reason. It handles summarization, Q&A, and drafting well, runs on 8 GB RAM, and has a massive 128K context window (meaning it can process very long emails or documents in one go). If your machine struggles, drop down to Phi-3 Mini or Gemma 3 4B.

Installing Ollama

Mac

Open your browser, go to ollama.com, and download the Mac app. Open it. That's it.

To verify it worked, open Terminal (search for "Terminal" in Spotlight) and type:

ollama --version

You should see a version number. Now pull your first model:

ollama pull llama3.1

This downloads about 4.7 GB. Wait for it to finish, then test it:

ollama run llama3.1 "Summarize this in one sentence: The quarterly revenue report shows a 12% increase in recurring subscriptions, though hardware sales declined by 8%. The board recommends increasing marketing spend in Q3."

You should get a clean one-sentence summary back. No internet needed after the model is downloaded. No account. No API key.

Windows

Download the installer from ollama.com. Run it. Open Command Prompt or PowerShell and use the same commands as above.

Linux

One command:

curl -fsSL https://ollama.com/install.sh | sh

Don't want to write code? Start here instead

If the idea of opening a terminal and writing Python makes you want to close this tab, there are two free desktop apps that give you a full ChatGPT-like interface on top of Ollama. No coding required.

Open WebUI is a browser-based chat interface that connects to Ollama. You can upload documents and ask questions about them. It looks and feels like ChatGPT, but everything runs locally.
AnythingLLM is a desktop app with drag-and-drop document ingestion. Point it at a folder of files, and it builds a searchable knowledge base you can chat with.

Both are free and open source. They make money through optional enterprise features and hosted versions. The local desktop app costs nothing. Install Ollama first (section above), then install either of these, and you have a working local AI assistant without writing a single line of code.

If that's all you need, you can stop here. But if you want to build something more tailored to your workflow, like an email summarizer that does exactly what you want, keep reading.

Building the email summarizer

We're going to build a simple web app where you paste in an email (or a batch of emails) and get back a clean summary with action items. The app runs entirely on your computer.

Step 1: Install Python and Streamlit

If you don't have Python installed, download it from python.org. Make sure to check "Add Python to PATH" during installation on Windows.

Then open your terminal and install the libraries we need:

pip install streamlit ollama

That's it, two packages. Streamlit gives us a browser-based interface. The ollama package lets Python talk to the Ollama server running on your machine.

Step 2: Create the app

Create a new file called summarizer.py and paste this in:


st.set_page_config(page_title="Email Summarizer", page_icon="📧")
st.title("Email Summarizer")
st.caption("Paste an email below and get a summary with action items. Everything runs locally on your machine.")

# Let the user pick which model to use
model = st.selectbox("Model", ["llama3.1", "phi3", "gemma3:4b", "mistral"], index=0)

email_text = st.text_area("Paste your email here", height=300, placeholder="Dear Mr. Johnson, ...")

if st.button("Summarize", type="primary") and email_text:
    with st.spinner("Reading..."):
        response = ollama.chat(
            model=model,
            messages=[
                {
                    "role": "system",
                    "content": (
                        "You are a helpful assistant for a small business. "
                        "Summarize the following text in 2-3 sentences. "
                        "Then list any action items as bullet points. "
                        "Be concise and professional."
                    ),
                },
                {"role": "user", "content": email_text},
            ],
        )
        summary = response["message"]["content"]

    st.subheader("Summary")
    st.markdown(summary)

That's 30 lines. You can modify the prompt with your own take on what your assistant should know. Tell it to respond in bullet points, focus on deadlines, extract dollar amounts, whatever fits your workflow.

Step 3: Run it

streamlit run summarizer.py

Your browser will open to localhost:8501 with a clean interface. Paste an email, click Summarize, and watch your local AI go to work. No data leaves your machine. Close the browser tab and the terminal when you're done.

Making it handle multiple emails

Want to summarize a batch? Swap the text area for a file uploader. Here's an enhanced version that adds tabs for pasting or uploading .txt files:

Click to expand the enhanced version


st.set_page_config(page_title="Email Summarizer", page_icon="📧")
st.title("Email Summarizer")

model = st.selectbox("Model", ["llama3.1", "phi3", "gemma3:4b", "mistral"], index=0)

tab_paste, tab_upload = st.tabs(["Paste", "Upload files"])

with tab_paste:
    email_text = st.text_area("Paste your email here", height=300)
    if st.button("Summarize", type="primary", key="paste") and email_text:
        with st.spinner("Reading..."):
            response = ollama.chat(
                model=model,
                messages=[
                    {
                        "role": "system",
                        "content": (
                            "You are a helpful assistant for a small business. "
                            "Summarize the following text in 2-3 sentences. "
                            "Then list any action items as bullet points. "
                            "Be concise and professional."
                        ),
                    },
                    {"role": "user", "content": email_text},
                ],
            )
        st.subheader("Summary")
        st.markdown(response["message"]["content"])

with tab_upload:
    files = st.file_uploader(
        "Upload email files (.txt)", type=["txt"], accept_multiple_files=True
    )
    if st.button("Summarize all", type="primary", key="upload") and files:
        for f in files:
            content = f.read().decode("utf-8")
            with st.spinner(f"Summarizing {f.name}..."):
                response = ollama.chat(
                    model=model,
                    messages=[
                        {
                            "role": "system",
                            "content": (
                                "You are a helpful assistant for a small business. "
                                "Summarize the following text in 2-3 sentences. "
                                "Then list any action items as bullet points. "
                                "Be concise and professional."
                            ),
                        },
                        {"role": "user", "content": content},
                    ],
                )
            st.subheader(f.name)
            st.markdown(response["message"]["content"])
            st.divider()

What's next: chat with your data

Once you're comfortable with the email summarizer, the natural next step is building a local knowledge base. Point it at a folder of your business data (manuals, contracts, FAQs, policies) and ask questions in plain English.

This uses a technique called RAG (Retrieval-Augmented Generation), and the stack is straightforward: Ollama for the AI brain, ChromaDB for searching your files, and Streamlit for the interface. Open WebUI and AnythingLLM (mentioned earlier) both support this out of the box if you want to try it without code.

Want to figure out the steps yourself? Try chatting with DeepSeek-R1 (ollama run deepseek-r1). It's great at reasoning through technical problems and can walk you through setting up a RAG pipeline. If you want it to write the code for you, try Qwen Coder (ollama run qwen2.5-coder). It's specifically trained for code generation and can scaffold a working app from a plain-English description.

Is this going to replace ChatGPT?

No. Let's be honest about the tradeoffs.

Local models running on consumer hardware are not as smart as the frontier models from the big providers. They're smaller, they hallucinate more, and they don't have access to the internet for real-time information. If you need to analyze a complex legal contract or write a nuanced marketing strategy, a cloud service will do it better.

But that's not the point. The point is that 80% of what small businesses use AI for (summarizing, drafting, extracting key points, answering routine questions) works just fine locally. And for those tasks, you get privacy, zero ongoing cost, and no dependency on someone else's service.

If you're the technical one, there's an opportunity here

I told you at the top to skip this post if you're a developer. But if you read it anyway and you're thinking "I could set this up for every small business I know," you're not wrong.

The AI consulting market is projected to grow from $11 billion in 2026 to $91 billion by 2035. McKinsey reports that over 70% of U.S. companies plan to adopt AI automation by 2026, but most small and mid-sized firms don't have anyone in-house who can set it up. The U.S. Chamber of Commerce notes that SMB investment in AI has jumped 58% in two years, and ICSC calls 2026 "the year small businesses finally make AI work for them."

The people who can bridge that gap, who can walk a small business owner through exactly what this post covers, are going to be in demand. You don't need to be a machine learning researcher. You need to know how to install Ollama, pick the right model, and build something that solves a real problem. That's it.

My wife's been playing around with her local setup for 2 weeks now. She still switches between ChatGPT, Claude, and Gemini for different things, but she also has data locally that she chats with using Ollama. Stuff she'd rather not upload anywhere. She never did ask about that subscription again.

Start here. See what's possible. If you outgrow it, you'll know exactly what you're paying for when you upgrade.

These are my personal thoughts and experiences, and they do not reflect the views of the company I work for.

This post was originally published on nvarma.com. Follow me there for more on software architecture, engineering leadership, and the craft of building things that last.

Building Radar: A Google Sheets Hack for My Link Feed

Navin Varma — Sat, 07 Mar 2026 04:00:50 +0000

I'd just finished setting up a newsletter with Kit and tried webmentions (p.s. it was a waste of time, no backlinks showed up). I was thinking about what would actually make this site more useful for anyone who visits. I read a LOT of articles, blogs, hackernews, reddit, random LinkedIn/X/Substack posts, emerging tech news and so much more. I had this idea of a curated "what I'm reading" page. A place where I could share links and have them show up on my website automatically.

The requirement was simple: click "Share" on an article on my phone, add a quick comment, and have it show up on my site. The name "Radar" came from a list of options (Signal, Bookmarks, Feed, Picks) but "on my radar" felt right for what this is.

First attempt: social platforms

My first thought was a public WhatsApp channel. Share a link from my phone, have my site pull it in. Deflect the scale problem to a third-party. Except WhatsApp has no public API for channels. So that was a no-go.

I looked at alternatives. Telegram had a great bot API, Raindrop.io was clean but another tool to maintain. I tried a couple of social platforms that had open public APIs. No API keys, no OAuth, no rate limit tokens. Just a URL you can hit and get a user's posts back as JSON.

I built the first version of Radar using one of these (hint: Bluesky). It worked great: fetch my posts at build time, render them as a feed, done. No JavaScript on the client, no live API calls. Just a fetch during the Astro build and some HTML.

Why I moved on

Then I paused and thought about what I was actually doing. I was embedding a social platform into my personal website, not just linking to it, but making it a core data source. Whatever platform I picked, I'd be associating my site with it. And every social platform today carries baggage.

I don't want my website to signal anything political. I'm not interested in debates, I'm not picking sides. This site is about what I'm building, reading, and thinking about — not which corner of the internet I post from. It also made me realize I need to be careful about what I share on my public website, so there's that.

When I looked into it, every social platform had something: a reputation, a lean, a controversy. It's not that any of these platforms are bad. Millions of people use them and that's their choice. But I want my site to be a neutral space. So I started evaluating alternatives:

Mastodon, Telegram, Micro.blog — All had usable APIs, but still social platforms. Micro.blog was also $5/month.
Supabase — Free Postgres with a REST API. Overkill for a list of links.
GitHub repo/issues — Free and reliable, but the workflow from phone is clunky.
Notion database — Public API, but rate-limited and requires an integration token.
Raindrop.io — Beautiful bookmarking tool, but another account to manage.
Cloudflare Workers KV — Free tier, but I'd need to build a small API to write to it.

Everything was either too heavy, too dependent on a startup's goodwill, or carried associations I wanted to avoid.

The Google Sheets hack

I did some hypothesizing with my friend Claude Code, and the simplest option won. Google Forms + Google Sheets.

Google Form with two fields: url (short answer) and comment (paragraph)
Form responses automatically populate a Google Sheet
Publish the sheet to the web as CSV, which gives you a public URL that returns the sheet data as plain CSV, no API key needed
Astro fetches the CSV at build time, parses it, and renders the feed

The CSV URL looks like this:

https://docs.google.com/spreadsheets/d/e/.../pub?gid=...&single=true&output=csv

No auth tokens. No API keys. No rate limits. No startup that might pivot or shut down. It's Google Sheets — a plain, boring data store. Nobody looks at a website and infers anything about the person behind it because they used a spreadsheet. It's invisible infrastructure, like using Gmail or Google Drive. That's exactly what I wanted.

The workflow from my phone: I added a shortcut to the Google Form on my home screen. I see an article I like, tap the shortcut, paste the URL, add a quick comment, submit. On my Mac, I created a shortcut app called "My Radar" and pinned it to the dock. After I submit my link and comment, the next site rebuild that is currently 3 times a day picks it up.

For each URL, I also fetch Open Graph metadata at build time so each link shows a rich preview card with the article's actual headline and image, not just a raw URL.

The Radar page is live. Go check it out if you want to see what's on my radar. Someday I'd love to build a "Navin's List" that aggregates everything I share across LinkedIn, X, and this blog into one feed. For now, Google Forms isn't glamorous, but it's free, it's reliable, it works from my phone, and nobody's going to read subtext into a spreadsheet.

This post was originally published on nvarma.com. Follow me there for more on software architecture, engineering leadership, and the craft of building things that last.

How I Structure My Thinking in 2026: Learning New Things, Spec Driven Development for Responsible AI

Navin Varma — Sun, 01 Mar 2026 22:45:13 +0000

The cherry plum tree in my backyard, as we go into the first week of spring 2026. Every year it starts from bare branches and turns into this. It felt like a fitting image for where I am right now — new skills blooming from scratch, a lot of growth happening all at once, and the optimism about what's ahead is the fruit that comes next.

My mode of learning is a mix of reading high-level documentation, thinking of some interesting problem to solve, and just getting my hands dirty. I've always been that way. I need to break something before I understand how it works. After this point is where I seek more structured forms of learning like courses, video walkthroughs and certifications.

I started experimenting with spec-driven development in winter 2025, spending weekends learning new things. Getting hands on using my personal Claude Code Max plan when Opus 4.5 dropped made me realize how much our craft may be evolving. It was exciting to feel the builder awaken in me again. GitHub published a great piece on spec-driven development with AI that resonated with where my head was at the time. A lot has changed since then. Markdown has become the de facto way to store context between coding sessions, and things are evolving fast. If you're reading this months from now, some of what I reference may already look different, but the underlying patterns of how to structure your thinking for AI-assisted work, those I expect to hold up.

How We Learn Is Changing

All of this brought me back to something fundamental: how we learn. Structured plans, reading, video walkthroughs, trial and error. We all gravitate toward different modes. What's new is this: the key to workflow automation using agentic AI is now using the same formal learning methods. You write your thoughts down, reason about what these AI collaborators actually produce, and guide them. Dan Koe's piece on strategic thinking resonates here. Your ability to think across dimensions determines the outcome, and learning to think clearly is the actual skill being tested right now.

One workflow that clicked for me was Filip Kowalski's approach: provide a feature spec, then have Claude interview you about implementation details and tradeoffs before writing a single line of code. The thinking happens first. The code follows. This pattern is now built into the tools themselves. Claude Code has a plan mode that enforces exactly this, restricting the agent to read-only exploration and clarifying questions until you approve a plan. The difference from traditional design documents is that the spec isn't a gate. It's a conversation with an agent that actually consumes it and acts on it in real time.

Where I'm Learning This

I found spec-driven development and skills from following practitioners sharing their workflows in real time on X. These often take weeks before they appear as polished blog articles. The learning loop has outpaced the teaching loop. By the time something makes it into a structured course or certification, the next thing has already landed.

I've been using a personal Claude Code plan for a while now. Anthropic's January 2026 Complete Guide to Building Skills for Claude was a turning point in my opinion. I had started building my own skills using examples from their published repos, but that guide helped me refine them into something more structured. In late February, Thariq from the Claude Code team wrote "Seeing like an Agent" about building tools by asking what the model actually needs, not what a human would want. That shaped how I recently built my own harness. You are teaching the agent how you think about quality.

Structuring Thinking Before Structuring Code

The shift for me hasn't been in the tools alone — it has also been in how I think before I even open them. Early on I noticed something when I was experimenting with side projects: the projects where I wrote down what I was trying to build, the goals, the non-goals, the constraints, those went well. The projects where I just started prompting and iterating turned into a mess I eventually rewrote or abandoned.

I’m realizing spec-driven development isn’t about generating better code. It’s about forcing myself to think clearly about what I actually want. The spec is a thinking tool to plan your work, the code that results from clear input has better outcomes. When I write "Non-Goals: This is not a production-grade platform" for something I was experimenting with, that's not just a note for Claude. It's a constraint I'm imposing on myself.

This is also where responsible AI use starts for me. When I give an AI agent unconstrained access to my codebase and just say "build me a feature," I'm letting the agent decide what good looks like. The spec, the architecture doc, the guardrails: those are how I stay in the loop. I am still the architect. The agent is the builder. But the builder needs blueprints, and if I don't provide them, it'll improvise. Sometimes brilliantly, sometimes in ways that are hard to undo.

This applies beyond code too. I recently built a skill for reviewing blog posts before I publish them. I write my posts verbatim from my head, every word typed by me. After writing about The Builder's Guilt earlier this year, that's a vow I take seriously. But writing from your head means you're also editing from your head, and that's where things can go wrong: conflict of interest with my employer, phrasing that could be taken out of context, disclosures I should have included. Is it contradictory to write everything yourself but then have AI review it? I don't think so. It's the difference between having AI write for you and having AI watch your back. A spell checker doesn't make the writing less yours. Neither does a reviewer that catches the things you're too close to see.

I write my judgment as well as my taste into a reusable workflow once, and the agent applies it consistently every time. That layering of safety checks into everything I produce, while keeping the writing entirely human, is what feels genuinely new about working with AI.

Putting It Into Practice

Let me walk through what that looks like in practice. I've built skills for work and for side projects, but I'll use the blog post reviewer as a simple, relatable example.

The Skill Definition as Your Spec

A Claude Code skill starts with a YAML frontmatter that describes when to trigger and what it does. Here's the opening of mine:

---
name: blog-post-reviewer
description: ">"
  Comprehensive blog post review for professionals publishing on
  LinkedIn, personal blogs, or Medium. Use this skill whenever a
  user asks you to review, vet, critique, or give feedback on a
  blog post... Trigger on phrases like "review my blog post",
  "check for conflicts of interest", "is this safe to publish",
  ...
---

That description isn't just documentation. It tells Claude when to activate the skill and what to expect from the conversation. Get the triggers right, and it shows up exactly when you need it.

Below the frontmatter, the skill walks through a five-step review workflow: gather context, check for conflicts of interest, assess public perception, evaluate writing quality, and deliver the findings. Each step has specific checklists. For conflict of interest, every issue gets classified as a hard blocker (must fix before publishing), a recommended change (should fix, but the post survives without it), or an awareness item (nothing wrong in the text, but something to watch for). I wrote these classifications once based on what I'd actually worry about if I were reviewing my own work. Now the agent applies them every time, without the "it's probably fine" bias I'd have at 11pm on a Sunday.

I also baked in my professional context (employer, role, adjacency areas to watch) and sections for my writing voice, so the feedback is calibrated to how I actually write rather than generic advice.

The Compound Effect

None of these layers is revolutionary on its own. A skill definition is just a trigger. Professional context is a profile. The writing voice stuff is basically a style guide. But put together, they create something that feels different. It's not that the AI becomes smarter. It's that I've given it the right context to be effective. The agent operates within the context I would if I were reviewing my own work.

Every project teaches me something new about what to encode and what to leave flexible. If you are out there experimenting with these workflows, I'd love to hear how you are approaching it.

Where the Tools Are Converging

This pattern of encoding your thinking into structured files isn't unique to Claude Code. The major AI coding tools are converging on a similar architectural pattern — instruction files, composable workflows, and extensibility layers — though the maturity and ergonomics differ significantly:

Feature	Claude Code	Cursor	Codex CLI	Gemini CLI
Instructions file	`CLAUDE.md`	`.cursor/rules/*.mdc`	`AGENTS.md`	`GEMINI.md`
Custom workflows	Skills (`SKILL.md`)	Commands (`.cursor/commands/`)	Agent Skills (`SKILL.md`)	Agent Skills (`SKILL.md`)
Bundled distribution	Plugins	Plugins (Feb 2026)	—	Extensions
Structured thinking	Plan mode	Plan mode	Plan mode	Plan mode (experimental)

The instruction file row is the most consistent — every tool has some version of "put a markdown file in your repo and the agent reads it." Custom workflows vary more: Claude's skills are the most formalized, Cursor's commands are lighter-weight, and the Codex/Gemini abstractions are still evolving. Bundled distribution is where the models diverge most. Claude Code's plugins package skills, agents, hooks, MCP servers, and LSP servers into a single installable unit. Cursor's plugin marketplace launched in February 2026. Gemini leans on extensions. Codex CLI hasn't emphasized bundled distribution in the same way yet. The pattern is the same across tools. But the fact that they are heading in the same direction tells you where this is going. If you're investing time in learning how to structure your thinking for one of these tools, that skill transfers. The real learning is not in picking a tool. It’s in learning how to apply these concepts regardless of the tool.

The purple leaf plum tree in my backyard — cherry plum, if you want to get technical — went from bare branches to full bloom in about two weeks. That's how this feels right now — a lot of growth happening fast, and I'm just trying to write it down before the next thing lands.

These are my personal thoughts and experiences from side projects and weekend experiments, and they do not reflect the views of my employer.

This post was originally published on nvarma.com. Follow me there for more on software architecture, engineering leadership, and the craft of building things that last.

AI Almost Sold Me a Subscription I Didn't Need

Navin Varma — Mon, 23 Feb 2026 04:00:23 +0000

I lead distributed engineering teams across multiple time zones, which means my work calendar can look strange on any given day — early morning calls to sync with Europe, midday blocks for other US offices, and the occasional odd gap where I've shifted my schedule around. Outside of work, I enjoy mentoring people on engineering leadership, connecting with folks to learn from each other, career counseling, or just jamming on music. I wanted to make it easy for people to book time with me — a quick breakfast or lunch during the week, or a longer session on the weekend. One link, respects my calendar, done.

It was not trivially easy. Or rather, it was — I just didn't find the easy answer first.

The split-calendar problem

My work runs on Outlook, locked down behind corporate IT. My personal life runs on Gmail. Both calendars sync to my Android phone, so I can see everything in one view. The problem is letting other people see when I'm available without giving them access to either calendar directly. If you're on iPhone with iCloud or you already pay for Calendly, this is old news. But I got curious about why it felt so hard for everyone else, and it turns out Android sits at about 70% of the global mobile market as of January 2026.

Seven out of ten smartphone users are on Android, and the scheduling tool ecosystem largely assumes you can authenticate directly against a cloud calendar provider — the exact thing enterprise IT blocks. So this isn't just my problem.

I suspected Google Calendar could handle this natively. But instead of poking around in settings for five minutes, I did what a lot of us do now: I opened up Gemini and Claude and asked for help.

The rabbit hole

Gemini 3 Fast went deep. I'm talking five rounds of back-and-forth. It walked me through shadow calendars (where you manually duplicate every work meeting into a separate calendar — by hand), OAuth token flows, Android apps like Calendar.AI and SyncGene that bridge your phone's local calendar data to the cloud, and free-tier comparisons across multiple scheduling platforms. It even produced a table comparing sync frequency and cost. I genuinely appreciated the thoroughness, every single recommendation was technically valid.

Claude took a different path but landed in the same place. It suggested Calendly, Cal.com (open source), and SavvyCal as products I can subscribe to. When I explained that my work calendar was behind corporate SSO and I cannot use my personal computer to link calendars, it pivoted to bridging apps like Sync My Calendar and DAVx5 to push data from my Android to the cloud. It did mention Google Calendar's Booking Pages in passing, early in the conversation, but as one bullet among several rather than the obvious answer.

This was striking to me: across both conversations, every recommendation involved installing something new or creating an account somewhere. Neither tool paused to ask what I already had. They pattern-matched toward a new purchase rather than a native solution.

What I actually ended up doing

Since both calendars already synced to my phone, I checked my Android Calendar settings and made sure that data was flowing up to my Google account. One toggle I'd apparently never flipped. Once my work busy times appeared in Google Calendar alongside my personal events, I set up Booking Pages — a built-in Google Calendar feature that checks all your visible calendars for conflicts, including subscribed ones, and generates a shareable booking page.

No new apps. No subscriptions. No OAuth dance. Took me less time than either AI conversation did, which is a little ironic.

The Tech Literacy Tax

I keep coming back to what would have happened if I didn't have a strong technical understanding of how calendar technology works — the difference between local and cloud calendars, what an ICS feed is, why enterprise auth blocks third-party integrations. If this was many years ago before I gained all this experience, I would have stopped at the first confident answer from my search tool, installed one of those bridging apps, maybe signed up for Cal.com's free tier, hit the plan limit in a month, and upgraded to a paid subscription. Ten dollars a month for something one of my existing tools already does out of the box.

I think of this as a tech literacy tax: the money you end up spending on tools, apps, and subscriptions for things your existing software already handles, simply because you didn't know to look. Nobody is being dishonest here. These models learned from a web that is saturated with "10 best tools" listicles, affiliate reviews, and product marketing pages. When you ask an AI how to solve a problem, it pattern-matches toward the products that exist to solve that problem, because that's what the training data talks about. Nobody writes a listicle about the thing you already have.

These models are still learning

There's a reasonable case that this gets better over time. These models improve through reinforcement learning from human feedback — essentially, when enough people flag the inaccuracy of the output from AI. The model adjusts its weights and learns to surface native solutions first. But we're not there yet, and in the meantime, the tax is real — especially for the non-technical majority who take the first answer at face value.

It also makes me wonder about the scheduling tool market more broadly. There is a massive, legitimate need for enterprises at scale — the kind of complex, multi-stakeholder workflows that organizations deal with every day across billions of actions they take across multiple software products tightly integrated with data flows. In those environments, a robust, unified platform is the only way to manage that level of complexity. But for the basic personal use case — letting someone pick a time slot without a dozen emails — the "native" answer is often already sitting in your pocket. As core platforms continue to integrate features that once required a separate login, the niche market for standalone solutions will need to keep innovating to stay ahead of the game.

Before you install anything new or ask an AI what tool to use, it's worth spending five minutes asking a simpler question: does the thing I already have do this?

In my experience, it usually does.

If you're curious how this turned out, the "Book a Meeting" link on my Connect page is the result of this weekend rabbit hole.

This was a personal project, entirely unrelated to my day job. These are my own thoughts and opinions.

This post was originally published on nvarma.com. Follow me there for more on software architecture, engineering leadership, and the craft of building things that last.

Making Images, Music, and More with AI on a Mac Mini: One Idea, Many Uses

Navin Varma — Sat, 14 Feb 2026 09:04:41 +0000

If you’ve wondered how AI image or music generation actually works—or whether you can run it on a Mac Mini—this is a short, plain-language guide. The main idea: the same pattern applies whether you’re making an image, a track, or a clip. You pick a “model” (a large file trained to create that kind of output), describe what you want, let it run through many small steps, and get a result. I’ll outline that pattern, then walk through running ComfyUI for images on a Mac Mini.

One idea for images, music, and video

Choose a model — a big file trained on lots of data to make that type of output. Describe what you want — e.g. “a cat on a sofa” or “upbeat piano, rainy day.” Run it — the model refines things step by step (more steps = often better, but slower; on a Mini, a few minutes per image or track is normal). Use the result — image, audio, or video file. Different tools, same idea. I use ComfyUI for images and the same flow for music: pick model, describe, run, get output.

Why run it yourself?

You choose the model (no lock-in to one website). No usage caps. Your prompts and outputs can stay on your machine. The tradeoff: some setup time, and on a Mac Mini each image or clip can take a few minutes instead of seconds.

What you need

Mac Mini with Apple Silicon (M1–M4). Plan for at least 10–15GB free (app + one image model). ComfyUI Desktop for Mac only runs on Apple Silicon.

Install and first run

Download the Apple Silicon build from the ComfyUI Desktop – MacOS guide (ARM64 DMG).
Install — open the DMG and drag ComfyUI into Applications. The guide has a screenshot of this step.
First launch — open ComfyUI from Applications or Spotlight. When asked how to use your Mac’s graphics, choose MPS (correct for Apple Silicon). Pick a folder with several GB free for its files. Let it finish; it may download Python and other bits (can take a while). If something fails, the MacOS guide has troubleshooting and log locations.
You’ll see a canvas with boxes and lines (nodes). You don’t build from scratch—you load a ready-made “workflow” and type your prompt. The Getting Started with AI Image Generation guide has a screenshot of the interface.

Load a workflow and generate an image

In the app: Workflows → Browse example workflows (or the folder icon), then select the default Image Generation workflow. Use Fit View if it doesn’t fit the screen.
The workflow needs an image model. The first generation guide suggests one and shows what to do if it’s missing (often a Download button; the file can be several GB). If you add a model from elsewhere, put it in ComfyUI’s “checkpoints” folder, then select it in the “load model” node.
In the text box (e.g. “CLIP Text Encode”), type what you want—e.g. “a cat on a sofa”—and optionally what to avoid. Click Queue.
ComfyUI runs left to right. The “drawing” step takes most of the time on a Mini (one to several minutes). When it’s done, the image appears in the “save image” node; right-click to save.

Why it’s slow: The model refines a noisy starting point step by step until it matches your words. More “steps” (often 20–30) = better quality, more time. On a Mini, use smaller sizes (512×512 or 768×768) and fewer steps (15–20) while learning. One image at a time keeps things stable.

Music, video, and text: same pattern

Music: ComfyUI now supports audio generation natively with ACE-Step 1.5. Go to Workflows → Browse Templates → Audio and load the ACE-Step workflow. Type a style ("upbeat piano, rainy day") and optional lyrics, hit Queue, and get an audio file. Full songs generate in seconds on a decent GPU.

Video: Wan 2.1/2.2/2.6 models run natively in ComfyUI—go to Workflows → Browse Templates → Video for ready-made text-to-video and image-to-video workflows. Bigger files, longer runs than images, but the same "model + prompt + run = result" idea.

Text: For text generation (chatbots, writing), Ollama lets you run models like Llama, Gemma, and DeepSeek locally. Install it, run ollama run llama3.2 in Terminal, and chat. Apple Silicon's unified memory makes Mac Mini surprisingly capable here.

Once the pattern clicks, you can switch between images, music, video, and text without relearning.

Going further

For more depth and troubleshooting: ComfyUI official docs, Stable Diffusion Art – ComfyUI, and ComfyUI on GitHub.

Video tutorials — image, video, audio, and text generation:

Image generation — Sebastian Kamph's complete ComfyUI beginner's guide (install, nodes, workflows, and first image):

https://www.youtube.com/watch?v=23VkGD-4uwk

Video generation (Wan 2.6 in ComfyUI) — latest Wan video model with reference-to-video, by Sebastian Kamph:

https://www.youtube.com/watch?v=dGDIpQz_l-E

Video generation (Wan 2.2 in ComfyUI) — character animation, lip-sync, and video workflows:

https://www.youtube.com/watch?v=woCP1Q_Htwo

Audio/music generation — ComfyUI now supports ACE-Step 1.5, an open-source music model that generates full songs in seconds on consumer hardware. In ComfyUI, go to Workflows → Browse Templates → Audio → "ACE-Step 1.5 Music Generation AIO", set a style tag (e.g. "upbeat piano, rainy day") and optional lyrics, then click Queue. Same pattern: pick model, describe, run, get output.

Text generation — NetworkChuck's walkthrough on running LLMs locally with Ollama and Open WebUI:

https://www.youtube.com/watch?v=Wjrdr0NU4Sk

This post was originally published on nvarma.com. Follow me there for more on software architecture, engineering leadership, and the craft of building things that last.

Blog Syndication: Cross-Publishing Blog Posts to Dev.to, Hashnode, and Medium

Navin Varma — Wed, 11 Feb 2026 04:36:21 +0000

I recently migrated to Astro based blog that is self-hosted. Most developers have a presence on Dev.to, Hashnode, and Medium. I wanted to syndicate my posts there too and was curious about the automation that exists today in this space.

So I built a small pipeline that handles it automatically. Push a new post to my Astro site, and GitHub Actions cross-publishes it to Dev.to and Hashnode with the canonical URL pointing back to my site. Medium is a different story, which I'll get to.

Why canonical URLs matter

Before getting into the code, this is the one thing you should care about if you cross-publish anything. Every platform lets you set a canonical URL — canonical_url on Dev.to, originalArticleURL on Hashnode. It's basically a pointer that says "the original lives on my site." If you don't set it, Google sees three copies and will probably rank the platform version higher than yours.

Set the canonical URL. Every time. No exceptions.

Dev.to has a straightforward REST API

Dev.to is the simplest one. You generate an API key at dev.to/settings/extensions, and then it's just a POST request:

const payload = {
  article: {
    title,
    body_markdown: body,
    published: true,
    tags: tags.slice(0, 4).map(t => t.toLowerCase().replace(/[^a-z0-9]/g, '')),
    canonical_url: canonicalUrl,
  },
};

const res = await fetch('https://dev.to/api/articles', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'api-key': process.env.DEVTO_API_KEY,
  },
  body: JSON.stringify(payload),
});

With Dev.to, you need make sure your posts are limited to 4 tags, all lowercase, no special characters. You should also ensure you don't hit their rate limit with too many requests (HTTP 429). The response payload has the article ID and URL. I store this in a tracking file so I don't publish the same post twice.

Hashnode uses GraphQL

Hashnode's API is GraphQL-based. You need a Personal Access Token from hashnode.com/settings/developer and your publication ID. If you know your blog URL, you can get the publication ID without even logging in:

curl -s -X POST https://gql.hashnode.com \
  -H "Content-Type: application/json" \
  -d '{"query":"{ publication(host:\"yourblog.hashnode.dev\") { id title } }"}'

The publish mutation looks like this:

const mutation = `
  mutation PublishPost($input: PublishPostInput!) {
    publishPost(input: $input) {
      post { id url }
    }
  }
`;

const variables = {
  input: {
    title,
    contentMarkdown: body,
    publicationId,
    tags: tags.map(t => ({
      name: t,
      slug: t.toLowerCase().replace(/[^a-z0-9]+/g, '-'),
    })),
    originalArticleURL: canonicalUrl,
    slug,
  },
};

Hashnode tags are objects with both a name and a slug, which is a little more involved than Dev.to's plain strings. The originalArticleURL field is their version of the canonical URL.

Medium dropped support for API tokens

You can't programmatically publish to Medium anymore. At least not through any official channel.

But you can still get your posts on Medium manually with the canonical URL intact. Medium has an "Import a story" feature that does exactly this:

Go to medium.com/me/stories.
Click the Import a story button.
Paste your post's URL (e.g. https://www.nvarma.com/blog/your-post-slug/).
Medium will import the content and automatically set the canonical URL to point back to your blog post.

That last part is the important bit. Medium links to the original URL when you use the import tool, so search engines still know where the post originated. While this manual part sucks, I'm glad they still have a way to do this less painfully.

For older posts you want to bring over, same process. Just import each one by URL. Medium will pull the content, preserve your formatting reasonably well, and set the canonical link. You might need to clean up some formatting afterward, so proof read them before publishing.

Sanitizing MDX for other platforms

Some of my posts use custom image components and are written in MDX. MDX generated content does not work on Dev.to or Hashnode.

I wrote a sanitizer that transforms the content into portable markdown:

// Strip MDX imports
content = content.replace(/^import\s+.*$/gm, '');

// Convert <figure>/<img>/<figcaption> to markdown
content = content.replace(
  /<figure[^>]*>\s*<img\s+src="([^"]+)"\s+alt="([^"]*)"[^>]*\/?>\s*(?:<figcaption>([\s\S]*?)<\/figcaption>)?\s*<\/figure>/g,
  (_match, src, alt, caption) => {
    let result = `![${alt}](https://www.nvarma.com/${resolveUrl(src)})`;
    if (caption) result += `\n*${caption.trim()}*`;
    return result;
  }
);

// Replace Astro components with "see original" links
content = content.replace(
  /<([A-Z][A-Za-z]+)[^>]*\/?>/g,
  (_match, componentName) => {
    return `*[Interactive ${componentName} — see original post](https://www.nvarma.com/${canonicalUrl})*`;
  }
);

// Resolve relative paths to absolute URLs
content = content.replace(
  /!\[([^\]]*)\]\((?!https?:\/\/)([^)]+)\)/g,
  (_match, alt, src) => `![${alt}](https://www.nvarma.com/${SITE_URL}${src})`
);

The Astro component replacement is my favorite part. If I have a *[Interactive BeforeAfterCarousel — see original post](https://www.nvarma.com/blog/2026-02-10-cross-publishing-blog-posts-devto-hashnode-medium/)* in my Astro rebuild post, the cross-published version gets a link that says "Interactive BeforeAfterCarousel - see original post" instead of broken HTML. Not perfect, but it's honest and sends people to the real thing.

I also prepend each post with a "Originally published on nvarma.com" header and append a footer with a link back. A little self-promotional, but that's kind of the whole point of cross-publishing.

Automating it with GitHub Actions

The workflow triggers whenever I push changes to src/content/blog/** on main:

name: Cross-Publish Blog Posts

on:
  push:
    branches: [main]
    paths:
      - 'src/content/blog/**'
  workflow_dispatch:
    inputs:
      post_id:
        description: 'Specific post ID to publish (filename without extension)'
        required: false

The workflow_dispatch trigger lets me manually publish a specific post if I need to. The script reads all blog posts and then checks a tracking JSON file to see what's already been published. After that, it only processes new posts. It also skips posts older than 30 days to avoid flooding those syndication sites with old content.

The tracking file gets committed back to the repo automatically, so there's a record of what went where:

{
  "2026-02-09-manager-ic-pendulum": {
    "title": "The Manager-IC Pendulum...",
    "firstPublishedAt": "2026-02-10T03:33:00Z",
    "platforms": {
      "devto": {
        "id": "3245645",
        "url": "https://dev.to/navinvarma/the-manager-ic-pendulum...",
        "publishedAt": "2026-02-10T03:33:00Z"
      },
      "hashnode": {
        "id": "abc123",
        "url": "https://navinvarma.hashnode.dev/the-manager-ic-pendulum...",
        "publishedAt": "2026-02-10T04:00:00Z"
      }
    }
  }
}

Setting it up yourself

Dev.to: Generate an API key at Settings > Extensions. Store it as DEVTO_API_KEY in your repo's GitHub Actions secrets.

Hashnode: Get a Personal Access Token from Settings > Developer. Look up your publication ID with the curl command from above. Store them as HASHNODE_PAT and HASHNODE_PUBLICATION_ID respectively.

Medium: Import stories manually using Medium's import tool. Paste the canonical URL and Medium imports the content of your post.

GitHub Actions secrets: Go to your repo Settings > Secrets and variables > Actions, and add each one. The workflow only runs when blog content changes, so it won't burn through your Actions minutes.

If you already have posts on a platform (like I did with Dev.to), make sure the tracking JSON has those entries before your first run. Be careful here as the script will try to publish duplicates and APIs will likely reject them or create duplicates.

Reflections

Setting this up took an evening. Not too much work, but you need to know your way around how Astro builds work and some general GitHub Actions, API & Integrations knowledge.

The nice part is that I now have a single workflow: write in markdown, push to git, and my post shows up on three platforms with proper canonical URLs. Medium requires a manual import but at least the process is simple and the canonical URL is preserved.

I'll probably add more platforms later if they have decent APIs. This was a fun weekend project to automate away some of my toil, hoping you might find this useful.

This post was originally published on nvarma.com. Follow me there for more on software architecture, engineering leadership, and the craft of building things that last.

The Manager–IC Pendulum and the Rise of the “Builder with Taste”

Navin Varma — Tue, 10 Feb 2026 03:33:00 +0000

*These are my personal thoughts, experiences, and opinions, and they do not reflect the views of the company I work for.*

I've been reflecting a lot lately about the pendulum swing between Engineering Manager and Individual Contributor. For those who have not read it, I would suggest reading Charity Majors' multiple posts about this topic and coming back here. It's an emotional space I've been in for the last five years as a hands-on manager, but the last twelve months have completely changed the physics of that swing.

The Builder's Guilt: AI saturation makes me sad

Navin Varma — Sat, 31 Jan 2026 21:00:00 +0000

One of my plans in 2026 is to generate more original content.

In the age of AI saturation, original content is something that takes you back in time - nostalgic, almost. It's like, you know when you're a kid growing up and you have TV, radio and so many other forms of entertainment, but you still write your daily journal at night or listen to your favorite songs on your cassette tapes. I did for a while, until I moved on to something else that made me happy. The memories of that daily journal habit are still very fresh in my memories, sitting down with a diary and writing what was on my mind to this unknown person. The frustrations, the joy, the doubt and the dreams of better days ahead.

Adding Social Share Buttons to Your Astro Blog

Navin Varma — Mon, 26 Jan 2026 09:00:00 +0000

I tried to share one of my posts on X after my website rewrite this week and... my face showed up as the preview image. Not the article, not a nice graphic - just my profile photo staring back at everyone. Embarrassing, honestly. And then I noticed there's no way for anyone reading my new blog to share it without copying the URL like it's early days of the internet.

Both of these bugged me enough that I spent a Sunday night fixing them.