spec VS devpod

There is also https://containers.dev which is the first thing I configured when my company gave us Cursor. All agentic LLMs to date need to be on a very short leash.

Pro tip: you can run `docker diff ` to see what files have changed in the container since it was created, which can help diagnose unexpected state created by the LLM or anything else.

Supporting the open Dev Containers Specification, the extension encourages a standardized approach to configuring development environments across different tools and platforms. This specification aims to foster consistency and portability in development setups, making it easier for teams to collaborate and for individuals to switch projects without the overhead of reconfiguring their development environment.

This doesn't support development containers (https://containers.dev), which means I can't insulate my machine from AI tooling. Not keen on this unless it's somehow earth-shattering.

This tutorial assumes familiarity with Docker, Docker Compose, Devcontainers and that your services have Dockerfile implemented

Leverage devcontainer to improve ci and local development

You can find the schema definition of the devcontainer.json file in the Visual Studio Code documentation or in this repository. In addition, this tutorial can also help.

-- What are Development Containers?

Devcontainers[1] are the new incarnation of this pattern. We use them at work and they are a dream for onboarding new developers. The only downside is the VSCode lock-in but if that's a concern there's always DevPod[2].

[1] https://containers.dev/

[2] https://devpod.sh/

## Quick Start [](https://devpod.sh/open#...) One click setup - no installation required!

GitHub: loft-sh/devpod

I come relatively late to the subject of Remote Development Environments (also known as Cloud Development Environments). The main reason is that I haven't worked in a development team for over six years. However, I'm now working for Loft Labs, and we have a RDE product: DevPod. I wanted to understand our value proposition as I'll be at FOSDEM operating the DevPod booth.

Devcontainers[1] are the new incarnation of this pattern. We use them at work and they are a dream for onboarding new developers. The only downside is the VSCode lock-in but if that's a concern there's always DevPod[2].

[1] https://containers.dev/

[2] https://devpod.sh/

In my experience, the case where this becomes really valuable is if your team needs access to either different kinds of hardware or really expensive hardware that changes relatively quickly (i.e. GPUs). At a previous small startup I setup https://devpod.sh/ (similar to gitpod) for our MLE/Data team. It was a big pro to leverage our existing k8s setup w/ little configuration needed to get these developer envs up and running as-needed, and we could piggyback off of our existing cost tracking tooling to measure usage.

The rest of our eng team just did dev on their laptops though. I do think there was a level of batteries-included-ness that came with the ephemeral dev envs which our less technical data scientists appreciated, but the rest of our developers did not. Just my 2c