The editor and the loop.
VS Code is the editor. Customized lightly. The defaults are good enough that fighting them is a waste of focus. The extensions that earn their place are the ones that compound across every project, not the ones that solve a single quirk.
GitHub Copilot and Claude Code sit beside it, not above it. AI completion is useful when the work is mechanical and dangerous when the work is structural. The rule is, AI accelerates the writing, not the thinking. The thinking has to be mine or the code rots in six months.
The feedback loop is the most important tool of all. Fast dev server, hot reload that does not lie, deploy previews on every commit. Anything that slows the loop gets removed; anything that tightens it gets kept.
Design tools, deliberately light.
Figma for layouts when the surface is complex enough to warrant it, which is fewer projects than you would think. Most of the work goes from sketch to component in the editor, because the design system is already in the codebase. Iterating in code is faster than iterating in a parallel design file when the code is the source of truth.
When a project does need a real design pass, the pattern is the same: low-fidelity wireframe in Figma, design tokens already in the codebase, then build the real thing in TSX. The high-fidelity Figma is the documentation, not the design.
The fastest design tool I own is the codebase. Everything else is a sketchbook.
Version control and review.
GitHub for everything. Branch per feature, descriptive commits, no fear of force-push on feature branches before they merge. The discipline is in the commit history, not in the diff size.
Code review is mostly self-review. Walk the diff before pushing. Read the PR description like a stranger would. The amount of bad code you do not ship by reading your own diff out loud is genuinely embarrassing.
Browsers and the inspector.
Arc for daily work because the way it handles workspaces matches how my projects are organized. Chrome for debugging because the DevTools are the most capable. Safari and Firefox during QA because shipping a site that does not work in one of them is a small humiliation.
The inspector is a tool I lean on harder than most developers seem to. Every layout problem has an answer in the computed styles panel; every performance bug has a signature in the performance tab. Learning to read those panels is a permanent skill upgrade.
Automation and the small scripts.
The lab runs on a quiet collection of small scripts. Shell helpers, Node CLIs, a handful of GitHub Actions. The pattern is consistent: if I do something twice and dislike it, I script it. If I do it three times, the script gets a flag.
AI helps here. Generating the boilerplate of a CLI in 30 seconds means the threshold for writing one drops significantly. The work that used to be too small to bother automating is now exactly the work that gets automated first.
The philosophy.
Pick the smallest set of tools that gets the work shipped. Do not collect new tools the way you collect new languages. Every new tool has a tax: configuration, mental overhead, integration cost. The tax is rarely worth it.
The good news is that the bar is high. A new tool has to clearly improve a feedback loop, a default, or a constraint to make the cut. Most do not. The toolbox stays tight on purpose. That is what frees attention for the work itself.
Tool churn looks like progress and feels like motion. It is neither.