blainm · HackerTrans

5 tháng trướcdiscuss

I think the issue is people are using tools in an automated fashion and running up a compute bill for free when they were only meant to be used by humans in a more limited capacity (for companies to gather data on how to improve their products for humans). I think the correct way to use these models in an automated fashion is via the APIs and even then they might also worry about things like abuse/distillation type attacks still if the volume is too high. I think the lack of transparency might actually be by design so that people abusing their services don't figure out what triggers them losing their accounts. I could be wrong of course, this is just speculation on my part.

blainm

năm ngoáidiscuss

Living things that are good at predicting things don't die as much. There's a good reason why our auditory system is always on, even when we sleep. I suspect the reason for something like an 'earworm' is a system that's eager to predict sounds from the environment.

It's probably better to have a slightly overeager prediction system which sometimes gives false positives than one that isn't as active, because false negatives could lead to your death. That includes things like noticing that birds suddenly stopped singing. Maybe it's nothing, but you can see the use of a subconscious background process that has is eagerly making predictions that would then have an error, that could potentially save your life.

Thinking Fast and Slow has a wonderful example of the veteran firefighter who knew to order people out and then later realised that it was his ears feeling unusually warm (that was the clue to the hidden fire under the floor) that made the area unsafe.

If there are alien life forms out there, I would expect them to have evolved similar systems.

blainm

năm ngoáidiscuss

Issues like these reflects an evolutionary blind spot: selective pressure drops off after reproductive age, allowing defects like prostate dysfunction to persist. It's the same reason late-onset neurological diseases remain prevalent.

blainm

năm ngoáidiscuss

I strongly believe technical interviews should try to mirror a pair programming session on a problem as if it was work, rather than a quiz or interrogation type format.

If someone asked during such a session (where it's cameras, screenshare) that they wanted to do something like google some documentation, I wouldn't see that as a problem. Obviously it's a problem if someone just googles for a solution and pastes it in.

I see LLMs in the same way. No issue with them using it do something like take the pseudo code they wrote in front of me and turned it into an implementation. Especially if they could talk through this code and make suggestions about further changes and so on, clearly showing they understand what's going on.

The real concern is going to be when sophisticated agents can impersonate (clone voice and video) in a convincing way, as well as the capabilities to see the screen and type away as if it was a real person, and they're responding to you in real time.

If the software is based on the models made by large companies, they'll be happy to give you recipes. They would refuse if the coding request mentioned something about cracking passwords or dumping credit cards. And all of them will have a meltdown if you try to ask them to say something politically incorrect (what a bizarre world that would be if that became the new captcha system for humans trying to figure out if they're wasting their time with a fake human).

That said, this is going to be a cat and mouse game. There will be nothing to stop people from fine tuning models to get around being "jailbreaked" to reveal themselves as LLMs. Perhaps the best means is taking the time to research problems that causes "vibe coding" to completely fall down. And that is likely going to be things that are novel and haven't been littered all over the internet. That has a knock on effect of making such interviews a bit more interesting for the people doing them too.

blainm

năm ngoáidiscuss

So when it really struggled to get around (kept just walking into obstacles), they gave Claude the ability to navigate by adding pathfinding and awareness of its position and map ID. However, it still struggles, particularly in open-ended areas.

This suggests a fundamental issue beyond just navigation. While accessing more RAM data or using external tools using said data could improve consistency or get it further, that approach reduces the extent to which Claude is independently playing and reasoning.

A more effective solution would enhance its decision-making without relying on direct RAM access or any kind of fine tuning. I'm sure it's possible.

There has to be a better approach, and also in a way that's not relying on reading values from RAM or any kind of fine tuning.

blainm

năm ngoáidiscuss

I like the idea of blending a portfolio-style showcase with some kind of network on top. Consider how to maintain meaningful engagement without falling into the same pitfalls as existing social media.

Some ideas:

Avoid Engagement for Engagement’s Sake – Features like posting and analytics can create the same inauthentic cycles seen on other platforms, where users engage primarily to boost metrics and reach rather than build genuine connections.

Encourage Thoughtful Interaction – Consider placing limits on outreach, such as allowing only one new direct message per day. This ensures that when someone reaches out, it’s intentional and meaningful, not spam.

Resist Monetisation Pitfalls – Rather than introducing premium features like LinkedIn’s paywalls or sponsored content, a fair enterprise model such as paid job postings section could sustain the platform without diluting its core value.

Your approach is promising, and with the right focus, OpenSpot could offer a genuinely valuable alternative. Best of luck!

blainm

năm ngoáidiscuss

I've found tools like Cursor useful for prototyping and MVP development. However, as the codebase grows, they struggle. It's likely due to larger files or an increased number of them filling up the context window, leading to coherence issues. What once gave you a speed boost now starts to work against you. In such cases, manually selecting relevant files or snippets from them yields better results, but at that point it's not much different from using the web interface to something like Claude.

blainm

năm ngoáidiscuss

One of the key limitations of even state-of-the-art LLMs is that their coherence and usefulness tend to degrade as the context window grows. When tackling complex workflows, such as customer support automation or code review pipelines - breaking the process into smaller, well-defined tasks allows the model to operate with more relevant and focused context at each step, improving reliability.

Additionally, in self-hosted environments, using an agent-based approach can be more cost-effective. Simpler or less computationally intensive tasks can be offloaded to smaller models, which not only reduces costs but also improves response times.

That being said, this approach is most effective when dealing with structured workflows that can be logically decomposed. In more open-ended tasks, such as "build me an app," the results can be inconsistent unless the task is well-scoped or has extensive precedent (e.g., generating a simple Pong clone). In such cases, additional oversight and iterative refinement are often necessary.

comments