Notes from the intersection of AI, developer tools, and practice

Exploring what's new — and what actually matters.

Developer relations & product at NVIDIA. Writing about things I'm figuring out. No fixed schedule, no polish.


Recent

All writing →
Writing
What LLM agents actually need to be useful (and what's still missing)

Agents are the most overhyped and underdelivered area in AI right now. Three gaps that frameworks mostly ignore.

Jun 15, 2026  ·  4 min read
Link
CUDA 12.9 — what's new for ML workloads

Improved memory pooling for multi-model inference and new per-kernel profiling hooks that don't require Nsight.

Jun 20, 2026  ·  NVIDIA Developer Blog
Writing
The developer experience tax nobody talks about

Every friction point costs you developers — not in a measurable way. Just quietly, one at a time.

May 20, 2026  ·  3 min read
Project
LLM response consistency checker

Runs a query N times, embeds responses, flags pairs where cosine similarity drops below a threshold.

May 10, 2026  ·  Python  ·  GitHub
Link
Why your RAG pipeline probably has a chunking problem

The problem is almost never about embedding quality — it's semantic units being split mid-thought.

May 15, 2026  ·  Towards Data Science
Link
The case for boring infrastructure

You want infrastructure you understand at 3am when it breaks. A useful check on any architecture decision.

May 1, 2026  ·  Charity Majors

Writing

Opinionated takes on AI, developer tools, and building things people actually use.

What LLM agents actually need to be useful (and what's still missing)

Jun 15, 2026 4 min read

Agents are the most overhyped and underdelivered area in AI right now. Three gaps that frameworks mostly ignore — and what actually needs to change before agents are useful in production.

LLMsagentsdeveloper-tools

The developer experience tax nobody talks about

May 20, 2026 3 min read

Every friction point costs you developers — not in a measurable, dashboard-visible way. Just quietly, one at a time, as they close the tab and go back to whatever they were using before.

developer-relationsDevExproduct
← Writing

What LLM agents actually need to be useful (and what's still missing)

Every few weeks, a new agent framework ships. Every few months, someone declares that agents are finally here. And yet most of the agent demos I see are still impressive in a controlled environment and frustrating in production.

I've been thinking about why, and I think it comes down to three gaps that frameworks mostly ignore.

Gap 1: Reliable task decomposition

The hardest part of agentic behavior isn't tool use — it's deciding when to break a task into subtasks and how. Current models are inconsistent at this. They'll nail it on easy examples, fail silently on edge cases, and hallucinate a plan that looks reasonable until step three when something breaks.

What's missing is better scaffolding for planning that's legible to the developer — so you can inspect, override, and debug the plan before it executes. Most frameworks treat planning as a black box. That's fine for demos, bad for anything in production.

Gap 2: Memory that actually persists meaningfully

Everyone has added some form of memory to their agent stack. Vector stores, conversation history, summaries. But memory without schema is just noise retrieval. What I haven't seen yet is a clean, developer-friendly way to define what should be remembered, in what form, and when it expires. That's a product problem, not just a research problem.

Gap 3: Error recovery that degrades gracefully

Right now, most agent systems either succeed or fail completely. What I want is agents that can say "I got to step four and hit an ambiguity — here are two interpretations, which one did you mean?" without needing to restart the whole task. Partial progress + human-in-the-loop checkpoints is the pattern, but building it well is still harder than it should be.

None of this is unsolvable. But I think the frameworks and the research community are optimizing for benchmark performance rather than production resilience. The next generation of useful agents will be built by people who've been burned by the current generation's failure modes.

LLMsagentsdeveloper-tools
← Writing
← Writing

The developer experience tax nobody talks about

There's a metric nobody tracks but everyone pays: the number of developers who bounced off your product at 11pm on a Tuesday because something didn't work and the docs didn't explain why.

I call it the developer experience tax. Every friction point — a confusing error message, an underdocumented parameter, an example that doesn't match the actual API — costs you developers. Not in a measurable, dashboard-visible way. Just quietly, one at a time, as they close the tab and go back to whatever they were using before.

The ones who debug are your best developers. The ones who bail are everyone else.

What actually helps

The most impactful fix is almost never better documentation. It's making the error message tell you what to do next. "Invalid API key" is nearly useless. "Invalid API key — make sure you're using a Project API key, not a User API key. See: [link]" saves five minutes of confused developer and probably the whole relationship.

The second most impactful fix is realistic examples. Not toy examples. Not "hello world" with a fake dataset. Examples that look like what the developer is actually trying to do. If your SDK is for production use, show production patterns.

The third is response time on the hard question — the one where someone has done everything right and it still doesn't work. How fast does your community or support surface an answer? That's the real measure of developer experience.

This is developer relations work, but it's also product work. The boundary is blurry on purpose — both functions are responsible for whether a developer feels capable or confused when using your product.

developer-relationsDevExproduct
← Writing

Projects

Things I've built or experimented with — what I tried, what I found, what surprised me.

May 10, 2026

I kept running into the same problem: asking an LLM the same question twice and getting subtly different answers that were both technically "correct" but contradicted each other. Built a small script that runs a query N times, embeds the responses, and flags pairs where cosine similarity drops below a threshold. Not a solution to inconsistency — just a way to measure it before putting anything in production.

PythonLLMstesting
March 5, 2026

Quick utility to estimate peak GPU memory usage for a given model + batch size + precision combination before actually loading the model. Saves time figuring out whether a workload fits on a single A100 or needs multi-GPU. Archived now because better tools exist — keeping it up since a few people found it useful.

PythonCUDAGPUutilities

About

I work on Physical AI and Agentic Intelligence at NVIDIA — product and developer relations for the messy, interesting problem of getting AI to take dependable action in the real world. That means simulation, multi-agent systems, and platforms like Omniverse. It's where most of my curiosity lives right now: the point where a model stops just generating text and starts moving things.

I didn't start here. I started on plant floors — commissioning automation systems, then building the MES and industrial IoT software that ran them, most of it over a long stretch at Rockwell Automation. From there the work climbed the stack: analytics, digital twins, and then generative and agentic AI at AWS. Twenty years of watching the same industrial problems get attacked with progressively better tools. That arc is why I care less about what a model can demo and more about whether it holds up on a factory floor at 2am.

So I tend to sit at the intersection of what's technically possible and how developers actually experience it — I see the gap between what's announced and what ships, between what's impressive in a keynote and what survives contact with real systems.

This site is where I think in public. Not a portfolio. Not a newsletter. Just a place where I write down things I'm figuring out — about AI, about developer tools, about building products that practitioners actually want to use — and share what I find worth reading.

If something here is useful to you, that's the whole point.

Currently NVIDIA. Previously AWS and Rockwell Automation. Based in San Jose, California.