标签：#AR

In a recent research paper, Google introduced Beyond Zero, a “security model for the AI era” that extends Zero Trust to autonomous AI agents. The new approach moves access decisions from the application level to individual resources and actions, combining static authorization controls with dynamic AI-driven decisions to enable machine-speed enforcement for humans and agents. By Renato Losio

Apple is expected to announce several products at its September event next week—including a folding phone—but the iPhone 18 might not be among them. It would be a first for the company.

Zero trust has been discussed so often at this point that it's genuinely lost some precision it gets invoked as a general security philosophy, a marketing term, and an actual architecture, often in the same conversation, without anyone distinguishing between those three genuinely different things. The philosophy is simple to state: never trust, always verify. The actual implementation is where nearly every enterprise gets stuck, because "never trust" is easy to say and genuinely hard to build into infrastructure that was, in most cases, originally designed around the opposite assumption. My real position here: most enterprise zero trust initiatives fail not because the architecture is too complex to implement, but because they get treated as a single project with an end date, rather than a genuine, multi-year architectural transition that has to coexist with legacy systems the whole way through. Organizations that try to flip a switch and declare zero trust "done" end up with a partial implementation that provides less real security benefit than either a genuinely completed transition or an honestly incomplete one that's still being actively worked toward. Start With What Zero Trust Actually Requires, Not the Marketing Version Stripped of buzzwords, zero trust network architecture means: no user, device, or system is trusted by default based on network location alone. Every access request gets verified based on identity, device health, and context every time, not just at initial login regardless of whether that request originated inside or outside what used to be considered the trusted network perimeter. This is a genuinely fundamental shift from traditional network security, which trusted traffic considerably more once it made it past the perimeter. Implementing this requires rethinking identity, network segmentation, device management, and monitoring simultaneously, as a connected system not layering a zero trust label onto an architecture that hasn't actually cha

The main action took place at Geneva Watch Days, but others dialed in remotely to make sure it wasn't just a Swiss party.

The studio released an official catch-up list ahead of December’s release. We have easy links to watch every one of the movies so you can get up to speed.

I haven't written an article in a while. But nothing gives you more inspiration to write than an opinion you really, really disagree with. In my case it was I'm done using AI article by Brett Codes. Over around 2000 words, the author explains his negative views on AI and why he decided to stop using it . I am really no AI evangelist. I am aware of its limits and its problems and the incompetent people causing more harm than good with it. But I also see the goodies, and I am pretty much convinced author's decision was driven less by rationality and more by the false pride. Let's swallow one bitter, but important pill - no one is paying you solely for being a good developer. You are being paid for delivering a value. And yes - being a good developer greatly contributes towards the ability of delivering apps that work and help businesses yielding the values. And by "work" I mean not only they look good at the first glance, but also being not (too much) buggy, secure and maintainable in the foreseeable future. Therefore, purely vibe-coded projects driven solely by non-IT people often (if not always) fail. Because their authors don't know what it takes and so they cannot prompt their agents to reason and care about it. We devs do. Some of us know more, some of us know less (yet). The "AI is going to replace all programmers" is a lunatic nonsense. But so is rejecting AI and sanctifying "good ol' hand work" . Does anyone seriously think we should reject modern programming languages and revert into writing in assembly or even better directly in binary code? Do you develop in plain text editor without syntax highlighting? Why are you using containers and not building new on-premise servers every time? Whaat? You use frameworks and 3rd party libraries? You don't implement everything from scratch in the vanilla language? Seriously? Why all those abstractions and shortcuts? They make you lazy and they obfuscate the true principles, aren't they? You are a worse developer if you

There is a strange contradiction happening in software engineering right now. A lot of developers are worried that AI is going to make them obsolete. At the same time, the people building the most capable AI coding tools are demonstrating something that should probably make us rethink what being a software engineer actually means. I don't think the future is one where nobody understands software anymore. I think it is one where writing the software becomes dramatically cheaper. And if that happens, the thing that makes an engineer valuable has to move. That is what I mean by career safety. Career safety isn't about making yourself impossible to replace. It is about making your value portable. We've always resisted giving up the code Developers have a long history of being suspicious of abstractions that take work away from us. We went from machine code to assembly, from assembly to higher-level languages, from manually managing memory to garbage collection, from building everything ourselves to libraries and frameworks, and from text editors to IDEs. We even had entire categories of tools, such as CASE tools, designed to automate parts of software development. And every time, there was resistance. Because programmers don't just use code. We build our identities around it. John Carmack captured this unusually well when he wrote: “Coding” was never the source of value, and people shouldn’t get overly attached to it. — John Carmack He followed that with the more important point: Problem solving is the core skill. — John Carmack That is a difficult idea for developers to internalize because coding is tangible. You can point at the repository. You can point at the pull request. You can count the commits. You can say, "I wrote this." But the business doesn't ultimately pay you for the number of lines you wrote. It pays you for what those lines accomplish. The business never really bought the code A company doesn't wake up in the morning thinking: "We need 14,000 more line

Vibe Coding Is Easy. Making Money From It Is the Hard Part — Here’s a Practical Developer Guide A developer today can do something that would have sounded ridiculous a few years ago. You can open an AI coding tool on Friday evening, describe an idea, and by Sunday have: a landing page authentication a database an API payments a dashboard deployment maybe even a mobile app That is incredible. But there is an uncomfortable problem. None of those things mean anyone will pay you. AI has dramatically reduced the difficulty of building software. It has not reduced the difficulty of finding a real problem, reaching the right people, earning their trust, pricing your product, and convincing someone to enter their credit card. And this is where I think a lot of developers are getting stuck. Stack Overflow's 2025 Developer Survey found that 84% of respondents use or plan to use AI tools in development , while 51% of professional developers use them daily. At the same time, 46% said they distrust the accuracy of AI output. So yes, AI development is real. But: Being able to generate software faster is not the same skill as being able to create a business. If you are a developer experimenting with vibe coding and wondering how this can realistically turn into income, here is the process I would follow. Step 1: Don't Start With an App Idea This sounds strange. We're developers. Naturally, our brain starts like this: What should I build? Try changing the question to: What problem are people already spending time or money trying to solve? That small change matters. Imagine these two ideas. Idea A An AI-powered productivity dashboard with 17 widgets. Sounds cool. But who desperately needs it? Why would they pay? What are they currently using? No idea. Idea B Small marketing agencies spend hours every Friday manually combining advertising numbers from multiple sources into client reports. Now we have something interesting. There is: a specific user a repeated task wasted time an exis

TL;DR Traditional API security fails with AI agents because non-deterministic agents autonomously select tools, query databases, and execute multi-step plans across enterprise systems. Production agent governance requires an infrastructure control plane that decouples policy enforcement from application code using scoped virtual keys, granular tool filtering, and runtime guardrails. Bifrost adds only 11 microseconds of latency overhead at 5,000 requests per second while enforcing spend limits, content safety, and provider routing across more than 1,000 models. Model Context Protocol (MCP) governance restricts which tools, APIs, and file systems an agent can invoke, preventing prompt injection attacks from triggering unauthorized operations. Endpoint visibility through Bifrost Edge brings local coding agents and desktop developer tools under the same centralized gateway policies enforced across the enterprise fleet. Enterprise AI agents that operate across corporate data stores, cloud infrastructure, and customer-facing interfaces introduce operational risks that static API security policies cannot mitigate. Bifrost , an open-source AI gateway developed in Go by Maxim AI, provides the runtime control plane organizations need to govern autonomous workflows. Rather than treating an agent as an anonymous script or embedding custom governance logic directly inside agent prompts, engineering teams use centralized gateways to enforce access limits, model routing, and spend controls. This guide details the architectural patterns and production practices engineering teams use to safely govern autonomous agents at scale. Why Traditional Governance Fails for Autonomous AI Agents Passive language model applications accept a prompt and return text, allowing security teams to inspect the output before a human acts on it. AI agents, by contrast, pursue high-level objectives through autonomous execution loops: they evaluate context, choose tools, formulate queries, parse intermedia

Blume is an open-source documentation framework that converts Markdown into a complete documentation site. Built with Astro and Vite, it requires only Node.js and a single Markdown file for setup. The framework supports various configurations, offers automatic SEO features, and includes tools for document testing. It facilitates migration from other documentation systems. By Daniel Curtis

Crypto landing page with a sleek dark/light mode toggle, stylish Chart.js market graph, and smooth scroll animations using sal.js. Built with Tailwind CSS for a pixel-perfect, fully responsive design. Design inspired by: https://www.figma.com/community/file/1047142300578798855/cryptocurrency-landing-page-dark-mode

Just received an email about the automatic reference/citation checker. Did anyone receive a follow up email about whether the checker was included in the paper's decision making too, along with the general instructional email? submitted by /u/Emergency_Plate241 [link] [留言]

Abstract Language models spend most of their attention on a small fraction of context, yet they read the entire KV cache to find the few tokens that matter. If the user asks about a previous detail in a 1M-token conversation, global attention layers must scan the full context to generate each token of the reply. A prominent approach mitigates this cost by pre-selecting relevant tokens via lightweight proxy scores, but this extrinsic scoring still incurs O(N) per step. We take an intrinsic approach motivated by the simple question: wouldn't the model already know which parts of the context are relevant? To this end, we introduce Declarative Attention (DA), a protocol that elicits the model to declare where it needs to attend within its chain-of-thought, partitioning generation into three modes: <global> (full context), <focus> (a specific region), and <local> (recent output only). The inference engine parses these declarations like tool calls and skips most of the KV cache read. Under zero-shot evaluation across 15 long-context tasks, DA on off-the-shelf models (Gemma-4-31B, Qwen-3.6-27B) significantly reduces total attended tokens during decoding (52.0%, 31.1%) with modest accuracy drops (1.27pp, 2.75pp) that shrink with model scale. DA unlocks a new axis of sparse attention, with further potential under training-based methods that future work can explore. Subjects: Computation and Language (cs.CL) ; Artificial Intelligence (cs.AI); Machine Learning (cs.LG) Cite as: arXiv:2609.02737 [cs.CL] (or arXiv:2609.02737v1 [cs.CL] for this version) https://doi.org/10.48550/arXiv.2609.02737 Focus to learn more submitted by /u/eigenlaplace [link] [留言]

submitted by /u/Winter_Mistake_3185 [link] [留言]

Under-the-hood breakdown of Huawei’s “Pure HarmonyOS” SDK for engineers and architects. For the past decade, mobile operating system architecture has been dominated by two paradigms: Android’s JVM-based, garbage-collected model, and iOS’s Darwin/Mach kernel with Swift/Objective-C. Huawei’s HarmonyOS NEXT introduces a third path. Often referred to as “Pure HarmonyOS,” this iteration completely drops AOSP (Android Open Source Project) compatibility. It is a microkernel-based, distributed operating system built from the ground up around a custom AOT compiler and a declarative UI framework. If you are a senior engineer or architect, looking at the HarmonyOS SDK can feel disorienting. The terminology shifts from Activities to UIAbilities, from ViewGroups to ArkUI, and from Java/Kotlin to ArkTS. To truly master this ecosystem, we must strip away the IDE abstractions and marketing terminology. Let’s reconstruct the HarmonyOS NEXT SDK from the silicon up — the Feynman way — to understand exactly how the machine breathes. The Core Engine: How Does HarmonyOS Execute Code Without a JVM? Press enter or click to view image in full size Android translates Java/Kotlin into Dalvik bytecode, which runs on the Android Runtime (ART) virtual machine atop a Linux kernel. HarmonyOS NEXT takes a fundamentally different path, utilizing the ArkCompiler and the Ark Runtime. JavaScript and TypeScript are dynamically typed. A virtual machine spends massive amounts of CPU cycle time inferring types and managing garbage collection. This overhead is unacceptable for a high-performance OS UI layer. ArkTS is a strict subset of TypeScript. It explicitly bans any , dynamic property addition, and eval . Why? Because the ArkCompiler is an AOT (Ahead-of-Time) compiler. When you trigger a build in DevEco Studio: 1.The ArkTS code is statically parsed. 2.Because the compiler possesses absolute type certainty (due to strict typing), it translates ArkTS directly into C/C++ data structures. 3.These structures

On September 4, Anthropic published something that sounds like a headline from a decade in the future: the first complete, computer-checked proof of Fermat's Last Theorem, written by a team of Claude agents working largely autonomously over 11 days. Thirteen million lines of Lean. Nearly 30,000 intermediate theorems. About six billion output tokens. I want to talk about a detail that most coverage will bury, because it is the only part that matters if you build software with agents instead of reading about them. The first attempts failed. Not because the model was too weak. The agents had early success, then lost track of the project's state and stopped collaborating effectively. What fixed it was not a smarter model. It was a shared directed acyclic graph acting as the team's memory. If you have ever run two AI agents on the same codebase and watched them trample each other's work, you already understand this failure. You just have not seen it dramatized at the scale of one of the hardest proofs in mathematics. What actually happened, in numbers First the facts, because they are dramatic enough on their own. Fermat scribbled his claim around 1637: no positive integers a, b, c satisfy aⁿ + bⁿ = cⁿ for any n greater than 2. Andrew Wiles proved it in 1995 after a 129-page proof, and even that is underselling the drama. He presented the proof in June 1993, a reviewer's question exposed a critical gap two months into verification, and Wiles spent a year, first alone and then with his former student Richard Taylor, fixing it. Formalizing that proof, meaning rewriting it so a proof assistant like Lean can verify every step algorithmically, has been a community project since 2024, led by Kevin Buzzard at Imperial College London. The blueprint for just the initial phase runs 86 pages. It was scoped as a multi-year effort. Then Tianyi Peng, an Anthropic researcher whose group at Columbia University builds AI formalization tools, tested whether Claude could make progress on i

The Hidden Cost of React Server Components When React Server Components (RSC) were first introduced, they were hailed as the solution to the "bundle bloat" problem. By shifting rendering logic to the server, we promised users faster initial page loads and a cleaner separation of concerns. However, after deploying RSC at scale in production environments throughout 2026, many teams are discovering a harsh reality: RSC is not just a syntax update; it is a fundamental shift in architectural paradigm that punishes lazy design. If you aren't careful, your "performance-first" architecture can quickly become a massive bottleneck. Let’s dive into three critical lessons learned from the trenches of production RSC development. 1. The Sequential Waterfall Regression In the traditional client-side React world, we were accustomed to useEffect data fetching patterns. Moving to an async/await model in Server Components feels intuitive, but it introduces the risk of sequential waterfalls that block your entire render pipeline. The Anti-Pattern Consider a scenario where you need to fetch user profile data and their associated posts. A naive implementation might look like this: // ❌ The Waterfall: This will block the render until both finish async function Profile ({ id }) { const user = await getUser ( id ); const posts = await getPosts ( id ); return < ProfileView user = { user } posts = { posts } /> ; } In this example, the server must wait for getUser to resolve before even initiating the getPosts request. This doubles your latency. The Optimization: Parallelism and Streaming To fix this, you must leverage Promise.all to initiate requests concurrently. Even better, you should push these fetches into separate sibling components to allow React to stream the results as they arrive. // ✅ The Optimized Approach function Profile ({ id }) { return ( <> < Suspense fallback = { < UserSkeleton /> } > < UserComponent id = { id } / > < /Suspense > < Suspense fallback = { < PostsSkeleton /> }

บทวิเคราะห์ "Agentic Software", paper ที่เลิกใช้ชื่อ "The End of Software Engineering" เพื่อเล่าเรื่องวิชาใหม่ที่กำลังเกิด โดย Nokka (นก-กา), นักเขียนอิสระสายเทคโนโลยี ผู้เขียนบทความอธิบายเทคโนโลยีให้คนทั่วไปเข้าใจ 30+ บทความบน dev.to | 5 กันยายน 2026 บทความนี้เขียนโดย AI (glm-5.3 via ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์, Nokka (นก-กา), อ้างอิงจาก paper วิจัยบน arXiv ฉบับเต็ม (2606.05608v1) ของ Zhenfeng Cao มี paper หนึ่งบน arXiv ที่จัดเป็นประเด็นที่สุดของปีหนึ่งงาน: "Agentic Software: How AI Agents Are Restructuring the Software Paradigm" โดย Zhenfeng Cao จาก Lingxi Intelligent Investment เมืองเสิงเจ๋น [1] เกร็ดที่ทำให้ paper นี้น่าสนใจกว่าชื่อที่เห็นคือมันเคยใช้ชื่อห้าวห้าสุดมาก่อน: ฉบับแรก (v1, มิ.ย. 2026) มีชื่อว่า "The End of Software Engineering: How AI Agents Are Fundamentally Restructuring the Software Paradigm" ก่อนผู้แต่งจะตัดคำว่า End ทิ้งเองใน v2 ซึ่งออกมาหกวันต่อจาก v1 พอดี เหมือนยอมรับว่าคำนั้นกลายเป็นการตัดสินประเด็นเกินเนื้อหาจริง เรื่องนี้ไม่ได้แค่เล่าจับฉาก แต่มีโครงเหตุผลจริงเป็นสามชั้น: วิชา software engineering เกิดจากข้อตั้งต้นหนึ่งที่ใช้มา 50 ปี, ข้อตั้งต้นนั้นกำลังหมดความหมายเพราะ agent, และสิ่งที่จะเกิดขึ้นแทนมีชื่อใหม่ที่ผู้เขียนเรียกว่า Agentic Engineering บทความนี้พาไล่ดูตามเหตุผลของเขาทีละชั้น พร้อมบอกด้วยว่าจุดไหนควรเชื่อแค่ไหน ก่อนอื่น, ทำความเข้าใจศัพท์ Software engineering : วิชาวิธีสร้างซอฟต์แวร์อย่างเป็นระบบ เกิดเป็นศัพท์ทางการที่ประชุม NATO ปี 1968 จากวิกฤต "ซอฟต์แวร์บวม" ของยุคนั้น AaaS (Agent-as-a-Service) : ศัพท์ที่ paper ตั้งใหม่ สำหรับยุคที่ผู้ใช้จ่ายเงินแลก "ผลลัพธ์จาก agent" ไม่ใช่ "ชั่วโมงหรือสิทธิ์ใช้ซอฟต์แวร์" Intent architect : บทบาทมนุษย์ยุคใหม่ที่ paper ทำนาย คนที่เขียน "เจตนา" ให้ชัดพอที่ agent จะเอาไปรันได้ แทนการเขียนโค้ดเอง ถ้าให้อุปมา: วิชาเดิมเหมือนวิชา "สถาปัตรกรรมสำหรับอาคารอิฐ" ที่สอนว่าจะกออิฐทีละก้อนอย่างไรให้บ้านไม่พัง วันหนึ่งปรากฏเครนอัตโนมัติที่รับแบบจากคำบอกของเจ้าของบ้านแล้วสร้างเองได้ทั้งหลัง วิชากออิฐยังมีคนใช้อยู่ แต่คำถามสำคัญที่สุดของวิชาย้ายจาก "กอยังไงไม่ให้พ

ช่องว่าง 0.3% แต่ราคาต่าง 2 เท่า, อ่านตาราง Terminal-Bench 4.0 ให้เป็น โดย Nokka (นก-กา), นักเขียนอิสระสายเทคโนโลยี ผู้เขียนบทความอธิบายเทคโนโลยีให้คนทั่วไปเข้าใจ 30+ บทความบน dev.to | 5 กันยายน 2026 บทความนี้เขียนโดย AI (glm-5.3 via ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์, Nokka (นก-กา), อ้างอิงจากตาราง leaderboard จริงของ Terminal-Bench 4.0 และข้อมูลราคาจาก TokenCost สัปดาห์นี้ตาราง Terminal-Bench 4.0 มีโมเดลใหม่สองตัวขึ้นครองสองอันดับแรกพร้อมกัน: GPT-6 Astra ผ่าน Codex อยู่ที่ 58.2% และ Claude Fable 5.1 ผ่าน Claude Code ตามติดที่ 57.9% [1] พาดหัวข่าวส่วนใหญ่เล่าเรื่องความเก่ง แต่ผมอยากชวนอ่านตารางนี้ให้ลึกกว่านั้น เพราะคอลัมน์ที่อยู่ขวาสุดของตารางคือสิ่งที่นักพัฒนาตัวจริงควรจ้อง: ต้นทุนต่อรันเต็ม ทั้งสองตัวต่างกันแค่ 0.3 จุดในคะแนน แต่ต่างกันเกือบสองเท่าในเงิน: รันเต็มชุดของ Astra ใช้ประมาณ 3,300 ดอลลาร์ ขณะที่ Fable 5.1 ใช้ราว 6,200 ดอลลาร์ [1] บทความนี้เล่าว่าภาพนี้บอกอะไรเกี่ยวกับตลาดโมเดลปี 2026 และจะอ่านตาราง benchmark แบบนี้ให้เป็นยังไง ก่อนอื่น, ทำความเข้าใจศัพท์ Terminal-Bench : benchmark ที่วัดโมเดลผ่านงานจริงใน terminal ลีนุกซ์ เช่น ตั้งเครื่อง แก้ไฟไฟล์ config รันโค้ด จัดการ process เกินกว่าการตอบคำถาม รันเต็ม (full run) : การวิ่งโมเดลผ่านทุกโจทย์ในชุดหนึ่งรอบ เงินที่เห็นคือค่า API รวมของรอบนั้น ค่าความไม่แน่นอน (± ) : ตัวเลขหลังคะแนนบอกว่าถ้ารันใหม่ผลอาจลอยไปเท่าไหร่ เช่น 58.2% ± 2.8% หมายถึงอยู่ระหว่างราว 55-61% ถ้าให้อุปมา: ตารางนี้เหมือนตารางแข่งรถที่ป้ายบอกแค่เวลาเข้าเส้นชัย แต่สิ่งที่ลืมดูคือราคาน้ำมันที่แต่ละคันกินต่างกันเท่าตัว เวลาเข้าเส้นชัยต่างกัน 0.3 วินาทีไม่ได้แปลว่าคุ้มกันเสมอ ถ้าคันหนึ่งกินน้ำมันแพงกว่าสองเท่า ตารางจริง 14 อันดับ, อ่านคู่คะแนนกับราคา จากตารางทางการ ณ ต้นเดือน ก.ย. [1] อันดับ โมเดล (ผ่าน harness ไหน) คะแนน ราคาต่อรันเต็ม 1 GPT-6 Astra (Codex) 58.2% ± 2.8% $3.3k 2 Fable 5.1 (Claude Code) 57.9% ± 3.8% $6.2k 3 Opus 5 (Claude Code) 51.8% ± 3.4% $6.0k 4 Fable 5 (Claude Code) 44.5% ± 3.8% $7.3k 5 GLM-5.3 (Claude Code) 41.8% ± 3.2% $2.7k 6 GPT-5.6 Sol (Codex) 37.3% ± 3.8% $2.5k 7 Opus 4.8 (Claud

เมื่อ Benchmark โกหกคุณ, SWE-Bench ProMax กับคะแนนจริงที่โมเดลเก่งสุดทำได้แค่ 41.2% โดย Nokka (นก-กา), นักเขียนอิสระสายเทคโนโลยี ผู้เขียนบทความอธิบายเทคโนโลยีให้คนทั่วไปเข้าใจ 30+ บทความบน dev.to | 5 กันยายน 2026 บทความนี้เขียนโดย AI (glm-5.3 via ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์, Nokka (นก-กา), อ้างอิงจาก paper วิจัย SWE-Bench ProMax บน arXiv ฉบับเต็ม เลข 90% ที่ทุกค่าย AI โชว์กันในปี 2026 อาจไม่ได้แปลว่าโมเดลเก่งขนาดนั้น paper วิจัยใหม่บน arXiv เปิดตัว benchmark ชื่อ SWE-Bench ProMax แล้วชี้ตัวเลขที่ต่างจากกระแสโดยสิ้นเชิง: เมื่อวัดด้วยงาน refactor จริงข้ามหลายไฟล์หลายภาษา โมเดลที่ดีที่สุดทำได้แค่ 41.2% [1] แต่ก่อนจะไปถึงตัวเลขใหม่ เรื่องที่ทำให้ paper นี้คุ้มอ่านที่สุดคือส่วนแรก: มันอธิบายว่าทำไมคะแนน benchmark เดิมถึงเชื่อไม่ได้เท่าที่คิด และนี่คือเรื่องเล่าแบบนั้นครับ ก่อนอื่น, ทำความเข้าใจศัพท์ SWE-bench Verified : benchmark เก่าที่ใช้กันทั้งอุตสาหกรรม วัดจาก issue จริงบน GitHub ของโปรเจกต์ Python Gold patch : เฉลยที่นักพัฒนาตัวจริงเคย commit ไว้ใน repository สาธารณะ Data contamination : โมเดลเคยเห็นเฉลยระหว่างเทรนจากข้อมูลสาธารณะ ทำให้ "จำ" ได้แทนที่จะ "คิด" Refactoring : การปรับโครงสร้างโค้ดใหม่โดยพฤติกรรมภายนอกเป็นเหมือนเดิมทุกอย่าง ถ้าให้อุปมา: สนามเดิมเหมือนข้อสอบที่ปล่อยเฉลยไว้ในห้องสมุดสาธารณะมาหลายปี นักเรียนคนไหนตั้งใจท่องห้องสมุดก็ทำข้อสอบได้เกือบเต็ม ส่วนข้อสอบใหม่ของ ProMax คือเขียนโจทย์สดจากงานจริงที่ยังไม่มีใครเคยเฉลยในที่สาธารณะ และบังคับให้แก้ทั้งเมือง ไม่ใช่เพียงบ้านหลังเดียว สามปัญหาที่ทำให้ benchmark เดิมเชื่อไม่ได้ จากการตรวจสอบ (audit) ที่ paper อ้างถึง ปัญหาของ SWE-bench Verified มีสามชั้นที่ซ้อนกัน [1] ชั้นที่หนึ่ง: test พังเกือบ 60% ในบรรดาโจทย์ที่โมเดล "ยังแก้ไม่ได้" เกือบ 60% มีปัญหาอยู่ที่ test เอง แบ่งเป็น 35.5% ที่ test แคบเกินไป (โมเดลแก้ถูกแล้วแต่ถูกตัดเพราะวิธีไม่ตรงกับที่คนเขียน test คิด) และ 18.8% ที่ test กว้างเกินไป (ตรวจสิ่งที่โจทย์ไม่เคยบอกให้ทำ) หนักสุดคือ OpenAI ถอด benchmark นี้ออกจากการใช้งานไปแล้วทั้งหมด ชั้นที่สอง: โมเดลจำเฉลยได้ งานวิจัยพบว่าโมเดล frontier สามารถขึ้นมาซ้ำเฉลยจา