DEV Community: Hemapriya Kanagala

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?

👋 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.

How I Built a Blockchain User Profile with Solidity (and You Can Too)

Hemapriya Kanagala — Tue, 29 Jul 2025 03:57:11 +0000

This is a smart contract I wrote using Solidity that lets people register and update their profile on the blockchain. It was one of the first contracts I built to understand how user data works on Ethereum.

The idea is simple:

Everyone has a wallet address. What if we could let each address store their name, age, and email - all saved on-chain?

So I built that.

Here is the GitHub link if you want to check out the code.

I wrote just one file: UserProfile.sol.

What This Contract Does

This smart contract lets a user:

Register their name, age, and email
Update that information later
View their own profile (no one else can access it)

Everything is connected to their Ethereum wallet address, so you don’t need to log in - your wallet is your ID.

Concepts I Used

If you're new to Solidity or smart contracts, these are the main building blocks I used:

Concept	What It Does
`struct`	Groups related data - like name, age, and email - into a single object
`mapping`	Stores info for each user using their wallet address as the key
`require()`	Adds checks so people don’t register twice or update before registering
`block.timestamp`	Saves the time a user registered, using the blockchain’s clock

Each time someone registers, their info is stored on the blockchain - and only they can update or view it.

How It Works

Here’s what the contract does in plain English:

1. `register(name, age, email)`

This function saves your profile to the blockchain - but only if you haven’t registered before. If you try again, it gives an error.

2. `updateProfile(name, age, email)`

If you already registered, this lets you change your info anytime.

3. `getProfile()`

This function shows your current profile - your name, age, email, and the time you first registered. Only you can see it (based on your wallet).

How to Try It Yourself (Beginner-Friendly)

You don’t need a real wallet or ETH to test this. Remix IDE runs everything in your browser using fake ETH.

Steps to Test the User Profile Contract

Go to Remix

→ https://remix.ethereum.org
Create a new file

→ Click “+” → Name it UserProfile.sol
Paste in the contract code

→ You can find it here on GitHub
Compile it

→ Go to the Solidity Compiler tab

→ Make sure version is 0.8.0 or higher

→ Click Compile
Deploy it

→ Go to the Deploy & Run Transactions tab

→ Select Remix VM (Prague) as environment

→ Leave Value as 0

→ Click Deploy
Register yourself

→ Fill in name, age, and email

→ Click register()

✅ You’ll see a green checkmark
Check your profile

→ Click getProfile()

✅ Your info will appear: name, age, email, and timestamp
Try updating it

→ Enter new name, age, or email

→ Click updateProfile()

→ Then click getProfile() again to see the updated info

What I Learned

Lesson	How I Used It
Structs in Solidity	Grouped user info like name, age, email
Mappings	Stored each user's profile by their address
Access control with `msg.sender`	Made sure only the owner of a profile can update or view it
Blockchain timestamp	Recorded when each user registered
Remix testing	Quickly deployed and tested without real ETH

Common Mistakes to Avoid

Mistake	Why It’s a Problem	How I Solved It
Registering twice	Contract would overwrite data	Used `require()` to block double registration
Updating before registering	User wouldn’t exist in mapping yet	Added `require()` to check registration first
Returning too much data	Could make `view` functions heavy	Kept `getProfile()` simple and clear

Up Next

I’d really appreciate your questions or feedback. Did something confuse you? Let me know. Your insights help shape the next articles.

Also, if there’s a non-Web3 topic you want me to cover (open source, side projects, etc), drop a comment below. If I know it, I’ll write about it. If not, I’ll point you to a good place to begin.

🤝 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.

Thanks for reading!

What Actually Happens When You Make a Blockchain Transaction?

Hemapriya Kanagala — Fri, 25 Jul 2025 06:33:31 +0000

Welcome back! If you read Article 1: A Beginner’s Guide to How Blockchain Actually Works, we walked through what a blockchain is, how blocks form, and why decentralization matters.

Now let’s get a little more hands-on.

You’ve probably heard things like:

“Just send me crypto.”

“It’s on the blockchain.”

“Check your wallet.”

But what does that actually mean? What happens under the hood when you send a transaction?

This article takes you behind the scenes - from clicking “Send” in your wallet to seeing the transaction confirmed on a blockchain explorer.

Step-by-Step: How a Blockchain Transaction Works

Let’s follow a single transaction from start to finish. We’ll use a simple example:

You want to send 1 token to a friend using a wallet like MetaMask.

Here’s what happens behind the scenes:

1. You Create the Transaction in Your Wallet

A wallet is an interface that lets you interact with the blockchain. It stores your private key (securely) and helps you sign transactions.

You enter:

Your friend’s public address
Amount to send
Optional message or data (depends on blockchain)
The gas fee you're willing to pay

Your wallet then signs the transaction using your private key. This proves it came from you, without ever revealing your key.

📌 Signing means creating a unique digital signature based on your private key and the transaction data.

2. Your Wallet Broadcasts the Transaction to the Network

Once signed, the transaction is broadcast to the network. This means it’s sent to nearby nodes (computers running the blockchain software).

Those nodes check if:

Your signature is valid
You have enough balance
The transaction is formatted correctly

If it looks good, they pass it on to more nodes - spreading it across the network, like sharing a file with everyone.

📌 Nodes are participants in the blockchain network. They validate transactions and keep a full copy of the blockchain.

3. The Transaction Enters the Mempool

Valid transactions are stored in something called the mempool - short for memory pool. Think of it as a waiting room where pending transactions sit before being added to a block.

Every node maintains its own mempool, but they’re usually very similar.

Inside the mempool:

Transactions are ranked (usually by fee amount)
Miners or validators pick from the top

📌 The mempool is like a “to-do list” for the network.

4. A Validator Picks It Up and Adds It to a Block

Depending on the blockchain’s consensus method, a participant is selected to propose the next block. This could be a miner (Proof of Work) or validator (Proof of Stake).

They:

Pick high-fee transactions from the mempool
Group them into a block
Validate and order them
Propose the block to the network

If accepted, the block is added to the chain - and your transaction is officially recorded.

📌 A block contains many transactions, plus metadata like timestamp, block number, and a hash of the previous block.

5. You See the Transaction Confirmed

Once included in a block, your transaction gets a confirmation.

Over time, more blocks are added after it - which makes your transaction harder to reverse. That’s why you’ll hear things like:

“Wait for 3 confirmations.”

“It’s confirmed on-chain.”

You (or anyone) can view it on a blockchain explorer like LiskScan or Etherscan. These tools let you search by:

Wallet address
Transaction hash
Block number

A Real-World Analogy: Certified Mail

Here’s a way to picture the entire process using something familiar — mailing a certified letter.

Blockchain Step	Certified Mail Equivalent
Create transaction in wallet	Write a letter, sign the envelope
Broadcast to network	Drop it at your local post office
Mempool	Letter goes into a mail sorting facility
Validator adds it to block	A courier picks it up and delivers it
Confirmed on-chain	Recipient signs for it, and delivery is logged

Both systems involve signing, routing, validation, and a final delivery record.

Wait... What’s This “Gas Fee” I’m Paying?

On most blockchains, every transaction requires a small payment - called a gas fee.

You’re paying the network to:

Validate your transaction
Store it in a block
Broadcast it across the chain

Fees vary based on:

Network congestion (how full the mempool is)
Complexity of your transaction (simple send vs smart contract)
Priority (higher fee = faster confirmation)

On Ethereum, gas is measured in gwei. On Lisk, it’s based on LSK token units.

Here’s a quick comparison:

Transaction Type	Typical Gas Fee (Estimates)
Simple token transfer	Low
NFT mint or marketplace buy	Medium
Complex smart contract call	Higher (depends on logic & storage)

Tip: Always check the fee before sending - wallets like MetaMask show it clearly.

How Long Does It Take?

Transaction time depends on:

The blockchain’s block time (e.g. Ethereum ~12s, Lisk ~10s)
Network traffic
Your fee

Blockchain	Avg Block Time	Confirm Time (1 block)	Notes
Ethereum (PoS)	~12 sec	~12 sec	High usage = higher fees
Bitcoin (PoW)	~10 min	~10 min	Slower but more secure
Lisk (PoS)	~10 sec	~10 sec	Fast and energy-efficient

More confirmations = stronger finality (i.e. harder to reverse).

What If Two People Try to Send the Same Coins?

The blockchain uses the nonce (a number that increases with each transaction) to prevent double spending.

If someone tries to send the same coins twice, only the valid transaction with the correct nonce will be accepted. The rest will be ignored.

Why Transactions Sometimes Fail

Here are common reasons a transaction doesn’t go through:

Problem	Cause
“Out of gas” error	You didn’t pay enough to complete it
“Nonce too low”	Another transaction was already sent before this one
Stuck in mempool	Gas fee too low, not attractive to validators
Wrong network selected	You sent tokens on the wrong chain

Always double-check your settings before hitting Send.

Can I Try This Myself?

Yes, if you’re curious and want to see this in action, here’s a safe, free way to experiment using a test network.

Install MetaMask browser extension
Create a new wallet and save your secret phrase securely
Add Lisk Sepolia as a custom network
Get free test tokens from the L2 Faucet
Use MetaMask to send a small token to yourself
Go to LiskScan and look up your wallet address
See your transaction as it appears on-chain

This gives you a hands-on feel for how blockchain transactions work.

Or, if this still feels early, you can just keep learning. Later articles will help build your confidence.

What’s Next?

I’d really appreciate your questions or feedback. Did something confuse you? Let me know. Your insights help shape the next articles.

🤝 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.

A Beginner’s Guide to How Blockchain Actually Works

Hemapriya Kanagala — Fri, 18 Jul 2025 22:44:47 +0000

If you've ever heard the word "blockchain" and thought, “Sounds complicated... probably not for me,” you're not alone. That was me too, not long ago. But the more I dug in, the more I realized it’s not some far-off concept meant only for coders or finance experts. It’s actually a simple idea that has the potential to change how we do things online, from sending money to keeping records and building apps.

What Is Blockchain?

Think of a digital notebook shared by many people at once. Every time someone records a transaction, it shows up instantly in everyone’s copy. No one can delete past entries or alter them without being noticed.

That unchangeable, transparent, shared structure is essentially what blockchain is. The participants all maintain it - no single person owns it. That’s what “decentralized” means.

Why Does It Matter?

Today, we depend on systems like banks, messaging platforms, or organizations to handle transactions, verify identities, or secure agreements. These intermediaries add layers of trust, fees, and delays.

Blockchain removes those layers by embedding trust in the system itself. People call it “trustless,” meaning you don’t have to rely on a central authority. The rules are enforced by the entire network.

How Blocks Form a Chain

A block is simply a collection of data - commonly a group of transactions. Inside each block you’ll find:

The details of what happened
A timestamp
A unique digital signature (called a hash)
A reference to the previous block’s hash

Linking blocks this way creates a chain. If someone tampers with a block, its hash changes and eventually the links break. That’s what makes the blockchain secure.

How the Network Decides What’s Real

Without a central authority, blockchains rely on a system called consensus. All participants (called nodes) follow a set of rules to verify transactions and add new blocks.

Here are two popular methods:

Proof of Work

Miners compete to solve a math problem. Whoever solves it adds the next block and earns a reward. This method secures the network but uses a lot of energy.

Proof of Stake

Participants lock up some of their coins as collateral. The network chooses one to add the next block. This method is faster and uses far less energy.

Most newer networks like Ethereum and Lisk use Proof of Stake today.

Public vs. Private Blockchains: What’s the Difference?

Some blockchains are open to anyone. Others are private and used within companies.

Feature	Public Blockchain	Private Blockchain
Who can use it?	Anyone	Only approved users
Who controls it?	No one	One organization
Examples	Bitcoin, Ethereum	Hyperledger, Corda

Public ones are like a public park. Anyone can enter and use it.

Private ones are more like an office building. You need a keycard.

Quick Pause: What About Security?

One word: cryptography.

Blockchains use strong math-based tools to keep things safe. Each user has two keys:

A public key, which is like your email address (you can share it)
A private key, which is like your password (you never share it)

Together, these keys help verify that transactions are real. If someone sends money, their private key is used to “sign” the transaction, proving it came from them.

Smart Contracts: Programs That Run Themselves

This part blew my mind the first time I understood it.

Smart contracts are self-executing agreements written in code. They live on the blockchain, and when conditions are met, they act on their own.

Example:

Let’s say you hire a freelancer online. Instead of using a middleman to hold the payment, you create a smart contract. When the work is marked as done, the money automatically goes to the freelancer.

No one can interfere. The contract is the boss.

Smart contracts are being used in:

DeFi (decentralized finance)
NFT marketplaces
Blockchain-based games
Digital voting

Challenges and Real Solutions

Blockchain sounds amazing, but it’s not perfect. Here are a few issues and how developers are solving them.

1. Scalability

Popular blockchains can get congested and slow.

Solution:

Use Layer 2 tools, like rollups, which process transactions more efficiently. Think of it like adding an express lane to a busy highway.

2. Energy Use

Proof of Work blockchains use a ton of power.

Solution:

Moving to Proof of Stake reduces energy use by over 90 percent. Ethereum already made this change.

3. Regulations

Governments are still figuring out how to handle crypto and blockchain legally.

Solution:

New laws are being written, and tools like Decentralized Identity (DID) are helping users stay compliant while protecting privacy.

What Is the Superchain?

Some projects, like those based on the OP Stack, aim to connect blockchains together so they can share updates and improvements. Lisk is part of this vision. The idea is a flexible, scalable, cooperative network of blockchains.

How to Begin Yourself

You don’t need coding skills to try it:

Install MetaMask
Create a wallet and save your recovery phrase
Add the Lisk Sepolia test network
Get free tokens from L2 Faucet
Send a token to yourself or a friend
See the transaction on a blockchain explorer

You’ve now used a blockchain.

Summary

Blockchain is a secure, shared digital record
It’s decentralized - no single owner
Blockchains use cryptography and consensus to stay honest
Smart contracts let you automate agreements
There are challenges, but active solutions exist
You can try blockchain yourself without cost

What Comes Next

In the next article, we’ll dive into what happens when you send a transaction - from your wallet all the way to confirmation on the blockchain.

I’d really appreciate your questions or feedback. Did something confuse you? Let me know. Your insights help shape the next articles.

🤝 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.

See you in Article 2.

DEV Community: Hemapriya Kanagala

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

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

Frameworks Are No Longer Being Designed Only for Humans

Table of Contents

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

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

Table of Contents

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

The Last Developer Museum: From Stack Overflow to AI

Exhibit 01 - The Forum Developer (1998 – 2007)

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

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

Exhibit 04 - The Tutorial Era (2015 – Present)

Exhibit 05 - The Senior Developer

Exhibit 06 - The AI Era (2022 – Present)

Exhibit 07 - The Lost Rituals

Final Exhibit - The Developer, Unchanged

🤝 Stay in Touch

Gemma 4 and the Economics of AI Access

Table of Contents

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

Why Gemma 4 Matters More Than Its Benchmarks

Table of Contents

1. `register(name, age, email)`

2. `updateProfile(name, age, email)`

3. `getProfile()`