People ask me this a lot. "Which frontend technology would you pick for a new project today?" My answer has been the same for a while now: TanStack Start, plus the rest of TanStack. It's the first thing I reach for when I start a new project. And right now I don't have a single reason to change that.

In this article I'll sum up what 1.0 means and what Tanner himself says about it. Most of all, I'll show how we use Start in production on two projects: this website, bhpslabs.com, and the udalist.app application. No theory, just real code.

What "1.0" means#

Plenty of companies have been running Start in production for a long time, from small projects to enterprise teams. As Tanner admits, many of them shipped it while it was still in beta, even when the team tried to talk them out of it. We were in the same boat.

So 1.0 isn't about Start suddenly starting to work. It's a formal commitment to the API. You can pick Start, learn it, and build a product on it without worrying that six months from now someone will rework the whole way your application works. For a company betting money and people on a technology, that's the most important property of all.

Tanner is also open about the road from release candidate to 1.0 taking longer than he expected. In the meantime, the framework got work on the compiler, streaming, hydration, and the boundaries between server and client. Manuel Schiller and Florian Pellet focused on SSR performance and got roughly 5.5× higher throughput in their benchmark. Christopher Horobin is the reason the router's extremely strong types don't grind your editor to a halt. None of this looks dramatic in a changelog, but you feel it in production.

What Tanner says (and why I agree)#

I recommend reading the whole post in the original. For those short on time, here are the points that resonate with me most.

It all started with a router#

Start didn't begin as a framework. It began as a router that Tanner wanted to know everything: which paths exist, which parameters they need, which search params are valid, what a loader returns, and what context is available where. And he wanted your editor to tell you, after every change, what else needs to change.

A few years ago, plenty of people didn't believe that was possible. Today I think it's the single biggest reason to use TanStack Router and Start.

A different path than "everything on the server"#

Tanner describes how the React ecosystem narrowed down to a single idea of what an application should look like. Next.js bet on React Server Components both as a framework foundation and as an ideology. Start goes another way: an application stays an application, with state, client-side navigation, and data caching. You add server rendering, streaming, and server functions where they make sense, without rethinking how your whole app works.

Each route can choose to render on the server, to only load its data on the server, or to run purely on the client. Server functions are typed and can be called from a loader or an event handler. Middleware can run on both the client and the server, and the context types carry through.

RSC as an option, not an obligation#

There's an interesting passage about React Server Components. The team spent a lot of time on them, and Start supports them, but without letting them take over the whole application. And the punchline: on tanstack.com they eventually turned them off, because it kept getting harder to reason about what was shipped where, for people and for AI models alike. Turning them off didn't mean rewriting the app. That's exactly the kind of freedom I want from a framework.

Host it anywhere#

Start is built on Vite and Nitro (and now supports Rsbuild too), so deployment isn't tied to one provider. Netlify, Vercel, Cloudflare, Railway, Render, or your own Docker container running a Node server, which is what we do.

Types help AI agents too#

I think this is the most underrated argument. Strict types and explicit APIs were built for people, but they help AI agents just as much. When an agent changes a route parameter or a server function's input, TypeScript immediately shows it every place that no longer agrees with that change. On top of that, TanStack has started shipping so-called skills inside its npm packages (via TanStack Intent), so an agent doesn't have to rely on outdated training data. It reads current best practices straight from the package.

Why I left Next.js#

I used Next.js for a long time and I don't want to trash it. It's great at explaining and selling its ideas, and it taught a lot of people a lot. But more and more I felt like I was fighting the framework instead of building the product.

• "use client" and "use server" directives decide where code runs, and the boundaries aren't always visible.
• Caching changed fundamentally across several versions in a row, and it was hard to tell what was cached, where, and for how long.
• The App Router mental model is hard for juniors (and honestly for seniors too): server components, client components, what's allowed to import what.
• Type safety in routing is more of an add-on than a foundation. Search params are basically string | string[] | undefined.

Start is the opposite. Components are components, routes are routes, and when I need the server, I say so explicitly. I don't need a second mental model of my app just to get through the day.

I've also met Tanner in person in Amsterdam, and that conversation confirmed what I'd sensed from the code for a long time: behind TanStack is someone who cares about tools that are good to use, not just tools that are easy to sell.

Developer experience and the learning curve#

In my view, Start's DX is a class above, and a few concrete things show it best.

Typed routes without keeping them in your head. The router generates its own route tree (routeTree.gen.ts). A link to a page that doesn't exist or a missing parameter is a compile-time error, not a 404 in production. On udalist.app we have more than 80 <Link> components, and every one of them is type-checked.

Search params as typed state. validateSearch (used by seven routes on Udalist) turns search params into a validated, typed object. Filters, pagination, or form state in the URL stop being a source of bugs.

An explicit server. A server function is a plain function you call. You can see what goes in, what comes out, and that it runs on the server. No magic.

The learning curve. Anyone who knows React and a bit of TypeScript is productive in Start within a few days. There's no new paradigm to learn, just the router. And if you know TanStack Query, you'll feel at home even faster. With the Next.js App Router, I've watched experienced developers struggle for weeks.

SEO and GEO: where Start really shines#

We spent a lot of time on SEO and GEO (Generative Engine Optimization, meaning optimization for AI assistants like ChatGPT, Claude, or Perplexity) on this website. Start didn't get in our way once. Quite the opposite.

Metadata on every route#

Every route has a head() function that returns the title, description, canonical, hreflang, Open Graph, and JSON-LD. It's typed, it knows the route's parameters, and it runs during SSR, so crawlers get finished HTML. Here's a simplified version of the route for this very article:

export const Route = createFileRoute('/$locale/blog/$slug')({
    beforeLoad: ({ params }) => {
        if (!findPost(posts, params.locale, params.slug)) throw notFound();
    },
    head: ({ params }) => {
        const post = findPost(posts, params.locale, params.slug);
        return pageHead({
            title: post.title,
            description: post.description,
            ogType: 'article',
            alternates, // hreflang to the article's translation
            nodes: [blogPostingNode({ headline: post.title /* … */ })], // JSON-LD
        });
    },
    component: ArticlePage,
});

Notice the beforeLoad as well. An old URL format redirects with a permanent 301, and an article that doesn't exist returns a real 404, not an empty page with a 200 status code. That matters a lot for SEO.

Prerendering and the sitemap right in the config#

We prerender static pages at build time, and the sitemap is generated automatically. On both projects it's a few lines in vite.config.ts:

tanstackStart({
    pages: getTanstackStartPages(),
    prerender: { enabled: true, crawlLinks: false, autoStaticPathsDiscovery: false },
    sitemap: { enabled: true, host: 'https://bhpslabs.com/' },
}),

On Udalist, the prerender also has a filter that skips the signed-in part of the app (the dashboard and authentication). Marketing pages are static and lightning fast, while the app behind the login runs as a classic SPA.

A website AI understands too#

This is where it pays off that Start doesn't hide anything. The custom server entry (src/server.ts) is a plain fetch handler, and you can add whatever you need to it. Thanks to that, on bhpslabs.com we:

• return the same page as Markdown when an AI agent asks for it with an Accept: text/markdown header. The agent doesn't have to parse HTML and gets clean text,
• build a Content-Security-Policy for each response from the hashes of its inline scripts, without unsafe-inline,
• serve files under /.well-known/ for agent discovery (a catalog, agent skills),
• and on top of that, a robots.txt with rules for AI crawlers and an llms.txt that tells models what we do and when to recommend us.

export default {
    async fetch(request: Request) {
        const wellKnown = await wellKnownResponse(request);
        if (wellKnown) return wellKnown;

        const markdown = wantsMarkdown(request.headers.get('accept'));
        const response = await paraglideMiddleware(request, () => handler.fetch(request));

        if (markdown) return toMarkdownResponse(response);
        // … CSP from inline script hashes, Vary, gzip
        return response;
    },
};

Udalist has a very similar entry: Paraglide middleware, security headers, Markdown for the home page, and /.well-known/ files. Designed once, used twice.

Our projects in production#

bhpslabs.com#

This website runs on TanStack Start, TanStack Router, React 19, Vite, and Nitro, deployed as a Node server in Docker. It's bilingual (Czech and English) through Paraglide, and paths look like /$locale/....

A few things worth mentioning:

• The blog (yes, including this article) is loaded from Markdown files through a custom Vite plugin that validates them at build time and turns them into typed data. Translations of an article are linked by their folder, not their URL.
• The enquiry form sends data through a typed server function with validation and rate limiting:

export const sendAuditRequest = createServerFn({ method: 'POST' })
    .validator((value: unknown): SendInput => {
        if (!isInput(value)) throw new Error('Invalid input');
        return value;
    })
    .handler(async ({ data }): Promise<SendResult> => {
        if (!allow(getRequestIP({ xForwardedFor: true }) ?? 'unknown')) return { status: 'unavailable' };
        // … validation and sending the email
    });

• Static HTML, caching, and compression are handled through Nitro routeRules: fonts and assets with a long cache, HTML with revalidation, and precompressed JS and CSS.

The result? Lighthouse gives bhpslabs.com 100 / 100 / 100 / 100 across all four categories (Performance, Accessibility, Best Practices, SEO), plus Agentic Browsing 3 / 3 in the new category that measures how well an AI agent can find its way around a site. That's not down to a single trick. It's the sum of everything above: prerendering, SSR without unnecessary JavaScript, metadata on every route, and a server you can extend with whatever you need. Start didn't get in the way of any of it.

udalist.app#

Udalist collects photos and videos from events (weddings, parties, corporate events) into one shared gallery. Guests scan a QR code and upload straight from their phone's browser, with no app and no account. It's our flagship, and it's more of an application than a website, so it shows the other side of Start:

• 33 route files with pathless layouts: _public for marketing, _guest for guests, and _secure for signed-in users. Each group has its own layout and its own rules, while the URL stays clean.
• TanStack Query lives in the router context, so every loader and beforeLoad has access to it. It pulls data from a Kotlin backend and is used in around 25 files across the app.
• TanStack Form powers nine forms, from contact to event security settings.
• Seven languages through Paraglide, and Sentry through its official SDK for TanStack Start.
• A home page A/B test runs through a server function that reads a cookie and sets response headers.
• Nitro cache rules are typed against the list of routes the router generates. Rename or delete a route, and the cache config stops compiling:

import type { FileRouteTypes } from '../src/routeTree.gen';

type AppFullPath = FileRouteTypes['fullPaths'];

const MARKETING_PATHS_WITH_LONG_CACHE = [
    '/',
    '/pricing',
    '/faq',
    '/blog/',
    // …
] as const satisfies readonly AppFullPath[];

A typo in a path is no longer a silent bug in production, where a page suddenly ships without caching and without security headers. It's a red squiggle in the editor. That's exactly what I love about TanStack.

Both projects deliberately share the same foundation. We're a team of four, and we don't want to maintain two different stacks. Whatever we solve on one, we carry over to the other.

The ecosystem is the biggest advantage#

Start is great on its own, but its real strength is that it isn't alone:

• TanStack Query for server data and caching, the standard you already know,
• TanStack Router with type safety you won't find anywhere else,
• TanStack Form for typed forms without the ceremony,
• TanStack Table and Virtual for tables and long lists,
• and more: Store, Pacer, DB, AI, Devtools, Markdown…

All the libraries share the same philosophy: headless, type-safe, framework-agnostic (React, Solid, Vue, and more), and designed to work well together. Learn one, and the others feel familiar. And if you decide not to use one of them, nothing breaks.

The ecosystem is also backed by strong partners: Netlify, Vercel, Cloudflare, Railway, Render, Lovable, Clerk, WorkOS, Sentry, Prisma, and more. These aren't just logos on a website. They're SDKs, templates, and integrations you can use right away.

What isn't perfect#

So this isn't just a hymn of praise: Nitro v3, which Start runs on in production, is still in beta. It works for us without problems, but it's good to know. And some advanced features (RSC, for example) are still evolving, so if you want to build your whole application on them, keep that in mind.

Neither was a reason for us to put off Start.

How to get started#

If you've been waiting for 1.0, now's the time:

pnpm create @tanstack/start@latest

Then I recommend the Start documentation, and if you're migrating from Next.js, TanStack has a migration guide too. And as Tanner himself suggests: feel free to put an AI agent on it. With up-to-date skills from the packages, TypeScript, and tests, it gets surprisingly far.

Conclusion#

For me, TanStack Start 1.0 confirms something I've known for a long time. A framework doesn't have to dictate what your whole application looks like. It can give you strong, typed, explicit tools and leave the decisions to you.

We run it in production on this website and on Udalist, and everything works as it should. Anyone who asks me what to pick for the frontend today gets a clear answer: TanStack Start. Plus the rest of TanStack.

Thank you, Tanner, and thanks to the whole team behind TanStack. And if you're wondering whether and how to move to Start, get in touch. We're happy to help.

Seven years ago I stood in the middle of a factory, hands dirty with oil, overalls full of dust, machines roaring around me, and a feeling in my head that my life was going nowhere. Shifts dragged on one after another, and when it rained I got on my bike and pedalled home, soaked, exhausted, thinking that this was probably how it would be forever. I was not desperate, but I felt that I wanted more. Not because I thought I was better than the people around me. They were honest and hard-working, the same as me. I was never top of the class. I was not some exceptional talent. I was an ordinary kid who wanted to achieve something in life. One day I stopped in the rain, looked at myself, a dirty electrician on a bike, and said: “I do not want to do this for the rest of my life.” The wish for a change led me to programming, something I had never dreamed of and had no background for. Today, at 26, I am a front-end tech lead at Raynet CRM, one of the best CRM systems in Czechia and Slovakia. Nobody handed me any of it. Everything I have, I earned myself. It was not easy for me, the same as it was not easy for anyone in the factory, and I do not want this to sound as if I am something more. I just decided to go after my goal, even though I did not believe in myself at the start.

Beginnings: No background, no help#

I never thought I would be a programmer. As a kid I was not the one who spends hours at a computer or builds robots. I ran around outside, played football, and the real world interested me. Technology passed me by. After school I became an electrician, because it was practical and within reach. I could wire cables and fix a socket, but I knew nothing about programming. Life in the factory was a routine: get up, work, go home, sleep, and repeat. The people around me were great and hard-working, and I respected them. It was not about being better than them. I just felt that I wanted something else. I bought an old laptop, the kind that growled like a tractor and overheated after a while, and started searching the internet for what programming even is. I had nobody to point me in a direction. No friend, no acquaintance in the field. The first evenings were chaos. I sat there after a shift, eyes burning with tiredness, trying to understand what “Hello World” means in HTML. It felt like a foreign world. I did not believe in myself, but I told myself: “If other people managed it, I can manage it too.” And so I started.

Discipline as my only companion#

Every day I set time aside. After a shift, when I came home dirty and exhausted, I told myself: “At least an hour.” Sometimes I got up at four in the morning, still in the dark, so I could get through a tutorial before work. It was as if I had two jobs. At the factory I was bolting and repairing things, and at home I was learning something new. I searched for answers on Google, went through YouTube videos, and read forums into the night. When I first understood CSS and saw a page change according to my code, I felt hope. Then came JavaScript, a completely different world. I spent hours staring at errors in the console, not understanding why it would not work. I often wanted to quit. I had impostor syndrome, the feeling that I was a fraud who was not cut out for this. But the drive to achieve something kept pushing me. I wanted to be proud of myself, of managing it on my own, of something nobody could take away from me. When I managed to get a simple calculator or an animation running, I told myself: “Maybe there is something to this.” Discipline kept me afloat. Even when I did not believe in myself, I did not give up.

A road full of disappointment#

After months of learning I decided to try for a job. I wrote a CV, an ordinary one, with no degrees, just a few sentences about what I had managed on my own. I sent it out. First ten, then twenty, and in the end about a hundred. And what came back? Silence. Now and then an email: “Thank you, but we are looking for someone with experience.” Or: “Without a degree, it will not work.” As a junior with an electrician’s past, I was invisible. Those moments wore me down. I sat at home in the evening, staring at another rejection, asking myself: “Why am I doing this?” Impostor syndrome grew stronger. I felt like a fraud who was only playing at being a programmer. Once I sat in the kitchen while it poured outside and told myself: “Maybe I am crazy.” I wanted to give up, go back to the overalls, back to something certain. Then it occurred to me what that would mean. No progress, just the factory. I wanted something I could be proud of. So I got up, opened another tutorial, and sent another CV. After six months, full of rejections and doubt, someone called. “We have a junior programmer position at Pickering Interfaces in Třinec. Do you want to try it?” That call changed everything.

First job: An unwanted project and an international team#

When I joined Pickering Interfaces in Třinec, a subsidiary of the British company Pickering, I felt my life moving. For the first time I had colleagues, and not just any colleagues. I worked on an international team, on a project that reached beyond Czechia. After months of learning alone it was liberating, but it was not easy. I came in as a replacement for a programmer who had left, and I inherited a project nobody wanted, forgotten code that nobody wanted to maintain or develop. As a newcomer I got what newcomers usually get: the hardest, least popular work. At the start I did not know where to begin. Impostor syndrome followed me. I was afraid I would fail. But I told myself: “I am different. I will learn it.” I got stuck in. I learned as I went, fixed bugs, and looked for a way through. Bit by bit I got that project under control, and today I am glad of it. They were not soft on me. They threw me in at the deep end, and that forced me to grow. I even got a whisky glass from the British Queen for my work. A small thing, but for me a symbol that hard work means something. After two years in Třinec I had to leave my hometown and move to Ostrava. A hard decision, but I knew another challenge was waiting.

Growing at Raynet CRM: From junior to tech lead#

In Ostrava I joined Raynet CRM as a junior programmer. I started at the bottom, but for the first time I had colleagues and mentors who helped me whenever I needed it. No question was stupid. As I put it: “The one who is afraid to ask stays a fool forever. The one who is not afraid is a fool for only a few minutes.” I was not afraid to ask. After years without support, that was a change. I had a team that pulled me forward. Mentors taught me to write better code and to think like a programmer. The discipline I had built joined up with their guidance, and I grew fast. In four years I went from junior to front-end tech lead, at 26. Today I design solutions and work on a top-tier CRM. My managers trust me, my opinion carries weight, and I have a say in how the team works. I am proud, not only for myself, but also because I can help my family and friends whenever they need me. Working with your head is demanding. Sometimes I miss ordinary work with my hands, bolting, repairing, something you can touch. But I know that what I do now matters. A few months ago I wrote a piece of code that programmers around the world can use, and they do use it. When I see that, I feel that my work reaches past my desk.

What is next: Vision and mentoring#

When I was an electrician, I did not believe that at 26 I would be a tech lead. Now I tell myself: “We will see where the road takes me yet.” I want to keep growing, in technology and in leadership. I dream of a bigger influence, maybe leading a larger team, taking part in breakthrough projects, or trying to build a business in IT. Maybe one day I will make my own application that helps people, the way Raynet helps now. Every day I learn something new, whether it is a framework or how to motivate a team. Now I am the mentor for my juniors at Raynet, and I enjoy it. I see myself in them: the doubts, the fear of whether they are up to it. I help them the way I once needed help, and seeing their progress keeps me going. The road taught me that we set our own limits, and I do not want to set them.

Closing: You can do this too#

My story is not about talent. I was not a genius, I had no background, and for a long time I had nobody to help me. I am no different from the people in the factory, or from anyone doing work they do not enjoy. I am not better. I just decided to step out of my comfort zone, even though I did not believe in myself. At the start I had impostor syndrome. I did not believe I was up to it, and I wanted to quit. But I did not give up. From the factory, through Pickering Interfaces in Třinec, where I worked for a British company, to Raynet CRM in Ostrava: from zero to tech lead at 26. I am proud that what I achieved is mine, and that I can support my family and friends. People often do not step out of their comfort zone. They think they are not cut out for a change. I was the same. But I want to tell you: you can do this. The best time to start may have been a year ago. The second best time is now. You do not need a background. I did not have one. It is enough to start, to stick with it, and not to give up. I managed it, and you can manage it too. Take that first step. It is worth it.

Everyone else, keep reading.

Today AI can write a component for you in a minute. Twenty components in five minutes. It works, the tests pass, everyone is happy. Then you open the pull request and see that one component uses interface, another uses type, a third has a forgotten console.log in the middle, and a fourth imports the same library in three different ways.

None of those things is a bug. The code runs. But a codebase where every file looks like it was written by someone else is hard to read, hard to review and hard to maintain. That flood of "it works, but nobody made it consistent" is what we now call AI slop. And every hour you spend cleaning it up is an hour you pay for.

The good news: you can prevent it almost for free. The bad news: if you do it with slow tools, you only prevent it halfway, because people will start working around them.

And an important point up front: it is not only an AI problem.

It is not only about AI, it is just more visible#

In my article about the Interface vs. Type rule I wrote about what happens when a team grows. Ten developers, ten slightly different habits. Someone brings interface over from Java, someone mixes both, and code review turns into a debate about whitespace instead of architecture.

An AI agent is basically ten more developers who have never met. It does not know your "unwritten rule". Every session starts from zero, the model has learned thousands of different styles and picks whichever fits the moment. On top of that it writes faster than any of us, so inconsistencies grow faster than anyone can catch them.

The answer is the same as before, only more urgent: the rules have to be enforced by a machine, not by human memory.

A rule in a prompt is a request, a rule in a linter is a law#

Of course you can write into AGENTS.md or a system prompt: "Use type instead of interface, do not use any, do not leave console.log behind." It often works. But it is only a request. The model forgets it once the context fills up, or interprets it its own way.

A lint rule works differently. It either passes or it fails. There is no discussion.

Modern AI agents also work in a loop:

1. write code,
2. run checks (tests, types, lint),
3. read the errors,
4. fix them and go again.

A linter and a formatter are exactly the feedback this loop needs. The agent does not have to guess what you like. It runs one command and gets a concrete answer: line 42, this rule, this is not allowed.

A formatter also removes a whole category of noise. Neither the agent nor the human has to think about quotes, indentation or trailing commas. The diff in a pull request contains only real changes, and the reviewer focuses on what the code does, not on how it looks.

A short history: ESLint and Prettier#

ESLint appeared in 2013 and Prettier in 2017. They changed the JavaScript world. ESLint guarded code quality (unused variables, dangerous constructs, custom team rules), and Prettier ended the eternal arguments about formatting by deciding for everyone.

The ESLint + Prettier pair became the standard and worked great for a decade. But it had one property we learned to live with: both tools are written in JavaScript and run on Node.js. On a small project nobody notices. On a large TypeScript codebase with type-aware rules, linting becomes something you run "at the very end" because it takes minutes.

Rust changed the rules of the game#

Then came the Oxc project and with it Oxlint (2023) and later Oxfmt. Both are written in Rust, run natively and use every core of your CPU.

The difference in speed is not cosmetic. One developer on Reddit described migrating their company project (M3 MacBook Pro, median of three runs, over 6,000 files):

• ESLint (single-threaded, type-aware rules): ~2 min 27 s
• Oxlint (5,360 files, 134 rules, 11 threads): ~1.3 s
• Prettier: ~13.9 s
• Oxfmt: ~2.1 s

Mind that this is one specific project with one specific configuration, and your results will differ. The official numbers in the Oxc docs are more modest: Oxfmt is roughly 30x faster than Prettier. But the order of magnitude is the same everywhere. We are talking about tens and hundreds of times, not tens of percent.

And here is what has changed over the past year:

• Oxfmt has been in beta since February 2026 and passes 100% of Prettier's conformance tests for JavaScript and TypeScript. The remaining differences are known bugs in Prettier itself. The output is not different, it is just faster.
• Type-aware linting has been stable since July 2026. It is powered by tsgolint, built on native TypeScript 7, and covers 59 of the 61 type-aware rules from typescript-eslint. This was for a long time the biggest excuse for staying on ESLint.
• Oxlint now supports more than 800 rules from ESLint core and popular plugins (React, jsx-a11y, import, unicorn...) and can run JS plugins too.

Speed is money#

I always say this, even though it sounds a bit dry: tooling speed is a business argument.

Let us run an illustrative example. A team of ten developers, each running checks ten times a day (before a commit, before a push, while fixing things after CI). With two and a half minutes of waiting per run that is 10 × 10 × 2.5 min, roughly 4 hours a day and about 80 hours a month spent staring at a terminal. With Oxlint (1.3 s per run) it adds up to under two minutes a day.

And that is before we count:

• CI/CD pipelines. Every minute in a pipeline is paid for (runners) and waited for (developers). Faster linting means faster feedback on a pull request and faster releases.
• Pre-commit hooks. People start bypassing a hook that takes 40 seconds with --no-verify. Nobody disables a hook that takes a second.
• Delivery. A faster cycle means features and bug fixes reach clients sooner. That is what the customer asks about.

Where AI fits in#

This is where the speed multiplies. A developer runs lint a few times a day. An AI agent runs it after every iteration, easily twenty times per task.

If every run takes two minutes, the agent either waits (and you wait with it, or pay for cloud agent runtime), or, which is worse, starts skipping the check. Slow feedback means the agent does more work blindly and then fixes more things at once.

As for tokens, let us be precise: waiting itself does not burn tokens. What burns them is the number of iterations and the size of the context. When the agent gets fast, precise feedback right after every change, it fixes the problem while it is still small. When it gets feedback only at the end, it has to re-read a bigger chunk of code, untangle dependencies and fix things it has since built on a wrong foundation. Depending on the model you use, you can see that on the invoice.

The result: a fast linter is to an AI agent what fast tests are to a human. As long as it takes seconds, it gets used. Once it takes minutes, people start walking around it.

How we set it up#

Let us not stay in theory. This website runs on Oxlint and Oxfmt. The linter config looks like this:

import { defineConfig } from 'oxlint';

export default defineConfig({
    plugins: ['import', 'unicorn', 'react', 'typescript', 'jsx-a11y'],
    categories: {
        correctness: 'warn',
    },
    rules: {
        'eslint/no-console': ['error', { allow: ['warn', 'error'] }],
        '@typescript-eslint/consistent-type-definitions': ['error', 'type'],
        '@typescript-eslint/no-explicit-any': 'error',
        '@typescript-eslint/no-unused-vars': 'error',
    },
});

Look at the middle line. The consistent-type-definitions rule, which I once wrote my own ESLint plugin for, is now one line of config and runs natively in Oxlint. The same goes for the accessibility rules (jsx-a11y) that AI loves to skip.

And so we do not have to think about three commands, there is one in package.json:

{
    "scripts": {
        "lint": "oxlint",
        "fmt": "oxfmt",
        "cq": "oxlint && oxfmt --check && tsc --noEmit"
    }
}

cq (code quality) runs lint, the format check and types. The same command runs in CI. The same command is what we tell the agent. One sentence in the agent instructions (AGENTS.md, CLAUDE.md, rules) is enough:

Before you call the work done, run `pnpm run cq` and fix every finding.

That turns a "recommendation" into a gate the code has to pass, whether a human or a model wrote it.

It is not 100% there yet (and I would still not reach for anything else)#

I do not want to write an advert, so let me be straight: Oxlint and Oxfmt are not yet a 100% replacement for ESLint and Prettier. A few things you may run into:

• Not every rule exists. Oxlint covers more than 800 rules, but some special rule from an ESLint plugin you depend on may be missing.
• Custom ESLint plugins. Local plugins are not migrated automatically, but you can add them by hand to the config through jsPlugins. Oxlint supports most of the ESLint v9 API, not all of it.
• Prettier plugins and less common formats. Oxfmt is in beta and Prettier plugin support is still catching up. If you depend on the exact behavior of a specific plugin, check it in advance.
• Type-aware linting needs TypeScript 7. On an older version that is one more step.

So what do you do? My position is simple: until something better comes along, I would not reach for anything other than Oxlint and Oxfmt. Not because they are perfect, but because the speed difference is so large that a few missing rules or small deviations can be worked around, while a slow tool in your pipeline never can. Development is also moving fast: in a few months Oxfmt went from alpha to a beta with full compatibility on JS and TS, and type-aware linting became stable.

If you really miss a rule, you can bridge it by running Oxlint first and leaving ESLint only for what remains (oxlint && eslint, and the eslint-plugin-oxlint plugin turns off duplicates). Treat that as a temporary bridge, not the end state.

How to start (in an afternoon)#

Migration is surprisingly painless today.

Linter:

pnpm add -D oxlint
npx @oxlint/migrate

Formatter:

pnpm add -D oxfmt@latest
pnpm oxfmt --migrate=prettier
pnpm oxfmt

Keep the bulk reformat as a separate commit and add its hash to .git-blame-ignore-revs so git blame does not point at "who reformatted the whole project". Then update CI and pre-commit hooks, and finally put the command into your AI agent instructions.

Conclusion#

In a world where a model writes much of the code, consistency is not a luxury. It is the one thing that keeps a codebase readable for humans and for the next AI agents that come after you.

Rules have to be automatic (we do not want to think about them all the time), enforced (no "I will be more careful next time") and fast (otherwise everyone avoids them). ESLint and Prettier taught us that. Oxlint and Oxfmt took it to the point where a check takes a second, not minutes. And that pays off whether you are paying for developer time, CI minutes or tokens.

If lint is the step you run "at the very end" today, try switching it. It takes an afternoon. And then tell me how many seconds you got back.

We are not talking about a handful of cases. We are talking about hundreds of packages that were compromised. Attackers got into maintainer accounts (often through social engineering or leaked tokens) and smuggled malicious code into legitimate, widely used libraries.

Some of those packages had millions of downloads a week. Picture it: you come into work on Monday morning, run npm install, and without suspecting a thing you pull malware into the project. It steals your ENV variables or injects a cryptominer into your users' browsers.

It is frightening. And honestly, if you are relying on luck, it is only a matter of time before it hits you too.

Four layers of manual defence#

The first instinctive reaction is: "I'll stop using NPM!" That is a nice thought, but in modern frontend development it is about as realistic as building a skyscraper with a hammer and nails. We cannot do without the React, TanStack, or Tailwind ecosystem today.

There are steps I take to keep the risk down:

1. Minimalism and forking#

Before I add a new dependency, I ask: "Do I really need a whole library to format a date?" If it is a small utility, I would rather write it myself. If it is a more complex library that still carries a lot of ballast, I often make a fork. I take only the part of the code I need and put it straight into my repository. That cuts the cord to future updates (which may be infected).

2. Disabling scripts (ignore-scripts)#

Most of these attacks rely on postinstall scripts. Those are commands that run automatically right after the package is downloaded. Attackers love them. It is the perfect place to hide a curl that sends your .env files to their server.

The defence is simple. In the project root (next to package.json) add an .npmrc file with this content:

ignore-scripts=true

That disables these scripts globally. Yes, it occasionally breaks the install of a legitimate tool (esbuild or Cypress, for example), but you can fix that by allowlisting specific packages. The security is worth it.

3. pnpm, and versions that have been out for a while#

npm downloads a package the minute someone publishes it. An attacker ships a version, you run the install in that same moment, and it is on your machine.

pnpm, from version 12, does not do that by default. It has a rule called minimumReleaseAge: it only downloads a version that has been on the registry for more than 24 hours. The value is in minutes, and the default is 1440 (one day). Most of those compromised releases are found and removed from the registry within the first few hours. A day's delay cuts you off from them before you download them.

A day is not enough for me. I want versions that are 7 to 14 days old, that have been out for a while, and that nobody has had to yank as malware. You set it in pnpm-workspace.yaml. Seven days is 10080 minutes, fourteen is 20160:

# 7 days. If the project can wait two weeks, put 20160 here.
minimumReleaseAge: 10080

This applies to transitive dependencies too, not only what you listed in package.json. You can still install a newer version when its turn comes. It just will not be the one that came out ten minutes ago.

4. Explicitly pinned versions#

Writing "react": "^19.1.0" in package.json does not say "I want React 19.1.0". It says "take anything from 19.1.0 up to just below 20". The caret and the tilde are open doors. Delete the lockfile, run pnpm update or start the project from scratch, and a version you have never seen ends up in your project. That is exactly how most of the compromised releases of 2025 spread: through ranges that happily accepted them.

So I write versions exactly, with no ^ or ~:

{
    "dependencies": {
        "react": "19.1.0",
        "@tanstack/react-router": "1.120.3"
    }
}

So that it does not depend on my memory, I tell the package manager too. In pnpm-workspace.yaml:

saveExact: true

With npm, the line save-exact=true in .npmrc does the same. Add a lockfile committed to the repository and pnpm install --frozen-lockfile in CI, so the build never reaches for anything that is not in the lockfile. The Renovate config below has "rangeStrategy": "pin" for the same reason. When it does bump a version, it writes it exactly again.

Security is not the only reason, though. The second one comes from Brussels.

The Cyber Resilience Act (CRA), EU Regulation 2024/2847, applies to every product with digital elements sold on the EU market. That includes the web applications and SaaS you deliver to clients. From September 2026 manufacturers must report actively exploited vulnerabilities, and from December 2027 the obligations apply in full. One of them: know and document the components of your product, among other things in the form of an SBOM (Software Bill of Materials). That is a machine-readable list of all dependencies and their versions, typically in the CycloneDX or SPDX format.

This is where pinning pays off a second time. An SBOM is useless if it does not match what actually runs in production. With ^ ranges, package.json is just a wish. Only exact versions and a locked lockfile guarantee that Monday's build and Friday's build contain the same thing, and that the SBOM generated in CI describes exactly what you deployed. When an advisory for a specific version comes out, you look at the SBOM and know within a minute whether it affects you. That is exactly what the CRA asks of manufacturers.

You can then generate the SBOM on every build, for example with CycloneDX's cdxgen:

npx @cyclonedx/cdxgen -o sbom.json

The CRA does not literally say "pin your versions", but without them the requirements for an overview of your components are hard to meet.

Automation: when a person is not enough#

Manual steps are fine, but they have one weakness: me. I forget. I do not have time every morning to read security reports and check whether lodash 4.17.21 happens to be vulnerable.

I spent a long time looking for a tool that would watch my back. I needed something that:

1. Runs automatically (CI/CD).
2. Knows the vulnerability databases (GitHub Security Advisories, OSV).
3. Will not bother me with updates I do not need, but will shout when it is a security issue.

The winner was Renovate Bot.

My "security-first" config#

Most people know Renovate as the tool that bumps package versions for you. "A new React version is out? Here is a PR."

I use it differently. On stable projects I do not want the bot "breaking" the app with minor updates I do not need. I want it to stay quiet and speak up only when my current version contains a security hole.

This is the configuration I am testing right now, and it lets me sleep:

{
    "$schema": "[https://docs.renovatebot.com/renovate-schema.json](https://docs.renovatebot.com/renovate-schema.json)",
    "extends": ["group:turboMonorepo", ":semanticCommits"],
    "timezone": "Europe/Prague",
    "prConcurrentLimit": 10,
    "prHourlyLimit": 0,
    "dependencyDashboard": true,
    "dependencyDashboardApproval": false,
    // This is where it starts: turn on security alerts
    "vulnerabilityAlerts": {
        "enabled": true,
        "labels": ["security", "vulnerability"]
    },
    "osvVulnerabilityAlerts": true,
    "automerge": false,
    "rangeStrategy": "pin",
    "schedule": ["at any time"],
    // Rule that disables ALL updates...
    "packageRules": [
        {
            "description": "Disable all non-security updates",
            "matchUpdateTypes": ["major", "minor", "patch", "pin", "digest", "lockFileMaintenance", "rollback", "bump", "replacement"],
            "enabled": false
        }
    ]
}

How does it work?#

Look at the packageRules section. It explicitly says: "Disable (enabled: false) every update type (major, minor, patch...)."

If I stopped there, Renovate would do nothing. But because I have vulnerabilityAlerts and osvVulnerabilityAlerts turned on above, Renovate still checks the vulnerability databases.

The result?

• axios v1.8.0 comes out (a new feature)? Silence. Renovate leaves me alone.
• It turns out axios v1.7.0 has a security hole? ALARM. Renovate immediately opens a pull request with the fix to a safe version and tags it as security.

Wire this config into a GitHub or GitLab CI pipeline and run it once a day (or every hour).

That way I know that even while I am asleep, my repository is being compared with the latest threat databases. It is not 100% protection (that does not exist), but it is much better than hoping it will pass me by.

Chaos when a team scales without clear rules#

When I started working with TypeScript at my company, the team was small, just a handful of developers. We had a verbal agreement to stick to type aliases instead of interface declarations, because they felt more predictable (more on that later). At first it worked beautifully. We were aligned, the code was clean, and life was fine. Then the team grew fast. Within a year we had 10 developers contributing to the same codebase, and that is when things got complicated.

New teammates were not always aware of our “unwritten rule”. Some preferred interface, because it felt more familiar from their Java background. Others mixed both approaches without even noticing. Code reviews turned into endless debates about style rather than substance. It was clear we needed a better way to enforce consistency, something automated, reliable, and able to scale. So I decided to roll up my sleeves and build my own ESLint plugin: eslint-plugin-interface-to-type. It would automatically enforce type instead of interface across the whole codebase and save us from ourselves.

Why I chose type over interface#

Before we get into the technical details, let us talk about why I chose type over interface in the first place. At a glance they look interchangeable. Both describe the shape of an object, right? But there is a subtle difference that can bite you on a larger project: declaration merging.

In TypeScript, if you declare two interface definitions with the same name, they are merged into one automatically. Here is a quick example:

interface User {
    id: number;
}

interface User {
    name: string;
}

// TypeScript merges them into:
interface User {
    id: number;
    name: string;
}

That behaviour can be useful in some cases, for example when extending types from third-party libraries. In a collaborative codebase it is a recipe for confusion. Picture two developers unknowingly declaring conflicting properties in separate files. That is a bug waiting to happen. Type aliases, on the other hand, do not merge. If you try to declare two type aliases with the same name, TypeScript throws a compile error, which forces you to resolve the conflict up front. For me, that predictability is a lifesaver.

Besides declaration merging, type aliases are more flexible. They can represent unions, intersections, and primitives, things that interface struggles with. Interface still has its place (for example when you need to extend a class), but I found that type is the safer default for most of our use cases.

Building the ESLint rule: From chaos to consistency#

Once I had a clear reason to enforce type, I needed a tool that would do it automatically. That is where my ESLint plugin, eslint-plugin-interface-to-type, comes in. I wanted a rule that would flag any interface declaration, suggest replacing it with a type alias, and even offer an autofix to speed the process up.

Writing a custom ESLint rule was a bit scary at first. I had never written one. After some research I got the hang of it. The plugin uses the ESLint AST (Abstract Syntax Tree) to detect interface declarations and transform them into equivalent type aliases. For example, this:

interface User {
    id: number;
    name: string;
    role: 'admin' | 'user';
}

gets flagged, and it can be fixed automatically to:

type User = {
    id: number;
    name: string;
    role: 'admin' | 'user';
};

The hardest part was the edge cases, such as interface declarations that extend other interfaces, or ones with complex generics. I spent hours tuning the rule so it stayed compatible and avoided false positives. Another challenge was the autofix. The ESLint --fix option needs exact transformations, so I had to map interface syntax onto type syntax carefully, without breaking the code.

Once the plugin was done, setting it up was straightforward. Install it as a dev dependency:

npm install eslint-plugin-interface-to-type --save-dev

Then add it to your ESLint config:

{
    "plugins": ["interface-to-type"],
    "rules": {
        "interface-to-type/prefer-type-over-interface": "error"
    }
}

Run ESLint with --fix and it converts your interface declarations into type aliases. Done.

Impact on how we work: Less arguing, more building#

The effect on the team was immediate. We used to spend chunks of code review arguing about interface vs. type. Now the rule enforces consistency for us and frees up mental space for discussions that matter more, such as architecture or performance.

It also saved us time. New developers no longer needed a long introductory lecture about our style preferences. The rule simply handled it. Code reviews got faster, because we were no longer nitpicking syntax. It is a small change, but the knock-on effect was huge.

Tips for developers: How to make this work for your team#

If the idea appeals to you, here are a few tips to help you enforce type, or any coding standard, in your projects:

1. Understand your needs first. Before you enforce type instead of interface, make sure it matches what your team is trying to do. If you rely heavily on declaration merging or on class implementations, interface may still have a place. For us, type worked better in 99% of cases, so it made sense to standardise on it.
2. Automate it with tools such as ESLint. Do not rely on verbal agreements. They do not scale. Tools such as ESLint (or Prettier for formatting) can enforce rules consistently across the whole team. Writing your own rule can sound intimidating, but it is a great thing to learn, and it pays off in the long run.
3. Get the team on board. If you are introducing a new standard, get feedback from your colleagues first. Before I rolled the ESLint rule out, I shared it with the team, and their input helped me catch a few edge cases I had missed.

Try it yourself and let me know#

Switching to type aliases and enforcing them with a custom ESLint rule was a real change for my team. The code became more predictable, reviews more productive, and onboarding smoother. If you are dealing with similar problems, or you just want to experiment with stricter standards, I recommend trying it.

Start by installing eslint-plugin-interface-to-type and running it on your codebase. See what it feels like to have a consistent approach to types in TypeScript. Do you see interface vs. type differently? Or did the rule surface unexpected problems in your project?