DEV Community: Hemapriya Kanagala

Letters to Tomorrow: A June Solstice Game About the Things We Carry Into Tomorrow

Hemapriya Kanagala — Mon, 15 Jun 2026 13:28:14 +0000

This is a submission for the June Solstice Game Jam

🎮 Play the Game: Letters to Tomorrow

TL;DR

Letters to Tomorrow is a narrative game set during the June Solstice, the longest day of the year.

A summer storm has scattered the town's annual letters to the future and damaged their final lines. You play as the Postmaster working the twilight shift, helping different people complete their letters before sunset.

Each phase of the day contains up to four letters. To move time forward, you only need to help at least two of them, but you are always free to stay longer and complete every letter if you wish. Only the letters you choose to finish are sealed and carried into tomorrow.

As the day progresses, you will meet people navigating friendship, courage, belonging, kindness, uncertainty, hope, and change. You can choose from suggested endings or write your own if none of the options feel right.

At the end of the journey, after helping others find the words they want to carry forward, you are given one final empty envelope and invited to write a letter to Tomorrow yourself.

The game is about the things we choose to keep when one chapter ends and another begins.

What I Built
Video Demo
Code
How I Built It
Prize Category
- Best Google AI Usage
- Best Ode to Alan Turing
Why Letters?
A Piece of My Story
A Small Step Outside My Comfort Zone
Final Thoughts

What I Built

Have you ever wanted to say something, but could not find the right words or the right moment?

That question became the starting point for Letters to Tomorrow.

Letters to Tomorrow is a narrative web game set during the June Solstice, the longest day of the year. You play as a postmaster working the twilight shift after a summer storm scatters the town's annual letters to the future. Many of the letters have lost their final sentences, and it becomes your job to help complete them before sunset.

Each letter belongs to a different person standing at a different point in life. A baker opening his shop for the first time. A musician wondering whether she deserves to be heard. A teacher reflecting on a moment that stayed with him. Someone remembering an unexpected act of kindness from years ago. A person trying to figure out what comes next.

As you read, you choose the words that feel most true. If none of the options feel right, you can write your own.

When I first read the challenge prompt, I kept returning to one idea: the solstice is a turning point. The longest day eventually becomes evening. Time keeps moving forward. We cannot stop it, but we can decide what we carry with us into tomorrow.

That became the heart of the game.

The letters are not about saving the world. They are about ordinary moments that quietly shape who we become. A conversation. A friendship. A kindness. A new beginning. The things we often forget to celebrate, even though they stay with us the longest.

My goal was to create something that feels like taking a deep breath at the end of a long day. A small space where people can slow down, reflect, and perhaps recognize a piece of themselves in someone else's story.

Video Demo

In this walkthrough, I take you through a full shift at the Sunset Post Office, explain the core mechanics, and share some of the ideas that inspired the letters and themes throughout the game.

Prefer to play first?

👉 Play Letters to Tomorrow

Code

If you'd like to explore the source code, the entire project is available on GitHub.

One thing I enjoyed about building this game was keeping everything surprisingly simple. The whole experience lives inside a single HTML file, which made it a fun challenge to organize the narrative, game systems, save functionality, animations, accessibility features, FAQ, and player guidance all in one place.

hemapriya-kanagala / letters-to-tomorrow

A narrative web game about unfinished letters, second chances, and finding the right words. Play as a postmaster on the June Solstice, helping lost messages reach tomorrow before the sun sets.

💌 Letters to Tomorrow

A June Solstice Story

A narrative web game about unfinished letters, quiet moments, and the things we choose to carry into tomorrow.

🎮 Play the Game • 📝 DEV Article

About

Letters to Tomorrow is a narrative web game created for the June Solstice Game Jam.

A sudden summer storm has scattered the town's annual letters to the future, leaving many of them unfinished just before sunset.

You play as the Postmaster working the twilight shift on the longest day of the year. Your role is to read these letters, understand the people behind them, and help them find the words they were trying to carry into tomorrow.

Each letter belongs to someone standing at a different…

View on GitHub

The game is deployed on Vercel and can be played directly in your browser. If you would rather experience it before reading further, you can jump straight into the Post Office below:

👉 Play Online: Letters to Tomorrow

No installation, downloads, or account creation required.

How I Built It

I wanted the experience to feel simple, accessible, and easy to run. The entire game lives in a single HTML file using HTML, CSS, and JavaScript. There is no backend, no account system, and no server required to play.

I want to be transparent about how Google AI was used throughout the project.

The concept, game structure, characters, letters, narrative themes, and overall experience were created by me. The emotional core of the game came from stories, memories, and ideas that I wanted to explore through the lens of the June Solstice.

Where Google AI helped most was during development.

I used Google AI as a coding partner to help build parts of the interface, refine layouts, improve responsiveness across devices, and implement visual details such as transitions, animations, and accessibility features. It helped me translate ideas that existed in my head into working code.

I also used Google AI to review instructional content such as the How To Play guide and FAQ section. Because the game is intentionally gentle and reflective, I wanted to make sure players would never feel confused about what to do next. I used AI as a second pair of eyes to identify questions I might have overlooked and to help improve clarity.

For the narrative content, I occasionally used AI for feedback and editing suggestions, but the letters themselves were written by me. I wanted them to feel personal, human, and grounded in real experiences rather than generated messages.

Accessibility was also important to me. The game is designed to work comfortably on phones, tablets, laptops, and desktop computers. I focused on readability, responsive layouts, and clear navigation so that players can focus on the stories rather than the interface.

One technical decision that mattered a lot to me was privacy.

The game uses local storage only. Everything the player writes stays on their own device. Custom letter endings, personal reflections, and the final letter to Tomorrow are never sent to a server and are never visible to anyone else.

I built it this way intentionally because I wanted players to feel comfortable being honest. Some people may only write a sentence. Others may write something deeply personal. Either way, those words belong entirely to them.

I also made the decision not to include background music. The silence is intentional. I wanted the game to feel like a quiet desk at the end of a long day, giving players room to reflect and hear their own thoughts while reading and writing.

Prize Category

Best Google AI Usage

Google AI, primarily Gemini Pro, played an important role in helping me bring this project to life.

I used Gemini as a development partner throughout development to help with frontend implementation, responsive design, accessibility improvements, animations, interface refinement, and general troubleshooting. It also helped me review and improve supporting content such as the How to Play guide and FAQ section.

For the narrative side of the project, the characters, themes, stories, and emotional direction came from me. I occasionally used Gemini for editorial feedback on drafts, but the letters themselves were written by me.

I also used Gemini to generate the banner image for this article. You may notice a Gemini watermark on the image, which is part of the generated output.

Most importantly, Gemini helped me spend less time fighting technical hurdles and more time focusing on the stories I wanted to tell.

Best Ode to Alan Turing

During the third phase of the game, players discover a letter called The Blue Envelope.

Rather than focusing on codebreaking or mathematics, I wanted to honor the human side of Alan Turing's story.

The letter is written for anyone who has ever felt different, thought differently, or seen the world from a different perspective. It is a reminder that some of the qualities that make us feel out of place are often the same qualities that allow us to contribute something meaningful.

The letter ends with a note acknowledging Alan Turing and the curiosity that changed the world.

Why Letters?

While designing this game, I kept asking myself a simple question: if the June Solstice is a turning point between today and tomorrow, what is the most human way to represent that?

I kept coming back to letters.

A letter exists in a strange space between the present and the future. When someone writes one, they are capturing a version of themselves that exists only in that moment. Their fears, hopes, questions, memories, and unfinished thoughts are placed on a page and sent forward to a person they have not become yet.

That felt deeply connected to the spirit of the solstice.

The longest day of the year is a reminder that time never stands still. The sunlight eventually fades. Seasons change. People change. We cannot hold on to a moment forever, but we can decide what we want to carry with us when it ends.

That is why every story in the game takes the form of a letter.

The baker is not simply remembering the day he opened his shop. He is trying to remind his future self why he started. The musician is not simply talking about fear. She is leaving herself a note for the next time doubt appears. Every person in the game is reaching across time and speaking to the person they hope to become.

In a way, that is exactly what the player is doing too.

By the end of the game, the final empty envelope is not another puzzle to solve. It is an invitation. After spending time helping other people find the words they want to carry into tomorrow, the player is given a chance to decide what they want to carry forward themselves.

That is why Letters to Tomorrow could only be told through letters.

A Piece of My Story

One of the letters in the game is based directly on a real experience from my own life.

After moving to the United States, I was struggling to carry heavy luggage up several flights of stairs when a stranger noticed and helped me without being asked. Not long afterward, one of my professors handed me her umbrella during a rainstorm and told me to keep it. When I tried to return it, she smiled and said, "No, you need it."

Neither of those moments lasted very long.

Neither of those people probably remember them now.

But I do.

What stayed with me was not the luggage or the umbrella. It was the feeling of being cared for in a place that was still unfamiliar to me. Those moments made the world feel a little less intimidating. They made me more willing to ask for help when I needed it and more willing to offer help when I saw someone struggling.

That experience became the inspiration for Hema's letter in the game.

I included it because I wanted at least one letter to come directly from my own life. It serves as a reminder that some of the things we carry into tomorrow are not major life events. Sometimes they are simply moments when someone chose kindness.

A Small Step Outside My Comfort Zone

There is one more thing I wanted to share.

The demo video for this project is narrated by me.

That may not sound like a big deal, but it was a meaningful step for me. I am usually much more comfortable expressing myself through writing than through recordings, and knowing that a video could be seen by many people made me hesitate more than once while working on this submission.

If you watch the demo, you will probably notice a few moments where I stumble over words, speak a little too quickly, or sound nervous. I tried my best to smooth those moments out during editing, but some of them are still there.

For a while, I considered using a generated voice instead. In the end, I chose not to. Letters to Tomorrow is a game about ordinary people sharing honest pieces of themselves, and I wanted the introduction to feel personal too.

So I left the imperfections in and shared it anyway.

I am still learning how to become more comfortable with speaking, recording videos, and putting my work out into the world. This project was a small step in that direction.

If you have any tips on narration, presentation, or creating better demo videos, I would genuinely appreciate the feedback. It is an area I am actively trying to improve, and every project teaches me something new.

Final Thoughts

Thank you for taking the time to read about Letters to Tomorrow.

I hope some of these letters feel familiar. If one of them stayed with you after you finished playing, I would genuinely love to know which one and why.

And if there is a letter you think belongs in this town but has not been written yet, I would love to hear that too. Some of the best stories begin as conversations.

I am also always interested in ideas for making the experience better. If there is a feature that would make the game more accessible, a question that should be added to the FAQ, or something that felt unclear while playing, please let me know.

If you would like to revisit the game, you can always return to the Sunset Post Office here:

👉 Play Letters to Tomorrow

Most of all, thank you for spending a little time with these stories.

Dev Opportunity Radar #3: Neo Scholars, a $2M AI Challenge, and an $85K AI Fellowship

Hemapriya Kanagala — Fri, 12 Jun 2026 13:47:44 +0000

TL;DR

Welcome back to Dev Opportunity Radar.

This is a weekly series where I share opportunities, resources, communities, and interesting finds that I come across, with the goal of helping people discover things they might otherwise miss.

This week's edition includes a student-focused founder program, a $2 million AI business challenge, a free Google AI agents course, a Web3 learning resource, and two community finds shared by community members.

If you've come across an opportunity, resource, community, program, or event that deserves more attention, feel free to share it in the comments.

If I feature it in a future edition, I'll make sure to credit you. If you discovered it, that recognition belongs to you.

Quick Scan
Still Open From Previous Editions
Radar Follow-Up
This Week's Opportunities
- Neo Scholars
- Gemini × XPRIZE AI Business Challenge
Bonus Opportunity
- 5-Day AI Agents Intensive Course with Google
Resources Worth Checking Out
- LearnWeb3
Community Finds
- AI Tinkerers
- Claude Corps
- Hacking for Good
Until Next Friday

⚡ Quick Scan

Opportunities

Opportunity	Organization	Type	Deadline
Neo Scholars	Neo	Founder & Career Program	June 14
Gemini × XPRIZE AI Business Challenge	Google & XPRIZE	AI Business Challenge	Aug 18
5-Day AI Agents Intensive Course	Google & Kaggle	Free AI Course	June 15-19

Resource Highlight

Resource	Type
LearnWeb3	Free Web3 learning platform with structured courses and projects

Community Finds

Shared By	Find	Type	Deadline
Julien Avezou (@javz)	AI Tinkerers	AI Builder Community	Ongoing
Phinn Markson (@marsonp)	Claude Corps	AI Fellowship	July 17
Francis (@francistrdev)	Hacking for Good	Global Hack Week	June 18

🔄 Still Open From Previous Editions

A few opportunities from previous editions are still accepting applications.

I've already covered these in detail, so I won't repeat everything here. If any of them catch your attention, check the original edition for the full overview, eligibility details, and application links.

Opportunity	Organization	Type	Deadline	Featured In
FR8	FR8	Builder Residency	Rolling	Edition #2
Interactivity Research Grants	Thinking Machines	Research Grant ($100K)	June 19, 2026	Edition #1

📡 Radar Follow-Up

One of the things I hoped this series would do was help someone discover an opportunity they otherwise wouldn't have come across.

Last week, Daniel Nwaneri (@dannwaneri) shared that he discovered the FR8 residency through the radar and applied the same day.

That genuinely made my week.

Daniel also shared something that summed up what I'm trying to do with this series:

"The series does something most opportunity roundups don't. It actually explains why something is worth your time instead of just listing it."

There are already lots of places that collect links.

My goal is to add enough context that you can quickly decide whether something is actually worth exploring further.

Seeing someone discover an opportunity, take action on it, and then come back to share that experience felt like a reminder that the series is doing what I hoped it would do.

Thank you again, Daniel, for sharing the update and for letting me mention it here.

And Daniel, if you're reading this, wishing you the very best with your application.

📍 This Week's Opportunities

Here are a few opportunities I came across this week that I thought were worth sharing.

📌 Neo Scholars

Who it's for: Undergraduate students who enjoy building things, love computer science, and are interested in startups, entrepreneurship, or ambitious technical projects.

Neo combines mentorship, startup recruiting, founder support, and access to a strong network of builders all within a single program.

Accepted scholars gain access to mentorship, startup opportunities, recruiting support, events, and a community that includes founders and builders from companies like Cursor, Cognition, Chai Discovery, Applied Compute, and more.

One thing I particularly liked is that participants aren't being pushed into a single path. Whether you want to start something, join a startup, explore ideas, or simply meet ambitious people, there seems to be room for all of those outcomes.

There's also an optional Neo Residency program where student teams can receive a $40,000 equity-free grant and spend time building in San Francisco.

Who can apply: Undergraduate students graduating Winter 2026 or later.

Application Deadline: June 14, 2026

🔗 Learn More & Apply

📌 Gemini × XPRIZE AI Business Challenge

Who it's for: Builders, founders, developers, students, and anyone interested in creating an AI-powered business.

Participants aren't just building a prototype.

They're expected to build something that reaches real users, solves a real problem, and generates real revenue.

The challenge focuses on businesses powered by AI agents and built using Google Cloud products.

Projects can be submitted across areas including education and human potential, entrepreneurship and job creation, small business services, financial access, and professional services.

I actually came across this later than I would have liked, but the good news is that there's still plenty of time left.

If you've been thinking about building something meaningful with AI rather than just experimenting with prompts, this might be worth looking into.

Prize Pool: $2,000,000

Grand Prize: $500,000

Deadline: August 18, 2026

🔗 Learn More & Join

🎁 Bonus Opportunity

5-Day AI Agents Intensive Course with Google

Who it's for: Developers, students, builders, and anyone interested in learning how modern AI agents are designed, built, and deployed.

The course goes beyond basic prompting and focuses on practical topics like agent workflows, tool use, memory, evaluation, security, and deployment.

The program is hosted by Kaggle and developed with Google researchers and engineers.

Participants receive daily learning materials, whitepapers, companion podcasts, hands-on codelabs, daily livestreams and AMAs, Discord discussions, and a capstone project.

The capstone project, called Kaggriculture, involves building an autonomous agent that manages a virtual farm and competes against other agents.

I wanted to include this because it's free, happening soon, and seems much more focused on building real agent systems than many introductory AI courses.

Dates: June 15-19, 2026

Capstone Deadline: June 28, 2026

Cost: Free

Bonus: Certificates, badges, and Kaggle swag for top participants.

🔗 Learn More & Register

📚 Resources Worth Checking Out

Not every useful find comes with an application deadline.

Here's one resource worth checking out this week.

LearnWeb3

LearnWeb3 is a free learning platform for developers who want to explore blockchain and Web3 development.

The reason I wanted to include it is because a lot of learning resources assume you already know where to start. LearnWeb3 does a good job of organizing topics into structured learning paths, making it easier to progress from one concept to the next.

The platform covers areas such as Ethereum development, Solidity, smart contracts, blockchain infrastructure, and other Web3 fundamentals through a mix of lessons, projects, and hands-on learning.

Whether you're completely new to Web3 or looking to build a stronger foundation, it's a resource worth bookmarking.

Cost: Free

Community: Discord, study groups, events, and developer support.

🔗 LearnWeb3

🌟 Community Finds

One of my favorite things about this series has been seeing people share opportunities, communities, and resources that others might not have discovered otherwise.

AI Tinkerers

Shared by Julien Avezou (@javz).

AI Tinkerers is a global community for people actively building with AI. They host meetups, demo nights, hackathons, workshops, and technical events across hundreds of cities worldwide.

What I like about it is how focused it is on builders. The community is built around sharing working projects, technical workflows, lessons learned, and real implementation details rather than AI hype or marketing.

Whether you're building with foundation models, agentic workflows, open-source models, or no-code AI tools, the focus is the same: show what you're building, explain how it works, and learn from others doing the same.

If you're someone who learns best by seeing what other builders are creating and sharing your own work, this looks like a community worth exploring.

Who it's for: Developers, engineers, researchers, builders, and people actively shipping AI projects

Cost: Free to join (event availability varies by city)

🔗 AI Tinkerers

Claude Corps

Shared by Phinn Markson (@marsonp).

Claude Corps is a new fellowship from Anthropic, CodePath, and Social Finance that places early-career fellows inside mission-driven nonprofits across the United States for a full year.

Rather than learning AI in a classroom, fellows work directly with organizations tackling challenges in areas like education, public health, workforce development, housing, food security, civic services, and more.

There is no degree requirement and no formal coding background is required. The program is looking for people who are already comfortable using AI tools, learn quickly, communicate well, and care about making an impact.

Fellows receive training, mentorship, relocation support if needed, and spend a year helping organizations put AI to work on real problems.

Compensation: $85,000 salary + benefits

Eligibility: 18+, authorized to work in the United States, and less than 2 years of full-time work experience

Application Deadline: July 17, 2026

🔗 Claude Corps

Hacking for Good

Shared by Francis (@francistrdev).

MLH's Global Hack Week is running a special Hacking for Good edition from June 12–18.

Global Hack Week is a week-long online event where participants complete challenges, attend live sessions, learn new technologies, and build projects alongside a global community of developers.

This particular edition is focused on using technology to create projects that have a positive impact.

One reason I wanted to include it is that Global Hack Week tends to be much more approachable than a traditional hackathon. You don't need a team, prior hackathon experience, or even a strong technical background to participate.

Whether you're looking to learn something new, build a small project, or simply meet other developers, it's a good opportunity to get involved.

Dates: June 12-18, 2026

Cost: Free

Who can participate: Anyone, anywhere

🔗 Hacking for Good

Thank you to Julien, Phinn, and Francis for sharing these.

I'd love for this section to keep growing.

If you've come across an opportunity, fellowship, grant, hackathon, conference, community, resource, or anything else you think more people should know about, feel free to share it in the comments.

If I feature it in a future edition, I'll make sure to credit you. If you discovered it, that recognition belongs to you.

One small request: If you're sharing an opportunity, please avoid posting raw URLs directly in the comments. DEV sometimes filters them before I get a chance to see them.

A short description alongside the link makes it much easier for me to review and potentially feature it in a future edition.

👋 Until Next Friday

Before I go, I just want to say thank you.

A few weeks ago, this was just an experiment.

Now people are discovering opportunities through the radar, applying to them, and sharing opportunities, resources, and communities back with the rest of us.

This week alone, the Community Finds section exists because Julien, Phinn, and Francis took the time to share something they thought others might benefit from.

I hope that continues.

The goal of this series hasn't changed:

Help people discover opportunities they otherwise might have missed.

My hope is that this slowly becomes our radar, not just mine.

So if you come across an opportunity, fellowship, grant, hackathon, conference, community, resource, or anything else you think more people should know about, feel free to share it in the comments.

And as always, if I feature it in a future edition, I'll make sure to credit you. If you discovered it, that recognition belongs to you.

If you end up applying to any of the opportunities featured here, I'd love to hear about it.

Thank you for reading, thank you for sharing, and thank you for being part of this.

If you'd like to catch future editions, consider following me on DEV and bookmarking the series.

I'll be back next Friday with more opportunities, resources, and community finds.

See you next Friday 👋

The Most Valuable Thing I Found in Tech Wasn't an Opportunity

Hemapriya Kanagala — Tue, 09 Jun 2026 14:52:40 +0000

TL;DR

As an international student in the United States, I joined tech communities hoping to find internships, mentors, resources, and opportunities.

I found all of those things.

But I also found something I wasn't looking for: belonging.

From Rewriting the Code, Mentor Me Collective, CodePath, Girls Who Code events, Boba Talks, SheFi, local meetups, and later DEV Community, these spaces became much more than professional networks. They became places where I learned, grew, found support, and met people who continue to be part of my life even after moving back to India.

This article is about how communities shaped my journey, why I believe nobody builds a career alone, and why finding your people may be just as important as finding your next opportunity.

Why I Joined Tech Communities
The Loneliness Nobody Talks About
More Than Networking
The Hidden Value of Community
Leaving Didn't End It
From Reading to Participating
The Best Decision I Made
I'd Love to Hear Your Story

Why I Joined Tech Communities

Some of the opportunities that changed my life came from communities.

But years later, those opportunities aren't what I remember most.

When I first joined tech communities, I had a practical goal: I wanted opportunities. Like many students and early-career professionals, I was looking for internships, mentors, advice, and ways to grow. Everyone told me networking was important, so I started showing up. I attended events, introduced myself to people, joined programs, and tried to learn from those who were further along in their journeys.

During my time in the United States, I became involved with communities like Rewriting the Code, Mentor Me Collective, CodePath, Girls Who Code events, Boba Talks, SheFi, local tech meetups, and various online groups.

At first, I treated them like resources. They were places where I could learn something new, discover opportunities, and hopefully move one step closer to my goals.

What I didn't realize was that they would eventually become something much bigger.

The Loneliness Nobody Talks About

Moving away from home teaches you things that no career advice article prepares you for.

You can be surrounded by people and still feel alone. You can be busy every day and still miss home. You can be doing everything "right" and still feel disconnected.

As an international student in the United States, there were moments when I missed home intensely. Not just the place itself, but the feeling, the familiarity, and the sense that you belonged somewhere without having to explain yourself.

What surprised me was that I started finding pieces of that feeling inside tech communities.

It wasn't because everyone had the same story. They didn't. But many people understood what it felt like to be figuring things out.

We were navigating uncertainty, trying new things, building careers, and learning who we wanted to become. The details were different for each of us, but the feeling was familiar.

For the first time, I realized that community wasn't only about professional growth. Sometimes it was simply about knowing that other people understood the challenges you were facing.

More Than Networking

The funny thing is that networking was never the part I remember most.

What stayed with me were the people: the mentor who took time to answer questions when they didn't have to, the community members who celebrated small wins, the conversations after events, the encouragement during difficult moments, and the people who remembered my name months later.

Nobody puts those things on a resume, yet they matter enormously.

When people talk about communities, they often focus on outcomes such as internships, jobs, referrals, and opportunities. Those things absolutely matter, and many communities helped me find them.

But they aren't the whole story.

The people behind those opportunities are what make communities special.

Looking back, the opportunities opened doors. The relationships made me want to keep walking through them.

The Hidden Value of Community

People often talk about communities in terms of what they can help you achieve.

And yes, communities can help you find internships, jobs, mentors, collaborators, and friends.

But I think the most valuable thing they offer is something harder to measure.

Perspective.

When you're struggling alone, every problem feels unique. Every setback feels personal. Every uncertainty feels like something only you are experiencing.

Inside a community, you begin to realize that's rarely true.

Someone else struggled with imposter syndrome, someone else felt lost, someone else changed careers, and someone else kept going anyway despite doubting themselves.

There is comfort in realizing you're not the only person trying to figure things out.

Sometimes the biggest gift a community gives you isn't an opportunity.

It's the reminder that you're not alone.

Leaving Didn't End It

Today, I'm back in India, yet some of the people who encouraged me when I was thousands of miles away from home are still part of my life. Many of the people I met during my journey in the United States now live in different cities, states, and even countries, but the connections remain. We still talk, celebrate each other's successes, share opportunities, and support one another despite the distance.

That's when I realized something important: a real community isn't defined by geography. It's defined by people.

The relationships didn't disappear when I boarded a flight. The support didn't stop when I changed time zones. If anything, those connections taught me that communities aren't simply places you go.

They're people you carry with you.

From Reading to Participating

After returning to India, I found another community through DEV.

For a long time, I was mostly a quiet observer. I read far more than I wrote. I'd browse articles, learn from discussions, and admire the people who seemed confident enough to share their thoughts publicly.

To be honest, I was intimidated. I worried that I didn't have enough experience, that my thoughts weren't interesting enough, or that I'd say something wrong. So I stayed on the sidelines for a while.

And I don't think there's anything wrong with that.

Not everyone participates in a community the same way. Sometimes showing up and reading is enough. Sometimes learning quietly is enough. Even today, I value silent readers because I've been one myself.

But over time, I started leaving comments. Then I started sharing thoughts. Then I started writing. Little by little, the community started feeling less like a place I visited and more like a place where I belonged.

As I became more involved, I started thinking about what I could contribute back. One thing kept coming back to me: throughout my own journey, I had missed opportunities simply because I found out about them too late. Sometimes I discovered internships after applications had already closed. Sometimes I heard about programs months after they happened. Sometimes I learned about scholarships only because someone happened to mention them in passing.

The opportunity itself was rarely the problem.

Access to information was.

Looking back, many of the opportunities that shaped my journey came from communities. A mentor forwarded an application. Someone shared a scholarship. Someone else posted a fellowship deadline at exactly the right moment. Those experiences made me realize that opportunities are often available, but they don't help much if people never hear about them.

That realization eventually became Dev Opportunity Radar, a series where I share internships, fellowships, scholarships, programs, and other opportunities that might help someone else on their journey.

When I published the first edition, I wasn't sure if anyone would find it useful. I just knew that if it helped even one person avoid missing an opportunity the way I had, it would be worth it.

Then something small happened that meant a lot to me. In the second edition, a community member submitted a Community Find that I was able to include. Another person reached out to tell me they had discovered and applied for an opportunity through the Radar.

Objectively, those are small moments. But to me, they meant everything because they showed that the series wasn't just a list of links anymore. It had actually helped someone.

That single message became all the motivation I needed to keep working on Edition 3. More importantly, it reminded me that community isn't always built through big gestures. Sometimes it's built one comment, one contribution, and one shared opportunity at a time.

The opportunities matter, but what stays with me most is something else entirely: a group of people who didn't have to help each other choosing to do so anyway.

In a world that can often feel disconnected, that's something I don't take for granted.

The Best Decision I Made

I've spent years learning programming languages, frameworks, libraries, and tools.

Some of them are no longer popular. Some have changed dramatically since I first learned them. Others have disappeared entirely.

The communities stayed.

Looking back, the best decision I made wasn't choosing a particular technology stack or learning a specific framework. It was deciding to show up. It was attending events even when I felt nervous, asking questions when I thought they might be obvious, volunteering when I wasn't sure I had enough experience, and slowly becoming part of something larger than myself.

When I first joined communities, I was looking for opportunities. I hoped to find internships, scholarships, fellowships, mentors, and career advice.

And I did.

But what I found was something even more valuable: belonging.

Years later, I don't remember every workshop I attended, every presentation I watched, or every event I signed up for. What I remember is how people made me feel. I remember feeling welcomed when I was new. I remember feeling encouraged when I doubted myself. I remember feeling supported during difficult moments and reminded that I wasn't figuring everything out alone.

Many of those relationships still exist today. Even after moving back to India, I stay connected with people I met through these communities. They're people I continue learning from, people whose successes I celebrate, and people who continue to inspire me through different stages of life and career.

Maybe that's the real value of community.

It's not just that it opens doors for us.

It's that, eventually, it gives us the chance to hold a door open for someone else.

If there's one thing I would tell anyone early in their journey, it's this:

Don't just learn technologies. Find your people.

Technologies change. Frameworks change. Job titles change. Sometimes even countries change.

But the people who believe in you, encourage you, and help you grow can stay with you for years.

That's what communities gave me.

And years later, across different countries, different chapters of life, and different stages of my career, joining them remains one of the best decisions I've ever made.

I'd Love to Hear Your Story

What community has shaped your journey?

Was it a meetup, an online forum, an open-source project, a nonprofit, a Discord server, or something else entirely?

I'd love to hear about the people and places that helped you find your place in tech.

🤝 Let's Stay Connected

If you'd like to connect, share opportunities, or continue the conversation, feel free to reach out.

Dev Opportunity Radar #2: A Fully-Funded Residency in Finland, AI Research Program, and a $60K Hackathon

Hemapriya Kanagala — Fri, 05 Jun 2026 14:58:21 +0000

TL;DR

Welcome back to Dev Opportunity Radar.

This is a weekly series where I share opportunities, resources, and interesting finds that I come across, with the goal of helping people discover things they might otherwise miss.

The response to the first edition was far more encouraging than I expected. Thank you to everyone who read, commented, shared feedback, and followed along.

This week's edition includes a fully-funded builder residency in Finland, an open science research program, a $60,000 hackathon, a bonus learning event, and a hands-on course for building production-ready LLM applications.

If you've come across an opportunity, resource, community, program, or event that deserves more attention, feel free to share it in the comments.

If I feature it in a future edition, I'll make sure to credit you. If you discovered it, that recognition belongs to you.

Hopefully this becomes less of my radar and more of our radar over time.

⚡ Quick Scan
🔄 Still Open From Last Week
📍 This Week's Opportunities
- 📌 FR8
- 📌 Summer of Open AI Research (SOAR)
- 📌 Google Cloud Rapid Agent Hackathon
⚡ Quick Update
- AAIF Ambassador Program
🎁 Bonus Opportunity
- Microsoft AI Skills Fest
📚 Resources Worth Checking Out
- LLM Zoomcamp
🌟 Community Finds
👋 Until Next Friday

⚡ Quick Scan

Opportunity	Organization	Type	Deadline
FR8	FR8	Builder Residency	Rolling
Summer of Open AI Research (SOAR)	EleutherAI	Research Program	June 8
Google Cloud Rapid Agent Hackathon	Google Cloud	Hackathon ($60K Prize Pool)	June 12
Microsoft AI Skills Fest	Microsoft	AI Learning Event	June 8-12
AAIF Ambassador Program	AAIF	Ambassador Program	June 12

Resource Highlight: LLM Zoomcamp - a free, hands-on course covering RAG, vector search, and AI agents, with a live cohort starting June 8, graded assignments, a capstone project, and a certificate for eligible participants.

🔄 Still Open From Last Week

One opportunity from last week's radar is still accepting applications.

Interactivity Research Grants by Thinking Machines remain open until June 19, 2026.

I'm mentioning it because some people may be discovering this series for the first time through this edition, and I'd rather point you to a still-open opportunity than assume you've already seen it.

I also don't want a good opportunity to disappear from the radar just because a new edition came out.

The program offers up to $100,000 in funding plus $25,000 in Tinker credits for research focused on human-AI interaction and collaboration.

🔗 Learn More | How to Apply

📍 This Week's Opportunities

Here are a few opportunities I came across this week that I thought were worth sharing.

📌 FR8

Who it's for: Builders, researchers, founders, and technically curious people who want to spend a few months working intensely on ambitious ideas.

What stands out: Accommodation, food, flights, tools, and community are fully covered. Participants spend three months immersed in a highly focused environment alongside other builders from around the world.

Format: In-person residency program in Helsinki, Finland.

Funding: Participation is free. FR8 also offers optional funding of $100,000 on an uncapped SAFE plus 2% equity.

I thought this one was particularly interesting because it feels less like a traditional accelerator and more like an environment designed for people who want to go all-in on an idea. You don't need a startup or even a fully formed idea to apply.

Location: Helsinki, Finland

Next Cohort: August 24 - November 21, 2026

Applications: Rolling admissions

🔗 Learn More | Apply

📌 Summer of Open AI Research (SOAR)

Who it's for: Developers, students, and aspiring researchers interested in AI research, including people with little or no previous research experience.

What stands out: Participants work on real research projects under the mentorship of experienced researchers and receive credit for their contributions, which may result in publication.

Format: Five-week fully remote research mentorship program organized by EleutherAI.

Research areas: Interpretability, AI safety, reasoning, representation learning, alignment, AI for science, information retrieval, computer vision, and generative modeling.

I liked this one because many research opportunities expect applicants to already have research experience. SOAR explicitly encourages applications from self-taught researchers and people looking to gain their first research experience.

Location: Online

Deadline: June 8, 2026

🔗 Learn More | Apply

📌 Google Cloud Rapid Agent Hackathon

Who it's for: Developers, builders, students, and AI enthusiasts interested in building real-world AI agents.

What stands out: Participants build task-oriented agents powered by Gemini and Google Cloud Agent Builder while competing for a share of $60,000 in prizes.

Focus: Building agents that can reason, plan, and take actions rather than simply answer questions.

Partner Tracks: Arize, Elastic, Fivetran, GitLab, MongoDB, and Dynatrace.

I thought this one was worth sharing because it focuses on agentic systems rather than traditional chatbot projects. If you've been looking for an excuse to experiment with MCP, agent workflows, or Gemini-powered applications, this could be a good opportunity to build something interesting.

Location: Online

Deadline: June 12, 2026

Prize Pool: $60,000

🔗 Learn More & Register

⚡ Quick Update

I came across this after publishing the original version of this edition, but applications are still open, so I thought it was worth adding here.

AAIF Ambassador Program

Who it's for: Developers, content creators, educators, community builders, and practitioners interested in agentic AI.

What stands out: Ambassadors help create tutorials, talks, videos, workshops, blog posts, and other educational content around projects supported by the Agentic AI Infrastructure Foundation (AAIF), including MCP, Goose, and AGENTS.md.

The commitment is one public contribution each month that helps more developers understand, use, or contribute to an AAIF project.

In return, ambassadors receive community recognition, access to project maintainers, private community channels, event perks, and opportunities to help grow awareness around emerging agentic AI projects.

I thought this was worth sharing because many programs focus on building products, while this one is also looking for people who enjoy teaching, explaining, documenting, and helping communities learn.

Applications for the initial cohort: Open through June 12, 2026.

🔗 Learn More & Apply

🎁 Bonus Opportunity

Microsoft AI Skills Fest

Who it's for: Developers, students, business professionals, technical teams, and anyone looking to build practical AI skills.

What stands out: Complete learning paths, attend live sessions, participate in the Agents League Hackathon, earn badges, and potentially qualify for a free Microsoft Certification exam voucher.

Format: Free week-long virtual event featuring role-based learning tracks, expert-led sessions, and hands-on AI activities.

I thought this was worth mentioning because it combines learning, certification preparation, and hands-on building in a single event. Whether you're interested in AI-assisted coding, building agents, using AI at work, or preparing for a certification exam, there's a dedicated path for different experience levels.

Dates: June 8-12, 2026

Bonus perks: Credly badges, certification exam vouchers (for eligible participants), hackathon participation, and prize opportunities.

🔗 Learn More & Register

📚 Resources Worth Checking Out

Not every useful find comes with an application deadline.

Here's one resource worth checking out this week.

LLM Zoomcamp

Who it's for: Developers, data engineers, ML practitioners, and anyone interested in building practical LLM applications.

What stands out: The course focuses on building real applications rather than just learning concepts. Participants work through topics like RAG, vector search, AI agents, evaluation, monitoring, and orchestration, then build a capstone project of their own.

Topics covered: Retrieval-Augmented Generation (RAG), embeddings, vector search, AI agents, function calling, hybrid search, reranking, evaluation, monitoring, and end-to-end LLM application development.

I wanted to include this because a lot of AI learning resources stop at prompting. This one focuses on building complete systems and gives you the chance to apply everything through a final project.

If you join the live cohort, you'll also get graded homework, a leaderboard, peer reviews, and the opportunity to earn a certificate by completing the project and review requirements. If you don't want the deadlines, all of the material is available in a self-paced format as well.

Format: Free, open-source course with both live cohort and self-paced options.

Live Cohort: Starts June 8, 2026 (graded assignments, leaderboard, peer reviews, and certificate eligibility)

Cost: Free (aside from small API usage costs if you run the examples yourself)

🔗 Course Repository | Register

🌟 Community Finds

No community finds this week.

The first edition was only published recently, so that's completely understandable.

That said, if you shared something and I didn't hear back from you, there's a chance I never saw it. From what I've learned, DEV sometimes filters comments that contain raw URLs before I get a chance to view them.

If that's what happened, I'm sorry.

I'd still love for this section to become a regular part of the series.

If you've come across an opportunity, fellowship, grant, hackathon, conference, community, or resource that more developers should know about, feel free to share it in the comments.

If I feature it in a future edition, I'll make sure to credit you. If you discovered it, that recognition belongs to you.

Small note: If you're sharing an opportunity, please avoid posting raw URLs directly in the comments. DEV sometimes filters them before I get a chance to see them.

Instead, use the opportunity name as the link and add a short description of what it is and who it's for.

For example:

[Opportunity Name](https://example.com)

Short description of what it is and who it's for.

This helps make sure I actually see your suggestion.

👋 Until Next Friday

Thank you again to everyone who read, commented, shared feedback, and followed along after the first edition. It genuinely means a lot.

The goal of this series hasn't changed:

Help people discover opportunities they otherwise might have missed.

I'll keep doing my best to make these weekly editions useful and worth reading.

If you end up applying to any of the opportunities featured here, I'd love to hear about it.

And if there's a particular opportunity or resource that stood out to you, let me know. It helps me understand what kinds of things are most useful to include in future editions.

I'd also love feedback on the format as the series grows.

What's working?

What isn't?

What would make future editions more useful?

Got an opportunity, grant, fellowship, hackathon, conference, resource, or community worth sharing?

Drop it in the comments.

If you'd like to catch future editions, consider following me on DEV and bookmarking the series.

I'll be back next Friday with more opportunities, resources, and community finds.

See you next Friday 👋

Dev Opportunity Radar #1: A $100K AI Grant, Two Fellowships, and an AI Agent Resource

Hemapriya Kanagala — Fri, 29 May 2026 14:19:10 +0000

TL;DR

I've missed a lot of opportunities simply because I didn't know they existed.

So every Friday, I'll share opportunities, programs, events, resources, and other interesting finds that I come across.

I know I'll miss things, so if you discover something worth sharing, drop it in the comments.

If I feature your find in a future edition, I'll make sure to credit you. If you discovered it, the recognition belongs to you.

Hopefully this becomes less of my radar and more of our radar over time.

This week's edition includes a contributor-focused fellowship, a $100,000 AI research grant, a founder fellowship, and a resource for people interested in building AI agents.

⚡ Quick Scan
📍 This Week's Opportunities
- Flow Fellowship
- Interactivity Research Grants by Thinking Machines
- Commit Fellowship
📚 Resources Worth Checking Out
- Hands-on AI Agents
🧭 Why I'm Starting This
🤝 Let's Build This Together
🌟 Community Finds
👋 Until Next Friday

⚡ Quick Scan

Opportunity	Organization	Type	Deadline
Flow Fellowship	Flow Research	Fellowship	May 31
Interactivity Research Grants	Thinking Machines	Research Grant ($100K)	June 19, 2026
Commit Fellowship	MLH & Transcend Network	Founder Fellowship	May 31

Resource Highlight: Hands-on AI Agents - a free book and code repository for learning modern AI agent frameworks.

📍 This Week's Opportunities

Here are a few opportunities I came across this week that I thought were worth sharing.

📌 Flow Fellowship

Who it's for: People interested in contributing to projects across AI, product, research, systems, content, and media.

What stands out: Unlike many programs that focus primarily on learning, this fellowship focuses on contributing to real projects and shipping public work.

Format: 12-week cohort with mentorship and project contributions.

Location: Global

Deadline: May 31

🔗 Learn More | Apply

📌 Interactivity Research Grants by Thinking Machines

Who it's for: Researchers exploring human-AI interaction and collaboration.

What stands out: Up to $100,000 in funding plus $25,000 in Tinker credits for projects focused on improving how humans and AI work together.

Areas of interest: Multimodal interaction, generative UI, AI safety for real-time systems, and human steering of long-running AI agents.

This was one of the most interesting opportunities I came across this week because it focuses on making AI systems better collaborators, not just more autonomous.

Location: Global

Deadline: June 19, 2026

🔗 Learn More | How to Apply

📌 Commit Fellowship

Who it's for: People curious about entrepreneurship who haven't yet started building a company.

What stands out: No startup idea, team, or previous founder experience required.

Format: Three-week fellowship from MLH and Transcend Network.

I liked this one because it's aimed at people who are still figuring things out. Many startup programs assume you're already building something. This one is designed for people who are much earlier in the journey.

Location: United States, Canada, Mexico

Deadline: May 31

🔗 Learn More & Apply

📚 Resources Worth Checking Out

Not every useful find comes with an application deadline.

Here's one resource worth checking out this week.

Hands-on AI Agents

Who it's for: Developers, AI engineers, and anyone interested in building AI agents.

What stands out: The book appears to build a single evolving system across chapters instead of jumping between unrelated examples.

Topics covered: LangGraph, CrewAI, MCP, agent handoffs, memory, observability, multimodal agents, and multi-agent systems.

Antonio Gulli, Distinguished Engineer at Google, is currently working on Hands-on AI Agents and publicly sharing the accompanying code and materials as the project evolves.

I'm sharing this because it covers many of the concepts that keep showing up in AI agent discussions right now while providing practical examples and implementations.

Status: Ongoing / actively being developed

🔗 Documentation | Repository

🧭 Why I'm Starting This

Over the past few years, I've realized I've probably missed a lot of opportunities simply because I never knew they existed.

Not because I wasn't interested.

Not because I wasn't qualified.

I just never came across them in time.

Fellowships. Hackathons. Grants. Communities. Resources.

Sometimes I discover these opportunities months after applications close, and my first thought is always:

"I wish I had known about this earlier."

So I started thinking:

If I happen to find something useful, why not share it?

Maybe it's an opportunity that helps someone get involved in open source.

Maybe it's a fellowship that introduces them to an incredible community.

Maybe it's the thing that opens a door they didn't even know existed.

That's what this series is.

Every Friday (IST), I'll share opportunities, programs, events, resources, and interesting finds I come across during the week.

Some weeks there might be three things.

Other weeks there might be ten.

The goal isn't quantity.

The goal is helping people discover opportunities they otherwise might have missed.

If even one opportunity helps someone learn, build, contribute, or connect with the right people, I'll consider this series a success.

🤝 Let's Build This Together

I know I'll miss things.

Opportunities are everywhere.

They're spread across communities, newsletters, Discord servers, social media posts, blog articles, company announcements, and places most of us don't check regularly.

That's why I'd love for this to become something we build together.

If you know about:

an ambassador program
a fellowship
a hackathon
a conference
a meetup
an open-source initiative
a grant
a learning resource
or anything else developers should know about

drop it in the comments.

If I feature it in a future edition, I'll make sure to credit you.

If you found it, that recognition belongs to you.

The goal isn't for this to become my radar.

The goal is for it to become our radar.

🌟 Community Finds

This section is empty for now.

Hopefully it won't stay that way for long.

My hope is that future editions don't just include things I happen to come across, but also opportunities, resources, and events discovered by people in this community.

Maybe next week one of the opportunities featured here comes from you.

There's a lot happening in tech, and no single person can keep up with everything.

That's one of the reasons I'm excited to see where this series goes.

What opportunities, resources, or communities have you come across recently?

Small note: If you're sharing an opportunity, please avoid posting raw URLs directly in the comments. DEV sometimes filters them before I get a chance to see them.

Instead, use the opportunity name as the link and add a short description of what it is and who it's for.

For example:

[Opportunity Name](https://example.com) + a short description.

This helps make sure I actually see your suggestion.

👋 Until Next Friday

This is the first edition, so we'll see where it goes.

My hope is simple:

If this series helps even one person discover an opportunity they would've otherwise missed, it'll be worth writing.

And if enough people contribute their own finds, maybe we can build something genuinely useful for the developer community.

Since this is the first edition, I'd also love feedback on the format.

What's working?

What isn't?

What would make future editions more useful?

Got an opportunity, grant, fellowship, hackathon, conference, resource, or community worth sharing?

Drop it in the comments.

If you'd like to catch future editions, consider following me on DEV and bookmarking this series.

I'll be back next Friday with more opportunities, resources, and community finds.

See you next Friday 👋

Hermes Agent Changed How I Think About Execution Boundaries

Hemapriya Kanagala — Tue, 26 May 2026 14:55:54 +0000

This is a submission for the Hermes Agent Challenge: Write About Hermes Agent

TL;DR

Traditional automation assumes software execution is predictable.

Agentic systems behave differently. They require runtime boundaries, verification loops, and continuous steering.

After going through Hermes Agent’s architecture, I realized the future of automation may be less about scripting workflows and more about designing safe environments for autonomous systems to operate reliably.

Estimated read time: ~8 minutes

Traditional Automation Assumes Deterministic Execution
Agentic Systems Behave Differently
Runtime Pressure Instead of Static Timeouts
Why Execution Boundaries Matter
The Security Shift: From Permissions to Operational Constraints
Why Verification Loops Matter
Context Is Becoming an Event System
The Rise of Asynchronous Agent Workflows
Local Models Change Infrastructure Assumptions
What This Means for Developers
Final Thoughts
References
🤝 Stay in Touch

Traditional Automation Assumes Deterministic Execution

Most software systems assume execution is predictable.

A script runs.

A workflow retries.

An exception crashes the process.

A timeout stops runaway execution.

Even large distributed systems still operate within deterministic boundaries. Engineers define exact execution paths and the infrastructure enforces them.

That mental model starts to break once autonomous agents enter the picture.

After spending time exploring Hermes Agent, I realized something important:

Agentic systems are not just “smarter automation.”

They behave less like fixed workflows and more like systems that make decisions dynamically while operating inside predefined limits.

That shifts what developers need to design.

Agentic Systems Behave Differently

Traditional automation follows predefined steps.

An agentic system works differently.

Instead of manually scripting every action ahead of time, developers give the system:

tools
instructions
boundaries
goals

The agent then decides how to move through the task on its own.

That distinction matters.

Instead of scripting every action, developers define:

what tools the agent can access
how long it can operate
what boundaries it cannot cross
how failures are verified
how runtime behavior is constrained

In this context, “execution boundaries” are the operational limits and safeguards that shape how an autonomous system behaves while it runs.

The system is no longer controlling every step directly.

It is shaping the environment in which reasoning happens.

Hermes Agent exposed this shift more clearly than I expected.

One of the clearest examples is how it handles long-running tasks.

Runtime Pressure Instead of Static Timeouts

Traditional systems often rely on hard timeouts.

If a process exceeds the limit, it gets terminated.

Hermes approaches this differently.

It uses an Iteration Budget system that continuously applies runtime pressure as the agent approaches its execution limit.

Instead of immediately killing execution, Hermes injects hidden warnings directly into tool responses:

{
  "_budget_warning": "[BUDGET WARNING: 81/90. Only 9 left. Respond NOW.]"
}

At first glance, this looks like a small implementation detail.

But architecturally, it represents a completely different philosophy.

The system is not simply enforcing a timeout.

It is actively steering the reasoning process toward graceful completion.

That changes the developer’s role.

Instead of relying entirely on hard stops, developers increasingly design systems that guide autonomous behavior toward safe outcomes while execution is still happening.

Why Execution Boundaries Matter

One idea kept appearing throughout Hermes Agent’s architecture:

The system assumes the reasoning engine is inherently unpredictable.

That assumption changes everything.

Traditional software trusts execution because the developer authored the logic directly.

Agentic systems generate execution dynamically.

That introduces a new challenge:

How do you safely grant autonomy without allowing unrestricted execution?

Hermes addresses this with layered execution boundaries.

One example is its Hardline Blocklist.

Even if a user enables aggressive autonomous execution modes, Hermes still blocks catastrophic operations such as:

destructive filesystem wipes
block-device writes
fork bombs
dangerous shell patterns

This happens below the reasoning layer itself.

The agent may reason freely, but execution still operates inside deterministic constraints.

That separation is important.

The system does not rely entirely on semantic intent or prompt instructions for safety.

Instead, it establishes physical operational boundaries beneath the agent.

I think this is one of the most important architectural shifts happening in modern automation systems.

The Security Shift: From Permissions to Operational Constraints

Traditional security models are usually permission-based.

You grant:

API scopes
database permissions
access roles

That works well when software behavior is predictable.

Agentic systems complicate this because the generated code and execution paths are not fully known in advance.

This increases potential attack surface in several ways:

tool misuse
prompt injection attempts
unsafe shell execution
over-permissioned integrations
accidental destructive operations

Hermes handles this with multiple layers.

One layer evaluates semantic intent before execution.

Another layer enforces deterministic safety rules that cannot be bypassed.

The Model Context Protocol, or MCP, also introduces another important consideration.

MCP allows agents to dynamically interact with external tools and services through a shared protocol interface.

That flexibility is powerful, but it also means developers must think carefully about tool exposure.

Hermes encourages strict tool filtering through allowlists and exclusion policies.

Instead of exposing everything, developers define the minimum viable operational surface area.

I think this mindset becomes increasingly important as autonomous systems become more capable.

The goal is not restricting useful automation.

The goal is creating environments where autonomy operates safely within clearly defined boundaries.

Why Verification Loops Matter

One of the biggest differences between traditional software and agentic systems is that reasoning systems can confidently describe work that never actually completed.

Hermes explicitly defends against this.

It includes a file mutation verifier that audits whether file operations truly succeeded.

If an operation silently fails, Hermes injects corrective feedback back into the conversation state.

In other words, the system independently checks whether the work actually happened instead of trusting the agent’s summary.

In deterministic software, successful execution is usually assumed unless an exception occurs.

In agentic systems, “no exception” is no longer enough.

Systems increasingly need independent verification layers that validate:

filesystem state
command execution
infrastructure mutations
deployment results

Without verification loops, hallucinated success can compound into real operational problems.

This does not mean autonomous systems are unsafe.

It simply means they require a different style of engineering discipline.

Context Is Becoming an Event System

One of the most interesting implementation details inside Hermes Agent is how it handles context loading.

Many systems aggressively load large amounts of information upfront.

The assumption is simple:

More context equals better reasoning.

But large context windows introduce real tradeoffs:

higher latency
larger costs
weaker cache efficiency
slower iteration cycles

Hermes takes a different approach through something called Progressive Disclosure.

Instead of loading every project instruction immediately, Hermes waits until the agent actually navigates into a relevant directory.

Only then does it inject the associated context.

For example, if the agent moves into a backend directory, Hermes can load only the instructions relevant to that part of the project instead of loading the entire codebase upfront.

In practice, filesystem navigation becomes an event trigger for context hydration.

That might sound subtle, but the implications are significant.

The system prompt effectively becomes a computational cache that must remain stable.

The future bottleneck may not be context size itself.

It may be the cost of constantly mutating context.

That shifts how developers think about memory, state management, and long-running execution in AI systems.

The Rise of Asynchronous Agent Workflows

Most people still interact with AI systems through synchronous chat interfaces.

You ask something.

The model responds immediately.

Hermes supports a different pattern through isolated background execution sessions that can continue operating independently and return results later.

That changes the interaction model quite a bit.

Some tasks naturally benefit from longer-running execution:

large codebase changes
infrastructure audits
multi-step research tasks
deployment preparation
complex orchestration workflows

In these situations, constantly waiting inside a live chat interface starts to feel limiting.

Hermes approaches this by allowing execution to continue in the background while preserving the agent’s working state separately.

What I found interesting is how this also changes debugging.

When execution happens inside temporary cloud environments, understanding what actually happened becomes harder once the environment disappears.

Hermes handles this by synchronizing modified artifacts back to the host system before teardown.

That creates a persistent execution trail developers can inspect afterward.

The debugging process becomes less about reading a single stack trace and more about reconstructing the broader execution path the agent followed.

Local Models Change Infrastructure Assumptions

One subtle but important detail inside Hermes Agent is how differently it treats local models compared to cloud APIs.

Most developers assume APIs respond quickly.

Local models break that assumption.

Large local inference workloads may spend significant time processing context before generating a response.

Hermes adapts by dynamically adjusting networking behavior:

extended socket timeouts
relaxed stream assumptions
tolerance for long prefill phases

This might sound operationally minor, but it reveals something deeper:

AI infrastructure increasingly depends on the physical realities of compute hardware.

As self-hosted models become more common, developers may need to rethink:

timeout assumptions
synchronous workflows
networking expectations
infrastructure resilience

The “physics” of local AI systems become part of application architecture.

What This Means for Developers

I do not think agentic systems reduce the importance of developers.

If anything, they increase the importance of thoughtful engineering.

The role simply evolves.

Developers are still responsible for:

defining boundaries
designing infrastructure
constraining execution
validating outcomes
building reliable systems
protecting operational surfaces

What changes is the layer of abstraction.

Instead of scripting every deterministic workflow manually, developers increasingly shape the environments where autonomous reasoning operates safely.

That requires:

systems thinking
operational discipline
security awareness
infrastructure design
runtime governance

And that is what made Hermes Agent so interesting to explore.

It does not just automate tasks.

It exposes the deeper architectural questions that emerge once reasoning systems become active participants inside software infrastructure.

Final Thoughts

Traditional automation assumes execution is deterministic.

Agentic systems do not.

That difference changes how software systems must be designed.

After exploring Hermes Agent, I came away with one central realization:

The future of automation may not be about defining exact execution steps anymore.

It may be more about designing safe environments where autonomous systems can operate reliably.

And that makes software engineering even more important.

Because autonomous systems still require carefully designed infrastructure, operational safeguards, verification layers, and thoughtful human oversight to work reliably in the real world.

So I’m curious:

What’s one thing you would never let an autonomous agent do completely on its own?

References

While researching and writing this article, these Hermes Agent docs were especially helpful in understanding the system’s architecture, execution model, security patterns, and runtime behavior:

I also explored additional Hermes Agent documentation and Quick Links resources while forming the broader ideas discussed throughout this article:

Hermes Agent Documentation

This included architecture docs, memory systems, skills, tools, MCP usage patterns, learning paths, troubleshooting resources, and best practices.

🤝 Stay in Touch

Place	Find me here
GitHub	building things → hemapriya-kanagala
LinkedIn	resources & updates → hemapriya-kanagala
X	random dev thoughts → @KanagalaHema

And seriously, if something here made sense (or didn’t), drop a comment.

Frameworks Are No Longer Being Designed Only for Humans

Hemapriya Kanagala — Thu, 21 May 2026 13:25:43 +0000

This is a submission for the Google I/O Writing Challenge

TL;DR
After watching the Google I/O 2026 sessions, I started noticing the same pattern across Flutter, Search, Chrome DevTools, and Google's agent workflows.

AI is not only becoming part of applications.

Frameworks, tooling, and even the web itself are slowly starting to evolve around AI systems as active builders too.

Estimated read time: ~8 minutes

I thought this year would be about models
The Flutter update that changed how I looked at the rest of I/O
We used to build interfaces for people
Search is starting to behave more like software generation
The Human Clipboard Problem
Websites are changing too
The tension underneath all of this
What developers may actually need to adapt to
Final thoughts
References
🤝 Stay in Touch

I thought this year would be about models

Every Google I/O eventually returns to the same themes.

Better models.

Faster responses.

More capable AI systems.

So when I started watching the Google I/O 2026 sessions, I expected another version of that story.

And there was plenty of it.

But after watching:

another pattern slowly started showing up underneath everything else.

Not through one major announcement.

Not through one headline feature.

It appeared through smaller architectural decisions spread across different sessions.

At first, none of them seemed connected.

Then the Flutter session started talking about separating Material and Cupertino from the core framework.

After that, I started noticing the same idea everywhere else too.

The Flutter update that changed how I looked at the rest of I/O

On the surface, the Flutter announcements sounded like framework maintenance.

Material and Cupertino becoming separate packages.

A more style-neutral Flutter core.

The GenUI SDK.

The A2UI protocol.

But the more I listened, the less it sounded like ordinary framework work.

Because UI frameworks have always been opinionated by design.

That is their job.

They guide developers toward structure and consistency.

For years, frontend development has mostly followed the same model:

developers design interfaces first

users interact with them later

The screens are already decided.

The flows are already decided.

Even dynamic applications are usually built from predefined layouts assembled by humans.

But many of the announcements at Google I/O 2026 seemed to move in another direction.

Interfaces that adapt:

to context
to conversation
to intent
to environment
to the task happening in that moment

Not fixed screens.

Generated ones.

And that changes something underneath the framework itself.

Because if software is expected to generate interfaces dynamically, frameworks cannot remain tightly structured around predefined human layouts.

They need to become flexible enough for software to assemble software.

That was the moment the rest of I/O started looking different to me.

Most of that realization came from watching What's New in Flutter.

The session spends a good amount of time talking about GenUI, A2UI, and Flutter becoming more style-neutral instead of tightly coupled to predefined design systems.

The more I watched it, the more it sounded less like a normal framework update and more like Flutter preparing for dynamically generated interfaces.

We used to build interfaces for people

What started becoming more obvious across the sessions was how deeply human-centered most software tooling has always been.

Component systems.

Design systems.

Navigation patterns.

Accessibility flows.

Everything was built around how humans:

read
navigate
interpret
scan
and move through interfaces visually

But now there is another participant inside the system.

Agents.

And they interact with software differently.

An AI agent does not care whether a button feels visually balanced on a screen.

It cares about:

structure
interaction points
capabilities
semantic meaning
machine-readable workflows
accessible pathways

That changes what frameworks need to optimize for.

Not replacing humans.

But supporting both humans and agents at the same time.

And I think that may be one of the biggest shifts underneath this year's I/O announcements.

For the first time, frameworks no longer felt entirely human-first.

Google was not only showing how AI could build software.

The more sessions I watched, the more it started feeling like software ecosystems themselves may slowly reorganize as AI systems become active participants inside them.

Search is starting to behave more like software generation

One of the moments I kept returning to from the Google I/O '26 Keynote was watching Search generate interactive software experiences directly inside the results.

Not just summaries.

Not just responses.

Actual usable interfaces.

A planner.

A simulator.

A generated workflow.

The important part was not the interface itself.

It was what produced it.

Traditionally, developers built applications and search engines helped users discover them.

Now the platform itself is beginning to generate software experiences dynamically for specific situations.

Not permanent applications.

Temporary ones.

Software created for the exact moment it is needed.

The examples shown during the Google I/O '26 Keynote are probably the clearest way to understand this direction.

Watching Search generate interactive planners and visual simulators in real time felt very different from traditional search demos.

It felt closer to software being assembled during the interaction itself.

And once software starts behaving like this, the frameworks underneath it have to change too.

The Human Clipboard Problem

Another moment I kept thinking about came from Chrome DevTools for Agents.

Mostly because it addressed a workflow almost every developer using AI tools already knows.

You ask AI to generate code.

Something breaks.

You copy the error.

Paste it back into the assistant.

Wait for another response.

Then repeat the cycle again.

The developer becomes the connection between:

the runtime
the browser
the tooling
and the AI system

But now agents can:

inspect the DOM
run Lighthouse audits
read error logs
attempt fixes
validate changes themselves

That changes the role of the developer too.

Because once AI systems can directly interact with tooling, they stop behaving like passive assistants.

They start participating inside the workflow itself.

This part came from the Developer Keynote (Google I/O '26), especially the Chrome DevTools for Agents demonstrations.

That session introduced one of the most practical shifts from the entire event for me, mostly because it changes how AI interacts with debugging and runtime tooling itself.

Websites are changing too

The same pattern appeared again with WebMCP.

For most of the web's history, websites were designed almost entirely for human interaction.

Humans:

navigate menus
press buttons
read layouts
move through interfaces visually

But WebMCP introduces the idea that websites should expose capabilities directly to agents too.

Not visually.

Structurally.

The Developer Keynote referred to this as improving "Agent Experience."

And the more I thought about it, the more important that phrase started feeling.

Because once software ecosystems begin optimizing for agents too, the internet itself starts becoming something different.

Not only human-readable.

Machine-readable in a much deeper way.

The conversations around WebMCP and "Agent Experience" also came from the Developer Keynote (Google I/O '26).

I found myself returning to that part of the session because it changes how the web itself is expected to behave when agents become part of normal software workflows.

The tension underneath all of this

I do not think any of this means:

designers disappear
frontend developers disappear
or interfaces become unpredictable AI-generated chaos

Actually, one of the most interesting parts across these announcements was the tension between:

flexibility
and consistency

Generated interfaces are powerful because they can adapt dynamically.

But people still rely on:

familiarity
stable navigation
predictable interaction patterns
consistent visual systems

That tension matters.

Because completely unrestricted generated interfaces would become exhausting very quickly.

And Google seemed aware of that throughout the sessions.

The direction did not feel like:
"remove structure completely."

It felt more like:
"allow software to adapt within carefully defined boundaries."

That is a very different idea.

And probably a much more practical one too.

What developers may actually need to adapt to

I do not think the biggest shift here is that AI will generate more code.

That conversation already exists everywhere.

The more interesting shift is that software ecosystems themselves are beginning to evolve around AI participation.

Frameworks are becoming more flexible.

Developer tools are becoming agent-aware.

Web standards are becoming machine-readable.

Interfaces are becoming dynamic.

And developers may slowly spend less time:

manually assembling static screens
wiring repetitive workflows
acting as the bridge between tools and AI systems

And more time:

defining boundaries
designing primitives
shaping behavior
reviewing generated systems
guiding adaptive workflows

That feels like a very different model of software development.

Not fully automated.

But definitely different from the one most of us learned.

Because the biggest change may not be AI replacing software development.

It may be software ecosystems slowly reorganizing themselves around AI participation.

Final thoughts

Going into Google I/O 2026, I expected better AI systems.

What I did not expect was how many sessions were pointing toward the same deeper shift underneath them.

Flutter becoming more style-neutral.

Search generating interfaces dynamically.

Web standards exposing capabilities directly to agents.

Developer tooling evolving around autonomous workflows.

Individually, these announcements seemed unrelated.

But together, they started feeling like pieces of the same transition.

For years, frameworks were designed almost entirely around human developers building interfaces for human users.

Now software ecosystems are beginning to evolve around AI systems too.

And I think future developers may look back at this moment less as:
"the year AI became smarter"

and more as:

"the year software ecosystems started reshaping themselves around AI participation."

References

These sessions helped shape most of the ideas and observations in this article:

I also found these sessions helpful while thinking through the broader direction around AI workflows, tooling, and interface generation:

🤝 Stay in Touch

Place	Find me here
GitHub	building things → hemapriya-kanagala
LinkedIn	resources & updates → hemapriya-kanagala
X	random dev thoughts → @KanagalaHema

And seriously, if something here made sense (or didn’t), drop a comment.

Your Tools Don't Learn You. This One Does.

Hemapriya Kanagala — Tue, 19 May 2026 18:13:56 +0000

This is a submission for the Hermes Agent Challenge

TL;DR
Most AI agents forget everything the moment your session ends. Hermes Agent is built differently, with a learning loop at its core that creates skills from experience, improves them during use, and builds a picture of you over time. The longer you use it, the better it gets at working with you specifically.

Estimated read time: ~8 minutes

Wait, Think About This First
The Goldfish Problem
Okay, What is Hermes Agent?
The Learning Loop, Without Making It Complicated
Is It Just Hermes Agent Doing This?
Oh, and the Skills Are Shareable Too
What This Changes Day to Day
Getting It Running
The Bigger Thing Underneath All Of This
References
🤝 Stay in Touch

Wait, Think About This First

Okay so I want to ask you something before we get into anything.

How long have you been using your code editor?

A year? Three? More?

Now here is the actual question.

Is your editor any better at working with you specifically after all that time?

Does it know how you structure projects? Does it know which patterns you reach for at 11pm when you are tired and just want something to work? Does it know anything at all about you as a person?

No.

It is exactly the same editor it was on day one. You learned it. It did not learn you back.

And the thing is, we have just accepted this. For as long as software has existed, this is how the relationship works. The tool stays the same. You do all the adapting. You learn the shortcuts. You write the snippets. You configure everything. You are the one who changes.

The software never does.

I want to talk about why that might be changing, and why Hermes Agent is one of the more interesting things I have come across in a while.

The Goldfish Problem

Before getting into what Hermes Agent is, I want to describe a thing that happens with almost every AI agent right now.

You open it. You start working. You have a productive session where things all come together and the agent figures out your context and you feel like you are finally getting somewhere.

Session ends.

You come back the next day.

The agent has absolutely no idea who you are.

You explain your project again. Your preferences again. The decision you made last week that the agent helped you reach. All of it, again.

This is what people in the AI field call being "stateless." When the session ends, everything goes away. No memory of what worked. No memory of you. Clean slate every single time.

For quick one-off tasks this is totally fine. You are not asking the agent to know your life story just to explain a concept or summarize a document.

But for ongoing work? For projects you come back to every day? For workflows that are genuinely specific to how you operate?

It gets old fast.

And here is the thing that gets me.

We accept this from AI agents in a way we would never accept it from an actual person.

Imagine hiring a contractor to help renovate your house. They show up day one, learn everything, do great work. Day two, completely different person, never heard of you. Day three, another new one.

You would not keep that contractor.

But somehow with AI agents we just... shrug and re-explain ourselves every single day.

Okay, What is Hermes Agent?

Hermes Agent is an open source AI agent built by Nous Research. If you do not know Nous Research, they are the team behind the Hermes model family and have been in the AI space long enough to have a real track record.

On paper it does what you would expect from a capable agent. Tool use, terminal commands, web browsing, code writing and execution, long complex tasks. You can talk to it through Telegram, Discord, Slack, WhatsApp, and about 20 other platforms. Runs on your own machine.

All of that is fine and good.

But then I noticed this.

Hermes Agent was built around a completely different assumption than most agents.

The assumption is: an agent that runs over time should actually get better over time.

Not because the underlying model gets an update. Better because it is learning from your sessions, building on what it figured out, and accumulating something real the longer you work with it.

That is a different idea. That is the software learning you back.

The Learning Loop, Without Making It Complicated

Hermes Agent calls this a closed learning loop. 4 things happen inside it.

Skills built from experience
When Hermes Agent figures out a good way to handle something specific to your work, it does not just do the thing and move on. It can package that into a reusable skill. An actual callable piece of capability it can reach for again next time.

So the more you use it, the more it has built up around your specific context. Your codebase. Your workflow. The kinds of problems you actually deal with on a Tuesday afternoon.

Skills that improve while being used
This one is the part that sounds a little too good to be true when you first hear it.

When the agent uses a skill and notices something that could work better, it updates the skill during the work. Not after. During.

Think of someone who, while doing a job, improves the way they do the job at the same time. Both happening at once. That is what this is.

The nudge system
Small thing. Actually matters a lot.

Left completely to itself, an agent might figure something useful out in a session and then just not bother storing it anywhere. The moment passes. Gone.

Hermes Agent has a mechanism that actively asks itself: is this worth keeping?

That push toward persistence is the difference between an agent that could remember and one that actually does.

A model of you that builds over time
This one has a name that sounds like a research paper: Honcho dialectic user modeling.

Plain language version: every interaction teaches the agent something about how you specifically work. Your preferences. Your patterns. What you care about and what you do not. How you like things explained.

Over time this becomes an actual picture of you. Not developers in general. Not your job title. You.

And this is different from writing a system prompt where you describe yourself manually. A system prompt is static and only knows what you remembered to tell it. This updates from experience. The agent notices things you never explicitly said.

Is It Just Hermes Agent Doing This?

No, and that part matters.

A few teams are working on agent memory and continuity seriously right now.

MemGPT, now developed under the Letta platform, is specifically built around persistent memory. They have thought carefully about what agents should keep versus let go.

LangGraph from LangChain is working on stateful agent workflows, giving developers control over how context carries between steps.

Anthropic has added memory features to Claude. OpenAI has memory in ChatGPT now too.

So this is not a problem only Hermes Agent noticed. Other people are thinking hard about it.

The difference is that Hermes Agent is fully open source, runs on your own machine, and the learning loop is not something added on top of an existing agent. It is baked into how the agent fundamentally works from the start.

That is a meaningful difference.

Oh, and the Skills Are Shareable Too

One more thing and then I will get to the practical stuff.

Hermes Agent connects to a community skill ecosystem at agentskills.io. Skills are portable and shareable between users.

So when someone in the community figures out a really reliable approach to a complex workflow, they can package it as a skill and share it. You install it and your agent has that capability without needing to figure it out from scratch.

And because skills improve during use, a skill you install can get refined through your own sessions over time and slowly fit your specific context better than when you first got it.

It is open source thinking applied to agent capabilities.

Someone builds something useful. It gets shared. It keeps getting better as more people use it.

What This Changes Day to Day

Concrete example because "the agent learns" is easy to say and hard to picture.

Say you use an agent to help review code every day. You have opinions. You care about specific things, maybe how errors are handled, or whether edge cases are covered, or particular patterns your team uses. Other things matter less to you.

With a regular stateless agent you explain your preferences at the start of every session. Or you have a long system prompt that tries to capture everything, and you hope you remembered to include the important stuff. It works but it is overhead you carry constantly.

With an agent that builds on your sessions, something different starts happening after a while.

It knows what you care about.

It has skills built around your codebase specifically.

It remembers the decisions you made last week and applies the same reasoning without being reminded.

You stop re-explaining yourself.

That overhead that you did not even notice because it was just how things worked starts to quietly disappear.

Getting It Running

One line.

Linux / macOS / WSL2:

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

Windows (PowerShell):

iex (irm https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.ps1)

Android via Termux:

Same curl command as Linux. The installer detects Termux automatically.

After it finishes, pick your provider:

hermes model

Works with OpenRouter, Anthropic, OpenAI, Hugging Face, and several others. Free tier options exist so you can try it without spending anything upfront.

Then just start:

hermes

Or the newer interface:

hermes --tui

First time it responds and just works, running entirely on your own machine, it does feel a little different from opening another browser tab.

The Bigger Thing Underneath All Of This

I want to end on something that I keep coming back to.

We have spent decades building the assumption that software stays static and users do all the adapting. You learn the tool. The tool does not learn you. That is just how it works.

Your text editor has been the same relationship since the beginning. Your terminal. Your browser. Your IDE. Every tool you use. You poured time into learning them. They gave you capability in return. But the relationship only ever went one direction.

You changed. The tools did not.

Hermes Agent is built on a different assumption. The agent adapts. The agent accumulates. The agent compounds over time.

An agent you have been using for 6 months is different from an agent you started today, because 6 months of your actual work went into it. Skills built from your sessions. A model of you built from your interactions. Capabilities refined around your specific context.

Your text editor cannot do that. Your terminal cannot do that. Almost nothing in your development environment can do that.

The relationship between a developer and their tools has been one-directional for a very long time.

This is one of the first real cracks in that.

References

For a deeper look at Hermes Agent and the ideas mentioned in this post:

🤝 Stay in Touch

Place	Find me here
GitHub	building things → hemapriya-kanagala
LinkedIn	resources & updates → hemapriya-kanagala
X	random dev thoughts → @KanagalaHema

And seriously, if something here made sense (or didn’t), drop a comment.

The Last Developer Museum: From Stack Overflow to AI

Hemapriya Kanagala — Fri, 15 May 2026 17:31:55 +0000

Welcome to the Museum of Software Development.

Please keep your hands away from the exhibits.

Some of the technologies displayed here are fragile, unstable, and still somehow running production banking systems.

Today’s tour includes:
The Forum Developer → The Stack Overflow Era → The Framework Expansion → The Tutorial Boom → The Senior Developer → The AI Era → The Lost Rituals → The Developer, Unchanged.

The first exhibit awaits below.

Exhibit 01 - The Forum Developer (1998 – 2007)

Here we see one of the earliest known programmers in their natural habitat.

This was the golden age of phpBB, vBulletin, and Usenet newsgroups, where every programming question began a thread and every thread was an adventure.

Notice the environment:

37 open browser windows
neon-colored forum boards with flaming banner graphics
a desktop wallpaper featuring something dramatic
unexplained animated GIFs used purely for emphasis

The Forum Developer survived primarily through community spirit and the occasional blunt redirect. Questions were greeted with sacred phrases such as:

"Please search before posting."

Veteran developers will recognize the uncensored version.

or the more advanced:

"Duplicate thread. Locked."

Historians believe many junior developers found their footing in this era by simply reading through thousands of archived threads. The answers were already there. You just had to page through them for forty-five minutes.

Exhibit 02 - The Stack Overflow Era (2008 – 2023)

Ah yes. The golden age of collective knowledge.

Please approach carefully.

Around 2008, Stack Overflow transformed programming help from scattered forum archaeology into organized collective suffering.

This civilization achieved unprecedented technological advancement through one revolutionary discovery:

"Someone else has already suffered before you."

The Stack Overflow developer did not solve problems in the traditional sense. Instead, they performed a sacred four-step ritual:

Google the error message, entire thing, quotation marks included
Click the purple link already visited three times before
Find the accepted answer, posted in 2012
Whisper quietly: > "Please still work."

Notice the preserved workstation. Researchers recovered:

14 browser tabs
3 abandoned side projects
one unanswered existential question
a coffee mug that may once have contained coffee

One fascinating behavior was their ability to identify the correct Stack Overflow answer purely by instinct, even when surrounded by:

five conflicting solutions
a comment war from 2015
and a bold red warning reading "DO NOT USE IN PRODUCTION"

The experienced developer somehow always knew which one to copy. Science still cannot explain this.

By 2021, Stack Overflow had helped developers over 50 billion times. The collective suffering had become collective wisdom. And it was magnificent.

Exhibit 03 - The Framework Expansion Era (2013 – 2018)

Around 2013, the frontend ecosystem entered what historians now call:

“the era of rebuilding the same app seventeen different ways.”

Please remain calm near this exhibit.

This period was defined by rapid framework evolution and mild psychological exhaustion.

A developer could leave for vacation and return to discover:

three new JavaScript frameworks
two deprecated build tools
one Medium article titled > “Why Everything You Know Is Wrong”

Simple websites now required:

847 npm dependencies
Webpack configuration understood by nobody
a package called left-pad
TypeScript (optional, then encouraged, then spiritually mandatory)

Communities formed around competing philosophies:

React developers believed everything should be a component.
Angular developers believed everything should be an enterprise architecture diagram.
Vue developers were simply trying to have a nice time until someone asked about scalability.

A framework considered revolutionary in 2014 was called “legacy” by 2017.

Archaeologists are still uncovering abandoned monorepos beneath modern frontend stacks. Each one tells a story of optimism, ambition, and a failed migration plan.

Exhibit 04 - The Tutorial Era (2015 – Present)

This room is dedicated to unfinished dreams. Please lower your voice.

Inside these glass displays are preserved GitHub repositories with names like:

netflix-clone-final-v2-REAL
startup-idea-v3
ai-app-new-new
todo-app-final-FINAL

Most contain a broken authentication flow, at least one expired API key, and a README that says simply:

"still working on it"

The Tutorial Era emerged as online learning platforms made software development accessible to millions of people worldwide. For the first time, anyone with curiosity and an internet connection could begin building real applications with remarkably little friction.

Researchers later identified a recurring developmental condition commonly referred to as:

"tutorial hell"

Symptoms included:

completing courses with growing confidence
struggling to begin independent projects
repeatedly restarting the same application with newer technologies
maintaining twelve open tabs titled: > "Build X in 20 Minutes"

Many developers believed they were one tutorial away from finally “becoming real developers.”

Curiously, this belief was not entirely incorrect.

Modern historians no longer classify the repositories in this exhibit as failures. They are now understood as early-stage artifacts of experimentation, persistence, and skill formation.

Several developers represented here later became senior engineers, though many still have a folder named final-final-v2 somewhere on their desktop.

Exhibit 05 - The Senior Developer

You may notice this exhibit appears empty.

Look closer.

There. In the corner.

The senior developer conserves energy through minimal movement and aggressive pattern recognition. Researchers believe they have witnessed the same industry trend cycle approximately four separate times under different branding.

Common phrases include:

"Who wrote this service? Let's ask them before we touch it."
"We tried something similar in 2016."
"It depends."

The senior developer possesses several unusual abilities:

locating production issues by staring silently at logs
reading stack traces faster than documentation
deleting 4,000 lines of code without elevated heart rate
identifying fragile infrastructure purely from file names

When introduced to a "revolutionary new JavaScript framework," the senior developer typically asks:

How large is the bundle?
Who maintains it?
Will it still exist in two years?

Researchers initially misidentified this behavior as negativity.

It was later classified as experience.

Exhibit 06 - The AI Era (2022 – Present)

Please proceed carefully.

This exhibit is evolving in real time.

For decades, developers searched the internet for answers.

Then the answers started talking back.

The modern developer no longer writes code alone. An AI now sits beside them at all times: infinitely fast, endlessly confident, and occasionally catastrophically wrong.

Observe a preserved AI-assisted workflow:

Developer:
"Build me a scalable auth system with retry logic,
clean architecture, and proper error handling."

AI:
[creates something impressive and deeply suspicious]

Developer:
"Not like that."

AI:
[creates something different and equally suspicious]

Developer:
[accepts 73% of it, fixes the dangerous parts,
and ships to production]

Entire categories of work changed almost overnight.

Boilerplate disappeared.
Syntax memory became optional.
Junior developers began shipping features in days that once took weeks.

A new skill emerged instead:

knowing how to explain what you actually want.

Prompt engineering. Communication. Context. Clear thinking.

Turns out these mattered more than everyone expected.

Senior developers adapted differently. Their value shifted from writing code quickly to recognizing subtle architectural mistakes before they reached production.

The experience has been described as:

“Pair programming with an infinitely confident intern who has read the entire internet.”

Entire codebases now appear overnight:

beautifully formatted
well documented
occasionally solving a completely different problem than intended

The humans still review.

The humans still decide.

The humans still deploy hotfixes on Friday night.

Some traditions survive every technological revolution.

Exhibit 07 - The Lost Rituals

Many ancient practices have quietly disappeared. The museum has preserved them here for educational purposes.

Reading Documentation. Once considered the first step. Now often attempted only after the third Stack Overflow thread and two AI prompts fail. Ironically, documentation has quietly gotten much better.
Memorizing Syntax. Modern developers ask the AI. This is arguably fine.
Closing Browser Tabs. Declared impossible sometime around 2017. No recovery in sight.
The "Temporary Fix." Despite the name, several temporary fixes from 2014 are still in production today, now considered load-bearing infrastructure.
The 2 AM Deploy. Once a beloved tradition where developers, filled with optimism and a light disregard for consequences, pushed changes to production late on a Friday. Though officially discouraged, sightings still occur in the wild.

Some rituals faded. Others simply evolved.

Final Exhibit - The Developer, Unchanged

Despite dramatic evolutionary changes across three decades, all developer generations share the same core behaviors.

Every developer, regardless of era:

believes the current bug "should be simple"
feels a quiet dread when asked to touch legacy code
has deployed something unintentionally and aged visibly in that moment
has pasted code from the internet and silently asked the universe for help

The tools changed. The languages changed. The frameworks changed. The AI arrived.

But the developer remained the same person, sitting in front of a screen at 2:13 in the morning, reading an error message, thinking some version of the same thought that every developer since 2008 has thought:

"Surely someone on the internet has suffered before me."

They had. They answered. It is still there, upvoted 847 times, from a thread opened in 2011.

Thank you for visiting the museum.

The gift shop sells mechanical keyboards, unfinished side projects, and a mug that says "it depends."

Which exhibit do you belong to? Drop it in the comments.

I’ll say mine in the comments first.

🤝 Stay in Touch

Place	Find me here
GitHub	building things → hemapriya-kanagala
LinkedIn	resources & updates → hemapriya-kanagala
X	random dev thoughts → @KanagalaHema

Gemma 4 and the Economics of AI Access

Hemapriya Kanagala — Mon, 11 May 2026 19:45:08 +0000

This is a submission for the Gemma 4 Challenge: Write About Gemma 4

TL;DR

For a lot of developers around the world, the real barrier to using AI is not skill. It is the monthly bill. Local models like Gemma 4 make AI more accessible in a way cloud-only tools never fully can.

Estimated read time: ~7 minutes

The cost of AI is not the same everywhere
What developers actually deal with
The hidden cost people never talk about
What running locally actually changes
Getting Gemma 4 running for free
But wait, is local AI actually good enough?
The compounding problem nobody writes about
Why this matters beyond cost
Where this goes from here
References
🤝 Stay in Touch

The cost of AI is not the same everywhere

Let me say a number: 20 dollars a month.

Depending on where you live, that may not sound like a meaningful monthly cost.

But software pricing is usually global while purchasing power is not.

A subscription that feels small in one economy can feel very different in another once local income levels, currency conversion, taxes, and payment fees are involved.

And this is just one subscription.

GPT-4 costs money. Claude costs money. Gemini has paid tiers. If you are experimenting across multiple models while building something, the costs stack up quickly.

A lot of AI discussions quietly assume everyone experiences these prices the same way. In reality, they do not.

What developers actually deal with

Here is a very normal situation for a lot of developers.

You are building a side project. Maybe you want to add document summarization, semantic search, or an AI assistant.

You check cloud APIs first because they are easy to start with. The documentation is good. The SDKs work. Everything feels smooth.

Then you open the pricing page.

The free tier works until you start building something real. After that, you either slow down or start paying monthly for a project that may never make money.

And sometimes the problem is not even the price itself.

International transactions fail. Certain cards are not accepted. Some banks block recurring foreign payments. Developers end up using prepaid cards, virtual cards, or workarounds just to access a tool.

That is not a technical problem.

That is an access problem.

The hidden cost people never talk about

The subscription price is the obvious cost. The annoying part is everything around it.

You are always watching usage limits

Free tiers are fine until you hit them in the middle of testing something.

After a while, you stop experimenting freely because every request feels tied to a meter running somewhere in the background.

You depend on payment systems that may not work smoothly everywhere

This sounds minor until you experience it yourself.

A surprising number of developers spend more time solving payment problems than setup problems.

Your data leaves your machine every time

For personal projects this may not matter much.

But for freelancers or client work, uploading code, documents, or internal information to external APIs is something you actually have to think about.

None of these issues are massive individually.

Together, they create friction.

And friction adds up over time.

What running locally actually changes

When you run a model locally, most of those problems disappear.

No monthly subscription. No rate limits. No card required. No sending data somewhere else.

You download the model once and it is just there whenever you need it.

That changes how you experiment.

You stop thinking about usage meters. You stop worrying about burning credits while testing ideas. You can actually try things freely.

If you are working with sensitive code or documents, everything stays on your machine.

If international payments are difficult where you live, none of that matters anymore. You download the model and start building.

Downloading local models still requires bandwidth and storage, which can also be a barrier in some places. But once downloaded, the ongoing cost becomes close to zero.

And to be clear, Gemma 4 is not the only model doing this.

Llama, Qwen, Mistral, DeepSeek, Phi, and others have also made local AI dramatically more accessible over the last few years. The idea of running capable models on consumer hardware is not new anymore.

Local AI is still constrained by hardware. Larger models need more RAM, better GPUs, and more storage. But the minimum hardware needed to run useful models has dropped dramatically.

What Gemma 4 represents is another strong step in that direction: open weights, practical model sizes, strong performance, and a setup simple enough that regular developers can actually use it.

That is the real reason local models matter.

Not benchmark charts.

Not parameter counts.

The fact that people can actually use them without financial or logistical barriers constantly getting in the way.

Getting Gemma 4 running for free

The easiest way to try Gemma 4 locally is with Ollama.

# Install Ollama from https://ollama.com

ollama pull gemma4:4b
ollama run gemma4:4b

That is basically it.

The 4B model can run on Apple Silicon and many modern laptops without a dedicated GPU. Once it is running, you get a local chat interface and a localhost API endpoint you can use in apps similarly to a cloud API.

If you want a no-setup option first, Google AI Studio also lets you try Gemma 4 for free.

You can also use Hugging Face or OpenRouter if you want more flexibility.

For most people, the 4B model is the best place to start. It runs without much trouble and is already useful for real work.

But wait, is local AI actually good enough?

This is the fair question.

A couple of years ago, local models felt clearly worse. Smaller context windows, weaker reasoning, weaker outputs.

That gap has narrowed a lot.

Gemma 4 supports long context windows, multimodal input, and reasoning modes depending on the model version. For everyday tasks like coding help, summarizing documents, debugging, searching through notes, or drafting content, local models are now genuinely usable.

Not “good for a local model.”

Just useful.

Yes, cloud models are still stronger for difficult reasoning tasks. That gap still exists.

But for most day-to-day developer work, local models are now capable enough that the economics start making a lot more sense.

The compounding problem nobody writes about

Here is the part I think matters most.

When people cannot afford to experiment freely, they build less.

Every developer who stops halfway because they hit a limit or ran out of credits is someone who did not finish that project. Did not learn that thing. Did not ship something they otherwise could have built.

The developers who can experiment freely usually learn faster because they can afford to try more things.

The people who get to experiment today are often the people who build tomorrow’s companies, tools, and research.

Meanwhile, others are constantly thinking about limits, subscriptions, and costs while learning.

That creates an uneven playing field.

Not because of talent.

Because of access.

Local models do not solve every problem. But they do remove one meaningful barrier, and that matters more than people think.

Why this matters beyond cost

This is not an argument against cloud AI.

Cloud AI is extremely useful and worth paying for in many situations. If these tools save you time professionally, the subscription cost can easily make sense.

But access to AI tools should not depend entirely on whether recurring subscriptions are affordable relative to local purchasing power.

That is why open-weight local models matter.

You can download them, run them on hardware you already own, and start building immediately.

No approvals.

No payment issues.

No monthly bill sitting in the background while you experiment.

For a lot of developers, that changes what is realistically possible.

Where this goes from here

The argument for local AI is probably going to get stronger over time.

Hardware keeps improving. Models keep getting more efficient. The laptops people already own today can do things that felt impossible locally just a few years ago.

Cloud AI is not going away. It will still matter for large-scale systems and the hardest problems.

But for learning, experimentation, side projects, and a lot of day-to-day development work, local models are already becoming the more practical option for many developers.

The biggest impact of local AI may not be better benchmarks.

It may simply be allowing more people to participate in the first place.

References

For a deeper look at Gemma 4:

🤝 Stay in Touch

Place	Find me here
GitHub	building things → hemapriya-kanagala
LinkedIn	resources & updates → hemapriya-kanagala
X	random dev thoughts → @KanagalaHema

And seriously, if something here made sense (or didn’t), drop a comment.

Why Gemma 4 Matters More Than Its Benchmarks

Hemapriya Kanagala — Fri, 08 May 2026 18:12:10 +0000

This is a submission for the Gemma 4 Challenge: Write About Gemma 4

TL;DR

Everyone's talking about benchmark scores. But the more interesting thing about Gemma 4 is that capable AI is now running on ordinary hardware. That shift is worth talking about.

Estimated read time: ~8 minutes

AI used to live somewhere else
The browser was never the destination
Open models changed something real
Why Gemma 4 actually feels different
Getting Gemma 4 running locally
Smaller models quietly became useful
What changed inside the model
Cloud AI is not going anywhere
This matters beyond AI
Where this is heading
References
🤝 Stay in Touch

AI used to live somewhere else

For a long time, using AI felt like going somewhere.

You opened a tab. Visited Claude or Gemini or ChatGPT. Did your thing. Closed the tab. Done.

It felt completely separate from the rest of your computer. Like a different room you walked into, used, and walked out of.

And honestly, that made total sense. These systems needed serious infrastructure. You couldn't just download "powerful AI" the way you downloaded a text editor. The hardware requirements alone would make your laptop cry.

But something has been quietly changing underneath all of this.

Capable AI is becoming practical on much smaller, more ordinary hardware. Not research-grade hardware. Not a server rack in some data center. Regular laptops. Phones. A Raspberry Pi sitting on someone's desk.

I think that part is being underestimated.

The browser was never the destination

We got so used to "going to AI" that we started thinking that was just how AI worked.

But if you look at how other technologies spread, you notice something. The early interface is almost never the final form.

Early internet meant going to a portal. Then the web became part of everything. Early music streaming meant going to a website. Now it's built into your car, your TV, your watch. Early GPS meant a separate device on your dashboard. Now your phone just... knows where you are.

The browser was how AI reached people fast. It was not the final destination.

AI is already showing up in code editors like Cursor and GitHub Copilot, in operating systems, in search, in accessibility tools, in terminals. Not as something you go visit but as something that is just there while you work.

Edge devices, phones, local environments, offline workflows. Things that had nothing to do with "frontier AI" two years ago are now running models locally.

That is a different kind of shift.

Open models changed something real

When people hear "open models" they usually think licensing debates. Gemma versus Llama versus whoever.

That is kind of missing the bigger thing.

The real shift with open models is that developers can now run capable AI directly on their own hardware. You do not have to go through someone else's platform. You do not have to pay per token. You do not have to send your data somewhere.

Your laptop. Your workstation. Your local server. Your edge device. Whatever you have, you can now run something real on it.

Models like Gemma, Llama, Mistral, Qwen, and Phi are not trying to replace Claude or Gemini. They are expanding where capable AI can realistically exist. Those are two completely different things.

Why Gemma 4 actually feels different

A lot of AI releases feel like: "We improved the benchmark scores." Cool. What does that mean for me on Tuesday afternoon?

Gemma 4 feels different for a more specific reason.

A few years ago, running AI locally meant: slow responses, weak reasoning, tiny context windows, everything crashing if you pushed it, and needing a GPU that costs more than your rent. The experience was rough enough that most people just used the cloud APIs and moved on.

That experience is changing pretty fast now.

Gemma 4 does multimodal work, handles long context windows, does coding assistance, function calling, tool usage. Things that used to require large cloud infrastructure are now showing up in models designed to run on a phone or a consumer laptop.

Google described Gemma 4 as "byte for byte" one of the most capable open model families released. And that framing is actually useful. It is not just "this model is smart." It is "this model is smart AND fits in places previous models could not."

The race has shifted from pure capability to deployable capability. That distinction matters.

Getting Gemma 4 running locally

Okay, let's actually do something. Getting Gemma 4 running is surprisingly easy.

Option 1: Ollama (start here)

Ollama is the easiest way to run Gemma 4 locally on Mac, Linux, or Windows. If you have not tried it, honestly just go install it right now.

# Install Ollama from https://ollama.com
# Then pull and run Gemma 4

ollama pull gemma4:4b
ollama run gemma4:4b

The 4B model runs on Apple Silicon and modern consumer laptops without needing a separate GPU. You get a working chat interface right in your terminal. It is weirdly satisfying the first time it just... works.

Option 2: Hugging Face + Transformers

If you want more control, Gemma 4 is on Hugging Face Transformers. You get direct access to model weights inside Python, which means you can mess with inference settings, quantization, and local deployment however you want.

Option 3: Google AI Studio (zero setup)

If you just want to explore without installing anything, Google AI Studio lets you try Gemma 4 in the browser and get free-tier API keys. Good for getting a feel for the model before committing to a local setup.

Option 4: OpenRouter (free tier)

OpenRouter gives you free-tier access to Gemma 4 31B if you want to test a larger model without the local hardware requirements.

Which size should you actually use?

Gemma 4 comes in a few different shapes:

2B and 4B: For phones, edge devices, Raspberry Pi, consumer laptops. Start here.
31B: Bridges local and server-grade. Works on a high-end workstation.
27B MoE (Mixture-of-Experts): More efficient for reasoning. Only activates parts of the model at a time, which keeps it faster than you'd expect.

If you are just starting out, grab the 4B. It will run without drama on most modern machines and gives you a real feel for what local AI is actually like now.

Smaller models quietly became useful

Here is something that does not get talked about enough.

The big story in AI is always the biggest models. GPT-4. Gemini Ultra. Claude Opus. Those are impressive. But something equally interesting has been happening with smaller models.

Smaller models have been getting genuinely useful for everyday work.

A model running locally with low latency can sometimes feel more practical than a larger remote model, depending on what you are doing. Coding help, summarizing docs, answering questions about a codebase, drafting things, offline research. The response is instant. Nothing goes over the network. It just works.

And the Mixture-of-Experts architecture is part of why this is possible. Regular dense models use the full network every single time they respond. MoE models only activate a portion of the network per response. The practical result: you get stronger reasoning without paying the full compute cost every time.

So the question has quietly shifted from "how powerful can we make it?" to "how deployable can we make it?" Those are genuinely different goals and they produce genuinely different models.

What changed inside the model

Some of the terminology around Gemma 4 is worth slowing down on because it sounds complicated but it is not.

Context windows

Think of a context window as the model's working memory during a conversation. Earlier local models had very short memories. You would have a long back-and-forth and the model would start forgetting what you were talking about earlier in the conversation.

Gemma 4 supports up to 128K tokens depending on the model size. That is large enough for long conversations, full codebases, whole documents, and multi-step research without things falling apart.

Multimodal

Gemma 4 can work with more than just text. Screenshots, images, diagrams, charts, documents. This matters because actual work rarely lives in text alone. You are looking at a chart and asking questions about it. You are sharing a screenshot of an error. The model handles that.

Reasoning modes

This one is interesting. Gemma 4 has configurable thinking modes where the model does step-by-step reasoning before giving a final answer.

The practical difference is that the model is not just generating text. It is working through problems. Planning. Using tools. Calling functions. Connecting to external systems. The shift from "AI that responds" to "AI that reasons through something" is noticeable when you use it.

Cloud AI is not going anywhere

It would be easy to read everything above and think this is a "local AI beats cloud AI" story. It is not.

Running larger models locally still needs serious hardware. Cloud systems still outperform smaller local models on plenty of complex tasks. Claude, Gemini, GPT-4 are not going anywhere.

The more realistic picture is that these things coexist. Some workloads stay in the cloud. Some workloads happen locally. And eventually the user stops thinking about which is which, because it all just works.

The interesting future is not local versus cloud. It is AI that is ambient across both, where the question of "where is this running" stops being something you have to think about.

This matters beyond AI

Technology has this pattern where once something becomes accessible enough, it stops feeling like a technology and starts feeling like a fact of life.

You do not think about "using GPS technology" when you navigate somewhere. You just go. You do not think about "accessing the internet" when you look something up. You just look.

Personal computers became what they became because people could own them. Smartphones became what they became because they were always with you. The internet became what it became because connectivity eventually reached everywhere.

AI might be entering a version of that same phase right now.

Not because one model suddenly changes everything. But because capable AI is gradually becoming efficient enough, small enough, integrated enough, and practical enough to run across ordinary computing environments.

When something is everywhere, using it stops feeling like using it.

Where this is heading

AI is already in coding tools, operating systems, productivity software, creative tools, accessibility products, research workflows. Not as something you visit but as something that is just present.

Nobody fully knows what the next few years look like. The models will keep getting better. The hardware will keep getting more efficient. The workflows will keep changing.

But the direction feels pretty clear.

AI is not just something you go to a website to use anymore.

And Gemma 4 running on a Raspberry Pi is probably the most honest summary of where we are right now.

That is the thing worth paying attention to.

References

For a deeper look at Gemma 4 and the ideas mentioned in this post:

🤝 Stay in Touch

Place	Find me here
GitHub	building things → hemapriya-kanagala
LinkedIn	resources & updates → hemapriya-kanagala
X	random dev thoughts → @KanagalaHema

And seriously, if something here made sense (or didn’t), drop a comment.

Your AI Agent Crashed at 2 AM. Here’s How Google Fixes It.

Hemapriya Kanagala — Wed, 29 Apr 2026 07:15:28 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

TL;DR

AI agents don’t just fail like traditional software. They fail because of how they reason.

At Google Cloud NEXT '26, Google introduced Agent Observability (to see what your agent was thinking) and Gemini Cloud Assist (to diagnose and fix issues directly in your code).

Together, they make debugging AI agents in production faster, clearer, and far less painful.

⏱️ Estimated read time: ~8 minutes

The Reality of AI Agents in Production
First, let's understand what "debugging an AI agent" even means
What is Agent Observability?
What is Gemini Cloud Assist?
The demo: a marathon simulation that broke mid-race
What even is a token limit?
How Cloud Assist fixed it
Why this matters for every developer building with AI
One thing to keep in mind
The real shift happening right now
References
🤝 Stay in Touch

The Reality of AI Agents in Production

It’s 2 AM. Your AI agent just crashed in production.

And the worst part? You don’t even know why.

You've spent weeks building it. It works great on your laptop. You deploy it. Customers start using it. And then, one random Tuesday, it just... dies. No clear error. No "you forgot a semicolon" message. Just a broken agent, confused logs, and you staring at your screen wondering what on earth it was thinking.

The problem isn’t just failure. It’s understanding why the agent failed.

This is the part nobody really talks about when we get excited about building AI agents. Building them is the fun part. Running them, keeping them alive, understanding why they fail, and fixing them fast, that is where things get genuinely hard.

At Google Cloud NEXT '26, Megan O'Keefe put it really well. The real challenge of putting agents into production isn't just scaling your infrastructure. It's "managing the reasoning, the tool calls, and all the places in the whole system where something can go wrong."

And Google showed two tools built exactly for this moment: Agent Observability and Gemini Cloud Assist.

First, let's understand what "debugging an AI agent" even means

With a traditional application, debugging is kind of like fixing a broken pipe. You find the leak, you patch it, you're done. The pipe either works or it doesn't. There's no in-between.

Debugging an AI agent is completely different. It's less like fixing a pipe and more like being a therapist for a robot. The agent isn't just crashing because of a typo or a missing database connection. It's crashing, or misbehaving, because of how it reasoned. It made a decision. That decision was wrong. And you need to understand why it made that decision so you can help it not do it again.

This is where AI systems are fundamentally different from traditional software.

That's a whole new discipline. And without the right tools, it's like trying to find a needle in a haystack while blindfolded.

What is Agent Observability?

Think about a flight data recorder, the black box on an airplane. After something goes wrong, investigators pull that box and replay everything: every reading, every signal, every action the pilots took. They don't have to guess. They have a record.

Agent Observability is that black box for your AI agent.

When a normal app has a problem, you check if a server crashed or if a response was slow. That's enough. But when an AI agent has a problem, you need to know something much deeper: what was it thinking? What tools did it call? What information did it look at? Where exactly did its reasoning go off track?

Agent Observability records all of this. It uses open standards, specifically OTel-compliant telemetry, which is the same kind of telemetry the broader software industry already uses for observability, to give you a visual trace of your agent's full execution path. Every step, in order, clearly laid out.

This matters because AI agents can fail in ways that are genuinely strange. They can get stuck in reasoning loops. Imagine someone pacing back and forth trying to solve a problem, taking the same wrong step over and over because they can't see that it's wrong. Or they can crash because they tried to hold too much information in memory at once. Both of these failures are invisible without observability. With it, you can actually see what happened.

What is Gemini Cloud Assist?

Now, once you see what happened, you still have to fix it. And this is where Gemini Cloud Assist comes in.

If Agent Observability is the black box, Cloud Assist is the investigator who reads it for you, connects it to everything else, and tells you exactly what to do.

Here's the old way of doing things: something breaks in production. You get an alert. You open logs. You stare at thousands of lines of dense, intimidating text. You copy chunks of it into a chat window somewhere, try to make sense of it, go back to your code, try to figure out where the problem lives, and maybe fix the wrong thing first. It's exhausting and slow.

Cloud Assist changes this. It doesn't just summarize the logs. It reads them, identifies the exact error, and then connects directly to your source code in your IDE (your code editor) through something called the Model Context Protocol (MCP). It reads both the production logs and your actual code at the same time. And then it suggests a specific, concrete fix.

Not a vague "maybe try this." An actual code change.

The demo: a marathon simulation that broke mid-race

To show how this all works together, Google ran a live simulation at the keynote (Google Cloud Next '26 Developer Keynote). Imagine a Las Vegas marathon. An AI agent is running the simulation of race logistics in real time. And mid-demo, the "Simulator Agent" crashes and starts causing high latency.

Here's how the debugging played out:

Megan got an alert in her Gmail. She opened the Cloud Monitoring console and looked at the trace view, the visual record of what the agent had done. She could see it had successfully called a few tools, and then it just died. Unexpectedly. No obvious reason in the trace itself.

Instead of scrolling through a massive wall of error text, she clicked one button to start a Cloud Assist investigation.

Cloud Assist found a 400 request error. The agent had tried to talk to the Gemini API and got rejected. But why?

Megan opened her code editor. Cloud Assist analyzed the source code (a file called agent.py) and figured out what happened: the agent had exceeded the 1 million context token limit.

What even is a token limit?

This is worth slowing down on, because it's one of those concepts that sounds technical but is actually very intuitive once you see it.

An AI's "context window" is basically its short-term memory. "Tokens" are the pieces of data it's holding in that memory, roughly speaking, the words and information it's actively working with.

Now imagine you're a student trying to memorize an encyclopedia in one sitting. You keep reading and reading, adding more and more to your working memory, and at some point your brain just gives up. It hits a limit. You can't hold any more.

That's exactly what happened to this agent. It had been running for a while, accumulating information, and it never stopped to summarize what it had learned. Its memory filled up. It hit the token limit. It crashed.

This is a real problem in production AI systems, and it's becoming one of the new bottlenecks in software development. "Token scale," managing how much information an agent holds and when it should compress its memory, is something developers now have to think about the same way they used to think about RAM or database size.

How Cloud Assist fixed it

This is the part that genuinely impressed me.

Cloud Assist didn't just say "your token limit was exceeded, good luck." It looked at the code, understood the architecture, and suggested a specific fix: add a token_threshold parameter to a feature called Event Compaction.

What Event Compaction does is force the agent to summarize its memory more frequently, before it gets dangerously close to the limit. By adding a threshold, you're essentially telling the agent: "don't wait until your memory is full. Start summarizing earlier and keep things manageable."

Megan approved the change, committed it, and the system automatically deployed the fixed agent.

The whole process, from alert to deployed fix, was remarkably fast. And more importantly, the fix was accurate. It wasn't a guess. It was based on reading the actual production error and the actual source code together.

Why this matters for every developer building with AI

Here's my honest take on all of this.

We're entering a genuinely new era of software development. A lot of us are building agents and excited about what they can do. But we haven't fully reckoned with the fact that agents are still just software. They still break. They still crash. They still misbehave in production.

They just break in completely new ways.

A traditional bug is usually deterministic. The same input gives you the same broken output every time. An agent bug can be non-deterministic. It might only happen under certain conditions, after a certain amount of time, or when the agent has accumulated a certain kind of context. That's much harder to reproduce and debug without proper tooling.

The moment you move an AI agent from a local experiment to a real environment where real users depend on it, you need observability. Not eventually. Immediately.

And tools like these fill a gap that genuinely needed filling. The IDE integration especially, being able to see the production error and the source code in the same place, at the same time, with suggested fixes, that's not just convenient. It's a fundamentally better workflow.

One thing to keep in mind

I want to be real with you about something, because I think it's worth saying.

We're now in a world where AI is diagnosing and writing code to fix other AI. That's remarkable. But it also means you should never just approve a suggested fix without understanding what it does.

Cloud Assist suggested the token_threshold change because it read the code and understood the architecture. But you, as the developer, need to review that change with your own understanding too. An AI can misread context. It can suggest a fix that solves the symptom but misses the root cause. Or worse, it could push a fix that quietly breaks something else.

Human-in-the-loop isn't just a nice phrase here. In production systems, it's genuinely important. Approve changes you understand. Don't just click accept because the AI was confident.

That said, the fact that we have these tools at all is genuinely exciting. Used thoughtfully, they make debugging AI systems faster and less painful than it's ever been.

The real shift happening right now

AI agents don’t just fail. They fail in ways you can’t see without the right tools.

The conversation in AI development is moving. A year ago, everyone was talking about building agents. Now the real challenge is running them safely, understanding them when they fail, and fixing them quickly.

Agent Observability and Gemini Cloud Assist are Google's answer to that challenge. And based on what was shown at NEXT '26, it's a thoughtful one.

If you're building AI agents, even small ones or experimental ones, start thinking about observability now. Not when something breaks. Now.

Because when an AI agent fails at 2 AM, you don’t just need logs. You need answers.

References

For a deeper look at the announcements and demos mentioned in this post:

🤝 Stay in Touch

Place	Find me here
GitHub	building things → hemapriya-kanagala
LinkedIn	resources & updates → hemapriya-kanagala
X	random dev thoughts → @KanagalaHema

And seriously, if something here made sense (or didn’t), drop a comment.

DEV Community: Hemapriya Kanagala

Letters to Tomorrow: A June Solstice Game About the Things We Carry Into Tomorrow

Table of Contents

What I Built

Video Demo

Code

hemapriya-kanagala / letters-to-tomorrow

A narrative web game about unfinished letters, second chances, and finding the right words. Play as a postmaster on the June Solstice, helping lost messages reach tomorrow before the sun sets.

💌 Letters to Tomorrow

A June Solstice Story

Table of Contents

About

How I Built It

Prize Category

Best Google AI Usage

Best Ode to Alan Turing

Why Letters?

A Piece of My Story

A Small Step Outside My Comfort Zone

Final Thoughts

Dev Opportunity Radar #3: Neo Scholars, a $2M AI Challenge, and an $85K AI Fellowship

Table of Contents

⚡ Quick Scan

🔄 Still Open From Previous Editions

📡 Radar Follow-Up

📍 This Week's Opportunities

📌 Neo Scholars

📌 Gemini × XPRIZE AI Business Challenge

🎁 Bonus Opportunity

5-Day AI Agents Intensive Course with Google

📚 Resources Worth Checking Out

LearnWeb3

🌟 Community Finds

AI Tinkerers

Claude Corps

Hacking for Good

👋 Until Next Friday

The Most Valuable Thing I Found in Tech Wasn't an Opportunity

Table of Contents

Why I Joined Tech Communities

The Loneliness Nobody Talks About

More Than Networking

The Hidden Value of Community

Leaving Didn't End It

From Reading to Participating

The Best Decision I Made

I'd Love to Hear Your Story

🤝 Let's Stay Connected

Dev Opportunity Radar #2: A Fully-Funded Residency in Finland, AI Research Program, and a $60K Hackathon

Table of Contents

⚡ Quick Scan

🔄 Still Open From Last Week

📍 This Week's Opportunities

📌 FR8

📌 Summer of Open AI Research (SOAR)

📌 Google Cloud Rapid Agent Hackathon

⚡ Quick Update

AAIF Ambassador Program

🎁 Bonus Opportunity

Microsoft AI Skills Fest

📚 Resources Worth Checking Out

LLM Zoomcamp

🌟 Community Finds

👋 Until Next Friday

Dev Opportunity Radar #1: A $100K AI Grant, Two Fellowships, and an AI Agent Resource

Table of Contents

⚡ Quick Scan

📍 This Week's Opportunities

📌 Flow Fellowship

📌 Interactivity Research Grants by Thinking Machines

📌 Commit Fellowship

📚 Resources Worth Checking Out

Hands-on AI Agents

🧭 Why I'm Starting This

🤝 Let's Build This Together

🌟 Community Finds

👋 Until Next Friday

Hermes Agent Changed How I Think About Execution Boundaries

Table of Contents

Traditional Automation Assumes Deterministic Execution