Techlist.io - Korean Tech Blog Curator

stripe·May 27, 2026·3 min readCurated summary

Expanding Stripe Radar to protect more of your business

Stripe has significantly expanded Radar from card fraud prevention into a broader, AI-powered risk platform. It now protects transactions across global payment methods, supports off-Stripe fraud signals and custom models, detects newer abuses such as multi-account and pay-as-you-go fraud, and helps platforms assess merchant risk. Stripe’s goal is to let businesses intervene earlier and with greater precision while reducing false positives and operational losses. ## Global Payment Coverage and Custom Fraud Models - Radar now protects transactions across supported payment methods, including: - Bank debits - BNPL - Crypto - Digital wallets - Real-time payments - Cash vouchers - Fraud signals such as IP addresses and device fingerprints can now protect transactions across payment methods and businesses on the Stripe network. - Stripe reported a 71% reduction in suspected fraud over five months for businesses using Affirm, Cash App, Klarna, and PayPal. - New multiprocessor signals predict: - Whether a transaction may trigger an early fraud warning - Whether it is likely to result in a fraudulent dispute - Businesses can use these predictions to refund transactions early, gather evidence, or adjust dispute strategies. - Custom fraud models allow businesses to provide proprietary signals such as: - Product catalog information - Loyalty status - Behavioral data - Structured metadata - Early adopters detected at least 15% more fraud without increasing false positives. ## Defending Against New Fraud Types ### Multi-Account Abuse - Fraudsters create multiple accounts to reuse promotions or distribute stolen-card activity. - More than one in six AI-company sign-ups on Stripe are associated with multi-account abuse. - Radar evaluates accounts in real time using network-wide signals such as device fingerprints, IP addresses, and email domains. - ElevenLabs reportedly blocks around 2,000 abusive users per day from its free tier. ### Pay-As-You-Go Abuse - Customers can consume substantial resources and intentionally avoid paying when billed later. - Radar predicts nonpayment risk as usage accumulates. - Businesses can respond by requiring top-ups, suspending service, or applying other controls before billing. ### Malicious Bot Payments - Radar assigns a bot score to Stripe Checkout payments. - Businesses can distinguish legitimate automated agents from malicious bots. - The score can support controls against: - Inventory hoarding - Promotional abuse - Purchase-limit bypasses - High-velocity automated orders ## Platform and Merchant Risk Management - Platforms receive 0–100 fraud scores for businesses and transactions. - AI-powered explanations, notes, account history, and account-level metrics help risk teams investigate merchants. - New merchant-risk signals include: - **Fraudulent website signal:** Detects suspicious pricing, AI-generated copy, misspelled domains, and other website red flags. - **Fraudulent merchant signal:** Uses business information, bank details, transaction activity, and disputes to identify risky accounts. - **Merchant delinquency risk signal:** Predicts whether a merchant’s negative balance is likely to persist for at least 60 days. - Platforms can use these signals to automate verification, trigger reviews, pause payments or payouts, reject accounts, establish reserves, adjust payout schedules, or request additional identity verification. Stripe’s expanded Radar offering is designed to move fraud prevention earlier in the customer and merchant lifecycle. Businesses and platforms should combine these network-wide signals with their own risk tolerance and workflows to block abuse proactively while minimizing unnecessary friction.

Read original(opens in new tab)

Machine LearningFraud DetectionPayment ProcessingBot Detection+4

google·May 27, 2026·3 min readCurated summary

Private analytics via zero-trust aggregation

Google presents a private analytics architecture combining one-shot cryptographic secure aggregation with trusted execution environments (TEEs). The design follows a zero-trust model: cryptography prevents individual data from being reconstructed, while TEE attestation verifies that approved, publicly auditable code is running. It aims to provide useful population-level insights without exposing raw user data, even if hardware protections are compromised. ## Why Private Analytics Matters - On-device AI protects user information, but developers still need to measure performance across millions of devices. - Aggregated analytics can reveal: - Model drift, such as difficulty handling new language or slang. - Hidden biases across regions, environments, or demographic conditions. - Real-world error rates and user reactions to model outputs. - Google already uses federated analytics in products including Pixel Recorder and Gboard. ## Limitations of Existing Protections - **TEEs** isolate sensitive computation from compromised operating systems and hypervisors. - Hardware attestation produces a cryptographic fingerprint proving which firmware and software are running. - However, TEEs remain vulnerable to newly discovered side-channel attacks. - Traditional cryptographic aggregation offers mathematical privacy guarantees, but many protocols require devices to stay online through several interactive rounds. - Extended multiround participation limits practical deployment at large scale. ## Combining Encryption and Isolation - The new system allows devices to submit data in a single message. - This removes the need for devices to remain connected for multiple protocol rounds. - Data is encrypted before leaving the device and is never reconstructed in server memory, including inside a TEE. - Unencrypted information is processed off-device only after it has been aggregated and anonymized. - TEE attestation provides verifiable evidence that the intended secure aggregation implementation is running correctly. - The cryptographic and hardware layers provide defense in depth: failure of one layer does not automatically expose individual data. ## One-Shot Lattice-Based Aggregation - The protocol uses lattice-based cryptography. - Ciphertexts can be combined so that their underlying data—and encryption keys—are aggregated together. - A resulting decryption key can reveal only the aggregate, not individual contributions. - Small client committees hold decryption hints and help unlock the aggregated result. - Differential privacy noise is added to further protect the aggregate. - Decryption authority is distributed across multiple parties, preventing any single party from accessing encrypted data. ## Application to Android SafetyCore - SafetyCore provides privacy-preserving, on-device safety features for Android 9 and later. - Private analytics can help measure which threats are detected and identify areas where detection needs improvement. - Google is working with the Android SafetyCore team to apply this system while preserving the confidentiality of individual users’ data. ## Practical Takeaway The approach pairs the scalability of one-shot cryptographic aggregation with the verifiability of TEEs. It is designed for private, large-scale analytics where neither individual data nor trust in a single hardware or software component is required.

Read original(opens in new tab)

Zero TrustDifferential PrivacyOn Device AiFederated Analytics+3

meta·May 26, 2026·4 min readCurated summary

SilverTorch: Index as Model — A New Retrieval Paradigm for Recommendation Systems

SilverTorch is a unified, GPU-based recommendation retrieval system designed to replace fragmented microservices with one integrated neural network. Its “Index as Model” architecture represents retrieval components—including item indices, filtering, reranking, and user modeling—as PyTorch modules. The system reportedly delivers up to 23.7× higher throughput and 20.9× better compute-cost efficiency than comparable CPU-based or traditional multi-service systems, while improving recommendation quality. ## Limits of Microservice-Based Retrieval - Traditional retrieval pipelines use separate services for: - Computing user embeddings - Finding similar content - Applying eligibility rules - Scoring and reranking candidates - An orchestrator coordinates these services before passing thousands of candidates to downstream ranking, all within roughly 100 milliseconds. - This architecture creates several structural problems: - **Data movement:** Network calls, serialization, and service coordination consume latency that could otherwise support more computation. - **Version inconsistency:** User models, item indices, and filtering rules may be updated independently, causing mismatches between user and item representations. - **Siloed engineering:** ML teams typically work in PyTorch while infrastructure teams work in C++, making improvements difficult to translate, test, and deploy. - GPU optimizations such as Faiss-GPU can accelerate individual services but do not eliminate the architectural overhead or enable deep coordination between components. ## Index as Model - SilverTorch replaces the service mesh with a single neural network. - Its central design principle, **Index as Model**, turns traditional retrieval artifacts into model components: - Item indices become tensors. - Eligibility filters become operators. - User towers, scoring layers, and rerankers become modules. - A single request passes through the integrated model, which: - Finds content relevant to the user’s interests - Applies language, geography, and policy constraints - Predicts multiple engagement outcomes - Produces a combined score for the final candidate set - This integration enables more complex models and larger candidate evaluations without exceeding the sub-100-millisecond latency target. ## Unified Retrieval Components - SilverTorch incorporates multiple functional regions within one model: - Approximate nearest-neighbor search identifies relevant items efficiently. - Eligibility filtering removes content that cannot be shown to a user. - Multi-task reranking predicts actions such as likes, shares, and comments. - Composite scoring combines these predictions into a final ranking signal. - Some components are hand-engineered, while others can be trained end-to-end through backpropagation. - From the runtime’s perspective, every component is a standard PyTorch `nn.Module`, regardless of whether it performs search, filtering, or learned prediction. ## Pure PyTorch Implementation - SilverTorch reimplements ANN search, Bloom-filter indexing, eligibility checks, neural reranking, and composite scoring as pure PyTorch modules. - The unified design requires: - Tensor-based data representation - Tensor-in, tensor-out operations - A consistent `nn.Module` interface - This allows modules to share memory, execution graphs, and compilation steps. - Engineers can co-design stages—for example, selecting promising clusters, filtering within them, and scoring only surviving candidates—instead of treating each operation as an isolated service. - The approach reduces the separation between ML and infrastructure engineering, allowing both groups to work within the same programmable layer. ## Performance and Scale - In an 80-million-item end-to-end evaluation, SilverTorch achieved: - **23.7× higher requests per second** than a strong traditional multi-service baseline using the same model architecture. - **20.9× better estimated total-cost-of-ownership efficiency** than a CPU-based solution. - The system is intended to support retrieval across multiple applications and large-scale feeds and video products. - Its increased efficiency makes neural reranking and multi-task engagement scoring practical within strict production latency budgets. SilverTorch’s main recommendation is architectural: consolidate retrieval into a single, composable model rather than optimizing disconnected services. Representing every retrieval stage as a PyTorch module can reduce overhead, improve consistency, enable deeper cross-stage optimization, and make more sophisticated recommendations feasible at scale.

Read original(opens in new tab)

MicroservicesRecommendation SystemsNeural NetworksPytorch+3

gitlab·May 26, 2026·3 min readCurated summary

Full security scanner coverage of your codebase in minutes

GitLab 19.0 introduces security configuration profiles, enabling teams to centrally apply SAST, dependency scanning, and secret detection across many projects without editing individual `.gitlab-ci.yml` files. Profiles address coverage gaps caused by organizational growth, inconsistent configuration, and rapidly increasing AI-driven development. By applying default profiles in bulk, teams can achieve broad scanner coverage within minutes. ## Why Manual Scanner Configuration Falls Short - Per-project YAML configuration becomes difficult to maintain as organizations add repositories and teams. - Scanner settings can drift between frontend, backend, and older projects. - Pipeline changes may accidentally remove security scanners. - New projects may receive scanning while existing projects remain unprotected. ## Security Configuration Profiles - Profiles are centralized group-level settings defining how and when scanners run. - Teams can apply one profile to many projects through the GitLab UI. - GitLab provides default profiles for: - Static application security testing (SAST) - Dependency scanning - Secret detection - Default profiles use recommended settings and require no manual YAML changes. ## Scan Triggers and Coverage - SAST and dependency scanning run on: - Merge request pipelines, identifying vulnerabilities introduced by the proposed changes. - Pipelines on the default branch, maintaining a complete view of its security posture. - Secret detection supports both pipeline triggers plus push protection. - Push protection detects and blocks secrets during `git push`, before they enter the repository. - Push protection is event-based and therefore does not have a scan date in the security inventory. ## Practical Security Use Cases - Security teams can select hundreds of projects from the security inventory and apply scanners in bulk. - SAST can catch insecure code patterns before a merge request is approved. - Dependency scanning can detect compromised packages before they reach production. - Secret detection can block accidentally committed API keys immediately, avoiding later remediation and credential rotation. ## Getting Started - Available on GitLab Ultimate for GitLab.com, Self-Managed, and Dedicated. - Navigate to **Secure > Security inventory** for a group. - Select projects, choose **Manage security scanners** from **Bulk Action**, and select **Apply default profile to all**. - Review scanner status in the **Tool Coverage** column: - Green indicates full activation. - Partial coverage indicates some triggers are enabled. - Gray indicates the scanner is not configured. - Existing `.gitlab-ci.yml` settings can coexist with profiles, but inventory status may be inaccurate during the transition. Check the project’s **Security Configuration** page for the most reliable profile status. Organizations using GitLab Ultimate should apply default security profiles broadly, then review coverage and project-specific configurations to ensure every relevant trigger is active.

Read original(opens in new tab)

CI/CDGitlabYamlSast+4

gitlab·May 26, 2026·3 min readCurated summary

Reduce supply chain risk with SBOM-based dependency scanning

SBOM-based dependency scanning in GitLab 19.0 addresses the limits of traditional scanners that focus only on declared packages and known CVEs. It inventories direct and transitive dependencies, traces how vulnerable packages entered a project, and identifies whether application code actually reaches them. The result is more targeted remediation and easier organization-wide enforcement of supply chain security. ## Why Traditional Dependency Scanning Falls Short - Modern applications rely heavily on third-party and deeply nested dependencies. - Supply chain compromises can affect every project that depends on a vulnerable package. - AI-generated code further increases risk, with research indicating that nearly half contains vulnerabilities. - Teams need to know not only which packages are vulnerable, but also: - How they entered the project - What dependencies they brought with them - Whether the application actually uses them ## How SBOM-Based Scanning Works - The analyzer inventories dependencies in a CycloneDX-format software bill of materials. - Components are matched against the GitLab Advisory Database to identify known vulnerabilities. - Findings appear in: - Merge requests, so developers can address issues before release - Vulnerability dashboards and reports, for centralized security oversight - GitLab produces both an SBOM and a dependency scanning report for compliance and supply chain tooling. ## Tracing and Prioritizing Vulnerabilities - The analyzer follows transitive dependency chains regardless of nesting depth. - Teams can see the path a vulnerable package took into the project—for example, `library-a` → `library-b` → `library-c`. - For Java, JavaScript/TypeScript, and Python, GitLab checks whether vulnerable packages are directly imported or required. - Findings include reachability status, helping teams prioritize vulnerabilities their code can plausibly execute. - Scans can run on merge requests, pipeline executions, and when new advisories are published, including for production systems with little ongoing development. ## Supported Ecosystems and Input Files - The release supports more than 24 package ecosystems, with additional support planned. - Lockfiles and dependency graphs are preferred because they provide complete transitive dependency information. - If those are unavailable, the analyzer can parse manifests such as: - `pom.xml` - `requirements.txt` - Gradle build files - Manifest scanning identifies direct dependencies but offers less complete coverage because transitive dependencies may be missing. ## Centralized Configuration and Enforcement - GitLab 19.0 provides a security configuration profile for applying dependency scanning across many projects. - Security and platform teams can configure scanning once instead of maintaining individual pipeline files. - Scan execution policies and pipeline execution policies can enforce requirements at the group or instance level without modifying `.gitlab-ci.yml` files. - Centralized policies reduce configuration drift, skipped projects, and audit gaps. ## Availability and Migration - SBOM-based dependency scanning is available to GitLab Ultimate customers on GitLab.com and is rolling out to Dedicated and self-managed installations. - Teams migrating from Gemnasium can run both analyzers in parallel and compare their results. - GitLab provides setup instructions, migration guidance, and documentation for supported languages and advanced configuration. Teams should prefer lockfile-based SBOM scanning, enable it centrally through security policies, and prioritize remediation based on dependency reachability rather than vulnerability presence alone.

Read original(opens in new tab)

GitlabDevSecOpsVulnerability ManagementDependency Scanning+4

figma·May 26, 2026·2 min readCurated summary

Issue no.16: Trust the process | Figma Blog

Issue 16 of Figma’s newsletter, “Trust the Process,” explores how AI and agentic tools are changing product design. Its central argument is that faster creation makes judgment, context, and craft more important—not less. Teams need to choose the right problems, preserve design intent, and build workflows that connect design and code. ## Choosing What’s Worth Shipping - AI enables product teams to build and iterate rapidly. - The main risk is moving quickly in the wrong direction or settling for “good enough” output. - Strong product judgment and a clear sense of what creates meaningful differentiation remain essential. ## Using MCP to Preserve Context - Model Context Protocol (MCP) allows coding agents to access context from Figma files and design systems. - Figma’s MCP server helps developers translate design decisions into code more accurately. - Better documentation and structured design systems can make this workflow more effective. ## Building Visual Workflows with AI - Figma Weave supports AI-assisted work across video, photography, illustration, and 3D effects. - The newsletter highlights more than 20 workflow templates and methods for creating asset libraries from reference images. - Effective prompting depends on understanding the logic behind a visual language, including how to build, edit, and direct imagery consistently. ## The Design-to-Code Loop - Modern teams increasingly move back and forth between canvas and code. - This “roundtripping” gives designers and developers faster feedback and deeper product context. - Keeping real product states connected to the canvas can reduce drift between what is designed and what ultimately ships. - The convergence of design and development creates more opportunities to improve both speed and craft. ## Practical Experiments - A workflow lab demonstrates how Figma MCP can help teams refine a video export flow by bringing real product states into the design canvas. - Figma also offers efficiency tips for users who rely heavily on Figma Make, including ways to manage credits and streamline workflows. The newsletter recommends treating AI as an accelerator rather than a substitute for direction. The best results come from combining faster tools with deliberate judgment, strong context, and continuous collaboration between design and code.

Read original(opens in new tab)

FigmaAIModel Context ProtocolDesign To Code+2

aws·May 25, 2026·3 min readCurated summary

AWS Weekly Roundup: AWS Local Zones in Istanbul, open-source ExtendDB, Kiro Web, and more (May 25, 2026) | Amazon Web Services

AWS’s latest updates focus on expanding regional infrastructure, improving developer workflows, and making cloud and AI services more portable. The Istanbul Local Zone strengthens data residency and low-latency capabilities in Türkiye, while tools such as ExtendDB, OpenAI-compatible SageMaker APIs, and Kiro Web reduce migration and development friction. Together, these releases emphasize flexibility, operational resilience, and easier local testing. ## AWS Local Zone in Istanbul - AWS opened a new Local Zone in Istanbul, Türkiye. - It provides nearby compute, storage, and networking with single-digit millisecond latency. - Organizations can keep and process data within Turkish borders to support residency and compliance requirements. - The zone supports latency-sensitive workloads in sectors such as finance, government, telecommunications, and healthcare. - Applications can combine Istanbul infrastructure with the broader AWS Region, enabling hybrid architectures without operating a private data center. ## Security and AI Service Updates - **Security Hub Extended** now integrates with 21 curated partner solutions across nine security categories, including endpoint protection, threat intelligence, and cloud security posture management. - **Amazon SageMaker AI** supports OpenAI-compatible inference APIs, allowing existing OpenAI-based applications to use SageMaker with minimal or no SDK changes. - **Secrets Manager Agent** can pre-fetch secrets at startup, reducing cold-start delays, and can assume IAM roles for workloads with different permission boundaries. - **Amazon Bedrock** introduced tools for advanced prompt optimization and migration across foundation models. ## Open-Source and Local Development Tools - AWS open-sourced **ExtendDB**, a DynamoDB-compatible adapter for alternative storage backends. - It supports local development and testing without a live AWS connection. - It can help teams retain DynamoDB API semantics while controlling the underlying storage layer. - **AWS SAM CLI** now supports CloudFormation Language Extensions locally, improving consistency between local testing and production deployments. ## Developer Experience and Reliability - **Kiro Web** brings AWS’s AI-assisted, spec-driven development environment to browsers, providing access to chat and agent capabilities without installing the desktop IDE. - AWS updated default retry behavior across SDKs and CLI tools. - Improvements include smarter backoff and better throttling handling. - Production applications should become more resilient to transient failures without additional configuration. ## Container Image Changes - Bitnami images are being removed from Amazon ECR Public. - Teams currently using those images should review the migration timeline and update image references to Bitnami’s own registry to avoid interruptions. ## Upcoming AWS Events - AWS Summit Amsterdam: May 27 - AWS Summit Bangkok: May 28 - AWS Summit Milan: May 28 Builders should evaluate the Istanbul Local Zone for residency- or latency-sensitive systems, consider ExtendDB and SAM improvements for local workflows, and review the Bitnami registry change before images are removed from ECR Public.

Read original(opens in new tab)

AIAWSAmazon BedrockServerless+4

github·May 25, 2026·3 min readCurated summary

GitHub for Beginners: Getting started with Git and GitHub in VS Code

VS Code provides an integrated way to manage Git and GitHub without leaving the editor, reducing context switching and simplifying common version-control tasks. The post walks beginners through initializing a repository, staging and committing files, creating branches, tracking edits, and reviewing diffs. It emphasizes that Git manages source code locally, while GitHub hosts repository copies remotely. ## Git, GitHub, and VS Code - **Git** is the program used to manage source code and version history. - **GitHub** hosts copies of Git repositories. - **VS Code** uses Git to provide a graphical workflow for managing code and synchronizing it with GitHub. - Following along requires installing both Git and VS Code. ## Initializing a Repository - Open a project folder in VS Code through the **Explorer** panel. - Select **Source Control** and click **Initialize Repository**. - VS Code creates a local Git repository, initially using the `main` branch. - The branch can be renamed through the Command Palette: - macOS: `Shift-Command-P` - Windows/Linux: `Ctrl-Shift-P` - Choose **Git: Rename Branch**. ## Staging and Committing Files - Newly detected files appear with a **U**, meaning “untracked.” - Click the plus sign beside a file—or beside **CHANGES** to stage everything. - Staged files receive an **A** indicator. - Enter a commit message in the Source Control panel and click **Commit**. - Git commits changes locally; they are not uploaded to GitHub until they are pushed. ## Creating and Switching Branches - Use the Command Palette and select **Git: Create Branch…**. - Enter a branch name such as `new-features`. - VS Code creates the branch and automatically switches to it. - The active branch is displayed in the bottom-left status bar. - Branches allow developers to work on features separately from `main`. ## Understanding Change Indicators VS Code displays edits directly in the editor gutter: - A green line marks newly added code. - A blue patterned line marks modified existing code. - A red arrow marks deleted code. - Modified files appear under **CHANGES** in the Source Control panel. - Hovering over a file provides controls to open it, discard changes, or stage it. - The **CHANGES** header also provides actions for reviewing, discarding, or staging changes across all files. ## Reviewing Diffs - Clicking a changed file opens a side-by-side comparison of the current and previous versions. - The diff menu’s **Inline View** option displays changes in a single editor pane. - Inline diffs can also be edited directly, allowing corrections before staging or committing. VS Code’s Source Control integration gives beginners a practical, visual workflow for Git. A typical process is to initialize a folder, create a working branch, inspect edits, stage selected files, commit them with a descriptive message, and then push the commits to GitHub.

Read original(opens in new tab)

GithubGitVersion ControlVisual Studio Code+3

github·May 22, 2026·3 min readCurated summary

GitHub recognized as a Leader in the Gartner® Magic Quadrant™ for Enterprise AI Coding Agents for the third year in a row

GitHub argues that AI coding has made code generation easier, shifting the main bottleneck to reviewing, securing, governing, and deploying software. It presents GitHub Copilot as an agentic platform spanning the full software development lifecycle, enabling developers to assign issues to agents and focus on reviewing and approving results. Gartner named GitHub a Leader in the 2026 Magic Quadrant for Enterprise AI Coding Agents, placing it highest for ability to execute for the third consecutive year. ## The Shift from Code Generation to Software Delivery - AI coding agents are increasingly expected to handle more than writing functions. - The harder problems now involve: - Code review - Security - Governance - Testing - Deployment - GitHub describes the new workflow as “orchestrating outcomes”: developers assign work to agents, then return to steer, review, and approve it. - Gartner projects that asynchronous AI coding-agent workflows could improve engineering productivity by 30%–50% by 2028, compared with 0%–20% gains from code assistants in 2025. ## Enterprise Adoption of GitHub Copilot - Copilot is used by 140,000 organizations, nearly three times the number reported a year earlier. - Overall growth exceeded 100% year over year. - Most users work with multiple AI models. - GitHub Copilot CLI usage nearly doubled month over month. - GitHub says these figures indicate that enterprises are adopting increasingly sophisticated, agent-driven workflows. ## Gartner’s 2026 Evaluation - Gartner evaluated 12 enterprise AI coding-agent vendors according to: - Ability to execute - Completeness of vision - GitHub was positioned as a Leader and ranked highest in ability to execute. - Gartner describes Leaders as vendors combining strong execution, market-shaping vision, rapid innovation, broad software-engineering relevance, and enterprise-grade security and governance. - The report’s Leader quadrant also includes Anthropic, Cursor, and OpenAI. ## GitHub’s Claimed Differentiators - **Developer choice:** Copilot supports multiple models and providers. - **Broad availability:** It works across editors, IDEs, CLIs, and GitHub’s web, desktop, and mobile applications. - **Full-lifecycle integration:** Copilot operates across issues, pull requests, code reviews, and GitHub Actions—not only inside the editor. - **Enterprise governance:** Teams can observe, audit, and secure how AI is used in engineering workflows. ## What GitHub Plans to Build Next - GitHub says it will expand agentic workflows across more developer-facing surfaces. - Planned investments include: - Greater model choice and intelligent model routing - Deeper integrations throughout the software lifecycle - Performance improvements based on how software is actually built and maintained on GitHub GitHub’s central recommendation is to treat AI coding agents as part of an end-to-end engineering platform rather than isolated code-generation tools. The post also notes that Gartner’s recognition is not an endorsement and that its findings should be considered alongside the full research report.

Read original(opens in new tab)

Github CopilotCode ReviewGithub Copilot CliAgentic Workflows+4

grammarly·May 22, 2026·2 min readCurated summary

How to Write a Salary Negotiation Email: Format and Examples

A salary negotiation email is a written counteroffer that helps candidates present their case clearly after receiving a formal job offer. The strongest emails combine market data with two or three measurable accomplishments, state a specific target, and maintain a collaborative tone. If base salary is inflexible, candidates can negotiate other parts of total compensation. ## Preparing Your Case - Research comparable salaries using sources such as Glassdoor, LinkedIn Salary, Payscale, and the Bureau of Labor Statistics. - Choose a specific target or narrow range based on the market, ideally toward the higher end of your acceptable range. - Support the request with quantifiable achievements tied to business outcomes, such as reducing onboarding time by 30% or improving client retention. - Consider the entire compensation package, including: - Signing bonuses - Additional PTO - Remote or hybrid flexibility - Earlier performance reviews - Professional development budgets ## Structuring the Email - Use a clear subject line, such as “Job Offer – [Your Name] – [Role Title]” or “Compensation Discussion – [Your Name].” - Open by thanking the employer and expressing enthusiasm for the role. - Explain the request using market data first, then connect it to relevant experience and accomplishments. - State a concrete counteroffer, such as a target salary or narrow range. - Phrase the request as an invitation to discuss rather than a demand. - Close by reaffirming interest in the position and openness to finding a mutually workable package. ## When to Send It - Negotiate after receiving a formal written offer but before accepting or signing. - If the offer was initially verbal, wait for the written version. - Respond within roughly one to two business days to keep the discussion timely. ## Mistakes to Avoid - Do not rely on vague claims such as having “a lot of experience.” - Avoid personal financial arguments involving rent, expenses, or cost of living. - Do not ask for “something higher” without naming a specific figure. - Avoid demanding or final language that could make the conversation adversarial. - Focus on professional value, relevant market ranges, and the full compensation package. A concise, evidence-based email gives employers a clear reason to reconsider the offer while preserving a positive relationship. Prepare market data and measurable accomplishments in advance, then make a specific, collaborative counteroffer before committing.

Read original(opens in new tab)

GrammarlyProfessional CommunicationSalary NegotiationCompensation+2

grammarly·May 22, 2026·2 min readCurated summary

How to Reply to a Job Rejection Email, With Examples

A thoughtful reply to a job rejection can preserve the relationship, demonstrate professionalism, and keep future opportunities open. The best responses acknowledge the decision, express genuine appreciation, and end with forward-looking language without trying to reverse the employer’s choice. Replies should be concise, personalized, and sent within 24–48 hours after taking time to process the news. ## Understanding Job Rejection Emails - A rejection email informs a candidate they will not advance after applying, screening, or interviewing. - It may be automated and brief or personalized after substantial interaction with the hiring team. - The level of contact should guide how detailed your reply needs to be. ## How to Reply Professionally - **Acknowledge the decision directly:** Begin with a clear statement such as, “Thank you for letting me know about your decision.” - **Show appreciation:** Thank the employer for their time and the opportunity. - **Personalize the message:** Mention one specific project, team detail, or topic discussed during the interview. - **Ask for feedback selectively:** After a substantial interview process, request feedback in a brief, optional way. - **Use forward-looking language:** Express interest in future roles if sincere, or simply wish the team well. - **Keep it concise:** Aim for two or three short paragraphs, use a professional sign-off, and reply in the original email thread. ## When to Send the Reply - Respond within **24–48 hours**. - Take a few hours to process the rejection before writing so the response remains composed. - A reply is usually unnecessary for clearly automated rejections or situations involving minimal interaction. ## Choosing the Right Response - **Early-stage rejection:** Send a short thank-you and ask to be considered for similar future roles. - **Post-interview rejection:** Thank the team, reference a specific discussion point, and express interest in future opportunities. - **Feedback request:** Ask for constructive input without creating pressure to respond. - Personalize each message with details from your experience rather than using a completely generic template. ## Mistakes to Avoid - Re-pitching yourself or arguing against the hiring decision. - Overexplaining your disappointment. - Asking for feedback in a demanding or entitled tone. - Sending an immediate emotional response. - Writing a message that is unnecessarily long. A brief, gracious reply is usually the best approach: thank the employer, personalize the message, and leave the relationship on a positive note.

Read original(opens in new tab)

Professional CommunicationEmail WritingEmail EtiquetteJob Search+1

line·May 22, 2026·4 min readCurated summary

ODW #7: Reduce Token Consumption by 40% in Three Ways! Context Engineering with ADK

The post explains how LY Corporation’s Orchestration Development Workshop uses context engineering to reduce AI-agent costs and improve accuracy. As internal adoption of tools such as Claude Code, Cline, and ADK grows, excessive token usage, missed instructions, and declining performance in long conversations have become common. The recommended solution is to deliberately select and manage the context sent to an LLM, demonstrated through an ADK-based Jira weekly-report agent. ## Problems Caused by Expanding AI Use - Increased AI adoption has led to unexpectedly high token consumption. - Users often receive incomplete or incorrect results despite providing detailed prompts. - Long-running conversations can cause the model to produce irrelevant answers. - Major causes include: - Trial-and-error prompting - More complex and long-running agents - Expansion from single-agent to multi-agent systems - Tool integrations such as MCP, whose definitions also consume context - Limited awareness of context optimization techniques ## Context Rot and Context Engineering - **Context rot** occurs when long-running agents accumulate conversation history, intermediate results, and irrelevant information. - As the context grows: - The context window becomes pressured. - Relevant information becomes harder to identify. - Noise overwhelms important signals, reducing accuracy. - Context engineering is the deliberate design and management of all information provided during inference, including: - **Static context:** System prompts and tool definitions - **Dynamic context:** User messages, conversation history, and retrieved external data - **Long-term context:** Persistent session state and accumulated information - The core principles are: - Treat tokens as a limited resource and retain the smallest set of high-signal information. - Provide neither too little information, which forces guesswork, nor too much, which wastes tokens and reduces clarity. ## Why Use ADK Google’s open-source Agent Development Kit (ADK) is presented as a practical platform for applying context engineering. - Agents can be designed and shared using team knowledge rather than relying on individual CLI expertise. - ADK includes UI, API-server, evaluation, and multi-agent capabilities. - Its multi-agent architecture naturally supports separating and controlling context. ## ADK Context-Engineering Components The workshop introduces nine key components, including: - **Structured input and output:** JSON or schema-based formats reduce unnecessary text and make agent processing more reliable. - **AgentTool:** Embeds one agent inside another as a tool. The calling agent receives only the final result, preventing internal tools and intermediate context from accumulating. - **MCP Toolset filtering:** The `tool_filter` parameter exposes only required MCP tools, reducing tool-definition tokens and improving model decisions. - The remaining components can be combined with these techniques to control context throughout an agent workflow. ## Jira Weekly Report Example The workshop builds `jira_weekly_report`, an agent that analyzes team Jira tickets and generates a weekly Markdown report. ### Version 1: Single Agent Without Context Engineering - A single agent retrieves the ticket list, fetches each ticket, analyzes it, and builds the report. - All Jira tools are exposed through one MCP toolset. - As the number of tickets increases, detailed ticket contents accumulate in the agent’s context. - This leads to context rot, higher token usage, and declining reliability. ### Version 2: Context-Aware Multi-Agent Design - The workflow is split into: - A root agent that searches Jira tickets and aggregates the final report. - A sub-agent dedicated to analyzing one ticket at a time. - `input_schema` requires a structured `issue_key`. - `output_schema` requires a structured report containing ticket content and progress, including comments. - The sub-agent receives only the `jira_get_issue` MCP tool. - The root agent receives only the `jira_search` tool. - `AgentTool` hides the sub-agent’s internal context and returns only its final report. - The sub-agent is instructed to include facts only and avoid speculation. This design limits each agent’s responsibilities, removes unnecessary tool definitions, and prevents individual ticket details from polluting the root agent’s context. ## Practical Recommendation For production AI agents, treat context as a constrained resource. Use structured schemas, narrowly filtered tools, and specialized sub-agents to pass only the information needed for each step.

Read original(opens in new tab)

Large Language ModelsAI AgentsKubernetesModel Context Protocol+3

toss·May 22, 2026·4 min readCurated summary

Tips for Growing the Skills to Solve Cross-Functional Technical Problems

As organizations grow, their hardest technical problems increasingly arise between teams rather than within them. These cross-functional, cross-domain problems cannot be solved through more meetings, status updates, or risk tracking alone; they require redefining the problem, structuring it, and creating an execution model that moves people to action. The post presents Toss’s Technical Program Manager (TPM) role as an example of this approach. ## Why Cross-Functional Problems Persist - Individual teams may perform well while the organization still fails to optimize as a whole. - Technical issues often span product, infrastructure, data, security, operations, strategy, and organizational design. - Common symptoms include: - Unclear ownership - Missing decision-makers - Conflicting priorities - Dependencies across multiple teams - Important “gray areas” with no formal owner - As organizations mature, these boundary problems become more common because team responsibilities become clearer while cross-team gaps remain. ## The Core Principle: Redefine the Problem - Cross-functional technical problems are not solved by increasing management activity. - More frequent meetings, status reports, risk registers, and stakeholder alignment may be useful but often address symptoms. - The real bottleneck may be: - An absent decision structure - Ambiguous ownership - Conflicting priorities - A system that does not connect individual team efforts - Effective problem-solving starts by identifying the underlying issue rather than merely describing delays or communication problems. ## Capabilities Required to Solve These Problems ### Reframing the Problem - Identify why schedules slip or decisions stall. - Determine which responsibilities or decisions are missing. - Find the structural conditions that repeatedly create the same gap. - Without accurate problem definition, organizations continue managing symptoms. ### Turning Ambiguity into Structure - Make decisions, options, responsibilities, dependencies, and sequencing explicit. - Break complex issues into manageable units. - Replace vague discussion with concrete decision points and ownership. ### Exercising Strategic Judgment - Distinguish temporary incidents from recurring structural problems. - Decide whether the issue can be solved within one team or requires broader intervention. - Assess whether immediate action is necessary. - Prioritize problems that improve the organization’s overall execution capability. ### Converting Plans into Execution - Identify who must act and which decisions must happen first. - Remove blockers and turn unclear discussions into explicit decisions. - Secure agreement on action plans and ensure those actions actually occur. - The goal is not merely to monitor execution, but to make execution possible. ### Influencing Without Formal Authority - Cross-functional work rarely succeeds through hierarchy alone. - TPMs need trust, sound judgment, and the ability to translate between teams with different goals and constraints. - Their influence should come from credibility and problem-solving results rather than title. ### Seeing People and Structure Together - Many technical problems are also caused by unclear roles, unsuitable team structures, or outdated operating mechanisms. - Effective intervention may require changing processes, redistributing responsibilities, or involving leadership—not just modifying technology. ## A Practical Starting Point for Less Autonomous Organizations - **Solve a small, concrete bottleneck first:** Demonstrate that involvement makes work clearer and faster. - **Add structure within existing coordination duties:** Use meetings and schedule management to expose decisions, dependencies, and blockers. - **Clarify ownership in a limited scope:** Define the real owner, decision rights, and completion criteria for a small initiative. - **Build evidence through successful cases:** Organizations often recognize new roles through demonstrated results rather than role descriptions. ## Important Cautions - Coordination remains valuable, but it should serve problem-solving rather than become the goal. - Lack of formal authority does not mean lack of influence; trust, structure, and results can be more powerful. - Introducing an idealized role too quickly may trigger resistance. It is better to make the approach work within the organization’s current environment and expand from proven examples. The central recommendation is to stop treating cross-functional technical problems as coordination exercises. First ask what the real bottleneck is, who is missing, and what execution structure would enable progress; then use that understanding to drive concrete organizational change.

Read original(opens in new tab)

Cross Functional CollaborationProblem SolvingOrganizational DesignTechnical Program Management+2

figma·May 22, 2026·2 min readCurated summary

7 Tips for Using Figma Make Credits More Efficiently | Figma Blog

Figma argues that efficient AI prototyping is less about writing longer prompts and more about setting up projects carefully, limiting changes, and knowing when to edit manually. The first prompt should establish a strong foundation, while follow-ups should describe precise deltas. For minor visual or code changes, direct editing is often faster and cheaper than another AI request. ## Build a Strong First Prompt - Treat the initial prompt as a complete project brief. - Include: - The project goal and context - Key elements and behaviors - Constraints and exclusions - A clear definition of what “done” means - Use follow-up prompts as deltas that explain: - What should change - How it should change - What should remain unchanged - For larger projects, work in stages: - Establish the structure first - Add logic and behaviors - Refine content and visual polish afterward - Keep follow-ups tightly scoped. Combine requests only when they affect the same component or logic. - Specific instructions such as “Update the calendar component” or “Edit `tokens.ts`” are more efficient than vague requests like “Redo it.” ## Prefer Manual Edits for Small Changes - Use Figma Make’s **Edit tool** for minor adjustments such as: - Changing spacing - Removing an element - Adjusting text - Direct edits avoid spending credits on changes that do not require a new design solution. - Use **Go to source** when the relevant value is dynamic or unavailable in the preview. - Press **⌘F** to search the code for a specific tag or data source. - Start with `App.tsx`, then inspect other `.tsx` files in the component folder if necessary. - Direct source editing is particularly useful for repeated components or content populated from lists.

Read original(opens in new tab)

User ExperienceReactTypeScriptFigma Make+3

figma·May 22, 2026·2 min readCurated summary

What Matters When Anyone Can Build | Figma Blog

AI has made building products faster and more accessible, but speed alone no longer creates an advantage. When anyone can ship, the differentiators become choosing the right direction and shaping the result with care. Figma’s Yuhki Yamashita argues that strong teams combine rapid exploration, deliberate decision-making, and relentless craft. ## Choosing What’s Worth Building - The abundance of possible ideas makes it easy to commit prematurely to the first promising concept. - Iterating deeply on one idea can become “local hill-climbing,” refining a path without questioning whether it is the right one. - AI tools can worsen tunnel vision by accelerating a chosen direction without challenging its assumptions. - Traditional strategic methods, such as MECE option mapping, encourage breadth but can remain too abstract to create conviction. - A stronger approach combines breadth and depth: - Explore several distinct directions in parallel. - Turn each direction into a realistic, end-to-end interactive prototype. - Compare actual user experiences rather than abstract diagrams or wireframes. - Invite teammates and AI agents to react and build on ideas collectively. - This creates a more collaborative, parallel way of working instead of a siloed, sequential process. ## Making the Product Yours - AI-generated products tend to converge on familiar patterns and statistically likely solutions. - “Good enough” becomes easy to produce and easy to accept, creating interchangeable products. - The main danger is passivity: accepting the first convincing result because it looks polished. - Craft requires active judgment: - Question every decision. - Revisit and refine multiple times. - Remove unnecessary elements. - Push beyond the first few acceptable versions. - Develop a distinct point of view. - As AI raises the baseline quality of products, differentiation will come less from tools or execution speed and more from the care and intention behind the final result. ## What Matters Now - The essential capabilities are **speed, direction, and craft**. - The best teams do not treat these as competing priorities: - They move quickly. - They choose deliberately. - They refine relentlessly. - In a world where nearly anything can be built, the lasting advantage lies in deciding what deserves to exist and shaping it into something distinctive.

Read original(opens in new tab)

AIUser ExperienceProduct DesignProduct Development+2