标签：#devto

About a week ago I open-sourced agmsg , a ~500-line bash + SQLite tool that lets CLI AI agents message each other directly. I built it for a dumb reason: I was tired of being the human copy-paste relay between Claude Code and Codex — selecting code in one terminal, pasting it into the other, carrying replies back, all day. I expected a few stars from friends and nothing else. Instead it went 5 → 320 in a week, picked up forks, derivative projects, and pull requests from people I've never met. That gap between what I expected and what happened is the interesting part, so here's the honest retrospective: the numbers, what worked, what flopped, and what genuinely surprised me. The numbers In about a week, with no budget and no audience to speak of: GitHub stars: 5 → 320 Forks: 0 → 15 3 derivative projects — someone ported the idea to shogi (agmsg-shogi), someone wrapped it as an MCP server (agmsg-mcp), someone rewrote it in Go (agmsg-go) Pull requests from outside contributors — support for Gemini CLI, Antigravity, and now GitHub Copilot CLI, plus a fix for role-isolation race conditions None of this came from one big spike. It came from a sequence of posts across channels, some of which worked and some of which completely didn't. What worked Leading with a video, not an explanation. The first post that got traction wasn't a description of the architecture — it was a 23-second clip of two Claude Code instances autonomously playing tic-tac-toe over agmsg, with no human input. People stop scrolling for a moving picture of agents doing something on their own. The text underneath could be short; the video did the work. A relatable problem, stated plainly. "I became a copy-paste relay between two AIs" landed because a lot of people are quietly doing exactly that right now. I didn't open with the technical design. I opened with the annoyance. The design was the payoff, not the hook. Using a long-form post as the landing pad. Timeline posts are good at reach and bad at depth.

AI Coding Agents in 2026: From Pair Programming to Autonomous Teams Slug: ai-coding-agents-2026-stack-comparison 1. The Three Categories That Actually Matter The 2024‑2025 hype cycle treated every AI coding tool as a single‑dimensional “best‑of‑list.” 2026 data shows that professional developers now average 2.4 tools per workflow (Stack Overflow Survey 2025). The real decision is architectural: Layer Goal Typical Agent Type Line‑level editing Speed, low latency Editor assistants Repo‑level planning Context depth, multi‑file changes Autonomous agents Enterprise governance Isolation, audit, CI/CD integration Platform agents Choosing a “one best tool” ignores the trade‑off between context window size (how many tokens the model can see) and execution speed (how fast the tool returns a suggestion). A narrow‑window editor assistant excels at instant autocomplete, while a wide‑window autonomous agent can rewrite an entire microservice in a single run. The three‑tier framework aligns the tool’s strengths with the architectural layer where they matter most. 2. Tier 1: Editor Assistants — Speed at the Line Level Tool Market Position Key Feature (2026) Pricing (per developer) Cursor $500 M+ ARR, fastest growth in Q1 2026 Parallel agents update git worktrees; 2‑second latency on 8‑core laptops $15 /mo (individual) – $120 /mo (team) GitHub Copilot 4.7 M paid subscriptions, 75 % YoY growth Agent Mode with multi‑agent workflows; deep VS Code integration $10 /mo (individual) – $100 /mo (enterprise) Windsurf 1.2 M active users, strong UI polish Real‑time code‑style enforcement; limited to 4‑file context Free tier up to 5 k lines, $30 /mo premium Tabnine Enterprise‑only after 2026 pivot Air‑gapped deployment; NVIDIA Nemotron 4‑bit models for on‑prem inference $200 /mo per seat (minimum 10 seats) When to choose each Cursor – prioritize raw typing speed and git‑aware suggestions. Ideal for startups that need rapid iteration without heavy IDE lock‑in. Copilot – best for teams already on

The problem Every time I started a session with Claude Code I had to re-explain my entire project. What framework I use. How my folders are structured. What naming conventions I follow. What decisions I have already made. Every. Single. Session. It was slowing me down and I knew there had to be a better way. What I built I built stackbrief. One command scans your repo and opens a local visual dashboard showing your full codebase intelligence. npx stackbrief scan It opens a dashboard at localhost:3000 showing: Interactive code map of your architecture Dependency version comparison against npm Convention detection (naming, async patterns, error handling) Context health score MCP server so Claude Code pulls context automatically How it works stackbrief reads every file in your project and builds a structured understanding of it. It detects your framework, architecture pattern, modules, dependencies, and coding conventions. It then writes a CLAUDE.md file to your project and starts an MCP server on port 3001. Claude Code picks this up automatically before every session. No more explaining your project from scratch. AI chat that actually knows your code The dashboard has an Ask your codebase section. Unlike generic AI chat, this assistant has read every file in your project. Ask it about your own architecture and get answers specific to your code. Works with Ollama (free, fully local), Claude, OpenAI, or any OpenAI-compatible provider including Groq, Mistral, and local runners like LM Studio and AnythingLLM. Zero config, fully local No cloud. No telemetry. No account required. Everything runs on your machine. npx stackbrief scan That is it. The dashboard opens automatically. Try it GitHub: https://github.com/ragavtech/stackbrief Built with Node.js and TypeScript. Open source, MIT license. Would love to hear what you think.

Keeping up with trending technical topics and new tools on developer forums can be time-consuming. To save time, I wanted to automate the process of finding popular articles, reading the comments to understand community sentiment, and drafting a summary. While I could write a standard Python script to scrape the dev.to API, simple scripts tend to be brittle. If an article doesn't have comments yet, a basic script will likely crash unless you write extensive error-handling logic. Instead of a rigid script, I built an Agent —a program that can dynamically reason about errors and adjust its approach. If one task fails, it can figure out the next best step. In this tutorial, I'll show you how to build a Trend-Spotting Agent using Python, the Google Agent Development Kit (ADK) , and Gemini 2.5 Flash. What We're Building We are going to write a Python application that acts as an autonomous agent. We'll give it three abilities: Search the dev.to API for rising technical articles based on specific tags. Dynamically fetch the top comments of those articles to read real community sentiment. Automatically draft a newsletter-style article on your DEV.to account summarizing its findings. Prerequisites Python 3.9+ installed on your machine. Google ADK . (Check out the Google ADK Docs if you need help installing). A DEV API Key . Grab this from your DEV.to account settings under "Extensions" and throw it in a .env file. Step 1: Giving the Agent its "Hands" (API Tools) Large Language Models (LLMs) are incredibly smart, but out of the box, they can't actually do anything on your computer. The coolest part about Google ADK is that we can write standard Python functions, hand them to the LLM as "tools", and let the AI decide how and when to use them. Let's write our API functions. Tool 1: Finding Rising Articles Here is our function to fetch rising articles. Pay close attention to the docstring ( """Fetches the top...""" ). We aren't writing this for other developers; the ADK actually

After using Claude Code, Codex, and Pi Agent for months, I wondered: how many AI agents are on my machine? I built a scanner. Here's what it found: Framework Active Archived Claude Code 192 191 Codex CLI 37 0 Pi Agent 8 sub-agents 12 scripts MCP Servers 8 - Total 448+ The Waste Duplicate calls : Same prompt → 3 agents (8-18% waste) Overqualified models : Simple tasks on expensive models (15-25% waste) Cache fragmentation : No shared prompt cache (12-20% waste) Zombie agents : Archived still indexed (2-8% waste) → 30-50% of AI API spend is wasted. The Fix AMA — Agent Management Agent bash pip install ama-core && ama scan && ama start Scans all agents across frameworks Smart routing (simple task → cheap model) Lifecycle management Local dashboard at localhost:8765 Free calculator: ama-agent-store.vercel.app/calculator MIT licensed. Feedback welcome!

Six months into running my SaaS, my "feedback system" was three browser tabs, a starred Gmail folder, and a sticky note on my monitor that said "check Discord." That was the whole system. It held together until the day I found a three-paragraph email from a paying user — a genuinely detailed feature request with a real use case — sitting unread for 24 days. His last line was: "Happy to pay more if you can support this." I replied the same afternoon I found it. His reply: "Switched last week, thanks anyway." That was the moment I stopped treating feedback management as a nice-to-have. Why the usual fixes didn't fix anything I tried the obvious things first. I want to document them because I see a lot of people cycling through the same failed solutions. Notion database 🪦 Built a beautiful one. Color-coded tags, priority columns, status tracking. It lasted 11 days before nobody — including me — was maintaining it. The friction of "open Notion, find the right database, fill in six fields" is invisible when you're designing the system and fatal when you're in the middle of a support conversation. Airtable form 🪦 Better entry point, still disconnected from where users actually were when they had feedback. Nobody bookmarks your Airtable form. They DM you on Discord and you think "I'll add that later" and you don't. Canny — this one actually worked, for a while I genuinely liked Canny. Clean interface, users could upvote requests, I could see what was popular. It felt like a real system. Then our user count grew and the pricing tier jumped. I was looking at $99/month for a feedback board for a product still finding its footing. That's not a moral judgment on Canny — it's a fair product — but for a bootstrapped indie dev, it started feeling like a tax on momentum. The deeper problem with all three solutions was the same: they were inboxes, not loops. User submits → enters the void → user never knows if anyone saw it → user assumes nobody did → trust erodes → churn. I had bui

Here is what a real solo founder orders. $ git worktree list ~/app a1b2c3d [ main] ~/app-review e4f5g6h [ review-branch] ~/app-content i7j8k9l [ draft-post] Three checkouts. One machine. Each one runs its own Claude Code session that cannot touch the others. That is a normal workday for me. I run a one person shop. Content and code, same desk, same hour. Anthropic's common workflows page lists about a dozen recipes for everyday work, and the docs are strong. What they do not tell you is which recipes survive contact with a real workday and which ones stay theory. After running Claude Code as my whole operation, five workflows carry the load. Here is the honest split. https://code.claude.com/docs/en/common-workflows 1. Worktrees changed how I work The problem worktrees solve is collision. You ask Claude to fix a bug. While it edits, you want to keep building a feature. Same repo, two streams of edits, and now your working tree is a fight nobody wins. A git worktree is a second checkout of the same repo on its own branch. Claude runs inside it and never sees the other windows. claude --worktree feature-auth Real scenario from this week. The post you are reading was drafted in one worktree while a separate Claude session reviewed an open pull request in another. Neither touched the other's files. When the review finished I merged, came back to the draft, and never lost my place. If you take one workflow from the docs, take this one. The setup cost is close to nothing and parallel agents stop stepping on each other. 2. Subagents protect the one resource you cannot buy more of The model's working memory is your budget. Every file Claude reads to answer a question spends it. Ask "how does our auth refresh work" in a large repo and Claude reads a pile of files to answer. Those files now sit in the window for the rest of the session, crowding out the work you care about. Delegate that to a subagent. use a subagent to investigate how our auth system handles token refresh The

I have been thinking a lot about coding agents lately. Not really about whether they can write good code, because usually they can, sometimes they can't. That part is obvious. But the risk is shifting from wrong answers to wrong outcomes. The part that feels more important to me is this: should the agent actually own the write authority? We already don't trust humans without roles, limits, reviews, and accountability. Developers use PRs, pilots use checklists, bank clerks have transfer limits. Capable agents need the same structure, but machine-readable. Right now a lot of setups still look roughly like this: agent reads the repo agent decides what to change agent has a GitHub token agent creates commits, branches, or PRs I don't think this is the right default. The agent can reason. The agent can inspect files. The agent can propose changes. But the moment it can directly create external impact, the problem changes. It is no longer just: did the agent say something wrong? It becomes: did the agent create the wrong outcome? That is a much more expensive failure mode. Intent is not authority The pattern I like more is simple: agent reads directly agent proposes intent a boundary decides an adapter materializes only admitted work So the agent does not get the write credentials. It submits a structured intent instead, which could look like: { "operation" : "write" , "target" : { "repo" : "example/app" , "branch" : "main" , "path" : "docs/config/agent-policy.md" }, "source_state" : { "blob_sha" : "8f31c2..." }, "requested_effect_hash" : "sha256:..." } This is then not a command anymore, it is a suggestion, or an intent. The system still has to decide whether this proposed outcome should exist. That decision layer can check things like: is this actor allowed? is this repo allowed? is this path in scope? does the source state still match? is this operation allowed? was the same effect already created? should this become a reviewable PR? Only after that should there be an

The problem I often switch between Codex, OpenCode, Cline, Claude Desktop, scripts, and terminals. The annoying part is not starting a new tool. The annoying part is explaining the same workspace state again: what changed what is still pending what should not be touched what tests passed what the next agent should read before editing What I built AgentContextBus (acb) is a local-first CLI for handing off workspace context between coding agents. It saves a local handoff packet, then lets the next agent read it through: paste-ready prompts brief prompts a local dashboard JSON output explicit MCP tools First run npx @xiaoshuo1988/acb verify first-run For Chinese output: npx @xiaoshuo1988/acb verify first-run --lang zh-CN A normal handoff From the agent that has context: acb handoff --from codex --summary "Ready for the next agent" --git From the receiving side: acb receive --latest After the receiving agent summarizes the packet: acb ack --latest --by opencode What ACB intentionally does not do no hidden prompt injection no traffic interception no third-party client config mutation no cloud sync no background daemon Why local-first I want the user to be able to inspect the packet store, copy text manually, and decide exactly when context crosses from one agent to another. What I want feedback on Is the handoff packet concept clear? Is verify first-run enough to understand the tool? Is receive --latest the right receiving-side command? Which client path needs the most work? Would you trust this workflow in a real project? Repo: https://github.com/xiaoshuo1988130/acb Feedback discussion: https://github.com/xiaoshuo1988130/acb/discussions/1

AI coding tools are no longer just autocomplete engines. For the last few years, developers used AI mainly to write faster: generate a function, explain an error, complete boilerplate, or suggest a code snippet. That was useful, but the human developer still controlled almost every step. Now the shift is toward agentic software development. Tools like OpenAI Codex and Google Antigravity are not only helping developers write code. They are starting to inspect repositories, understand tasks, edit files, run commands, verify outputs, and return work for human review. But Codex and Antigravity are not the same kind of product. They represent two different architectures for the future of software development. Codex: Delegated Engineering Agent OpenAI Codex is best understood as a delegated software engineering agent. The developer gives it a scoped task: fix a bug, review a pull request, write tests, refactor a module, or implement a defined feature. Codex then works through the codebase, makes changes, runs checks where possible, and returns a result that the developer can review. Its natural workflow is close to how software teams already work: Task → Repository Context → Code Changes → Tests/Checks → Pull Request or Reviewable Output This makes Codex useful for structured engineering work. It fits naturally into GitHub-style workflows, pull requests, code reviews, tests, and CI/CD practices. In simple terms, Codex feels like assigning work to an AI engineer. Antigravity: Agent-Orchestration Environment Google Antigravity takes a different approach. It is better understood as an agent-first development environment. Instead of focusing only on one delegated task, Antigravity is designed around supervising agents inside the development workspace. Agents can operate across the editor, terminal, browser, and artifacts. They can help plan, build, verify, and explain the work. Its workflow looks more like this: Goal → Agent Orchestration → Workspace Execution → Browser Verif

Here's something nobody talks about. .gitignore doesn't encrypt your secrets. It just hides them from git. They're still sitting on your laptop as plaintext. Every tool you install can read them. Every script that runs can read them. One accidental commit and your database password is public on GitHub forever. So I built dotlock — an encrypted .env vault with a terminal UI, written in Go. Before and after Before dotlock DATABASE_URL = postgres://localhost/myapp # plaintext, readable by anything STRIPE_KEY = sk_live_abc123 # one grep away from anyone After dotlock # .dotlock file on disk — looks like this: [ encrypted binary — unreadable without your private key] How it works under 10 seconds cd my-project dotlock set DATABASE_URL # prompts for value, input is masked dotloc # opens the terminal UI Secrets are encrypted with age — X25519 key agreement and ChaCha20-Poly1305 authenticated encryption. The same primitives serious security engineers use. No master password. No cloud. No telemetry. 100% offline. What it looks like Two panels — profiles on the left, secrets on the right. Values are masked by default. Press v to reveal for 30 seconds, then it hides itself automatically. Switch between dev , staging , and prod profiles. Run a diff before deploying to catch missing variables before they break your app. The interesting technical bit The hardest part wasn't the encryption — filippo.io/age makes that straightforward. It was the TUI. BubbleTea uses the Elm architecture — Model, Update, View. Everything is a message. A keypress is a message. A timer firing is a message. Your Update function receives messages and returns a new model. The 30-second auto-hide on secret reveal works like this — no time.Sleep , no goroutines: type secretReveal struct { key string value [] byte expire time . Time // Now() + 30 seconds } On every render, check if time.Now() is past the expiry. If it is, zero the bytes and clear the display. Simple once you understand the model but it took

Most developers paste production JWTs into online decoders without thinking. Here's a 10-second DevTools check to see if your token is actually leaving your machine. A coworker was debugging an auth bug last month. Standard workflow: copy the JWT from the failing request, paste it into an online decoder, read the payload. I've done it a thousand times. You probably have too. Except the token he pasted belonged to a real customer. And the decoder he used is owned by an identity company that's had its share of security incidents. Nothing bad happened. Probably. But it made me think about something I'd never actually checked: when you paste a JWT into an online decoder, where does that token go? What a JWT actually contains Quick reminder of why this matters. A JWT isn't encrypted — it's just Base64URL-encoded. Anyone who has the token can read everything in it: header.payload.signature The payload routinely contains: User ID, email, and role Session identifiers Token expiry ( exp ) and issue time ( iat ) Sometimes — against best practice — far more And here's the part people forget: a valid, unexpired JWT is a live credential. If it hasn't expired, whoever holds it can often impersonate the user. Pasting it into a random website is functionally similar to pasting a password. The 10-second check Most online JWT decoders claim to be "secure" and "client-side." Some are. Some aren't. You don't have to trust the claim — you can verify it yourself in 10 seconds: Open the decoder in your browser Open DevTools → Network tab Clear the network log Paste a JWT and decode it Watch the Network tab If any request fires when you decode — your token left your machine. A truly client-side decoder fires zero network requests during decoding. The JavaScript does everything locally; nothing is sent anywhere. Try this on whatever decoder you currently use. You might be surprised. Why most "online" tools send data It's usually not malicious. Building decoding logic on the server is someti

The moment I realized AI coding assistants were broken I was building a side project — a simple task manager app. I opened Claude Code, typed: "Add user authentication with email and password login" …and hit enter. Twenty minutes later, I had code. A lot of code. Authentication logic, routes, middleware, even some basic tests. But there was a problem. The frontend (me, on a different day) had assumed a different API shape. The tests only covered the happy path. There was no architecture decision to reference — I just picked JWT because it felt right. And the docker-compose.yml ? It didn't exist yet. I had AI-generated code, but no real software development workflow. What was actually missing Good software isn't just code. Before you write a single line, you need: A spec that everyone (including future-you) agrees on An architecture decision that explains the why Backend and frontend designed to talk to each other Tests that prove things actually work A code review that catches security holes before they ship A deployment config that someone can actually run Normally, a team handles all of this. A PM writes the spec. An architect proposes options. Engineers implement and review each other's work. A DevOps person sets up CI/CD. What if AI could fill all those roles? Building the pipeline I built claude-dev-pipeline — a Claude Code plugin that orchestrates a team of specialized AI agents, each with a specific job. airwaves778899 / claude-dev-pipeline 7-agent full-stack development pipeline plugin for Claude Code — PM → Architect → Backend → Frontend → QA → Reviewer → DevOps claude-dev-pipeline A Claude Code plugin that orchestrates 7 specialized AI agents to take your feature request all the way from requirements analysis to production deployment — with a human-in-the-loop checkpoint at every phase. 中文說明 Why? Writing a feature involves more than just code. You need: A clear spec that everyone agrees on An architecture decision before you write a single line Backend and

This is a submission for the Hermes Agent Challenge : Write About Hermes Agent I Didn't Start With Hermes Six months ago I started building a set of agent skills and personas for how I build software. Not generic prompts — opinionated role files. A /backend-architect that owns schema and recommendation logic. A /test-engineer that writes Vitest coverage and flags weak acceptance criteria. A /project-manager that maintains planning docs and closes iterations cleanly. These roles have evolved across multiple projects. They have layering rules, discovery checklists, inheritance from a base engineering discipline file. They produce consistent, reviewable work because they're scoped — the backend architect doesn't touch test files, the test engineer doesn't redesign the schema, each persona has a defined mandate and exits cleanly. When I heard about Hermes Agent, my first instinct wasn't "let me learn a new system." It was: can I run my existing system inside this? The answer is yes. That's what this article is about — what it looks like to bring a mature workflow into Hermes, what you gain, where it breaks down, and what I'd do differently. What Hermes Is (and Isn't) to Someone Who Already Has a Workflow Hermes is an LLM-agnostic orchestration layer. It has its own skill system, its own soul.md concept for persistent agent identity, built-in cron scheduling and MCP management. All of that is real and useful. But it's also a runtime. If you have skills that work, you can bring them in. I installed a local Hermes instance — few clicks, straightforward setup — and ran it inside VSCode's integrated terminal pointed at my existing persona files. No migration. No rewrite. My /backend-architect runs in Hermes the same way it runs in Claude Code. Before settling on this, I'd tried a couple of other paths — a VPS instance with a Telegram interface for ideation, and attempting to build through a browser-based terminal. The VPS was fine for sketching ideas. The browser terminal ma

Two stories landed in the same news cycle. Microsoft cancelled most internal Claude Code licenses....