Engineering on sbgrl.me

The end of tech-debt?

sylvain.bougerel@gmail.com (Sylvain Bougerel) — Sat, 16 May 2026 18:03:00 +0800

After Claude Code performed a refactor across our codebase in less than 24 hours and mostly autonomously, I started to wonder if we could end our tech-debt, and put a price on it?

Setting the stage
#

The codebase I’m referring to is that of our main Next.js application. It’s not a small codebase by any measure: 200KLOC, 1500 files, Typescript, Terraform and other languages.

Within this codebase, we use both API route handlers and server functions to fetch or mutate data. Each mechanism fits a specific purpose: an application should make its public API available via route handlers, while it should use server functions for internal mutations only.

In our application, however, we had leftover server functions used only to fetch data — without mutating it. This often resulted in the server function returning stale information, because it was doing something it was not designed for. We needed to migrate them to route handlers.

I had already fixed 4 of them, but I found 18 more that needed addressing.

This is not hard work, but not a dumb task either. Each case requires a new API route, a new contract, properly bounded inputs, validated outputs, updating how the client-side sends requests and handles responses, all while making sure it lints correctly and passes the ~2700 unit tests of our application — a perfect task for an agent.

Ralph to the rescue!
#

To make fixing the first 4 easier, I had already refined and tested a 150-line Claude skill. I knew it was time for a Ralph loop. So I set up the skill as the spec file, provided additional instructions around merge request (MR) submission and handling, and got it going in auto mode.

And it did. After 8 hours of work, it created 18 MRs for me to review, and continued to autonomously address the comments and fix any failures reported by the CI pipeline.

At the point where all 18 MRs were submitted and ready to merge, this task had cost roughly USD$180. I estimate that Claude went roughly 5-10 times faster than I would.

$180 is not a large amount of money for a specific, targeted refactor. We have dozens of those we can do to migrate and improve our codebase. Can we end tech-debt in our codebase?

Then reality caught up
#

After MR 6/18 merged into the main branch, our testing environment went down. It was not hard to notice: even a local test server would not run after rebasing. MR 6/18 contained a route that was not set up properly, and that could only be caught at runtime. It was an easy fix, and it reminded me that I had forgotten a step in my Ralph loop: I quickly instructed it to build comprehensive test cases for us to exhaustively verify the changes.

Testing is going to need improvement, but we knew this; we had already started to experiment with end-to-end tests to tackle this tech-debt. Here again, with great help from Claude, we managed to automate some end-to-end testing. However, in contrast to the current migration, none of the results so far have been satisfactory. This time, it seems our issues have more to do with the design of our application — and the solution isn’t yet clear.

The trouble with the process
#

But the testing environment going down was not actually the biggest friction — it was fixed quickly. The problem was that it took Claude 4 to 5 hours just to merge the remaining 12 MRs after MR 6. 8 hours of productive work, 4 hours of watching paint dry.

We use short-lived development branches against the origin/main trunk, and maintain a semi-linear history on merges (trunk-based development). This means that after each merge, the next merge request needs to be rebased, and the CI pipeline must run again. A rebase + CI cycle takes around 8 to 10 minutes today; and if the pipeline fails or a conflict occurs during rebase, additional CI cycles may need to run.

Every day, we race each other to merge our work. That day, we also raced the 18 MRs the agent had to merge. And our CI pipeline is not going to get faster — if anything it’s going to take more time once we add end-to-end tests.

So, can we end tech-debt?

In short, not all tech-debt scales equally well for agents, especially when the issue may have more to do with application design or the solution is not yet clear — as in our case with end-to-end testing.

And while we can certainly price some migration work, or even execute it concurrently with our feature work, it still needs to clear CI. Agents didn’t eliminate the implementation bottleneck — they moved it to the CI process.

I now find myself thinking about merge trains and other merging strategies to eliminate the CI bottleneck. I’m also wondering whether larger organisations are now experiencing the same pressure on their CI processes, and how this will shape the future of CI and trunk-based development.

Why I continue to review code

sylvain.bougerel@gmail.com (Sylvain Bougerel) — Fri, 01 May 2026 10:01:00 +0800

Given the increase in velocity from coding assistants such as Claude Code and Copilot, automated review had become a necessity. Since we rolled out Coderabbit on our project, almost everybody stopped reviewing code. It didn’t happen immediately, but organically.

As it turns out, Coderabbit is a formidable reviewer: with only a bit of context in the commit messages and a well-written AGENTS.md, Coderabbit will often be more thorough in reviews than most of my colleagues. And if that wasn’t enough, Coderabbit is almost always available—98.3% of the time in the last 30 days, not good for typical SLA targets but much better than colleagues—and a fraction of their cost.

Eventually everybody stopped reviewing code… Save for me.

For one thing, coding assistants can hallucinate blunders that neither humans—regrettably—nor Coderabbit will catch:

const NON_EDITABLE_BOOKING_STATUSES = new Set([
 'cancelled',
 'canceled',
 'declined',
 'withdrawn',
]);

I took that snippet from a merge request submitted yesterday. We do not have any declined or canceled statuses in our entire domain model—they simply don’t exist. I chose this example because it’s one of the simplest. The day before, a merge request had a complete re-implementation of a 200+ lines utility we already had. This happens all the time.

But most importantly, if the phone rings because of an issue on the system, I need to get on the call and fix the issue. When my work has potential to impact my personal life and my weekends with family, there’s no AI that I will trust enough. And every alert, whether it fires on the job or not, still costs the whole team velocity when we scramble for unplanned work.

Ultimately, our customers don’t care who wrote the code: “We’re sorry, Claude wrote that line and Coderabbit didn’t catch the problem” is not a good look. No matter how powerful our tools have become, responsibility is still mine. So I’ll keep on reviewing code.

AI exacerbated the divide between engineers

sylvain.bougerel@gmail.com (Sylvain Bougerel) — Sat, 25 Apr 2026 22:12:00 +0800

Any complex product requires deep context about the product’s domains, architecture, implementation. And if you want to make effective use of AI to solve a problem, you need to inject the right subset of that entire context into the prompt, or that smart auto-complete will spit out costly nonsense.

Naturally, engineers with the best understanding of the context, the capacity to articulate the problem and the skills to implement it are even stronger with AI: they can provide better input to the model and quickly validate its output. The once derided 10x engineer is starting to become a reality for anyone who can use AI to implement a correct solution at a fraction of the time it would have taken them.

On the other end of the spectrum, weaker engineers are now compelled to keep up with the pace set by their stronger peers, only they can neither prompt the LLM effectively nor validate what it produces. So they just let the garbage out—knowingly or not.

If you feel like you’ve become a “man-in-the-middle”—a proxy between somebody else’s request and an LLM—you will be phased out. The great engineers of today learned the ropes at a time AI didn’t exist, when they could invest in their fundamentals. Give yourself the same gift: carve out time to use less AI, and start learning again so you can close the divide.

Should you use React Strict Mode in Next.js?

sylvain.bougerel@gmail.com (Sylvain Bougerel) — Tue, 03 Mar 2026 17:34:00 +0800

If you’re not familiar with React StrictMode, you’re probably not using a framework like Next.js that enables it by default. Strict Mode aims to help you find bugs during development. But it feels more like a band-aid that can reveal bugs or hide them, especially when mixing with server-side rendering (SSR).

In this post, I will assume you’re using SSR and Strict Mode too as they are usually enabled by default with Next.js.

Enter the rabbit hole
#

Now let’s suppose you write the following component, that renders a simple <time /> markup for a given date. Nothing fancy:

export default function LocalTime({ date }: { date: Date }) {
 const isoString = date.toISOString();

 return <time dateTime={isoString}>{date.toLocaleString()}</time>;
}

Let’s say you also have a simple home page, in your typical React application:

import LocalTime from "./local-time";

export default function Home() {
 return (
 <main>
 It is <LocalTime date={new Date("02/03/2026, 10:00 AM")} />
 </main>
 );
}

If your application uses SSR, what you will see always depends on your locale and on the time zone of the server; in this case, with an en-US locale and a UTC timezone, the server will render the following page, even in development:

It is 2/3/2026, 10:00:00 AM

However, that’s usually not what you want for your clients. Let’s say your client lives in Singapore, they should expect to see a time in a different timezone (GMT+8 in the case of Singapore). If you’re a bit experienced, you know your component must run on the client, and there’s a "use client;" directive in React that ensures a component can be an entry point to client rendering. You update the LocalTime component:

"use client"; // new directive

export default function LocalTime({ date }: { date: Date }) {
 const isoString = date.toISOString();

 return <time dateTime={isoString}>{date.toLocaleString()}</time>;
}

Your development server hot-reloads and this time you see:

It is 2/3/2026, 6:00:00 PM

Success! However, when you refresh the page, you notice there’s a flicker: the UTC time shows first, then the local time appears. You pull up the console, and you see a pretty large error message:

Uncaught Error: Hydration failed because the server rendered text didn't match the client. As a result this tree will be regenerated on the client. This can happen if a SSR-ed Client Component used:

- A server/client branch `if (typeof window !== 'undefined')`.
- Variable input such as `Date.now()` or `Math.random()` which changes each time it's called.
- Date formatting in a user's locale which doesn't match the server.
- External changing data without sending a snapshot of it along with the HTML.
- Invalid HTML tag nesting.

We’ve hit a classic issue with React SSR/CSR: hydration mismatch due to a time zone difference between the server and the client. And more importantly, you might not have noticed that error at all. The flicker might not have caught your attention, you might not have looked at the console.

You might just have deployed it to production. And to your surprise, once in production the page would show the UTC time only. It seems the component did not run on the client. Not a great user experience:

It is 2/3/2026, 10:00:00 AM

In reality, there was no reason for your component to re-render on the client again after hydration. This happened in development only due to React Strict Mode, so we’ve been led down the wrong path; thinking the application worked where it didn’t. You think this example is contrived? At Canterly, we have already faced 3 scenarios similar to this one; each time React Strict Mode was hiding an issue.

The reasoning behind Strict Mode
#

React brings a flavor of functional programming (FP) to UI. In FP, when the output of a function is defined only by its input, and it has no side effects, we call it a pure function. The React equivalent means that the rendering of a component should be idempotent: it depends only on the component properties, its state and its context. These 3 sources of information are the rendering inputs in React; you should not use any other inputs.

That is not to say React does not handle side effects. However, you should confine side effects to events handlers, and in case you can’t find a suitable event handler for your side effect, React dedicates a whole phase of its update to side effects which you declare in the use*Effect() hooks. The steps below are an over-simplification of an update with React (more about it here):

If there are no updates to component inputs, go to the last step;
Render updated components;
Run side effects;
Return to the top;
Commit changes to the DOM.

Idempotency allows React to track component changes by looking only at their inputs. However, it’s easy to break idempotency if you unknowingly use an external input, modify properties incorrectly or rely on a variable during rendering that is not provided through its properties, state or context.

To help uncover these issues, React introduced Strict Mode. Wrapping your component in <StrictMode> adds an extra render on mount and after the side effects run, to check that rendering was not impacted:

If there are no updates to component inputs, go to the last step;
Render updated components;
Run declared side effects;
Strict mode: render all components once more and check there are no differences with the output in 2.
Return to the top;
Commit changes to the DOM.

If your React component is pure, then that extra render should be idempotent and similar to the first.

False positives with Strict Mode
#

Returning to our example: the first server-side render produces an incorrect UTC time, which could have been caught if it was not immediately redrawn by the extra Strict Mode render that occurred when React mounted the component. Instead, the developer saw the local time.

This little example illustrates that this approach is just as likely to catch a bug as to hide one, since Strict Mode can lead to false positives. Especially if you’re not careful with checking hydration issues.

It’s worth noting that a more careful developer could also catch the hydration mismatch. And they might be tempted to address the locale & time zone hydration mismatch by simply silencing it, since this component does not have any children:

"use client";

export default function LocalTime({ date }: { date: Date }) {
 const isoString = date.toISOString();

 return (
 <time dateTime={isoString} suppressHydrationWarning>
 {date.toLocaleString()}
 </time>
 );
}

Perhaps unexpectedly, once the component uses the property suppressHydrationWarning, the UTC time rendered server side re-appears and is not replaced by the local time in development. Even in the presence of Strict Mode, the component is not regenerated again. This could have revealed the error again; but requires employing a property that is usually discouraged.

Beyond Strict Mode
#

Since React 18, the React Compiler has grown a new linter. I highly recommend the React Compiler ESLint plugin. While it does not address all the objectives of Strict Mode, there’s a significant amount of overlap between the two tools. In my own usage, I have found that the linter helps me better with identifying violations of the Rules of React.

Unfortunately, when it comes to our little example, the linter does not identify that date.toLocaleString() requires a time zone and a locale that are not declared as input to the component. The linter is still a work in progress; I hope that these limitations will eventually be addressed.

I will leave you with a version of the component that follows the Rules of React (note that this version will not scale well if you have a lot of components to render):

"use client";

import { useEffect, useEffectEvent, useState } from "react";

export default function LocalTime({ date }: { date: Date }) {
 const [formattedDate, setFormattedDate] = useState(
 // Fix a locale and a time zone for idempotency
 date.toLocaleString("en-US", { timeZone: "UTC" }),
 );
 const isoString = date.toISOString();

 const onMount = useEffectEvent(() => {
 setFormattedDate(date.toLocaleString());
 });
 useEffect(() => {
 onMount();
 }, []);

 return <time dateTime={isoString}>{formattedDate}</time>;
}

This may seem a little complicated for a component that just renders a date without any interactions; but remember that there’s a hidden side effect in the original rendering. And unfortunately, in this specific scenario, Strict Mode put us on the wrong path.

One of the selling points of Strict Mode is that it will help reveal the issues with components that violate the Rules of React. But I would argue that if the issues can’t be found without Strict Mode, then you might as well just ignore them: your component is probably too simple to care about them. Otherwise, you should always pay attention to hydration issues and ensure your project uses the React Compiler ESLint plugin.

Introducing @sbougerel/eslint-plugin-next-use-client-boundary

sylvain.bougerel@gmail.com (Sylvain Bougerel) — Sat, 14 Feb 2026 17:46:00 +0800

In my last post I spoke about releasing an ESLint plugin to lint the serialization of 'use client' module entries. I’ve spend a few hours with Claude code to get this done and published on npmjs.org. I’ll probably come back in another post on the experience there (Some gains, some losses). I’ve just started a branch on my product to use the plugin, looking forward to see if it’s useful to others.

Don't abuse 'use client'

sylvain.bougerel@gmail.com (Sylvain Bougerel) — Sat, 31 Jan 2026 17:56:00 +0800

I see 'use client' used too often in our own code base, and it seems to be a matter of confusion elsewhere too: devs don’t understand 'use client' or don’t want to get into it. Let me give a quick explanation of why you should not use it everywhere and hopefully, by the end of this post, you’ll have at least understood what it is not for.

'use client' indicates that a client module can be called within server modules. No more no less. That means 'use client' modules have some restrictions, because they can sit at the server-client boundary:

When a server evaluated module imports values from a 'use client' module, the values must either be a React component or supported serializable prop values to be passed to a Client Component. Any other use case will throw an exception.

(Source: React reference)

The thing is: most types are serializable, so you don’t generally see an issue with putting 'use client' everywhere. But one commonly used type is not: plain simple functions. It should make intuitive sense: a reference to a function is meaningless at the server-client boundary (unless it is a server action).

In practice: if your reactive client component exposes events to its parents, like onSubmit and onCancel in the component below, that means we expect the parents to be client component themselves.

 export default function LineItemForm({
 account,
 onSubmit,
 onCancel,
 }: {
 account: string;
 onSubmit?: (data: LineItemData) => void;
 onCancel?: () => void;
 }) {

How could it be otherwise? The function onSubmit or onCancel could never cross the client-server boundary. Thus, you can remember now:

When an exported client component has properties that are not serializable, like functions, its module should not start with 'use client'.

Now, you may be thinking: “But adding 'use client' does not hurt anything, right?” Ever taken painkillers when you don’t need it? It’s the same reasoning: it does not harm, but at the critical moment where you need to feel pain, you’re suddenly numb to it.

Without 'use client' at the top of that component, the compiler will not let you call that client component from a server component. But with an incorrect 'use client' the compiler will just obey and assume you’ve made sure the properties are serializable without checking, and misusing that component in server components could result in runtime errors.

Unfortunately, I cannot find any linter that lints this. There is however a dynamic warning provided by the typescript-language-server: Props must be serializable for components in the "use client" entry file. Adding a linter for this would be an interesting project.

3 rules for simple tenancy in DynamoDB

sylvain.bougerel@gmail.com (Sylvain Bougerel) — Mon, 12 Jan 2026 12:39:00 +0800

Access control in DynamoDB
#

DynamoDB does not come with its own account management & fine-grained access control. Instead, it integrates with IAM, just like other AWS services.

This is great when your users authenticate with IAM, but it’s not the case of the majority of serverless web applications that authenticate users via OAuth.

Serverless web applications on AWS are usually structured this way: API Gateway receives a request, proxies this request to a Lambda, that constructs the response, optionally querying DynamoDB. In this architecture, the Lambda runs with a static IAM role. OAuth authentication is performed in the Lambda runtime using this static role; i.e. no fine-grained IAM access control.

This approach is usually preferred because it is simple, responsive, and yet scales. It leaves the responsibility of access control to the Lambda’s runtime, however¹.

If you’re writing a SaaS application in particular, you need to make sure that your tenants are isolated.

Fortunately, by following 3 rules, DynamoDB can provide tenant-based access control.

All partition keys have `tenant`
#

Make the tenant identifier a constituent of all your items’ partition key (a.k.a. hash key). For a String partition key, with a single-table design, the value of the partition key be:

${tenant}#${entity_kind}#${item_partition_key}

No `SCAN`
#

All other CRUD operations are allowed, however you shall not use scan. Scanning in DynamoDB reads any of your partitions at random. Thus, it bypasses the first rule. Enforce this in your Lambda role permission: deny dynamodb:Scan.

Get `tenant` from the request only
#

The final piece: the tenant identifier is always provided by the request. It shall not be a value you can retrieve from a query in the same table. If you do need to provide a list of tenants somewhere, this should be done separately, in a different table or preferably in a different cell.

How does it work?
#

All CRUD operations in DynamoDB require a partition key. All except scan which is why we disable it in rule 2.

Rule 3 ensures that a client’s access to a tenant partition is handled separately; the tenant identifier acts as a message passed between this step and the current requests; isolating each request to a single tenant. As a corollary, you should treat any request that require access to multiple tenant with higher restrictions, ideally running on a separate Lambda with the least privileges.

Finally, rule 1 leverages rule 2 and 3 to ensure that your CRUD operations can only retrieve information from that tenant’s partition, since it becomes impossible to access other tenants’ data without their identifiers.

Limitations
#

While this works well to isolate requests to a single tenant, this remains a “coarse-grained” approach; you do not have access to the attribute based access control provided by IAM and will need to implement the equivalent permissions in your application.

API Gateway’s Lambda authorizers allow you to provide context variables that can be used in dynamic fine-grained access control roles. This approach is more complex and not common for Next.js applications, in particular. ↩︎

Pino log instrumentation with Next.js 16

sylvain.bougerel@gmail.com (Sylvain Bougerel) — Sun, 04 Jan 2026 11:39:00 +0800

Recently at Canterly, we migrated from Next.js 14 to Next.js 16. In that process, we also switched from webpack to turbopack. This was a great speed improvement that came with some surprises. In particular, log instrumentation via next-logger now triggered a failure during compilation. I had been wanting to replace it anyway, since all it does is to patch console to use Pino instead (It also patches log functions in Next.js next/dist/build/output/log, which is redundant since these functions use console too). So instead, I patched console on my own. This is simpler and allows us to keep control over the instrumentation, rather than obfuscating the process with an additional dependency.

This is what we have now in instrumentation.ts:

export async function register() {
 if (process.env.NEXT_RUNTIME === 'nodejs') {
 const instrumentation = await import('./instrumentation-nodejs');
 await instrumentation.register();
 }
}

We’ve replaced next-logger.config.cjs with our own logger.ts which is a straight forward port:

import { LoggerOptions, pino } from 'pino';

let pinoOptions: LoggerOptions = {
 level: 'warn',
};

if (process.env.NODE_ENV !== 'production') {
 pinoOptions = {
 level: 'info',
 transport: {
 target: 'pino-pretty',
 },
 };
}

export const logger = pino(pinoOptions);

And in instrumentation-nodejs.ts:

import type { LogFn } from 'pino';

async function instrumentLogging() {
 // NextJS also patches `console` functions during development for better
 // debugging; bypass instrumentation unless the environment
 // variable CANTERLY_INSTRUMENTATION is "true"
 if (
 process.env.NODE_ENV === 'development' &&
 process.env.CANTERLY_INSTRUMENTATION !== 'true'
 ) {
 return;
 }

 const loggerModule = await import('./logger');

 const wrapLogger = (method: LogFn, ...args: unknown[]) => {
 if (args.length === 0) {
 return;
 }
 if (args.length === 1) {
 return method(args[0]);
 }
 // Converts usual Console usage to Pino's meta patterns.
 if (
 args.length === 2 &&
 typeof args[0] === 'object' &&
 args[0] !== null &&
 typeof args[1] === 'string'
 ) {
 return method(args[0], args[1]);
 }
 if (typeof args[0] === 'string') {
 return method({ consoleArgs: args.slice(1) }, args[0]);
 }
 return method({ consoleArgs: args });
 };

 const consoleLogger = loggerModule.logger.child({ name: 'console' });
 (['error', 'warn', 'debug', 'info', 'log', 'trace'] as const).forEach(
 (level) => {
 if (level === 'log') {
 console[level] = (...args) =>
 wrapLogger(consoleLogger.info.bind(consoleLogger), ...args);
 } else {
 console[level] = (...args) =>
 wrapLogger(consoleLogger[level].bind(consoleLogger), ...args);
 }
 },
 );
}

export async function register() {
 await instrumentLogging();
}

And that’s it. This instrumentation does not just replace next-logger, it improves on it. With next-logger, the following console call…

console.log("Log without interpolation", valueA, valueB, valueC)

…would be patched to the Pino call…

logger.log("Log without interpolation", valueA, valueB, valueC)

…but that would lose logging data: when the first argument is a string message, Pino will only keep other arguments when they get interpolated. This new instrumentation preserves the additional arguments, by treating them as a mergingObject.

Now, when our application starts, we can immediately see the additional arguments in the logs, as soon as instrumentation kicks in (We use pino-pretty as the default transport during development):

npm run dev
> ...
> env TZ=UTC next dev

▲ Next.js 16.1.1 (Turbopack)
- Local: http://localhost:3000
- Network: http://...
- Environments: .env.local

✓ Starting...
[03:23:14.265] INFO (console/28071): ✓ Ready in 1439ms
[03:23:14.447] WARN (console/28071): [auth][warn][debug-enabled]
 consoleArgs: [
 "Read more: https://warnings.authjs.dev"
 ]

NextJS revalidateTag won't work if it's not called in an awaited promise

sylvain.bougerel@gmail.com (Sylvain Bougerel) — Thu, 18 Dec 2025 18:37:00 +0800

Using unstable_cache extensions or "use cache" if you’re on NextJS16, you can leverage revalidateTag to invalidate cache across cached calls. However, I noticed today that these won’t work in a route handler that is not async. And I’m not yet sure why.

This was my original (simplified) route handler:

export async function POST(req: Request) {
 try {
 void someTask();
 return NextResponse.json({ done: true });
 } catch (err) {
 return new NextResponse(`Internal error`, {
 status: 500,
 });
 }
}

Note that someTask returns a Promise which I didn’t await initially: the caller only needed to know that someTask was called, not that it succeeded. However, it became evident someTask didn’t behave properly.

someTask gets a list of subscriptions and updates them progressively. After each update, it re-validates cache entries associated with the Subscription tag:

const cachedFindOutdatedSubscriptions = unstable_cache(
 findOutdatedSubscriptions,
 undefined, // Unused (For additional keys)
 {
 tags: ["Subscription"],
 },
);

export default async function someTask() {
 const subscriptions = await cachedFindOutdatedSubscriptions();

 for (const subscription of subscriptions) {
 await updateSubscription(subscription);
 revalidateTag('Subscription');
 }
}

The function cachedFindOutdatedSubscriptions returns subscriptions from a cache entry also tagged with Subscription. You would therefore expect that across repeated calls to this route, the subscriptions array becomes empty when no new subscriptions are created.

This is not what happened; the same subscriptions got reprocessed every single time, served from the cache. As if revalidateTag was not called.

Interestingly, the fix is simply to await the call to someTask in the route handler:

 export async function POST(req: Request) {
 try {
- void someTask();
+ await someTask();
 return NextResponse.json({ done: true });
 } catch (err) {
 return new NextResponse(`Internal error`, {
 status: 500,
 });
 }
 }

After reading the code for unstable_cache, I got the intuition for the fix. I’m not sure of what is exactly happening under the hood yet, but I think it has to do with the lifetime of the request’s context. I’ll return to this once I understand it properly.

Engineering on sbgrl.me

The end of tech-debt?

Setting the stage #

Ralph to the rescue! #

Then reality caught up #

The trouble with the process #

Why I continue to review code

AI exacerbated the divide between engineers

Should you use React Strict Mode in Next.js?

Enter the rabbit hole #

The reasoning behind Strict Mode #

False positives with Strict Mode #

Beyond Strict Mode #