Where AI helps us, where it doesn't, and what we promise about your data
Every agency on the planet says “we use AI”. That sentence is meaningless on its own. This page is the contract behind it: which tools, which models, where they touch your code, where they don't, and what we do to keep your data out of training sets.
Last updated 2026-04-15
The rule of thumb
AI is a co-pilot, not an autopilot. A human engineer is responsible for every commit, every deploy, and every architectural decision. AI accelerates the work; it does not sign off on it.
Where we use AI
- Boilerplate scaffolding. Routes, types, forms, schemas, fixtures, migration stubs.
- Design exploration. Generating multiple visual directions before a senior designer narrows down.
- Test generation. Drafting unit and integration tests in parallel with feature work; reviewed before merge.
- Documentation. Generating handover docs and changelogs from the diff so the artefacts stay current.
- Code search and explanation. Onboarding to your repo, mapping unfamiliar codebases, summarizing PRs.
- Refactor proposals. AI drafts a refactor plan, a senior engineer accepts, modifies, or rejects it.
Where we never use AI alone
- Architecture decisions. Trade-offs are debated among humans, written down by humans.
- Production deploys, secrets, infra changes. AI can suggest; only an engineer with the right access executes.
- Critical-path code review. The reviewer of record on the PR that ships is always a senior engineer.
- User-facing copy that names you, your customers, or your numbers. Written by humans.
- Legal, compliance, and security review. Not an AI call, ever.
- Critical debugging where being wrong is expensive. AI is a second opinion at most, not a first.
Models and providers
We currently route AI work through enterprise plans of:
- Anthropic Claude (Opus, Sonnet, Haiku): primary for code, refactoring, planning, and longer reasoning.
- OpenAI (GPT-4 family, o-series): secondary for code completion and structured tasks.
- Cursor and Claude Code: IDE assistants used by every engineer, configured against the providers above.
- Self-hosted Llama / Qwen models: used in isolated environments when client data cannot leave their VPC.
We re-evaluate this list every quarter. The current pick is on the methodology hub.
Data handling
All AI providers we use are configured with:
- Zero data retention on prompts and outputs, where the provider supports it.
- No training on your data, your code, or your prompts.
- EU and US data residency options picked per client based on contractual requirements.
- Enterprise SSO and audit logs on every account, so we can show who ran what and when.
For clients with stricter compliance needs (regulated industries, sovereign data, defence), we will run on self-hosted open-weight models inside your environment.
Disclosure on every project
At project kick-off you will receive an AI usage statement tailored to your engagement, covering:
- The exact tools and models that will touch your code.
- The data classes that will and won't leave your environment.
- Sub-processor list for the engagement.
- Any open-source licenses introduced through AI-suggested code.
If you want any of these turned off, we turn it off and adjust the timeline. We'd rather quote a slower project than make assumptions on your behalf.
Quality controls
AI-generated code has predictable failure modes: hallucinated APIs, plausible-but-wrong logic, weak edge-case coverage. Our standard guardrails:
- Two-pass review. AI draft → engineer rewrite → senior review. AI never writes the final commit alone.
- Test gates. Generated tests must run, fail meaningfully, and cover the new code paths.
- Static analysis. TypeScript strict, ESLint, and language-specific linters block AI-suggested anti-patterns.
- Security review. Any prompt that touches auth, payments, or PII pipelines goes to a senior engineer regardless of AI confidence.
Open-source and licensing
We track license attribution on every AI-suggested snippet. If a generation looks substantially similar to a known open-source project, we attribute it or rewrite it from scratch. We don't ship code with mystery provenance.
What we publish
With your permission, we publish anonymized prompts, evaluations, and methodology pieces from your engagement on our public methodology hub. We strip names, customer data, business metrics, and anything you flag as confidential. Your SOW can disable this entirely if you prefer.
Changes and contact
This policy evolves with the model landscape. We update it whenever a meaningful new provider, model, or capability enters our delivery stack. Questions about how AI is used on your specific project go to ai@yateweb.com. Your engineering lead will reply.