当人人都能做软件，懂业务的人有了什么新机会？丨Y Combinator
原创 Capihom 2026-11-08 20:45 北京
司机用手机做打车应用，工程师让 Agent 写代码，十几人的创业团队重新算融资的账。做软件的门槛降低后，哪些事变了？
每天挑选一期硅谷AI科技值得关注的播客，让你与前沿同频。如果你现在没空可以收藏进 晚点再听LaterCast，在通勤、走路或做家务时一篇篇轻松听完
"过去在 Supabase 上做软件通常需要工程背景，现在没有工程背景的人也能做了。"
"想赢得 Agent，第一步是让模型选中你，第二步是它卡住时别让它换掉你。"
"数据库已经存在了五十年，我觉得它们还会再存在五十年。"
Supabase 的一场大会结束后，一位巴西出租车司机找到联合创始人兼 CEO Paul Copplestone，说自己用手机给当地市场做了一个打车应用，像个小型 Uber。Paul 不知道他为什么要做这个应用，倒是很清楚地记得对方讲起这件事有多兴奋。
访谈里提到，Supabase 的注册量一年间从约 300 万涨到 1,300 万，管理的数据库从约 800 万个涨到接近 5,000 万个，现在每周还会新建超过 100 万个。主持人 Garry Tan 给了另一个数字，约七成新增活动来自 Agent。以前来开数据库的大多是工程师，现在来做软件的人更多了，真正动手开库的常常是 Agent。
懂行的人，可以先把点子做出来
Paul 把增长归到两拨人身上，工程师做的东西比以前多，没有工程背景的人也开始在 Supabase 上搭应用。通常注册量一下子冲上去，激活和转化容易被拉低，这次两项却都在涨，Paul 当时预计营收能达到上一年的约四倍。
一位主持人说，他认识的金融科技创业者以前能凑出几段 Ruby 脚本，真要做成软件还得找工程师，现在已经能给自己做资产负债表和财务追踪工具，连银行接口都从头接。做过金融业务的人知道该记哪些账、该从银行拿什么数据，这些细节就能直接写进他自己的工具里。
Garry 说，前几年 YC 特别看重团队有没有技术联合创始人，现在有些人靠 AI 就能先把点子做一版，看看它管不管用。做出第一版容易了，知道该做什么就更要紧。比如司机要做什么样的打车应用，答案可能就在他每天跑车时碰到的麻烦里。
Paul Copplestone 用一位巴西司机的经历，说明数据库平台正在迎来哪些新用户。
只给自己用的软件，也值得做
YC 的 Jared Friedman 原本想用 OpenClaw 聊天，把资料全放在 Markdown 里，真要管邮件、开支和运动记录时，还是给自己搭了一个带界面和数据库的「控制塔」。有了专门处理邮件的页面，他打开就能分拣邮件，连收件箱都不用进。
一笔转账只显示姓名时，Jared 的 Agent 可以去查那是谁，再按他自己的方式归类。体重和运动数据也能连着日历看，体重涨了，Agent 还能看到他那几天正在出差。这些事靠一款面向所有人的理财或健康应用，很难替他做到这么细。
Paul 担心联系人和日常流程都留在同一个 Agent 里，将来想换工具还得跟着搬资料，便开始把它们一点点迁出来。Jared 也有个类似的做法，收到文件就转发邮件或直接上传，由 Agent 判断文件和自己有什么关系、接下来该怎么处理，原件留在 Supabase 的文件存储里。
数据库的入口，从仪表盘变成命令行
Supabase 最早给 Postgres 做了个像 Airtable 的仪表盘，工程师可以在页面上直接管理数据，后来有集成方要批量建库，团队才为此做了 API。等到 Bolt、Lovable 这类产品来接入时，批量建库的接口已经有了。
编程 Agent 开始绕过仪表盘之后，Paul 给团队发了份备忘录，要求以代码为先，并重做命令行工具，好让 Agent 能在沙箱里调用。他对产品功能的要求是：
"仪表盘上能做的事，代码里也要能做。"
Supabase 赶上了被模型当作默认数据库的时机，Paul 觉得开源帮了大忙，也承认很难知道换条路会怎样。团队参与维护的工具进入了 Postgres 社区，主持人提到，Agent 排查问题时可以直接读开源实现，Paul 则想到企业采购时也可能想看看供应商的源代码。
创始人用手机试，Agent 卡在哪里
Paul 拿自己搭网站的过程来试 Supabase，那天他从电脑换到手机，继续跟 Agent 通话，嫌网站的生态介绍和用例页面连得不顺，就让它先提建议，再照着改。按他的回忆，大约二十秒后 Agent 让他刷新页面，点开链接就能看到改动。
"我尽量不告诉它该怎么做，也尽量不指给它看 GitHub。"
Paul 有工程背景，知道该给 Agent 哪些提示，所以试的时候反倒有意少说，平时也尽量不看代码，真要核验实现时才打开。他想知道，一个只会描述需求的人，能不能顺利用上 Supabase。
过去碰到一条笼统的 500 错误，工程师还能拿着它去搜，Supabase 现在会让 Agent 跑真实任务，看看它卡住时到底收到什么。报错里能写修法就直接写，需要查文档就指到具体页面，免得模型一开始选了 Supabase，遇到问题却只好换一家。
Agent 写得越多，团队越要知道怎么验收
按主持人转述的 Supabase 内部调查，用编程 Agent 写约八成代码的工程师比例，半年里从约 10% 升到了约 60%。Paul 说公司没有统一的 AI 使用规定，工程师可以自行选工具，模型变好以后，他们也在自己的工作里看到了能做成什么。
工程师用 AI 写的代码多了，团队也开始加做测试、引入新的测试工具来确认结果。Supabase 会让不同模型跑实际任务，比较它们能不能完成，也单独测模型操作 Postgres 的表现。
Paul 说，现在有相当一部分工程时间用来弄清用户究竟在拿产品做什么，再把那些用法变成测试。单个 API 能正常返回，Agent 仍可能在建应用的中途走错，这类问题得把任务从头跑一遍才看得出来。
给 Agent 一堆资料，还得让它找得到那两页
Garry 做 GBrain 时，手里有大量个人资料，模型虽然能读很长的文本，眼下该给它读哪一段却是另一个问题。资料可能有几十 GB，Agent 为了回答手头的问题，也许只需要其中两页。Garry 把检索单独做了一层，用向量搜索和资料间的关系找出相关内容，再交给模型。
他从实际运行记录里挑出一组测试，分成大约四十类，除了看找得准不准，还看要花多久、花多少钱。Agent 可以反复试新的检索办法，分数有改善的就留下，没跑通的也写下来，说明试了什么、可能为什么没用，免得下次再试一遍。
主持人问，以后做软件的人也得懂这些评估方法吗？Garry 觉得未必，他把自己的做法看作早期实验。访谈也提到 Claude Code 的 Boris Cherny 描述的另一种体验，用户可以像跟朋友聊天一样说出需求，让工具自己想办法做出来。
Garry Tan 介绍 GBrain，Agent 先从个人资料中找出相关材料，再把检索结果放进上下文。
数据库公司得同时做大、做小
Supabase 最早盯着 YC 的创业公司，Paul 想在它们开张第一天就把数据库接进来，毕竟用起来以后要搬家很麻烦。现在，一些用户做的只是个人理财工具，数据会一年年往里存，项目本身却未必需要一套大公司的配置。
Paul 假设有十亿级的 AI 用户，如果每个人每月都想开一个项目，数据库公司就得考虑怎么撑住每月十亿级的建库需求。Supabase 要让少数客户的数据库继续长大，也要让大量小项目开得起。
面向刚起步的项目，Paul 提到计划用 Turso 的技术做 Supabase Spark，接下类似 SQLite 的轻量负载。另一头则是面向大型 Postgres 工作负载的 Multigres，留给真正长到需要扩容的项目。
小团队重新算一遍创业的账
Garry 和创始人聊下来，发现有些垂直 SaaS 做到 500 万至 1,000 万美元的年度经常性收入，A 轮也比以前难融。但他也看到，有些公司只靠十到十五个人，就能做到过去得请更多人才能做到的收入规模。
有创始人没拿到下一轮就觉得自己没达标，Garry 会问，手上的收入是不是已经够养活团队。Paul 说，自己刚创业时也觉得拿到钱是件了不起的事，现在反而有点羡慕那些做到了可以不融资的公司。
至于 Supabase 自己，Paul 相信做软件的方式还会继续变，数据总要有地方存，所以愿意长期做数据库。他说，团队还得继续拿自家工具做东西，从合作伙伴那里听听人家在做什么，手上也得留点人试新想法，毕竟听上去很好的合作，动手以后也有做不成的。
写在最后
如果你也想试试，可以挑一件每周都要做、现成软件又帮不上忙的小事，拿几条真实样例给 Agent，看看做出来的东西能不能直接用。它第一次做错时，你纠正它用的那条规则，可能就是你想要的功能。能把这条规则讲清楚，就有东西可试了。
内容来源："What Happens When Everyone Can Build Software"丨Y Combinator（嘉宾：Paul Copplestone）
原视频：https://www.youtube.com/watch?v=vl7HiMdGfjo
相关文章
如果你现在没空，可以收藏进晚点再听，通勤、走路或做家务时一次性听完⇣
⇣ 关注我，每天为你更新硅谷最新的 AI 创业／科技播客总结，让你与前沿保持同频 ⇣