How I work
A specification first, then agents, then review
I have been writing software for eighteen years. The tools changed; the order of operations did not. What follows is the process I actually run today, and the boundary I keep around it.
The loop
The same six steps whether the deliverable is a feature, a migration or a rebuild.
-
Understand the problem
Before choosing anything: what has to be true when this is done, who depends on it, and what the actual constraint is. On ApiFuel the constraint turned out to be outbound concurrency, not request rate, and that single sentence changed the whole design.
-
Design the simplest solution that satisfies it
Every dependency, service and abstraction is a cost someone pays for years. It gets added when a requirement forces it, and the reasoning is written down so a future reader can challenge it.
-
Break the work into manageable tasks
Small enough that each one can be reviewed on its own and reversed on its own. A task that cannot be described in a sentence is not a task yet.
-
Write the specification, then implement against it
Spec-driven development: the requirements and acceptance criteria exist as text before code exists. That artifact is what later tells me whether the implementation is correct, instead of whether it looks reasonable.
-
Use specialized agents where they genuinely help
Exploration, mechanical refactors, test scaffolding, documentation drafts. Agents are useful precisely where the work is well specified, which is why step four has to come first.
-
Review, test, and take the result
Every diff is read. The tests are mine. Security, data handling and failure behaviour are checked by me, not asserted by a tool. Then it goes to production and I answer for it.
What changes with AI, and what does not
The honest split between what I delegate and what I keep.
Delegated to agents
- Exploring an unfamiliar module and reporting what it found
- Mechanical changes across many files once the shape is decided
- First drafts of tests, documentation and boilerplate
- Comparing options when I already know what the criteria are
Kept, always
- Deciding what gets built and what deliberately does not
- Data models, API contracts and anything other systems depend on
- Reading every diff before it lands
- Judgment on tradeoffs, failure modes and operational risk
- Owning what happens in production
What this actually costs in time
AI compresses the part that used to be typing. It does not compress the parts that decide whether the result is correct — and those are most of the schedule.
-
The specification comes first, and it is slow on purpose
Deciding what has to be true when this is done, what is explicitly out of scope, and how each requirement will be verified. If this part is wrong, generating code faster only produces the wrong result faster.
-
Every diff is read
Not skimmed because it compiled, and not accepted because a test went green. Data decisions, API contracts and security handling get read by hand, line by line.
-
Tests are written, reviewed and run
An agent can draft them. Accepting a test nobody read is worse than having no test at all, because it buys false confidence at exactly the moment you need real confidence.
-
Operational work does not accelerate
Backups, staging, post-deployment verification, rollback paths. That is calendar time, not keystroke time, and no model makes it shorter.
Code that reaches production unreviewed is not faster. It is a deferred cost.
None of this has a fixed duration
The cost scales with the complexity of the problem, not with the number of screens to build. The single biggest variable is how precisely the outcome can be stated: a requirement that keeps moving does not make generation slower, it makes the specification unbounded — and the specification is where the expensive part lives. That is why a client who knows what they want is worth more to the schedule than a faster tool.
What I do not claim
Using AI does not make software correct, secure or maintainable. It changes how fast code is produced, and it changes nothing about whether that code is right. The difference is made by review, testing and operational experience — which is exactly why those are the parts I refuse to delegate.
You can check this instead of taking my word
The decisions behind this site are recorded as Architecture Decision Records, including the alternatives I rejected and why. They are public, dated and written before the code, not after.
Want the details?
The CV has the trajectory; the projects page has the systems.