AI 资讯

I 've been using Cursor on non-trivial repos and kept hitting the same issue: the agent finds a file but misses routes, shared modules, and tests that should run after a change. I built FlowIndex — a local CLI + MCP server that scans a repo and builds a behavior graph in SQLite (entrypoints, imports/calls, tests, git co-change). No embeddings, no SaaS, no LLM calls in the index itself. Setup: pip install "flowindex[mcp]" In your project: flowindex init flowindex scan Add to ~/.cursor/mcp.json (use your repo' s absolute path for cwd ) : { "mcpServers" : { "flowindex" : { "command" : "flowindex" , "args" : [ "mcp" ] , "cwd" : "/absolute/path/to/your/repo" } } } 4. Restart Cursor — you get tools like get_change_impact, suggest_tests, make_context_pack, explain_entrypoint, get_repo_overview. Example workflow: before editing payments/ledger code, ask the agent to use make_context_pack or get_change_impact on that file — it pulls from the local graph, not a generic file search. Honest limits: static analysis + git heuristics only. Call paths resolve via imports but aren 't compiler-grade. TS/JS is heuristic. Documented in the README. MIT · pip install flowindex · https://github.com/adu3110/flowIndex Curious if others use MCP for repo context and what tools you wish existed. Happy to fix setup issues if anyone tries it.

Exposing your app to an AI agent over MCP is basically handing someone a master keyring and trusting them to only open the doors they're supposed to. That trust is a bug waiting to happen. This week I wired up a batch of MCP tools over a multi-tenant Laravel app, and the whole exercise was really about one question: how do I let an agent drive the app without letting it drive someone else's data? Here's the thing about MCP tools — each one is an endpoint. An agent calls list_events , publish_event , check_in_participant , and your server runs code on the caller's behalf. The moment you have more than one tenant, every single tool needs to answer two questions before it does anything: are you allowed to do this , and are you allowed to do it *here *. Authorization and scope. Skip either and you've built a confused deputy. The trap: ambient scope doesn't exist under token auth In a normal web request, multi-tenancy is comfortable. You've got a logged-in user, a global scope on the model that quietly appends where organization_id = ? , and you mostly forget it's there. Everything Just Works because there's an ambient "current organization" sitting in the session. MCP tools don't have that. The caller authenticates with a token, there's no session, no middleware stack that set up a current-tenant context. If you lean on a global OrganizationScope that reads "the current org" from somewhere, it reads nothing — and a query you assumed was fenced returns every tenant's rows. That's the kind of bug that doesn't throw an error; it just silently leaks. So the rule I settled on: under token auth, never rely on ambient scope. Filter explicitly, every time, in one place. That "one place" is a small trait every event-scoped tool pulls in: trait ResolvesOrgEvents { protected function resolveOrgEvent ( Authenticatable $user , string $uuid ): ?Event { if ( empty ( $user -> organization_id )) { return null ; } return Event :: query () -> withOrganization ( $user -> organization_id )

Sometimes, the best ideas come when you least expect them — like at 2 AM, scrolling through social media with nothing exciting to do. That’s exactly how IGram, my latest side project, came to life. No grand plans, no investors, no pressure — just a spark of curiosity and a desire to build something fun. In this post, I’ll share the story of how IGram started, what it is, the challenges I faced, and what I learned along the way. If you’ve ever wondered what it’s like to build a messaging app from scratch or are just curious about side projects, this one’s for you. HOW IT BEGAN _**A few days ago, stuck in an endless social media scroll loop, I suddenly thought, “Why not build my own messaging app?” Not to compete with the giants like Telegram or WhatsApp, and certainly not because I had a startup idea or funding. Simply because I wanted to see how far I could take it. That spontaneous idea turned into IGram, a project born purely out of boredom and a hunger to learn. What Is IGram? IGram is a modern messaging app inspired by platforms like Telegram and Discord. But it’s not a clone. Instead, it’s designed to feel fast, smooth, and enjoyable—an experience I wanted to craft from the ground up. It’s my personal challenge and learning experiment, built solo and fueled by the excitement of creating something new. Features You’ll Find in IGram Even though it started as a simple idea, IGram has grown to include a solid set of features: One-to-one messaging Group conversations Channel support Message reactions, editing, and deletion Reply and message forwarding Search functionality Dark and light themes Responsive design and mobile-friendly layout User profiles and modern UI animations Every feature is designed to keep the app feeling smooth and responsive, because the user experience matters just as much as the functionality. The Biggest Challenge: User Experience Surprisingly, writing the code wasn’t the toughest part—it was designing how everything flows and feels. Modern

You forwarded the phishing email to the security channel about ninety seconds too late. The laptop is already cooperating with someone else. Your personal access token, the one you minted "just for that one script", is on its way to whatever Discord pays for stolen tokens this week. Now what? For users on GitHub Enterprise, what was previously a clickthrough checklist you complete while your hands shake is now one button. On June 24 the GitHub Changelog announced a self-service credential revocation flow under Settings, Credentials. From that view a user can see counts of every credential they have generated or authorized through SSO, then revoke or delete all of them in a single action. Personal access tokens, SSH keys, OAuth tokens, SSO authorizations: gone together. What actually shipped Containment used to be a manual scavenger hunt. PATs sat under Developer Settings. SSH keys lived one tab over. OAuth apps you forgot you authorized two years ago hid behind a different submenu. SSO was its own world. In practice that meant during an incident you forgot something, and the something you forgot was the credential the attacker actually wanted. The new view collapses that surface onto one screen. Counts on one side, a revoke-or-delete-everything action on the other. Whoever wrote it had clearly pictured the 3am screenshot: a user who has just been told to "rotate everything" and has no idea where "everything" lives. GitHub frames this as a complement to an earlier enterprise-owner capability that lets admins with the "Manage enterprise credentials" permission bulk-revoke across one user or many. So there are now two pairs of hands on the kill switch: the user, and the org. (Whichever one notices first.) Why a pipeline owner should care Because users are the trust boundary you keep pretending is somebody else's problem. A leaked PAT in a CI pipeline is rarely a CI bug. It is a human who pasted the token into a script, then a laptop, then a sync folder, then a backup,

Part 4 of the Building Enterprise AI Automation Systems Series Introduction Most Named Entity Recognition (NER) tutorials end with a prediction. The model successfully extracts: COMPANY INVOICE CONTRACT PURCHASE_ORDER The article ends. The notebook prints a beautiful JSON response. Mission accomplished. Or so it seems. In real enterprise systems, extracting entities is only the beginning. Consider the following prediction: { "COMPANY" : "ALPHABRIDGE" , "INVOICE" : "MFG-INV-000157" } At first glance, everything looks correct. But from a business perspective, the system still knows almost nothing. Questions remain unanswered. Which ALPHABRIDGE? Which customer record? Which contract? Which invoice? Which business relationship? These questions belong to a completely different problem known as Entity Resolution. Entity Resolution transforms extracted text into business knowledge. Without it, AI understands words but not businesses. NER Finds Text Named Entity Recognition answers one question: "What pieces of text represent meaningful entities?" For example: PAYMENT FROM ALPHABRIDGE SOLUTIONS MFG-INV-000157 becomes { "COMPANY" : "ALPHABRIDGE SOLUTIONS" , "INVOICE" : "MFG-INV-000157" } This is extraction. Nothing more. The model has no idea whether: the company exists, the invoice exists, the invoice belongs to the company, the invoice has already been paid, the contract is still active. Extraction is syntax. Enterprise automation requires semantics. The Hidden Problem Imagine the following customer master. CUS-00001 ALPHABRIDGE SOLUTIONS Now imagine receiving these transaction narratives. PAYMENT FROM ALPHABRIDGE PAYMENT FROM ALPHABRIDGE LTD PAYMENT FROM ABS PAYMENT FROM ALPHA BRIDGE Humans immediately recognize these as the same customer. Machines do not. To a computer, every string is different. Without resolution, automation immediately breaks. What Entity Resolution Actually Does Entity Resolution answers a different question. Instead of asking: "What entity is this?"

Apache Iceberg looked like the answer to everything when we first adopted it. Open format, ACID transactions, time travel, schema evolution. We migrated our Hive tables, ran a few queries, and felt good about life. Three months later, our S3 costs doubled. Queries that used to take 10 seconds were taking 4 minutes. Metadata operations were timing out. Nobody on the team could explain why. That was the beginning of a real education in how Iceberg actually behaves in production. This post covers what I wish someone had told us before we went all-in. The Small Files Problem Is Not Optional Iceberg is append-friendly by design. Every micro-batch write, every streaming insert, every incremental load creates new Parquet files. Each file also gets its own metadata entry. After a week of hourly loads, you might have 10,000 files in a single partition where you wanted 20. The result: Iceberg's metadata layer has to plan queries across thousands of file manifests. Planning takes longer than execution. Your 10-second query becomes a 4-minute query, and your users start filing tickets. Fix: automate compaction from day one. In Spark, compaction is called rewrite_data_files . The basic call looks like this: -- Run this on a schedule, not on-demand CALL iceberg_catalog . system . rewrite_data_files ( table => 'analytics.events' , strategy => 'binpack' , options => map ( 'target-file-size-bytes' , '134217728' , -- 128MB target per file 'min-input-files' , '5' -- only compact if 5+ small files exist ) ) Target file size of 128MB to 512MB is the practical sweet spot. Smaller than that, you still have too many files. Larger, and your query engines cannot parallelize reads efficiently. If you are not using Spark, PyIceberg exposes compaction through the table maintenance API (as of 0.7.x). For Flink or Trino-only shops, schedule compaction as a separate Spark job. Yes, it is annoying, but it is the right call. Hidden Partitioning Is the Feature You Are Probably Ignoring Old Hive parti

Introduction Most developers today are learning how to “use AI APIs.” But that’s not enough anymore. The real shift happening in software engineering is this: We are moving from building APIs → to building AI-powered systems. And that requires a completely different mindset. The Problem with Most AI Tutorials Most tutorials show this: Call OpenAI API Get response Print output That’s it. But in production systems, this approach fails because it ignores: Context management State handling Reliability Tool integration System design In real applications, AI is not a function call — it is an orchestrated system. What an AI System Actually Looks Like A production AI system usually includes: 1. Input Layer Validation Preprocessing Safety checks 2. Reasoning Layer (LLM) Prompt engineering Context injection Model selection 3. Tool Layer APIs Databases Search engines Internal services 4. Memory Layer Conversation history Vector DB / embeddings User context 5. Output Layer Formatting Validation Response filtering Simple Example: From API Call → AI Agent Thinking Instead of this: response = client . chat . completions . create (...) We design something like this: class AIAgent : def __init__ ( self , llm , tools ): self . llm = llm self . tools = tools def run ( self , user_input : str ): context = self . build_context ( user_input ) response = self . llm . chat . completions . create ( model = " gpt-4o-mini " , messages = context , temperature = 0.2 ) return self . post_process ( response ) Now AI becomes: ✔ structured ✔ extendable ✔ production-ready Key Shift in Thinking Old mindset: “How do I call the model?” New mindset: “How do I design the system around the model?” That’s the difference between: ❌ AI script ✅ AI product system Why Tools Matter More Than Prompts Modern AI systems are not just text generators. They are tool-using systems . Examples: Search APIs (RAG systems) Databases (SQL, NoSQL) External APIs Internal business logic This turns AI from “chatbot” into “agent

AI operating system for value based care teams Discussion | Link

Part 3 of the Building Enterprise AI Automation Systems Series Introduction Named Entity Recognition (NER) is one of the oldest problems in Natural Language Processing. Most tutorials introduce NER using examples like: Person Organization Location Date A sentence such as: Elon Musk founded SpaceX in California. becomes PERSON ORGANIZATION LOCATION While this is useful for learning NLP fundamentals, it has very little relevance to enterprise software. Businesses do not automate biographies. They automate operations. Enterprise documents contain an entirely different language. Invoices. Contracts. Purchase Orders. Bank Statements. Remittance Advice. Payment Narratives. ERP Exports. The entities that matter inside these documents are not "PERSON" or "LOCATION". Instead, they are business concepts such as: Customer Contract Invoice Purchase Order Payment Type Understanding these entities is the first step toward intelligent automation. In this article, we'll build a Financial Named Entity Recognition pipeline capable of transforming raw enterprise transaction narratives into structured business knowledge. The Difference Between Generic NER and Enterprise NER Traditional NER focuses on linguistic entities. Enterprise NER focuses on operational entities. Consider the following sentence. PART PMT ALPHABRIDGE SOLUTIONS MFG-INV-000157 A generic language model may identify: Organization and ignore everything else. From a business perspective, this is almost useless. What we actually need is: PAYMENT_TYPE COMPANY INVOICE The objective is not language understanding. The objective is business understanding. Step 1 — Designing the Business Taxonomy Before training any model, define what the model should learn. This is one of the most overlooked stages in machine learning projects. Many teams immediately begin annotation without first defining a taxonomy. As a result, annotations become inconsistent. Models become confused. Evaluation becomes unreliable. For our transaction intell

Part 2 of the Building Enterprise AI Automation Systems Series Introduction One of the biggest obstacles in enterprise AI is not choosing a model. It is finding data. Most tutorials assume that training data already exists. Reality is very different. Large organizations rarely share operational datasets. Financial transactions contain confidential information. Contracts contain sensitive agreements. Invoices reveal commercial relationships. Bank statements expose customer activity. For legal, regulatory, and competitive reasons, these datasets almost never become public. This creates a difficult problem for AI engineers. How do you build intelligent systems when the data you need cannot be accessed? The answer is synthetic data. Unfortunately, most synthetic datasets found online are little more than randomly generated CSV files. They contain names. Numbers. Dates. But they completely ignore something far more important: Business relationships. In this article, we'll explore how to design synthetic enterprise datasets that preserve real business logic and can be used for machine learning, automation, benchmarking, and AI engineering. Random Data Is Not Synthetic Data Many developers believe synthetic data simply means generating fake values. For example: Customer,Invoice,Amount John,INV001,500 Alice,INV002,1200 Bob,INV003,900 Technically, this is synthetic. Practically, it is useless. Why? Because enterprise systems are built around relationships. Invoices belong to contracts. Contracts belong to customers. Payments reference invoices. Purchase orders authorize invoices. Bank transactions settle invoices. Without these relationships, there is nothing meaningful to learn. A machine learning model trained on isolated records learns isolated patterns. Real enterprise automation requires connected data. Thinking Like an Enterprise System Before writing a single line of Python, ask one question: "How does the business actually operate?" Imagine a manufacturing company. A

Introduction In the early 2000s, email spam was rampant, cluttering inboxes with unsolicited messages promising quick riches or promoting dubious products. Fast forward to today, and a similar phenomenon is occurring in the world of open-source software: Pull Request (PR) spam. Much like its email predecessor, PR spam is becoming a major nuisance for developers and maintainers, disrupting workflows and compromising the integrity of collaborative software projects. This blog post explores the parallels between early 2000s email spam and contemporary PR spam, examines the motivations behind this new wave of digital clutter, and discusses potential solutions to mitigate its impact. The Rise of PR Spam The Allure of Contribution Metrics One of the primary drivers behind PR spam is the increasing emphasis on contribution metrics in the open-source community. Platforms like GitHub have made contributing to projects more accessible, and many developers are eager to showcase their activity through public repositories. However, this focus on quantity over quality can lead to an influx of low-effort or irrelevant PRs. An example of this is Hacktoberfest, an annual event encouraging contributions to open-source projects. While well-intentioned, it has, in some instances, resulted in a deluge of superficial PRs. Contributors seeking to meet participation thresholds often submit changes that are trivial or unnecessary, much like the spam emails of old that inundated our inboxes with irrelevant or nonsensical content. Automated PR Generators Another factor contributing to the rise of PR spam is the use of automated tools that generate pull requests. These tools can be beneficial for routine tasks such as dependency updates or code formatting. However, when misused, they can lead to a flood of PRs that lack genuine human oversight or consideration, akin to the automated email spam generators that once plagued communication networks. For instance, a tool might automatically submit

Hey Dev Community, If you are running enterprise-scale web scrapers, pricing monitors, or data ingestion pipelines for LLMs, you’ve probably spent sleepless nights dealing with network latency and sudden 403 blocks. When choosing an infrastructure partner, every provider pitches the same script: "99.9% uptime guarantees, millions of residential IPs, and lightning-fast response times." But in the trenches of real-world data collection, we all know that marketing numbers rarely match production reality. Last quarter, my team ran an exhaustive infrastructure audit to compare proxy providers pricing performance and infrastructure stability. If you want to dive straight into our live dataset, telemetry scripts, and interactive monitoring utilities, you can check out the full workbench at ProxyVero . Here is a technical breakdown of how we built our benchmarking matrix, and the architectural gaps we discovered across mainstream enterprise proxy services. 📊 1. The Core Metrics: Uptime vs. Success Rates The biggest lie in the networking industry is confusing Server Uptime with Request Success Rate . A proxy gateway server can maintain a 99.9% uptime while the underlying residential peer network is failing 20% of your data collection requests due to strict target WAFs or high peer churn. When conducting our proxy providers uptime guarantees performance benchmarks , we evaluated three core parameters: TCP Handshake Latency : The time it takes to establish a connection with the proxy endpoint. TTFB (Time to First Byte) : Critical for parsing dynamic JavaScript targets. HTTP Status Code Reliability : Tracking the exact ratio of 200 OK vs. 403 Forbidden / 429 Too Many Requests . ⚖️ 2. The Big Three: Oxylabs vs Bright Data vs SmartProxy Comparison To provide an objective proxy network performance benchmarks comparison , we deployed standard headless browser worker instances (Playwright/Puppeteer) routed through different enterprise gateways. Below is a high-level summary of our a

AI COO that runs your team in tools you already use Discussion | Link

Backed by Mayfield and Aramco Ventures, Vishal Sikka’s new venture brings together veterans from SAP, Infosys, and VianAI.

Right now he's merely a several-hundred-billionaire, according to Bloomberg's Billionaires Index.

Describe a slide or drop in rough notes make a polished deck Discussion | Link

Thariq Shihipar, engineering lead for the Claude Code team, recently published a blog post (Using Claude Code: The Unreasonable Effectiveness of HTML) arguing that HTML, with its richer visualizations, color, and interactivity, improves the productivity of human-agent communication in many settings, especially when compared to default Markdown outputs. By Bruno Couriol

In its first earnings report since going public, the AI chipmaker forecast a narrower gross margin in its core business, scaring investors.