AI 资讯

When I checked Google Search Console after a month, only 2 of my 8 sites were indexed. The other 6 had zero pages in Google's eyes. No penalty, no error banner. Just silence. The bug My build script generated the sitemap by mapping over page objects. Somewhere a URL field was an object, not a string. So the sitemap shipped lines like: <url><loc> https://example.com/[object Object] </loc></url> Google fetched the sitemap, saw garbage URLs, and quietly skipped the whole file. No crawl, no index. How I caught it GSC > Sitemaps > it said "Success" but "Discovered pages: 0". That mismatch is the tell. I opened the raw sitemap.xml in the browser and searched for [object . There it was. Root cause: url: page.url where page.url was itself { path, params } , not a string. The fix // before loc : page . url // -> [object Object] // after loc : `https://livephotokit.com ${ page . path } ` Redeployed, resubmitted the sitemap, and requested indexing on the core pages. Pages started landing in the index within a couple of days. Takeaway A "Success" status on your sitemap does not mean Google read your URLs. Always open the raw XML and eyeball it. One bad [object Object] can silently sink an entire site. I'm building LivePhotoKit and a handful of other small tools solo with AI. Sharing the real bugs as I hit them.

Please post your personal projects, startups, product placements, collaboration needs, blogs etc. Please mention the payment and pricing requirements for products and services. Please do not post link shorteners, link aggregator websites , or auto-subscribe links. -- Any abuse of trust will lead to bans. Encourage others who create new posts for questions to post here instead! Thread will stay alive until next one so keep posting after the date in the title. -- Meta: This is an experiment. If the community doesnt like this, we will cancel it. This is to encourage those in the community to promote their work by not spamming the main threads. submitted by /u/AutoModerator [link] [留言]

AI is changing how we build software, but I think a lot of developer tools are solving yesterday's...

Shared mailboxes for teams and AI agents Discussion | Link

https://www.gnosyslabs.com/case-studies/safety-classifier-sparse-labels Gnosys is an autonomous model engineer: it improves prompts and classifiers when ground truth is too sparse for conventional optimization. On ToxicChat, a public safety benchmark, under realistic label scarcity, it improved a classifier past both the team's starting point and GEPA (a standard prompt optimizer), across two runs of our current method. This note describes what we did, what we found, and where the method underperformed. Results We report harm caught : the share of harmful messages flagged, holding the false positive rate fixed at 5% (one in twenty) for every method, so a difference reflects additional harm caught at the same cost rather than a change of threshold. Both runs below are scored on a held-out set the system never saw. Headline run (3,000) Prior run (1,000) Gnosys 0.777 0.909 Starting classifier 0.731 0.788 GEPA 0.702 0.848 In both runs, Gnosys improved on both the starting classifier and GEPA. In the headline run GEPA not only trailed Gnosys but fell below the starting classifier (0.731 to 0.702); in the prior run it improved on the starting point. This inconsistency is the central difficulty under sparse labels: optimization sometimes helps and sometimes harms, and without trustworthy measurement there is no way to tell which has happened. The comparison is intentionally conservative: both approaches use the same underlying optimizer. The only difference is that Gnosys engineers the objective the optimizer works against. The problem Teams running high-stakes AI classifiers, in content moderation, fraud, claims review, and risk scoring, share one constraint: the ground truth they need is a human judgment that is expensive, slow, and sometimes never arrives. They can verify only a small set of examples while decisions accumulate on everything else. Tuning the model against the few labels on hand is where the difficulty concentrates. Here "few" is literal: about 200 verifi

Every few months, a new AI model is released, and the same question comes up: "Will AI replace software developers?" My answer is simple: No, but it will change what it means to be a developer. AI Is Already Changing the Way We Work Today's AI tools can write code, explain complex functions, generate tests, fix bugs, and even review pull requests. They're incredibly useful, and they've made developers more productive than ever. But writing code is only one part of software engineering. Developers still need to: Understand business requirements Design scalable systems Make architectural decisions Communicate with stakeholders Review trade-offs Debug production issues Think critically about security and performance These responsibilities require context, judgment, and experience—things AI still struggles with. Coding Isn't the Hard Part Many people think programming is mostly about typing code. In reality, coding is often the easiest part. The challenging work is figuring out: What problem should be solved? What's the best approach? What are the risks? How will this scale in the future? How do different systems work together? AI can generate solutions, but it doesn't truly understand your business, your users, or your long-term goals. Developers Who Use AI Will Have an Advantage The biggest shift isn't developers versus AI. It's developers who use AI effectively versus those who don't. The best engineers are already using AI to: Generate boilerplate code Create documentation Write unit tests Learn unfamiliar frameworks Prototype ideas quickly Automate repetitive tasks This allows them to spend more time solving meaningful problems instead of repetitive ones. What Skills Will Matter More? As AI becomes better at generating code, developers will need stronger skills in areas that AI can't easily replace. These include: System architecture Problem-solving Communication Product thinking Cloud infrastructure Security Performance optimization Leadership and mentoring The va

Every developer has that one project. The passion build that sits in the back of your mind for months—or even years—before you finally sit down, crack your knuckles, and make it a reality. For me, that project was building a modern, open-access bilingual digital lexicon bridging English and Assamese: AssameseDictionary.org . While it started as a personal milestone dream, it quickly turned into a massive data engineering and architecture challenge. Here is how I tackled parsing a massive vocabulary database and serving it globally with near-zero latency. 🏗️ The Core Challenge: Scale vs. Speed A dictionary isn't like a standard SaaS app or landing page. It lives and dies by its database depth. To make this a truly definitive tool, I compiled, cleaned, and programmatically validated an extensive vocabulary index mapping over 293,000 words . The dataset doesn't just hold simple translations; it maps complex bidirectional lookups, phonetic transliterations, advanced English definitions, context usage examples, and cross-linked synonym tokens. If I threw this massive dataset into a traditional relational database hooked up to a standard server setup, I ran into immediate roadblocks: Latency: Heavy search queries on a dataset this size can cause noticeable lag. Cost/Overhead: Maintaining and scaling database servers for unpredictable public traffic gets expensive fast. I wanted the search utility to snap back instantly. To achieve that, I had to ditch traditional server paradigms entirely. ⚡ The Architecture: Serverless Edge Caching To keep things ultra-lightweight, highly cost-effective, and blazing fast, I built the platform around an edge-computing topology: The Runtime: I offloaded the backend logic entirely to Cloudflare Workers . Instead of routing traffic to a centralized origin server, queries are intercepted and executed at serverless edge locations physically closest to the user. The Data Layer: Instead of an active SQL database bottleneck, I mapped the data mat

Introduction: Unveiling the Critical Vulnerability The recently identified CVE-2026-8037 vulnerability in Progress Kemp LoadMaster represents a critical threat to enterprise infrastructure. This remote code execution (RCE) flaw, stemming from an uninitialized heap issue , enables pre-authentication exploitation, allowing attackers to bypass initial security barriers without valid credentials. The root cause lies in the failure to initialize dynamically allocated memory regions, creating an exploitable condition where untrusted input can corrupt critical data structures. Attackers leverage this memory corruption to redirect program execution to malicious payloads, achieving full system compromise—from data exfiltration to operational disruption. Technically, the vulnerability arises during the software’s handling of untrusted input. When memory chunks in the heap are allocated but not properly initialized, they retain residual data or undefined states. Attackers exploit this oversight by crafting inputs that overwrite function pointers or control-flow structures, hijacking the program’s execution path. The causal sequence is precise: uninitialized heap → memory corruption → arbitrary code execution → system compromise. The pre-authentication nature of the exploit exacerbates the risk, as attackers require no prior access to execute their payload, rendering perimeter defenses ineffective. The implications are severe for enterprises relying on Kemp LoadMaster for load balancing and application delivery. Unpatched systems are exposed to infiltration, data theft, and ransomware deployment. Beyond the technical failure, CVE-2026-8037 exposes systemic deficiencies: insufficient input validation in software design and inadequate security testing during development. Organizations further amplify risk through delayed patch management , creating a critical window of opportunity for attackers. Immediate remediation is imperative to prevent catastrophic breaches that could under

The agent brand is irrelevant; the work item is everything. I have watched teams argue about Copilot Studio versus Claude Code versus Codex as if the model decides whether their build succeeds. It does not. Your agentic development power platform effort lives or dies on one thing: whether the Azure DevOps work item you hand the agent is a machine-readable spec or a vaguely worded wish. Swap the agent all you want. If the requirement is unstructured, every agent guesses, and every guess is a different guess. This article is opinionated on exactly one point and neutral on everything else. Neutral on the tool. Ruthless about the spec. Why "AI-assisted" Power Platform dev stalls on real teams The agent guesses intent because the acceptance criteria live in a stale wiki, a Teams thread, or someone's head. That is the whole failure. Switching from one agent to another does not close the gap. The missing spec does. Prompt-by-prompt building has a second problem that shows up later and hurts more. One maker gets a working flow out of a chat session, but nobody else can reproduce it and no one can audit it. You have a solution that exists and a rationale that evaporated. For teams doing serious dynamics 365 ai development , that is not acceleration. That is a single point of failure wearing a productivity costume. Frame the cost honestly. Say a rework cycle caught in UAT runs roughly 5x the cost of the same fix at design time. Illustrative; calibrate against your own data, actuals vary. Under that assumption, the line item bleeding your budget is the improvised requirement, not the agent license. You are paying to rediscover intent three environments too late. Takeaway: if your requirement is not structured, your agent is improvising, and the brand of agent does not matter. Make the ADO work item the single source of truth An agent reads fields. It does not read the room. So the work item has to carry everything the agent needs in a shape a parser can trust every single time

📚 Series: Databricks on AWS (Part 0, prologue) The Target Architecture ← you are here Building a Databricks AI Platform on AWS RBAC with Function-Role Groups Compute Governance: Pools, Policies, Clusters The BOOTSTRAP_TIMEOUT Mystery Fixing It with AWS PrivateLink How We Structure the Terraform Before the build story, here's the destination. This is the target-state data architecture we designed the whole platform toward — the three principles that shaped every later decision, and the Unity Catalog governance model that keeps production data safe from human hands. The rest of this series is a build log: workspaces, RBAC, compute, the networking rabbit hole, the Terraform layout. But every one of those decisions was made in service of a target picture we drew first . This post is that picture — the "to-be" architecture, not the scaffolding we happened to have up on any given week. It's built on three things Databricks basically hands you if you lean into them: the Lakehouse (one store, ACID tables, no separate warehouse to sync), the Medallion architecture (raw → cleaned → integrated → business, each layer a promotion), and Unity Catalog as the single governance plane across all of it. The interesting part isn't reciting those three buzzwords — it's the specific way we wire them so that prod, dev, and analyst sandboxes never step on each other. Three principles, and everything follows Almost every concrete rule later in this series is a consequence of one of these three. 1. Nobody touches production by hand. Create, update, delete in prod data happens only through an automated, code-reviewed pipeline running as a service principal. Human accounts don't get write on prod — not analysts, not engineers, not admins. The blast radius of a bad afternoon is capped at whatever a person can do with read-only. This one principle is why the whole "promote" flow later exists. 2. Never copy production to look at it. If an analyst wants to explore the gold layer, they read it in p

Pricing is the single most powerful lever you have for growing SaaS revenue — yet most founders treat it as an afterthought. A 1% price increase can yield an 8-12% increase in operating profit, far more than acquiring the same revenue through new customers. This playbook covers the five core decisions every SaaS company must make: monetization model, value metric, tier structure, psychological pricing tactics, and pricing page optimization. Introduction: Why Pricing Is Your Most Important Growth Lever When founders think about growth, they typically reach for familiar levers: more marketing spend, bigger sales teams, viral features. But pricing is the one lever that touches every single customer interaction — and it costs nothing to change. Consider this: if you raise prices by 1% and lose 1% of customers, your net revenue still increases. The math works because the lost customers are often your least price-sensitive ones. In practice, companies that run pricing experiments typically find they can increase prices by 5-15% before seeing any meaningful impact on conversion. Yet pricing is also where most SaaS companies are at their most irrational. We underprice out of fear, copy competitors without understanding why, and avoid changes because we're afraid of customer backlash. Freemium vs Free Trial vs Paid-First Freemium Freemium offers a permanently free tier with limited features. It's a top-of-funnel machine — but it requires low marginal cost per user and a clear upgrade path. Aspect Freemium Best for Products with viral loops, network effects Conversion rate Typically 2-5% free-to-paid Risk High support cost for free users Example Slack, Notion, Canva Free Trial (Time-Limited) Time-limited trials give full access for 7-30 days, then require payment. Aspect Free Trial Best for Products with immediate value delivery Conversion rate Typically 10-25% trial-to-paid Risk Users forget to use the trial Example GitHub, Figma, Intercom The biggest mistake teams make: tre

Using AI to find authorization bugs — and to prove the ones that aren't real Draft flagship post. Safe to publish now (no undisclosed vulnerabilities). The production case study referenced at the end is withheld pending coordinated disclosure. In 2026, bug bounty programs started closing their doors. Nextcloud suspended paid rewards, citing a flood of AI-generated, low-quality reports. Mattermost ended its program. The Internet Bug Bounty cut payouts by roughly 80%. The common thread isn't that AI can't find bugs — it's that most AI-assisted "findings" are plausible but wrong , and triage teams are drowning in them. That reframes the problem. The scarce skill in 2026 isn't generating candidate vulnerabilities — a language model will hand you fifty before lunch. It's refuting the forty-nine that don't hold . The differentiator is a method whose primary output is correct negatives . Here's the method I use for source-available targets, and a worked example where the honest result was "there's no bug here." The method: fan out to find, converge to refute Two stages, two different cost tiers: Fan-out (cheap models). Split the target's authorization surface into subsystems and read each in parallel. Each reader's only job is to surface candidate broken invariants — places where an object is loaded by ID without an owner check, where a protected action might skip a re-auth gate, where two code paths authorize the same thing differently. Optimize for recall. Expect mostly false positives. Adversarial verification (an expensive, high-reasoning model). Take each candidate and try to kill it. Default to REFUTED. A candidate survives only if you can cite the specific source lines proving the guard is absent and the dangerous path is reachable and nothing upstream already blocks it. Frame every survivor as a broken invariant — a one-sentence statement of the rule the system must never violate — and classify it as core versus config-dependent. The output that matters most is the

Shared, searchable memory for every AI coding agent Discussion | Link

Introduction to Hydration and Rendering Strategies In the relentless pursuit of faster, more responsive web applications, developers have engineered a spectrum of hydration and rendering strategies . Each approach emerges as a response to specific performance bottlenecks, yet none is universally optimal. This section dissects the core mechanics of these strategies, their historical evolution, and the critical problem they aim to solve—balancing speed with practicality. The Problem: A Trade-Off Landscape At its core, the challenge is mechanical : how to deliver content to the user’s browser with minimal latency while maintaining interactivity. Traditional rendering methods (e.g., server-side rendering) prioritize initial load speed but often defer interactivity until JavaScript execution. Client-side rendering, conversely, delays the first paint but ensures seamless interactions post-hydration. The tension between these extremes has birthed hybrid strategies like incremental hydration and islands architecture , each addressing specific failure points in the rendering pipeline. Key Mechanisms Driving Strategy Evolution Advancements in Web Technologies : New APIs (e.g., Web Components, Streaming SSR) enable finer-grained control over rendering. For instance, streaming SSR reduces Time-to-First-Byte (TTFB) by sending HTML in chunks, but risks breaking the causal chain of DOM hydration if not synchronized with client-side scripts. User Expectations : Sub-second load times are no longer aspirational but expected. This pressure deforms traditional workflows, pushing developers toward pre-rendering or static site generation (SSG), which trade dynamic flexibility for speed by offloading rendering to build time. Competitive Pressure : Performance is a zero-sum game. Companies adopt strategies like partial hydration (hydrating only interactive components) to minimize JavaScript payload, but this risks breaking interactivity if the hydration boundary is misaligned with user int

We’ve all been there. You get a notification from your smartwatch saying your heart rate has been a bit funky, or your blood oxygen is dipping. Usually, we ignore it until it becomes a problem. But what if your personal AI was looking out for you? 🤖 In this tutorial, we are building an Autonomous Health Agent . This isn't just a notification bot; it's a proactive system that uses Playwright browser automation , OpenAI Function Calling , and Python to monitor your health trends and—if things look suspicious for three days straight—literally opens a browser and books a doctor's appointment for you. By leveraging Autonomous AI Agents and Playwright automation , we are moving from "Passive Monitoring" to "Active Intervention." This is the future of Health Tech Automation . 🏗 The Architecture Before we dive into the code, let's look at how the data flows from a "scary heart rate" to a "confirmed appointment." graph TD A[Wearable Data/Health Logs] --> B{3-Day Anomaly Check} B -- Normal --> C[Stay Healthy! 🟢] B -- Abnormal --> D[Trigger AI Agent 🤖] D --> E[OpenAI Function Calling] E --> F[Playwright Browser Automation] F --> G[Hospital Booking Platform] G --> H[Appointment Confirmation 🏥] H --> I[Notify User via SMS/Email] 🛠 Prerequisites To follow along, you’ll need: Python 3.10+ Playwright : The king of modern browser automation. OpenAI API Key : For the "brain" of our agent. A healthy dose of curiosity! 🥑 pip install playwright openai pydantic playwright install chromium 👨‍💻 Step 1: Defining the "Brain" (OpenAI Function Calling) We don't want the LLM to just "talk" about booking an appointment; we want it to actually execute the action. We'll use OpenAI's Function Calling to bridge the gap between text and code. import json from openai import OpenAI client = OpenAI () # Define the tool our agent can use tools = [ { " type " : " function " , " function " : { " name " : " book_doctor_appointment " , " description " : " Books a medical appointment based on department and s

Video AI systems consistently fail to track what happens when the camera looks away: when a scene pans away from an object in motion and returns, current models re-render the object in its original position rather than showing the logical result of off-screen change. Scaling to more parameters makes this failure worse, not better, according to WRBench , a new benchmark that tests what researchers call "world model reliability." The benchmark presents AI video systems with scenes where something happens off-screen — the camera pans away while an object is in motion, or while a light changes, or while an open door should stay open — then pans back to see what the system believes should have happened. A system that genuinely models the world would track what occurred during the off-screen interval. Current systems mostly don't. Key facts What: A new benchmark tests whether video AI systems can track what happens to parts of a scene the camera isn't currently showing. Across 23 models, the answer is mostly no — and making the models larger made the problem worse, not better. When: 2026-06-19 Primary source: read the source (arXiv 2606.20545) The benchmark covers twenty-three different video generation models and nearly ten thousand video clips across six categories of off-screen change, each designed to test a different aspect of world continuity: objects in motion, light sources changing, object states such as open or closed doors, and several others. This gives a comprehensive picture rather than a single narrow test. The most striking finding is the scaling result. The researchers tested one of the more capable video generation systems at two different sizes: a smaller version and one with more than ten times as many parameters. More parameters didn't help. Scaling made the off-screen tracking problem measurably worse. The larger model produced more realistic-looking frames, but it was less accurate about what should have happened to the parts of the scene it wasn't

Loop Engineering — เมื่อการ Prompt Agent ด้วยมือไม่พออีกต่อไป แล้ว Programmer ต้องออกแบบ Loop แทน โดย Nokka (นก-กา) | 1 กรกฎาคม 2026 TL;DR — สำหรับคนที่รีบ กลางเดือนมิถุนายน 2026 ที่ผ่านมา วงการ AI developer สั่นสะเทือนด้วยประโยค 6 คำจาก Peter Steinberger ผู้สร้าง OpenClaw: "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." ประโยคนี้มียอดวิว 8 ล้านครั้งในวันเดียว และจุดกระแส "Loop Engineering" ที่กลายเป็น buzzword ร้อนที่สุดของเดือน Loop Engineering คือการเปลี่ยนจากการนั่ง Prompt Agent ทีละคำสั่ง มาเป็นการเขียน Loop (โปรแกรม) ที่ทำหน้าที่ Prompt Agent แทนคุณ โดย Loop จะเป็นคนเลือกงานต่อไป, ส่งให้ Agent, ตรวจสอบผล, ตัดสินใจว่าจะทำต่อหรือหยุด คุณไม่ได้เป็นคนขับ Agent อีกต่อไป — คุณเป็นคนออกแบบระบบที่ขับ Agent 1. Loop Engineering คืออะไร? เกิดมาจากไหน? เรื่องนี้เริ่มต้นจาก Boris Cherny ผู้สร้าง Claude Code พูดบนเวที Acquired Unplugged ต้นเดือนมิถุนายน 2026 ว่า: "I don't prompt Claude anymore. I have loops that are running. They're the ones that are prompting Claude and figuring out what to do. My job is to write loops." สองวันต่อมา Peter Steinberger โพสต์บน X ว่า "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." โพสต์นี้มียอดวิว 8 ล้านครั้ง [1] หลังจากนั้น Addy Osmani (Google Engineer, O'Reilly author) เขียนบทความ "Loop Engineering" บน O'Reilly Radar ให้คำจำกัดความว่า: "Loop engineering is replacing yourself as the person who prompts the agent." [2] และ @0xCodez ก็รวบรวมเป็น 14-step roadmap จาก "prompter" สู่ "loop designer" [3] ในมุมมองของผม Loop Engineering ไม่ใช่ buzzword ธรรมดา แต่มันคือการเปลี่ยน abstraction layer ของการทำงานกับ AI เหมือนกับที่เราเปลี่ยนจาก Assembly → High-level language หรือจาก Bare metal → Cloud แต่ก็ต้องยอมรับว่า Loop Engineering ยังเป็นแนวคิดใหม่ และยังไม่มี standard practice ที่ชัดเจน สิ่งที่ใช้ได้วันนี้อาจเปลี่ยนไปใน 3 เดือน 2. ทำไมต้อง Loop Engineering? ลองนึกภาพการทำงานกับ AI coding agent แบบเดิม: คุณพิมพ์ prompt → รอ → อ่าน dif