Five AI use cases for technical teams, step by step

On a technical team the question is not whether AI is useful, but where it enters without becoming one more tool sitting outside the real work. These are the five cases we have started with most often, each with what it takes to implement it, what to measure and when it is not worth it. If what you are after is the whole approach rather than the cases, it is in the approach for IT.

How to read these cards

Each case shows the same task twice: how it is done today and how it looks with AI implemented. What is struck through in the "today" column is the manual work that disappears; where a person is still working, even with help, nothing is marked.

The hours come from one real example, not an average and not a promise. And in all five cases a person decides at the end: what gets automated is gathering context and preparing the work, not the technical decision.

01 · Shipping a change

What it takes. The repository accessible, the conventions written where they can be read in every session —structure, naming, what gets tested and how— and an automatic pre-review that applies those criteria before a person looks. The conventions are the part you cannot skip: without them, human review still does exactly the same work as today.

What to measure. Time from the ticket being opened to the change being in production, review comments per change, and incidents per release. The second one shows whether the criteria are well written.

When it is not worth it. If there are no automated tests and no way to verify what ships, speeding up writing only speeds up how fast errors reach production. That is the case that comes before this one.

02 · Serving the business

What it takes. A readable data model, with names that mean something to whoever is asking, and permissions resolved by role before the door opens. This is the case where data governance stops being postponed, because without it there is nothing to implement: you have to decide who sees what and what gets logged, and you have to decide it on day one.

What to measure. Questions that stop reaching the team's queue, response time to the business, and the list of questions the agent marks as unanswerable. That list is the most valuable output of the case: it is a roadmap of the missing data, written by the people who need it.

When it is not worth it. If every system gives a different figure for the same question, unify first. An agent on top of data that does not reconcile saves no work: it just spreads the disagreement faster and to more people.

03 · Resolving an incident

What it takes. Centralised logs with enough context to reconstruct what happened, and a deployment history that can be correlated with the alerts. If logs are spread across five places and each one needs a separate login, the prep work is bringing them together.

What to measure. Time to identify the cause —not to resolve: what changes is the diagnosis, not the decision about the fix— and incidents that end with a written report, which in most teams today is close to none.

When it is not worth it. If the real problem is that there are too many incidents, the work is in the cause and not in the diagnosis. Resolving a recurring failure faster makes it sustainable, which is exactly what you do not want.

04 · Adding a feature

What it takes. The repository conventions, as in the first case, and one decision that is not delegated: which version already adds value without being the most complete. That is a product decision, and it determines whether the feature is in use in days or in months.

What to measure. Days from approval to the first version in use, and the share of features that keep growing after delivery versus the ones nobody touches again. The second figure tells you whether you were building what was needed.

When it is not worth it. If the team cannot deploy often, shipping the first version earlier changes nothing: it waits in the same queue. Deployment first, then this.

05 · Redesigning a screen

What it takes. Support queries stored somewhere readable —an inbox will do— and your visual system available as components or as code. With those two things, a navigable alternative is ready in hours and the discussion stops being about a document.

What to measure. Support queries about that screen before and after, and tasks completed without asking for help. Both are measured with what you already have, and both have to be measured before anything is touched.

When it is not worth it. If nobody has looked at why the screen fails, a fast redesign produces a new screen with the same problem, plus the feeling that it is already solved.

Which of the five to start with

The first case is not chosen for how impressive it is, but for what it leaves learned. Of these five, shipping a change repeats most often during the day and is the fastest at teaching the team to write criteria, provided automated tests already exist.

Serving the business frees the most time outside the technical team, and forces permissions and data governance to be resolved: that makes it slower to start and more valuable to have. Resolving an incident depends entirely on the state of your logs. And the last two are projects rather than tasks: they come in once the team already works this way.

The full set of criteria we use to filter a first case —it repeats, it needs judgement that lives in one person, it can be verified, the data exists, and nothing breaks if it fails— is in the article where we explain how we work.

These five are the most common, not the only ones: the full catalogue sorts them by the part of the company they affect, and there is a version of this list for business and operations. If you want to see how they fit your stack, you can ask for information with no commitment: if it is not a fit, we will tell you.