Slack

43 posts

github2 min readCurated summary

How to build interactive experiences with canvases

Canvases extend GitHub Copilot beyond text-based conversations by providing shared, interactive workspaces where developers and agents can visualize information and take action together. They are useful for tasks such as triaging issues, exploring code architecture, managing worktrees, and searching organizational knowledge. The article concludes that canvases make AI workflows more engaging, practical, and easier to iterate on. ## How canvases work - Canvas extensions are interactive surfaces within the GitHub Copilot app. - Agents can update the canvas while users interact through clicks, edits, swipes, and other controls. - User actions may be sent back to the agent or handled locally. - Developers create one by running `/create-canvas` in a Copilot agent session and describing the desired interface and capabilities. - Canvases can evolve through follow-up prompts that add features or refine existing behavior. ## Visual issue triage - A card-based interface displays GitHub Issues one at a time. - Users swipe right to ship an issue or left to reject it. - The canvas updates immediately, organizing issues into decision-based categories. - This replaces a slower, text-heavy review process with direct visual interaction. ## Interactive codebase diagrams - A generated diagram represents components of a project as connected nodes. - Users can hover over, drag, and filter elements to explore relationships and architectural layers. - The interface turns static codebase documentation into an explorable model. ## Managing sessions and worktrees - A canvas can display active GitHub Copilot sessions and their associated Git worktrees. - It distinguishes active, stale, and orphaned worktrees. - Cleanup actions are available directly from the interface, reducing manual maintenance. ## Improving agent prompts - The prompt coach reviews previous agent interactions. - It identifies issues such as unclear context, spelling mistakes, and syntax problems. - It suggests ways to make prompts more precise and improve future agent results. ## Finding organizational knowledge - A knowledge finder can search sources such as Slack, Teams, email, and documentation. - It identifies people connected to a file or topic. - Results explain both who has relevant context and where that connection was found, making it easier to locate the right expert. ## Getting started Canvases are best suited to workflows where visual understanding and direct manipulation are more effective than sequential prompts. Developers can try them in the GitHub Copilot app by using `/create-canvas`, then iterating with the agent to build a workspace tailored to their task.

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

Got Skills? Make the Figma Agent a Better Collaborator | Figma Blog

Figma’s custom skills turn team knowledge and workflows into reusable instructions for the Figma agent. They complement design systems by adding guidance such as brand voice, critique methods, writing standards, and review processes. Figma’s experience suggests that any repeated task or team-specific judgment can become a shared skill that improves consistency and collaboration. ## Custom Skills Capture Team Expertise - A skill is a reusable set of plain-English instructions for the Figma agent. - Skills can be triggered in chat with a forward slash (`/`). - Teams and organizations can publish skills so members do not have to recreate prompts or explain workflows repeatedly. - They are particularly useful for practices that are easy to use but difficult to document and often exist only in someone’s head. ## A Second Opinion on Demand Skills can provide focused critique and help teams apply shared standards. - **Simulate stakeholder feedback:** Figma created a skill based on CEO Dylan’s comments, allowing designers to pressure-test work before a review. - **Apply UX writing standards:** A skill based on Figma’s style guide checks capitalization, punctuation, and other consistency issues. - **Review work as a new user:** The agent can assess an experience from a first-time user’s perspective, exposing friction and missing context that experts may overlook. - Design systems supply components, patterns, and UI elements; skills add broader team expertise such as compliance rules, product principles, and critique frameworks. ## Build Once, Use Everywhere Repeated team rituals are strong candidates for automation through skills. - **Catch-me-up:** Summarizes recent file or project activity so returning teammates can quickly understand what happened without searching comment threads. - **Crit preparation:** Interviews the designer about the project, persona, scope, and audience, then creates a critique page with guided discussion prompts. - Figma’s crit-prep skill draws on Nielsen Norman Group best practices to encourage more effective research questions. - **Crit recap:** Organizes feedback into themes, decisions, action items, and deferred items. - Recaps can be placed on the canvas or copied into Slack, helping preserve decisions and keep follow-up work visible. ## Connecting Existing Tools The article begins describing how skills become more powerful when they can draw on the tools a team already uses, suggesting that skills can connect workflows and information across the organization. The provided excerpt ends before giving the specific examples or implementation details. Teams should start by identifying repeated tasks, recurring meetings, or expert review processes and turn those into shared slash-command skills.

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

Transitioning as a hubber

Arthur Searle describes transitioning at GitHub as a largely smooth experience, enabled by an inclusive, remote-first culture and strong workplace support. Using handles, written communication, flexible avatars, and gender-affirming benefits reduced many common sources of stress. His experience shows that transition can involve both bureaucratic challenges and profound joy when colleagues respond with acceptance and care. ## A Career Built at GitHub - Searle began in IT support and operations before teaching himself to code. - He joined GitHub’s IT Engineering team after a colleague’s referral and moved to Enterprise Security six months later. - His work has included: - Helping migrate GitHub’s main SaaS platform to infrastructure as code. - Speaking at Oxford University about version control. - Throughout his transition, his handle—“gleeblezoid”—remained constant, providing continuity at work. ## How GitHub’s Culture Supported Transition - GitHub’s remote-first structure reduced anxiety around appearance, commuting, and in-person interactions. - Much of Searle’s work happened through written communication in Slack and GitHub, limiting the pressure of speaking while undergoing voice training and hormone-related voice changes. - Employees commonly use handles and informal avatars, making gender assumptions based on appearance less central. - Searle was able to update his name and pronouns in internal systems, with colleagues consistently using them. ## Gender-Affirming Benefits - GitHub covered gender-affirming healthcare for employees. - Benefits included reimbursement for: - Voice training. - Hormone replacement therapy prescriptions. - Therapy. - The main remaining difficulty was ordinary administrative friction, such as changing his legal name in payroll systems. ## Acceptance, Joy, and Belonging - Searle contrasts his experience with people who remain closeted, repeatedly come out to new coworkers, or face extensive bureaucracy. - Colleagues treated his transition as a normal part of his life and expressed genuine happiness for him. - Small gestures had a major emotional impact, including hearing his name and pronouns used at work for the first time and receiving a shaving kit from a teammate. - He emphasizes that being trans is not defined only by hardship; there is also joy in living openly and being supported by others. GitHub’s example suggests that inclusive policies, flexible communication practices, and everyday respect can make workplace transition significantly safer and more affirming. For organizations, support should extend beyond formal benefits to the culture and systems employees use every day.

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

From Prompting to Workflows: Boosting Frontend Development Productivity with AI

Frontend development is increasingly shifting from a coding problem to an orchestration problem. Requirements, designs, documentation, discussions, and existing code are scattered across tools, while LLMs can now connect these sources through repeatable workflows. The article argues that structured, reviewable workflows—rather than clever one-off prompts—are the key to scaling AI-assisted development and improving implementation quality. ## From Prompting to Repeatable Workflows - A prompt may produce a useful result once, but it does not create a reusable process. - A workflow defines a repeatable path from inputs to outputs: - Collect context from Jira, Confluence, Slack, and the codebase. - Summarize the actual requirements. - Identify ambiguities and unresolved decisions. - Propose an implementation plan. - Wait for human review before modifying code. - The LLM acts as the engine executing the workflow. - LY Corporation’s Noah MCP connects systems such as Jira, Confluence, Slack, and GitHub, allowing AI agents to access real organizational context instead of relying on manually copied prompts. - Once established, the same workflow pattern can be applied across many tickets, even when the specific inputs differ. ## Example: Planning a List Page The example Jira ticket requests a list page with search, filtering, sorting, and role-based filter visibility. - In the traditional process, a developer manually: - Reads the Jira ticket and identifies missing details. - Searches Figma for loading, empty, and no-results states. - Finds role-based filter rules in Confluence. - Searches Slack for prior decisions. - Inspects the codebase for reusable hooks and components. - Copies findings into notes and assembles an implementation plan. - Implements the feature, resolves bugs and edge cases, and submits a PR. - An AI workflow performs these steps systematically before coding. - The generated plan identifies: - A new `FeatureListPage` route and `FeatureList` component. - Reuse of `useTableFilters` and `useUrlState`. - Existing API support through `GET /api/<feature>`. - URL synchronization for filters, sorting, and pagination. - Role-based visibility using `useCurrentUserRole()`. - Required loading, empty, and no-results states. ## Surfacing Hidden Requirements The workflow improves quality by exposing information that might otherwise appear late in development. - A Slack decision establishes that filter and sort state should use URL parameters rather than `localStorage`, enabling shareable and reloadable views. - Existing hooks such as `useTableFilters` and `useUrlState` are discovered before new code is written, preventing unnecessary duplication. - Unresolved questions are explicitly listed for human review, including: - Whether filter and sort state belongs in URL parameters or `localStorage`. - Which empty-state design should be used when Figma contains multiple variants. - Resolving these questions early reduces rework during implementation or PR review. ## Closed-Loop Verification The workflow should continue after coding rather than stopping when the first implementation is complete. - The agent compares the implementation with the original plan. - It runs: - Type checks. - Linting. - Related unit tests. - Relevant smoke tests or local verification flows. - It reports: - Successful checks. - Failures that were fixed. - Items that could not be verified automatically. - UI screenshots or state notes. - Remaining risks before opening a PR. - This creates a closed-loop development cycle in which AI not only writes code but also validates its work against the intended requirements. Teams should treat AI as a workflow and context-orchestration layer, not merely a code generator. The most effective process gathers information across systems, obtains human approval for the plan, implements with existing project patterns, and automatically verifies the result before review.

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

How we built an internal data analytics agent

Qubot is GitHub’s internal, Copilot-powered analytics agent, designed to make warehouse data accessible without requiring an analyst. Employees ask natural-language questions through Slack, VS Code, or the Copilot CLI, while Qubot uses curated context and selects between Kusto and Trino to produce answers. GitHub’s experience shows that structured context is central to improving both accuracy and response speed. ## The Problem Qubot Addresses - Product teams often struggle to identify the right data model, grain, filters, and query. - Limited analyst availability leaves many teams to investigate telemetry independently. - Qubot targets exploratory questions rather than replacing dashboards or formal reporting. - It enables employees to investigate unfamiliar datasets with minimal setup and maintenance. ## Multiple Ways to Ask Questions - **Slack:** Users ask questions in a shared channel, receive answers in threads, and collaborate on follow-up questions. - Each result is saved as a Markdown report in a pull request, allowing users to refine queries or reuse them in dashboards. - **VS Code and Copilot CLI:** Qubot is installed as a plugin and operates alongside other agents, skills, and tools. - Offering both zero-configuration and developer-focused interfaces increased adoption among different user groups. ## A Federated Context Layer Qubot’s context is tailored to GitHub’s warehouse layers: - **Bronze:** Product teams provide telemetry schemas and metadata for raw events. - **Silver:** Data teams maintain query examples, usage guidance, and required filters for conformed data. - **Gold:** Dataset owners contribute business rules and metric definitions. - ETL pipelines add derived metadata and other signals automatically. - Context is fetched at runtime through the GitHub MCP Server. A dedicated context agent standardizes contributions from different teams. It ingests Markdown documentation and repository references, then organizes and normalizes them into a structure that Qubot can use effectively. ## Evaluation Before Deployment Every change to Qubot’s instructions or context layer is tested through an offline evaluation framework. - Test cases contain prompts, expected answers, ground-truth SQL, domains, and difficulty levels. - Automated orchestration launches multiple parallel agent trials using `gh agent-task create`. - Results are saved as JSON and aggregated by completion rate, accuracy, and duration. - Teams compare configurations and detect regressions before releasing changes. ## Choosing Between Kusto and Trino Qubot connects to both query engines through MCP servers: - **Kusto** is used for fast exploration of recent event data. - **Trino** handles complex joins and deeper historical analysis. - Qubot defaults to Kusto and switches to Trino when the question requires more advanced or historical querying. - This hides query-engine selection from users. ## Adoption and Lessons Learned - Hundreds of GitHub employees have run thousands of queries through Qubot. - Routine questions in analytics support channels declined as teams gained more autonomy. - The agent helped employees who previously avoided the warehouse access data for decision-making. - GitHub found that well-structured, carefully maintained context improved accuracy and made Qubot approximately three times faster at finding the right answer. The main recommendation is to treat analytics context as a maintained engineering asset. A capable agent depends not only on model intelligence, but also on accurate metadata, documented business rules, evaluation-driven iteration, and interfaces that fit users’ existing workflows.

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

If You Asked a Designer to Make Anything with AI

Toss Design Chapter’s AI Contest invited designers to build anything with AI, resulting in 122 projects over one month. The examples show that designers primarily used AI to improve existing work—making it faster, more persuasive, and higher quality—rather than creating entirely new kinds of work. The article recommends starting with a frustrating, repetitive task or a frequently repeated communication problem. ## Automating Repetitive Work - A color-extraction tool automatically identifies and adjusts colors from images for use in UI. - Color extraction had been an unresolved challenge at Toss because results varied widely by image. - Designers used AI to draft the logic, test it against many sample images, and rapidly refine it. - The resulting system is now used for product-card colors in Toss Shopping. ## Reducing Collaboration Costs with a Personal Bot - A Slack bot was trained on a designer’s knowledge, past discussions, and reference materials. - It creates draft answers to the many design and requirements questions the designer receives each day. - Team members can send the draft as-is or revise it before responding. - The bot learns from those revisions, improving its answers to similar questions over time. - The designer described the result as feeling like becoming “1.5 people,” and other Toss designers began creating their own bots. ## Persuading Through Interactive Prototypes - A designer built a functioning prototype of a stock-trading desktop interface instead of presenting only static screens. - Users could drag panels, rearrange them, and resize windows, with the interface responding accordingly. - Showing the intended interactions directly reduced the risk that design ideas would be misunderstood during development. - The working prototype helped align designers and developers and persuade the product owner. ## Pushing Quality Within Tight Deadlines - AI-generated motion graphics were created for the key visual of Toss Bank’s recruitment website. - Each job category needed its own animation despite a very short schedule. - The designer created the foundational images manually and repeatedly refined Kling prompts to achieve the desired results. - Human-designed starting and ending frames combined with AI-generated motion allowed all category animations to be completed in a single day. ## Four Ways to Start Using AI - **Efficiency:** Hand off one especially annoying repetitive task to AI. - **Replication:** Build a bot to answer questions you repeatedly handle yourself. - **Persuasion:** Turn designs that require verbal explanation into working prototypes. - **Quality:** Use AI to reach a higher level of polish within a limited timeframe. The practical recommendation is to begin with an existing task rather than searching for an entirely new AI application. Choose one area where AI can save time, communicate intent more clearly, or help raise the final quality.

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

Designing the Work You Do Every Day

A product designer at Toss Bank transformed her personal task-management routine instead of accepting repetitive manual work as unavoidable. She built an AI-powered desktop widget that collects Slack messages, summarizes them into actionable tasks, preserves their context, and helps her focus on prioritization. What began as a personal solution revealed a broader problem shared across roles and spread throughout her team. ## From Manual Task Tracking to Workflow Design - For two and a half years, she manually copied tasks, feedback, discussion links, and requests from Slack into Notion or Slack lists. - As her responsibilities expanded to three teams, daily tasks grew from roughly 10 to more than 20. - She reframed the issue as a product-design problem: - **User:** herself - **Real goal:** completing the most important work without missing anything - **Main friction:** copying, organizing, and locating context - **Ideal state:** tasks collected automatically, leaving only prioritization to manage - This led to three core requirements: - AI should register tasks directly from Slack. - Each task should retain its source thread and document links. - Priorities should remain visible in an always-present widget. ## Teaching AI to Understand Work Context - Adding a specific emoji to a Slack message sends it to a designated channel. - Claude Code reads the message and converts it into a task with: - A concise summary - The relevant team tag - A link to the original Slack thread - The hardest part was turning long, contextual Slack conversations into one clear action. - For example, a request about an error during a loan-extension application becomes “Check loan-extension error case.” - She created writing guidelines and examples defining: - What qualifies as a good task - How teams should be categorized - Which expressions and sentence structures to use - The goal was for AI-generated tasks to sound like something she would have written herself. - Refining the AI’s output was less about coding than encoding her judgment about what constitutes a real task. ## Designing the Widget Experience - Making the widget feel natural required detailed interaction design and repeated implementation. - She rebuilt the code to refine the expand-and-collapse behavior. - The drag interaction took nearly a week to complete. - Explaining seemingly obvious behaviors to AI forced her to define her own requirements more precisely. - In this sense, working with AI became a process of clarifying thoughts and translating them into explicit language. ## Replacing Anxiety with Prioritization - She no longer needs to open Slack or Notion repeatedly to remember her tasks. - The always-visible widget removed a previously unnoticed source of friction. - AI now handles collecting and organizing work, reducing the mental energy spent on administration. - She can concentrate on deciding what matters most instead of worrying that something has been forgotten. ## A Personal Problem Shared by the Team - Although the widget was initially built for personal use, many colleagues adopted it. - Developers unexpectedly became active users, reporting bugs and suggesting features. - The usual designer–developer relationship reversed: developers raised issues while she fixed and redeployed the tool. - This showed that task collection, prioritization, and context management are common problems across job functions. - The tool spread not because its concept was revolutionary, but because it addressed an existing, widely felt inconvenience. ## Applying the Method - Identify the most frequent “not really work” task from the past week: - Copying information - Searching for context - Organizing lists - Define the problem as a product: - Who is the user? - What are they truly trying to accomplish? - Where is the greatest friction? - What does success look like? - Examine why existing tools do not solve the problem. - Start with the smallest version that can be useful immediately. The practical lesson is to treat repetitive coordination work as something that can be designed away. Instead of searching for a perfect general-purpose tool, build a small solution around the specific context, habits, and judgments that existing products cannot know.

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

Encoding Your Domain Expert: The Context Layer Behind Spotify's Data Assistant | Spotify Engineering

Spotify’s data assistant, Vedder, relies less on model size than on carefully curated domain context. With more than 70,000 datasets, schemas alone cannot capture business definitions, data quality issues, or preferred query patterns. Spotify’s solution is a cluster-based context layer owned by domain experts, making AI-generated SQL more reliable, transparent, and maintainable. ## Why Schemas Alone Are Not Enough - Spotify has petabytes of data across more than 70,000 datasets, making it impossible to provide an LLM with the entire warehouse. - Even large context windows cannot represent all available schemas effectively. - Schema types and column names omit critical meaning, such as: - Which values represent test or legacy data - What “active user” means in a particular domain - Which tables or columns are authoritative - Without this context, an AI assistant may confidently choose the wrong dataset. ## Spotify’s Data Agent - Users ask questions in natural language, and the agent: - Selects the relevant context - Generates SQL - Executes it against the warehouse - Returns the answer, query, and sources - It uses a ReAct loop to reason, call tools, inspect results, and revise its approach. - Users can see how an answer was produced rather than receiving an opaque result. - The assistant is available through: - Slack - An MCP server for IDEs and AI tools - A dedicated web interface - Since August 2025, it has supported more than 2,100 users, 13,000 conversations, and 60,000 messages across 177 domain clusters. ## The Cluster Model Spotify organizes data domains into “clusters,” each owned by a named team of experts. A cluster contains: - **Datasets** - Relevant warehouse tables with schemas and profiling - Column cardinality, common values, and partition information - Details that help the model construct accurate filters and queries - **Pairs** - Expert-approved natural-language questions paired with SQL - Examples of both query patterns and domain semantics - **Docs** - Business terminology and definitions - Known data pitfalls - Guidance about which columns to use or avoid Clusters can represent organizations, initiatives, or specialized areas of interest. Domain experts decide what belongs in each cluster and which examples best represent correct practice. ## Why Human Curation Matters - Spotify considered automatically generating training pairs from historical query logs. - That approach produced unreliable results because query history contains: - Exploratory analysis - Debugging queries - One-off investigations - Incorrect table choices - Technically valid but misleading patterns - Cluster curators accepted only 12.5% of the proposed question-SQL pairs. - Experts therefore determine what is canonical and trustworthy, while the model uses that curated knowledge to answer more users. - The goal is not to replace data specialists, but to scale their judgment and expertise. ## Keeping Context Current - Data models and business logic change continuously. - Cluster health scores monitor signals such as: - Underlying data quality - Whether curated SQL still works after schema changes - Coverage of users’ real questions - Reproducibility of generated SQL - Renamed columns or deprecated tables can immediately reduce the validity of existing examples. - Cluster owners use health dashboards and recommended actions to prioritize maintenance. ## Learning from Every Conversation - Vedder records conversations, queries, answers, generated SQL, and user feedback. - Cluster owners use this information to identify missing documentation, weak examples, and emerging needs. - Each approved example or clarified definition improves future answers. - The system treats context as an ongoing product that requires ownership and maintenance, not a one-time upload of metadata. Spotify’s approach suggests that trustworthy enterprise AI depends on a maintained context layer: curated datasets, expert-approved examples, clear documentation, and continuous feedback. The model supplies reasoning and automation, but domain experts remain responsible for defining what the data means.

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

ODW #8: A Hands-On Internal Workshop on Accelerating Incident Response and FAQ Generation with Slack MCP

LY Corporation’s Orchestration Development Workshop demonstrated how Slack MCP can turn scattered Slack conversations into structured operational knowledge. Using AI, employees can summarize incidents, generate reports, create FAQs, and publish results to Confluence with minimal setup. The workshop’s central conclusion was that hands-on practice, reusable skills, and human review are essential for turning new AI capabilities into practical workplace tools. ## The Information and Adoption Challenge - Slack contains valuable real-time information from incident response, customer inquiries, and project discussions. - Much of this information remains unstructured because employees lack time to document it. - Documentation quality varies by author, causing useful knowledge to become difficult to find. - Although Slack MCP became available internally in March 2026, adoption barriers remained: - Limited time to explore new tools - Concerns about complex configuration - Slow internal distribution of technical knowledge ## Introducing Slack MCP Through Hands-On Practice - Slack MCP is an internally developed MCP server connected to company authentication. - Employees can access internal Slack data without issuing personal tokens or configuring OAuth. - The workshop began with a simple exercise: - Launch a coding tool such as Claude Code - Ask the AI to post “Hello” in a designated Slack channel - Confirm that the message was actually posted - This immediate success helped participants understand MCP’s practical capabilities. ## Combining Slack MCP with Other MCP Servers Slack MCP supports several core operations: - Reading messages and threads - Posting messages and performing actions - Looking up channels and members - Searching Slack content Combined with other MCP servers, it can support broader workflows: - Slack plus Confluence MCP: Generate and publish project reports or FAQs - Slack plus Jira MCP: Create work tickets from discussions - Slack conversations can be transformed into structured documents rather than remaining isolated in chat history. ## Automatically Creating FAQs from Slack Inquiries The first major exercise converted repeated support discussions into reusable knowledge. - Slack inquiry threads were collected and converted into FAQ-formatted Markdown. - Existing Confluence content was checked to identify duplicates. - New FAQs were published as child pages under an existing Confluence knowledge base. - The output was formatted as a table containing: - Symptoms - Causes - Solutions The workflow was packaged into reusable skills such as: - `slack-to-faq`: Searches recent inquiry threads and generates new FAQ files - `faq-to-confluence`: Converts and publishes the FAQs to Confluence This demonstrated how MCP can automate the entire path from conversation search to knowledge-base publication. ## Supporting Incident Response The second exercise focused on reducing the time needed to understand and document incidents. ### Rapid Situation Summaries Participants could ask the AI to summarize an outage in natural language. MCP searched relevant Slack threads and organized the information into: - Current resolution status - Customer impact - Actions being taken by team members - A chronological timeline This helps managers or newly joining responders understand the situation quickly without reading every thread. ### Automated Incident Reports After resolution, the AI generated reports in a specified format, including: - Incident and detection times - Duration - Root cause - Affected users and features - Whether data was lost - Remediation steps The `slack-incident-status` and `slack-incident-report` skills separated real-time status checking from post-incident documentation. ## Practical Guidelines and Safeguards - Clean and constrain source data before processing it: - Compare results with existing Confluence FAQs - Filter messages using reactions or other markers - Limit searches to relevant channels and threads - Do not publish AI-generated documents without review. - Check for personal information and confirm that the output accurately reflects the source conversations. - Include links or references to the original Slack threads. - Specify the desired output structure, such as a three-column table for symptoms, causes, and solutions. - Convert successful prompts into reusable skills so teams can avoid rewriting complex instructions and maintain consistent output quality. ## Lessons from the Workshop - **Timing matters:** Holding the workshop soon after Slack MCP became available captured user interest and accelerated experimentation. - **Practice is more effective than explanation:** Starting with a simple Slack post and progressing to FAQs and incident reports made the benefits immediately tangible. - **Real work makes training relevant:** Inquiry handling and incident response were chosen because they are common, time-consuming tasks. - **Reusable skills improve adoption:** Prompt patterns were tested manually, refined, saved as skills, and shared with participants for continued workplace use. The recommended approach is to introduce new AI tools through timely, task-focused workshops, then refine successful workflows into shared skills. MCP can greatly reduce the effort of operational documentation, but human validation remains necessary before generated knowledge is published.

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

Introducing Nova, our internal platform for coding agents

Nova is Dropbox’s internal cloud platform for running coding agents across the software development lifecycle. Rather than building separate tools for coding, CI debugging, migrations, and operational tasks, Dropbox created a shared platform that supports interactive sessions and autonomous workflows within its monorepo and infrastructure. The platform grounds agent changes in real builds and tests, making AI assistance more reliable and easier to integrate into engineering workflows. ## The Case for a Shared Platform - Engineering work includes repetitive but important tasks such as: - Debugging CI failures - Updating dependencies - Improving test coverage - Fixing flaky tests - Managing migrations and operational work - Different tasks require different interaction models: - Interactive chat for developer-driven work - Asynchronous workflows for long-running remediation and automation - Dropbox’s environment has specialized requirements: - A large monorepo - Bazel for builds and tests - Caching and remote execution - On-premises infrastructure - Dropbox-specific validation workflows - Off-the-shelf coding agents were designed primarily for local development and did not naturally fit this environment. ## How Nova Runs Coding Sessions - Each session runs in an isolated environment using a specific snapshot of the codebase. - Callers provide: - The repository commit - A task description - Optional validation commands - Iteration limits and branch settings - Nova can run builds and tests after an agent proposes a change. - If validation fails, the results are sent back to the agent so it can continue troubleshooting. - This creates a feedback loop of: - Propose a change - Validate it in the real environment - Correct failures - Repeat as needed - Nova supports multiple coding agents behind a common interface. - Engineers can access it through: - A web interface - A command-line client - An API - Internal scripts and services - The platform also provides prompt evaluation, observability, feedback collection, skills, plugins, and MCP integrations for accessing systems such as logs and monitoring tools. ## Deterministic Code Publication - Nova keeps code publication outside the agent. - Each session is limited to a single branch. - This makes active work and publication status predictable. - It avoids the complexity of agents creating and managing multiple branches. - The deterministic model simplifies automation such as: - Running tests - Rebasing onto the main branch - Tracking which changes belong to each session ## Engineering Workflows Using Nova ### Developer-Driven Sessions - Engineers use Nova’s web interface for quick fixes and prototypes without disrupting local work. - Validation commands can use Bazel selectivity tools to target the relevant compile and test dependencies. - Slack discussions can be carried into Nova sessions, preserving context and reducing manual setup. ### Flaky Test Remediation - Dropbox built Deflaker, a durable workflow connected to Athena, its flaky-test detection system. - Deflaker gathers examples of a test passing and failing. - It sends the associated logs to Nova. - The agent analyzes the evidence, identifies a likely cause, and proposes a fix. - This demonstrates how Nova can combine investigation, context gathering, and code changes in a longer-running automated process. ## Practical Takeaway Dropbox’s experience suggests that coding agents are most useful when embedded in existing engineering systems rather than treated as isolated code-generation tools. A shared platform like Nova can support many workflows while preserving consistent execution, validation, context, and observability.

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

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

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

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

AI Didn’t Replace QA; It Expanded It

Generative AI has not replaced QA at LINE Album; it has expanded QA’s scope and influence. The team found that QA productivity depends less on executing tests quickly than on organizing and interpreting large amounts of scattered information. By embedding AI into event-driven quality workflows, QA engineers now focus more on risk assessment, test strategy, and final decisions. ## QA as a Quality Architect - QA operates across the entire product lifecycle: planning, development, testing, release, and post-release feedback. - Its responsibilities include: - Identifying design risks during planning - Assessing the impact of code changes - Designing test strategies - Validating releases - Connecting user feedback and operational data to product improvements - QA information comes from many sources: - Planning and technical documents - Slack discussions and decisions - Jira tickets and pull requests - Automated test scripts and logs - App Store and Google Play reviews - The central challenge is therefore managing information volume and complexity, not merely increasing testing speed. ## From AI Assistant to AI-Driven Workflow - Initially, AI was used interactively to: - Summarize documents - Draft test cases - Organize bug reports - Document reproduction steps - This improved individual productivity but required QA engineers to manually collect and prepare information. - LINE Album QA instead built an automated quality platform with more than 30 workflows. - AI now reacts automatically to events such as: - Jira issue creation - Code changes and pull requests - Test execution - User feedback collection - AI gathers, analyzes, and structures quality information, while QA engineers interpret risks and make decisions. ## Scheduling and Webhook Automation ### Scheduled Analysis - Scheduled workflows periodically collect and summarize quality data. - Examples include: - Daily App Store review classification - API test result summaries sent to Slack - UI automation reports - Weekly QA activity and issue reports - QA engineers spend less time gathering data and more time evaluating risks and verifying important findings. ### Webhook-Based Analysis - Webhook workflows run immediately when quality-related events occur. - Examples include: - Summarizing the potential impact of merged code changes - Creating meeting notes when Slack discussions end - Analyzing and visualizing automated test results - This allows the team to recognize important quality signals much earlier. ## The AI-Supported QA Workday - UI tests run through MagicPod for Android and iOS, with results updated in Jira and shared in Slack. - Failed tests trigger analysis to determine whether they are flaky tests and identify possible causes. - Pytest-based API tests are similarly reported to Jira and Slack. - Daily Scrum workflows automatically provide: - Current test progress - Scrum board and issue dashboard links - Unresolved issues - Jira mentions requiring QA attention - App reviews are analyzed daily, classified as positive or negative, translated into Japanese and Korean, and summarized for the team. - During focused work periods, QA engineers use AI-generated information to plan quality activities, execute tests, monitor workflows, and summarize relevant discussions or documents. - End-of-day workflows summarize completed work and remaining issues. ## AI as a Test Design Partner - By 2026, AI generated approximately 90% of LINE Album QA’s test-case drafts. - Simple prompting produced many generic scenarios but failed to capture: - The reason a feature was introduced - Historical defect patterns - Effects on existing user flows - The team improved results by supplying broader context, including: - Specifications and development tickets - Change rationale - Previous Jira issues - Test history - Recurring bug patterns ### Multi-Agent Test Generation - An orchestrator coordinates five specialized sub-agents: - **Plan-Analyzer:** Examines requirements, feature descriptions, and images. - **Dev-Analyzer:** Adds implementation and development-ticket context. - **TestCase-Generator:** Produces normal, exceptional, boundary-value, platform-specific, and prioritized scenarios. - **TestCase-Validator:** Checks coverage, traceability, completeness, Given/When/Then structure, priorities, and platform coverage. - **Quality-Inspector:** Uses prior feedback and quality evaluations to improve future generations. - The workflow expands testing beyond stated requirements by incorporating defects that have historically occurred. - Validation feedback creates an iterative loop, making the output more executable and useful over time. AI is most valuable when it is connected to the organization’s accumulated context and quality signals—not when it is used merely as a chat-based drafting tool. The recommended approach is to automate information collection and analysis while keeping QA responsible for interpretation, prioritization, and final quality decisions.

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

AWS Weekly Roundup: Anthropic & Meta partnership, AWS Lambda S3 Files, Amazon Bedrock AgentCore CLI, and more (April 27, 2026) | Amazon Web Services

This week’s AWS news centers on deeper AI infrastructure partnerships and tools for building production-ready agents. AWS and Anthropic are expanding Claude’s integration with AWS hardware and Amazon Bedrock, while Meta is adopting Graviton for large-scale agentic AI workloads. New services for Lambda, EKS, Aurora, and Bedrock also emphasize simpler data access, hybrid networking, serverless scaling, and faster agent development. ## Anthropic and Meta Expand AWS AI Partnerships - Anthropic is training advanced foundation models on AWS Trainium and Graviton processors. - Anthropic and AWS’s Annapurna Labs are co-engineering at the silicon level to improve efficiency across the stack. - Claude Cowork is now available through Amazon Bedrock, allowing enterprise teams to collaborate with Claude while keeping data within AWS. - A unified Claude Platform on AWS is planned, offering a single experience for building, deploying, and scaling Claude applications. - Meta signed an agreement to deploy tens of millions of AWS Graviton cores for CPU-intensive agentic AI tasks, including reasoning, code generation, search, and orchestration. ## New Lambda and Kubernetes Infrastructure - AWS Lambda can mount Amazon S3 buckets as file systems using S3 Files. - Functions can perform standard file operations without downloading data first. - Built on Amazon EFS, S3 Files combines file-system access with S3’s scalability, durability, and cost model. - Multiple Lambda functions can share the same workspace, supporting AI agents that need persistent memory or shared state. - The Amazon EKS Hybrid Nodes gateway simplifies networking between cloud-based EKS resources and on-premises Kubernetes Pods. - It enables pod-to-pod traffic, control-plane webhook communication, and access to AWS services without making on-premises pod networks routable. - The gateway is available at no additional charge. ## Aurora Serverless and Bedrock Agent Development - Aurora Serverless now offers up to 30% better performance on platform version 4. - Its scaling algorithm better handles competing workloads, including busy APIs and bursty agentic AI applications. - The service continues to scale to zero during idle periods, with no additional charge for the improvements. - Amazon Bedrock AgentCore adds a managed harness in preview, allowing developers to define a model, system prompt, and tools without writing orchestration code. - Harnesses can later be exported as Strands-based code for greater control. - The AgentCore CLI supports governed, auditable deployments through AWS CDK, with Terraform support planned. - The CLI is available in 14 AWS Regions at no additional charge, and AgentCore skills support coding assistants. ## Cost Management, Operations, and Machine Learning - Granular cost attribution for Amazon Bedrock enables teams to track usage by project or organization and support detailed chargeback. - AWS DevOps Agent can work with the Salesforce MCP Server to investigate incidents, diagnose causes, and notify customers through Salesforce Service Cloud. - AWS microcredentials are now free through AWS Skill Builder in supported countries. - These hands-on assessments use simulated business scenarios and live AWS environments rather than traditional multiple-choice testing. - Amazon SageMaker AI can recommend optimized generative AI inference configurations, including instance types, containers, and inference parameters, helping reduce latency and deployment costs. ## Upcoming AWS Events - “What’s Next with AWS” is scheduled as a virtual event on April 28. - AWS Summits continue in May across cities including Singapore, Tel Aviv, Warsaw, Stockholm, Sydney, Hamburg, Seoul, Amsterdam, Bangkok, and Milan. AWS’s latest releases point toward a more integrated AI platform: specialized hardware for model execution, managed agent tooling, shared state through serverless storage, and stronger cost and operational controls. Builders should evaluate S3 Files and AgentCore for AI workflows, while teams running production inference can benefit from SageMaker recommendations and Bedrock’s improved cost attribution.

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

The Key to AI Utilization Lies in 'Organizational Learning' - The Start of the Orchestration Development Workshop

LY Corporation is moving from simply adopting AI tools to building with AI as a collaborative development partner. Its new Orchestration Development Workshop teaches engineers to coordinate multiple AI systems across coding, testing, reviews, incident analysis, and other workflows. The initiative aims not only to improve efficiency but to free engineers from repetitive work so they can focus on more creative, high-value challenges. ## From AI Adoption to AI Collaboration - AI-assisted development and operations are spreading rapidly across LY Corporation. - Engineers use generative AI for code generation and testing, while combining it with non-generative AI for analysis and operational optimization. - Despite broader adoption, employees differ significantly in how deeply they use AI in their daily work. - The workshop was created to help the organization evolve from “using AI” to “creating alongside AI.” ## Orchestration: Coordinating Multiple AI Systems - “Orchestration” refers to combining multiple AIs, along with human input, to produce a complete outcome. - Example workflows include: - Generating code automatically from a Jira ticket. - Having AI run tests, conduct reviews, and create a pull request. - Analyzing a Slack incident report, estimating the cause, and proposing a fix. - The workshop turns these emerging practices into hands-on learning rather than passive demonstrations. ## A Hands-On, Interactive Learning Model - Participants follow instructors in real time and perform the same tasks themselves. - Zoom conversations and Slack questions create two-way communication during the session. - Instructors and representative participants explore solutions to problems as they arise. - The goal is for attendees to gain skills they can reproduce in their own projects, not merely acquire theoretical knowledge. ## Organization-Wide Support Through Guilds and DevRel - The initiative is designed to avoid depending on individual enthusiasm. - Three complementary functions support continuous growth: - **DevRel:** Drives the program and promotes adoption. - **Guilds:** Contribute practical insights from engineering teams. - **TD:** Helps maintain quality and reproducibility. - This structure supports consistent content quality and enables AI knowledge to spread across the company. ## Beyond Efficiency: Unlocking Engineering Creativity - LY Corporation views AI as more than a way to complete tasks faster. - By delegating repetitive work to AI, engineers can spend more time on creative and strategically valuable activities. - The organization aims to move beyond a model where AI writes code and humans only review it. - Instead, engineers should collaborate with AI from the design stage through implementation. ## Future Direction - LY Corporation plans to share lessons from the workshops through external channels such as its technology blog. - Future topics will include both generative and non-generative AI. - The broader goal is to provide practical guidance for engineers building new workflows with AI. The workshop represents a structured way to turn AI experimentation into repeatable organizational practice, helping engineers coordinate multiple AI tools while preserving human creativity and judgment.

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

How We Built an SRE Bot That Reduced Our Team’s Repetitive Work by 90%

LINE Home DevOps created an SRE bot to reduce the repetitive work caused by growing services, Flava cloud migration, and increasing developer requests. By making Slack the central interface and automating Jira, Confluence, and workflow updates, the team reduced deployment-request handling from roughly 30 minutes to under one minute. The bot also improved tracking, consistency, and response speed, helping SREs move away from constant firefighting. ## Repetitive SRE Work and Its Costs - Developers frequently asked how to inspect Flava pod logs, request permissions, interpret errors, and access staging environments. - Deployment requests required manual movement between Slack, Confluence, and Jira: - Finding release checklists - Copying information into Jira - Creating missing Fix Versions - Linking Epics and active sprints - Sharing ticket links and deployment documentation - Each deployment request previously took about 30 minutes to an hour. - Manual processing caused omissions and mistakes, especially during urgent releases. - General requests were buried in Slack mentions, making ownership and completion status difficult to track. - Measurement showed that each SRE spent nearly half a day per week on repetitive work. ## Slack-Centered Automation The team adopted the principle that developers should only need Slack, while SREs should be able to manage work with a few clicks. - **Slack as the single source of truth:** Requests begin and remain trackable in Slack. - **Zero manual work:** Rule-based Jira and documentation tasks are automated. - **Immediate visibility:** Status changes and results are posted to Slack in real time. - **Permission control:** Only authorized SRE members can claim or complete requests. ## Key Technical Decisions ### Slack Workflows Instead of Slash Commands - Slash commands are easy to implement but depend on users entering correctly formatted text. - Slack Workflows provide structured forms with required-field validation. - Because Workflows are native Slack functionality, the team avoided building a separate user interface. - The lower usage barrier made adoption more likely. ### Asynchronous Processing - Slack requires event responses within three seconds. - Sequential calls to Jira, Confluence, and other APIs could exceed that limit. - The bot immediately acknowledges the request, then performs external work in the background. - Successes and failures are reported in the Slack thread, keeping processing transparent. ### Redis-Based State Management - In-memory state would be lost whenever the bot restarted. - Slack metadata APIs were considered too slow for real-time interactions such as emoji clicks. - Redis was selected for sub-100-millisecond lookups and persistent state. - A 30-day TTL limits stale data. - Redis transactions using `WATCH/MULTI/EXEC` ensure consistent updates when multiple SREs interact simultaneously. ### Hexagonal Architecture - The bot uses ports and adapters to isolate business logic from external systems. - The architecture separates: - Inbound Slack event adapters - Application use cases and business logic - Outbound Jira, Confluence, and Redis adapters - External API or SDK changes can be handled without modifying core business logic. - This structure also makes testing and future feature development easier. ## Automated Request Scenarios ### Deployment Requests - Developers submit required project, release-version, checklist, and other details through a Slack Workflow. - The bot automatically: - Creates a missing Jira Fix Version - Creates and configures the Jira ticket - Links the Epic - Adds the ticket to the active sprint - Finds the relevant deployment manual - Posts the result to the Slack thread - An SRE can click 👀 to claim the work. - Clicking ✅ completes the Jira ticket and posts a completion notification. - SRE effort falls from about 30 minutes to under one minute, with minimal risk of missing required fields. ### Emergency Deployments - Selecting an urgent request automatically sets Jira Priority to `Highest`. - The bot immediately announces the request in Slack. - An SRE can claim it with 👀, perform the deployment, and complete it with ✅. - The process reduces delays from roughly 30–40 minutes to about one minute. ### General SRE Requests - Requests such as production-access permissions are submitted through a structured Slack Workflow. - The bot creates a Jira ticket, links the Epic, assigns the active sprint, and sets an appropriate priority. - Slack retains the ticket link and status, eliminating the need to search through message history later. - SREs claim and complete the request using the same emoji-based workflow. The main recommendation is to automate repetitive, rule-based operations at the point where requests already occur. A Slack-centered, asynchronous bot with durable state and clean system boundaries can reduce manual effort while making ownership, progress, and completion visible to everyone.

Read original(opens in new tab)