How eight people hold the bar for 200+ builders

Keeping frontend quality high when most of the code is written by Agents

Frontend Tech is a small frontend infrastructure team at Fin. For years, our job has been to help others build fast and safely, and the way we did that was pretty hands-on: maintaining shared code, reviewing PRs, documenting conventions, and answering dozens of the same questions a week.

We barely do any of that anymore. At least not for humans.

Instead of explaining conventions to people, we’ve encoded them into the tooling so anyone building UI, human or Agent, ends up on the right path by default. That changes how we work and also what our team is for.

Encoding our design judgment

Take Surge, our design system.

When it came to encoding our component library into skills, we had a headstart – they were already structured, named, and documented. But a component library is only half a design system. The essence of your design, your taste, lives in the details: which component to reach for, how to compose a flow, and which combinations hold up across the product and which break. That knowledge sits in designers’ heads, Figma annotations, and a variety of documentation, making it difficult for an Agent to build a cohesive picture.

Surge Intelligence doc for design system foundations

So the real work wasn’t wiring Surge into a skill, though we did do that. It was building the layer underneath: a structured, maintained knowledge base that encodes not just the components but the patterns and taste, in a form an Agent can reason over. We call it Surge Intelligence. The skills are just how you reach it; the knowledge layer is the real asset, and it compounds. A decision encoded once pays forward to everyone who builds anything similar after it.

Building this system is design work. You can’t hand it off as a documentation exercise. It means revisiting old decisions, arguing about them, and writing down why one pattern is right and another isn’t.

An example of this is the header of any given page. You could argue the simplest way to describe it is that a page has a title and an action, but it’s not that simple. You need to define everything:

• How long can the title be?

• How many actions can you have?

• Do you have a primary and a secondary action?

• Is there a limit on actions per page?

• Does the title need to follow certain content design guidelines?

Any pattern needs to be thought through in detail and encoded, ensuring usability and your taste are preserved.

The impact of a knowledge layer

We measure whether Surge Intelligence is working by comparing tasks run with and without it enabled. Without it, only 7% of the components an Agent reached for existed in our design system; with Surge Intelligence, 96% did. Code respected typechecking rules 74% of the time, up from 0% of the time. While components were placed in the correct context 68% of the time, up from 42%.

Unfortunately, that means even with the invented imports gone, about a quarter of pages still use the wrong props. But it’s early and we’re still building improvements.

The red elements show where the Agent has deviated from our design system, compared to when it has Surge Intelligence.

This is a concern because of how Agents fail. An Agent creating UI without a design system in context will default to generic patterns and custom code, drifting from your quality bar just to please you. Agents are biased to succeed, they won’t refuse a task even if they’re unable to complete it. So the design system has to be in the Agent’s hands with clear paths to success.

Beyond the visual

But Surge Intelligence is just one piece of a much larger frontend puzzle. In 2024, we began to migrate from Ember to React and committed to using AI coding Agents in the process. We built a “react” skill to ensure the code we write meets our standards and patterns, helping our engineers start building with less React experience.

Principal Engineer Pat O’Callaghan went further writing skills to evaluate existing product features that require migration, enabling product engineers to generate migration plans and verify the features once moved. Pat will share more on this soon.

In one year we’ve grown from supporting 2 engineers a week in React to up to 104.

Now, around 450 engineers have shipped React code, roughly 230 in any given month, most of whom didn’t know React before they started. They’ve taken React from 0% of the product to a third of it, writing 1.4 million lines of code, using AI infrastructure created and maintained by just eight people.

To be fair, though, that wouldn’t have been possible without investment in our overarching Agent platform and dedicated 2x Team. They’ve helped more than 90% of PRs to be written with an Agent while half are auto-approved by Agents.

So what’s the team for?

If the Agent has the entire design system, all our coding conventions, and our architectural documentation, do we even need to keep humans around to work on this stuff?

Yes. Obviously yes, and not only because I’d like to keep my job. But what we do, and how we go about it, has changed.

For years our work scaled linearly with the number of people building, and we couldn’t always keep up. Doing more meant adding more designers and opportunities for review. Now the conventions live in the environment, our leverage is completely different. By shipping one considerate skill, auto-installed for everyone, our small team can lift the velocity of the whole org.

Our frontend team is also able to serve and enable more teams than ever before. The line between engineer and designer keeps blurring – designers now prototype in code while engineers ship whole surfaces without a designer in the room. With Surge Intelligence, a designer can build something real, safely, or an engineer can ship something polished and consistent.

But this impact is only possible if we maintain and consistently improve our AI systems. This is still a work in progress.

What we’re still figuring out

One risk is the environment becoming a black box. If people can ship without understanding, you have to invest just as hard in keeping humans able to judge what the Agents produce. Your focus moves up a level: from how to do the work, to how to direct and judge it. That one’s tricky, and we haven’t solved it yet.

We have evals for the things that are straightforward to measure, but not yet a way to judge whether output is truly design-guidance compliant. Building that judging pipeline is next. We’ve encoded the obvious rules, but the part that carries our taste, like the composition decisions, the recipes, and the product knowledge, still mostly live in people. We’re eager to unlock this.

Our opportunity hasn’t changed. It’s the same as it always was: a small team that can have an outsized effect on what everyone else can build. It just means something different now: building the foundations that accelerate the company and everything built on top of them. The Agents included.