Security
Boundaries before convenience
Who may do what? Define permissions, then test both allowed and denied operations.
Blog / Tim Witter
Safer systems, useful agents, verifiable software. Engineering perspectives with concrete code examples.
14 of 14 articles
Security
Who may do what? Define permissions, then test both allowed and denied operations.
Quality & evidence
No findings or no inspection? Make coverage gaps in security reports visible.
Agents & tools
Make tools easy to discover without turning visibility into permission to use them.
Architecture
What do designs, tests, builds, and runtime checks actually prove? Match each claim to its evidence.
Architecture
Use code indexes to find relevant source faster, without guessing at unresolved connections.
Agents & tools
Pinned tools and durable instructions make agent-assisted work easier to reproduce and review.
Security
Choose isolation for the actual risk. What a sandbox protects, and what remains outside it.
Security
Planning is not execution. Use previews and explicit approval before changing shared state.
Quality & evidence
Choose the right project checks and distinguish passed, failed, and not run in the handoff.
Architecture
Generate a project scaffold without overwriting existing work: preview, change, then verify.
Quality & evidence
From search result to supported claim: read sources, retain evidence, and name uncertainty.
Quality & evidence
Challenge tests with near misses and ambiguous cases so a green result supports the actual claim.
Agents & tools
Offer specialized guidance at the right decision point without replacing the project's rules.
Quality & evidence
Inspect interfaces across sizes and states, fix a specific problem, then recheck the result.