AI 资讯

The trajectory of AI agents over the past two years has been remarkably clear: from single-purpose tools to personal assistants. Everyone runs their own agent, feeds it tasks, gets results back. It works well for individual productivity. Then comes the question every team eventually asks: can these agents work together? The answer is yes, but the problems you encounter along the way are rarely the ones you expected. They aren't about model capabilities or prompt engineering. They're about communication, context, and coordination — the same class of problems that distributed systems engineers have been solving for decades, now showing up in a new form. Here are three challenges that caught us off guard when we started building agent collaboration into Octo , an open-source workplace platform where AI agents and humans share the same communication space. Challenge 1: Context Visibility Boundaries When you use an agent personally, context management is straightforward. You decide what information the agent sees; its output comes back to you. The boundary is clean — it's just your workspace. In a team setting, that boundary dissolves. One of the first issues we ran into was surprisingly simple. We had an agent summarizing discussions across several channels. During testing it started pulling roadmap discussions from a product channel into an engineering planning thread. Nothing sensitive leaked externally, but it immediately exposed how unclear our context boundaries were. Traditional software handles this through API gateways, data permissions, and microservice boundaries. But agent context isn't just structured data — it includes conversation history, reasoning chains, and intermediate states. An agent's thought process during a task is valuable context, but it might also contain information that shouldn't cross team boundaries. What you need is fine-grained context visibility control. Not "everything open" or "everything closed," but dynamic rules that determine whic

Debugging authentication in web apps is painful. You need to test the same flow as five different user types — new visitor, returning user, admin, expired session, logged-out — and the easiest way is to constantly create new accounts or clear all your cookies and start over. There's a faster way. These five techniques use direct cookie manipulation to simulate any auth state without touching your database or creating dummy accounts. I use CookieJar for most of this — a free Chrome extension built natively on MV3 that gives you a proper UI for cookie editing. But I'll show you the underlying Chrome DevTools method too, so you understand what's actually happening. 1. Simulate a Logged-Out State Without Clearing Everything The naive approach: clear all cookies and reload. The problem: you just nuked your dev server session token, your local storage flags, your Stripe test mode cookie, and everything else you carefully set up. The targeted approach : identify and delete only the session/auth cookie. Most session cookies are named session , sid , auth_token , _session_id , or something close. In DevTools: Application → Cookies → [your domain] → find the session cookie → right-click → Delete With CookieJar: open the extension, search session , click the trash icon next to just that cookie. Your dev environment stays intact. The user state resets to logged-out. 2. Test the "Returning User" vs "New User" Path Without a Second Account Session cookies tell the server you're authenticated. But many apps use separate cookies to track whether a user has seen the onboarding flow, completed setup, or visited before. Look for cookies like onboarding_complete , setup_done , first_visit , or custom flags in your app code. To test the new user experience: Export your current cookies (CookieJar → Export → JSON format, or copy from DevTools) Delete the specific onboarding/first-visit flag cookie Reload and test the new user path Re-import or re-set the cookie to restore your state This

Claude Opus 4.7 shipped last week, and the question any engineering team reaches for is how it compares to its peers. It is the strongest frontier coding model we tested on the baseline leaderboard, and it will be the easy default a lot of teams reach for. But in 2026, the model you reach for could matter less than the skill you load with it. That is what 880 evals across nine models (Opus 4.7, Opus 4.6, Sonnet 4.6, Haiku 4.5, gpt-5.4, gpt-5.3-codex, gpt-5-codex, and Cursor's Composer-2) tell us. Let’s take a step back. It’s now 2026, and agent skills are spreading like wildfire… (even our favourite movies are catching up to them). Watch on YouTube Every major agent ecosystem now has some version of them. So the question worth asking, whether you are a dev, a platform engineer, or an engineering leader, is which skills actually earn their context weight, and which ones just add cost. At Tessl, we believe context -particularly agent skills- and the broader concept of a context development lifecycle are where this space is heading (see also: Why the best AI coding teams will win on context ). The results below add to a growing body of signals pointing to a shift that is already underway. Top-line results Model Native behavior rate coverage (e.g "without skill") Adherence to skill ("with skill") Lift $/run (with skill) Avg time (with skill) claude-opus-4-7 80.5% 94.5% +14.0 $1.00 158.9s claude-opus-4-6 77.1% 93.8% +16.7 $0.53 126.6s claude-sonnet-4-6 75.6% 93.3% +17.7 $0.31 125.1s claude-haiku-4-5 61.2% 84.3% +23.1 $0.12 77.8s gpt-5.4 75.9% 92.7% +16.8 N/A* 135.4s gpt-5.3-codex 75.8% 91.9% +16.1 N/A* 87.9s gpt-5-codex 73.8% 85.1% +11.3 N/A* 136.2s cursor-composer-2 73.6% 90.5% +16.9 N/A* 152.0s We’ve evaluated 11 node.js development skills ( documentation, fastify-best-practices, init, linting-neostandard-eslint9, node-best-practices, nodejs-core, oauth, octocat, skill-optimizer, snipgrapher, typescript-magician ) , and aggregated “with vs without” skill performance. F

Fix what's breaking in your AI agent Discussion | Link

Review AI-generated Markdown and HTML in a focused workspace Discussion | Link

Feel free to include any brands or product names as well. Be as obscure or on the nose as you'd like....

AI makes us faster, but does it make us better engineers, or just more dependent? As a follow-up...

Over the past year, I've noticed something interesting in conversations about enterprise AI. Most...

https://xcancel.com/LarsAnders1620/status/206820886474754051...

TL;DR: I built a .NET library that renders Helm charts and drives Kubernetes releases without shelling out to the helm CLI. 129/129 templates across ingress-nginx, cert-manager, external-dns, podinfo, and metrics-server now render successfully. The main entry point is HelmSharp.Action, with lower-level packages available for chart loading, rendering, Kubernetes operations, and release storage. MIT licensed, looking for feedback and early adopters. Why I Built This At work, our .NET services deploy to Kubernetes through Helm. Every Docker image had to bundle the helm binary — another dependency to manage, another layer in the image, another surface for CVEs. I wanted to cut that out entirely and do Helm-style rendering directly in-process. The .NET ecosystem doesn't really have this. There are YAML libraries. There are Kubernetes client libraries. There are template engines. But nothing ties them together the way helm template does — values merging, named templates, include , range , toYaml , the whole Sprig function set, all wired into a single render pipeline. So I started building one. (This is also my first real open source project — I'd spent years consuming OSS without contributing back, and HelmSharp is what came out of deciding to change that.) What HelmSharp Does HelmSharp is a multi-package .NET SDK (net8.0 / net9.0 / net10.0) that covers: Package What it does HelmSharp.Action High-level Helm client — TemplateAsync , UpgradeInstallAsync , RollbackAsync HelmSharp.Chart Chart loading from directories and .tgz , values merging, --set / --set-json style overrides HelmSharp.Engine Helm-style template rendering — 100+ Sprig/Helm functions HelmSharp.Kube Kubernetes apply, delete, and wait (no kubectl needed) HelmSharp.Release Release history stored in Kubernetes Secrets (Helm-compatible) HelmSharp.Repo Chart repository index, pull, and search Plus Registry , Storage , PostRenderer extension points Here's the lower-level rendering API — no result objects, no stdout

Let me confess something a little creepy. I have a habit of peeking at other people's dev posts. Not stealing the writing — relax. I run a tiny read-only job that fetches the public pages on dev.to, Zenn, and Qiita and counts only the boring parts: titles, post times, like counts. Who published what, at what hour, and how far it traveled. Then it tallies the lot. The reason is petty: my own posts weren't landing. The content is already in my hands — so I wanted to know how much the rest, the when and how you publish , actually moves the needle. By the numbers, not by gut. So I counted across three platforms. And the conditions that make a post fly turned out to be roughly mirror images between Japan (Zenn / Qiita) and the English-speaking world (dev.to). Here's the story. First, my most important disclaimer This post is full of numbers, so let me put up a guardrail before any of them. This is correlation, not causation . A result like "weekend posts don't do well" could mean the weekend itself is bad — or it could mean people who post on weekends are just dashing something off on the side. The data can't separate those. Please read it that way. Also, I only keep aggregate numbers I computed myself . I don't store or reuse anyone's article body (read-only GET, count the features, throw the page away). I peek, but only at the overall shape . Nobody gets singled out here. With that out of the way — four findings I enjoyed. 1. The best hour to publish is just your readers' time zone This one came out cleanest. On Qiita , posts published in the morning win (+32pt in the GOOD group). Midday is +14pt. Evening is -32pt, late night -14pt. Zenn likes midday too (+27pt). Late night is -15pt. dev.to is the exact opposite. Late night Japan time scores +7pt — Japanese evening is actually weak. The trick is obvious once you see it. dev.to's readers are English-speaking, mostly US. Late night in Japan is the US working day. Zenn and Qiita readers are in Japan, so the Japanese morni

I run a paid infrastructure service. Alone. No co-founder, no on-call rotation, no senior engineer to escalate to. My only collaborator is Claude Code, and after about a year, my persistent memory has grown to 60+ entries. Those entries have become more valuable than any runbook I've written. They've also taught me — painfully — what makes memory architecture work and what makes it quietly fail. If you're running anything solo with an AI agent, here are five lessons I wish I'd burned into my brain on day one. 1. Write the why , not the what The first instinct when you start using persistent memory is to log what you did. "Migrated service X from tool A to tool B." "Switched protocol from X to Y." Six months later, when something breaks, that information is worthless . You don't need to know what you did — git log and git blame already tell you that. You need to know why you made that choice. What constraint forced it. What you ruled out. Real example. The bad version of an entry I once wrote: Switched the worker pool from Docker containers to systemd units on host. Tells me nothing my git history doesn't. The rewritten version: systemd units on the host instead of Docker containers on this VPS provider. Why: the provider runs aggressive kernel-wide OOM scoring across tenants; containers were getting reaped by oom-killer triggered by other customers' workloads. systemd processes survive because they're scored as system processes. How to apply: any VPS where dmesg | grep -i oom shows kills from PIDs you don't recognize — don't run containers there, run systemd. That one entry has saved me three rebuilds. Because the next time I'm tempted to "just dockerize it, it'll be cleaner," the memory entry says: no, you already learned this, you'll be back here in a week. The pattern: always include Why: and How to apply: lines. If a memory entry can't answer those two questions, delete it. 2. Memory rots — prune or pay About six months in, I did a memory audit. Of 60 entries, 1

13.5.0 Before We Begin During its design, Rust drew inspiration from many languages, and functional programming had a particularly strong influence on Rust. Functional programming often includes passing functions as values to parameters, returning them from other functions, assigning them to variables for later execution, and so on. In this chapter, we will discuss some Rust features that are similar to what many languages call functional features: Closures Iterators (this article) Improving the I/O Project with Closures and Iterators Performance of Closures and Iterators If you find this helpful, please like, bookmark, and follow. To keep learning along, follow this series. 13.5.1 What Is an Iterator To talk about iterators, we first need to talk about the iterator pattern. The iterator pattern allows you to perform a task on each element in a sequence, one by one. In that process, the iterator is responsible for: Traversing each item Determining when the sequence has finished iterating Rust iterators are lazy: unless you call a method that consumes the iterator, the iterator itself does nothing. In other words, if you write an iterator in your code but never use it, it is as if it did nothing at all. Take a look at an example: fn main () { let v1 = vec! [ 1 , 2 , 3 ]; let v1_iter = v1 .iter (); } v1 is a Vector , and v1.iter() creates an iterator for v1 and assigns it to v1_iter . But v1_iter is not used yet, so the iterator can be considered to have no effect. Now let’s use the iterator to traverse the values: fn main () { let v1 = vec! [ 1 , 2 , 3 ]; let v1_iter = v1 .iter (); for val in v1_iter { println! ( "Got: {}" , val ); } } This is equivalent to using each element in the iterator once in a loop. 13.5.2 The Iterator Trait All iterators implement the Iterator trait. This trait is defined in the standard library and looks roughly like this: pub trait Iterator { type Item ; fn next ( & mut self ) -> Option < Self :: Item > ; // methods with default implementa

This is a submission for the June Solstice Game Jam Archive — The Last Historian of Humanity What if history wasn't discovered... but selected? History is often treated as something permanent—something waiting to be uncovered. Archive asks a different question: What happens when humanity loses the ability to tell the difference between truth, memory, and fabrication? You play as the final Archivist after the collapse of civilization. Humanity's knowledge survives, but it has become fragmented, contradictory, and corrupted. Your responsibility is no longer to preserve everything—you must decide what deserves to be remembered. Every decision changes the civilization that will inherit your version of history. What I Built Archive is a narrative investigation game where players reconstruct humanity's past by examining historical memories, investigating evidence, resolving contradictions, and deciding what becomes official history. Unlike traditional mystery games, there is rarely a perfect answer. Instead, every investigation asks questions such as: Should conflicting memories be preserved? Is stability more important than truth? Can compassion justify rewriting history? If no one can verify the past, what does "truth" even mean? Each recovered memory is presented as a historical article. Players investigate through classified documents, research papers, witness testimonies, forensic reports, personal journals, and government archives before making irreversible decisions. Those decisions reshape the civilization that follows. By the end of the game, players don't simply receive a score—they discover the kind of society they created. Why It Fits the Theme The June Solstice represents a turning point. It is the moment when one season gives way to another, when light begins yielding to darkness, or darkness begins yielding to light. Archive explores a similar transition. Not between seasons... but between certainty and uncertainty. Human civilization reaches a moment where

13.4.0 Before We Begin During its design, Rust drew inspiration from many languages, and functional programming had a particularly strong influence on Rust. Functional programming often includes passing functions as values to parameters, returning them from other functions, assigning them to variables for later execution, and so on. In this chapter, we will discuss some Rust features that are similar to what many languages call functional features: Closures (this article) Iterators Improving the I/O Project with Closures and Iterators Performance of Closures and Iterators If you find this helpful, please like, bookmark, and follow. To keep learning along, follow this series. 13.4.1 Closures Can Capture Their Environment Closures have a capability that functions do not: a closure can access variables in the scope where it is defined. Take a look at an example: fn main () { let x = 4 ; let equal_to_x = | z | z == x ; let y = 4 ; assert! ( equal_to_x ( y )); } The closure part is: let equal_to_x = | z | z == x ; Some people may find it hard to distinguish the roles of = and == here, so let’s rewrite it another way: let equal_to_x = | z | { z == x ; } In other words, the closure takes z as its parameter, compares it with x (which is 4, because x = 4 was defined above), and returns a boolean. If they are equal, the result is true ; otherwise it is false . Here the closure directly accesses the variable x in the same scope, which functions cannot do. But this feature has a cost: it introduces memory overhead . In most cases we do not need a closure to capture its environment, and we do not want the extra overhead either. That is why functions are not allowed to capture variables from the environment, and defining and using a function never introduces this kind of overhead. 13.4.2 How Closures Capture Values From Their Environment Closures capture values from the environment in three ways, just like functions receive parameters in three ways: Taking ownership, whose trait

This is a submission for the June Solstice Game Jam Link to Game Home Page - here Link to Game Docs - here What I Built Heliograph is a short 2D solar-noir platformer. You are a courier who wakes with no memory on the summer solstice , the longest day of the year — the one day the sun is supposed to never quite die. A cracked handheld computer flickers on in your hand and tells you the truth: tonight the sun will set, and a relay station full of light has one unfinished message left to send before the dark. Sunlight is your battery and your map — it refills your light cell and reveals the route. Shadow hides you from the station's machines, but it slowly drains you, so you can never simply wait. Every screen is a negotiation between expose, charge, traverse, hide, decode. The core puzzle is a light relay . Most of the station is dark. Standing in a live sunbeam, you trip a relay that throws the light forward — a beam snaps to the next aperture, that beam comes alive, its cipher glyph becomes readable, and the chain continues until the final relay powers the exit terminal. You are literally carrying the light deeper into the ruin one beam at a time. Skip a relay and the road ahead stays dark and unsolvable. The jam theme is the solstice — light and darkness, and the passage of time. Heliograph is built entirely out of that tension: Light vs. darkness is the core mechanic, not a backdrop. Light is power, information, and danger at once; shadow is safety that costs you. The passage of time is the antagonist. The whole game is one long solstice day bleeding into night, and the message has to leave the station before dark. The station is a heliograph — a real Victorian device that sent Morse code by flashing sunlight off mirrors. Light is the message. There are no cutscene dumps. ACE, your handheld guide, narrates the opening, and after you decode each level's keyword — SUN → ARC → LUX → RAY — ACE decrypts one more fragment of the truth: why you're here, that you may not

When we open sourced Neural Inverse Cloud, the easiest choice would have been MIT. Most developers like MIT. It's short, permissive, and widely adopted. If you've released an open-source project before, MIT is probably the first license you considered. We didn't choose it. We chose AGPL. Not because we dislike permissive open source. Not because we want to restrict users. We chose it because infrastructure software plays by different rules. The Infrastructure Problem MIT works incredibly well for libraries. You publish code, developers use it, and occasionally improvements flow back into the project. Nobody is forced to contribute, but community norms often make it happen anyway. Infrastructure software is different. Cloud IDEs, databases, developer platforms, deployment systems, and backend services can be monetized without ever distributing the source code. A company can: Fork your project Add proprietary features Launch a hosted version Build a competitive advantage on top of community work Never contribute anything back The original project does all the R&D. The fork captures the value. We've seen this pattern repeatedly across open-source infrastructure over the last decade. Why AGPL Exists AGPL closes a loophole that traditional open-source licenses leave open. With GPL, if you distribute modified software, you must publish your changes. But what if you never distribute the software? What if you simply run it as a hosted service? That's where AGPL comes in. If you modify AGPL software and provide it to users over a network, you must also provide the source code for those modifications. That applies to everyone. Including us. If we improve Neural Inverse Cloud, those improvements stay open. If someone else builds a SaaS business on top of it, their modifications stay open too. Why This Matters for Users We wanted users to have guarantees. With AGPL: You can self-host the latest version Community improvements remain accessible No company can create a permanently

Hi 👋 fellow devs Sorry for such a big gap since my last article...... Life got a bit hectic, but I am finally back in action! You know how it goes. We spend so much of our energy obsessing over the flashy side of tech. We talk about gorgeous UI designs, smooth animations, and whatever frontend framework is trending on GitHub this week. But let’s be completely real for a second. What actually keeps your favorite apps from melting down when millions of people hit the refresh button at the exact same moment? That is exactly what we are going to unpack today. We are pulling back the curtain on the quiet, brilliant backstage crew of infrastructure tools. You see their logos all over tech Twitter and hear senior engineers drop their names in meetings like secret handshakes, but today, we are stripping away the corporate fluff. We will break down eight legendary backend technologies using conversational paragraphs and quick bullet points so you can finally master what they actually do. Let’s dive right in. 1. Redis Traditional databases live on hard drives. They are fantastic for keeping your data safe and organized permanently, but pulling data off a physical drive takes time. If your application has to wander deep into those database aisles to fetch the exact same piece of information every single second, your entire system starts to stall. To understand how Redis fixes this, imagine you are studying for a brutal exam. Your massive, 1,000-page textbook represents your main database. It holds every single answer, but flipping through the pages continuously is incredibly slow. Redis is the digital equivalent of writing the core formulas you need on a neon sticky note and taping it directly to your monitor. It keeps critical data sitting directly inside the system's lightning-fast short-term memory. You will typically find Redis stepping in to handle operations like: Session Management: Keeping users logged into an application without checking the main database on every cli