techlist.io
KREN

Techlist.io - Korean Tech Blog Curator

figma2 min readCurated summary

How to Supercharge your Design System with Slots | Figma Blog

Slots let designers customize components without detaching them from a design system. By allowing content to be inserted into stable structures—much like components work in code—slots reduce variant sprawl, preserve consistency, and improve design-to-development handoff. Figma recommends starting with high-traffic components and using default content strategically to balance guidance with flexibility. ## Why Slots Matter - Growing design systems often become restrictive, leading teams to: - Create excessive variants - Expand component libraries - Detach instances - Develop workarounds outside the system - Slots allow designers to change content while preserving a component’s underlying structure. - The approach mirrors code-based composition, where developers inject dynamic content into predictable layouts. - Benefits include: - **Design system managers:** fewer variants and less maintenance - **Designers:** more freedom within the system - **Developers:** structures that map more predictably to production - **Automation and AI:** clearer, more interpretable component structures - Figma introduced slots at Schema 2025 and made them available in open beta. ## Start with High-Use Components The greatest immediate value comes from components that teams frequently detach or customize. - Prioritize components that: - Appear often across screens - Are duplicated throughout the system - Have accumulated many variants - Support frequently changing content - Common starting points include: - Dialogs and modals - Menus and lists - Cards and panels - Slots are especially useful when the structure stays stable but the content varies. - Repeating elements such as menu items or list rows no longer require numerous hidden layers for every possible item count. - Designers can add only the items they need while keeping the component connected. - For configuration-heavy components like cards and modals, slots can replace combinations of properties and variants for titles, descriptions, media, and buttons. ## Use Pre-filled and Empty Slots Deliberately Slots can either contain default content or remain empty, depending on the intended workflow. - **Pre-filled slots:** - Provide context and demonstrate expected usage. - Reduce unnecessary work when content is usually predictable. - Are useful for persistent elements, such as an icon in the top-right corner of a card. - **Empty slots:** - Clearly signal that the designer must add content. - Work well when customization is required. - Resemble existing instance-swap patterns used in many design systems. - Authors should choose between the two based on whether content is optional, predictable, or required. Figma’s practical recommendation is to introduce slots where teams already experience the most friction, then use defaults and empty placeholders intentionally to guide customization without sacrificing flexibility.

Read original(opens in new tab)
FigmaDesign SystemsUser InterfaceDesign To Development+1
aws3 min readCurated summary

Introducing OpenClaw on Amazon Lightsail to run your autonomous private AI agents | Amazon Web Services

Amazon Lightsail now offers a preconfigured OpenClaw instance for running a private, autonomous AI assistant without managing a complex installation. The setup uses Amazon Bedrock by default and supports browser access plus messaging integrations such as WhatsApp, Discord, and Telegram. AWS aims to simplify deployment while addressing the security concerns of running an agent that can access email, files, and the web. ## Launching OpenClaw on Lightsail - In the Lightsail console, create a new instance. - Select: - A preferred AWS Region and Availability Zone - Linux/Unix as the platform - OpenClaw as the blueprint - A 4 GB memory plan is recommended for performance. - The instance typically reaches a running state within minutes. ## Pairing the Browser - Use **Connect using SSH** from the Lightsail Getting Started tab. - Copy the dashboard URL and security credentials shown in the SSH welcome message. - Open the dashboard and enter the access token in the **Gateway Token** field. - Approve the pairing from the terminal by entering `y`, then `a`. - Once pairing succeeds, the dashboard displays an **OK** status. ## Enabling Amazon Bedrock - OpenClaw is preconfigured to use Amazon Bedrock as its AI provider. - Copy the setup script from the Getting Started tab. - Run it in AWS CloudShell to enable Bedrock API access. - After completion, use the **Chat** section of the dashboard to interact with the assistant. ## Messaging Integrations OpenClaw can connect to services such as Telegram and WhatsApp, allowing users to interact with the assistant from a phone or messaging client. It can perform tasks including email management, web browsing, and file organization. ## Permissions and Costs - The setup script creates an IAM role with permissions to access Bedrock. - IAM policies can be customized, but removing required permissions may stop the assistant from generating responses. - Lightsail charges are based on the selected instance plan’s on-demand hourly rate. - Bedrock usage is billed according to tokens processed. - Third-party models offered through AWS Marketplace may add software charges. ## Security Considerations - Do not expose the OpenClaw gateway directly to the public internet. - Treat the gateway authentication token like a password. - Rotate the token regularly. - Store credentials in environment files rather than hardcoding them in configuration. - Review OpenClaw’s gateway security guidance before granting the agent access to sensitive systems. OpenClaw on Lightsail is available in all commercial AWS Regions where Lightsail operates. It provides a convenient deployment path, but users should carefully control IAM permissions, monitor costs, and secure the gateway before connecting personal data or messaging accounts.

Read original(opens in new tab)
Amazon BedrockAi AssistantAws IamSsh+2
cloudflare3 min readCurated summary

Always-on detections: eliminating the WAF “log versus block” trade-off

Traditional WAFs force teams to choose between broad visibility in logging mode and active protection in blocking mode. Cloudflare’s new always-on detection model separates attack detection from mitigation, allowing every signature to inspect traffic and provide metadata without immediately blocking requests. Attack Signature Detection is available in Early Access, while Full-Transaction Detection is planned to improve accuracy by analyzing both requests and responses. ## The Always-On Framework - Detection signatures run on every proxied request for opted-in customers. - Results appear in Security Analytics and are added to request metadata usable by custom security rules. - Detection is separated from mitigation: - Signatures identify suspicious traffic. - Security rules decide whether to block, challenge, or otherwise handle it. - This preserves visibility into all matching signatures, even when one detection leads to a mitigation action. - Initially, detections can run after the request is sent to the origin, avoiding added latency. - Once a blocking rule depends on a detection, that detection runs inline and may add latency based on the application’s traffic profile. - Bot Score and Attack Score already use this detection model. ## Attack Signature Detection - The system uses the same analytical heuristics as Cloudflare Managed Rules but does not directly apply traffic actions. - It covers attack types such as: - SQL injection - Cross-site scripting - Remote code execution - Specific CVEs - Cloudflare’s Managed Ruleset contains more than 700 active rules, with new rules generally released weekly and emergency rules released for major vulnerabilities. - Each signature has: - A unique Ref ID - One confidence level - One or more attack categories - Confidence levels indicate expected false-positive risk: - **High:** Designed for high true-positive rates and low false positives; comparable to default Managed Rules behavior. - **Medium:** More likely to cause application-specific false positives and should be assessed before blocking. ## Detection Metadata Attack Signature Detection exposes three fields in Security Analytics and the Edge Rules Engine: - `cf.waf.signature.request.confidence` - An array of confidence values for matching signatures. - `cf.waf.signature.request.categories` - An array of matched attack categories, such as SQLi or XSS. - `cf.waf.signature.request.ref` - An array of up to 10 matching signature Ref IDs. These fields let teams create precise policies based on observed traffic rather than relying on broad, manually tuned rules. ## Using Security Analytics for Onboarding - Detection begins collecting data as soon as an application is proxied through Cloudflare. - Teams can review aggregate matches by signature and attack category. - Analysts can compare matches against request outcomes, including: - Blocked requests - Cached responses - Requests delivered to the origin - If malicious traffic reaches the origin, teams can quickly create appropriate security rules. - Analytics also helps identify false positives and determine where exceptions are needed. ## Full-Transaction Detection - The planned system will analyze the complete HTTP transaction, including both request and response. - Correlating both sides should reduce false positives compared with request-only engines. - It may detect threats that request analysis misses, including: - Reflective SQL injection - Subtle data-exfiltration behavior - Dangerous misconfigurations visible only in responses The practical recommendation is to enable Attack Signature Detection during application onboarding, use its metadata and analytics to understand real traffic, and then create targeted mitigation rules. This preserves continuous visibility while allowing teams to deploy blocking protections with greater confidence.

Read original(opens in new tab)
Web Application FirewallCross Site ScriptingSql InjectionSecurity Analytics+4
cloudflare2 min readCurated summary

Mind the gap: new tools for continuous enforcement from boot to login

Cloudflare introduces two tools to enforce security continuously from device boot through application access: mandatory authentication and independent MFA. Mandatory authentication prevents unauthenticated devices from accessing the Internet, while Cloudflare MFA adds a second trust authority beyond the identity provider. Together, they reduce visibility gaps and limit the impact of compromised credentials. ## Closing the Authentication Gap - Cloudflare One Client provides policy enforcement and traffic inspection, but historically left devices exposed before a user authenticated or after a session expired. - In these “unknown device” states, users could potentially bypass controls using local machine connectivity. - Mandatory authentication, configured through MDM, makes the client enforce access from system boot: - Blocks Internet traffic using the system firewall. - Permits only the client’s authentication flow through a process-specific exception. - Prompts users to authenticate directly. - The feature will initially support Windows, with other platforms planned. ## Independent MFA at the Network Edge - SSO providers such as Okta, Entra ID, and Google are valuable security anchors but also high-value targets. - If an attacker hijacks an SSO session, they may gain access to every connected application. - Cloudflare MFA provides an independent, network-edge “step-up” factor, requiring attackers to overcome a second authority even if the primary IdP is compromised. - Supported methods include: - Biometrics such as Windows Hello, Touch ID, and Face ID. - WebAuthn, FIDO2, and PIV security keys. - TOTP authenticator applications. ## Granular Policy Enforcement - Administrators can require MFA globally, per application, or within specific access policies. - Organizations can match authentication strength to resource sensitivity—for example, weaker methods for chat and security keys for source-code repositories. - Strong MFA can be imposed on contractors using personal identities or social logins. - Legacy applications can receive modern MFA protection without code changes. - Cloudflare’s independent MFA is currently in closed beta. ## Reducing Attack Impact - Requiring authentication before Internet access ensures managed devices remain registered and visible. - Independent MFA reduces the blast radius of stolen passwords or compromised SSO sessions. - Cloudflare positions these capabilities as part of a broader move toward continuous, automated security posture enforcement. Organizations using Cloudflare One should consider mandatory authentication for managed endpoints and independent, risk-based MFA for sensitive applications.

Read original(opens in new tab)
CloudflareZero TrustNetwork SecurityMulti Factor Authentication+3
cloudflare3 min readCurated summary

Defeating the deepfake: stopping laptop farms and insider threats

Trust is becoming a critical security weakness as attackers use stolen identities, AI-generated deepfakes, and laptop farms to impersonate remote workers. Traditional zero trust controls verify devices and credentials but often fail to verify the actual person behind them. Cloudflare’s partnership with Nametag adds identity verification during onboarding and risk-based controls afterward, aiming to prevent fraudulent workers from accessing corporate systems. ## The Rise of Remote Worker Fraud - Organized groups, including North Korean operations, use “laptop farms” to infiltrate companies. - Devices are shipped to domestic addresses, physically connected to KVM switches, and remotely operated by fraudulent workers. - Attackers use stolen identities, generative AI for interviews, and deepfake tools to create convincing government IDs and selfies. - Valid credentials and corporate-issued devices can make these users appear legitimate to standard zero trust systems. ## Why Traditional Insider Threat Defenses Fall Short - DLP and UEBA tools typically detect suspicious behavior only after an attacker has gained access. - Conventional onboarding often trusts: - The identity provided by a new hire - The shipping address receiving the laptop - Credentials sent to a personal email address - Zero trust policies commonly verify device posture, location, and account permissions—but not whether the person is genuinely the employee. ## Identity-Verified Zero Trust - Cloudflare Access is adding Nametag’s workforce identity verification to its existing policy checks. - Nametag verifies that the person receiving, configuring, and using a device is: - A real person - The legitimate person named in the identity documents - The authorized employee - Verification occurs before access to email, code repositories, or other internal resources is granted. ## How the Nametag Integration Works - Nametag integrates with Cloudflare Access through OpenID Connect (OIDC). - It can operate as the primary identity provider or as an additional evaluation factor alongside Okta or Microsoft Entra ID. - A typical onboarding flow includes: - The user attempts to access an onboarding portal. - Cloudflare redirects them to Nametag. - The user provides a work email, takes a selfie, and scans a government-issued ID. - Nametag’s Deepfake Defense technology uses cryptography, biometrics, and AI to detect fake identities, injection attacks, and presentation attacks such as printed photos. - A successful verification returns an ID token to Cloudflare, which applies its Access policies. - The process reportedly takes less than 30 seconds, and biometrics are not retained afterward. ## Layered Insider Threat Protection - Identity verification complements Cloudflare’s existing controls: - API-driven DLP for detecting data exfiltration - Remote Browser Isolation for reducing browsing risks - Shadow IT reporting and CASB capabilities for identifying unmanaged services and misconfigurations - Together, these controls distinguish between knowing which account is connecting and knowing who is actually behind the keyboard. ## Continuous Verification - Initial identity checks are not sufficient because legitimate credentials can later be sold or compromised. - Cloudflare Access uses user risk scores to support context-aware policies. - A sudden increase in risk can trigger access revocation for one or multiple applications. Organizations facing remote hiring and insider-threat risks should supplement device and credential verification with strong identity assurance at onboarding, followed by continuous, risk-based monitoring.

Read original(opens in new tab)
AICloudflareZero TrustData Loss Prevention+4
cloudflare2 min readCurated summary

Stop reacting to breaches and start preventing them with User Risk Scoring

Cloudflare is adding User Risk Scores to Cloudflare One so access decisions can reflect a user’s recent behavior, not just identity and device posture. The system continuously combines security signals, assigns a deterministic risk level, and applies adaptive access policies in real time. This is intended to replace slow, manual incident response with continuous, automated protection. ## Continuous User Risk Scoring - Risk scores identify behaviors associated with compromised accounts or insider threats, including: - Impossible travel - Failed login attempts - Malware detections - Risky browsing - Data loss prevention (DLP) violations - Outdated or insecure devices - Cloudflare Access and Gateway provide internal telemetry such as login activity, location, malware events, and sensitive-data triggers. - Integrations with CrowdStrike and SentinelOne add third-party device and security signals. - Administrators choose which behaviors to monitor and assign each a low, medium, or high risk level. - A user’s score is based on the highest-risk enabled behavior detected during the relevant period. - Investigators can manually reset a score after reviewing an incident while retaining its historical record. ## Adaptive Access Policies - User Risk Score is now available as a condition in Cloudflare Access policies. - Organizations can create global or application-specific controls, such as: - Blocking high-risk users from financial applications - Requiring medium-risk users to authenticate with a physical security key - Automated enforcement reduces the delay involved in revoking sessions or changing identity-provider groups manually. - Policies can limit damage while allowing lower-risk users to continue working. ## Dynamic Enforcement and Integrations - Access can be revoked during an active session when a user’s risk increases. - Access is automatically restored when the score falls after investigation and clearance. - Cloudflare plans to explore enforcing step-up MFA during active sessions when risk changes. - Through the Shared Signals Framework, Cloudflare can send risk information to Okta so users restricted on the network are also restricted at the SSO entry point. Cloudflare recommends using User Risk Scores to make zero trust access continuously adaptive rather than evaluating users only at login. Existing customers can configure the feature in the Cloudflare One dashboard, while larger organizations can integrate partner telemetry through a ZTNA pilot.

Read original(opens in new tab)
Zero TrustSaseCloudflare OneIdentity Provider+4
cloudflare2 min readCurated summary

Moving from license plates to badges: the Gateway Authorization Proxy

Cloudflare’s Gateway Authorization Proxy extends identity-based traffic protection to devices where the Cloudflare One Client cannot be installed. It replaces IP-based identification with browser-based authentication, allowing organizations to apply user-specific policies and maintain visibility across unmanaged endpoints. The solution is especially suited to VDI, acquisitions, and regulated environments, while the One Client remains preferable for fully managed devices. ## Limitations of IP-Based Proxy Access - Earlier proxy endpoints identified users through static IP addresses. - This resulted in: - Logs that showed locations rather than individual users. - Policies breaking when users changed networks. - Manual maintenance of self-hosted Proxy Auto-Configuration (PAC) files. ## Gateway Authorization Proxy - The proxy authenticates users through a Cloudflare Access-style login before applying Gateway filtering. - Organizations can: - Attribute proxy traffic and logs to specific users. - Create granular rules, such as restricting accounting tools to the Finance team. - Offer one or multiple identity providers, including Okta and Azure AD. - Use a familiar per-user seat-based billing model. ## Cookie-Based Identity Tracking - The proxy uses signed JWT cookies to associate a user with requests. - On the first visit to a domain: - The proxy checks for a domain-specific identity cookie. - If none exists, it redirects the user to Cloudflare Access. - Existing Access sessions can issue a domain-specific token immediately. - Otherwise, the user authenticates through the configured identity provider. - Once established, the cookie authorizes later requests to that domain and its subdomains without further redirects. - Cloudflare’s edge network makes the authentication flow effectively invisible to users. - Access can be revoked quickly without installing software on the endpoint. ## Cloud-Hosted PAC Files - Cloudflare now hosts PAC files, removing the need for customers to operate their own hosting. - Starter templates simplify initial configuration. - Cloudflare’s AI assistant, Cloudy, can summarize PAC file behavior so administrators do not need to inspect the code manually. ## Best-Fit Use Cases - **Virtual desktop infrastructure:** Browser traffic from managed or shared virtual machines. - **Mergers and acquisitions:** Rapidly bringing users from different organizations under common security policies. - **Compliance-constrained environments:** Devices where endpoint software installation is prohibited. - The Cloudflare One Client is still recommended when deeper device control and the best user experience are possible. The Gateway Authorization Proxy is a practical alternative for securing unmanaged devices: use the One Client for fully managed endpoints, and browser-based authorization when identity and policy enforcement must happen without endpoint installation.

Read original(opens in new tab)
CloudflareJwtIdentity ManagementProxy Configuration+3
gitlab2 min readCurated summary

10 AI prompts to speed your team’s software delivery

AI-assisted coding can accelerate code production without accelerating delivery, because review, security, documentation, and planning often become the new bottlenecks. The post recommends applying AI across the full software lifecycle, using targeted prompts to reduce routine work and let teams focus on architecture, risk, and business decisions. ## Code Review as an Accelerator - AI can review merge requests (MRs) for: - Logical errors, edge cases, and potential bugs. - API changes, altered return types, schema modifications, and configuration changes that may break consumers. - Catching these issues before human review reduces repeated review cycles and helps prevent deployment-time rollbacks. ## Shifting Security Left - Security scan analysis can use AI to: - Distinguish real vulnerabilities from false positives. - Explain risks and recommend remediation. - Prioritize findings by severity and exploitability. - AI-assisted code reviews can identify injection flaws, authorization problems, data exposure, insecure dependencies, and cryptographic weaknesses before an MR is created. - This reduces security-team backlogs and limits late-stage developer/security rework. ## Keeping Documentation Current - AI can generate release notes from merged MRs, organizing changes into features, fixes, performance improvements, breaking changes, and deprecations. - It can also identify which README files, API references, architecture diagrams, and onboarding guides need updates after code changes. - Automating these checks helps prevent documentation drift without creating a separate manual task. ## Breaking Down Complex Planning - An AI planning prompt can decompose an epic into implementable issues by considering: - Technical dependencies. - Appropriate issue sizes. - Acceptance criteria. - Implementation order. - The goal is to replace lengthy planning meetings with an initial AI-generated breakdown followed by team review. The practical recommendation is to treat AI as a team workflow accelerator, not merely a code generator. Applying focused prompts to review, security, documentation, and planning can help prevent increased coding speed from creating larger downstream bottlenecks.

Read original(opens in new tab)
Database DesignMachine LearningPostgreSQLCode Review+4
discord2 min readCurated summary

Tracing Discord's Elixir Systems (Without Melting Everything)

Discord runs each guild independently using Elixir’s concurrency model, helping chats and reactions feel instantaneous at scale. When a guild becomes overloaded, metrics and logs can reveal activity spikes but often fail to show the actual user experience or downstream effects. To fill this gap, Discord built distributed tracing for its Elixir services and integrated it without downtime. ## Guild-Level Isolation and Outages - Each Discord server, or “guild,” runs independently from others. - This isolation supports high concurrency and limits failures to individual guilds. - A guild may become laggy or go offline when user activity exceeds its processing capacity. - If it cannot recover automatically, on-call engineers investigate the incident. ## Limits of Metrics and Logs - Engineers inspect metrics showing: - How often each user action type is processed. - How long processing takes. - These metrics can identify bursts of activity, such as sudden waves of reactions or messages. - However, they do not clearly show how those conditions affected users. - Metrics are comparable to a car dashboard: they expose internal conditions but not necessarily the consequences. ## Guild Timings - Discord’s custom “guild timings” tool records the amount of each minute spent processing different action types. - The data is stored in memory and provides more detail than standard metrics. - Its high volume makes long-term storage impractical, so data is frequently rotated. - The tool also focuses on guild-local processing and does not capture downstream effects or complete end-to-end request experience. ## Building Distributed Tracing for Elixir - Distributed tracing shows how long each part of an operation takes across services. - Other Discord teams had already benefited from tracing and application performance monitoring. - Typical tracing systems propagate operation context through metadata such as HTTP headers. - Elixir’s built-in communication mechanisms do not provide an equivalent metadata layer. - Discord therefore built its own mechanism for propagating tracing information between services. ## Deployment Without Downtime - Although the tracing system changed how Discord services communicate, it was integrated without taking the platform offline. - The result gives engineers a more complete view of request paths, helping them understand both the source of guild problems and their impact on users. Discord’s experience suggests that detailed distributed tracing is essential when local metrics and logs cannot explain end-to-end behavior. For highly concurrent systems, investing in tracing infrastructure tailored to the platform can significantly improve incident diagnosis without requiring disruptive deployment changes.

Read original(opens in new tab)
Database DesignApplication Performance MonitoringDistributed TracingElixir+3
gitlab4 min readCurated summary

How GitLab built a security control framework from scratch

GitLab created its own security control framework after finding that existing frameworks were too broad, rigid, or insufficiently granular for its multi-product, cloud-native environment. The GitLab Control Framework (GCF) combines industry best practices with product-specific implementations and extensive operational metadata. This lets GitLab manage multiple certifications and internal risks through one scalable framework rather than maintaining separate frameworks for each product. ## Why Existing Frameworks Were Insufficient - GitLab initially used the Secure Controls Framework, then adopted NIST SP 800-53 in preparation for FedRAMP. - NIST’s more than 1,000 controls were comprehensive but included requirements that did not apply to GitLab. - Broad controls often combined several distinct activities: - NIST AC-2, “Account Management,” covers account creation, modification, disabling, termination, shared accounts, and monitoring. - GitLab treated these as separate controls because they have different owners, risks, testing methods, and evidence requirements. - Repeatedly customizing NIST controls effectively meant GitLab was building its own framework, leading to the decision to formalize one. ## Establishing the GitLab Control Framework GitLab developed the GCF through five major steps: ### Assessing Requirements - The team mapped requirements from existing and planned certifications, including: - SOC 2 Type II - ISO 27001, ISO 27017, ISO 27018, and ISO 42001 - PCI DSS - TISAX - Cyber Essentials - FedRAMP - Internal requirements covered mission-critical systems outside certification scopes and systems handling sensitive data. - This analysis established the minimum controls GitLab needed to meet compliance and risk-management obligations. ### Learning from Industry Frameworks - GitLab compared its requirements with: - NIST SP 800-53 - NIST Cybersecurity Framework - Secure Controls Framework - Adobe and Cisco Common Controls Framework - The goal was to reuse proven structures and ensure important security domains and practices were not omitted. ### Creating Custom Domains - The team organized the framework into 18 custom control domains. - Each domain groups related controls according to how GitLab’s security program is managed. - The structure supports adding, changing, or retiring controls as the business evolves. ## Separating Framework Requirements from Implementations GitLab operates several products with different infrastructure and compliance scopes: - GitLab.com is a multi-tenant SaaS platform hosted on GCP. - GitLab Dedicated is single-tenant SaaS hosted on AWS. - GitLab Dedicated for Government is a FedRAMP offering hosted on AWS. To avoid duplicating the framework, the GCF uses two control levels: - **Level 1:** Defines what must be implemented at the organizational framework level. - **Level 2:** Describes how each product fulfills the requirement. - Entity-level controls apply across the organization and are inherited by all product offerings. - This model supports product-specific audits while preserving a single source of control requirements. ## Adding Operational Metadata Rather than tracking only a control ID, description, and owner, the GCF records detailed context for each control: - Responsible owner and risk accountability - Applicable environment or product - Covered assets and systems - Performance or testing frequency - Manual, semi-automated, or automated nature - External certification or internal-risk classification - Testing procedures and required evidence This turns the framework into an operational control inventory. Teams can filter it to identify controls for a particular audit, determine ownership, or find manual controls that may be candidates for automation. ## Designing for Growth - The GCF is intended to evolve with GitLab’s products, risks, and certification goals. - Its structured metadata helps GitLab assess scope and identify gaps when pursuing additional certifications such as ISMAP, IRAP, or C5. - The framework’s modular design makes it easier to extend compliance coverage without creating entirely new control systems. GitLab’s experience suggests that organizations should consider a custom framework when standard frameworks require extensive modification. The most effective approach is to retain useful industry guidance while tailoring control granularity, product implementations, ownership, testing, and metadata to the organization’s actual operating environment.

Read original(opens in new tab)
Database DesignGitlabCloud NativeSecurity Compliance+4
datadog3 min readCurated summary

Designing MCP tools for agents: Lessons from building Datadog's MCP server

Datadog’s initial MCP server simply exposed existing APIs, but real-world agent use revealed major problems with context limits, inaccurate trend analysis, and tool overload. The team redesigned its tools around token efficiency, query-based analysis, and a smaller, more deliberate tool surface. These changes improved both answer quality and cost, though emerging agent features may eventually reduce the need for some optimizations. ## Context Efficiency Matters - Observability results can be extremely large: a log record may range from roughly 100 characters to 1 MB. - CSV or TSV is more token-efficient than JSON for tabular data, often using about half as many tokens per record. - YAML can reduce token usage for nested data by around 20% compared with JSON. - Removing rarely used fields from default responses, while allowing agents to request them when needed, further reduces output size. - Combined formatting and field-trimming improvements allowed some tools to return approximately five times more records within the same token budget. - Pagination by record count is unreliable when records vary greatly in size. Datadog instead paginates by token budget and returns a cursor when the limit is reached. - Tools such as Cursor and Claude Code increasingly write long results to disk, which could make response-format efficiency less important in the future. ## Let Agents Query Data - Retrieval-only tools forced agents to infer trends from incomplete samples, such as guessing which services generated the most errors. - Agents sometimes repeatedly fetched logs to compensate, wasting tokens and producing unreliable answers. - SQL lets agents aggregate and filter data directly: ```sql SELECT service, COUNT(*) AS error_count FROM logs WHERE status = 'error' GROUP BY service ORDER BY error_count DESC LIMIT 10 ``` - Agents can select only necessary fields, limit row counts, and calculate aggregates without loading raw data. - SQL improved correctness and reduced costs; some evaluation scenarios became about 40% cheaper. - Supporting SQL at Datadog’s scale required significant infrastructure work because traditional relational databases were insufficient. ## Tools Are Not Free - Exposing every API endpoint as a separate tool increases tool-selection errors and consumes context through tool descriptions. - Flexible tools can support multiple related workflows through carefully designed schemas, reducing the total tool count. - Toolsets provide a core collection by default while allowing users to opt into specialized capabilities, though users must anticipate their needs. - Layered tools can first explain how to accomplish a task and then execute it, keeping specialized functionality out of the initial context. - Layering introduces additional tool calls and therefore increases latency. - Improving agent context management, including tool search and dynamically loaded skills, may reduce the need for aggressive tool minimization over time. The practical recommendation is to design MCP tools for how agents actually reason: minimize and control output size, provide query and aggregation capabilities instead of raw retrieval alone, and expose a focused set of flexible tools rather than mirroring every API endpoint.

Read original(opens in new tab)
Database DesignDatadogObservabilityAPI Design+4
figma2 min readCurated summary

3 Ways Teams Are Building Conviction Faster With Figma Make | Figma Blog

Product teams are using Figma Make to turn abstract product ideas into interactive prototypes earlier in the process. By making concepts tangible, PMs can align designers and engineers, test assumptions, collect feedback, and build conviction before significant development begins. The article highlights examples from ServiceNow, Ticketmaster, and Affirm. ## Prototyping Instead of Relying Only on PRDs - Product managers traditionally translate customer needs, design goals, and engineering constraints into shared decisions. - Figma Make lets them create prototypes that demonstrate both a product’s appearance and behavior. - Interactive prototypes provide more useful early feedback than static mockups or abstract explanations. - Teams can identify problems, test ideas with users, and adjust direction before implementation progresses too far. - Earlier visibility helps teams make better-informed decisions and build products that more closely meet user needs. ## Bringing Complex Product Thinking Into Shared Focus - At ServiceNow, Product Director Ram Devanathan works with a design team serving multiple product groups, making dedicated design support difficult to obtain. - He needed to redesign a configuration page containing 15–20 settings, including technical options affecting incident prioritization and system load. - The initial mockup was functional but did not fully communicate the desired hierarchy, guidance, or tone. - Ram used Figma Make to transform the mockup into a clearer prototype: - Settings were grouped logically. - Simpler options appeared first. - Tooltips explained individual settings. - A warning clarified that changes required restarting the service. - The prototype gave Ram and the designer a shared, concrete representation of the intended experience. - Figma Make templates can also embed design systems and UX patterns, allowing PMs to iterate consistently without requiring designers for every early exploration. - Ram found that showing the idea directly was much more effective than describing it abstractly, helping the team reach agreement faster. ## Validating Features Before Building - The article next introduces Ticketmaster’s use of Figma Make for validating new features before development. - Ticketmaster applies prototypes to situations involving high-demand concert ticket purchases and internal dashboards for monitoring sales and troubleshooting issues. - The provided excerpt ends before explaining the specific feature-validation process or the third approach involving Affirm. Figma Make is presented less as a replacement for design or engineering and more as an early collaboration and validation tool. Product teams can use it to communicate complex behavior, explore alternatives, and secure alignment before committing substantial resources.

Read original(opens in new tab)
AIDesign SystemsUser ExperiencePrototyping+3
google3 min readCurated summary

Teaching LLMs to reason like Bayesians

LLMs often struggle to update their beliefs as new evidence arrives, relying instead on simplistic heuristics. Google Research tested whether training models to imitate an optimal Bayesian assistant could improve this capability. The results show that Bayesian teaching substantially improves recommendation accuracy, adaptation across interactions, and generalization to other tasks—more effectively than training on always-correct answers. ## Testing Bayesian Reasoning in LLMs - Researchers created a five-round flight recommendation task involving three options with different: - Departure times - Flight durations - Number of stops - Costs - Simulated users had hidden preferences, such as strong, weak, or no preference for high or low values of each feature. - After every recommendation, the user revealed the correct choice, giving the assistant new evidence. - The benchmark compared: - Off-the-shelf LLMs - Human participants - An optimal Bayesian assistant - The Bayesian assistant maintained a probability distribution over possible user preferences and updated it using Bayes’ rule. - Most LLMs performed substantially worse and often stopped improving after the first interaction, showing limited ability to incorporate information over time. - Humans improved more than most LLMs but still failed to match the Bayesian assistant. ## Bayesian Teaching Framework - Bayesian reasoning requires an agent to: - Start with a prior belief about the world - Incorporate new evidence - Produce a posterior belief - Use that posterior as the prior for future reasoning - For LLMs, the “world state” includes facts, relationships, concepts, and inferred user preferences. - Researchers used supervised fine-tuning on many simulated user interactions to teach models this update process. ## Oracle Teaching vs. Bayesian Teaching - **Oracle teaching** trained models on interactions with an assistant that knew the user’s preferences perfectly and always selected the correct option. - **Bayesian teaching** trained models to imitate an assistant that estimated preferences probabilistically and sometimes made mistakes, especially during early uncertain rounds. - The researchers argued that Bayesian examples better preserve uncertainty and demonstrate how beliefs should change as evidence accumulates. - This approach resembles knowledge distillation: the LLM learns to reproduce the predictions of a more principled teacher rather than memorizing only correct outcomes. ## Results and Generalization - Both fine-tuning strategies improved performance compared with the original LLMs. - Bayesian teaching consistently outperformed oracle teaching. - Models trained on Bayesian predictions more often agreed with the optimal Bayesian assistant. - Improvements extended beyond the original flight recommendation task, suggesting the models learned a broader approximation of probabilistic reasoning rather than merely memorizing task-specific patterns. - The findings indicate that LLMs can acquire reasoning strategies from examples and apply them in new domains. The practical implication is that training models on the behavior of an optimal probabilistic reasoner may be more effective than supplying only correct answers. For agents that must learn user preferences or update beliefs over time, examples that explicitly preserve uncertainty and demonstrate evidence-based belief revision could produce more reliable behavior.

Read original(opens in new tab)
Large Language ModelsSupervised Fine TuningBayesian InferenceProbabilistic Reasoning+3
datadog2 min readCurated summary

Designing MCP tools for agents: Lessons from building Datadog's MCP server | Datadog

Datadog is presented as a Leader in the 2026 Gartner Magic Quadrant for Observability Platforms. The provided content, however, consists almost entirely of Datadog’s website navigation rather than the blog post itself, so it does not include Gartner’s evaluation criteria, Datadog’s strengths, or any supporting analysis. ## Gartner Recognition - The page headline announces Datadog’s “Leader” position in the Gartner Magic Quadrant for Observability Platforms. - A link is provided to a Gartner-related resource page. - No ranking details, competitor comparisons, or Gartner commentary are included in the supplied text. ## Datadog’s Product Coverage The navigation indicates that Datadog offers a broad observability and operations platform spanning: - **Infrastructure:** infrastructure, container, network, serverless, GPU, storage, and cloud-cost monitoring. - **Applications:** APM, service monitoring, profiling, dynamic instrumentation, and agent observability. - **Data and logs:** database, data-stream, data-quality, job, log, and sensitive-data monitoring. - **Digital experience:** browser and mobile RUM, session replay, synthetic monitoring, product analytics, and error tracking. - **Security:** code, cloud, workload, vulnerability, compliance, SIEM, and application/API protection. - **Software delivery and service management:** CI visibility, testing, developer portals, incident response, SLOs, workflows, and case management. - **AI:** agent observability, GPU monitoring, AI integrations, Bits AI agents, and an MCP server. ## Limitations of the Provided Content - The actual article body is absent. - The text does not explain why Gartner recognized Datadog as a Leader. - It provides no technical findings, customer examples, methodology, or conclusions beyond the headline. The supplied excerpt supports only the conclusion that Datadog announced Gartner recognition and positions itself as a comprehensive observability platform. A substantive summary would require the full article text.

Read original(opens in new tab)
AI AgentsKubernetesDatadogObservability+3
github1 min readCurated summary

How we rebuilt the search architecture for high availability in GitHub Enterprise Server

The provided content is a brief author biography, not a technology blog post. It describes David, a GitHub software engineer specializing in search engineering and information retrieval. His expertise spans both search infrastructure and relevance engineering. ## Author Background - Works as a software engineer at GitHub. - Specializes in search engineering. - Covers the full information-retrieval stack, including: - Search infrastructure - Relevance engineering No blog post content or technical argument was included to summarize.

Read original(opens in new tab)
GithubInformation RetrievalInfrastructureSearch Engineering+1