Indeed it was (I was listening to it while stumbling across this post). Also, fun fact: The Gambler was written by Don Schlitz while working as a Computer Operator in 76' which makes it all the more relevant [1].
Gemini on the web as a chat app is great (as well as NotebookLM). But Antigravity is an embarrassment and the reason I cancelled my Gemini subscription. I'd recommend avoiding it at all costs. It has degraded so badly in the last two weeks it's hardly usable anymore.
The difference here though is that ads are baked into the response via plain text.
How far away are we from an offline model based ad blocker? Imagine a model trained to detect if a response contains ads or not and blocked it on the fly. Im not sure how else you could block ads embedded into responses.
Nice work! I'm curious though, what was your use case for needing a smaller library? Since you're running this on a server, what difference does an extra 226KB make?
The article also lacks any personal opinion or experience on the matter. It just stated a bunch of pointless stats and "facts". Almost every single point is refutable depending on the task at hand.
Yep. My grandma bought her house in ~1962 for $20k working at a factory making $2/hr. Her mortgage was $100/m; about 1 weeks worth of pay. $2/hr then is the equivalent of ~$21/hr today.
If you were to buy that same house today, your mortgage would be about $5100/m-- about 6 weeks of pay.
And the reason is exactly what you're saying: the average US worker doesn't provide as much value anymore. Just as her factory job got optimized/automated, AI is going to do the same for many. Tech workers were expensive for a while and now they're not. The problem is that there seems to be less and less opportunity where one can bring value. The only true winners are the factory owners and AI providers in this scenario. The only chance anybody has right now is to cut the middleman out, start their own business, and pray it takes off.
>Each model gets access to market data, news APIs, company financials...
The article is very very vague on their methodology (unless I missed it somewhere else?). All I read was, "we gave AI access to market data and forced it to make trades". How often did these models run? Once a day? In a loop continuously? Did it have access to indicators (such as RSI)? Could it do arbitrary calculations with raw data? Etc...
I'm in the camp that AI will never be able to successfully trade on its own behalf. I know a couple of successful traders (and many unsuccessful!), and it took them years of learning and understanding before breaking even. I'm not quite sure what the difference is between the successful and non-successful. Some sort of subconscious knowledge from staring at charts all day? A level of intuition? Regardless, it's more than just market data and news.
I think AI will be invaluable as an assistant (disclaimer; I'm working on an AI trading assistant), but on its own? Never. Some things simply simply can't be solved with AI and I think this is one of them. I'm open to being wrong, but nothing has convinced me otherwise.
Every single SDK I've used was a nightmare once you get past the basics. I ended up just using an OpenRouter client library [1] and writing agents by hand without an abstraction layer. Is it a little more boilerplatey? Yea. Does it take more LoC to write? Yea. Is it worth it? 100%. Despite writing more code, the mental model is much easier (personally) to follow and understand.
As for the actual agent I just do the following:
- Get metadata from initial query
- Pass relevant metadata to agent
- Agent is a reasoning model with tools and output
- Agent runs in a loop (max of n times). It will reason which tool calls to use
- If there is a tool call, execute it and continue the loop
- Once the agent outputs content, the loop is effectively finished and you have your output
This is effectively a ReAct agent. Thanks to the reasoning being built in, you don't need an additional evaluator step.
Tools can be anything. It can be a subagent with subagents, a database query, etc.
Need to do an agent handoff? Just output the result of the agent into a different agent. You don't need an sdk to do a workflow.
I've tried some other SDKs/frameworks (Eino and langchaingo), and personally found it quicker to do it manually (as described above) than fight against the framework.
>I needed it to be a pretty fully functional IDE. I needed [IDE feature]...
I'm just curious, why didn't you make this as a VS Code plugin to benefit from all the features of an IDE? I'd imagine you could do something similar to the Live Server plugin. That way you could support any browser and not worry about maintaining the IDE features.
We actually do have a VSCode plugin we built a couple of months ago. It's a sort of a gnarly install if you run our dev-server from a docker container (which we do), so we shelved it. We dog food everything before putting it out. There's some cleanup we need to do before we publish it but it's coming.
> I'm just curious, why didn't you make this as a VS Code plugin to benefit from all the features of an IDE?
What I was trying to articulate is that I want is to write code in my dev-panel. I don't want to switch panes to an IDE for frontend tweaking. Of course there are times that I do want to switch to my IDE, which is why we developed the VSCode extension that is coming.
> I'd imagine you could do something similar to the Live Server plugin. That way you could support any browser and not worry about maintaining the IDE features.
This may turn out to be the right approach in the end. I've just explored the one avenue that you see today but I could be totally wrong and you might be right that the embedded browser in the IDE approach is the way to go.
Know when to Re-prompt,
Know when to Clear the Context,
And know when to RLHF.
You never trust the Output,
When you’re staring at the diff view,
There’ll (not) be time enough for Fixing,
When the Tokens are all spent.
reply