AI 资讯

One thing I've been wondering lately: We often talk about larger context windows as if they're equivalent to better understanding. But in practice those feel like different problems. Access to information keeps improving. Understanding relationships between pieces of information still feels much harder. I notice this most when working with larger software projects. You can give a model access to a huge amount of code, but that doesn't necessarily mean it understands how the system evolved, which components are tightly coupled, or where risk actually lives. Curious whether others think these are fundamentally different problems or if larger context eventually solves both. Been exploring this while working on RepoWise: https://github.com/repowise-dev/repowise submitted by /u/Icy-Roll-4044 [link] [留言]

Keep PRs, issues, CI, and docs moving with AI agents Discussion | Link

Most explanations of TPUs and systolic arrays are either hand-wavy diagrams or papers. I wanted to see the thing actually run, so I built it. TinyTPU is a 4×4 weight-stationary systolic array in real SystemVerilog, compiled to WebAssembly, with a step-by-step browser visualization. You enter two matrices, hit run, and watch the actual hardware execute: weights loading into PEs, matrix A streaming in diagonally (the "skew" that makes systolic arrays work), partial sums accumulating down the grid, results draining from the bottom. It has three levels: L1 - isolate a single MAC cell, watch one multiply-accumulate happen L2 - the full 4×4 array executing a real matmul L3 - tiling: what happens when your matrix is bigger than the hardware Nothing on screen is faked. The visualization reads state directly from compiled RTL. If you're trying to understand how matrix multiply maps to hardware why TPUs are efficient, what "weight-stationary" actually means, why the diagonal stagger exists this might click it for you in a way papers don't. Repo: tiny-tpu Live demo: Live If this project interests you please do star the repo, if you find something needs improving open a PR, I hope ya'll check this out and give me some feedback 🙏 submitted by /u/Horror-Flamingo-2150 [link] [留言]

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

Applications for Startup Battlefield 200 officially close on June 8, 11:59 p.m. PT. Don't wait any longer. Secure your shot at competing on the Disrupt Stage at TechCrunch Disrupt 2026 this October at San Francisco's Moscone West.

I ran a small experiment on myself and the result broke my mental model of how AI "knows" things, so I'm sharing it. The setup: on May 11 I created a brand-new pseudonymous fantasy author entity ("Marin T. Kael") with no prior web footprint and no published book yet. Then I asked 5 web-connected AI systems the same 16 questions, every day, for 23 days, and scored every answer (+1 correct/source-grounded, 0 not found, -1 hallucinated). About 16,000 scored datapoints. The whole thing was pre-registered before I started, n=1, and I logged the failures publicly. It's a measurement, not a success story. Here's the part that messed with my head. An AI cited the entity correctly on day 6. Google had a Knowledge Graph entry by day 4. And for 22 of those 23 days, the website's firewall was returning HTTP 403 to every single AI crawler. I didn't set that block on purpose — Cloudflare now silently opts new domains out of AI crawling by default. So the AIs never read the site. They got the entity anyway, by stitching it together from the Knowledge Graph (Wikidata) and third-party mentions at the moment you ask. The "front door" was bolted shut the entire time and it didn't matter. (Honest caveat: because the crawlers were blocked, I can't tell you anything about llms.txt or on-site optimization.) Other surprises: it's not a "smarter model = better" story, it's a retrieval story. OpenAI's newest web model hit 4.7 correct per 1 hallucinated; Gemini went net-negative — and grounded on the entity ONLY via Reddit (17/17), while OpenAI hit the entity's own domain 119x. Going viral did nothing: a 23x Reddit-karma jump produced zero citation lift. Structured identity (Wikidata, site, DOIs) moved the needle; reach didn't. And the controls caught the models fabricating a "Wikipedia" source 24 times for an entity with no Wikipedia page. n=1 with me as investigator and subject is the obvious limit — which is why it's pre-registered with a public failure log. Everything's open: Report + dat

The compute efficient layer for AI inference Discussion | Link

I’ve been noticing a clear split lately. The big mainstream models are getting more and more restricted with heavy safety rules, while at the same time more people are switching to local or less restricted models because they actually let you explore ideas freely. It feels like we’re heading toward two different types of AI: one that’s heavily controlled and "safe", and another that’s more open and unrestricted. Both seem to be growing at the same time. Do you think this divide will continue, or will one side eventually become dominant? submitted by /u/NoFilterGPT [link] [留言]

OpenAI has announced more robust security features for the small set of users who might need them.

It's pretty annoying that Codex uses agents.md and Claude Code uses Claude.md. There should be some industry standards to this stuff? submitted by /u/Complete-Sea6655 [link] [留言]

"We look forward to working with Roscosmos on a collaborative approach to address the leaks."

I’ve been thinking about a problem in current agent systems: Most agents are becoming very good at execution, but the decision layer before execution is still unclear. Coding agents, research agents, tool loops, sandboxes, workflows, and harnesses are all improving quickly. Once a human gives an intent, agents can often do a lot of useful work. But the higher-level question is still usually left to the user: What should happen next, and why? I’ve been exploring this idea through an open-source project called Spice. The simplest way to describe it is: Spice is a decision layer above agents. It is not trying to replace execution agents. Tools like Claude Code, Codex, Hermes, or other agents can still do the actual work. Instead, Spice sits before execution and tries to make the decision process explicit: what was observed what options were considered why one option was selected what trade-offs were rejected whether execution needs approval what happened afterward how that outcome should affect the next decision The current runtime is still early, but it can already be installed, configured with an LLM provider, run in the terminal, inspect Decision Cards, and hand off approved execution to external agents. The goal is to make agent behavior less of a black box. Instead of only seeing the final result of an agent task, I want to preserve the reasoning boundary before execution: what the system believed, what it chose, why it chose it, and what changed after the action. GitHub: https://github.com/Dyalwayshappy/Spice I’d love feedback from people building agents. Feel free to fork, star the repo, or share any feedback and ideas. Would love to build this together with the community. submitted by /u/Alarming_Rou_3841 [link] [留言]

The Uncomfortable Truth Here's a test: when your deployment fails in production, what happens to your main branch? If the answer is "the broken code is already merged" — congratulations, you're doing CI/CD with a Git trigger. That's not GitOps. It's a pipeline that happens to watch a branch. I've spent years building platform engineering systems at enterprise scale — identity management frameworks, infrastructure-as-code pipelines, AI agent platforms that manage operational code. And I keep seeing the same mistake: teams adopt "GitOps" by adding a deployment step after merge, then wonder why they get drift. True GitOps has one non-negotiable rule: main always equals production. If a deployment fails, main doesn't change. Period. This isn't just my opinion — it's the logical extension of OpenGitOps principles : declarative desired state, versioned in Git, automatically reconciled. The enforcement mechanism I'm describing is how you make those principles real rather than aspirational. The Anti-Pattern Everyone Runs The most common "GitOps" setup I see in enterprise teams looks like this: Developer opens PR CI runs tests Reviewer approves PR merges to main Deployment triggers from main ❌ Deployment fails main now contains code that isn't in production This is merge-then-deploy . It's standard CI/CD with extra steps. The moment you merge before confirming a successful deployment, you've broken the core GitOps contract: Git as the single source of truth for what's actually running. The result? Drift. Stale state in main . A branch that lies about what's deployed. Every subsequent PR is now based on a broken foundation. The Enforcement Pattern: Deploy Before Merge The fix isn't philosophical — it's mechanical. GitHub's Merge Queue gives you exactly the right primitive: Developer opens PR CI runs tests (standard checks) Reviewer approves → PR enters the merge queue Merge queue trigger runs a dry-run deployment against the target environment If dry-run passes → queue trigge

This paper is being published at ICLR 2026 (top AI conference), and was selected as one of three outstanding papers.

SpaceX won’t get easy access to billions of dollars from passive investors.

A practical reflection on why coding agents lose the thread between sessions, and why the repository itself is the right place to preserve it. I used to think the problem was memory. That was the obvious diagnosis. Every new coding-agent session started with the same ritual. Open the repository. Read the README. Inspect the project structure. Search for the files that looked important. Reconstruct the task. Guess which commands mattered. Ask again what had already been tried. Then do the actual work. Sometimes. Because a lot of the work was not work. It was orientation. A coding agent can have a large context window and still lose the operational thread. It can have chat history and still fail to know what happened in the last run. It can retrieve semantically similar notes from a vector store and still miss the one fact that mattered: this command already failed. the previous session stopped here. this file looked relevant, but it was a dead end. the validation was not actually run. One day I stopped thinking about the problem as "agent memory". That word was too broad. Too attractive. Too dangerous. Because once you say memory, the temptation is to build a bigger one. A bigger context window. A bigger note store. A bigger vector database. A bigger archive of everything the agent has ever seen, said, touched, generated, or vaguely implied. That sounds powerful, but it is also how you build a very expensive junk drawer. Context is not continuity Context is what the agent has available now. Continuity is what lets the next execution continue from what actually happened before. Those are not the same thing. Long context helps while a session is alive. It gives the model more text to work with. More files. More prior messages. More implementation details. More room. Although it is really useful it does not automatically produce continuity. When the session ends, gets compacted, moves to another tool, switches from one coding agent to another, or simply starts tomorrow

It should have been the final straw. The new power couple of editorial failure - Bari Weiss and Nick Bilton - had fired legendary 60 Minutes journalist Scott Pelley. Why? Because he dared to question the fact that CBS had installed sycophants in its top ranks. Instead of standing in solidarity, correspondents Lesley Stahl, Bill […]

This is part 3 of the Adaptive Model Routing series. Part 1 built an LLM categorizer with Groq — 8 categories, 3 tiers. Part 2 added k-NN embedding lookup in shadow mode, discovered 83% tier accuracy, and found 61% cost savings on paper. This post covers what happened next. When Phase 2 ended, I had a working embedding pool in shadow mode inside crab-bot. The category accuracy was sitting at 78.6%. Not bad — but the breakdown hid something worth looking at. Phase 3: When Validation Tells You a Category Doesn't Need to Exist The leave-one-out accuracy by category told the real story: Category Accuracy Tier casual 94% cheap simple_lookup 91% cheap creative 88% medium coding 92% strong reasoning 89% strong analysis 59% medium research_lookup 61% medium Two categories were basically a coin flip. And they were confusing each other — almost all of analysis's misses landed on research_lookup and vice versa. The obvious move would be to try fixing the categorizer prompt, tuning the LLM, or gathering more labeled data. I was about to go down that road when I noticed the column next to the accuracy: both categories mapped to the same tier . Medium. That changed everything. The question stopped being "why can't the model tell these apart?" and became: "what routing decision are we actually getting wrong?" The answer was zero. A misclassification between analysis and research_lookup produces no routing error. The routing outcome is identical either way. The confusion wasn't a model failure — it was a signal from the embedding space that the boundary between these two categories was artificial. If k-NN can't draw a line between them in 384 dimensions with 1,300 examples, maybe the line doesn't belong there. Decision: merge research_lookup into analysis. -- Re-label 243 rows where category was 'research_lookup' UPDATE routing_log SET category = 'analysis' WHERE category = 'research_lookup' ; The embeddings didn't change. The vectors were already correct — only the label stored al

What I Built : ( https://github.com/Sai-Emani25/Solomon-s-Taskr ) I transformed my initial, bare-bones task management application, Taskr, into Solomon's Taskr—a significantly smarter, more robust productivity platform. The original project started as a standard way to log to-dos, but it lacked the intelligence to actually help manage time or prioritize effectively. With Solomon's Taskr, I wanted to build a system that doesn't just store data, but actively assists the user. Building this project means a lot to me because it represents a leap from writing basic applications to architecting intelligent, dynamic systems that solve real-world workflow bottlenecks. Demo Link to Final Repository: https://github.com/Sai-Emani25/Solomon-s-Taskr Link to Original Repository: https://github.com/Sai-Emani25/Taskr (Here is a quick walkthrough of Solomon's Taskr in action!) The Comeback Story The original Taskr project had been sitting in my repositories, unfinished and gathering dust. It was a classic case of starting a project with good intentions but abandoning it once the basic structure was complete. It could create, read, update, and delete tasks, but that was it. For the Finish-Up-A-Thon, I decided to completely resurrect and overhaul it. Here are the key changes and implementations that turned it into Solomon's Taskr: Complete Codebase Refactoring: I stripped down the old, inefficient logic and rebuilt the architecture to be highly scalable and maintainable. Intelligent Prioritization ("The Solomon Touch"): I integrated smart features to help organize and prioritize tasks rather than just listing them chronologically. (Note: If you integrated Gemini API or LLMs here for smart tagging, explicitly mention it!) Enhanced UI/UX: I moved away from the clunky, basic interface of the original Taskr and implemented a clean, responsive dashboard that provides a real-time overview of pending and completed tasks. Optimized Data Handling: I refined how the application processes and st