Every project described in this portfolio was built using Claude Code, an agentic coding tool, as the primary development method, not as an occasional assistant brought in for small tasks. This describes the actual tools and working discipline I use, since the methodology itself is as much a part of the work as any single project.
Why this approach, specifically here
A nonprofit engineering effort runs lean by nature, a small number of people covering an entire organization’s data and reporting needs, without the headcount a comparable initiative would get somewhere larger. That constraint is not a complaint, it is just the actual condition I work under, and it shaped my approach directly.
Building a real data warehouse, a resilient extraction platform, shared application infrastructure, and an evaluated on-premises AI capability, from the ground up, with a team our size, would not have been realistic without something changing the math. AI assistance was that something. Not a novelty layered on top of the work, and not a replacement for the judgment behind any of it, but a genuine force multiplier: the difference between what was actually achievable with the people available and what would have stayed a backlog indefinitely.
The core tool
Claude Code runs from the command line and can read a codebase, propose changes, write and edit files, run builds, and execute tests, all inside a real development environment rather than a chat window disconnected from the actual project. We built every project in this portfolio through sessions with this tool, working from a real, version-controlled repository the entire time.
A shared skills system across our team
Rather than each person building their own private habits and prompts,
we maintain a single shared repository of reusable instructions,
called the Shared AI Skills Library, that every team member’s machine stays synchronized
with through git. A setup script installs these as either slash commands,
invoked explicitly by typing something like /session-done, or as
skills, which Claude Code can choose to use on its own when a task matches
what the skill describes. The distinction matters: some of these skills
commit code, deploy applications, or rewrite files across an entire
project, and their descriptions explicitly say to wait until asked before
acting, rather than firing unprompted.
The actual skills in use include one that starts a session by pulling the latest shared skills and project code and loading both global and project-specific memory silently, one that closes out a session by syncing memory files into the repository and committing everything, one that builds and maintains an application’s in-app help documentation end to end, including capturing and annotating real screenshots, one that audits an application’s screens for layout and alignment problems and fixes what it finds, and one that edits written text to strip out patterns typical of AI-generated writing, so that documentation and explanations read as something a person actually wrote rather than something generated and left unedited.
Project memory that survives across sessions
Each project keeps a folder of memory files that persist across conversations, since a single chat session has a limited amount of context and eventually needs to end or compact. These files record the current state of the project, standing corrections about how I prefer to work, and durable notes about specific design decisions, so that a new session starts already knowing this history rather than requiring it to be explained again from scratch every time.
The actual working discipline
The habits below are not abstract principles. Each one exists because I explicitly corrected it into place after the tool did something I did not want, and I recorded the correction in the project’s own memory as a standing rule for every future session.
I discuss the plan before any code gets touched. Before it writes or edits a single file, the assistant describes the plan in plain language, and work only proceeds once I have explicitly approved it. This rule resets every session, even when I had already discussed and agreed to the same fix before a prior session ended.
Design explanations get written into the project’s own documentation before the corresponding code is written, not just explained once in conversation and then forgotten. A verbal explanation given inside a chat is easy to lose once that conversation ends. The habit adopted instead is to write any real design explanation into the relevant documentation file, in plain language, using ordinary analogies rather than pure jargon, before moving on to the code itself. The documentation this produces is meant to be read cold, by someone with no memory of the conversation that produced it.
Extended design discussions stay in an explicit planning mode, with decisions saved continuously to a persistent plan file as the discussion evolves, rather than trusting the conversation itself to remain available indefinitely. Coding only begins once I explicitly say to proceed.
Communication itself stays plain, a short, jargon-free explanation of what is being done and why comes first, with technical detail placed afterward rather than in front of it. Heavy technical detail presented before the plain explanation reads as less trustworthy, not more, since it buries the actual reasoning under language that has to be decoded first.
Sessions end by recording what happened, not by reciting it back. Completed work gets summarized into the project’s own memory and worklog, not repeated back conversationally at the start of the next question. The worklog convention behind the case studies in this portfolio is itself built on this same habit, a short, structured account written at the close of each working session, which is what these project write-ups were assembled from.
Why these tools, specifically
None of these tools were adopted on faith. The clearest evidence of that is a separate internal evaluation project that tested seven different local language models against real warehouse work, T-SQL, dbt, DAX, Crystal Reports formulas, before deciding which two to actually keep running.
That evaluation is worth describing here because it explains the reasoning behind the whole approach, not just one project. A few findings from it shaped how every project in this portfolio uses AI assistance:
Architecture matters more than size. Every dense model tested ran slower than every mixture-of-experts model tested, regardless of overall parameter count. A model’s active parameter count, not its total size, predicted its speed almost perfectly.
Specialization matters more than architecture. A general-purpose model and a code-specialized model from the same vendor, same architecture, same size, were tested against the same twelve coding tasks. The specialized version produced usable code in ten cases. The general version managed one.
Findings were not trusted on a single sample. Two early conclusions from single-sample testing later failed to reproduce entirely, one model was initially marked as failing an Excel task and then passed it perfectly on retest, and a different model was briefly credited with fixing a hard DAX problem based on one lucky result, then scored zero out of three on a proper retest. Anything that actually drove a decision in that evaluation was confirmed across multiple samples before being trusted, and that same discipline, do not believe a single result, carries into how every other tool decision in this portfolio gets made.
Local models complement Claude rather than replacing it. The evaluation’s own conclusion was plain: Claude authors the first correct version of something genuinely difficult, a slowly changing dimension load, a tricky filter-context measure, and local models handle the repetitive work of extending a verified pattern across many similar cases. Buying more powerful hardware to fix an accuracy problem that routing already fixed for free was explicitly identified and rejected as the wrong move.
Privacy was verified, not assumed. The claim that local model inference never sends data outside the organization’s own infrastructure was tested directly, including blocking all outbound network traffic for the model runtime and confirming inference still worked correctly with no external connection at all.
The same evidence-first standard applies to why a shared skills system exists across our team rather than everyone building private habits individually: a documented, version-controlled set of shared instructions is auditable and consistent in a way that individual, undocumented habits are not, which matters in a HIPAA-sensitive environment where being able to show how AI-assisted work is actually governed is itself part of the job.
None of this describes an unsupervised process. Every plan is reviewed before code gets written. Every design decision that matters gets a real discussion with me, not a rubber stamp. The tool moves quickly and remembers project history reliably, but the judgment behind what gets built, what gets rejected, and what counts as done throughout this portfolio remained a person’s call at every step, not the tool’s.