Test first, build second. Every time.
Writing the test before the code sounds backwards until you realize it's the only way to know your code does what you intended, not just what you typed.
The natural instinct is to write the code first and the tests after. The problem: tests written after the code tend to test what the code does, not what it should do. You end up with tests that pass but don't actually catch bugs. Test-driven development flips the order: write a test that describes the correct behavior, watch it fail, then write the minimum code to make it pass.
A failing test is a clear definition of 'done.' There's no ambiguity about whether the feature works. The test either passes or it doesn't.
This is especially valuable when working with AI coding assistants. The assistant will happily write code that looks right but handles edge cases wrong. A pre-written test catches that immediately. The assistant can't declare victory until the test goes green.
Pick a feature or bug fix. Before writing any code, write a simple test that describes what should happen. Run it. It should fail (because the code doesn't exist yet). Now write just enough code to make the test pass. Clean up. Repeat.
Start with the simplest possible test. 'When the user submits an empty form, show an error message.' That's a test. Write it, then build the code that makes it true.
Pure visual changes. Adjusting colors, spacing, or layout is better tested by looking at the screen than by writing automated tests. But anything with logic (validation, calculations, data transformations) benefits from test-first thinking.
Product leader shipping across enterprise SaaS, AI in production, and 0→1. Writing about what actually ships — not what sounds good in a deck.