AI/ML consultant
Some of my clients are highly competent product and engineering organizations. They have a proven rhythm for building and shipping software. But when they start building AI or ML features for the first time, that rhythm necessarily gets disrupted.
As a CTO, once my engineering team grew large enough, I found it extremely difficult to spend any time writing code. And all the prevailing wisdom backed that up as a good thing:
One of the biggest process shifts for teams building AI-powered apps is baking in time to create a golden dataset before building the system.
There are plenty of tasks that the large LLMs we use every day are still terrible at. One category: simple puzzles that require generalizing from limited examples, interpreting symbolic meaning, and flexibly applying rules, like those in the ARC-AGI benchmarks. These problems are dead-simple for humans to solve.
I’m a little sheepish to admit this, but I’m kind of a self-improvement junkie.
The paper Verbalized Sampling: How to Mitigate Mode Collapse and Unlock LLM Diversity describes a surprisingly simple and effective way to get diversity out of an LLM, avoiding mode collapse. It’s a fun one!
I’ve been working with two clients recently who are building recommender systems. (Think: recommending fitness classes based on people’s goals. Not a real client example, but you get the idea.)
Everyone’s first instinct for making their product feel more modern and “AI-native” is adding a chat interface.
I’ve been digging into model provenance, or how we trace where large AI models (like LLMs) come from, who trained them, and what they’re built on.
A few months ago I was exploring Claude Code to get a feel for how it handled some of my projects. But I was also feeling a little limited…like I suspected there was so much more I could do, I just didn’t know what.