Windsurf's product philosophy is built around a shared timeline that combines what the developer and the AI do across a software workflow.
2
The company wants Windsurf to read context from developer tools and take actions across coding, design, pull requests, reviews, deployment, and other services.
3
SWE-1 is trained for complete software engineering workflows, including partially completed tasks and ongoing conversations, rather than code generation alone.
Summary
Kevin Hou describes Windsurf's growth from an editor with autocomplete into an agent that can edit multiple files, research codebases, run commands, use web search, connect to MCP services, and work with parallel agents. His central idea is a shared timeline between a developer and the AI. That timeline must include activity in the editor as well as Slack, Google Docs, Figma, GitHub, Jira, Notion, Linear, and other tools. Windsurf's planned direction is to read this context and act across the whole workflow, from writing design documents and code to opening pull requests, reviewing changes, and deploying an application. Hou also introduces SWE-1, a model trained for software engineering workflows, including tasks that begin in the middle of a conversation or codebase. He connects the product, model, and user feedback through a data flywheel, where real usage reveals missing tools and workflow failures that guide new training and product work.
Windsurf has expanded from autocomplete into an agentic editor
Hou says Windsurf did not exist a year earlier, when many developers were using autocomplete and few people had heard of agents. Since its launch in November, the product has added what the company calls "waves," including web search, MCP support, autogenerated memories, deploys, and parallel agents. Windsurf can edit multiple files, research thousands of files in the background, and execute terminal commands inside the editor. Hou says the product was generating about 90 million lines of code each day and more than a thousand messages each minute, although he says the talk will focus on why the product feels connected to developers rather than on growth numbers.
A shared timeline connects the developer's work with the AI's work
Hou calls Windsurf's "secret sauce" a shared timeline between the human and the AI. Earlier coding tools handled small edits and autocomplete. Windsurf's agent expanded that timeline by editing files, researching the codebase, and running commands. Hou argues that the timeline cannot stop at the IDE because software work also includes decisions, research, reviews, and deployment. The AI needs to understand what has already happened, what the developer is doing now, and which action should come next. This is the reason he gives for Windsurf feeling as if it is reading the developer's mind.
Windsurf needs context from every tool in a developer's workflow
Hou divides useful engineering context into several sources. Inside the editor, this includes file reads, terminal commands, history, and open tabs. Outside it, the developer may inspect GitHub commits, related pull requests, online searches, and documentation. A further category is what Hou calls "metalearning": organizational practices and engineering preferences that distinguish junior, senior, and staff-level work. His example follows a feature from customer requests in Slack to design documents in Google Docs, tickets in Jira, parallel design work in Figma, code, pull requests, review, merging, and deployment. Windsurf aims to fetch context from Google Docs and Figma and connect to services such as Notion, Linear, and Stripe through MCP.
The agent is meant to act across the whole software workflow
Reading context is only part of the plan. Hou says Windsurf must also do and write things beyond code. The examples include interacting with third-party services, provisioning API keys, writing design documents and PRDs, making wireframes, testing, opening pull requests, and deploying. In his web app example, the agent runs relevant terminal commands, choosing when to ask for approval. Browser previews let it control Chrome, inspect DOM elements, and use the JavaScript console. GitHub MCP can open a pull request and use other pull requests to write its description and test plan. Windsurf Reviews can leave comments and suggest changes, while a one-click Netlify service can deploy the merged application.
Windsurf wants background work with human approval at the end
Hou describes Windsurf's current workflow as mostly agent activity with a smaller human role. He says timelines today are 80 to 90 percent agent and 10 to 20 percent human, with a goal of reaching 99 percent agent and 1 percent human. The intended system would research in the background while the developer works on something else and ask for approval only when needed. Hou imagines software work being possible at any time, including through voice activation and while away from a desk. This requires the system to handle messy, partially completed workflows, tasks that begin midstream, and tools outside the editor.
SWE-1 is trained for software engineering workflows rather than code output alone
Hou introduces Windsurf's software engineering model, SWE-1. He says the team needed a system designed around its representation of the shared timeline, because standard frontier models did not handle the full problem. SWE-1 is trained for software engineering workflows rather than pure code generation. Windsurf evaluates it with an end-to-end task benchmark, which starts with an intent and a codebase and measures whether the resulting pull request passes unit tests. Its conversational SWE task benchmark places the model inside an existing conversation or partially completed task, then scores helpfulness, efficiency, and correctness.
User feedback tells Windsurf where the software engineering frontier is
Hou describes a data flywheel connecting the product, users, models, and tools. Developers use Windsurf and provide signals through thumbs up, thumbs down, accept, and reject actions. Those signals reveal repeated workflows, missing tools, and places where the product falls short. Hou says this points to a software engineering frontier that is different from the SWE-bench frontier. Windsurf uses the feedback to train a better model, build more tools, improve its agent harness, and improve memories and checkpointing. The cycle repeats as the company ships, finds the frontier, builds at the margin, and ships again.
AI products need the model, data, and application to work together
Hou presents SWE-1 as an example of building an AI product around more than model quality. He says the team achieved near-frontier results with a smaller team and fewer resources than larger companies. In his view, the application must mimic the user behavior that the model is meant to reproduce. Product design creates the workflow, real usage provides data about failures and preferences, and model training uses those signals to improve the system. He calls this a harmony of model, data, and application, with Windsurf's goal of being everywhere and doing anything across the software development process.
"It demands this harmony of model, data, and application where the application is actually mimicking the user behavior that you want to replicate inside of your model."14:55
Who should watch
You are building an AI coding product and need to think beyond code completion toward the full software workflow.
Your team's work is spread across an editor, issue tracker, design tools, documents, pull requests, and deployment services.
You want to understand how Windsurf frames model training around ongoing conversations, partial tasks, and feedback from real usage.
