cloudflare·Mar 11, 2026·3 min readCurated summary

AI Security for Apps is now generally available

Cloudflare’s AI Security for Apps is now generally available to help organizations discover, detect, and mitigate threats targeting AI-powered applications. The service protects AI endpoints through Cloudflare’s reverse proxy and integrates AI-specific signals with existing WAF controls. New GA features include free endpoint discovery for all customers, custom topic detection, and custom prompt extraction capabilities. ## Why AI Applications Create a New Attack Surface - Traditional applications follow predictable workflows, while AI applications accept natural-language input and produce probabilistic outputs. - Attackers can exploit models through: - Prompt injection - Sensitive information disclosure - PII exposure - Toxic or off-policy content - Unbounded resource consumption - Risks become more serious when AI agents can call tools to issue refunds, change accounts, apply discounts, or access customer data. - Organizations may struggle to maintain consistent safeguards as teams rapidly adopt new models and providers. ## AI Endpoint Discovery - AI Security for Apps automatically identifies LLM-powered endpoints across web properties, regardless of hosting location or model provider. - Discovery analyzes endpoint behavior rather than relying only on paths such as `/chat/completions`, since AI may also power search, valuation, and recommendation features. - Discovered endpoints appear under **Security → Web Assets** with the `cf-llm` label. - Discovery is now free for Cloudflare Free, Pro, and Business customers: - Free-plan discovery begins when users open the Discovery page. - Paid plans receive recurring background discovery. - Sufficient valid traffic is required to confidently identify AI-powered endpoints. ## Always-On AI Threat Detection - Prompts sent to discovered AI endpoints are evaluated by multiple detection modules. - Built-in protections cover: - Prompt injection - PII exposure and extraction - Sensitive or toxic topics - Detection results are attached as metadata and can be used in custom WAF rules. - Cloudflare intends to use its global network data to identify emerging attack patterns across millions of sites. ## Custom Topics and Prompt Extraction - Custom topics allow organizations to define their own sensitive categories, such as securities, patient data, or competitor products. - Each prompt and response receives a relevance score that can be logged, blocked, or handled through custom policies. - Custom prompt extraction identifies where prompts are located in request bodies, supporting formats such as: - `$.messages[*].content` - `$.requests[*].params.messages[*].content` - `$.property_description` - Standard formats from providers including OpenAI, Anthropic, Google Gemini, Mistral, Cohere, xAI, and DeepSeek are supported. - Unknown payload formats use a default-secure approach that scans the full request body, which may create false positives. - Cloudflare plans to support user-defined JSONPath expressions and automated prompt learning to improve accuracy. ## WAF-Based Mitigation - Organizations can block, log, or customize responses to detected threats using the existing Cloudflare WAF rule builder. - AI-specific signals can be combined with broader request data, including IP reputation, browser fingerprints, bot activity, and attack history. - This lets security teams distinguish isolated suspicious prompts from attacks associated with broader malicious behavior. ## Expanding Partnerships - IBM has selected Cloudflare to provide AI security for its cloud customers. - Cloudflare and Wiz are partnering to provide mutual customers with a unified view of AI security posture. - The service is being extended through Cloudflare’s broader security ecosystem. Organizations adopting AI agents should first inventory their AI endpoints, then apply detection and WAF policies tailored to their data, users, and business risks. Cloudflare’s unified approach is designed to provide a practical fail-safe as AI deployments expand.

Read original(opens in new tab)

Large Language ModelsDatabase DesignCloudflareAi Security+4

line·Mar 10, 2026·4 min readCurated summary

Journey Toward Perfect AI Guardrails

NeurIPS 2025 research shows that AI safety is moving beyond simple post-training alignment and output filtering toward system-level, modular defenses. New approaches intervene in reasoning, multimodal interpretation, policy enforcement, and continuous evaluation to balance safety with latency and usefulness. The central conclusion is that deployable AI requires adaptable guardrails designed for real-world systems, not isolated attack benchmarks. ## The Shift Toward Practical AI Safety - Guardrails protect AI services from harmful instructions, privacy leaks, confidential-data exposure, bias, prompt injection, and other failures. - NeurIPS 2025 reflects a broader shift: - From post-training safety tuning to intervention in reasoning mechanisms. - From text-only LLMs to VLMs, RAG systems, and reasoning models. - From laboratory attack scenarios to the practical balance between utility and safety. - The article focuses on guardrail frameworks, multimodal moderation, prompt injection and jailbreaks, hallucinations, and over-refusal. ## Modular Guardrail Frameworks **PRIME Guardrails: A General, Low-Latency Safety Framework for Generative AI** addresses the trade-off between rigorous safety checks and response latency through a modular architecture: - **Policy specification:** Declarative, human-readable rules separate policies from model parameters, allowing legal or policy teams to control behavior. - **Risk sensing and scoring:** Asynchronous detectors combine lexical rules, semantic similarity, and lightweight classifiers. Early exit blocks obvious attacks quickly while allowing domain-specific calibration. - **Intervention router:** A deterministic controller chooses whether to allow, rewrite, or reject an interaction based on policies and risk scores. - **Monitoring and memory:** Lightweight records preserve decisions and rejection reasons for predictability and auditing. - **Evaluation and evolution:** Red-team recipes and automated vulnerability testing help the system adapt to new attack methods. The framework supports defense in depth without running every expensive safety mechanism sequentially. Its modularity, auditing capabilities, and continuous-evaluation loop make it suitable for production environments. ## Turning Governance Policies into Code **Policy-as-Prompt: Turning AI Governance Rules into Guardrails for AI Agents** converts informal organizational materials into runtime-enforceable controls. - The framework analyzes sources such as PRDs, technical design documents, regulations, and source code. - It builds a **source-linked policy tree** connecting individual rules to their original documents. - The policies are compiled into lightweight prompt-based classifiers. - When an agent rejects a request, the system can trace the decision back to its legal or organizational basis. - The approach helps enforce: - Least-privilege access. - Data minimization. - Restrictions on out-of-scope tasks. - Protection against prompt injection. - It may be especially valuable in regulated industries such as finance and healthcare, where frequently changing policies create substantial technical debt. ## Multimodal Safety and VLM Reasoning Vision-language models create new safety challenges because harmful meaning can emerge from interactions between images and text. **GuardReasoner-VL: Safeguarding VLMs via Reinforced Reasoning** trains models to reason about combined modalities rather than classifying each input independently. - It addresses cases where harmless text obscures harmful visual content, such as an image of a bloodied knife paired with “cooking.” - Its GRPO-based training process includes: - **Safety-aware data concatenation** to create difficult examples containing hidden or mixed harmful content. - **Dynamic clipping** that encourages exploration early in training and tighter refinement later. - **Length-aware safety rewards** that reward concise conclusions supported by reasoning. - The method aims to detect subtle harms such as hate speech hidden in memes and visual metaphors. ## Hidden Vulnerabilities in Multimodal Training Data **VLMs can Aggregate Scattered Training Patches** demonstrates that filtering training images may not be sufficient. - A harmful image can be divided into individually innocuous patches and included in training. - A VLM may reconstruct the harmful concept by associating patches that share the same text label. - The paper calls this behavior **visual stitching**, related to cross-sample reasoning and inductive out-of-context reasoning. - Text labels such as “safe” or “unsafe” can help the model connect fragmented visual information and infer the original image-level meaning. - This suggests that safety evaluations must inspect not only final outputs but also: - Input-processing pipelines. - Cross-sample interactions. - Internal or latent representations. The available article ends while introducing research on distorted safety perception, so that section cannot be summarized further from the provided text. In practice, organizations should combine modular, low-latency enforcement with traceable policy management and multimodal evaluations that test hidden interactions—not just obvious harmful prompts or images.

Read original(opens in new tab)

Large Language ModelsDatabase DesignMachine LearningGenerative AI+4

datadog·Mar 9, 2026·3 min readCurated summary

When an AI agent came knocking: Catching malicious contributions in Datadog’s open source repos

Datadog describes how AI-powered attackers targeted its open-source repositories through malicious issues, pull requests, and comments. The campaign, attributed to the “hackerbot-claw” agent, focused on weaknesses in GitHub Actions and LLM-powered workflows. Datadog’s LLM-based review system and layered CI security controls detected the activity and helped limit its impact, while prompting further hardening. ## Why Open-Source Repositories Attract Attackers - Public repositories are attractive targets because automated CI/CD pipelines often build and execute code from external contributions. - Common attack techniques include: - Injecting user-controlled values, such as PR titles, into workflow scripts. - Using indirect poisoned pipeline execution to introduce malicious dependencies or build instructions. - Abusing `pull_request_target` workflows, which may run untrusted code with elevated permissions. - Prompt-injecting LLM-powered GitHub Actions used for issue triage, labeling, or code assistance. - Attackers may also disguise malicious changes through: - Large or obfuscated diffs. - Invisible Unicode characters. - Malicious libraries. - Imposter commits that resemble legitimate dependency references. ## Datadog’s LLM-Based Contribution Detection - Datadog receives dozens of external PRs each week across projects such as the Agent, tracers, SDKs, Vector, chaos-controller, and Stratus Red Team. - Its BewAIre system monitors GitHub events and selects security-relevant activity, including PRs and pushes. - BewAIre: - Extracts, normalizes, and enriches code diffs. - Sends them through a two-stage LLM pipeline. - Classifies changes as benign or malicious. - Produces a structured explanation for each verdict. - Malicious verdicts are forwarded to Datadog Cloud SIEM, where detection rules create enriched signals for the Security Incident Response Team to investigate. ## Hardening CI and Development Workflows - Datadog reduces the potential impact of successful attacks through multiple preventive controls: - Its `dd-octo-sts-action` generates minimally scoped, short-lived GitHub credentials using OIDC. - Long-lived and overly broad personal access tokens and GitHub Apps are being replaced. - Unused GitHub Actions secrets are identified and removed across thousands of repositories. - Organization-wide controls enforce branch protection, mandatory PR approval, commit signing, and lower-privilege default `GITHUB_TOKEN` permissions. - Engineers are provided with documented best practices and secure “golden paths” for CI development. ## The Hackerbot-Claw Campaign - Modern AI models are increasingly capable of offensive security tasks, especially when given tools, feedback loops, and autonomy. - StepSecurity reported an AI agent attacking open-source CI systems on March 1. - Between February 27 and March 2, the actor: - Opened 16 pull requests. - Created two issues and eight comments. - Targeted nine repositories across six organizations. - The activity was later linked to the hackerbot-claw agent, whose GitHub account was removed. - Datadog’s investigation began after BewAIre alerted the team to a suspicious contribution in the newly public `datadog-iac-scanner` repository on February 27. ## Practical Takeaway Organizations that accept public contributions should combine automated, AI-assisted review with least-privilege credentials, strict workflow permissions, secret management, mandatory approvals, and human incident response. Detection alone is insufficient; CI pipelines should be designed so that a malicious contribution has limited access and minimal opportunity to compromise secrets or production systems.

Read original(opens in new tab)

Large Language ModelsDatabase DesignCI/CDOpen Source+4

github·Mar 6, 2026·3 min readCurated summary

How to scan for vulnerabilities with GitHub Security Lab’s open source AI-powered framework

GitHub Security Lab’s open-source Taskflow Agent uses AI-driven, multi-step auditing workflows to find high-impact vulnerabilities in web applications and open-source projects. The authors report more than 80 vulnerabilities, including authorization bypasses and private-data disclosures, with about 20 already disclosed. They argue that carefully designed taskflows and prompts can give LLMs enough freedom to discover vulnerabilities while reducing hallucinations and false positives. ## Running the Audits - The taskflows are available in the [`seclab-taskflows`](https://github.com/GitHubSecurityLab/seclab-taskflows) repository. - To run an audit: 1. Start a Codespace for the repository. 2. Wait for initialization. 3. Run `./scripts/audit/run_audit.sh myorg/myrepo`. - Audits may take one or two hours on a medium-sized repository. - Results are stored in SQLite and can be inspected in the `audit_results` table. - Rows marked with a check in `has_vulnerability` indicate potential findings. - A GitHub Copilot license and premium model requests are required. - The same repository should be audited multiple times because LLM results are nondeterministic; using different models may reveal different vulnerabilities. - Private repositories require changes to the Codespace configuration to grant access. ## How Taskflows Work - Taskflows are YAML files defining ordered tasks and dependencies for an LLM. - The `seclab-taskflow-agent` runs tasks sequentially and passes their results between stages. - Repository audits begin by dividing the codebase into functional components. - For each component, context is gathered, including: - Untrusted-input entry points - Intended privilege levels - Component purposes and behavior - This context is stored in a database for later auditing tasks. - Separate tasks can: - Suggest generic security issues - Carefully verify each suggested issue - Focus on specific vulnerability classes - Tasks can be reused across many components asynchronously through templated prompts and component-specific substitutions. ## Why Use Multiple Tasks - A single large prompt is less reliable because LLMs may omit steps in complex, multi-stage investigations. - Taskflows help control, debug, and structure the process even when models provide large context windows. - Breaking work into stages allows each result to be reviewed and reused as context for subsequent analysis. - Repeated task execution across components makes the approach scalable for large repositories. ## General Security Auditing - The team initially used the framework to triage CodeQL alerts, where strict instructions and predefined criteria helped limit false positives. - General auditing is more difficult because the LLM must search broadly for vulnerabilities rather than evaluate known alerts. - Greater freedom increases the risk of hallucinations and unexploitable findings. - The authors’ approach uses taskflow design and prompt engineering to preserve a high true-positive rate while allowing the model to investigate diverse security issues. ## Reported Vulnerabilities - The taskflows have found more than 80 vulnerabilities in open-source projects. - Many reported issues are high-impact, including: - Authorization bypasses - Information disclosure - Logging in as another user - Accessing private user data - Examples include exposing personally identifiable information in ecommerce shopping carts and authenticating to a chat application with arbitrary passwords. - The authors manually verify findings before reporting them and maintain an advisories page as disclosures become public. The practical recommendation is to run the open-source taskflows on your own projects, repeat audits with different models, and manually validate every result. The framework is intended to improve through shared taskflows, prompts, and findings across the security community.

Read original(opens in new tab)

Large Language ModelsOpen SourceGithub CopilotPrompt Engineering+4

line·Mar 6, 2026·3 min readCurated summary

On-Device Image Model Training for Mess

This post describes an on-device image captioning system for mobile messenger apps. Because autoregressive vision-language models took more than five seconds to generate captions, the team replaced them with a non-autoregressive decoder, reducing latency to roughly 200–400 ms. They then used LLM-based acceptance evaluation, caption re-generation, and multi-stage knowledge distillation to improve quality while keeping the model at 172 MB. ## Why Conventional Captioning Was Unsuitable - Models such as BLIP-2, MobileVLM, PaliGemma, and MiniCPM were too large or slow for mobile deployment. - BLIP-1 was selected as a practical baseline because of its smaller size and clear licensing, but still required more than five seconds after quantization. - Autoregressive decoding generates tokens sequentially, requiring one decoder pass per token. - On a Samsung Galaxy Fold 4, the initial model required about 142 ms per token, or approximately 2.8 seconds for 20 tokens. - Mobile UX required stable latency in the hundreds of milliseconds, including cold-start and variable-device conditions, so simple model compression was insufficient. ## Non-Autoregressive Caption Generation - The system predicts all caption tokens in parallel using a fixed set of learnable query tokens. - This changes the decoding cost from roughly O(T) for autoregressive generation to near O(1) through parallel processing. - The architecture consists of: - An image encoder reused from the previous system - Image embeddings injected as a prefix, following the ClipCap approach - A 66.4-million-parameter Transformer-based text decoder - Twenty learnable query tokens for short captions - Query-CTC loss addresses the alignment problem caused by predicting tokens simultaneously. - The resulting model generated captions in about 200 ms, achieving the required speed improvement. ## Speed Improved, but Caption Quality Declined - Standard metrics such as CIDEr and CLIPScore appeared acceptable. - Manual inspection revealed frequent: - Repeated words, such as “a desk with a computer on a desk” - Spelling errors, such as “a people ons” - Grammatical problems - Incomplete captions, such as “a” - These defects made the model unsuitable for direct use in a messaging product. ## LLM-Based Acceptance Evaluation - The team introduced an “accept ratio” based on GPT-4o mini judgments. - Captions were classified as either `accept` or `non-accept`. - The evaluation checked for: - Duplicate content - Errors - Clarity and grammatical correctness - This better reflected production usability than conventional image-captioning benchmarks. - The low acceptance rate confirmed that CIDEr and CLIPScore alone could not measure whether captions were appropriate for users. ## Data Quality and Knowledge Distillation - Analysis showed that the training data contained inconsistent and noisy captions: - A mixture of very short and overly long descriptions - Unnecessary OCR-like attempts to describe text in images - Uneven language quality - The smaller 66.4-million-parameter model also had less representational capacity than BLIP-1’s 110 million parameters. - Generating an entire sentence in one pass was especially difficult for the compact non-autoregressive model. - The training pipeline was redesigned as an iterative quality-improvement loop: - Train a baseline using the original data - Identify failures with LLM-based acceptance evaluation - Re-caption poor-quality training examples - Distill knowledge from a larger teacher model into the student model - Replace or refine rejected samples and repeat - Architectural scaling and metric optimization did not consistently improve acceptance rates, while re-captioning and knowledge distillation produced more meaningful gains. The practical recommendation is to design on-device captioning around the actual product experience: prioritize parallel decoding for latency, measure quality with production-oriented acceptance criteria, and use carefully curated data plus knowledge distillation to make compact models reliable.

Read original(opens in new tab)

Large Language ModelsDatabase DesignKnowledge DistillationNon Autoregressive+3

google·Mar 4, 2026·3 min readCurated summary

Teaching LLMs to reason like Bayesians

LLMs often struggle to update their beliefs as new evidence arrives, relying instead on simplistic heuristics. Google Research tested whether training models to imitate an optimal Bayesian assistant could improve this capability. The results show that Bayesian teaching substantially improves recommendation accuracy, adaptation across interactions, and generalization to other tasks—more effectively than training on always-correct answers. ## Testing Bayesian Reasoning in LLMs - Researchers created a five-round flight recommendation task involving three options with different: - Departure times - Flight durations - Number of stops - Costs - Simulated users had hidden preferences, such as strong, weak, or no preference for high or low values of each feature. - After every recommendation, the user revealed the correct choice, giving the assistant new evidence. - The benchmark compared: - Off-the-shelf LLMs - Human participants - An optimal Bayesian assistant - The Bayesian assistant maintained a probability distribution over possible user preferences and updated it using Bayes’ rule. - Most LLMs performed substantially worse and often stopped improving after the first interaction, showing limited ability to incorporate information over time. - Humans improved more than most LLMs but still failed to match the Bayesian assistant. ## Bayesian Teaching Framework - Bayesian reasoning requires an agent to: - Start with a prior belief about the world - Incorporate new evidence - Produce a posterior belief - Use that posterior as the prior for future reasoning - For LLMs, the “world state” includes facts, relationships, concepts, and inferred user preferences. - Researchers used supervised fine-tuning on many simulated user interactions to teach models this update process. ## Oracle Teaching vs. Bayesian Teaching - **Oracle teaching** trained models on interactions with an assistant that knew the user’s preferences perfectly and always selected the correct option. - **Bayesian teaching** trained models to imitate an assistant that estimated preferences probabilistically and sometimes made mistakes, especially during early uncertain rounds. - The researchers argued that Bayesian examples better preserve uncertainty and demonstrate how beliefs should change as evidence accumulates. - This approach resembles knowledge distillation: the LLM learns to reproduce the predictions of a more principled teacher rather than memorizing only correct outcomes. ## Results and Generalization - Both fine-tuning strategies improved performance compared with the original LLMs. - Bayesian teaching consistently outperformed oracle teaching. - Models trained on Bayesian predictions more often agreed with the optimal Bayesian assistant. - Improvements extended beyond the original flight recommendation task, suggesting the models learned a broader approximation of probabilistic reasoning rather than merely memorizing task-specific patterns. - The findings indicate that LLMs can acquire reasoning strategies from examples and apply them in new domains. The practical implication is that training models on the behavior of an optimal probabilistic reasoner may be more effective than supplying only correct answers. For agents that must learn user preferences or update beliefs over time, examples that explicitly preserve uncertainty and demonstrate evidence-based belief revision could produce more reliable behavior.

Read original(opens in new tab)

Large Language ModelsSupervised Fine TuningBayesian InferenceProbabilistic Reasoning+3

cloudflare·Mar 3, 2026·3 min readCurated summary

How Cloudy translates complex security into human action

Cloudy is Cloudflare’s LLM-powered explanation layer for Cloudflare One, translating complex security detections into clear, actionable guidance. It helps security teams understand why emails or SaaS findings were flagged and helps end users make better decisions in real time. Its integration with Phishnet aims to reduce unnecessary SOC submissions while preserving strong protection against genuine threats. ## Turning Complex Detections into Human Guidance - Email and CASB systems analyze numerous signals, including sender reputation, authentication, links, infrastructure, behavior, misconfigurations, and exposed data. - Traditional detections may correctly identify risk without clearly explaining the reasoning. - Cloudy converts machine-learning outputs into concise explanations for both administrators and nontechnical users. - For Email Security, it explains why messages are classified as Malicious, Suspicious, Spam, Bulk, or Spoof. - For CASB, it is intended to clarify the risk and remediation path for SaaS findings. ## The Challenge for Email Users and SOC Teams - Users increasingly serve as an additional defense layer against social engineering and impersonation attacks. - Periodic security training and phishing simulations do not provide enough context when users encounter real messages. - This creates two problems: - Some users report nearly every questionable email, overwhelming SOC queues. - Others interact with risky messages because no clear warning appears at the moment of decision. - Excessive reporting creates backlogs and slows investigations of genuinely dangerous emails. ## Cloudy in Phishnet - Cloudy will be integrated into the Phishnet reporting workflow for Microsoft. - When users report a message, they will receive a simplified, plain-language explanation of the relevant security signals. - The goal is to help users decide whether a message is truly suspicious and reduce unnecessary escalations. - This allows SOC teams to focus on messages requiring investigation while making users more effective participants in security operations. ## How the Explanation Pipeline Works - A Phishnet report triggers a Cloudflare Workers-based workflow. - The workflow aggregates outputs from multiple detection models, including: - Sender reputation - Domain and infrastructure characteristics - SPF, DKIM, and DMARC authentication results - Link and content analysis - Behavioral indicators - Workers AI processes these structured signals using purpose-built prompts. - The prompts generate a natural-language explanation rather than changing the original message classification. - The experience is optimized for end users, avoiding overly technical terms such as ASNs, IP reputation, and raw authentication failures. ## Translating Technical Signals - An SPF failure becomes: “This email failed a sender verification check.” - A DKIM failure is explained as a failed message-integrity check that may indicate tampering. - A DMARC failure indicates that the sender’s domain could not confirm the email’s legitimacy. - These translations preserve the meaning of the underlying detections while making them understandable to nontechnical recipients. Cloudy’s practical value is its ability to connect sophisticated security analysis with immediate human decision-making. Embedding understandable explanations directly into Phishnet should improve user judgment, reduce SOC noise, and make complex detections more actionable without altering the underlying security verdict.

Read original(opens in new tab)

Large Language ModelsMachine LearningCloudflareCloudflare Workers+4

cloudflare·Mar 3, 2026·3 min readCurated summary

From reactive to proactive: closing the phishing gap with LLMs

Cloudflare argues that email security must move beyond reacting to user-reported phishing misses. LLMs can analyze millions of emails, reveal emerging threat patterns that traditional systems overlook, and guide specialized detection models before attacks become widespread. Its Sales Outreach phishing program reportedly reduced average daily reported misses by 20.4% from Q3 to Q4 2025, with a further two-thirds decline in Q1 2026. ## The Blind Spot in Reactive Defense - Traditional systems improve mainly after users report messages that were incorrectly classified as clean. - This feedback is valuable but inherently delayed: it reveals attacks that already succeeded. - The authors compare this problem to Abraham Wald’s World War II aircraft analysis: - Engineers studied bullet holes on returning planes. - Wald identified the missing data—the damage on planes that never returned. - Email security faces the same challenge because undetected threats are largely invisible. ## Mapping Threats with LLMs - LLMs can interpret context, intent, urgency, deception, and other nuanced characteristics in natural-language emails. - Cloudflare processes millions of unwanted messages daily, making manual classification and detailed threat mapping impractical. - LLM-generated categories expose emerging patterns and persistent trends, including: - `PrizeNotification` - `SalesOutreach` - These tags give analysts near-real-time, high-fidelity signals and reduce the need for manual investigation. - The resulting intelligence helps Cloudflare create or retrain targeted machine-learning models before threats become widely visible through customer reports. ## Detecting Sales Outreach Phishing - Sales Outreach phishing imitates legitimate B2B communication, using offers, special deals, or transactional requests to encourage malicious clicks or credential disclosure. - After identifying it as a major threat category, Cloudflare used LLM tags to build a continuously growing corpus of relevant messages. - Training data was grouped by linguistic and structural traits such as: - Persuasive framing - Manufactured urgency - Transactional language - Subtle social proof - Feature extraction focused on sentiment and intent rather than static indicators. - A specialized sentiment-analysis model was trained for Sales Outreach behavior instead of overloading a general phishing classifier. ## From Classification to Enforcement - The specialized model produces a risk score based on how closely an email matches known Sales Outreach patterns. - That score is combined with other signals, including: - Sender reputation - Link behavior - Historical context - Messages can then be allowed, quarantined, or blocked. - LLMs serve as the discovery layer, identifying new language variants, while the specialized model provides fast, scalable enforcement. - Newly detected examples continuously feed back into the pipeline as attackers change their tactics. ## Reported Results - Cloudflare says the proactive approach reduced customer-reported Sales Outreach misses. - Average daily submissions fell from 965 in Q3 2025 to 769 in Q4 2025. - This represented a 20.4% quarterly reduction. - The company reports that average daily submissions decreased by another two-thirds in Q1 2026. - Fewer misses mean less analyst work, fewer interruptions for users, and fewer opportunities for phishing messages to reach inboxes. Cloudflare’s approach recommends combining broad LLM-based threat discovery with narrowly focused detection models. This creates a proactive feedback loop that can identify and address emerging phishing techniques before relying on large volumes of user-reported failures.

Read original(opens in new tab)

Large Language ModelsMachine LearningNatural Language ProcessingDeep Learning+3

microsoft·Feb 27, 2026·3 min readCurated summary

Engineering and algorithmic interventions for multimodal post-training at Microsoft scale

At production scale, post-training multimodal agents fail for reasons that standard reinforcement-learning literature often overlooks. Heterogeneous tasks, long tool-use trajectories, noisy reward sources, and strict latency and safety requirements can make aggregate reward look healthy while the policy gradient becomes uninformative and important capabilities regress. The post presents interventions designed to preserve useful advantage signals as scale, task diversity, and interaction horizons grow. ## Production-Scale Challenges - Copilot agents must simultaneously handle: - Tool orchestration - Enterprise documents and mixed-media inputs - Content moderation - Multi-step execution - Trajectories range from roughly 100 to more than 2,000 tokens and span 6 to 25+ interaction steps. - Rewards come from programmatic checks, human judgments, and implicit usage signals, each with different noise and latency. - A single scalar reward can hide regressions in robustness, long-horizon planning, or downstream task success. - Aggregate reward may rise while gradient updates increasingly depend on a small, unrepresentative subset of trajectories. ## Staged Objective Curriculum - The team separates: - **Verifiable objectives**, such as tool syntax and format compliance - **Preference objectives**, such as tool choice and response quality - Training uses only verifiable objectives during the first 30%. - Preference signals are then introduced linearly. - An entropy floor, implemented through a KL penalty activated below a threshold, prevents premature policy collapse. - Entropy bonuses were insufficient because the issue was not simply exploration; optimization was favoring behaviors that were easy to score. - A 30% warmup worked better than 10% or 50% across task families. - Early text-only supervision could also activate multimodal capabilities more reliably than noisy direct multimodal supervision, assuming adequate cross-modal alignment from pretraining. ## Adaptive Curriculum Based on Estimator Health - The team monitors effective sample size (ESS): `ESS = (Σ wᵢ)² / Σ wᵢ²` - ESS measures how many trajectories meaningfully contribute after importance weighting. - ESS falling below 20% of nominal batch size predicted learning stalls by about 35 epochs. - When ESS drops, the system: - Injects near-miss trajectories from a reservoir buffer - Temporarily increases the KL penalty to limit policy drift - Near-misses worked better than hard negatives because they preserve useful distinctions near the decision boundary instead of merely pushing the policy away from failure. - The intervention maintained ESS above 70%, with approximately 15% additional memory usage. ## Variance-Corrected Normalization - Per-task gradient normalization balances task magnitudes but ignores variance within each task. - Broad categories such as “coding” may contain trajectories ranging from 100 to 2,000 tokens, with very different variance. - Importance weighting can cause long trajectories to dominate the effective gradient even after task-level normalization. - The excerpt ends while introducing the team’s variance-correction approach, so its implementation and results are not included here. The central recommendation is to treat estimator health—not just reward and task metrics—as a first-class training signal. Monitoring ESS, controlling objective timing, and accounting for trajectory variance can help prevent healthy-looking dashboards from masking policy collapse and capability regressions.

Read original(opens in new tab)

Large Language ModelsReinforcement LearningPost TrainingAgentic Systems+3

daangn·Feb 27, 2026·5 min readCurated summary

Things I learned using 2

Karrot’s Taxonomy team built an LLM-powered system to classify marketplace posts, group activities, and local businesses into a shared category and attribute structure. After finding that manually managed taxonomies and event-only pipelines were difficult to scale, they created a configurable Taxonomy Management System using Dataflow/Beam, BigQuery, Kafka, and multiple LLM strategies. The system emphasizes scalable inference, rapid evaluation, multilingual support, and continuous taxonomy expansion. ## What a Taxonomy Is and Why It Matters - A taxonomy is a hierarchical category system, such as `Outerwear > Padding/Down > Long Padding`. - It can also include attributes that describe an item’s characteristics: - Category: long padding - Attributes: brand=Nike, color=black, material=polyester - A consistent taxonomy acts as a shared language across: - Search, including parent and child-category expansion - Recommendations and diversity controls - Advertising and targeting segments - Analytics and machine-learning features ## Karrot’s Taxonomy Challenges - Karrot manages roughly 1,400 marketplace categories across up to three levels. - Users are not required to manually select highly detailed categories because that would increase posting friction and produce unreliable labels. - Earlier systems used a Golang Kafka consumer to receive posting events and extract categories with an LLM. - This approach had several limitations: - Taxonomy definitions were managed separately by different teams. - Categories alone could not express useful properties such as season or material. - Batch processing and backfilling were difficult. - Expanding to data sources outside Kafka was inconvenient. - Quality monitoring and failure handling were insufficient. - Changes to prompts or models required slow offline and online experiments. ## The Taxonomy Management System - The new system centrally manages taxonomies, performs LLM-based classification, delivers category and attribute results, and monitors quality. - Dataflow with Apache Beam was selected because it supports: - Parallel, high-throughput LLM inference - Both streaming and large-scale batch processing - Existing team expertise compared with alternatives such as Spark or Flink - BigQuery serves as the source of truth for inference results. - Analysts and data scientists can query results directly. - Online consumers can receive results through Kafka sinks into the internal feature platform. ## Configuration-Driven and Extensible Design - Taxonomy definitions are stored in YAML, allowing different services and category trees to use the same framework. - Pipeline settings, worker sizing, Kafka topics, and BigQuery destinations are also configured through YAML. - LLM models and inference strategies can be selected through configuration, including: - Primary and evaluation models - Single-shot or two-stage categorization - Attribute extraction modes - Evaluation sampling ratios - The system is designed for multilingual taxonomies. - Large translation jobs are divided into chunks. - One LLM generates translations and another validates consistency and naturalness. - A depth-first traversal carries parent-category translations into child-category prompts to maintain terminology consistency. ## Creating and Expanding Taxonomies with LLMs - New taxonomies are developed by researching established taxonomies and generating candidate trees from real data. - Existing taxonomies are expanded by: - Classifying sampled data against the current taxonomy - Asking the LLM to suggest categories for unsuitable examples - Merging similar suggestions using LLM similarity judgments - Promoting sufficiently strong candidates for review - Candidates undergo two evaluations: - Whether the originating examples are correctly assigned to the new category - Regression testing comparing classifications under the old and new taxonomies - This process enabled the team to move beyond the existing 1,400 three-level categories and create taxonomies with more than 10,000 categories and six or more levels. ## LLM Categorization Strategies The team supports multiple strategies because the best approach depends on the model and taxonomy size: - **Single shot:** Provide all categories and ask the model to choose one. - **Hierarchical classification:** Select the best category at each depth, then continue through the chosen branch. - **Two-stage tournament:** Split categories into chunks, select candidates from each chunk, and run a second selection among those candidates. - Categorization and attribute assignment are separate modular Beam `DoFn` stages: - `Article → Category inference → Attribute inference` - New approaches can be added as interchangeable strategies without redesigning the whole pipeline. ## Evaluation with LLM-as-a-Judge - A sample of production data is processed by multiple different models. - Their labels are combined into a ground-truth label, generally through majority voting. - Each model’s output is compared against that ground truth. - Accuracy changes are tracked whenever the team modifies: - The LLM model - Prompts - Pipeline structure - Categorization or attribute strategies - The ground-truth method varies depending on whether the task involves: - A single category - Multiple categories - Multi-label attributes - Category quality is measured as a precision-at-one-style accuracy: the primary model’s category must match the ground-truth category. - Attributes are evaluated with precision and recall because a post can legitimately contain multiple attribute-value pairs. The main recommendation is to treat LLM classification as a production data pipeline rather than a one-off prompt: centralize taxonomy management, support both batch and streaming execution, make inference strategies configurable, and build automated evaluation and monitoring into the system from the beginning.

Read original(opens in new tab)

Large Language ModelsApache KafkaPrompt EngineeringBigquery+4

dropbox·Feb 26, 2026·3 min readCurated summary

Using LLMs to amplify human labeling and improve Dash search relevance

Dropbox Dash improves AI answers through retrieval-augmented generation (RAG): enterprise search retrieves relevant company documents, and an LLM uses a small subset of them to generate grounded responses. Because ranking determines which documents reach the LLM, search relevance depends heavily on high-quality query–document labels. Dash combines a small set of human judgments with large-scale LLM-generated labels to produce training data efficiently while retaining human oversight. ## How Dash search ranking works - Dash uses a trained ranking model, such as XGBoost, rather than manually configured rules. - The model learns from query–document pairs labeled on a 1–5 relevance scale: - **5:** Closely matches the user’s intent. - **1:** Not useful enough to display. - Relevance depends on the query, user context, and timing; it is not an intrinsic property of a document. - Ranking quality is especially important because enterprises may have millions or billions of indexed documents, while only a small selection can be sent to the answer-generating LLM. ## Sources of relevance labels - Labels can come from: - User behavior, such as clicks or skipped results. - Human evaluators assigning relevance scores. - LLMs directly judging query–document relevance. - Behavioral signals are useful but often sparse, biased by existing rankings, and unevenly distributed, so they work best as a supplement. - Human evaluators can provide comprehensive judgments across result sets, but labeling is expensive, difficult to scale, and vulnerable to inconsistency. - Humans also cannot directly review sensitive or proprietary customer data in this process, and different content types—such as Slack messages, Jira tickets, and Salesforce records—require different contextual expertise. ## LLM-assisted relevance evaluation - LLMs can evaluate far larger candidate sets at lower cost and with greater consistency than human annotators. - They can operate across languages and analyze customer content within established compliance boundaries. - Their judgments still depend on the model’s quality and the clarity of the evaluation prompt. - LLM-generated labels therefore require calibration and validation before being used for model training. ## Combining human review with LLM scale - Dropbox first creates a relatively small, high-quality dataset using human evaluators and limited, non-sensitive internal data. - These human labels are used to tune LLM prompts and model parameters. - Once the LLM meets quality thresholds, it generates hundreds of thousands or millions of relevance labels. - This approach multiplies human labeling effort by roughly 100 times, enabling broader and more representative training data. - LLMs are used offline rather than directly at query time because production-time use would introduce excessive latency and context-window limitations. - The LLM acts as a teacher for smaller, faster ranking models that can serve searches at scale. ## Evaluation as the foundation - Dash follows an iterative process: measure performance, change the model or instructions, and measure again. - The article compares this to chess engines, where the quality of the evaluation function determines which possible moves are preserved or discarded. - The same principle applies to ranking: poor relevance judgments can cause useful search-result patterns to be eliminated, while accurate judgments guide the model toward better rankings. Dash’s approach uses humans for quality control and contextual grounding, then uses LLMs to expand that expertise into large-scale training data. This hybrid strategy offers a practical way to improve enterprise search relevance without exposing customer data to human reviewers or imposing LLM latency on every search.

Read original(opens in new tab)

Large Language ModelsMachine LearningRAGXgboost+3

toss·Feb 26, 2026·4 min readCurated summary

The Software 3.0

The post argues that teams using the same LLM can achieve very different results because individual knowledge of context engineering varies widely. Claude Code’s plugins and marketplace could help turn personal LLM techniques into shared, executable team workflows, raising the organization’s productivity floor. The author presents this as a forward-looking hypothesis rather than a proven success story. ## The Frictionless Harness - LLM adoption loses effectiveness when developers must switch between terminals, browsers, and chat tools. - Claude Code’s terminal-based TUI reduces context switching by combining natural-language instructions and code in the developer’s existing environment. - This low-friction experience makes it easier to distribute standardized workflows across a team. ## Executable Single Source of Truth - Wikis and Notion pages become outdated because they are designed primarily for human reading. - Claude Code plugins can serve as “executable SSOT”: - Humans can read them as guidelines and manuals. - LLMs can interpret them as precise system instructions. - Updating a plugin can immediately change how team agents behave, keeping operational knowledge aligned with current practices. ## Raising the Team’s Productivity Floor - Teams have significant differences in LLM literacy, independent of coding ability. - Generic open-source plugins can provide shared best practices, but they lack company- and domain-specific context. - Each domain needs its own rules for: - Tasks the AI can perform autonomously. - Tasks requiring human approval through HITL processes. - The goal is to minimize human intervention while preserving approval at critical points. ## Extending Platform Engineering into Software 3.0 - AI workflows resemble traditional internal platform components such as authentication, logging, and payment libraries. - The analogy is: - Common software modules → AI workflow plugins - Library distribution → Marketplace publishing - The implementation changes from traditional code to prompts and agent logic. - AI workflows should receive the same quality practices as software modules, including review, optimization, and feedback on token usage and failure cases. - Marketplace-based collaboration could turn individual prompting techniques into shared organizational intelligence. ## Why Use a Marketplace Instead of Only RAG? - RAG systems can make it difficult to predict which context will be retrieved due to search, reranking, and indexing behavior. - Plugins provide more explicit and controllable instructions and code. - Developers can modify and test workflows locally in the TUI without deploying a server. - With the Claude Agent SDK, workflows validated locally could also run in server environments, improving development-production parity. - The marketplace could become the shared source of truth between experimentation and production. ## Marketplace as a Workflow Distribution Platform - Teams could package coding conventions, Git strategies, lint rules, and testing policies into private plugins or registries. - Hooks could actively correct behavior rather than merely reject violations—for example, preventing commits on `main` and creating a `feature/` branch instead. - Slash commands could distribute the best engineer’s workflow to everyone: - `/new-feature` gathers requirements. - Creates a Jira issue and branch. - Produces an implementation plan for approval. - Implements the feature and opens a pull request. - This allows less experienced users to follow a reliable, high-quality process without reproducing it manually. ## Layered Context Architecture The author proposes separating plugin knowledge into three layers: - **Global layer:** Organization-wide security rules and coding standards. - **Domain layer:** Business-specific knowledge for areas such as payments, settlement, or membership. - **Local layer:** Repository-specific implementation details and conventions. This structure avoids overwhelming the LLM with irrelevant information and creates a “living knowledge base” made of maintainable prompts and code rather than static documents. ## The Data Flywheel Hypothesis - Standardized plugins could generate high-quality instruction-tuning data. - Accumulated workflow data might eventually support domain-specific model fine-tuning. - Existing workflows could also provide evaluation criteria for those models. - Success would require sustained data collection, quality controls, and long-term organizational investment. - The proposed flywheel is: more usage creates more data, better data improves models, and better models encourage further usage. The practical recommendation is to treat LLM expertise as an organizational system rather than an individual skill. Teams should begin packaging their implicit knowledge, approval rules, and proven workflows into versioned, domain-aware plugins that can be tested, reviewed, and distributed through a marketplace or private registry.

Read original(opens in new tab)

Large Language ModelsAI AgentsModel Context ProtocolRAG+4

airbnb·Feb 24, 2026·4 min readCurated summary

Academic Publications & Airbnb Tech: 2025 Year in Review

Airbnb’s 2025 research program expanded across major academic venues, with a focus on applying AI, machine learning, and data science to search, ranking, personalization, and marketplace optimization. The company strengthened its presence at KDD and CIKM while broadening into NLP, optimization, and measurement science. Its research emphasized practical systems that improve experimentation, retrieval, recommendations, ranking quality, and booking conversion. ## Research Expansion in 2025 - Airbnb presented research at established conferences including KDD and CIKM, while expanding into venues such as COLING, LION, and VLDB. - Researchers used these conferences to: - Share production-scale findings with academic and industry peers. - Develop new collaborations. - Learn about emerging methods. - Mentor early-career researchers. - The work was organized around themes including applied machine learning for search and personalization, and NLP and LLM systems in production. ## Search Ranking and Marketplace Retrieval at KDD KDD is a leading conference for data mining, knowledge discovery, and large-scale analytics. Airbnb has presented there since 2018, and its 2025 contributions focused on improving search experimentation and location retrieval. - **Interleaving and counterfactual evaluation** - Airbnb introduced techniques for evaluating search-ranking ideas before launching full A/B tests. - These methods help teams identify promising experiments more quickly. - They are especially useful for accommodation booking, where long conversion cycles can make statistical significance slow to achieve. - The goal is to accelerate experimentation without compromising evaluation accuracy. - **Extreme classification for audience expansion** - Airbnb presented a high-precision approach to retrieving relevant geographic areas in its two-sided marketplace. - The system uses categorical location cells to identify areas containing listings a guest might realistically book. - This helps balance Airbnb’s diverse global inventory with users’ preferences for location, amenities, style, and price. - Airbnb also presented work on **TSMO**, or Two-sided Marketplace Optimization, and indicated that some technologies might eventually be open-sourced. ## Search and Recommendation Advances at CIKM At CIKM 2025, Airbnb’s Relevance and Personalization team had five peer-reviewed papers accepted. The work addressed search, recommendations, ranking metrics, multimodal representations, and user comparison behavior. - **Recommendations for overly narrow searches** - Airbnb developed a system that suggests alternatives when a guest’s search returns too few accommodations. - Suggestions may include different dates, broader amenity requirements, or adjusted price ranges. - The system aims to reduce search frustration and increase booking rates. - **Map-specific ranking optimization** - Maps account for approximately 80% of Airbnb search interactions. - Traditional feed-ranking assumptions do not accurately represent how users view and interact with map results. - Airbnb introduced a map-specific version of NDCG, a ranking-quality metric. - Experiments showed that optimizing for this metric improved bookings. - **BiListing multimodal embeddings** - BiListing combines listing text and photos into unified embedding representations. - It uses large language models and pretrained language-image models as ranking signals. - The approach produced a reported 0.425% improvement in normalized discounted booking gain and generated tens of millions of dollars in incremental revenue. - **Beyond pairwise learning-to-rank** - Airbnb proposed a learning-to-rank method that models interactions between items during pairwise comparisons. - This provides a more realistic view of what users prefer when evaluating search results. - The paper also describes efficient implementation techniques and online and offline evaluation results. - **Learning to Comparison-Shop** - The LTCS system models how users compare multiple listings rather than evaluating each listing independently. - It produced statistically significant improvements of 1.7% in NDCG and 0.6% in booking conversion rate. - The work reflects Airbnb’s broader effort to make ranking models sensitive to the context of an entire results page. ## NLP and Production LLM Systems - Airbnb also highlighted NLP and production LLM research, including participation in EMNLP. - Relevant application areas include: - Customer support. - Search and discovery. - Trust and safety. - EMNLP covers language-model architectures, training strategies, safety, evaluation, datasets, and open-source tooling. Airbnb’s 2025 publications show a strong emphasis on research that translates directly into marketplace performance. The most practical opportunities involve faster experimentation, context-aware ranking, multimodal listing understanding, and recommendation systems that help guests recover from overly restrictive searches.

Read original(opens in new tab)

Large Language ModelsMachine LearningNatural Language ProcessingData Science+4

grammarly·Feb 19, 2026Original article

10 Best AI Assistants: Top Tools for Work, Writing, and Everyday Tasks (opens in new tab)

Modern AI assistants have evolved from general-purpose chatbots into specialized productivity tools that leverage Natural Language Processing (NLP) and Large Language Models (LLMs) to automate complex workflows. By selecting an assistant based on specific task relevance, integration depth, and technical capabilities like context window size, users can significantly reduce manual effort and context switching. Ultimately, the most effective tools are those that proactively support "in-flow" work rather than requiring users to step away from their primary applications. ### Technical Foundations of AI Assistants * Assistants use NLP to interpret the intent and tone behind everyday language, moving beyond the rigid menu-based structures of traditional software. * Responses are generated by LLMs trained on massive datasets, allowing the tools to recognize linguistic patterns and provide natural-sounding outputs. * Functionality is typically driven by prompts—typed or spoken requests—that allow the AI to summarize documents, refine messaging, or brainstorm project outlines. ### Evaluation Criteria for Professional Use * **Context Awareness:** This refers to the "context window," or the amount of information an AI can hold in its active memory; larger windows allow for the analysis of entire documents or long-term conversation history. * **Proactivity versus On-demand:** Some tools wait for a specific prompt, while others are "proactive," surfacing suggestions and refinements automatically as the user works. * **Integration Ecosystem:** High-value assistants operate as extensions within browsers (Chrome, Edge) or directly inside 100+ third-party apps to pull in relevant background info without manual data entry. * **Accuracy and Verification:** For research-heavy tasks, the best tools offer citations and references to mitigate the risk of "hallucinations" or incorrect data common in LLMs. * **Privacy and Security:** Professional-grade tools provide transparent data handling and storage policies, which is essential for teams managing sensitive information. ### Specialized Assistants and Use Cases * **Go:** A communication-focused assistant that works proactively within existing workflows to draft emails and improve clarity in real-time. * **ChatGPT:** A versatile, general-purpose tool best suited for technical problem-solving, coding support, and creative ideation, though it often requires manual context switching. * **Claude AI:** Optimized for high-volume text processing, making it the preferred choice for deep document analysis and complex, long-form revisions. To achieve the best results, users should audit their daily app usage and primary tasks—such as scheduling, coding, or drafting—before committing to a platform. Prioritizing an assistant that integrates directly into your most-used software will yield the highest productivity gains by eliminating the friction of copying and pasting data between windows.

Large Language ModelsMachine LearningNatural Language ProcessingData Privacy+2

spotify·Feb 19, 2026·3 min readCurated summary

Background Coding Agents: Predictable Results Through Strong Feedback Loops (Honk, Part 3) | Spotify Engineering

Spotify argues that unsupervised coding agents become reliable only when surrounded by strong, automated feedback loops. Its “Honk” system uses component-specific verifiers, mandatory pre-PR checks, and an LLM judge to catch build failures, test failures, scope creep, and functionally incorrect changes. The conclusion is that constrained, sandboxed agents with rich verification are more predictable than flexible agents operating independently. ## Failure Modes at Scale - Agents may fail to produce a pull request, which is inconvenient but usually manageable. - They may produce PRs that fail CI, leaving engineers to repair incomplete work. - Most seriously, they may produce PRs that pass CI but are functionally wrong and potentially reach production. - These failures are more likely when components lack tests, agents modify code beyond the prompt, or agents cannot correctly run builds and tests. - Reviewing invalid or nonsensical PRs can become a significant engineering time sink. ## Verification Loops - Honk uses independent verifiers that provide incremental feedback while the agent works. - Verifiers activate automatically based on the repository contents; for example, a Maven verifier runs when a root-level `pom.xml` is present. - The agent sees an abstract MCP tool rather than the implementation details of Maven, test runners, or build systems. - Verifiers handle formatting, compilation, testing, and output parsing, returning concise error messages instead of consuming the agent’s context with raw logs. - All applicable verifiers run before a PR is opened. In Claude Code, this is enforced with a stop hook. - If verification fails, the PR is blocked and the user receives an error. ## An LLM as a Judge - Deterministic checks cannot detect every problem, especially when an agent makes unnecessary refactors or disables flaky tests. - Honk therefore sends the original prompt and proposed diff to a separate LLM judge. - The judge runs after the regular verifiers and can veto changes that exceed the requested scope. - Across thousands of sessions, the judge rejects roughly one quarter of proposed changes. - Agents successfully correct about half of the vetoed changes. - Spotify has not yet built formal evaluations for the judge, but observed that scope violations are its most common reason for rejection. ## Constrained Agents and Sandboxing - The agent has limited responsibilities: inspect the relevant code, edit files, and invoke verification tools. - Surrounding infrastructure handles prompt creation, pushing code, and user communication through systems such as Slack. - Restricting the agent’s capabilities improves predictability and provides security benefits. - Agents run in heavily sandboxed containers with limited permissions, few installed binaries, and almost no access to surrounding systems. - Spotify reports that agents solve increasingly complex tasks reliably when these feedback loops are present, but often produce unusable code without them. ## Future Expansion - Spotify plans to support more hardware and operating systems. - Current verifiers run only on Linux x86, limiting support for systems that require macOS, such as iOS applications, or ARM64 environments. - The company also intends to integrate Honk more deeply with existing CI/CD pipelines. The practical recommendation is to treat autonomous coding as an infrastructure and verification problem, not merely a prompting problem: keep agents narrowly scoped, isolate them securely, and require layered automated checks before accepting their changes.

Read original(opens in new tab)

Large Language ModelsAI AgentsCI/CDModel Context Protocol+4