dev.to top (week)

10 Open Source Tools Every Developer Should Know 🔥

Anthony Max — Mon, 25 May 2026 00:00:13 GMT

When studying a profession, we often encounter the fact that new knowledge gives us a feeling of the full picture, when everything becomes clearer.

As the industry develops, something new appears every day that gives more advantageous positions to those who know it. This was the case, for example, with the emergence of ChatGPT, knowledge of which gave people a huge advantage.

In this article, I tried to collect 10 projects, knowledge of which will help you become a great specialist.

Let's go!

1. 💎 Bifrost - Fastest enterprise AI gateway

To be honest, I can describe the project simply and quickly. If you want a powerful LLM Gateway for your project, and at the same time deploy it in a user-friendly interface without setting up a bunch of configs and other things, then this project is for you.

🌱 Star the Bifrost repository ☆

2. 👾 Godot - Free and open source 2D and 3D game engine

A truly legendary engine like Unity or Unreal Engine for games. If you are a game developer, you should know this project. From pet projects for the university to multi-million dollar games - it gives it all.

Godot Engine is a feature-packed, cross-platform game engine to create 2D and 3D games from a unified interface. It provides a comprehensive set of common tools, so that users can focus on making games without having to reinvent the wheel.

🌱 Star the Godot repository ☆

3. ▲ Turborepo - Build system optimized for JavaScript and TypeScript, written in Rust

Created by the same folks behind Vercel and Next.js, Turborepo is a high-speed build system that’s especially useful for monorepos.

Turborepo is a high-performance build system for JavaScript and TypeScript codebases, written in Rust.

🌱 Star the Godot repository ☆

4. 🐈‍⬛ Nest.js - A progressive Node.js framework for building efficient, scalable, and enterprise-grade server-side applications

If you’ve ever wished Express had a bit more structure, Nest.js is the upgrade you’ve been looking for. It brings TypeScript, OOP, and a modular architecture to Node.js development.

Nest is a framework for building efficient, scalable Node.js server-side applications. It uses modern JavaScript, is built with TypeScript (preserves compatibility with pure JavaScript) and combines elements of OOP (Object Oriented Programming), FP (Functional Programming), and FRP (Functional Reactive Programming).

🌱 Star the Nest.js repository ☆

5. ⚙️ GitMCP - free, open-source, remote MCP server for any GitHub project

The following project is a server implementing the MCP protocol that connects LLM directly to a GitHub repository.

GitMCP is a free, open-source, remote Model Context Protocol (MCP) server that transforms any GitHub project (repositories or GitHub pages) into a documentation hub.

🌱 Star the GitMCP repository ☆

6. 📁 Linux kernel - Linux kernel source tree

Now let's look at something truly colossal. The next project needs no introduction, but if anyone doesn't know, it's the kernel of the Linux operating system, which you may be using to view this article.

The Linux kernel is the core of any Linux operating system. It manages hardware,
system resources, and provides the fundamental services for all other software.

🌱 Star the Linux kernel repository ☆

7. 🗄️ Redis - Preferred, fastest, and most feature-rich cache, data structure server, and document and vector query engine.

If you need a fast response from your database, this system is 100% suitable.

non-relational NoSQL database management system

🌱 Star the repository ☆

8. 💼 Frappe HR - Open Source HR and Payroll Software

The next project is an open source business solution for HR management from Frappe. This company has been around for a long time and has a really big name in the industry, as you may have used (or are using) its ERPNext product if you work as a manager.

Frappe HR has everything you need to drive excellence within the company. It's a complete HRMS solution with over 13 different modules right from Employee Management, Onboarding, Leaves, to Payroll, Taxation, and more!

🌱 Star the Frappe HR repository

9. ⚙️ MLX - An array framework for Apple silicon

An excellent framework from Apple that will allow you to teach your MacBook, iMac and other devices to solve many necessary tasks for business and more.

MLX is designed by machine learning researchers for machine learning researchers. The framework is intended to be user-friendly, but still efficient to train and deploy models. The design of the framework itself is also conceptually simple.

🌱 Star the MLX repository

10. 👀 Mockoon - Easiest and quickest way to run mock APIs locally

Now, let's move on to creating an API. If you want to test your application route on a localhost, say, how information about products comes in, then you can do it thanks to this tool without deploying to dev or prod.

Mockoon is the easiest and quickest way to design and run mock APIs. No remote deployment, no account required, free and open-source.

🌱 Star the Mockoon repository

🖋️ Conclusion

In this article, I have reviewed only a small part of the volume of projects that are important and even necessary for every developer to know. It is clear that, well, let's say, there are hundreds of such projects today, and maybe more. But I hope you have discovered something new, and if not, at least remembered that there is.

Thank you very much for reading this article ❤️!

What other projects do you know that are not so popular, but also useful? It will be interesting to find out in the comments!

I Built a Production-Grade E-Commerce Platform in 3 Months — GitHub Copilot Was My Co-Founder

Syed Ahmer Shah — Sat, 23 May 2026 20:57:12 GMT

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

Let me be honest with you first — when I started Commerza, I genuinely didn't know if I would ever finish it.

I'm a 19-year-old software engineering student from Pakistan. Not from some well-funded university. Not from a bootcamp in San Francisco. I'm doing a 4-year BSE at HITMS and a 3-year Advanced Diploma in Software Engineering at Aptech Pakistan, side by side, trying to become a full-stack developer with real skills — not just tutorial-following muscle memory.

Commerza is a production-grade PHP + MySQL e-commerce platform. Full storefront. Full admin panel. Real payments (COD + Stripe). Enterprise-level security — CSRF protection, Google reCAPTCHA v2 and v3, rate limiting, audit logs, stock locking, SMTP failover, Argon2id password hashing, SQL injection defenses across every user-facing mutation path.

The kind of stuff you'd expect from a team. Not one broke student coding at 2am.

And no — it wasn't a "weekend project". This thing has:

80 PHP files
339 total tracked files
136 commits
PHP 62.6% | JavaScript 20.8% | CSS 15.0% | PowerShell 1.6%

Stack: HTML · CSS · JavaScript · jQuery · Bootstrap · PHP · MySQL · JSON · XML · SEO

It has a dark mode (OrangeRed + Black) and a light mode (NavyBlue + White). It has Cloudinary integration, Redis/APCu caching layers, ClamAV upload scanning, sub-admin role management, a product trash bin, coupon campaigns, review eligibility enforcement, OAuth via Google and Facebook, customer blacklists, and a CI security gate that runs on every push.

This is Commerza.

And GitHub Copilot — with Claude Sonnet 4.6, Claude Opus 4.6, and GPT-5.2-Codex — built probably 78% of the backend alongside me.

Demo

🔗 GitHub: github.com/ahmershahdev/commerza

(Screenshots Below)

The Comeback Story

Where It Started

January 2026. I had the idea. I wanted to build something I could actually show to a client or employer — not a todo app, not a blog engine. Something real. An e-commerce platform from scratch. No Laravel, no framework crutch. Raw PHP. Because I wanted to understand every layer.

The first month? I was mostly doing frontend. HTML structure. CSS design system. Bootstrap grid. jQuery interactions. I wrote those by hand. Clean, methodical, slow. Every component manually. The product cards. The navbar. The cart page. The admin sidebar.

You can see it in my commit history. Slow, small, frontend commits. One file at a time.

Then I hit the backend wall.

I stared at the PHP folder for three days. I knew PHP basics. But production PHP is a different animal. PDO vs mysqli. Prepared statements everywhere, not just "when you feel like it". CSRF tokens — what are they, really, and where do they go? Argon2id vs bcrypt — does it matter for a student project? (Yes. It does.)

The stuff I thought would take me "a few days" started looking like months of work. Email automation — SMTP with a failover to a backup transport? Rate limiting that doesn't break normal users? reCAPTCHA v3 with score thresholds and action validation?

I'd have been done in 6-8 months. Maybe.

Enter Copilot

I'd been using GitHub Copilot casually for code completion. But sometime in early February 2026, I started actually talking to it. Using the agent mode. Giving it context. Describing what I needed. Letting it write entire systems.

The shift was dramatic.

Here's one of the first real "wow" moments. I needed SMTP failover. My plan was: try primary SMTP, if it fails, fail the email. Copilot suggested something I hadn't considered — a dual-route architecture where the primary and secondary share a duplicate-suppression check so you don't accidentally send the same email twice if both routes are responsive at once.

I did not know that was a real pattern. I learned it in the tool. Not from a YouTube tutorial. Not from StackOverflow. From watching Copilot write it and then asking it to explain why.

The final architecture for backend/mailer/mailer.php:

// Simplified illustration of the SMTP failover logic Copilot introduced
function send_mail(string $to, string $subject, string $html_body): bool {
    $primary   = smtp_transport('primary');
    $secondary = smtp_transport('fallback');

    // Suppress duplicate route — if both point to same host/account, skip fallback
    if (same_transport($primary, $secondary)) {
        return attempt_send($primary, $to, $subject, $html_body);
    }

    if (attempt_send($primary, $to, $subject, $html_body)) {
        return true;
    }

    // Primary failed — try fallback
    return attempt_send($secondary, $to, $subject, $html_body);
}

Small thing. But I would not have thought of the duplicate suppression check. That detail would have caused a real bug in production.

What Copilot Built

Let me be specific. Here's what GitHub Copilot generated — or heavily scaffolded — with me reviewing, testing, and iterating:

Email Automation System

SMTP primary + fallback routing (mailer.php)
Security code generation + 15-minute expiry OTP for 2FA and password resets
Cart expiry reminder emails (send_engagement_reminders.php)
Wishlist expiry reminder emails
Monthly profit report emails (monthly_profit_report.php)
Weekly analytics report emails (weekly_analytics_report.php)

Admin Panel Systems

Coupon management (create, activate, validate, campaign control)
Product review moderation with delivery-status eligibility enforcement
Product trash bin with restore workflow and storefront exclusion logic
Sub-admin lifecycle (invite, email verify, roles, suspend/reactivate, delete + immediate session revocation)
Security event monitoring UI

Security Infrastructure

Google reCAPTCHA v3 verification with strict score threshold (0.65 default), action validation, hostname checking, challenge_ts freshness
reCAPTCHA v2 fallback when v3 isn't active for a flow
Honeypot field embedded in CAPTCHA widget
Fallback CAPTCHA challenge (arithmetic + knowledge, hashed answer per nonce, attempt lockout)
Rate limiting across all sensitive endpoints
PDO helper layer for controlled incremental migration from mysqli prepared statements
security_helpers.php — centralized Argon2id/bcrypt hashing, password policy enforcement, rehash logic
CI security gate via .github/workflows/security-gate.yml — static checks on every push + dynamic probes when SECURITY_BASE_URL is configured

Checkout Hardening

Stock locking with SELECT ... FOR UPDATE during order placement
Idempotency key consumption to block duplicate form submissions
High-value COD OTP threshold (email OTP for orders above configurable limit)
Refund and review blacklist enforcement across all user-facing mutation paths

The Before vs. After

Dimension	Before Copilot	After Copilot
PHP files written	~8 (basic CRUD)	80 tracked PHP files
Security posture	basic input escaping	3-level security model (baseline → sensitive forms → critical money paths)
Email system	single PHP mail() call	SMTP failover + 6 automation scripts
Estimated time to complete	6–8 months	3–4 months
Things I knew I didn't know	PDO vs mysqli	stock locking, CSP nonces, Argon2id, idempotency keys
Things I didn't know I didn't know	SMTP duplicate suppression, COD OTP threshold patterns, APCu/Redis cache layering	discovered through Copilot's generated code

The last row is the real one. The things I didn't know I didn't know.

My Experience with GitHub Copilot

The Models Matter

I used three models across this project:

Claude Sonnet 4.6 — my daily workhorse. Fast, accurate for PHP, good at following context across multiple files. When I was iterating quickly on storefront logic or admin UI, Sonnet was my go-to. It understood my existing codebase structure without me re-explaining every time.

Claude Opus 4.6 — for the scary parts. When I needed the CAPTCHA hybrid system designed, or when I was trying to figure out the checkout security model (transaction boundaries, row locking, idempotency), I reached for Opus. Slower, but it reasoned through edge cases I wouldn't have caught. The "Level 1, Level 2, Level 3 security severity model" in my README — that framework came out of an Opus session.

GPT-5.2-Codex — I used this mostly for breakpoint testing, spotting logic flaws, checking SQL injection vectors, and validating security helpers. Different model, different angle on the same code. Like having a second pair of eyes that reads code differently. Copilot's multi-model architecture made this seamless — I could switch within the same workflow.

As of April 2026, GitHub Copilot supports model selection for both Claude and Codex agents, with Claude Sonnet 4.6 and Claude Opus 4.6 available for Anthropic tasks, and GPT-5.2-Codex, GPT-5.3-Codex, and GPT-5.4 available for OpenAI Codex tasks.

What Actually Happened in Practice

It wasn't magic. Let me be clear.

I wrote every single frontend file by hand. Copilot suggestions during HTML/CSS work were mostly noise — I ignored them. The jQuery interactions, the Bootstrap grid, the storefront layouts — that's mine, manually typed.

Where Copilot exploded in value was PHP systems logic. The kind of code where one missed edge case means a security hole or a race condition in checkout. The kind of code where you need to know patterns you've never been taught.

A real example: I knew I needed "CSRF protection." What I didn't know was where exactly to validate the token (before any database operation, not after), or that regenerating the token after each validated request is a meaningful hardening step. Copilot wrote it the right way. I read the code, asked it why, it explained. That's not just autocomplete — that's mentorship encoded into a tool.

What I Pushed Back On

Copilot is not always right. A few things I rejected or significantly modified:

It initially generated SQL using string concatenation in a few helper queries — I pushed back and forced prepared statements everywhere
One version of the reCAPTCHA logic didn't validate hostname or challenge_ts — I asked for hardening and got a stricter implementation
The first version of the rate limiter didn't have burst tolerance — it would have flagged fast-typing legitimate users. I caught it in testing

The right model is: you're the architect. Copilot is a very fast contractor who sometimes cuts corners. Review everything.

On Learning While Using AI

Here's the thing people don't say enough: AI-assisted development taught me more than it replaced. I learned PDO, Argon2id, CSP nonces, idempotency keys, stock locking, Cloudinary server-side signing, APCu caching, and Redis connection pooling — all through reading, testing, and interrogating code that Copilot generated. If I'd been alone, I'd have written simpler code and never encountered these patterns at all.

The alternative wasn't "I would have learned this from scratch." The alternative was "I would have shipped something less secure and less complete."

Conclusion

Commerza is archived now — May 5, 2026. I archived it not because I abandoned it, but because it reached a state I'm actually satisfied with. 339 files. 80 PHP files. 136 commits. A CI security gate. A dual-SMTP mailer. An admin panel I'd actually use.

Is it perfect? No. There are things I'd change. The PDO migration is incomplete — the README says so honestly. Some admin UI pages are rougher than others. There's a lot of room to grow.

But it exists. It runs. It handles real security concerns that most tutorial-based PHP projects completely ignore.

That's the difference three months and GitHub Copilot made.

I'm not a "vibe coder." I'm not someone who just prompts and ships. Copilot was my accelerator, my pattern library, and — genuinely — my teacher on the backend. The frontend was mine. The architecture decisions were mine. The testing, the debugging, the "wait this doesn't make sense, let me re-read the generated code at 1am" — all mine.

If you're a student developer who thinks AI tools are "cheating": they're not. They're the closest thing to a senior developer pair-programming with you that most of us will ever get access to, for free. Use them intelligently. Read everything they generate. Push back when it's wrong. Ask why.

That's how you build a production-grade e-commerce platform in 3 months instead of 8.

Links:

🔗 GitHub: github.com/ahmershahdev/commerza

Built by Syed Ahmer Shah — BSE student, HITMS BSE, Aptech ADSE, Pakistan. 2026.

Find Me Across the Web

✍️ Medium: @syedahmershah
💬 DEV.to: @syedahmershah
🧠 Hashnode: @syedahmershah
💻 GitHub: @ahmershahdev
🔗 LinkedIn: Syed Ahmer Shah
🧭 All links: Beacons
🌐 Portfolio: ahmershah.dev

From a College Hackathon Idea to an Unfinished Developer Dream — Reviving AlgoPair 🚀

Hrishika Malviya — Sat, 23 May 2026 05:36:20 GMT

GitHub Finish-Up-A-Thon Challenge Submission

There’s a very different kind of nostalgia in opening an old GitHub repository.

Not the happy kind.

The dangerous kind 😭

The kind where you stare at old folders, unreadable code, random commits like final_final_v2_REAL, and suddenly remember how excited you once were while building it.

That’s exactly what happened when I reopened AlgoPair.

A project my team and I built during our college internal hackathon last year.

At that time, the idea felt genuinely exciting.

Not because it was revolutionary.

But because it solved a problem we ourselves faced almost every day.

💭 The Idea Behind AlgoPair

If you’ve ever practiced DSA with friends, you probably know the struggle.

One person opens LeetCode.
Another joins on Discord.
Someone shares their screen.
Someone disconnects.
Half the time goes into explaining code instead of solving problems together 😭

So during our hackathon, we thought:

“What if friends could solve DSA questions together in real time… even from different locations?”

That simple thought became AlgoPair.

A collaborative coding workspace where students could:

💻 Solve DSA questions together
🧠 Discuss approaches in real time
⚡ Write and sync code live
📞 Stay connected remotely while practicing

It was basically our attempt at making “multiplayer DSA practice” feel smooth and interactive.

And honestly?

During the hackathon, we were obsessed with the project.

Late-night debugging.
Cold coffee.
Zero sleep.
Last-minute UI fixes five minutes before evaluation 😭

Typical hackathon energy.

At that moment, AlgoPair genuinely felt like something we would continue building even after the event ended.

But reality works differently.

🫠 The Project Slowly Got Abandoned

Once the hackathon ended, college life came back at full speed.

Assignments.
Exams.
Deadlines.
Burnout.

And slowly, AlgoPair became “that GitHub repo I’ll finish someday.”

The project technically worked…

…but only barely.

The real-time syncing was inconsistent.
Some UI sections were incomplete.
Authentication had issues.
Responsive design was almost nonexistent.
The codebase had become messy after the hackathon rush.

And because everything was built quickly, continuing the project later started feeling overwhelming.

So the repository stayed untouched for months.

Still public on GitHub.

Still unfinished.

💡 Then This Challenge Changed Something

When I came across the GitHub Finish-Up-A-Thon challenge, AlgoPair was the first thing that came to my mind.

Not because it was my most advanced project.

But because it was the one I never fully gave up on.

Most developers have at least one unfinished project sitting quietly in their GitHub profile.

A project they genuinely cared about…
but never got the chance to properly complete.

AlgoPair became that project for me.

And this challenge finally pushed me to stop saying:

“I’ll finish it later.”

🛠️ Rebuilding AlgoPair After Months

Coming back to old code is honestly terrifying 😭

Especially hackathon code.

Everything feels confusing when you revisit it months later.

But this time, instead of trying to rebuild everything from scratch, I focused on improving the project step by step.

That approach changed everything.

✨ Cleaning the Messy Structure

The first version of AlgoPair had:

Duplicate components
Hardcoded values everywhere
Poor folder organization
Repeated logic
Large unreadable files

I spent time restructuring the entire project properly.

Separating reusable components.
Improving readability.
Making the frontend easier to scale.

And surprisingly, GitHub Copilot helped a lot during this phase.

Not by magically “building the app for me”…

…but by helping me move faster whenever I got stuck refactoring old logic.

🎨 Making the UI Feel Like a Real Product

One thing I realized while rebuilding the project:

A polished UI makes a project feel alive again.

So I redesigned major parts of the platform.

I improved:

✅ Dashboard layout
✅ Real-time collaboration sections
✅ Dark mode support
✅ Mobile responsiveness
✅ Cleaner coding workspace
✅ Better spacing and navigation

Instead of looking like a rushed hackathon demo, the platform finally started feeling usable.

And that feeling genuinely motivated me to continue building.

⚡ Features That Made AlgoPair Better

While rebuilding the project, I also expanded the original idea.

The newer version now focuses more on collaborative learning instead of just code syncing.

Some features I added/improved:

🧠 Real-time collaborative coding
💬 Discussion/chat while solving
📈 Coding progress tracking
🔥 Daily consistency tracking
🎯 Better problem organization
📱 Responsive design for different devices

One feature I personally loved building was the coding activity tracker inspired by GitHub contribution graphs.

It visually shows how consistently users practice DSA together.

That small feature made the platform feel much more community-driven.

📚 What Reviving This Project Taught Me

Starting projects is exciting.

Finishing them is difficult.

Hackathons teach you how to build fast.

But unfinished projects teach you patience.

Reviving AlgoPair made me realize something important:

Not every abandoned project is a failure.

Sometimes projects are simply paused versions of ideas we still believe in.

And honestly, rebuilding something old felt far more meaningful than starting another random new project.

Because this time, it wasn’t about just impressing judges during a hackathon.

It was about finally completing something I once cared deeply about building.

❤️ Final Thoughts

A year ago, AlgoPair was just a college hackathon submission built under pressure and sleep deprivation 😭

Today, it feels like an actual product with real potential.

Maybe not perfect yet.

But finally moving in the right direction.

And I think that’s what this challenge is really about.

Not perfection.

Just refusing to leave good ideas unfinished.

Sometimes the best projects aren’t the ones that start perfectly.

I Let Hermes Agent Handle Real Work for 24 Hours — Here’s What Surprised Me 🚀

Hrishika Malviya — Sat, 23 May 2026 05:25:44 GMT

Google Docs summaries, task planning, research help, workflow automation… I wanted to know whether Hermes Agent was actually useful or just another flashy AI demo. 👀

Like many developers, I’ve seen countless “AI agents” online recently. Most of them look impressive for five minutes and then fall apart the moment you give them real work.

So instead of watching another demo video, I decided to do something more interesting:

👉 I gave Hermes Agent actual tasks for an entire day.

Not toy prompts.
Not “write me a poem.”
Real tasks that I normally do myself.

And honestly? Some of the results genuinely surprised me.

First Impressions 💡

The first thing that stood out to me about Hermes Agent was that it didn’t feel like a normal chatbot.

Most AI assistants wait for instructions. Hermes Agent felt more like a system that wanted to figure things out step-by-step.

That difference became obvious very quickly.

What also caught my attention was the flexibility. Unlike many closed AI systems, Hermes Agent can run on your own infrastructure and connect with different models and tools. That open-source approach already makes it interesting for developers who like control and customization.

You can explore the project here:

Hermes Agent Official Website
Hermes Agent GitHub Repository
The Experiment 🧪

I decided to treat Hermes Agent like an AI intern for one full day.

Here were the tasks I gave it:

✅ Research assistance
✅ Summarizing long information
✅ Planning workflows
✅ Multi-step reasoning tasks
✅ Organizing ideas
✅ Helping with coding-related work
✅ Remembering context between tasks

I wasn’t expecting perfection.
I mainly wanted to see one thing:

Could this agent actually reduce my workload in a meaningful way?

Task 1: Research and Summarization 📚

I started with something simple.

I gave Hermes Agent a large amount of information and asked it to summarize the key points and organize them clearly.

This is where I noticed the first major difference compared to normal chatbots.

Instead of giving a quick surface-level answer, Hermes Agent tried to break the task into smaller reasoning steps. It felt more structured and intentional.

And surprisingly, the summaries were actually useful — not just random bullet points copied from the input.

That immediately made me think:

“Okay… this might be more powerful than I expected.” 👀

Task 2: Multi-Step Workflow Planning ⚙️

Next, I tested something harder.

I asked Hermes Agent to help plan a small workflow involving multiple steps and dependencies.

This is where many AI tools usually struggle. They often lose context or generate inconsistent steps halfway through.

Hermes Agent handled this much better than I expected.

It broke the task into:

goals,
subtasks,
logical sequences,
and execution ideas.

It genuinely felt like the agent was thinking through the process instead of just predicting the next sentence.

That distinction matters a lot.

The Most Interesting Part: It Felt Persistent 🧠

One of the biggest reasons Hermes Agent stood out to me was its approach to memory and persistence.

Most AI chats feel temporary. You ask something, get a response, and everything disappears into the void.

Hermes Agent feels different because it’s designed around:

learning,
memory,
skills,
and long-term improvement.

That changes the experience completely.

At one point, I noticed it referencing earlier context more naturally than I expected, and that small moment honestly made the system feel far more “agentic” than typical AI assistants.

Not magical.
Not perfect.
But definitely different.

Where Things Got Messy 😅

Of course, not everything worked perfectly.

There were moments where:

outputs became repetitive,
reasoning drifted slightly,
or tasks required clearer instructions than I initially gave.

And honestly, I’m glad those moments happened.

Because it made the experience feel real.

One thing I’ve realized while testing AI systems is that the most trustworthy reviews are the ones that include failures too.

Hermes Agent is powerful, but it’s still a tool that benefits from good prompting, structured tasks, and realistic expectations.

What Actually Impressed Me Most 🚨

It wasn’t the speed.

It wasn’t flashy outputs.

It was the feeling that Hermes Agent was trying to operate through tasks rather than simply answer prompts.

That sounds like a small difference, but it changes everything.

For the first time in a while, I felt like I was interacting with something closer to an AI workflow system rather than a standard chatbot interface.

And I think that’s exactly why so many developers are paying attention to agentic AI right now.

Open-Source AI Feels Important Again 🌍

Another thing that made this experience exciting was the open-source side of Hermes Agent.

In a world where most advanced AI systems are becoming increasingly closed and centralized, there’s something refreshing about tools that developers can actually:

run themselves,
customize,
inspect,
and experiment with freely.

That openness creates room for innovation.

And honestly, some of the most interesting AI experiments in the next few years might come from open communities rather than giant corporations alone.

Final Thoughts 💭

After spending a day testing Hermes Agent with real work, I don’t think AI agents are just hype anymore.

Are they perfect? No.

Are they fully autonomous replacements for humans? Definitely not.

But systems like Hermes Agent show where things are heading:

persistent AI,
tool-using AI,
self-improving workflows,
and agents that can genuinely assist with complex tasks.

The most surprising part?

For the first time, I stopped feeling like I was “chatting with AI” and started feeling like I was coordinating with a system that could actually help manage work.

And that shift feels important. 🚀

Thanks for Reading 🙌

If you’ve experimented with Hermes Agent or other agentic systems, I’d genuinely love to hear your experience too.

The AI agent space is evolving incredibly fast, and it feels like we’re only beginning to see what these systems might eventually become.

“I Built a Fully Offline AI Memory Engine Around Gemma 4 — No Cloud, No Vector DB”

Hrishika Malviya — Sat, 23 May 2026 05:11:59 GMT

Most AI assistants today are impressive… until you realize they forget everything unless you connect them to expensive cloud infrastructure, embeddings APIs, or vector databases.

That never felt right to me.

I kept wondering:

“Can an AI remember useful things intelligently without relying on Pinecone, ChromaDB, or cloud memory systems?”

So over the past few days, I built an experimental offline AI memory engine powered entirely by Gemma 4.

No cloud.
No vector database.
No external APIs.
Just local inference, smart memory ranking, and a lot of late-night debugging ☕💀

🧠 The Goal

I didn’t want to build another chatbot wrapper.

I wanted to explore something deeper:

How can we make local AI systems remember information in a smarter and lighter way?

Most memory systems today work like this:

User Message → Embeddings → Vector DB → Similarity Search → AI

Mine works differently.

Instead of embeddings and vector search, I experimented with:

memory compression
keyword scoring
relevance ranking
contextual summaries
priority-based recall
local JSON/SQLite storage

Everything runs fully offline.

⚡ What The System Does

The AI can:

✅ remember important conversations
✅ recall ideas across sessions
✅ store goals/projects/tasks
✅ rank memories by importance
✅ retrieve relevant context locally
✅ work completely offline

For example:

You can say:

“Remember my startup idea about offline education.”

And later ask:

“What startup ideas did I save earlier?”

The system rebuilds context dynamically and feeds only the most relevant memories back into Gemma 4.

🔥 Why I Avoided Vector Databases

Vector databases are powerful, but I wanted to test something simpler.

Modern LLMs already have strong reasoning capabilities.

So instead of relying heavily on embeddings, I focused on:

smarter context building
compressed memory summaries
lightweight ranking logic
structured memory retrieval

Surprisingly…

It worked much better than I expected 👀

🏗️ Tech Stack
AI
Gemma 4
Ollama
Backend
FastAPI
Python
Frontend
Next.js
Tailwind CSS
Framer Motion
Storage
SQLite
JSON memory store

Everything runs locally on my laptop.

🧩 How The Memory Engine Works

The architecture is pretty simple:

User Input
↓
Memory Extractor
↓
Local Memory Store
↓
Relevance Ranking
↓
Context Builder
↓
Gemma 4 Response

The interesting part was building a system that decides:

“What is actually worth remembering?”

Not every message should become memory.

That part took the most experimentation.

💡 What I Learned

This project taught me something important:

Sometimes we overcomplicate AI systems.

You don’t always need:

massive infrastructure
cloud pipelines
complex retrieval systems

With the right architecture, local AI can already feel surprisingly intelligent.

And honestly…

There’s something really satisfying about seeing an AI system work completely offline 🔥

📊 Current Results

So far the system can:

maintain long-term memory surprisingly well
recall relevant information across sessions
run smoothly on consumer GPUs
operate fully offline after setup

Still experimenting with:

memory decay
smarter ranking
long-context optimization
hallucination reduction

But the early results are exciting.

🚀 What’s Next

I’m planning to explore:

memory graphs
adaptive memory compression
persistent AI personas
offline multi-agent memory systems
local “second brain” workflows

Gemma 4 has been incredibly fun to experiment with for these kinds of systems.

Final Thoughts

I started this project mostly as an experiment.

But somewhere during the process, it stopped feeling like a chatbot project…

…and started feeling like the foundation of a real personal AI system.

Offline AI is getting seriously powerful.

And I think we’re only getting started. 🔥

I Built a Smart Kitchen AI with Gemma 4 That Turns Fridge Photos Into Recipes

rishi — Sat, 23 May 2026 04:35:05 GMT

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

I Built a Smart Kitchen AI with Gemma 4 That Turns Fridge Photos Into Recipes

What I Built

Smart Kitchen AI is a multimodal AI-powered cooking assistant designed to make everyday cooking smarter and easier.

The idea started during a Build With AI bootcamp where my team and I wanted to explore how AI could solve practical real-world problems using computer vision and intelligent reasoning.

The workflow is simple:

Users upload a photo of ingredients available in their refrigerator
The AI analyzes the visible ingredients
It generates recipe suggestions based on the detected items
The system can also recommend possible meal ideas and smart combinations

The goal was to create an AI experience that feels genuinely useful in daily life instead of just being another chatbot demo.

Demo

Core Features

Fridge image analysis
Ingredient detection
AI-powered recipe generation
Smart meal suggestions
Multimodal AI interaction
Modern user-friendly interface

Example Workflow

Upload refrigerator image ➜ AI detects ingredients ➜ Smart recipes generated instantly

Future Improvements

Nutrition analysis
Grocery recommendations
Voice assistant integration
Personalized meal planning
Smart kitchen automation

Code

Technologies Used

Python
Flask
HTML/CSS
AI image analysis workflows
Prompt engineering
Gemma 4 integration concepts

GitHub Repository

https://github.com/rishihuyr

How I Used Gemma 4

For this project, I explored the potential of Gemma 4 multimodal capabilities to power intelligent recipe understanding and contextual reasoning.

I chose the Gemma 4 31B Dense model because the project required:

stronger reasoning,
multimodal understanding,
and better contextual response generation.

Since Smart Kitchen AI needs to understand ingredient combinations and generate meaningful cooking suggestions, a more capable reasoning-focused model made the most sense for the experience I wanted to create.

What impressed me most about Gemma 4 was the balance between:

reasoning capabilities,
multimodal potential,
and flexible deployment possibilities.

Instead of building a generic AI chatbot, I wanted to create something practical that demonstrates how multimodal AI can improve everyday experiences.

That’s what made Gemma 4 such an exciting fit for this project.

Challenges I Faced

One of the biggest challenges was designing prompts and workflows that generated useful recipe recommendations instead of random outputs.

Ingredient recognition can also become difficult when refrigerator images contain:

unclear lighting,
overlapping objects,
or partially visible ingredients.

Improving contextual understanding and response quality became an important part of the experimentation process.

What I Learned

This project taught me that some of the most exciting AI ideas are often the simplest ones.

Not every AI application needs to be futuristic or overly complex.

Sometimes solving small real-world problems in a smart and accessible way can create the best user experiences.

Building Smart Kitchen AI also helped me better understand:

multimodal AI workflows,
prompt engineering,
AI reasoning systems,
and how modern open models like Gemma 4 can support practical innovation.

Final Thoughts

AI is slowly becoming part of everyday life.

Projects like Smart Kitchen AI made me realize that multimodal models are opening the door to a future where AI can understand images, context, and human intent more naturally than ever before.

And honestly, that future feels incredibly exciting.

devchallenge #gemmachallenge #gemma #ai

From Abandoned Prototype to Smart AI System: Reviving Trafiq AI with GitHub Copilot

rishi — Sat, 23 May 2026 04:28:15 GMT

This is a submission for the GitHub Finish-Up-A-Thon Challenge

I Revived My Abandoned AI Traffic Project Using GitHub Copilot — And It Became Better Than I Imagined

What I Built

Trafiq AI is a smart AI-powered traffic management concept focused on improving how future smart cities analyze and manage traffic systems.

The idea originally started during an innovation-focused project where I wanted to explore how AI could help:

detect traffic congestion,
optimize routes,
analyze traffic flow,
and improve smart transportation systems.

At the beginning, Trafiq AI was mostly a rough prototype with incomplete ideas, unfinished UI screens, and limited functionality.

But instead of letting the project stay abandoned, I decided to bring it back and completely rethink the experience.

This challenge became the perfect reason to finally finish what I started.

Demo

Core Features

AI-powered traffic analysis
Smart route optimization concepts
Traffic heatmap visualization
Predictive traffic insights
Futuristic dashboard UI
Smart city inspired interface

Project Screenshots

Vision

The long-term vision behind Trafiq AI is to explore how AI systems can support:

smarter transportation,
intelligent city planning,
and future smart city ecosystems.

The Comeback Story

Like many hackathon-style projects, Trafiq AI started with excitement but eventually got pushed aside.

The biggest problems were:

incomplete implementation,
lack of polish,
unfinished UI,
and limited time during development.

At one point, the project became just another unfinished idea sitting in my folders.

But revisiting the project later felt completely different.

Instead of simply fixing bugs, I focused on transforming the project into something more realistic and visually polished.

Here’s what changed during the revival process:

Before

Basic prototype
Unfinished dashboard
Rough UI design
Limited traffic visualization
Incomplete project structure

After

Futuristic smart-city inspired interface
Improved dashboard experience
Better visual presentation
Cleaner structure and organization
Expanded AI-driven concepts and workflows

One thing I realized during this process is that unfinished projects often still contain strong ideas.

Sometimes they just need more time, patience, and better tools.

My Experience with GitHub Copilot

GitHub Copilot genuinely helped speed up the rebuilding process.

While working on Trafiq AI, Copilot helped me with:

code suggestions,
debugging support,
UI improvements,
faster implementation,
and organizing repetitive logic.

What I liked most was how it reduced development friction during experimentation.

Instead of getting stuck repeatedly searching for small syntax fixes or boilerplate code, I could focus more on improving the actual project experience and exploring ideas faster.

As someone still learning and building projects in the AI space, that productivity boost felt extremely valuable.

What I Learned

Reviving an abandoned project taught me something important:

A project doesn’t need to start perfectly to become meaningful.

Many student projects fail not because the idea is bad, but because time, polish, and consistency become difficult during fast-paced development.

This challenge pushed me to revisit an unfinished idea and turn it into something I’m genuinely proud of.

And honestly, seeing an old prototype evolve into a much more polished AI concept felt incredibly satisfying.

Final Thoughts

AI and smart systems are changing how we imagine future cities, automation, and real-world problem solving.

Trafiq AI started as a simple experimental idea.

But rebuilding it with better tools, improved design thinking, and support from GitHub Copilot showed me how much unfinished projects can still evolve.

This challenge wasn’t just about finishing code.

It was about finishing something I once believed had potential.

And I’m really glad I came back to it.

devchallenge #githubchallenge #github #ai

I Imagined Hermes Agent Running an Entire Smart City — And It Changed How I See AI

rishi — Sat, 23 May 2026 04:15:26 GMT

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

I Imagined Hermes Agent Running an Entire Smart City — And That Changed How I See AI

Most people still think of AI as a chatbot.

But while exploring Hermes Agent, I realized something much bigger:

We are entering an era where AI systems won’t just respond.
They’ll reason, plan, analyze, and take action.

As a Generative AI student who loves building real-world projects, this idea instantly fascinated me.

And it completely changed how I started thinking about one of my own concepts:
Trafiq AI.

From Chatbots to Autonomous Systems

For the last few years, most AI projects have followed a simple pattern:

Input → Response.

But Hermes Agent feels different.

Instead of behaving like a traditional assistant, it introduces something far more powerful:

planning,
tool usage,
reasoning,
and multi-step execution.

That shift may sound technical.

But honestly?

It changes everything.

Because once AI systems can reason through problems step-by-step, they stop feeling like simple software tools and start behaving more like intelligent systems.

The Moment Trafiq AI Started Making Sense

Recently, I worked on a concept called Trafiq AI — an AI-driven smart traffic system focused on:

congestion analysis,
route optimization,
predictive traffic monitoring,
and intelligent transportation insights.

At first, I imagined it as a dashboard.

But after exploring Hermes Agent, I started imagining something much more advanced.

What if the system could actually think through traffic problems?

What if an AI agent could:

monitor live congestion,
detect unusual traffic patterns,
prioritize emergency vehicles,
reroute traffic dynamically,
and generate real-time recommendations automatically?

That’s when I realized:

Agentic AI systems may become the operating layer behind future smart cities.

And honestly, that idea feels insane in the best possible way.

Why Hermes Agent Feels Important

The biggest thing that impressed me about Hermes Agent is accessibility.

Usually, advanced AI systems feel locked behind massive infrastructure and enterprise ecosystems.

But open-source agentic systems change that dynamic completely.

Now students and independent developers can experiment with:

autonomous workflows,
AI research systems,
intelligent assistants,
automation pipelines,
and decision-making agents

without needing huge resources.

That democratization matters a lot.

Because innovation becomes faster when more people can build.

AI Is Quietly Entering a New Phase

I think we are slowly moving beyond the “AI chatbot era.”

The next phase feels more like:

AI systems coordinating tasks,
using tools intelligently,
reasoning through workflows,
and collaborating with humans.

That’s a much bigger shift than most people realize.

And platforms like Hermes Agent are giving developers an early look at that future.

What Excites Me as a Student Developer

As someone passionate about Generative AI, hackathons, and building practical systems, this future feels incredibly motivating.

A few years ago, building intelligent multi-step systems like this would have sounded unrealistic for students.

Now it’s becoming possible with open ecosystems and modern AI tooling.

That’s powerful.

Because the next breakthrough idea might not come from a giant company.

It could come from:

a student,
a small developer team,
or someone experimenting late at night with open-source AI agents.

Honestly, that possibility is what excites me most.

Final Thoughts

Hermes Agent didn’t just make me think about better AI tools.

It made me think about a future where AI systems actively help run complex environments, assist decision-making, and solve real-world problems dynamically.

From smart kitchens to intelligent traffic systems like Trafiq AI, the future of AI feels less about simple conversations and more about intelligent action.

And after exploring agentic systems, one thing feels clear:

We are only at the beginning of what autonomous AI can become.

hermesagentchallenge #devchallenge #agents #ai

How we're using Gemini Embeddings to build a smarter, community-driven feed on DEV

Ben Halpern — Fri, 22 May 2026 16:27:19 GMT

Big improvements incoming 👋

Finding the right balance for a feed algorithm is historically really hard. If you optimize purely for clicks and comments, you end up with a clickbait echo chamber. But if you just sort by recency, it's a firehose where great discussions disappear in hours.

We've wrestled with this tension at DEV for a long time. We want a feed that feels alive, but actually surfaces high-quality, intellectually stimulating stuff.

So, we're trying something new. We are combining standard community signals—like who you follow and what you react to—with Gemini Embeddings 2 and pgvector.

Here is a look under the hood at how we are putting this together.

1. Keeping things flexible and auditable

Instead of duct-taping API calls all over the codebase, we built a flexible foundation using wrapper classes, mostly centered around Ai::Base and Ai::Embedding.

When a service needs the API, it just passes wrapper: self to the client. This lets Ai::Base look at the calling object, grab its class name, and check its VERSION.

Ai::Base.new(wrapper: self)

This pattern gives us a really clean audit trail via our AiAudit model. Every single time we generate a vector or analyze a trend, we automatically log the model used, the caller's class, payloads, latency, and token counts.

It makes debugging and tracking costs so much easier, without muddying up our core business logic.

2. A more personalized feed

Our main feed is powered by FeedConfig. It compiles custom SQL to score and rank articles for you.

Historically, this was all hardcoded math based on things like tags and whether you follow the author. Now, we've introduced a semantic feedback loop.

As you interact with the platform, we compile a dynamic interest_embedding that represents what you actually care about. We use the pgvector extension in PostgreSQL to inject your interests directly into the SQL query:

(
  CASE
    WHEN articles.semantic_embedding IS NOT NULL
      AND articles.published_at >= :published_since
    THEN (1 - (articles.semantic_embedding <=> :interest_embedding)) * :semantic_similarity_weight
    ELSE 0
  END
)

By using 1 - (embedding <=> user_interest), we get a cosine similarity score. We scale that up and mix it in with standard social signals (like who you follow), post quality, and time decay.

This means a highly relevant post can rise to the top of your feed, but so can a globally trending post from a community member you love. It’s all about balance.

3. What the heck is an embedding anyway? (And why v2 matters)

If you're new to the concept, an embedding is basically taking a piece of content—like an article text—and turning it into a long string of numbers (a vector). These numbers map the content into a "semantic space." If two posts are talking about the exact same conceptual ideas, their numbers will look very similar mathematically, even if they use completely different wording.

We've upgraded this pipeline to use Google's newly released Gemini Embeddings 2 model.

A standard text embedding model only looks at words. But Gemini Embeddings 2 compiles into massive 3,072-dimensional vectors and maps everything into a single, unified semantic space.

Future-proofing for a multi-modal DEV

The coolest part about moving to Embeddings 2 is that it isn't just restricted to text. It natively accepts multimodal inputs—meaning text, code, images, audio, and video.

Right now, we're using it to analyze written DEV posts. But because the underlying math maps everything into the exact same vector space, we are completely future-proofing our infrastructure. As the DEV platform evolves, we can easily feed images, podcast audio, or video posts into the exact same database architecture[.

A user's interest_embedding will be able to effortlessly surface an open-source video tutorial or a technical podcast episode based entirely on conceptual relevance, without us needing to rewrite our feed logic from scratch.

4. Catching nuanced trends 📈

Tags are great for high-level sorting, but they miss the highly specific, timely conversations. If Ruby 3.4 drops, a #ruby tag search won't distinguish between a "Hello World" tutorial and a deep debate about the new parser.

To fix this, we are in the process of building a clustering service powered by TrendDetector.

Every 6 hours, a background job runs a Leader Clustering algorithm in pure Ruby:

Quality first: We only look at recent articles scoring at least 15 points above our homepage minimum.
Clustering: We measure the cosine distance between articles. If a post is close enough (0.15 or less) to an existing cluster, it joins it. If not, it starts a new one.
Labeling: Once a cluster hits 10 or more articles, we ask the Gemini API to label the trend and summarize the core debate.

We store all of this in TrendMembership, which lets us sort articles in the UI based on how close they are to the core topic.

All of this can be tracked via our open source codebase Forem:

forem / forem

For empowering community 🌱

Forem 🌱

For Empowering Community

Welcome to the Forem codebase, the platform that powers dev.to. We are so excited to have you. With your help, we can build out Forem’s usability, scalability, and stability to better serve our communities.

What is Forem?

Forem is open source software for building communities. Communities for your peers, customers, fanbases, families, friends, and any other time and space where people need to come together to be part of a collective See our announcement post for a high-level overview of what Forem is.

dev.to (or just DEV) is hosted by Forem. It is a community of software developers who write articles, take part in discussions, and build their professional profiles. We value supportive and constructive dialogue in the pursuit of great code and career growth for all members. The ecosystem spans from beginner to advanced developers, and all are welcome to find their place…

View on GitHub

5. Putting the community first ❤️

Human curation, both from the broader community and our editorial perspective, is still the backbone of the system.

We are using Gemini Embeddings to amplify what the community is already doing. It’s about mixing the raw utility of vector search with the human spirit of developer-voted scores and relationships.

We want DEV to be the best place on the internet to share code and talk about software. We think this is a big step in that direction.

What do you think? Let me know in the comments.

Happy coding!

What was your win this week!?

Jess Lee — Fri, 22 May 2026 13:00:00 GMT

👋👋👋👋
Looking back on your week -- what was something you're proud of?
All wins count -- big or small 🎉

Examples of 'wins' include:

Getting a promotion!
Starting a new project
Fixing a tricky bug
Learned something new (even from a random YouTube rabbit hole)📚

Happy Friday!

Google I/O 2026 Didn’t Kill Coding — It Changed Who Controls It

Hrishika Malviya — Fri, 22 May 2026 05:48:05 GMT

When I started watching Google I/O 2026, I thought it would be another polished tech event.

Some AI demos.
Some productivity upgrades.
A few “future of development” promises.

But halfway through the keynote, I stopped watching like a developer.

I started watching like someone realizing the industry is mutating in real time.

Because this year Google didn’t introduce better coding tools.

They introduced systems that are slowly learning how to replace the entire process of software development.

The Shift Nobody Wants To Admit

For years, developers believed AI would stay an assistant.

Helpful, but controlled.

Something that suggests code while humans stay in charge.

Google I/O 2026 completely broke that illusion.

Now AI agents:

plan projects,
execute workflows,
debug themselves,
deploy apps,
communicate between tools,
and even continue unfinished work autonomously.

That’s not assistance anymore.

That’s delegation.

And delegation eventually changes jobs forever.

Antigravity Is More Dangerous Than People Realize

Everyone online is hyping Gemini.

But honestly?

Antigravity scared me more.

Because Gemini is a model.

Antigravity is a developer ecosystem where AI agents operate almost like independent workers.

One agent writes backend logic.
Another handles testing.
Another checks vulnerabilities.
Another deploys infrastructure.

Parallel execution.

Continuous reasoning.

Minimal human interruption.

This is the first time I genuinely felt like big tech companies are no longer trying to support developers.

They’re trying to redesign development itself.

Developers Used To Build Products

Now Developers May Only Supervise Them

That’s the real difference after I/O 2026.

Earlier:

humans built,
AI assisted.

Now:

AI builds,
humans supervise.

And once that transition becomes normal, the industry changes permanently.

Because companies care about:

speed,
scalability,
cost reduction,
and automation.

An AI agent doesn’t sleep.
Doesn’t burn out.
Doesn’t ask for salary hikes.
Doesn’t need onboarding.

That’s the uncomfortable business reality nobody says out loud.

WebMCP Might Quietly Become The Biggest Internet Shift Since Mobile

Most people ignored WebMCP because it sounded technical.

Huge mistake.

Because WebMCP is basically teaching websites how to communicate directly with AI agents.

Right now agents interact with websites like confused humans:

clicking buttons,
reading layouts,
guessing actions.

WebMCP changes that.

Now websites can expose structured AI-readable tools directly.

Meaning future apps won’t only compete for human attention.

They’ll compete for AI compatibility too.

That changes web development forever.

In the future, developers may optimize apps for:

users,
search engines,
AND intelligent agents.

That’s an entirely new layer of the internet.

The Most Terrifying Realization I Had

The problem isn’t that AI writes code fast.

The problem is that AI is removing friction everywhere.

Google showed:

instant deployment,
automatic testing,
migration agents,
full-stack scaffolding,
cloud integration,
security analysis,
autonomous workflows.

All the painful parts developers spent years mastering…

are becoming automated.

And when hard things become easy, industries restructure fast.

But Here’s Why I Don’t Think Developers Are Finished

I think average developers are in danger.

Not great developers.

Because AI still lacks:

deep business understanding,
product intuition,
accountability,
human creativity,
long-term engineering judgment.

AI can generate systems.

But it still struggles understanding consequences.

And companies eventually pay for bad decisions more than slow development.

That’s where real developers still matter.

The New Era Won’t Reward “Coders”

It will reward:

system thinkers,
AI orchestrators,
technical strategists,
builders with product sense.

The future developer isn’t the person typing the fastest.

It’s the person directing intelligence effectively.

That’s a completely different skillset.

What Changed For Me Personally After Watching I/O 2026

Before this event, I thought learning more frameworks was enough.

Now I think that mindset is outdated.

Because frameworks change.

Syntax changes.

Tools change.

But understanding systems, users, scalability, and architecture stays valuable.

So if I were rebuilding my skillset today, I’d focus on:

AI workflows,
automation systems,
cloud architecture,
cybersecurity,
product engineering,
and agent collaboration.

Not endless tutorial watching.

Not memorizing syntax.

Those things are becoming commodities.

The Biggest Mistake Developers Will Make

Either:

completely rejecting AI,

depending on it blindly.

Both are dangerous.

The smartest developers will be the ones who:

understand fundamentals deeply,
but also use AI aggressively.

That balance will create the next generation of elite engineers.

Final Thought

Google I/O 2026 didn’t feel exciting to me.

It felt historic.

Like one of those moments people look back at years later and say:

“That was the moment everything changed.”

Because this wasn’t just a keynote about AI products.

It was a preview of a world where software increasingly builds itself.

And honestly?

I don’t think the industry is fully prepared for how fast that future is approaching.

googleiochallenge #devchallenge #ai #gemini

As a Gen AI Student, Here’s What Excited Me Most at Google I/O 2026

rishi — Fri, 22 May 2026 01:54:27 GMT

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

Google AI Studio Might Be the Most Exciting Announcement From Google I/O 2026

Google I/O 2026 was packed with announcements around AI, Gemini, Firebase, Android, and cloud technologies. But as a B.Tech student specializing in Generative AI, the update that genuinely excited me the most was the evolution of Google AI Studio and the Gemini ecosystem.

For the first time, it feels like powerful AI development is becoming accessible not only to large companies, but also to students, indie developers, and small creators.

And honestly, that changes everything.

Why This Announcement Stood Out to Me

Over the last year, AI development has been growing at an incredible speed. Every week there’s a new model, framework, or tool.

But one major challenge still exists:

Many students have ideas but don’t have the resources or infrastructure to build them easily.

That’s where Google AI Studio feels different.

Instead of spending days configuring environments and APIs, developers can now prototype ideas faster and focus more on solving real-world problems.

As someone who regularly participates in hackathons and AI events, this instantly caught my attention.

My Experience Building AI Projects

One reason I connected so much with the announcements is because I’ve already been exploring AI development through projects and bootcamps.

Recently, during the Build with AI Bootcamp, my team built a Smart Kitchen System powered by AI.

The idea was simple but practical:
Users could upload a photo of ingredients available in their refrigerator, and the AI system would analyze the items and suggest recipes that could be prepared using them.

What made this exciting was seeing how AI can solve everyday problems in a simple and user-friendly way.

We combined:

image understanding,
AI-powered recommendations,
and practical problem-solving

into one project experience.

That project genuinely showed me how accessible AI development is becoming for students.

Exploring Real-World AI Beyond Tutorials

I’ve also worked on another project called Trafiq AI during an innovation-focused experience with Antigravity.

The project focused on using AI concepts for smarter traffic-related solutions and automation ideas.

Experiences like these made me realize something important:

Modern AI tools are no longer just for research labs.

Students can now build practical systems capable of solving real-world problems using accessible APIs and development platforms.

And after watching Google I/O 2026, it feels like Google is accelerating that future even further.

Why Google AI Studio Feels Important

The biggest thing I noticed is how focused the platform is on developer productivity.

A few things that impressed me:

Faster experimentation
Easier AI integration
Beginner-friendly workflows
Rapid prototyping capabilities
Better accessibility for students and startups

This matters because many students have strong ideas but struggle with deployment complexity or expensive infrastructure.

Google seems to be reducing that barrier significantly.

Why This Matters for Student Developers

This is probably the most exciting part for me personally.

Students usually face:

Limited computing resources
Limited budgets
Difficult deployment workflows

But tools like Gemini and Google AI Studio simplify experimentation and development.

That means students can spend more time:

learning,
building,
participating in hackathons,
and creating innovative solutions

instead of struggling with setup issues.

As someone passionate about becoming an AI engineer, this feels incredibly motivating.

What I Loved About Google I/O 2026

What impressed me most wasn’t just the technology itself.

It was the direction.

Google’s announcements showed a future where AI becomes:

more practical,
more accessible,
and more integrated into everyday development.

Instead of AI being treated as something futuristic and unreachable, it’s becoming a normal part of the developer workflow.

That shift is incredibly important.

One Thing I Hope Improves

While the ecosystem looks exciting, beginners may still feel overwhelmed because AI is evolving extremely fast.

There are now:

multiple models,
APIs,
frameworks,
integrations,
and workflows.

So I’d love to see even more beginner-focused learning resources, templates, and guided project experiences directly inside Google AI Studio.

That could help even more students start building confidently.

Final Thoughts

Google I/O 2026 made one thing very clear:

The future of software development will heavily involve AI.

But what excites me most is that this future is no longer limited to massive companies with huge resources.

Students, independent developers, and small creators now have access to tools powerful enough to build meaningful AI applications.

From building projects like a Smart Kitchen recommendation system to exploring AI-powered solutions like Trafiq AI, I’ve personally seen how accessible AI development is becoming.

And after watching Google I/O 2026, I genuinely feel the next generation of developers will build things we once thought were impossible.

And honestly, I think we are only getting started.

googleiochallenge #devchallenge #ai #machinelearning

Join the GitHub Finish-Up-A-Thon Challenge: $3,000 Prize Pool!

Jess Lee — Thu, 21 May 2026 17:33:15 GMT

We're thrilled to announce our newest challenge with GitHub!

Running through June 7, the GitHub Finish-Up-A-Thon Challenge invites you to finally give that abandoned side project, challenge submission, or hackathon creation the love it deserves. GitHub is looking for ways to empower builders to finish what they started, and this challenge is the first step.

There's a $3,000 prize pool on the line for those of you who are up to the challenge. Ten winners will be selected and will also receive a DEV++ membership along with an exclusive winner badge.

Read on to learn more.

Our Prompt

Your mandate is to revive and finish a project you started but never completed.

You built something cool under pressure, likely with too little sleep and not enough time. Now it's your chance to pick it back up, add some polish, and share it with the world.

The most important aspect? Show us your before and after, and how GitHub Copilot helped you get there.

Judging Criteria

All qualified entries will be judged based on the following criteria:

Use of underlying technology
Usability and User Experience
Originality and Creativity
Completion Arc: Is there a clear before and after journey?

Prizes

Ten Winners will each receive:

$300 USD
DEV++ Membership
Exclusive DEV Badge

All Participants with a valid submission will receive a completion badge on their DEV profile.

How To Participate

In order to participate, share your revived project and publish a post using the submission template below.

GitHub Finish-Up-A-Thon Challenge Submission Template

Please review our judging criteria, rules, guidelines, and FAQ page before submitting so you understand our participation guidelines and official contest rules such as eligibility requirements.

Important Dates

May 21: GitHub Finish-Up-A-Thon Challenge begins!
June 7: Submissions due at 11:59 PM PST
June 18: Winners Announced

We can't wait to see what you finally ship! Questions about the challenge? Ask them below.

Good luck and happy building!

Open Source Toolkit for Building AI Agents in 2026

Anmol Baranwal — Thu, 21 May 2026 14:59:12 GMT

It used to take a lot of effort to get your first PR merged in open source. Now you can ship something real in a weekend thanks to coding agents like Claude Code.

But that also means the noise went way up. I saw the wave of openclaw repos a while back but the ratio of hype to actual maintenance is quite different.

I have a habit of exploring new projects almost every day, been doing that for 2+ years. Lately I have been deep in the AI agents space and these are the repos that actually stuck.

These aren't random projects, I have come across these in my journey and built with some of them. Agent harness, frontend stack, engineering skills for coding agents, voice agents, browser automation, computer use and a lot more. If you are building AI agents in 2026, this list is for you.

If you are new to open source, check out this free guide I made a while back. For any project you're considering: look for a CONTRIBUTING.md and a healthy community profile.

Let's jump in.

1. Frontend & UI Layer - CopilotKit

CopilotKit is the frontend stack for Agents. Most agent stacks give you the backend and leave the user-facing layer entirely to you.

CopilotKit is the layer that provides all the building blocks. Chat components, hooks, headless UI for custom agent interfaces, persistent threads, human-in-the-loop, shared state and a built-in Inspector for debugging.

They support all three generative UI patterns in one runtime. Basically, it allows the agent to show components rather than just describing them (A2UI by Google is one pattern).

The part I really like is that they have a mcp server for coding agents that lets coding agents fetch live docs without any usage limit.

You can connect directly to any LLM in just a few lines without any agent framework on the backend and make it context-aware about your app. They also have 13+ first-party integration support with major frameworks.

import {
  CopilotRuntime,
  copilotRuntimeNextJSAppRouterEndpoint,
} from "@copilotkit/runtime";
import { BuiltInAgent } from "@copilotkit/runtime/v2"; 
import { NextRequest } from "next/server";

const builtInAgent = new BuiltInAgent({ 
  model: "openai:gpt-5.5",
});

const runtime = new CopilotRuntime({
  agents: { default: builtInAgent }, 
});

export const POST = async (req: NextRequest) => {
  const { handleRequest } = copilotRuntimeNextJSAppRouterEndpoint({
    runtime,
    endpoint: "/api/copilotkit",
  });

  return handleRequest(req);
};

You can enable multimodal attachments like images, PDFs, audio, video & pass reasoningEffort to control how hard the model thinks.

The framework-agnostic design is what makes it practical. It's built on AG-UI protocol, the open event protocol for agent-user interaction now adopted by Google, AWS, Microsoft, LangChain, and many more. So if you switch any framework or protocol, everything on the frontend stays exactly the same.

I have used it for a couple of my recent projects, including a job search assistant I built using LangChain Deep Agents & it helped me surface all the things it was doing under the hood.

CopilotKit has 31.5k stars on GitHub.

Star CopilotKit ⭐️

Alternatives

TanStack AI - Framework-agnostic, vendor-neutral AI SDK from the TanStack team. Strong TypeScript support, modular adapters per provider. Direct alternative to Vercel AI SDK without the Next.js coupling.
Vercel AI SDK - Good for streaming and tool calling in Next.js. Stateless and tied to the Vercel ecosystem.
Tambo - React SDK focused purely on generative UI. Still early and not the full agent-chat stack.
Assistant UI - Headless React primitives for building chat UIs.
agent-native - Framework from Builder.io where agent and UI share the same action model. Define actions once, expose them to both. No separate agent API - if the UI can do it, the agent can and vice versa.

2. Skills & Plugins - agent-skills

Anthropic shipped the Skills format and the ecosystem took off fast. A lot of people are even saying MCP is dead because of Skills (I don't really believe so).

A skill is basically a directory containing a SKILL.md file that contains organized folders of instructions, scripts, and resources that give agents additional capabilities.

The official repo has 138k stars & it's worth reading the engineering blog to understand how progressive disclosure works in practice.

agent-skills by Addy Osmani is the gold. 23 production-grade engineering skills with 7 slash commands that map to the full dev lifecycle (/spec, /plan, /build, /test, /review, /ship).

Hard exit criteria, anti-rationalization tables, progressive disclosure. Encodes Google engineering culture -- Hyrum's Law, the Beyonce Rule, trunk-based development.

It has 43.8k stars on GitHub. Here are all the skills included.

Star Agent Skills ⭐️

agent-skills/
├── skills/                            # 23 skills (22 lifecycle + 1 meta)
│   ├── interview-me/                  #   Define
│   ├── idea-refine/                   #   Define
│   ├── spec-driven-development/       #   Define
│   ├── planning-and-task-breakdown/   #   Plan
│   ├── incremental-implementation/    #   Build
│   ├── context-engineering/           #   Build
│   ├── source-driven-development/     #   Build
│   ├── doubt-driven-development/      #   Build
│   ├── frontend-ui-engineering/       #   Build
│   ├── test-driven-development/       #   Build
│   ├── api-and-interface-design/      #   Build
│   ├── browser-testing-with-devtools/ #   Verify
│   ├── debugging-and-error-recovery/  #   Verify
│   ├── code-review-and-quality/       #   Review
│   ├── code-simplification/          #   Review
│   ├── security-and-hardening/        #   Review
│   ├── performance-optimization/      #   Review
│   ├── git-workflow-and-versioning/   #   Ship
│   ├── ci-cd-and-automation/          #   Ship
│   ├── deprecation-and-migration/     #   Ship
│   ├── documentation-and-adrs/        #   Ship
│   ├── shipping-and-launch/           #   Ship
│   └── using-agent-skills/            #   Meta: how to use this pack
├── agents/                            # 3 specialist personas
├── references/                        # 4 supplementary checklists
├── hooks/                             # Session lifecycle hooks
├── .claude/commands/                  # 7 slash commands (Claude Code)
├── .gemini/commands/                  # 7 slash commands (Gemini CLI)
└── docs/                              # Setup guides per tool

Alternatives

skills.sh - The npm for agent skills (marketplace). Install any skill with npx skills add <owner/repo>. The leaderboard surfaces what developers are actually using rather than what got hyped on launch day.
taste-skill - Portable design taste skills (minimalist, brutalist, GPT-tuned) that fix the generic-looking AI slop. One of the few skills that visibly changes what the agent produces. I have been using it for a couple of months.
Repomix - Packs an entire repo into one AI-friendly file. Pick when you need the agent to see the whole codebase at once.

3. Computer Use - UI-TARS Desktop

Most computer-use agents take a screenshot and ask a generalist VLM to guess pixel coordinates. UI-TARS was trained end-to-end on GUI grounding - it understands UI elements as a first-class concept rather than image regions to click on.

What I find really interesting is the "System-2 reflection" -- after each action, it compares before/after screenshots and generates a corrective plan if something didn't land right, instead of just going through a broken sequence.

It scores higher on OSWorld vs Claude Computer Use. Personally, I believe practical usage matters a lot more than benchmarks. 😅

They also ship Agent TARS - a CLI and Web UI that brings the same vision + MCP tool integration to your terminal and browser.

You can say something like: Please help me book the earliest flight from San Jose to New York on September 1st and the last return flight on September 6th on Priceline. All the demos are in the readme.

It has 34k stars on GitHub.

Star UI-TARS Desktop ⭐️

One very interesting repo I found is Sutando. It's a personal AI agent for macOS and runs on your Claude Code subscription with minimal extra costs.

The use cases are pretty wild. You can say "join my 2pm call" - it reads your calendar, joins Zoom via the desktop app or Google Meet via browser, takes screenshots to identify participants, does live research when someone asks a question and writes you a summary when the call ends.

Or you can call it from your phone, say "summon" - it opens Zoom with screen sharing and you control your computer by voice while walking around.

When you're not giving it tasks, Sutando runs an autonomous build loop - it monitors its own health, detects patterns in how you work, discovers new skills, and builds missing capabilities, which is crazy.

It has like 300 stars on Github but it is genuinely interesting.

Alternatives

Midscene - Also from ByteDance's Web Infra team. Vision-driven UI automation across web, Android, and iOS from one API. Integrates with Playwright and Puppeteer, ships a Chrome extension, CLI, and MCP server.
Agent-S - Hierarchical planning approach that builds a knowledge base from past interactions and uses it to plan future tasks. Benchmarks well on OSWorld and WindowsAgentArena.
Bytebot - Self-hosted AI desktop agent in a containerized Linux environment. The agent gets its own full virtual desktop -- browser, file system, password manager, any app. docker-compose up and it's running.
cua - macOS/Linux VM sandbox so the agent runs on a virtual machine, not your real machine.
OpenHands - Full developer environment that can browse, write code, run tests, and commit PRs. Covered again under Coding Agents.

4. Agent Orchestration - LangGraph

LangGraph is the stateful graph runtime built on LangChain. It is the most mature framework for building, managing, and deploying long-running, stateful agents.

The loop is a graph. Every step is a node. State is typed and checkpointed. You can pause at any node, serialize the entire state to disk, resume on a different machine days later.

They also ship Deep Agents - a coding agent harness on top of LangGraph with planning, filesystem tools, sub-agents, and context compression, if you want to skip writing the graph yourself.

Combining it with other products like LangSmith Engine, LangChain, Deep Agents gives developers a full suite of tools for building agents. And it's super useful for debugging.

If you're confused, here's a simple distinction:

LangChain - agents via chains and create_agent. Simple, fast to get started, less control over the state. The foundation on which everything else is built. If the process dies, the agent starts over.
LangGraph - stateful graph runtime built on LangChain. You can replay from any checkpoint to debug what went wrong.
Deep Agents - harness built on top of LangGraph.

LangGraph has 32.3k stars on GitHub.

Star LangGraph ⭐️

Alternatives

Agno - lightweight support for agents needing persistent memory and multimodal inputs. Ships with AgentOS, a pre-built FastAPI server with sessions, streaming, RBAC, and observability. Claims 529x faster instantiation than LangGraph.
Mastra - TypeScript-first with RAG, observability, MCP, and workflows baked in. Pick if your team lives in JS/TS rather than Python.
Pydantic AI - Type-safe agent framework from the Pydantic team. Pick when you want validated structured outputs without writing the validators yourself.
Google ADK - Google's official agent dev kit with native Vertex AI integration. Pick if you're building on Google Cloud.
PocketFlow - A 100-line LLM framework. Genuinely minimal. Pick when LangGraph feels like too much infrastructure.

5. Coding Agent Harness - Deep Agents

A harness is everything around the model that makes it an agent - tools, state, planning, memory, feedback loops, guardrails.

You can say: "Agent = Model + Harness". LangChain proved this matters more than most teams expect: harness-layer changes alone moved the same model from 52.8% to 66.5% on Terminal Bench 2.0, jumping from Top 30 to Top 5. No model change.

Deep Agents is LangChain's batteries-included harness built on LangGraph. Planning, filesystem tools, sub-agents, and context compression out of the box.

User goal
  ↓
Deep Agent (LangGraph StateGraph)
  ├─ Plan: write_todos → updates "todos" in state
  ├─ Delegate: task(...) → runs a subagent with its own tool loop
  ├─ Context: ls/read_file/write_file/edit_file → persists working notes/artifacts
  ↓
Final answer

The core problem with long-running agents is that they accumulate tool call results until the context window fills -- causing context poisoning, distraction, and confusion.

Their fix:

Large tool outputs go to a virtual filesystem instead of the prompt
Skills load only frontmatter at startup, full content on demand
Conversation history gets compressed as sessions grow
Sub-agents run in their own context window, the main agent only gets the final result

You can build lots of stuff around this like Deep Research Assistant.

Deep Agents has 23.1k stars on GitHub.

Star Deep Agents ⭐️

Alternatives

Hive - Outcome-driven agent development framework. Agents evolve based on whether they actually achieved the goal, not just whether they completed steps.
Browser Harness - From the Browser Use team. Self-healing harness that gives the LLM maximum freedom -- instead of wrapping Chrome with thousands of lines of heuristics, it lets the LLM use CDP directly and add its own tools when it needs them. Different philosophy from most browser frameworks.
Archon - Open-source harness builder for AI coding. Describe what you want and it generates a deterministic, repeatable agent harness for you.

6. Open-Source Coding Agents - OpenCode

I have used Claude Code and Codex extensively. Both are great but locked to their respective ecosystems.

OpenCode is the open-source alternative - terminal-native, 75+ provider support, LSP integration, multi-session (run multiple agents in parallel on the same project), privacy-first.

What makes it stand out: genuinely provider-agnostic from day one. You can switch between Claude, Gemini, GPT-5 and local models in the same session without reconfiguring anything. Most other coding agents have a preferred model set up in the defaults.

You can also share a link to any session for reference or to debug. It is available as a terminal interface, desktop app, and IDE extension - though I have only used the terminal.

OpenCode has 162k stars on GitHub.

Star OpenCode ⭐️

Alternatives

Codex (OpenAI) - OpenAI's official terminal coding agent. Pick when you want first-party support and the cleanest GPT-5 integration.
Gemini CLI - Google's official terminal agent with 1M token context. The free tier is hard to beat for experimentation.
Cline - VS Code extension with per-step approval. Pick if you want IDE-native control rather than a terminal.
Aider - Git-native terminal pair programmer. 70%+ of Aider's own code is now written by Aider. Fast and model-agnostic.
OpenHands - Full agentic developer environment that can browse, run shell, and commit PRs. Heavier than the others.
Goose - Block's extensible coding agent with first-class MCP and a clean extension model.

7. Browser Automation - Browser Use

Browser Use gives your agent a browser. Point it at a URL, describe what you want done, and it clicks, types, and navigates. You write intent, not selectors -- the agent reads the DOM and figures out the interaction itself.

The LLM-first design means you describe intent, not selectors, and the agent figures out the DOM.

The reason they are so good is that they have built purpose-built LLMs specifically for browser tasks. Their bu-ultra model scores 97% on Mind2Web vs 62% for claude-opus-4-6.

The open source library works with any model but their custom ones are what the benchmarks run on.

They also have a desktop app that controls your local Chrome directly and Browser Use Box - a 24/7 Claude Code agent you can deploy on any $5 VPS and control via Telegram.

# pip install browser-use-sdk

from browser_use_sdk.v3 import AsyncBrowserUse

client = AsyncBrowserUse()

result = await client.run(
  "Go to amazon.com, extract 200 products with name, price and reviews, save to products.csv"

It has 94k stars on GitHub.

Star Browser Use ⭐️

Alternatives

Stagehand - Four primitives: act, extract, observe, agent. Deterministic step-by-step control when you need it, autonomous execution when you don't. Self-healing -- "click submit" survives page redesigns because it's resolved by AI at runtime, not hardcoded selectors.
Playwright MCP - Microsoft's MCP server wrapping Playwright. Pick if you already write Playwright tests and want your agent to drive the same browser.
Skyvern - Uses a swarm of agents + computer vision to operate on sites it's never seen before. No XPaths, no selectors -- maps visual elements to actions in real-time. Also ships a no-code workflow builder.
Scrapling - Adaptive scraper that survives selector drift. Bypass anti-bot systems like Cloudflare Turnstile out of the box. Allows concurrent, multi-session crawls with automatic proxy rotation.

8. Web Scraping & Ingestion - Firecrawl

Agents need to pull content from the web constantly - research, monitoring, competitive intel, RAG pipelines.

Most scrapers give you raw HTML full of nav menus, ads, and cookie banners that burn tokens and confuse the model.

Firecrawl converts any website into clean LLM-ready Markdown or structured JSON. Three core endpoints that cover everything:

/search for web search with content already extracted
/scrape for full page Markdown
/extract for structured JSON via natural language prompt.

They also have an /agent endpoint where basically you describe what you want in natural language and it searches, navigates, and extracts across multiple sites autonomously. No URLs needed.

import Firecrawl from '@mendable/firecrawl-js';
import { z } from 'zod';

const firecrawl = new Firecrawl({ 
  apiKey: 'fc-YOUR-API-KEY' 
});

const schema = z.object({
  companies: z.array(z.object({
    name: z.string(),
    founders: z.array(z.string()),
    funding: z.string().optional(),
    website: z.string()
  }))
});

const result = await firecrawl.agent({
  prompt: 'Get all YC W24 companies',
  schema: schema
});

Their FIRE-1 navigation agent (beta) can autonomously navigate complex sites, clicks, scrolls, fills forms and handles multi-step flows before extracting. Pages behind login or pagination are no longer a blocker.

There's a lot more so feel free to explore. It has 122k stars on GitHub.

Star Firecrawl ⭐️

Alternatives

Gitingest - Replace 'hub' with 'ingest' in any GitHub URL and get a prompt-friendly extract of the codebase. Filter by file size, include/exclude specific paths, and support private repos too.
Crawl4AI - Open-source, self-hosted, no API key needed. Built specifically for RAG pipelines - LLM-aware chunking, BM25 content filtering, full-site crawling with depth control. Pick when you want full control without per-request fees.
Jina Reader - Prepend r.jina.ai/ to any URL and get clean Markdown. Zero setup, zero SDK. Pick for quick one-off page conversion or prototyping, where you don't want any configuration.
ScrapeGraphAI - Prompt-driven scraping. Describe what you want extracted in natural language and it builds the scraping workflow. Pick when you need structured JSON extraction, not just Markdown.

9. Multi-Agent Frameworks - CrewAI

CrewAI is the most widely adopted multi-agent framework right now. You define a crew of agents with specific roles, goals, and tools and CrewAI handles how they collaborate to finish a task.

The role-based model (PM, researcher, engineer) is intuitive because it maps to how you would actually divide work between people.

It's the easiest entry point into multi-agent systems. Well-documented, large community, with examples for almost everything.

The tradeoff is control - agent-to-agent communication is mediated through task outputs, not direct messaging and there's no built-in checkpointing for long-running workflows.

CrewAI Flows (the newer event-driven mode) addresses some of this for predictable pipelines. For cyclical workflows with feedback loops, most teams end up moving parts to LangGraph.

CrewAI has 51.6k stars on GitHub.

Star CrewAI ⭐️

Alternatives

AG2 - The community fork of AutoGen (Microsoft moved AutoGen to maintenance mode). Conversable agents that talk to each other in group chats, swarms, and nested chats. Better for research and custom communication patterns.
Microsoft Agent Framework - The enterprise successor to AutoGen. Stable APIs, long-term support, A2A and MCP built in. Pick when you need long-term support guarantees.
OWL - Multi-agent automation framework built on CAMEL. Uses a planning agent + execution agent model for long-horizon real-world tasks. Ranked #1 on the GAIA benchmark among open-source frameworks.
MetaGPT - Simulates a software company with PM, architect, and engineer agents. Best for code-generation pipelines.
AgentScope - Alibaba's production framework with realtime voice, MCP, A2A, and OTel built in.

10. Document Processing - Docling

Feeding a PDF to an agent and watching it miss things that were right there in the table is frustrating. Most parsers extract raw text and lose the structure - tables flatten, multi-column layouts collapse, equations come out unreadable.

Docling is IBM Research's document conversion engine, now donated to the Linux Foundation. It uses Granite-Docling-258M - a parameter vision-language model purpose-built for document conversion that rivals systems several times its size.

The output uses DocTags, a universal markup format IBM Research developed that captures every page element, its type, position and reading order. Not only Markdown. This is what makes the RAG downstream more accurate.

Red Hat called it "the number one open source repository for document intelligence". Sharing this for no reason 😅

from docling.document_converter import DocumentConverter

source = "https://arxiv.org/pdf/2408.09869"  # file path or URL
converter = DocumentConverter()
doc = converter.convert(source).document

print(doc.export_to_markdown())  # output: "### Docling Technical Report[...]"

Docling has 60.1k stars on GitHub.

Star Docling ⭐️

Alternatives

LlamaIndex - Full RAG framework with 160+ data connectors. Pick when you need orchestration across many data sources, not just document parsing.
MinerU - PDF parser with SOTA table and formula extraction. Pick for technical or scientific documents where math and equations dominate.
RAGFlow - DeepDoc pipeline that handles parsing, chunking, and retrieval end-to-end. Pick when you want the full RAG stack, not just the parser.
Marker - PDF, EPUB, PPTX to Markdown with high fidelity. Faster than Docling, lower GPU requirements. Pick for clean plain-text output at scale.
PaddleOCR - The OCR engine powering MinerU, RAGFlow, and OmniParser under the hood. 100+ languages, browser SDK. Pick when you need raw OCR power directly.
Unstructured - 65+ file formats including emails, spreadsheets, and images. Pick for mixed-input pipelines beyond just PDFs.

11. Voice Agents - Pipecat

Building voice agents is still harder than it should be. The AI part is mostly solved in my opinion. The hard part is everything around it, like interruption handling, transport, latency budgets across STT/LLM/TTS boundaries.

Pipecat is a Python framework from Daily for real-time voice and multimodal AI agents. STT, LLM, and TTS are composable frame processors like Unix pipes, but for voice.

The reason I picked it: you can swap any STT, LLM, or TTS without rewriting the pipeline. Most devs don't want to be locked into one provider, especially when voice model quality is still changing fast.

Silero VAD (voice activity detection) handles interruption at the framework level - voice activity mid-response stops the audio and re-engages the LLM automatically.

Pipecat Flows then adds predefined conversation paths with dynamic transitions so agents stay on task without going off-script mid-call.

import {
  PipecatAppBase,
  ConnectButton,
  UserAudioControl,
} from "@pipecat-ai/voice-ui-kit";

<PipecatAppBase
  transportType="smallwebrtc"
  connectParams={{ webrtcUrl: "/api/offer" }}
>
  <div>
    <ConnectButton />
    <UserAudioControl />
  </div>
</PipecatAppBase>

You can go to the website and try it out live. As you can see, I asked How can I bring it to my app & it opened the code panel as well as gave me a proper explanation.

There were multiple panels of code (install, pipeline, final implementation). The part that surprised me was that it was able to detect that I played around with the code when I stopped it, which makes it context-aware to the app.

It has 12k stars.

Star Pipecat ⭐️

The other day I was in a project where the agent would create an appropriate form based on the call and it worked. Generally, it's very hard to collect data from just voice.

Alternatives

LiveKit Agents - The WebRTC stack that OpenAI (ChatGPT Voice) and Meta run on. Room-first, not pipeline-first - your agent joins as a participant. Native telephony, semantic turn detection, MCP support. Pick when you need production infrastructure bundled with the framework.
fish-speech - SOTA open TTS with multilingual zero-shot voice cloning. Pick when output quality matters more than orchestration.
Moonshine - Very low-latency on-device STT. Pick when latency is the constraint and cloud isn't an option.
Whisper - OpenAI's STT model. The default transcription layer for custom voice stacks.
GPT-SoVITS - Few-shot voice cloning from 1 minute of audio, zero-shot from 5 seconds. Chinese, English, Japanese, Korean. Pick for cloned-voice TTS with minimal training data.
CosyVoice - Alibaba's multilingual zero-shot voice generation with 150ms latency. Pick for non-English voice quality.

12. Visual Builders - Langflow

Langflow is a drag-and-drop agent pipeline builder, IBM-backed. Connects to any LLM, any vector DB, any tool.

The way the CTO puts it: "Langflow is essentially an API designer. The flow becomes an endpoint you can call from anywhere."

What makes it interesting: the flow becomes a callable REST endpoint. You prototype visually, then your engineers call it an API from any codebase.

Every component exposes its Python class so you can extend with custom logic without leaving the tool.

You can find a lot of pre-built templates to get started. Here is a Supply chain risk monitoring workflow that scores disruption risk by linking supplier and route data with live news signals.

It has 149k stars on GitHub.

Star Langflow ⭐️

Alternatives

Dify - LLM app platform with a visual agent builder, RAG pipeline, and plugin marketplace. Pick the more polished UI and built-in app shell.
Sim - Drag-and-drop agent orchestration, very actively developed. The cleanest 2026-native alternative to Langflow.
n8n - Workflow automation with 400+ integrations and strong AI nodes. Pick when the workflow is mostly cross-service automation with an agent at the center.
Flowise - Simpler no-code LangChain builder. Pick for non-technical users who need to build agent workflows without writing code.
Coze Studio - ByteDance's open-source visual agent platform. Agent builder with RAG and plugins, workflow engine with loops and custom Python execution.

13. MCP & Tool Integration - Composio

MCP servers solved how agents connect to tools. But managing OAuth, token refresh, and keeping 1000+ integrations working is still your problem.

Composio is the integration layer between your agent and real-world tools with managed auth.

The part I liked the most is the Tool Router - one MCP endpoint that dynamically discovers and loads the right tools based on what the agent is trying to do. Instead of pre-loading every tool and bloating the context, it surfaces only what's relevant.

They have 28.4k stars on GitHub.

Star Composio ⭐️

Alternatives

LiteLLM - One unified API across 100+ LLM providers. Azure, Bedrock, Anthropic all look like OpenAI to your code. Cost tracking, routing, fallback. Pick the model gateway layer.
MindsDB - SQL access to 200+ data sources from a single interface, no ETL. Also ships as an MCP server. Pick when your agent needs to read data, not take actions.
ACI - 600+ tool integrations via a unified MCP server. Self-hosted Composio alternative.
Portkey AI Gateway - 1,600+ models with guardrails built in. Pick when gateway latency matters.

14. Sandboxing & Code Execution - E2B

When an agent generates and runs code, that code needs somewhere safe to execute. Regular Docker containers share the host kernel - one vulnerability and untrusted code breaks out.

E2B provides isolated sandboxes that let agents safely execute code, process data, and run tools. Their SDKs make it easy to start and manage these environments.

It runs agent-generated code in Firecracker microVMs - each sandbox gets its own dedicated kernel. ~150ms boot, full Linux filesystem, Python, Node, and common packages pre-installed.

import { Sandbox } from 'e2b'

const sandbox = await Sandbox.create() // Needs E2B_API_KEY environment variable
const result = await sandbox.commands.run('echo "Hello from E2B Sandbox!"')
console.log(result.stdout)

Nothing touches the host machine. Manus uses it to run 27 different tools. Perplexity uses it for data analysis. Hugging Face uses it to replicate DeepSeek-R1.

You can check some of the examples in their cookbook repo on how to use all of this.

It has 12k stars on GitHub.

Star E2B ⭐️

Alternatives

OpenSandbox - Alibaba's internal sandbox infrastructure. Covers coding agents, GUI agents, browser automation, VNC desktops, and RL training from one API. Docker and Kubernetes runtimes. Broader scope than E2B.
Daytona - ~90ms spin-up, open-source, persistent environments with Git integration and LSP. Pick when you need a state that persists across sessions.
microsandbox - Local, programmable sandboxes. Pick when you want sandboxes on the dev machine without cloud dependency.
Firecracker - The microVM tech under E2B, Lambda, and Fargate. Pick when you need the raw layer with full control.

15. Agent Memory - mem0

Memory is where most agent demos fall apart in production. The agent knows things in one session and forgets them in the next. We seriously don't want agents to die after closing the tab haha.

mem0 is the most widely deployed standalone memory layer right now. Instead of storing raw conversation chunks, it runs an extraction phase that identifies salient facts and distills them into compact natural language memories. Handles short-term, long-term, and entity memory behind one interface.

# Add a memory
messages = [
    {"role": "user", "content": "I'm a vegetarian and allergic to nuts."},
    {"role": "assistant", "content": "Got it! I'll remember your dietary preferences."},
]
client.add(messages, user_id="user123")

# Search memories
results = client.search(
    "What are my dietary restrictions?",
    user_id="user123",
)
# print(results)

Most major frameworks are building memory in such a way that LangGraph has checkpointing built in (state persists per thread, time travel, crash recovery) and CopilotKit has persistent threads via useThreads.

The gap worth knowing: Mem0 scores 49% on LongMemEval vs Zep's 63.8% - the difference comes from temporal reasoning.

For personalization memory it's the pragmatic choice. For agents that need to reason about how facts changed over time, Graphiti is the better pick.

It has 55k stars on GitHub.

Star Mem0 ⭐️

Alternatives

Graphiti - Zep's temporal knowledge-graph engine. Stores facts with validity windows -- not just what happened, but when and whether it's still true.
Letta (formerly MemGPT) - Memory built into the system prompt at runtime. The agent itself decides what to keep - not retrieved after the fact, baked into how it reasons.
Supermemory - Cross-agent memory API with plugins for OpenCode, OpenClaw, and Claude Code. Say "remember that this project uses Bun" and it saves. Context shows up automatically next session.
Cognee - Deterministic knowledge-graph memory pipelines. Pick for structured memory over large corpora.

16. Testing & Evaluation - DeepEval

Most teams skip evals entirely until something breaks in production. By then, you're debugging blind - no idea if it's the prompt, the retrieval, the model, or all three.

DeepEval brings eval into your test suite. Write assertions the way you write unit tests, run them in CI, and catch regressions before they ship.

50+ metrics covering RAG, agents, tool-use, multi-turn conversations, and safety. The agent-specific ones are the most useful: task completion, argument correctness, tool correctness, step efficiency. Also generates synthetic datasets for edge cases that are hard to collect manually.

It has 15.6k stars on GitHub.

Star DeepEval ⭐️

Alternatives

promptfoo - CLI-first eval and red-teaming in one tool. Pick when adversarial testing matters as much as accuracy metrics.
Phoenix - OTel-native tracing + evals from Arize AI. Auto-instruments LangChain, LlamaIndex, Mastra, Vercel AI SDK. Pick when you're already on OTel and want tracing and evals in one tool.
Opik - Comet's open eval and tracing platform. Pick when you want evals and observability together.
MLflow - Now has full LLM and agent eval features alongside the ML lifecycle tools. Pick when your team already runs MLflow for traditional ML.
garak - NVIDIA's LLM vulnerability scanner. Probes your agent for weaknesses before someone else does.
AI-Infra-Guard - Tencent's red teaming platform. Scans MCP servers, agent skills, and AI infrastructure. Pick when you want to find vulnerabilities before deploying.

17. Monitoring & Observability - Langfuse

Most teams find out their agent is broken when a user reports it. By then, you're debugging a black box - no trace of what the agent did, in what order, or where it went wrong.

Langfuse is the de facto open-source LLM observability stack. Traces, evals, prompt versioning, and cost tracking in one self-hostable package.

The trace shows exactly what the agent did, at what latency, with what cost. Debugging multi-step agents becomes a lot easier.

It has 27.6k stars on GitHub.

Star Langfuse ⭐️

Alternatives

Opik - Comet's tracing, evals, and dashboards. Pick for the Langfuse-equivalent with Comet's ML lineage behind it.
TensorZero - Gateway, observability, and optimization unified in one tool. Pick when you want one box instead of three.
Logfire - OTel-native LLM observability from the Pydantic team. Pick the tightest fit with Python and Pydantic-AI agents.
OpenLLMetry - OTel instrumentation library for LLM apps. Pick when you want agent traces feeding into an existing Grafana or Datadog backend.

A brief note on agent protocols

Three protocols run the modern agent stack. Worth knowing the difference:

MCP (Model Context Protocol) - agent to tools. Anthropic's standard, now under the Linux Foundation, adopted by OpenAI, Google, and Microsoft. GitHub
A2A (Agent-to-Agent) - agent to agent. Google's protocol for inter-agent communication. GitHub
AG-UI - agent to user. The open event protocol for agent-user interaction originated by CopilotKit and is now adopted by Google, AWS, Microsoft, LangChain, and Mastra. GitHub

Extra Resources

1) 12-Factor Agents - Dex Horthy's principles for shipping LLM software that actually works in production. The core insight: most successful AI products aren't autonomous agents -- they're mostly deterministic code with LLM steps placed at exactly the right points. One of my favorite repos in open source.

2) Generative Agents - The Stanford simulacra paper code. 25 agents in a Sims-like sandbox that wake up, form relationships, plan their days, and remember past interactions. The canonical reference for how memory, reflection, and planning work in multi-agent simulations.

3) AI Agents for Beginners (Microsoft) - 12-lesson structured course from Microsoft. Pick this if you want a guided path rather than piecing it together yourself.

4) HuggingFace Agents Course - Stronger on the model and tool-use fundamentals. Better for ML practitioners coming into agents from the model side.

5) Roadmap.sh AI Agents - Visual map of everything you need to know to build agents in 2026. Good starting point if you want to see the full picture before diving in.

Whew! This took a really long time to write, but I enjoyed every bit of it.

This list is based on my opinions and what I've actually seen get adopted in the open source community. If I missed something you think deserves a spot, drop it in the comments.

And on that note, here's what multi-agent collaboration actually looks like in 2026 😅

Have a great day! Until next time :)

Connect with me on GitHub, Twitter and LinkedIn.

thanks for reading!

Every Developer Is Lying About Something — And AI Won’t Fix It

Sylwia Laskowska — Thu, 21 May 2026 07:06:41 GMT

Yes, all of us are lying. And you are probably lying too. Let me prove it 😉

Oh, I have so many article topics in my head right now. The really exciting kind. But this week absolutely steamrolled me 😅 I finally finished preparing my JSNation talk, and at the same time two other amazing opportunities appeared — one professional, and one that feels more like a childhood dream coming true ☺️ But I don’t want to jinx it yet.

And just so it doesn’t sound like everything magically works out for me — I’ve also had a few CFPs rejected recently. The ones I actually cared about! But honestly? That’s just part of the game. One conference may reject your talk this year and happily accept another one from you the next.

So yes, the really big topics will have to wait a little bit longer 🙂 Which doesn’t mean this one is trivial.

We talk about AI everywhere now, as if it’s going to solve all our problems. But as we’ve already noticed, there’s no AI without humans, and behind every “smart” model there’s still some human being — at least for now 😉

Which is probably why, in practice, coding agents do speed things up… but not nearly as much as many people expected. Some studies even suggest they slow developers down.

Because the real problem is often not the code itself. The real problem is the people writing or generating that code.

And unfortunately, all of us lie in one way or another. Sometimes to others. Sometimes to ourselves.

Some Developers Lie About Knowing What They’re Doing

One of the best developers I know once confessed something to me.

This guy is genuinely brilliant. The kind of engineer companies fight over. He currently works on optimizing drivers for LLMs, gets promoted constantly, and even in this lovely “tech crisis” era, he still had multiple job offers to choose from when he considered switching jobs.

And yet, every single time he joins a new project, he feels like a complete idiot.

Everybody else seems productive. People are delivering tickets. Writing code. Moving confidently through the project. Meanwhile, he sits there staring at the codebase wondering:

What exactly is happening here?
What are we even building?
Why does this work like this?
Why are we implementing it this way and not differently?

And then he starts asking questions.

Usually, it turns out nobody really knows what they’re doing, why they’re doing it, or whether they’re even solving the right problem in the first place.

It reminds me of that old joke about lumberjacks cutting down a forest. Eventually, the team leader climbs the tallest tree, looks around, and screams:

“Guys! We’re cutting down the wrong forest!”

And the workers below shout back:

“Who cares? We’re making great progress!”

And honestly, no LLM will save us here. Especially if we never even ask the right questions.

Others Lie About Knowing How To Do Something

This is basically an extension of the previous problem.

A less experienced developer picks up a task and confidently says:
“Yeah, I know how to do this.”

Unfortunately, what they often mean is:
“I hope I’ll somehow figure it out.” 😅

In reality, they may not know how to solve the problem, which tools to use, what architecture makes sense... or even what prompt to write to get useful help from a coding agent.

But they’re afraid to ask.

Because how will they look in front of the team? What will the manager think? The tech lead?

Best-case scenario: they eventually ask questions… just way too late.

Worst-case scenario: they never ask at all and deliver something completely wrong. Which often isn’t even caught properly because…

Someone Else Is Lying About Having Time

Now we’re entering senior and leadership territory 😅

The motivations differ. Some people build their self-worth around being “the reliable one.” Others are terrified of losing status, influence, or even their job.

So they keep taking on more:

the hardest tasks,
endless meetings,
refinements,
estimations,
discussions with support,
discussions with business,
code reviews,
architecture decisions,
documentation.

And let’s be honest. Something eventually has to break.

Human beings are not made of steel. Nobody can operate at 100% forever.

So what happens?
People start half-listening during calls. Code reviews become rushed. Documentation quietly dies in a corner somewhere.

But they still refuse to admit — either to others or to themselves — that they’re simply overloaded.

Some Developers Lie About How Long Things Will Take

I see this constantly with more advanced juniors and mids.

They throw around hilariously optimistic estimates with absolute confidence.

And sure — if they could work uninterrupted for eight straight hours, the application contained no legacy code, edge cases didn’t exist, and other humans never interacted with the system… then maybe the estimate would actually be correct 😄

Then sprint review arrives, and suddenly everybody is shocked that the team didn’t deliver everything.

But this is not the only problem with estimations.

I once worked with an especially funny senior developer.

He treated estimations like sacred truth. He would aggressively defend his numbers during planning sessions, insisting that this specific task was definitely extremely complicated. The rest of the team usually suspected it wasn’t that bad, but eventually we’d surrender just to end the discussion.

And then — at least three separate times — he personally picked up the exact task he had massively overestimated… and finished it in about an hour.

Which basically meant the estimation discussion itself took longer than implementing the feature 😅

Did this experience change his behavior?

Absolutely not.

And Some Lie About Knowing Everything Best

These are probably the most dangerous ones.

I avoid people who say things like:

“Use THIS technology and ONLY this technology because everything else is garbage.”

Insert your favorite holy war here:
Angular vs React, Java vs Python, Rust vs literally anything else 😄

I never write like that myself. Even when I publish something titled “I Love Tailwind. Sorry Not Sorry”, I still talk about its downsides and explain where it absolutely doesn’t make sense.

If one day I start claiming some technology is objectively perfect for every possible situation, please leave a comment saying:

“Sylwia, go touch grass immediately.” 😅

Honestly, I’ve always wondered where this sense of absolute certainty comes from.

Because not all of these people are even paid influencers. Some genuinely seem emotionally attached to technological holy wars. Others maybe only know one stack deeply, so everything else automatically feels “bad.”

And while this behavior is very common among tech influencers, you absolutely see it inside companies too.

The problem is that this kind of certainty can seriously damage projects. People stop questioning decisions. Other developers become afraid to speak up. Stakeholders assume “the confident person” must be right simply because they sound convinced.

Best-case scenario: you end up with an annoying developer who knows more about frameworks than the actual business domain.

Worst-case scenario: you end up with a terrible stack choice and spaghetti architecture held together by ego.

People Are Just… People

Of course, I’m not innocent either.

I’ve used many of these lies myself in the past. Maybe I’m older now. Maybe slightly wiser. Or maybe I just recognize these patterns more easily.

But I’m definitely still lying somewhere too. Maybe not to others — maybe to myself.

Because a lot of our problems in software development aren’t really technical problems at all. They’re deeply human problems:

ego,
insecurity,
fear of looking stupid,
fear of admitting mistakes,
fear of saying “I don’t know.”

And honestly, I don’t have some magical solution for this. We’re not going to require three years of therapy from every developer before allowing them into a sprint planning meeting 😄

But I have noticed one thing.

Very often, admitting you don’t know something, openly discussing uncertainty during planning, or simply saying:

“Sorry, I still don’t understand this. Could you explain it one more time?”

doesn’t make people see you as a worse developer.

Quite often, the opposite happens.

Suddenly communication inside the team improves. Other people start asking questions too. Conversations become more honest. Problems get discovered earlier.

Seriously. Try it at least once. You might be surprised 🙂

So… what kinds of developer lies do you see most often in your team?