techlist.io
KREN

Techlist.io - Korean Tech Blog Curator

aws3 min readCurated summary

AWS Weekly Roundup: AWS Transform at 1 year, Claude Platform on AWS, EC2 M3 Ultra Mac instances, and more (May 18, 2026) | Amazon Web Services

AWS’s May 18, 2026 roundup highlights the rapid expansion of AI-assisted modernization, cloud infrastructure, and developer tooling. AWS Transform reached its first anniversary after processing billions of lines of code and migrating hundreds of thousands of servers, while new services provide direct Claude access, stronger Mac development hardware, improved analytics, and automated security remediation. The roundup also covers multicloud connectivity, AI research funding, community events, and startup credits. ## AWS Transform Reaches Its First Anniversary - AWS Transform launched a year earlier for modernizing .NET, mainframe, and VMware workloads. - New capabilities include: - Custom AWS-managed or user-defined code transformations - Language and framework upgrades - Performance optimization and code analysis - Full-stack Windows modernization - Mainframe reimagining and automated testing - In its first 12 months, customers: - Migrated hundreds of thousands of servers - Saved more than 1.6 million hours - Processed over 4.5 billion lines of code - AWS Transform agents are now available in Kiro, Claude, Cursor, and Codex. ## Major Product Launches - **Claude Platform on AWS:** Provides Anthropic’s native Claude APIs, console, and beta features through existing AWS accounts and billing. Anthropic operates the service, and customer data is processed outside the AWS security boundary. - **EC2 M3 Ultra Mac instances:** Use Apple M3 Ultra Mac Studio hardware with a 28-core CPU, 60-core GPU, 32-core Neural Engine, and 256 GB of unified memory. Compared with M4 Max instances, they offer more CPU, GPU, Neural Engine cores, and memory for parallel Xcode simulators and on-device machine learning. - **Redshift RG instances:** AWS Graviton-based instances run workloads up to 2.4 times faster than previous RA3 instances while costing 30% less per vCPU. They include a vectorized engine for Apache Iceberg and Parquet data. - **Bedrock Advanced Prompt Optimization:** Compares original and optimized prompts across as many as five models, helping users improve performance or migrate between models. - **AWS Security Agent repository scanning:** The preview feature analyzes entire codebases and generates fixes linked to specific files and lines. It is free for existing Security Agent customers during the preview. - **AWS Interconnect for OCI:** Enables private, resilient multicloud connections to Oracle Cloud Infrastructure. The same open specification already supports Google Cloud and is planned for Azure later in 2026. ## Research, Community, and Startup Updates - AWS is investing $110 million in the Build on Trainium program to give university researchers access to purpose-built AI chips. - Research at institutions including UC Berkeley, MIT, and Carnegie Mellon is open source, allowing improvements to benefit the broader developer community. - AWS Community Days 2026 will take place globally, with agendas organized by local developer communities. - The Kiro Startups Credit program has reopened, offering eligible organizations up to one year of Kiro Pro+ credits applied through AWS accounts. AWS’s latest updates emphasize managed AI tools, faster specialized hardware, automated modernization, and broader support for developers and researchers. Organizations can particularly benefit by evaluating AWS Transform, Bedrock prompt optimization, new Mac instances, and the expanding multicloud connectivity options.

Read original(opens in new tab)
Amazon BedrockAmazon Ec2ClaudeApache Iceberg+3
grammarly3 min readCurated summary

How to Write a Follow-Up Email After a Sales Call, With Templates

A sales follow-up email keeps a deal moving by reinforcing the call, adding useful information, and proposing one clear next step. The most effective messages are personalized, concise, and sent soon after the conversation. Follow-ups should create momentum rather than merely ask whether the prospect has “had a chance to think.” ## Purpose of a Sales Follow-Up Email - Continues the conversation after a sales call. - Reinforces the prospect’s pain points, goals, and agreed commitments. - Answers open questions and provides relevant resources or insights. - Guides the prospect toward a decision or concrete action. - Differs from a generic check-in because it is directly tied to an active deal. ## Structure of an Effective Follow-Up ### Define the Objective - Review call notes before writing. - Choose one goal, such as confirming a demo, discussing pricing, or scheduling a meeting with a decision-maker. - Keeping the message focused makes it easier for the prospect to respond. ### Write a Specific Subject Line - Reference the conversation: “Next steps from today’s call.” - Highlight value: “Quick recap + the case study I mentioned.” - Mention a specific topic or challenge. - Avoid vague subjects such as “Just checking in.” ### Set the Context - Briefly remind the prospect what you discussed and why you are writing. - Use specific context, such as their onboarding challenge or growth goal. - Avoid generic openings like “Per our conversation” or “Just following up.” ### Recap and Add Value - Summarize the most relevant challenge, goal, or commitment in two or three sentences. - Personalize the message using something the prospect actually said. - Add one useful item, such as a case study, answer, recommendation, or insight. - The new value gives the prospect a reason to respond. ### Request One Clear Next Step - End with a specific, low-friction call to action. - Suggest a time, ask a yes-or-no question, or request confirmation of an agreed action. - Connect the CTA to the call so it feels like a natural continuation. - Avoid vague requests such as “Let me know what you think.” ### Proofread Before Sending - Check grammar, spelling, clarity, and tone. - Ensure the email sounds professional, confident, and helpful. - Read it once for correctness and again from the prospect’s perspective. ## Timing and Follow-Up Cadence - Send the first email within two hours of the call, or by the end of the same business day. - If there is no response, follow up again after three to five days with a new insight or resource. - Send a brief, low-pressure final outreach about a week later. - Use any timeline agreed during the call as the primary guide. - Test different sending times, but maintain consistency because many deals require multiple follow-ups. ## Using Templates Effectively - Templates can provide a reliable structure for common situations, including calls with clear next steps. - A strong template includes: - A personalized reference to the prospect’s challenge - A promised resource or recommendation - A specific proposed action and time - Adapt every template to the actual conversation rather than sending generic copy. The practical recommendation is to send a personalized recap quickly, include something genuinely useful, and ask for one concrete next action. This combination preserves momentum and makes it easier for the prospect to move the deal forward.

Read original(opens in new tab)
GrammarlyEmail MarketingCrmSales Follow Up+1
cloudflare3 min readCurated summary

Project Glasswing: what Mythos showed us

Project Glasswing found that Anthropic’s Mythos Preview represents a major advance in AI-assisted vulnerability research. Unlike conventional scanners, it can combine multiple low-level bugs into a credible exploit chain and generate working proofs by writing, compiling, and testing code iteratively. However, inconsistent refusals and a high rate of speculative findings mean capable models still require strong safeguards and human-led validation before large-scale deployment. ## Exploit Chain Construction - Mythos Preview can combine several seemingly minor vulnerabilities into a complete attack. - It can reason from primitives such as use-after-free bugs to arbitrary read/write access, control-flow hijacking, and ROP-based system takeover. - Earlier frontier models often identified individual bugs but failed to connect them into a working exploit. - This ability can elevate low-severity findings that might otherwise remain ignored in vulnerability backlogs. ## Automated Proof Generation - The model does more than describe suspected vulnerabilities: - Writes proof-of-concept code. - Compiles it in a scratch environment. - Executes it and checks whether the expected behavior occurs. - Revises its hypothesis when testing fails. - This feedback loop distinguishes plausible speculation from demonstrated exploitability. ## Inconsistent Model Refusals - Mythos Preview lacked the additional safeguards used in generally available models, but still developed emergent refusals around some offensive security tasks. - These refusals were inconsistent: - The same research task could succeed after an unrelated environmental change. - The model might confirm serious memory bugs but refuse to create an exploit. - Rephrasing the request or repeating it could produce a different result. - Organic model guardrails are therefore not reliable enough to act as a complete safety boundary. - Future publicly available cyber-capable models will need additional, deliberate safeguards beyond their learned behavior. ## The Signal-to-Noise Problem - Vulnerability research still requires determining which findings are real, exploitable, and urgent. - AI tools increase the volume of speculative findings, making triage more difficult. - Two major factors affect noise levels: - **Programming language:** C and C++ expose developers to memory bugs such as buffer overflows and out-of-bounds access, while memory-safe languages such as Rust eliminate many of these classes at compile time. Memory-unsafe projects produced more false positives. - **Model bias:** Models tend to report possible vulnerabilities even when evidence is weak, using qualifications such as “possibly” or “could in theory.” - Exploratory over-reporting may help discover novel issues, but it is costly in a production triage queue because each speculative finding consumes analyst time and model resources. ## Scaling AI-Assisted Security Research - Mythos Preview’s capabilities justify treating it as a different class of security tool rather than simply a better conventional scanner. - Scaling these systems will require: - Post-validation stages to filter speculative findings. - Sandboxed environments for compiling and testing proofs. - Human review of exploit chains and severity. - Explicit safety controls that do not depend solely on model refusals. - The main challenge is no longer only whether models can find vulnerabilities, but whether organizations can reliably validate, prioritize, and safely manage their output. Organizations should use advanced security models in controlled environments with layered safeguards and rigorous validation. Their ability to construct exploits is powerful, but their inconsistent safety behavior and noisy findings make unsupervised use inappropriate.

Read original(opens in new tab)
RustC++Memory SafetyLlm Security+4
gitlab2 min readCurated summary

Beyond BYOK: Why governance matters for AI agents

BYOK and local models give developers more control over which AI systems they use, but they do not provide enterprise governance by themselves. The post argues that AI agents operating in CI/CD need platform-level controls for authorization, security, and auditing, especially when no human is present. It presents GitLab Duo CLI and its Agent Platform as a governance-oriented alternative for controlled, auditable automation. ## Terminal AI: Individual Tool vs. Platform - Copilot’s BYOK and local-model support primarily extend AI capabilities at an individual developer’s workstation. - The post argues these features do not enforce organization-wide model policies or provide a complete audit trail of agent actions. - GitLab Duo CLI is positioned for both interactive development and automated workflows across multiple projects and release cycles. - Its headless mode allows it to run non-interactively and scriptably inside CI/CD pipelines. ## Why Model Choice Is Not Governance - Interactive coding tools generally assume a human reviews every action. - Automated agents can run tests, modify configuration, and perform multi-step delivery tasks without continuous oversight. - Enterprise governance therefore requires answers to questions such as: - What resources can the agent access? - Which actions is it authorized to perform? - Can the organization prove what the agent did? - GitLab’s platform-level controls include: - Human approval for actions in interactive mode. - Prompt-injection detection. - Composite identity scopes limiting agent access. - `AGENTS.md` and `SKILL.md` files for defining permitted tasks and actions. ## CI/CD Automation Requires Consistent Controls - Potential use cases include debugging failed pipelines and completing multi-step development work. - Pipeline-based agents cannot rely on a developer to detect prompt injection or unexpected behavior. - Security controls must therefore be built into the platform and applied consistently across workflows and environments. ## Model Flexibility and Data Sovereignty - The post recommends evaluating whether AI tooling maintains its security model when no human is watching. - GitLab Duo CLI supports both self-hosted and GitLab-hosted models. - Organizations can keep sensitive workloads on infrastructure they control while using hosted models for other tasks. ## Practical Recommendation Model flexibility is useful, but production adoption depends on governance. Teams considering AI agents for CI/CD should prioritize authorization, auditing, prompt-injection protection, and consistent platform controls—not just BYOK or offline execution.

Read original(opens in new tab)
AI AgentsCI/CDDevSecOpsGovernance+3
spotify3 min readCurated summary

When Can LLMs Replace Humans in A/B Tests? | Spotify Engineering

LLMs can approximate human outcomes in A/B tests only when strong assumptions hold; unlike randomized user experiments, those assumptions are not guaranteed by design. In the Upworthy headline dataset, raw GPT-4o-mini predictions recovered just 39% of the human treatment effect, but appropriate calibration and repeated sampling substantially improved accuracy. However, the assumptions are hardest to justify for genuinely new products or interventions—the cases where replacing human tests would be most valuable. ## Raw LLM Predictions Underestimate Treatment Effects - Researchers used the Upworthy Research Archive, containing click-through rates from thousands of headline experiments. - GPT-4o-mini predicted click-through rates for treatment and control headlines. - Treating those predictions as human outcomes recovered only 39% of the observed human treatment effect. - The error was systematic rather than random: LLM predictions attenuated effects toward zero. - This could lead companies to underestimate product improvements and make poor shipping decisions. ## Conditions for Valid LLM Surrogates Two assumptions are required: - **Surrogacy:** LLM predictions must capture everything about a treatment that affects human behavior. Once predictions and relevant pre-treatment characteristics are accounted for, treatment assignment should provide no additional information about the human outcome. - **Comparability:** The relationship between LLM predictions and human behavior—the calibration function—must remain stable between historical experiments and the new experiment. - If either condition fails, more LLM samples will not solve the problem; the procedure estimates an effect on the model rather than the effect on users. ## Calibration Methods Matter - Linear calibration with ordinary least squares failed a falsification test, producing estimates 3.8 standard errors away from the human benchmark. - Random forests and gradient-boosted trees performed better because they could model nonlinear relationships between LLM predictions and human click behavior. - Repeatedly sampling the LLM and averaging its outputs reduces temperature-driven noise, lowering bias toward zero and reducing variance. ## Limits for New Interventions - Historical data can partially test surrogacy and comparability, but neither assumption can be verified for a treatment never previously tested. - Trust declines as a new treatment becomes more different from past experiments. - The Upworthy setting is unusually favorable: binary outcomes, text-only treatments, similar headline variants, and an LLM trained on extensive textual data. - These assumptions are much less plausible for changes to layouts, recommendation algorithms, pricing, or entirely new product concepts. Human A/B tests remain essential for genuine product innovation. LLM-based testing is most defensible for incremental changes that resemble well-understood historical treatments, with human experiments used to validate the approach and calibrate its predictions.

Read original(opens in new tab)
Large Language ModelsMachine LearningAb TestingCausal Inference+4
gitlab3 min readCurated summary

GitLab Dedicated for Government now GovRAMP-authorized

GitLab Dedicated for Government has received GovRAMP Authorization, giving state and local agencies a compliant path to adopt SaaS-based DevSecOps. Its single-tenant, U.S.-based architecture combines data residency, private networking, physical isolation, and managed infrastructure with GitLab’s development, security, and compliance capabilities. The authorization is especially timely as more states move toward mandatory GovRAMP requirements. ## Modernization Meets Security - Government agencies are increasing investments in hybrid- and multi-cloud modernization. - NASCIO’s 2025 survey ranked modernization as a top priority for state CIOs. - Agencies must modernize while addressing: - Aging IT systems and security gaps - Third-party software supply-chain risks - Ransomware and nation-state threats - Limited budgets and staffing - GitLab Dedicated for Government is designed to provide infrastructure control and compliance without requiring agencies to build and operate the underlying platform. ## GovRAMP Authorization - GovRAMP provides a standardized security and compliance assessment for state and local government cloud services. - Thirty-two states have adopted GovRAMP, with several moving toward mandatory requirements. - Authorization reduces a major procurement barrier for agencies seeking secure DevSecOps platforms. - GitLab Duo is available within the authorized environment, while GitLab Duo Agent Platform is planned for later in 2026. ## Toolchain Consolidation - Public-sector teams often use more than five development tools and more than five security tools, increasing cost, complexity, and attack surface. - Tool sprawl also creates collaboration barriers; surveyed teams reported losing roughly six hours per week to inefficient processes. - GitLab Dedicated for Government consolidates development, security, and compliance workflows on one platform. - Centralized access controls support zero-trust implementation and consistent security policies. - Open APIs and integrations allow agencies to consolidate tools gradually rather than requiring an immediate replacement of existing systems. ## Data Residency and Protection - The platform runs on GovRAMP-authorized infrastructure with data access restricted to U.S. citizens. - Private connections can link an agency’s virtual private cloud to its isolated GitLab instance without exposing services directly to the public internet. - Data is encrypted in transit and at rest. - Customers may use their own AWS Key Management Service key to control encryption for stored data. - GitLab continuously patches vulnerabilities and CVEs, reducing the infrastructure and compliance workload for agency teams. ## Managed, Single-Tenant Hosting - Each customer receives a physically isolated, single-tenant environment. - The service is U.S.-based, privately connected, and fully managed by GitLab. - Agencies can focus staff on mission priorities instead of infrastructure operations. - GitLab argues that managed hosting can provide faster time-to-value and lower total cost of ownership than self-hosting, while improving developer productivity, delivery speed, security, and compliance. ## Native Security and Compliance - Security and compliance capabilities are integrated throughout the software development lifecycle. - Built-in scanners include: - Static application security testing - Secret detection - Container scanning - Dynamic application security testing - Dependency scanning covers both direct and transitive dependencies without depth limits. - Results are available at the project and group levels, helping teams identify supply-chain risks across applications. - Findings appear directly in merge requests and pipeline security views for contextual, one-click triage. - Custom rulesets and automated security policies help reduce false positives and standardize enforcement. GitLab Dedicated for Government offers agencies a managed alternative to self-hosted DevSecOps while preserving stronger control over residency, isolation, networking, encryption, and compliance. For state and local governments preparing for stricter GovRAMP requirements, it provides a practical foundation for modernization without sacrificing security or operational control.

Read original(opens in new tab)
GitlabDevSecOpsCloud SecuritySoftware Supply Chain Security+4
spotify3 min readCurated summary

Coding Is No Longer the Constraint: Scaling Developer Experience to Teams and Agents at Spotify | Spotify Engineering

Spotify argues that AI has shifted software development’s main constraint from writing code to coordinating people, systems, and decisions. Years of investment in standardized platforms, automation, and developer experience enabled Spotify to adopt AI coding tools at extraordinary scale. The company’s experience suggests that consistent infrastructure and strong feedback loops are essential for making both human developers and coding agents effective. ## Rapid AI Adoption - More than 99% of Spotify engineers use AI coding tools weekly. - 94% report improved productivity. - Pull request frequency has increased by 76%, with most PRs created by developers working alongside AI agents. - Adoption accelerated sharply after the release of Claude Opus 4.5. ## Fleet Management Before AI Agents - Spotify’s codebase was growing seven times faster than its engineering workforce. - Developers increasingly spent time on dependency upgrades, API migrations, and vulnerability fixes. - Fleet Management automated changes across hundreds or thousands of components. - Its orchestration system, Fleetshift, has merged more than 2.5 million maintenance PRs, most without human intervention. - This approach reduced migrations from work taking weeks or months across many teams to centrally managed operations. ## Honk: A Background Coding Agent - Deterministic scripts struggled with complex refactoring and the edge cases found across large codebases. - Spotify created Honk, a background coding agent powered by Claude through the Agent SDK. - Honk runs in Kubernetes pods, allowing many coding sessions to execute concurrently. - It can use trusted tools and run builds in CI across multiple operating systems. - Fleetshift identifies targets, schedules work, and tracks PRs, while Honk performs the code changes. - A recent Java migration across Spotify’s backend services took three days. - Engineers can invoke Honk through Slack, where it uses conversation context to create and return PRs. - Honk v2 adds shared sessions, team projects, and agent orchestration through Chirp. ## Standardization Improves Agent Performance - Spotify’s principle of limiting the number of technologies it supports reduces decisions and improves collaboration. - Consistent service architectures and design patterns also give AI agents better reference material. - Agents perform worse in fragmented codebases with inconsistent conventions. - Backstage provides a unified internal developer portal and catalog for software components. - Spotify exposes Backstage capabilities to agents through MCP integrations and command-line tools. - Agents can discover component ownership, read documentation, and contact responsible teams. ## Guardrails Through Backstage - Backstage’s Soundcheck and “golden state” define recommended technologies and practices. - Teams can assess their components against these standards. - Static analysis and linting provide immediate feedback when developers or agents use unsuitable patterns. - This creates a feedback loop that helps agents correct their work and drives consistency across the organization. Spotify’s experience indicates that scaling AI development requires more than giving engineers access to models. Organizations should invest in standardized platforms, searchable component metadata, automated fleet-wide workflows, and strong validation systems so agents can operate reliably at team scale.

Read original(opens in new tab)
AI AgentsKubernetesCI/CDSlack+4
discord2 min readCurated summary

Every Voice and Video Call on Discord Is Now End-to-End Encrypted

Discord now uses end-to-end encryption by default for nearly every voice and video call, without requiring users to opt in. The rollout, completed in March 2026, relies on the open DAVE protocol and spans desktop, mobile, browsers, consoles, bots/apps, and the Social SDK. Discord says encryption was introduced without reducing call quality or performance, though Stage channels remain exempt. ## Building DAVE Across Platforms - Discord began experimenting with voice and video E2EE in 2023. - The DAVE protocol was introduced in 2024 as an open, audited encryption system. - Support was expanded to: - Desktop and mobile - Web browsers - PlayStation and Xbox - Discord bots and apps - The Social SDK - The protocol and its implementation are publicly available and open source. - Trail of Bits externally audited the design and implementation. - Discord expanded its bug bounty program to cover DAVE. - The team collaborated with Mozilla to fix a Firefox issue that interfered with encrypted calls. ## Reaching Default Encryption - Since early March 2026, E2EE covers calls in: - Direct messages - Group DMs - Voice channels - Go Live streams - All clients must support DAVE before joining a call. - Discord is removing unencrypted fallback code, after which calls will no longer be able to downgrade to unencrypted connections. - Encryption operates transparently, preserving expected call quality and latency. ## Why Stage Channels Are Excluded - Stage channels are intended for large-scale broadcasts, AMAs, live events, and town halls. - Their broadcast-oriented architecture differs from personal voice and video conversations. - Discord therefore continues to exclude them from E2EE. ## Future Privacy Work - Discord will continue maintaining and improving DAVE, including its open protocol and bug bounty program. - The company has no current plans to add E2EE to text messages. - Many Discord text features depend on server-side access to messages, so supporting encryption would require substantial redesign. Discord’s recommendation is effectively to treat DAVE as an ongoing privacy foundation rather than a finished project: voice and video calls are now protected by default, while the protocol remains open to inspection and continued improvement.

Read original(opens in new tab)
Open SourceEnd To End EncryptionBug BountyCross Platform+3
gitlab3 min readCurated summary

Fix bugs with Codex and GitLab

Codex accelerates coding in the terminal, but producing a fix is only one part of shipping software. GitLab supplies the surrounding lifecycle: issues, merge requests, CI/CD, security scanning, code review, and human approval. The tutorial demonstrates this progression through a Rust WebSocket bug, first with local Codex, then with GitLab MCP for issue context, and finally with Codex as an external agent in GitLab Duo Agent Platform. ## Prerequisites and Project Setup - Configure Codex in the terminal, Rust/Cargo, and access to a GitLab project. - Import and clone the Tanuki IoT Platform project, then launch Codex from its repository root. - The tutorial focuses on `backend/`, where: - Sensors submit readings through a REST API. - Dashboards receive live readings through WebSocket streams. - `AGENTS.md` provides Codex with repository structure, toolchain instructions, build commands, and quality expectations. ## Reproducing the WebSocket Filtering Bug - Start the Rust metrics backend on port `9090`: ```bash PORT=9090 cargo run --manifest-path backend/rust-metrics-store/Cargo.toml ``` - Connect to a filtered WebSocket stream: ```bash websocat 'ws://localhost:9090/ws?sensor=arduino-iot-collector&metric=temperature_celsius' ``` - Submit both temperature and humidity readings for the same sensor through the REST API. - The stream incorrectly returns both metrics instead of only `temperature_celsius`, proving that the WebSocket handler does not apply the metric filter. ## Fixing the Bug with Codex - Give Codex a focused request to add metric filtering to `/ws`. - Codex examines the Rust source and identifies that the endpoint already supports `sensor` filtering but lacks an optional `metric` condition. - It updates the handler, adds tests, and keeps documentation aligned with the implementation. - Codex runs formatting, tests, and builds before creating a branch, committing, and pushing the change. - Once the merge request is created, GitLab handles: - CI/CD pipelines - Security scanning - GitLab Duo Code Review - A follow-up WebSocket test confirms that supplying both sensor and metric now returns only the requested metric. ## Adding GitLab Context with MCP - Local Codex can inspect repository files, but it cannot automatically see GitLab issues, requirements, implementation notes, merge-request discussions, or pipeline status. - The GitLab MCP server connects Codex to that development lifecycle context. - Codex can retrieve the existing issue directly instead of requiring the developer to copy its contents into the prompt. - The issue acts as the shared source of truth and includes: - The bug description - Functional behavior requirements - Non-functional requirements - Required tests - Updates to `README.md` and `AGENTS.md` - Implementation notes - This helps Codex produce a fix that satisfies the agreed requirements rather than merely addressing the symptom visible in the local code. ## Using Codex as an External GitLab Agent - The tutorial’s third workflow uses Codex inside GitLab Duo Agent Platform as an external agent. - This allows the agent to participate after the merge request is open, particularly when addressing review feedback. - GitLab remains the system coordinating issues, merge requests, pipelines, reviews, and deployment, while Codex contributes its terminal-oriented coding capabilities. - The overall workflow moves from bug report to implementation, automated validation, review feedback, revisions, and an informed human decision to ship. ## Practical Conclusion Use Codex for fast, repository-local implementation, but connect it to GitLab through MCP or Duo Agent Platform when requirements and review context matter. The strongest workflow combines Codex’s coding speed with GitLab’s issue-aware, automated, and human-governed delivery lifecycle.

Read original(opens in new tab)
AI AgentsCI/CDGitlabRust+3
github3 min readCurated summary

Building a general-purpose accessibility agent—and what we learned in the process

GitHub is piloting a general-purpose accessibility agent that answers accessibility questions and automatically fixes straightforward issues in front-end code. The agent has reviewed 3,535 pull requests and resolved 68% of identified issues, especially problems involving structure, control names, status messages, text alternatives, and keyboard focus. GitHub’s experience shows that an accessibility agent is most effective as an augmentation of human expertise, supported by a strong foundation of manually documented accessibility work. ## Goals and Results - The agent serves two purposes: - Provide just-in-time accessibility guidance through GitHub Copilot CLI and VS Code. - Detect and automatically remediate simple, objective accessibility issues before production. - It evaluates pull requests that modify front-end code. - Its five most common issue categories are: - Making structure and relationships understandable to assistive technologies. - Giving interactive controls clear, concise names. - Ensuring users receive important status announcements. - Providing text alternatives for non-text content. - Maintaining a logical keyboard focus order. - Example fixes can identify mismatches between visual order and screen-reader reading order, then suggest code changes that developers can commit directly. ## An Augmenting, Not Universal, Tool - GitHub frames accessibility through the social model of disability: barriers are often created by how digital environments are designed and built. - The agent is intended to help engineers remove those barriers, not “solve” accessibility independently. - It is not a silver bullet capable of handling every accessibility scenario. - Clearly limiting its responsibility helped GitHub launch the experiment more quickly and gain broader internal support. ## Why Manual Accessibility Work Matters - New and upcoming regulations, including the European Accessibility Act and the Americans with Disabilities Act’s planned WCAG 2.1 AA requirements, increase the importance of accessibility investment. - Organizations without established processes for manually identifying and fixing accessibility problems will be at a disadvantage. - GitHub already had a mature issue-management process containing: - Structured problem reports. - Reproduction steps. - Severity, service-area, and WCAG metadata. - Links to fixing pull requests. - Acceptance criteria. - Centralizing these issues in one repository made the collection a valuable reference corpus for the agent. ## Using Historical Issues as Training Material - The agent examines past accessibility issues and related pull requests to find applicable code and language patterns. - LLMs’ fuzzy matching can be useful here because it helps connect new problems with similar historical examples. - Generic instructions such as “follow accessibility best practices” are insufficient. - LLMs often reproduce accessibility antipatterns because their training data contains decades of inaccessible code. - Manually cataloged issues and organization-specific fixes provide contextual examples that are more useful than short, generic accessibility checklists. GitHub’s experience suggests that teams should first build reliable human processes for reporting and remediating accessibility issues. Once that structured knowledge exists, an agent can help apply it consistently and efficiently—while remaining a complement to, rather than a replacement for, accessibility expertise.

Read original(opens in new tab)
Large Language ModelsAccessibilityGithub CopilotGitHub Actions+3
github3 min readCurated summary

Raising the bar: Quality, shared responsibility, and the future of GitHub’s bug bounty program

GitHub is reaffirming its commitment to external security researchers while tightening bug bounty submission standards. Rising report volumes—partly driven by AI and other tools—have increased both valuable findings and unvalidated noise. GitHub’s central message is that tools are welcome, but researchers remain responsible for validating vulnerabilities, demonstrating impact, and understanding the platform’s shared security boundaries. ## Rising Submission Volume - New tools, including AI, have lowered the barrier to security research and expanded the number of people examining attack surfaces. - GitHub has also seen more reports that: - Lack a working proof of concept - Describe only theoretical attack scenarios - Concern categories already listed as ineligible - Because this challenge affects the wider industry, some bug bounty programs have shut down; GitHub instead plans to improve its program. ## Requirements for Strong Reports - Submissions must include a working proof of concept demonstrating concrete security impact. - Researchers should show what an attacker can actually accomplish, rather than merely describing a possible attack path. - Reports must respect GitHub’s published scope and ineligible findings list. Examples of generally ineligible issues include: - DMARC, SPF, or DKIM configuration problems - User enumeration - Missing security headers without a demonstrated attack path - Scanner, static-analysis, or AI-generated findings must be manually validated before submission. - Unverified false positives create unnecessary triage work and may affect a researcher’s HackerOne Signal and reputation. ## AI Is Welcome, but Validation Is Required - GitHub supports the use of AI in security research and uses AI internally. - AI-assisted reports are acceptable when findings are reproduced, verified, and supported by a working proof of concept. - Researchers remain accountable for the accuracy of their submissions, regardless of which tools produced them. - GitHub recommends a concise report structure: - A short issue summary - Clear reproduction steps and evidence, such as screenshots, HTTP requests, or terminal output - An impact statement explaining what an attacker can achieve - Lengthy theoretical explanations and AI-generated filler can obscure the actual vulnerability and slow triage. ## Shared Responsibility and GitHub’s Security Boundary - GitHub protects users through automated scanning, manual review, and other systems for detecting malicious content. - Users are still responsible for deciding what repositories, issues, code, and scripts to trust. - Users should review content before executing or interacting with it. - Cloning a repository is considered an act of trust because Git hooks, build scripts, and other automation may run locally. - Users must also secure their own environments, including tokens, credentials, and local security settings. - Scenarios generally do not bypass GitHub’s security controls when they require victims to deliberately engage with attacker-controlled content. ## Common Shared-Responsibility Scenarios - Prompt injection in content a user intentionally provides to an AI tool - Git hooks or filters executing code from a repository the user checked out - Malicious content in a repository the user chose to clone - Unexpected LLM output caused by untrusted input supplied by the user Research into these areas remains useful when it identifies a way to bypass an actual GitHub security control without requiring the user to actively trust malicious content.

Read original(opens in new tab)
GithubGitAi SecurityStatic Analysis+4
line3 min readCurated summary

ODW #6: The Pros and Cons of MCP and Agent Skills from a Git Automation Perspective

The post presents agent skills as a simpler, more practical alternative to building MCP servers for many AI-agent workflows. It demonstrates how to use Anthropic’s `skill-creator` to build a Git release automation skill that analyzes commits, updates a changelog, bumps versions, commits, tags, and pushes releases. The author emphasizes that precise requirements and explicit constraints are essential for preventing unintended agent behavior. ## Why Agent Skills Are Practical - Agent skills can simplify both implementation and architecture compared with custom MCP servers. - Although online examples explain the concept, the post focuses on a practical, work-oriented use case. - The tutorial assumes familiarity with the basic concept of skills and concentrates on building and applying one. ## Git Smart Release Automation The example skill automates releases for a Git project in the current working directory. - Reads the Git history after the most recent tag. - Summarizes changes and adds them to the top of `CHANGELOG.md`. - Creates `CHANGELOG.md` if it does not exist. - Updates the version in `pyproject.toml`. - Commits the changelog and version changes. - Creates a corresponding Git tag. - Operates based on the terminal’s current `pwd`. ## Using `skill-creator` - Anthropic’s official `skill-creator` skill is used to generate the new automation skill. - The user provides a detailed requirements specification rather than implementing everything manually. - Explicit workflow steps and constraints help keep the agent focused on the correct directory and avoid unnecessary complexity. - The development process is demonstrated with Claude Code. ## Clarifying Requirements Before generating the skill, the agent asks questions to resolve ambiguous behavior. - Support patch, minor, and major version bumps. - Use `v0.1.0` for the first release when no prior tag exists. - Follow a structured changelog format. - Push both commits and tags to the remote repository. - Abort with an explanation if the working directory contains uncommitted changes. ## Generated Skill Structure The completed skill contains: - `SKILL.md` — instructions and metadata for the agent. - `scripts/smart_release.py` — a local Python script that performs Git operations and file modifications. - `evals/evals.json` — evaluation cases for testing the skill. The skill also includes: - Keep a Changelog-style updates. - Dirty working-directory checks. - Automatic remote pushing. - Commit categorization such as `feat`, `fix`, and `docs`. ## `SKILL.md` and the Python Script - The frontmatter in `SKILL.md` acts as a concise discovery description that helps the agent decide when to load the skill. - The Markdown body provides the detailed execution workflow. - `smart_release.py` handles operations requiring deterministic file and Git manipulation, reducing the need for the language model to process raw data directly. - The post then begins testing the skill with a simple Python calculator project. A practical approach is to define release behavior, edge cases, and safety constraints before asking an agent to generate the skill, while delegating file and Git operations to a local script.

Read original(opens in new tab)
Model Context ProtocolPythonClaude CodeGit+3
aws2 min readCurated summary

Amazon Bedrock introduces new advanced prompt optimization and migration tool | Amazon Web Services

Amazon Bedrock Advanced Prompt Optimization automatically rewrites prompts to improve performance or support migration between models. It compares original and optimized prompts across up to five Bedrock models using example inputs, reference answers, and configurable evaluation methods. The tool supports text and multimodal inputs, then reports quality scores, estimated costs, and latency. ## Prompt Optimization and Model Migration - Users can optimize prompts for their current model or compare a baseline model with up to four alternatives. - Bedrock runs prompts against supplied examples, evaluates the responses, and iteratively rewrites the prompt. - Results include: - Original and optimized prompt templates - Evaluation scores - Cost estimates - Latency information - The process can identify regressions in established use cases and improve weaker tasks. ## Multimodal and Dataset Support - Prompt templates and evaluation examples are supplied in JSONL format. - Each JSON object must appear on a single line. - Supported multimodal inputs include: - PNG and JPG images - PDF documents - Files can be uploaded directly or imported from Amazon S3. - Optimization results and evaluation data can also be written to an S3 location. ## Evaluation Methods Users can select one evaluation approach per prompt template: - **Lambda-based evaluation** - Uses custom Python scoring logic for metrics such as accuracy, F1, execution accuracy, or structured JSON matching. - The function compares model outputs with reference responses. - **LLM-as-a-judge** - Uses a custom rubric with named metrics, structured instructions, and rating scales. - Bedrock’s judge model evaluates responses and provides scores with reasoning. - Claude Sonnet 4.6 is the default judge, though other supported judge models can be selected. - **Natural-language steering criteria** - Describes desired qualities such as brand voice, formatting, or safety constraints. - A default LLM judge evaluates responses holistically against those criteria. ## Getting Started and Availability - Start from **Create prompt optimization** in the Amazon Bedrock console or use the `CreateAdvancedPromptOptimizationJob` API. - Optimization is available in selected AWS Regions across North America, Europe, Asia-Pacific, Canada, and South America. - Pricing is based on Bedrock inference tokens consumed during optimization, using standard per-token inference rates. The tool is most useful when teams need measurable prompt improvements or want to migrate applications to another model. Preparing representative evaluation examples and choosing an appropriate scoring method will be essential for producing reliable optimization results.

Read original(opens in new tab)
Large Language ModelsAmazon BedrockMultimodal AIAmazon S3+3
github1 min readCurated summary

From latency to instant: Modernizing GitHub Issues navigation performance

Alexander is a senior software engineer on GitHub’s Issues team, where he focuses on making developer workflows feel fast and seamless. His background spans computer graphics, machine learning, and geospatial software, giving him a broad technical perspective. ### Professional Role - Works on the GitHub Issues team. - Focuses on improving everyday developer workflows. - Enjoys finding creative ways to make interactions feel instant. ### Technical Background - Computer graphics - Machine learning - Geospatial software The provided content is a short professional biography rather than a technical blog post, so it does not include a specific argument, technical explanation, or conclusion.

Read original(opens in new tab)
Machine LearningSoftware EngineeringGithub IssuesComputer Graphics+1
cloudflare3 min readCurated summary

Our billing pipeline was suddenly slow. The culprit was a hidden bottleneck in ClickHouse

Cloudflare’s migration to per-namespace retention in ClickHouse unexpectedly caused billing queries to slow dramatically, even though I/O, memory usage, rows scanned, and parts read appeared normal. The hidden bottleneck was query-planning lock contention: as the new `(namespace, day)` partitioning scheme multiplied the number of data parts, queries spent much of their time waiting for a mutex protecting the table’s active-part list. Investigation with flame graphs exposed the issue, leading Cloudflare to develop ClickHouse fixes. ## A Petabyte-Scale ClickHouse Platform - Cloudflare stores more than 100 PB across dozens of ClickHouse clusters. - Its Ready-Analytics system lets hundreds of internal teams share a massive table using: - A `namespace` to identify each dataset - A standard schema - A primary key of `(namespace, indexID, timestamp)` - By December 2024, the system contained more than 2 PiB and ingested millions of rows per second. ## The Limits of a Global Retention Policy - The table was partitioned by day, and a retention job dropped partitions older than 31 days. - This prevented teams from applying different retention periods: - Some needed years of data. - Others needed only a few days. - Teams requiring custom retention had to use more complicated, conventional table setups. ## Moving to Per-Namespace Partitions - Cloudflare considered: - Creating a separate table for every namespace. - Changing the partition key from `(day)` to `(namespace, day)`. - They chose the second option because it preserved the existing retention workflow while enabling namespace-level deletion. - The team expected more total parts but assumed query performance would remain stable because queries already filtered by namespace. - Migration began in January 2025 using ClickHouse’s `Merge` table feature. ## Billing Queries Begin to Slow - By late March 2025, billing aggregation jobs were approaching their daily deadlines. - Standard performance indicators looked healthy: - I/O and memory were normal. - Queries scanned no more rows or parts than before. - Query latency correlated strongly with the growing total number of parts in the cluster, revealing that merely having more parts could hurt performance. ## Finding the Hidden Lock Bottleneck - Cloudflare used ClickHouse’s `trace_log` to generate flame graphs for leaf `SELECT` queries. - CPU traces showed that roughly 45% of sampled CPU time was spent in `filterPartsByPartition`, which filters parts during query planning. - Reordering pruning heuristics produced only a 5% improvement. - “Real” traces, which include waiting and inactive threads, exposed the real issue: - More than half of query time was spent waiting on a mutex protecting the table’s active-part list. - Every query-planning thread had to contend for the `MergeTreeData` lock. - The migration increased the number of parts enough to make this previously unnoticed planning bottleneck dominant. The main lesson is that ClickHouse performance can degrade during query planning even when execution metrics look normal. When partitioning changes substantially increase part counts, teams should monitor planning time and lock contention—not just data scanned, I/O, or memory—and use real-time flame graphs to identify waits hidden by CPU-only profiling.

Read original(opens in new tab)
ClickhouseLock ContentionDatabase PartitioningQuery Planning+2