AI, your code,
and your IP.

Yours to use, modify, and deploy

The custom work I deliver is contractually assigned to you at handoff: the source code written for your project, infrastructure definitions, architecture diagrams, documentation, and test suites. You can run it, change it, extend it, hand it to another developer, or build your product on it, and none of that requires my involvement or permission.

Like many working engineers, I bring my own toolkit to every project: reusable libraries, utilities, and development tooling built over years of this work. Where any of that ends up embedded in your system, the project agreement grants you a license broad enough to operate, modify, maintain, and extend the delivered system as your own. The toolkit itself stays with me, which is what lets me deliver at this pace for every client. Third-party and open-source components follow the same principle: they remain under their own licenses, and I document what your system uses so your team knows what it inherited.

The choice of contractual assignment over copyright framing is deliberate. In January 2025, the U.S. Copyright Office concluded that AI-generated content produced without sufficient human creative control is not eligible for copyright protection, and that prompts alone do not constitute that control. In March 2026, the Supreme Court declined to hear Thaler v. Perlmutter, leaving that position as settled doctrine. What the threshold looks like in practice (whether code produced with AI assistance meets the bar for sufficient human contribution) is still being defined case by case. Rather than build your rights on a claim that may or may not hold, the project agreement assigns your deliverables to you contractually. That instrument works regardless of how copyright doctrine continues to develop for AI-assisted work.

Confidentiality

I treat client code, architecture decisions, credentials, and business context as confidential by default. Client work doesn't get discussed with other clients. I keep credentials in your systems or in a secrets manager under your control, and I keep architectural details to the people working on the project. The binding confidentiality terms are set in the project agreement before any work begins.

What tools I use and for what

The primary AI tool is Claude Code. I use it to accelerate code generation, test scaffolding, refactoring, and documentation. AI output goes through my review before it's committed. I don't commit code I haven't read, and I don't accept AI-generated test suites as a substitute for understanding what they're actually testing.

For clients with compliance requirements or security policies that restrict AI tooling, I can work without it. That option is available from the first conversation.

Judgment and accountability stay with me

The engineer who designs your system, writes the code, and delivers the handoff is me, not a model. AI accelerates the work; it doesn't make the decisions. Architectural choices are mine to defend, and the code I ship is code I've reviewed and stand behind.

If something in a delivered codebase turns out to be wrong, it's mine to answer for. That accountability doesn't get distributed across a toolchain.