VibeCode的概念越来越火，这是一种新的编程方式。程序员从用纸带打孔编写代码，到用记事本编写汇编，接着使用有lint和颜色区分的专用代码编辑器，再到上一阶段集成了各种工具的IDE。程序员的代码编写工具越来越高级，但最终目的始终没有发生变化，抽象物理世界。
现在我们迎来了新的阶段，和大模型一起编程。不同的编程工具其实会极大地影响人们的编码风格，在使用IDE的时候，我们更倾向于分割代码，因为IDE的索引可以让我们非常方便地在各个文件中跳来跳去。而如果使用普通的代码编辑器，一个简单的功能写几十个文件是不可接受的。
前端和后端代码仓库的管理，经历了前后端不分离–前后端分离–SSR的变化。现在还有很多对于SSR的争议，最近nextjs的CVE就让大家对SSR又充满质疑。我这篇文章不关注SSR本身的技术优劣势，单从VibeCode的角度来看。现在的微服务、前后端分离的架构，我们往往将一个部署单元独立成一个代码仓库。这在部署的时候很方便，因为我们只需要关注这个单元的CICD流程。同样的，在编写代码的时候，我也可以更高效的分工写作。但在AI时代，AI更擅长的是给完整的视角，更全面的信息来写单一职责的链路。越单一的功能，AI实现的越好，这点毋庸置疑。但是将代码仓库隔离，就给AI获取整个链路的上下文增加了阻碍。
我最近在写一个AI续写的网站，刚开始的时候建了两个仓库，一个前端仓库一个后端仓库。我的网站除了AI生成部分的逻辑，其他的逻辑是比较简单的CRUD，但是因为一开始我分割了两个仓库，导致我每个功能点都需要在两个仓库中重复一遍，而且还需要人工介入当传话筒。当后端定义出接口后，我得告诉前端的AI接口协议是什么样的。如果前端AI写的过程中少数据了，我还得再让后端AI再写一遍。再这样开发了一段时间之后，我受不了了，不单单是时间的问题，token也花费很多。于是我建了一个新的文件夹，把后端仓库和前端仓库都放在统一的文件里，然后让同一个ai来进行操作。这样效率提高了不少。至少每个功能点我只需要写一次prompt就可以了，唯一的缺点是，git的管理不轻松，尤其AI编程很容易需要回滚，但是在两个不同的git仓库里操作，统一的回滚是很麻烦的。像一些VibeCode工具都只支持到git仓库级别，所以我又大刀阔斧将后端和前端直接整合成一个仓库，这种仓库也有一个名字：MonoRepo。
据说谷歌内部大部分代码都在一个代码仓库里，他们并不是使用的git这种分布式文件版本控制工具，而是内部自研的一套单体仓库管理。好处是大家都在master上开发，并且所有的CICD构建都统一管理。当我将前后端完全合并成一个仓库后，我和ai的开发变轻松了不少，在版本控制上，我可以让AI并行进行开发，拉取两个分支。如果有一个分支开发的不好，我直接弃用就可以。这是两个git仓库难以做到的事。
VibeCode除了让大家工作变快了之外，对于个人来说，他提供了更多单人公司的机会。之前需要一个团队才能完成的事，现在完全可以由一个人交付的。利用AI独立开发，很多人都了解，也有不少人以及尝试了。我从我第一个vibecode的项目中来看。独立开发的服务部署成本非常高，而vibecode时代，代码和程序开始进入走量时代。很多人可能要同时做大量的服务。而这个时候，部署成本成了关键的因素。如果拆分为两个部署单元，当项目非常小的时候就很不划算。以我使用的Railway举例，一台机器最低配是1CPU1GB的配置，但我的MVP服务后端占用只有不到20MB，前端不到5MB。我使用两个容器部署就得掏两倍的钱。所以将代码合并，在走量的VibeCode流程中也是非常重要的。