Articles

Research notes, build journals, and product articles with enough room to think.

This page holds the long-form side of the site: how I think about retrieval quality, computer vision pipelines, AI infrastructure, interface pacing, and the mechanics behind systems that need to work in production.

Writing

Five articles, five distinct visual systems, no chatbot in sight.

I replaced the assistant gimmick with actual writing: research notes, build journals, and product articles that show how I think when the work gets technical.

Each article carries its own palette and mood.
Research note6 min readCobalt lattice

Meta Brain2Query Feels Like Retrieval Discipline Disguised As A Research Demo

Brain2Query matters less because it is flashy, and more because it treats query generation as a systems problem instead of a prompt flourish.

Article 1

Why it caught my attention

What I like about Meta's Brain2Query direction is that it does not pretend the user's first query is good enough. That is the quiet lie inside a lot of AI products: we act as if the first natural-language request is already optimized for retrieval, ranking, and action. It usually is not.

Brain2Query is interesting because it reframes the query itself as a learned transformation layer. That means the system can rewrite, decompose, or enrich what the user meant before the retrieval stack ever touches the index. When you take that seriously, recall improves without forcing the interface to become more technical.

What it changes in product terms

The practical implication is simple: the best AI products will stop treating retrieval as one vector search against one user string. Instead they will fan out into multiple latent queries, context-aware expansions, and ranked retrieval plans. The user keeps a calm interface; the system gets aggressive under the hood.

That matters because most production retrieval failures are boring. People search with vague language, internal jargon, half-formed goals, or the wrong nouns. A system like Brain2Query turns those weak starting points into structured retrieval intent. That is a better use of model intelligence than just generating prettier prose on the way out.

Where teams still get this wrong

A lot of teams will read work like this and immediately jump to “let's add another model call.” That is not the lesson. The lesson is to treat query planning as an explicit subsystem with observability: what rewrite was generated, what documents it pulled, what recall it improved, and what failure class it introduced.

If I were integrating this kind of pattern, I would instrument it like any other critical service. Save the original user query, the rewritten variants, the retrieved candidates, and the final answer path. Once you can inspect the chain, you can actually tune it. Without that, Brain2Query becomes another opaque layer you cannot debug when quality drifts.

Build journal7 min readStudio coral

Using SAM, Segmentation Masks, and FashionCLIP For Fashion Recognition At Silvr.ai

The interesting part was never just classification. The real leverage came from using segmentation to isolate the product signal before embedding or retrieval touched it.

Article 2

The problem with raw fashion imagery

Fashion recognition breaks quickly when the product is buried inside scene noise. Editorial backgrounds, model pose, lighting variation, accessories, and overlapping garments all compete for attention. If you embed the whole frame, your nearest-neighbor search ends up partially matching the wrong thing.

That is why the segmentation layer matters so much. With SAM-style masks in the loop, the system can separate dress from bag, jacket from background, shoe from leg. Once the object boundary is explicit, the downstream embedding model stops wasting capacity on context that should never have counted in the first place.

Why SAM plus FashionCLIP is a stronger stack

At Silvr.ai, the compelling path was not one giant model doing everything. It was a composed pipeline: propose or refine masks, crop the relevant item region, normalize that region, and send the cleaner visual payload into FashionCLIP or a related domain-tuned embedding path. That raises signal density before similarity search even begins.

Once the embeddings are cleaner, the retrieval layer gets more honest. You can compare silhouette, texture, color family, and product type with less contamination from background artifacts. The segmentation masks also create room for better metadata fusion because you can attach category confidence, region size, overlap behavior, and mask quality directly to the asset.

What I would optimize next

The next frontier is not just better masks. It is mask-aware ranking. In other words: similarity should know whether the compared regions describe a sleeve, a full garment, a handbag strap, or an entire outfit composition. The system should not treat all visual matches as equivalent units of meaning.

I would also push toward feedback loops from merchandisers and stylists. If humans keep selecting one retrieval cluster over another, that preference should tune the ranking layer. Once segmentation, fashion embeddings, and human selection data all line up, the system stops being a clever computer vision toy and starts behaving like a real commercial search product.

Product article5 min readSignal green

AI Products Need Better Pacing More Than They Need More Model Parameters

Users forgive latency when the system communicates intent. They do not forgive confusion, silence, or theatrical noise pretending to be progress.

Article 3

The hidden interface problem

A surprising number of AI interfaces still act like a blocking API call with rounded corners. You click, everything freezes, and eventually an oversized answer lands all at once. That is not intelligence. It is just bad pacing.

Good pacing means the product acknowledges the request, frames what it is doing, and reveals progress without becoming noisy. The model can stay exactly the same while the experience becomes dramatically more trustworthy, simply because the interface knows when to be quiet and when to surface motion.

How I think about response choreography

The first beat is confirmation: did the system understand the task? The second beat is direction: what path is it taking? The third beat is delivery: how should the user read or act on the answer? Products that compress all three beats into a single giant blob feel heavier than they need to.

This is why streaming matters, but only when the content shape supports it. If the answer is exploratory, token-by-token output feels alive. If the answer requires a complete synthesis, it may be better to stream structure first and detail second. The point is not “always stream.” The point is to control the cadence deliberately.

Infra article5 min readInfra violet

MCP Is Quietly Becoming Infrastructure, Not A Novelty

Tool use stops looking magical the moment it becomes operationally necessary. That is exactly why MCP-style systems are going to stick.

Article 4

What changes when tools become first-class

Once a model can reliably inspect systems, call services, and return structured results, the product stops being a chat box and starts looking like orchestration software. That is the shift I think many teams are underestimating.

MCP-style architectures matter because they formalize the boundary between language reasoning and real system capability. Instead of hiding all integrations inside custom glue code, they expose tools in a way that can be observed, permissioned, and expanded. That is what infrastructure usually looks like right before everyone realizes it is no longer optional.

Why implementation quality will matter more than demos

Most of the impressive early demos will not survive production unchanged. Permission models, tool discovery, retry behavior, audit logs, and human override all become decisive once real workflows are on the line. The hard part is not making the model call a tool once. The hard part is making the entire loop legible and safe over time.

The teams that win here are going to be the ones that treat tool use like backend architecture, not stage magic. Once they do, agents become much less mystical and much more commercially useful.

Design article6 min readWarm brass

Designing For Trust In AI Means Designing For Inspectability

Trust is not a branding layer you pour over a model. It is the result of making the system's behavior legible at the moments that matter.

Article 5

Trust is a systems output

A lot of AI products still try to feel trustworthy through tone alone. They smooth the copy, round the corners, and hope the user stops asking what just happened. That never lasts. The moment the system makes a consequential mistake, the interface either has an inspection path or it does not.

That is why I think inspectability is the real design primitive. Users should be able to understand where the answer came from, what tools were involved, what confidence signals exist, and what next action is safe. Not always, and not everywhere, but at the points where the stakes rise.

How this shows up in interface work

Inspectability can be subtle. It might look like retrieved sources that are actually relevant, execution summaries that are concise, or a task log that explains the system's route without drowning the user in tokens. The interface should reveal enough structure to support judgment, not so much that it becomes a debugging console by default.

The design challenge is calibrating disclosure. Show too little and the product feels fake. Show too much and the product feels exhausting. The sweet spot is a layered system where confidence and evidence appear exactly when the user needs to verify the machine, not before.