Large Language Models

178 posts

spotify4 min readCurated summary

Inside the Archive: The Tech Behind Your 2025 Wrapped Highlights | Spotify Engineering

Spotify’s 2025 Wrapped Archive identified up to five remarkable listening days for each eligible user and turned them into personalized, LLM-generated stories. A distributed pipeline, carefully designed prompts, model distillation, and massive-scale pre-generation made it possible to create roughly 1.4 billion reports before launch. The system prioritized factual grounding, creative consistency, safety, and reliable parallel storage. ## Identifying Remarkable Listening Days - Spotify used a priority-ordered set of heuristics to evaluate each user’s full year of listening. - Straightforward categories included: - Biggest Music Listening Day - Biggest Podcast Listening Day - Biggest Discovery Day, based on first-time artists - Biggest Top Artist Day - Biggest Top Genre Day - More nuanced categories detected: - Nostalgic listening and throwback-heavy sessions - Unusual listening patterns that differed from a user’s typical taste - Contextual dates such as birthdays and New Year’s Day - Candidate days were ranked by narrative potential and statistical strength, reducing hundreds of millions of events to as many as five standout days per user. - A distributed data pipeline aggregated the results and stored listening data in object storage. - Messaging queues then moved each user’s data asynchronously into report generation. ## Prompt Engineering for Reliable Stories - Spotify spent more than three months iterating on prompts and evaluating edge cases. - The system prompt established: - Traceability to real listening behavior - A witty, sincere, and quietly playful tone - Safety constraints excluding references to drugs, alcohol, sex, violence, and offensive language - User prompts supplied: - Detailed daily listening logs - Precomputed statistics, since LLMs are unreliable at arithmetic - Overall Wrapped data - The remarkable-day category - Previously generated reports to reduce repetition - The user’s country for appropriate spelling and vocabulary - Outputs were improved through prototype comparisons, LLM-based judging, human review, and feedback from creative, technical, and safety teams. ## Distilling the Model for Scale - Larger frontier models produced strong results during prototyping but were too expensive for more than a billion generations. - Spotify generated high-quality reference outputs and curated them into a reviewed “gold” dataset. - A smaller, faster production model was fine-tuned on that dataset. - Direct Preference Optimization (DPO), based on curated human A/B evaluations, further aligned the smaller model with the preferred output style. - The resulting model achieved preference performance comparable to the larger baseline. ## Generating 1.4 Billion Reports - Approximately 350 million users were eligible, with up to five reports each. - Spotify pre-generated about 1.4 billion reports before Wrapped launch. - The system sustained thousands of model requests per second over several days. - After remarkable days were computed, snapshots were published to a pub/sub queue. - Reports were generated sequentially per user so earlier reports could inform later ones and prevent repetition. - Real-time dashboards tracked throughput, reliability, errors, and projected completion time. - The generation engine ran continuously for four days, followed by checks for missing reports, inconsistencies, and necessary re-generation. ## Designing Storage for Concurrent Writes - Completed reports were stored in a distributed, column-oriented key-value database optimized for high-throughput writes. - Each user occupied a single row, with separate columns representing completed remarkable days. - Instead of maintaining a serialized list—which could cause race conditions during read-modify-write operations—each date received its own column qualifier in `YYYYMMDD` format. - Independent reports could therefore be written concurrently to separate cells without locks or coordination. - Report content was written first, followed by lightweight metadata marking the report complete. - This ordering prevented the system from exposing a completion marker before the underlying report was safely stored. ## Practical Conclusion Building Wrapped Archive required treating creative AI generation as a large-scale production system: ground outputs in structured data, use smaller specialized models when volume demands it, evaluate continuously, and design storage schemas that make concurrency safe by default.

Read original(opens in new tab)
grammarlyOriginal article

What Is an AI Assistant? Definition, Types, and Examples (opens in new tab)

AI assistants have evolved from simple command-driven tools into sophisticated digital partners that leverage natural language processing to streamline workplace productivity. By integrating large language models with real-time data and contextual awareness, these tools enable users to automate repetitive tasks and manage information more effectively. Ultimately, their value lies in their ability to bridge the gap between open-ended human intent and actionable digital output across diverse software environments. ### The Technical Framework of AI Interaction * **Natural Language Processing (NLP):** This technology allows assistants to interpret the nuance of everyday language, distinguishing between literal questions and requests for tonal adjustments or stylistic changes. * **Large Language Models (LLMs):** These models use machine learning patterns to predict and generate helpful responses rather than relying on a pre-written script. * **Context Windows:** Modern assistants maintain a "memory" of the current conversation or document, allowing them to refer back to earlier sections and maintain consistency across long-form projects. * **Tool Integration:** Many assistants function by connecting to external APIs, enabling them to check calendars, pull data from the web, or manage task lists within other applications. ### Functional Applications in Daily Workflows * **Content Synthesis:** Assistants can ingest lengthy documents or meeting recordings to produce condensed summaries, outlines, and key takeaways. * **Drafting and Revision:** Beyond simple generation, these tools help refine existing text for clarity, length, and professional tone. * **Ideation and Brainstorming:** Users can utilize AI to overcome the "blank page" problem by generating initial project structures or exploring different angles for a specific topic. * **Technical Support:** For developers, AI assistants can interpret error messages, generate code snippets, and explain complex technical concepts in plain language. To maximize the impact of these tools, users should focus on providing detailed prompts that provide clear context and intent. As AI assistants become more deeply embedded in browsers and operating systems, understanding the balance between their generative capabilities and their contextual limitations is essential for maintaining an efficient digital workflow.

grammarlyOriginal article

How to Create an AI Assistant Step by Step: A Beginner’s Guide (opens in new tab)

Creating a custom AI assistant is no longer restricted to engineers, as modern no-code tools and APIs allow users to build specialized agents for specific personal or professional workflows. By focusing on a narrow scope and selecting the right platform, individuals can gain greater control over data, behavior, and task efficiency than generic tools provide. Ultimately, the shift toward custom assistants reflects a move away from one-size-fits-all software toward personalized AI teammates integrated directly into daily work. ## The Anatomy of an AI Assistant * Digital assistants utilize Natural Language Processing (NLP) to interpret user intent and tone through conversational prompts. * Large Language Models (LLMs) serve as the underlying engine, recognizing language patterns to generate contextually relevant responses. * Advanced implementations, such as the "Go" assistant, operate within existing apps like email and documents to eliminate context switching and manual data entry. ## Strategic Drivers for Customization * **Personalization:** Tailoring the assistant’s tone and behavior ensures it supports specific tasks exactly as the user expects. * **Data Control:** Building a custom solution offers transparency into how data is used, which is critical for teams handling sensitive internal information. * **Efficiency and Innovation:** Customizing an assistant for a niche problem—like summarizing specific document types or automating recurring questions—reduces manual effort more effectively than general tools. * **Independence:** Creating a proprietary tool reduces reliance on third-party platforms that may change their pricing or feature sets. ## Defining the Core Mission * The most successful assistants focus on one primary responsibility rather than trying to handle every possible task. * Effective planning requires answering who the user is and what specific problem the assistant is meant to solve consistently. * Starting with a narrow scope, such as a dedicated writing assistant or a customer service bot, simplifies the testing and refinement process during the initial launch. ## Development Paths and Lifecycles * Users can choose between no-code platforms for rapid deployment or API-based configurations for higher flexibility and integration. * The development process follows a standard lifecycle: strategic planning, technical configuration, launch, and continuous improvement. * Ongoing monitoring is essential to ensure the assistant remains responsible, accurate, and aligned with evolving user needs. To build a successful AI assistant, start by identifying a single high-impact task and selecting a tool that matches your technical comfort level. Prioritizing a narrow focus during the initial build will allow for more effective monitoring and easier scaling as your requirements grow.

netflix4 min readCurated summary

Scaling LLM Post-Training at Netflix

Netflix argues that LLM post-training at production scale is as much an infrastructure challenge as a modeling challenge. Its internal framework abstracts distributed data processing, model sharding, GPU orchestration, checkpointing, and complex training workflows so developers can focus on experimentation. The result is a flexible system supporting SFT, DPO, reinforcement learning, and knowledge distillation across hundreds of GPUs. ## Why Post-Training Becomes an Engineering Problem - Pre-training provides general language ability, but post-training adapts models to Netflix’s catalog, member histories, recommendation tasks, personalization, and search. - Production-scale training introduces challenges involving: - Large proprietary datasets - Multi-node GPU coordination - Distributed model state - Workflows that combine training and inference - Failure recovery and experiment tracking - A simple Hugging Face fine-tuning script is insufficient for reliable, large-scale jobs. ## Preparing Data Correctly - Chat templates serialize conversations but do not determine which tokens should contribute to the loss. - Netflix applies explicit loss masking so training focuses on assistant responses rather than prompts or other non-target text. - Variable-length examples can waste GPU memory through padding and create synchronization overhead across FSDP workers. - Sequence packing combines multiple samples into fixed-length sequences. - A document mask prevents attention across separately packed samples while improving GPU utilization. ## Loading and Optimizing Large Models - Models that do not fit on one GPU require sharding strategies such as FSDP or tensor parallelism. - Partial weights should be loaded directly onto the device mesh rather than materializing the entire checkpoint on a single device. - Developers can choose full fine-tuning or LoRA and use: - Activation checkpointing - Compilation - Appropriate precision settings - Reinforcement learning requires compatible precision between rollout generation and policy training. - Large vocabularies create memory pressure because logits have dimensions `[batch, seq_len, vocab]`. - The framework reduces peak memory by removing ignored tokens before projection and computing logits and loss in sequence chunks. ## Distributed Training and Workflow Management - The framework supports standard forward/backward training for SFT as well as workflows that interleave: - Rollout generation - Reward-model and reference-model inference - Policy updates - Ray actors orchestrate distributed jobs while keeping hardware concerns separate from modeling code. - Experiment tracking covers both quality metrics, such as loss, and efficiency metrics, such as Model FLOPS Utilization (MFU). - Standardized checkpointing allows jobs to resume after failures. ## Netflix’s Post-Training Framework - The stack is built on: - Mako for AWS GPU provisioning - PyTorch, Ray, and vLLM - Netflix’s framework library for reusable utilities and training recipes - Jobs are generally defined through configuration files that select a recipe and provide task-specific components. - Unlike narrower fine-tuning systems, the framework supports: - Custom output heads - Expanded vocabularies and semantic IDs - Special tokens - Transformer models trained on non-natural-language sequences - This flexibility is important for Netflix-specific recommendation and personalization use cases. ## Four Core Abstractions ### Data - Dataset abstractions cover SFT, reward modeling, and RL. - Streaming supports datasets larger than local disk capacity. - Asynchronous sequence packing overlaps CPU preprocessing with GPU execution to reduce idle time. ### Model - The framework supports architectures such as Qwen3 and Gemma3, including Mixture-of-Experts variants. - LoRA is integrated into model definitions. - High-level sharding APIs distribute models across device meshes without requiring developers to write low-level distributed code. ### Compute - A unified job interface scales from one node to hundreds of GPUs. - MFU measurement remains accurate for custom architectures and LoRA configurations. - Checkpoints include parameters, optimizer state, dataloader state, and data-mixer state, enabling exact resumption. ### Workflow - The system supports SFT, DPO, RL, and knowledge distillation. - Online RL uses a hybrid architecture combining a single controller with Single Program, Multiple Data (SPMD) workers. - This extends conventional SPMD training to multi-stage workflows that cannot be represented as a simple training loop. Netflix’s approach is to standardize the difficult operational parts of post-training while preserving enough flexibility for unconventional models and objectives. A framework built around reusable data, model, compute, and workflow abstractions can help teams iterate faster and scale experiments without repeatedly rebuilding distributed infrastructure.

Read original(opens in new tab)
dropbox3 min readCurated summary

How low-bit inference enables efficient AI

Low-bit inference reduces the memory, compute, and energy required to serve modern AI models by representing values with fewer bits. Quantization can substantially increase GPU throughput, but its benefits depend on model accuracy, hardware support, and whether workloads prioritize latency or throughput. The article presents low-bit inference as a production trade-off rather than a universally optimal technique. ## The Rising Cost of Modern Models - Models are growing rapidly, increasing demand for: - Memory capacity - Compute power - Energy - Low-latency serving infrastructure - Dropbox uses attention-based models for Dash and other capabilities involving: - Text, image, video, and audio understanding - Search and summarization - Reasoning over large collections of content - Production deployment requires balancing model capability with hardware utilization, cost, and responsiveness. ## Where Inference Compute Is Spent - Most computation comes from repeated matrix multiplications in two areas: - **Linear layers**, including attention projections, MLP layers, and final output layers. - **Attention mechanisms**, which calculate relationships between input tokens and become increasingly expensive with longer contexts. - GPUs accelerate these operations using specialized hardware: - NVIDIA Tensor Cores - AMD Matrix Cores - These cores execute matrix multiply-accumulate operations much faster than general-purpose CUDA cores. ## How Lower Precision Improves Efficiency - Quantization reduces the number of bits used to represent model values. - Converting values from 16-bit to 8-bit or 4-bit formats: - Reduces memory usage - Lowers memory-transfer costs - Can increase matrix-operation throughput - Reduces energy consumption - GPU throughput generally improves as precision decreases; halving precision can approximately double the number of operations performed per second in suitable workloads. - Eight-bit quantization maps values into 256 discrete levels. Formats below 8 bits typically require **bitpacking**, combining multiple values into types such as `uint8` or `int32` because 4-bit values are not normally stored as native hardware types. - Newer hardware, such as Blackwell GPUs with FP4 support, can provide major energy savings compared with higher-precision systems like the H100. ## Limits of Extremely Low-Bit Formats - Binary and ternary quantization restricts weights to two or three possible values, offering greater theoretical savings. - These formats are not well matched to today’s GPUs because they cannot fully use Tensor or Matrix Cores. - Specialized accelerators could make them more practical, but adoption remains limited by: - Weak ecosystem support - Hardware availability - Concerns about model quality - Practical gains therefore depend not only on bit width, but also on how well the format is supported by existing hardware and software. ## Quantization Formats and Deployment Trade-offs - Quantization is a family of techniques with different choices for: - Numerical representation - Scaling - Execution strategy - These choices affect: - Model accuracy - Inference speed - Memory consumption - Hardware utilization - Different workloads have different priorities: - Latency-sensitive applications need fast individual requests. - Throughput-oriented workloads prioritize processing large volumes efficiently. - Depending on the workload, inference may be limited by software overhead, memory bandwidth, or specialized GPU compute units. ## Pre-MXFP and MXFP Approaches - The article divides modern low-bit formats into two broad groups following the introduction of **MXFP microscaling**: - **Pre-MXFP formats** rely on software-managed scaling and explicit dequantization. - **MXFP formats** move scaling and related operations into Tensor Core hardware. - MXFP aims to standardize low-bit data types while making them more directly usable by modern GPUs. - The choice between these approaches depends on the hardware generation and the specific performance requirements of each production workload. Low-bit inference is most effective when quantization formats, model quality, and hardware capabilities are considered together. Teams should select formats based on the actual bottleneck—memory, bandwidth, latency, or compute—rather than assuming that the fewest possible bits will always deliver the best result.

Read original(opens in new tab)
meta2 min readCurated summary

The Death of Traditional Testing: Agentic Development Broke a 50-Year-Old Field, JiTTesting Can Revive It

Just-in-Time Tests (JiTTests) are an LLM-driven testing approach designed for fast, agentic software development. Instead of maintaining static test suites, the system generates tests for each code change, simulates likely faults, and reports only meaningful regressions. The goal is to reduce test maintenance and false positives while catching serious bugs before production. ## Limitations of Traditional Testing - Tests are manually written as code changes enter the system. - They must account for both current behavior and unknown future changes. - This often leads to: - Tests that fail to detect relevant bugs. - False positives when intended changes break outdated assumptions. - Ongoing maintenance and review costs. - Agentic development increases the volume and speed of changes, making these problems harder and more expensive to manage. ## How Catching JiTTests Work - A new code change or pull request is submitted. - An LLM infers the likely intent of the change. - The system creates mutants—versions of the code containing deliberately introduced faults. - It generates and runs tests designed to expose those faults. - Rule-based and LLM-based assessors evaluate failures and filter out likely false positives. - Engineers receive a focused report when the system identifies an unexpected behavior change. Because the tests are tailored to a specific change, they can reason about intended behavior and distinguish legitimate updates from regressions. ## Benefits for Agentic Development - Tests are generated on demand and do not remain in the codebase. - There is no ongoing test maintenance or test-code review. - Each test is specific to the change being evaluated. - Tests automatically adapt as the code evolves. - Human attention is required mainly when an actual bug is detected. - Testing shifts from measuring generic code quality to determining whether a specific change introduces a real fault. Catching JiTTests are presented as a way to make testing scale with AI-assisted development by moving routine test creation and maintenance from engineers to automated systems.

Read original(opens in new tab)
google3 min readCurated summary

Beyond one-on-one: Authoring, simulating, and testing dynamic human-AI group conversations

DialogLab is an open-source research prototype for designing, simulating, and evaluating dynamic human–AI group conversations. It addresses the tension between rigid scripts and unpredictable generative dialogue by combining structured conversational phases with real-time improvisation. Its evaluation with 14 participants suggests that human-guided simulation offers the strongest balance of realism, engagement, and control. ## A Framework for Multi-Party Conversations - DialogLab separates a conversation’s social structure from its progression over time. - **Group dynamics** define: - Groups, such as a conference or social event - Parties, such as presenters and audiences - Elements, including human or AI participants and shared content - **Conversation-flow dynamics** define: - Snippets, or distinct phases such as opening, debate, and consensus - Participants and turn sequences within each snippet - Interaction styles, including collaborative or argumentative modes - Rules for interruptions and backchanneling - This separation makes complex conversation designs modular and easier to revise. ## The Author–Test–Verify Workflow ### Authoring with Visual Tools - Designers use a drag-and-drop canvas to arrange avatars and shared content. - Inspector panels configure personas, roles, interaction patterns, and snippet behavior. - Automatically generated prompts can be customized for specific narrative or conversational goals. ### Human-in-the-Loop Simulation - A live preview displays the evolving transcript. - In human-control mode, an audit panel suggests possible AI responses. - Designers can edit, accept, or reject suggestions, retaining control over the agents’ contributions. - The system supports both structured interactions and more improvisational conversations. ### Verification and Analytics - A verification dashboard provides post-hoc analysis of the conversation. - Visualizations show turn-taking distributions and sentiment flows. - These tools help creators diagnose interaction patterns without manually reviewing entire transcripts. ## Prototype Evaluation - Fourteen participants from game design, education, and social science research evaluated DialogLab. - They designed an academic social event and tested AI group discussions under three conditions: - **Human control:** Users prompted agents to shift topics, introduce perspectives, ask probing questions, or generate emotional responses. - **Autonomous:** Agents participated proactively according to predefined random or sequential orders. - **Reactive:** A simulated human agent responded only when directly addressed. - Human control was rated significantly more engaging and was generally considered more effective and realistic. - Participants also described the interface as intuitive, flexible, and enjoyable. - Users valued the combination of automated prompt generation, detailed customization, and support for different moderation strategies. DialogLab demonstrates that effective multi-party conversational design benefits from combining explicit structure with controlled improvisation. For developers and researchers building group-based human–AI experiences, a visual authoring workflow paired with human-guided simulation and analytics can provide a practical foundation for rapid iteration and more realistic interactions.

Read original(opens in new tab)
grammarlyOriginal article

Agentic AI vs. generative AI: What’s the Difference and When to Use Each (opens in new tab)

While generative AI focuses on creating content like text and images through prompt-based prediction, agentic AI represents a shift toward autonomous goal achievement and execution. By combining the creative output of large language models with a continuous loop of perception and action, these technologies allow users to move from simply generating drafts to managing complex, multi-step workflows. Ultimately, the two systems are most effective when used together, with one providing the ideas and the other handling the coordination and follow-through. ### Distinguishing Creative Output from Autonomous Agency * Generative AI functions as a responder that produces new content—such as text, code, or visuals—by predicting the most likely next "token" or piece of data based on a user’s prompt. * Agentic AI possesses "agency," meaning it can take a high-level goal (e.g., "prepare a client kickoff") and determine the necessary steps to achieve it with minimal guidance. * While tools like Midjourney or GitHub Copilot focus on the immediate delivery of a specific creative asset, agentic systems act as proactive partners that can use external tools, manage schedules, and make independent decisions. ### The Underlying Mechanics of Prediction and Action * Generative models rely on Large Language Models (LLMs) trained on massive datasets to identify patterns and chain together original sequences of information. * Agentic systems operate on a "perceive, plan, act, and learn" loop, where the AI gathers context from its environment, executes tasks across different applications, and adjusts its strategy based on the results. * The generative process is typically a direct path from input to output, whereas the agentic process is iterative, allowing the system to adapt to changes and feedback in real-time. ### Practical Applications in Content and Workflow Management * Generative use cases include transforming rough bullet points into polished emails, summarizing long documents into flashcards, and adjusting the tone of a message to be more professional. * Agentic use cases involve higher-level orchestration, such as monitoring document revisions, consolidating feedback from multiple stakeholders, and automatically sending follow-up reminders. * In a project management context, an agentic system can draft a project plan, identify owners for specific tasks, and update timelines as milestones are met or missed. ### Navigating Technical and Operational Limitations * Generative AI is susceptible to "hallucinations" because it prioritizes probabilistic output over factual reasoning or logic. * Agentic AI introduces complexity regarding security and permissions, as the system needs authorized access to various apps and tools to perform actions on a user's behalf. * Current agentic systems still require human oversight for critical decision-making to ensure that autonomous actions align with the user's intent and organizational standards. To maximize efficiency, you should utilize generative AI for the creative phases of a project—such as brainstorming and drafting—while delegating administrative overhead and coordination to agentic AI. As these technologies continue to converge, the focus of AI utility is shifting from the volume of content produced to the successful execution of complex, real-world results.

grammarlyOriginal article

AI Assistants vs. AI Agents: What’s the Difference and When to Use Each (opens in new tab)

While AI assistants and agents often share the same large language model foundations, they serve distinct roles based on their level of autonomy and task complexity. Assistants operate on a reactive "prompt-response" loop for immediate, single-step tasks, whereas agents function as semi-independent systems capable of planning and executing multistep workflows to achieve a broader goal. Ultimately, the most effective AI strategy involves leveraging assistants for quick, guided interactions while utilizing agents to manage complex, coordinated projects that require memory and tool integration. ### Reactive vs. Proactive AI Architectures * Assistants are reactive tools that follow a "prompt-response" loop, similar to a tennis match where the user must always serve to initiate action. * Agents are proactive and semi-independent; once given a high-level goal, they can decompose it into actionable steps and execute them with minimal step-by-step direction. * In a practical scenario, an assistant might summarize meeting notes upon request, whereas an agent can organize those notes, assign tasks in a project management tool, and schedule follow-ups automatically. ### Technical Capabilities and Coordination * Both tools utilize Large Language Models (LLMs) to understand natural language, but agents incorporate advanced features like long-term memory and cross-app integrations. * Memory allows agents to retain feedback and results from previous interactions to deliver better outcomes over time, while integrations enable them to act on the user's behalf across different software platforms. * The two systems often work in tandem: the assistant acts as the front-facing interface (the "waiter") for user commands, while the agent acts as the back-end engine (the "kitchen") that performs the orchestration. ### Balancing Control and Complexity * AI assistants provide high user control and instant setup, making them ideal for "out of the box" tasks like grammar checks, rephrasing text, or answering quick questions. * AI agents excel at reducing cognitive load by managing "moving parts" like deadline tracking, organizing inputs from different stakeholders, and maintaining project states across various tools. * Grammarly’s implementation of agents serves as a technical example, moving beyond simple text revision to offer context-aware suggestions that help with brainstorming, knowledge retrieval, and predicting audience reactions. To maximize productivity, users should delegate isolated, high-control tasks to AI assistants while allowing AI agents to handle the background orchestration of complex projects. Success with these tools depends on maintaining human oversight, using assistant-led prompts to provide the regular feedback that agents need to refine their autonomous workflows.

google3 min readCurated summary

Towards a science of scaling agent systems: When and why agent systems work

AI agent systems do not improve simply by adding more agents. Google Research’s evaluation of 180 configurations found that coordination helps substantially on parallelizable tasks but can severely hurt sequential workflows and tool-heavy tasks. The study proposes measurable design principles and a predictive model that selected the best architecture for 87% of unseen tasks. ## Defining Agentic Tasks The study distinguishes agentic tasks from static benchmarks by requiring: - Sustained, multi-step interaction with an external environment. - Iterative information gathering under partial observability. - Adaptive strategy changes based on environmental feedback. Researchers tested five architectures across Finance-Agent, BrowseComp-Plus, PlanCraft, and Workbench: - **Single-agent:** One agent handles reasoning and actions sequentially. - **Independent:** Agents work in parallel without communication and combine results at the end. - **Centralized:** An orchestrator delegates work and synthesizes outputs. - **Decentralized:** Agents communicate directly in a peer-to-peer network. - **Hybrid:** Hierarchical oversight is combined with peer coordination. ## Coordination Must Match the Task - Multi-agent systems produced very different results across GPT, Gemini, and Claude models. - On parallelizable financial reasoning tasks, centralized coordination improved performance by **80.9%** over a single agent. - Parallel agents can independently analyze areas such as revenue, costs, and market comparisons before combining their findings. - On sequential planning tasks, every multi-agent architecture performed worse, with declines of **39–70%**. - Communication and synchronization overhead can fragment reasoning and consume the available cognitive budget. ## The Tool-Coordination Trade-off - As tasks require more tools, coordinating multiple agents becomes increasingly expensive. - Tool-heavy systems, such as coding agents with access to 16 or more tools, face a disproportionate coordination “tax.” - Adding agents is therefore especially risky when actions must be tightly ordered or frequently synchronized. ## Architecture and Reliability - Architecture affects not only performance but also how errors spread. - Independent agents amplified errors by up to **17.2×**, because no mechanism checked their intermediate results. - Centralized systems limited error amplification to **4.4×**. - An orchestrator acts as a validation bottleneck, detecting and containing mistakes before they propagate. ## Predicting the Best Architecture - The researchers built a predictive model using properties such as task decomposability and tool count. - The model achieved an **R² of 0.513**. - It correctly predicted the optimal coordination strategy for **87% of unseen task configurations**. - These results point toward systematic, task-driven agent design rather than relying on the assumption that more agents are always better. For practical deployments, choose architecture based on the task: use coordinated parallel agents for decomposable work, simpler sequential systems for tightly ordered reasoning, and centralized oversight when reliability and error containment are priorities.

Read original(opens in new tab)
netflix3 min readCurated summary

The AI Evolution of Graph Search at Netflix

Netflix is evolving Graph Search from structured DSL queries toward natural-language search using large language models (LLMs). The goal is to let users describe what they want in everyday language while preserving the accuracy and trustworthiness required by Netflix’s complex, federated GraphQL data. Rather than replacing existing applications, Netflix plans to augment them with AI-generated filters and future retrieval-augmented generation capabilities. ## Why Natural-Language Search Is Needed - Graph Search currently relies on a Filter DSL, with applications translating UI interactions into structured queries. - Netflix has hundreds of applications with inconsistent query-building experiences, forcing users to learn different interfaces. - Some indexes contain hundreds of filterable fields, making large forms slow and cumbersome even for subject-matter experts. - Users naturally express goals in language such as “show all movies from the 90s about robots from the US,” not through query builders or DSL syntax. - Natural-language input could reduce friction while allowing each application to retain its own domain-specific presentation. ## Converting Text into Graph Search Filters - The core task is translating an ambiguous natural-language request into a valid Graph Search Filter DSL statement. - Graph Search indexes are defined through GraphQL queries containing typed fields, including booleans, strings, enums, and controlled vocabularies. - Generated filters can combine: - Comparisons such as `>` and `==` - Inclusion or exclusion operators such as `IN` - Logical operators such as `AND` - Netflix evaluates generated queries at three levels: - **Syntactic correctness:** The statement follows the DSL grammar and can be parsed. - **Semantic correctness:** The query uses existing fields, respects field types, and selects valid controlled-vocabulary values. - **Pragmatic correctness:** The filter accurately reflects the user’s intended meaning. ## Context Engineering for the LLM - The LLM needs index metadata to generate semantically valid filters. - Netflix derives much of this context from GraphQL schemas, including: - Field paths - Field descriptions from schema comments - Field types - Valid enum or controlled-vocabulary values - Controlled vocabularies define finite, governed sets of values, such as countries, and prevent generated queries from using invalid alternatives. - Supplying all metadata works for simple examples but does not scale: - Some indexes contain hundreds of fields. - Some vocabularies contain thousands of values. - Larger prompts increase latency and can reduce generation accuracy. - Netflix therefore needs ways to provide the LLM with relevant metadata without overwhelming its context, while still grounding generated queries in the actual schema and allowed values. Netflix’s approach combines schema-aware context, LLM-based query generation, and validation to make natural-language Graph Search practical. The key recommendation is to use AI as an augmentation layer over existing Graph Search applications, with strong grounding and correctness checks rather than treating generated queries as inherently reliable.

Read original(opens in new tab)
google3 min readCurated summary

ATLAS: Practical scaling laws for multilingual models

ATLAS introduces practical scaling laws for training multilingual language models, addressing the lack of public guidance for non-English systems. Based on 774 runs covering 400+ languages and models from 10M to 8B parameters, it predicts how to combine languages, data, and model capacity efficiently. The study finds strong cross-lingual transfer, a manageable multilingual capacity tax, and clear trade-offs between fine-tuning and pretraining from scratch. ## Adaptive Scaling for Multilingual Mixtures - ATLAS extends traditional scaling laws with: - A cross-lingual transfer matrix identifying helpful language combinations. - Rules for scaling model size and data as supported languages increase. - Guidance on whether to pretrain from scratch or fine-tune a multilingual checkpoint. - It separates training data into: - The target language. - Similar “transfer languages,” such as Spanish, Portuguese, and Italian for Catalan. - All other languages. - This allows ATLAS to estimate which languages help or hinder a target language. ## Evaluation Across Languages and Model Sizes - Experiments used MADLAD-400, spanning more than 750 monolingual, bilingual, and multilingual runs. - ATLAS outperformed earlier scaling laws when predicting performance for new: - Model sizes. - Data volumes. - Language mixtures. - Optimal scaling patterns were broadly similar across English, French, Russian, Chinese, Hindi, and Swahili. - Multilingual vocabularies and data impose a compute-efficiency tax, particularly for English. - Low-resource languages eventually encounter data repetition, causing their scaling curves to bend upward. ## Cross-Lingual Transfer - The transfer matrix measures how training on one language affects another. - Examples of strong transfer include: - Norwegian benefiting from Swedish and German. - Malay benefiting from Indonesian. - Arabic benefiting from Hebrew. - English, French, and Spanish are broadly useful training languages, partly because of their large, diverse, and high-quality web corpora. - Shared writing systems and language families are the strongest predictors of positive transfer, with statistical significance of p < .001. - Transfer is asymmetric: language A may help language B more than B helps A. - The results replace informal language-selection assumptions with empirical data. ## Scaling the Number of Supported Languages - ATLAS formalizes the “curse of multilinguality,” in which adding languages can reduce performance because model capacity is limited. - Adding languages creates a modest capacity cost but also substantial positive transfer. - To support twice as many languages, the study recommends approximately: - 1.18× larger model size. - 1.66× more total training data. - Although each language receives less data individually, cross-lingual synergies offset much of the degradation. ## Pretraining Versus Fine-Tuning - Fine-tuning a strong multilingual “Unimax” checkpoint generally delivers the best early performance for the least additional compute. - Pretraining from scratch can eventually produce better results when substantially more tokens are affordable. - For 2B-parameter models, the crossover typically occurs between roughly 144B and 283B tokens, depending on the language. - The supplied article ends while discussing how ATLAS further models this crossover point. ## Practical Recommendation Use ATLAS to select language mixtures based on measured transfer rather than intuition. Fine-tune an existing multilingual checkpoint under tight compute budgets, but consider training from scratch when enough data and compute are available to pass the language-specific crossover point.

Read original(opens in new tab)
tossOriginal article

Welcoming the Era of (opens in new tab)

The tech industry is shifting from Software 1.0 (explicit logic) and 2.0 (neural networks) into Software 3.0, where natural language prompts and autonomous agents act as the primary programming interface. While Large Language Models (LLMs) are the engines of this era, they require a "Harness"—a structured environment of tools and protocols—to perform real-world tasks effectively. This evolution does not render traditional engineering obsolete; instead, it demonstrates that robust architectural principles like layered design and separation of powers are essential for building reliable AI agents. ### The Evolution of Software 3.0 * Software 1.0 is defined by explicit "How" logic written in languages like Python or Java, while Software 2.0 focuses on weights and data in neural networks. * Software 3.0, popularized by Andrej Karpathy, moves to "What" logic, where natural language prompts drive the execution. * The "Harness" concept is critical: just as a horse needs a harness to be useful to a human, an LLM needs tools (CLI, API access, file systems) to move from a chatbot to a functional agent like Claude Code. ### Mapping Agent Architecture to Traditional Layers * **Slash Commands as Controllers:** Tools like `/review` or `/refactor` act as entry points for user requests, similar to REST controllers in Spring or Express. * **Sub-agents as the Service Layer:** Sub-agents coordinate multiple skills and maintain independent context, mirroring how services orchestrate domain objects and repositories. * **Skills as Domain Components:** Following the Single Responsibility Principle (SRP), individual skills should handle one clear task (e.g., "generating tests") to prevent logic bloat. * **MCP as Infrastructure/Adapters:** The Model Context Protocol (MCP) functions like the Repository or Adapter pattern, abstracting external systems like databases and APIs from the core logic. * **CLAUDE.md as Configuration:** Project-specific rules and tech stacks are stored in metadata files, acting as the `package.json` or `pom.xml` of the agent environment. ### From Exceptions to Questions * Traditional 1.0 software must have every branch of logic predefined; if an unknown state is reached, the system throws an exception or fails. * Software 3.0 introduces Human-in-the-Loop (HITL), where "Exceptions" become "Questions," allowing the agent to ask for clarification on high-risk or ambiguous tasks. * Effective agent design requires identifying when to act autonomously (reversible, low-risk tasks) versus when to delegate decisions to a human (deployments, deletions, or high-cost API calls). ### Managing Constraints: Tokens and Complexity * In Software 3.0, tokens represent the "memory" (RAM) of the system; large codebases can lead to "token explosion," causing context overflow or high costs. * Deterministic logic should be moved to external scripts rather than being interpreted by the LLM every time to save tokens and ensure consistency. * To avoid "Skill Explosion" (similar to Class Explosion), developers should use "Progressive Disclosure," providing the agent with a high-level entry point and only loading detailed task knowledge when specifically required. Traditional software engineering expertise—specifically in cohesion, coupling, and abstraction—is the most valuable asset when transitioning to Software 3.0. By treating prompt engineering and agent orchestration with the same architectural rigor as 1.0 code, developers can build agents that are scalable, maintainable, and truly useful.

tossOriginal article

Will developers be replaced by AI? (opens in new tab)

The current AI hype cycle is a significant economic bubble where massive infrastructure investments of $560 billion far outweigh the modest $35 billion in generated revenue. However, drawing parallels to the 1995 dot-com era, the author argues that while short-term expectations are overblown, the long-term transformation of the developer role is inevitable. The conclusion is that developers won't be replaced but will instead evolve into "Code Creative Directors" who manage AI through the lens of technical abstraction and delegation. ### The Economic Bubble and Amara’s Law * The industry is experiencing a 16:1 imbalance between AI investment and revenue, with 95% of generative AI implementations reportedly failing to deliver clear efficiency improvements. * Amara’s Law suggests that we are overestimating AI's short-term impact while potentially underestimating its long-term necessity. * Much of the current "AI-driven" job market contraction is actually a result of companies cutting personnel costs to fund expensive GPU infrastructure and AI research. ### Jevons Paradox and the Evolution of Roles * Jevons Paradox indicates that as the "cost" of producing code drops due to AI efficiency, the total demand for software and the complexity of systems will paradoxically increase. * The developer’s identity is shifting from "code producer" to "system architect," focusing on agent orchestration, result verification, and high-level design. * AI functions as a "power tool" similar to game engines, allowing small teams to achieve professional-grade output while amplifying the capabilities of senior engineers. ### Delegation as a Form of Abstraction * Delegating a task to AI is an act of "work abstraction," which involves choosing which low-level details a developer can afford to ignore. * The technical boundary of what is "hard to delegate" is constantly shifting; for example, a complex RAG (Retrieval-Augmented Generation) pipeline built for GPT-4 might become obsolete with the release of a more capable model like GPT-5. * The focus for developers must shift from "what is easy to delegate" to "what *should* be delegated," distinguishing between routine boilerplate and critical human judgment. ### The Risks of Premature Abstraction * Abstraction does not eliminate complexity; it simply moves it into the future. If the underlying assumptions of an AI-generated system change, the abstraction "leaks" or breaks. * Sudden shifts in scaling (traffic surges), regulation (GDPR updates), or security (zero-day vulnerabilities) expose the limitations of AI-delegated work, requiring senior intervention. * Poorly managed AI delegation can lead to "abstraction debt," where the cost of fixing a broken AI-generated system exceeds the cost of having written it manually from the start. To thrive in this environment, developers should embrace AI not as a replacement, but as a layer of abstraction. Success requires mastering the ability to define clear boundaries for AI—delegating routine CRUD operations and boilerplate while retaining human control over architecture, security, and complex business logic.

kakaoOriginal article

Kanana-2 Development Story ( (opens in new tab)

Kakao has introduced Kanana-2, a series of language models utilizing a Mixture of Experts (MoE) architecture to achieve high intelligence while maintaining low inference costs. To support the stable pre-training of their largest 155B parameter model, the team implemented advanced technical stacks including the Muon optimizer and MuonClip to prevent training instabilities. These developments reflect a strategic focus on balancing large-scale performance with "high-efficiency, low-cost" engineering. ### MoE Architecture and Scaling Strategy * Kanana-2 models, such as the 32B version, activate only 3B parameters during inference to maximize computational efficiency without sacrificing the intelligence of a larger model. * The team is currently training a massive 155B parameter version (Kanana-2-155b-a17b) using FP8 training infrastructure, MuonClip, and Hyperparameter Transfer to ensure stable convergence. * Custom-developed MoE kernels were integrated to reduce memory usage and increase training speed, resulting in a highly stable Loss Curve even during constant learning rate phases. ### A Controlled Testbed for Mid- and Post-Training * The Kanana-2-30b-a3b-base-2601 model was intentionally released without synthetic reasoning data to serve as a "clean" base for research. * This model allows researchers to investigate phenomena like "Reasoning Trace Distribution Mismatch" and "Spurious Rewards" by providing a baseline unaffected by post-training interventions. * By offering a high-quality Korean base model, Kakao aims to support the local AI community in conducting more rigorous experiments on mathematical and logical reasoning. ### Optimization with Muon and Polar Express * Kakao shifted from the industry-standard AdamW optimizer to Muon, which updates parameters by orthogonalizing gradients rather than performing element-wise updates. * To achieve more accurate orthogonalization, they implemented the Polar Express iterative algorithm instead of the standard Newton-Schulz method, aiming to reduce noise in weight updates during the latter stages of large-scale training. * The optimization process also involved detailed adjustments to RMSNorm parameterization and learning rate (LR) management to ensure the model scales effectively. ### Training Stability via MuonClip * To address potential "logit explosion" in large-scale models, the team utilized MuonClip, a technique that clips attention logits to maintain stability. * Because standard Flash Attention stores Max Logit values only on-chip, the team modified the Flash Attention kernels to extract and return these values for monitoring and clipping purposes. * Stress tests conducted with high learning rates proved that MuonClip prevents training divergence and maintains performance levels even when the model is pushed to its limits. The development of Kanana-2 demonstrates that scaling to hundreds of billions of parameters requires more than just data; it necessitates deep architectural optimizations and custom kernel engineering. For organizations looking to train large-scale MoE models, adopting sophisticated orthogonalization optimizers and logit clipping mechanisms is highly recommended to ensure predictable and stable model convergence.