I Build Tools I Actually Need
I donāt build portfolio projects to impress recruiters. Every one of these started because I had a real problem and got frustrated enough to solve it myself.
RepoAudit exists because I kept inheriting codebases and needing to understand them fast. TALON exists because I wanted to evaluate land for real estate investment and no existing tool could answer the questions I actually had. Classifieds Briefing exists because I was planning a mountain relocation and got tired of re-reading the same six classifieds searches every morning, trying to remember whether that ā7.3 dieselā was the good engine or the troubled one. The rest of the catalog follows the same pattern: a real problem, real constraints, and a tool I have to live with afterward.
That last part is why theyāre built with rigor. The alternative is debugging my own shortcuts at 2am.
How I Work: AI-Augmented Development With Engineering Discipline
LLMs arenāt replacing developers. But a developer who actually knows how to use them can ship in days what used to take weeks, and not by cutting corners.
Before Writing Code: Architecture First
I donāt start with main.py. I start with a conversation.
Iāll spend 30 minutes with an LLM sketching out the system, trade-offs between patterns, where the bottlenecks are going to be, whether composition or inheritance makes sense here. The AI pushes back on assumptions I didnāt realize I was making. By the time I write the first line of code Iāve already explored the dead ends and settled on the right approach, which means Iām not refactoring it out of a corner three weeks later.
During Development: Match the Tool to the Task
I use AI-powered IDE tooling to generate boilerplate, catch bugs before runtime, and suggest refactors I wouldnāt have thought of. But I match the model to the work:
- Frontier models for hard architectural calls and deep refactors
- Fast models for autocomplete and repetitive patterns
- Local/self-hosted models for privacy-sensitive codebases and offline work
Iām not dogmatic about any of this. The tooling changes every few months. What doesnāt change is matching capability to task complexity, and not using a frontier model to format a JSON blob.
After Writing Code: AI-Powered Review
I feed whole codebases to LLMs and ask the questions Iād want a senior engineer to ask: where are the circular dependencies, which modules are doing too much, what breaks if this API starts rate-limiting me.
That habit eventually became its own product, RepoAudit, which runs multiple analysis profiles (architecture, security, AI maturity, documentation) against any repo and generates a structured report. The tool I wished existed every time I inherited somebody elseās codebase.
The end result is that I ship features in days instead of weeks, and they still have test coverage, clean interfaces, and solid error handling.
The Quality Engineering Edge
A lot of people building with AI can move fast, but they canāt tell you whether what they shipped actually works. Years in QA gave me a systematic understanding of how software fails, and that shows up everywhere in my work.
Tests Are the Architecture
Most developers write code, then write tests. I write the tests first, then the code.
When I built my Lead Generator I wrote the entire test suite before I scraped a single website. In TALON the test suite is the specification for a hexagonal architecture whose domain layer has zero framework dependencies. If your tests are hard to write, your design is wrong, thatās usually the cheapest signal youāll get, and itās the one most people ignore.
evalharness applies the same instinct to AI systems. An eval harness is a test suite for a nondeterministic system, so I built one the way a test-framework engineer would: every score is a deterministic pure function, baseline runs are committed to git and gate CI like any other regression test, and a retrieval improvement doesnāt get promoted until it survives a held-out split. Most eval tooling asks an LLM to judge quality; mine treats āthe numbers must be re-derivable by anyone, foreverā as the non-negotiable starting point.
Data Is Hostile Until Proven Otherwise
I donāt trust APIs (theyāll change their schema), LLMs (theyāll hallucinate), user input (itāll be malformed), or my own assumptions (theyāll be wrong). Especially my own assumptions.
In BookParser validation gates sit between every component, so when the LLM invents an entity ID that doesnāt exist, the system catches it, logs it, and retries with corrective feedback. In Reddit Research, circuit breakers and rate limiting keep long-running scraping jobs alive when an API has a bad afternoon. In TALON, the LiDAR orchestrator assumes every one of its three government data sources will eventually fail, because every external source eventually does.
Distributed systems break in weird ways. Iād rather handle it upfront than debug it at 2am.
The Five Principles
1. Architecture Enables Speed
Good architecture isnāt gold-plating. Itās removing friction. The 2 hours I spend refactoring to kill a circular dependency is 2 days I donāt spend debugging when requirements change next month (and they always change).
I use established design patterns not because they sound smart, but because theyāre battle-tested solutions to recurring problems: Strategy Pattern for swapping AI providers without code changes, Abstract Factory for ingesting disparate data sources through one interface, circuit breakers for self-healing systems, dependency injection for testability. Under the Hood maps which pattern lives in which project.
TALON is the clearest example. Hexagonal architecture with strict dependency inversion means the domain layer is pure business logic with zero framework imports. Swapping the database, adding a new data source, replacing the LLM provider, none of it touches the core domain. Months of sustained development in, the architecture hasnāt needed a rewrite. It just absorbs new features.
2. Latency Is a Feature
Speed isnāt raw performance, itās perceived responsiveness. When I built Voice Coach, the standard voice pipeline (speech-to-text, then LLM, then text-to-speech) meant 3-5 second round-trips, a dealbreaker for a conversation simulator: a 3-second pause in a sales call destroys the whole point. No amount of tuning fixes a pipeline thatās structurally too slow, so instead of stitching one together I built the app around OpenAIās Realtime API over a direct WebRTC connection, with the backend reduced to minting ephemeral tokens. That got ~500ms responses and natural interruptions. I didnāt invent the transport; the engineering was recognizing which architecture could actually serve the userās experience and committing to it early, rather than shipping the easy version and hoping.
3. Intelligence Belongs at the Data Layer
Raw data isnāt knowledge. In Reddit Research I use semantic clustering to deduplicate insights before anything touches an LLM. If 50 people say the same thing in different words, the system recognizes it as one cluster, cutting LLM calls by ~90% without losing signal.
TALON takes this further. Raw government datasets get enriched at the data layer before a user ever touches them, slope, canopy, soil suitability, ownership classification. By the time a user asks āfind me a south-facing lot with mature hardwood,ā the intelligence is already in the data, the query is just a filter.
4. Privacy Is the Default
I build local-first whenever I can. Chronicle runs entirely on SQLite with zero cloud dependencies. Prism supports local LLMs via Ollama. Voice Coachās transcripts never leave the browser. Cloud sync is opt-in, not mandatory.
5. Every Dependency Is a Liability
A package isnāt free code, itās a commitment: its bugs become my bugs, its transitive dependencies become my attack surface, and its maintainerās account security becomes my problem. One npm install can pull in hundreds of packages Iāll never read, and supply-chain attacks target exactly that blindness. So before I add a dependency, the question isnāt āis there a library for this?ā but āwhat does this buy me that a hundred lines of my own code doesnāt?ā
Sometimes the answer is a lot: Iām not writing my own PostGIS. But my browser tools (JSON Viewer, CSV Viewer, Markdown Viewer, Apex Log Parser) are single-file PWAs with no framework and no build step; JSON Viewer and the Apex Log Parser run on zero runtime dependencies outright, and the others pull in only the focused libraries they exist to wrap, like PapaParse and marked. SF Assistant is a full RAG system in pure Java, right down to a dependency-free test harness running 1,000+ tests, because JUnit would have broken the constraint the whole project was built to prove. Fewer dependencies means less bloat, fewer breaking upgrades, and a supply chain short enough to actually audit.
From Raw Data to Useful Answers
Thereās a pattern across my projects: they start by swallowing messy data and end by answering questions about it.
Classifieds Briefing does it with classified listings. Six regional markets get scraped daily, scored against a tuned buy box, and audited by Claude; what comes out is a briefing that answers the only question that matters: whatās worth driving to see.
TALON does this with government land data. Shapefiles, LiDAR point clouds, soil surveys go in; āfind me a south-facing 10-acre lot with mature hardwood and road frontageā comes out the other side as a natural-language query against enriched spatial data.
RepoAudit does it for codebases. Raw source files go through architecture, security, AI maturity, and documentation analysis, and out comes a structured report that catches things a manual review would miss.
Fast and Correct Are Not Opposites
I take problems from concept to shipped product. AI lets me move fast; QA discipline means what I ship actually works. Moving fast is only useful if what you ship holds up, and rigorous engineering is only useful if you ever finish. Iāve built both habits, and they reinforce each other more than they fight each other.