tristanz

Joined 13 years ago

Karma
580
Submissions
164
Member since
Jan 28
CEO and Cofounder @ Continual (https://continual.ai) – the fastest way to build AI assistants for applications. Formerly, CTO for Machine Learning at Cloudera and CEO/Cofounder of Sense (https://sense.io), acquired by Cloudera in 2016.

Email: [email protected] Twitter: https://twitter.com/tristanzajonc

View on Hacker News

Recent submissions

Comment · 1 year ago
Yes, I think you could get quite far with a few tools like memory/todo list + code interpreter + script save/load. You could probably get a lot farther though if you RLVRed this similar to how o3 uses web search so effectively during it's thinking process.
Comment · 1 year ago
You can combine MCPs within composable LLM generated code if you put in a little work. At Continual (https://continual.ai), we have many workflows that require bulk actions, e.g. iterating over all issues, files, customers, etc. We inject MCP tools into a sandboxed code interpreter and have the agent generate both direct MCP tool calls and composable scripts that leverage MCP tools depending on the task complexity. After a bunch of work it actually works quite well. We are also experimenting with continual learning via a Voyager like approach where the LLM can save tool scripts for future use, allowing lifelong learning for repeated workflows.
Comment · 1 year ago
Not considering the potential for AI consciousness and suffering seems very shortsighted. There are plausible reasons to believe that both could emerge from an RL processes coupled with small architectural and data regime changes. Today's models have inherent architectural limits around continual learning that make this unlikely, but that will change.
Comment · 1 year ago
Coming from TRPC, ORPC is a breath of fresh air. I tested out a migration from TRPC to ORPC and I found two things particularly beneficial.

The first is contract-first development which separates the contract from the implementation. This allows you to avoid codebase dependencies between your server and client. TRPC works fine when you only use your client from your server package, but if you need to export it elsewhere, e.g. a public SDK, you can easily end up with circular dependency issues and a bunch of pain.

The second is OpenAPI support. TRPC doesn't support OpenAPI generation and trpc-openapi is unmaintained. ORPC has first class OpenAPI support, which means you can use ORPC internally but expose a public OpenAPI API to customers and generate OpenAPI based clients if you want to.

I'm hoping this project gets traction since it is amazingly well done. I have zero affiliation or interest in ORPC to be clear, I just loved it from my quick tests.

Comment · 2 years ago
As an FYI, this is fine for rough usage, but it's not accurate. The OpenAI APIs inject various tokens you are unaware of into the input for things like function calling.
Comment · 3 years ago
ChatGTP maybe, but OpenAI hasn't even tried to train a model to replace search.

Until somebody tries to fine-tune a model using RLHF explicitly with the goal of replacing Google it's very hard to know what the resulting experience would look like. It could be shocking if ChatGTP is any guide.

Comment · 4 years ago
Comment · 4 years ago
To get 10x I think you need to wed it to solving broader workflow challenges, like dbt does today.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton