How I use AI in the work I do for you, and where I draw lines. This page exists because you should not have to ask.
I use AI, and I tell you where
I use AI tooling in my own development work — code generation, refactoring, research, drafting. It makes me faster. It does not make the decisions.
Every architectural choice, every tradeoff, and every line that ships is reviewed and understood by me. If I can't explain why the code is the way it is, it doesn't go in. You are hiring an engineer who uses good tools, not a person forwarding model output.
Your code and your data
- Your code stays yours. I don't train on it, share it, or reuse it across clients.
- I ask before sending anything sensitive to a third-party model. Proprietary code, customer data, and credentials are not pasted into a chat window on my judgment alone.
- If you have a policy, it wins. Some clients prohibit AI tooling entirely, or restrict it to self-hosted models. Tell me and I'll work that way.
What I build for you
The same standard applies to the AI I build into your systems:
- Traceability by default. If a model produced a number, there's a record of which model, which prompt, and what it returned. "The AI said so" is not an answer anyone should have to accept.
- No vendor lock-in. I build provider-portable where it's reasonable, so a price change or a deprecated model is a config change rather than a rewrite.
- AI where it earns its place. Most systems need less AI than the pitch suggests, applied more carefully. I'll tell you when the answer is ordinary software.
What I won't do
I won't ship something I don't understand, claim a model's output as verified when it isn't, or build a system whose failures land on people who can't see them coming.
Questions
If your organization has an AI policy, procurement requirement, or a specific concern, ask me directly — jeb.seibel@yahoo.com.