What the job waskept changing.
Seven times, roughly. Each one left something behind that is still in use.
The short version: composition, then a storefront that could not go down, then code, then people, then systems, then models. The part that surprises people is the law degree, and it turns up about two thirds of the way down.
01Origin
Composition first.
The first thing I was any good at was looking. Framing, sequence, what to leave out — design work, and a long habit of watching films closely enough to follow how a scene was assembled rather than only what happened in it.
That is not a detour from the engineering. Deciding what someone sees first, and what they should never have to see at all, is the same decision in an interface as it is in a shot. Curiosity did the rest — taking a thing apart is still how I learn what it is.
Every system since has had its interface designed by the same person who built it.
02The storefront
Live means live.
Administering a live commercial storefront. Content, configuration, theme settings, catalog housekeeping — no code yet, and none needed for most of it.
What that year taught was not a platform. It was how a production system behaves once real customers are inside it: a change is never only a change, the hour you make it in is a real constraint, and “it worked when I checked” is a claim about one screen and nothing else. Everything downstream of that — dry runs, verification gates, non-destructive releases — is the same lesson with better tools.
Respect for the moment a change reaches somebody who did not ask for it.
03Code
Configuration ran out.
Every settings panel has an edge. Past it, the change you want is not an option on a form, and you either accept the theme's opinion or write the behaviour yourself.
First production Liquid, then HTML and CSS, then JavaScript that changed what the store did rather than how it looked. None of that first year was elegant. It was the year the work stopped being configuration and became authorship — and the year I stopped asking whether something was possible and started reading the source to find out.
A preference for owning the behaviour over negotiating with somebody else's abstraction.
04Direction
Most of it was not code.
Leading web development meant the queue stopped being only mine: release QA on a store that cannot go down, third-party vendors, stakeholders fourteen hours away, and technical screening for engineering hires.
The pattern took a while to admit. A large share of what arrives looking like a development problem is a communication problem wearing its clothes — an assumption nobody stated, a rule that lives in one person's head, a decision made in a meeting and never written down. More code does not fix those. It usually buries them somewhere harder to reach.
Design documents that record what will deliberately not be built, and runbooks written so a tool is not owned by its author.
05Systems
The same hour, every week.
The internal tools all started the same way — watching a step happen by hand for the third time. A planning team queuing behind a developer for the same order export. A merchandising threshold that existed only in one person's memory. A seasonal catalog drop moved across, image by image.
None of it is difficult, which is exactly why it survives: never urgent enough to fix, and never finished either. Turning one into a system means giving it a name, a rule somebody else can read, a dry run, a test, and an owner afterwards. The tools are on the work page. The habit is the part worth reporting here.
The destructive step should be the one you can inspect before it runs.
The degree is in law, which turns out to be unusually useful for regulated-domain software.
Payroll tax, social-security contributions and employee-data access control are statutory-interpretation problems before they are engineering problems. The hard part is not computing a bracket. It is deciding which rule governs, in what order, for whose situation — and being able to show the reading you committed to, months later, to somebody entitled to ask.
That is the same work as reading a statute: find the operative rule, then its exceptions, then the definitions the exceptions turn on, then write the interpretation down somewhere it can be checked against. Encoding it afterwards is the comparatively mechanical half.
It is one advantage in one class of problem. It does not replace engineering, and nobody should be their own lawyer about their own software. But when the specification is a national regulation and the requirement is that a decision stays explainable years later, it is a better first instinct than most.
- Statutory payroll
- Which rule applies to this month, at which rate, in what order — and a result that carries the rule snapshot that produced it.
- Social-security contributions
- Contribution bases, per-relative additions and thresholds, each of which is a definition before it is a formula.
- Employee-data access
- A personal-data regime that asks for demonstrable control over who may see what, which is a permissions model written by somebody else.
06AI
Not an answer generator.
Models go where judgement is genuinely wanted and stay out of where they would add risk. In the ads pipeline that boundary is literal: a deterministic engine makes every keep-or-pause call from thresholds held in one config file, and the model is allowed only to explain the call in language a person will read. Two hard vetoes sit above it, so it cannot talk a product into having no live coverage.
The interesting part of this work is rarely the prompt. It is the boundary — what a model may decide, what it must never contradict, and what the system does on the day it is confidently wrong. Prompt versions are kept side by side for the same reason rule engines are versioned: so you can say which one produced a given answer.
A threshold belongs in a config file — not in a prompt, and not in a reviewer's head.
Spec first. Agents second. The release decision is mine.
Much of the recent work was built spec-driven: a written specification that pins exact shapes, rule ordering and the alternatives already rejected, then AI coding agents implementing against it in parallel lanes. Saying so is not a disclaimer. Who typed a line is the least interesting question about a system that has to still be right in a year — who is accountable for the architecture, the rule interpretation, the safety regime and the decision to release is the one that matters.
Nothing is delegated until the rules are settled.
MINE
- The domain model, and the rule interpretation agreed with the people who own the rules
- Exact shapes, rule ordering and performance budgets, pinned before anything is written
- The alternatives rejected on purpose, recorded so they are not re-litigated later
- Nothing. A specification an agent wrote for itself is not a specification.
07Now
AI and automation, with the direction attached.
The current work is engineering the internal systems a company runs on: an HR and statutory payroll platform in live production after a cutover, with the legacy workbook kept deliberately as the reconciliation reference, and an ads-review pipeline putting a constrained model downstream of a deterministic engine. The formal title is AI Project Manager, which describes the one part of the job that is not the work.
None of this route was planned. Read forwards it is a series of accidents. Read backwards it is fairly legible — composition, then production, then authorship, then people, then systems, then models, and underneath all of it a training in reading rules carefully and writing down what you decided they meant.
Everything above, still in use.
Tennis early. Football with people who take it far too seriously. The gym most days. Films, still, and closely.
Some of it gets filmed and posted. The content side is a genuine habit rather than a strategy, and it is where the composition half of this page goes when it is not being spent on an interface.
Based in Bali, working in WITA. Generally easier to reach than the infrastructure.
The systems are the better argument.