Vibe Coding Ovechkin's GR8 Chase

I’ve been a Washington Capitals fan for as long as I can remember. My dad often snagged extra tickets from a neighbor who worked at the old Capital Centre in Landover, MD, and I got to tag along with a sibling or three. The moment I saw the game in person, I was hooked! We’d sit in the “nosebleed” seats for just $2.50—cheap enough for students—but the view was still pure excitement.

A few months ago, I shared my two-year AI renaissance—transforming writing, coding, and learning, boosting productivity and personal growth.

In that post, I mentioned how—around six months ago—I was really enjoying agent-based development tools like Cursor and Windsurf. Since then, a buzzword called “Vibe Coding” has taken the AI development world by storm.

As Jeff Schneider puts it, "Vibe coding refers to an AI-driven approach to software development where people use natural language prompts to instruct large language models (LLMs) to generate code. Essentially, it's about describing what you want the software to do, rather than writing the code itself.”

My approach is more of a hybrid style—blending my hands-on review and architectural instincts with emerging AI-driven methods. I’m not at all surprised that I’m enjoying the process even more than when I was coding full-time, thanks to the creativity and ease these tools bring.

In this post, I’ll share tips on my “Vibe Coding” approach, which dovetails perfectly with Alex Ovechkin’s chase of Wayne Gretzky’s “never to be beat” NHL goals record. I thought it’d be fun to build an app that predicts the exact game in which Ovie will surpass Gretzky’s total.

I started by writing a series of ChatGPT prompts along these lines:

Create a Python 3.11 script that fetches Alexander Ovechkin’s total career goals and games played from the NHL API at https://api-web.nhle.com/v1/, including robust error handling for any API or data issues. Use the retrieved stats to calculate how many more goals he needs to surpass Wayne  Gretzky’s 894-goal record, figure out his goals-per-game rate, and estimate the additional games required—along with a projected date.  Document any assumptions, such as the scoring rate and days per game, and then send the results via email with a clear subject and a detailed body while handling any email errors. Make sure to follow PEP8 style, include concise inline comments and a module-level docstring, and keep the script modular and self-contained so it can be easily integrated into a bigger project.

I then opened Windsurf—using Claude Sonnet 3.7—and pasted this prompt into the Cascade window. In a single shot, it generated both the code and a Bash script, which I ran to produce the following email:

I went from idea to the email app you see above in less than 5 minutes and I was feeling pretty pumped. But having tried similar approaches twice before and ending up with messy, unmanageable code, I decided to pause, reflect, and proceed more methodically this time. As a result, I began documenting my prompts in a docs/prompts.md.

Over the past few months, I’ve attempted to build more than a dozen applications—some successful, others less so. With each project, I’m refining an evolving system for effectively applying this vibe coding approach and learning from every success and misstep.

Since I wanted to add more features—like hosting the app as a website and providing regular automated updates—I turned to documenting user stories. Though it happened over several prompts, here’s one example that populated my user_stories.md:

Generate a set of user stories for a project that tracks Alex Ovechkin’s goal count and progress toward Wayne Gretzky’s record, including acceptance criteria, implementation details (with file paths), and tests. Organize them by functionality (core tracking features, CLI, notifications), a static website (with automatic updates and cache configuration), AWS infrastructure (IaC, scheduled Lambda, GitHub Actions with OIDC), and configuration/management (AWS Parameter Store parameters, testing). Each story should use a consistent format—'As a [user], I want to [goal], so that [benefit]'—and include acceptance criteria, implementation references, and test files. Make sure to number the user stories in increments of ten and leave room for additional stories (e.g., US-515) without renumbering existing ones. Finally, add a 'Future Considerations' section that contains partially or not implemented features, each with clear acceptance criteria, status, and references to any relevant sources (like Martin Fowler's articles) or best practices.

I followed up by generating an architecture diagram and a traceability matrix linking automated tests to user stories. Although I’m condensing it here into a single prompt, it actually took multiple prompts to create. Also, when I used Windsurf to write the code, I worked one user story at a time with a good bit of back-and-forth. From experience, I know that reviewing code in smaller increments helps avoid the bloated, hard-to-maintain mess that can result from letting Cursor or Windsurf generate an entire app in one shot.

As shown in the figure below, the Ovechkin Goal Tracker architecture flows from NHL API data retrieval—processed by Python scripts calculating Ovechkin’s goals needed and projected record-break date—into a static site generated by update_website.py, stored in an Amazon S3 bucket, and delivered globally through Amazon CloudFront. Amazon EventBridge triggers a scheduled Lambda function that updates the HTML, invalidates the cache for fresh content, and optionally sends email notifications. Amazon Route 53 manages DNS, while AWS Certificate Manager (ACM) provides SSL certificates. GitHub Actions uses OIDC for secure AWS access, avoiding static credentials and enforcing granular role permissions. Each project references global and local “rules” files—streamlining naming conventions, security scanning, and best practices—while prompts.md centralizes AI-driven task templates. Finally, AWS CloudFormation ensures consistent resource provisioning for DNS, certificates, and other infrastructure, with scripts dedicated to configuration, deployment, and cache invalidation.

The architecture diagrams are illustrated below and you can find more details at architecture_diagrams.md.

After many iterations, the current website at https://greateightgoals.com/ looks like this:

To manage all this with Windsurf, I rely on a few key artifacts that help keep my projects consistent and secure:

1. Windsurf Memories (~/.codeium/windsurf/memories/) This is where I keep high-level, AI-influencing rules—like guidelines for style, naming conventions, and general heuristics I want my AI dev tools to follow globally. Think of it as a personal knowledge base that shapes how the AI interprets my prompts across all projects. If you ever find that your AI keeps defaulting to code patterns you dislike, updating these “global” memories helps reset the baseline.
2. Global Rules File (~/.codeium/windsurf/memories/global_rules.md) Within the memories directory, I maintain a global_rules.md where I list overarching development principles—such as adhering to PEP8, setting docstring requirements, or even specifying consistent variable naming conventions. Whenever I see recurring issues or best practices that apply to all my repos, I add them here.
3. Project-Specific Rules (.windsurfrules in the project root) In addition to the global rules, each repository has a .windsurfrules file. This is where I define project-specific constraints—like referencing a particular AWS service, using only certain library versions, or specifying a naming standard for user stories (e.g., US-100, US-110, US-120). By scoping some rules to a single project, I avoid “polluting” other projects with domain-specific guidelines.
4. Prompts File (prompts.md) Because I reuse many of the same prompt templates—especially for tasks like updating documentation, generating user stories, or scanning for potential vulnerabilities—I keep them all in a dedicated prompts.md file. This saves me time and ensures consistency when I’m iterating rapidly. By simply copying and pasting from prompts.md, I can maintain the same structure for tasks like updating an architecture_diagrams.md or generating acceptance criteria in user_stories.md.
5. Security & Automation One of my prompts is a security audit request that generates or updates a SECURITY.md file, highlighting areas to fix. For instance, it might recommend implementing SAST tools—like Prowler—to scan for known misconfigurations in AWS. I also use these insights to craft new GitHub Actions pipelines (tied to OIDC for AWS deployment), ensuring each commit is scanned for security regressions before it merges into main.
   1. In practice, if the AI picks up on a potential problem—like an unencrypted S3 bucket or a missing IAM policy restriction—I revise my .windsurfrules to flag such configurations as risky. Over time, the model “learns” to avoid them or automatically suggest fixes when generating code.

Overall, I've discovered that maintaining small, focused artifacts—global memories, per-project rules, recurring task prompts, and SAST-friendly pipelines—drastically reduces code bloat and security blind spots that often plague rapid, AI-assisted development. By systematically capturing and reusing best practices, I can build new features and projects with minimal overhead. And if Alex Ovechkin shatters the goals record on April 12th, 2025, I'll be thrilled to let my “Vibe Coding” approach join in the celebration!