Power tools, not shortcuts: Rolling out Windsurf at ServiceNow

Training tools on a desk under stage-like lighting to suggest a live session.

Over the past month, I’ve traveled to ServiceNow offices worldwide training engineering teams on Windsurf, our AI-powered coding environment. While demonstrating new workflows and watching productivity gains emerge was rewarding, one insight consistently surfaced: tools matter, but people matter more.

Master craftspeople understand their traditional tools intimately while recognizing when power tools provide necessary leverage. Not because they seek shortcuts, but because they value their time and respect the work’s complexity. Windsurf doesn’t replace engineering judgment or taste—it amplifies existing capabilities while freeing mental bandwidth for higher-order thinking.

Our training focused on five core principles. First, context quality determines AI effectiveness, so we began by improving documentation, capturing decision records, and establishing tests as the definitive source of truth. Second, we emphasized small, safe feedback loops—proposing changes, running tests, reviewing differences, and iterating—rather than attempting large, opaque generations.

Third, we practiced writing intentional prompts that clearly articulate goals, constraints, and success criteria. The objective isn’t creative expression but precision and clarity. Fourth, we applied Windsurf to practical refactoring tasks: extracting functions, improving documentation, and generating test scaffolding, always validating against existing test suites. Finally, we positioned the AI as a supplementary code reviewer rather than a replacement, asking it to explain complex changes and suggest simplifications.

This curriculum wasn’t about technological novelty but building sustainable habits around a powerful capability. Our adoption approach prioritized real-world application over theoretical exercises. Each session incorporated actual issues from team repositories with the goal of shipping tangible improvements before conclusion.

We implemented a champion model, identifying curious engineers for deeper training who subsequently ran office hours for peers. This peer-to-peer knowledge transfer proved more effective than top-down mandates. We established lightweight guardrails covering security practices, data handling protocols, and attribution standards, defaulting to transparency about AI assistance in pull requests.

For measurement, we discouraged fixation on code volume metrics, instead tracking meaningful engineering productivity indicators: lead time for changes, review latency, change failure rates, and recovery time. Improvement in these metrics while maintaining quality standards indicated successful adoption.

Responsible use guidelines emphasized four areas. Security and privacy protocols prohibited sharing secrets and treated prompts as potentially auditable information. We established the primacy of existing code, tests, and documentation as the source of truth, preventing the AI from inventing requirements. We mandated readable changes through smaller diffs, clearer commit messages, and pull request descriptions explaining rationale rather than just implementation details. Most importantly, we reinforced that human engineers must understand and take responsibility for all changes, regardless of how they were generated.

Several observations surprised me during this rollout. Senior engineers, rather than resisting, embraced Windsurf as a thinking partner to generate alternatives, challenge assumptions, and prototype experiments. Junior engineers gained confidence through constrained usage patterns, shipping improvements faster while learning idiomatic patterns through examples. The most effective results consistently came from well-defined constraints—specific goals, clear boundaries, and comprehensive tests transformed a general-purpose agent into a focused collaborator.

For teams adopting similar tools, I recommend five practices: begin with failing tests or well-defined issues that provide objective success criteria; document constraints including interfaces, performance requirements, security considerations, and style guidelines; request targeted changes rather than complete files to maintain tight feedback loops; thoroughly review generated code, rejecting anything not fully understood; and delegate mechanical tasks like scaffolding, repetitive edits, and documentation generation to maximize human focus on design decisions and correctness verification.

The most meaningful moment from these training sessions wasn’t any particular feature demonstration but witnessing engineers’ excitement upon realizing they could redirect their attention to the most intellectually engaging aspects of software development: problem modeling, interface design, and creating meaningful user experiences.

Exceptional tools don’t diminish professional skill—they honor it by providing appropriate leverage. Windsurf represents this philosophy in practice. Our responsibility as engineers remains unchanged: building robust systems, sharing knowledge effectively, and maintaining uncompromising standards. In future posts, I’ll share specific patterns from our training, including prompt templates and our AI-assisted pull request checklist.