GitHub 分享了提升 diff lines 性能过程中的工程取舍，并强调很多性能优化最后还是要回到更简单的设计。
The path to better performance is often found in simplicity. The post The uphill climb of making diff lines performant appeared first on The GitHub Blog.
Microsoft 介绍了 Awesome GitHub Copilot Customizations 项目的新网站、学习中心与插件能力，方便社区分享自定义 instructions、prompts 和 chat modes。
Back in July, we launched the Awesome GitHub Copilot Customizations repo with a simple goal: give the community a place to share custom instructions, prompts, and chat modes to customize the AI responses from GitHub Copilot. We were hoping for maybe one community contribution per week. That… did not happen. Instead, you all showed up. […] The post Awesome GitHub Copilot just got a website, and a learning hub, and plugins! appeared first on Microsoft for Developers.
OpenAI 收购 TBPN，目标是加速围绕 AI 的全球对话，并支持独立媒体，进一步扩大与开发者、企业及更广泛技术社区的连接。
OpenAI acquires TBPN to accelerate global conversations around AI and support independent media, expanding dialogue with builders, businesses, and the broader tech community.
AI Gateway 现在支持网关级自动重试。当上游 provider 返回错误时，请求会按你配置的策略自动重发，无需修改客户端逻辑。可配置重试次数、重试间隔以及 Constant、Linear、Exponential 等退避策略。
AI Gateway now supports automatic retries at the gateway level. When an upstream provider returns an error, your gateway retries the request based on the retry policy you configure, without requiring any client-side changes. You can configure the retry count (up to 5 attempts), the delay between retries (from 100ms to 5 seconds), and the backoff strategy (Constant, Linear, or Exponential). These defaults apply to all requests through the gateway, and per-request headers can override them. This is particularly useful when you do not control the client making the request and cannot implement retry logic on the caller side. For more complex failover scenarios — such as failing across different providers — use Dynamic Routing. For more information, refer to Manage gateways.
Codex 现为 ChatGPT Business 和 Enterprise 提供按量计费选项，让团队能以更灵活的方式启动和扩展使用规模。
Codex now includes pay-as-you-go pricing for ChatGPT Business and Enterprise, providing teams a more flexible option to start and scale adoption.
Cloudflare 认为，每周超过 100 亿次的 AI bot 请求正在改变缓存设计的前提。文章讨论了 AI bot 流量与人类流量的差异，以及缓存系统需要如何相应演进。
2026-04-02ResearchCacheThe explosion of AI-bot traffic, representing over 10 billion requests per week, has opened up new challenges and opportunities for cache design. We look at some of the ways AI bot traffic differs from humans, how th…
Cloudflare 发布 EmDash beta，这是一款基于 Astro 6.0 的全栈无服务器 JavaScript CMS，试图把传统 CMS 的能力与更现代的插件安全模型结合起来。
2026-04-01Today we are launching the beta of EmDash, a full-stack serverless JavaScript CMS built on Astro 6.0. It combines the features of a traditional CMS with modern security, running plugins in sandboxed Worker isolates....Continue re…
GitHub 回顾了近期以窃取 secrets 为目标的开源攻击，并介绍当前可用的防护措施，以及平台正在推进的安全能力。
Recent attacks on open source focus on exfiltrating secrets; here are the prevention steps you can take today, plus a look at the security capabilities GitHub is working on. The post Securing the open source supply chain across GitHub appeared first on The GitHub Blog.
现在所有 wrangler workflows 命令都支持 --local，可直接操作本地 wrangler dev 会话中的 Workflow，包括触发、查看实例、暂停、恢复、重启、终止和发送事件。
All wrangler workflows commands now accept a --local flag to target a Workflow running in a local wrangler dev session instead of the production API. You can now manage the full Workflow lifecycle locally, including triggering Workflows, listing instances, pausing, resuming, restarting, terminating, and sending events: npx wrangler workflows list --localnpx wrangler workflows trigger my-workflow --localnpx wrangler workflows instances list my-workflow --localnpx wrangler workflows instances pause my-workflow <INSTANCE_ID> --localnpx wrangler workflows instances send-event my-workflow <INSTANCE_ID> --type my-event --local All commands also accept --port to target a specific wrangler dev session (defaults to 8787). For more information, refer to Workflows local development.
OpenRouter 公布了 Auto Exacto，这是一项默认开启的自适应质量路由能力，用于在不同模型和请求场景下动态优化路由表现。
February Release SpotlightFebruary 23, 2026OpenRouter Outages on February 17 and 19, 2026February 20, 2026January Release SpotlightJanuary 9, 2026Distillable Models and Synthetic Data Pipelines with NeMo Data DesignerDecember 24, 2025Decem…
纽约时报报道，Artemis II 宇航员被允许携带智能手机进入飞船，用于拍摄照片和视频，不过这些设备当然无法联网。
Kalley Huang / New York Times: The Artemis II moon mission is one of the first times NASA has let astronauts fly with smartphones, giving them modified iPhones for taking photos and videos — The astronauts traveling in the Artemis II spacecraft were allowed to take smartphones with them. Sadly, they can't connect to the internet.
Swift 6.3 继续推进跨平台能力，带来官方 Android 支持、通过新 @c 属性显著增强 C 互操作，并继续扩展嵌入式开发支持。
Swift 6.3 advances Swift cross-platform story with official Android support, improves significantly C interoperability through the new @c attribute, and continues extending embedded programming support. It also strengthens the ecosystem with a unified build system direction and gives developers more low-level performance control. By Sergio De Simone
Inc. 报道称，Whoop 以界面相似为由起诉 Bevel，但 Bevel CEO 反击称这是一种“法律战”，并表示 Whoop 在起诉前还曾接触讨论合作。
Leila Sheridan / Inc.com: Health data startup Bevel's CEO pushes back against Whoop's lawsuit that alleges Bevel copied the look of the Whoop app, saying Whoop's actions are “lawfare” — He says Whoop previously reached out to explore a collaboration before filing the suit.
广泛使用的开源漏洞扫描器 Trivy 短暂向用户分发了恶意版本，这次事件再次暴露了软件供应链安全中的薄弱点。
A major security incident affecting the widely used open source vulnerability scanner Trivy has exposed critical weaknesses in software supply chain security, after maintainers confirmed that a malicious release was briefly distributed to users. By Craig Risi
The Pragmatic Engineer 援引消息称，Mark Zuckerberg 和 Garry Tan 都在 AI 辅助下重新开始深度参与编码工作。
Gergely Orosz / The Pragmatic Engineer: Sources: Mark Zuckerberg is back to writing code after a two-decade hiatus, submitting three diffs to Meta's monorepo, and is a heavy user of Claude Code CLI — Mark Zuckerberg and Garry Tan join the trend of C-level folks jumping back into coding with AI. Also: a bad week for Claude Code and GitHub, and more
作为随 webpack 5 推出的开源微前端机制，Module Federation 2.0 带来了动态 TypeScript 类型提示、解耦运行时层、Node.js 支持等更新，并进一步增强了对不同 bundler 与框架的兼容性。
Module Federation 2.0, an open-source micro-frontend mechanism introduced with webpack 5, offers significant updates including dynamic TypeScript type hints, decoupled runtime layers, and Node.js support. It enhances compatibility across various bundlers and frameworks. Key features include a Side Effect Scanner and easier integration for remote modules, addressing previous adoption challenges. By Daniel Curtis
The Verge 报道称，Anthropic 将停止用 Claude 订阅覆盖第三方工具访问配额，此举与容量管理有关。
Jay Peters / The Verge: Anthropic says Claude subscriptions will no longer cover usage on third-party tools like OpenClaw starting April 4 at 12pm PT, to better manage capacity — Claude subscriptions will no longer cover third-party access from tools like OpenClaw starting Saturday, April 4th.
Andrew Harmel-Law 与多位架构师讨论了 2025 年架构实践的变化，包括如何向利益相关方解释技术债务、如何通过 ADR 推动去中心化决策，以及现代技术领导者的职业路径。
Andrew Harmel-Law and a panel of expert architects discuss the shifting practice of architecture in 2025. They explain strategies for communicating technical debt to stakeholders, the benefits of decentralized decision-making through ADRs, and the career paths of modern leaders. The panel shares insights on bridging the gap between mobile and backend teams to ensure a holistic system. By Andrew Harmel-Law, Cat Morris, Diana Montalion, Shana Dacres-Lawrence, Vanessa Formicola, Elena Stojmilova, Peter Hunter
一场安静的变化正在发生，它不只出现在实验室或科技公司，也出现在办公室、教室、小店，甚至客厅里。
A quiet shift is happening — not in labs or tech companies, but in everyday places: offices, classrooms, small shops, even living rooms…Continue reading on Medium »
作者从一个看似普通的网站体验切入，讨论单个交互细节如何显著影响整体感受。
The other day, my partner who works in sales stumbled upon an excavating and hauling website that looked unassuming for the most part. It…Continue reading on Medium »
文章围绕 Angular 开发中常见的两种编程范式展开，比较声明式与命令式写法各自的优缺点与适用场景。
In the world of Angular development, there is a constant tug-of-war between two programming paradigms: Imperative and Declarative. If…Continue reading on Medium »
从活动报名场景出发，文章讨论了“公平”在预约和配额系统中为何并不容易定义与实现。
Imagine you’re organizing an event and open the registration.Continue reading on Medium »
文章结合 DX Research 和 Sonar 数据，认为 AI 带来的变化并不只是“更快写代码”，而是在重塑软件组织的 operating model。生产代码中已有相当比例由 AI 参与生成，但真正决定成效的，仍然是团队架构、评审文化、验证体系与组织流程。
Beyond the Hype: What 121,000 Developers and Autonomous Agents Tell Us About AI's Real Impact on Software Engineering We stopped talking about better tools a while ago. We're talking about a different operating model. The Frame We Were Given — and Why It's Not Enough When Andrej Karpathy coined the term "vibe coding" in February 2025, he gave us a useful shorthand. The idea: stop thinking about the code. Describe what you want, let the AI write it, stay in the flow of the product rather than the implementation. The AI writes the code; you specify the intent. That framing was genuinely useful for individual developers building small tools. It lowered the barrier to building. It let non-engineers ship products. It saved experienced engineers hours on boilerplate. But here's what that frame missed: Vibe coding describes a shift in how individuals write code. It doesn't describe the deeper shift in how organizations build software, how teams work, how knowledge flows, how responsibility is distributed, or what "being a software engineer" will mean in three years. The deeper shift — the one that matters — isn't about assistants completing your sentences. It's about agents that operate autonomously: they read the codebase, plan an approach, execute changes across multiple files, run tests, observe failures, revise their plan, and ship a working result. Without you in the loop for every step. That's not a productivity improvement. That's a change in what the job is. What the Data Actually Says Before we talk about what's changing, let's look at what we actually know. Because the gap between the hype and the data is instructive. The DX Research Numbers (121,000 Developers, 450+ Companies) Laura Tacho's research, presented at the Pragmatic Engineering Summit and drawn from DX Research's data across 121,000 developers at 450+ organizations, gives us the clearest industry-wide picture we have: 92.6% — of developers — use AI coding tools at least monthly — up from a minority just 18 months earlier 26.9% — of production code — is now AI-authored — up from 22% in Q3 2025. More than 1 in 4 lines shipped is AI-generated. ~10% — productivity plateau — AI saves roughly 4 hours/week per developer — significant but not the 10× most claimed 50% — faster onboarding — Time to 10th pull request — a standard onboarding benchmark — cut in half with AI assistance Data from DX Research's Developer Coefficient study, presented at Pragmatic Engineering Summit. Figures as of early 2026. The headline that gets shared is the productivity gain. The number that doesn't get shared enough is the plateau: AI saves about 4 hours per week — and then it stops. The gains don't compound beyond that for most developers. Something else is limiting progress, and it's not the AI. Tacho's finding on organizational dysfunction is the one worth paying attention to: AI amplifies existing processes, good and bad. Teams with clear requirements, good architecture, and functional review processes ship faster with AI. Teams with unclear ownership, poor documentation, and ineffective communication ship faster — but into more chaos. AI doesn't fix broken organizations. It makes the brokenness more visible and faster-moving. The Sonar State of Code (1,100+ Developers) The Sonar "State of Code 2025" survey covers 1,100+ developers across a range of company sizes and gives us the trust picture: Key Findings from Sonar State of Code 2025 96% don't fully trust AI-generated code. Even among developers who use AI tools daily, near-universal doubt about the reliability of what comes out. 42% of committed code is AI-assisted. Nearly half of what goes into production today was touched by an AI tool at some point in its creation. 75% believe AI reduces toil. Most developers report less time writing boilerplate, scaffolding, and repetitive patterns. But... 23-25% of the work week still spent on low-value tasks. AI didn't eliminate toil. It shifted it. Less time writing boilerplate, more time validating AI output, reviewing AI-generated PRs, and debugging subtle AI mistakes. Source: Sonar "State of Code 2025" survey of 1,100+ developers. Figures reflect self-reported data. Read those two numbers together: 96% don't trust AI code, but 42% of commits are AI-assisted. That's not a contradiction — it's a description of reality. Developers are using AI constantly while simultaneously knowing that what it produces requires careful review. The tools are useful enough to use even when you don't fully trust them. That tension is the defining characteristic of the current moment. The Actual Shift: From Assistant to Operating Model Here's the distinction that matters. There are two very different things happening under the label "AI in software engineering": AI Assistants (Where We Were) Autonomous Agents (Where We're Going) Autocomplete on steroids Agent receives a goal, not a prompt Human writes, AI suggests Agent plans its own approach Human reviews every line Agent executes across many files Human controls the loop Agent observes results, revises plan Scope: one function, one file Scope: feature, module, codebase You're in the driver's seat You define constraints and review output The transition from the first column to the second is what changes everything. Because when an agent operates at the level of a feature or module rather than a line or function, the developer's role shifts from writing code to defining the problem clearly enough that an agent can solve it correctly. That's a different skill set. Agents and the Tribal Knowledge Problem Every engineering team has knowledge that lives only in engineers' heads: why this table is structured the way it is, what the edge case was that broke production in 2023, why we chose this library over that one, how the onboarding flow really works (not how the ticket said it should work). Call it tribal knowledge. Traditional AI assistants inherit none of this context. They see the code you show them, the files you paste, the context window you fill. They don't know what they don't know about your system. Autonomous agents, especially those configured with persistent memory and full codebase access, change this. An agent that has operated in a codebase for weeks accumulates context. It "knows" the patterns, the naming conventions, the architectural decisions, the exceptions. It doesn't forget the conversation you had about the auth service last Tuesday. It never goes on vacation. The tribal knowledge problem wasn't primarily a documentation problem. It was a continuity problem. Documentation goes stale. Engineers leave. Context decays. Agents with persistent memory and full codebase access could be the first genuine solution to this — not because they document things better, but because they never lose the context in the first place. Trust Moves from Output to Process Here's a subtle but important shift: with AI assistants, trust was about the output. You looked at the code it generated and decided whether to accept it. With autonomous agents, trust has to be about the process. You can't review every step an agent takes across a 2,000-file codebase — you have to trust that the pipeline it operates within is safe, that the constraints are set correctly, and that the review gates catch what matters. This changes the relationship between developers and their CI/CD pipelines. The CI system stops being a gate you pass through and becomes the feedback loop the agent uses to know whether it succeeded. Tests become the specification the agent works to satisfy. Code review becomes the final human judgment layer in a largely automated process. The Hidden Risks The productivity gains are real. The risks are less discussed. Shadow AI: The Governance Problem The Number Companies Don't Track 35% of developers who use AI for work do so through personal accounts, not company-provided tools. For ChatGPT specifically, research suggests more than half of work-related usage happens outside company environments. This matters because of what goes into those conversations. Developers pasting production code, architecture diagrams, customer data patterns, or internal API schemas into personal AI accounts aren't violating policy out of malice — they're solving the problem in front of them. But the data is leaving the building. Most organizations' AI governance frameworks focus on what models they've approved and what data classification policies say. The governance they're not enforcing is at the point of actual usage: the developer's keyboard. The Technical Debt Paradox One of the more counterintuitive findings from the Sonar data is that developers believe AI both reduces and increases technical debt simultaneously: AI Reduces Debt When... AI Accelerates Debt When... Tests are generated for existing untested code AI-generated code is merged without full review Documentation is auto-generated and kept current Patterns are generated inconsistently across sessions Refactoring suggestions are reviewed and applied Working code is accepted without understanding it Boilerplate patterns are consistent across the codebase Edge cases the AI didn't consider ship undetected PR descriptions and changelogs are complete Speed incentivizes skipping architecture decisions The determining factor in which direction you go isn't the AI — it's the review culture, the test coverage requirements, and whether your team has a shared understanding of what "acceptable" AI-assisted code looks like. Organizations that haven't explicitly defined this are drifting toward the right column by default. Two Futures for the Developer The "AI will replace developers" conversation is the wrong one. A more useful question: what kind of developer does the AI-agent era need? Based on where the industry is heading, two archetypes are emerging. They're not mutually exclusive, but most developers will find themselves pulled toward one more than the other. The Orchestrator Works with agents. Defines goals, constraints, and acceptance criteria. Provides system-level judgment that agents can't replicate: architectural direction, product intuition, stakeholder communication, and the ability to recognize when an agent's solution is technically correct but strategically wrong. Skills that matter: System design and architecture Requirements precision (writing goals agents can act on) Reading and reviewing agent output critically Cross-functional communication Judgment under uncertainty The Infrastructure Builder Builds the systems that agents run on. This includes the agent pipelines themselves, the tool interfaces, the security boundaries, the observability infrastructure, and the evaluation frameworks that tell you whether an agent is actually doing what you think it's doing. Skills that matter: Agent frameworks and orchestration (LangGraph, CrewAI, etc.) Security and access control for AI systems Evaluation and testing of non-deterministic systems Observability (tracing agent decisions, debugging failures) Platform and developer experience thinking Company Adoption Patterns Organizations aren't adopting AI uniformly. Three distinct patterns are emerging: Deep Integration (20-30% of companies) AI tools deeply embedded in the dev workflow — custom tooling, agent pipelines, proprietary context systems. These companies have made AI infrastructure a strategic priority and have dedicated teams building it. Cloud Agent Adoption (50-60% of companies) Using available AI tools (Copilot, Cursor, Claude, etc.) without custom infrastructure. Productivity gains are real but capped — they haven't addressed the organizational bottlenecks that the data says limit returns beyond 10%. Hybrid/Wait-and-See (20-30% of companies) Cautious adoption due to IP concerns, regulated industries, or organizational resistance. Often have the highest shadow AI rates — developers find their own tools when official ones aren't available. The Junior Engineer Question The impact on junior developers deserves specific attention because it's where the most disagreement lives. The optimistic view: AI democratizes access to senior-level guidance. A junior developer can now get instant feedback on their code, explanations of patterns they don't understand, and suggestions for edge cases they might miss. The AI is a senior engineer available at 2am. The pessimistic view: the work junior developers traditionally learned from — the boilerplate, the scaffolding, the "doing it 100 times until you understand why" — is now being skipped. You get the answer without the struggle that creates understanding. Both views are true in different contexts. Here's the distinction: What junior engineers gain with AI: Dramatically faster onboarding (50% faster per the DX data) Access to explanations and context on demand Faster exposure to more diverse codebases and patterns Reduced anxiety about asking "basic" questions What junior engineers risk losing with AI: The deep understanding that comes from building things from scratch Debugging intuition built from hours of manual investigation The ability to reason about a codebase without tool assistance Knowing when an AI answer is subtly wrong The onboarding improvement is a genuine win. But there's a real risk that developers who've never built anything without AI assistance will hit a ceiling faster than those who have — because they'll encounter problems the AI can't solve and lack the foundation to solve them unaided. Why Mastery Still Matters Here's an argument that sounds anti-AI but isn't: you should still learn the fundamentals properly, even in a world where AI can generate the implementation for you. The analogy is mathematics. Calculators exist. Wolfram Alpha exists. You could argue that "learning long division" is unnecessary now that any phone can compute it. In practice, students who understand what division is — who have the underlying mental model — use calculators vastly more effectively than those who don't. They know when the answer looks wrong. They understand what operation to apply. They can build on the concept. The same logic applies to programming. Understanding what a database index actually does lets you review AI-generated queries and notice when the AI chose the wrong approach. Understanding memory management lets you spot why the AI's solution works for small inputs and explodes at scale. Understanding security fundamentals lets you catch the injection vulnerability the AI confidently introduced. AI doesn't change what mastery is. It changes what mastery is for. The purpose of deep technical knowledge used to be: so you can build things. In the agent era, the purpose shifts to: so you can direct agents effectively, recognize their errors, and take responsibility for what they produce. The destination changes. The need to understand the territory doesn't. The developers who will be most effective in an agent-driven world aren't those who outsourced their learning to AI early — they're the ones who built a real foundation and now know how to leverage AI on top of it. Skipping the foundation to get to the AI faster is optimizing the wrong variable. The Responsibility Argument Here is the question nobody wants to answer directly: when an AI agent writes the code that causes a production outage, loses customer data, or introduces a security vulnerability — who is responsible? The answer, legally and professionally, is the same as it's always been: the engineer who shipped it. The Thought Experiment A rocket engineer uses automated guidance software to design a trajectory. The software contains an error. The rocket fails. Is the engineer responsible? An airline pilot uses autopilot for most of a flight. The autopilot makes a navigational error. Is the pilot responsible? The answer in both cases is yes — because professional responsibility doesn't transfer to the tool. The engineer's job is to understand the system well enough to catch errors that automated systems make. The pilot's job includes maintaining the ability to fly the plane manually when the automation fails. This isn't an argument against using AI. The rocket engineer uses guidance software because it makes the rocket more accurate. The pilot uses autopilot because it reduces fatigue and improves performance. Both tools make the professional more effective — and neither tool reduces the professional's responsibility for the outcome. The implication for software engineers: using AI at scale requires developing new judgment skills. Not just "does this code work?" but "is this the right architecture?" "what could this agent have missed?" "what assumptions did it make that I haven't validated?" "am I confident enough in this to put my name on it?" Responsibility cannot be outsourced. The AI is a tool. The engineer is accountable. What "Augmentation Not Abdication" Actually Looks Like The phrase "AI augmentation" gets used constantly and means very little in practice. Here's what it looks like concretely: ✓ Augmentation You ask an agent to implement a feature. You review the output critically — not just "does it work?" but "is this maintainable?" "does it fit our architecture?" "are the tests actually testing the right things?" You merge when you're satisfied, not when the CI is green. ✗ Abdication You ask an agent to implement a feature. Tests pass. CI is green. You merge. You didn't read the implementation. You don't know what assumptions the agent made. You'll find out what it got wrong when a user does. ✓ Augmentation You use AI to explore a new codebase 5× faster. You still understand the system before you change it. The AI helped you get there faster — but the understanding is yours. ✗ Abdication You use AI to write all the code so you never have to understand it. When something breaks without an obvious error message, you ask the AI to fix it. When the AI can't, you're stuck — because you never built the understanding to fall back on. The Honest Summary of Where We Are 1 The shift is real and accelerating. 26.9% of production code is AI-authored. That number will only go up. Autonomous agents that can operate across full codebases are already deployed in leading engineering organizations. This is not a coming trend — it's the current state. 2 The productivity gains are real but bounded. 4 hours/week saved. Onboarding cut in half. These are significant wins. But the 10% plateau means AI isn't a multiplier — it's an optimizer. The larger gains require addressing organizational bottlenecks that AI exposes but doesn't solve. 3 The trust deficit is real and rational. 96% of developers don't fully trust AI-generated code. That's not irrationality — it's professional judgment. AI makes confident mistakes. The skill is learning to catch them efficiently, not learning to stop looking. 4 The governance gap is real and growing. 35% of AI-for-work usage happens through personal accounts. Most organizations don't know what code their developers are running through which models. This is a risk that compounds silently. 5 Responsibility doesn't transfer to the tool. The developer who ships AI-generated code is responsible for it. The engineer who deploys an AI-generated system is accountable for its behavior. This has always been true of tools. It remains true now. What to Do With This If you're an individual developer: → Build the fundamentals first, use AI to go faster. Not the other way around. The calculator analogy isn't just philosophical — developers who understand what they're asking for will extract dramatically more value from AI than those who don't. → Learn to write goals, not just code. The most valuable skill in an agent-driven workflow is specification — being precise enough about what you want that an agent can succeed. This is systems thinking expressed as requirements, not as implementation. → Get opinionated about review. With AI-assisted code going from generation to production faster than ever, your review standards — what you're actually checking, what passes and fails — matter more, not less. → Use your company's tools, not your personal account. Or advocate for better company tooling. The shadow AI problem is partly an organizational failure to provide good enough tools — but contributing to it doesn't make the governance risk go away. If you're leading a team or an organization: → Address the organizational bottlenecks, not just the tooling. If you're seeing the 10% plateau, the problem isn't the AI. It's the processes the AI is exposing. Unclear requirements, ownership gaps, and poor review culture will limit your returns regardless of what tools you deploy. → Define what "acceptable AI-assisted code" looks like. If you haven't explicitly set standards for AI code review, your team is making that call individually — inconsistently, and often under time pressure to ship. → Track shadow AI usage. You almost certainly have it. Understanding the scale of it and why developers are using personal accounts will tell you what your approved tooling is failing to provide. → Invest in junior engineers deliberately. The onboarding improvement is real — use it. But create explicit learning paths that don't outsource the fundamentals to AI. The engineers who will be most valuable in three years are the ones who understand why the AI does what it does.
这篇文章继续 TableCraft 系列，主张通过独立的 fetch adapter 和状态同步层来构建企业级前端客户端架构，把鉴权、重试、错误处理与本地缓存收束到统一边界中。
Part 6: The Smart Client SDK (State Synchronization & Fetch Adapters) Welcome back. If you’ve been following the TableCraft series, you know we aren’t here to play around with fragile abstractions or “magic” boilerplates that lock you into a single vendor. We are building robust, enterprise-grade B2B systems. Today, we look at the Smart Client SDK. The "Creator-to-Creator" Reality Let’s be brutally honest for a moment. Most modern frontend boilerplates give you an illusion of speed. They hand you a chaotic global state and 50 scattered fetch() calls hidden inside useEffects or server actions that blur the lines of responsibility. When your app is a weekend project, that’s fine. When you’re shipping for enterprise clients, that architecture rots faster than you can patch it. You don’t need more magic; you need discipline. The Librarian / Menu Storytelling Pattern Think of your client architecture not as a giant bucket of data, but as a Librarian holding a Menu. The Menu (Fetch Adapters) The frontend component is the reader. It doesn't go wandering into the stacks (the API/database) looking for data. It reads from a strict, typed Menu. We build a single isolated adapter layer. // The Menu export const TableCraftSDK = { tenant: { get: (id: string) => librarianFetch(/api/tenant/${id}), sync: (payload: TenantPayload) => librarianFetch(/api/tenant, { method: 'POST', body: payload }) } }; By forcing every request through the Librarian (librarianFetch), you gain a single, impenetrable choke point. This is where you handle auth token injection, 401 retries, and global error catching. No more silent failures in random components. The Librarian (State Synchronization) When the Menu order is placed, the Librarian handles the synchronization. Instead of optimistic UI updates that lie to the user when a database transaction inevitably fails, the Librarian maintains a clean local cache (a ledger). It only updates the view when the backend confirms the truth. class LibrarianStore { private ledger = new Map<string, any>(); // Sync the truth, not the assumption. public commit(key: string, data: any) { this.ledger.set(key, data); this.notifySubscribers(key); } } Why We Build This Way This architecture isn't about saving keystrokes. It's about building a moat. When you completely decouple your state synchronization and fetch logic from your React/Vite components, you own your application. If you ever need to rip out the backend or change the frontend framework, the Librarian and the Menu remain intact. That is how you survive enterprise security reviews and scale without tearing your hair out. Stay tuned for the next part of the TableCraft series. Keep shipping clean architecture.
帖子汇总了 VOID 模型在 Hugging Face、GitHub 和在线 Demo 的入口，展示 Netflix 首次公开放出的视频编辑模型。
Hugging Face netflix/void-model: https://huggingface.co/netflix/void-model Project page - GitHub: https://github.com/Netflix/void-model Demo: [https://hu…
发帖者表示自己试用了新的 Gemma 4 模型，整体体验不错，但也因此更能体会 Qwen 在模型质量和大上下文可用性上的表现。
Been playing with the new Gemma 4 models it’s amazing great even but boy did it make me appreciate the level of quality the qwen team produced and I’m able to have much larger context windows on my standard consumer hardware.
发帖者比较了自己在 TMLR、ICLR 和首次投 ICML 时的评审体验，认为在较短决策周期下，不同 venue 的评审质量差异值得讨论。
This year I submitted a paper to ICML for the first time. I have also experienced the review process at TMLR and ICLR. From my observation, given these venues take up close to (or less than) 4 months until the final decision, I think the q…
一位 PhD 学生在发表过多篇 A/B 类论文后，首次准备投稿 NeurIPS，向社区请教高等级会议在讨论氛围和评审上的差异。
I'm a PhD student and already published papers in A/B ranked paper (10+). My field of work never allowed me to work on something really exciting and a core A\* conference. But finally after years I think I have work worthy of some discussi…
MIT study challenges AI job apocalypse narrative
发帖者回看 2025 到 2026 年的 AI 安全事故数据后认为，很多问题并不是高级攻击，而是熟悉的安全模式在 AI 系统里重新上演，只是外界讨论还不够多。
I’ve been digging into AI security incident data from 2025 into this year, and it feels like something isn’t being talked about enough outside security circles. A lot of the issues aren’t advanced attacks. It’s the same pattern we’ve seen…
How Microsoft Vaporized a Trillion Dollars
帖子指出一个名为 strapi-plugin-events 的 npm 包伪装成社区插件，安装后会执行可疑行为，提醒开发者立即排查 Strapi 生态中的供应链风险。
strapi-plugin-events dropped on npm today. Three files. Looks like a legitimate community Strapi plugin - version 3.6.8, named to blend in with real plugins like strapi-plugin-comments and strapi-plugin-upload. On npm install it…
safer：一个避免文件和流发生部分写入的小工具safer: a tiny utility to avoid partial writes to files and streams作者分享了自己写的一个小库，用来降低配置文件或流在写入过程中被部分覆盖、损坏的风险。
**What My Project Does** In 2020, I broke a few configuration files, so I wrote something to help prevent breaking a lot the next time, and turned it into a little library: https://github.com/rec/safer It's a drop-in replacement for open…
这个名为 WeThePeople 的 FastAPI 应用聚合了 40 多个政府公开 API，用于跟踪企业游说、政府合同、国会议员股票交易、执法行动和竞选捐款等数据。
**What My Project Does:** WeThePeople is a FastAPI application that pulls data from 40+ public government APIs to track corporate lobbying, government contracts, congressional stock trades, enforcement actions, and campaign donations acros…
先把 Codex 启动得更强，再在工作规模变大时让 OMX 接管更好的提示词、工作流和运行时辅助。
Start Codex stronger, then let OMX add better prompts, workflows, and runtime help when the work grows.
**Onyx** 是 LLM 的应用层，提供功能丰富、且任何人都能轻松自托管的界面。
**Onyx** is the application layer for LLMs - bringing a feature-rich interface that can be easily hosted by anyone.
TimesFM（Time Series Foundation Model）是 Google Research 开发的预训练时间序列基础模型，用于时间序列预测。
TimesFM (Time Series Foundation Model) is a pretrained time-series foundation model developed by Google Research for time-series forecasting.
OpenScreen 是一个免费、开源的 Screen Studio 替代品。
OpenScreen is your free, open-source alternative to Screen Studio (sort of).
面向 AI agents（MCP）和 Neovim 用户的高速文件搜索工具，并内置记忆能力。
AI agents (MCP) | Neovim users A fast file search for your AI and neovim, with memory built-in
全球最大的开源提示词库之一，支持 ChatGPT、Claude、Gemini、Llama、Mistral 等多种 AI。
The world's largest open-source prompt library for AI Works with ChatGPT, Claude, Gemini, Llama, Mistral, and more formerly known as Awesome ChatGPT Prompts 🌐 Browse Prompts • 📖 Read the Book • 📄 View on GitHub • 🚀 Self-Host
可跨 400 多个社交网络根据用户名追踪账号，并提供 Debian、Ubuntu、Homebrew、Kali、BlackArch 等社区维护包。
Hunt down social media accounts by username across 400+ social networks Community-maintained packages are available for Debian (>= 13), Ubuntu (>= 22.10), Homebrew, Kali, and BlackArch.