Aneesh Simha

New York as an operating system

2026-03-27T00:00:00Z

I keep catching myself describing New York in systems terms. The subway is a scheduler with a relaxed SLA. A dinner reservation is a mutex. A walk from the West Village to the Lower East Side is a request that fans out across half a dozen services — bodega, ATM, friend's stoop, second friend's text — and you're lucky if any of them respond on the first try.

It's not just a metaphor. It's the actual reason the city feels different from a smaller one. Most places are single-threaded. You do one thing, then the next thing. New York is preemptive: any plan can be interrupted by a better one, and the cost of switching contexts is built into the price of living here.

Latency vs. throughput

The thing nobody warns you about is the tradeoff. New York is a high-throughput city with terrible latency. You can get an enormous amount done in a week, but any individual errand will take three times longer than it should. The grocery store is twenty minutes away because the grocery store is always twenty minutes away, no matter where you live.

People who optimize for latency get bitter. People who optimize for throughput get tired. The ones who last figure out which queue they're actually in.

A city, like a system, is honest about exactly one thing: the bottleneck.

What it teaches

What I've learned, mostly, is to stop fighting the scheduler. If a thing is going to take an hour, it's going to take an hour. The right move is to batch — to put three errands in the same hour, to do the loud work in loud places and the quiet work at 6 a.m., to treat the subway as compute time and not as wasted time.

The city is not trying to make you efficient. It's trying to make you capable. Those are different metrics. They run on different schedulers. Most people learn the difference around year three.

I'm still learning.

Notes on deep tech VC

2026-04-08T00:00:00Z

The phrase "deep tech" is doing a lot of work right now. It used to mean hard science with a long road to revenue. Lately it means anything with a physics diagram in the pitch deck. The first definition is more useful, and the more interesting question is what's actually fundable inside it.

A few rough notes from the last six months of conversations.

The thesis everyone shares

Every fund I've talked to has some version of the same line: software margins on hardware businesses, AI as the connective tissue, and a regulatory tailwind in energy or defense. The line is correct and almost meaningless — it's a description of the entire frontier, not a thesis. The differentiation is in what each fund refuses to fund.

Where the two stacks meet

The interesting deals are the ones where the bits stack and the atoms stack are no longer separable. A robotics company whose moat is the data flywheel from a million deployed units. A materials company whose moat is a simulation pipeline nobody else has tuned. A biotech whose moat is, frankly, a really good internal eval harness.

The check size is for atoms. The defensibility is in the bits. Founders who can only speak one language get under-priced or over-priced; almost never correctly priced.

What I'd want to see more of

I'd want to see more founders who came up through operations — supply chain, fabrication, deployment — rather than research. The research is increasingly commoditized. The ability to ship a real machine on a real schedule is not. Capital is going to flow toward people who can run a factory floor and read a benchmark with equal calm.

Most of the rest is narrative. The market for atoms is finally pricing the bits, and it's going to keep being lumpy for a while.

Materials databases and the future of taste

2026-04-21T00:00:00Z

Taste looks like a personal trait and behaves like an infrastructure problem. The reason a certain shade of orange feels right in 2026 and wrong in 2019 isn't that the collective unconscious shifted overnight. It's that somebody, somewhere, added a swatch to a database, and three seasons later it's in every storefront on Lafayette.

I've been spending time inside materials databases — Pantone-adjacent libraries, Material ConneXion, the spectral archives that paint and textile companies guard like state secrets. They're the boring backstage of culture. A taste is just a query against one of these, run by a person with enough authority to commit the result to production.

The interesting layer

The interesting layer is not the database itself. Pigments and fibers and weaves have existed forever. The interesting layer is the index — the metadata that lets a designer in Milan find the same off-white a designer in Tokyo specified last year, and lets a buyer in New York reorder it without ever touching the physical sample.

When the index gets better, taste compresses. When the index gets worse, taste fragments. Both are happening at once right now.

A guess

My guess is that the next decade of taste is going to be shaped less by influencers and more by whoever owns the highest-resolution material indexes — and by the small number of people who can read those indexes like a sommelier reads a wine list. The models will help, but only at the edges. The core skill is still: hold a sample under the light, name what's wrong with it, write the name down.

That last part — writing the name down — is the part most people skip. It's also the part that builds the database that builds the taste.

The whole thing is recursive. That's why it works.

The personal RAG app as resume artifact

2026-05-02T00:00:00Z

A resume is a claim. A working app is a receipt. If you're trying to get hired to build with language models in 2026, the cheapest receipt you can produce is a personal RAG that does one specific thing well — and the most common mistake is to build one that does five things badly.

The personal corpus is the unfair advantage. Your notes, your bookmarks, your code, the long email thread where you actually thought something through — none of it is in the pretraining distribution, and none of it can be faked by a stranger trying to clone your project page. Index it, build a thin retrieval layer over it, wrap it in an interface that you would actually open on a Sunday, and you've already done more than most candidates.

The trap

The trap is building "a chatbot for your second brain." That framing is the kiss of death. Nobody, including you, wants to chat with their notes. People want answers, summaries, and the occasional reminder that they had a better idea about this six months ago.

So pick a verb. Find the three notes I wrote about X. Draft a reply in the voice of my last twenty replies. Surface the open loop I've been avoiding. The verb is the product.

What it proves

A small RAG app, built carefully, shows the reader: you can ingest messy data, you can write an eval that isn't "looks fine," you can reason about chunking and recall, you can ship a UI a human will tolerate, and you can keep latency and cost in your head while you do it.

It also shows something subtler — that you were willing to use your own work on yourself. In a market full of demos built for screenshots, an app you actually open is a strong signal.

Ship the smallest version. Use it for a month. Then talk about it.

Becoming an AI engineer without LARPing

2026-05-14T00:00:00Z

Most "AI engineer" portfolios prove nothing about engineering or AI. A README full of model names is not proof; a notebook that calls an SDK is not proof. The proof is in the system that does something useful on the machine of a person who doesn't care how it was built.

There's a costume version of this job and a real version. The costume is easy: a Twitter bio, a few benchmark plots, an opinion about the latest paper. The real version is closer to plumbing than to research. You write a thing, you watch it fail on inputs you didn't imagine, you fix the prompt, the schema, the retry, the cache, the eval. You ship. You watch the latency tail. You ship again.

What I actually look for

When I review someone's work I try to skip the talk and find one trace of taste. Did they bother to fix the obvious failure mode? Did they write a tiny eval, or did they ship vibes? Did the cost of the system go down between v1 and v3, or did they just keep adding tokens until the demo looked good?

Taste in AI engineering is the willingness to delete the cleverest part of your prompt because it didn't move the eval.

The other tell is whether the system has a job. Not a "use case" — a job. A real user, on a real Tuesday, getting something done that would otherwise take them forty minutes. If you can describe that user in one sentence and they aren't you, the project will teach you more than a year of papers.

A small contract

I try to hold myself to this: I don't get to call something AI engineering until somebody who isn't me has used it on purpose, twice. Until then it's a prototype, and prototypes are honest as long as you call them that.

Everything else is costume.