DHSeaDev · Engineering Profile · Companion to the CV
How I Build
What I ship, the process behind it, and where I am actively improving.
This engineering profile is a companion document to my CV that describes the method rather than the résumé. A CV asserts outcomes; this explains the process that produces them — and names, with evidence, the four places it still falls short.
The Record
Client-identifying detail is withheld throughout and workplace systems are described by function. Effort is qualitative — I do not publish invented hour figures.
Court e-filing automation
A browser-automation driver that drafts legal filings into a state court electronic filing system — a legacy web target where a failed run has real consequences. It began as an eight-module pipeline; I recognised the coupling cost and consolidated it into a single deployable file, which became a standing standard in my own methodology. Drafts-only by architecture: a human confirm-gate means the robot never submits an irreversible court action on its own.
It also produced an evidence discipline I now apply everywhere — captures at every gate, and element selectors authored only from live captures, never from screenshots.
AI operations assistant
A sidebar extension giving operational staff an AI assistant over live job data, in production across thirty-plus released versions. Prompt-injection defence over untrusted third-party data was a first-class design constraint rather than an afterthought, and every write back to the system of record sits behind exact-match resolution and a human confirm-gate.
Analytics application and utilities
A desktop reporting platform normalising sixty-six-column operational exports into a canonical field model, with ratio-eligibility and controllability logic encoded in code and every release verified by a headless suite — plus packaged executables built for non-technical colleagues, and a multi-state AI use policy authored as a print-quality document with every legal citation independently verified.
Training simulator for a high-risk workflow
A single-file simulation of an entire multi-step filing wizard, login through mock payment, so new staff can practise a consequential procedure at zero live risk. It grew an assessment layer: append-only per-trainee audit log, automated correctness review, supervisor dashboard, and injection-guarded CSV export. Sensitive fields are never stored, and deliberate divergences from the real system are documented rather than hidden.
Published catalogue and this site
Browser extensions, idle games and desktop apps shipped under my own name — including one hardened by a four-shard adversarial stress test that found and fixed six real defects (unbounded catch-up loop, silent save failure, debounce data loss, malformed-save acceptance, numeric overflow, duplicate export), all six locked into a permanent regression suite. This site carries the shared multiplayer layer, the arcade game, and a search-visibility programme run against a measured analytics baseline — all built and verified in the open.
The Method
“Vibe coding” usually implies improvisation. Mine is the inverse. I have converted the recurring failure modes of AI-assisted development into a registry of versioned, changelogged methodology files that route every task through domain knowledge, mandatory gates and evidence rules. Four properties make it defensible.
1 · Failure becomes infrastructure, on a clock
The governing rule is a two-strike clock: a bug class seen twice becomes a new methodology entry or a mutation of an existing one, that session. The lineage is documented rather than claimed. Repeated blank-panel extension bugs produced a pre-ship validation gate. Spreadsheet type-coercion traps produced a data-hardening reference. A corrupted binary payload seam produced a transit-integrity discipline. Discovering that a test suite asserted the implementation rather than the contract produced a contract-first authoring rule. Each fix is generalised to the bug class, versioned, and routed so it fires next time instead of relying on memory.
2 · Evidence discipline is structural, not aspirational
No completion claim without observed runtime output. A live data sample captured before any field-mapping code is written. Explicit uncertainty tags on unconfirmed claims. Any count I report verified by a second independent method. These live in executable gates, not in good intentions — and the system polices its own honesty: when a review found a mandatory gate being reported roughly a dozen times while the gate file itself was never opened, the fix was a run-it-or-state-what-you-actually-ran clause written into the gate.
3 · The registry audits itself, adversarially
Maintenance passes reconcile claimed versions against deployed ones, sweep every file for stale references to retired entries, verify absorption claims when one entry replaces another, and re-litigate every open gap marker. One recent pass found a dozen unrouted entries, five stale cross-references, and two of its own earlier findings that were simply wrong — both retracted with changelog entries explaining the error. A process that records its own retractions is a process whose other claims can be trusted.
4 · Anti-bloat is enforced, not stated
A new entry must clearly beat extending an existing one. A recent evaluation of proposed additions concluded that zero were warranted and produced five surgical mutations instead. Redundant entries are retired with absorption receipts rather than left to rot. An audit measured the real cost driver — a fixed per-invocation context overhead of roughly twenty-one thousand tokens — and correctly identified entry count, not file length, as the variable to manage.
Independent Validation
In July 2026 the first systematic study of agent skill files as software artifacts gave this process something it previously lacked: an external yardstick. From Anatomy to Smells analysed 238 real-world skills, derived a taxonomy of 13 higher-level and 44 lower-level semantic components, and defined 26 authoring best practices from a review of 29 sources. Three findings, checked against my own registry.
- The taxonomy includes a Lessons Learned component — recording useful lessons for future invocations of a skill — found in 1.3% of the skills studied. That component is the load-bearing centre of my system. I did not know the figure when I built it that way.
- The study’s most prevalent defect is the rationalisation loophole: a skill offering no guidance against the agent skipping its own required steps, present in 94% of skills. My own review had already found exactly that in my stack — a mandatory gate reported a dozen times and run zero times — and had already fixed it structurally.
- Only 7 of the 13 components are governed by any explicit published guidance. Evaluation, where my verification and pre-ship gates live, is one of the six with none. That cuts both ways: the design leads the literature, and it correspondingly lacks external validation.
[ASSUMPTION] Benchmarks showing curated skills can degrade agent performance tested general-purpose marketplace skills. Mine are bespoke to documented failures in my own work, which plausibly places them above the average measured benefit — but that is an inference I have not measured, and I label it as one.
Self-Assessment
| Competency | Grade | Evidence and the honest limit |
|---|---|---|
| Shipping & proof | A+ | A full automated suite green at release; a production AI assistant across thirty-plus versions; automation performing consequential real-world filings; a published catalogue; a live site. No material limit. |
| Learning velocity | A | Roughly two months to productive Python, Qt, async, browser automation, extension platform work, LLM integration and CMS REST work. Limit: a bug class has sometimes recurred two or three times before being formalised. |
| Systems thinking | A− | API response shapes, run evidence and storage concurrency treated as design constraints rather than late discoveries. Limit: formalisation lags the code — patterns get written up after a session rather than during it. |
| Code craft | B+ | Single-file architecture discipline, concurrency guards written before failure, evidence-first debugging. Limits: test-first reflex still forming; rework when a live sample was not captured before mapping code. |
| Architecture & design | B+ | Recognised an eight-module consolidation into one file as an order-of-magnitude maintainability win; cross-platform packaging and distribution. Limit: no formal design gate before a first commit. |
Current Engineering Focus
Four things I am actively working on. Each is here because my own records identified it, and each is stated with the move I am making rather than as a resolution.
Making gates fire, not merely exist
My worst outcomes were never missing gates. They were existing gates that did not fire, because the requirement lived in explanatory prose while the instruction rows that actually get followed omitted it. The fix was structural: every release path now names its review gate in the followed row, ahead of the mechanical checks. The ongoing work is sweeping the whole registry for the same shape. This is my highest-leverage open item and I treat it as such.
Measuring process efficacy instead of assuming it
Published benchmarks report that curated skills can degrade agent performance, and that enabling them helps in only a minority of paired trials. I have not measured the equivalent for my own registry — which entries fired and whether the outcome improved is currently an assumption, not a result. I am adding a per-session firing-and-outcome tally to turn the argument above from reasoned into demonstrated. Making the claim measurable matters more to me than assuming it favourable.
Independently authored test shards for anything that persists data
Tests written from the same mental model as the code assert the implementation, not the contract. I proved this on my own work: a suite passing every case fell to roughly half under independently authored review shards, exposing a silent data-destruction path. Contract-first authoring and a test-power check — reintroduce the bug, confirm the test goes red — are now standing practice. The extension is making independent adversarial review routine for any code that persists user data, not reserved for high-stakes releases.
Treating my own rules as hypotheses
My most useful single lesson is that one of my own standing rules produced a bug. A guard I required on every asynchronous handler is correct only when the redundant call can be discarded; when it carries unique data the correct structure is a per-key queue, and applying the rule blindly destroyed data. It was caught, generalised, and encoded with its boundary condition. Every rule I write now carries its scope of validity, and rules face the same adversarial review as the code they govern. A methodology that cannot be wrong is not a methodology.
Closing
The record is a self-taught developer, months into the craft, shipping production systems with real consequences — inside a methodology built for exactly that purpose.
Every limitation named on this page came from my own records. A process that generates its own critiques, fixes them, and versions the fix is not improvisation. It is engineering, applied to the method as well as the product.
The résumé version
This page covers how the work gets built. The CV covers what the work is, alongside sixteen years of operations experience and seven independently verified references.
Donnie Harding · DHSeaDev · Effort described qualitatively; no hour or cost figures are estimated. Client and employer details withheld. External findings attributed to arXiv:2607.01456.