Techlist.io - Korean Tech Blog Curator

gitlabJun 29, 20262 min readCurated summary

What's new in Git 2.55.0?

Git 2.55.0 introduces improvements focused on stacked-branch workflows, large repositories, multi-remote setups, and clearer history visualization. Highlights include `git history fixup`, a built-in Linux filesystem monitor, remote-group pushing, and a configurable width limit for `git log --graph`. The release also continues Git’s Rust adoption and improves performance for partial clones. ## `git history fixup` - Adds `git history fixup <commit-id>`. - Takes staged changes and amends them directly into an existing commit. - Avoids creating a separate fixup commit and running an interactive autosquash rebase. - Automatically updates other local branches containing the amended commit, making it useful for stacked branches. ## Built-in fsmonitor support for Linux - Git’s filesystem monitor speeds up `git status` by tracking changed files instead of scanning the entire worktree. - Git 2.55 extends the built-in `core.fsmonitor=true` daemon from Windows and macOS to GNU/Linux. - Linux support uses `inotify`, avoiding the elevated privileges required by `fanotify`. - The daemon needs a watcher for every repository directory, so large repositories may require increasing `fs.inotify.max_user_watches`. ## Pushing to remote groups - Remote groups were previously supported by `git fetch` but not `git push`. - Configure a group, for example: ```bash git config set remotes.forks "origin upstream" ``` - Push to every remote in the group with: ```bash git push forks main ``` - Each remote is handled independently and follows its own `remote.<name>.push` mappings and mirror settings. ## Limiting `git log --graph` width - `git log --graph` can become difficult to read in repositories with many parallel branches. - Git 2.55 adds a way to limit the graph’s lane width, preventing the ASCII history from expanding indefinitely. - This is particularly useful for large projects such as Git itself, where the graph can become many lanes wide after only a few commits. ## Rust adoption and partial-clone performance - The release continues the gradual evolution of Rust within Git’s codebase. - `git grep` and `git cherry` receive performance improvements when operating in partial clones. Git 2.55 is especially useful for developers working in large monorepos or stacked-branch workflows. Enabling the Linux fsmonitor, using `git history fixup`, and configuring remote groups can provide immediate productivity benefits, while graph-width limits make complex histories easier to inspect.

Rust Git Linux Version Control+2

githubJun 26, 20262 min readCurated summary

Transitioning as a hubber

Arthur Searle describes transitioning at GitHub as a largely smooth experience, enabled by an inclusive, remote-first culture and strong workplace support. Using handles, written communication, flexible avatars, and gender-affirming benefits reduced many common sources of stress. His experience shows that transition can involve both bureaucratic challenges and profound joy when colleagues respond with acceptance and care. ## A Career Built at GitHub - Searle began in IT support and operations before teaching himself to code. - He joined GitHub’s IT Engineering team after a colleague’s referral and moved to Enterprise Security six months later. - His work has included: - Helping migrate GitHub’s main SaaS platform to infrastructure as code. - Speaking at Oxford University about version control. - Throughout his transition, his handle—“gleeblezoid”—remained constant, providing continuity at work. ## How GitHub’s Culture Supported Transition - GitHub’s remote-first structure reduced anxiety around appearance, commuting, and in-person interactions. - Much of Searle’s work happened through written communication in Slack and GitHub, limiting the pressure of speaking while undergoing voice training and hormone-related voice changes. - Employees commonly use handles and informal avatars, making gender assumptions based on appearance less central. - Searle was able to update his name and pronouns in internal systems, with colleagues consistently using them. ## Gender-Affirming Benefits - GitHub covered gender-affirming healthcare for employees. - Benefits included reimbursement for: - Voice training. - Hormone replacement therapy prescriptions. - Therapy. - The main remaining difficulty was ordinary administrative friction, such as changing his legal name in payroll systems. ## Acceptance, Joy, and Belonging - Searle contrasts his experience with people who remain closeted, repeatedly come out to new coworkers, or face extensive bureaucracy. - Colleagues treated his transition as a normal part of his life and expressed genuine happiness for him. - Small gestures had a major emotional impact, including hearing his name and pronouns used at work for the first time and receiving a shaving kit from a teammate. - He emphasizes that being trans is not defined only by hardship; there is also joy in living openly and being supported by others. GitHub’s example suggests that inclusive policies, flexible communication practices, and everyday respect can make workplace transition significantly safer and more affirming. For organizations, support should extend beyond formal benefits to the culture and systems employees use every day.

Github Slack Version Control Infrastructure As Code+3

lineJun 26, 20263 min readCurated summary

From Prompting to Workflows: Boosting Frontend Development Productivity with AI

Frontend development is increasingly shifting from a coding problem to an orchestration problem. Requirements, designs, documentation, discussions, and existing code are scattered across tools, while LLMs can now connect these sources through repeatable workflows. The article argues that structured, reviewable workflows—rather than clever one-off prompts—are the key to scaling AI-assisted development and improving implementation quality. ## From Prompting to Repeatable Workflows - A prompt may produce a useful result once, but it does not create a reusable process. - A workflow defines a repeatable path from inputs to outputs: - Collect context from Jira, Confluence, Slack, and the codebase. - Summarize the actual requirements. - Identify ambiguities and unresolved decisions. - Propose an implementation plan. - Wait for human review before modifying code. - The LLM acts as the engine executing the workflow. - LY Corporation’s Noah MCP connects systems such as Jira, Confluence, Slack, and GitHub, allowing AI agents to access real organizational context instead of relying on manually copied prompts. - Once established, the same workflow pattern can be applied across many tickets, even when the specific inputs differ. ## Example: Planning a List Page The example Jira ticket requests a list page with search, filtering, sorting, and role-based filter visibility. - In the traditional process, a developer manually: - Reads the Jira ticket and identifies missing details. - Searches Figma for loading, empty, and no-results states. - Finds role-based filter rules in Confluence. - Searches Slack for prior decisions. - Inspects the codebase for reusable hooks and components. - Copies findings into notes and assembles an implementation plan. - Implements the feature, resolves bugs and edge cases, and submits a PR. - An AI workflow performs these steps systematically before coding. - The generated plan identifies: - A new `FeatureListPage` route and `FeatureList` component. - Reuse of `useTableFilters` and `useUrlState`. - Existing API support through `GET /api/<feature>`. - URL synchronization for filters, sorting, and pagination. - Role-based visibility using `useCurrentUserRole()`. - Required loading, empty, and no-results states. ## Surfacing Hidden Requirements The workflow improves quality by exposing information that might otherwise appear late in development. - A Slack decision establishes that filter and sort state should use URL parameters rather than `localStorage`, enabling shareable and reloadable views. - Existing hooks such as `useTableFilters` and `useUrlState` are discovered before new code is written, preventing unnecessary duplication. - Unresolved questions are explicitly listed for human review, including: - Whether filter and sort state belongs in URL parameters or `localStorage`. - Which empty-state design should be used when Figma contains multiple variants. - Resolving these questions early reduces rework during implementation or PR review. ## Closed-Loop Verification The workflow should continue after coding rather than stopping when the first implementation is complete. - The agent compares the implementation with the original plan. - It runs: - Type checks. - Linting. - Related unit tests. - Relevant smoke tests or local verification flows. - It reports: - Successful checks. - Failures that were fixed. - Items that could not be verified automatically. - UI screenshots or state notes. - Remaining risks before opening a PR. - This creates a closed-loop development cycle in which AI not only writes code but also validates its work against the intended requirements. Teams should treat AI as a workflow and context-orchestration layer, not merely a code generator. The most effective process gathers information across systems, obtains human approval for the plan, implements with existing project patterns, and automatically verifies the result before review.

Large Language Models Model Context Protocol React TypeScript+4

lineJun 26, 20264 min readCurated summary

Solving the Cold-Start Problem in Search Reranking Through Embedding Stabilization: A LINE Part Time Jobs Case Study

LY Corporation improved LINE Part Time Jobs’ real-time search reranking by stabilizing user and item embeddings produced by a two-tower recommendation model. The approach addressed both cold-start degradation and daily embedding-space drift without changing the underlying model or training pipeline. Offline and online evaluations showed substantial gains, including a 4.7% overall KPI increase and 6.5% revenue growth. ## Search Reranking at LINE Part Time Jobs - Search consists of: - Retrieval, which finds listings matching a query. - Reranking, which orders the retrieved candidates. - The previous system ranked listings by cosine similarity between precomputed user-to-item two-tower embeddings. - This approach was computationally simple and captured broad user preferences, but: - It ignored query-specific information, such as the distance from a selected station. - Its embeddings combined behavior from multiple services and recommendation modules, not just search activity. - The team therefore introduced a dedicated real-time reranking model. ## Challenges with the Dedicated Reranking Model ### Cold Start - Most job listings are replaced at the beginning of each month. - New listings initially lack sufficient interaction data. - As a result, reranking quality dropped until enough training data accumulated. ### Embedding-Space Drift - Two-tower models were regularly retrained from random initialization. - Each training run produced a different embedding space. - Using embeddings as downstream features caused a mismatch between training-time and inference-time data, reducing model performance. ## Stabilizing the Embedding Space - Each day’s embeddings are aligned with the previous day’s stabilized embeddings. - The first day’s embeddings are used without stabilization. - This preserves continuity across retraining cycles and allows embeddings generated on different days to remain comparable. - Downstream models and embedding generation no longer need perfectly synchronized update schedules. ### Low-Rank SVD - User and item embeddings are converted into a more standardized low-dimensional representation. - Instead of decomposing the enormous user-item score matrix directly, transformation matrices are derived from the embedding matrices. - This makes the procedure practical for large-scale data. ### Orthogonal Procrustes Alignment - The transformed embeddings are aligned to the previous day’s stabilized space. - The orthogonal transformation only rotates or reflects the space. - Distances and inner-product relationships are therefore largely preserved, maintaining the two-tower model’s scoring behavior. ## Scalable Implementation - The algorithm was implemented with Apache Spark to handle LINE Part Time Jobs’ large datasets. - For low-rank SVD: - The original QR decomposition was optimized using Cholesky decomposition. - The Gram matrix \(G=A^\top A\) is decomposed to obtain the same upper-triangular matrix \(R\) as QR decomposition. - For Procrustes alignment: - The large matrix multiplication \(M=B^\top A\) is distributed across Spark. - The resulting \(e \times e\) matrix is small enough for SVD on a single node using NumPy. ## Evaluation Results ### Embedding Stability - Before stabilization, embeddings from randomly selected days had correlations close to zero. - After stabilization: - Similarity remained around 0.88 after one week. - Similarity remained around 0.87 after one month. - This reduced performance loss caused by embedding drift. ### Offline Evaluation - Unstabilized embeddings reduced nDCG by approximately 1–5% when training and inference used different days. - Stabilized embeddings improved: - Conversion nDCG by about 9.0%. - Click nDCG by about 4.5%. ### Online A/B Test - Search-page KPIs alone did not show statistically significant improvement. - Across the entire service: - KPIs increased by 4.7%. - Revenue increased by 6.5%. - The results suggest that the embeddings captured long-term user preferences that influenced later actions across the service, not only behavior on the search page. - The added embedding features also helped mitigate the initial cold-start problem. ## Practical Benefits and Future Work - The solution required no changes to the two-tower model itself. - Stabilization was added as post-processing, minimizing changes to existing pipelines and reducing deployment risk. - LY Corporation plans to test the method as the service expands its sources of job listings and to reuse the approach across other services through its internal machine-learning platform. Overall, sequential low-rank SVD and orthogonal Procrustes alignment provide a relatively simple way to make frequently retrained embeddings reliable downstream features while improving real-time reranking and business outcomes.

Machine Learning Apache Spark Online Learning Two Tower Embedding+4

tossJun 26, 20264 min readCurated summary

While Others Test Toss, We Build the Way to Test.

Every week, Toss releases a new version containing roughly 300–400 code changes, making quality assurance essential to protecting users from broken critical features. The QA Platform team combines smoke tests, regression testing, release monitoring, automation, and AI-assisted tools to make releases reliable and efficient. Its central lesson is that teams often want QA work handled responsibly—not merely more tools to operate themselves—so the team is shifting toward directly owning more of the testing process. ## Weekly Release Quality - QA begins when a Release Candidate is available. - **Toss Doctor** runs smoke tests covering core flows such as login through account deletion. - A pull-request analyzer identifies changed areas, potential impact, bug risk, and testing priorities. - **Toss Checker** performs regression testing to ensure new changes have not damaged stable functionality. - After release, the team monitors crash metrics and decides whether an immediate hotfix is necessary or whether a safer fix can wait for the next release. - Custom dashboards track crashes and hotfixes, including causes and prevention measures. - The team also supports product groups starting QA, improves internal tools, and helps establish organization-wide QA processes. ## Defining Toss’s Quality Standard The team’s goal is to go beyond basic testing and establish consistent quality standards across Toss. - **Reliable releases every time:** Quality must remain dependable week after week, not just during individual successful launches. - **High-quality testing:** The focus is on finding defects that could become real incidents, rather than simply increasing test volume. - **Efficient quality assurance:** Manual repetition alone cannot keep pace with the company’s release speed, so automation and sustainable workflows are necessary. - AI is intended to handle suitable decisions and repetitive work, allowing people to focus on areas requiring human judgment. ## Building the Tossion Platform Commercial tools did not provide enough flexibility for Toss’s release pace and evolving AI experiments, so the team built its own platform, **Tossion**. - Tossion replaced TestRail and brought test-case creation, execution, and result tracking into one system. - Multiple bots were consolidated into **Toss Butler**, optimized for the team’s workflow. - **PRCheck** analyzes pull requests and highlights where testers should focus. - **tcgen** uses PRDs, design documents, and surrounding context to generate initial test cases for review. - An automation testing platform displays manual and automated test results together. - **Crash Trend** tracks crash patterns using metrics tailored to Toss. - A hotfix dashboard categorizes causes and records measures intended to prevent recurrence. - These tools are connected by one objective: handling the growing volume of weekly changes more effectively. ## Learning What Teams Really Need The team initially assumed that making test-case creation easier would encourage more people to test. However, tcgen received less adoption than expected. - Users did not necessarily want better tools for doing QA themselves. - What they really wanted was for someone to perform testing quickly and accurately while taking responsibility for its quality. - Providing a tool could feel less like removing work and more like assigning a new task. - As a result, the team shifted toward directly handling more testing and pursuing tenfold efficiency without transferring responsibility to product teams. ## Staying Flexible as AI Evolves AI has solved many problems but has also made long-term planning difficult. - Initial hypotheses may be only partly correct, as the tcgen experience demonstrated. - Tools and methods can become outdated rapidly as AI capabilities change. - The team discarded an API testing tool, **API Labs**, after only eight hours when it proved misaligned with its goals. - Tossion, Toss Doctor, Toss Checker, and internal skills are designed with replacement in mind rather than as permanent, finished systems. - AI can accelerate tool creation, but people must still define what quality means, establish priorities, and decide what standards must be preserved. The QA Platform team’s ongoing approach is to build adaptable systems, learn from actual usage, and remain willing to replace anything that no longer serves its purpose. Its upcoming work will explore Tossion, the release-gate tools, regression automation, and intelligent AI bots in greater detail.

AI Test Automation Regression Testing Release Management+4

googleJun 26, 20263 min readCurated summary

Accelerating Gemini Nano models on Pixel with frozen Multi-Token Prediction

Google introduces a way to add Multi-Token Prediction (MTP) to already-deployed, frozen Gemini Nano models, accelerating on-device generation without a separate drafting model. The approach attaches a lightweight Transformer head to the existing model, reuses its hidden states and KV cache, and preserves identical final outputs through verification. On Pixel 9 and 10 devices, it delivers faster generation, lower memory use, and reduced energy consumption for features such as Notification Summaries and Proofread. ## The Mobile Inference Bottleneck - Autoregressive models generate one token at a time, creating latency and underusing mobile hardware. - Phones face strict RAM and energy constraints that make conventional acceleration techniques difficult. - A standalone speculative-decoding drafter consumes additional memory and must independently process the prompt. ## A “Late Exit” MTP Strategy - Speculative decoding uses: - A small drafter to propose several tokens. - The large model to verify those tokens in parallel. - MTP replaces the separate drafter with a lightweight Transformer head attached near the end of the main model. - The head uses the backbone’s high-dimensional activations to predict future tokens, benefiting from semantic context already computed by the larger model. ## Retrofitting a Frozen Backbone - Google freezes the fully trained Gemini Nano v3 weights and trains only the attached MTP head. - This avoids retraining or fine-tuning the production foundation model. - Incorrect draft tokens are discarded during verification, so the final output remains bit-for-bit identical to the original model. - The method therefore improves efficiency without changing the model’s capabilities or safety alignment. ## Zero-Copy Memory Architecture - The MTP head cross-attends directly to the backbone’s existing KV cache instead of maintaining a duplicate cache. - This eliminates separate prompt-prefill work for the drafter. - It also removes redundant embedding tables, attention variants, and application-specific tuning parameters. - Compared with a standalone drafter, the design saves up to 130 MB per instance. ## Accuracy and Speed Improvements - Access to the backbone’s richer internal representations makes MTP predictions more accurate than those of similarly sized standalone drafters. - Instruction-following tasks such as summarization and rewriting show especially strong gains. - For predictable formats such as smart replies, token acceptance improved by up to 55%. - Pixel 9 experiments showed speedups of 50% or more depending on the task. ## Production Impact - The updated inference stack coordinates drafting and verification on Pixel 9 and 10 devices. - In workloads including AI Notification Summaries and Proofread, MTP predicts nearly two additional tokens per inference pass on average. - Fewer verification cycles reduce processor wake-ups, improving latency and battery efficiency. MTP provides a practical way to accelerate existing on-device models without maintaining a separate drafter for every application. Reusing the frozen backbone’s computations and memory state makes it particularly well suited to mobile deployments where RAM, energy, and backward compatibility are critical.

Kubernetes Transformer Edge Computing Speculative Decoding+3

githubJun 25, 20263 min readCurated summary

Evaluating performance and efficiency of the GitHub Copilot agentic harness across models and tasks

GitHub argues that an agentic harness—the system coordinating tools, context, and workflow—strongly influences how effectively an AI model solves software tasks. Its shared Copilot harness aims to match model-vendor harnesses in task completion while using fewer tokens. Benchmark results across four models suggest near-parity overall, with performance varying by model and task. ## Benchmarking Approach - GitHub evaluates the harness using public and internal benchmarks, plus real-world metrics and online experiments. - Comparisons hold the following constant: - The same underlying model - The same task - Context-window size - Reasoning effort - Tool selection - MCP servers - Copilot CLI is compared with: - Claude Code for Claude Sonnet 4.6 and Claude Opus 4.7 - Codex CLI for GPT-5.4 and GPT-5.5 - Benchmarks include: - **SWE-bench Verified:** 500 human-validated Python bug fixes - **SWE-bench Pro:** More complex, multi-step engineering tasks - **SkillsBench:** Skill usage and triggering - **TerminalBench:** Command-line workflows - **Win-Hill:** Software tasks in Windows containers ## Token Efficiency - Copilot’s harness generally completes tasks at rates comparable to model-vendor harnesses while consuming fewer tokens. - It performed better across the reported tests for Sonnet 4.6 and Opus 4.7. - For GPT-5.4 and GPT-5.5, Copilot performed better on nearly every benchmark. - The main exception was SWE-bench Verified, where Copilot was 7% worse with GPT-5.4 and 4% worse with GPT-5.5. ## Task Resolution - GitHub emphasizes that lower token use matters only when the agent successfully completes the work. - Overall task-resolution rates were considered on par with vendor harnesses. - Results varied by benchmark: - Copilot generally did better on SWE-bench Pro, especially with GPT models. - It outperformed vendor harnesses on Win-Hill or matched them for every model. - It performed better on TerminalBench with Sonnet and Opus, matched GPT-5.5, and trailed GPT-5.4. - SkillsBench results favored GPT models on Copilot but favored vendor harnesses for Claude models. - Differences are described as statistically comparable because model behavior is stochastic and run-to-run variation can explain many gaps. ## TerminalBench Variance Analysis - GitHub uses TerminalBench 2.0 to study both cost and completion rate over repeated runs. - The preferred outcome is higher resolution with lower cost. - The analysis illustrates that benchmark results should account for variance rather than relying on a single run. - GitHub presents Copilot as equal to or better than the vendor harnesses on this cost-versus-success comparison. The practical conclusion is that harness design is a reusable performance multiplier across Copilot products. GitHub’s results support using its shared harness when developers need broad model choice, efficient token usage, and comparable task-completion performance, while recognizing that the best harness can still vary by model and workload.

Large Language Models AI Agents Model Context Protocol Github Copilot+3

metaJun 25, 20263 min readCurated summary

Privacy-Aware Infrastructure in the AI-Native Era: An Asset Classification Case Study

Privacy-aware infrastructure depends on accurate asset classification before it can enforce retention, access, purpose, sharing, or anonymization policies. Because data is noisy, distributed, and constantly changing—especially in AI-native systems—LLMs are useful for ambiguity but should not make routine production decisions. The recommended approach combines rich contextual evidence, human-reviewed labels, narrowly used LLMs, and versioned deterministic rules that are faster, replayable, and auditable. ## Why Asset Classification Matters - Assets include more than tables and columns: they may be nested payload fields, logs, event parameters, API fields, ML features, embeddings, or derived datasets. - Classification must track the meaning of data as it moves through pipelines and changes representation. - A field such as `age` could represent sensitive personal information or an infrastructure cache TTL, making context essential. - Four recurring challenges shape the problem: - **Noisy signals:** Raw metadata can overwhelm models and hide relevant evidence. - **Distributed context:** Code, lineage, ownership, documentation, annotations, and usage patterns reside in separate systems. - **Changing requirements:** Product and policy changes can outpace static rules and periodic reviews. - **Enforcement consequences:** False positives cause unnecessary restrictions, while false negatives create protection gaps. - Classification must reason about ambiguity while producing decisions that can later be explained and reproduced. ## The Hybrid Classification Pattern - **Context beats prompts:** Improving the evidence supplied to a model generally matters more than endlessly tuning instructions. - Evidence briefs should organize: - Supporting and contradicting signals - Provenance - Relevant code and lineage - Masked or circular fields that could distort reasoning - **Evaluation must remain independent:** Human-reviewed reference labels, frozen test sets, separate models or prompts, and regression gates prevent the classifier from defining its own ground truth. - **Stable behavior should be distilled into rules:** LLMs handle novelty and uncertainty, while validated patterns become deterministic, versioned, and auditable logic. - Over time, the LLM’s production role should shrink as routine cases move to low-latency deterministic enforcement. ## A Stable Classification Contract - The classifier should operate as a platform service with a small, explicit interface. - Inputs include: - An asset identifier - A structured bundle of contextual evidence - Outputs include: - A taxonomy category - A confidence score calibrated against reviewed labels - A decision trace explaining influential evidence - The matching deterministic rule, when applicable - Versions for the context, rules, and prompt - Classifiers should answer one scoped, domain-specific question rather than use a universal taxonomy. - Narrow classifiers are easier to evaluate, debug, govern, and compose across downstream privacy decisions. ## Privacy-Aware Infrastructure Responsibilities Asset classification supports the broader PAI lifecycle: - Understanding what data exists and how it is governed - Discovering data flows relevant to a policy - Enforcing retention, access, purpose, and sharing constraints - Producing verifiable evidence of compliance ## Practical Recommendation Use LLMs selectively for ambiguous or novel assets, but build the surrounding system around structured context, independent human-reviewed evaluation, and deterministic rule promotion. This preserves the flexibility of AI while making routine privacy enforcement predictable, auditable, and operationally efficient.

Large Language Models Data Governance Human In The Loop Data Lineage+3

dropboxJun 25, 20262 min readCurated summary

How we used DSPy to turn AI evaluations into better responses in Dash chat

Dropbox uses DSPy to turn AI evaluations into improvements for its Dash chat agent. The process first calibrates LLM judges against human-labeled conversations, then uses those judges to optimize the agent’s system prompt. This feedback loop reduced incomplete answers and token usage while maintaining answer quality. ## The Complexity of Evaluating AI Agents - Agent quality depends on more than the final response: - Understanding user intent - Selecting relevant context - Choosing and using tools - Synthesizing information across documents, messages, and meetings - Handling ambiguity and follow-up turns - Producing grounded, complete answers - Evaluations therefore inspect the full interaction trajectory, not just the output. - Separate evaluations for intent understanding, tool use, context selection, grounding, adaptation, and task completion help identify the source of failures. - Reliable judges were necessary before evaluation results could safely guide agent improvements. ## Calibrating LLM Judges with Human Labels - Dropbox sampled internal chats containing final answers and agent trace logs. - Human reviewers scored five dimensions: - User-intent following - Semantic relevance - Tool calling - Instruction following - Context selection - Reviewers followed a structured process: - Determine whether the agent understood the request. - Check whether it selected appropriate context. - Inspect searches, retrievals, and other tool actions. - Verify that final claims were supported by evidence. - Score relevance, grounding, completeness, and instruction adherence. - Many metrics used a 1–5 scale. - Reviewers also added: - Reasoning notes explaining their scores - Failure codes for issues such as stale evidence, missing context, unsupported claims, incomplete coverage, and poor personalization - These richer annotations helped improve judge prompts while also supporting debugging, error analysis, roadmap planning, and prioritization. ## Using DSPy to Improve Evaluation - DSPy was used to make LLM judges align more closely with human evaluations. - Judges were required to follow a retrospective workflow: - Infer the user’s intent - Inspect the conversation and agent trace - Review supporting evidence - Assess context selection and tool use - Produce scores, failure codes, and reasoning notes - GEPA and MIPROv2, optimization algorithms within DSPy, automatically proposed and tested prompt changes against human-labeled examples. - Optimization supported several scenarios: - Rewriting judge instructions entirely - Adapting a judge to another underlying model - Targeting specific failure modes while preserving the existing evaluation behavior The overall approach creates a scalable improvement loop: human labels calibrate the judges, calibrated judges provide consistent evaluation signals, and those signals guide improvements to the chat agent itself.

Large Language Models AI Agents Dspy Prompt Optimization+4

cloudflareJun 25, 20263 min readCurated summary

How we built saga rollbacks for Cloudflare Workflows

Cloudflare Workflows now supports saga rollbacks, letting each durable step declare how to compensate for its side effects if a later operation fails. This addresses partial failures in multi-step processes, such as refunding a debit when a subsequent credit cannot complete. Rollbacks execute in reverse order and preserve Workflow durability, while requiring the same idempotency safeguards as normal steps. ## The Saga Problem - Durable Workflows can retry steps and persist state, but completed external operations cannot always be directly undone. - In a bank transfer: - Bank A debits the sender. - Bank B fails to credit the recipient. - The original debit must be reversed with a new credit operation. - The pairing of a forward action and its semantic compensation is known as the saga pattern. ## Manual Compensation Before Rollbacks - Developers had to track which steps completed and write centralized `try`/`catch` logic. - Compensation had to: - Run only for completed operations. - Execute in reverse order. - Continue even if one rollback fails. - Remain durable and retryable. - This approach becomes increasingly complex as workflows gain more steps. ## Rollback Functions on `step.do()` - Rollback logic is now declared directly in the step’s options: ```js await step.do("debit-bank-a", debitFn, { rollback: async ({ output }) => refundFn(output.id), }); ``` - Each step carries its own undo operation, making compensation easier to maintain. - Rollbacks can use the original step output, such as a payment or transaction ID. - If a later step fails, previously registered rollback handlers run automatically in reverse step-start order. ## Idempotency and Partial Failures - Rollback functions must be idempotent because they may be retried. - External operations should use idempotency keys to prevent duplicate refunds, credits, or inventory releases. - A step that fails may still need compensation: - It could have modified an external system before failing. - The operation may have succeeded even though Workflows never received its result. - Rollback handlers must therefore handle `output === undefined`. - If user code catches an error and the Workflow continues, rollback does not immediately start. However, if the Workflow later fails, previously registered handlers can still run. ## Practical Usage - Developers pass an options object with a `rollback` function as the final argument to `step.do()`. - Rollbacks can reverse payments, release resources, or perform other compensating actions. - This removes the need for growing manual catch blocks and explicit rollback ordering while retaining durable execution behavior. Cloudflare’s rollback support is best suited to workflows involving external side effects. Developers should define compensation alongside every reversible step and make both forward and rollback operations safely repeatable.

Cloudflare Workflows Rollback Idempotency Saga Pattern+2

lineJun 25, 20264 min readCurated summary

What If AI Agents Debated Each Other? Redesigning the Development Process Through Multi-Agent Collaboration

AI coding’s main bottleneck is no longer code generation but the human coordination surrounding it: clarifying intent, validating assumptions, testing implementations, and preparing trustworthy pull requests. LY Corporation proposes an AI-native pipeline in which specialized “proposer” and “challenger” agents debate across three stages—specification, build, and delivery—while an orchestrator decides whether to revise, escalate, or proceed. The goal is for AI to substantiate its own work before human engineers review and approve it. ## Human Coordination as the Bottleneck - Traditional AI-assisted development speeds up individual tasks but leaves handoffs between requirements, implementation, verification, and review to humans. - Engineers still need to: - Write or refine specifications - Review AI-generated drafts - Transfer failed tests and feedback between steps - Inspect diffs - Prepare PR descriptions - Decide whether the result is trustworthy - The proposed solution is not to remove human judgment, but to automate repetitive coordination while preserving human ownership and final approval. ## Proposer–Challenger Collaboration - AI responsibilities are divided between two opposing groups: - **Proposers** develop specifications, implementations, and delivery materials. - **Challengers** validate them from specialized perspectives. - The separation prevents one general-purpose assistant from combining design, implementation, testing, and review into a single unchallenged response. - Specialized roles may include: - `requirements-synthesizer` - `security-analyst` - `test-coverage-reviewer` - `technical-writer` - `evidence-verifier` - An **orchestrator** mediates disagreements, redirects discussions, resolves deadlocks, and determines whether to revise, escalate, or advance. ## The Spec–Build–Deliver Pipeline ### Specification - The specification acts as a contract for all later stages. - It records: - Goals and constraints - Interpreted requirements - Explicit assumptions - Open questions - Proposed approach - Definition of done - Agents use evidence from the workspace and external sources such as Jira, Confluence, design documents, APIs, tests, dependencies, and existing conventions. - Ambiguous but low-risk and reversible issues can be documented as assumptions. - Unsafe, destructive, externally constrained, or hard-to-reverse uncertainties are escalated instead of guessed. ### Build - The approved specification is converted into a test-first verification plan before production code is changed. - The proposer identifies expected behavior, edge cases, required tests, and execution commands. - Challengers can dispute the verification design before or during implementation. - Proposers must support rejected objections with concrete evidence such as: - Execution paths - Compiler or linter output - Failing tests - Other workspace evidence - This prevents a simple green CI result from hiding missing or inadequate validation. ### Delivery - The final output is a review-ready PR package rather than merely a diff summary. - It explains: - What changed - Where reviewers should look first - Which checks passed - Remaining risks - Which challenges were already investigated - At this stage, the orchestrator acts more like a jury, judging whether sufficient evidence exists for release. ## Structured Debate Protocol - Each agent receives stage-specific context and returns structured JSON rather than a free-form essay. - Agents do not share one live context window. Shared state consists of: - Workspace files - Generated artifacts - The orchestrator’s accumulated transcript - Each round includes a proposer response, challenger response, and orchestrator decision. - The protocol distinguishes manageable uncertainty from blocking risk. - Consistent schemas make agent outputs easy to parse, compare, and feed into subsequent rounds. - For example, a challenger can identify an unclear scope boundary, explain why it matters, assign severity and confidence, and indicate whether user input is required. ## Overall Impact - Issues move through a continuous chain: debated specification, branch, tested implementation, and review-ready PR. - Humans intervene mainly to define intent, approve the final result, or resolve explicitly escalated decisions. - The central leverage comes not from generating code faster, but from requiring AI to explore, challenge, verify, and package its work before asking engineers to pay attention. The practical recommendation is to redesign AI development around explicit artifacts, specialized adversarial roles, evidence-based decisions, and automated handoffs. Human engineers should remain the final decision-makers, while AI handles the intermediate coordination and proof-building work.

AI Agents CI/CD Code Review Json+3

lineJun 25, 20264 min readCurated summary

In the AI Era, Development Ability Is Determined by Verification Skills: Strategies for Rapid Validation and Local Environment Setup Learned While Developing the Flava API Gateway

AI coding agents iterate quickly, but their output can be inconsistent, make incorrect design decisions, or generate code that does not compile. Because CI runs, environment provisioning, and human review are slower, the article argues that reliable agent-assisted development requires three practices: spec-driven development, automated verification, and fast, self-contained local environments. ## Flava API Gateway and the Development Challenge - Flava API Gateway is part of LY Corporation’s private Flava cloud. - It provides a multi-tenant RESTful control-plane API for creating, deploying, and monitoring web APIs. - Kong serves as the data plane. - The team adopted agent-based coding while building the product and focused on preserving software reliability without sacrificing AI-driven speed. ## Spec-Driven Development The team found that agents became more unpredictable when implementation began before the design was settled. They use explicit specifications to reduce ambiguity and constrain implementation decisions. - OpenAPI is written before code to define the control-plane API. - Features are divided into smaller units and implemented with OpenSpec. - Specifications serve both as implementation guidance and as a standard for detecting deviations. ### Managing OpenAPI with Nickel - Raw OpenAPI YAML is repetitive and difficult to maintain manually. - Nickel is used to describe API resources declaratively and generate complete CRUD specifications. - A resource definition can specify: - Description and parent resource - Whether updates are allowed - Automatic timestamps - Property schemas - Required fields - Sorting and filtering behavior - The generator produces consistent endpoints such as `listPaths`, `createPath`, `getPath`, and `deletePath`. - Generated endpoints include pagination, sorting, filtering, ETags for optimistic locking, and standardized error responses. ### OpenSpec Workflow OpenSpec structures each change into four artifacts: - **Proposal:** Why the change is needed and what will change - **Design:** Technical decisions and trade-offs - **Delta specifications:** Behavioral requirements written as Given-When-Then scenarios - **Task list:** A step-by-step implementation checklist The developer and agent review the feature together, the agent creates these artifacts, and then implements the checklist incrementally. Once complete, the delta specification is archived into the main specification library, creating a versioned, evolving record of the system’s behavior. ## Automated Verification The team initially tried adding lists of pitfalls to prompts, but found this ineffective and potentially harmful. Instead, they made tests and tools reveal errors progressively so the agent could diagnose and correct them. - Automated tests, linters, and formatters provide precise feedback. - Failed tests identify what went wrong, allowing the agent to fix one issue before moving to the next. - Project-specific skills bundle these checks together. - `AGENTS.md` tells the agent when to load the relevant skills, avoiding unnecessary instructions on every turn. - Testing and linting are treated as essential infrastructure rather than optional activities, since agents frequently make errors during implementation. ## Fast, Independent Local Environments Relying on CI and shared test environments is too slow for agent-driven iteration. Long waits can disrupt the agent’s context and make repeated experimentation impractical. - A complete local environment provides immediate feedback. - Local dependencies make logs and state easier to inspect. - Developers avoid sending every failed attempt through a remote pipeline. - The local test suite contains 2,754 tests across three layers: - **Unit tests:** Isolated business logic - **Integration tests:** Real PostgreSQL, database constraints, triggers, soft-delete cascades, transactions, in-process HTTP, and OpenAPI compliance - **End-to-end tests:** Athenz authentication, Kong, API keys, and multi-tenant isolation - The full suite completes in roughly 15 seconds on a developer machine. - Parallel execution and strong test isolation are critical to achieving this speed. ## Practical Recommendation Agent-assisted development works best when agents are given clear behavioral contracts, immediate automated feedback, and a fast local loop. Teams should invest in specifications, comprehensive tests and linting, and realistic local dependencies so agents can correct mistakes continuously without waiting for CI.

PostgreSQL Coding Agents Automated Testing Openapi+4

gitlabJun 25, 20263 min readCurated summary

Google Antigravity agents get full context with GitLab Orbit

Google Antigravity agents can now access GitLab’s broader software lifecycle context through GitLab Orbit, available in the Antigravity MCP Store. Orbit builds a knowledge graph connecting code, projects, dependencies, merge requests, pipelines, users, and vulnerabilities, allowing agents to answer questions that would otherwise require manual research across GitLab. GitLab reports that internally tested agents using Orbit were up to 11 times faster, used 4.5 times fewer tokens, and hallucinated up to 45 times less. ## GitLab Orbit Adds Lifecycle Context - Antigravity agents can normally access files and terminals but lack information about: - Service dependencies - Related vulnerabilities - Merge request history - Code ownership and reviewers - Pipeline performance - Orbit indexes GitLab and exposes its knowledge graph through: - `query_graph` for structured lifecycle queries - `get_graph_schema` for available node types, properties, and relationships - Agents receive typed results through GitLab Orbit’s JSON query DSL. ## Practical Development Use Cases ### Blast radius analysis - Engineers can identify which projects depend on a module before refactoring it. - Agents can also find open merge requests affecting those files and identify their owners. - This reveals conflicts and stakeholders before changes are made. ### Onboarding and codebase exploration - Agents can explain a service’s dependencies, entry points, and recently opened merge requests. - Results can be captured in a persistent Walkthrough Artifact rather than disappearing in chat. - Orbit reindexes changes within minutes, keeping documentation more current than static wikis. ### Live architecture diagrams - Agents can query service dependencies and render them as diagrams using Nano Banana Pro. - Diagrams can be filtered, such as showing only services with unresolved security findings. - Access controls apply to every query, making generated diagrams safe to share. - GitLab is developing similar functionality through its Software Architecture Map. ## Installation Through the MCP Store - Open Antigravity settings and go to the customization tab. - Find the MCP section and select **Add MCP**. - Choose GitLab Orbit and authenticate with GitLab. - No configuration files or terminal commands are required. ## Availability and Technical Details - Orbit uses the same context engine as GitLab Duo Agent Platform. - It supports code indexing for Ruby, Java, Kotlin, Python, TypeScript, JavaScript, Rust, and C#. - Code is indexed from the default branch and refreshed within minutes. - MCP queries consume GitLab Credits, while `get_graph_schema` calls are free. - The feature is available to GitLab Premium and Ultimate customers on GitLab.com. For teams already using GitLab and Google Antigravity, GitLab Orbit provides a governed, current context layer that can make agents more accurate and useful. Teams should enable Orbit for a top-level group and install it through the Antigravity MCP Store, while accounting for GitLab tier requirements and credit usage.

Model Context Protocol DevSecOps Gitlab Duo Agent Platform Gitlab Orbit+3

googleJun 25, 20263 min readCurated summary

Optimizing cloud economics with linear elastic caching

Linear elastic caching treats cache memory as a variable cost rather than a fixed allocation. It dynamically adjusts how long pages remain in memory by balancing ongoing memory expense against the cost of fetching evicted data again, using the ski rental problem as its theoretical foundation. Experiments in Spanner and public cache traces show meaningful cost reductions with only modest increases in misses. ## Fixed-Size Cache Limitations - Traditional caches allocate a fixed amount of RAM and use policies such as LRU when space runs out. - Undersizing the cache causes excessive disk or storage access and poor performance. - Oversizing it wastes money during periods of low demand; some serverless providers charge up to $3 per day for 1 GiB of memory. - Fixed sizing therefore creates a “Goldilocks” problem as workloads fluctuate. ## Ski Rental Model for Cache Eviction - Each cached page presents two choices: - **Rent:** Keep it in RAM and continuously pay for its memory footprint. - **Buy the miss:** Evict it and risk a latency and I/O penalty if it is requested again. - A ski rental algorithm assigns each page a time-to-live (TTL). - If the page is not accessed before its TTL expires, it is evicted. - If the cache becomes physically full, a conventional policy such as LRU handles capacity pressure. - The researchers prove that eviction policy and rental duration can be optimized separately, simplifying implementation. - Unlike worst-case break-even or randomized ski rental strategies, lightweight machine learning can exploit predictable workload patterns. ## Lightweight TTL Prediction - In Spanner, each page receives a TTL based on: - Page size - Cost of a cache miss - Type of database operation - Observed access behavior - A shallow decision tree was chosen because Spanner processes billions of requests per second. - The model can be translated into a few lines of interpretable C++ code. - Its cost-aware decisions allow extra misses mainly for data that is inexpensive to retrieve. ## Spanner Production Results - Compared with a standard fixed-size cache: - Memory usage fell by **15.5%**. - Cache misses increased by only **5.5%**. - Total cost of ownership fell by approximately **5%**. - The additional misses increased actual I/O costs by only **0.5%**, because they were concentrated on cheap-to-fetch data. - The policy was deployed on production Spanner servers and evaluated over several months. ## Public Trace Evaluation - The approach was tested on public industry cache traces using GDSF as the fixed-size baseline. - GDSF generalizes LRU to account for pages with different sizes. - Researchers evaluated four elastic-cache variants using: - Break-even or randomized ski rental policies - Learned or non-learned TTL selection - Because public traces lacked application-level features, learning used the first half of each trace to calculate the best TTL for individual pages. - Caches were warmed with one day of requests before performance measurement began. ## Overall Results - Elastic caching consistently produced lower total cost across diverse workloads. - Its advantage increased as memory became more expensive relative to cache misses. - At comparable cache sizes, elastic policies also achieved substantially lower miss rates than fixed-size approaches. Linear elastic caching is most useful when memory costs vary significantly or workloads are bursty and predictable. Dynamically assigning page TTLs offers a practical way to reduce memory spending while limiting performance impact, especially when the system can estimate the cost of each miss.

Machine Learning Caching C Plus Plus Database Systems+4

discordJun 25, 20262 min readCurated summary

Discord Update: June 25, 2026 Changelog

Discord’s June 25, 2026 changelog focuses on making game discovery, mobile navigation, and social interactions more convenient. Highlights include a weekly Trending Games page, faster iOS uploads, improved mobile controls, easier friend invitations, and richer game information. Discord also adds organizational tools such as pinned DMs and channels. ## Trending Games - A new Trending Games page updates every Thursday. - It showcases popular single-player and multiplayer games across Discord. - The page is designed to help users find games to play or stream during game nights. ## Mobile Updates - **Tap to React** lets users double-tap a message to apply a preset emoji. - The shortcut emoji can be configured in **User Settings > Chat**. - A new **You Bar** gives mobile users quicker access to their identity and profile. - Mobile users must confirm before calling a DM or Group DM, reducing accidental calls. - iOS photo uploads are approximately **17% smaller** and have about **12% lower latency** after compression and performance improvements. - Wishlists are now available on mobile, including the ability to view other users’ wishlists. ## Chats, Channels, and Game Communication - Discord and Riot account linking is rolling out for **League of Legends** and **VALORANT**. - Players can view Discord friends in-game and invite them directly from the Riot game client. - DMs, Group DMs, and server channels can be pinned for easier access. - Voice invitations now indicate who is currently in the call, helping users avoid unexpected interruptions. - Desktop users are encouraged to send a wave after adding someone new, though they can send any message they choose. ## Expanded Game Profiles - Game Profile pages now include: - Screenshots - Supported platforms - Steam and OpenCritic reviews - Popularity on Discord - Links to the game’s official Discord server - Users can open these profiles by clicking a game’s name while someone is playing it. Discord’s updates primarily improve discovery and reduce friction across mobile, messaging, and gaming workflows. Users looking for additional changes can consult the latest monthly Patch Notes for bug fixes and other improvements.

Discord iOS Mobile App Steam+4