Techlist.io - Korean Tech Blog Curator

aws2 min readCurated summary

Introducing the next generation of Amazon OpenSearch Serverless for building your agentic AI applications | Amazon Web Services

Amazon’s next-generation OpenSearch Serverless is a managed search and vector engine optimized for agentic AI applications. It scales from zero to thousands of requests per second, creates resources in seconds, and can reduce costs by up to 60% compared with clusters provisioned for peak demand. The release is generally available across supported AWS commercial Regions and integrates with tools such as Vercel, Kiro, Claude Code, and Cursor. ## Elastic Scaling and Cost Optimization - Scales capacity up to 20 times faster than the previous generation. - Supports scale-to-zero when idle, minimizing compute costs. - Charges separately for compute through OpenSearch Compute Units (OCUs), storage in GB-month, and GPU acceleration where applicable. - Supports capacity limits for indexing and search, with minimum capacity set to zero and configurable maximums. ## Creating Next-Generation Collections - Collections can be created through the Amazon OpenSearch Service console, AWS CLI, or SDKs. - The console’s **Express create** option automatically applies default settings and matching security policies. - At launch, supported collection types are: - Full-text search (`SEARCH`) - Vector search (`VECTORSEARCH`) - Users who need the existing infrastructure can select the classic OpenSearch Serverless generation. - Collections inherit their generation from a parent collection group. Example CLI workflows create a next-generation collection group with standby replicas and then create a search collection within it. ## Integrations for Agent Development - Vercel users can create or connect OpenSearch Serverless collections directly from the Vercel console. - OpenSearch Agent Skills bring search-specific knowledge, best practices, and multi-step workflows into agents using Claude Code, Cursor, and Kiro. - Kiro’s OpenSearch Launchpad provides guided architecture planning for building search applications. ## Availability - The next generation is generally available in all AWS commercial Regions where OpenSearch Serverless is currently offered. - AWS recommends consulting the OpenSearch Serverless documentation and pricing information for configuration and cost details. The release is intended to let developers deploy production-ready search and vector backends quickly, while avoiding the infrastructure management and peak-capacity costs associated with provisioned OpenSearch clusters.

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

Beyond code generation: rethinking engineering productivity in the age of AI agents

AI coding agents have increased Dropbox’s code production, but they have also exposed bottlenecks in review, testing, release coordination, and operations. The central argument is that engineering productivity must be measured by end-to-end product velocity and customer impact—not code or pull-request volume alone. Dropbox is responding with agent platforms, stronger workflow infrastructure, broader quality metrics, and training that helps engineers adapt to new responsibilities. ## From Copilots to Agents - Copilots assist with explanations, snippets, and questions within existing workflows. - Agents can take scoped tasks, inspect repositories, edit files, run tests, fix failures, and return changes for human review. - Engineers remain responsible for intent, architecture, quality, and release decisions. - Increased parallel work and code output create new pressure on: - Code review systems - CI and testing infrastructure - Validation workflows - Release processes - Production operations - More code and pull requests do not necessarily create more customer value. ## Nova as Dropbox’s Agent Platform - Nova runs AI coding agents in controlled environments with relevant codebase context and internal engineering practices. - Its value comes from the surrounding platform—safe execution, workflow integration, guardrails, and human review—not only from the underlying model. - Nova generates approximately one in twelve Dropbox pull requests. - It supports both feature work and maintenance tasks, including: - Migrations - Flaky-test remediation - Bug investigation - Dependency updates - Other high-effort engineering work - The intended workflow is structured: define the task, let the agent work within constraints, validate the result, and require human approval before production. ## Measuring Product Velocity and Impact - Pull-request throughput was useful when implementation speed was the main constraint, but it is insufficient as AI increases output. - Dropbox evaluates whether the broader engineering system can absorb additional work efficiently. - Its four-stage measurement model tracks: - **Fuel:** Whether engineers use AI tools - **Adoption:** How teams change their workflows - **Output:** Whether AI contributes to production work - **Impact:** Whether products reach customers faster and create greater value - Quality and trust metrics include review turnaround time, first-run test pass rate, defect ratio, and rework rate. - Productivity improvements must not come at the expense of reliability or customer trust. ## Evolving Engineering Workflows - Engineers increasingly focus on defining intent, framing problems, reviewing changes, and making architectural and quality decisions. - Adoption requires more than tools; Dropbox uses hands-on learning, hackathons, bootcamps, workflow examples, and peer-led training. - Teams should adopt agents at different speeds based on risk, context, and readiness. - The goal is not to automate every workflow, but to make agentic development safe, useful, measurable, and repeatable. ## Broader Lessons - AI does not remove bottlenecks; it shifts them downstream. - Organizations must invest in validation, orchestration, governance, workflow integration, and measurement alongside code generation. - Competitive advantage will come less from access to common foundation models and more from the systems built around them: internal context, safeguards, quality controls, and integrated engineering workflows. Dropbox’s experience suggests that companies should treat AI agents as a change to the entire software delivery system, not merely as faster coding tools. The strongest results will come from improving the full path from idea to validated production impact.

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

Slack AI: The Path to Multi-Cloud

Slack’s AI infrastructure evolved from self-managed SageMaker deployments to managed Amazon Bedrock as Slack sought enterprise-grade security, reliability, lower operational overhead, and faster access to new models. SageMaker provided strong isolation and compliance but required extensive capacity and regional management, while Bedrock simplified operations through managed throughput and on-demand options. Slack’s carefully staged migration achieved zero customer-facing incidents and established a practice of measuring parity, shifting traffic gradually, and monitoring continuously. ## Phase 1: The SageMaker Era - SageMaker offered: - Security and FedRAMP compliance - Control over model availability - An escrow VPC strategy that kept Slack data private while preventing access to providers’ model weights - Slack deployed model containers across multiple AWS regions to support global availability. - Engineering teams had to manage: - Cross-region IAM roles - Routing across model endpoints - Capacity planning - Auto-scaling - The main operational challenges were: - **Scaling latency:** New instances could not start instantly. - **GPU scarcity:** A100 and H100 capacity was often unavailable. - **Over-provisioning:** Idle resources had to be maintained for peak demand. - On-Demand Capacity Reservations and scheduled scaling reduced some problems, but required substantial manual coordination. - SageMaker also created model feature lag because AWS prioritized releasing newer Anthropic models and optimizations through Bedrock. ## Phase 2: Migrating to Amazon Bedrock By mid-2024, Bedrock had matured enough to meet Slack’s security and FedRAMP requirements. - The migration provided: - Managed infrastructure instead of individual GPU instances - Faster access to newly released LLMs - Flexible capacity options for different workload patterns - Slack used: - **Provisioned Throughput (PT)** for predictable, latency-sensitive features such as channel summaries - **On Demand (OD)** for bursty scheduled workloads such as Recap - Bedrock measured capacity in **Model Units (MUs)**, letting Slack plan around token throughput rather than hardware details. ## Executing a Zero-Incident Migration Slack used a gradual, validation-heavy process: - Obtained Legal, Security, and FedRAMP approval before moving production traffic. - Performed load testing to determine the number of MUs needed to match SageMaker capacity. - Compared model quality and latency through A/B tests and evaluation frameworks. - Used feature flags for incremental traffic shifting and immediate rollback. - Ran shadow requests and extensive tests to verify behavioral and performance parity. This approach allowed Slack to move live production traffic without customer-facing incidents. ## Operational Improvements and Remaining Gaps - Bedrock reduced infrastructure maintenance, allowing engineers to focus more on model quality and product features. - Slack could adopt new models weeks or months earlier, improving features such as AI Search with higher-reasoning models. - Capacity planning shifted from reactive scaling to forecasting demand several weeks ahead. - Provisioned Throughput still required maintaining a high baseline of MUs to handle large regional workday surges, creating an over-provisioning challenge for traffic that varies significantly throughout the day. Slack’s migration demonstrates that managed AI infrastructure can improve agility and reliability, but success depends on careful capacity modeling, comprehensive parity testing, gradual rollout, and continuous monitoring.

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

How we built Cloudflare's data platform and an AI agent on top of it

Cloudflare built Town Lake to unify data scattered across production databases, analytics systems, streams, and object storage behind one governed SQL interface. The platform combines Trino, Iceberg on R2, DataHub, and custom access-control and PII-detection services to make data fresher, more discoverable, and safer to use. Skipper extends Town Lake with a natural-language AI interface intended to provide fast, accurate, and auditable answers without requiring users to write SQL. ## The Data Sprawl Problem - Cloudflare processes over a billion events per second across a network spanning more than 330 cities and 120 countries. - Relevant data was distributed across: - Postgres - ClickHouse - BigQuery - Kafka - Google Cloud Storage and R2 - Numerous pipelines and production databases - Users needed separate credentials, query languages, retention expectations, and system knowledge for each source. - Sampled analytics data worked for dashboards but was unsuitable for billing, usage calculations, and security investigations. - External vendors created cost and dependency concerns. - Important data was difficult to discover because table locations, schemas, joins, and customer-ID mappings depended on tribal knowledge. - Data infrastructure had historically been treated as a back-office service rather than core company infrastructure. ## Goals for the New Platform Cloudflare wanted a single place where authorized employees could answer questions about customers, traffic, billing, security events, and support activity. - Support both: - Fresh, accurate, unsampled data for billing and investigations - Fast, downsampled data for dashboards and exploration - Provide built-in governance: - Automatic PII detection - Sensitive tables locked down by default - Auditable access - Time-limited permission grants - Build the system using Cloudflare’s own products, including R2, Workers, Access, and Workflows. - Eventually let employees ask questions in plain English rather than requiring SQL knowledge. - That natural-language interface became Skipper. ## Town Lake’s Lakehouse Architecture Town Lake is a lakehouse: a query engine combines data from object storage and operational systems while a metadata layer makes the data behave like a unified database. - **Trino** serves as the query engine. - A single query can join Postgres, ClickHouse, and Iceberg tables stored on R2. - Trino pushes filters into source systems and combines results without requiring intermediate materialization. - **R2 Data Catalog and Apache Iceberg** store warm and cold data. - Iceberg provides schema evolution, time travel, partition evolution, and compaction. - Data can be rolled from per-minute to hourly and eventually daily granularity as it ages. - Older data becomes cheaper to store while remaining queryable. - Parquet files on R2 cost less than retaining equivalent data in an OLAP database. - **DataHub** provides the metadata catalog. - It stores table and column descriptions, owners, lineage, and glossary terms. - Users can discover what a table contains, which teams maintain it, and how it relates to upstream and downstream data. ## Access Control and Privacy - **Lifeguard** manages access policies. - Rules are stored in D1. - User and group memberships are retrieved dynamically from Cloudflare’s internal access-management system. - Lifeguard produces JSON policies that Trino reads over HTTP. - It also supplies access information to Skipper and the Gateway, allowing users to be blocked before queries execute. - **Skimmer** continuously scans tables for PII. - It samples rows from columns across the data platform. - Workers AI classifies whether columns contain personally identifiable information. Cloudflare’s overall approach is to combine unified querying, durable low-cost storage, rich metadata, and policy enforcement so data can be broadly useful without sacrificing accuracy or governance.

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

Solo founding is at an all-time high: Top performers have these traits in common

Solo founders now represent 63% of new Stripe Atlas C corps, but performance is increasingly polarized: median revenue is falling while top performers grow rapidly. Stripe’s analysis of thousands of solo-founded startups found that the strongest companies tend to be AI-native, global from launch, B2B-focused, and effective at retaining customers. Multifounder startups generally pull ahead over time, though exceptional bootstrapped solo founders can nearly match them. ## AI-Native Products - Top-decile solo founders were about twice as likely to build products whose core functionality depends on AI models. - By year two, AI-native startups generated nearly twice the revenue of other solo-founded companies. - Their advantage was broad-based, spanning approximately the 50th through 95th revenue percentiles—not merely the result of a few extreme outliers. - AI lowers the technical barrier, allowing founders to focus on solving problems quickly, shipping products, and finding distribution. ## Global Sales from Launch - Top-performing solo founders sold to an average of 10 countries in their first month, compared with three for median founders. - By month 24, they reached about 40 non-US countries, versus six for median founders. - International customers generated 51% of top-decile revenue, compared with only 2% for median companies. - Early access to large markets such as the US helped accelerate growth. ## B2B Business Models - Top solo founders were nearly 30% more likely to build B2B companies. - By month 24, the median solo B2B startup generated more than four times the revenue of the median B2C startup. - Among top performers, B2B companies earned nearly twice as much as comparable B2C companies. - This advantage persisted among bootstrapped startups, suggesting it was not primarily caused by easier access to funding. ## Early Customer Retention - Nearly 30% of customers at top-decile startups returned the following month, compared with 8% at middle-decile companies. - Top performers began recovering churned customers around three months earlier. - By the start of year two, their first-month customers were spending 47% more than at acquisition—roughly twice the increase seen among middle-decile startups. - In B2B, top solo founders retained initial customers at six times the rate of median founders. - Recurring billing was more common among top performers, by 26 percentage points in B2B and 20 points in B2C. ## Solo Founders Compared with Teams - Solo startups initially generated more revenue than multifounder startups, but multifounder companies led by month 24. - Top-decile multifounder startups produced 53% more revenue than top-decile solo startups, even after accounting for funding. - Among the very best bootstrapped companies, the gap narrowed to just 5%. - Exceptional solo founders compensate for limited headcount through speed, resourcefulness, hiring, advisors, and founder networks. Solo founders appear most likely to succeed when they use AI to move quickly, target business customers, sell internationally from the beginning, and validate demand through strong retention. Teams still offer a long-term advantage, but highly capable, well-connected solo founders can approach team-level performance without outside funding.

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

From Tokyo to Fukuoka, Finding Answers in the Field: Our CS InquiryChat Implementation Journey

MessagingHub replaced Demaecan’s third-party customer-service chat with its own InquiryChat platform. The transition eliminated annual licensing costs, improved operational flexibility, and reduced repeat customer inquiries by about 20%. The project’s success depended not only on rebuilding features, but also on observing call-center work directly, aligning distributed stakeholders, and balancing agent convenience with user privacy. ## Why Demaecan Chose an In-House Platform - Demaecan’s existing chat provider was being discontinued, prompting a choice between upgrading to another vendor solution or adopting InquiryChat. - InquiryChat was selected because it offered: - Zero licensing costs - Flexible customization for Demaecan’s processes - Direct internal technical and operational support - Secure access to customer information - Real-time analytics and reporting - The migration had to preserve service continuity while changing agents’ workflows and tools. ## Problems with the Existing Service - Agents could preview messages before users sent them, creating a transparency and privacy concern. - Chat sessions were not preserved when users left, forcing customers to repeat their inquiries. - Vendor customization and integration options were limited. - Some existing features appeared useful on paper but were not actually used in call-center operations. - Because agents were accustomed to the existing system, they needed evidence that the replacement would improve their daily work—not merely solve problems identified by headquarters. ## Understanding Real Call-Center Needs - Requirements initially arrived indirectly through multiple departments, making their operational context difficult to understand. - The team reorganized requirements into: - Standard platform features - Features requiring customization or review - Features requiring new development - PM Kim Seri visited two call centers in Fukuoka, observed peak-hour operations, and interviewed agents and managers. - Field research revealed: - A manager-support chat feature was unnecessary because agents used hand signals instead. - Audio alerts were ineffective because office environments kept sound muted. - Integration with the existing CS system was essential because agents had to summarize and record every interaction after a chat. - These observations helped the team remove unnecessary features while raising the priority of workflows that were genuinely critical. ## Managing a Distributed Migration - The project involved teams in Korea and Japan, two Fukuoka call centers, external operators, and multiple internal departments. - To create a shared operating model, the PM: - Built a Jira dashboard to visualize progress and support data-driven decisions. - Created a master specification as a single source of truth. - Led internal product and development QA to ensure the original intent was implemented correctly. - Produced detailed operational guides for launch and adoption. - These processes reduced ambiguity across the project and supported a smoother transition from development to live operations. ## Focus Group Testing and Interviews - A focus group test (FGT) brought all stakeholders together to act as customers and CS agents. - Participants followed complete scenarios, from opening an inquiry through resolution. - The FGT exposed user-experience issues before formal QA, including: - Unclear role and status indicators - Android push-notification instability - Keyboard and input-field overlap - Missing timestamps on links - Push-title wording issues - Chat logs not consistently reaching the CS system - Several issues were fixed immediately, while clearer role and status displays were scheduled for further improvement. - Follow-up focus group interviews found the system generally stable and easy to operate, though some participants initially needed time to understand operator and manager roles. ## Balancing Agent Convenience with Privacy - Agents strongly valued the old “message being typed” preview because it helped them anticipate replies and reduce average handling time (AHT). - From a platform perspective, previewing unsent or deleted text was a serious information-ownership and privacy risk. - Rather than simply removing the feature, the team introduced a typing-status indicator. - This preserved agents’ awareness of the customer’s response rhythm without exposing the customer’s actual unfinished text. The project demonstrates that successful system internalization requires more than feature parity. Direct observation, structured stakeholder coordination, realistic user testing, and privacy-conscious design enabled Demaecan to reduce costs while improving both operational efficiency and customer experience.

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

Official Discord Integrations for Steal a Brainrot, Grow a Garden, Brookhaven RP, and more

Discord is launching native Social SDK integrations for Roblox games including *Steal a Brainrot*, *Grow a Garden*, *Brookhaven RP*, and others. The integrations improve community safety while enabling account linking, Rich Presence, and one-click game invites. Discord emphasizes that users retain control over data sharing, visibility, and account authorization. ## Integrated Community Safety - Developers can require players to link their Roblox account and authorize a specific game before joining an official Discord server. - This helps verify that participants actually play the associated Roblox game. - Server access and direct messaging can be limited to linked players, improving privacy and reducing unwanted interactions. - Developers can apply in-game moderation decisions to Discord bans, reducing manual moderation work. - *Grow a Garden* is highlighted as an example where verified-player access can support a safer competitive community. ## Account Linking and Player Control - Rich Presence and Game Invites work only after users connect their accounts and authorize the individual game. - Players choose whether to share their information and can revoke authorization at any time. - Rich Presence visibility can be managed through Discord’s **Settings → Activity Privacy → Activity Sharing** controls. - The SDK provides a native alternative to third-party Roblox–Discord account-linking tools. ## Rich Presence for Roblox Games - Roblox players previously appeared on Discord only as “Playing Roblox.” - With the integration, games such as *Brookhaven RP* can display richer activity details, including the game name, location, and current activity. - This gives friends more context and helps games become more discoverable across Discord. ## One-Click Game Invites - Discord users can see what friends are playing and join their sessions directly. - In *Grow a Garden*, players can invite friends to share, trade, and explore their farms without leaving Discord. - The feature simplifies coordinating group play through official game servers. ## Expansion Across the Roblox Ecosystem - Discord plans to extend its existing community-management tools to Roblox developers. - Roblox games often use Discord for event coordination, announcements, feedback, and player engagement. - The integrations support communities built around activities such as *Grow a Garden* events and *Steal a Brainrot*’s raid-and-defend gameplay. Developers adopting the SDK can provide safer, more trusted Discord communities while giving players optional social features and direct control over their account connections and activity sharing.

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

4 New Ways to Go From Idea to Product With AI Tools | Figma Blog

AI tools are reshaping product development by enabling teams to prototype, test, and refine ideas earlier and across both code and design. The article argues that working prototypes can expose problems that static mockups miss, while preserving design context throughout the path to production. It illustrates this shift through examples from FloQast, Merkle, Affirm, and Accor. ## AI-enabled product workflows - Product teams are: - Prototyping earlier instead of relying solely on traditional requirements documents. - Testing ideas in code before finalizing designs. - Exploring more possibilities at greater scale. - Carrying design-system context into implementation. - Figma presents these practices as ways to balance faster iteration with deliberate product decisions. ## Testing constraints in code AI coding tools make it easier for non-developers and product teams to build functional prototypes involving: - Multi-step workflows. - Conditional behavior based on user permissions or data. - Actions that trigger subsequent actions. - Realistic backend logic and data relationships. A prototype can then be moved into Figma with Codex to Figma for collaborative exploration and refinement. If implementation work continues in code, teams can move the design back through MCP while retaining the relevant design context. ## FloQast’s complex workflow prototype ### The challenge - FloQast needed to redesign an accounting workflow for investigating discrepancies. - Users previously had to move between multiple pages to: - Find an issue. - Investigate it. - Resolve it. - The team wanted one page where users could see tasks, identify blocked work, and take action. - Because the workflow depended on interconnected steps, real data, and business logic, a static mockup could not fully validate the concept. ### The unlock - UX manager Benjamin Ellis built a working prototype with an AI coding tool. - The prototype included: - A simulated backend. - Realistic data based on an actual customer’s workflows. - Clickable scenarios where completing one task affected the next. - Testing the workflow revealed interactions that appeared sound in a design mockup but failed when subjected to realistic conditions. ### The impact - The team and designer committed to a direction only after testing it against real scenarios. - They identified interaction problems earlier. - The approach reduced later surprises and increased confidence in the final design. ### When this approach is useful - When behavior depends on permissions, data, or sequential actions. - When a small fix is faster to make directly in code. - When designers and developers need a working example to scope a complex experience together. ## Exploring with AI on the canvas The next section introduces using AI directly in the Figma canvas to explore product possibilities. The provided excerpt ends before describing the specific workflow or company example. Teams should use code-backed prototypes when logic and real data are central to the experience, then bring those prototypes into collaborative design tools to refine decisions with greater confidence.

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

GitLab Patch Release: 19.0.1, 18.11.4, 18.10.7 | GitLab Docs

GitLab released patch versions 19.0.1, 18.11.4, and 18.10.7 on May 27, 2026, addressing multiple security vulnerabilities and bug fixes across CE and EE. The most serious issue, rated CVSS 8.2, affected Duo AI workflow identity resolution, while other fixes addressed authorization, data exposure, denial-of-service, and CI access issues. GitLab strongly recommends that self-managed installations upgrade immediately. ## Release Scope and Upgrade Guidance - Applies to GitLab Community Edition and Enterprise Edition. - GitLab.com is already patched; GitLab Dedicated customers do not need to act. - The releases include fixes for supported versions and should be applied as soon as possible. - GitLab publishes vulnerability details publicly 30 days after the release containing the fix. - Patch releases are generally issued on the second and fourth Wednesdays, with critical ad-hoc releases possible. ## Security Fixes - **CVE-2026-4868 — Duo AI workflow runners, EE** - CVSS 8.2. - Under certain conditions, an authenticated user could cause workflows to run under another user’s identity. - Affected versions were EE releases before 18.10.7, 18.11.4, and 19.0.1. - **CVE-2026-1402 — Wiki denial of service, CE/EE** - CVSS 6.5. - Insufficient validation could allow an authenticated user to trigger a denial-of-service condition. - **CVE-2026-6713 — GraphQL WorkItem API, CE/EE** - CVSS 5.3. - Incorrect authorization checks could allow unauthorized enumeration of private projects. - **CVE-2026-5296 — Duo Workflows API, EE** - CVSS 4.3. - Developer-level users could bypass restrictions on group-level foundational flows in certain configurations. - **CVE-2026-2601 — Operations, EE** - CVSS 4.3. - Developers could potentially access sensitive deployment data because of missing authorization checks. - **CVE-2026-8716 — Pipelines, CE/EE** - CVSS 4.3. - Incorrect name resolution could expose CI data from an unintended ref type. - **CVE-2026-2710 — Authentication endpoints, CE/EE** - CVSS 4.3. - Blocked project access tokens could continue accessing private resources in certain cases. ## Bug Fixes in 19.0.1 - Added write permissions for repositories in job-token fine-grained permissions. - Fixed broken trial calls to action on the self-managed GitLab Credits dashboard. - Updated API security remediation guidance. - Removed Helm-based release-environment QA coverage. - Backported final 19.0 release notes and related maintenance changes. ## Bug Fixes in 18.11.4 - Updated Ruby thread scheduler behavior and Zlib to version 3.2.3. - Upgraded GitLab Shell to 14.50.0 and Elasticsearch indexer to 5.14.7. - Fixed lost comments when moving wiki pages. - Improved subgroup provisioning, synchronization workers, pipeline cancellation, and build handling. - Corrected issues affecting swimlanes, epic boards, CI catalog filtering, and pipeline traces. - Improved advanced-search bulk indexing by using the primary database connection. - Added AI workflow scope support and endpoint handling for diagram proxies. - Included performance optimizations for license approval workflows. ## Recommended Action Administrators of affected self-managed GitLab installations should upgrade to 19.0.1, 18.11.4, or 18.10.7 immediately, using the appropriate deployment method such as Omnibus, source, or Helm.

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

A New Era of Innovation: Google Research at I/O 2026

Google’s I/O 2026 research announcements present AI as an “agentic” amplifier of human ingenuity, particularly in science and healthcare. New systems such as Gemini for Science, ERA, Co-Scientist, and Gemini Deep Think are designed to generate hypotheses, write and optimize code, evaluate evidence, and solve difficult research problems. Google also highlighted health-focused AI that supports users before, during, and after medical visits, while emphasizing collaboration, validation, and responsible deployment. ## AI-Driven Scientific Discovery - **Gemini for Science** is a suite of experimental tools built from Google Research and developed with Google Cloud, Google DeepMind, and Google Labs. - **Empirical Research Assistance (ERA)** acts as a code-optimizing research engine: - Proposes concepts and writes software. - Evaluates results against a defined scoring system. - Uses tree search to test thousands of code variants. - Has supported work in neuroscience, cosmology, respiratory-illness forecasting, and California runoff prediction. - **Co-Scientist** is a Gemini-based multi-agent collaborator that generates, evaluates, and refines hypotheses. - Researchers have applied it to antimicrobial resistance, plant immunity, and liver fibrosis. - **Computational Discovery**, combining ERA and AlphaEvolve, runs thousands of code variations in parallel to test scientific models and hypotheses more quickly. - **Hypothesis Generation** uses a multi-agent “idea tournament” to debate and rank research ideas, with clickable citations supporting claims. - **Literature Insights**, powered by NotebookLM, helps researchers synthesize large bodies of scientific literature. - **Science Skills** can automate specialist workflows such as structural bioinformatics and genomic analysis on agentic coding platforms. ## AI for Peer Review and Advanced Reasoning - Google is piloting the **Paper Assistant Tool (PAT)** for scientific peer review. - PAT has experimentally reviewed more than 10,000 papers for conferences including ICML, STOC, and NeurIPS. - Its feedback has helped authors identify theoretical gaps and design additional experiments. - **Gemini Deep Think** has been used with mathematicians, physicists, and computer scientists to address open problems involving network deadlocks, optimization, machine-learning behavior, auction theory, and cosmic-string singularities. ## Advancing Health with AI - Google’s health research focuses on supporting people throughout the full healthcare journey, from understanding symptoms and preparing for appointments to interpreting medical records. - Research contributions underpin the **Google Health app** and **Google Health Coach**, with the app beginning rollout to existing Fitbit users. - **Symptom AI** investigates how conversational AI can reason about information relevant to a person’s symptoms. - A Fitbit-based study included 13,917 participants. - In blind comparisons, clinicians preferred Symptom AI’s differential diagnoses roughly twice as often as those produced by other clinicians. - The **Plan for Care** pilot involved 1,779 participants preparing for doctor visits. - Compared with baseline systems, 15% more users felt prepared. - 13% more users felt confident they could make effective use of their appointment. - Google is also studying personal health large language models and the use of personal health record data to improve health guidance. Google’s announcements point toward research systems that actively experiment, collaborate, and reason rather than merely retrieve information. Their practical value will depend on continued scientific validation, clinician involvement, privacy protections, and careful expansion from experimental tools into real-world use.

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

Claude Opus 4.8 on GitLab: Complex agentic work, less disruption

Claude Opus 4.8 is now available in GitLab Duo Agent Platform for complex, multi-step coding and agentic workflows. The model is designed to follow instructions more precisely over extended autonomous runs, reducing the need for human correction and intervention. It also supports mid-conversation system-prompt updates without invalidating the prompt cache, making it better suited to changing contexts. ## Improved Long-Horizon Agentic Execution - Handles complex workflows involving multiple tools and extended sequences. - Provides more comprehensive planning and reasoning. - Produces more accurate end states with fewer interruptions or redirects. - Interprets instructions more precisely than previous models. - Supports professional tasks beyond coding, including: - Document drafting - Data analysis - Structured knowledge work ## Mid-Conversation System Prompts - System instructions can change during an active session. - Prompt-cache validity is preserved when context changes. - This is useful when: - Files change on disk - Token budgets shift - User context is updated - Asynchronous information arrives ## Availability and Pricing - Available through model selection in Agentic Chat and across GitLab Duo agent workflows. - Runs on GitLab Credits. - GitLab Premium and Ultimate subscribers can use included credits. - New users can access it through a GitLab Duo Agent Platform trial or the GitLab Free tier. Teams seeking more reliable autonomous coding and documentation workflows can use Opus 4.8 in GitLab Duo to reduce manual oversight while agents complete longer, more complex tasks.

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

Figma Make, Now on Your Local Code | Figma Blog

Figma is bringing Make beyond prototyping by connecting it directly to local production codebases. Designers can visually edit interfaces, use annotations and prompts for more complex behavior, and manage changes through Git workflows without leaving Figma. The broader goal is to make design and code a continuous, collaborative workflow rather than separate tools. ## Visual Editing in Production Code - Make connects to a local codebase and translates visual changes into code. - Users can select interface elements and modify: - Layouts - Colors - Fonts - Sizing - Other visual properties - Annotations let users describe interactions, animations, and other changes that go beyond simple property edits. - The feature is currently best suited to designers who already have access to their organization’s codebase. ## Git-Based Branching and Shipping - Make supports standard development workflows, including: - Creating branches - Reverting commits - Reviewing commit history - Creating pull requests - Changes remain in local commits until the team intentionally opens a pull request. - Engineering teams can review Make-generated changes like any other production contribution. ## Collaboration Between Design and Code - Local code changes can be shared as files and links with teammates who have access to the relevant branch. - Teammates can inspect changes, build on them, and compare versions through commit history. - Screens, pages, and components can be copied from Make into Figma Design as editable layers. - Changes made in Figma can be detected and brought back into Make, creating a round-trip workflow between the design canvas and codebase. ## Beta Availability - Direct editing, annotations, chat, and pull-request creation enter limited beta on May 28, 2026. - Beta access is limited to Figma’s Mac desktop beta app and requires joining a waitlist. - The features will not consume credits during beta; pricing for AI credits will be announced later. - Figma plans to expand availability to other platforms. Figma’s recommendation is effectively to use whichever environment best fits the current task—design canvas, code-based prototyping, or production code—while maintaining a shared workflow between them.

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

Agentic coding is only as good as its context

Coding agents are only as effective as the context they can access. Repository-only agents may produce compiling fixes, but they often miss issue requirements, CI rules, security policies, and review standards. Integrating agents with GitLab’s issues, merge requests, pipelines, and security controls produces better-aligned code, fewer review cycles, and safer releases while preserving human approval. ## From Repository Context to Full Lifecycle Context - GitLab tutorials demonstrate progressively richer workflows using Claude Code and Codex. - **Repository only:** The agent reads local files, interprets the prompt, and runs the build, but lacks acceptance criteria, organizational requirements, and review expectations. - **Repository plus issue:** Through GitLab’s MCP server, the agent can read issue descriptions, labels, milestones, and implementation notes. - It can correctly link changes to issues, such as adding `Closes #32`. - Tools such as `get_issue` and `create_merge_request` connect implementation work to planned work. - **Working inside the merge request:** GitLab’s Code Review Flow provides feedback, which the agent can address by adding tests, improving documentation, and fixing validation gaps. - New commits automatically trigger CI/CD. - Human reviewers can inspect the result in the same merge request. - The tutorials report fewer review rounds and shorter merge times. ## Why Platform Visibility Matters - Platform teams determine: - Which agents and tools are permitted - How agent output is verified - Where human approval is required - Important context lives in the DevSecOps platform: - Issues define requirements. - CI/CD configuration defines quality standards. - Review instructions establish coding conventions. - Security scanners enforce vulnerability policies. - Merge requests bring automation and human review together. - IDE- or terminal-based agents generally see only the files provided to them, while the platform sees the full lifecycle, including deployment targets and approval rules. - Consequently, the platform—not the agent alone—largely determines what can ship safely. ## Security Implications of Faster Code Generation - Agents produce code and remediation patches faster, increasing both the number of vulnerabilities and the number of security fix merge requests. - The bottleneck shifts from finding vulnerabilities to deciding which AI-generated fixes should be reviewed and approved first. - Effective prioritization requires broader context, including: - Application data flows - Deployment environments - Project-wide code - Organization-wide security policies - GitLab’s security layer can filter false positives, confirm vulnerabilities, and use surrounding repository context to propose fixes. - Agentic SAST vulnerability resolution creates a merge request with the proposed remediation. - CI/CD validates the change, while a human reviewer retains final approval. - Strong quality gates and security controls applied within merge requests reduce the chance that vulnerabilities reach production. ## Repository Instructions with `AGENTS.md` - The tutorials use `AGENTS.md` to provide project-specific instructions. - These files can describe: - Repository structure - Commands to run - Code-quality expectations - Files or areas that must not be changed - Language and framework conventions - CI image-pinning requirements - Concurrency patterns - Custom instructions help agents operate consistently with project standards, even before they receive broader platform context. Organizations should connect coding agents to the systems that define requirements, quality, security, and approval. Repository access may enable a working patch, but lifecycle context is what makes that patch trustworthy and ready to merge.

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

Iran's Internet is partially restored, Cloudflare Radar data shows

Cloudflare Radar data indicates that Iran’s Internet access began a partial restoration on May 26, after nearly three months of near-total shutdown following the February 28 military strikes. Traffic and DNS activity increased significantly, but remained far below normal levels, and the recovery could still be temporary. IPv6 connectivity remains effectively absent. ## Iran’s Two Internet Shutdowns - The first nationwide shutdown began on January 8, with traffic falling nearly to zero. - Limited connectivity briefly returned on January 21 and January 25 before recovering more substantially on January 27. - A second shutdown began on February 28 as military strikes escalated. - Traffic dropped to less than 1% of previous levels and stayed there for nearly three months. ## Signs of Partial Restoration - Around 11:00 UTC on May 26, Cloudflare observed sharp increases in traffic and DNS queries. - Transferred data briefly spiked at 11:45 UTC and then rose steadily from 12:00 UTC. - Traffic reached roughly 15 times the levels recorded during the previous week. - Activity followed expected daily patterns, declining around 21:00 UTC before rising again the following morning. - Increased DNS queries suggested that more users were successfully attempting to access websites and online services. ## Tehran and Major Providers Lead the Recovery - Tehran accounted for 91.6% of HTTP requests during the increase. - Other regions experienced only modest gains. - Traffic increased across several major providers, including: - TCI - IranCell - RighTel - MCCI ## Connectivity Remains Well Below Normal - Peak traffic on May 26 reached only about 40% of the maximum activity recorded in 2026 before the disruptions. - Future measurements will determine whether connectivity returns to pre-shutdown levels. - The January shutdown demonstrated that temporary restorations can quickly disappear. ## IPv6 Is Still Unavailable - Announced IPv6 address space from Iran remains effectively at zero. - IPv4 announcements have stayed relatively stable throughout both shutdowns. - This contrast suggests the disruptions were likely implemented through mechanisms such as application filtering or whitelisting rather than by withdrawing IPv4 routes from global networks. The data supports cautious optimism: Iranian users are regaining some Internet access, particularly in Tehran and through major providers, but service remains incomplete and potentially unstable. Continued monitoring is necessary to determine whether this is a lasting restoration.

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

Meet Our Newest AWS Heroes – May 2026 | Amazon Web Services

AWS has named four new Heroes for May 2026, recognizing leaders who advance cloud, AI, serverless, and community education. Their work ranges from building Amazon Bedrock-powered tools and contributing to AWS certifications to organizing major user groups and events across Europe and Latin America. Together, they demonstrate how technical expertise and community leadership can help more builders adopt AWS. ## Damiano Giorgi — Pavia, Italy - An Artificial Intelligence Hero and Cloud Solutions Architect specializing in AI. - Helps organize AWS User Groups in Pavia and Milan. - Created the “Unofficial post:Invent Session Suggester,” using Amazon Bedrock and Amazon Nova to recommend re:Invent sessions. - Shares knowledge through his “Bass and Bytes” blog and conferences across Europe. ## Darryl Ruggles — Ottawa, Canada - A Serverless Hero and Cloud Solutions Architect with a background in software development. - Focuses on AWS application architecture, AI/ML, serverless, containers, and FinOps. - Publishes blog posts, LinkedIn content, and open projects. - Participates actively in online communities such as “Believe In Serverless” and in-person AWS events. ## Ricardo Daniel Ceci — Buenos Aires, Argentina - An Artificial Intelligence Hero leading the AWS User Group Buenos Aires, with nearly 2,400 members. - Principal organizer of AWS Community Day Argentina. - Named AWS Community Leader of the Year 2025 for Latin America. - Hosts a podcast with cloud experts, AWS Heroes, and developer advocates. - Works to make cloud and AI more accessible to Spanish-speaking builders across LATAM. ## Matias Kreder — Buenos Aires, Argentina - An Artificial Intelligence Hero and AWS Certification Subject Matter Expert. - Contributed to AI/ML certifications, including the AWS Certified AI Practitioner exam. - Began his community involvement through AWS DeepRacer, qualifying as a finalist three times. - Organizes racing events, ML talks, and AWS community activities across Latin America. - Helped organize AWS Community Day Argentina 2025 and speaks at regional events. These new Heroes illustrate the value of combining AWS expertise with mentorship, content creation, certification work, and community organizing. Builders can learn more or connect with regional leaders through the AWS Heroes program.

Read original(opens in new tab)