sauercrowd

Really surprised by all the comments here, they didnt hire him because of the amazing security openclawd had, but because he's one of the first one's who made a truly personal assistant that's actually valueable to people.

It's about what he created, not what he didnt create.

They're not acquiring the product he built, they're acquiring the product vision.

> ... most of which can be fixed by a rewrite in Rust

huh? That is clearly not the case. memory bugs - sure. Not having a public test suite, not accepting public contributions, weakly typed columns and lack of concurrency has nothing to do with the language. They're governance decisions, that's it.

>I see this situation trhough the prism of the innovator's dilemma: the incumbent is not willing to sacrifice a part of its market to evolve, so we need a new player to come and innovate.

I don't think the innovators dilemma quite applies in the open source world. Projects are tools, that's it. Preserving a project for the sake of preserving it isn't a good idea.

If people need to run a sqlite db in these exotic places, shedding it means someone else has to build their own tool now that can do it. Sqlite has decided that they care about that, so they support it, so they can't use rust. Seems sound.

Projects coming and going is a good thing in open source, not a bug.

This seems quite useful to me, especially for a larger org. If your dev's are working on LLM features, they'll need access to the OpenAI APIs. So are you just gonna give all of them a key? the same key?

No idea how this is solved at the moment, so seems like a smart step

You seem to read a lot into what I wrote, so let me phrase it differently.

These are ways I'd suggest to approach working with LLMs if you enjoy building software, and are trying to find out how it can fit into your workflow.

If this isnt you, these suggestions probably wont work.

> I don't get any enjoyment from "building something without understanding".

That's not what I said. It's about your primary goal. Are you trying to learn technology xyz, and found a project so you can apply it vs you want a solution to your problem, and nothing exists, so you're building it.

What's really important is that wether you understand in the end what the LLM has written or not is 100% your decision.

You can be fully hands off, or you can be involved in every step.

> and hate how much extra bullshit I didn't ask for they always add to the output.

I can recommend for that problem to make the "jumps" smaller, e.g. "Add a react component for the profile section, just put a placeholder for now" instead of "add a user profile".

With coding LLMs there's a bit of a hidden "zoom" functionality by doing that, which can help calibrating the speed/involvment/thinking you and the LLM does.

Three things I can suggest to try, having struggled with something similiar:

1. Look at it as a completely different discipline, dont consider it leverage for coding - it's it's own thing.

2. Try using it on something you just want to exist, not something you want to build or are interested in understanding.

3. Make the "jumps" smaller. Don't oneshot the project. Do the thinking yourself, and treat it as a junior programmer: "Let's now add react components for the profile section and mount them. Dont wire them up yet" instead of "Build the profile section". This also helps finding the right speed so that you can keep up with what's happening in the codebase

People are not full time maintainers of their infra though, that's very different to companies.

In many cases they want something that works, not something that requires a complex setup that needs to be well researched and understood.

Flip it around: a new user might be confused why the AI features that all their friends told them about are not available.

It's a tradeoff

Strong disagree. For most parts travelling is a non-event these days.

A train that splits, on the way to the airport where there will be a lot of non-german speaking people, and for some reason only shows it on the platform is insane.

Having a train that splits on that route is already bad enough, but you HAVE to emphasize it on the train.

I know that I need to pay attention to this, because I've grown up with DB pulling all sorts of fucked up shit, but we should not accept that this is reasonable.

I dont disagree on the workflow - struggling with the same. But CLIs have an absolute sweetspot abstraction.

A simple text interface, access to endless tools readily available with an (usually) intuitive syntax, man pages, ...

As a dev in front of it super easy to understand what it's trying to do, and as simple as it gets.

Never felt the same in Cursor, it's a lot of new abstractions that dont feel remotely as compounding

Seems like there's a few abstractions mixed up, the problems have nothing to do with SSE.

You can store the state in the SSE connection and have the problems described, and if you don't like those, you can move thr state to something distributed/persisted.

Pubsub is just a layer on top of SSE or websockets, cause guess how it'd end up sending things to the browser

Comments here complaining about the fact that it's vscode seem to miss the point here.

That's a huge advantage, it's means all the obvious stuff will just work. LSPs, debuggers, version control, customisation.

As much as I like Emacs, it's an insane pain to make all these things work.

If your value prop is agents on a codebase, there's no point in trying to reinvent those. They have basically been solved.

I think the reality is most of these are already dead, and a PE firm taking over is giving them one more chance

404d

This whole article feels like majorly overblown. I mean yes would be nice if the 2 mattress has an offline mode, but I'm sure everyone was fine for a day without it.

Probably simplifies their clients and backends I'd imagine?

What's "the Elm architecture"?

> retention project

Never heard this phrase before, but I can definitely see this happening at companies of that size

I've interned at Cloudflare back in 2020 and had a great time- would highly recommend!

Can't speak to the locations but the stuff you're interested/experienced in seems extremely likely to overlap with what they do. They do a lot of very deep technical things in all kinds of areas.

my recommendation if you want to talk to someone about it: search github/twitter/linkedin for ppl who work there on stuff you like, and just send them a message and ask for a 20 minute call!

have done it plenty of times, has always been extremely positive

> This problem strikes me more as a debuginfo generation bug than a "compiler" bug.

But isn't that the same thing here? The bug occurred in their production workflows, not in some specific debug builds, so with that seems pretty reasonable to call it a compiler bug?

100% agree. I really think it's time we move on from vibecoding, the tools have evolved and we should have a term that attaches more quality to the function

I really don't think we're doing the tools or the industry any favors/justice by prefixing new terms with `vibe`.

Looking at vibe coding: it suggests you're coding but you only vaguely know what's going on, so the work is the same (coding) but the outcome may or may not be what you want

Why dont we flip it around? We want a term that suggests that a fixed amount of work (coding) to be more efficient/leveraged.

So why dont we call it something like hypercoding, dense engineering, autocode, ...

The problem is they often can't, even if they have the skills to. Big companies are full of politics

I think one part that gets easily overlooked is that they not in-house, and that's a feature.

That means even when an in-house team has the same expertise, they have to adhere by in-house processes and hierarchy.

If a CEO signs off a consultant contract, they dont play in the same arena, and can often side-step the hurdles an internal team would face, without anyone internally getting too upset (compared to an internal team side-stepping processes).

Oh right the cloud version is what I remember - thanks for clarifying

Bit more stretched out than I thought it had been

My bad, I remember vaguely that fly io had a "litefs released" post but I seem to have confused timelines

The rails creator dhh has been hyping it up a lot in the first 6 month of this year, and quite a few followed of the "Dev influencers" scene. Fly's litestream came out around that time, and there's been more sqlite in the cloud companies/discussions, in particular with the AI agent use-case.

Not super sure who followed who but there was all of a sudden a lot of excitement

This.

Criticising a prototype that it doesn't do all the things of a finished product is... interesting

It's a good question, and I don't think answered sufficiently in the recent sqlite hype.

In my opinion if you have an easy way to run postgres,MySQL,... - just run that.

There's usually a lot of quirks in the details of DB usage (even when it doesn't immediately seem like it - got bitten by it a few times). Features not supported, different semantics, ...

IMO every project has an "experimental stuff" budget and if you go over it it's too broken to recover, and for most projects there's just not that much to win by spending them on a new database thing

>The U.S. shed 32,000 private-sector jobs in September, payroll-processing giant ADP said on Wednesday.

> That is down from a revised loss of 3,000 in August. Economists polled by The Wall Street Journal had expected an increase of 45,000.

Yikes