The engineers who will work on your product.

Agents, retrieval and RAG, voice, evaluations and guardrails

The evidence that the system is right often enough to put in front of your customers.

An AI feature is not deterministic. The same question twice can come back differently, so a passing unit test proves nothing. The evaluation suite is built first, your own team marks what a right answer looks like, and every release has to clear it.

India Avenue's investor assistant went live after their own team marked fifty questions right or wrong. That suite is the test every release has passed since.

Held to

• You get a number for how often it is right, from answers your team marked, before a customer sees it
• A prompt change that quietly breaks three other cases is caught by the suite, not by a customer
• Every answer carries the source it came from, so your team can check it instead of trusting it

Front end, back end, mobile, legacy modernisation

A change that is ready to release the day it is written, and the question it was meant to answer.

Test driven from the interface to the database, integrated to trunk at least daily, and trunk stays releasable. AI drafts inside the gates: the tests, the coverage threshold and the mutation gate decide what survives.

view.com.au moved from ColdFusion to React in under four months, a slice at a time, live to millions the whole way. We have engineered with them since 2019.

Held to

• Releasing is your decision, not an event the team has to survive, because trunk is always releasable
• Work arrives in slices of two days or less, so changing your mind stays cheap
• Every bug fix ships with the test that reproduces it, so the same defect cannot come back

Discovery and example mapping, acceptance scenarios, exploratory and usability testing

The questions asked before a line is written, and the problems no pipeline will find after.

QA starts at discovery, not after the build. Sitting with product and engineering, they turn a vague requirement into concrete examples, which is where the cheapest defect in software is caught. Once it is built, they go where automation cannot.

CHAIRS Global collects frank advice from company chairs. Their assistant was tested as seven different Chairs, and identified none of them.

Held to

• You find out a requirement was wrong in a conversation, where it costs minutes, not in production, where it costs days
• Every defect is traced to where it was introduced, so that class of bug stops recurring
• The scenarios automation misses are found by a person, before your customers find them

Pipelines, warehousing, analytics, the retrieval layer

The data the answers are drawn from, and whether it can be trusted.

Structured and unstructured sources modelled into something queryable, then the retrieval layer an agent reads from. Lineage and freshness are tested like any other behaviour rather than checked by hand.

OnlyFacts publishes the Australian climate data newsrooms quote by name. We built the 190 data tools two agents answer from, cited every time.

Held to

• Any answer can be traced back to the record it was drawn from
• A source that goes stale or changes shape is caught by a test, not by a wrong answer in front of a customer
• What real usage shows feeds the next decision, rather than waiting for a quarterly report

CI and CD, cloud infrastructure, observability, DevOps

The path from a commit to production, and how fast you get back when it breaks.

The delivery platform on your account: pipelines, environments, and the gates every change passes. Unit, component and contract tests run on every commit; smoke, acceptance and end to end tests run on the way out.

A telemetry platform ran 380 gateways reading more than 60,000 metrics a second at peak.

Held to

• A change reaches production the day it is committed, rather than at the end of a cycle
• Fewer than 15% of changes cause a problem, and when one does you are back inside an hour
• A broken build stops the line and is fixed in minutes, so nobody builds on a broken base

Architecture, code review, coaching, delivery metrics

The standard the team holds to, and whether your own engineers keep it after we go.

Runs a workstream and pairs across it: architecture decisions written down, review on every change, and the delivery numbers read with your leads rather than reported at them. Coaching is the job, not a side effect of it.

view.com.au grew from one integration to a team of 48 over seven years, with the practices held the whole way.

Held to

• Your own engineers hold the practice after we leave, because they were paired with rather than handed to
• You see the same delivery numbers we do, at the same retro, not in a status report
• About a fifth of the week goes to improvement, so the codebase gets easier to change rather than harder