From 2a801352a7304e91b7ed1e657ea6bdf574b6d0e6 Mon Sep 17 00:00:00 2001
From: ctr26 <ctr26@users.noreply.github.com>
Date: Fri, 27 Mar 2026 14:51:03 +0000
Subject: [PATCH] feat: add vibe coding page

Pattern language format documenting coding style, preferences,
and collaboration approach. Includes fundamentals, advanced
patterns, anti-patterns, and working-with-me sections.

Why: Portfolio needs developer-focused complement to CV
---
 vibe.md | 150 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 150 insertions(+)
 create mode 100644 vibe.md

diff --git a/vibe.md b/vibe.md
new file mode 100644
index 0000000..2e5bc9b
--- /dev/null
+++ b/vibe.md
@@ -0,0 +1,150 @@
+---
+title: Vibe Coding
+layout: default
+permalink: /vibe/
+---
+
+# Vibe Coding
+
+I'm an ML scientist who codes. Here's how I work.
+
+**Quick Navigation:** [Fundamentals](#fundamentals) • [Advanced](#advanced) • [Anti-Patterns](#anti-patterns) • [Working With Me](#working-with-me)
+
+---
+
+## Fundamentals (Start Here) {#fundamentals}
+
+Core practices that shape everything else.
+
+### Commit Discipline
+- One commit does one thing
+- First line describes what changed, body explains why
+- Read your own commits from last month — can you understand them?
+
+### Code Readability
+- Write code that doesn't announce itself as AI-generated
+- Keep indentation shallow (≤4 levels)
+- Extract functions when nesting gets deep
+
+### File Organization
+- Resist creating new files unless necessary
+- Flat structures beat deeply nested ones
+- Each file has one clear job
+
+### Standards Over Invention
+- Follow existing style guides (Google Python, PEP 8)
+- Use conventional commit/branch formats
+- Don't make up your own conventions
+
+### Git Basics
+- Small, focused commits are easier to review and revert
+- Never bundle unrelated changes
+- Commit messages are for future you and your team
+
+---
+
+## Advanced Patterns {#advanced}
+
+Sophisticated workflows for experienced developers.
+
+### Worktree Mastery
+- Never `git checkout` — isolate every branch in its own worktree
+- Work on multiple features in parallel without conflicts
+- Clean mental model: one workspace = one concern
+
+### Agent-Driven Workflows
+- Default to background/async for independent work
+- Thinker/Worker separation: planning vs execution
+- Main session stays free for steering, not waiting
+
+### Typed Everything
+- Pydantic schemas for configs with runtime validation
+- Type hints everywhere — let tools catch errors before runtime
+- Invalid states shouldn't be representable
+
+### Minimal Diff Philosophy
+- Extract shared abstractions to reduce code duplication
+- Additive changes over rewrites when possible
+- Delete dead code completely — no commented-out safety blankets
+
+### Privacy & Security
+- Never reference private repos in public spaces
+- Review what goes in commits (no secrets, no `.env` files)
+- Treat branch names and repo references as potentially sensitive
+
+### Atomic Actions
+- Each tool call, file edit, agent spawn is self-contained
+- Reversible operations mean safer experimentation
+- One logical change per action
+
+---
+
+## Anti-Patterns I Avoid {#anti-patterns}
+
+What I consciously reject or unlearn.
+
+### 1. LLM-Looking Code
+Code that screams "generated by AI" — overly verbose, unnecessary abstractions for one-time use, generic variable names.
+
+**Example:** Creating a `DataProcessor` base class when you only have one processor.
+
+### 2. File Clutter
+New files are expensive. Prefer extending existing modules over spawning new ones.
+
+**Example:** Resist the urge to split every function into its own file.
+
+### 3. Blocking Workflows
+Never wait when you can parallelize. Never block the main session when you can background.
+
+**Example:** Running sequential git operations instead of using worktrees for parallel branches.
+
+### 4. Messy Git History
+Bundling unrelated changes, vague commit messages, bypassing hooks, force-pushing to main.
+
+**Example:** One commit with "fix tests, update docs, add feature".
+
+### 5. Private Repo Leakage
+Referencing private repos in public/org issues, PRs, or commits.
+
+**Example:** Mentioning private work in public discussions or linking to internal repositories.
+
+---
+
+## Working With Me {#working-with-me}
+
+Quick reference for collaborators.
+
+### What I Value
+- Atomic commits and clean git history
+- Conventional formats for everything (commits, branches, comments)
+- Type safety and validation over runtime errors
+- Minimal diffs and focused PRs
+- Documentation that lives with the code
+
+### How I Work
+- Worktrees for everything — expect multiple workspaces per repo
+- Background agents for parallel tasks — main session stays responsive
+- Python-first with Pydantic, Hydra, uv, ruff tooling
+- Google Python Style Guide unless repo has its own conventions
+- PRs only when CI passes — no "fix in review" cycles
+
+### Communication Style
+- Conventional comments in code reviews
+- Draft PRs for WIP, ready PRs for merge-ready code
+- Direct feedback preferred over indirect suggestions
+- Context in commit messages — explain the "why"
+
+### Expectations
+- Don't reference private repos on public/org repositories
+- Follow repo conventions if they exist, fall back to standards if not
+- Ask before force-pushing or destructive git operations
+- Keep file clutter minimal — prefer extending over creating
+
+### Working Async
+- I default to backgrounding independent work
+- Prefer parallelizing over sequential blocking
+- Main conversations stay free for steering and questions
+
+---
+
+*Last updated: March 2026 • [Back to CV](./)*