How I AI: Cognition Labs CEO Scott Wu & Devin AI, the junior engineer that never sleeps

Scott Wu calls Devin, the AI agent from his company Cognition, his favorite intern. He has an infinite supply of them, and they never sleep. He uses Devin for scoped engineering tasks like researching a codebase, preparing pull requests, and making frontend changes. The key is that human engineers still define the task, review the code, and decide what ships.

Devin is best understood as a junior engineer that excels at tasks, not open-ended problems. In this episode of How I AI, Scott demonstrates three workflows where this model shines: adding a server integration to an existing codebase, iterating on frontend changes, and gathering context after an incident alert. He positions Devin as a powerful assistant for work with a clear scope and sufficient context, not as an autonomous senior architect.

Integrating a new server with a well-researched prompt

Before handing off a task, Scott treats Devin like a new team member. You would not just send a five-word Slack message to an intern; you would sit down with them for two minutes to provide context. Scott starts by using a tool called DeepWiki to do this synchronous part of the work, collecting the relevant codebase context before giving Devin a detailed, asynchronous implementation request.

Understanding the codebase with DeepWiki

DeepWiki generates documentation for a repository by combining natural-language explanations with the relevant code. For this task, Scott asks it to explain how the MCP server list is implemented. The tool returns a mix of English and code, pointing to the specific files and components that are already in place. This allows him to quickly find reference implementations and code excerpts to ground the task he is about to assign.

Crafting a detailed prompt for Devin

Instead of just sending his initial, simple request, Scott uses the research from DeepWiki to generate a much more effective prompt. The system takes his five-word idea and expands it with the context it just found, specifying the patterns to follow from existing servers, the exact type structures to use, and the functions to reference. This small loop of turning a simple idea into a detailed, context-aware prompt saves significant back-and-forth later.

Please go research the chat PRD-MCP server and add that to the list here.  Follow the pattern of existing servers like Atlassian and HubSpot. Here's the exact type it structure that would be used here. Here are the functions that you should be looking at. And here's what you should check to make sure that it works.

Asynchronous execution and pull request generation

Once the task is kicked off, Devin works asynchronously. Scott emphasizes that you are not expected to sit and watch it work. Just like an intern, it goes off to do the research, read documentation, edit code, and run checks on its own. This workflow allows engineers to multithread their work, kicking off several Devin sessions for different tasks while they attend meetings or focus on more complex problems. For security, any asynchronous agent should work with least-privilege credentials in an isolated environment.

Reviewing the pull request

Devin prepares a pull request, but a human engineer decides whether it is ready. Scott reviews the diff, requests changes when needed, and keeps testing, security review, and deployment with the team. The Devin and DeepWiki integration workflow shows how a short idea becomes codebase research, a scoped prompt grounded in reference implementations, an inspectable diff, and a reviewed pull request rather than an autonomous merge.

Handling frontend fixes and UI polish

Scott’s number one use case for Devin is handling miscellaneous frontend fixes. These are often small but time-consuming tasks involving spacing, styling, or component adjustments. Because the desired outcome is visual, it is easy for a human to verify the result, making it a perfect task to delegate. It is especially useful for adding the kind of UI polish that might otherwise get deprioritized.

Identifying the visual task

The workflow often starts in Slack with a specific issue and a screenshot. For example, a teammate might ask Devin to make a button a little more round or standardize font sizes. While a screenshot provides clear visual acceptance criteria, the reviewing engineer still needs to check for impacts on accessibility, responsive behavior, and interaction logic.

Devin's implementation and visual proof

After receiving the request, Devin finds the relevant frontend code and proposes changes. Crucially, it returns before-and-after screenshots with its pull request. This allows the reviewer to see the visual impact of the code changes directly in their workflow, without needing to pull down the branch and run it locally.

Collaborative review and feedback

An engineer reviews both the diff and the rendered result, often with teammates adding feedback in the same Slack thread. Devin incorporates those comments into later commits, and the shared review teaches the team which requests and screenshots produce useful work. The frontend iteration workflow keeps the original issue, visual acceptance criteria, implementation, before-and-after proof, accessibility checks, and collaborative review together.

Using Devin as the first responder for incidents

Scott’s team has institutionalized Devin as the first line of defense for incidents. When an alert fires, Devin is the first one paged. The goal is to have an initial investigation ready before a human even gets to their computer. As Scott puts it, you can wake up at 4 AM, and Devin has already written a report with a hypothesis, pointing to a recent change and the relevant error traces.

Integrating Devin into the alert system

Devin is connected to alerting systems like PagerDuty. When an alert fires, it automatically kicks off a session. For this kind of workflow, it is critical to start with read-only permissions for investigation. The team should only grant permissions for automated actions after they have been explicitly approved and tested.

Devin's initial incident report

The agent reviews available logs and traces to draft an initial report. It can identify a likely source, such as a recent code change that correlates with the error. However, engineers still need to verify the evidence. An agent can sometimes omit important context or infer the wrong cause, so human oversight is essential.

Human-led investigation and resolution

Human engineers own diagnosis, mitigation, and communication. Devin can correlate logs with a recent change and prepare a hypothesis before the on-call engineer arrives, but that report may omit context or infer the wrong cause. The automated triage workflow starts with read-only access, gathers the relevant traces, and returns an initial report that the incident owner must verify before acting. The speed comes from having evidence ready sooner, not from delegating the consequential incident decision to the agent during a live production response.

Devin is a force multiplier, not a senior architect

Scott’s workflows are worth copying because they all treat Devin as a junior engineer, not a magical replacement for one. The contract is clear: give the agent a well-scoped task with relevant context, let it prepare a first draft, and have a human review the result. This 'tasks, not problems' approach works best for frontend cleanup, version upgrades, documentation, adding tests, and initial incident research. In all these cases, the output can be inspected and verified before it affects users. Start with tasks that have clear success criteria, limit the agent's credentials, and always keep the final merge, deployment, and incident response decisions with an accountable human engineer. Devin will not solve your hard architectural problems, but it can free up your team from the engineering toil that gets in the way of solving them. The human engineer still owns the hard calls. For every task, the useful output is evidence a reviewer can inspect before deciding whether the work is done.