Code Is the Plan: Treating Commits as Tasks

Shipping speed comes from short feedback loops. The shortest loop is a single, well‑named commit that closes a tiny piece of the plan. Not a doc, not a meeting, just code that compiles, runs, and moves the product by one honest step.

Treat commits as tasks. Give each one a clear intent, a small surface area, and a clean end state. If you turned off every flag after the commit, the app should still work. If you had to revert just that commit tomorrow, the rest of the system should barely notice.

Naming is the contract. “feat: add resume viewer,” “fix: remove dark→light flash on navigation,” “refactor: extract TopBar hide/show.” The message should read like the checklist item you just finished, not a shrug. The diff should tell the story without a translator.

Prefer vertical slices. Ship something thin but real end‑to‑end instead of sprinkling partial changes across the codebase. Touch fewer files per commit. If you need to touch many, split along interfaces so each step stays reviewable and reversible.

Small commits feel slower for the first two steps and faster for everything after. Build times stay short. Reviews get easier. You catch regressions sooner because each step is visible. Revert becomes a scalpel instead of a rollback grenade.

The history turns into a map of decisions. You can scan what changed and why without guessing. You learn what actually moved metrics. You see where you trimmed complexity and where you accidentally added it. It becomes much harder to hide magic or confusion inside a mega‑commit.

Anti‑patterns are familiar: “WIP” that breaks the build, multi‑topic commits that change behavior and rename files and reformat everything, messages like “fix” that leave future‑you no clue. These are expensive later even if they felt fast now.

A simple workflow works. Write a short checklist. Turn each line into a commit name. Implement one line end‑to‑end, commit, move on. If you discover a new task mid‑way, write it down—don’t stuff it into the current change. Let the plan grow in the repo instead of in your head.

Velocity doesn’t come from typing faster. It comes from planning at the level the system can verify: the commit.