AI in Engineering at Xelix

Sean Oldfield - Senior Frontend Engineer

Preamble: how AI has changed software

AI has quickly moved from an experimental productivity aid to a practical part of modern software delivery. It can now help engineers explore unfamiliar code, generate implementation options, automate repetitive tasks, write tests, review changes, summarise context, and accelerate learning. Used well, it reduces friction across the development lifecycle and gives teams more time to focus on judgement, design, collaboration, and customer outcomes.

At the same time, we believe AI has not changed the fundamentals of good software engineering. We still need clear problem definition, maintainable architecture, thoughtful product trade-offs, secure implementation, reliable testing, and careful review. I don’t think anyone will question that AI has increased the speed at which we produce code, but speed only creates value when the output is correct, understandable, secure, and aligned with our standards.

For Xelix, the opportunity is not simply to “use more AI”. The opportunity is to use AI deliberately: to raise the leverage of our engineers, improve delivery quality, and help teams move faster without weakening the engineering discipline that our product depends on.

Our philosophy at Xelix

Our philosophy is that AI should be an impactful tool in the hands of capable engineers. AI is not a replacement for quality engineering work.

We want teams to feel confident using AI where it helps: shaping ideas, exploring approaches, orienting in the codebase, reducing boilerplate, improving documentation, identifying edge cases, and rapidly ideating on ideas. We should treat it as part of the engineering toolkit, alongside IDEs, testing frameworks, observability tools, design systems, and code review practices.

“Why did you do that?”, “Well Claude decided”

Accountability remains with the engineer and the team. AI-generated code should be held to the same standards as any other contribution. It must be understood, reviewed, tested, maintainable, and appropriate for the problem being solved.

We try to keep our approach balanced:

We encourage experimentation, but experiments are not the same as production solutions.
We value speed, but not at the cost of reliability or maintainability.
We use AI to amplify engineering judgement, not bypass it.
We aim to make AI adoption inclusive, shared, and transparent across the team.

The best use of AI at Xelix is not to replace engineering, but to make it more deliverable.

Maintaining quality

As AI increases the pace of code generation, our quality practices become even more important. Our goal has always been to create a development environment where AI can help us move fast while our engineering systems continue to protect the product, the customer experience, and the long-term health of the codebase.

This is where the idea of Xelix’s engineering harness becomes important. A harness is the set of technical, procedural, and cultural guardrails that surrounds engineering work and helps steer it towards safe, reliable outcomes. The stronger this harness is, the more effectively we can use AI. Without it, faster code generation can simply mean faster accumulation of risk.

Codebase Routing

We have embedded documentation in our codebase to support AI-assisted work. This works alongside tooling harnesses from platforms including Cursor and Claude Code. This means each of our key repositories has opinionated rules and guardrails built directly into the development workflow. These are exposed directly through AGENTS.md with dynamic routing to direct AI agents based on the desired work.

          ## TASK ROUTING — READ THE MATCHING DOC BEFORE WRITING

`ai-docs/*.md` are the canonical deep-dives. This file is only the constraint summary.

- Always read the `ai-docs/*.md` row(s) that match your task BEFORE planning or writing code — only the matching rows, not every doc.
- If a task spans multiple rows, read each matching doc (only those that apply).
- When delegating to a sub-agent, always pass the matching doc path(s) in its prompt. Sub-agents do not inherit this file.
- Always find the existing implementation with `rg` / `find`.
- Never proceed without reading it.


| Task touches…                                           | Read first                         |
| ------------------------------------------------------- | ---------------------------------- |
| <an-area-of-the-codebase>                               | `ai-docs/<example-file>.md`        |

A good embedded harness gives engineers confidence to move quickly and support AI to solve problems in the “Xelix-way” and applies automatically behind-the-scenes.

Continuous Integration and Shifting Left

Xelix has always advocated for a rich continuous integration suite across its repositories. These suites give every change fast, repeatable feedback before it is merged, covering the checks that are best handled automatically rather than left to individual judgement in review.

On key repositories, this includes:

Automated test suites.
Type checking to catch unsafe assumptions.
Linting and formatting to keep code consistent, readable, and aligned.
Build and packaging checks to prove that the application still compiles, bundles, and deploys.
Accessibility, performance, and security checks where they are relevant to the repository.
Dependency and configuration checks.

Whilst CI is not new a Xelix, we focus on bringing what is feasible directly into an agents workflow. AI is most valuable when it helps engineers think through risks before implementation is complete. Within our embedded documentation, agents are required to lint, type check, test and build their changes before they even make it to a pull request.

This approach keeps quality embedded throughout delivery, rather than treating it as a final checkpoint.

Pull request reviews

Pull request reviews remain a critical quality gate, but AI changes what reviewers should spend their time on. As AI acts as a multiplier, more code can be raised more quickly.

Alongside our CI above, every pull request is reviewed by Claude, with subagents for dedicated personas, and runs static analysis in SonarQube. These checks help catch issues such as code smells, risky patterns, maintainability concerns, and implementation details that take the onus off a human to catch. Every PR is linked to tickets directly in our project management software, Shortcut, so the intent behind a change is visible alongside the code. Claude can use that linked ticket context to check the semantics of the implementation: whether the code appears to do what the ticket expected, whether important acceptance criteria have been missed, and whether there is a mismatch between the proposed change and the underlying problem.

Human review shifts to focusing on the areas where engineering judgement matters most:

Is the approach appropriate for the wider architecture and follows system patterns?
Does the test strategy give confidence in the intended behaviour and important edge cases?
Is the change introducing unnecessary complexity, duplicated logic, or long-term maintenance cost?

This does not reduce the importance of pull request review. As AI increases throughput, reviewers become less of a syntax safety net and more of a semantic quality gate, ensuring that faster delivery still results in correct, maintainable, and valuable software.

How we keep the team up to date

AI tooling is moving quickly, so our approach needs to be active rather than static. We need lightweight structures that help engineers learn what is available, understand what is recommended, and share what is working.

Tooling repository

At Xelix, we have a central tooling repository gives the team a shared place to document approved tools, setup guidance, workflows, examples, and known limitations. It should help engineers answer practical questions such as:

What tools are available?
How should they be configured?
What workflows have worked well for other teams?
What risks or limitations should I be aware of?
Where should I contribute improvements or examples?

Dedicated engineers

We have a dedicated AI Tech Initiative team (AI-TI, yes a little Star-warsy) who stay close to AI tooling, evaluate new capabilities, and help translate them into useful engineering practices at Xelix. Their role is not to own AI usage on behalf of everyone else, but to act as multipliers: testing workflows, sharing patterns, identifying risks, and helping teams adopt tools effectively.

These engineers help maintain standards, support teams with onboarding, and ensure that our approach remains connected to real engineering needs rather than hype.

Drop-ins and knowledge sharing

Regular drop-ins and knowledge channels give engineers a place to ask questions, share examples, compare workflows, and get help with practical adoption. They also create a feedback loop between teams using AI day to day and the people helping shape our tooling and guidance.

Good knowledge sharing should be pragmatic. We should focus on examples that engineers can apply immediately: useful prompts, review workflows, test generation patterns, debugging approaches, and lessons learned from real projects.

Closing remarks

Striking a balance with the “right amount of AI” is really hard, but, we will try. AI will continue to change the way software is built but we are confident, that with our amazing team we will continue to use it, as the revolutionary tool it is. We will focus on whether our teams can continue to deliver more great software and ensuring Xelix remains a world-leading product.