Skip to content

AI in Our Engineering

We use AI assistance heavily in our engineering work. This page says how, and — more usefully — what it is not allowed near.

We would rather be specific than quiet about it. Anyone reading our documentation or our commit history can see AI in the loop; a vendor being vague on the subject is the one worth asking harder questions of. The useful question is not whether a supplier uses AI in 2026. It is whether they can tell you where the boundaries are and who is accountable for what ships.

What it never touches

The limits come first, because they are the part you are actually assessing:

  • No customer data. AI tooling is not given your data — not operational data, not configuration exported from your systems, not log extracts. If a diagnosis needs your data, it is done against your data in your environment or in a support channel, not by pasting it into an assistant.
  • No production credentials. AI tooling holds no production secrets, keys, or tokens.
  • No secrets or network topology in context. What we do share with a tool is reviewed first. Credentials, key material, and internal network topology are excluded by policy, not by habit.
  • Not an autonomous actor in our release path. Nothing reaches a release because an AI decided it was ready.

Where it genuinely helps

The honest list, because "AI-powered" as a blanket claim is worth nothing:

  • Documentation. Much of our written corpus is AI-assisted, and it is why the documentation is structured the way it is — stable terminology, explicit cross-references, one subject per document. That structure serves human readers first and makes the corpus retrievable for reasoning second.
  • Code assistance. Drafting, refactoring, test authoring, and translating upstream SDK changes into our own code. The work an engineer would do, done faster, and then reviewed.
  • Reasoning across a large estate. Our architecture, decisions, and operational knowledge span many repositories. Being able to ask questions across the whole of it — and get answers that cite the record rather than a recollection — is a real advantage for a small team supporting production software.
  • Tooling design. We build command-line-first, composable tooling partly because it is good engineering and partly because it is automatable by both people and machines.

Human accountability

AI changes how quickly work gets drafted. It does not change who is answerable for it.

  • An engineer reviews AI-assisted code before it is deployed. Review is the gate, and it is performed by a person.
  • Architectural decisions are made and recorded by people, with the alternatives that were rejected and the conditions that should reopen the decision. AI helps write the record; it does not own the choice.
  • Releases are gated on tests, not on confidence. A hermetic suite runs in CI on every change and again at release, and a final acceptance tier runs against a real source system on an engineer's host. Those results are captured as an attributable evidence bundle naming the engineer and machine that produced them (see Compliance posture). AI speeding up authorship does not loosen that gate — if anything it is the reason to keep it.

The same principles that govern the rest of our engineering apply here without exception — least privilege, secure by default, and reviewed change. See Security posture.

Where this is going

We expect to extend AI assistance further into our own operations over time, and to do it under the same constraints: scoped access, human approval for anything outward-facing or destructive, and an audit record of what was done and by whom. We are not going to describe capability we have not built — when it is running, it will be documented here like anything else.

What you can ask for

If your organization has a position on supplier AI use — many now do, and the good ones are specific — these are available on request:

  • The specific AI tools we use and the commercial terms they operate under.
  • Our internal AI usage guardrails, as written for our own engineers.
  • Contractual constraints on AI-assisted handling of your data or your engagement. If you have a requirement here, raise it during contracting so the commitment is written down rather than assumed on either side.

Reach us through the Endeavor Engineering resources hub or your usual Endeavor Engineering contact.