In a project where I already have a lot of linting brought into the editor, I want to be able to reuse that linting in a headless mode: start something at the CLI, then hop into the IDE when it says it's done or needs help. I'd be able to see the conversation up to that point and the agent would be able to see my linting errors before I start using it in the IDE. For a large, existing codebase that will require a lot of guardrails for an agent to be successful, it's disheartening to imagine splitting customization efforts between separate CLI and IDE tools.

For me so far, cursor's still the state of the art. But it's hard to go all-in on it if I'll also have to go all-in on a CLI system in parallel. Do any of the tools that are coming out have the kind of dual-mode operation I'm interested in? There's so many it's hard to even evaluate them all.

Does anyone think this model of "tool" + "curated model aggregator" + "open source" would be useful for other, non-developer fields? For instance, would an AI art tool with sculpting and drawing benefit from being open source?

I've talked with VCs that love open source developer tools, but they seem to hate on the idea of "open creative tools" for designers, illustrators, filmmakers, and other creatives. They say these folks don't benefit from open source. I don't quite get it, because Blender and Krita have millions of users. (ComfyUI is already kind of in that space, it's just not very user-friendly.)

Why do investors seem to want non-developer things to be closed source? Are they right?

But as you point out there are great solutions so it’s clearly not a dead end path.

* Code is off of laptops and lives entirely on the dev server in many (but not all) cases. This has opened up a lot of use cases where devs can have multiple branches in flight at once.

* Big investments into bazel.

* Heavier investment into editor experiences. We find most developers are not as idiosyncratic in their editor choices as is commonly believed, and most want a pre-configured setup where jump-to-def and such all "just work".

* Local dev has laptop-based state that is hard to keep in sync for everyone. Broken laptops are _really hard_ to debug as opposed to cloud servers I can deploy dev management software to. I can safely say the oldest version of software that's in my cloud; the laptops skew across literally years of versions of dev tools despite a talented corpeng team managing them.

* Our cloud servers have a lot more horsepower than a laptop, which is important if a dev's current task involves multiple services.

* With a server, I can get detailed telemetry out of how devs work and what they actually wait on that help me understand what to work on next; I have to have pretty invasive spyware on laptops to do the same.

* Servers in our QA environment can interact with QA services in a way that is hard for a laptop to do. Some of these are "real services", others are incredibly important to dev itself, such as bazel caches.

There's other things; this is an abbreviated list.

If a linux VM works for you, keep working! But we have not been able to scale a thousands-of-devs experience on laptops.

I’m sure there are a bunch of things that make it the right choice for Stripe. Obviously if you just have too many things to run at a time and a dev laptop can’t handle it then it’s a dealbreaker. What’s the size of the cloud instances you have to run on?

I don't think there's confusion. I only have total access when the VM is provisioned, but I need to update the dev machine constantly.

Part of what makes a VM work well is that you can make changes and they're sticky. Folks will edit stuff in /etc, add dotfiles, add little cron jobs, build weird little SSH tunnels, whatever. You say "I can know versions", but with a VM, I can't! Devs will run update stuff locally.

As the person who "deploys" the VM, I'm left in a weird spot after you've made those changes. If I want to update everyone's VM, I blow away your changes (and potentially even the branches you're working on!). I can't update anything on it without destroying it.

In constrast, the dev servers update constantly. There's a dozen moving parts on them and most of them deploy several times a day without downtime. There's a maximum host lifetime and well-documented hooks for how to customize a server when it's created, so it's clear how devs need to work with them for their customizations and what the expectations are.

I guess its possible you could have a policy about when the dev VM is reset and get developers used to it? But I think that would be taking away a lot of the good parts of a VM when looking at the tradeoffs.

> What’s the size of the cloud instances you have to run on?

We have a range of options devs can choose, but I don't think any of them are smaller than a high-end laptop.

In terms of needing to reset, it’s just a matter of git branch, push, reset, merge. In your world that sync complexity happens all the time, in mine just on reset.

Just to be clear, I think it’s interesting to have a healthy discussion about this to see where the tradeoffs are. Feels like the sort of thing where people try to emulate you and buy themselves a bunch of complexity where other options are reasonable.

I have no doubt Stripe does what makes sense for Stripe. I’d also wager than on balance it’s not the best option for most other teams.

PS thanks for chiming in. I appreciate the extra insights and context.

They do, but I can see those changes if I'm helping debug, and more importantly, we can set up the most important parts of the dev processes as services that we can update. We can't ssh into a VM on your laptop to do that.

For example, if you start a service on a stripe machine, you're sending an RPC to a dev-runner program that allocates as many ports as are necessary, updates a local envoy to make it routable, sets up a systemd unit to keep it running, and so forth. If I need to update that component, I just deploy it like anything else. If someone configures their host until that dev runner breaks, it fails a healthcheck and that's obvious to me in a support role.

> Just to be clear, I think it’s interesting to have a healthy discussion about this to see where the tradeoffs are. Feels like the sort of thing where people try to emulate you and buy themselves a bunch of complexity where other options are reasonable.

100% Agree! I think we've got something pretty cool, but this stuff is coming from a well-resourced team; keeping the infra for it all running is larger than many startups. There's tradeoffs involved: cost, user support, flexibility on the dev side (i.e. it's harder to add something to our servers than to test out a new kind of database on your local VM) come immediately to mind, but there are others.

There are startups doing lighter-weight, legacy-free versions of what we're doing that are worth exploring for organizations of any size. But remote dev isn't the right call for every company!

I’d anticipate you would be equally as able to ssh to VMs on dev laptops. That’s definitely a prerequisite for making this work in the same way as you’re currently doing.

The only difference between what you do and what I’m suggesting is the location of the VM. That itself creates some tradeoffs but I would expect absolutely everything inside the machine to be the same.

Our laptops don't receive connections, but even if they could, folks go on leave and turn them off for 9 months at a time, or they don't get updated for whatever reason, or other nutty stuff.

It's surprisingly common with a few thousand of them out there that laptop management code that removes old versions of a tool is itself removed after months, but laptops still pop up with the old version as folks turn them back on after a very long time, and the old tool lingers. The services the tools interact with have long since stopped working with the old version, and the laptop behaves in unpredictable ways.

This doesn't just apply to hypothetical VMs, but various CLI tools that we deploy to laptops, and we still have trouble there. The VMs are just one example, but a guiding principle for us been that the less that's on the laptop, the more control we have, and thus the better we can support users with issues.

[0]: https://github.com/Mic92/nixos-shell (not to be confused with nix-shell)

As just one reason why, many developers need to set up complex test data. We have tools to help with that, but they take time to run and each team has their own needs, so some of them still have manual steps when creating a new dev server. These devs tend to re-use their servers until our company-wide max age. Others, to be fair, spin up a new machine for every branch, multiple times per day, and spinning up a new VM might not be burdensome for them.

Yes, but forcing people to rebase is disruptive. Master moves several times per minute for us, so we don't want people needing to upgrade as the speed of git. Some things you have to rebase for: the code you're working on. Other things are the dev environment around your code, and you don't want that to be part of the checkout as much as possible. And as per my earlier comment, setting up a fresh VM can be quite expensive in terms of developer time if test data needs to be configured.

I think this is where our contexts may differ, and so we end up with different tradeoffs and choices :) The services running on our dev servers are updated dozens of times per day, and they roughly correspond to the non-code parts of a VM.

So if this was a problem back then, when the company had less than 1000 employees, I can't even imagine how hard would it be to get local dev working now

Not saying it's the wrong choice for you, but it's a choice, not a natural conclusion.

They absolutely did! It was getting companies to agree to skipping straight to the onsite after a 15-minute recruiter call.

This lets you skip the back-and-forth of screen scheduling and result chats. In turn, that saves weeks of time during a job search, and allows you to have all of your onsites within a short time period, and then and offers come in within a much narrower window of time. You can make apples-to-apples comparisons about which role you might take that way, so it's a much lower cost for a much greater payoff to spend a few hours interviewing with a company you weren't thinking of to see if it's a fit.

In my mind, this was the absolute killer feature. I am still at a Triplebyte job 7 years later that impressed me via their onsite, and I would not have thought to apply if they had not been on TripleByte's skip-to-the-onsite list.

The unit of survival is not the individual or the species, but the gene. Genes maximize their survival by combining via sexual reproduction with other genes over time. Any one combination of genes will be out-competed over time.

The reason for honest aging signals is that a gene survives longer by getting out of the way of its offspring's combinations with other, newer genes. Sexual reproduction is the only way to get access to new phenotype features.

It's not service for the collective. Hanging around in one individual is the genetic version of vendor lock-in.

which are an expression of the concept of gene over the field of informatics, instead of the field of biology (unit cells vs unit bits)

All models are wrong but this one is mine, IANA biologist, yadda yadda.

- there are only so many resources to sustain individuals

- ergo there's a cap of the number of individuals

- ergo some individuals will die, if not from age, from attrition

- if age is not factored in, there are more old individuals, genetic competition between young individuals is reduced as they have to compete for resources with old individuals

- ergo age which kills old individuals irrespective of available resources allows more young individuals to exist in such a pool

- ergo ageing a) promotes competition between young individuals b) increases mixing of the gene pool

- ergo it promotes quicker turnaround on mutations

- ergo ageing is a significant asset in species adaptability to change

IOW vendor lock-in sucks in face of changing conditions as one is suddenly stuck with a suboptimal solution and competitors have a harder time emerging to challenge the status quo.

conversely the benefits of short term ageing are counterbalanced by social effects, where elders, even when not reproductive anymore but still otherwise in good health and thus autonomous as well as minimally consuming resources, are able to provide support for their chain of descendants, freeing energy for parents-to-be to reproduce, then parents to gather more resources that are then directed to support their younglings. The lack of reproductiveness of elders is advantageous to the species as it removes them from the direct gene mixing pool, instead promoting the younger ones.

IOW for its individual lives to be longer, a species goes increasingly social, channeling more support and thus energy towards their younger members, but ageing is still key otherwise the species ability to face quick change (at evolutionary scales) is severely hampered.

The deeper question for me is whether ageing is a specific primary process (a literal clock, which a technique such as the paper would attempt to skew backwards) that emerged from evolution or if it is a secondary effect from entropy corrupting other processes (e.g there's constant degradation + a ton of error correction but at some point degradation is too high and error correction cannot cope, triggering a catastrophic cascading effect leading to the sudden inability for an organism to sustain its own life, which the paper would delay by introducing younger cells, thus less errors, thus error correction can cope for longer)

This mindset goes back to the AT&T antitrust breakup. It was decided that phone companies would not be allowed to reject each other's traffic, because the larger ILEC's (incumbent local exchange carrier) would find reasons and excuses to cut off the CLEC's. This would be more or less a death penalty to those businesses, and the ILEC's had exactly zero reason to want the CLEC's to exist at all, so there was a lot of fear and rulemaking to prevent this.

Fast forward 30 years and the details have changed, but the mindset is largely the same. The fear is still quite real, and that's why phone spam isn't treated like email spam. If i.e. verizon cuts off incoming calls from a random CLEC in a midwestern state, that business is just over, done, that's that. It would be impossible to restore the business after your customers left, which they would do more or less instantly; there's no court remedy that would fix it. Great pains are taken to ensure that such an action is legitimate.

The rules are oriented around the idea that the ILEC's were evil antitrust actors, and the plucky CLEC's are the competition we need to protect from big ILEC's heavy hand. In a world of spam, that mindset is backward. And that mindset is changing, but because of the reasonable concerns, it's taking longer than we expect.

> since a small minority of human drivers cause the vast majority of incidents

It's tough to find anything relevant on DDG or google, they come up with information about racial disparities in traffic stops...can you link anything to read about this?

Curiously, from the article, copyright infringement is not alleged:

> As a final note, the complaint alleges a violation under the Digital Millennium Copyright Act for removal of copyright notices, attribution, and license terms, but conspicuously does not allege copyright infringement.

Perhaps the plaintiffs are trying to avoid exactly this prior law?