The user wanted to decide whether to add a development container file to their Go CLI project to support contributors using GitHub's web interface or AI coding agents. Initially hesitant, they agreed it would help these contributors and asked for it to be added. The assistant added a minimal setup and created a pull request for the change.
should we add a devcontainer file?
Let me take a quick look at the project to give you a useful answer.
I'd skip it. The project is a Go CLI tool with no services, databases, or complex runtime dependencies. Anyone contributing just needs Go installed and go build works. A devcontainer would add a file to maintain for a setup that's already one command.
If you start getting contributors who struggle with environment setup, it might be worth revisiting, but for a project like this it's overhead without much payoff.
but what about people contributing via the github website or ai agents?
Good point, that changes the calculus. Codespaces (and things like GitHub's edit-in-browser flow) rely on devcontainers, and AI coding agents like Devin or OpenHands use them too. Without one, those environments have to guess at the setup or fall back to defaults that may not have the right Go version.
The maintenance cost is basically zero for a Go project - it's a small JSON file pointing at a Go image. Worth doing.
Want me to add one?
yes
Done. Keeps it minimal - just the Go 1.25 devcontainer image and the Go VS Code extension. No Dockerfile, no post-create scripts, nothing to go stale. The image already includes git and common tools.
open a pr