It also made me confront a slightly uncomfortable truth: I have spent nearly two decades arranging an unreasonable number of mornings, afternoons and late nights around one man's ability to hit a fuzzy yellow ball. There are probably worse ways to spend your time. I am conveniently choosing not to investigate.

Becoming a Rafa fan

I started following Rafa in 2007. Federer was already the definition of effortless brilliance, which made Rafa feel like the complete opposite. Every point looked like it required every ounce of him. The sprinting, the sliding, the lasso forehand and, of course, the vamos after a ridiculous point.

There was something magnetic about watching someone compete as if every point mattered equally. Rafa could be playing a Grand Slam final or be up two sets in an early round, and he still carried himself like the next point was the only one that existed.

As someone whose own tennis game has always contained considerably more enthusiasm than technique, this was deeply inspiring. Unfortunately, inspiration does not add topspin to a forehand. Perhaps the same can be said of my bowling prowess, but I digress.

The ritual of watching

Following an athlete for this long creates its own rhythm. There were the clay seasons where losing felt almost impossible, the injuries that made every comeback feel uncertain, and the matches where he somehow found another gear after looking completely spent.

Watching Rafa was rarely relaxing. Even when he was comfortably ahead, I maintained the emotional composure of someone diffusing a bomb. But that tension was part of the appeal. You never felt like he took the outcome for granted, so neither did you. Over time, the matches became markers for different periods of my own life. I can remember where I was for many of the big wins and some of the more painful losses. Jobs changed, cities changed and responsibilities grew, but for a couple of weeks every year, there was Rafa at Roland Garros.

Growing older together

The documentary does a wonderful job of revisiting the trophies and rivalries, but the part that stayed with me was seeing the passage of time. The younger Rafa seemed indestructible. Later, every tournament carried a quiet question about how much longer his body would allow him to keep going.

There is a strange comfort in following a sporting career for so long. At first, you watch your hero grow into their prime. Then one day, without really noticing when it happened, you are both older and discussing knee pain with far more authority than either of you would prefer.

His career became less about whether he would win everything and more about appreciating that he was still there. Each comeback felt like a small refusal to let the story end before he was ready.

What made Rafa different

The obvious answer is the relentlessness. Nobody made suffering through a five-set match look quite as purposeful. But what I admired most was that the intensity never seemed to turn into entitlement.

He celebrated wins, accepted losses and returned to the work. That sounds simple, but it is incredibly difficult to do consistently, especially when the entire world expects greatness from you. For all the trophies and impossible shots, that might be the most enduring part of watching Rafa: effort was never beneath him. He made trying incredibly hard look like its own form of talent.

One last vamos

Watching the documentary felt less like revisiting a collection of tennis matches and more like going through a cherished flipbook. The matches were Rafa's, but the memories attached to them were mine.

I will miss the nervous energy of watching him compete. I will miss believing that no match was truly over while he was still on court. And I will miss yelling vamos maniacally at my tv screen, an activity that contributed absolutely nothing to the outcome but felt essential nonetheless.

Gracias, Rafa. What a privilege it was to watch.

That was useful, but it was also immediately obvious that I was walking into a crowded room. GitHub has push protection. Mature tools like Gitleaks, TruffleHog, GitGuardian, and detect-secrets already exist. There are also a growing number of small uvx-friendly scanners that do roughly the same thing.

So the question became less “can I build a secret scanner?” and more “what is the specific leak surface that feels newly weird because of how I actually build now?”

The answer, for me, is AI-agent config.

The local repo is getting stranger

AI-assisted development has changed what ends up near the codebase. It is not just app source files anymore. A working project can now include MCP configs, editor agent settings, generated scripts, copied setup snippets, auth headers from docs, notebook outputs, deployment glue, and half-finished local integrations.

Claude Code, for example, supports project-scoped MCP servers through .mcp.json, while Claude Desktop has its own claude_desktop_config.json path and behavior. The Claude Code MCP docs explicitly describe project-scoped server configuration, and the Desktop docs call out that Desktop and Claude Code MCP configs are separate.

That separation is powerful, but it also means there are more places for a tired developer to paste something sensitive.

The new helpfulGremlin direction

I do not want helpfulGremlin to become a sprawling security platform. That feels like the wrong game.

The better version is narrower:

Catch the dumb, expensive mistakes before they leave my laptop.

So the next iteration is defaulting toward agent-aware local scanning. It still looks for the usual API keys, private keys, database URLs, and high-entropy strings, but it now also pays special attention to files like:

• .mcp.json
• mcp.json
• .claude/settings.json
• .cursor/mcp.json
• claude_desktop_config.json
• .env, .env.local, .env.*
• .npmrc, .pypirc, .netrc
• cloud credential JSON files

For JSON-based agent configs, helpfulGremlin tries to parse the file and inspect values under fields like mcpServers, env, headers, args, command, and url. If it sees a literal token where an environment variable reference should be, it reports that as an agent-config finding.

It also warns when sensitive local config files are present at all. That is intentional. A .env.local file full of placeholders is not the same as a leaked production token, but it is still worth pausing on before a push.

Why this feels more useful than “more regexes”

The generic secret-scanner market rewards breadth. More providers, more token formats, more validation, more integrations.

That is not where this project is likely to be interesting.

The interesting part is context: a tiny local tool that understands the shapes created by AI-assisted development and gives a developer one more moment to notice something before it becomes permanent.

In the original post, I wrote about building helpfulGremlin quickly with agentic tools. This follow-up is the more honest second step: after shipping the obvious MVP, the useful product shape became clearer.

Not a better Gitleaks.

A small guardrail for the messier local workflows that AI tools are creating.

All these trips mean driving around the bay area for her, which means we need a mechanism to track those miles for reimbursement. Enter trusty old Google Sheets - a couple of simple macros later, a simple sheet was up and we were on our way. Initially, this worked fine. But as the number of days entered in the sheet grew, the unwieldy nature of Google Sheets on mobile really came to the fore. Perhaps a separate sidebar for a different day on my feelings on that topic (I know Sheets can be so much better on mobile, but it's not at the moment).

The AHA moment

In parallel, the other tracking challenge was to ensure we could accurately account for time off based on hours outside of regularly scheduled vacation days for our Nanny. This is so that we could do accurate accounting and bookkeeping with the payroll service. Now trying to update information on this payroll website (HomePay) feels akin to swimming in quicksand. So once again, trusty old Google sheets came to the rescue initially, and once again very soon ran into similar usage limitations.

Stand aside Google Sheets

I thought I could probably build something quick, responsive, which eliminates the friction for data entry and makes the key tracking insights dead simple and prominently visible. And for sheer cheek, I asked Gemini to use Google themed branding for general look/feel.

Key details that made this work for us:

• Globally configured mileage reimbursement rate, number of holidays, number of sick days
• Adding the agreed upon vacation days to see a holistic calendar view
• Logic to handle round trips and reconciliation for paid v/s unpaid miles

Overall results have worked out pretty well and my wife, the nanny and I are finding very good use out of this. I mean what else would I do when I have an un-used domain lying around.

All code and tech stack breakdown on

There's also another personal angle, my wife is fluent in ASL and as a multi-lingual household, we want to champion the languages (English, Hindi, ASL) for our son as he grows up as well. This is where the genesis of my problem starts.

How can I build an ASL learning mechanism that's sticky enough for me to keep up with the learning curve without it feeling like a chore?

A solution to this problem should:

• Give clear feedback
• Actually tell me how the sign works
• Be intuitive to use
• Ideally free (after some spirited fight, I relented on this)

In my head, I thought if I can build a simple app that can help me practice a sign and tell me how well am I signing it. Not just score me, but give some other kind of feedback as well in terms of how I'm moving my hands when I'm signing (ASL is heavily dependent on body language for grammar, but that's a more complex and nuanced problem to solve).

Enter ASL Educator - My personal learning assistant to help me navigate the nuances of ASL.

Evolution of ASL Educator

The idea was simple. I turn on my webcam, sign a word and get immediate feedback.

I was thinking with the power of , I could knock this out in a weekend... oh how wrong was I. Nailing down the production deployment was a pro level game of whac-a-mole! A lot of it was self-inflicted as I was earlier trying to do this all of $0 using Render's free tier.

How I thought the dev process would largely be?

graph TD
    A[Idea] --> B[Local ML Pipeline]
    B --> C[Deploy App]
    C --> D[Productionize]

How the dev process actually went?

flowchart TD
    Start((Start)) --> ML[Local ML Pipeline]
    
    subgraph "Phase 1: ML Pipeline"
        ML --> ML_Ch1[Dealing with large tensors & OOM]
        ML --> ML_Ch2[Debugging Similarity Math]
        ML_Ch1 & ML_Ch2 --> ML_Done{Accurate?}
        ML_Done -->|No| ML
    end

    ML_Done -->|Yes| Frontend[Frontend & Web App]

    subgraph "Phase 2: Frontend Debugging"
        Frontend --> FE_Ch1[Camera Access & Stream]
        Frontend --> FE_Ch2[Real-time Video Latency]
        Frontend --> FE_Ch3[Syncing ML state to UI]
        FE_Ch1 & FE_Ch2 & FE_Ch3 --> FE_Done{Responsive?}
        FE_Done -->|No| Frontend
    end

    FE_Done -->|Yes| Prod[Deploying to Prod]

    subgraph "Phase 3: Production & Infra"
        Prod --> Prod_Ch1[Git LFS overages & Build sizes]
        Prod --> Prod_Ch2[Serverless constraints for ML]
        Prod --> Prod_Ch3[Need for persistent state]
        
        Prod_Ch1 --> Sol1[Cloudflare R2 for Assets]
        Prod_Ch2 --> Sol2[Render for ML Services]
        Prod_Ch3 --> Sol3[Supabase for Postgres DB]
        
        Sol1 & Sol2 & Sol3 --> Prod_Done{Stable?}
        Prod_Done -->|No| Prod
    end
    
    Prod_Done -->|Yes| Success(((Success!)))

I ended up spending more time than I would have liked on ensuring that the ML service and the backend gateway can wake up in time as a user goes onto the app and tries to practice. The cold start for the app kept winning this battle.

The things that didn't work for combating the free tier deployment:

• Adding a Github Action to send a ping to Render for the two services I had
• Increasing timeout for ML Service loadup
• Showing a waiting UI interstitial while the services woke up in the background
• Lazy Loading ML Data from Cloudflare R2
• Slimming down docker image

Parting Thoughts

Ultimately, I had to bite the bullet and upgrade from the free tier to keep the ML inference snappy. The small monthly cost is absolutely worth it to avoid losing my momentum while staring at a loading spinner.

So, did I solve my original problem? Yes and no. The app is a solid start for nailing down the accuracy of individual signs, and I'm definitely keeping pace with my toddler's growing vocabulary (we're moving way past just "more" and "food" now!).

But the journey doesn't stop here. To make this truly persistent long-term and habit forming, the next phase is moving from single-word recognition to full sentence-level processing. Oh, and adding some gamification—because nothing motivates quite like a 30-day streak! (gotta come up with an ASL-themed Duolingo pun). I should be getting some feedback from my relatives who happen to be in deaf education as well, so the MAU trend can climb a little bit as well (I'm all about those metrics).

Until then, I've got some signs to practice.

All code and tech stack breakdown on

I've been using Claude Code and Gemini App heavily at work and its been truly incredible to have such capable agents at my disposal. I would be remiss if I didn't shout out to the open-source community for some amazing plugins and the patterns they champion:

• Persona-driven friction: Heavily inspired by Garry Tan’s gstack. AI agents shouldn’t just be blind coders. They should emulate senior technical roles that actively push back.
• File-based memory: Inspired by get-shit-done. Architectural context and phase logic must be explicitly tracked in rigid Markdown files (PRD and STATE) to serve as the ultimate source of truth.

These patterns have been immensely helpful as I've been building PoC to production-ready apps, but I felt there was a gap within the Gemini ecosystem.

That's why I built PM-Engine. I wanted to bring the same friction and discipline I value in real-world product teams to my AI workflow.

Focusing on the why

Instead of just telling the AI to "build X," PM-Engine forces you through a structured discovery phase. Take a look at this /discover session for a quick macro tracking app I was playing with:

The Lead PM persona doesn't write a single line of code. Instead, it hits you with "brutal" questions: Who is this for? What is the one quantifiable pain point? What are we NOT building?

This friction is a feature, not a bug. By the time you get through these questions, you have a PRD.md that actually means something. It's the difference between a project that drifts into a mess of hallucinations and one that has a clear finish line.

The Dual-Brain System

The core of PM-Engine is simple: separate the Intent from the Execution.

• The Product Engine (PRD.md): The persistent memory of what we are building. It’s the boundary against scope creep.
• The Execution Engine (STATE.md): A rigid state tracker that preserves context over long sessions.

When you run /plan, a Staff Engineer takes the PRD and breaks it into a checklist. When you /execute, the agent is locked into only the active phase. It's physically unable to hallucinate future features because it doesn't "see" them yet.

Moving with Intention

Ultimately, I just wanted to build a framework that can be broadly consumed by anyone using Gemini-cli. I've been using it for everything from scaffolding fast Astro sites to heavier backend work with inference layers, etc. (more on that coming soon), and it's been the first time working with an agent where I felt in control of the architectural drift.

Available on and now. GitHub repo with all the details on how to get started:

This might be the most PM thing of all time I've done. Giving my AI its own bespoke PM.

Diamonds are forever, but so is radar - Udit, 2019

Very early on while working at Apple, it became evident to me that the company runs on Radar - quite figuratively and literally! If an issue wasn't a Radar, it wasn't going to be actioned on. I myself championed that ethos with quite a bit of vigor the more time I spent at .

Radar is everywhere

Radar is Apple's internal bug tracking system. Built by Apple, for Apple. I won't go into details around what it did, but it was the single source of truth for everything that needed to be done. What made it so incredibly effective wasn't necessarily its UI—it was the uncompromising enforcement of its use. Everyone used it - whether you were an engineer, manager, or a designer. There was no escaping it. Furthermore there was some very good role modeling from the senior leaders within the company, so A+ on that.

Enter Linear

When I left Apple in the summer of last year, I was naturally curious as to what the new normal was for task tracking at my new job. I had heard good things about Linear and been a fan of the work Karri had done at Airbnb and Coinbase. So naturally I was itching to try Linear and see if it was as good as advertised.

What Linear does better

• Triage Intelligence: This is pure magic. It automatically categorizes, routes, and groups issues, saving me and engineers hours of manual sorting.
• Asks: Managing the chaotic influx of Slack requests has always been a nightmare. Linear's "Asks" feature seamlessly bridges ad-hoc communication with structured issue tracking.
• Granularity per Team: Radar forced a monolithic structure. Linear allows incredible granularity with custom settings per team, allowing different pods to vibe safely with their own workflows while remaining connected to the broader org.
• Seamless Integrations: It plugs into everything we use effortlessly, acting as a modern hub rather than an isolated silo. So from repos on Github, to Slack Channels, Figma, etc. you name it - and it's highly likely that the integration exists.

Despite the aesthetic and experience differences, both tools succeed for the same fundamental reason: they are the absolute source of truth. Both require strong cultural buy-in. An empty Linear workspace is just as useless as a neglected Radar queue (I've been at the receiving end, so I know the pain).

Room for Improvement

As much as I love Linear, it isn't perfect, especially when handling massive organizational oversight:

• Roadmaps and Initiatives: Building long-term roadmaps in Linear still feels like it's lacking the robustness needed for massive, multi-year, cross-functional bets.
• The Transparency Trade-off: Initiatives in Linear are inherently public across the workspace. While this default-to-transparency is generally fantastic for startups, it can be tricky for organizations that require siloed visibility or strict need-to-know access control—something Radar handled implicitly due to Apple's internal operating model.

TLDR

Linear is a fantastic, well-designed and intentional product that should be a must for all product teams looking to move with intention.

In my constant zest to explore everything the world of Food & Beverage has to offer, I've been lucky enough to dine at a few restaurants and I feel like these small sojourns into high-end gastronomy always leave a profound impact.

My wife and I recently had an amazing dinner at Birdsong SF. The whole evening was pretty incredible, but this one abalone dish left me speechless. We usually do one vegetarian and one regular tasting and I think we both came out on the upside with our selections and the reserve wine pairing. It was super fascinating to watch the orchestra of that immaculate kitchen play out in front of our eyes. We even had a quick discussion with Chef Bleidorn about the correct ratio of peanut butter to jelly in any good PB&J sandwich!!

I think it was the sheer technique and skill of cookery of the abalone, which was beautifully accentuated by that warm salty broth, that did it for me. In that moment it made me realize why I was having such a visceral reaction to a bite of food - its' the ability to evoke such emotions, transport you back to a moment in time, make you feel something you haven't felt in a long time, that's the magic of food. Being able to share that with someone you love and care about deeply, just elevates it even more.

There's definitely a few standout dishes and some incredible regulars, that immediately transport back to the moment. In no particular order:

• Gnochhi at Fig
• Ridged pasta at Acquerello
• Everthing Bagels at Saratoga Bagels
• Slice of the original at Scarr's Pizza
• BBQ at Micklethwait Craft Meats — Hard to pick one thing lol

With the recent storeis about ClawdBot MoltBot, a very clear pattern has emerged - moving so fast comes with some apparent risks where tokens and credentials are left out in the wild. And that got the wheels churing in my head..

Problem Definition

• A clear and intuitive way to get confidence that the code being pushed to a repository won’t leak anything that shouldn’t be out in the world. Think API keys, tokens, etc.

Key Requirements

• Should work with uv
• Ease of use in terms of instantiating the tool
• Provide helpful descriptions for identitified issues
• Distribute this package via pypi so it can be used by anybody. helpfulGremlin available now!

Solution

Using Antigravity + Gemini 3 has truly been really impactful for my personal workflows. After a few targeted prompts, I had a MVP up and running in no time.

I would be remiss if I dind’t shout out to Claude, which I use very religiously at work. It’s fun to evaluate different agentic solutions to see how they’re both unique.

• main.py — (The Conductor): The CLI entry point built with Typer and Rich. It orchestrates the entire process—spinning up a process pool to scan files in parallel, displaying a real-time progress bar, and rendering the final report table with remediation advice.

• scanner.py — (The Navigator): Responsible for efficiently traversing the file system. It handles the gritty work of parsing

• detector.py —(The Brain): The core detection engine. It loads regex signatures (specified in the patterns.yaml file) and implements a Shannon entropy algorithm to flag high-randomness strings (like generic passwords) that don’t match known patterns.

Details of the package on Github README

Having gone through this rite of passage of

Blogger --> Wordpress --> CSS/HTML hosted static site(s) --> Hugo on Firebase --> ... this?

Why have your own website in the first place? What’s the intrinsic value here?

I’m a big believer in an evidence of impact style of doing things. Having an outlet to comprehensively document, and reflect back like one would with a compendium, is something pretty neat.

And then there’s the tighter control over the content, layout and overall end result when I am managing the entire end-to-end deployment. There’s something about the utility of tinkering which has always been a big draw. Not to say this is anything too drastic (simple Astro template with minor changes and hosted on Vercel)

What are you going to write about?

Mostly about things I’m experiementing with on my machine, learning recently or general observations over time. No specific theme per say.