If you follow the React ecosystem closely, you've probably tripped over this announcement this week. Dominic Gannaway launched Octane, described as "the React programming model, compiled". It's the declared successor to Inferno, the framework Gannaway himself built back in 2016 with the same performance pitch.

It's worth pausing to understand two things. First, what it actually does technically. Second, and more important for anyone making stack decisions, what its arrival says about where React is heading.

Have you ever spent half an hour refining a prompt — making the instructions clearer, more detailed, adding examples, adding constraints — and the agent kept failing in exactly the same way?

You've been there: the model hallucinates even with a perfect prompt. Or worse: the agent acts on the world, does something it shouldn't, and you find out in production. Not in the test chat, not in the sandbox. In production, with real data.

That's not a prompt problem. And polishing the system prompt text won't fix it.

This article is about understanding where the problem actually lives — and why conflating these three layers of AI engineering wastes time, money, and sometimes causes incidents.

Over the past few months I've been using Claude Code intensively in my work and personal projects. It's not hype — it's an actual work tool. And like any tool, there's a right way to use it, there are traps, there are limits, and there are combinations with other things that change the game.

This article is an honest account. What worked, what didn't, what I learned the hard way, and what I'd tell any developer just starting out. If you want the marketing pitch of "AI will replace programmers," this article isn't for you. If you want to know how to get the most out of it without losing your mind, keep reading.

Machine learning always seemed distant from frontend — Python, powerful servers, expensive GPUs. But that changed. Today it's possible to run a trained AI model directly in the browser, with zero backend, using pure JavaScript and the user's own GPU.

This article explains how this works in practice, using TensorFlow.js as a foundation — and how I applied it in a project called SeeFood, a classifier that solves humanity's greatest problem: knowing whether what you're about to eat is a hot dog or not.

There's a type of bug that doesn't break the build, doesn't show up in the logs, doesn't land in Sentry, but kills your product overnight: user A opening the application and seeing — out of nowhere — user B's data. Transaction, balance, tax ID, address, whatever. And the worst part: in almost every project where I saw this happen, the problem wasn't "a bug" in the code. It was the total absence of RLS in the database.

Today I want to talk about Row Level Security, which is literally the wall that separates one user's data from another's — within the same table.

Anyone who has spent hours chasing an undefined in the middle of a bundle or a strange behavior only in production knows how an unresolved import chain can become a headache. One of the frequent culprits is the circular import: module A imports B, B imports C, and somewhere in the chain someone imports A again — closing a cycle.

It's wonderful — the build works, the project runs locally, but when you try to deploy, it breaks! \o/

I've seen this in small projects and in large ones; the only difference is the size of the problem you'll face. You can spot the headache with Madge and it's a lifesaver!

To lock up TypeScript, a circular import is a treat.