I am not a developer. I studied immunology.
In the last year I’ve built three systems I use every week. None of them required me to write code by hand.
What matters
Building practical AI systems is less about transformer architecture and more about four skills analytical people already have:
- Problem decomposition. Turn a messy problem into small, testable steps. This is the whole game.
- Prompt design. State intent clearly enough that a reasonable reader cannot misunderstand you. Scientific writing was good training for this.
- System thinking. Autonomous parts fail in weird ways. If you have run a lab, study, or team in production, you already know the feeling.
- Judgment about automation. Know when to automate, when to keep a human in the loop, and when to kill the idea.
That’s the skill stack. Now the systems.
System 1: A Mandarin deck
The one I touch most is a language-learning app. It started as a single HTML file: thousands of vocabulary cards, tone-marked pinyin, examples, breakdowns, and etymology notes.
There is no backend. No API calls. The SRS logic is vanilla JavaScript. Progress is stored in localStorage. Audio uses the Web Speech API at multiple playback speeds, so I can slow a sentence down until I hear every tone, then play it back at normal pace.
HSK 3.0 is the backbone. I added food, restaurants, Hong Kong terms, transport, slang, filler words, and the small vocabulary that shows up in real conversations before HSK teaches it.
Two things happened during the build that taught me more than the rest of the work combined.
The first was a data problem. I started on an older HSK draft. Weeks later, the official November 2025 list landed with different entries and counts. The fix was not a patch. It was a migration: rebuild from the authoritative source, drop nonstandard words, add missing ones, and remap every example to its new index.
What I took from that: your data will be wrong at some point. The job isn’t to prevent that. It’s to build the verification step that catches it before you lose trust in your own system.
The second was quieter. Toggling a word between SRS stages silently reset its ease factor and review interval. One click could erase weeks of earned data while the display still looked fine. The fix was a four-path state machine: no-op if the stage did not change, fresh defaults only for new words, promotions only raise thresholds, demotions cap intervals without touching accuracy history.
Both lessons came from treating the build like an experiment: find the failure, write the test, move on.
System 2: A retirement calculator
The second system is a client-side retirement tax model I built for a family member. Enter accounts, Social Security estimates, and spending assumptions. It projects year by year across federal tax, California tax, IRMAA, ACA subsidies, and Social Security provisional-income math.
It exists because most retirement calculators use a single static withdrawal rate and ignore the interactions between tax systems. Those interactions are where the actual money lives.
Take the ACA cliff. In 2026, a single filer crossing $62,600 of income by a dollar can lose every cent of their ACA subsidy. For someone retiring at 56 with a nine-year bridge before Medicare, that cliff can be worth six thousand dollars a year in healthcare premiums. Most software doesn’t warn you that your Roth conversion strategy just blew through it.
Under the hood, each simulated year runs a constraint loop. It resolves ACA thresholds, IRMAA tiers, and federal tax brackets before locking in the withdrawal plan. Several MAGI definitions run in parallel because each program defines income differently. Monte Carlo handles market variance. The projection table flags cliffs before you hit them.
The thesis is unfashionable: the 4% rule is 1990s math for a 30-year retirement. A 40-year horizon looks different. A guardrails-based approach can start higher, but only if you will cut spending during bad markets.
I did not write numerical libraries from scratch. I decomposed the math into modules: federal tax, state tax, IRMAA, ACA, Roth conversion, capital gains, RMDs. Claude Code built each module with tests. The hard work was reading the domain rules and deciding how they interact.
The point of the model isn’t to be right. It’s to make the tradeoffs visible. When you can see that one extra dollar of income costs thousands in subsidies, you stop arguing with the model and start planning.
System 3: A research vault
The third system is an Obsidian-style vault for my digital security education work. Source transcripts live in one folder. Insight notes with verbatim excerpts live in another. Topic files on hardware wallets, threat modeling, inheritance, and backups are the distilled output I write from.
Slash commands move information between layers. One pulls a YouTube transcript. Another turns it into an insight note and warns me about duplicates. Another promotes daily notes into permanent registers. Another rebuilds a topic file from the insight notes behind it.
The key discipline is the Golden Quote rule: every sourced claim needs verbatim excerpts from the original. No paraphrasing claims of fact. If firmware changes later, I can patch the downstream material instead of second-guessing my own memory.
Before this, my research was forty browser tabs I would lose by Friday. Now every claim has a trail. It is not glamorous. It is foundational.
The point was not the model. It was treating the vault like code: rules, reviews, and a verification pass before anything ships.
The real skill
Problem decomposition. That’s the skill that transfers from any analytical background into building useful systems with AI. Science, finance, operations, consulting, legal work, medicine. If you’ve ever designed an experiment or built a process, you already have the foundation.
The people getting the most out of these tools are not the strongest programmers. They’re the clearest thinkers.