How I work

1. 01

   Understand before building

   Every job starts with understanding the problem: what the product must do, which business rules govern it, what counts as a correct result. Writing code before understanding the problem is a recipe for rework. I define acceptance criteria before implementing — what must be true when I'm done.

2. 02

   AI in the process, not in place of judgment

   I use AI as part of the development flow: investigating code, proposing plans, executing bounded tasks, generating checks. Every contribution passes independent review — what AI produces, the process verifies. AI accelerates execution; architecture, scope, and trade-off decisions stay human.

   Honest distinction: I have hands-on experience in AI-assisted engineering; AI-powered products are my area of study, not a credential I claim.

3. 03

   Delegation with separated responsibility

   When work splits up, each part has its own goal, closed scope, and exit criterion. Whoever executes doesn't approve their own work: investigation, execution, and verification are distinct responsibilities, even when the same person — or the same AI session — goes through all of them at different times.

4. 04

   Independent review and process testing

   I review against the source, not the summary: diff, tests, and evidence beat narrative. Tests verify behavior before and after the change, when feasible — fail first, pass after. I check completeness at the end: nothing partial declared done.

5. 05

   Automated checks and preserved context

   Repeatable checks become automated routine — local gates that must be green before anything ships. Decisions and context live in versioned documents, not in a session's memory: anyone (or any future session) picks the work back up from the written record.

6. 06

   Learning from mistakes

   A documented mistake becomes a rule or a gate. Each process failure produces a concrete change: a sharper acceptance criterion, a new check, a recorded constraint. The current process is the accumulation of past mistakes, written down.

• cost

  Process has a cost: planning, review, and gates make the start slower in exchange for less rework at the end. For trivial tasks, I apply the process proportionally — full rigor on everything would be bureaucracy.

• domain

  AI doesn't replace domain knowledge: in an unfamiliar business, the first task is to study, not to delegate.

• secrecy

  I don't present internal metrics from professional work as public proof: what is confidential stays confidential.

scope note — this page describes my process in general terms. Internal details — metrics, tickets, clients, corporate systems — are confidential and don't appear here.