DEV Community: Hala Kabir

Needing Help for Missing 100 Days of Solana challenge -Hala Kabir

Hala Kabir — Mon, 01 Jun 2026 12:27:42 +0000

@niranjannlc please can you help or ask somone for help ....

Hi everyone,

I need some help regarding the 100 Days of Solana challenge.

I completed Day 39 and Day 40, but the next email I received was Day 43. I didn't receive any emails for the days in between. I also remember something similar happening earlier where I never received Day 35.

Could someone please check if they received:

* Day 35
* Day 41
* Day 42

If you did receive them, could you let me know whether those days actually exist in the email sequence?

And if possible, would you be willing to share the challenge links or forward the exact emails to me? I don't want to miss any lessons or fall behind because of missing emails.

Thanks a lot for any help!

Understanding Hermes Agent: Why Agentic AI Is More Than Just a Chatbot

Hala Kabir — Sun, 31 May 2026 19:19:04 +0000

Artificial intelligence has advanced rapidly over the last few years, but many AI systems still operate as simple chat interfaces. They can answer questions, generate text, and assist with tasks, yet they often stop at a single response.

This is where agentic AI becomes interesting.

Hermes Agent is an open-source agent framework designed to go beyond traditional chatbot interactions. Instead of only responding to prompts, it can plan tasks, use tools, and work through multiple steps before producing an answer.

What Makes Hermes Agent Different?

One of the biggest differences between a standard chatbot and an AI agent is the ability to take action.

A traditional chatbot might answer:

"What is the current gold price?"

An agent, however, can follow a process:

Retrieve information from a tool or data source.
Analyze the information.
Compare findings with additional context.
Generate a useful summary.

This approach allows the AI to solve more complex problems rather than simply responding with a single generated answer.

The Power of Multi-Step Reasoning

Many real-world tasks cannot be completed in one step.

Research, software development, data analysis, and automation often require a sequence of actions. Hermes Agent is designed with this idea in mind.

Instead of jumping directly to an answer, the agent can break a larger goal into smaller tasks and work through them logically. This creates a workflow that feels much closer to how humans approach problem-solving.

Why Tool Use Matters

Tool use is one of the most important capabilities in modern AI agents.

Without tools, an AI model is limited to the information available within the model itself. With tools, the agent can interact with external systems, retrieve information, and perform actions that would otherwise be impossible.

This capability significantly expands the types of problems an agent can help solve.

Why Open Source Is Important

Another aspect that makes Hermes Agent compelling is its open-source nature.

Developers can inspect how the system works, customize workflows, integrate new tools, and run the agent on their own infrastructure. This level of transparency and flexibility is important as AI systems become increasingly capable.

Open-source development also encourages experimentation and innovation by allowing the community to contribute improvements and new ideas.

My Take

What excites me most about Hermes Agent is not its ability to answer questions. Many AI systems can already do that.

The more interesting shift is toward AI systems that can reason through tasks, use tools effectively, and execute workflows. As AI continues to evolve, I believe these agentic capabilities will become increasingly important.

Hermes Agent represents an interesting step in that direction by combining planning, tool use, and multi-step reasoning within an open-source framework that developers can explore and build upon.

Whether you are interested in AI research, automation, or building intelligent applications, Hermes Agent is a project worth paying attention to.

From Basic Tokens to Soulbound Assets: What I Learned Building on Solana Token-2022 -Hala Kabir

Hala Kabir — Mon, 25 May 2026 21:33:02 +0000

From Basic Tokens to Soulbound Assets: What I Learned Building on Solana Token-2022

Over the past few days, I went from knowing almost nothing about Solana tokens to building Token-2022 assets with metadata, transfer fee mechanics, and even non-transferable “soulbound” tokens.

Coming from a more Web2 mindset, one of the biggest realizations for me was this:

On Solana, token behavior is enforced directly by the blockchain protocol itself not just by application code.

That completely changed how I think about digital assets.

Starting With a Simple Token

My journey started with creating a basic token mint on Solana devnet.

At first, it felt similar to creating records in a database:

create a mint
create token accounts
mint supply
transfer between wallets

But after experimenting more deeply, I realized Solana tokens are much more programmable than I expected.

Using the Token-2022 program, I could attach rules and behavior directly to the token itself.

Adding Metadata to Tokens

One of the first things I learned was that a token without metadata is basically just an address.

Adding metadata gave the token:

a name
a symbol
a metadata URI

Example:

const mint = await createMint(
  connection,
  payer,
  payer.publicKey,
  null,
  9,
  undefined,
  undefined,
  TOKEN_2022_PROGRAM_ID
);

This made the token feel more like a real product instead of raw blockchain data.

Understanding Transfer Fees

The next concept I explored was transfer fees.

In Web2 systems, fee logic is usually handled by:

backend servers
payment processors
APIs

But with Token-2022, fee behavior can be attached directly to the token design itself.

I simulated a 2% transfer fee model where:

sending 100 tokens
resulted in the recipient receiving 98
while 2 tokens were treated as fees

That was the moment I started understanding how blockchain protocols can enforce economic rules at the asset level.

The Most Interesting Part: Soulbound Tokens

The most fascinating experiment for me was creating non-transferable tokens.

These are sometimes called “soulbound” tokens.

Instead of behaving like currency, they behave more like:

certificates
badges
credentials
identity proofs

I created a Token-2022 mint and intentionally simulated a failed transfer attempt.

TRANSFER FAILED
Reason: Token is NON-TRANSFERABLE
Blockchain rejected transfer attempt

At first this seemed strange because most blockchain discussions focus heavily on trading and transfers.

But then it clicked:

Not every digital asset should be tradable.

A university certificate, event attendance badge, or verified identity token only has meaning if it stays attached to the original wallet.

That is where non-transferable tokens become powerful.

What Surprised Me Most

The biggest surprise was how much token behavior can be enforced at the protocol level.

In Web2:

platforms enforce rules in backend code

On Solana:

the blockchain itself can enforce those rules

That changes the trust model completely.

Another thing that surprised me was how quickly tooling differences appear between environments. Some Token-2022 CLI commands were unavailable in Solana Playground, so I had to adapt by using TypeScript implementations instead.

That debugging process honestly taught me a lot more than just following tutorials.

Key Concepts I Learned

Over these exercises, I learned:

how token mints work
how token accounts hold balances
how metadata gives identity to assets
how transfer fee systems operate
how Token-2022 extends the original SPL token standard
how non-transferable tokens can represent credentials instead of currency

Why Token-2022 Matters

Before this challenge, I thought tokens were mostly about cryptocurrencies.

Now I see them more as programmable digital assets.

A token can represent:

money
reputation
access
memberships
achievements
credentials

And Solana’s Token-2022 program gives developers much more flexibility in designing those systems.

What’s Next

I want to continue exploring:

advanced Token Extensions
NFTs and compressed NFTs
on-chain identity systems
Solana program development
real-world Web3 applications

This challenge gave me a much deeper appreciation for how blockchain systems can move beyond speculation and become infrastructure for digital ownership and identity.

                      # Have a Coderfull Day

The Biggest Google I/O 2026 Announcement Wasn’t a Model -Hala Kabir

Hala Kabir — Sun, 24 May 2026 18:59:02 +0000

When people talk about Google I/O 2026, most conversations will probably focus on Gemini’s newest models and multimodal AI capabilities.

But after watching the developer keynote, I think the most important announcement was something bigger than a model release.

It was Google’s vision for agent-first development through Antigravity.

More than any individual demo, the keynote showed a shift in how software may be built in the future: developers increasingly defining goals and workflows while intelligent agents handle execution.

From AI Assistants to AI Agents

One line from the keynote stood out to me:

“The big shift is our move towards agents, from AI that simply assists you to agents that help you get stuff done.”

That idea appeared throughout the entire presentation.

For the past few years, most AI tools for developers have worked like enhanced assistants:

autocomplete,
debugging help,
code suggestions,
or documentation summaries.

Google’s demos at I/O 2026 felt different.

Instead of simply helping developers write code faster, Antigravity focused on agents that can:

execute workflows,
manage tasks,
coordinate tools,
provision environments,
and operate with increasing autonomy.

That distinction matters.

The keynote wasn’t just about AI-generated code. It was about software workflows becoming agent-driven.

Antigravity Was the Real Star of the Show

The most interesting part of the keynote for me was how everything connected back to Antigravity.

Google introduced:

managed agents,
dynamic subagents,
scheduled tasks,
sandboxed execution environments,
Android integrations,
terminal workflows,
and tooling built specifically for AI-native development.

What stood out most was that Google positioned Antigravity not as a chatbot, but as infrastructure for orchestrating intelligent systems.

That feels like a major shift.

Managed Agents Solve a Real Problem

One of the smartest announcements was managed agents inside the Gemini API.

Building AI agent systems normally requires developers to handle:

orchestration,
execution environments,
scaling,
security,
and infrastructure management.

Google’s approach simplifies this dramatically:

one API call gives developers both the agent and the execution environment.

The Stitch demo showed this clearly. Their agent connected to a GitHub repository, analyzed the codebase, and automatically generated a design system file.

Not just text generation.

Actual development workflow automation.

And importantly, Google emphasized that developers can focus on building experiences instead of managing infrastructure complexity.

“Markdown Is the Hottest Programming Language”

One of the most memorable moments came when Logan Kilpatrick joked:

“Honestly, it feels like the hottest new programming language is Markdown.”

It was funny, but also surprisingly accurate.

Many of the workflows shown in the keynote relied on defining:

instructions,
tools,
skills,
and orchestration logic

through Markdown-based configurations.

That changes the role of developers.

Instead of manually implementing every process step-by-step, developers increasingly define intent, constraints, and capabilities while agents coordinate execution.

In many ways, developers are becoming orchestrators of intelligent systems rather than only writers of low-level implementation logic.

AI Studio Is Becoming a Real Development Platform

Another major takeaway was how quickly Google AI Studio is evolving.

The keynote demonstrated:

app generation,
Cloud Run deployment,
Android app creation,
Firebase integration,
Google Workspace integrations,
and Play Store publishing.

At this point, AI Studio feels much closer to an AI-native development environment than a simple experimentation playground.

The Android demos especially stood out to me. Seeing Kotlin Android apps generated, previewed, tested, and prepared for publishing through agent workflows felt like a preview of how development may look in the near future.

What excites me most is not replacing developers.

It’s reducing friction.

A huge amount of software development time is spent on:

setup,
configuration,
repetitive debugging,
deployment steps,
and environment management.

If agents can reliably reduce that overhead, developers can spend more time focusing on:

architecture,
user experience,
product thinking,
and solving meaningful problems.

The Web Announcements Were Quietly Important

The Chrome and web platform demos may end up being some of the most underrated announcements from the keynote.

Features like:

WebMCP,
Modern Web Guidance,
and Chrome DevTools for agents

suggest that Google is preparing the web itself for AI-native interaction.

The idea that websites can expose structured capabilities directly to browser agents feels like the early foundation of an “agentic web.”

One detail I found especially interesting was the emphasis on accessibility metadata and semantic structure. As browser agents become more capable, accessibility may become even more important because agents rely heavily on structured understanding of interfaces.

That’s a fascinating shift.

Final Thoughts

Google I/O 2026 showcased impressive AI models and polished demos, but I think the deeper story was about the evolution of software development itself.

The keynote presented a future where:

agents collaborate,
workflows become autonomous,
environments provision themselves,
and developers focus more on defining outcomes than manually implementing every step.

We are moving from:

“How do I build this?”

to:

“How do I define what I want built?”

And I think Google Antigravity may end up being one of the most important steps toward that future.

This article was written after watching the Google I/O 2026 developer keynote and reflecting on the direction of agent-first development.

--> By Hala Kabir

🚀 Looking for Android Beta Testers – EcoQuantum Solution 🌍💚 Hello DEV Community!

Hala Kabir — Sun, 24 May 2026 04:36:58 +0000

We recently launched the beta version of EcoQuantum Solution, a youth-led AI & sustainability platform focused on climate awareness, smart technology, and social impact.

We are currently looking for Android beta testers who can help us by:
✅ Testing app performance
✅ Reporting bugs or crashes
✅ Giving honest UX feedback
✅ Suggesting improvements before wider rollout

If you’re interested in supporting an early-stage mission-driven startup, feel free to comment or DM your Gmail address for access to our Google Play closed testing track.

Your feedback can help us improve the app and create better technology for humanity. 🌱✨

Android #BetaTesting #GooglePlay #AI #ClimateTech #Startup #DEVCommunity #EcoQuantumSolution

🚀 Looking for Android Beta Testers for EcoQuantum Solution 🌍

Hala Kabir — Sat, 23 May 2026 18:54:53 +0000

Hello developers and tech enthusiasts!

We recently launched the early version of EcoQuantum Solution — a youth-led AI & sustainability platform built to create technology for climate awareness and social impact.

We are currently looking for Android testers who can help us by:
✅ Testing app stability
✅ Reporting bugs/issues
✅ Giving honest UX feedback
✅ Suggesting improvements

If you are interested in supporting an early-stage mission-driven startup, feel free to comment or DM your Gmail address for beta access.

Your feedback can help us improve the app before wider public rollout. 💚

AndroidTesting #BetaTesting #AI #ClimateTech #Startup #OpenSource #GooglePlay #EcoQuantumSolution

Building EcoQuantum Solution: An AI-Powered Disaster Monitoring MVP 🌍🚀

Hala Kabir — Sat, 23 May 2026 18:49:30 +0000

Hi developers 👋

I’m currently building EcoQuantum Solution, a climate-tech project focused on environmental monitoring, disaster awareness, and AI-powered risk detection.

The current MVP, EcoGuard AI, is being developed using:

Python + FastAPI
React frontend
AI-based monitoring workflows
Real-time dashboard concepts
One of the biggest challenges has been maintaining stable frontend/backend communication while scaling features step by step.

I’m sharing this project to learn publicly, improve the architecture, and get feedback from the developer community.

Would love feedback on:

API structure
frontend/backend integration
scalability
dashboard UX

climate-tech architecture ideas
Open to collaboration, mentorship, and technical suggestions.

Solana’s Account Model: A Web2 Developer’s Guide to On-Chain Storage - Hala Kabir

Hala Kabir — Sat, 16 May 2026 18:23:47 +0000

If you are a Web2 developer dipping your toes into Web3, the word "account" probably conjures up images of user profiles, usernames, and passwords stored securely inside a database table.

When you move over to blockchain networks like Ethereum, an account is either a wallet (Externally Owned Account) or a smart contract.

But then you get to Solana, and suddenly everyone is screaming, "Everything is an account!" Your wallet? An account. A smart contract? An account. A random piece of data or an NFT metadata file? You guessed it—an account. If this sounds incredibly confusing, don't worry. Today, we are pulling back the curtain on Solana’s account model using structural concepts you already know from traditional computing.

The Ultimate Analogy:

Think of Solana as a Linux Filesystem
If you want to understand Solana without getting bogged down in crypto jargon, think of the entire Solana blockchain as a massive, decentralized Linux Filesystem, and the core network software (the System Program) as the operating system kernel.

In this model:

Every account is simply a file.

The public key (address) of the account is the file path (e.g., /user/documents/wallet).

The data inside the account is the contents of the file.

The ** metadata ** dictates the file permissions and details.

Just like a filesystem handles configuration files, image files, and executable script files using the exact same underlying disk structure, Solana stores wallets, tokens, and code inside the exact same account format.

🕵️‍♂️ The 5 Hidden Fields:

In Every Solana FileWhenever you use the Solana Command Line Interface (CLI) to look up an address under the hood, the network returns the exact same 5-field **metadata layout for every **single object on the ledger. Let's look at what a raw account looks like:

JSON{
  "public_key": "Config1111111111111111111111111111111111111",
  "balance": "0.00114144 SOL",
  "owner": "BPFLoaderUpgradeable11111111111111111111111",
  "executable": true,
  "data_length": 1024,
  "rent_epoch": 18446744073709551615    
}

Every single account shares these exact five fields:

Lamports (Balance): The amount of fractional SOL this account holds. (Note: $1\text{ SOL} = 1,000,000,000\text{ lamports}$).
Data Length & Data Array: A raw byte array allocated to store custom state or compiled program bytes.
Owner: The public key of the specific smart contract program authorized to write data to this file.
Executable: A simple boolean flag (true or false). If it is true, it means this account contains compiled code that can run. If it is false, it's just a data folder or a wallet.
Rent Epoch: A legacy field now permanently set to a maximum placeholder value for all modern rent-exempt accounts.

The Mind-Bending Twist:

Programs Are Stateless!
Here is the concept that completely shocks Web2 engineers when they first build on Solana: Smart contracts (programs) cannot store data inside themselves.

In Ethereum or traditional backend architecture, a class or smart contract often maintains its own state variables internally. If you have a counter program, the counter variable lives right inside the code.

Not on Solana. On Solana, programs are completely stateless.

Think of a Solana smart contract like an isolated Nginx web server or a Docker container. The container holds the code to process requests, but it cannot save files locally. If it needs to read or update a user's data, it must reach out to an entirely separate, external file (a data account) passed into it during the transaction.

Program Account:

** Has Executable:** true. It only holds immutable, executable logic.

Data Account:

** Has Executable:** false. It only holds raw data bytes and balances.

The Security Model:

strict Ownership Rules
How does Solana keep everything secure if programs are constantly modifying external data files? The network enforces a beautifully simple, ironclad security rule:

Only the program designated as the "Owner" of an account can modify its internal data or debit its Lamport balance.

Think of it like file permissions. Anyone can look at a public file, and anyone can drop extra money (credit lamports) into a wallet file. But only the specific owner program has the cryptographic permission to write changes to that file's data array or spend its money. If a malicious user tries to bypass this, the operating system kernel rejects the transaction instantly.

Paying Your Digital Property Tax:

Rent Exemption
Space on a high-speed blockchain ledger is premium real estate. Because validators have to keep active accounts loaded in RAM **for **maximum speed, you cannot store data on-chain for free.

To keep the network clean, Solana uses a mechanism called Rent Exemption.

When you create a new account file, you must deposit a small minimum amount of SOL proportional to the size of the data bytes you want to store. Think of it like a security deposit for apartment rental. As long as your account holds that minimum balance, it stays "rent-exempt" and will live on the blockchain forever without ever losing funds. For a standard layout, this is usually just a tiny fraction of a single SOL token!

Summary

Transitioning from Web2 to Solana becomes incredibly intuitive once you realize that the blockchain isn't a magical black box—it's just a globally shared, high-performance operating system. By separating stateless code execution from organized, heavily-permissioned data files, Solana achieves the blazing-fast transaction speeds it is famous for.

Beyond "Send": Tracking the Life Cycle of a Solana Transaction - Hala Kabir

Hala Kabir — Sat, 09 May 2026 12:19:44 +0000

Most developers coming from Web2 expect a transaction to be like an HTTP request: you send it, you get a 200 OK, and you're done. On Solana, I realized that "sending" is only the beginning. The real magic happens in the "Commitment Ladder."

In my journey through the 100 Days of Solana, I recently built a SOL transfer tool. While building it, I moved away from "fire-and-forget" transactions to a manual polling system that tracks how the network actually reaches consensus.

Core Content: The Three Stages of Truth

When you send a transaction on Solana, it doesn't just "succeed" instantly. It climbs through three specific commitment levels:

Processed 🟠: The transaction was included in a block by a validator. It’s "on the map," but not yet set in stone.

Confirmed 🟢: A supermajority (over 66%) of the network has voted that the block is valid. At this point, it’s highly unlikely to be reversed.

Finalized 💎: The block is now a permanent part of the ledger. This is the "Gold Standard".

Learning from Failure

I learned the hard way that Solana is strict. During my build, I ran into a base58-encoded address error because my recipient address was 45 characters instead of 44. Unlike a loose Web2 API, Solana’s cryptographic requirements mean even a single extra letter will cause a panic.

Code Snippet: Manual Polling

Instead of using built-in helpers, I wrote a manual polling function to watch these statuses move in real-time. This gave me a front-row seat to the blockchain's consensus process.

async function waitForCommitment(rpc, signature, commitment) {
    while (true) {
        const { value: statuses } = await rpc.getSignatureStatuses([signature]).send();
        const status = statuses[0];
        if (status && status.confirmationStatus) {
            if (status.confirmationStatus === commitment) return;
        }
        await new Promise(r => setTimeout(r, 500));
    }
}

The Takeaway

The biggest mental shift for me was moving from "Request/Response" to "Atomic State Changes." A Solana transaction is an all-or-nothing package of instructions that requires a valid blockhash and specific signatures. If the faucet is empty or the address is one byte off, the whole thing fails—and that’s a feature, not a bug. It ensures the integrity of the global state.

Here's Proof:

Taming the Digital Chaos: Building My Own AI Text Refiner at 11 -Hala Kabir

Hala Kabir — Sun, 26 Apr 2026 13:40:37 +0000

This is a submission for the OpenClaw Writing Challenge
**
As a **young developer, my screen is often a whirlwind of tabs, code, and messy notes. Sometimes, my brain moves faster than my fingers, leaving me with notes that look more like random thoughts than actionable tasks. I realized I needed a "CatClaw" for my productivity—a tool that could catch my messy text and sharpen it into professional, clean content.

So, I built the CatClaw Refiner.

The Problem

Productivity is hard when you're overwhelmed. I wanted a simple interface where I could dump my brain-dump, hit a button, and get a polished result ready for emails, blog posts, or study notes.

The Solution:

** CatClaw Refiner**
I built this using FastAPI for the backend and Groq (Llama 3) for the AI heavy lifting. The goal was simplicity: a clean, responsive interface that talks to an AI to do the "polishing" work for me.

Why the Backend (FastAPI + Groq)?

I chose **Groq **because it is incredibly fast and offers a generous free tier for developers. Here is how I set up the main.py to handle the text refinement.

The Frontend:

I kept the UI clean with standard HTML/CSS. It keeps the focus on the task: inputting the mess, getting the output.

Want to see the code?

I believe in building out in the open. You can check out the full project, see how I structured the files, and even contribute your own "CatClaw" improvements on my GitHub repository here:

🔗 Check out the CatClawTasker Project on GitHub

ClawCon Michigan

I couldn't make it to ClawCon Michigan this year, but I followed the updates online and the energy in the community is truly inspiring. Seeing what other developers are building reminds me why I love coding—it's about creating solutions for real-world problems.

Final Thoughts

Coding at 11 years old is a wild ride, but projects like this make it worth it. If you have messy notes piling up, feel free to clone the repo and let the AI do the heavy lifting!

Thanks for reading! Let me know in the comments what productivity tools you're building!

Echoes of Experience: Building EcoGuard AI Through the Pressure by Hala Kabir.

Hala Kabir — Mon, 20 Apr 2026 19:16:37 +0000

Earth Day 2026 is here

, and with it, the critical need for tools that protect our environment. When I set out to build **EcoGuard AI, I didn't just want to create an app; I wanted to build a bridge between real-time data and actionable, human safety. I wanted to help people make smarter decisions based on their local weather and disaster risks.

The process, however, was far from linear.

My journey

began with a vision: a single interface where anyone could see the pulse of the earth—weather updates, earthquake alerts, and flood risks—translated into simple, daily advice. But between that vision and the final build lay the "Nightmare Debugger" phase. I faced unexpected API limits, frontend integration hurdles, and the looming deadline of a global challenge.

There were moments in the terminal when the code seemed to resist. There were times when the "Quota Exceeded" errors felt like a signal to stop. But each error was not a failure; **it was a map. I learned to build robust **fallback systems that ensure user experience never breaks, even when the data flow does.

EcoGuard AI is not just a tool; it is a testament to the fact that persistence in development is as important as the code itself.

I Need Your Help!

As I move into the final stages of this project, I find myself at a crossroads, and I would love to tap into the wisdom of this community. I’ve built the MVP, but I want to take the next step:

Deployment:

I have a FastAPI backend and a static HTML frontend. How would you recommend I deploy this app for free? I’m looking for the most efficient, beginner-friendly route to get this live for everyone to use.

Feedback:

I’ve put together a video walkthrough of the app to demonstrate the features and the "Earth Day" mission. Please check out this video and MY GitHub and tell me what improvements to make. I am all ears—whether it’s about the UI, the feature set, or the way I'm presenting the disaster data, your feedback will directly shape the next update.

Whether you are a student just starting your journey or a seasoned dev, remember: the value of your work lies in the process. Keep coding, keep debugging, and keep building for a better world.

Let me know your thoughts in the comments—I can't wait to learn from all of you!

I Built a "Mean Girl" AI to Judge Your Terrible Passwords 💅

Hala Kabir — Sun, 12 Apr 2026 14:17:40 +0000

I Built a "Mean Girl" AI to Judge Your Terrible Passwords 💅
This is a submission for the DEV April Fools Challenge

What I Built

I built The Sarcastic Strength Meter, a delightfully judgmental web app that doesn't just check your password strength—it roasts your entire existence. Instead of helpful tips like "add a special character," you get a high-pitched, high-attitude "Mean Girl" voice telling you that your security choices are "literally cringe, bestie."

It’s useless for security, but great for your ego (if you enjoy being bullied by a laptop).

Demo
Check out the Gnarly Roast Video here!

Code
Github

The project is built using a FastAPI backend and a vanilla HTML/JS frontend. It uses the Gemini 2.0 Flash API to generate unique, multi-sentence roasts on the fly.

The Backend (FastAPI + Gemini)
Python
@app.post("/roast-password")
async def roast_password(data: PasswordCheck):
    salt = random.randint(1, 1000000)
    prompt = f"Request ID: {salt}. User Password: '{data.password}'. Task: Write a 3-sentence sassy 'Mean Girl' roast paragraph. Use slang like 'bruh' and 'cringe'. Be gnarly."

    response = model.generate_content(prompt, generation_config={"temperature": 1.0})
    return {"roast": response.text.strip()}
The Frontend (Web Speech API)
JavaScript
function speakRoast(text) {
    const utterance = new SpeechSynthesisUtterance(text);
    utterance.pitch = 1.6; // The "Attitude" setting
    utterance.rate = 1.0;
    window.speechSynthesis.speak(utterance);
}

How I Built It

Python & FastAPI: For a lightning-fast backend.

Google Gemini API (2.0 Flash): To generate creative, non-repetitive insults. I used a high temperature setting to keep the AI unpredictable.

Web Speech API: To give the AI a physical "voice." By manipulating the pitch, I transformed a standard system voice into a gnarly, sassy personality.

CSS Animations:

For that "shaking in fear" effect whenever you submit a password.

Prize Category

I am submitting for the Best Google AI Usage and Community Favorite.

Why? Because using cutting-edge Generative AI to recreate the experience of being judged by a high school clique is the peak of 2026 technology. It demonstrates that AI can do more than summarize documents—it can also be "literally so mean, bruh."

Hala Kabir