Claude Blog 采集 (2026-07-19)¶
共采集 5 篇文章
📋 文章索引¶
- How Anthropic runs large-scale code migrations with Claude Code - Jul 16, 2026 (评分: 9.5)
- Zero risk isn't the job: a CISO's guide to agentic AI - Jul 17, 2026 (评分: 9.5)
- Claude in Microsoft Foundry is now generally available - Jun 29, 2026 (评分: 9.0)
- Choosing a Claude model and effort level in Claude Code - Jul 07, 2026 (评分: 9.0)
- Bringing Code Review to Claude Code - Mar 09, 2026 (评分: 9.0)
How Anthropic runs large-scale code migrations with Claude Code¶
来源: Claude Blog 发布日期: Jul 16, 2026 采集时间: 2026-07-19 价值评分: 9.5/10 正文字数: ~5435 字符
摘要¶
A step-by-step guide to running large code migrations with AI agents — including Bun's million-line Zig-to-Rust port.
正文内容¶
A step-by-step guide to running large code migrations with AI agents — including Bun's million-line Zig-to-Rust port.
Code migrations, projects that port a production codebase to a new language, were multi-year endeavors until recently. In the last month, individual developers at Anthropic migrated 10 code packages consisting of tens to hundreds of thousands of lines of code using Claude Fable 5, Claude Opus 4.8, and dynamic workflows . In this article we’ll cover two examples along with best practices from these projects. Jarred Sumner, co-founder of Bun and Member of Technical Staff at Anthropic, used Claude Code to migrate Bun from Zig to Rust . A million lines of code were produced in less than two weeks, with 100% of Bun's existing test suite passing in CI before merge. Nineteen regressions surfaced after merge and have all been fixed. The Rust port was shipped inside Claude Code in June. Mike Krieger, co-lead of Anthropic Labs, migrated a Python codebase to 165,000 lines of TypeScript over a weekend. This included hundreds of agents, eight phase gates, three adversarial review rounds, and a final parity check that diffed every command's output against the Python original. Claude Code’s new capabilities change the math for these long-deferred projects. Below is the six-step process we now use, drawn from what these migrations taught us. The core insight is that you don’t fix the code. You fix the process (loop) that produced the code . Why and when to migrate languages Before going straight into the how , it’s worth discussing the when and why because the assumptions around these projects have evolved. Teams launch migrations because of landscape changes between their initial build and current project. Either a known trade-off has become limiting, a better approach has emerged, or the original ecosystem is shrinking. For example, Jarred originally chose Zig because it offered C-level performance with radical simplicity, ideal for a solo founder “writing Bun in 1 year in a cramped Oakland apartment pre-LLM.” This simplicity came with known tradeoffs, which he writes about here . Fast forward to 2026. Bun's CLI is getting over 10 million monthly downloads and is used extensively within Claude Code. As recently as last quarter, those tradeoffs wouldn’t have been enough to justify freezing the roadmap and committing resources to a multi-quarter project. Migrating languages can deliver smaller, faster, and safer systems, but no one wants to pay for them. Software engineers have also had to contend with the career risk inherent in these formerly mega-projects. You could maintain two parallel code bases for quarters or years, and if the end result was 90% parity, you had a bigger headache than when you started. Now, the worst case scenario is you delete the branch and try again. There still needs to be a justifiable business case. While million line migrations no longer cost $3 to $4 million in engineering resources over the course of a four year project, they still cost tens to hundreds of thousands of dollars or more to execute. The Bun migration, for example, consumed 5.9 billion uncached input tokens and 690 million output tokens — around $165,000 at API pricing. The main portion of Mike’s port was 27 million tokens.
Six steps for large code migrations The process below has been generalized to be relevant to multiple languages and scenarios. For additional details, you can read Jarred’s blog . Prerequisites A prerequisite before starting on your migration project is to have a strong judge in place, otherwise you won’t have an exit condition or measure of success. The judge must be able to evaluate both the original code and the target code on equal terms. Test suites written in the original language will often depend on internal functions that won't exist in the target code. To build this judge: Categorize existing tests . Use Claude to identify which tests are expressible as external calls and which depend on internals that won't port. Rewrite for portability. Convert the external-facing tests into assertions that can run against both the original and the port. Use adversarial agents to verify the rewritten tests don't weaken the assertions. Validate the judge . Run it against the original code to confirm it passes. Then run it against deliberately broken code to confirm it fails — a judge that doesn't catch breakage isn't a judge. Jarred had a large test suite written in a third language (TypeScript), but that will not be the case for most projects. For his Python-to-TypeScript port, Mike created a parity harness of seven real-world scenarios and considered any behavior change a bug to be fixed. Before we get into each stage, this graphic may help you follow along. This mostly follows Jarred’s methodology, with reviews and gates at each stage. Mike followed a similar overall structure using similar loop workflows, but he ran the entire migration end to end, revised the rules and the workflow based on the results, and ran it again — discarding the output each time until the third run.
Explore more product news and best practices for teams building with Claude.
Transform how your organization operates with Claude
Product updates, how-tos, community spotlights, and more. Delivered monthly to your inbox.
Please provide your email address if you'd like to receive our monthly developer newsletter. You can unsubscribe at any time.
采集自 Claude Blog，由 collect_claude_blog.py 自动采集
Zero risk isn't the job: a CISO's guide to agentic AI¶
来源: Claude Blog 发布日期: Jul 17, 2026 采集时间: 2026-07-19 价值评分: 9.5/10 正文字数: ~21249 字符
摘要¶
Anthropic's Deputy CISO shares a four-question framework for assessing agentic AI risk, and walks through controls that keep agent deployments bounded and auditable.
正文内容¶
Anthropic's Deputy CISO, Jason Clinton, shares his team's lessons learned adopting agentic AI, and the risk assessment framework they've developed for building and deploying agents securely.
Security leaders are being asked to approve agentic AI use cases that did not even exist a few months ago. Boards want to know whether any of it is governed, and somewhere in your organization, an employee has already connected an agent to something without telling you. Saying “no” to these requests produces shadow adoption, which has zero telemetry and generally no off switch. Saying “yes” without controls produces incidents, and the first serious agent incident at your company will set your AI program back. A CISO’s responsibility in the age of agentic AI is not to achieve zero risk. Instead, our jobs are to make agentic risk legible and bounded. This way, we can deliberately accept what we can manage, so the business moves on our terms instead of around us. In this article, I share our framework for evaluating agents for security risk, explain what “bounded” means in practice, and preview where our work is headed. External risk from AI versus internal risk in the post-Mythos era In an earlier blog post , my colleagues and I shared how AI is collapsing the time between a vulnerability existing and a working exploit, highlighting how organizations can mitigate these risks. In the coming months, we expect that vast numbers of bugs that have sat unnoticed in code, sometimes for years, will be found by AI models and chained into working exploits. Frontier models like Claude Mythos Preview and Claude Mythos 5 are already finding serious vulnerabilities that years of human review missed, including in OpenBSD, the Linux Kernel and Mozilla Firefox . These are serious risks to any GRC program. Mitigating and closing vulnerability gaps, as well as for preparing for the coming wave of exploits, should be a top priority. For this topic, we have prepared a separate doc: Preparing your security program for AI-accelerated offense . We’ll focus on internal risks for this guide. Governing internal risks For many organizations, the most likely threat vector for agentic systems is a data leak enabled by connecting disparate systems through personal agents with insufficient oversight. Another concern is prompt injection : an attacker hides instructions inside content the agent reads, and the agent follows the attacker instead of the user. Any agent that touches untrusted content could then be exposed, depending on how robust the defenses of the model are. As models grow increasingly capable, they’re getting meaningfully better at resisting injection. While attack success rates keep falling , they’re not zero. There are many concerns outside of these two examples, and the deluge of new classes of concern can seem overwhelming. Four questions to ask When an agentic use case reaches our review process, we assess its risk by asking four questions: What untrusted content does it ingest? Untrusted means anything an attacker could plausibly write or alter, including outside email, the open web, third-party documents, or public repositories. If the answer is "nothing," the agent-specific risk is near zero and you should move quickly. What actions can it take, and on whose behalf? Read-only is a different concern from read/write. Tool calls, code execution, and network egress each widen the aperture. Every action happens under some identity, and you need to know whose. What is the blast radius if it is misaligned? Scope X severity is the quick calculation: did the bad actor or alignment incident have access to one file or the whole org? Would it be an anomaly, an annoyance, a data exposure, or a true incident? What observability do I have? Can you tell agent actions from user actions? Does it land in your SIEM? The four answers to these questions give you a picture of your risk, but the principle of least agency tells you what to do with it: grant the narrowest capability that still completes the task (see our Zero Trust for AI Agents white paper to learn more). Our default posture at Anthropic is admin-paced rollout: enable a small group, watch the telemetry, and then expand access. Apply these questions to a new paradigm for thinking about risky agentic systems. An agent that drifts out of alignment with your intent is indistinguishable from an insider attack. The security industry spent 2019-2022 formalizing insider risk as a discipline distinct from perimeter defense—recognizing that the most dangerous external attack vectoractor in a system is often one that compromises someone who already has legitimate access. The operational difference is response time: Ponemon Institute's 2026 Cost of Insider Risks report found organizations took an average of 67 days to contain an insider incident—even after years of investment in dedicated insider risk programs. At agent execution speeds, responses measured in days are too long. The agentic identity spectrum Everything we deploy sits at one of two ends of an identity access model spectrum. At one end is the system service account : a self-contained, single-purpose, least-privilege identity that does exactly one thing for the business, with no human identity attached. The incident-response agent (see below), a ticket triage agent, or an autonomous code reviewer are examples of these. Another example is Claude Tag , our new shared workspace agent that lets human teams collaborate with agents in shared workspaces like Slack by tagging in Claude. At the other end is the human credential . When an employee uses a chat interface or a personal agent harness like Claude Cowork on their laptop, the person at the keyboard is accountable for the outcome, the same way they are accountable for anything else done with their credentials. The middle of the spectrum, where an agent carries a person's delegated identity into systems that person is not watching, is where accountability gets ambiguous. Ambiguous accountability is how incidents become unexplainable. An agent that drifts out of alignment with your intent is indistinguishable from an insider attack. The security industry spent 2019-2022 formalizing insider risk as a discipline distinct from perimeter defense—recognizing that the most dangerous external attack vector in a system is often one that compromises someone who already has legitimate access. Ponemon Institute's 2026 Cost of Insider Risks report found organizations took an average of 67 days to contain an insider incident—even after years of investment in dedicated insider risk programs. At agent execution speeds, 67 days is the wrong unit of measurement entirely. Case study: an incident response agent More than a year ago, we pointed Claude at our incident response process. Anyone who has been on-call for a production application knows the problem: you’re paged at 2 a.m. about a security incident, you spin up an incident response channel, you pull in the right people, and get to work. This process is tedious, documentation-heavy, and fast-moving. But, with the right context about your production environment codebase, the majority of it can be automated. So we built an agent to do it. We gave the agent access to three tools: read-only access to our production logs, which contain no PII; access to Slack, to open the incident channel and run the process; and the ability to draft a Google Doc for the postmortem after the incident is resolved. We ran it through the four questions: Untrusted content: none. The inputs were our own logs and our own internal Slack, both inside the trust boundary, so an injection would require an insider or a compromised account rather than an anonymous attacker. Actions: reads everywhere, writes limited to new documents and Slack messages. No edits or deletes, no permission changes, no external endpoints. Blast radius: the worst outcome we could construct was some mildly sensitive log lines posted into an incident channel that was already locked down. Observability: every action landed in our SIEM, so anything unexpected would surface in minutes, not weeks. While the agent wasn’t risk-free, it operated on a bounded write surface with full audit coverage, which was a risk profile we were comfortable with. However, there’s an interesting addendum to this story: with each model release, the agent got smarter. In November 2025, we moved this agent from Claude Opus 4 to Claude Opus 4.5 and changed nothing else—no new tools, permissions, or prompts. Immediately after this, for the first time, the intelligence uplift alone was enough for the agent to notice, mid-incident, that it had already found the root cause in a stack trace and that, in the absence of the human who hadn't arrived yet, it could try to fix production on its own by reaching out to another agent that had the appropriate code access to produce the code change. Post hoc, we reviewed logs: we watched it work through this in the thinking traces: I have done what I was asked to do. The human is not here. What if I fixed the problem? Inside of Anthropic we have an internal variant of Claude Tag-like technology which can write code changes and upload them for human review. On its own, it reached out over Slack to this Claude Tag-like instance and asked it to write the fix. The fix went to a pull request that a human reviewed before pushing it to production. The expanded blast radius that came from this emergent agent-to-agent communication was itself governed by our principles: the worst that could happen would be that a code change would be uploaded which contained a production log line. This agent-to-agent communication is now a regular part of our incidence response root cause and remediation practices; all with human-on-the-loop monitoring. This emergent behavior taught us two things. First: new capabilities can show up within the boundaries of an agent deployment. It’s important to limit access and actions, not around what you believed today's model limits are. Second: controls are effective even with stochastic agents like this. The new behavior was human-on-the-loop because it happened in a Slack channel, and the only write-like action still required a human review. Today, outside of incidence response, agent-to-agent communication within chat channels, with human on-the-loop where people work, is the norm. Case study: Claude Cowork The incident response agent is a service account doing one job, in a bounded service account. Claude Cowork is at the human operator end of the spectrum: an employee at a keyboard is accountable for the outcome, and the agent then acts on their behalf, in systems they authorized—increasingly—running in the cloud. Claude Cowork's threat model is straightforward, because the agent is essentially Claude Code running either locally or inside a hosted interface. The desktop app remains required for local file access, browser use, and computer use; those capabilities reach the local machine directly and need the app to do so. The full system surface is therefore two-part: a (possibly remote) execution environment handling orchestration, MCP calls, and outbound network requests, and a local bridge for file and screen access. The four questions outlined above produce different answers for every Claude Cowork use case. But with the right controls in place, you can bound them to better control any possible risk. Each control below is stated twice, first as the requirement any agent environment should be able to meet and then as how it is enforced in Claude Cowork: Identity comes from your IdP: an agent's identity has to be issued and revoked where you already issue and revoke everything else, with your existing groups as the unit of policy. Claude Cowork uses SAML or OIDC for sign-in and SCIM for provisioning. On Enterprise plans, custom roles let you scope capability by group. Connector allowlists draw your data boundary: allowslists for connectors (MCPs) let you decide which systems the agent can reach. Claude Cowork uses a two-gate model: an admin enables each connector org-wide, and each user then individually authorizes their own account. There is a per-role connector control, so enabling a connector makes it available to everyone in that role (groups from your IdP can be assigned to roles). The admin decision about which connectors to turn on is also the decision about which data the agent can reach. Keep connectors on the corporate side of your corporate/production data boundary or, if they access information from untrusted sources, ensure that human review is required for any destructive or one-way decision. For example, if a personal agent is being used for email but using web search results as a part of its input, an excellent default is to only allow draft emails to be created and never sent externally, automatically, without human review. If data must cross the boundary, it should go through the DLP or DSPM controls. Per-tool, per-action approval is where risk reduction gets granular: the agent's tool list is a more fine-grained permission boundary, so you need to be able to remove any particular connector’s verbs/actions and not only that entire connector system. In Claude Enterprise Chat and Cowork, admins can now restrict which actions are available within each connector org-wide and per-role: allow drafting docs but never automatically send them, allow reads and searches but never deletes. If the failure mode that keeps you up at night is "the production database gets deleted," remove the delete verb from the agent's world entirely. It will never attempt an action that isn't in its tool list. (A note on this: Claude for Chrome and Claude Code enable more degrees of freedom and so are more risky, if not governed well. An agent could use an engineer’s browser to delete a production resource or their command line CSP tool to do the same. See our guide to securing Claude Code for more.) Sandboxed execution keeps the agent's working environment away from production credentials: one principle that we hold constant at Anthropic is that the environment the agent loop runs in should never hold a credential worth stealing. In Claude Cowork's remote sessions, the agent loop runs in an isolated, temporary sandbox on Anthropic-managed infrastructure. Connector authorization tokens never enter the sandbox, because connector calls are made via a reverse proxy that injects real credentials, so the sandbox never holds a credential that can be exfiltrated. As of July 2026, more than 50% of all code submitted for pull requests at Anthropic is authored by our internal version of a Claude Tag-like system. The primary reasons we can run that safely are that all of it happens in ephemeral VMs separated from our production keys and accounts, with a human review before anything lands. Egress allowlisting is your strongest control against prompt injection: all traffic leaving the agent's execution environment
采集自 Claude Blog，由 collect_claude_blog.py 自动采集
Claude in Microsoft Foundry is now generally available¶
来源: Claude Blog 发布日期: Jun 29, 2026 采集时间: 2026-07-19 价值评分: 9.0/10 正文字数: ~2017 字符
摘要¶
Starting today, Claude models are generally available in Microsoft Foundry, hosted on Azure.
正文内容¶
Starting today, Claude models are generally available in Microsoft Foundry, hosted on Azure. Claude runs in your Azure environment with the authentication, billing, and governance controls your teams already use. You can choose where inference is processed, including a US data zone for teams with data residency requirements. Anthropic operates the inference and is the data processor.
Build with Claude through your Azure account To start, Claude Opus 4.8 and Claude Haiku 4.5 are available in the Messages API, with core capabilities like prompt caching and extended thinking to support use cases ranging from coding and agentic work to complex reasoning. We'll continue expanding what's available in Foundry over time. Claude in Microsoft Foundry is Azure-native, working with your existing Azure identity, networking, and governance controls. You receive a single consolidated invoice, and for eligible customers with a Microsoft Enterprise Agreement, Claude usage draws down a Microsoft Azure commitment. Run Claude in Azure, operated by Anthropic There are two ways to run Claude in Microsoft Foundry. Choose hosted on Azure when running in your Azure environment matters, with Azure authentication, billing, governance, and a US data zone. Choose hosted on Anthropic (previously the Foundry Preview) when you need the full set of API features or a model that is not yet available on Azure. Over time, we aim to have feature and model parity between the hosted on Azure offering and the Anthropic-hosted one. Get started Claude in Microsoft Foundry is generally available today. To get started, open Claude in Microsoft Foundry or explore the documentation .
Explore more product news and best practices for teams building with Claude.
Transform how your organization operates with Claude
Product updates, how-tos, community spotlights, and more. Delivered monthly to your inbox.
Please provide your email address if you'd like to receive our monthly developer newsletter. You can unsubscribe at any time.
采集自 Claude Blog，由 collect_claude_blog.py 自动采集
Choosing a Claude model and effort level in Claude Code¶
来源: Claude Blog 发布日期: Jul 07, 2026 采集时间: 2026-07-19 价值评分: 9.0/10 正文字数: ~2545 字符
摘要¶
Anthropic's guide to the Claude Code effort level and model selection: when to raise or lower effort—low, medium, high, and max—and how to choose between Claude Fable, Opus, and Sonnet.
正文内容¶
Key takeaways : Claude model selection chooses the set of fixed weights, or the overall capability range of the model. While models can be provided context or steered, the model’s overall knowledge base and capabilities are set. Effort means more than "thinking time.” It controls how much work Claude does on your request overall including the number of files read, tools used, and how many steps it takes before it checks back in with you. Choose smaller models for more routine tasks and larger models for more complex or ambiguous tasks. Start with default effort levels for each model and tune as a general preference based on the type of work you do rather than task-by-task. If Claude has all the pertinent context, clearly tried, and still got it wrong, that's a signal to pick a more capable model. If Claude got it wrong by skipping a file, not running the tests, or bailing on a refactor partway through, pick a higher effort level. Claude Code effort level and model selection Claude Code gives you two settings that appear to "make the answer better": the model setting and the effort level. You may expect that larger models like Claude Fable 5 provide a smarter output than Claude Sonnet, and a higher effort level means Claude thinks longer before it answers. The first assumption is accurate. Our largest models are more capable, according to industry-standard benchmarks. But effort means more than just "thinking time." Effort level controls how much work Claude does on your request overall. This does include how long the model thinks, but also: How many files it reads; How much it verifies; and How far it pushes through a multi-step task before checking in with you. At a higher effort, Claude will take more of those actions (for example, read files, run tests, and double-check) before it comes back to you. At lower effort, it would rather ask you for more context than spend tokens figuring something out on its own.
How model selection works When you press enter, Claude Code assembles your message together with the system prompt, tool definitions, your CLAUDE.md, the conversation history, and any files in context. All of this is sent as one request to the API.
Explore more product news and best practices for teams building with Claude.
Transform how your organization operates with Claude
Product updates, how-tos, community spotlights, and more. Delivered monthly to your inbox.
Please provide your email address if you'd like to receive our monthly developer newsletter. You can unsubscribe at any time.
采集自 Claude Blog，由 collect_claude_blog.py 自动采集
Bringing Code Review to Claude Code¶
来源: Claude Blog 发布日期: Mar 09, 2026 采集时间: 2026-07-19 价值评分: 9.0/10 正文字数: ~729 字符
摘要¶
Claude Code now dispatches a team of agents on every PR to catch bugs that skims miss. Available in research preview for Team and Enterprise.
正文内容¶
Practical guidance on how to structure agent tasks using three common workflow patterns, with tradeoffs and benefits for each.
Today we're introducing Code Review, which dispatches a team of agents on every PR to catch the bugs that skims miss, built for depth, not speed. It's the system we run on nearly every PR at Anthropic. Now in research preview for Team and Enterprise.
Explore more product news and best practices for teams building with Claude.
Transform how your organization operates with Claude
Product updates, how-tos, community spotlights, and more. Delivered monthly to your inbox.
Please provide your email address if you'd like to receive our monthly developer newsletter. You can unsubscribe at any time.
采集自 Claude Blog，由 collect_claude_blog.py 自动采集