DEV Community: Athar

Canopy: Offline Bird Detection for 6,000+ Species with open Birdnet model

Athar — Sat, 10 Oct 2026 17:30:13 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass.

What I Built

I built Canopy, a local-first Android birding companion that identifies
bird calls across 6,000+ species using the open BirdNET model.

Canopy is designed for hikers, birdwatchers, families, and anyone curious about
the sounds around them. Instead of constantly looking at a screen, users can
start a listening session, put their phone away, and explore their surroundings.

As users walk and listen, Canopy:

Identifies birds from microphone audio.
Works locally, including in areas without internet access.
Records species, confidence, time, and optional location.
Builds a Pokémon-style collection of detected birds.
Tracks how many times each species has been heard.
Creates offline birding challenges.
Uses Android's built-in text-to-speech to announce detections.
Optionally uses local Gemma to create personalized summaries and challenges.

The goal is simple: make the screen the shortest part of the experience.

Demo

Watch the Canopy walkthrough:

Demo video: https://youtu.be/71nXyElfp1c

Code

The complete open-source project is available on GitHub:

Repository: https://github.com/atharhive/canopy

Beta release: https://github.com/atharhive/canopy/releases/tag/v5.4.0-gemma-beta

Canopy is released under the GNU General Public License v3.

How I Built It

Canopy is an Android application built with Kotlin, Java, Gradle, and Android
SDK API 35.

Bird detection

The core detection pipeline uses the open BirdNET model to analyze microphone
audio and identify likely bird species. The model supports recognition across
more than 6,000 bird species.

The detection flow is:

Microphone audio
      ↓
Local audio buffer
      ↓
BirdNET classifier
      ↓
Species and confidence score
      ↓
Local observation database
      ↓
Collection card and challenge

BirdNET remains the source of truth for species identification. The optional
language model never replaces or changes the detected species.

Local Gemma integration

Canopy optionally downloads a quantized Gemma 3 1B instruction-tuned model
separately from the APK. The model runs locally through the MediaPipe GenAI
runtime.

Gemma can:

Turn a BirdNET result into a short natural-language explanation.
Create personalized challenges from collected species.
Answer questions about a user's bird collection.
Suggest ways to explore and listen during future walks.

Gemma is not required for the app to work. Without it, Canopy uses deterministic
offline summaries and challenges.

Privacy-first narration

Canopy uses Android's built-in Text-to-Speech engine for local narration. No
ElevenLabs API key or cloud voice service is required.

The local narration flow is:

BirdNET detection
      ↓
Optional Gemma summary
      ↓
Android offline Text-to-Speech

If Gemma is unavailable, Canopy automatically falls back to a short local
summary such as:

“European Robin detected with 91 percent confidence.”

Collection and challenges

Every detected species can become a collectible card containing:

Bird name
Best confidence score
Number of detections
Collection date
Observation history

Canopy also includes offline challenges, including:

Discover a new species.
Hear two different birds before lunch.
Record a detection above 70% confidence.
Find a species at sunrise or sunset.
Build a five-species collection.
Improve an existing card with a higher-confidence detection.
Revisit a favorite location and look for a new bird.

Why Does Open Innovation Matter?

Open innovation made Canopy possible as a private, offline outdoor experience.

A closed cloud API would require users to upload audio recordings and
potentially location data to a remote service. It would also make the app
dependent on:

Internet connectivity.
API availability.
Usage limits.
Per-request costs.
A vendor-controlled model and experience.

With open models and local inference, Canopy can:

Work on trails with no signal.
Keep recordings and observations on the device.
Avoid sending location history to a third party.
Reduce operating costs.
Let the model and inference pipeline evolve independently.
Provide a usable fallback even when Gemma is not installed.
Give users more control over their data and tools.

The open pieces are not decorative additions. BirdNET powers the central
identification experience, while optional local Gemma adds contextual
explanations and personalized challenges.

Prize Categories

Best Use of Gemma

Canopy uses a downloaded, quantized Gemma model locally to:

Generate short explanations for BirdNET detections.
Create custom challenges from the user's collected species.
Answer questions about the user's collection.
Provide personalized outdoor exploration prompts.

Best Use of GitHub Copilot

Copilot assisted with the development workflow, including:

Android UI implementation.
Local narration integration.
Collection and challenge features.
Build troubleshooting.
Release preparation.
Documentation and testing guidance.

The Vision

Canopy is built around a simple idea:

Technology should help people notice more of the world, not demand more
attention from them.

The app helps users identify what they hear, then encourages them to put the
phone down and continue exploring.

The next bird is not inside the screen.

It is somewhere outside. 🐦

Gemini CLI Is My Weirdest AI Productivity Hack?

Athar — Thu, 05 Mar 2026 20:57:17 +0000

I use a lot of AI tools—coding like copilot, agents, chat tools, and IDE integrations. But one tool somehow became one of the most used parts of my workflow: Gemini CLI.

What started as curiosity turned into something much bigger. Over time I began using it for everything: setting up repositories, writing documentation, generating architecture plans, and even running multiple AI “workers” from different terminal tabs. At some point, it stopped feeling like just another AI tool and started feeling more like an experimental productivity engine.

In This Article I'll talk about

The strange reason Gemini CLI never seems to hit limits for me
My workflow of running multiple AI terminals at once
How I generate architecture docs and MVP plans in minutes
A crazy experiment where I generated dozens of projects automatically
The story of building a working CLI tool in 2.5 hours
Things Gemini CLI does better than most AI coding tools
And a few things that seriously need improvement

How I Started Using Gemini CLI

When I first heard about Gemini CLI, two things stood out:

A very large context window
A generous usage model compared to many other AI tools

Naturally, I wanted to test it.

What surprised me the most was something unexpected. While testing it with friends, they would often hit usage limits relatively quickly—sometimes after around a hundred requests. Meanwhile,** my sessions kept going. I could continue making requests, generating code, and experimenting without running into token limits. ** It's the same even now 😭

Friends joked that I was somehow exploiting Gemini CLI and that someone from Google team would eventually reach out to me for my weird use cases.

I still don’t know why that happened, but it gave me the freedom to experiment with some unusual workflows.

One Instruction Repository Setup

One of the first practical uses I discovered was using Gemini CLI to set up entire project repositories with a single instruction.

Normally, starting a project involves a lot of repetitive setup:

creating folders
configuring dependencies
setting up linting and formatting
writing base documentation
preparing project architecture

With Gemini CLI, I started doing something much simpler. I would give it one instruction describing the project and the development stack, and it would generate the entire project scaffold.

This includes directory structure, configuration files, dependencies, and even initial documentation. Instead of spending time on boilerplate setup, I can immediately start focusing on the actual idea.

My Multi-Terminal Gemini Workflow

One of the most unusual ways I use Gemini CLI is by running multiple sessions simultaneously.

Instead of relying on a single AI interaction, I open several terminal tabs and assign different responsibilities to each one. Each session acts like a separate worker focused on a specific task.

For example:

one session generates system architecture

another handles frontend implementation

another builds backend logic

another writes documentation

All of these run at the same time.

It feels a little chaotic, but it also dramatically speeds up development. Instead of waiting for one step to finish before starting the next, everything progresses in parallel.

My Implementation Plan System

To make this workflow manageable, I usually start by generating an implementation plan.

These plans break the project into smaller steps and tasks. I store them as files such as:

implementation-1.4.md
implementation-1.5.md

Each file contains:

implementation steps
expected outputs
technical constraints

Once these plans are ready, I distribute tasks across multiple Gemini CLI sessions. One session might implement step 1.4, another step 1.5, and another writes documentation explaining both.

This structured approach turns Gemini CLI into something that feels surprisingly close to a small development team.

Why I Use Gemini CLI for Documentation

Another place where Gemini CLI shines is documentation.

I frequently use it to generate:

README files
architecture documentation
MVP planning documents
project explanation guides
system diagrams and architecture descriptions

Because the context window is large, I can provide the full project structure and ask it to generate complete documentation around it.

Some friends even asked how I was able to produce so many structured docs without constantly hitting AI limits. At the time I didn’t reveal the tool, but the answer was simple: Gemini CLI.

Research and Package Discovery

One capability that stands out compared to many AI coding agents is research.

Many tools struggle when asked to find the right libraries, frameworks, or documentation. They often suggest outdated packages or incomplete solutions.

Gemini CLI performs much better in these scenarios, likely because it leverages the broader search ecosystem connected to Google.

When I ask it to find a package, evaluate libraries, or read documentation to determine the correct dependency, it tends to produce much more reliable results.

This is particularly useful when setting up new stacks or integrating unfamiliar tools.

Now few cool stories I have with Gemini cli

The 40-Project Experiment

One of the first major experiments I tried with Gemini CLI was intentionally extreme.

I found a repository on GitHub containing around fifty small web development projects. Instead of building them manually, I selected forty of those projects and asked Gemini CLI to analyse them and generate new versions inspired by them.

The instruction was simple: use the existing projects as inspiration but rewrite them with modifications, improved functions, and additional features.

The process ran for several hours. When it finished, Gemini CLI had produced roughly forty projects with altered logic and added functionality.

They were not perfect, and some contained bugs, but a surprisingly large portion worked correctly. For me, this experiment demonstrated how powerful AI-assisted code generation could become when given sufficient context.

Rewriting Full-Stack Projects

After seeing the results of the first experiment, I tried something more difficult.

This time I found a repository containing multiple full-stack projects built with the MERN stack. I selected ten of those projects and asked Gemini CLI to analyze and rewrite them with structural modifications.

Again, the results were not flawless, but many applications ran successfully with minimal adjustments. The fact that such large transformations could be generated automatically was impressive.

Building a Hackathon Project in Two and a Half Hours

One of my most memorable uses of Gemini CLI happened during a hackathon organized by Major League Hacking.

The challenge involved using MongoDB alongside Gemini.

I didn’t have much time to code, so I decided to rely heavily on Gemini CLI. The project I built was a tool called GitWhisperer.

The idea behind it was simple:

store commit messages in MongoDB
analyze commits using the Gemini API
generate summaries of development progress
automatically create demo explanations for completed projects

Gemini CLI helped design the architecture, structure the CLI application, and implement the functionality. The entire project was completed in roughly two and a half hours.

For a working command-line tool connected to external APIs, that speed was remarkable.

Now, Things I Think it Could Improve

Even though Gemini CLI is extremely useful, there are still areas where improvements would make it significantly better.

One limitation is the lack of straightforward image input support. Being able to pass screenshots, diagrams, or UI images directly into the CLI workflow would help with debugging and interface design.
Another issue is code visibility. Sometimes the CLI shows only partial code changes until they are approved. It would be helpful to preview the entire generated code before applying modifications.
Session management is another area that could be improved. Currently, sessions often need to be saved manually. Automatic session recovery and resume functionality would make long development sessions more reliable.
Performance could also be better. Installation can be resource-heavy, and even simple tasks sometimes require significant memory. A more lightweight implementation—possibly built with languages such as Go or Rust—could improve efficiency.

Why I Still Use It Every Day?

Despite these issues, Gemini CLI has become one of my favorite tools.

I regularly use it for:

documentation generation
architecture planning
repository setup
research and package discovery
rapid prototyping

More than anything, it enables experimentation. Running several sessions simultaneously and assigning different tasks makes development feel surprisingly dynamic.

It sometimes feels less like using a single AI assistant and more like coordinating a small team of automated developers.

Final Thoughts

AI tools often try to replace existing workflows. Gemini CLI fits differently into the process.

Instead of replacing the workflow, it becomes an extension of it.

For me, it has turned into a flexible system for experimentation, automation, and rapid idea exploration. If you enjoy building things quickly and experimenting with AI-assisted development, it is definitely a tool worth trying.

Kiro Somehow Replaced My Favourite CLI Overnight

Athar — Fri, 05 Dec 2025 19:13:31 +0000

When AWS announced that Kiro is officially GA (Nov 17, 2025), I figured I’d skim the release notes, bookmark a few things, and play with the new toys over the weekend.

Yeah… that didn’t happen.
Because within a few hours, Kiro casually replaced one of my favorite CLIs ever — and I didn’t even see it coming.

Kiro : More Than Just Another Update

**
I’ve been a fan of Kiro for a while now — the vibe-coding experience, the spec-driven workflow, the smooth MCP integration, and those clever hooks that make everything feel almost alive.

But the GA release introduced something new that immediately stood out:

The brand-new Kiro CLI.

And not just as a standalone tool — it’s deeply woven into the Kiro IDE in a way that makes both feel smarter together.

Naturally, I planned to take it for a spin later.
Naturally, AWS had other plans for me.

😄Goodbye Q CLI… Hello Kiro CLI

While jumping through the docs, I noticed one line that made me blink twice:

Kiro CLI now replaces the Amazon Q Developer CLI.

Yep.
My go-to CLI — the one I’ve used day in, day out — was quietly swapped out for… another one of my favourite dev tools.

Honestly?
It felt like my IDE had staged a friendly coup.

⚡ The Upgrade Took Exactly One Command

If you’re already logged in to the Q CLI, upgrading is hilariously simple:

q update

That’s it. One command.
A second later, my entire dev environment was reborn as the Kiro CLI.

No broken configs.
No re-auth headaches.
Even my existing MCP setups recognized Kiro instantly.

AWS didn’t just ship an upgrade — they delivered a teleportation.

Why This Matters: Kiro Isn’t Just a Tool, It’s a Shift

Kiro isn’t just “a new AWS product.”
It feels like AWS is leaning all the way into conversational, intelligent, context-aware development.

And the secret sauce behind that shift?

Introducing Kiro Powers: The Feature That Changes Everything

This is where things get wild.

Modern AI tools have a big problem:
They’re smart, but not smart enough about your actual tools, frameworks, and workflows.

❌ Without context, AI agents guess

They don’t automatically know:

best practices for Stripe checkout

connection pooling patterns for Neon

how to structure Supabase calls

when to use idempotent keys

or what the “right” approach is for frameworks you don’t use every day

So you end up debugging your AI instead of debugging your code.

❌ With too much context, agents slow down

Load 5 MCP servers?
Congrats — your model now burns 50K+ tokens before writing a single line of code.

Your agent becomes “smart but sluggish,” drowning in irrelevant tool definitions.

❌ And AI dev tools today feel… fragmented

Claude Skills here.
Cursor rules there.
MCP configs everywhere.
Dynamic tool loading in its own world.
Switch IDEs? Redo part of it.

Developers want one thing:

“Just install Stripe and let my agent instantly know how to use Stripe correctly.”

Not:
“Configure eight different files across three clients and pray.”

⚙️ Kiro Powers Fix All of This

A Kiro power is basically:

A bundle of tools, context, expertise, and best practices — loaded only when you need them.

Like The Matrix, but for dev.

A power includes:

POWER.md — a steering brain that teaches the agent how to use the tool

MCP configuration — all the actual tool endpoints

Optional rules/hooks — behaviors and workflows

And the magic trick?

🟢 Powers load dynamically

Mention “checkout”? Stripe power activates.
Switch to “database”? Neon pops in, Stripe quietly steps away.
Jump to “deploy”? Netlify steps up.

Your context window stays clean.
Your agent stays fast.
Your tools feel alive.

Kiro launched with a seriously stacked partner lineup:

Stripe

Supabase

Neon

Figma

Postman

Netlify

Datadog

Dynatrace

Strands

Amazon Aurora
…with more on the way.

Plus the community has already started building:

SaaS builder powers

AWS CDK infrastructure powers

Aurora DSQL helpers

Instead of “finding the right MCP server,” you now just… install a power.

Your agent becomes an expert instantly.

🧑‍💻 What This Means for Me (and Probably You)

The moment Kiro CLI replaced Q CLI, I realized AWS wasn’t just iterating — they’re redefining the workflow.

This is dev tooling that adapts to you.
It listens. It loads context only when needed.
It knows best practices out of the box.
It makes agents feel more like collaborators rather than clever autocomplete.

And honestly?

It feels like the closest thing we have to a universal “developer brain” that plugs into your stack.

Wrapping Up

I started the day thinking I’d casually test a new CLI.
Instead, I watched one of my most-used tools transform into something smarter, faster, and genuinely exciting.

Kiro GA isn’t just an AWS release.
It’s a hint at where developer tooling is headed — unified context, dynamic intelligence, and agents that actually know what they’re doing.

And re:Invent 2025?
I’m suddenly way more curious about what surprises the Kiro team still has up their sleeve.