AI编码时代:如何防止“氛围编程”引发的数据库灾难

探讨AI如何将软件开发者转变为软件架构师,非工程师编程的兴起,以及为何必须在AI编程助手中设置护栏和更高层次的编程原语以防止数据灾难。

Only you can stop AI database drops

Ryan与Retool的创始人兼首席执行官David Hsu一同探讨了AI如何将软件开发者的角色转变为软件架构师,编程对非工程师的日益普及,以及在AI编程助手上设置护栏和更高层次编程原语的重要性。

Retool是一个面向内部软件开发的企业级AI应用生成平台,允许您使用任何LLM、数据源或API来创建应用、智能体和流程。

David Hsu此前曾做客本播客,抱怨过维护内部工具的问题。

在Twitter上联系David。

今天的致谢送给用户Waseem Wisa,他因回答"Sass compiler throws ‘undefined mixin’ error when mixins are kept in seperate folder"而获得了"Populist"徽章。

转录稿

Ryan Donovan: 如果你正在构建任何与语音AI相关的东西,请查看Assembly AI。他们的多语言语音转文本和理解模型准确得惊人。可以处理发言者ID并直接与LLM集成。你可以在assemblyai.com/stackoverflow获得50美元的免费额度。

[开场音乐]

Ryan Donovan: 大家好,欢迎来到Stack Overflow播客,一个畅谈所有软件和技术话题的地方。我是Ryan Donovan,今天的主持人,我们今天要讨论的是,你知道,一个小话题——软件工程不断变化的本质,以及得益于AI革命,软件能做什么。所以,我今天请到的嘉宾是返场嘉宾,Retool的首席执行官David Hsu。那么,欢迎回到节目,David。

David Hsu: 谢谢,Ryan。很高兴来到这里。

Ryan Donovan: 是的。既然你以前来过,我们就跳过开场白。如果人们想了解你的起源故事,他们可以收听之前的节目。显然,每个人都看到了AI在某种程度上改变了软件的可能性,那么,现在谁才是软件工程师?

David Hsu: 是的。所以,我认为软件行业从过去10年或20年几乎没有变化的时期,过渡到在过去18到24个月里经历了一场相当惊人的变革,我认为主要体现在两个方面;其中之一是软件工程的性质,或者说今天谁才是软件工程师。

Ryan Donovan: 嗯。

David Hsu: 以前,要构建一个功能性的Web应用需要很多技能和知识。你需要知道如何编码,但你也需要了解一大堆事实,比如,哦,你知道,在React中,redux是今天大多数人管理状态的方式。什么是React与Vue?我应该用Heroku还是AWS?基本上所有这些都是事实。所以,我认为,成为软件工程师意味着什么,这一点正在发生变化,这是其一。第二是软件本身的本质正在改变,也就是说,软件过去只能做完全确定的事情。

Ryan Donovan: 对。

David Hsu: 所以,如果你想将两个数字相乘,没问题。

Ryan Donovan: 易如反掌。

David Hsu: 是的。但如果你想让软件为你创作一首歌,软件肯定做不到。

Ryan Donovan: 对。

David Hsu: 而现在,今天它可以了。因此,软件的总可寻址市场,或者说你能用软件解决的问题范围,我认为已经发生了根本性的转变,我认为在未来几年,我们将看到软件创造的繁荣。我们谈论数字化改造,或者公司谈论数字化改造。那是软件的第一波浪潮,就是将事物数字化。我认为下一波浪潮——可能会是更大的浪潮——是思考软件能做什么过去更像人类完成的任务。所以,我认为这算是一股自动化浪潮,可能会让我们所有人,包括我自己,都失业。所以,想想有点可怕,但这就是我认为的两个相当巨大的变化。

Ryan Donovan: 是的。那么,让我们从软件工程师面孔的变化开始。随着氛围编程和AI智能体的出现,软件已经变得更容易接触。有些人甚至说,你知道,新的编程语言是英语。你认为随着每个人都能创造软件,他们能创造出称职的软件吗?

David Hsu: 很好的问题。我认为就目前的产品而言,答案是不能,我们在世界上的Bolt、Lovable、Replit等公司身上看到了这一点,非工程师——我有一些非工程师的朋友——现在能够构建相当复杂的Web应用来追踪他们的个人生活,帮助他们的孩子学习数学,诸如此类。你现在可以构建程序了,这太棒了,这项技术令人难以置信。但当我观察这种软件中有多少比例属于我所说的几乎是"玩具应用"而非生产应用时,世界上大多数软件都是由大公司为生产用例构建的。

Ryan Donovan: 对。

David Hsu: 这是一个关于软件的相当惊人的事实,但实际上大多数软件是面向内部的,这让大多数人感到惊讶,原因在于,如果你想想大多数公司,比如财富500强,这些公司中有多少是软件公司?并不多,可能只有10%。所以,财富500强中90%的公司实际上雇佣了很多软件工程师。他们日复一日所做的,就是构建生产级的内部软件来运营他们的业务。所以,无论你是从CVS取处方药,还是从亚马逊订购东西,或者,你知道,你乘坐飞机去纽约,例如,有太多的内部工具,可以说,内部工具真正在运行这个世界。

Ryan Donovan: 对。

David Hsu: 当我观察——氛围编程能让我们达到那个目标吗?或者你能生成那种……我会信任氛围编程来生成允许你取我的处方药的软件吗?答案肯定是不,我会这么说。所以,我认为那里实际上缺失了一些相当根本的东西。但答案,我认为,是不能。

Ryan Donovan: 是的。我认为有趣的是,你知道,你谈到内部工具,当人们谈论氛围编程和这些AI智能体所促成的"公民开发者"时,就像,是的,我为自己创建一个小批处理脚本或小工具,但差距是什么——你知道,我们甚至还没谈到产品软件,那种你用来赚钱的。为自己创建的工具和为公司安排处方药的工具之间的差距是什么?

David Hsu: 是的。嗯,我认为风险要高得多。你可能见过,我想是不久前的一个头条新闻,我觉得Replit删除了某人的数据库。

Ryan Donovan: 哦,是的。

David Hsu: 而且,你知道,他们对此不太高兴,因为所有数据都丢失了。

Ryan Donovan: 对。

David Hsu: 但这是一个例子,我认为问题在于,今天很多这类产品是构建在JavaScript之上的。我的意思是,它输出的只是原始的JavaScript或原始的React代码,这对软件工程师来说实际上很好。这就是为什么我认为Cursor,实际上Claude Code,非常有效,所以,我实际上没有把它们归入这一类。它们也在进行氛围编程,但这几乎是工程师在氛围编程。所以,我认为那不一样。那相当安全,因为工程师实际上可以阅读代码并理解发生了什么。我认为真正的危险是当非开发人员使用输出代码的产品时,他们很难审视代码并判断,比如——假设你有这条语句,是删除表。

Ryan Donovan: 对。

David Hsu: 一个非工程师读起来会说:“我不知道,看起来合理。让我运行它。看看会发生什么。“或者,像工程师会说的那样:“哦,删除表,你知道,等等。也许我们还不应该这么做。”

Ryan Donovan: 对。

David Hsu: 所以,这就是一个例子,我认为这些非开发人员用来氛围编程的基础层,或者说原语的抽象,实在是太低了。这几乎就像,你知道,假设Claude Code为你输出了汇编语言。如果它输出了汇编,我可能会说,你知道,我想那是有用的,但实际上很难阅读,很难调试。你知道,理论上,我是计算机科学专业的,所以我在10-20年前写过汇编,但我不记得了。它非常详细,非常底层。

Ryan Donovan: 嗯。

David Hsu: 所以,这有点像现在非工程师使用这些氛围编程产品的感受。这几乎就像一个软件。如果你是软件工程师,想象一下如果Claude Code输出汇编。就像:“嗯,那很好。你知道,我想我运行它,然后我想它应该能工作,对吧?但这有点冒险,“对吧?所以我认为对工程师来说,实际上Claude Code很棒,但是,我认为对非工程师来说,这些产品真的需要进化,我认为这正是Retool可以发挥重要作用的地方。

Ryan Donovan: 嗯。是的。这是一个有趣的比较,你知道,很多程序员处理编译后的二进制文件,对吧?他们的代码被编译成汇编或机器码,但这更像一个确定性的过程,对吧?你知道编译器要做什么。每个人都在发现未定义行为并处理它。我们如何达到那个程度,对于,你知道,那种氛围编程的JavaScript?或者我们能吗?

David Hsu: 所以,这是我的观点,但我愿意接受挑战。我的感觉是,你真的需要对氛围编程中可能发生的事情设置很多护栏,特别是对非工程师。然后,我认为这实际上将是软件工程师工作的演变。我的意思是,我认为软件工程师动手编码的时代基本结束了。你知道,我想现在是2025年,至少对于内部工具来说。我认为肯定结束了。我的意思是,软件工程师不再是坐在键盘前输入’让我去写这个内部工具的代码’,我认为软件工程师的工作将会改变。相反,将会变成’我几乎像个架构师。我如何去构建护栏或基础,让这些非开发人员去构建内部软件?‘现在很多氛围编程,特别是这些消费级产品的问题在于,没有护栏。所以,删除数据库非常简单。你会删除数据库。然而我认为,如果你能让这些开发人员构建护栏或更高级的原语,你可以想象,例如,在公司里,你说:“嘿。这是客户视图的React组件。如果你是一个非工程师,想在一对一的基础上可视化客户,你将始终使用这个客户组件。顺便说一下,这里有一个ORM供你使用,这是客户对象。客户对象被定义为我们在Postgres数据库中的这些东西,加上我们在Databricks数据库中的这些东西,加上Salesforce中的这些东西,“例如。一旦工程师定义了这些更高级的原语,那么非工程师实际上可以相当安全地工作。你甚至可以说——工程师可以说——,“嘿。非工程师永远不能通过这个ORM删除数据库,例如。所以,我认为很多这些氛围编程产品的问题在于没有护栏,完全没有工程师参与其中。所以,当没有护栏,没有更高级的原语,只是输出原始代码时,这真的相当危险。所以,这就是Retool在整个氛围编程革命中的全部论点:我们认为氛围编程是一项惊人的技术,目前它对于,我会说,更偏向于玩乐或原型应用来说效果很好。但真正的机会在于,如果它能改变内部软件的开发方式——再次强调,超过一半的软件是内部软件,你真的需要这些护栏。如果我们能提供这些护栏,让工程师以一种安全的方式定义这些护栏,那么非工程师实际上可以构建相当有趣的应用。

Ryan Donovan: 嗯。

David Hsu: 我想也许这里可以类比商业智能,即BI,今天,如果你要求任何工程师,或者要求我,去构建一个BI仪表板,我首先会说:“哦,让我去用Metabase。让我去用Tableau。让我去用Looker。“我会用任何BI工具。

Ryan Donovan: 对。

David Hsu: 我使用BI工具的原因是我可以只专注于我需要编写的确切内容,也就是为了构建我的图表所需的10行SQL。我不想处理数据库驱动程序,不想处理身份验证,不想处理授权。我甚至不想处理前端图表组件。我只想让所有那些都为我完成,我所做的只是SQL。

Ryan Donovan: 嗯。

David Hsu: 这样一来,你现在实际上可以看到很多数据人员,甚至是非技术人员,可以去学一点SQL,他们就能构建相当有吸引力的图表,并真正去分析数据。我认为类似的革命也会发生在应用程序上。今天,应用程序正在被构建——我的意思是,如果你氛围编程一个BI仪表板,它可能会到处都是bug,没有人会那么做。每个人只会说:“嘿,你为什么不在Tableau上氛围编程SQL标题呢,例如。”

Ryan Donovan: 嗯。

David Hsu: 这就是我们试图对所有应用程序做的事情。就是这个想法。

Ryan Donovan: 听起来我们是从隔离危险代码变成了隔离危险的编码者,而你提出的解决方案的一部分,似乎是软件本身越来越组件化。是这样吗?

David Hsu: 是的,没错。我认为问题在于今天它太底层了。所以,我举一个我们作为开发者可能认为理所当然的例子,假设你正在构建一个内部工具,你在构建一个流程,当你在表单中按下提交按钮时,你想禁用那个按钮,因为你不想让人连按五次并提交表单五次,对吧?

Ryan Donovan: 对。

David Hsu: 你知道,非常合理。但在React中做这件事实际上需要很多工作。所以,你需要做的第一件事是导入一个状态管理库Redux,很可能。是的。然后你说,“嘿,你知道,当我按下按钮时,我想把’isFetching’设为true,然后我想去获取数据,然后我想发送post请求。然后当post请求返回时,‘isFetching’变为false,“这样按钮就可以再次启用。所以,当’isFetching’为true时,按钮应该被禁用。实际上,如果你想一下,这需要很多逻辑。

Ryan Donovan: 对。当然。

David Hsu: 至少对于内部工具来说,一个按钮没有理由被多次按下,可以这么说。当然,这对所有软件来说并非如此。例如,如果你在玩视频游戏,你可以想象,“嘿,实际上连按五次按钮。“也许这是件好事。你希望人们连按五次按钮,例如。所以,我认为这是一个例子,如果你缩小问题的范围,如果你说:“嘿,我们不是对所有软件都感兴趣,我们只对内部工具或内部信用应用感兴趣,“你可以说:“嘿,按钮在被点击后应该总是自动禁用,实际上,“并且那个HTTP请求在发出直到返回之前都应该被禁用。所以,这是一个例子,说明React在这方面几乎就像汇编,对吧?它不是为任何特定用例优化的。它是为所有程序优化的,就像汇编在某种程度上也是。但就像我们摆脱了汇编一样,我认为有一天我们也会摆脱React,转向这些更高级的语言。特别是为了让这些非工程师能够不搬起石头砸自己的脚,因为非工程师不想担心Redux状态管理。我的意思是,这对很多程序员来说都太复杂了,他们不想考虑函数式编程,不想考虑如何折叠状态,你知道吗?

Ryan Donovan: 对。只要禁用按钮就行。无论你需要做什么,只要禁用按钮。

David Hsu: 完全正确。所以,我认为你刚才说的是对的,那就是我们需要更高级的原语,可以这么说。我们需要更高级的编程方式,而不仅仅是写汇编,对吧?

Ryan Donovan: 是的。我想知道,你知道,对于这种LLM驱动的氛围编程,代码生成,实现这一点的可能方式是什么。我可以想象某种特性缓存,某种检索增强生成之类的。但我想知道你是否有关于那种护栏机制的想法?

David Hsu: 是的。这就是我们正在做的,所以我可能有点偏见,但我真的认为这将开启明天的开发者。举个例子,我们正在开发的一个功能,我们称之为"安全引擎”,安全引擎的作用是让你实际上在语义上标记你组织内的数据,然后能够说:“嘿,这些特定的数据表,或者表内的这些列或行,永远不应该对某些特定的Okta组可见。”

Ryan Donovan: 嗯。

David Hsu: 这实际上让你能够达到这样一个点:你生成的任何应用,至少从数据角度来看,默认是安全的。我的意思是,今天如果你给一个非开发人员生产数据库的访问权限,并说"你可以尽情发挥,构建一些氛围编程的应用”,那是相当危险的,对吧?而如果你可以说:“嘿,我的用户表中的SSN列永远不应该被这些Okta组看到,“那么你就可以说:“嘿,无论你如何构建这个应用,因为应用运行在Retool平台上,我们保证SSN永远不会暴露给这些Okta组。“仔细想想,这实际上是一种更好的安全实践方式。你知道,你希望在数据层面获得这些保证,而不是在"信任开发者"的层面。想想今天安全的现状,老实说,现在的很多安全就是"信任开发者”。

Ryan Donovan: 对。

David Hsu: 我的意思是,这有点像,我希望安全漏洞在拉取请求中被发现。如果没被发现,它就会进入生产环境,你可能会被黑客攻击,实际上,或者SSN被泄露,而且这种事经常发生。真的,我认为这已经失效了。但如果你再加上那些你可能无法信任、可能不知道自己在做什么的未来开发者——那真的会出大问题。所以,我认为,隔离,或者说制定这些规则,让开发者——或者明天的开发者——拥有完全的自由,而即使他们拥有完全的自由,他们仍然无法搞砸。我认为这将是未来的方向,所以这几乎像是约束带来自由,可以这么说。

Ryan Donovan: 是的。嗯,多么奥威尔式啊。不,就是用户访问控制,对吧?就像,对于你的客户用户,你不会给他们所有数据的访问权限。有一个,你知道的,应用层,数据访问层,然后这似乎是那种做法的延伸。你把它应用到开发者身上,所谓的"开发者”,在这种情况下。

David Hsu: 是的。

Ryan Donovan: 那么,让我们谈谈对话的另一部分——更大的自动化。你提到了自动化创作歌曲之类的。你认为软件本身发生了什么变化?

David Hsu: 所以,我对过去20-30年左右软件市场的理解是,有很多过程是完全确定性的。我的意思是,你知道,先做A,然后做B,然后做C。如果30年前这些是由人类完成的,那么这些过程中的很大一部分现在都由软件完成了。不是全部,所以,你知道,并不是说我们已经完全数字化改造了,但很多。

Ryan Donovan: 嗯。是的。

David Hsu: 越来越多的行业中,纸笔开始消失,所以很明显很多正在被数字化。然而,今天大多数公司,当他们无法将一个过程数字化时,他们就在那个过程中插入人类,所以也许需要人类判断。例如,也许你在审批信贷,审批抵押贷款,也许你需要验证一个ID。所以,人类需要看一下ID并验证是否是正确的人?基本上就是这类事情。所以,这是一个例子。另一类例子可能需要一些创造力。所以,也许第一类是关于验证——你并不完全信任机器。第二类是关于创造力,也就是,“嘿,我们公司今年的战略是什么?”

Ryan Donovan: 嗯。

David Hsu: 我在打销售电话,需要说服对方购买我的产品。你知道,很难将这种逻辑确定性地编码到软件中。所以,你需要人类;你需要人类销售员来做。我会说创造力是另一个例子。我认为我们现在在我们的客户群中开始看到的是,LLM,特别是在这些特定任务上,开始变得非常非常有效。例如,以销售用例来说,现在SDR实际上可以打电话,或者我应该说LLM SDR实际上可以打电话。你知道,现在的延迟不是很好。可能有一两秒,但目前实际上相当可行,而且技术只会越来越好。延迟会下降。将会达到这样的程度,我认为,从销售的角度,从支持的角度,你实际上可以和LLM通电话来回答你关于产品的问题,如果你有——也许可以购买产品,这很酷。所以,这就是一个例子,我认为软件整体的总可寻址市场可能会增长3、4、5倍。所以,软件将会爆炸式增长。以前,我认为问题是"我能构建软件来完成这个任务吗?“答案是不能。现在,很多时候,答案将是能。所以,我认为这比以往任何时候都更是如此。实际上,现在成为软件工程师很棒,因为软件工程师正处在前沿,引领着如何应用软件工程和LLM去解决这些相当模糊、不明确的问题。所以,我认为这是一场相当重大的革命,而且我认为我们还处于非常早期的阶段。

Ryan Donovan: 是的。

David Hsu: 我认为你还没有真正看到LLM在劳动力数字中显现出来,但我想你会看到的,一旦你开始看到,我认为在某种程度上会相当可怕,但在另一种程度上——

Ryan Donovan: 那将是很奇怪的时代。

David Hsu: 也会相当有启发性。是的。

Ryan Donovan: 是的。你谈到LLM的创造力,我认为,你知道,它将具有一定的创造力,并且总体上与人类偏好有很好的一致性,但它产生的那种创造力像是统计上有效的,对吧?它是一种数据驱动的创造力。你认为LLM会停留在那个水平吗?就像,这是一个平庸的初稿,或者随便什么,然后让领域专家介入,还是你认为它们有可能达到领域专家的水平?

David Hsu: 是的。让我们看看。所以,这里有几个想法。关于创造力方面,我确实同意你的看法。你知道,我从来没有读过任何LLM生成的东西,让我觉得"哇,那太不可思议了。“你知道吗?至少从文体风格的角度,我还没有那种感觉。但实际上,大多数工作并没有那么高雅,老实说。

Ryan Donovan: 那倒是。是的。

David Hsu: 我的意思是——

David Hsu: 很多工作都相当平庸。是的。

David Hsu: 是的。你知道,例如,我读很多小说,我喜欢小说,但大多数作品都不是,你知道,诺贝尔奖级别的小说。你知道LLM能达到那个水平吗?老实说,我不确定,但它不需要达到那个水平就能产生大量具有经济价值的工作。所以,我要说的两点——这是其一。第二点是,当你将LLM的范围缩小到一个特定任务,给它正确的输入时,我们从客户群中看到的是,它实际上做得非常好,通常比人类更好,特别是如果你考虑到LLM实际工作的速度。举个例子,Retool开始做的一件事是,我为我的所有会议都配备了录音器。我想我们用的是Whisper,我们基本上转录,至少我所有的会议都被转录,然后保存下来,实际上,在一天结束时,我可以用一个LLM来梳理会议记录。所以,这实际上相当有效。而且,你知道,过去当我试图用LLM来做一些工作时,会很困难,因为它没有上下文。它不太知道发生了什么,不太能访问我们的文档,不太能访问我们的会议记录。但如果你给它访问会议记录的权限,给它访问文档的权限,它实际上就有很多上下文了。现在,上下文工程相当棘手。你不想给它太多上下文,所以你不想让它超载,但如果你能给它特定的正确上下文,正确的文档,正确的会议记录,它实际上出奇地有效。它比我强吗?我的意思是,老实说,在某些情况下,它可能比我做得更好。但即使是在它不比我强的情况下,也许它能达到我所能做到的80%,但它做得快得多。所以,当你考虑时,在某些情况下,你知道,质量确实重要。

Ryan Donovan: 嗯。

David Hsu: 但很多时候,实际上,我会很容易接受在两分钟内达到80%的质量。你知道,而不是五天内达到100%的质量。所以,我认为当我们这样想时,我认为当你给LLM正确的输入,并且不仅仅考虑它产出的工作是否和我产出的完全一样好,还考虑时间,考虑成本,那么它就开始看起来相当可怕了,因为老实说,LLM相当不错。

Ryan Donovan: 嗯,在信息检索、总结和综合方面,它相当惊人。我以前也用它做过一些研究,它提取信息的速度比我快,我得在资料里挖掘——

David Hsu: 我也是。是的。

Ryan Donovan: 但是,你知道,终稿的东西,那是我总是希望有人类参与的地方,对吧?

David Hsu: 我认为很多伟大的作品,至少在艺术上,你知道,都有某种惊喜元素,而你知道,LLM目前并不太令人惊讶。所以,我同意,我认为那最后一步,但老实说,我不确定惊喜或愉悦是否是大多数知识工作中完成的工作的一个因素。

Ryan Donovan: 当然。

David Hsu: 你知道,当我阅读一份文件时,我不会说"那是一份很棒的文件,因为我是如此惊讶,“你知道,我不一定会这么说。

Ryan Donovan: “多棒的功能规格书!”

David Hsu: 是的。我的意思是,有时我确实有那种感觉,但很多时候,你知道,它是否解决了客户的问题?老实说,我认为在综合客户反馈方面,LLM会比任何一个产品经理做得更好,特别是当你考虑到它综合了多少信息,以及它能以多快的速度完成时。

Ryan Donovan: 所以,我认为你谈话中那个刺激的数据是,到2030年,10%的工作将被自动化,我想是这个。你能谈谈你认为那将是哪些工作吗?

David Hsu: 所以,这个说法的背景是,我们发布了一个名为"智能体"的产品。所以,也许我简单解释一下。

Ryan Donovan: 好的,好的,当然。

David Hsu: 然后我会回到这个问题。什么是智能体——这是目前LLM工程中的标准术语——所以,它被称为React风格的智能体。它基本上进行推理并采取行动。它通过,你知道,基本上,你给它一些输入,然后说"嘿,你的目标是将这个输入转化为这个输出”,然后你会得到这些工具来实现它。所以,LLM基本上会思考,你知道,“我如何从这个输入到达这个输出?“就像:“好吧,那么,你知道,有了这些工具,我会先应用这个工具,然后我应用这个工具,然后我应用这个工具,然后也许我就会得到我的输出。“这里真正酷的一点是,至少在LLM出现之前这是不可能的,那就是这实际上不是确定性的。以前你可以有工作流,你可以说"嘿,你知道,做A,做B,然后做C,A是计算。B是计算,C是计算。“是的,你知道,那只是代码,对吧?从上到下运行它。现在,有了这个LLM,至少有了智能体,你有了这些工具,你思考应该使用哪些工具来实现这个结果。这,你知道,是一种相当奇怪的工程思维方式。

Ryan Donovan: 当然。

David Hsu: 这有点像人类所做的。如果你要求一个人说"嘿,去解决这个支持工单,“这个人会说"好吧,那么,我有什么工具可以用?“或者"嘿,去制定这个公司的战略。“这个人会想"好吧,那么,“假设我是个顾问,你知道,我在麦肯锡工作,我就像"好吧,我如何制定这个公司的战略?“嗯,可能首先,我想收集数据。我想了解当前的战略。它有效吗?没效吗?所以我查看数据,然后我说"好吧,那么竞争对手在做什么?“你知道,所以,也许我查找竞争研究工具,你知道,进行网络搜索,无论是什么,然后最终,我使用写作工具来产生最终结果。所以,基本上就是这个产品。我们认为它相当了不起,而且它实际上增长非常快。按目前的速度,我们预计到2030年,实际上用这个产品可以自动化美国10%的劳动力。

Ryan Donovan: 对。

David Hsu: 所以,这很酷。但我具体的意思是——我想你知道为什么它增长这么快,是因为——我认为很多工作,如果你仔细想想,基本上可以这样分解。我认为有一个例子能引起Stack Overflow受众的共鸣,那就是想想为什么像Cursor和Claude Code这样的应用如此有效,原因是它们是自主的、智能体的。它们有工具。我的意思是,你实际上可以用ChatGPT应用完成Claude Code所做的一切,对吧?所以,你可以说"嘿,你知道,ChatGPT,给我写这段代码。“它给你写了代码,你复制它,粘贴到你的IDE,运行它,得到一个错误,你把错误复制回来,去ChatGPT,说"我得到了这个错误。这仍然是个问题。再来一次。“所以,你知道,你来来回回。现在,实际上,Claude Code基本上就在做这件事。但Claude Code不是在复制粘贴——它们不进行任何复制,因为它们直接写入IDE,但基本思想是,它能够代表你做事。然后,它意识到如果你告诉它"嘿,你知道,我运行它并得到一个错误,“它会自己运行它。就像"哦,我得到了一个错误,所以让我去做点什么。“所以,我认为了不起的是——这就是为什么我认为它,我认为大多数开发者,Cursor或Claude Code比复制粘贴到ChatGPT中要有效得多。

Ryan Donovan: 对。

David Hsu: 但如果你想想今天大多数知识工作,大多数人使用ChatGPT的方式——大多数知识工作者使用聊天,包括我自己——就是我们一直在把内容复制粘贴进出ChatGPT。所以,如果你能想象,引入一种像Claude Code那样的智能体方式来做事情,但你把它连接到所有你拥有的上下文,连接到Google Docs,连接到所有工具,连接到所有系统,Salesforce,连接到服务系统,连接到所有你使用的系统,那么你几乎可以想象,所有其他工作,而不仅仅是软件工程,都会发生类似的革命。这基本上就是Retool智能体这个产品的目标。所以,我们允许你去自定义构建工具,然后现在LLM实际上可以使用这些工具在你的业务中实际做事。所以,从这方面想,软件开发者的工作,我认为在过去6到12个月里变化太大了。我认为类似的革命在未来18个月内会非常快速地发生在所有工作上,一旦我们授权软件工程师能够构建这类智能体,而这正是我们产品的设计目的。

Ryan Donovan: 是的。我的意思是,回到你之前说的一些话,这听起来确实会有一个有点可怕的工作重塑,对于,你知道,像我们这样的人来说。所以,你知道,希望我们都能安然度过。会有,你知道的,技术动荡的政治解决方案。

David Hsu: 老实说,我有点担心,因为我认为你看到了美国制造业工作岗位消失的一些后果,现在也许它们会回来。我们拭目以待。这是否是件好事,我不确定。但如果知识工作在美国消失了,我的意思是,我们剩下的就不多了。你知道,如果服务业经济没了,那就没多少了。所以,是的,我们看看。我认为这是一个可怕的时代,但我认为至少在未来几年,我认为软件工程师会有很多事情要做,因为所有这些东西都需要由软件计算机来构建。

Ryan Donovan: 现在是节目中我们向某人致谢的时间,这个人来到Stack Overflow,分享知识,激发好奇心,为自己赢得了一枚徽章。今天,我们向赢得Populist徽章的人致谢——这个人给出了一个非常好的答案,以至于得分超过了被接受的答案。那么,祝贺Waseem Wisa回答了"Sass compiler throws ‘undefined mixin’ error when mixins are kept in separate folder”。如果你对此感到好奇,我们会在节目说明中为你提供答案。我是Ryan Donovan。我是Stack Overflow博客的编辑,也是这个播客的主持人。如果你有评论、担忧或话题要讨论,请给我发邮件至podcast@stackoverflow.com,如果你想直接联系我,你可以在LinkedIn上找到我。

David Hsu: 我是Retool的首席执行官David Hsu。如果你想在网上找到我,我在Twitter上是@dvdhsu,retool.com是你可以找到Retool的地方。谢谢邀请我。

Ryan Donovan: 好的。非常感谢大家的收听,我们下次再聊。

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计