HackerTrans
TopNewTrendsCommentsPastAskShowJobs

tristanz

no profile record

Submissions

A Peek into Tesla's Autonomous Future by VP Ashok Elluswamy at ICCV25 [video]

youtube.com
1 points·by tristanz·8 mesi fa·0 comments

ORPC 1.0 – Typesafe APIs made simple

orpc.unnoq.com
3 points·by tristanz·anno scorso·1 comments

The AI Revenue Wave

continual.ai
1 points·by tristanz·3 anni fa·0 comments

Drive Anywhere: End-to-End Autonomous Driving with Multimodal Foundation Models

drive-anywhere.github.io
1 points·by tristanz·3 anni fa·0 comments

comments

tristanz
·anno scorso·discuss
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.
tristanz
·anno scorso·discuss
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.
tristanz
·anno scorso·discuss
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.
tristanz
·anno scorso·discuss
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.
tristanz
·2 anni fa·discuss
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.