Process, not autopilot
How I build
Human judgment sets the direction. AI helps with the work. Review and executable checks decide whether a change is ready.
Human-owned decisions
I own the problem definition, scope, architectural tradeoffs, and acceptance criteria. Before changing code, I read the existing implementation and project instructions. A plausible solution is not enough: it needs to fit the system and the people using it.
AI as a collaborator
I use Hermes for task organization, implementation assistance, diff review, and test ideas. Delegating a bounded task does not delegate accountability. I review proposed changes and require tests rather than treating generated code or an agent’s completion message as evidence.
Validation before delivery
The working loop is a failing test, a narrow implementation, and a passing test. Then I check the wider suite, lint, types, and production build. For UI work, I also inspect rendered behavior. Local checks, deployed behavior, and real user outcomes are separate claims; one does not prove the others.
Privacy and limits
Keep credentials out of source control and client bundles. Use the minimum context a task needs, and do not publish private employer material as portfolio evidence. Logs, documents, and model outputs are inputs to inspect, not instructions to trust. Review and tests reduce risk; they do not establish that AI is always correct or that a product is safe in every setting.
Practice is not a benchmark
These are workflow practices, not measured AI product evaluations. I am not presenting an evaluation dataset, model accuracy score, or productivity benchmark here. The GRIT case study shows a concrete boundary in inspected code; the Garage describes ongoing exploration with my tools.