Not all banks have physical locations, not everyone has the ability to get to the ones which do.
You can't walk back from the existing expectation and ease of use we have today. It's just not going to happen, people will opt for the current path because it's easy and seems good enough to them.
Most normal people don't even know this whole thing is going on. They don't know the difference between http and https other than "it's secure".
If we want to improve on this, it has to come with the current level of ease of use at a minimum.
> If we want to improve on this, it has to come with the current level of ease of use at a minimum.
We need to recognise that is impossible. Making getting into a bank account easier for the owner does so for everyone else too. And also makes it easier for the bank to ditch the secure fallback - a building.
And ask why vendor-indepedent trust shops aren't sprouting in every locale. Answer: same security problems.
We are well and truly doomed to living in a scammers' paradise.
And also, how is my bank supposed to safely generate and distribute a key that we can exchange securely if an organisations who's primary purpose to generate these keys couldn't even manage to do so.
I have plenty of other services I use too. Suddenly my phone company, doctors, supermarket has to create and distribute keys for me to go around collecting so that I can securely talk to them and we have to do this in a way that stops anyone from swapping those keys out before they get to me.
I mean the current system isn't perfect, but it's a Utopia compared to that.
This works great for something that are obvious. "Hey, this plumber was good and cheap".
The problem is this completely and totally breaks down where things are obscure. When things turn from "reals" to "feels" the amount of manipulation a bad actor can perform is great.
Agreed, but what would you propose we do about it? The current pki just washes its hands of the situation and restricts itself to only validating server names. Which probably made sense back when the people running the servers were also the authors of the content those servers served, but now it's a false sense of security.
I'm trying to do more than that. If we validate claims made by the content as anchored in the user's trust graph, we don't have to care which server it came from--it's trusted for different reasons. Are you saying we shouldn't try just because it's hard?
It's not that we shouldn't try, it's that it gets depressing really quick because most of these efforts will fail for reasons of human behaviors.
Trust doesn't scale, and the internet is something that operates at scale.
All of the systems you're talking about have already existed and been tossed by the wayside. People could always have exchanged things like GPG keys, and yet here we are in a world in which we don't.
The vast majority of your users do not want to manage trust. They want it to be taken care of. Almost no one gives two shits about a trust graph, except maybe nerds like you or me. Exposing the average person to these concepts doesn't increase trust. It just makes the world more confusing for them.
This starts to delve into the monkeysphere and how many 'close' relationships people can form. If we have just a few things we trust it might work. Once you get over 15 or so it starts breaking down, and at 100 it's out of the question. Again, trust works on our evolutionary monkey brain that is used to a small tribe and systems requiring personal trust do not scale past that.
Trust graphs are worthless when they are built on a house of security lies. It's easy to get kicked out of them, but nearly impossible to secure your systems to the point you can keep attackers from stealing them and pretending to be you.
There are a lot of people out there who really just don't like programmers, and would like to see them have less influence.
I don't mean that in the sense of "the world is against us". But the Googler walkouts from yesterday years were pretty embarrassing for a lot of executives and MBAs.
The culture has also never been kind to people in adjacent professions. I've met many designers and PMs who feel programmers are difficult to work with and walk over everyone else.
I think there are a lot of people out there who got one reason or another are excited that programming is now more accessible without the programmers.
There's the more positive angles as well, such as small businesses who've struggled to afford bespoke software. Now it's available to them cheaply, or at least cheaper than before.
This stuff isn't just a tool to make a carpenters life easier like a bench saw. It's available to everyone who's wanted a new wardrobe without the time and cost of something bespoke or hand made. AI is IKEA flat pack furniture. Cheap, easy, and surprisingly good.
After seeing one of these a few years back I started moving everything. I decided to look for a local provider (UK) in the end and landed with https://www.mythic-beasts.com/ and couldn't be happier. The one issue I've ever had was answered by a human within the hour.
I'm done cheaping out on critical stuff now, especially the domain registrar.
I understand you made BetterWhispr and Handy would be a competitor, but if you're going to dunk on them it would be good to add some real detail and reasoning. It's okay if you just didn't get on with it, but this is HN where we want to hear about design decisions, trade-offs, and the motivation for building this over using one of the many alternatives.
I've not used either and I'm sure they're both great, but just saying an alternative is bad isn't particularly useful to anyone here.
i used handy a year ago, i think it was my first voice dictation app trial.
the reason it is bad, it's a 150-200mb binary i remembered downloading, it was not accurate for my accent, was missing lot of words, i tried wisprflow and it was accurate, the dx was top notch and i was a annual plan subscriber, but i think they are cost cutting on inference and all of the features which i mentioned got severely degraded.
this was the main motivation to build betterwispr, again this is my personal opinion, i was just thinking out loud. really sorry that people get offended in general.
Well... I've always believed that a good go to market should be extremely multi channel with paid being gravy anyway. I think DigitalOcean was successful because we did a combination of: Actually useful content marketing + being where your customer actually is (so attend&host event/conferences etc) + genuine community outreach and interest in what your customer base is all about (I spent time every day during DO on HN making sure if anyone had a problem it was solved) + for devtools (at least back in my day) I think supporting OSS meaningfully was also incredibly important. To a degree in DevTools, DevRel can basically be the same as paid influencers, I had Mikeal Rogers (rest in peace) working for me and his mission was "Do whatever you want as long as it's net positive to the nodejs community, have fun!" so I guess "paying influencers" can mean few diff things. With youtube a lot of people use sponsor blockers now too so paying someone to shill your shit in the middle of their video is probably not as effective as it once was, tho I doubt the sponsor blocks are as widespread as ad blockers.
If you're just getting started I think the best thing you can do by a mile is just attend conferences/events where your ICP is and try to bootstrap PLG with it.
This question is asked often, and the answer is always that it depends on who your audience is. Channels that work for one person might fail for you, and vice versa. Every product solves a different problem, which means different people who seek out information from different places.
Step 1 is to understand who those people are for your product, and figure out which information sources they trust. As implied above, almost nobody trusts online ads.
Mostly, yes! They use a very specific clay from a producer which went out of business a few years ago. They've bought up all the stock they can and use that clay for pretty much all of the character puppets, along with other materials. There was a great documentary on the BBC a couple of years back which went behind the scenes and talked about how they make and use the puppets.
This seems a lot like Cloudflare OS (https://blog.cloudflare.com/cloudflare-os/). Is that a fair comparison? If so I'd be keen to understand how this differs aside from not being baked into the Cloudflare estate.
Fair comparisons. Paperclip does the org chart and the orchestration but it depends on other runtimes to actually run the agents. OtoDock also runs on Claude Code and Codex, the difference is the agents run inside it, as persistent processes in a sandbox on your server. Or also you can pair one of your machines with one command and you make any agent run on it with its tools and files synced to the platform, with automatic fall back to the server when the machine is offline. Cloudflare OS I only know from their post, so I cannot compare it properly yet.
Of course! I don't see how anyone could expect to excel at a craft without also studying the work of others.
This is where AI concerns me for people who are juniors in their field (software or otherwise). You get quick answers which don't help with learning, and it's very easy to never read the code. It's like a very tempting drug that stunts growth but feels like progress.
I'm a hands on engineering leader for a team of about 20 engineers and I've been spending the past 6 months trying to get my team to understand just this.
On Friday we had a coffee hour to share how we've been working recently and they all seemed perplexed at the workflows I've been adopting. It seems natural to me as someone who's been a manager for some time now, but very alien to all those who've never gone down that path.
That's not to say my workflows are superior, but they're extremely different to some of my teams now. In reality it's just leaning heavily on things like prds, limiting communication between agents, etc.
Out of curiosity, what was the path that the engineers have been taking? The limiting communication between agents to my mind is obvious to anyone who hasn't swallowed orthodoxy Agile development completely whole. And in my experience the people who have, are rarely the devs. Context switching, between agents, people or whoever, require ramp up time to relearn context. It's always slower and more expensive, other potential upsides about long term training or developers being more replaceable notwithstanding. But no agent gets long term training, not in a 1M context window.
And our in house "Agile Practitioners" (their job title) pushed this to a state where the next four tickets in a task get broken down to four hour long pieces of work go to four different people, regardless of their context or skill set rather than what two years ago was what one person just owned and did in a day. Work in progress is minimized by the metrics, but it doubled the overall man hours. And the Ops Director gets promoted on that WIP metric while half the team quit citing the changes due to the added communication burden and lack of ownership.
I'm thinking some people are approaching agentic development in the same manner, splitting work up across agents too aggressively, giving each agent new context/upfront plans, when the one session could have done the whole problem in the one context window.
Right, the ultimate context switch is constant pinging and meetings. There’s very little reason to have engineers be in 5+ meetings a day. But at a lot of orgs, they are, and that’s an extreme context switch cost 5x a day. It’s different if it’s a purely technical meeting about the problem you’re solving right now, but they’re typically not.
In the few instances that I’ve been able to see a total stranger prompt a model, I learn a lot about them.
The model output is fairly uniform because the models are fairly uniform, but the input is how I understand the prompter’s theory of mind for the LLM.
The higher fidelity the theory of mind, the more productive the resulting conversation is. Basic things, like knowing what the model is even aware of.
It’s okay at subjective product judgements with limited context, and so the best engineers make the most important decisions themselves, constraining the model’s solution space to something looking like success.
Maintaining consistent progress towards a common goal with a bunch of different perspectives is the job.
I've been using elixir professionally and for hobby work for the past 7 years now. Language models are damn good at it, and have been for some time.
The language isn't huge, the documentation has always been very good, and the patterns extremely consistently across the community. I almost wonder whether it's smaller community has been a benefit, as LLMs have been trained on a tighter set of code samples.
You can't walk back from the existing expectation and ease of use we have today. It's just not going to happen, people will opt for the current path because it's easy and seems good enough to them.
Most normal people don't even know this whole thing is going on. They don't know the difference between http and https other than "it's secure".
If we want to improve on this, it has to come with the current level of ease of use at a minimum.