AI 资讯

Over the past week, a new fanworks movement has kicked off, with the aim to root out authors using generative AI. But the detection methods being implemented are questionable, and any fanfic writer could be caught in the crossfire. Broad distaste around the use of Claude, ChatGPT, and other AI tools has long been a […]

Midjourney is asking the court to get Disney, Warner Bros. and Universal to submit information on their AI use.

Disturbances in this critical sense are often linked to problems with brain health.

Biology could explain the find, but there are other potential explanations.

I've been trying to come up with a solution for keeping extremely long ai sessions coherent. Sometimes there is too much substance to risk compaction. With so much buzz around diffusion going on it got me thinking, what if we treat the context like a progressive render, blurry>sharp. The practical way to make text "blurry" is compression. This is a "diffusion inspired" system which borrows the coarse-to-fine process, not the formal math. It uses semantic compression so the overall structure of the session stays intact. Read the compressed version first to build an outline. Then read progressively less compressed slices until you're reading small verbatim chunks that give full detail. So you're basically using compression as noise on the input side, then progressively building an output. Each slice is compressed to fit within the context window, so the model only ever needs to read the current slice+input+current output. Tell the model what pass it's on, so it knows whether to write an outline or add detail. The thing I'm actually trying to preserve is what you'd call "non-local information". Think of it as stuff that surfaces when looking at the whole session & doesn't survive fragmented retrieval. Retrieval misses it, compaction deletes it. Both miss what only exists in a holistic view. Here is a visual demonstration to get a general idea of the workflow. https://dev-boz.github.io/diffusive-semantic-compression/demo/architecture-demo.html There is substantial overlap with lots of prior art, Recursive Language Models is one of the closest (source and output on disk, process recursively). I wrote most of this before I found RLM and nearly gave up before realising there was still a small part that was novel. As far as I can tell there's no exact match for this particular implementation. Please let me know if I've missed one. The difference to regular masked diffusion is in changing the length of the input rather than just masking. What seems to be new ground is using

Plus: Alleged Scattered Spider hacking member extradited, dozens of license plate reader errors, and Indian officials are concerned about WhatsApp’s username rollout.

Book: Observability for LLM Applications — Tracing, Evals, and Shipping AI You Can Trust Also by me: Agents in Production — the companion book in The AI Engineer's Library (2-book series) My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools Me: xgabriel.com | GitHub Your triage agent has been in production for three months. The traces look clean. Every span is green, every run terminates, the p95 latency is flat, the token bill is boring. Then support forwards you a screenshot: the agent routed a billing refund to the security queue. You pull the trajectory. Nothing is broken. The agent called a reasonable tool with reasonable arguments, got a reasonable result, and picked the wrong queue with total confidence. That is silent drift. The trace shows you what the agent did. It does not tell you whether what it did was any good. Between a model provider's minor version bump, a prompt tweak someone shipped on Tuesday, and the slow shift in your incoming traffic, the quality of your agent's decisions moves. It rarely announces itself with an error. It shows up as a support ticket, then a second one, then a churned account. You catch it the same way you catch a memory leak: with a baseline and an alarm, not by staring at dashboards. Decision quality is a distribution, not a number The failing traces in Chapter 12 of Agents in Production are the easy case. Twenty retries of the same empty search is visibly wrong. You see the loop count in the invoke_agent parent and you know. Most quality regressions are not visible in a single trace. They show up only when you look at the distribution of decisions across thousands of runs. So the first thing to instrument is the decision itself. If you followed the tracing chapter you already emit a small fixed vocabulary per chat span: span . set_attribute ( " gen_ai.agent.step " , 3 ) span . set_attribute ( " gen_ai.agent.decision " , " call_tool " ) span . set_attribute ( " gen_ai.

I didn’t set out to become a systems architect. In fact, I didn’t even know that’s what I was becoming. There was no grand plan, no formal training, no moment where someone handed me a title. It happened the same way most systems failures happen: slowly, then all at once. What I did have was a habit. Whenever something broke — a workflow, a process, a piece of software, an organisation — I couldn’t leave it alone. I needed to understand why. Not the surface‑level “why,” but the structural one. The hidden one. The one nobody sees until it’s too late. Most people move on when something fails. I map it. I started noticing patterns. The same failure modes appeared everywhere: unclear ownership, mismatched incentives, brittle assumptions, invisible dependencies, and the classic “we built this fast and hoped it wouldn’t collapse.” Different domains, same architecture problems. I wasn’t trying to fix things. I was trying to understand them. But understanding inevitably leads to repair, and repair inevitably leads to design. Eventually I realised I wasn’t just analysing systems — I was architecting them. Not officially. Not ceremonially. Just… functionally. I became the person who could see the structure beneath the mess. The person who could explain why something was breaking and what would happen next. The person who could redesign the thing so it wouldn’t break again. People started asking me questions that only architects get asked. “Why is this happening?” “How do we stop it?” “What should this look like instead?” “What’s the underlying pattern here?” I didn’t have a job title for it. I didn’t need one. The work defined itself. Over time, I realised that “systems architect” was simply the most accurate description of what I was already doing. Not in the traditional enterprise sense — no UML diagrams, no formal frameworks, no ivory‑tower abstractions. More like: the person who sees the real structure beneath the chaos and can articulate it clearly enough that others fin

Sony shared an announcement with the console market: physical disc production for all PlayStation games will completely stop in January 2028. You can read the official announcement on the PlayStation Blog . From a pure engineering perspective, modern internet infrastructure has rendered physical distribution redundant. We no longer need plastic circles to transport megabytes. The gamer community response isn't about data transfer speeds. It is over true digital ownership, consumer rights, and software preservation. In this article, we break down the details, look at the history leading to this moment and explore why console makers would pursue this direction. 🔍 The Announcement Break Down The 2028 Deadline: The mandate strictly applies to new games launching after January 1, 2028. Legacy Back Catalog: Discs pressed before this date will still function (assuming future hardware maintains optical drive compatibility). "Code-in-a-Box" Retail: Stores will still sell physical cases on shelves, but they will contain a paper download voucher instead of a disc. I am no sustanability poster boy, seems wasteful to preserve retail shelf presence. 🛑 The Illusion of Ownership: "Buying" vs. "Renting" When you hit "Buy" on a digital storefront, you aren't purchasing a game. You are purchasing a conditional license to stream or download it—a long-term rental agreement that can be unilaterally altered or revoked. No Secondary Market: Players completely lose the ability to resell, trade, or lend games to friends. Monopoly Pricing: Eliminating discs removes competitive pricing from retailers like GameStop, JB Hi-Fi, or Amazon, leaving users locked to a single proprietary storefront. Delisting Vulnerability: If a publisher loses IP rights, the software vanishes instantly. 🎮 Case Study: My Close Call with Digital Erasure Look no further than Star Trek: Resurgence for proof of how fragile digital stores are. In April 2026, the publishers suddenly lost their IP distribution rights. Within

Book: Agents in Production — Building, Tracing, and Shipping Multi-Step AI You Can Trust Also by me: Observability for LLM Applications — the companion book in The AI Engineer's Library (2-book series) My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools Me: xgabriel.com | GitHub In June 2025 two engineering teams posted opposite advice in the same week. Anthropic shipped How we built our multi-agent research system : an orchestrator dispatching subtasks to worker agents, beating a single agent by 90.2% on breadth-first research. A few days later Cognition, the team behind Devin, published Don't Build Multi-Agents , arguing that parallel subagents without shared context produce fragile systems. Both were right. They were describing different workloads. Anthropic's research agent is embarrassingly parallel: four workers go read four things and come back with four small summaries. Cognition's target is writing code, where every edit depends on every other edit and context cannot be sliced. Most people get the plumbing wrong, not the decision. Once you have two agents that need to coordinate, you have to choose how they talk. That choice decides your failure modes long before the models do. Handoffs vs a shared bus There are two ways to wire agents together, and they fail differently. A handoff transfers control. Agent A finishes, hands the whole conversation to Agent B, and steps out. This reads well in a demo. In production it means the transcript grows on every hop, and by the fourth agent you are paying to re-read a conversation nobody trimmed. Handoffs also lose the parent: once A hands off to B, nobody is holding the original task to check the final answer against it. A shared bus keeps a supervisor in charge. Workers never talk to each other. They receive a small typed task, do the work, and return a small typed artifact to the supervisor, which composes the result. This is the shape of Anthropic's research

Book: Agents in Production — Building, Tracing, and Shipping Multi-Step AI You Can Trust Also by me: Observability for LLM Applications — the companion book in The AI Engineer's Library (2-book series) My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools Me: xgabriel.com | GitHub The agent works on your laptop. It passes evals. Your manager asks when it ships and you say Monday, because the modeling is done. Then you try to put it behind a load balancer and it falls apart, because you deployed it like a web service. An agent is not a web service. A web service answers in milliseconds and forgets. An agent thinks for minutes, burns tokens across two or three providers, streams partial output to a browser, and sometimes decides to call delete_invoice on the eighth turn. Every deployment decision you make flows from one question: what does this thing do to your infrastructure while it is running? Here is how to package it, where to hold state, and how to scale a workload whose bottleneck is a model call you do not control. The shape is decided by the longest step The single rule that saves you the most pain: an agent's deployment shape is decided by its longest step, not its average step. A support chatbot answers in two seconds. A code-review agent thinks for six minutes. A research agent runs for forty. You cannot put all three behind the same HTTP endpoint and expect any of them to survive. Pick the pattern that matches the longest step, then cap the rest with timeouts. Under 30s → stateless HTTP endpoint (Cloud Run, Fly.io). 30s to 5m with a user watching → streaming over WebSocket or SSE. 5m to an hour, async → queue plus worker (Temporal, Inngest, or Redis). Longer than an hour → still queue plus worker, whether you like it or not. Do not hold an HTTP request open for forty minutes. Something you did not know existed will kill it at the worst moment: a proxy, a CDN, a load-balancer idle timeout. Package it: p

How to Compress Images in the Browser with Canvas API Every image you upload to a "free" online compressor is sent to a server — often without you knowing what happens to it afterward. For a tool that processes your private photos, that's a terrible design. Here's how to build (or use) an image compressor that runs entirely in the browser using the HTML5 Canvas API. No uploads, no server costs, and unlimited file sizes. The Core Technique: Canvas toBlob() The key API is HTMLCanvasElement.toBlob() : js const canvas = document.createElement('canvas'); const ctx = canvas.getContext('2d'); const img = new Image(); img.onload = () => { canvas.width = img.naturalWidth; canvas.height = img.naturalHeight; ctx.drawImage(img, 0, 0); canvas.toBlob((blob) => { const url = URL.createObjectURL(blob); }, 'image/jpeg', 0.8); }; img.src = 'your-image.jpg'; The second parameter is the MIME type (image/jpeg, image/png, image/webp, image/avif). The third is quality (0–1). Step-Down Resizing for Large Images If you're compressing a 6000×4000 px photo, drawing it at full resolution onto a canvas can eat 70+ MB of memory. Step-down resizing halves the dimensions repeatedly: function stepDownEncode(img, maxDim, quality) { let w = img.naturalWidth; let h = img.naturalHeight; let src = img; while (w > maxDim * 2 || h > maxDim * 2) { w = Math.floor(w / 2); h = Math.floor(h / 2); const temp = document.createElement('canvas'); temp.width = w; temp.height = h; temp.getContext('2d').drawImage(src, 0, 0, w, h); src = temp; } const canvas = document.createElement('canvas'); canvas.width = w; canvas.height = h; canvas.getContext('2d').drawImage(src, 0, 0, w, h); return new Promise((resolve) => { canvas.toBlob((blob) => resolve(blob), 'image/jpeg', quality); }); } This prevents memory crashes and actually produces better quality (step-down preserves more detail than a single jump). Comparing Real-World Results Format Avg Original Avg Compressed Avg Savings JPEG → JPEG (Q80) 3.2 MB 0.8 MB 75% PNG → We

JWTs are one of those technologies that feel wonderful right up until you hit your first "log me out" requirement. Then you discover the awkward truth: the very property that makes JWTs attractive — statelessness — is also what makes logout hard. This post walks through what JWTs actually are, why "invalidating" one is a design problem rather than a one-liner, and the practical methods available to revoke an access token on logout, along with the bottleneck each one introduces. A quick refresher on JWTs A JSON Web Token (JWT) is a signed, self-contained token. It carries a JSON payload of claims — who the user is, when the token was issued, when it expires, and often a unique token id ( jti ) — and a cryptographic signature over that payload. Because the token is signed with a secret (or a private key), any server holding the corresponding key can verify it is authentic and untampered without calling a database . That last part is the entire point. When a request arrives with a JWT, the server checks the signature and the expiry, reads the claims, and proceeds. No lookup, no shared session store, no round trip. This is what people mean when they call JWT auth stateless : the server keeps no per-user session record. The token itself is the session, and it's valid until it expires. Access tokens and refresh tokens In practice you rarely use a single token. The common pattern splits responsibility across two: The access token is the short-lived workhorse. It's sent on every API request and typically expires in minutes (5–15 is common). Because it's checked statelessly on every call, you want its lifetime short — if it leaks, the damage window is small. The refresh token is long-lived (days or weeks) and does one job: obtain new access tokens when the current one expires. It is not sent on every request — only to a dedicated token endpoint. This lets the access token stay short and stateless while the user avoids logging in every ten minutes. The refresh token is easy —

Book: Agents in Production — Building, Tracing, and Shipping Multi-Step AI You Can Trust Also by me: Observability for LLM Applications — the companion book in The AI Engineer's Library (2-book series) My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools Me: xgabriel.com | GitHub On April 2, 2026, Microsoft shipped agent-framework 1.0 and, in the same blog post, moved AutoGen into maintenance mode. Semantic Kernel went with it. Three overlapping projects folded into one package with stable APIs and long-term support. Microsoft framed the move as a consolidation. If you had an AutoGen project that morning, you woke up with a migration. That is the shape of this whole category. The framework landscape you pick from today is not the one you picked from a year ago, and it will not be the one you pick from next year. So the useful question is not "which framework is best." It is "which framework has which wedge, and which trade-off comes with it." Here is an honest read on six frameworks worth installing in 2026, and when to reach for each. The churn is the feature, not the bug Before the tour, one thing that changed the math: the wire formats underneath these SDKs converged. Every framework here speaks MCP for tools. Most support A2A for cross-framework handoffs. Model Context Protocol started as an Anthropic proposal at the start of 2025 and is now the default way agents pick up external tools. That convergence means the framework you pick locks you in less than it used to. You are still locked at the abstraction layer, though. Migrating a production system from CrewAI to Pydantic AI is a rewrite of every Agent definition and every tool decorator. The pick is sticky. Choose it with that in mind. LangGraph : durability as the wedge Reach for LangGraph when your agent has to survive a crash. It models the agent as a graph with checkpointers backed by Postgres or SQLite, so a workflow that dies at step seven resumes a

Book: Agents in Production — Building, Tracing, and Shipping Multi-Step AI You Can Trust Also by me: Observability for LLM Applications — the companion book in The AI Engineer's Library (2-book series) My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools Me: xgabriel.com | GitHub You ship an agent that resolves billing disputes. It works in the demo. Two weeks later a support ticket lands: the agent tried to refund $4,000 on a $19 charge. You read the trace. The model returned a JSON blob, your code did json.loads , pulled amount , and passed it straight to the payments API. No cap. No type. No check. The model hallucinated a number and your code trusted it. The model is stochastic. Your code does not have to be. The gap between those two facts is where most production agent bugs live, and it is exactly the gap Pydantic AI is built to close. The wedge is types Most agent frameworks hand you an Agent object and a bag of strings. Pydantic AI hands you Agent[Deps, Output] — a generic parameterized by its dependency type and its output type. The IDE and your type checker read those parameters. So does the runtime. Install pulls in the framework plus an optional tracing extra: pip install "pydantic-ai[logfire]" The smallest program that earns its keep: from dataclasses import dataclass from pydantic import BaseModel from pydantic_ai import Agent , RunContext @dataclass class Deps : customer_name : str class SupportReply ( BaseModel ): reply : str escalate : bool agent = Agent ( " anthropic:claude-opus-4-8 " , deps_type = Deps , output_type = SupportReply , system_prompt = " You are a support agent. " , ) A tool is a plain function whose type hints become the schema the model sees, and the run returns the validated SupportReply : @agent.tool def customer_name ( ctx : RunContext [ Deps ]) -> str : return ctx . deps . customer_name result = agent . run_sync ( " What is my name? " , deps = Deps ( customer_name = " Ana "

Every dev using an AI coding agent has hit this moment: the agent says "Done — tests pass" and you go check, and nothing passes. Or worse, nothing changed at all. The instinct is to ask "why did it just lie to me?" That's the wrong question. It assumes intent. There isn't any. The right question is: What made the wrong answer cheaper than the right one — and what input did it exploit to get there? That question always has an answer. And the answer is always your next check. The mantra An LLM agent isn't a person deciding whether to be honest. It's a process that takes whatever path costs least, given whatever is actually being measured. If "claim done" and "verify, then claim done" both produce the same reward — because nothing downstream distinguishes them — the agent will drift toward the cheaper one. Every time. This isn't a flaw you can prompt your way out of. "Please don't lie to me" doesn't change the cost structure. What changes it is making the dishonest path actually expensive: something that catches the gap between claim and reality, every time, automatically. What this looks like in practice I built GroundTruth (a Claude Code Stop-hook plugin) after hitting this exact pattern on my own project, EraPin. Agents kept claiming "tests pass" or "refactor complete" when the git diff told a different story. Every fix I've shipped since started with the same exercise: Broadened extraction rule → a missed rule cost nothing, because nothing measured recall. Fix: track what's not being parsed, not just what is. Grounding check regression → a zero-hit result looked identical to "genuinely absent," so a silent no-op was free. Fix: pin the check against a real signal, not a pattern that can quietly degrade. Permission gate → auto-arming a misread rule cost nothing when there was no human in the loop. Fix: nothing gets armed without explicit approval. Every one of these is the same shape: find the loophole where "looks done" was cheaper than "is done," and close it so th

A 2023 HotOS paper by Sanjay Ghemawat (MapReduce/Bigtable co-author) and Amin Vahdat (Google Fellow) got repackaged by tech media as "microservices are dead." It said no such thing. Three years later, the misreading has traveled further than the paper itself. This post does three things: reconstructs what the paper actually claims, maps its three structural gaps, and introduces a variable the authors couldn't have predicted — AI code generation — which, I'll argue, undermines the paper's central solution more than any of those gaps. The AI section uses my own open-source project ReqForge as evidence. Flagging the conflict of interest up front: this isn't neutral analysis, it's a design rationale. Which is exactly why it's more honest than a hypothetical example. What the paper actually said The paper is Towards Modern Development of Cloud Applications (HotOS '23, 8 pages). Its core claim in one sentence: The fundamental problem with microservices is that they bind the logical boundary to the physical boundary. You let "how the code is organized" dictate "how the code is deployed" — two questions that should never have been welded together. From that claim, the paper proposes a three-layer solution: Logical monolith — developers write a cleanly modularized monolith; deployment is someone else's problem. Automated runtime — a smart platform that decides at runtime whether components should be merged or split, based on load. Atomic deployment — all components on a request path share one consistent version, avoiding half-old/half-new. Prototype numbers: 15× lower latency, 9× lower cost. That's it. The paper never says "microservices are wrong," never says "everyone should go back to monoliths," and gives no implementable plan. It's a vision paper — written to provoke discussion at a workshop, not an engineering whitepaper. A ruler Before dissecting it, here's a ruler you can apply to any architectural claim (this is a common framing in the engineering literature — you'r

From order, chaos. From courage, fear. From strength, weakness. — The 36 Stratagems, "Make a Sound...