How I AI: Ryan Nystrom's 3 Notion Workflows for Engineering Velocity

Notion engineering manager Ryan Nystrom has stopped treating meeting prep, implementation work, and feature specs as separate chores. In this episode of How I AI, he shows how his team automates standup preparation, turns a Notion task into a reviewed pull request in about 20 minutes, and builds features from version-controlled specifications that agents can implement and verify.

Ryan still writes code while managing a team of engineers, and AI has changed nearly every part of how he works. After more than a decade using roughly the same development setup, he now changes IDEs, terminals, and workflows constantly. Instead of feeling destabilizing, he says the pace has made engineering feel fresh again. He spends less time compiling updates and more time reviewing ideas, fixing bottlenecks, and experimenting.

The three workflows span different layers of engineering work: gathering context before a meeting, handing a scoped task to a background coding agent, and using a written specification as the source of truth for implementation and verification. None of them are fully autonomous systems. Each one narrows a repetitive loop that previously consumed human attention. See Implement Features Using Spec-First Development and an AI Coding Agent.

The pattern across all three workflows is the same. The agent gathers information or produces a draft implementation, then humans review the result at a clear checkpoint: a pre-read, a pull request, a preview build, or a verification run. Ryan’s team is optimizing for shorter feedback loops, not removing engineering judgment.

Turn standups into high-context working sessions

Ryan’s team runs daily standups for Project Afterburner, Notion’s effort to dramatically reduce CI time. The problem was not the meeting itself. It was the preparation work required to make the meeting useful. Someone had to gather metrics, scan Slack threads, review merged pull requests, summarize task updates, and reconstruct what changed since yesterday.

Instead of manually assembling that context, Ryan built a custom Notion AI agent called Hot Potato. Before the meeting starts, the agent prepares a structured pre-read so the team can spend the standup discussing decisions, risks, bugs, and discoveries instead of reciting status updates. See Automate Daily Standup Preparation with a Custom Notion AI Agent.

How the standup agent works

1. Create the page: A recurring Notion automation generates a fresh meeting page from a template before each standup. The page starts blank except for the structure Ryan wants the agent to fill in.
2. Trigger the agent: At 9 a.m., Hot Potato runs automatically and reviews activity from the previous 24 hours. Ryan explicitly instructs it to limit its search window so the meeting stays current instead of turning into a giant project digest.
3. Gather context: The agent fans out across several systems in parallel to assemble the same information Ryan would normally gather by hand:

• Metrics: It pulls CI performance data from Honeycomb through a Model Context Protocol (MCP) connection so the meeting always starts with the latest build and test numbers.
• Communication: It scans the team’s Slack project channel for updates, feedback, open questions, and decisions that might otherwise stay buried in threads.
• Work: It checks the Notion task database for recently closed tickets and project changes tied to the Afterburner effort.
• Code: It reviews merged GitHub pull requests so implementation details and infrastructure changes appear alongside project discussion.
• History: It reads the previous meeting notes for continuity so unresolved questions and ongoing work do not disappear between standups.

1. Build the pre-read: Ryan gives the agent a specific structure to follow so the output stays predictable and scannable during the meeting:

• CI speed
• Decisions
• Progress and changes
• Bugs and feedback
• Open questions and risks

1. Notify the team: After generating the page, the agent posts a short Slack message linking to the pre-read. Ryan intentionally asks it to keep the message brief and slightly playful so the automation feels lightweight instead of corporate.

Ryan estimates the workflow saves about 20 minutes of preparation every day, but the bigger change is conversational quality. The team arrives with shared context already assembled, which means the meeting can focus on tradeoffs and problem solving. I point out that richer standups also surface quieter engineers more consistently because the system pulls work from the actual tools instead of relying on whoever is most comfortable speaking up.

Hand a scoped task to a background coding agent

Notion’s internal background-agent system, Boxy, lets engineers assign work to a coding agent directly from a Notion comment. Instead of copying prompts into a terminal, waiting beside a local environment, and manually wiring up tooling, Ryan can hand off a task from the same place the team already tracks work.

Ryan demonstrated the workflow with a small feature request from a friend: add a way to copy a direct link to a tab in Notion. Rather than dropping the request into a backlog for later, he turned the message into a scoped task immediately.

From task description to reviewed pull request

1. Write a clear task: Ryan described the feature in plain language, included a related hover-state bug, documented a deep-linking edge case, and attached a screenshot showing exactly where the new control should appear in the UI. The task was only a few short paragraphs, but it contained enough implementation detail to constrain the agent.
2. Invoke the agent: In a comment on the task, he mentioned @Codex to start the workflow.
3. Let Boxy run: The mention spins up a virtual machine with Codex, the codebase, and the required development tooling already configured. The agent reads the task description, comments, screenshots, and surrounding context before starting implementation.
4. Review the result: About 20 minutes later, the agent responded with a GitHub pull request and a live preview environment. The pull request documented how it tested the feature and included screenshots from its own UI verification process, showing the new behavior working inside the app. You can follow the full implementation in From Notion Task to GitHub Pull Request in 20 Minutes with a Coding Agent. See From Notion Task to GitHub Pull Request in 20 Minutes with a Coding Agent.

Ryan still reviewed the code closely. When he found a line he did not understand, he asked the agent to explain it directly in the pull request. The agent clarified the reasoning, fixed remaining type errors, and updated the implementation. I note that this changes the emotional dynamic of code review. Engineers can ask blunt questions without worrying about social friction, and agents can repeatedly explain or revise without slowing the team down.

Use specs as the source of truth

For larger projects, Ryan’s team starts with behavior and verification before implementation. Instead of treating specs as disposable planning documents, they keep them version-controlled inside the repository and use them to drive the coding agent directly. Engineers spend more time defining architecture, constraints, and validation logic while the agent handles more of the implementation loop.

Ryan demonstrated the process using Ask Mode, a Notion AI feature that limits the system to read-only tools. The interesting part was not the feature itself. It was the workflow used to build it.

Building features from version-controlled specs

1. Dictate the idea: Ryan started by talking through how Ask Mode should behave and used the transcript as raw material. He did not begin with code or formal requirements. He began with an explanation of intent, edge cases, and expected behavior.
2. Generate the formal spec: He handed the transcript to Codex along with examples from the team’s existing spec library so the model could mirror the same format and level of detail.

"Here's our other like spec library. Learn the format, take my information, write a spec."

1. Commit the spec: After revising the generated Markdown document, Ryan added ask_mode.md to the repository’s /agent-specs/ directory and pointed Codex at the file. The spec became the canonical description of how the feature should behave.

"Build it."

1. Build and verify: The specification included a verification section describing how the feature should be tested. The agent used a custom CLI to run Notion AI, send prompts, toggle Ask Mode on and off, and compare actual behavior against the written requirements. Ryan’s team built these verification tools specifically so agents could evaluate functionality without constant human supervision.
2. Keep the spec current: The initial implementation took a couple of hours to generate and review. After that, future changes started with updates to the spec itself rather than edits scattered across the codebase. Ryan likes that the repository now contains a readable history of how the feature evolved, not just a trail of implementation details buried in commits.

What is actually worth copying

Ryan’s workflows work because the boundaries are explicit. Hot Potato has defined data sources, clear permissions, and a fixed meeting structure. Boxy receives scoped tasks with screenshots and edge cases, then returns artifacts humans already know how to review: pull requests, previews, and test results. The spec-first workflow defines verification criteria before implementation starts.

The easiest place to start is not a giant autonomous system. It is a narrow loop with obvious inputs and outputs. Automate one recurring pre-read. Let an agent implement one small UI fix. Write one spec detailed enough that another engineer could build from it. Then inspect the output quality and cycle time before expanding the scope.

The strongest idea in this episode of How I AI is not that agents replace engineers. It is that engineering velocity increasingly depends on reducing waiting: waiting for meeting prep, waiting for CI, waiting for reviews, waiting for context gathering, waiting for implementation scaffolding. These workflows work best in teams with fast testing pipelines, disciplined review habits, and people who still want to stay close to the code. Human judgment remains essential around architecture, verification quality, and whether the generated work actually matches the intent behind the request.