Every project in this portfolio was built using Claude Code, an agentic coding tool, as the primary development method, not as an occasional assistant. This page is the record of the method, because the methodology is as much a part of the work as any single project. The idea underneath it, people doing the serving while AI absorbs the must, leads the front page; this essay is the practice.
The must is derivative
One property of the must makes the whole division workable: it is a restatement of work that already happened, in another format, for another reader. A status update is the week retold. A training document is the process retold. A requirements matrix is the requirement retold against the code. Producing it takes accuracy, not new judgment, because the judgment was already exercised in the work it describes, and a language model, weak at judgment and strong at faithful re-rendering, fits that layer. Nothing about this is specific to our field: swap the payer for a customer and the must looks the same in any business. Our own team is where the division was proven on real work; whether it holds for every kind of must in the organization is the direction, not yet the record, and the private AI program is the governed path toward it.
Why this approach, here
A nonprofit engineering effort runs lean: a small number of people covering an entire organization’s data and reporting needs. Building a real warehouse, a resilient extraction platform, shared infrastructure, and an evaluated on-premises AI capability with a team our size needed something to change the math, and AI assistance was that something, not a novelty on top of the work, but the difference between what was achievable and what would have stayed a backlog indefinitely.
The working system
Claude Code runs from the command line and can read the codebase, propose changes, edit files, run builds, and execute tests, inside a real version-controlled repository the whole time. Around it sit three things that matter more than the model itself.
The shared skills library keeps the team’s working instructions in one synchronized repository instead of private habits: session openers and closers, a help-documentation builder that captures and annotates real screenshots, a layout auditor, and a text editor that strips machine-writing patterns. The skills that can commit, deploy, or rewrite files carry explicit wait-until-asked language. Project memory lives in git beside the code, committed at every session’s close, so a new session starts already knowing the history instead of being taught it again. And documentation regenerates from the running application and publishes to a URL a colleague can open, while project status updates itself on the monday.com boards the moment work starts, publishes, or releases.
Where the speed comes from
It would be easy to conclude the productivity gain is a model that writes code quickly. That is the smallest part. The real catalysts are the systems above, and what they share is that each moves a recurring piece of the must off a person’s attention. The other half is parallelism, and I think it is the underrated half: a person does tasks one after another, so elapsed time is the sum; the assistant runs work concurrently, a build cycling in the background while the next change is discussed, screenshots capturing while an audit runs. Elapsed time collapses toward the longest single task instead of the total.
None of this removes the person. The must still gets signed by one: a generated compliance artifact nobody verified is a governance failure with better formatting, so the requirements document is read before it goes out, and the traceability findings are confirmed one by one. What changed is the cost of producing the draft, never the responsibility for its accuracy. And the gains stop at the organizational boundary the same way the coding gains do, as the costs essay spells out.
The actual working discipline
Each habit below exists because I corrected it into place after the tool did something I did not want and recorded the correction as a standing rule. The plan is discussed in plain language and approved before any file changes, and that rule resets every session. Design explanations get written into the project’s documentation before the code, meant to be read cold by someone with no memory of the conversation. Extended design discussions stay in an explicit planning mode with decisions saved to a plan file as they land. Communication stays plain, the short jargon-free explanation first and the technical detail after it. And sessions end by recording what happened into memory and a worklog, which is the worklog convention these case studies were assembled from.
Why these tools,
None of the tools were adopted on faith. A separate evaluation project tested 16 local language models against real warehouse work before deciding which two to keep, and its findings shaped every project here: architecture predicted speed better than size, specialization mattered more than architecture, and privacy was verified rather than assumed, by blocking the model server’s network and watching inference still work. Two early single-sample conclusions failed to reproduce, which is where the standing rule came from: nothing that drives a decision rests on one result. The evaluation’s own conclusion was plain: Claude authors the first correct version of something difficult, local models extend a verified pattern across many similar cases, and buying hardware to fix an accuracy problem that routing had already fixed was rejected as the wrong move.
The same evidence-first standard is why a shared skills system exists at all: a documented, version-controlled set of working instructions is auditable in a way private habits are not, and in a HIPAA-sensitive environment, being able to show how AI-assisted work is governed is part of the job. None of this describes an unsupervised process. The tool moves quickly and remembers reliably, but what gets built, what gets rejected, and what counts as done remained a person’s call at every step.