Answer data questions and build dashboards from the warehouse
We've been building Devin with Devin since the beginning. Task: We've been building Devin with Devin since the beginning. Last week, we merged 659 Devin PRs into our own codebase, up from 154 in our best week in 2025. Many of you know Devin as the web app. Internally, we use it across every interface (web, Slack, Linear, CLI, API) depending on where the work starts. This post covers how we leverage all of them. Core Experience The setup is this: we add any of the codebases we'd like Devin to manage. We're then given a unified interface where we can work across all of our repos using natural language. It's designed as a conversational interface, so we can chat with it the same way we'd message a teammate, whether from Slack, a Linear or Jira ticket, or the web app. Tag @ Devin in any channel. Include attachments if needed. Communicate back and forth as we would in the regular chat interface. A powerful result is that anyone is able to contribute regardless of their technical expertise or role in the company, they don’t need to understand and set up Git or any command line tools to start contributing to our codebases. Tag @ Devin with a request and we get a PR we can review and test out. If someone notices out of date documentation or a bug for example, they send a short message in Slack to get it fixed and move on with their day. This removes friction and barriers for rapid iteration and polish,and results in less context switching. And when engineers see what their teammates are accomplishing with Devin, on the same codebase they work on every day, they have the "Oh, really? Devin can do that?" moment, so it spreads organically. Ask Devin (Codebase Q&A) Once a repository is added to Devin, it's automatically indexed. Ask Devin becomes a window into that codebase. We use this constantly for scoping work before starting sessions. The workflow: use Ask Devin to explore the code and clarify a goal, then start a session directly from the search interface. Devin starts with clear context from our exploration, and the prompt is automatically tailored to our task. This same workflow applies with Jira or Linear integrations. Tag Devin on a ticket. Devin analyzes the task, searches the codebase, and plans its approach. It generates a high-quality session prompt automatically. Automated Code Review As we ship more code with agents, the bottleneck shifted from writing code to reviewing it. Devin Review turns large, complex GitHub PRs into intuitively organized diffs and precise explanations. We use it for every PR now. Every time Devin posts a PR in Slack, it includes a Devin Review link, so the organized diff is always one click away. What makes Devin Review useful: Autofix. If Devin Review or a GitHub bot flags bugs, Devin automatically fixes the PR. Devin also tackles CI/lint issues until all checks pass, closing the agent loop. Smart diff organization. Groups changes logically, putting related edits together instead of alphabetical order. Copy and move detection. Detects when code has been copied or moved and displays changes cleanly, instead of full deletes and inserts. Bug Catcher. Automatically analyzes PRs for potential issues and labels them by confidence level. Severe bugs require immediate attention. Non-severe bugs should still be reviewed. Flags are informational annotations. Codebase-aware chat. Ask questions about the PR and get answers with relevant context from the rest of the codebase. For any GitHub PR link, you can replace github.com with devinreview.com in the URL. Once Auto-Review is configured, Devin starts automatically reviewing PRs when they're opened, when new commits are pushed, or when someone is added as a reviewer. Design System Design systems drift. Someone hardcodes a hex value, another person builds a one-off button, and suddenly we're maintaining multiple sources of truth. We handle this two ways. First, anyone can fix violations the moment they spot them. Tag Devin in Slack with a screenshot and it migrates the component to match the design system. Second, we run a daily audit. Every morning Devin scans PRs merged in the last 24 hours, flags hardcoded colors, non-standard spacing, and components that should use the shared library. It creates Linear tickets for each violation, and optionally opens fix PRs automatically. The combination means violations get caught whether someone notices them or not. Bug Triage Automation; tools: Devin. Human role: The original post does not say how a person stayed involved.; limitations: Requires connecting DANA to the data warehouse via MCP and maintaining schema knowledge. Success depends on users being specific about metrics and time periods. The agent provides SQL for validation, implying human review is necessary to ensure accuracy. Source reliability is high as it is a first-party engineering blog..
Tools
Published on Agent Work Atlas:
Overview
We've been building Devin with Devin since the beginning.
Workflow
We've been building Devin with Devin since the beginning. Last week, we merged 659 Devin PRs into our own codebase, up from 154 in our best week in 2025. Many of you know Devin as the web app. Internally, we use it across every interface (web, Slack, Linear, CLI, API) depending on where the work starts. This post covers how we leverage all of them. Core Experience The setup is this: we add any of the codebases we'd like Devin to manage. We're then given a unified interface where we can work across all of our repos using natural language. It's designed as a conversational interface, so we can chat with it the same way we'd message a teammate, whether from Slack, a Linear or Jira ticket, or the web app. Tag @ Devin in any channel. Include attachments if needed. Communicate back and forth as we would in the regular chat interface. A powerful result is that anyone is able to contribute regardless of their technical expertise or role in the company, they don’t need to understand and set up Git or any command line tools to start contributing to our codebases. Tag @ Devin with a request and we get a PR we can review and test out. If someone notices out of date documentation or a bug for example, they send a short message in Slack to get it fixed and move on with their day. This removes friction and barriers for rapid iteration and polish,and results in less context switching. And when engineers see what their teammates are accomplishing with Devin, on the same codebase they work on every day, they have the "Oh, really? Devin can do that?" moment, so it spreads organically. Ask Devin (Codebase Q&A) Once a repository is added to Devin, it's automatically indexed. Ask Devin becomes a window into that codebase. We use this constantly for scoping work before starting sessions. The workflow: use Ask Devin to explore the code and clarify a goal, then start a session directly from the search interface. Devin starts with clear context from our exploration, and the prompt is automatically tailored to our task. This same workflow applies with Jira or Linear integrations. Tag Devin on a ticket. Devin analyzes the task, searches the codebase, and plans its approach. It generates a high-quality session prompt automatically. Automated Code Review As we ship more code with agents, the bottleneck shifted from writing code to reviewing it. Devin Review turns large, complex GitHub PRs into intuitively organized diffs and precise explanations. We use it for every PR now. Every time Devin posts a PR in Slack, it includes a Devin Review link, so the organized diff is always one click away. What makes Devin Review useful: Autofix. If Devin Review or a GitHub bot flags bugs, Devin automatically fixes the PR. Devin also tackles CI/lint issues until all checks pass, closing the agent loop. Smart diff organization. Groups changes logically, putting related edits together instead of alphabetical order. Copy and move detection. Detects when code has been copied or moved and displays changes cleanly, instead of full deletes and inserts. Bug Catcher. Automatically analyzes PRs for potential issues and labels them by confidence level. Severe bugs require immediate attention. Non-severe bugs should still be reviewed. Flags are informational annotations. Codebase-aware chat. Ask questions about the PR and get answers with relevant context from the rest of the codebase. For any GitHub PR link, you can replace github.com with devinreview.com in the URL. Once Auto-Review is configured, Devin starts automatically reviewing PRs when they're opened, when new commits are pushed, or when someone is added as a reviewer. Design System Design systems drift. Someone hardcodes a hex value, another person builds a one-off button, and suddenly we're maintaining multiple sources of truth. We handle this two ways. First, anyone can fix violations the moment they spot them. Tag Devin in Slack with a screenshot and it migrates the component to match the design system. Second, we run a daily audit. Every morning Devin scans PRs merged in the last 24 hours, flags hardcoded colors, non-standard spacing, and components that should use the shared library. It creates Linear tickets for each violation, and optionally opens fix PRs automatically. The combination means violations get caught whether someone notices them or not. Bug Triage Automation
Reported result
The source reports that DANA answers ad-hoc data questions that previously sat in queues for days, allowing non-engineers to get answers directly. It reduces context switching for engineers by handling 'click a bunch of buttons' reporting tasks. Specific quantitative metrics on time saved or error rates are not provided in the text.
Human role
The original post does not say how a person stayed involved.
Limitations
Requires connecting DANA to the data warehouse via MCP and maintaining schema knowledge. Success depends on users being specific about metrics and time periods. The agent provides SQL for validation, implying human review is necessary to ensure accuracy. Source reliability is high as it is a first-party engineering blog.
Try it
Act as a data analyst using DANA. 1. Connect to [replaceable: data warehouse name, e.g., Snowflake] via MCP. 2. Ask: '[replaceable: specific business question, e.g., Why did signups drop last Tuesday?]'. 3. Request a seaborn visualization and the underlying SQL. 4. Review the SQL logic for correctness. 5. If valid, generate a dashboard summary. If invalid, refine the prompt with specific metric definitions. Do not publish results without human confirmation of the SQL logic.
Source reports are not independently verified. Publication date is the catalog publication date, not the original article date.