2... I create a new package only if

- It's a separate service (production or dev app).
- It's a package shared between monorepos (currently I use Git submodules to do so), so fewer external dependencies.
- It's an open-source library published to a registry (which is rare).

2. I committed to extracting app code into "aspect" packages, and it has its benefits, but dependency wiring is just way too tiring. Moving and sharing code gets harder with every new package. Now I have monolithic "core" package that I share between apps.

1. I tried to work with recommended Turborepo setup with `tsc` for each package for few months and got back to references. I got tired of routinely restarting VS Code just to resolve weird problems. Also, single `tsc --build --watch` is just the best way to work on a TS project.

On the other hand, I'm having so much fun designing solid architecture and also writing a lot of code!

I'm actually happy that LLMs are bad at making changes keeping big picture in mind. They leave all the joy to us!

Here's an example of when it's handy.

It is a massive achievement for such a big company to put money where their mouths are.

I wish more companies were that dedicated, not for my wallet's sake, as I spend more money on Sentry than they gave back 💸, but for the health of the community!

I got boiled like the frog.

It's @OpenAI's gpt-5-codex with (mostly) high reasoning. Pro plan, if it matters.

The source code: gist.github.com/kossnocorp/4...

My takeaway is that you can't vibecode something like that. It needs an engineer in the loop, constantly improving the system.

This is despite detailed specs.

In hindsight I should've designed it myself, but it's hard to notice the problem without writing the code.

Nothing to refactor at this point, just a full rewrite.

The complication comes from the fact that VS Code extension backend communicates with a webview via messages, and without architecture established by a human engineer, it is doomed to fail.