AI 资讯

Uber One, meet Waymo Premier. The robotaxi operator announced a new $29.99-a-month premium tier for riders who want a more elevated and exclusive autonomous experience. The invite-only membership service is aimed at Waymo customers who use the service most frequently, offering them a number of perks, including priority pickups, 10 percent cash back on every […]

One of the reasons I often find myself disagreeing with modern software trends is that many conversations revolve around features. How many features does it have? How quickly can we add more? What can we put on the marketing page? What can we announce next? Features matter. But I care far more about systems. Because at the end of the day, people don't buy features. They buy outcomes. And outcomes come from systems. The Car Analogy One of the easiest ways to explain my thinking is with cars. A car is made up of thousands of individual components. An engine. A transmission. Suspension. Brakes. Fuel systems. Electrical systems. Cooling systems. Sensors. Wiring. Each component is important. But nobody walks into a dealership and says: "I'd like to purchase six pistons, a transmission housing, and a fuel injector." They buy a car. They buy transportation. They buy a complete system. The individual parts only matter because they contribute to the overall experience. The customer doesn't want to think about every moving piece. They want to get in, turn the key, and drive. Drivers and Mechanics This is where I think technology often loses its way. Users are drivers. Engineers are mechanics. A driver should be able to: Start the vehicle Fill it with fuel Check the oil Wash it Perform light maintenance That's about it. They shouldn't need to understand combustion timing, transmission gearing, or electrical diagnostics to get to work. The mechanic, however, lives in the details. They tune the system. They replace parts. They troubleshoot failures. They recommend upgrades. They understand how the pieces fit together. Technology is exactly the same in my mind. Users should be able to focus on their goals. Engineers should focus on the machinery. Features Are Parts This is where I think software conversations sometimes become backwards. A feature is a component. A login screen is a component. A dashboard is a component. A database is a component. An API is a component. AI integra

In December 2025, Anthropic acquired Bun , the JavaScript runtime written in Zig. In April 2026, the Bun team announced a 4× compile-time improvement on their fork of the Zig compiler — "parallel semantic analysis and multiple codegen units to the llvm backend" , in their phrasing. They also announced they would not be upstreaming the work, "as Zig has a strict ban on LLM-authored contributions." The framing landed badly with Zig observers, for two reasons. The first was that the framing made Zig's contribution policy the obstacle. The second, pointed out shortly afterwards by a Zig core contributor in the Ziggit thread, was that the patch had separate engineering reasons it would not have been merged regardless: "Parallel semantic analysis has been an explicitly planned feature of the Zig compiler for a long time" , with "implications not only for the compiler implementation, but for the Zig language itself" . The AI-ban explanation was, on a closer read, a tidy way of declining to litigate the engineering disagreement in public. Both readings are useful. They are also both downstream of the actual rationale, which is one of the most carefully argued OSS-governance documents to appear in 2026. What the policy actually says The relevant clauses, in the Zig code of conduct under the section heading Strict No LLM / No AI Policy , are three: No LLMs for issues. No LLMs for pull requests. No LLMs for comments on the bug tracker, including translation. English is encouraged, but not required. You are welcome to post in your native language and rely on others to have their own translation tools of choice to interpret your words. The translation clause is the surprising one. It is also the one that disambiguates the policy from a code-quality rule. A blanket ban on LLM-mediated communication, including translation, is not a heuristic about whether agentic tools produce good code. It is a stance about what the project's communication channels are for . Contributor poker Lor

Alerts are more trustworthy and actionable when noise is reduced. See how we improved the verification step with context-aware LLM reasoning. The post Making secret scanning more trustworthy: Reducing false positives at scale appeared first on The GitHub Blog .

Before agentic coding, I always prided myself on how long I could work in a flow state. I was really good at working deeply. Now, with slow agents like Claude, I find myself no longer working deeply. What are you all doing to stay focused?

If you’ve been learning React for a while, you’ve probably come across hooks that help optimize your application such as useMemo() and useCallback() and might have wondered: "Do I really need these hooks?", "Where are they useful?" etc. In React 19, the React Compiler was introduced and it's work is to help you optimize your application automatically. This raises a question where if React can automatically optimize an application, why should I bother learning how to optimize my app manually with hooks like useMemo() ?. Let me break down why you would still need to do manual optimization and what the React Compiler was created to solve in a simple, beginner friendly way. What Is the React Compiler? The React Compiler is a new optimization tool developed by the React Team. It's goal is simple: Automatically make your React app faster without you writing extra optimization code. Traditionally, React re-renders a component each time the state changes. This is usually fine, but if you have a component that does a lot of work, this can make your app very slow during re-renders. The React Compiler steps in to: Detect unnecessary re-calculations Memoize values and functions automatically Prevent avoidable re-renders So instead of you writing: const filteredItems = useMemo (() => filterItems ( items ), [ items ]); The compiler handles it for you behind the scenes. Why is this such a big deal? This changes how we write code in React, it helps us avoid over-optimizing our code when it might not need any optimization. Most developers that learn about useCallback() or useMemo() tend to overuse them (guilty party here 😅), resulting in the application behaving much slower instead of faster, hence the need for the React compiler as it optimizes the code where necessary. The React Compiler also provides the following benefits: 1. Less boilerplate code You don’t have to wrap your optimization logic in useMemo() or useCallback() . 2. Fewer mistakes Manual memoization is easy to get wr

Elon Musk, on the verge of becoming the world's first trillionaire, is whipping up anti-immigration tensions amid ongoing riots in Belfast, Northern Ireland. Following a knife attack in the city on Monday, Musk declared support for Restore Britain, a hard-right populist political party that advocates for large-scale migrant deportation in the UK. He reposted statements […]

I keep finding the same Stripe webhook bugs in SaaS launches Most early SaaS billing bugs are not in Stripe Checkout itself. They are in the glue around it: trusting the success redirect instead of the signed webhook parsing JSON before signature verification missing idempotency for retry events reflecting verifier errors from unauthenticated webhook routes updating subscription state without a replay/audit trail letting "Pro" access drift from the payment source of truth Over the last few days I have been shipping small public fixes around exactly this class of problem. Recent examples: Morphix: Cloudflare Worker Stripe webhook with signature verification, Supabase subscription sync, and event idempotency ledger https://github.com/yiyuanlee/morphix/pull/25 Open Mercato: hardened unauthenticated payment/shipping provider webhooks against raw verifier error reflection and missing rate limiting https://github.com/open-mercato/open-mercato/pull/2680 Covenant: webhook signatures hardened against replay and secret rotation gaps https://github.com/wienerlabs/covenant/pull/229 Volunteerflow: made a Stripe invoice.paid Founders Circle counter update transactional instead of partially committing user/counter state https://github.com/ppppowers/volunteerflow-project/pull/49 The pattern is boring in the best possible way: payment systems should be boring. The 48-hour version For a small SaaS that is about to turn on paid plans, I can take a bounded payment assurance sprint: inspect Checkout / webhook / subscription state flow verify signed webhook handling and raw-body behavior add idempotency around Stripe retry events ensure subscription status and entitlement state have one source of truth add a small regression test or smoke script leave a deploy/runbook note so the next failure is diagnosable Fixed scopes I am taking: $2,000 / 48 hours: one payment path hardened and documented $5,000 / 5 days: full launch pass across Checkout, webhook, subscription mirror, Pro gate, pricin

Introduction Nowadays, AI agents are becoming increasingly powerful at assisting users in their daily web activities. However, we cannot yet allow them to act completely autonomously—there is still a risk of them clicking on the wrong elements, for instance. In theory, these agents are capable of performing impressive tasks, provided they are guided step-by-step through the interface. The challenge here is not a lack of intelligence in the model, nor a shortage of web APIs to expose data to the agent. The core issue lies in the fact that the agent must currently "guess" its way through applications that were designed exclusively for humans. This is precisely the problem that WebMCP is here to solve. It is important to note that these are not intended to replace standard APIs as access points for an application. Instead, they provide a structured way for a web application to "instruct" the AI agent used in the browser on how to navigate its interface. This results in: Fewer misplaced clicks. Less trial-and-error when interacting with the UI. When utilized to their full potential, WebMCPs could redefine the user experience in the coming years. What is WEBMCP? As you may have guessed, WebMCP is a browser-side "guide/standard" for exposing tools to an AI agent directly from an active web page. During Google I/O, this new feature was introduced as a way for web applications to describe how a page functions—and what actions can be performed—to various AI agents. As a result, agents can execute these described actions faster, more efficiently, and with greater precision. Unsurprisingly, the syntax for creating these descriptions relies on JavaScript functions. These functions take natural language descriptions as parameters, along with structured schemas directly exposed from the web page. This is exactly where the power of WebMCP lies. Today, while we have Playwright (designed for end-to-end testing of web applications) and Playwright MCP (which extends this model to LLMs

built a dealer management system for a tea reseller (basically a billing/accounting app). The tech stack is: Frontend: Next.js 15 (App Router) Backend: Hono framework running on Bun Database: PostgreSQL with Drizzle ORM Auth: Better Auth (session-based, role-based access) About the business: ~400 customers (tea leaf suppliers) 5-10 staff users max Daily data entry (tea collection weights), monthly billing with deductions Database will be tiny — maybe 15 MB/year of pure text data They want it to feel like a desktop app but with data stored safely in the cloud Budget is very tight — ideally free or under $5/month What I've considered: Free tier stack (Vercel + Render + Neon) — $0 but Render free tier sleeps after 15 min, cold starts are annoying VPS (Hetzner/DigitalOcean ~$5/mo) — Hostinger Node.js hosting — doesn't support Bun or PostgreSQL PWA for the "desktop app" feel — seems like the right call My questions: For developers who build apps for small businesses in developing countries — what's your go-to deployment strategy? Is the free tier stack (Vercel + Render + Neon) reliable enough for production? Would you switch from Bun to Node.js just to have more hosting options? The Bun lock-in is becoming a pain. Is there a better approach I'm not seeing? Something between "run it on a local PC" and "pay for a VPS"? How do you handle backups for clients who can't manage their own infrastructure? Any advice appreciated. This is my first time deploying a production app for a real business and I want to get it right — it handles their financial data. submitted by /u/Iamxv [link] [留言]

A few months ago, while interviewing for a Cloud Solutions Architect role at Microsoft, one of the interviewers asked me a question that stuck with me long after the interview ended. Not because I couldn't answer it. But because I kept thinking about whether I had answered it well. The question was: "What's the hardest part about working on mainframe technology?" At the time, I was still relatively new to the world of mainframes. And by "relatively new," I mean embarrassingly new. Before joining my current company, I didn't even know something called a "mainframe" still existed. If you'd asked me what COBOL was, I probably would've guessed it was a Pokémon. Okay that is an exaggeration but you get what I mean. I still remember early on hearing terms like KT (Knowledge Transfer) being thrown around and quietly wondering if everyone had received some secret corporate dictionary except me. The good news is that I've never been particularly afraid of looking stupid. So my strategy is simple: Ask the question. Then ask the follow-up question. Then ask the question that reveals I didn't understand the previous answer either. Surprisingly, people were usually happy to explain. Anyway, after a few KT sessions and what I'd generously describe as a "bare minimum amount of research," my brain went where most developers' brains probably would've gone. The technology The age The tooling The learning curve The fact that some of these systems were designed before I was even born All perfectly reasonable answers. But while I was sitting there in the interview, another thought appeared: "This feels too obvious." Interviewers at that level usually aren't asking for the first answer that comes to mind. They're trying to understand how you think. And the more I reflected on that question afterwards, the more I realized something interesting. The hardest part isn't the technology itself. Before I started working around large enterprise systems, my mental model of old technology was pret

Modern enterprise order processing architectures must decouple synchronous client demands from asynchronous backend dependencies. Here I'll detail a highly scalable, fault-tolerant design built on AWS. By utilizing an automated API Gateway entry point, specialized Amazon Cognito authentication, optimized AWS Lambda logic blocks, an engineered RDS Proxy connection layer, and an event-driven SQS/EventBridge core, the design guarantees isolation, cost efficiency, and sub-millisecond structural routing. The Scenario User places an order → payment is processed → inventory updated → confirmation email sent Client → API Gateway (Cognito auth + validation) → Order Lambda (business logic + DynamoDB write) → SQS (payment queue) → Payment Lambda → EventBridge → Inventory Lambda → Notification Lambda (SES) 1- Entry Point — API Gateway REST endpoint: POST /orders Request validation via API Gateway models (reject malformed payloads instantly, no Lambda invoked) Auth via Cognito User Pool Authorizer — validates JWT token on every request How It Works The Request Hits: A client sends a POST /orders request with a JWT token in the header. Auth Check: API Gateway automatically intercepts the request and validates the JWT against the Cognito User Pool. If expired or spoofed, it returns 410 Gone / 401 Unauthorized right there. Payload Check: Next, it compares the body against your JSON Schema Model. If a required field like customer_id is missing, API Gateway instantly drops it with a 400 Bad Request. The Win: Your downstream services (like Lambda) are never invoked for bad/unauthorized requests, saving compute costs and protecting against basic DDoS or bad actor spam. Gotchas Cognito Latency: While Cognito authorizers are native, they can add a slight latency overhead to your API's P99 metrics during peak traffic. For massive global scale, some enterprises migrate to custom Lambda Authorizers that cache tokens in ElastiCache (Redis). Model Validation Limits: API Gateway's built-in val

We are so excited to announce the winners of the Google I/O 2026 Writing Challenge ! We asked you to explore the announcements from Google I/O 2026 and share your thoughts and firsthand takes. Wow, you delivered. The quality and depth of submissions genuinely impressed our team. From hands-on walkthroughs to bold opinions on what the announcements really mean for developers, the entries were thoughtful, original, and packed with insight. Thank you to everyone who participated. Your writing helps make this community one of the best places on the internet to learn what's actually happening in tech. Now, let's celebrate our five winners! 🎉 🏆 Congratulations To… The Sleeper Announcement from Google I/O 2026 That Will Change How We Think About Apps Google I/O Writing Challenge Submission Vrushali Vrushali Vrushali Follow May 24 The Sleeper Announcement from Google I/O 2026 That Will Change How We Think About Apps # devchallenge # googleiochallenge # android # kotlin 7 reactions 2 comments 7 min read @vrushali_dev_15 wrote a standout deep-dive into AppFunctions — Android's new API for exposing app capabilities directly to AI agents. With 10 years of Android experience behind the lens, this post goes far beyond the surface announcement to map out the full architectural shift this signals and what developers should be thinking about right now, even before shipping a single AppFunction. I gave Gemini 3.5 Flash a CVE-fix PR to review. It found another bug in the same file. Google I/O Writing Challenge Submission Vicente Junior Vicente Junior Vicente Junior Follow May 22 I gave Gemini 3.5 Flash a CVE-fix PR to review. It found another bug in the same file. # googleiochallenge # devchallenge # ai # gemini 9 reactions 1 comment 7 min read @vicente_junior_dev did something rare: actually tested the thing. Running Gemini 3.5 Flash across 3 real production PRs, including a CVE fix, the post documents what the model caught. Grounded, honest, and exactly the kind of first-person expe

Virtual Coffee has always been a free, volunteer-led developer community supporting the tech community since 2020. We host small-group coffees, challenges, learning opportunities, and community spaces where folks can ask questions, find encouragement, share job leads, get support, and build relationships with other people in tech. For many members, Virtual Coffee has been more than another Slack group or online event. It has been a place to feel less alone while learning, job searching, changing careers, growing as a developer, or navigating the tech industry. And we want to always keep it free. That matters to us because our members are in many different seasons of life, employment, financial security, energy, and capacity. We never want cost to be the reason someone cannot participate. Right now, though, Virtual Coffee is struggling to cover the basic costs that keep the community available. Over time, sponsorships and individual contributions have declined. We have reached out to people and companies, covered costs ourselves when needed, and worked to reduce expenses by lowering tool costs, reviewing what we can remove or replace, and building more of our own infrastructure. We are close to covering the basics, but not quite there. We are also being realistic about capacity. Virtual Coffee is volunteer-led, and we are very aware of volunteer burnout. We are not promising a big relaunch, a burst of extra programming, or a sudden expansion. Our immediate goal is simpler: stabilize the basics so Virtual Coffee has room to thoughtfully plan for a sustainable future. If you believe free, welcoming developer communities matter, we would be grateful for your support. You can help by sponsoring Virtual Coffee through GitHub Sponsors . Even a small monthly contribution helps. One-time contributions help too. You can also help by sharing our GitHub Sponsors page with someone at your company who supports developer communities, open source, learning, DevRel, or community pro

This is Lowpass by Janko Roettgers, a newsletter on the ever-evolving intersection of tech and entertainment, syndicated just for The Verge subscribers once a week. Severance. Pachinko. Silo. Ted Lasso. Over the past couple of years, a number of Apple TV shows have become hits with audiences and critics alike. And yet, compared to the […]

So long and thanks for all the cool new video games.

tl;dr: I'm looking for a visual HTML builder - not a design tool, but something that specifically builds code Hi everyone, I feel the need to explain before anything, why I'm looking for this. Pls read the explanation before coming for me with "why don't you just write HTML and CSS normally, what's wrong with you". I've been a dev for 12+ years, mostly specializing in complex software. Give me a design system, business requirements (not even a fleshed out plan) and I'll give you something that works and is futureproof, as much as I can predict the future anyway. In all of that, I've always struggled with writing full pages with HTML and CSS. I find it hard to keep the whole context in mind and I've never come up with a way to structure it sensibly. Frameworks like Tailwind CSS drive me nuts because why do I need to memorize specific classes instead of just writing CSS? Anyway, that's not the point. Recently I realized that I need to diversify my service offering, and therefore start offering more of these custom built websites. But now I'm running into my personal limitation of being trash at HTML/CSS. AI isn't much help here because Claude Code is absolute garbage in implementing designs, and I'm not paying for 3 different AI subscriptions - that would work against my goal of making money. So now I'm looking for a more visual HTML and CSS editor. Design tools like Figma are one thing, but I'd like something that is made for people who know HTML, but just don't want to write it themselves. The workflow I imagine is something like this: I start with a blank slate. It prompts me to add fonts, colors and other foundational design system elements. This would set CSS variables. From here I can proceed to create pages or complete the design system with other components (buttons, inputs, etc) Each page contains common elements (header, footer, sidebar, whatever) + a blank area for me to drag and drop elements into. As I use the elements, I should be able to set classes, id