Techlist.io - Korean Tech Blog Curator

githubJul 27, 20262 min readCurated summary

GitHub Copilot app for Beginners: Getting started

The GitHub Copilot app is designed as a development workspace rather than a single AI chat window. It connects agent sessions to projects, supports parallel tasks, provides an interactive browser canvas for UI work, and helps manage pull requests through Agent Merge. Together, these features aim to support the full workflow from exploration to shipping. ## Project-Based Agent Sessions - Each session is connected to a specific project and its repository context. - Projects can be selected from GitHub or added from a local machine. - Copilot can inspect the codebase, identify relevant files, implement changes, and run tests. - This reduces the setup required before beginning a development task. ## Managing Multiple Work Threads - Users can create separate sessions for different tasks without interrupting ongoing work. - **Quick Chat** provides a lightweight way to: - Ask questions about Copilot or the codebase - Explore implementation options - Investigate unfamiliar parts of an application - Gather context before making changes - Returning to an existing session preserves its history and allows work to continue from where it stopped. ## Interactive UI Work with Canvas - The app includes a browser canvas for previewing applications alongside the AI conversation. - Canvas can be created with the `/create-canvas` slash command. - **Enable Canvas Dev Mode** and **Pick & Polish** allow users to select page elements directly and use them as context for refinement requests. - This supports an iterative workflow in which developers can inspect the visual result, identify problems, and ask Copilot to adjust specific UI elements. ## Pull Request Assistance with Agent Merge - **Agent Merge** extends Copilot’s role beyond implementation into code review and delivery. - It can be enabled from a pull request’s options in the Copilot app. - Developers choose which actions it may perform, including: - Addressing review feedback - Helping resolve CI failures - Handling merge conflicts - Agent Merge monitors the pull request while checks and reviews are in progress, preparing it for merge once requirements are satisfied. The Copilot app is intended to centralize development activities in one workspace: start with a project, separate work into focused sessions, visually refine applications through canvas, and use Agent Merge to help complete the pull request process. Developers can learn the workflow by applying it to an existing backlog task.

AI Agents CI/CD Github Github Copilot+3

kakaoJul 27, 20264 min readCurated summary

Smaller and More Powerful Kanana SLM Development

Kanana-2 is Kakao’s second Small Language Model series, designed to deliver strong performance under the memory and compute constraints of on-device environments. It includes 3B, 1.3B, and 0.9B models, using improved pre-training, distillation, pruning, tokenizer efficiency, and Sliding Window Attention. Kakao reports that the resulting models outperform earlier Kanana models and compare favorably with similarly sized open-source models. ## Motivation and Model Lineup - On-device services require models that are small and fast because smartphones have limited memory and compute. - Kakao uses its own SLMs in the “Kanana in KakaoTalk” service. - The Kanana-2 series consists of: - Kanana-2-3B - Kanana-2-1.3B - Kanana-2-0.9B - Base and Instruct versions of the 3B and 1.3B models are being released. - The development builds on techniques from Kanana-2-30B-A3B and earlier Kanana Nano models. ## Efficiency Improvements - **Kanana-2 Tokenizer** - Improves Korean tokenization efficiency by more than 30% compared with the previous tokenizer. - Reduces the number of tokens required for Korean text, improving processing efficiency. - **Sliding Window Attention** - Reduces KV cache size during inference. - Improves memory efficiency and helps reduce decoding bottlenecks on devices. ## 3B Pre-Training ### TPU-Based Training from Scratch - Kanana-2-3B-Base was initially trained from scratch on a TPU v5e cluster. - Kakao used a MaxText-based internal training framework. - The team developed infrastructure allowing training to transition between TPU and GPU clusters: - Pre-training was completed on TPU. - Distillation was subsequently performed on GPUs using Megatron-LM. - Pre-training used two stages: - Stage 1: 7.5 trillion tokens - Stage 2: 2 trillion tokens - The Muon optimizer was used throughout pre-training. ### Learning-Rate Scaling - Directly searching learning rates at multi-trillion-token scale would be too expensive. - Kakao instead tested learning-rate candidates using a 100-billion-token proxy dataset while preserving the Stage 1 data distribution. - The selected learning rate was scaled to the full 7.5-trillion-token training run using the Token Horizon scaling rule: `LR_target ≈ LR_proxy × (D_target / D_proxy)^−β` - The experiments used: - `D_proxy = 100B` - `D_target = 7.5T` - `β = 0.32` - This approach enabled stable hyperparameter selection with a smaller exploration budget. ## Teacher-Based Distillation - The Kanana-2-30B-A3B-Instruct-2601 model was used as the teacher. - Kakao compared Base, Instruct, and Thinking versions of the teacher model. - The Instruct teacher consistently produced the strongest student-model performance. - The result supports recent findings that post-trained teachers can be especially effective for transferring mathematical and coding capabilities. ## Long-Context Training - The model’s context length was expanded from 4K to 32K using YaRN. - Additional mid-training data was introduced during the learning-rate decay phase. - The resulting Kanana-2-3B-Base reportedly surpassed earlier Kanana 3B models across Korean and English knowledge, mathematics, and coding. - It also exceeded many similarly sized open-source SOTA base models. ## Building the 1.3B and 0.9B Models - Kanana-2-1.3B-Base and Kanana-2-0.9B-Base were progressively derived from Kanana-2-3B-Base. - The process extended the Minitron-based structured pruning and knowledge-distillation approach used for Kanana Nano. - The smaller models were trained with SWA-aware long-context procedures to preserve efficiency in on-device decoding. ### Improved Hidden-Dimension Pruning - Traditional hidden-dimension pruning scores each dimension independently using activation statistics from calibration data. - This is efficient but may overlook information represented jointly across multiple dimensions. - Kanana-2 applies PCA-based pruning inspired by Ministral 3: - Collect activation statistics from Attention RMSNorm, MLP RMSNorm, and Final RMSNorm inputs. - Compute a global rotation matrix with PCA. - Apply the rotation consistently to token embeddings and attention/MLP projection weights. - Reduce hidden dimensions after rotation, aiming to preserve more meaningful shared representations. Kakao’s approach combines large-scale pre-training, teacher distillation, structured compression, better Korean tokenization, and attention-level inference optimization. For practical on-device deployment, the smaller Kanana-2 models are intended to offer a better balance of speed, memory usage, and capability than simply deploying a larger general-purpose LLM.

Knowledge Distillation Kanana Tpu Small Language Model+4

awsJul 27, 20263 min readCurated summary

AWS Weekly Roundup: Local Zone in Athens, Claude Opus 5 on AWS, Lambda durable execution for .NET, and more (July 27, 2026) | Amazon Web Services

The week’s AWS updates focus on bringing infrastructure closer to users, expanding AI capabilities, and improving reliability and observability. Highlights include a new Athens Local Zone, Claude Opus 5 availability, durable Lambda workflows for .NET, and unified Amazon Bedrock AgentCore telemetry. The post also points to new data, contact-center, developer-productivity, and community resources. ## AWS Local Zone in Athens - AWS launched its second EMEA Local Zone in Athens, Greece. - It supports: - Amazon EC2 C7i, M7i, and R7i instances - Amazon S3 One Zone-Infrequent Access - Amazon EBS and EBS Local Snapshots - Amazon ECS - Greek organizations can process and store data locally to help satisfy data-residency requirements. - The zone enables single-digit-millisecond latency for workloads such as gaming, media production, and financial services while still connecting to the nearest AWS Region. ## New AI and Serverless Capabilities - **Claude Opus 5 on AWS** is available through Amazon Bedrock and Claude Platform on AWS. - It provides top-tier Opus-level intelligence. - Bedrock enables zero data retention by default, supporting stricter governance requirements. - **Lambda durable execution for .NET** is now generally available. - C# developers can create long-running, multi-step workflows without custom checkpointing or external orchestration. - Workflows can pause for up to one year. - Use cases include payment pipelines, AI agents, and human approvals. ## Improved Agent Observability - Amazon Bedrock AgentCore now stores traces, prompts, inputs, outputs, and application logs in a single CloudWatch log group. - Engineers can investigate individual agent invocations without searching multiple destinations. - Agent-level access controls and customer-managed key encryption are also supported. ## Contact Center, Data, and Developer Updates - Amazon Connect added more natural agentic voice experiences across more than 50 languages. - The service now includes over 100 new voice options and improved handling of tone and sentiment. - SageMaker Unified Studio can query Amazon OpenSearch data alongside Redshift, S3, and relational database assets. - CloudWatch coding agent insights measures the organizational impact of tools such as Claude Code, Codex, and GitHub Copilot using OpenTelemetry telemetry without custom instrumentation. ## Additional Resources and Events - AWS published guidance for evaluating AI agents with Strands Agents and Bedrock AgentCore. - A new guide covers multi-region resiliency for CloudFormation custom resources. - Amazon SES introduced pricing plans intended to make large-scale email costs more predictable. - Upcoming opportunities include AWS Summits and AWS Community Day Belo Horizonte on August 22. Together, these releases suggest AWS is prioritizing lower-latency regional infrastructure, production-ready AI workflows, and better operational visibility. Builders should assess the Athens Local Zone for residency-sensitive workloads, consider durable Lambda execution for complex .NET processes, and adopt the new observability tools as agent deployments grow.

AWS Amazon Bedrock Aws Lambda Amazon Sagemaker+4

cloudflareJul 27, 20263 min readCurated summary

We’re open sourcing our privacy proxy CLI

Oblivious HTTP (OHTTP) is difficult to debug because requests pass through multiple parties, use binary HTTP encoding, and depend on several RFC-defined cryptographic steps. Cloudflare created and open-sourced `pvcli`, a CLI that simplifies testing and troubleshooting privacy protocols by exposing each stage of the process. Released under Apache-2.0, the tool is designed for production-scale debugging and community contributions. ## Why OHTTP Debugging Is Complex - OHTTP ensures that no single party can know both the client’s identity and the requested content. - It relies on two non-colluding servers: - A **relay** that sees the client but not the request contents. - A **gateway** that decrypts the request but does not see the client’s identity. - A typical request proceeds through several stages: - The client retrieves the gateway’s public key. - The client encrypts the request and sends it to the relay. - The relay forwards the anonymized request to the gateway. - The gateway decrypts it and contacts the target. - The response travels back through the gateway and relay before being decrypted by the client. - Every stage can introduce failures, making it difficult to identify whether the problem lies with the client, relay, gateway, or target. ## Why Cloudflare Built `pvcli` - Privacy products such as Privacy Proxy and Privacy Gateway introduced increasing operational complexity and customer-specific requirements. - Engineers frequently had to create one-off clients to test customer deployments. - Diagnosing failures required determining which protocol step had failed and which party was responsible. - OHTTP’s binary formats made manual inspection especially error-prone. - `pvcli` consolidates privacy-protocol functionality into one familiar CLI with support for different protocols and architectures. ## Debugging OHTTP Manually - Engineers first fetch the gateway’s public key, receiving a long hexadecimal binary payload. - They must manually parse fields according to RFC 9458, including: - The key entry length. - The public key identifier. - The asymmetric encryption method, such as DHKEM with X25519 and HKDF-SHA256. - The gateway’s public key. - Supported symmetric encryption algorithms, such as HKDF-SHA256 and AES-128-GCM. - The original HTTP request must then be converted into binary HTTP according to RFC 9292. - Engineers manually verify encoded fields such as: - The request method (`POST`). - The HTTPS scheme. - The target hostname. - The request path and headers. - The JSON body. - Finally, they need custom scripts to encrypt the binary request and construct the OHTTP wrapper request. ## Using `pvcli` - A complete OHTTP request can be issued with a single command: ```bash pvcli --ohttp \ --first-hop https://relay-cloudflare.ohttp.info \ --proxy https://gateway.ohttp.info \ -X POST \ --header "content-type: application/json" \ --data '{"test":1}' \ https://target.ohttp.info/anything ``` - The tool handles the relay, gateway, encryption, binary HTTP encoding, and target request flow. - It provides a clearer view of each protocol step, replacing manual hexadecimal parsing and bespoke scripts with a repeatable debugging workflow. `pvcli` is a practical way to test live OHTTP deployments, isolate failures across the relay and gateway chain, and reduce the risk of mistakes when inspecting binary protocol data.

Cryptography Cli Oblivious Http Binary Http+3

figmaJul 27, 20262 min readCurated summary

Digital Tools, Human Expression: The Visual Identity Behind Config 2026 | Figma Blog

Config 2026’s visual identity used digital tools and AI to express human creativity rather than replace it. Figma’s Brand Studio built a system around evolution, fluidity, and harmony, combining expressive glyphs, imperfect textures, and structured compositions. The result connected AI-assisted making with craft, experimentation, and distinctly human irregularity across digital and physical conference spaces. ## A Visual System for Human–Machine Collaboration - The identity reflected three aspects of modern design: - **Evolution:** remixing and reinventing ideas into something new. - **Fluidity:** moving between design and code while starting from different points. - **Harmony:** using generative tools while maintaining human judgment. - The system combined: - Sketchy, generative, and crisp glyphs. - AI-prompted textures. - Structured, dynamic compositions. - The contrast between “wonky” results and programmatic digital processes represented how ideas can morph and multiply. - Particle glyphs suggested ideas spawning and generating, while clean rectangles represented more resolved concepts. - Glyphs were translated into 14-foot foam sculptures and installed around San Francisco’s Moscone Center. ## AI-Assisted Texture Generation - Figma’s Brand Studio created tools in Figma Make to codify three lo-fi visual effects: - Scribbly linework. - Blurred gradients. - Oval-shaped particles. - Images were processed through these tools to create compositions that felt surprising, hand-drawn, and imperfect. - A custom dithering tool applied a consistent pointillist treatment to hundreds of speaker portraits. - The textures balanced digital precision with human qualities such as irregularity, grain, and imperfection. - Animated versions of the textures appeared at the conference’s block party and on keynote screens. ## Designing Static and Motion Assets Together - The team developed motion and still graphics in parallel rather than treating animation as a final production step. - Motion influenced visual design, while design informed motion decisions. - Bringing glyphs to life helped the team discover new directions for the identity. - This iterative process reinforced Config’s theme of ideas evolving through experimentation and collaboration. Figma’s approach demonstrates how AI can support a strong visual identity when it is guided by human taste and craft. The practical lesson is to use generative tools to create possibilities, while preserving controlled imperfections and human judgment in the final system.

Figma AI Figma Make Motion Design+2

gitlabJul 27, 20263 min readCurated summary

Claude Opus 5 on GitLab: Reasoning built for the hard tasks

Claude Opus 5 is now available through GitLab Duo Agent Platform for complex, high-stakes engineering tasks. GitLab reports a 93.3% benchmark resolution rate, significantly above Opus 4.8’s 73.0%, while maintaining comparable or better speed. The model is intended for difficult debugging, large refactors, coordinated multi-agent work, and code reviews where correctness matters more than minimizing initial cost. ## Reliable Reasoning for Complex Work - Opus 5 is designed to maintain consistent reasoning across long-running tasks and multiple steps. - It aims to reduce partial patches, failed runs, diagnostic work, and repeated prompting. - In GitLab’s internal evaluation: - Opus 5 completed 100% of the tasks it attempted. - Its verified resolution rate was 93.3%, compared with 73.0% for Opus 4.8. - In one five-file SSO authentication task, Opus 5 implemented the feature, added exported types and configuration fields, committed the changes, and opened a merge request. - The model is also presented as effective for code review, identifying genuine bugs while producing relatively few false positives. ## Coordinating Multiple Agents - Opus 5 can support workflows where several agents work in parallel. - Subagent coordination helps prevent agents from interfering with one another’s changes. - Writer-verifier patterns allow one agent to check another’s output before it is accepted. - GitLab Credits usage caps can limit spending when running multiple parallel agents. ## Speed Alongside Depth - On GitLab’s most difficult benchmark tasks, Opus 5 was faster at the 95th percentile: - 768 seconds for Opus 5 versus 784.98 seconds for Opus 4.8. - 768 seconds versus 982.57 seconds for Sonnet 4.6. - GitLab argues that this combination of speed and reliability produces more predictable completion times for long tasks. ## Choosing the Appropriate Model - Sonnet-class models remain suited to routine development because they are fast, affordable, and dependable. - Opus 5 is recommended for: - Difficult debugging - Large refactors - Complex multi-file features - Decisions where rework would be costly - Model selection is configurable within GitLab, while all models use the same context management, policy controls, and audit trail. ## Availability - Claude Opus 5 is available on GitLab Duo Agent Platform and uses GitLab Credits. - New users can start with a free trial. - GitLab Premium and Ultimate subscribers can enable Duo Agent Platform and use included credits. Opus 5 is best viewed as a specialized model for high-complexity work rather than a universal replacement for faster Sonnet-class models. Teams should match the model to task difficulty and use spending limits when scaling autonomous, parallel-agent workflows.

AI Agents Code Review Refactoring Gitlab Duo Agent Platform+4

cloudflareJul 24, 20264 min readCurated summary

BGP ORIGIN attribute manipulation and its impact on the Internet

BGP’s ORIGIN attribute is intended to describe how a route entered the protocol and should remain unchanged after being set by the originating AS. However, the investigation found that roughly 70% of observed paths had an ORIGIN value different from the original, often because transit providers manipulate it to influence route selection and attract traffic. This widespread practice turns a supposedly stable routing signal into a tool in a revenue-driven competition between networks. ## What the BGP ORIGIN Attribute Means - ORIGIN describes how a route was injected into BGP, rather than identifying the originating Autonomous System. - It has three values: - **IGP (0):** The route originated within the AS. - **EGP (1):** A historical value associated with the obsolete Exterior Gateway Protocol. - **INCOMPLETE (2):** The route was learned through an unknown or external mechanism. - Across routes visible through RIPE RIS and RouteViews: - 89.8% used IGP. - 3.5% used EGP. - 6.7% used INCOMPLETE. - When Local Preference and AS_PATH length are equal, BGP prefers the lower ORIGIN value, making IGP preferable to EGP and INCOMPLETE. - RFC 4271 states that ORIGIN is generated by the originating speaker and **should not be changed** by other speakers. ## How Providers Use ORIGIN Manipulation - A transit provider can rewrite a route’s ORIGIN to IGP, making its path more attractive during BGP route selection. - In the example: - AS64501 announces a route with ORIGIN INCOMPLETE. - AS64502 and AS64503 propagate the route to AS64504. - AS64503 changes the ORIGIN to IGP. - Because both paths have equal AS_PATH lengths, AS64504 selects the path through AS64503. - This manipulation redirects traffic—and potentially transit revenue—toward the provider that altered the attribute. - Some operators also rewrite routes to EGP or INCOMPLETE to make them less preferred than customer routes. - The practice has been discussed at RIPE and LACNIC meetings and has contributed to proposals recommending that ORIGIN be deprecated. ## Measuring ORIGIN Rewriting - The researchers announced: - Three IPv4 prefixes. - Three IPv6 prefixes. - Each prefix used a different ORIGIN value: IGP, EGP, or INCOMPLETE. - Announcements were made from multiple peering locations using BGP Anycast. - After propagation, the prefixes were withdrawn to trigger BGP path hunting, exposing additional routes. - Researchers analyzed: - MRT UPDATE messages from RIPE RIS and RouteViews. - Local BMP data from their border routers. - BGPKIT tools for parsing the data. - UPDATE messages were chosen over routing-table snapshots because they reveal more paths during both announcements and withdrawals. ## Visibility Challenges - Public collectors cannot observe every AS involved in a route’s propagation. - The growth of hyperscalers, CDNs, and direct local peering has flattened the traditional transit hierarchy. - As a result, many paths bypass publicly visible transit networks. - Conclusions about which AS changed an attribute therefore carry some uncertainty, especially beyond directly observed peers. ## Direct-Peer Findings - The first analysis examined two-AS paths such as `ASX AS13335`, where ASX was a direct peer of the researchers. - Because the researchers controlled the original ORIGIN value, any different value observed from a direct peer indicated that peer had rewritten it. - Among 352 IPv4 direct peers: - Three ASes consistently changed routes to EGP. - Four changed routes to INCOMPLETE, potentially attempting to deprioritize them. - One contacted operator confirmed that it rewrote peer- and provider-learned routes to EGP so customer routes would be preferred. - Several ASes advertised both the original ORIGIN and IGP for non-IGP prefixes, likely because they received the routes at multiple locations and altered the value to steer traffic through preferred sites. - Combining these behaviors, the researchers found that nearly 10% of direct peers were rewriting ORIGIN, while the broader experiment detected changes on approximately 70% of observed paths. Network operators should treat ORIGIN rewriting as a significant deviation from BGP’s intended behavior, since it can alter routing decisions, distort traffic engineering, and create commercial incentives for further manipulation.

Bgp Ipv6 Autonomous Systems Ipv4+4

naverJul 24, 20261 min readCurated summary

[AI Hackathon Recap] What the Winning Team Didn’t Leave to AI

The content is a minimal NAVER D2 landing page rather than a substantive technical blog post. It provides navigation links to D2 News, About D2, NAVER Developers, DEVIEW, OpenSource, and D2 STARTUP FACTORY, along with a “Hello world” message and a copyright notice. ### Site Navigation - D2 News - About D2 - NAVER Developers - DEVIEW - OpenSource - D2 STARTUP FACTORY ### Footer - Copyright © NAVER Corp. All Rights Reserved. No technical topic, argument, or detailed content is provided.

Open Source Software Development Developer Community

cloudflareJul 23, 20263 min readCurated summary

Introducing Cache Response Rules

Cache Response Rules let Cloudflare modify an origin response after it arrives but before it is stored in cache. They address response-header problems—such as accidental `Set-Cookie`, restrictive `Cache-Control`, or problematic validators—that can unnecessarily reduce cacheability. This provides an origin-independent fix while preserving the distinction between request-time and response-time caching decisions. ## When Caching Decisions Are Made - CDN caches aim to serve content from the edge and contact the origin only on misses. - Origin response headers determine: - Whether content can be cached - How long it remains fresh - When it should be revalidated - Whether it should be cached at all - Common problems include: - `Set-Cookie` on static assets such as `/static/app.js`, making them uncacheable - `Cache-Control: no-cache` on content that is safe to cache at the CDN - Browser-oriented cache directives that are unsuitable for Cloudflare - Overly aggressive `ETag` values causing repeated revalidation - These issues often require coordination between separate origin and CDN teams, delaying simple fixes. ## Cache Response Rules - Run after the origin responds but before Cloudflare writes the response to cache. - Can: - Rewrite `Cache-Control` directives - Strip `Set-Cookie`, `ETag`, and `Last-Modified` - Manage cache tags for purging - Apply entirely within Cloudflare, without requiring origin code changes. - They solve problems that request-time rules cannot, because response headers are unavailable until after the origin request completes. ## The Missing Piece in Cloudflare’s Cache Controls - Earlier caching behavior was largely handled through Page Rules, which combined caching with unrelated features. - Cloudflare later introduced more focused controls, including: - Cache Rules - CDN-Cache-Control - Custom cache keys - Other cache-specific settings - Most existing controls operate during the request phase. - Before contacting the origin, Cloudflare can evaluate only request information such as the URL, headers, file extension, geography, and device type. - Previously, response-header problems required: - Changing the origin - Deploying a Worker to re-fetch and rewrite responses - Accepting a lower cache hit ratio ## Two Phases, Two Questions - **Cache Rules** run before the origin request and determine: - Whether the response is eligible for caching - What cache key identifies the object - How it should be cached, including TTL and stale-serving behavior - **Cache Response Rules** run after the origin response and determine whether caching behavior should be adjusted: - Remove headers that make content ineligible - Change origin cache directives - Set cache tags - When the two rule types conflict, the Cache Response Rule takes precedence. - Response rules cannot change the cache key, since that must already be established during the request phase. - They can make an otherwise eligible response non-cacheable with `no-store`, or make content eligible by removing `Set-Cookie`, but they cannot recover the latency of a request that was already excluded from caching at request time. Cache Response Rules complement rather than replace Cache Rules. Use request-phase rules for cache eligibility, keys, and general caching behavior; use response-phase rules to correct origin headers before they damage cacheability.

Cloudflare Caching Cdn Cache Response Rules+2

githubJul 23, 20261 min readCurated summary

The case for a cooldown: Why Dependabot now waits before issuing version updates

Carlin is a GitHub Product Manager focused on GitHub Advanced Security and Dependabot. Her experience in software engineering and data science supports a data-driven approach to product management. ### Professional Background - Works on GitHub Advanced Security. - Focuses specifically on Dependabot. - Brings experience in software engineering and data science. ### Personal Interests - Lives in Washington with her partner and dog, Cookie. - Enjoys cycling and competitive board games. No technical blog post content was provided beyond this author biography.

Product Management Data Science Software Engineering Dependabot+1

figmaJul 23, 20263 min readCurated summary

How Figma Stays Ahead of Vulnerabilities With Agents | Figma Blog

Figma uses AI agents to prevent, detect, and fix vulnerabilities during code generation, pull-request review, and historical code audits. Its central strategy is a shared security policy combined with continuous measurement of precision and recall. The company began with PR review because developer feedback and replaying known bugs created the fastest improvement loop. ## A Shared Policy Across the Development Lifecycle - The same policy guides agents during: - Code generation - Pull-request review - Full-repository auditing - The policy records: - Trust boundaries - Accepted risks - Security precedents - Improving PR review first helped Figma refine the policy before applying it to other stages. ## Measuring Precision and Recall - **Precision** measures how many reported findings are genuine vulnerabilities; low precision creates false positives. - **Recall** measures how many real vulnerabilities the system detects; low recall creates false negatives. - Figma measures: - Precision through author thumbs-up or thumbs-down feedback on findings. - Recall by replaying the reviewer against commits containing known bugs. - These separate signals allow the team to improve both dimensions rather than optimizing for only one. ## AI-Assisted Pull-Request Review - Every pull request receives an automated review. - Findings are posted directly to the PR, allowing developers to respond and fix issues in context. - Figma currently runs: - Claude Code with Opus 4.8 at extra-high effort - Codex with GPT-5.6 Sol at high effort - The models identify different classes of bugs, so Figma reports a finding if either model detects one. - Reviews cost approximately $0.50 per pull request at the median. The agents have identified both sophisticated and conventional vulnerabilities, including: - A multi-step desktop-client exploit in which an injected sandbox object exposed the host realm’s `Function` constructor and enabled possible code execution. - An insecure direct object reference where an authenticated user could retrieve another organization’s invoice by supplying its ID. ## Building Trust Before Exposing Findings - Figma launched Anthropic’s Claude Code Security Reviewer in August 2025 in shadow mode. - Initial results were strong at reproducing known vulnerability root causes, but only 4 of 27 findings—about 15%—were valid. - The team prioritized precision first because developers quickly lose trust in tools that generate excessive false positives. - Figma set a practical target of at least 70% precision. - Developer-facing comments were withheld until precision exceeded that level over a two-week period without severe false positives. - Security engineers replayed the reviewer across eight weeks of historical pull requests and manually labeled incorrect findings. - Those examples were used to create and refine the shared security policy. ## Continuous Improvement Through Precedents - A **precedent** documents why a finding is valid or invalid in a particular context. - Human feedback and historical vulnerability replays feed back into the policy. - This process lets Figma improve the agent automatically rather than relying only on model changes or one-time prompt tuning. Figma’s approach treats agentic security as an engineering and measurement problem, not simply a matter of asking an AI to scan code. Organizations adopting similar systems should establish feedback loops, measure precision and recall independently, and build developer trust before making automated findings part of everyday development.

AI Agents Code Review Claude Code Monorepo+3

githubJul 22, 20263 min readCurated summary

Copilot vs. raw API access: What are you actually paying for?

GitHub Copilot and direct model APIs serve different purposes rather than competing at the same layer. Copilot bundles model access with development workflows—repositories, editors, terminals, issues, pull requests, and organizational controls—while APIs give teams the primitives to build their own systems. The best choice depends on whether you want to own the surrounding infrastructure or use GitHub’s integrated tooling. ## Copilot as Development Tooling - Copilot supports workflows from GitHub Issues through code changes, testing, pull requests, and review. - Its value includes integration with: - Editors and repositories - Terminals and permitted commands - Repository instructions - Pull requests and organizational policies - Paid plans include code completions and Next Edit Suggestions, while more intensive chat and agentic tasks consume AI Credits. - Actual cost depends on context selection, input/output/cached tokens, tool calls, retries, and task complexity. - Organization plans pool credits and provide budgets and usage tracking through the billing dashboard. ## Raw APIs for Systems You Control - Direct API access is suited to product features, internal agent platforms, evaluation systems, and automation pipelines. - Teams control prompts, retrieval, model routing, retries, logging, security, credentials, and billing. - Production agents still require substantial engineering, including: - Selecting relevant repository or document context - Preserving instructions - Handling failed tool calls - Storing traces and audit records - Defining data boundaries and approval points - Agent SDKs can provide orchestration, tools, sessions, and streaming. GitHub’s Copilot SDK exposes the runtime used by Copilot CLI and can run with either a Copilot subscription or a provider key. ## BYOK: Keeping Copilot’s Workflow - Copilot’s public-preview Bring Your Own Key feature lets teams use supported external models in Copilot Chat, CLI, and VS Code. - Supported providers include Anthropic, AWS Bedrock, Google AI Studio, Microsoft Foundry, OpenAI, OpenAI-compatible services, and xAI. - GitHub continues to provide the Copilot harness and integrations, while the customer pays the model provider directly. - BYOK can preserve existing cloud contracts or provider commitments while maintaining a familiar Copilot workflow. - Administrators can control which GitHub-hosted or BYOK models teams may use. - Because BYOK is still in public preview, teams should consult the current documentation before making purchasing or architecture decisions. ## Choosing the Right Layer - Choose raw API access when you need custom integrations, behavior, security controls, auditing, or billing. - Choose Copilot when developers primarily need to work faster within existing repositories, editors, terminals, issues, pull requests, reviews, and security processes. - BYOK is a middle option for teams that want GitHub’s development workflow but prefer to pay for models through an existing provider relationship. The practical decision is not simply about token price. It is about whether your team needs to build and operate the surrounding AI system or wants an integrated development workflow managed through Copilot.

Large Language Models Github Copilot API Agentic Workflows+4

githubJul 22, 20262 min readCurated summary

Next chapter: Restructuring GitHub’s bug bounty program

GitHub is restructuring its bug bounty program to prioritize high-quality, high-impact security research over report volume. The changes introduce a permanent VIP program with higher rewards and faster support, reduce and simplify public-program payouts, and add submission limits for researchers without an established track record. Reports submitted before July 27, 2026 will remain under the previous terms. ## Permanent VIP program for top researchers GitHub is creating a private, invite-only program for researchers who consistently produce valuable findings. - VIP researchers receive: - Higher payouts - Faster response times - Closer collaboration with GitHub’s security engineering team - VIP bounty payouts are: - Low: $1,000 - Medium: $7,500 - High: $20,000 - Critical: $30,000+ - Researchers can qualify by achieving at least one of the following: - One critical finding - Two high-severity findings - Four medium-severity findings - Seven low-severity findings - The program emphasizes quality and impact rather than the number of submissions. ## Restructured public bounty payouts GitHub is replacing variable payout ranges with fixed amounts to make rewards more predictable and reduce administrative overhead. - New public-program payouts: - Low: $250 - Medium: $2,000 - High: $5,000 - Critical: $10,000 - GitHub may still provide discretionary bonuses for exceptional work. - The public program will remain an entry point for new researchers and a pathway into the VIP program. ## Higher submission standards To address increasing report volume, including low-effort and AI-generated submissions, GitHub is adding a HackerOne signal requirement. - Researchers below the required signal threshold will have a limited number of submissions. - New researchers can make up to four initial submissions while establishing credibility. - The goal is to reduce noise without excluding legitimate newcomers. ## Existing commitments and transition period GitHub says it will continue paying quickly, communicating clearly, and treating researchers as security partners. - Reports submitted before the changes take effect will follow the old bounty structure. - Reports submitted on or after July 27, 2026 will use the new rules. - GitHub also plans to improve response times, severity explanations, and community engagement through conferences and outreach. The restructuring is designed to make GitHub’s bug bounty program more sustainable while directing greater rewards and attention toward researchers who deliver deep, thoughtful security work.

Vulnerability Management Application Security Bug Bounty Hackerone+2

datadogJul 22, 20263 min readCurated summary

Unbiased Java CPU profiling with JFR in JDK 25

Java Flight Recorder (JFR) provides low-overhead, production-safe diagnostics, but its `ExecutionSample` event can produce biased CPU profiles because it samples JVM-observed runnable threads rather than strictly measuring CPU time. For CPU-bound workloads—particularly reactive applications—this may obscure the real hotspots. Modern profilers therefore combine JFR with JVMTI, `SIGPROF`, `AsyncGetCallTrace`, and JVM-internal techniques, while the Java ecosystem works toward a supported CPU-sampling mechanism. ## How Sampling Profilers Work - Continuous profilers repeatedly capture stack traces and aggregate them to reveal recurring behavior. - CPU profilers commonly sample at fixed intervals, such as every 20 milliseconds. - **CPU-time sampling** highlights code actively consuming processor cycles. - **Wall-clock sampling** reveals latency sources, including I/O waits, lock contention, and blocked threads. - Other profilers trigger on events such as allocations, garbage collection, thread parking, or lock contention. - Regardless of the trigger, profilers capture a stack, associate it with an event, and aggregate the results. ## Limitations of JFR’s `ExecutionSample` - JFR is integrated into the JVM and designed for low-overhead, always-on production use. - Its `ExecutionSample` event captures stacks from a rotating subset of runnable threads. - CPU-heavy threads tend to appear more often, but samples are not strictly proportional to actual CPU consumption. - This can lead to incomplete or biased results on CPU-saturated systems. - Reactive applications are a notable example: their scheduling behavior can cause thread CPU usage and hotspots to be underrepresented. ## CPU Sampling with `AsyncGetCallTrace` - JVMTI agents can use operating-system signals such as `SIGPROF` to sample threads according to CPU time. - The signal handler invokes HotSpot’s `AsyncGetCallTrace` to walk Java stacks asynchronously. - This approach avoids safepoint bias and can capture stacks during arbitrary execution states. - Tools such as `async-profiler` use this technique to produce profiles that more closely match actual CPU usage. - The drawback is that `AsyncGetCallTrace` is an unsupported internal JVM API. - Under heavy load, it can occasionally fault, requiring profilers to add extensive safeguards. - Datadog also uses **vmstructs walking**, which reads internal JVM metadata to recover stack and runtime information unavailable through standard APIs. ## The Safety–Accuracy Tradeoff - JFR offers stability, structured runtime telemetry, and low overhead. - `AsyncGetCallTrace` and vmstructs walking offer more accurate CPU sampling. - Relying on JVM internals creates maintenance and reliability risks because those interfaces are not officially stable. - Consequently, modern profilers combine JFR with unsupported sampling mechanisms rather than choosing only one approach. ## Toward a Supported CPU Profiling Event - Datadog, SAP, Amazon, and OpenJDK contributors recognized that this limitation affected the broader profiling ecosystem. - JFR was already the natural foundation for safe, continuous profiling. - The missing capability was a first-class CPU sampling event that could provide accurate CPU-based results without depending on unsupported JVM internals. - Datadog participated in OpenJDK discussions to explain why existing sampling was insufficient and to help improve the platform’s profiling foundation. Ultimately, accurate production CPU profiling requires both JFR’s safety and CPU-time-based sampling. A supported JFR CPU profiling event would remove the ecosystem’s dependence on fragile JVM internals while preserving the low-overhead behavior needed for continuous use.

Java Jvm Cpu Profiling Java Flight Recorder+3

gitlabJul 22, 20263 min readCurated summary

Modernize Java with Cursor and GitLab

The post argues that modernizing Java 8 to Java 21 should be handled as a series of small, reviewable changes rather than one large AI-generated merge request. Cursor is effective for bounded coding tasks, while GitLab provides the planning, CI/CD, security, review, and lifecycle context needed to make those changes safe. The recommended approach is to begin with a focused test fix, establish quality gates, and then modernize one application boundary at a time. ## AI-Assisted Java Modernization - Java modernization affects the build, runtime, dependencies, APIs, concurrency, tests, containers, and production behavior. - A single broad prompt can produce an oversized merge request that is difficult to validate or review. - Cursor works best when given a focused issue, such as one failing test or one bounded implementation problem. - GitLab complements Cursor with: - Durable planning through epics and issue hierarchies - GitLab MCP context inside Cursor - CI/CD and security scanning - Code Review Flow and Developer Flow - Code-owner approvals and impact analysis - Cross-service testing and review evidence ## The Java HTTP Metrics Collector - The tutorial uses Tanuki IoT Platform’s Java HTTP metrics collector. - The collector: - Checks HTTP health and maintenance endpoints - Records response status and timing metrics - Sends readings to a Rust metrics-store backend through `POST /api/metrics` - This creates a realistic boundary for modernization because both the Java client and Rust backend contract must continue working. ## Project Setup and Guardrails - Required tools include Cursor, Java 8 and Java 21, Maven, Docker, Docker Compose, and GitLab MCP. - GitLab Duo Code Review Flow, Developer Flow, and an impact-analysis flow should be enabled for the project. - The repository includes `AGENTS.md`, which provides Cursor with project structure, instructions, and Maven test commands. - The workflow begins by importing the GitLab project, cloning it, and opening it in Cursor. ## Fixing the Failing End-to-End Test - The collector allows users to configure an expected HTTP status code. - The implementation incorrectly treats every 2xx response as successful and rejects configured responses such as `503`, even when they are expected. - An existing end-to-end test exposes the mismatch, but the CI job is initially allowed to fail, turning the failure into ignored background noise. - Cursor is prompted to: - Analyze the problem first - Trace the configuration through `HttpCollector` - Fix the implementation - Run the focused tests and the full Maven test suite - Once the fix passes, Cursor creates a branch and merge request. - The formerly non-blocking end-to-end job can then become a required check once it is deterministic and green. ## Review and Merge Controls - Each merge request triggers CI/CD, tests, and security scanning. - GitLab Duo Code Review evaluates the change against Java-specific project instructions. - Concrete review findings are addressed through Developer Flow before merging. - The merge request remains the central collaboration and decision point, even when Cursor performs most of the implementation work. - Fixing the test first establishes a behavioral baseline without combining it with the Java runtime migration. ## Planning the Java 21 Migration - The Java 8-to-21 migration is treated as a larger, planned effort rather than an isolated coding task. - The modernization epic contains: - Child work items - Team discussions - Research merge requests - Pipeline history - Dependencies - Security findings - This project context gives the agent information beyond the local source code and helps define the quality gates required before changing production behavior. The practical recommendation is to use Cursor for fast, narrowly scoped implementation while relying on GitLab to provide durable planning, automated evidence, and consistent review controls. This combination allows teams to modernize incrementally without sacrificing safety or reviewability.

CI/CD Gitlab Model Context Protocol Docker & Containers+4