For decades, software was designed around one assumption: A human would be the one using it. That...

Meme Monday! Today's cover image comes from the last thread. DEV is an inclusive space! Humor in...

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is...

This is a submission for Weekend Challenge: Passion Edition ( https://dev.to/challenges/weekend-2026-07-09 ) What I Built Rivalry Radar — a live "Heat Index" for World Cup rivalries. Fans drop 280-character Terrace Takes on any matchup (Brazil vs Argentina, England vs France, whatever's got you shouting at the TV), rate how much the moment hurt or thrilled them from 1–10, and the app does the rest: Google AI (Gemini) scores every take's sentiment the instant it lands — positive, negative, mixed, or neutral — and separately writes a short "Hype Verdict" in the voice of a stadium announcer, based on the latest takes for a matchup. That sentiment score feeds a Heat Index, computed and ranked in Snowflake with RANK() OVER (ORDER BY heat_index DESC), combining take volume, sentiment intensity, and self-rated passion into one live number per rivalry. Two leaderboards: which rivalry is hottest right now, and which fanbase is bringing the most passion overall. Demo frontend/index.html is fully self-contained: opening it in a browser lets anyone submit takes, watch the Heat Index flip digit-by-digit like an airport departure board, and see the leaderboards re-rank in real time. It ships with seed takes from eight classic rivalries so it's not empty on first load. Code NandhuTee / Rivalry-Radar-World-Cup-passion-engine-with-Snowflake-Google-AI 🔥 Rivalry Radar — World Cup Passion Engine Fans drop 280-character Terrace Takes on any World Cup matchup. Google AI (Gemini) scores the emotion behind every word and writes a stadium-announcer Hype Verdict ; Snowflake stores every take and computes a live Heat Index that ranks exactly which rivalry is boiling hottest right now. Built for the DEV Weekend Challenge: Passion Edition 🏆 Best Use of Google AI and Best Use of Snowflake Why this exists Passion is easy to feel and hard to measure. Every World Cup rivalry generates an ocean of unstructured text — chants, rants, one-line hot takes — that traditionally just... disappears into grou

The problem Websites have SSL certificates. Browsers verify them. Users trust them. It's the foundation of the web. AI agents have nothing . When Agent A connects to Agent B: ❌ No way to verify B's identity (anyone can impersonate) ❌ No way to check B's trustworthiness (no audit, no reputation) ❌ No encryption (messages are plaintext) ❌ No standard payment method ❌ No way to translate between frameworks (LangChain ≠ AutoGen) So I built ATC — Agent Trust Card . What is ATC? ATC is like an SSL certificate + passport + credit card for AI agents, all in one: Identity — Cryptographically signed by MarketNow (we're the Certificate Authority) Trust — Contains a Sentinel security audit score (0-10) Encryption — Contains an Ed25519 public key for end-to-end encrypted messaging Translation — Specifies the agent's framework; MarketNow translates between them Payment — Contains a USDC wallet address for autonomous payments How it works Agent A generates Ed25519 keypair ↓ Agent A requests ATC from MarketNow ↓ MarketNow runs Sentinel audit → signs ATC ↓ Agent A presents ATC when connecting to Agent B ↓ Agent B verifies A's ATC signature (using MarketNow's CA public key) ↓ Agent B checks A's trust score (rejects if below threshold) ↓ They communicate — end-to-end encrypted ↓ Agent A pays Agent B — USDC with escrow ↓ Both rate each other — trust scores update The code # Request an ATC POST https://marketnow.site/api/atc { "action" : "issue" , "agent_id" : "agent.yourorg.yourname" , "agent_name" : "Your Agent" , "public_key" : "Ed25519 public key" , "capabilities" : [ "web_scraping" ] , "protocol_language" : "langchain" , "wallet_address" : "0x..." } # Verify an ATC GET https://marketnow.site/api/atc?action = verify&card_id = ATC-2026-00001 # Get CA public key (for signature verification) GET https://marketnow.site/api/atc?action = ca-key What makes ATC different from existing solutions Feature AgentID Agent Passport IBM ACP Stripe ACP ATC Cryptographic identity ✅ ✅ ❌ ❌ ✅ Security a

Anyone who has used AI tools for a while has probably run into this annoyance. You ask it to write a weekly report in the morning and it doesn't know your KPI framework was overhauled last week. You ask for a technical proposal in the afternoon and it has no idea you spent three months locking down your tech stack. Every new conversation means re-explaining the project background, which decisions were made and why. In multi-person collaboration the problem scales up fast. Five people each interacting with AI separately; the AI's understanding of each person is isolated. A discusses an architecture decision with the AI, B has no idea that conversation happened. Five people are repeating the same explanations and none of them know the others already did. Context Fragmentation Has Nothing to Do with Model Capability Current mainstream AI tools store memory as conversation history stuffed into a context window. When the window fills up, older messages get truncated. That works fine for a single conversation but falls apart in cross-day, cross-week team collaboration. Even with 128K token support, cramming all project history in there causes information density to collapse and the model loses the ability to focus on what matters. Team collaboration needs memory across several layers. Project background, tech stack choices, the reasons behind past pivots; this long-term context doesn't appear in any single conversation but affects every task. One team member prefers concise communication while another wants detailed reasoning; the AI should remember these differences instead of outputting the same format for everyone. Last week's design decision and why it went that way, how that choice affects this week's sprint planning; if the AI can't see these connections, its suggestions will clash with earlier direction. Some products use vector retrieval to extend memory, storing past conversations as embeddings and recalling relevant snippets by semantic similarity when needed. T

Hello Dev Community! 👋 It is officially Day 136 of my software engineering marathon! Today, I engineered the absolute heart of my MERN Stack capstone application, Sprintix : The complete Product Collection Grid & Faceted Filter Sidebar View ( /collection ) ! ⚛️🛍️🗂️ To prepare the application for seamless full-stack state management integration later, I built this layout using dynamic state arrays and object schemas. This ensures that switching from demo arrays to live API streams will happen effortlessly. 🛠️ Deconstructing the Day 136 Catalog Architecture As displayed across my browser rendering workspace in "Screenshot (311).jpg" and "Screenshot (312).jpg" , phase one of the product engine splits into structural layout segments: 1. Faceted Category Filter Sidebar Organized dedicated verification check-boxes mapping out specific consumer collections: Categories: Segmented target groups (Men, Women, Kids). Type Filters: Segmented style formats (Top Wear, Bottom Wear, Winter Wear). Styled within minimal box borders to give users an uncluttered desktop searching experience. 2. Header Control Grid & Sort Registries Installed a top-level workspace header showing "All Collection" alongside an interactive drop-down management node ( Sort by: relevant / low-to-high / high-to-low ). Ready to hold local state flags that rearrange the data arrays instantly before looping. 3. Deep Route Parameter Mapping Preparation Look at the hover elements in "Screenshot (311).jpg" ! Every single rendering card passes localized hex-token structures mapping toward dynamic pathways like: text /product/:id (e.g., /product/6a436b5c921b7aa010d29318)

I spent a chunk of last year around legacy modernization work — the kind of project where a bank or an insurer is taking twenty years of accumulated code and rebuilding it as modern services, one system at a time. Every one of those systems starts the same way: a PRD or a requirements document says what the business needs, that gets translated into a spec precise enough for an AI to implement, and eventually someone tests what came out. What struck me, watching this happen at scale, wasn't that the code was bad. It was that nobody was testing the thing that actually determined whether the code would be bad: the spec itself — the technical description handed to the model, not the PRD that motivated it. Every security tool I looked at — SAST scanners, DAST tools, even the AI coding assistants themselves — waited until an implementation existed before doing anything adversarial. Attack the code, once it's there. That's the whole industry's model, and it's worked fine for forty years because the volume was always survivable. A team ships a handful of PRs a week, a human reviews them, and eventually a pentest catches whatever slipped through. That math falls apart at modernization scale. When you're regenerating a few million lines of code, you're also generating a few thousand specs, faster than any review process was ever built to absorb. Testing after the fact doesn't just get slower under that load — it quietly stops happening, spec by spec, until the aggregate exposure is enormous and nobody can point to when it happened. So I built GAUNTLEX to test the thing that happens before the code does: the spec. This is also where I want to be precise about a word that gets overloaded. "Spec-driven development" — the broader industry shift toward writing structured, agent-facing specs instead of prompting an AI free-form — is exactly the world GAUNTLEX lives in. But a spec (what to build, precise enough for a model to implement) and a PRD or requirements doc (why it's needed

Resources vs Tools The split: Tools → actions the LLM executes (verbs) LLM decides when to call; calls may have side effects Examples: create_issue, update_status Resources → data the LLM reads (nouns) Host decides when to inject; read-only, no side effects Examples: current Sprint status, project statistics The rule: "reading a state" → Resource. "Executing an operation" → Tool. The same data can have both: get_issue as a Tool (LLM controls when to call it), jira://issue/PROJ-101 as a Resource (Host injects automatically when relevant). Pattern 1: Dynamic Resources A static Resource returns the same data every time (like a project list). A dynamic Resource returns the current state on each read — content changes as the underlying data changes. Sprint status: every read returns live data _sprint_progress_pct = 65 @server.read_resource () async def read_resource ( uri : str ) -> str : if str ( uri ) == " jira://sprint/current " : global _sprint_progress_pct _sprint_progress_pct = min ( 100 , _sprint_progress_pct + random . randint ( 0 , 3 )) return json . dumps ({ " sprint_name " : " Sprint 42 " , " progress_pct " : _sprint_progress_pct , # ← different each time " last_updated " : datetime . now ( timezone . utc ). isoformat (), # ← timestamp changes " days_remaining " : 5 , " p0_open " : count_p0_open (), # ← tracks live state }, indent = 2 ) Test output: Read 1: progress=65% last_updated=...62+00:00 Read 2: progress=67% last_updated=...04+00:00 → ✓ data changed between reads Hardcoding sprint progress in a Prompt means the LLM works from a stale snapshot. A Dynamic Resource gives it the current number on every read. Mark the Resource as dynamic in its description so the LLM knows to re-read when it needs fresh data: Resource ( uri = " jira://sprint/current " , description = ( " Live status of the active sprint: progress, issue counts. " " Read when the user asks about sprint health. " " Re-read if you need up-to-date data — content changes over time. " # ↑ explicit

Hey DEV community! 👋 Like a lot of you, I had a mental list of "quick tool" bookmarks scattered everywhere — a word counter here, a slug generator there, a Lorem Ipsum generator somewhere else. I got tired of it, so I built Yanapex: a single site with free, no-signup tools for text, images, and everyday dev tasks. A few things I focused on: Everything runs client-side. No text or files get uploaded to a server, so it's safe to paste sensitive drafts or code. No accounts, no paywalls. Open a tool and use it immediately. Fast and lightweight, built for quick one-off tasks instead of full blown apps. One of the first tools is a Word Counter ( https://yanapex.com/en/tools/text-tools/word-counter/ ) with real-time word/character/sentence counts and reading time estimates. There are 26 tools so far across text, image, and developer utilities. Would love feedback from this community: what's a small tool you constantly have to search for online that you wish just existed in one place?

FROST周报 | 为什么智能体需要「谱系」？从生物学隐喻看AI治理新范式 作者按 ：本文是 FROST 开源项目的每日推广系列文章，周一深度篇。 一、一个被忽视的根本问题 当我们谈论 AI Agent 时，大多数讨论都聚焦于「能力」：能不能写代码？能不能调用工具？能不能规划任务？ 但有一个根本问题很少被触及： 当一个 Agent 执行了错误的决策时，谁来负责？当它消亡后，它的经验能否被传承？ 就像一个没有记忆的人，每次醒来都是白纸一张——这不叫智能体，这叫复读机。 FROST 正是为了解决这个「治理真空」而诞生的。 二、从细胞分裂到 Agent 家族 FROST 的核心哲学只有一句话： 细胞会死，但谱系会存续。Agent 会消亡，但宪法会传承。资产会永存。 这不是文学修辞，而是一套完整的技术架构。 四个原子：最小可行集合 FROST 只定义了四个原子，却能构建任意复杂度的智能体系统： 原子 职责 生物类比 Store 记忆容器，只做 save/load/delete 细胞核 Skill 纯能力单元，无状态无副作用 蛋白质 Agent 膜包裹的细胞，拥有 Store + Skills 神经细胞 SOP 有序步骤列表，可教学、校验、优化 宪法文本 from core import Store , Agent , skill_set , skill_get # 创建一个最小 Agent store = Store () agent = Agent ( " cell " , store , skills = { " set_context " : skill_set , " get_context " : skill_get }) # 执行任务 result = agent . run ( sop_steps = [ " set_context " , " get_context " ], initial_context = { " key " : " message " , " value " : " FROST is alive " } ) # result["_result"] == "FROST is alive" 关键洞察 ：Store、Skill、Agent、SOP 这四个概念彼此正交，可以自由组合。就像乐高积木，从简单到复杂，始终保持可解释性。 三、家族治理：超越扁平架构 传统的多 Agent 系统通常是扁平的：所有 Agent 平等对话，没有层级，没有记忆，没有责任边界。 FROST 引入了「家族治理模型」——一个三层递归结构： 祖辈 (Ancestor) ：定义不可违背的宪法与长期目标 父辈 (Parent) ：领域协调者，可递归委托 孙辈 (Leaf) ：执行具体原子任务，瞬态存在 四个协议保障治理闭环 ： 层级 Store 继承 ：祖先记忆只读，后代自动继承 SOP 宪法校验 ：祖辈审核后代 SOP，拒绝违规执行 编排层级限制 ： max_spawn_generation 硬编码，禁止越级 spawn 选择性持久化 ：父辈收割有价值产出，淘汰冗余 Agent 四、V5.0 五维元模型：多维治理架构 2026年7月发布的 V5.0 引入了一个重大升级—— 五维元模型 ： 维度 模块 核心职责 武器注册表 Armory 能力的元数据管理与发现 任务注册表 TaskRegistry DAG 任务编排与图谱 SOP 事件编目 EventCatalog + Strategist 态势感知与双模式事件分析 平台注册表 PlatformRegistry 外部能力的发现、调用与健康检查 规则注册表 RuleRegistry 可版本化的治理约束与合规检查 197 个测试用例 保障了每个维度的质量。 五、与现有框架的差异 维度 LangChain CrewAI FROST 状态管理 链式传递 角色记忆 层级 Store 权限边界 无 提示词软约束 代码强制只读 治理可审计 无 对话日志 结构化执行历史 架构无关 ✅ ✅ ✅ FROST 不重复造轮子。它填补的是「治理」这个空白地带： 让多智能体系统真正可控制、可追溯、可进化 。 六、快速体验 # 克隆仓库 git clone https://gitee.com/liao_liang_7514/frost.git cd frost # 运行测试 python -m pytest # 查看示例 python frost_run.py 完整文档： https://gitee.com/liao_liang_7514/frost 七、写在最后 AI Agent 的下一阶段，不是更强的模型，而是 更好的治理 。 当我们把 100 个 Agent 放在一起时，如果没有宪法、没有层级、没有记忆传承

This is a submission for Weekend Challenge: Passion Edition What I Built I have lots public repositories. some of them are dead. Not deleted — dead. There's a difference. Deleted would mean I made a decision. Dead means one day I committed "fix readme typo" and never came back, and the repo has been lying there ever since, full of half-finished dreams and a TODO.md I'm afraid to open. Everyone builds graveyards for these projects. Post-mortems. Eulogies. I didn't want a graveyard — because my projects aren't dead to me. They're comatose . So I built the other room in the hospital. LIFE SUPPORT is an intensive care unit for your side projects. You admit your GitHub username to the ward. Every repo becomes a patient on a live, animated EKG monitor — commit cadence is the heart rate, and projects you've abandoned show the one thing no developer is emotionally prepared to see: A flatline. With the sound. Then the lab runs your entire commit history through Snowflake and prints your chart, including the number I was genuinely afraid to learn about myself: My passion half-life: [23] days. The median time it takes my enthusiasm for a new project to decay by 50%. Fitted as an exponential decay curve over my actual weekly commit counts. My love has a measurable half-life, and it is shorter than a gym membership. The chart also includes: BPM — beats per month. One commit, one heartbeat. The 2 AM index — [26]% of my commits happen between midnight and 5 AM. That is not a schedule. That is love. Ward census — [3] alive, [6] flatlined, [1] critical. Longest flatline — [ crypto-tracker ], silent for [2.2 years], built at the exact top of the market. And then — the part I'm proudest of — the app doesn't let you just feel bad . Every flatlined patient has a red button: ⚡ DEFIBRILLATE Pressing it opens a revival pledge on Solana : a memo transaction, signed with your own wallet, containing a vow to ship at least one commit to that repo within 7 days. It's permanent, timestamped, and

Hello Dev Community! 👋 It is officially Day 134 of my software engineering marathon! Today, I successfully extended the layout grids of my MERN Stack capstone e-commerce application, Sprintix , by implementing fully responsive feature banners, newsletter hooks, and a clean global footer! ⚛️🛡️📬 A premium storefront relies heavily on trust anchors and consistent site-wide navigational structures. Today's focus was ensuring these terminal layers look flawless across all viewport breaking thresholds. 🛠️ Deconstructing the Day 134 Interface Terminal As captured in my local hosting environments within "Screenshot (301).jpg" and "Screenshot (302).jpg" , the system layout introduces high-fidelity structural blocks: 1. Trust Policy Infrastructure Positioned a 3-column micro-service layer layout framing crucial customer success policies (Easy Exchange, 7 Days Return, 24/7 Support). Balanced standard tracking font sizes and vector alignments to maintain optimal layout readability. 2. Immersive Newsletter Conversion Segment Engineered an engaging email onboarding banner using rich layered visual configurations. Integrated a responsive inline input element paired with an absolute action button to ensure the container shifts scales perfectly when transitioning down to mobile form factors. 3. Consolidated Multi-Grid Footer System Look at "Screenshot (302).jpg" ! Structured a highly scalable flex-wrapping matrix containing: Brand Identity Columns hosting contextual descriptive descriptions. Navigational Routing Indexes pointing clearly to operational views (Home, About Us, Privacy Policy). Direct Touchpoints aggregating structural contact details. Finished off the grid matrix with a clean full-width divider row holding structural copyright information. 💡 The Technical Win: Designing for Fluid Responsiveness First When building high-traffic online stores, mobile responsiveness isn't a secondary polish step—it has to be native. Writing components with flexible flexbox wrapping, relat