AI is most useful to me when it makes the engineering process clearer. I use it to inspect more context, compare more options, and shorten the distance between an ambiguous problem and a verified solution—not to outsource judgment.
The useful output of each task is not only code. It is also better context for the next decision.
- 01Context
- 02Plan
- 03Build
- 04Verify
- 05Learn
The operating principle
AI works inside my process, not above it.
The model does not attend the stakeholder conversation, own the production incident, or explain a tradeoff to the team. I do. That changes which work I accelerate and which decisions stay firmly human.
My goal is not to generate more code. It is to reduce the distance between an unclear problem and a verified solution.
AI can widen the search space; the engineer remains responsible for narrowing it correctly.
- 01AI leverage · Inspect and draft · Search, Compare, Scaffold, Refactor, Challenge
- 02Human responsibility · Decide and own · Understand, Choose, Review, Explain, Own outcomes
My workflow
Five loops move the work from context to confidence.
Domain-heavy work—especially healthcare—stays bounded by product behavior, privacy, architecture, and evidence rather than model confidence.
- 01Context · User outcome, constraints, nearby code, and existing patterns.
- 02Plan · Facts, assumptions, risks, scope, and acceptance criteria.
- 03Build · Mechanical implementation within known boundaries.
- 04Verify · Types, tests, build, browser journey, and diff review.
- 05Learn · Turn corrections into tests, tokens, docs, or rules.
Where it helps
The tool changes role across the development lifecycle.
The pattern is consistent: let AI increase breadth, then use product and engineering evidence to narrow the answer.
- 01Discovery · Map code, data flow, and nearby patterns / Is the context complete and relevant?
- 02Product shaping · List states, edge cases, and acceptance criteria / Does this match the real user decision?
- 03Implementation · Draft components, tests, migrations, and docs / Does it respect system boundaries and craft?
- 04Debugging · Generate focused hypotheses from concrete signals / Which hypothesis survives reproduction?
- 05Review · Challenge accessibility, performance, and scope / What does the actual diff and product prove?
The boundaries
Some work should never be delegated blindly.
Credentials, private customer information, patient data, and confidential business material stop at an approval boundary. Generated code also does not get to establish an architectural pattern by accident.
I read what ships. AI can draft quickly, but responsibility cannot be delegated.
The boundary is not anti-AI. It is what makes AI useful without turning convenience into authority.
- 01Input · Approved context · Sanitize and confirm the environment before sensitive material enters a tool.
- 02Design · Deliberate architecture · New patterns require a reason, not merely generated precedent.
- 03Release · Verified ownership · A responsible engineer understands, tests, reviews, and owns what ships.
A practical example
A feature should leave behind evidence, not only a diff.
The final correction moves out of the chat and into the codebase, so the next task begins with stronger context.
- 01User statement · Describe the result in the user’s language.
- 02Repository map · Find adjacent behavior, primitives, state, and tests.
- 03Bounded plan · Expose assumptions, edge cases, and stop conditions.
- 04Draft diff · Delegate mechanics while shaping behavior directly.
- 05Verified journey · Exercise responsive, accessible, loading, empty, and error states.
- 06Reusable rule · Preserve the lesson as a test, token, component, or note.
The result
AI gives me leverage when the feedback loop stays honest.
The value is not that AI can type faster. It is that I can inspect more context, compare more options, and verify more thoroughly—while remaining accountable for every decision. Used this way, AI does not replace the engineering workflow. It makes the workflow more deliberate.