Approach
How I build
Five principles that guide how I design, test, and improve software, with examples from the projects where I applied them.
Enforce safeguards in the architecture
A rule enforced by convention depends on every developer remembering it. A rule enforced by the database, or by the shape of the system, applies on every code path.
Authorization rules live in PostgreSQL row-level security policies, which restrict access to family records at the database level instead of in each screen's code. Security tests sign in as different roles against a real database, and the suite held 110 checks at the September 2026 audit.
Files are read and processed in the browser with pdf-lib and pdf.js, and the app has no upload endpoint, so file contents are not sent to this site's server. Page loads, analytics and the optional signature fonts are ordinary web requests.
Keep critical decisions grounded in explicit rules
AI is well suited to ranking, explaining and drafting. For decisions that affect someone's access to money, housing or aid, I keep the decision in rules that can be read and tested, and use the model to rank and explain the results.
A deterministic engine evaluates GPA, credits, income and citizenship before any AI is consulted, and the model then ranks and explains the matches. The model does not determine eligibility, and the program's agency still makes the final decision.
The daily snapshot comes from a deterministic scoring engine with no model in the scoring path. Each signal's contribution is shown against a neutral baseline, so the explanation and the score come from the same thresholds.
Design for uncertainty and failure
What a system does when it fails, or isn't sure, matters as much as the happy path. A system that can't say it is unsure will say something confident instead.
Each recommendation shows a match score, a confidence band, the reasons it matched and the licensed source. The score is the track's result under the scoring mode the listener picks (genre, mood or energy), with a breakdown they can open. The confidence band summarizes how strong that match is; it is not a calibrated probability that the listener will like the track.
Visa requirements come from a commercial API. When its quota runs out or it is unavailable, the server falls back to Gemini and tags the answer with its source. The interface then labels it “AI-assisted travel guidance” and asks travelers to confirm entry requirements with the destination's official immigration authority or embassy.
Validate the data and assumptions behind the tests
A passing suite shows that the cases it covers behave as expected. It can't show that the data and assumptions behind those cases are right, so I check both: dataset integrity, label semantics, and whether each regression test fails against the defect it was written for.
A data-quality pipeline found a label-decoding defect affecting nearly 19% of annotations that 78 passing tests had missed. Correcting the decoder raised verified IoU from 34.4% to 42.5% with the model unchanged, so it was an evaluation correction, not a model improvement. The suite now has 141 automated tests (up from 66), including dataset-integrity checks, and each regression test was confirmed to fail against the original defect.
Communicate results and limitations clearly
A result is only useful if the reader knows the conditions it holds under. I state the sample, the metric and the intended use next to the number, and remove claims the data can't support.
Ships a claims register that records each removed claim and why: a confidence percentage that began as a hardcoded 65, a figure for how many hours someone could sustainably work, and a burnout forecast. A test fails the build if the forbidden wording returns.
Segmentation figures are published with their conditions: a research prototype evaluated on 18 held-out images with a strict overlap metric, on a dataset where crack pixels are 1.6% of the total. It is not intended for safety-critical decisions.
I use AI where it adds value, such as ranking, explaining and drafting, and I keep decisions that need to be explainable in rules I can read and test.