随着GitHub的规模不断扩张，程序代码库也越来越庞大，为了让GitHub新的开发成员快速上手，以及提供更方便的开发环境，GitHub工程团队从原先以macOS为中心的开发模型，转而使用Codespaces，并且采用预构建等方法，将启动开发环境的时间缩减至10秒钟。另外，GitHub也宣布，开始向Team和Enterprise Cloud方案用户提供Codespaces，并扩展个人方案用户的测试规模。
距离GitHub.com第一个程序代码提交已经14年，在这14年间，GitHub.com核心存储库已经收到超过一百万次提交，而这些提交绝大多数，来自在macOS上构建和测试的开发人员，而随着GitHub开发平台不断发展，macOS模型已经不适用。
多年来，GitHub采用一种称为Scripts-to-rule-them-all的方法，让新加入开发团队的成员，可以复制github/github存储库、执行设置、加载脚本，并且能够在半天的时间，就成功于本地执行实例执行GitHub.com，当流程无法顺利进行，则脚本会自动帮新进成员连接到内部支持人员，以快速解决问题。
但GitHub提到，尽管他们做出许多努力，但本地端开发环境仍然非常脆弱容易出错，有时候甚至需要开发者花数小时的时间来恢复开发环境，而且这种情形并不少见，他们甚至特别编写了一个称为–nuke-from-orbit的脚本来解决这类问题，该脚本会尝试删除设置，尽可能将本地环境恢复成为良好状态。
另外，GitHub认为，单一上下文且定制的本地端开发环境，与现在GitHub的运营需求，包含即时启动、从任何地方访问的哲学格格不入，开发者在跨多个项目的多个分支上协作更是不便，当新分支加入新的相依项目、发布架构更改或是从不同的SHA分支的时候，常需要花费45分钟以上的等待时间。
在GitHub构建Codespaces时，他们发现不少企业遭遇相同的问题，而这些企业也在组织内置构类似Codespaces的平台，来解决这类问题，GitHub提到，在大规模的组织中，消除这类型的生产力损失，将会是明显提升生产力的好方法。
Codespaces是GitHub在2020年发布的新服务，让用户可以直接在网页IDE编辑程序代码，并且使用所有VS Code浏览器版本的所有功能，包括配置程序代码和相依项目等功能，其一大优点是可以简单地切换开发环境。官方提到，将GitHub.com程序代码库搬到Codespaces，解决了GitHub开发环境现有的缺点。
Codespaces让开发者依据手上任务，按需获取开发环境，不过，这也带来新的问题，基于任务的工作流程，需要接近即时的速度，但因为光是简单地复制GitHub.com存储库13 GB的文件，就需要20分钟，再加上依赖性配置设置，要完整加载一个GitHub.com程序代码空间，需要花费45分钟，这个时间无法满足基于任务的开发环境条件。
因此GitHub进行了一些方法来加速获取程序代码库的速度，首先是改变Codespaces复制的方法，让Codespaces进行浅层复制，不在配置时进行完整复制，仅在最新的程序代码提交，Codespace创建之后，才会在背景进行非浅层复制，这样可使得一开始复制时间，从20分钟降为90秒。同时，GitHub每晚还会执行一个GitHub Action，将存储库、相依项目和构建等文件打包成为镜像文件，这个镜像文件被用作github/github的开发容器，以配置即程序代码的方式构建Codespaces环境。
这两项改变以及一些应用和服务层级的优化，使得GitHub.com程序代码空间的创建时间，从45分钟缩短至5分钟。虽然5分钟已经是很大的进步了，但是GitHub仍不满足，因此他们又采用预构建方法，在Codespaces池中准备事先启动的开发环境，等待需要的开发者连接访问，这样的方法可以让开发者在10秒内，立即使用到GitHub.com开发环境。
在Codespaces中，GitHub能够简单地配置每个开发者所使用的机器规格，一开始使用8核心、16 GB内存的虚拟机，为了符合更多样服务的需求，因此进一步提高机器规格到32核心、64 GB内存的虚拟机，GitHub提到，这个过程只需要更改一行配置，就能够立刻升级每个工程师的机器。
除了使用VS Code作为主要来操作程序代码空间的工具，原本使用Vim和Emacs的用户，也能够使用程序代码空间，GitHub借由升级预构建镜像文件，让该镜像文件使用GitHub公钥，并且打开22连接端口，并从端口口转送程序代码空间，让不使用图形接口编辑器的用户也可以用到Codespaces。