Skip to content

vibe.md

Latest commit

 

History

History
150 lines (107 loc) · 4.74 KB

vibe.md

File metadata and controls

150 lines (107 loc) · 4.74 KB
title Vibe Coding
layout default
permalink /vibe/

Vibe Coding

I'm an ML scientist who codes. Here's how I work.

Quick Navigation: Fundamentals • Advanced • Anti-Patterns • 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