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.

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

This site is the easiest place to see it, because you can check most of it from outside. Every build runs a chain of guards after it compiles. One walks the rendered route manifest and fails the build if any page is missing its own share card, because a page that inherits the wrong card looks fine to everyone except the person who shared it. Another reads every component file and enforces five layout rules we learned the hard way, including one about twelve-column grids that silently collapse to nothing on a phone. A third drives a real browser across every route at three widths and reports overflow, dead zones and undersized tap targets.

None of those care who or what wrote the code. That is the point. When a change is proposed, the question is never whether it reads well - it is whether the guard passed, whether the measurement moved, and whether the number that was wrong before is right now.

One example, because the principle is easier to trust with a case attached. A recent change to this site's masthead logo looked completely fine in every screenshot. Measuring it at 375 pixels turned up 219 pixels of horizontal overflow, which nobody would ever have seen, because the scroll container clips overflow rather than showing a scrollbar. The screenshot was not lying, exactly. It just could not see the thing that was wrong.

That example is from this site, which is the easy case, because I can hand you the repository and let you check it. The same discipline is what found a capacity problem on a client platform before its users did: simulated traffic ramped until something moved, a handful of expensive requests turning out to be enough to take a dependency down and everything behind it with it, and the tooling reading the live telemetry itself to work out why. Luke has written that one up in the piece on building to enterprise standards.

The rulebook, and why it is written down

The second change is that the standards stopped living in people's heads. This repository carries a file called AGENTS.md - about 406 lines and three thousand words - and it is written to be read by the tooling before it writes anything. It is not documentation in the usual sense, because nobody is expected to remember it. It is enforcement.

It covers the things that go wrong repeatedly. There is a section on horizontal padding that exists because slices kept drifting to slightly different scales. There is a section on video that exists because a single unoptimised file was once doing four jobs across four routes and Lighthouse measured three megabytes of it on the home page alone, which was eighty-two per cent of that page's weight, for a film nobody had asked to watch. There is a section on images that exists because the project cards were feeding portrait boxes with landscape artwork, so the browser was magnifying every one of them, and it was invisible on a retina screen.

Every one of those sections is a mistake we made, written down in a form that stops it happening again. That is the real function of the rulebook: an agent that reads it before it starts cannot rediscover a problem we already paid for.

My favourite entry is about a bug-reporting widget that shipped to production once, under a comment that said REMOVE BEFORE LAUNCH. It is now gated on the deploy environment rather than on anybody's memory, and the rulebook says so in those words. That is a small thing that tells you a lot about the difference between intending to be careful and building carefulness into the machinery.

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.