wowamit

Is finding the right stocks to invest in an LLM problem? Language models aren't the right fit, I would presume. It would also be insightful to compare this with traditional ML models.

Regardless of which model you're using, you may notice that Claude frequently ignores your CLAUDE.md file's contents.

This is a news for me. And at the same time it isn’t. Without the knowledge of how the models actually work, most of the prompting is guesstimate at best. You have no control over models via prompts.

It's really frustrating to see every innovation eventually crammed into advertisements. The brightest minds spend most of their energy figuring out effective ways of serving ads.

You are right. I dug through the document some more. The setup, as mentioned for protected branches [1], should ideally work without much overhead. It does suggest merging back to main, but the FAQ also mentions that the frequency can be decided individually.

[1] https://github.com/steveyegge/beads/blob/main/docs/PROTECTED...

I was always afraid to switch from Gmail, knowing the impact it would have. But I switched to Fastmail this year and my experience has been comparatively frictionless. My fear was unfounded.

With so many settings spread across multiple sections, especially in Workspace accounts, it's challenging to keep track of how existing settings are affected by each new addition. I generally review these regularly, yet find surprises now and then.

Knowing what setting does what in Gmail is becoming difficult by the day.

The way I understand this, when the agent runs `bd onboard` at startup, it gets the instructions from beads, which might refer to data files in the beads directory. Keeping them in sync via a separate branch would be an unnecessary overhead. Right?

The way I read it is beads steers agents to make use of the .beads/ folder to stay in sync across machines. So, my understanding is a dedicated branch for beads data will break the system.

Thanks! It is the structure that matters here, then. Just like you, I ask my agents to keep updating a markdown file locally and use it as a reference during working sessions. This mechanism has worked well for me.

I even occasionally ask agents to move some learnings back to my Claude.md or Agents.md file.

I'm curious whether complicating this behaviour with a database integration would further abstract the work in progress. Are we heading down a slippery slope?

I went through the whole readme first and kept wondering what problem the system aims to address. I understood that it is a distributed issue tracker. But how can that lead to a memory upgrade? It also hints at replacing markdown for plans.

So is the issue the format or lack of structure which a local database can bring in?

Yeah, true. Implementing this would be tricky.

A much-needed project. Making yourself invisible to such privacy-invasive devices will be the need of the day. Of the two approaches you mentioned, blocking/jamming the specific wireless traffic would be pretty interesting, if possible.

You can't. I am curious if this adds another layer of latency.

Same here. At first, I thought it was a one-file-based database, which would have been even more commendable.

I am curious to better understand the benchmarks against simple SQLite, especially under typical load. Any level of latency will be an unnecessary overhead.

PocketBase is an open source backend consisting of embedded database (SQLite) with realtime subscriptions

I am not sure I understand—is this a wrapper around SQLite?

I would be hesitant to generalise that. There is an inherent tension with its impact on the larger availability of your system. We can't analyse the effect in isolation.

Agreed. Setting up structures for people to provide regular feedback is a must -- I believe this goes without saying. The only downside is that this cannot be done 1:1 with each person. Hence, enabling even the motivated few is a good trade-off. But sure, necessary but not sufficient.

At the same time, accepting and acting on feedback is a skill in its own right.

Eventual consistency arises from necessity -- a need to prioritise AP more. Not every application needs strong consistency as a primary constraint. Why would you optimise for that, at the cost of availability, when eventual consistency is an acceptable default?

Their struggles are not your struggles anymore.

Though I agree with the larger point, there is a critical way to overcome that. The second line of leadership must own the culture at their team's level. This only works if you have direct access to the larger group. An open-door policy where anyone can schedule time with you is essential.

You might not understand their struggle, but you can hear and route it to the right people. Sometimes the best way to show empathy is simply to listen.

That's impressive. Well, I was using the default Gemini 3 Pro. Based on my experience, I am surprised you did not hit the quota limit.

Interesting. I did not face many issues while communicating with Gemini. But I believe these issues will iron themselves out -- Google does feel to have rushed the launch.

I haven't tried complex coding tasks using Gemini 3.0 Pro Preview yet. I reckon it won't be materially different.

In my limited testing, I found that Gemini 3 Pro struggles with even simple coding tasks. Sure, I haven't tested complex scenarios yet and have only done so via Antigravity. But it is very difficult to do that with the limited quota it provides. Impressions here - https://dev.amitgawande.com/2025/antigravity-problem

I am worried that we are diverging with CLI updates across models. I wish we had converged towards a common functionality and behaviour. Instead, we need to build knowledge of model-specific nuances. The cost of choosing a model is high.

I’ve had shop staff tell me about some discount if you download their app, and when I decline, say something like “It’s really easy! Here, just give me your phone and I’ll do it for you.”

This behaviour is pretty prevalent worldwide, I believe. Especially the phone plan setup use case happened to me in Bangkok, too. This happens to me in India at gas stations, cafes and even local supermarkets. All want me to install their apps, and the first step is to log in with my mobile number.

With auto-detection of mobile numbers/Google Accounts on Android, it's even easier to create an account in one click.

The work of writers, journalists and intellectuals will not become superfluous simply because much of the web is no longer written by humans.

Instead, the more the words on the internet are written by AI, the less the worth of those words will be. AI self-training itself into oblivion is a problem worth researching.

AI is not one solution to all the problems in the world. But neither is it worthless. There's a proper balance to be had in knowing how useful AI is to an individual.

Sure, it can be overdone. But at the same time, it shouldn't be undersold.

Nice. This is needed at every place where user-generated content is commented and voted on. Any forum that offers the option to report something as abuse or spam should add "AI slop" as an additional option.

Nice. This is needed at every place where user-generated content gets commented and voted on. Any forum that offers the option to report something as abuse or spam should add "AI slop" as an additional option.

When LLMs write and maintain code, does the programming language they use even matter? Anyway, the inputs to LLMs are all in natural language, and what we get is what we wanted built.

Is it better to specify the parameters and metrics —aka non-functional requirements —that matter for the application, and let LLMs decide? For that matter, why even provide that? Aren't the non-functional requirements generally understood?

It is the specifics that would change—scale to 100K monthly users, keep infrastructure costs below $800K, or integrate with existing Stripe APIs.