今日已更新 377 条资讯 | 累计 26360 条内容
关于我们

标签:#ai

找到 4693 篇相关文章

AI 资讯

The problem with security scanners isn't the scanning

At a previous job I worked at as a Dev we had someone who ran Semgrep on our codebase for the first time. It came back with 180 findings. We had no security engineer. The developer who ran it looked at the output, closed the terminal, and we never ran it again. That's not a story about a careless team. That's a story about a tool that produced output most teams in small companies with no expertise knew what to do with. I've seen this exact moment happen more times than I can count working with small dev teams. And it's the reason I spent the last year building SecOpsium. But before I get to that let me explain the actual problem, because I think it's misunderstood. The problem isn't the scanning Semgrep and Gitleaks are excellent tools. They're free, actively maintained, and genuinely powerful. If you're not using them you should be. The problem is what happens 10 minutes after you run them. You get 200 findings. Some are critical. Some are test files. Some are commented-out code from 2021. Some are legitimate secrets. Some are variable names that pattern match against a rule but contain nothing sensitive. They all look the same in the output. Now you're a developer who also does DevOps, also reviews PRs, also handles incidents, and you're staring at 200 items with no clear indication of which three actually matter this week. So you close the terminal. Or you create a Jira ticket labeled "security findings" that lives in the backlog forever. Or you spend two days triaging manually and burn out before you fix anything. This is the real problem. The scanning was never the hard part. Why rule based scanners produce so much noise It helps to understand technically why this happens. Semgrep and Gitleaks are rule-based. They match patterns. A variable named api_key_example in a test file flags the same way as a live Stripe key in an active production config. Gitleaks scans for entropy and known credential patterns but can't distinguish between a key that was rotated and r

2026-05-29 原文 →
AI 资讯

Put your Coding Agents in Drive w/ Superpowers (aka How Superpowers is the Automatic Transmission of Agentic Coding)

The most downloaded and widely used methodology in the Claude Code ecosystem is Superpowers , with over 208k stars⭐️ and 18.5k forks🍴 on GitHub (and counting!) Going from raw Claude Code to using Superpowers is as revolutionary as going from a manual transmission to an automatic. Here's why this analogy holds: Planning Mode vs. Coding Mode When we build with Claude (or Codex, or Gemini...), we're usually in one of two states: planning mode coding mode Like shifting gears in a car🚘, moving between these modes effectively is what makes it all work. Skip the shift, and you're just revving your engine (aka burning context and going nowhere.) Superpowers lets Claude automatically detect and shift between these modes. It picks up on ambiguity in your prompt and ensures it fully understands the task before entering coding mode. No manual shifting required! Slower, but for Good Reason Superpowers can feel slower and less satisfying than raw Claude Code, like how driving an automatic can feel less engaging than a manual. But both serve the same critical purpose: they stop you from blowing up your engine! That said, there's still a time and place for raw Claude. Sometimes you want direct, fast, unmediated output. But that minor gain in speed often isn't worth the added complexity, the ambiguity risk, and the tradeoffs that come with it. The Layer Underneath Entire is building the foundation beneath all of this — capturing every session and decision, and linking it to the commit it produced. It's the full record of how the code was written, not just the code itself. So the question is this: how will you put your agent in drive🚘?

2026-05-29 原文 →
AI 资讯

Why I built tmpdrop: a self-hosted, expiring file drop

I had a screenshot to send. Nothing secret — a stack trace from a side project — but it had an internal hostname, a file path with my username, and a chunk of a config file in the terminal behind it. The fast move is to drag it onto a free image host and paste the link. I sat there with my cursor over the upload button and couldn't do it. Because I know what happens next. That image lives on someone else's infrastructure, indefinitely, behind a URL I don't control, and I have no idea who else can reach it. For a throwaway screenshot, that's a permanent record I never agreed to. So I closed the tab and built a thing instead. It's called tmpdrop , and it's ~500 lines of Node. The threat model The problem with public file hosts isn't that they're evil. It's the gap between what you intend ("share this once, with one person") and what the platform delivers ("store this forever, serve it to anyone who finds the link"). A few specific things go wrong: Retention. "Temporary" hosts keep your files long after you've forgotten them. There's no expiry you can trust, and deletion is usually best-effort. Predictable URLs. Plenty of hosts use sequential or short IDs. Scrapers walk the keyspace and hoover up everything. Your "private" link was never private. Stored XSS via uploads. If a host serves an uploaded .html or .svg file inline with a permissive content type, an attacker can ship JavaScript that runs in your browser, in the host's origin. Your file host becomes an XSS delivery service. Abuse vectors. No rate limit means the box is a free CDN for whatever someone wants to dump on it — malware, spam payloads, the works. So the design goal wasn't "another uploader." It was: close each of those gaps, then stop. What I built tmpdrop is a single Fastify server backed by SQLite. The whole defensive surface is small enough to hold in your head: Unguessable URLs. Slugs are 9 random bytes, base64url-encoded — 72 bits of entropy. You cannot enumerate them. A TTL reaper. Every upload

2026-05-29 原文 →
AI 资讯

The Paradox of Democratized Software

Everyone can build it. Almost no one can afford to run it at scale. And the companies selling the picks and shovels are about to get undercut by the same forces they unleashed. by VEKTOR Memory — 20 min read How This Article Started: 20 Forums, 40 Headlines, and a Growing Sense That Everyone Was Confused I woke up to clear skies and the sun finally shining, and I set out to understand this idea, the truth behind it, and the nagging suspicion that the narrative around AI and software costs had become so loud, so uniform, and so confidently confusing that someone needed to sit down and actually go through it. No tweets, or are they now X's? No LinkedIn thought leader infomercials, no Substack hype, just actual research and deep thoughts. So I spent time reading, collating data. Forums, whitepapers, LinkedIn posts, Hacker News threads, VC essays, Reddit arguments. I went looking for the real signal underneath the noise. What I found instead was the full spectrum of human overconfidence, lots of moat real estate. On one end: the hype machine at full throttle. “Software is going to zero.” “A solo dev can now build what a 50-person team built in 2021.” “The era of the $500/month SaaS subscription is over.” “Vibe coding will replace your entire engineering org.” These headlines were everywhere. Breathless. Confident. Shared tens of thousands of times, this angle gets views, of course, the algorithm loves being fed claps, shares, comments, and reposts. Most were written by people who had a very good Tuesday with Codex, Windsurf, Claude and Cursor and decided that instant dev, open source to Github and getting oodles of stars, maybe even roping in a celebrity, was now the permanent condition of software development. “We are now famous on GitHub!" Very hipster, very vibes, see you on the playa.. On the other end: the backlash. Experienced engineer, people with 15 to 25 years in production systems are pushing back hard. “Show me the vibe-coded app that survived its first real

2026-05-29 原文 →
AI 资讯

I Built a Local AI Agent That Thinks Like a Brain, Not a Database

I Built a Local AI Agent That Thinks Like a Brain, Not a Database Most AI agents today are sophisticated autocomplete engines. Ask them something, they answer. Ask again in a new conversation, they start from zero. The context window is the only memory they have. Serenity is different. It's a fully local AI agent that encodes experiences the way biological brains do — semantically clustered, causally structured, and self-organizing. No cloud. No API calls to a vector database. No data leaves your machine. Ever. The Core Problem with Current AI Memory The standard approach to AI memory is essentially a hack: you stuff embeddings into a vector DB, do nearest-neighbor retrieval, and dump the results into the prompt. It sort of works. But it's not how brains work. Your brain doesn't search for memories. When one fires, related ones light up automatically. Serenity's architecture — called S.E.R.A (Semantic Experience Reasoning Agent) — tries to bridge that gap. Here's the key difference: Traditional Approach Serenity Vector search on embeddings Semantic node activation Prompt-injected context Persistent working memory One-shot retrieval Emergent recall via association Static embeddings Pruned & crystallized over time How It Works: The Neural Node Network At the core is the Neural Node Network (NNN) . Instead of storing facts in isolation, Serenity encodes experiences in causal format: ACTION → BEFORE → OUTCOME → AFTER When she learns something, she doesn't file it in a folder. She finds where it semantically belongs in a web of related concepts. Similar things cluster together — the same way neurons that fire together wire together. Then the abstraction layer kicks in. Three or more related concepts crystallize into a higher-order node: the thing they all have in common that none of them says directly. Those nodes bundle into pathways. Those pathways grow into domains. She also has inhibitors and pruning — weak connections get cut so strong ones sharpen. Her knowledge ge

2026-05-29 原文 →
AI 资讯

I gave my AI agent a 2MB PDF. Here's what happened to my token count.

Every token your agent spends on file I/O is wasted reasoning capacity. I was building a document processing agent — the kind that reads incoming research reports, extracts key findings, and produces executive briefings. Nothing exotic. The kind of workflow thousands of teams are automating right now. The PDF I was testing with was 2MB. Dense text. A typical industry research report. When I measured the token cost of processing it inline, the number was 97,354 input tokens — just to get the text into Claude's context. At claude-sonnet-4-6 pricing, that's $0.29 per document. For a pipeline that processes 500 reports a month, you're looking at $150/month before your agent writes a single word of output. That's the problem nobody talks about in the AI agent space. Everyone optimises prompt engineering and output tokens. The silent cost is input: the files, the content, the raw data you're shoving into context before the agent can do anything useful. How the token count explodes When you pass a document to an agent inline, one of two things happens: Option A — Base64 encoding. You read the binary file, encode it, embed it in the prompt. A 2MB PDF in base64 is ~2.7MB of text. At roughly 3.5 characters per token, that's ~770,000 tokens before your agent has read a single word. This is catastrophic. Don't do this. Option B — Text extraction. You extract the raw text content first (via pdftotext , PyMuPDF, or equivalent), then pass the text to the agent. Better — but a 2MB PDF with dense content still yields ~97,000 tokens of extracted text. You've paid for every word, every header, every footnote. Either way, the document content dominates your context window, crowds out your system prompt, and you're burning money on file I/O instead of reasoning. The alternative: specialist services via MCP Model Context Protocol (MCP) is Anthropic's open standard for connecting AI agents to external tools and services. The key insight is simple: your agent doesn't need to contain the co

2026-05-29 原文 →
AI 资讯

RAG SOTA, Agent Harnessing, and Langfuse Observability for AI Frameworks

RAG SOTA, Agent Harnessing, and Langfuse Observability for AI Frameworks Today's Highlights Today's top stories delve into optimizing RAG performance with open-source benchmarks, designing robust AI agent systems, and implementing best practices for LLM observability in production. RAG SOTA: I Tested 7 Pipelines and Built SEQUOIA (Open Source) (Dev.to Top) Source: https://dev.to/__2ddbae6bb7d/--5cec This article presents a comprehensive benchmark of seven Retrieval-Augmented Generation (RAG) pipelines, culminating in the development and open-sourcing of SEQUOIA, a new RAG system. The author details over 20 hours of compute time spent locally to rigorously test different RAG configurations against real-world tasks, providing valuable insights into their performance characteristics. The technical deep dive includes discussions on various components like chunking strategies, embedding models, vector databases, and re-rankers, along with their impact on retrieval quality and generation coherence. Readers gain an understanding of the trade-offs involved in designing effective RAG systems and the empirical evidence supporting different architectural choices. The release of SEQUOIA as an open-source project means developers can directly implement and experiment with a battle-tested RAG pipeline, offering a tangible starting point for their own projects. Comment: This is an invaluable resource for anyone building RAG. Benchmarking 7 pipelines and open-sourcing a well-performing one provides immediate practical value and a solid foundation for further experimentation. Stop Upgrading the Model. Start Engineering the Harness. (Dev.to Top) Source: https://dev.to/tacoda/stop-upgrading-the-model-start-engineering-the-harness-194 This insightful article argues that instead of solely focusing on larger or "better" base models, teams should invest in "engineering the harness" around their AI agents to improve performance. The author highlights that the supporting architecture—compri

2026-05-29 原文 →
AI 资讯

RAG SOTA: I Tested 7 Pipelines and Built SEQUOIA (Open Source)

RAG SOTA: I Tested 7 Pipelines and Built SEQUOIA (Open Source) After 20+ hours of compute time on local hardware, I benchmarked 7 RAG configurations against real-world tasks. SEQUOIA (RAPTOR tree + step-back prompting) consistently outperformed alternatives. The Full Pipeline List Method Core Approach No-RAG Direct LLM generation Classical RAG Dense retrieval (BGE-small + FAISS) Hybrid RAG BM25 + Dense + RRF + reranker LightRAG Key-value graph + dense hybrid PageIndex Two-stage hierarchical retrieval GraphRAG Entity graph + dense fallback Agentic RAG Multi-step reasoning pipeline SEQUOIA RAPTOR tree + step-back prompting SEQUOIA Pro Multi-query + rerank + compression Why LightRAG Underperformed The hype suggested graph-based RAG would revolutionize retrieval. On real banking documents and technical manuals: Graph construction is expensive (entity extraction, relationship mapping) Retrieval quality did not justify the overhead Academic benchmarks do not equal production reality Why RAPTOR Works Recursive Abstractive Processing for Tree-Organized Retrieval: Cluster leaf nodes (individual chunks) Summarize upward (hierarchical abstraction) Retrieve at multiple levels (specific details + high-level context) This mirrors how humans organize knowledge. Step-Back Prompting: Free Performance Before retrieving, generalize the query: User asks: "What's the error rate for Q3?" Step-back: "What metrics are tracked quarterly?" Retrieve broader context first, then narrow Result: ~15% improvement in recall. Zero latency cost. SEQUOIA Architecture User Query Step-back Prompting (generalize) RAPTOR Tree Retrieval (multi-level) Context Compression (summarize long contexts) Re-ranking (cross-encoder) Local LLM Generation Local LLM Evaluation I used a local model weaker than GPT-4 for judging. Key finding: relative rankings between methods stayed consistent even with a weaker evaluator. You can prototype and compare approaches without burning API credits on GPT-4 evaluations. Productio

2026-05-29 原文 →
AI 资讯

How vibecoding is destroying the open source that feeds it

How vibecoding is destroying the open source that feeds it March 3, 2026 The snake eating its own tail A year ago, vibecoding was a curiosity. Today, it’s an industry. Millions of developers — or rather prompters — generate entire applications by describing what they want to an LLM. In minutes, an API, a frontend, a deployment. Magical. But behind this magic lies a dirty secret that nobody wants to face: every line of code generated by these AIs was trained on millions of open source projects — projects that are now dying. Vibecoding would be nothing without open source. And it’s killing it. What exactly is vibecoding? For those who spent 2025 in a cave: vibecoding is the practice of creating software in natural language, relying on generative AI models (Claude, GPT-5, Gemini, and the dozens of specialized models that have emerged since). You describe a vibe , an intention, and the AI produces the code. No debugging. No reading documentation. No Stack Overflow. And above all — here’s the crux — no contributing back . The implicit pact of open source is broken The open source ecosystem has always rested on a tacit social contract: I publish my code for free. In return, others use it, find bugs, suggest improvements, contribute. The project lives because a community keeps it alive. This contract had already been severely tested by large corporations that consume open source without contributing proportionally. But at least the developers who used these libraries understood them. They opened issues. They forked. They sent pull requests. They wrote blog posts that spread the word about the project. Vibecoding has blown up this cycle. The vibecoder doesn’t know which library they’re using. They don’t know, and they don’t care. They asked “build me a payment API with webhook handling,” and the AI chose this or that dependency for them. They will never read that project’s README. They will never open an issue. They won’t even know that project exists . The chilling numbers

2026-05-29 原文 →
开发者

Nintendo’s newest WarioWare is a weirdo smartphone app

A decade ago, Nintendo made a big splash into the world of mobile gaming with a new Super Mario platformer directed by none other than Shigeru Miyamoto. But even though the game proved popular, it wasn't the success the company had hoped for. Over the ensuing years Nintendo has slowly retreated from smartphone gaming, with […]

2026-05-29 原文 →
AI 资讯

Microsoft 365 Copilot gets a speed boost and cleaner design

Microsoft is launching a revamped version of Microsoft 365 Copilot, offering a cleaner design that the company claims loads twice as fast. As part of this update, Copilot will provide more reliable and structured responses that are easier to scan, according to Microsoft. The redesign, which is rolling out across desktop and mobile devices, comes […]

2026-05-29 原文 →
AI 资讯

I made my Markdown Editor "AI-Ready": MarkSmith v0.3.0

Hey DEV community! 👋 A few days ago, I built a VS Code extension called Marksmith to fix the most annoying parts of writing Markdown (like pasting Excel tables and syncing preview scrolls). But recently, I noticed a huge shift in my own workflow: Half the Markdown I write isn't for humans anymore. It’s being fed directly into Claude, ChatGPT, or Gemini as prompts and context. When you're constantly stuffing docs into context windows, two things happen: You worry about hitting context limits (or racking up API costs). You waste time dealing with AI "hallucinations" when you ask it to generate docs back for you. So, for the v0.3.0 release , I decided to pivot Marksmith into something new: An Agent AI-Ready Markdown Toolkit. 🚀 Here is what I added to survive the AI era: 📊 1. Real-time LLM Token Estimator Instead of just counting words, Marksmith’s Document X-Ray sidebar now includes a Heuristic Token Estimator for GPT, Claude, and Gemini. Before you copy-paste that massive README into your AI assistant, you can see exactly how "heavy" it is in terms of tokens right inside your editor. No more guessing if you're about to blow past your context limit! ✂️ 2. Copy Optimized for AI (1-Click Minify) Formatting is great for humans, but LLMs don't need all those extra spaces, perfectly aligned markdown tables, or empty lines. I added a CodeLens button at the top of your files. Click it, and Marksmith instantly minifies your Markdown (compresses tables, strips blanks) and copies it to your clipboard. Result: You save significant tokens and API costs without ruining your beautiful local .md file. 🕵️ 3. Hallucination Quick Fix Ever ask an AI to write documentation, and it leaves behind a bunch of [TODO: Insert link here] or makes up a fake local image path? Marksmith now automatically scans your document and puts a red squiggly line under AI placeholders and broken local links . Click the 💡 icon, and you can instantly strip them out or fix them. It acts as a safety net before you

2026-05-29 原文 →
AI 资讯

Anyone Can Make Software Now. But When Does A Side Project Become Production Ready?

Author's note: In the spirit of fairly critiquing AI and practicing a suggestion I end the article with, this article and the accompanying illustration were created entirely without AI assistance. Agentic coding AI is here, and it’s transforming the software industry. But with agentic coding out now for over a year, has it felt like the software industry has really transformed? From my from vantage point, although there are some really cool projects that have been built only because of new agentic coding tools, it generally feels like we’re awash in a sea of software slop. Tim Kadlec wrote a great article, “Losing Focus” , that really resonated with me, especially this quote: “I don’t think the quality of software has increased all that much in in the past 12 months. I think maybe the amount of software has, but it’s very, very hard to find software that’s reliable.” - Max Scoening, Head of Product at Notion I’ve been hearing loads of stories and murmurs about AI from the people I know in tech, and I think there’s a lot being lost in the binary divide that a lot of people seem to fall into - either AI is bad and can do nothing right, or AI is the new future of engineering, and every company should have all their code written by AI today . I want to posit that right now we’re in the messy middle. An era of hype and grifters that want to sell you an AI fantasy that hasn’t been reached, which obscures the real present - powerful AI tools that can speed up professional developers, but can lure non-developers into shipping products that aren’t nearly ready for prime-time. My Background But first, if you don’t know me, let me explain why you should listen to my perspective. I’ve been working professionally in software (specifically web development, focused on the frontend), for over ten years. In that time I’ve worked at a non-profit, a for-profit, led a small startup, freelanced, and have led a number of open-source volunteer teams at Chi Hack Night , including right now

2026-05-29 原文 →