tristanz

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.

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.

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.

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.

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.

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.

https://www.zdnet.com/article/what-is-elon-musks-x-the-every...

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

Collaborative incremental improvement of models would be extremely disruptive. While this happens via research, it's massively inefficient, particularly as pretrained models get larger and span multiple modalities.

Continual | Frontend, Fullstack, and ML Engineer | SF, REMOTE | https://continual.ai.

Continual is building the missing AI layer for the modern data stack. We're hiring multiple roles (frontend, full stack, ML engineer) at all levels. This is an opportunity to get in early on a massive opportunity in one of the most interesting areas of technology – democratizing operational AI/ML.

Email tristan@continual.ai to learn more.

This is one of the most interesting and ambitious feature stores I've seen. It's also another example of Chinese companies really innovating on AI/ML infra.

Does anybody have any paid or open source solutions that they actually like? All the open sources solutions I've tried don't actually work for real world use cases with highly dynamic policies, users, groups, and objects (e.g. Google Docs). Often the issue is the inability to easily push down filters into the database or search index.

Aserto looks very promising (https://www.aserto.com/), but it still in private beta.

It's crazy this still is part of the stack where there are no great solutions.

Continual (https://continual.ai) | Senior ML Engineer | San Francisco or Remote (US)

We're building a continual AI/ML platform for the enterprise. We're hiring a Senior ML engineer to work on our core ML infrastructure. If you believe there should be higher-level, data-first abstractions for AI, please reach to me at tristan@continual.ai.

Job Details: https://angel.co/company/continual-ai/jobs/1232377-machine-l...

Agreed! Thank you Arrow community for such a great project. It's a long road but it opens up tremendous potential for efficient data systems that talk to one another. The future looks bright with so many vendors backing Arrow independently and Wes McKinney founding Ursa Labs and now Ursa Computing. https://ursalabs.org/blog/ursa-computing/

Apple always innovates on top of a user experience change. I doubt this time will be different. Tesla made the touchscreen dominant, but Apple won't copy it. Touch screens in cars leave a lot to be desired -- they aren't particularly ergonomic and they lead to screen fatigue. They also don't make much sense in a fully autonomous era.

Apple will likely build an AR-centric user experience using the windshield and new control paradigms. There's a huge area for creativity here and I don't doubt Apple can come up with something that will make a big touch screen seem archaic. If they can make the driver optional, there's even more room to think different.

Yeah, I really should not have put Splunk in this list because it shows perils of trying to make on-premise software run in cloud vs. SaaS-first mindset.

I have a hard time buying this hybrid architecture is the future. Running a bunch of stateful services with potentially large storage requirements in my own infrastructure is not zero-maintenance even if the control plain is managed. And proxying the UI for end users introduces back security and usability issues.

The best experience and lowest friction sale is to deliver a fully managed experience and earn the trust of customers. Confluent, Snowflake, Mongo Atlas, Rockset, CockroachDB, Elastic, Splunk, New Relic, etc all prove this is a great model for both customers and vendors. For the largest security conscious customers you can offer a fully VPC/on-prem solution with exactly the same form factor if you want. Hybrid can have its place, but I'd always try hard to offer a managed solution if you can justify it.

Sounds very similar to https://www.amundsen.io/, which came out of Lyft originally but is now used by Lyft, Square, Ing, Workday and a bunch of others

There's a lot of negativity here for understandable reasons given the success of SQL empirically. But I'd encourage everybody to read the home page https://edgedb.com/. This project is not trying to replace SQL as its primary goal, it's trying to build a data modeling and query interface on top of Postgres that meshes well with modern applications that have hierarchical data akin to what you'd model with GraphQL. Major kudos for trying to rethink and improve upon things -- I'm sure it wouldn't be too hard to stick an SQL backdoor in there for the laggards too ;).

A great collection of real-world case studies and various implementations can be found here: http://featurestore.org/

Somewhat counterintuitively to frequentists, this is not a problem if they did Bayesian analysis. Many new trails for COVID19 therapeutics are actually reporting realtime Bayesian estimates of efficacy.

https://www.pwc.com/us/en/industries/health-industries/libra...

This looks like a fantastically clean API for Python data and ML pipelines. Congratulations!

It would be great to have a scheduler and monitoring UI that are equally lightweight.

I'm referring to EKS here not ECS. EKS doesn't yet enable the PodSecurityPolicy admission controller, so any user that can launch a pod via EKS can root the EKS cluster regardless of RBAC rules. The main ask here is to just find a way to enable PodSecurityPolicy admission controller so that secure multi-user EKS clusters are possible like ECS.

As far as I understand, EKS doesn't support PodSecurityPolicy yet so any user that can launch a pod can trivially root the host via host mounts already. This surprisingly isn't clearly documented.

https://github.com/segmentio/create-next-app

Conversion is treated as a taxable event. If you claim the IP is worth $0 but sell it two days later for $10M, you're going to have problems.

What was the issue?

Unfortunately this isn't enough. Discriminatory rules such as "don't lend to any zip code that's over 75% black" will pass this test if you include this variable as a feature. The same logic applies to less obvious cases such as purchasing behavior.

I think philips is exactly right. The whole design of Kubernetes is geared toward allowing users write their own controllers for advanced use cases. You could view something like Jenkins or Vitess as controllers because they spawn Kubernetes pods on demand. The beauty is Kubernetes gives you great primitives, so you often will be controlling these objects, not the underlying pods. Of course many simple applications don't need a controller, although I suspect more and more simple use cases will be managed by an external controller like Helm which orchestrates the lifecycle of applications.

The questions is: Why isn't this just called a controller? What's this new term Operator?

The tensorflow team is working on a go wrapper as well:

https://github.com/tensorflow/tensorflow/issues/10#issuecomm...