AI 资讯

Everyone's building armies of AI "specialists" inside Claude Code. Most of them never trigger, collide with each other, and quietly bloat the very context window they were supposed to protect. I built and stress-tested 100 subagents — official built-ins, the big community collections, and a pile of my own — to find the handful that genuinely earn their keep. Here are the 12 I actually delegate to, the ones I deleted, and the uncomfortable truth about what a subagent is really for. Why I Went Down This Rabbit Hole This is the third time I've done this to myself. First it was 100 Claude Skills . Then 100 MCP servers . Now: subagents. Together they're the three pillars of the Claude Code stack — Skills give an agent competence , MCP servers give it capability , and subagents give it delegation . I'd covered two. The trilogy demanded the third. And subagents are where the hype is loudest right now. Open GitHub and you'll find collections with hundreds of them: VoltAgent's awesome-claude-code-subagents ships 154+ agents across 10 categories with 22.9k stars ; wshobson's marketplace packs 194 agents, 158 skills, and 16 orchestrators into 37.5k stars . The pitch is intoxicating: assemble a team of AI specialists — a security-auditor , a react-specialist , a kubernetes-specialist , a quant-analyst — and let Claude Code dispatch the right expert for every task. So I did the obvious thing. I installed, wired up, and actually used 100 subagents across real work: code review, debugging, test runs, security audits, database analysis, incident triage. I watched which ones Claude actually delegated to, which ones sat inert, and which ones quietly made my main conversation worse . Most got deleted. Not because they were badly written — many were excellent — but because I'd fundamentally misunderstood what a subagent is for . That misunderstanding is the whole point of this article, and I'll get to it before the list. This is the shortlist that survived. Twelve subagents. Out of a h

Most developers use Git every day and understand almost none of it. That's not an insult, it's just the reality of how most people learn tools. You pick up the commands that get you through the day, you memorize the ones that fix the situations you keep breaking, and you build a working mental model that is almost entirely wrong at the mechanical level. The mental model most people carry looks something like this: Git tracks changes to files. When you commit, it saves a snapshot of what changed. Branches are pointers to different lines of work. That's roughly correct at a surface level, but it skips over the actual machinery in a way that leaves you confused every time something unexpected happens. Why does rebasing rewrite history? Why are commits immutable? Why does detached HEAD state exist? Why can you lose work in ways that feel impossible if Git is just tracking changes? The answers are all in the object model, and the object model is surprisingly simple once you sit with it. Git is a content-addressable filesystem Before any of the version control concepts, Git is a key-value store. You put content in, you get a hash back. You use that hash later to retrieve the content. That's the entire foundation, and everything else is built on top of it. The hash Git uses is SHA-1, producing a 40-character hexadecimal string. When you run git hash-object on a file, Git takes the content, prepends a small header describing the object type and size, and runs SHA-1 over the whole thing. The resulting hash is both the key and the identity of that content. Two files with identical content will always produce the same hash. A file whose content changes even slightly will produce a completely different hash. This is the first thing that breaks people's mental models. In most storage systems, identity is location: a file is "that file" because it lives at that path. In Git's object store, identity is content. The path a file lives at is separate metadata, not the file's identity

KiCad, a PCB EDA suite is now working in a browser, you can try it at the link, there's a demo project or you can bring your own. Firefox is best, Chrome is good, Safari is "working". We’re Emergence Engineering, a dev shop from Hungary, mostly working with rich text editors, CRDTs. PCBJam started as my (Viktor, CTO, ex-electrical engineer) hobby project but as time went on I put more and more energy into it, and a product started shaping up in my head, in the last few months we’ve started to fo

This is The Stepback, a weekly newsletter breaking down one essential story from the tech world. For more on the bleak state of the video game industry, follow Andrew Webster. The Stepback arrives in our subscribers' inboxes on Sunday at 8AM ET. Opt in for The Stepback here. How it started Microsoft closed out Summer […]

This massive 85-inch model is highly customizable but jaw-droppingly expensive.

Your order-processing Lambda starts sending duplicate confirmation emails. Not always — maybe one order in twenty. CloudWatch shows more invocations than messages published. The function code hasn't changed in weeks. What changed is that someone added a fraud check that pushed processing time from 25 seconds to around 45, and your SQS queue is still running the default 30-second visibility timeout. That combination is the whole bug. When a Lambda pulls a message from SQS, the message isn't deleted — it's hidden for the duration of the visibility timeout. If the function is still working when that window closes, SQS assumes the consumer died and hands the same message to another invocation. Now two Lambdas are processing the same order, both will "succeed," and both will send the email. Nothing errors. Nothing retries. There is no log line that says "this message was delivered twice because your timeouts are misconfigured." Infrawise ( npm ) flags this exact mismatch as a high-severity finding before it costs you an afternoon of staring at idempotency-free handler code. This post walks through why the bug is so hard to see, how the detection works, and how to keep an AI assistant from reintroducing it. Why you never catch this one yourself Three things make this misconfiguration nearly invisible: It passes every test. In local tests and staging, your handler processes a synthetic message in two seconds. The 30-second visibility window never comes close to expiring. The bug only exists under production conditions — real payload sizes, real downstream latency, cold starts stacking on top of slow dependencies. The defaults set the trap. SQS queues default to a 30-second visibility timeout. Lambda functions routinely get their timeout bumped to 60, 120, or 900 seconds as they grow. Nobody bumps the queue at the same time, because the two settings live in different consoles, different IaC resources, and usually different pull requests. The failure signature points elsewhe

Modern C# Features: A Deep Dive into Records, Pattern Matching, Async, and Performance A practical guide to the C# language features that have reshaped how we write .NET code — records, pattern matching, async/await improvements, nullable reference types, LINQ enhancements, Span<T> , and performance optimizations. Table of Contents Introduction Records Pattern Matching Async/Await Improvements Nullable Reference Types LINQ Enhancements Span<T> and Memory<T> Performance Optimizations Quick Reference Table Conclusion Introduction C# has evolved significantly since C# 8. Each release (9, 10, 11, 12, 13) has focused on three consistent themes: Conciseness — write less boilerplate to express the same intent. Safety — catch bugs at compile time instead of runtime (especially around null ). Performance — give developers low-level control without leaving the managed, safe world of .NET. This guide walks through the features that matter most in day-to-day development, with working code examples you can drop into a dotnet run project. 1. Records Introduced in C# 9 , record types give you immutable, value-based data models with almost no ceremony. Why records exist Before records, representing an immutable data object meant hand-writing a constructor, Equals , GetHashCode , ToString , and often a With -style copy method. Records generate all of this for you. // Before: a "plain" immutable class public class PersonClass { public string FirstName { get ; } public string LastName { get ; } public PersonClass ( string firstName , string lastName ) { FirstName = firstName ; LastName = lastName ; } public override bool Equals ( object ? obj ) => obj is PersonClass p && p . FirstName == FirstName && p . LastName == LastName ; public override int GetHashCode () => HashCode . Combine ( FirstName , LastName ); public override string ToString () => $"PersonClass {{ FirstName = { FirstName }, LastName = { LastName } }} " ; } // After: the same thing as a record public record Person ( stri

In-process cron ( node-cron , @nestjs/schedule , OS crontab) runs inside one Node process. That is fine for a single instance, but it does not survive restarts gracefully, deduplicate across replicas, or share infrastructure with your other background jobs. BullMQ stores queues and schedulers in Redis . Job Schedulers (BullMQ 5.16+) are the recommended way to enqueue recurring work on a cron pattern or fixed interval. The same workers that process one-off jobs also process scheduled ones, with retries, backoff, and concurrency you already get from BullMQ. This post covers Job Schedulers in plain Node.js, operations and pitfalls, a NestJS setup with @nestjs/bullmq , and a runnable demo with a fast cron heartbeat and a daily cleanup cron. Prerequisites Node.js version 26 Redis at redis://localhost:6379 (included in the demo docker-compose.yml , or use Postgres and Redis containers with Docker Compose ) npm i bullmq For the NestJS section: npm i @nestjs/bullmq bullmq BullMQ 2.0+ does not require a separate QueueScheduler instance. Use the Job Scheduler API ( upsertJobScheduler ), not the deprecated repeat option on queue.add() . Mental model Piece Role Queue Holds jobs waiting to run Worker Executes jobs Job Scheduler Factory that enqueues jobs on a schedule Scheduled job A job instance produced by a scheduler A scheduler id is stable across deploys. Calling upsertJobScheduler with the same id updates the schedule in place instead of creating duplicates. Queue and worker Share one Redis connection config between the queue and the worker: import { Queue , Worker } from ' bullmq ' ; const connection = { host : ' localhost ' , port : 6379 }; const queue = new Queue ( ' reports ' , { connection }); const worker = new Worker ( ' reports ' , async ( job ) => { console . log ( `[ ${ job . name } ]` , new Date (). toISOString (), job . data ); }, { connection }, ); worker . on ( ' failed ' , ( job , error ) => { console . error ( job ?. name , error . message ); }); Start the

Hello, everyone. When listening to a conversation, we naturally keep track of who is speaking. A program has a harder job: beyond finding speech, it must also determine where one speaker gives way to another. Today, I will use an ONNX version of Pyannote Segmentation 3.0 to detect speaker changes in a two-person conversation and split the recording into one WAV file per utterance. What I Tested This lab uses FFmpeg to decode a roughly 14-second conversation into a 16 kHz mono waveform. It then combines the Pyannote segmentation model with simple post-processing to produce contiguous speaker segments. I wanted to verify: Whether six alternating utterances can be separated into six segments Whether the detected speaker indexes remain consistent throughout the recording Whether ONNX Runtime can process the audio faster than real time using only its CPU execution provider Whether every segment can be saved as a separate WAV file The complete code and reproducible environment are available in the pyannote-scd lab in kiarina/labs . This test performs segmentation using the model's speaker indexes. It does not compare speaker embeddings or run clustering, so it is not a complete speaker diarization pipeline that identifies the same person throughout a long recording. Reproducing the Lab You will need: mise uv FFmpeg curl The following commands fetch only this lab, download the shared test audio, and run it: git clone --depth 1 --filter = blob:none --sparse \ https://github.com/kiarina/labs.git cd labs git sparse-checkout set .gitignore .mise/tasks Makefile mise.toml \ 2026/07/04/pyannote-scd make download-test-assets mise -C 2026/07/04/pyannote-scd run On the first run, the task downloads the full-precision onnx/model.onnx file from onnx-community/pyannote-segmentation-3.0 on Hugging Face. uv then prepares the Python dependencies and runs the detector. How Speaker Segments Are Detected The input is this shared test asset: assets/mp3/conversation_2speaker_14s_16k.mp3 The re

When asked how I evaluate BMAD recently I said haven't quite decided yet, but it definitely has strong sides and makes development faster. Of course, it dependss what you are currently work on. If you work in scrum and handle single tasks from Jira, you probably won't fin BMAD useful in any way. It's strength is in handling large projects which have to be taken from brainstorming, through requirement specification to proper design and implementation plan. BMAD does really good job in asking the right questions and pushing you into providing all necessary details. The only thing I found a bit discouraging was the boring implementation phase where you just keep clicking approve. I was recently pointed to Superpowers framework, which apparently deosn't have that problem and does the implementation part without human interaction. I tested it, but to be honest I wasn't impressed. In my case it didn't work so good. The whole planning phase comes down to brainstorming and implementation plan. This is clearly not meant to be handling large complex projects. In BMAD you have several distinct steps where each of them is handled with care and brings value to the final design. First, the brainstorming in BMAD pushes you into providing all available information, any documents you may already have and then asks a bunch of questions. Superpowers is more like: give me a brief intro and I will make up the rest. In BMAD, brainstorming is just the start, then you go to PRD, UX and architecture. You have to really spend some time to get it right, but that's exactly the real value, you spend the effort on planning, but save long hours of searching for bugs in the implementation or re-implementing the solution. Having said that, I am going to keep using BMAD, but there is still the issue I mentioned, and it has to be taken care of. The implementation itself is a pain. It's not just the approval thing, this can be fixed easily, by running cluade with --dangerously-skip-permissions , which

🧠 Building CogneeCode - AI Developer Memory Assistant The Problem Every developer faces the problem of lost context. "Why did I make this decision 3 months ago?" "How did I fix this bug last week?" Current AI tools forget everything between sessions. This is a real problem that wastes hours of developer time. My Solution CogneeCode is an AI developer memory assistant that builds a permanent knowledge graph using Cognee Cloud . It remembers every decision, bug fix, and code context you give it. What It Does ✅ Log architectural decisions with tags and context ✅ Log bug fixes with error messages and solutions ✅ Ask natural language questions about your codebase ✅ Get answers with evidence citations from the knowledge graph ✅ Semantic search across all memories ✅ Visual timeline of all decisions and bug fixes ✅ Analytics dashboard showing memory insights ✅ Knowledge graph visualization Tech Stack Backend: Flask (Python) Memory Layer: Cognee Cloud LLM: Groq Llama 3.3 Frontend: Vanilla HTML + CSS + JS Icons: Tabler Icons Cognee Cloud APIs Used remember() - Save decisions and bug fixes with metadata recall() - Natural language queries with evidence citations search() - Semantic search across memories visualize() - Knowledge graph visualization improve() - Memory graph enrichment forget() - Remove outdated memories Why This Matters When you return to a project after months, all your reasoning and solutions are still there, searchable in natural language. No more "Why did I do this?" or "How did I fix this bug?" Demo Watch the video: https://youtu.be/TNcBIBuPW7c Links 🔗 GitHub: https://github.com/JOSESAMUEL14/cogneecode 🔗 Live Demo: https://josesamuel.pythonanywhere.com AI Assistance Disclosure Built with assistance from Claude and Gemini AI. Built for WeMakeDevs x Cognee Hackathon 2026 Category: Best Use of Cognee Cloud ⭐ Star the repo if you find it useful!

You did the hard part. You designed it, you built it, you shipped it. The product is good. And still, the users do not come. I have been in that exact spot more than once. You refresh the analytics, you tell yourself it is early, and quietly a worse question starts to form: what if people are not ignoring my app, what if they simply never see it? Here is the thing almost nobody tells builders in 2026. For a growing share of your future users, the front door to the internet is no longer a list of blue links. It is a sentence. Someone opens ChatGPT, Perplexity, or Google's AI Mode and types "what is the best tool for X." The model replies with a short list of names. If your product is not one of them, you do not exist in that moment. There is no page two to claw your way onto. There is one answer, and you are either in it or you are not. Three things are probably true about your app right now, and you cannot see any of them Your app might render blank to the machines that decide. If you built a single-page app (React, Vue, most modern stacks), the raw HTML a crawler receives can be an almost empty . Most AI crawlers do not run JavaScript. They read what your server sends and leave. To them, your beautiful app has no words, no product, no reason to be cited. You can rank number one on Google and still be missing from the answer. In one large 2025 study, roughly 68 percent of the pages cited in AI Overviews were not even in the top ten organic results. Ranking and being cited have quietly become two different games. Winning the old one no longer wins you the new one. A model may already be describing your product to strangers, and getting it wrong. A feature you do not have. A price that is out of date. A category that is not yours. You are being represented in rooms you will never enter, by a narrator you never hired, and the only way to fix the story is to give the machines a cleaner one to read. None of this shows up in your dashboard. That is what makes it dangerous

Artificial Intelligence has changed the way we write software, but one thing has become clear: AI is a collaborator, not a replacement. After using coding assistants for months, I've realized they're best at handling repetitive tasks: Generating boilerplate code Explaining unfamiliar APIs Refactoring existing functions Writing documentation Creating unit tests Finding bugs faster Where AI still struggles is understanding the bigger picture. It doesn't know your product vision, business requirements, or why one architectural decision is better than another. Those are still human problems. The most productive workflow isn't asking AI to build an entire application from scratch. It's treating AI like an experienced teammate that can help with implementation while you stay responsible for the design and direction. The developers who will thrive over the next few years won't necessarily be the ones writing the most code—they'll be the ones asking better questions, validating AI-generated solutions, and combining technical knowledge with critical thinking. AI is changing software development, but it's also raising the value of good engineering judgment. How has AI changed your development workflow? What's one task you now almost always delegate to an AI assistant?

Honestly it's not a new concept. this feature already existed in models before. problem was the models were just weak. Looping only works if each attempt gets the agent closer to the correct solution. Earlier models weren't consistent enough for that. They often misunderstood feedback, repeated the same mistakes, or got stuck in an infinite loop. Instead of improving with each iteration, they frequently failed to make meaningful progress, eventually consuming large numbers of tokens without solving the problem. The Context Window Limitation Earlier language models had much smaller context windows. As the agent went through more iterations, the conversation history and reasoning gradually filled the available context. Once the context window was exceeded, older messages had to be dropped or compressed into summaries. As a result, the agent could forget previous failed attempts, lose important clues or reasoning, and sometimes repeat the same mistakes it had already made. So what did modern models actually fix? Bigger context windows Models can now hold way more of the conversation/history without forgetting, so the agent doesn't need to spin up a fresh session every few iterations. it can just keep looping with the full history of what failed and why. modern models also got way more consistent earlier if you asked a model to fix the same bug 5 times you'd get 5 different half-baked answers, now it actually converges toward the real fix. and tool use got better too . Old models could write code but couldn't run it and read the actual error, now they call a test runner, see the real failure, and fix that exact thing which is literally what makes the "verify" step possible. And then there's inference it is simply the process of a model generating an answer. like when you type "write a java binary search," the model reads your prompt, thinks, and generates code that whole process is inference. every time the model generates text, that's one inference. now here's the thin

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