What we mean when we say AI-native

I have read a lot of agency copy about AI over the last year, and the striking thing is how little of it commits to anything. There is a great deal about being AI-first and AI-powered and AI-enabled, and almost nothing about which part of the work is different on a Tuesday afternoon. It is a claim shaped like a fact, and clients have started to notice, because the output arriving on their desks did not get noticeably better - it just got faster and blander at the same time.

That is the thing worth naming up front, because it is the actual risk. Generative tooling is very good at producing something that has the shape of good work. It writes code that compiles, decks that scan, copy that reads fine at a glance and falls apart the moment somebody who knows the subject looks twice. If your only quality gate is whether it looks right, this technology will beat that gate every single time, and you will ship an enormous volume of confident, plausible, quietly wrong work.

The danger was never that AI writes badly. It is that it writes plausibly, and plausible passes most reviews.

So being AI-native, for us, is not a statement about how much of the work a machine touches. It is a statement about what we changed to stop that failure mode, because the tooling on its own makes it far more likely, not less.

Verification, not review

The single change that everything else hangs off is this: we stopped accepting work because it looked right, and started accepting it because it was measured. That sounds like a small distinction and it reorganises everything downstream of it.

Review is a person reading something and forming an opinion. It is genuinely useful and it is also exactly the gate that fluent, confident, wrong output is built to walk through. Verification is different: it asks what would be true if this were correct, and then goes and checks whether that thing is true. It produces a number, or a pass, or a diff, and it does not care how good the work looked on the way in.

In practice that means the checks get built before the pace does. A layout change is not accepted on the strength of a screenshot, because a screenshot is taken on one screen at one size by somebody who already knows what they meant to build. It is accepted once it has been measured at the sizes real people actually use, and it is the measurement that gets recorded, not the opinion.

None of that machinery cares who or what wrote the code, which is exactly the point. When a change is proposed the question is never whether it reads well. It is whether the check passed, whether the measurement moved, and whether the thing that was wrong before is demonstrably right now.

“We do not accept work because it looks right. We accept it because it was measured, and we can show you the measurement.”

The failures this catches are almost always invisible ones. A layout that overflows inside a container which clips rather than scrolls looks perfect and is broken, and no amount of careful looking will find it, because there is nothing there to see. That is why the discipline has to be mechanical. Attention does not scale, and it is not as sharp at five in the afternoon as it was at nine; a check is.

The rulebook, and why it is written down

The second change is that our standards stopped living in people's heads. Every project carries a written rulebook now, and it is written to be read by the tooling before it writes anything rather than by a new starter in their first week. It is not documentation in the usual sense, because nobody is expected to remember it. It is enforcement.

What goes into it is the things that go wrong repeatedly, in the specific form they went wrong: the spacing scale that kept drifting, the asset doing four jobs at once and costing a page most of its weight, the image slot whose artwork was the wrong shape so every card was being quietly magnified. Each entry is a mistake we made, written down in the form that stops it happening twice.

That is the real function of it. A person who reads the rulebook is better informed; an agent that reads it before it starts cannot rediscover a problem we have already paid for. The second is worth considerably more, because the agent is the thing generating volume, and volume is precisely where an unwritten standard fails.

The pattern underneath is small and it matters more than any of the tooling: the difference between intending to be careful and building the carefulness into the machinery. A rule that lives in somebody's memory is a rule that holds right up until the week they are on leave and the deadline moves.

Where it sits, division by division

We organise what we sell into three groups, and the tooling shows up differently in each. It is worth being specific about that, because a studio claiming AI helps everywhere equally is usually claiming it helps nowhere in particular.

Build Products: platforms, applications and the things that have to still be running in three years

This is where the tooling is most load-bearing and most tightly fenced. Our engineers work with an agent inside the repository itself - Claude Code, against the rulebook described above - and it does the work that is genuinely mechanical: sweeping a change across forty files consistently, writing the test that proves an edge case, tracing a behaviour through a codebase nobody has read in six months, doing the arithmetic on a layout instead of eyeballing it.

What it does not do is decide. Architecture, the shape of the data model, what we are actually building and what we are refusing to build - those are engineering judgements, and they are made by the engineer whose name is on the work. The agent proposes, and it is very good at proposing. It does not get a vote on whether the proposal is right.

The visible outcome for a client is that the boring half of a build stopped being expensive. Tests, types, migrations, the documentation that always got written last and badly, the accessibility pass that used to be the first thing cut when a date got tight - all of that is now cheap enough that there is no argument about whether to do it. That is a quality change dressed up as a speed change, and it is the more valuable half.

Provide Expertise: strategy, design and the work where being wrong is expensive

Here the tooling is used earlier and trusted less. It is genuinely excellent at the first ninety per cent of research - reading a sector, summarising a competitor set, pulling the shape out of a pile of interview transcripts, generating fifteen directions when a designer would reasonably have produced four. Breadth is cheap now, and breadth used to be the expensive part of thinking.

But strategy is a series of commitments, and a commitment made by something with no stake in the outcome is not a commitment. So the rule in this part of the business is that a model may widen the option set and may never narrow it. The narrowing is the job. It is what a client is actually paying a senior person to do, and handing it to a machine would be the single fastest way to produce work that is fluent, defensible and worth nothing.

The same holds in design. Generating a layout is now trivial and deciding which one is correct for this brand, this audience and this constraint is exactly as hard as it always was. What changed is that our designers see more options before committing, and spend a far larger share of their week on the committing.

Deploy Solutions: support, automation and the things that run every day

This is the quietest one and possibly the most useful. Support work is mostly triage - reading an incoming request, working out what it actually is, what it touches, how big it is and who should have it. That is pattern-matching against a system somebody already knows, and it is exactly what this tooling is best at.

It means the first response to a support request is faster and better-informed, and it means the monthly report a client gets is assembled from what actually happened rather than reconstructed from memory at month end. Automation work benefits the same way: the tedious part of an integration is mapping one system's idea of a customer onto another's, and that mapping is now drafted in an afternoon instead of a week, then checked properly, because the checking is the part that matters.

What happened to the people

Nobody's title changed. I want to be plain about that, because the honest version of this story is less dramatic than the version that sells conference tickets. We did not restructure, we have not replaced a discipline with a prompt, and the team is the same team.

What moved is the ratio. Every role here used to be some mix of judgement and production - deciding what should exist, and then doing the labour of making it exist. Production has collapsed in cost, so the mix inverted, and a week that used to be mostly making is now mostly deciding, specifying and checking. That sounds like a lighter job and it is not. Judgement is the tiring part, and there is now much more of it per person per day.

It has changed what good looks like in a hire, too. The most valuable person in this building is no longer the one who can produce the most; it is the one who can look at something plausible and say precisely why it is wrong. That skill was always valuable and it used to be a nice-to-have on top of raw output. It is now the whole job, and it is a genuinely harder thing to find.

The scarce skill stopped being the ability to make the thing. It is now the ability to know whether the thing is right, and to prove it.

The corollary is uncomfortable and worth saying: this only works with senior people. A model plus a junior produces confident work that nobody in the room can properly evaluate, which is the exact machine for generating slop at scale. We are a senior studio, and the tooling has made that more necessary rather than less.

The three rules it does not get to break

Everything above rests on three boundaries. They are unglamorous and they are the reason any of this is safe to sell.

1. A named person owns every output. Not a team, not a process - a person, who is accountable for it whether they typed it or approved it. Nothing reaches a client or production without that name attached, and "the tool produced it" has never once been an acceptable answer to a question about why something is wrong.
2. Nothing is trusted because it was reviewed. It is trusted because it was verified - a guard passed, a measurement taken, a before and an after that can be shown to somebody who was not there. Where a claim cannot be checked, it does not get made.
3. The tooling works on code, drafts and internal artefacts. It does not operate against client data or live systems, and access to a production environment is a human decision made by a human with the authority to make it.

You will notice none of those are about the technology. They are about accountability, evidence and blast radius, and they would be sensible rules in a studio that had never touched a model. That is rather the point. The tooling did not require us to invent a new ethics; it required us to actually enforce the one we already claimed to have, because the cost of not enforcing it went up enormously.

What this is actually worth to you

Stripped of the language, there are four things a client gets out of this, and I would rather be judged on these than on the word AI-native.

• The work that used to get cut now gets done. Tests, documentation, accessibility, performance budgets, the second and third pass on a piece of copy - these were always the first casualties of a fixed date, and they are no longer expensive enough to be worth cutting.
• More of your money buys senior attention. If production is cheap and judgement is not, then the proportion of an engagement spent on people thinking about your problem goes up rather than down.
• Speed where speed is safe, and no faster anywhere else. A migration or a sweep across a codebase genuinely does land in a fraction of the time. A strategic recommendation takes exactly as long as it used to, because the slow part was never the typing.
• You can check us. Every claim we make about a change to your product should come with the measurement that supports it, and if it does not, ask for it. That is a reasonable thing to demand of any studio and it is now a completely reasonable thing to expect.

Where it does not help, which is most of the interesting part

I would not trust this piece if it did not have this section in it, so: the tooling has not made us better at the hard parts. It has not improved our taste. It does not know your business, it cannot sit in a room and read what a stakeholder is not saying, and it has no opinion worth having about whether a thing is worth building at all. Those are the parts of the work that clients remember years later and they are exactly the parts that are unchanged.

It is also actively unhelpful in one specific way that is worth watching for: it lowers the cost of producing something so far that it becomes tempting to produce something instead of deciding something. The discipline of sitting with a hard problem and not generating anything for a while is harder to maintain now than it was two years ago, and I think a lot of the slop in the market comes from exactly that - not from bad tooling, but from good tooling used as a substitute for thinking.

So that is what AI-native means here. Not that the machines do the work. That we rebuilt how we check the work, wrote down what we know so it cannot be forgotten, kept a person's name on everything that leaves the building, and spent the time we got back on the parts that were always the point. If your current partner is telling you they are AI-native, the useful question is not which tools they use. It is what they changed about how they verify, and whose name is on it when it is wrong.