VS Code production readiness checklist

A "VS Code paved path" is production-ready when a new hire can clone a repo, open it in VS Code, and be productive within an hour — and when a long-tenured engineer does not lose a day to configuration drift every quarter. This checklist is the threshold.

Ownership is split: the platform team owns the shared components (Extension Pack, devcontainer bases, agent configs); each data-product team owns its repo's adherence to the standards.

1. Extension Pack

• [ ] A paved-path Extension Pack is published to the Visual Studio Marketplace or the org's internal mirror.
• [ ] The pack has a semver version and a change log.
• [ ] The pack's extensionPack field enumerates every approved extension ID.
• [ ] The pack is pinned in .vscode/extensions.json of every data-product repo.
• [ ] Auto-update is off at the user level; extension version changes land via Pack version bumps.
• [ ] Quarterly review of the pack removes stale entries and adds vetted new ones.

2. Devcontainer bases

• [ ] A family of blessed devcontainer base images published by the platform (at minimum: generic Python/dbt, and PySpark with the right JDK).
• [ ] Each base has an automated rebuild cadence (nightly or weekly) to pick up security patches.
• [ ] Each base is scanned for CVEs before publish; criticals block the release.
• [ ] Every data-product repo's .devcontainer/devcontainer.json inherits from a platform base and layers minimally.
• [ ] Features are version-pinned in every repo's devcontainer.
• [ ] Python version, JDK version, and CLI versions in the devcontainer match production.

3. DevPod provider

• [ ] A DevPod provider config is published by platform for remote devcontainers.
• [ ] The provider uses the company's approved VPC, AMIs, and IAM roles.
• [ ] Auto-stop is configured (idle timeout ≤ 1 hour).
• [ ] Cost attribution flows to the right team (tags on the EC2 instance or K8s namespace).
• [ ] A runbook documents how to connect, size, and destroy a devpod.

4. AI agent baseline

• [ ] At least one approved AI agent has an org license (Copilot, Claude Code, or Cursor are the common picks).
• [ ] The license scope is understood: which data can and cannot be sent to the model provider.
• [ ] The paved-path agent config (CLAUDE.md, cursor/rules, .github/copilot-instructions.md) ships in every repo.
• [ ] Skills are published and versioned in a shared location.
• [ ] A documented process exists for contributing new skills.

5. MCP servers

• [ ] The approved MCP servers are documented, with version pins.
• [ ] Each server runs with a scoped service principal (Databricks), scoped PAT (GitHub), or scoped API token (Slack/Jira).
• [ ] No long-lived personal tokens in MCP configs.
• [ ] An MCP "block list" names servers engineers should not install.
• [ ] Quarterly audit of deployed MCP servers and their tool exposure.

6. Settings Sync and dotfiles

• [ ] Settings Sync is enabled by default for new hires (documented in onboarding).
• [ ] A dotfiles repo is documented for per-user shell, Git, and tool config.
• [ ] DevPod integrates with the dotfiles repo (applies on every new environment).
• [ ] No secrets in the dotfiles repo.

7. Shared formatters and linters

• [ ] Ruff is the only Python formatter/linter in the paved path.
• [ ] SQLFluff is the only SQL formatter/linter.
• [ ] Ruff and SQLFluff versions match between local, pre-commit, and CI.
• [ ] Config files (pyproject.toml, .sqlfluff) are authoritative and committed.

8. Pre-commit

• [ ] A paved-path .pre-commit-config.yaml is published.
• [ ] Every repo inherits from or matches the paved path.
• [ ] Pre-commit runs in CI as a gate on PRs.
• [ ] pre-commit autoupdate is scheduled monthly and reviewed before merge.

9. Onboarding

• [ ] A new-hire runbook walks from "laptop fresh from IT" to "first dbt model merged" in under a day.
• [ ] The runbook starts with the extension pack install and ends with a successful PR.
• [ ] The runbook is updated when the paved path changes.
• [ ] A new hire's successful onboarding is the gate for promoting new paved-path changes.

10. Security

• [ ] Marketplace extensions installable only from the approved allow-list (enforced via EDR policy or MDM).
• [ ] Dev containers never ship secrets.
• [ ] Databricks, AWS, and GitHub auth use OAuth flows, not long-lived PATs.
• [ ] Agent configs have no literal secrets; substitutions only.
• [ ] A rotation schedule exists for any credential that cannot be OAuth-delivered (e.g., Snowflake service user passwords, if you must).

11. Debug and test paths

• [ ] Every data-product repo has a working F5 experience for its primary language.
• [ ] Every data-product repo has a working Run Tests experience in Test Explorer.
• [ ] Launch configs cover both local and remote-execution paths (Databricks Connect, attach-to-container).
• [ ] The inner loop for each stack lands in the target time (see inner loop).

12. Documentation

• [ ] A docs site hosts the paved-path standards and reference pages.
• [ ] The /docs/vscode-* doc set stays current. A doc is out of date if its version references mismatch the shipped Extension Pack.
• [ ] New paved-path changes ship with doc updates in the same PR.
• [ ] Troubleshooting guides exist for the top-five failures (see the quickstart, devcontainer, and debugging docs).

13. Feedback loop

• [ ] Engineers have a clear channel (Slack, issue tracker) for paved-path problems.
• [ ] Platform responds to pack-change requests within one sprint.
• [ ] A quarterly survey measures editor setup time and toolchain frustration.
• [ ] Survey trends drive the next quarter's investments.

14. Cost and capacity

• [ ] DevPod usage and cost are monitored.
• [ ] Agent-inference cost is attributed to the right team.
• [ ] Databricks Connect cluster usage from individual engineers is visible (idle clusters wake up people).
• [ ] The org has a view of who uses which paid extensions (Copilot, Cursor) and whether they are active.

15. Incident readiness

When something in the paved path breaks (a Pack update breaks Python tests, a devcontainer base hits a CVE, an MCP server starts hallucinating):

• [ ] A rollback path exists for each component (pin to the prior Pack version, pin to the prior base image).
• [ ] A communication channel announces incidents to every engineer within an hour.
• [ ] Post-incident reviews happen and generate durable improvements to the checklist.

16. The quarterly gate

Platform runs a quarterly review covering:

• Extension Pack contents: adds, drops, pins.
• Devcontainer base images: version bumps, CVE patches, Python/JDK updates.
• Agent configuration: new MCP servers, updated skills, agent version bumps.
• Incidents: what broke, what we fixed, what we learned.
• Cost: is the platform getting cheaper per engineer over time?
• Satisfaction: did the survey improve?

The gate is attestation: every data-product team confirms their repo still passes the workspace standards. Non-passing repos have 30 days to remediate or document a waiver.

What "done" looks like

A paved-path VS Code environment is done when:

• Every data engineer opens every repo and is productive immediately.
• Laptop swaps take under an hour.
• DevPod bursts to a 64-core EC2 in one command.
• AI agents follow org conventions by default.
• Security, compliance, and cost attribution are invisible to engineers because platform handled them.
• Quarterly reviews reveal small improvements, not emergencies.

That is the bar.

See also

• Workspace standards — the per-repo rules this checklist sits atop.
• The extension pack reference — what the pack must contain.
• Devcontainers — the reproducible environment layer.
• AI agents — the agent layer this checklist governs.