
An API Is a Boundary, Not a URL
A working endpoint is not yet a reliable API. The real contract includes validation, errors, retries, idempotency, and a way to evolve without making yesterday’s frontend fail tomorrow.

A working endpoint is not yet a reliable API. The real contract includes validation, errors, retries, idempotency, and a way to evolve without making yesterday’s frontend fail tomorrow.

A frontend request does not jump straight from the browser into your backend. It crosses DNS, encrypted connections, edge infrastructure, application code, and a database before the UI sees a result.

I built a personal AI reviewer for GitHub Pull Requests, not as a cold rule bot, but as a local and observable tool that checks known risk patterns and turns them into useful engineering conversation.

What interests me about TypeSafe's Jev is turning human language into data we can query. Restaurant reviews, product complaints, and Reddit discussions make the idea much more concrete than another chatbot benchmark.

I arrived at Liberty with a working model for agentic development. Now the company is exploring a more formal approach built around reusable agent skills. I don't know which model will prove better yet, and that uncertainty is the interesting part.

For the Silpo AI Factory hackathon, the interesting problem was not building another AI shopping chat. It was figuring out where AI should stop, where deterministic procurement logic should begin, and how MCP could execute a controlled supplier workflow at the end.

Every micro-frontends pitch I've seen leads with the technical benefits — independent deploys, framework isolation, smaller bundles per team. Almost none of it holds up unless the real problem was organizational to begin with. Conway's Law isn't a fun fact here. It's the actual justification.

Every frontend architecture is really just a decision about which axis you slice the app along — by technical kind, or by feature. Both are correct. Both eventually hurt. The question worth asking isn't which one is better, it's which one is cheaper to be wrong about later.

How Nivra went from a vague hackathon direction to a tested WebMCP workspace: choosing the right idea, making architecture the shared context, and proving that human UI, agent tools, and deterministic validation could work from the same model.

Feature-Sliced Design got popular because frontend spent years being treated as the part of the codebase that didn't need real architecture. It fixed that perception. It did not fix cohesion, and pretending it did is how you end up with a button smeared across ten folders.