this blog post was created for the purposes of entering the google ai hackathon. the project is open source and lives here: github.com/prayush21/spogo-on-the-run #GeminiLiveAgentChallenge

tldr

• inspiration: guessing songs mid-run kept me going longer

• what it is: a voice-first ai running companion that plays spotify and runs music quizzes hands-free

• built with: google adk, gemini live api, vertex ai, google cloud run, spogo cli

• the cool part: real bidirectional voice streaming via gemini native audio models, with smart intent handling for guesses vs. just enjoying the music

• deployed: google cloud run with secret manager + vertex ai live api in production

if you’re a runner and a music nerd, this one’s for you. give it a spin.

source code: github.com/prayush21/spogo-on-the-run
deployed agent: spogo-song-agent-954196838557.us-central1.run.app
youtube demo:

the problem with running

i love running outdoors. genuinely. but there’s this thing that happens around the 2-mile mark — my brain locks in on the exhaustion. the legs feel heavy, the breathing gets loud, and suddenly stopping feels like the only reasonable option.

one day i was running with spotify going, and i started playing a little mental game with myself: can i name this song from just the first few seconds of the intro? that tiny spark of curiosity was enough. my attention shifted from tired legs to the music. i ran further than usual, felt weirdly good, and actually had fun.

that moment became the seed for spogorun — a voice-first ai agent that turns every run into a real-time music quiz. no screen, no buttons, just your voice and your music.

what spogorun does

once you start your run and launch the agent, you talk to it like you’d talk to a person. you can ask it to play a song, guess what’s currently playing, or kick off a full 5-round song quiz based on a genre, artist, mood, or whatever you’re feeling.

a typical session might look like:

• you: “start a quiz for 90s bollywood romance”

• agent: “starting a quiz for ‘90s bollywood romance’. round 1 of 5 is now playing. you have 2 attempts to guess this song.”

• song plays for a few seconds

• you: “is it tujhe dekha toh?”

• agent: “wrong guess. one attempt left.”

• you: “pehla nasha?”

• agent: “right guess! moving to the next song.”

no tapping. no looking at your phone. just the game.

how it was built

step 1: proving the idea with spogo

before writing a single line of adk code, i needed to validate that the core loop — play a specific song via cli, check what’s playing, compare guesses — was even technically possible.

i built a quick prototype using spogo, an open-source cli tool that lets you control your spotify account from the terminal. it wraps spotify’s api in a clean set of commands like spogo play "song name", spogo status, and spogo queue. once i had basic playback control working end-to-end, it was time to give it an agentic brain.

step 2: the adk agent backbone

the core of the project is a google adk agent powered by gemini live api. if you haven’t used adk before, here’s the short version: it’s google’s production-ready framework for building ai agents that can use tools, manage conversation state, and run in real time. it handles all the heavy infrastructure — session management, tool orchestration, event coordination — so you can focus on building the actual product experience.

the key insight from the adk docs (part 1) is how the framework separates concerns cleanly:

• you define the agent (model, tools, instructions)

• adk provides the LiveRequestQueue, Runner, and run_live() streaming loop

• gemini live api provides the real-time voice intelligence

the whole architecture is built on bidirectional streaming — meaning the agent and the user can communicate simultaneously, not in a rigid back-and-forth. this is what makes the quiz feel natural. the agent can speak and listen at the same time, just like a real conversation.

here’s a simplified look at what the agent definition looks like:

from google.adk.agents import Agent

root_agent = Agent(
    name="spogo_song_agent",
    model=os.getenv("AGENT_MODEL", "gemini-2.5-flash-native-audio-preview-12-2025"),
    tools=[play_song, generate_song_list, start_song_quiz, submit_song_quiz_guess, ...],
    instruction="you are a voice-first music quiz agent running on spotify..."
)

the agent is stateless — it’s created once and shared across all sessions. state lives in the Session object that adk manages per user.

step 3: wrapping spogo as adk tools

the next challenge was turning spogo’s cli commands into tools that the agent could call reliably during a live voice session. each tool is a python function the agent can invoke:

• play_song(song_name, album_name="") — searches top 5 tracks, picks the best match using weighted similarity, queues it, and plays it immediately

• generate_song_list(user_request, count=5) — uses gemini to generate a structured list of songs (name, year, album) from a natural language prompt like “5 happy hindi songs”

• check_current_song_guess(song_guess) — reads current playback status and compares the guess against the playing track with a similarity score

• start_song_quiz(user_request, count=5) — builds a 5-song quiz playlist, queues the tracks, and starts the game loop

• submit_song_quiz_guess(song_guess) — handles the per-round guess logic (2 attempts max, auto-advance, scoring)

the tricky part here was state. a quiz spans multiple rounds, multiple songs, and multiple tool calls. adk’s session state (via tool_context) made this manageable — quiz progress gets stored and retrieved across the entire game without any manual bookkeeping.

step 4: voice mode with gemini live api

for the voice experience to feel right, the model needed to understand speech in real time and respond with natural audio — not text-to-speech on top of a text response. that’s where gemini live api’s native audio models came in.

during development, the model was set to gemini-2.5-flash-native-audio-preview-12-2025 (for local testing via google ai studio). for production, it swaps to gemini-live-2.5-flash-native-audio running on vertex ai — all without any code change, just a single environment variable flip:

# development
GOOGLE_GENAI_USE_VERTEXAI=FALSE
GOOGLE_API_KEY=your_key

# production (google cloud)
GOOGLE_GENAI_USE_VERTEXAI=TRUE
GOOGLE_CLOUD_PROJECT=your_project_id
GOOGLE_CLOUD_LOCATION=us-central1

the adk streaming architecture makes this seamless. your application code is identical in both environments — the LiveRequestQueue sends messages upstream to the agent, and the run_live() event loop streams events back downstream. whether that’s going through google ai studio or vertex ai is abstracted away entirely.

step 5: the nuance that made it feel smart

one of the proudest moments in the build was getting the agent to handle a subtle but important distinction: is the user guessing the song, or are they humming/singing along?

if you say “i think this is kesariya”, that’s a guess — route it to submit_song_quiz_guess. if you hum a few bars or say “ooh i know this one, la la la”, that’s not a guess yet.

this kind of intent disambiguation is exactly where gemini shines. the model instruction was carefully written to recognize this nuance, and it made the ux feel genuinely smooth during testing. neither siri, standalone llms, nor spotify itself offers this kind of integrated, preference-aware, screen-free experience.

deploying on google cloud run

once everything was tested locally, the whole thing was deployed to google cloud run using adk’s built-in deployment command:

adk deploy cloud_run \
   --project="$GOOGLE_CLOUD_PROJECT" \
   --region="$GOOGLE_CLOUD_LOCATION" \
   --with_ui \
   spogo_song_agent

for production, a few more pieces were wired up:

• secret manager for storing the google api key and spotify auth credentials securely — never baked into the container

• iam bindings so the cloud run runtime service account could access secrets and call vertex ai models

• spogo runtime bootstrap — since the cloud run container doesn’t come with spogo pre-installed, a startup script auto-installs it and initializes auth from the SPOGO_AUTH_BLOB secret

the live url is running at spogo-song-agent-954196838557.us-central1.run.app.

the challenges (the real ones)

getting up to speed with adk’s architecture

the first real hurdle was understanding how all the adk components fit together — Agent, Runner, LiveRequestQueue, RunConfig, sessions. the 5-part adk streaming guide was genuinely helpful here. the mental model that clicked for me: upstream tasks send messages into the queue, downstream tasks pull events out of run_live(), and those two run concurrently via asyncio.gather(). once that picture was clear, everything else followed.

oh, i heavily utilized NotebookLM for gathering better understanding and increasing interesting into the docs and the overall architecture.

here is the link to the notebook i created for this. checkout the audio and video summaries if you want a quick overview of this toolkit!

making spogo work in a stateful, multi-step game

spogo is a cli tool. it was designed for single commands, not for coordinating a 5-round game with stateful scoring. wiring it into the quiz flow required digging into spotify’s authentication specifics (the sp_dc cookie, connect device handling) and making each tool reliable enough to be called mid-conversation without failing silently. reliability under a live voice session is unforgiving — a broken tool call just means the agent gets confused.

what’s next

spogorun is the first ai-native experience that brings running, music, and fun together in one seamless flow. the next step is wrapping it in a coverflow-inspired mobile app — something that feels as good to look at as it does to use. the goal is to make the screen you glance at before a run feel as exciting as the run itself.

the core loop is solid. voice works. quizzes work. the agent handles nuance well. now it just needs a home that matches the vibe.

#GeminiLiveAgentChallenge

Over the past few weeks, discussions around Clawdbot have been hard to miss. Personal AI assistants are set to be the centre of attention in 2026, and Clawdbot (now Moltbot OpenClaw) has become the “torchbearer” for the pack before Big Tech and major labs release their own versions.

• GitHub stars for Clawdbot are skyrocketing.

• Anthropic emailed the developer to request a name change.

• Mac minis are reportedly selling out as users spin up local setups.

• A social media network of personal assistants is exploding.

At first glance, it’s easy to dismiss this as just “another AI moment”, a clever demo, a fast-growing repo, and the familiar cycle of hype and skepticism. To be fair, there are reasons for skepticism: the project has rough edges and real security concerns. At the same time, it is clearly not “AI slop.” The codebase shows intent, structure, and evidence of care.

What stood out to me wasn’t just what was built, but how it was built. This was largely a one-person effort, developed rapidly and grounded in software fundamentals. It uses agents aggressively, yes, but within a workflow that emphasizes feedback, verification, and iteration.

That is the part I want to focus on. Clawdbot’s popularity is fascinating, but the engineering mindset behind it is what’s worth studying.

It’s a glimpse into a different way of building software.

2. A Preview of a New Builder Archetype

Clawdbot reveals a shift in who builds effectively in an AI-native world. It’s not necessarily the fastest coder, the one most fluent in a specific framework, or even the one with the most programming experience. Instead, it points to a new builder archetype shaping the transition to an agentic engineering landscape.

In this model:

• Code is disposable. You are willing to delete large chunks and rewrite them if the iteration loop teaches you something new.

• Feedback loops are sacred. The real work isn’t typing code, it’s designing tight cycles of thinking, execution, and verification, then letting agents run those loops relentlessly.

• Product taste is the real moat. The hardest problem isn’t getting something to work; it’s making it feel “right” to the human on the other side.

Clawdbot uses AI, and that’s cool. But what sets it apart is how AI is used: not as a shortcut or for brainless prompting, but as a collaborator operating inside well-designed loops. That distinction quietly changes everything about how software will be built from here on out.

3. Where these ideas come from

The way Clawdbot was built makes more sense once you look at the creator. Peter Steinberger is not new to software or product thinking. He spent over a decade building PSPDFKit as a founder and CEO, staying close to the code and deeply involved in product decisions. After selling his stake and stepping away for a few years, he’s back and building again.

That background matters. His “vibe coding” sessions naturally look different from the efforts of most engineers. Listening to Peter discuss the project on TBPN and The Pragmatic Engineer, what stands out is his comfort level working with AI. There is no anxiety about being replaced and no hesitation to experiment with a beginner’s mindset, likely aided by his break from day-to-day engineering. This created space to treat agents as genuine collaborators.

Yes, Peter has advantages: experience, time, and the freedom to experiment. But those are only a small part of the story. The transferable part is how he uses that freedom. He stays intensely curious, plays with ideas instead of over-planning, and works hard to close feedback loops quickly.

In a fast-moving landscape, those traits matter more than ever. Agentic engineering may reward privilege to some extent, but it rewards care, curiosity, and repetition far more consistently.

4. Why coding is no longer the moat

For a long time, speed in software engineering meant one thing: how fast you could write correct code.

That made sense in a world where humans were the bottleneck. The faster you think & solve, the faster you ship. The better you knew a language or framework, the more leverage you had.

Raw execution speed is no longer scarce. You can spin up agents that generate implementations, refactors, and fixes faster than any single engineer ever could. In that world, writing code stops being the bottleneck. Deciding what to write, how to guide it, and importantly, when to throw it away becomes the real work.

This is where the idea that “code is disposable” starts to make sense.

Disposable does not mean careless. It means you are not emotionally attached to the first version. If an agent produces something that teaches you more about the problem than about the solution, you delete it and move on. The value is in what the loop revealed, not in preserving the output.

Speed now comes from something subtler. It comes from understanding how agents fail. From anticipating what context they will miss. From knowing when a prompt needs structure and when it needs freedom.

This is what people loosely describe as “getting the vibes.” But it is not intuition in the mystical sense. It is pattern recognition built through repetition. After enough loops of disposing code and writing prompts, you develop a feel for what an agent will misunderstand, what it will overfit to, and what it can safely be trusted with. And, through these iterations, you will get more context about the problem at hand. Gaining exposure from different angles through various responses helps you better approach a solution, disguised as a better prompt.

That is why coding, by itself, is no longer the moat and treating code as disposable is a practice of the hour.

5. Closing the loop is where engineering comes back

Closing the loop is about thinking about features in a way that makes them plannable, executable, and testable.

This is where the essence of engineering shows up.

When you work agentically, you are forced to think about a feature from multiple angles at once. What is the architecture? What is the approach? What constraints matter? How would this be tested? How would failure show up?

Peter mentioned that he now thinks about architecture and system design even more than before, despite agents doing most of the coding. That might sound counterintuitive, but it makes sense. When execution becomes cheap, judgment becomes visible.

Pair that kind of upfront thinking with fast feedback from agents, and something interesting happens. You immediately see the consequences of your architectural decisions. The loop from idea to implementation to validation closes quickly.

By moving through ideation, planning, execution, and testing in quick succession, you keep architectural judgment close to its outcomes. The process becomes verifiable, not just in code, but in thinking. You are exercising judgment continuously, not upfront and then again months later, as often happens in larger orgs and teams.

A useful mental model here is local CI. Just as continuous integration constantly verifies that changes do not break the system, well-designed agent loops continuously verify that progress is real. When something fails, the loop catches it early and course-corrects before it turns into wasted effort.

This is also why agentic engineering is the opposite of vibe coding. Vibe coding hopes the output is good. Closing the loop proves it.

Once those loops are in place, the leverage compounds. You are no longer supervising every line of code. You are designing systems where ideas reliably turn into working software.

6. What still matters: product taste

Once coding becomes cheap and loops become fast, the hardest part of building is yet to arrive.

The main difficulty is no longer getting something to work. It is making it feel right.

Peter was explicit about this. Even with agents doing much of the execution, the hardest problem remained figuring out how to make the product feel magical to the user.

This is where product taste becomes the real moat.

Taste is hard to define and even harder to automate. It lives in decisions that are difficult to test directly. It takes shape in the questions you ask about the product and the user. In what environment will the user interact with the product? How will the interaction take place? And what will bring delight to the user?

Agents can help you explore options. They can prototype variations and surface trade-offs quickly. But they cannot decide what feels right. That judgment still comes from a human who cares deeply about the experience on the other side.

This is also why Clawdbot resonated the way it did. Its popularity was driven more by product taste and freedom than by raw capability.

That combination matters more than ever. Code can be rewritten. Loops can be tightened. Infrastructure can be copied. Taste compounds quietly over time.

What I’m taking away

Clawdbot’s success isn’t just a glimpse into personal assistants. It is a preview of a new builder archetype.

Someone who treats code as disposable, loops as sacred, and product taste as the real moat.

That framing has helped me make sense of the current AI engineering landscape.

In experimentation. In judgment. In feedback. In care.

What I’m focusing on next:

• Designing tighter loops between planning, execution, and verification..

• Building intuition by experimenting relentlessly with new models.

• Caring more about the end-user experience than the implementation..

If there’s one reassuring takeaway in all of this, it’s that this landscape does not reward hype or shortcuts for long. It rewards curiosity, repetition, and people who care enough to keep refining their taste through building real stuff.

That’s a version of engineering I’m excited to grow into.

Inspired by Peter Steinberger’s appearances on podcast and .

A scene in a movie is more than just audio and video, right? It’s the dialogue, scores, the camera movements, the tiny gestures that make it land. A song isn’t just words and chords; it’s layers of feeling compressed into minutes, reaching for something larger than the sum of its notes.

Studying is this pursuit of understanding the machinery, the patterns, the connective tissue that guides how I think about building anything meaningful on the outside.

That curiosity shows up in everything I consume. In computer science, it’s the challenge of understanding algorithms and distributed systems, not just that they work, but why they work, and how the pieces fit together under the hood.

In stories and films, it’s the way scenes, dialogue, and visuals interlock to create a single experience. A single edit or change in attitude of character can shift an entire scene, just as a small tweak in code can change a program’s behaviour. Songwriting works the same way: layers of words and music compress a vast range of feeling into minutes.

Across systems, media, and music, the pattern repeats: I’m drawn to the parts that make the whole work. Understanding how things connect, whether it’s a line of code, a frame, or a note, is what informs everything I build.

but lately, things have started to shift.

Studying the inner workings is only half the story. The other half is how it lands in the real world. Building something isn’t just about correctness; it’s about the way people experience it.

Take sound design, for example. The same alarm can feel alarming, soothing, or invisible depending on context. A weekday office alarm should jolt you awake, while a Sunday morning chime should lift you gently without intruding. The question shifts: not “does it work?” but “how does it land?”

The same principle shows up in products and interactions everywhere. Every design choice, every feature, every tweak is an opportunity to translate internal understanding into a meaningful, human-centred experience. Studying systems teaches me how things work; shipping teaches me how they feel.

Over time, I realised this approach isn’t something I force; it just happens. It’s a habit of noticing the parts that often go unseen and asking, “Is there value here if I look a little deeper?” Whether it’s a system, a scene in a film, or a layer of music, I naturally dive into the mechanics and connections, curious about what can be drawn from them.

That’s why I’ve started thinking of myself as an inside–outside builder.

I study the inside of systems so I can build better experiences on the outside, from distributed systems to human-centred products. It’s a simple idea, but it captures the way I work: looking deeply, almost instinctively, then shaping thoughtfully, whether it’s code, a product, or a story.

Right now, I’m shipping ConnectSignull, a casual multiplayer word game built around the energy of friends genuinely having fun together. It started with a feeling, that spark of connection, and became an idea, a piece of code, and a solid prototype.

The game is simple in description but rich in interaction. I didn't build it just to sync states across clients; I built it to engineer a specific kind of chaos. It’s about the tension in the silence while someone thinks, the rhythm of the clues, and the collective burst of laughter when the answer finally clicks. The code handles the logic, but the experience is defined by the unique friction of friends trying to read each other's minds.

Through building ConnectSignull, I noticed something striking: the experience embodies the inside–outside lens across every layer. The systems that make the game work, the design of interfaces, the sound effects to interactions, the subtle rhythm of conversations and back to setting systems for scoring, all combine to create a meaningful, playful experience. It’s the same patterns I capture in films, songs, and systems: depth informs experience, and experience gives depth purpose.

Alongside ConnectSignull, I’m studying distributed systems and building a Memcached clone, exploring the mechanics that underpin large-scale software. And in my free time, I play with Vision Language Models and AI for generating media, writing a scene and seeing how well it translates to an image & video.

Everything I study and ship feeds this same habit: noticing depth, exploring connections, and turning insight into experience. It’s almost instinctive, the habit of looking inward, then outward, again and again.

For now, I study the inside so I can shape the outside. I build what feels alive, and I trust the process will continue to reveal the full picture.

This post is inspired by a recent post by at Thanksgiving, 2025. Now, that I think of it, it seems to be not-so-recent, but having a manifesto out late seems better than not having posted at all.

It’s been a few days since Stranger Things ended, and the feeling hasn’t settled into anything recognisable yet. Not closure. Not satisfaction. Not even clean disappointment. Just a quiet, persistent void that’s hard to explain rationally.

I loved the experience of watching the finale. The scale of it, the tension, the way it felt communal again. And yet, when it was over, something didn’t resolve. Instead, it lingered. I found myself replaying moments, not because I was searching for Easter eggs or answers, but because I was trying to understand why the absence felt heavier than expected.

On paper, it doesn’t quite add up. This was a great, engaging piece of television. One that ran its course. One that gave us years of characters, memories, and growth. And still, the ending didn’t leave behind a sense of completion. It left behind space and a lot of loose ends.

That’s the part that’s been hardest to sit with. Not that the ending hurt, but that the hurt feels strangely unanchored. As if the show didn’t just end, but quietly stepped aside and left something unfinished in the viewer.

This isn’t an attempt to defend the finale or argue that it was secretly perfect. It’s an attempt to understand why loving and hating it can coexist so strongly, and why that tension itself might be part of what the ending was asking us to hold.

2. Why Mike Mattered So Much Here

Across Stranger Things, most characters are given arcs that are easy to name once they are completed. Lucas learns what loyalty costs. Max confronts grief and learns how to survive it. Will faces his fear and slowly learns how to be honest about who he is. Dustin figures out the underlying theory and plays a crucial role in devising the plan to save the kids, stop the doom, and kill Vecna.

Mike’s arc has always been harder to summarise, not because it is quieter, but because it is less glamorous amid all the chaos and spectacle. His role is not to shine in isolation, but to enable other people to become who they need to be.

We see it in the way he brings out the best in people around, and in how he draws courage and resolve out of people simply by trusting them with Will the Sorcerer, Holl the Heroic and even his mom, Karen, walk’em down Wheeler. Mike often acts as a quiet catalyst rather than a visible hero.

Because of that, it felt natural to expect something specific from him in the finale. If anyone was going to cut through confusion, restore clarity, or give meaning to chaos, it would be Mike. Especially when it came to Eleven.

Their relationship has always been built on belief. On seeing each other clearly when the rest of the world cannot. So it was easy to imagine Mike as the one who would help Eleven untangle the doubt and distortion surrounding her past, her power, and the choices forced on her. Easy to believe that his role would culminate in reassurance or rescue.

That expectation mattered. Not because the story owed it to us, but because Mike’s entire identity had trained us to hope for it.

3. When the Enabler Loses the Person He Loved the Most

What the finale ultimately does is refuse the version of Mike’s arc we were prepared for.

Instead of stepping in to save, clarify, or restore, Mike is left with loss. He loses the person he loved the most, the one relationship that had defined his sense of hope since childhood.

The loss is not framed as heroic or triumphant. It is quiet, heavy, and unresolved. Love does not arrive in the form of rescue or reassurance. It arrives as absence.

What makes the moment difficult to sit with is how much history it carries. From waiting in the rain as a child, to believing without evidence, to holding onto hope when it looked unreasonable, Mike’s relationship with Eleven has always been about choosing faith in the face of uncertainty. The finale does not invalidate that history. It takes it seriously enough to demand something harder from it.

Instead of rewarding belief with reunion, the story asks what belief looks like when the person you believed in is gone.

And that question lingers.

4. Mike’s Hardest Role: Enabling Himself

What follows the loss is not resolution, and it is not clarity. Mike is not given answers, instructions, or even reassurance that what he believes is correct. What he is left with is memory, experience, and the choice of what to do with them.

For most of the series, Mike’s strength has come from standing just behind the people he cares about, helping them find courage, direction, or belief. In the finale, that outward motion collapses inward. The only thing left is how he chooses to carry what he has already lived.

Hope, here, is not framed as optimism. It is not the confidence that things will work out, or that answers will eventually arrive. It is closer to discipline. A decision to keep faith with what mattered, even when certainty is gone.

Mike does not move forward because he knows he is right. He moves forward because he chooses to believe that the meaning of what he experienced is not erased by how it ended. That choice does not erase grief. It exists alongside it.

This is where the ending quietly shifts. The story stops offering direction and instead watches to see what its characters, and eventually its viewers, will do with what remains.

5. Widening the Lens

It is hard not to notice how this moment mirrors the position the finale leaves the audience in. Not because the story insists on the parallel, but because it quietly places us in the same emotional posture.

Like Mike, we are left without complete answers. The story steps away without resolving every thread or easing every loss. What remains are memories, interpretations, and the question of what we choose to do with them.

This is where the ending begins to feel less like a conclusion and more like a handoff. The responsibility of meaning shifts from the story itself to the person watching it. Not in a way that feels instructional or deliberate, but in a way that feels unavoidable.

For fans who feel angry or conflicted, this can register as abandonment. As if the show asked for years of emotional investment and then refused to offer the comfort that usually comes at the end. That reaction makes sense. The absence of reassurance is not something the audience was prepared for.

And yet, seen through Mike, the discomfort takes on a different shape. The ending does not ask us to approve of what happened. It asks us to decide how we carry it. Whether grief hardens into resentment, or whether it is allowed to coexist with the belief that what we experienced still mattered.

That choice is not easy. And it is not resolved by interpretation alone.

6. What This Ending Leaves Us With

If the finale leaves us with anything concrete, it is not answers or reassurance. It is permission.

Permission to feel disappointed without needing to declare the ending a failure. Permission to grieve what we hoped the story would give us, without turning that grief into bitterness. Permission to admit that something meaningful can still hurt when it ends this way.

What Stranger Things leaves behind are not conclusions, but tools. Memory. Interpretation. The ability to look back and decide what mattered, even if some questions remain unanswered. The quiet insistence that meaning is not undone just because the ending refuses to comfort us.

Mike does not reject what happened. But he also does not leave it untouched. He rewrites the ending for himself, not to erase the loss, but to keep grief from hardening into bitterness. He chooses a version of the story that allows the pain to exist without letting it define him.

The uncertainty stays real. The loss stays real. What changes is not the past, but the meaning he carries forward from it. Hope survives not because it is rewarded, but because it is actively practised.

That is the invitation the finale extends. Not to agree with it. Not to feel good about it. But to decide what kind of relationship we want to have with what we loved, now that it is over.

It took Mike and his friends eighteen months to reach this moment. Not certainty. Not proof. Just a choice.

Maybe we don’t need that long.

There’s something unforgettable about a 25–30 shot rally in a Grand Slam final. Yes, the winning point is what shows up in the highlight reel — but it’s the rally that holds the beauty of that point. The sweat, the impossible saves, the sheer endurance. That’s what makes the victory feel earned, both for the players and for us watching.

Building a product is no different. Launching may seem like everything, but the truth is, it’s the rally — the countless decisions, fixes, and iterations — that make the launch possible and meaningful.

(Here is a clip from one of the rallies I love watching)

My own rally began with the first serve: fast prototypes built in Google’s Gemini Canvas. At the time, I thought some of them might be aces — a sentence-to-playlist generator, an image-to-journaling-based notes app — but ideas rarely land those aces as cleanly as we imagine. I realise this now, the real power wasn’t in hitting a perfect serve, but in getting the opportunity to serve the ball for an ace. Prototyping fast gave me space to breathe, reset, and line up the next shot in the rally. You throw the ball up in the air to hit the serve and get it going with a working prototype of a chatroom, and integrate it with this social game idea you've had in your mind for quite some time. The ball crosses the net this time, bounces in the court within the legal area, and the rally begins.

The initial points in the rally are about testing the opponent, aiming sharp shots into the corners, and forcing movement. That was the first push: developing and deploying a prototype in Vanilla JS, tied to Firestore, and hosting it quickly on Firebase. Just a few exchanges in, and I was in the game — a simple rally underway, the ball moving, friends testing it.

Then the opponent returned stronger. Feedback revealed a bug in the Vanilla JS setup: every time the UI refreshed, it cleared the input fields, cutting off the flow for players mid-guess. It was the kind of interruption that broke momentum and frustrated anyone racing against the clock. A low, sharp ball at the net. I lunged forward and responded with a stronger shot.

That shot was React. Modular, component-based, robust — React gave me control over the interface, and Zustand provided lightweight but mature state management. It was a cleaner, more deliberate stroke. I deployed on Vercel this time, enjoying its seamless Next.js integration, and sent the ball back deep.

But the rally didn’t end there. The opponent managed to return with a lofted shot to the baseline. The UI broke again, not because of the frontend, but because Firestore struggled with multiple concurrent updates. Race conditions appeared, and the state slipped into inconsistencies. I had to pivot, turn, and sprint back to keep the ball alive.

The next return demanded more than a framework switch. I researched how other multiplayer games — Skribbl.io, Codenames — managed their flow. The answer was clear: WebSockets. Unlike the slower, state-heavy back-and-forth with Firestore, WebSockets provided a way to keep connections alive, fast, and reliable. They made it possible to avoid latency, sync players smoothly, and keep the rally fluid.

Now the ball is bouncing high near the baseline, and I’m racing to meet it. The next shot in this rally is WebSockets — a chance to keep the game alive and push forward into a more reliable backend. Whether I make the return or not, that’s the moment the match continues.

This is the third blog in the series on building this word game for friends. In the next post, we will dive into WebSockets and what it takes to build a real-time multiplayer word game. I can’t wait to share it — and to get the game into your hands soon.

👉 If you want to try it as soon as it’s ready, join the waitlist here.

See you in the next one!

During one of those chats, she shared an analysis she’d seen about what made Wordle so successful. One factor was its clever sharing mechanic — but the one that stuck with me was how it was created.

Wordle began as a gift: built by Josh Wardle for his partner, who loved word games. It wasn’t backed by a company, or spun out of a data study, or optimized for scale. It was just one person building something delightful for another.

That idea — “building for one” — struck a chord. Focus on making the best possible experience for one person, and the rest either follows… or it doesn’t. Either way, you’ve built something meaningful.

The power of one is a great compass when building.

When you design for just one person, something interesting happens: the work gets sharper. Every choice has to hold up to real feedback. You don’t get to hide behind dashboards or trends — you’re forced to notice what delights, what confuses, what sparks joy.

That intimacy naturally shapes the product. It keeps things people-first. You’re not optimizing for metrics, you’re crafting an experience. Like preparing a meal for a friend: it doesn’t need twenty courses, it just needs to feel thoughtful and satisfying. And most importantly, it still has to be fun.

Only after that intimacy works does the question of scale even matter. Once something is meaningful and joyful for a few people, then it can extend outward gracefully. But starting with the crowd — building for “everyone” — is often where products lose their soul.

I felt this most clearly during the weekend playtests of this multiplayer word game I am building.

In the early version of the prototype, everything lived inside a single index.html with HTML, CSS, and JS woven together. It wasn’t elegant, but it let me move fast. If someone in the group pointed out an issue, I could fix it within minutes. If someone had a feature request, it went straight into a doc and often made it into the very next round of play.

That’s what building for one (or in my case, a group of friends) does. It keeps the product close to real reactions, rather than relying on abstract guesses.

Of course, even when building for one, things can get messy fast. Ideas pile up, bugs surface, and people suggest tweaks mid-game. Without some structure, the “fun” quickly turns into chaos.

To keep myself nimble without overengineering, I set up a lightweight workflow — just three simple docs:

• plan.md → the original logic and configuration

• features.md → a living list of features with status updates

• user_stories.md → detailed context behind each feature request

That was it. Just enough scaffolding to keep momentum without slowing down.

The philosophy behind this was simple: the tools you use to build quietly shape what you build. Heavy processes create heavy products. By contrast, light tools keep the product playful, human, and close to the people using it.

This little experiment began as a fun weekend social game with friends — and it’s slowly evolving into something bigger. Each playtest shapes it in surprising ways, and I can’t wait to see how it grows when more people get their hands on it.

Here’s a quick peek at the prototype (a more robust version is on the way).

If you’re curious to play when it’s ready, I’ve set up a waitlist here.

Thanks for reading — and for joining me in exploring how playful, mindful products get built. Cheers!

Freud said, “Love and work, work and love, that's all there is.” Well, I’m computer engineering grad student at Stony Brook University. And this summer, my work and love for computers came with a catch: as an international student, I wasn't authorized for a traditional internship for the summer.

How did the summer go for me then? It has been an ongoing, relentless effort in creativity.

At first, I admit, I enjoyed the novelty of it. felt like I was playing hooky from the world of structured internships

I got my hands on the latest AI tools using every student discount I could, then spent my time exploring their capabilities, building apps, generating content and dreaming up new ideas.

But there's a problem when you let go of the leash and have the freedom to do anything—you start to run out of meaningful things to build. The "nothing-is-real" and “everything-is-a-prompt” feeling hits you like a ton of bricks.

I realized the key to this whole deal was to keep moving. To keep creating, and not lose sight of my own capabilities and curiosities.

So, I got up. Got myself ready, and come rain or shine, my day started with applying data structures & algorithms. Three to four problems every single day. I can't explain it, but it’s like having those Starbucks coffee highs! This ritual made me feel part of something bigger— sharpening my craft and solving problems.

“How do I spend the rest of my days?
Started with learning Go — building little command-line tools.
Then joined an open-source community, Team Shiksha — designing products, databases, and MVPs.
Vibe-coded a chatroom with friends, which somehow turned into a social game prototype.
Read Netflix and Notion tech blogs… even wrote some of my own on Substack.
Listened to podcasts — the regular human kind, and the research-paper-turned-into-podcast kind using AI.
Watched F1. Played football. Tried songwriting, video editing… even went to a Coldplay concert.
Translation? Believe me, I watched a lot of Phineas and Ferb to soak some in this summer.”

Amidst all this, of course, there were the moments of despair. The doomsday news about AI replacing us, the layoffs, brainrot content, celebrities explaining trigonometry, ai generated superheros mocking each other in interviews and so much more than I could imagine. all felt like funerals for the future of art and authenticity.

i am not an unhappy pessimist with all this ai stuff coming in. quite the contrary. i just know that there is this huge wave in technology, and i need to learn to surf it.

soon.

An easy escape for me from all this noise & clutter of ai and social media has always been watching a feel-good film. And there's this one classic with Robert De Niro and Anne Hathaway, that I find myself going back to again and again: The Intern.

The story follows Ben, a retired old man who becomes an intern for a driven entrepreneur named Jules. I was watching it again recently, right before it left Netflix, and something hit me. In a future with AI agents and AGI, a handful of lines of code or a no-code tool) could help Jules achieve each & every target she wants for her startup. But the warmth, wisdom, and human connection that De Niro's “intern” brings? That will always be fresh, relevant, and utterly invaluable.

Then, the movie has this scene—

So here I am, applying to be one of your interns! Because the more I think about this idea, the more tremendous I think it is. I am studying computers here at Stony Brook, after completing my undergrad at the one of the finest university of my state back in India. I want the connection, the excitement. I want to be challenged… and maybe a place to pour all this curiosity into!

Unlike Ben, I won’t need a 9-year-old grandson to explain what a USB connector or a modern-day MCP is. I’ll go out there and figure it out. The tech is where I live. But like him, I'm loyal to the craft, trustworthy in a team, and good in a crisis. I’ve a couple of years of experience working in startups to back this too.

I read once that when you want to build a ship, you don’t teach people how to gather wood and how to sail; instead, you teach them to yearn for the sea.”

I believe I am ready for the waters as well! absolutely positive about that!

The story begins a few days ago, when my foi (aunt) asked for my US address. She wanted to send me rakhis for Rakshabandhan, a festival for siblings where a sister ties a sacred thread on her brother's wrist, signifying a promise. It’s the promise of the thread guarding the brother, and the brother safeguarding the sister in return—not with another thread, but through his actions and duties. I gave the address and got the rakhis last week. When I received the package, I realised I also have to carry out the ritual of changing the sacred Janoi thread, that I have been sworn to since the February of 2024. When I was talking to my aunt about having received the package, I told her that I would have to find a temple to get the Janoi thread for the ceremony. To my surprise, my grandmother had remembered about this, and had added it the package as well. Thoughtful, timely and caring, just as grandmothers are. While I was talking to them, I told them that I would also have to find a girl here, who could tie me rakhi for the festival. I told them I would look for some foreign asian or maybe american girl maybe who could tie. The thought of having a sister beyond borders was amusing to me.

After talking to them, I had a profound moment of realisation. Over the years, I have celebrates festivals at various places. My dad working in Bharuch and our family being in Ahmedabad, there would be instances where I would have celebrate some Diwalis in Ahmedabad others in Bharuch, or Navratris in Bharuch and some of them in Ahmedabad. Rakshabandhan happened to have stood the test of time, being the only festival, when I was for sure in Ahmedabad. Come what may. Throughout the school years, I was notoriously known as someone who would never have a school friend tie me rakhi, as I would be off to Ahmedabad a day or two earlier. Even during the college years and two years of working, friends would be startled by the number of Rakhis on my wrist, thanks to all my elder and little sisters in the family. I even didn’t miss the rakshabandhan during the covid of 2020, and made it to Ahmedabad during those trying times. Knowing that this Rakshabandhan would be so distant and different felt like a punch to the gut. The history of how I'd always celebrated this festival with family made my search for a sibling here feel all the more personal and urgent.

I did give a subtle try to get a girl from Greece to tie me rakhi, but didn’t go quite as well.

This brings us to the morning of Rakshabandhan eve in New York. I signed up for a meet-up for a Systems Coffee Club and I don’t know who I was here to impress or get connected with that would help me get a job, that I woke up at 5.30 in the morning, got ready, cooked & packed some breakfast, got some coffee and got running to catch the train. With all the packing and breakfast involved, I missed the first train, but reached just in time to make it to the meet-up and it went good.

Not great, but good.

I felt I wasn’t as extroverted or outgoing as some people I saw around. I was genuine for what I did, tried talking about my stuff, listened to people about their work, packed some learnings and maybe a bit of disappointment as well. You can always be better at these things, right?

I leave that space and sit by a table at my favourite park in the city. Well, I haven’t been to many yet, but this one will stay favourite for being the first to fall for, sleep at, stroll by and basically do everything and anything I have done in the city. Coping through some dejection from the meet-up, I was just sitting and watching time pass by. People walking by, having their breakfast, couples playing games that couples do, observing the trees, the building, checking the freshness in the air, listening to the piano by the centre. Reading a book at the reading area, watching people play chess and checkers, baby girls in a merry-go-round and also joining in with a couple of strangers to play table tennis for a bit.

I talked with my family back home, who had gathered for Rakshabandhan just the way we would the day before at Ahmedabad. I shared them some glimpses of the park and the activities going around. The thought of the failure in finding a sister did pass my mind during the call, not gonna lie. but let it be. The call ended, and I picked the thinnest of the book from the book stand and started reading it. It was a comic on the ancestors of Lord Ram. Finished it pretty quickly and started looking for a place to eat lunch.

I don’t get to eat much of South Indian food near my university, so selected a place nearby to get some medu vada. As I ordered and took my seat, a girl sat beside me and a gentleman, maybe in his 30s, took his seat beside her. This gentleman was the guy who would just rock up any meet-up you put him in. Consider him the guy who is working in finance & management, extroverted and outgoing, in all the ways out there. He talked with everyone around and went away in a bit. While him doing his thing, I happened to introduce myself to this guy and the girl besides.

In a classic act of universal serendipity, I found out that the girl, about the age my sister, lived in Ankleshwar back in India, which is a twin city to Bharuch, where I spent my childhood and schooling and she had studied at a school well-known to me, and we instantly connected over our shared hometowns. During the conversations between the three of us, I was not the most spontaneous, and extroverted nor the one with the most punchlines, but I was honest, authentic and frank about what I was doing and listening to them sharing their stories. After the guy left, she was waiting for some of her friends and told us that we could go somewhere around till then to explore the city. Just as I would have been connected with a neighbour from back home, we talked a lot on our student journeys in US and a lot more. During one of those conversations and exploring the diamond street, I asked if she celebrated Rakshabandhan here or not, knowing that her family was here itself. She told her brother & parents weren’t in the states, so she won’t be. I asked instantly, if I still have the package I received from my Foi in my bag, could she tie the Rakhi? She agreed, but only on the condition that I don’t gift her anything in return. I agreed, a bit dishearteningly, because I also had nothing to offer in return.

As we were walking through the street, we saw a huge church at the end of the diamond market, and she told us we should visit it, it’s really great and she has been here many times. The church was massive and just beautiful. I was just so in awe of the moment, on what are the coincidences I would have to cross through to have found a neighbour in the biggest city on the planet that I wished for the last ten days. Everything then was just icing on the cake of the moment. The intricate glass piece works inside the church, the lighting candle ritual at the church, relating with our Indian culture of lighting up diyas, and a christian wedding taking place in the church at the same time. It felt so fulfilling and fitting to see these events unfold intricately. I told her we should do it right there—to tie the rakhi in the church itself. After all, it is a sacred space. I checked my bag and found the package lying at the bottom. I got out the rakhi thread, and she tied it onto my wrist. Just as I didn’t get to record any video or photo of this, she tied me another one just for the gens in me to get it on camera. An old lady sitting in the front of us did the favour of clicking some photos as well. I also happened to find a couple of chocolates, I put them in with the breakfast(that made me miss the train in first place) in hurry, which helped me manage to gift her something tangible at the end of this nothing short of mix match of a tradition we carried out. We started leaving the church as she was getting a call from her friends, and in no time she left as her friends were nearby. Gone. Just like that.

I don’t understand what part of trusting strangers turn to neighbours turn to festival that makes this all come true, but still couldn’t fathom about how this clockwork of the universe functions. Is it all probabilities, chances and coincidences or is there some destiny at play to this? I don’t know. What I know for sure is

with a leap of faith, some authenticity at heart and a spirit of adventure there is something out there in universe for you too.

PS: this overall incident prompted me more towards finishing that song-writing attempt ngl.

lets go back to the caveman and ancient definition of engineering. what did engineering look like in the most earliest of the days. someone was feeling cold, light a fire, sort of engineering it is. having to walk a hundred miles from point a to point b, transform a wheel to a car, engineering it is. and relatively modern example would be the converting chemicals to react to get electricity out of them. basically, any application of science paired up with logic to make people’s lives better seems to be the broad definition of engineering.

then came the invention of assembly lines that leveraged an individual engineer’s intellect and effort into repetitive tasks. the benefits of these were unparalleled. profits for companies and factories reached new heights. these profits empowered the organizations to make crazy lot of money to scale things outside of their arena. after ruling their own regions, they left their localities and took their products and services beyond borders. the repetition of engineer’s effort also gave rise to them developing expertise and acquiring specific knowledge. this was a boon and a curse in disguise. engineers had little of direct value to the society as an individual. their logic, reasoning and efforts were commodotized by the organizations. not a problem on temporal time scale, but extending it for prolong periods of industrial revolution and same model followed during the rise of programming jobs since the second quarter of the last century.

the core advantage with programming jobs of the last quarter was the ease of switching between the works of various organizations due to shared adoption of technologies and open-source destribution going the right way. but the majority engineers having the mindset and skillset of ambituous Tony Stark, where limited by the montony and laziness of going beyond the requirements set forward to them by higher order decision makers and stakeholder. also, the money still being poured into it, made the major chunk of engineers lazier to go beyond the daily work and unleash their real potential. a big part of the engineering went into fixing up the naive css and centering divs and deciding between flexbox and grids.

enter ai. getting better by the day than most frontend developers out there, making sure to cook up the smoothest, crispest, and flowiest UI out there. almost at the speed of thought. even though it turns out to be a boon to the wrecking havoc those UI issues took to reslove, right now, the same ai is trying to be framed as something challenging their jobs.

why so?

first things first, most of the hype is just attention hacking propaganda out there. by targeting the mere identity and job of a developer and screaming out loud that it will sink the whole titanic is a bit of exaggeration out there. of course you could build a website in one shot top notch prompt, but that doesn’t translate to build a stateful, efficient, robut and well crafted UI and frontend for a web or mobile interface? there goes a ton of tinkering, experimenting, testing and feedback, to build the modern day products. even though our basic unit of work to be done by hand is automated by ai, the competition to get better by the minute by the competitor is getting steeper still. you would want to prototype faster, get user data points and feedback quicker, to iterate again and come up with something that user doesn’t have to tell you to code, but just fits to what it should be according to them.

i am developing a collaborative word game for quite sometime, and from my experience, i would say AI is making my engineering better if not worse. i am dedicating more time figuring out what users want, how can i understand users need better or maybe spend time with user testing instead of figuring out what the CSS class selectors go where and how to set the padding right. I am not against those activities as well. If a designer or artist is putting in efforts to get the best & most meticulous designs and UIs, i respect that more. But as per my background in technology, i would like to figure out ways to make day better for my user. And AI enables me to test more and iterate on feedback better than ever before.

my take is simple. frontend development isn’t dying. its transitioning. it’s giving engineers back their experimentation and putting brains to use for something far more challenging and impactful. going beyond fixing weird ui bugs. its going into crafting better products.

so, the pichu of frontend development is evolving to the pikachu of frontend “engineering”. are you ready for it?

follow along as I experiment my way through it and share my journey through building this game.

“Connect”

“Connect”

“Connect”, joined another hand, hesitatingly.

while one of the other guys was screaming “train”, “transportation”, the raised hands started with a countdown—

3….2….1 “TELEPORTATION!”

the guy screaming was disappointed for a second, and the next moment he said—

“next letter is R, so TR11”

I was still trying to figure out what was going on. looking at my puzzled face, an excited fellow from the group said, “explain it to prayush, he will enjoy this one too”

everyone quickly explained to me the rules, and that’s how my journey with this game began!

i loved it from that day on. we played it many times internally in the committee, on trips, and even taught it to our friends and batchmates. we played it during fest, and even on video calls during the lockdown and quarantines of ‘20 & ‘21.

everytime a group of friends would get together to play Codenames, Mafia, or Among Us, I would think of bringing this game to a new group. but the explanation and the gameplay throughout might be difficult to follow. i needed an interface.

recently, i got talking to someone from my undergrad, and we were reminiscing about this game. i remembered the rules pretty well, and was trying to find it to play online. couldn’t find it online, so started building it using Gemini.

after a prototype for a chatroom app and another 6 hours of elaborate prompting and and i got a basic canvas and prototype ready!

as this canvas was shareable via link, i shared it with a couple of homies and we started playing it! everyone loved it. i started collecting feedback and got my prototype to the next level, minimum-viable-product.

i spent the next week giving it some time daily, refining the edges and giving it a proper shape. connected it to Firebase, formalized the game logic, ensured all the flows worked fine, and finally deployed it last Saturday.

the development work will keep on improving, but that is nothing without seeing it live in action. so, i have started playing with it with everyone around. my roommates, some homies, and I are gathering more and more feedback, to give it the best collaborative word game experience one has had.

i’ll be launching the game pretty soon, the gameplay being collaborative in essence, isn’t designed to be played or understood without a group of friends, family, colleagues, or even strangers as of now. if you are someone who likes to play these fun social games and wants to be one of the first to try out, you can subscribe to this Substack.

more on the game here soon!

you have to deal with all the people, figuring out the tickets, the credit cards, seats, resellers, Ticketmaster, and whatnot.

and wait, we haven’t yet talked about the physical inconveniences of the concert experience. setting the status of OOO early that day, figuring out the least traffic route, reaching before time at the concert to get to a better position near the stage, standing for hours to save the spot in the scorching summer heat, all the crowds pushing and still whatnot.

the post-experience isn’t that well too: walking slowly with the pace of the crowd, the odor of people who are drunk or have smoked pot, being unable to get a space to stand on the bus/train, and whatnot.

but still, we go to concerts. I guess it's because our love for the band's music—or if not for the band, then the love of the people we are going with—is stronger than these inconveniences

my adventure of lifetime starts in 2016. A teenager preparing for engineering entrance tests is running late on a Saturday, trying to get home from his coaching center to watch the live telecast of Coldplay's concert in Mumbai. when i reached home, the concert already started and was almost coming to an end. Now, they were just showing the highlights, glimpses, and sparks of the concert. i ate my dinner and went to the room. a bit disappointed, but back to studying for the test the next morning.

the sunday went by pretty fast. with some dejection at heart for missing the concert, how the test went didn’t really matter.

monday was my birthday. i had reached that point in my age when birthdays were not special days where you wore new clothes to school and distributed chocolates to everyone in class. it started to feel like just another round trip around the sun. i got to school, in normal uniform, and came back.

afternoon, I rolled back to this channel again. Colors Infinity I recollect. It showed some of the western tv shows I was fond at the time. And there was running the WHOLE. COMPLETE replay of the concert i missed. even better, they cut the breaks in between performances, and now I was watching this band just perform some sorcery of music. transcending space and time. there was no limit to the amount of joy those one and half hours brought. then they called up AR Rehman, one of the India’s finest music composer, and sang Vande Mataram with him. IT WAS JUST CRAZY!

pure unabridged goosebumps when Chris tried jamming in hindi with Rehman.

If you remember something peculiar about the music in India, during the november of 2016, it was this one hindi song that people loved from the get go and still love i think. and this english band, then decided to just pull off that. with the last song of the night left to be played, the stage gets dark. no light on the stage, and you see Chris Martin, the lead singer, walk through the stage, hyping up the audience.

“Lets Go, Lets Go”

“Hands Up, Hands Up“

and then he drops those banger of two words everyone from India have heard, atleast once—

“Channa Mereya”

just one of those english guys’ attempt at speaking hindi words? i would say not. it was melodious and more importantly my hymn for that weekend.

with the most magical edm piece surrounding it, the singer goes crazy with the chorus of the song. and it was pure magic.

and with the conclusion of this piece, the singer picks up the last song of the night—

A Sky Full of Stars.

this might be the age old trick in the bag of the bands to perform a local trending song, but it is enough to inspire this teen to attend the concert ONCE in A LIFETIME! Also, the fact that “Channa Mereya” and “A Sky Full of Stars” hold very similar semantic meanings made this performance the as Yellow as possible.

years pass by.

enter 2024. a year full of hope, concert announcements, and online ticket queues.

the coldplay concert was announced in India, and it was again at the same city Mumbai. you know the story from here right.

tickets go live online. people try for tickets, but hardly people got any.

hope is lost, but there is still one reel that i saw somewhere down my feed, where a comedian added in his narration that coldplay is planning for not 1 show, but four to five shows in India, and possibly Ahmedabad as a venue itself! Ahmedabad is my second home city btw, so it’s kind of a big deal if this comedian is speaking facts.

in the hope of it all, we wait for days, weeks and months, to finally get this announcement of band playing in Ahmedabad and new tickets going live!

this time we go in with a better strategy for tickets. instead of just 4 more devices to get the ticket, we get 4 more friends to get in the queue. and guess what.

we made it! a friend secured 4 tickets and the dream looked sorted enough.

there is this line in Kal Ho Naa Ho title track, it goes like—

“Chahe jo tumhe pure dil se, milta hai woh mushkil se"

the mushkil is yet to kill me.

enter 2025.

when i came to know that the concert date clashes with the start date of my masters program in the US. when the band decides to visit to the country you have lived in since birth, and you decide to go to the US the very same time.

the sadness was real at the time. i went to the nearest common room on the campus when the concert was going live in India. there i found a lonely piano. i did try to learn something on it during those moments.

wishing if you could go back to the start.

nevertheless, the story doesn’t end here. we still make it to the concert, after applying for visa, Canada allowing it, and making it to Toronto, just in time, when some good sister karma brings in the best floor tickets for the Coldplay experience.

there is this line in Kal Ho Na Ho title track, it goes like—

“Chahe jo tumhe pure dil se, milta hai woh mushkil se"

i used to believe that this line was more about not getting what you want in life.

trying to understand the connotation at all the times might sway you away from the real stuff. in life and lyric alike.

milta hai woh is the sure part, given if you have “chahe jo tumhe pure dil se” sorted

“mushkil se” depends on how you look at the journey.

thats my time, see you around in the next one, where we can talk about the concert experience itself.

until then, long live life or as they say— Viva la Vida.

fuck it, lets write something. i have been meaning to write something for a while. lots of ideas flooding in. about everything. product. software. music. podcasts. ai. llms and more. i choose to write about ai as you can guess from the title. the last of the ideas i mentioned. but why? well, the rest of them are projected to be doable by a bunch of algorithms, as we put it for the layman. a silent, tireless code. doing stuff better than an average human can do. so why do anything now. why am i writing this even. generating texts, words and sentences are the first things computer scientists tried. while i stop typing at this point, to look up at the grainy white ceiling, to ponder. i look out the window, the wide green expanse and a road passing by. i hear the birds chirping, amidst the music. what do you build now? what will you work on now? the question still lingers. i close my eyes, and a quiet little voice gently whispers, i remember my dad saying this to me last time we talked. or maybe a quote from that famous apple guy—

when fisherman can’t go to the sea, they repair their nets

am i looking for my “net” right now? a net to rescue from what? what's the sea for me, and why can’t i go to it, and why am i the fisherman? its not these tangibles that i am looking for. its something intangible in this line, thats what is missing. something captured in the spaces between the words but still hidden from them. its the intangible drive to go to the sea. the will in their eyes that tightens the strands in their nets. its this impalpable work they put into the knots they tie. build the work ethic. the “fuck it” that started this writing. that done over and over again. that, every time i pick up a task. and that’s what i am looking for. thats it, everything else will come and go, like the waves. what stands unshakable is the work ethic you develop. the soul you put it. with ai, without ai doesn’t matter. having the intent to build. thats the win we are looking for. i mean, what I am looking for. Or is it both of us? i’ll stop violating this aesthetic distance now. its time to get up and going. the sea, the waves, and the water have taught me enou…

ahhh. i finally get what i was missing.

i need water. i have been feeling thirsty since having food. thats what has been missing. i guess, ai is good at doing that too.

the ac was working fine. cooling the space good. but, it made a lot of noise. the entirety of my noon, evening and night, just went by listening to the noise of the ac and pondering how I will get through this all summer. especially, how would I be solving a single problem, if I my attention is for sale to white background noise. i breaked this though cycle by going back to my previous house for some time, brought back some of my remaining stuff. unpacked them a bit. making sure most of them still unpacked in the room.

the noise (headphones recommended)

amongst all the other changes in the work duties and routine setup, I stopped paying attention to the noise of ac after a point. focusing on what I am going to cook, when I have to do the office-shift, how will I solve the water trapping problem using stacks & queues. all these concerns and the consequent actions, made me get back to the present. i spent a week like this, figuring out the schedule and taking care of myself. one fine afternoon, I was back to building something for the web, I noticed there was a sudden pin drop silence. i realised it was the compressor of the ac went through its periodic cycle of shutting down. the silence reminded me how earlier, the noise felt like working under the waterfall. but as I kept focusing on what needed to be done, and continued doing it. not caring about what we can’t change, or have no effect over, makes you resilient over it for sure. what if same goes true for the all exploration i set out to while i am solving a problem. and what if its not about the noise around you, its the noise within you to whom you should not be paying attention. i mean we have very decreasing attention span’s anyway right. letting that work in my favour now

.

Subscribe now