Three ideas that explain how I approach a system: the real work, the business domain, and where AI belongs.
[01] THE WORK
Most of what I have built sits close to real operations: accounting and finance automation, agricultural campaign management, civic incident reporting, household software with gamification. The domains change; the shape of the work does not. Someone explains how a process actually happens — usually with more exceptions than steps — and the software has to respect that truth instead of enforcing a nicer, wrong one.
I like the unglamorous part: reading the ledger before touching the code, drawing the transaction boundary, and asking what happens on the day the rule doesn't apply. That answer is usually the design.
Field, record, model. Three languages, one pipeline: the part of the work nobody sees is the translation in the middle.
[02] HOW I THINK
Architecture, for me, starts where dependencies point and where failure stops: the business domain at the centre, technology at the edge, the framework replaceable without rewriting the rules. But that is not all of it. Module boundaries, data ownership, what can ship on its own and the qualities the system must hold are architecture decisions too: performance, availability, security, privacy. Those decisions are made in the core, not in how the folders are arranged.
What matters is that a new engineer can trace one request through the system and find nothing pretending to be something else.
Dependencies point in. The adapters know about the domain; the domain knows about none of them. The crossed arrow is the rule that keeps it that way, and the reason a failure has somewhere to stop.
[03] WORKING WITH AI
The framework I work with is ODD (Organic Driven Development). Small work is solved small, in one session and without ceremony; large work leaves one document holding the spec verbatim, and every handoff points at it instead of paraphrasing it, so the work resumes without rebuilding context. At the centre of that framework sits spec-driven development: I start from requirements, the data model and my own instructions, because that — not the code — is the contract the agent must follow.
Then the agent explores, thinks and plans, and that is where I step in: I verify that the plan covers what the software must do, how it should do it, and what sits behind it at the architecture level, not the framework. Only then does the AI act, test-first by default: every rule I request enters with a failing test first and then passes. That is not TDD as a design discipline; it is the evidence that what was asked for is there.
AI amplifies decisions; it does not make them. The real work isn't asking for code; it's writing the contract that leaves nothing to assume.
Documents and my instructions open the flow; the agent explores and plans; I verify before it acts. Rejection is not an error state — it is the normal outcome of a failed verification.