Many have written about this already, but regardless of how you feel about AI (in engineering or otherwise), it’s hard to overstate how wonderful it is to be able to scratch your own itch.

I’ve always loved IntelliJ’s ‘history for line selection feature’, it’s great: select a line range and easily navigate through the history:

GitLens and similar VSCode extensions don’t really come close to this. You can say ‘show me the history for this line’, but it doesn’t let you easily navigate through just that specific range.

In just minutes I had exactly what I wanted in VSCode, thanks to Codex. Here it is (unpublished/not in the store):

Then, just the other week, while I was mucking around with Lua, I realized that the Busted VSCode test runner plugin wasn’t great and didn’t support debugging. So I vibe’d one. It works great, at least for my limited use case.

Maintaining this stuff and all the gnarly edge cases I’m sure remain unsolved is a different story, but how awesome is it to just be able to do this kind of stuff, off the cuff, in minutes?

There’s a temptation to make independent database operations concurrent:

await db.transaction(async (tx) => {
  await Promise.all([
    tx
      .update(accounts)
      .set({ balance: sql`${accounts.balance} - 100.00` })
      .where(eq(accounts.name, 'Dan')),
    tx
      .update(accounts)
      .set({ balance: sql`${accounts.balance} + 100.00` })
      .where(eq(accounts.name, 'Andrew')),
  ]);
});TypeScript

Inside a transaction, though, there usually isn’t any point. Even if both promises fire at once, the driver still has to send the statements down a single connection.

Anything not bound to the database connection can still run concurrently:

await db.transaction(async (tx) => {
  await Promise.all([
    otherAsyncWork(),
    tx
      .update(accounts)
      .set({ balance: sql`${accounts.balance} + 100.00` })
      .where(eq(accounts.name, 'Andrew')),
  ]);
});TypeScript

But you probably shouldn’t do other I/O in the middle of a transaction anyway if you can avoid it (especially writes). It keeps the transaction open for longer, and any external side effects won’t be rolled back.

It’s common to pretty-print logs to stdout during development:

[10:42:18] INFO  Request started
  method: GET
  path: /api/posts
  requestId: req_123

Then switch to structured logs in production:

{"time":"2026-05-24T10:42:18.120Z","level":"info","message":"Request started","method":"GET","path":"/api/posts","requestId":"req_123"}JSON

Pretty logs are nice when an app is small, but they become painful once things scale. Thousands of lines fly past, terminal search only gets you so far (your scrollback needs to be set absurdly high), and when the terminal closes, the logs are gone.

I’ve started to prefer writing structured logs to disk during development. Send them over to something like Logdy (if you want something lightweight), or VictoriaLogs (if you want something a bit more capable).

Then you get the same filtering, grouping, and JSON-attribute goodness you rely on in production. It’s also very useful to be able to point your agent at the logs of an already running process.

Here’s a trick that seems obvious in retrospect. If you want to represent a type like this in Zod:

type Order = { name: string } & (
  | { orderType: 'DELIVERY'; details: DeliveryOrderDetails }
  | { orderType: 'PICKUP'; details: PickupOrderDetails }
);TypeScript

You can just create the union type separately and then intersect it:

const OrderDetails = z.discriminatedUnion('orderType', [
  z.object({
    orderType: z.literal('DELIVERY'),
    details: DeliveryDetailsSchema,
  }),
  z.object({
    orderType: z.literal('PICKUP'),
    details: PickupDetailsSchema,
  }),
]);

const OrderSchema = z.object({ name: z.string() }).and(OrderDetails);

// Or this:
// const OrderSchema = z.intersection(z.object({ name: z.string() }), OrderDetails);TypeScript

Neat if you’re forced to keep the type discriminator top-level.

Vitest’s custom fixture support is great. Originally inspired by Playwright’s fixture setup, it’s now evolved into an auto-typed flexible builder:

const test = baseTest
  .extend('client', () =>  new UserClient())
  .extend('user', async ({ client }) => client.getUser())

test('Does the thing', async ({ user }) => {
  // No need to await user, it's already resolved.
})TypeScript

I’ve long wondered how they manage to lazily initialise fixtures based on object destructuring — even with a Proxy or similar it’s not possible to hide the async part. Today I finally took a look, and it’s actually pretty cursed:

// https://github.com/vitest-dev/vitest/blob/v4.1/packages/runner/src/fixture.ts#L646
let fnString = filterOutComments(implementation.toString())TypeScript

The trick is to stringify the function and extract with regex the names of the fixtures requested. Vitest can then build up the fixture dependency tree and resolve these before passing them to your test fixture.

It’s also why this doesn’t work:

test('Does the thing', async (ctx) => {
  // No proxy magic or anything wild, so this won't work -
  // only the function arguments are parsed.
  const { user } = ctx
})TypeScript

Turns out Playwright does the extact same thing.