cheeseblubber

AI intelligence is also very jagged. Meaning it can be super human in a lot of things and bad at a ton of others. This is most represented in places where they can't get enough data. Starting business is a combination of a lot of skills chained together and breaking a single chain can cause the business to not work.

Secondly even they are constrained by resources. They have a limited amount of people/GPUs/capital. Given the constraints its best to focus your attention on the highest ROI given your team and organization.

Since I can't read the article I believe they are referencing to https://www.metaculus.com/tournament/metaculus-cup-summer-20...

It seems to be that they were trying beat a guy named Dylan Mathews. And seems like the community beat him in making predictions for 58 questions about the future

Related: https://news.ycombinator.com/item?id=49020999

Anecdotally the site we manage we are easily seeing 100x the traffic from bots than from humans in the past year. So much so that it is impacting our hosting costs.

My problem with the article is that they don't even mention this fact. The metaphors with Uber often is brought up but it breaks down at cost optimization. It also wouldn't be fair to say we are at the peak efficiency of LLMs and that there wouldn't be any improvements left.

It make sense if you account for cost of intelligence getting cheaper every year. Most of the models per unit of intelligence is getting far cheaper. We get better hardware, architecture, training techniques, inference optimizations and caching. All those improvements add up. In in early 2022 you were getting 10x cheaper annually now is closer to 2x - 5x cheaper annually. The cost is still dropping where as Uber can only get the cost down by so much.

The human brain also is a product of billions of years of evolution. We branched off from our common ancestor 7-9 million years ago. We encode quite a lot of structure and information that is essential for intelligence. The starting point of just our life time of training is incomplete.

If you calculate 100W * 7 million years * 365 = 255,500MW to train.

Yes definitely we were using our own budget and out of our own pocket and these model runs were getting expensive. Claude costed us around 200-300 dollars a 8 month run for example. We want to scale it and get more statistically significant results but wanted to share something in the interim.

Via api you can turn off websearch internally. We provided all the models with their own custom tools that only provided data up to the date of the backtest.

We used the LLMs API and provided custom tools like a stock ticker tool that only gave stock price information for that date of backtest for the model. We did this for news apis, technical indicator apis etc. It took quite a long time to make sure that there weren't any data leakage. The whole process took us about a month or two to build out.

You can click in to the chart and see the conversation as well as for each trade what was the reasoning it gave for it

OP here. We realized there are a ton of limitations with backtest and paper money but still wanted to do this experiment and share the results. By no means is this statistically significant on whether or not these models can beat the market in the long term. But wanted to give everyone a way to see how these models think about and interact with the financial markets.

There is a transcript of the entire conversation if you scroll down a little

Made a site that let's LLMs trade stocks and you can watch their performance https://www.aitradearena.com/

Would be cool to see the Quetzal website internationalized itself and see what it looks like in different languages.

! basically functions like @ in Slack and chat applications. The only difference in Linen is that we give you an @mention so that it doesn't necessarily need to send a push.

We actually tried shipping a desktop client with Tauri and Rust. It helped with initial bundle size but performance and resource consumption was kind of similar. We also ran in to issues with the api’s being bit limiting. Most likely we’ll revisit the desktop client with Tauri but depending on how mature the api is we may have to resort to electron.

Our bundle size has actually only gotten smaller since we’ve shipped our first version. We know it will gradually grow but we try to be disciplined in not using too many external dependencies

Thanks! Linen is secretly email in disguise. We have played around with syncing with email clients which would let you manage all your messages and notifications from one client.

We've actually done test on scaling. This is a fork of Linen.dev which had community of up to 50k members. So we've tested this well. Search is an on going feature we are working on. We're going to enhance it with more embedding like search functionality.

We use Elixir for websocket/real-time updates but crud stuff like settings, creating channels etc are mostly rest.

Definitely agree on developer community and third party integrations. That is our main focus after this launch. Building just a good quality chat tool took quite a bit of time but we understand how important the dev ecosystem is.

Thanks for checking the privacy policy will update to include AWS!

One of the pain point I've actually seen for Slack is Slack Connect becomes disorganized very quickly to the point where you need a custom solution to manage it. I think it is a symptom of the overall problem with Slack. Since Linen is thread first it makes manage these conversations much easier. We do plan on shipping our own version of Slack Connect or even integrating with existing channels.

Pricing wise we're still figuring out. I do think paying for active users is a likely direction though!

Yes we will! We've shipped a desktop client previously with Rust(Tauri) but their api's were a bit lacking. We'll be revisiting it very soon

One thing that we wanted to do was to create a design that was more modern and a bit more familiar to the average Slack/Discord user. I think zulip is great but can be a bit more overwhelming. We wanted to keep a familiar UX as much as possible while giving the benefits of a thread first experience.

Secondly we are a bit more opinionated in thread management. Our inbox is designed to get to an inbox zero state. We have things like !mention vs @mention which helps with urgent vs non urgent communication.

Some technical notes: This is actually a fork of Linen.dev, an SEO-friendly Slack alternative for communities. We originally built Linen.dev with Next.js but ultimately found it quite limiting when we wanted to make things fast and responsive and have custom caches. For Linen.team, there wasn’t a need for server rendering since we didn’t need our product to be SEO-friendly. We removed Next.js and replaced it with Vite and Express, which simplified our code quite a bit since we didn’t have the legacy requirements. We also spent quite a bit of time optimizing the performance and query so that it is much faster than the previous version of Linen. Our plan is to open source Linen.team as well; we need to do some repo clean-up first.

Finally, after a year, we actually reduced our client bundle size from 500kb to less than 400kb. You can see our post on bundle optimization here: https://news.ycombinator.com/item?id=35718417.

The problem is maintenance of a separate database and operationally it would be more work. For us who want to use embedding features having a separate database just for the embedding means now we have to keep data across multiple databases in sync and to maintain

Linen.dev founder here. Linen is a Google searchable community chat platform. Most of our communities use us to make Slack/Discord Google-searchable.

We've had users ask about making Matrix Google searchable. This is a beta version of the feature and lacks a lot of the features as our other integrations. We currently support two way real-time text sync between Matrix and Linen. In the roadmap we have historic sync, images, emojis and users sync.

Would love to hear some feedback and if this use case makes sense.

The person ultimately responsible for the success of your company is yourself and most likely you'll fail regardless of VCs.

I take issues with some of the second order effects:

1. "Because your goal is to sell the company later, it has to grow."

You don't have to hire just because you take VC money. You should hire at the right rate.

2. "You’ll be spending much of your time on finding the next investors".

If you manage your burn properly you wouldn't have to and you should aim to be default alive. http://www.paulgraham.com/aord.html

3. "You have to focus on large markets with many (or large) customers"

Yes you shouldn't take VC money if you don't want to go big eventually.

4. "Making existing customers happy is less important than acquiring many more new customers"

You have to do both and the goal should be to make existing customers so happy that tell others which will drive growth. If you don't make a product people love you won't win in the long run anyways.

Finally I think a common mistakes for Founders is making their VC's their boss. Although I agree with some of the sentiment of there is some perverse incentives with VCs as a founder you should take ownership of the decisions that impact your company.

We use typescript through out the app and we like having both the frontend and backend sharing types in the same repository.

Since this was written about 8 months ago. Our Elixir/Phoenix service has been incredibly stable and I can't think of a single time we had an issue with it.