AI 资讯

[ Removed by Reddit on account of violating the content policy . ] submitted by /u/n4r735 [link] [留言]

Operator perspective. I use AI daily across three companies and I am bullish on it, but the gap between what gets shouted on stage and what the data shows is enormous. Best measured number across hundreds of engineers is about 7.8%, and 66% of the people who hit a peak gain saw it fade the next quarter. At the same time, people are being pushed onto it under threat of their jobs while the return is not even proven to the people mandating it. My read is the anger is not really “AI is bad,” it is “my boss profits from me using it and I do not.” Where do you land - is the resistance cognitive (it erodes skill) or economic (the gain is not shared)? submitted by /u/Alternative_Letter72 [link] [留言]

I’ve been using AI pretty heavily for the past few months — quick research, rewriting emails, brainstorming ideas, even helping outline stuff I need to write. It saves so much time and the output is usually decent. But lately I’ve noticed something weird: I’m second-guessing myself way less. I’ll get an answer from it and just kind of roll with it instead of thinking it through like I used to. Yesterday I asked it about something I already had a rough opinion on, accepted its take, and only later realized I didn’t even challenge any part of it. It feels convenient as hell, but also a little unsettling. Like I’m outsourcing the actual thinking part. Is this normal? Or am I slowly losing the habit of thinking deeply on my own? Anyone else feeling this? submitted by /u/pen-pineapple-apple [link] [留言]

Online it feels like every company is fully embracing AI. In reality, most organizations I interact with are still trying to figure out where it fits into existing workflows, processes and software. The interesting conversations aren't usually about models anymore. They're about trust, reliability, permissions, governance and how AI fits into the way people already work. The gap between AI demos and real-world adoption still feels larger than most people realize. submitted by /u/Bladerunner_7_ [link] [留言]

Hi r/webdev , As web developers, we frequently get stuck fighting the tools we use for e-commerce. You find a great framework, but it forces you to use a specific database, or it only deploys nicely to one cloud platform. I built Storecraft to solve this frustration. It is an open-source, headless e-commerce core that treats both the database and the runtime hosting environment as completely swappable dependencies. Why it makes building easier: Deploy Anywhere: It runs identically on traditional servers (Node), modern runtimes (Deno, Bun), or lightweight edge infrastructure (Cloudflare Workers). Choose Your DB: Switch between Postgres, MongoDB, or SQLite by simply changing your driver configuration. Purely Headless: Connect it to any frontend stack you prefer via a clean, predictable API. Whether you are building a small storefront for a local client or a globally distributed edge application, the engine adapts to your infrastructure—not the other way around. Repository link: https://github.com/store-craft/storecraft website: https://storecraft.app/ I'd love to get your feedback on the setup ergonomics. What are the biggest pain points you usually hit when deploying open-source e-commerce backends for your clients? submitted by /u/hendrixstring [link] [留言]

We run Quackr, a virtual phone number platform that lets developers and individuals receive SMS verifications without exposing a real number. We just published our first inventory transparency report and the data was surprising enough that we thought the dev community would find it useful. The Numbers Right now, 97.6% of our entire virtual phone number inventory is actively rented. 66,214 out of 67,815 numbers assigned and in use across 15+ countries. Over 1,000 numbers available at any given moment but they move fast. That utilisation rate tells you something about how the market has shifted. Virtual numbers are no longer a niche throwaway tool. Developers, businesses, and privacy-conscious users are holding them long term. What Developers Actually Use Virtual Numbers For The obvious use case is SMS verification during testing. Spin up a number, verify an account in staging, move on. But that is not what drives the bulk of demand on our platform. The real volume comes from: Multi-account management — developers and businesses running multiple instances of platforms that require unique phone verification per account. Privacy layers in production apps — applications that need to verify users without collecting their real numbers. A virtual number sits between the user and the platform. Automated verification pipelines — this is where our API and MCP Server come in. If you need to provision numbers programmatically and retrieve OTPs without manual intervention, this is the use case we built for. Geographic flexibility — needing a UK number from Australia, a US number from Ukraine, or any combination that your real SIM cannot provide. The OTP Blocking Problem Something worth knowing if you are building anything that involves SMS verification: platform-level VoIP blocking has become significantly more aggressive over the past two years. WhatsApp, Telegram, Google, and TikTok all run detection on incoming verification requests. A VoIP number gets flagged and the OTP simp

This is a submission for the GitHub Finish-Up-A-Thon Challenge I wired edge-context-mode into my own...

Most API teams treat the contract as an afterthought: write code, generate a spec, then watch the two drift apart. Git-native API design reverses that flow. You treat the API contract as source code, version it in Git, and review every change the same way you review application logic. Try Apidog today This guide focuses on implementation discipline, not a single tool. You’ll design contracts in branches, review them in pull requests, and turn a committed spec into mocks, tests, and docs. The goal is simple: your Git history should also be your API history. If you already know what Spec-First tooling looks like and want the product walkthrough, read the companion piece on the git-native API workflow . This article stays focused on practice. What “git-native” means for API work Git-native means your API definition lives in your repository as a plain text file. Not in a proprietary cloud database. Not behind a vendor login. A .yaml or .json file sits next to your code and is tracked by the same version control system your team already uses. In many cloud-locked API design tools, the contract lives in the vendor’s backend. You edit through a web UI, and your repository only contains an export. That export can become stale, and your Git history no longer explains how the API evolved. The git-native model inverts that relationship: The file in main is the contract. Any GUI is a view onto that file. Branches, commits, pull requests, blame, and rollback all apply to your API surface. Mocks, docs, tests, and generated clients derive from the committed spec. A git-native setup has three core properties: The spec is a text file in the repo. Changes flow through normal Git operations: branch, commit, PR, merge. Downstream artifacts derive from the committed file, not from a separate database. Why design and develop APIs in Git You already trust Git with your code. Your API contract deserves the same treatment. 1. History When someone asks, “When did we add the cursor pagination

You deploy your app. The build succeeds. The logs show the server starting. You click the URL your deployment platform gave you and get a connection error, a 502, or nothing at all. This is one of the most common first deployment failures, and the cause is almost always the same: the app is binding to the wrong address, or listening on the wrong port, or both. What port binding actually means When a server app starts, it listens for incoming connections on a network address. That address has two parts: the IP address it listens on, and the port number. The IP address determines which network interfaces the application accepts connections from. localhost (which resolves to 127.0.0.1 ) means the app only accepts connections from the same machine. 0.0.0.0 means the app accepts connections from any network interface, including external ones. During local development, localhost is fine. Everything is on the same machine. Your browser and your server are both on your laptop. When you deploy to a server, the platform's load balancer is not on the same machine as your app. It is trying to connect from outside. An app bound to localhost is invisible to it. The port problem Deployment platforms often assign ports dynamically. They tell your app which port to use through an environment variable, almost always called PORT . Your app needs to read this variable and bind to that port. If your app ignores PORT and hardcodes a port number, it starts on a port the platform is not watching. The platform tries to connect on its assigned port, gets nothing, and marks the deployment as failed. // This will fail on most platforms app . listen ( 3000 ) // This is correct app . listen ( process . env . PORT || 3000 ) The || 3000 fallback makes the app work both locally (where PORT is not set) and in production (where the platform sets it). What AI tools generate AI tools often hardcode both the address and the port. The generated code looks like this: app . listen ( 3000 , ' localhost ' ,

TL;DR Day 2 of AI Native DevCon shifted from agent capability to operating discipline. The strongest sessions focused on how teams can run AI-native delivery with clearer context pipelines, measurable agent behavior, safer execution boundaries, and better organizational ownership. The scale showed up in the numbers too. Across the two days, DevCon brought together 650+ in-person registrations, around 2,000 online registrations, and a packed mix of sessions, workshops, hallway conversations, and practical lessons. Day 2 leaned into workshops. That shift mattered because the second day was less about proving agents can do useful work and more about showing how teams can make that work repeatable. Hey there, welcome back. Rohan Sharma here again continuing the devcon series. Day 1 gave us the framing, including Guy Podjarny ’s core point that skills should be treated like real software assets. Day 2 picked up from there and moved into the operating details. Once agents are inside daily engineering work, platform and product teams need to decide what changes first, who owns those changes, and how the results are measured. Talks that shaped Day 2 Harness engineering beyond code Marc Sloan from Tessl focused on the next gap many teams are hitting. Code context is increasingly structured, but product and design context still lives in external systems such as Figma, Notion, and Linear. Pulling that context live can reduce staleness, but it introduces drift in evals, versioning, and reproducibility. The practical lesson was to stop treating external product and design context as random reference material. Teams need a defined layer between the repository and those external systems, with clear versioning so evaluations can be replayed against known context snapshots. Without that, agents can produce work that looks technically correct while missing the product constraint that actually mattered. That is a very expensive kind of almost-right. From vibes to metrics Simon Obstbau

Node.js will change its release schedule starting with version 27 in October 2026, moving from two major releases per year to one. All releases will become Long-Term Support (LTS), removing the distinction between odd and even versions. An Alpha channel for early testing will also be introduced. This decision addresses maintenance challenges and aims to align with user needs. By Daniel Curtis

Introduction: The Question of Relevance Imagine you’re a college student, fresh off mastering pandas , and you’re eyeing the freelancing market for data cleaning and automation gigs. You’ve heard of openpyxl , but as you dig deeper, you hit a wall: every resource seems to peg it as a relic for handling 2010 Excel sheets . That’s it. No modern use cases, no integration with cutting-edge tools, just a dusty library stuck in the past. So, you pause. Is openpyxl still relevant in 2023, or is it a dead end for someone trying to build a competitive freelancing portfolio? This dilemma isn’t just about openpyxl—it’s about the mechanism of perception in tech. When a tool is associated with outdated formats, its capabilities are often misinterpreted or overlooked . Openpyxl’s documentation and community discourse rarely highlight its modern applications, leaving newcomers like you to assume it’s obsolete. But here’s the catch: openpyxl isn’t just a 2010 Excel handler. It’s a low-level Excel manipulator that, when paired with libraries like pandas and numpy, can handle complex tasks that these libraries alone can’t. The problem isn’t openpyxl’s functionality—it’s the information gap between its perceived and actual utility. The stakes are clear: if you dismiss openpyxl as outdated, you risk missing out on a tool that could complement your pandas and numpy skills , making your freelancing services more efficient and versatile. But if you invest time in it without understanding its modern applications, you might waste effort on a tool that doesn’t align with current demands. The question isn’t whether openpyxl is relevant—it’s whether you’re looking at it through the right lens. In this investigation, we’ll dissect openpyxl’s role in 2023 freelancing, addressing its perceived limitations and uncovering its hidden strengths. By the end, you’ll have a clear rule for deciding whether to include it in your toolkit: If your freelancing gigs involve Excel-specific tasks that pandas ca

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

Here's a trace that reset how I think about evaluating tool-calling agents. An agent tries to book a flight. It calls search_flights with departure_date="next Friday" . The endpoint expected an ISO date, so it returns a 400 . The agent retries the same string four times, then apologizes to the user and gives up. Now the part that actually bothered me. Tool selection was correct. The model picked the right function out of a registry of 28. My tool-selection accuracy logged a clean 1.0 . The aggregate task-completion logged a 0 . And neither number told me which of three things broke: the argument was wrong, the model never read the 400 body, or the retry policy looped on the same input. My eval wasn't wrong. It was asking the wrong question. What "tool-call accuracy" actually grades If the only thing you measure is did the agent call the right tool , you're testing intent, not execution. Tool selection is necessary, not sufficient. It passes the moment the right function name shows up in the trace, completely blind to whether the arguments were garbage, whether the model read what came back, or whether it recovered from the 400 . That's the gap. The metric checks that the agent started the right way. Production needs to know whether it finished the right way. The reframe: it's four eval problems, not one The thing I had to internalize is that tool-calling eval is four problems stacked, each with its own root cause: Tool selection , right tool, or correctly no tool Argument extraction , schema-valid and semantically correct Result utilization , did it actually use what the tool returned Error recovery , did it retry, fall back, or escalate Score them separately and "the agent failed" collapses into "the argument extractor regressed on date strings on the flight-booking path." One bisect instead of three days. What I rebuilt Layer 1: Tool selection (with the bucket everyone drops) F1 on the tool name, so a 28-tool registry doesn't hide a regression on one rare endpoint

I run multiple Claude Code sessions all day — one per feature, one per service, sometimes five at once. Every session was asking me for permission in its own terminal. I'd miss requests buried in a background tab. I'd switch windows mid-thought just to approve a git status . I'd lose context constantly. And there was no single place to see what Claude was doing across all of them. So I built Gatekeeper — a TUI daemon that intercepts every Claude Code tool call and routes it to one unified approval dashboard. The dashboard Three panes, one terminal: Left — all active Claude sessions, with status badges: [auto] means auto-approve is on, [linked] means it's wired to a terminal window Middle — pending permission requests with an age timer so you know what's been waiting longest Right — full request detail, danger warnings, and the numbered approval menu Every Claude Code tool call — Bash , Edit , Write , Agent — passes through a PreToolUse hook before executing. The hook connects to Gatekeeper's Unix socket, sends the request, and blocks. Gatekeeper shows it in the UI. When you decide, the answer travels back and Claude proceeds or stops. Approving requests The menu in the right pane mirrors Claude Code's own style: 1 Allow once 2 Always allow 3 Deny ↑ / ↓ moves the cursor, Enter confirms. Or just press 1 , 2 , 3 directly. A and D are quick shortcuts for allow/deny. Option 2 — always allow — is where it gets useful. Choosing it saves a persistent rule so the same request never surfaces again: Bash → saves the command pattern (e.g. npm run * ) to config Edit / Write → saves the directory to an allowlist Agent → enables auto-approve for that session The rule is written both to Gatekeeper's own config and to Claude Code's settings.json allowlist — so Claude Code itself won't prompt for it either. Auto-approve sessions Press A in the Sessions pane to mark a session as trusted. It shows [auto] — routine tool calls pass silently without appearing in the queue. But some things

Hand the same paired before/after dataset (n = 25) to ChatGPT five times. Same prompt: "These are the same subjects measured before and after an intervention. Did their scores change significantly?" Four of the five runs return p = 0.009 from a paired t-test. The fifth run does a Shapiro–Wilk normality check on the differences first, decides they're non-normal, switches to a Wilcoxon signed-rank test, and reports p = 0.000018 . All five reach the same conclusion (significant). But notice what happened: only one run out of five thought to check an assumption you'd want it to check. The other four skipped it. The choice of method — and the test statistic, and the p-value — depended on whether the LLM happened to run an assumption check that time. On borderline data, this is the difference between reject and don't reject. If you're using LLMs for exploratory data analysis on a weekend project, you might shrug. If you're using them for anything that gets cited, gets submitted to a regulator, or gets handed to a clinician, this is a problem. It's a known problem — Cui & Alexander (2026) documented exactly this kind of method-divergence empirically; AIRepr (Zeng et al., 2025) shows the same thing across reproducibility metrics. The current answer in the literature is to constrain the agent so its execution is replayable. But replayability fixes "did we run the same code." It doesn't fix "did we run the right analysis." I've spent the last two months building a different fix. The more interesting half is the architecture. Let me walk through it. The real problem isn't temperature The first reflex is "set temperature=0 ." It's not enough. temperature=0 doesn't make a tool-using agent deterministic across runs. Three reasons: Inference isn't bitwise deterministic, even at temperature=0. Production LLM serving batches requests dynamically, and the attention kernels aren't batch-invariant — so the same input produces different output tokens depending on what other requests it

Smart Lighting Protocol Showdown: Zigbee vs Matter vs BLE Mesh (2026) After deploying thousands of Zigbee smart lights through our manufacturing line at nexLAMP, and watching countless customers struggle with protocol selection, I decided to write this practical comparison. The Real Problem "My smart lights keep disconnecting! I think I chose the wrong protocol..." This is the #1 complaint I see on Reddit, Xiaohongshu, and Zhihu. The fix isn't a better router — it's choosing the right protocol from day one. Protocol Deep Dive Zigbee — The Workhorse Frequency : 2.4 GHz (separate from WiFi) Topology : Star + Mesh hybrid Max devices : 200+ per coordinator Latency : 50-200ms Cost/unit : ~$3.5-5.0 (Tuya Zigbee drivers) Why it wins for lighting: Each node is a repeater → self-healing mesh Ultra-low power → years on coin cell for sensors Mature ecosystem → Tuya, Hue, Aqara, Xiaomi all ship Zigbee The catch: You need a Zigbee gateway (~$15-20). This is the only upfront cost. BLE Mesh — The Budget Option Frequency : 2.4 GHz (shared with WiFi/BLE) Topology : Managed flood mesh Max devices : ~50 (practical limit ~30) Latency : 100-500ms (increases with node count) Cost/unit : ~$2.0-3.5 The flooding problem: Every command is broadcast to every node. With N nodes, you get O(N²) message propagation. Past 30 devices, you'll notice visible lag. Good for: Small apartments (≤ 6 lights), budget projects. Matter — The Future Transport : Thread (preferred) or WiFi Topology : Thread mesh (similar to Zigbee) Max devices : 250+ (theoretical) Latency : 30-150ms (Thread), variable (WiFi) Cost/unit : ~$7.0-11.0 (currently higher) Matter's promise is genuine cross-platform control. But in 2026: Pros: Native HomeKit, Alexa, Google Home support Thread mesh is excellent (when it works) IP-based → easier cloud integration Cons: Thread Border Routers aren't ubiquitous yet Advanced lighting features still evolving Premium pricing for early adoption Cost Analysis (20-Fixture Deployment) Protocol Driv

Hello Dev Community! 👋 It is officially Day 12 of my journey to master the MERN stack! Today, I wrapped up Lecture 3 of Apna College's JavaScript playlist with Shradha Didi, focusing on a fundamental data type we use every day: Strings . Before today, I thought strings were just plain text wrapped in quotes. Today, I learned how much power JavaScript gives us to manipulate, slice, and dynamically format text. 🧠 Key Learnings From JS Lecture 3 (Strings) I explored how JavaScript handles text strings and the built-in properties and methods that make text manipulation effortless: 1. Template Literals (The Ultimate Game Changer) Shradha Didi introduced Template Literals , which use backticks ( ` ) instead of standard quotes. This allows us to perform String Interpolation —embedding variables directly inside a string using ${variable} . It makes code look clean and professional: javascript let obj = { item: "pen", price: 10 }; // Old way: console.log("The cost of", obj.item, "is", obj.price, "rupees."); // Modern way: console.log(`The cost of ${obj.item} is ${obj.price} rupees.`);