WorkOS 如何让任何员工用 AI 安全交付内部应用

简要描述Brief Description

让公司里的任何人都能借助 AI 发布内部应用——WorkOS 的 Garrett GalowLet Anyone at Your Company Ship Internal Apps with AI — Garrett Galow， WorkOS

目录Table of Contents

• 简介
  Intro
• 让每个人都能发布产品
  Letting everyone ship
• 故事：Perona GPT
  Story: Perona GPT
• CEO 无法打开它
  The CEO couldn't open it
• 构建变便宜了，交付却没有。
  Building got cheap. Shipping didn't.
• 我们需要做的：构建并分享
  What we needed: build and share
• Claude 时代：键盘前的非工程师
  Claude days: non-engineers at the keyboard
• WOW 命令行界面
  The WOW CLI
• 共享技能仓库
  A shared skills repository
• 演示：向运行中的应用发送一条命令
  Demo: one command to a running app
• 注册表中有 278 个应用程序
  278 apps in the registry
• 示例应用
  Example apps
• 每个需要通过公司登录访问的应用
  Every app behind company login
• Atlas：底层平台
  Atlas: the platform underneath
• 三项原则
  Three principles
• 在 Cloudflare 上运行
  Running on Cloudflare
• 默认安全：单点登录、日志、密钥
  Secure by default: SSO, logs, secrets
• 结果：37% 的产品在没有工程师参与的情况下构建而成
  Results: 37% built without engineers
• 接下来是什么
  What's next
• 总结
  Wrap-up

简介Intro

大家下午好。我叫 Garrett。我在 WorkOS 的产品团队。你们可能注意到了，这张幻灯片的标题，也就是这场演讲的标题，稍微改了改。呃，这是个坏消息。好消息是，这让演讲变得更好了，因为我两个月前对这场演讲最初的构想，呃，现在已经有点过时了……Good afternoon everybody. My name is Garrett. I'm on the product team at WorkOS and you may see that the title of this slide this talk has slightly changed. Uh, that's the bad news. The good news is that the talk is better for it because the original idea I had for this talk two months ago uh is already sort of out of date with

让每个人都能发布作品Letting everyone ship

事情发展得真快。今天我们要聊聊，怎样才能让公司里的每个人都能交付成果？公司里有很多人有很棒的想法，能解决公司内部的问题，但即使有了 AI，技术仍然会成为他们的阻碍。所以我想讲讲我们是如何应对这个问题的、采取了哪些措施，并给你一些建议——如果你打算自己解决这个问题，或者想了解我们会提供什么帮助来协助大家应对这个问题。事情大约发生在六到八个月前。how quickly things move. So today we're going to talk about how do we enable anyone at your company to ship? There are lots of people at your company that have great ideas of things that will solve problems inside your company but even with AI the technology still holds them back. So I'm going to tell you the story of how we dealt with this problem, what we did about it and give you some advice if you're going to do it yourself or talk about what we're going to offer to help folks with this problem. So this was about six eight months ago.

故事：佩罗娜 GPTStory: Perona GPT

嗯，我们有一位客户经理叫 Perona，她当时正准备休产假。她是一位非常出色的客户经理，想在休假期间做点东西来帮助销售团队的其他成员。于是她就做了一个叫 Perona GPT 的工具。嗯，它基本上是一个聊天机器人，基于她的销售通话记录以及她对产品的了解进行训练，帮助她不在的时候的其他同事。她当时用 Lovable 做了这个工具，把所有东西都弄好后，效果很棒。她把工具分享出来，说：“嘿，我做了这个工具，我不在的时候你们可以用。希望能帮上忙。”结果，我们的 CEO Michael 第一个试用这个工具时，看到的却是：“你没有……”Uh, one of our account executives Perona she was about to go on maternity leave. She's a incredible AE and she wanted to build something to help the rest of the sales team while she was on leave. So she went and built something called Perona GPT. Uh, it's basically a chatbot trained on her sales calls and all the stuff she knew about the product to help other people uh while she was out. So she went, she built this at the time she used lovable, all the stuff she got it working great. She shared it and said, "Hey, I have this tool that you can use while I'm out. I hope it's helpful." First thing our CEO Michael tries to use the tool and he gets this you don't have

首席执行官打不开它。The CEO couldn't open it

访问权限。他没有 Lovable 账号，因为他没用过 Lovable，所以也就没法用。于是他就问：“嘿，我们能怎么办？怎么才能确保每个人都能用？”解决方案是：“嘿，应用 AI 团队的两位工程师，你们能把这个改成一个应用吗？这样我们就能部署它，让所有人都能访问。”现在，客户经理想出了一个好主意，但要让这个主意真正发挥作用，我们就得找工程师花一大堆时间重新编写代码，你知道，把它从 Lovable 迁移出来、部署、管理之类的。这真的很让人头疼，因为本来应该是她创建应用、部署、分享，所有人都能访问，然后大家就可以……access. He doesn't have a lovable account cuz he's not not used lovable uh and so he can't use it. And so he's like, "Hey, how what can we do here? How do we make sure everyone can use it?" And so the solution was "Hey, two engineers on our applied AI team, can you go convert this into like an app that we can deploy and that we can give everyone access to? So now we have account exec who comes up with a great idea, but in order to make that idea actually useful, we have to go get engineers to spend a bunch of time recode it, you know, move it from lovable, deploy it, manage it, all this kind of stuff. And this is really painful because really what should happen is she creates the app, deploys it, shares it, everyone gets access, and now people are are

构建变便宜了，交付却没有。Building got cheap. Shipping didn't.

使用它。所以，构建东西变得很便宜了，对吧？她当时在用 Lovable，那大概正好是 Opus 48 要发布的时候。现在很多情况下，人们会用 Cloud Code、Codex 之类的工具。所以，做出一个东西并不难——一个你可以运行 `npm run dev` 的东西。现在这很容易。但把它发布出去，让别人能用，哪怕只是在公司内部使用，也并没有变得容易多少，对吧？你要把它部署到哪里？这个应用要在哪里运行？怎么确保它是安全的，对吧？人们要怎么……你想要……让公司的内部员工通过身份验证来访问它，但又不想让它公开可用。所以，对于技术不太熟悉的人，或者非工程师来说，他们会很纠结，比如：我要把它部署到 Vercel 上吗？using it. And so building things got cheap, right? She was using lovable, that was kind of, you know, right around when like Opus 48 was coming out. Now people are using Cloud Code, Codex and stuff in many cases. And so it's not hard to build a thing, something that you can, you know, npm run dev. It's pretty easy now. But shipping it, making it available, even internally to your company, hasn't really gotten that much easier, right? Where do you deploy this? Where are you going to run this app? How do you ensure it's secure, right? How are people going to You want to I'll have your internal employees authenticate to it, but you don't want it to be publicly available. And so, you know, for a less technical person, for a non-engineer, they're going to struggle with, you know, do I put it on Vercel?

嗯，我没有 Vercel 或 Cloudflare 账号，因为我不是工程师。他们可能也不清楚该怎么做。即使是熟悉这些工具的工程师，也并不想每次都从头到尾把这一套流程再走一遍。而且，如果你要在内部部署这些东西，就希望它们本身就集成了身份验证和安全机制。你肯定不希望有人随便把 API 密钥发给别人，最后可能还被提交到代码库之类的地方。那么该怎么办呢？结果就是，你得耗费大量工程时间去说：“嘿，这事很重要。我们得把它改造成一个正经的应用部署。”Well, I don't have access to a Vercel account or a Cloudflare account because I'm not an engineer. They might not know the details of how to do that. Even for engineers who know how these tools work, they don't really want to have to go through this and do it from scratch every single time. And then if you're deploying these things internally, you want them to have auth and security baked in. You don't want people just, you know, shipping API keys to stuff that might get like checked into code bases or stuff like that. And so what do you do? You end up burning a bunch of engineering time to say, "Hey, this is important. We need to go convert this to be some proper app deployment."

我们的需求：构建并分享What we needed: build and share

所以，WorkOS 需要的其实是两件事。第一，让公司里的每个人都能构建并发布应用。他们不应该需要去找基础设施团队申请资源，也不应该需要为标准应用获得安全审批。他们只需要把东西构建出来并提供给大家使用。第二，我们想要一种分发方式，对吧？我们希望他们一发布应用，就能把链接发给其他人。对方可以点击 Slack 里的链接，打开应用并访问它，不会遇到任何警告或繁文缛节。所以，我们想要快速行动、快速构建。WorkOS 有一支应用 AI 团队，他们唯一的职责就是思考：怎样才能让 AI 在公司里越来越有用？不只是想办法推进软件开发流程、让工程师善用 AI，而是要让每个人都能善用 AI。So the thing we needed at WorkOS was kind of two things. One, the capability for everyone at the company to build a build and ship an application. They shouldn't need to go ask infra for provisioning. They shouldn't need to get like security approval for standard apps. They should just build a build the thing and make it available. And two, we want a distribution. Right? We want As soon as they ship it, they can link someone else to it. That person can click the link and slack, open it up, and access the application without any red flags or any kind of red tape. And so, we want to move fast. We want to build quickly. We have this applied AI team at WorkOS who's their kind of singular job is, how do we make AI more and more useful across the company? Not just, you know, how do we move the software development process along, make engineers useful with AI, but how do we make everyone useful with AI?

开发嘛，你知道，开发成本很低，对吧？我们可以做出一个东西，没问题。但我们怎么知道它有没有用？我们需要收集相关反馈。结果发现，我们基本上已经有了……Building, you know, building is cheap, right? We can build a thing, no problem. But how do we know it works? We need to get the feedback around it. Turns out we basically had

Claude 时代：非工程师也能编写代码Claude days: non-engineers at the keyboard

一种收集反馈的推动机制，也就是我们开始举办全公司的 Cloud Days。基本上，这是一个为期一天的黑客马拉松，大家两两组队，开发一款应用。通常我们会让非工程师和工程师搭档。实际上，我们会让非工程师来动手开发。他们才是真正敲键盘、构建应用的人。呃，与他们搭档的工程师则在一旁提供建议，帮他们解决遇到的问题，让他们不会卡住；也会充当一个可以一起讨论想法的对象，帮他们琢磨该如何着手。不过，我们有很多市场和销售团队的同事，他们对应用有各种很棒的想法，只是一直以来可能都很难把这些想法变成现实。a sort of a forcing function to gather feedback, which is we'd start doing these company-wide Cloud Days. Basically, it's a single-day hackathon where everyone pairs up into teams and builds an app. And typically, when we do this, we actually pair non-engineers with engineers. And we actually have the non-engineers do the building. They're the ones that have our hands on keyboard. They're the ones building the application. Uh while the engineer that's paired with them is there to consult, help them, you know, unblock them with any issues they find so they don't get stuck, kind of be a sounding board for, you know, how they can approach this. But we have a ton of our, you know, marketing folks and sales folks that have all these really great ideas of apps that, you know, they've maybe struggled to bring to life.

所以，我们构建了两样东西。第一样是一个 CLI。So, we built two things. The first thing is we built a CLI.

WOW 命令行界面The WOW CLI

我们把它叫作 Wow。Wow 能帮助你构建和生成应用，无需了解任何底层细节。它基本上是一套工具包，可以帮你设置 Git、创建代码仓库、克隆一个示例应用，让你以此为起点，使用 Cloud Coder Codex 构建想要的应用。我们通过公司的 MDM 将它分发给每一位员工，直接推送到你的电脑上。因此，每位员工从入职第一天起就能使用这个工具。Well CLI 可以让你运行 `wow app create` 之类的命令。它会让你为应用命名，然后扫描你的电脑并询问：“好，你安装 Git 了吗？登录 GitHub 了吗？安装 Doppler 了吗？它是你的密钥管理工具。”它会为你的开发电脑完成这些预配置，无论你是不是工程师，让一切都准备就绪，这样你就不会在过程中遇到任何阻碍。We call it wow. Wow is the thing that helps you build and generate an app without needing to know any of the underlying details. It basically is a toolkit that helps you set up Git, set up a repo, clone in an example application that you can use to start with for Cloud Coder Codex uh to build the app you want to build. And we distribute it to every single employee at the company through our MDM. We just push it on your machine. So, every employee day one has access to this tool. The Well CLI lets you run things like wow app create. What it does is that you name the app, it scans your machine and says, "Okay, do you have get installed? Do you have you logged into GitHub? Do you have Doppler which is your secrets management?" Kind of does all this pre-configuration of your developer machine whether you're an engineer or not so that everything is kind of ready to go and you're not going to hit any snags along the way.

共享技能仓库A shared skills repository

我们还搭建了一个共享技能仓库。也就是说，公司里的任何人只要开发了有用的技能，都可以把它上传到仓库，与所有人共享。这样大家就能轻松查看有哪些技能可用，并把技能拉取下来，帮助自己构建东西或执行特定工作流。We also built a shared skills repository. So, anyone at the company can if they built a skill that's useful, they can push that skill up and it's shared to everyone and then it's easy to fetch those skills, see what's available, and pull skills down to help you build things or or do certain workflows.

演示：一条命令启动应用Demo: one command to a running app

所以，我来快速演示一下，大致给你们看看它是什么样的。嗯，我现在在这个文件夹里，想创建一个应用。就叫 AIE demo 吧。然后，它基本上会走完这一整套流程。我显然已经配置好了这台机器，这不是我第一次这么做了。它会检查我是否安装了 get、Node 和 GitHub、Doppler，是否已登录，以及其他所有内容。实际上，它会在我们的企业版 GitHub 账号中创建一个仓库，并使用我们预先定义好的一个模板。所以，起步时基本上就是一个空白的 Node.js 应用。嗯，它会完成这些操作，把所有内容推送上去并运行起来。然后，我们就会得到一个可以在内部或本地运行的东西。它会执行一个简单的部署步骤，然后我们就能在 localhost 上访问它，我可以在这里打开看看。So, I'm going to do a quick demo to kind of show you a little bit of what this looks like. Um So, here I'm in this folder and I want to create an app. Let's do AIE demo. And so, it basically runs through this whole flu- flow. I've already obviously configured my machine. It's not the first time I'm doing this. So, it checks I have get, I have node, GitHub, Doppler, I'm signed in, everything. And what it does actually creates a repo in our enterprise GitHub account. Uh uses a kind of a template that we already have defined. So, it starts out with basically a kind of blank Node.js app. Um so, it does that, pushes everything, runs it, and then, you know, now we get some something that I can run internally or locally. It does a little uh deploy step and then we get something available at localhost that I can pull up here.

我们还有这个内部应用示例。如果还不明显的话，我们是在 Cloudflare 上运行这个应用，嗯，因为它能让我们非常轻松地快速部署一个 Node 应用。所以，这很棒。只需一条命令，我现在就让这个应用跑起来了。从那之后，你知道，我只要打开 Claude，说：“嘿，我在为 AIE 做演示。我们可以在这个应用里加点什么有意思的东西？”所以，我就让它运行起来吧。我也不知道，看看它会做出什么来。嗯，这算是 Claude 一贯的风格，不过我想带大家过一下其中的几个部分。And we have this internal app example. If it's not obvious, we're running this on Cloudflare, um because it makes it really easy to quickly deploy um a node app. So, this is great. Single command, I now have this app running. And then from that point on, you know, I can just, you know, pop into Claude and say, "Hey, I'm doing a demo for AIE. What can we put in this app that would be cool?" So, I'm going to let this go off. I don't know, we're going to see what it does. Um this is sort of just Claude being Claude, but um I want to walk through like a few parts

注册表中有 278 个应用程序278 apps in the registry

关于我们构建的内容，下面举几个例子。我们有一个内部注册表。每当你使用 Wow 推送一个应用时，我们都会将它记录到内部注册表中。可以看到，目前已有 278 个应用被推送，其中 21 个今天完成了部署。在过去一周里，这些应用总共处理了 330 万个请求。所以，这些不只是一些小型仪表盘工具，它们还包括 API、Slack 机器人，以及我们自己创建并在内部使用的各种工具。另外，其中 60 个使用了自定义域名，也就是拥有自己的品牌域名。of uh what we built in some examples of the things we built. So, we have this uh internal registry. So, anytime you push an app with Wow, uh we actually log it into the internal registry. So, you can see we have 278 apps that have been pushed, uh 21 that were had a deployment done today. Uh over the last week, we've had 3.3 million requests go through these applications. So, these aren't just uh little dashboard tools, they're also APIs, Slack bots, and things that we created and use internally ourselves. Um and then 60 of these are on sort of custom domains, so they have their own uh like branded um domain name.

示例应用Example apps

我们做出来的东西有几个例子。比如，呃，我们产品营销团队的 Connor 会发送每月通讯，内容大概是：“嘿，Work OS 最近有什么新动态？”呃，这事儿有点麻烦：我们得把已有的更新整理成一种格式，然后还得分别排版，发到 Slack 和邮件里，嗯，挺烦人的。A couple examples of things we built is um Connor on our product marketing team, we send these monthly newsletters that are like, "Hey, what's the latest in Work OS?" Uh it's kind of a pain, we have to take updates that we have, put them into a format, and then we need to format them to send it both Slack and over email, um which is pretty annoying.

所有需要通过公司登录访问的应用Every app behind company login

所以，我们搭建了这个，呃，我想是我的身份验证系统。那这些应用是这样受到保护的：我必须用我的 Okta 账户登录才能访问它们。所以，如果你访问其中任何一个网址，就会发现自己无法进入。它基本上会汇总我们所有的更新日志。你可以整理这些内容，也可以设计 Slack 消息的样式。所以，这是一个集中设计整个体验的地方。我搭建的东西是这样的：我们有一个更新日志，Changelog.workable.com/changelog 是我们发布所有更新的地方。我们通过 Webflow 来完成这项工作，它是一个 CMS 平台。实际上，进去设计更新日志文章并完成这一系列操作，过程相当痛苦。所以我开发了一个工具，让我们公司里的任何人都能起草这些更新日志。And so, we built this uh I think my auth. So, here's how these apps are protected, right? I have to log in with my Okta account in order to access them. So, if you go to uh any of these URLs, you'll see uh you won't be able to get to them. So, here it basically pulls in all of our change logs. You can curate that. You can design what the Slack message is going to look like. And so, it's a kind of singular place to design this experience. I think that I built is we have a change log. Changelog.workable.com/changelog is where we post all our updates. And we do this through Webflow, which is like a CMS platform. It's pretty It's pretty painful to actually like go in, design the change log post, and do all of this stuff. And so, I built a tool that basically allows anyone at our company to draft these change logs.

这样，任何人都可以进来。哦，我得刷新一下我的身份验证。好了。呃，任何人都可以进来，起草这些变更日志，然后它们会发布到 Slack 上，这样我就能知道：“嘿，有人起草了一份新的变更日志，我可以审核一下。”等准备好了，我就可以发布它，然后让它正式上线。所以，这就是我们能够构建的这类工具。基本上，现在公司里的任何人都可以自行启动 Cloud Code，构建自己想要的应用，并将其部署上线，让全公司都能使用。我就让它在后台运行吧。我们不用看它做什么。嗯，不过，是的。这就是大致的想法。现在公司里有很多人在构建这类工具。呃，没有什么会阻碍他们。他们不必请求：“嘿，有人能帮忙部署一下吗？”And so, someone can come in. Ooh. I got to refresh my auth. There we go. Uh anyone can come in, kind of draft these change logs, and then it posts into Slack, so I can know, "Hey, there's a new change log someone's drafted up. I can review it." And then when it's ready, I can post it and then post it live. So, this is what it the kind of tools that we're able to build. Basically, anyone at our company can now self, you know, spin up Cloud Code, build the app that they want, and deploy it live, make it available to the entire company. I'm going to I'm going to let that just sit in the background. We don't need to see what that does. Um but yeah. So, that's that's the kind of idea. Now we have uh tons of people at the company building these tools. Uh nothing gets in the way. They don't have to ask for, "Hey, can someone deploy this?

“嘿，有人能帮我开通个账户吗？”呃，公司里的每个人默认都可以使用这个工具。所以，我想稍微谈一谈……Hey, can someone provision some account for me?" Uh everyone by default in the company can use this tool. So, I want to talk a little bit about

Atlas：底层平台Atlas: the platform underneath

Atlas 是底层实际支撑这个工具的平台。Wow 只是人们用来与它交互的命令行界面，而 Atlas 才是底层基础设施。基本上，Atlas 让你能够创建、构建、部署和分享这些应用。Atlas, which is the actual platform underneath this that uh powers this this this tool. Wow is just sort of the CLI that people use to interface with it, but Atlas is actually the underlying infrastructure. Basically, Atlas allows you to create, build, deploy, and share these applications.

三项原则Three principles

构建 Atlas 时，我们大致遵循三项原则，希望把它们贯彻下去，并为用户带来出色的体验。第一，我们希望基础设施是无形的。没人应该需要知道部署目标在哪里。我们目前恰好运行在 Cloudflare Workers 上。如果哪天我们想改用 Vercel 或 AWS，也不应该造成影响。对于任何想要构建和部署这些应用的人来说，这一切都应该是透明的。第二，我们希望默认就具备安全性，对吧？我们不想冒这个险——我没法把我们构建的所有应用都展示给你看。有些应用涉及大量个人身份信息（PII），是我们使用的客户工具和销售工具。因此，我们不希望公司外的任何人都能访问这些工具，因为它们非常敏感。最后一点是发现能力的可发现性。There's sort of three principles when we're building Atlas that we wanted to maintain and and that provided a great experience. One was we wanted the infra to be invisible. No one should need to know where the deployment target is. It happens to be that we're running on Cloudflare Workers. If at some point we want to change that to Vercel or AWS, it shouldn't matter. Should be transparent to anyone trying to build and deploy these applications. Wanted to be secure by default, right? We don't want to risk there's I can't show you all of the apps that we built. Some of them have a lot of PII, they're customer tools, sales tools that we use. So we don't want anyone just to be able to access these tools outside the company because they're very sensitive. And then last is the discovery of discoverability.

有人在 Slack 中分享了链接，任何人都应该能够点击它。Someone shares a link in Slack, anyone should be able to click

在 Cloudflare 上运行Running on Cloudflare

这样就能查看那个工具了。如今，Ilist 运行在 Cloudflare 的开发者平台上。每个应用在执行那个 wild create 步骤时，都会提供计算能力、存储空间，比如 D1 数据库、KV 键值，以及你需要的各种组件。所以你不必再问：“哦，如果我需要存储持久化数据，能做到吗？”这已经包含在套餐里了。我们还会在你把这些工具推送到 workos.tools 后，自动为它们提供托管服务。我们有一个共享域名，无论你的应用叫什么，它都会获得一个位于 workos.tools 下的主机名。因此，你不必操心应用会在哪里上线、如何上线，或者人们能否访问它。that and be able to view that tool. So today Ilist runs on Cloudflare's developer platform. Every app, when you run that wild create step, provides compute, storage, uh with D1 databases, KV values, all the bits and pieces you need. So you don't have to ask like, "Oh, well, if I need to like store persistent data, am I going to be able to do that?" It's It's already part of the package. Um and we automatically host all of these tools when you push them under workos.tools. So we have this shared domain that whatever your app is called, you get that host name underneath workos.tools. So you don't have to worry about where is the app going to be available, how does it get, you know, do people get access?

默认安全：单点登录、日志、密钥Secure by default: SSO, logs, secrets

默认安全。因此，所有这些应用都会自动受到我们的 Octa SSO 账户保护。如果没有我们的 Octa 账户访问权限，就无法登录。我们还针对 API 和 Slack 机器人构建了一种方案，用来弥补基于令牌的身份验证方面的不足。如果你有这方面的需求，可以配置启用它，从而获得我们正在使用的某些工具的 API 访问权限。所有请求都会被记录并可供审计，因此我们能查看所有流量的日志。如果我们怀疑发生了泄漏或安全问题，就可以追查并检测具体情况。所有密钥也都会安全存储；如果你需要访问任何内部工具或第三方工具的 API，相关密钥都会得到妥善保管。我们在这里使用的是 Doppler。Secure by default. So all of these apps are automatically protected by our Octa SSO account. So you can't log in if you don't have access to our Octa account. We've actually built for APIs and Slack bots. We built a way to actually plug holes for a token-based authentication. And so if that's something you need, you can build out uh you can kind of enable that and then get API access for some of these tools that we're using. All the requests are logged and auditable. So we have logs of all the traffic that's happening. So if we think there was some sort of leak or um security issue, like we can go and detect what happened. And then all the secrets, so if you need API access to any of our tools, internal tools, or third-party tools, that's all stored securely. Uh we use Doppler in this case.

这样一来，你基本上不需要管理密钥，也不用担心自己是不是把密钥推送到了 Git 仓库里，导致现在出了问题。这一切都是安全处理的。最后，我们还有用于发现应用的目录。每个应用都可以被发现。嗯，不需要分享。你不需要——我们不需要支持分享，因为默认情况下你就有访问权限。所以，到目前为止，我给你看过那个目录页面，里面有几百个应用。显然，并不是每个应用都特别重要、都能真正投入使用，但大约有 60 个应用已经部署、维护，或者一直有人在用。所以，这不只是人们做出来的两款实用工具，而是逐渐成为了一种维护事物的方式。实际上，有人还做了一个工具，你可以上传任意 HTML 文件，它就会生成一个可分享的链接。And so you don't really have to do secrets management. You don't have to worry about did I, you know, push a secret into the Git repo that's now, you know, a problem. It's all done securely. And then last, we have the catalog for discovery. Every app's discoverable. Um no need to share. You don't We don't need to have sharing support because you by default have access. So, I think so far, you know, I showed you that catalog page which had a few hundred apps. Obviously, not every single app is super important and sees the light of day, but we have about 60 apps that are been deployed, maintained, or getting used on a regular basis. So, this isn't just like two tools people built that are useful. It's actually becoming um a way in which things are being maintained. We actually had someone build a tool where you take any arbitrary HTML, upload it, and it gives you a shared link.

所以，它基本上就像一个小型托管平台，可以托管模型、图表之类的内容，而且很容易分享。我们看到所有这些应用每周的请求量超过 300 万次。这其中一部分是用户流量，但还有一部分来自我们的工具之一 Wallaby。它是一个销售工具，我们还为它构建了 API，让我们能够在其他系统（比如 Slack）中访问这些数据。所以，访问这些数据的不只是人，还有机器和智能体。我们已经彻底消除了部署应用时需要求助他人的情况，因为现在再也没有任何障碍了。我觉得最重要的指标是，我们的目标是让非工程师也能构建和部署应用。在我们的应用中，在这 60 个应用里，So, it's basically like a mini hoster of like mocks or diagrams or things that you can easily share. We're seeing over 3 million requests a week run run through all of these apps. Um this is partially users using traffic, but it's also um one of our tools, Wallaby, is like a sales tool, and we actually built an APIs for that that allows us to access that data in other systems, in Slack. And so, it's not just humans accessing this data, it's machines and agents as well. We've completely eliminated the need for uh asking for help in deploying applications because nothing stops anyone anymore. And I think like the most important metric is, you know, our our goal was enable non-engineers to build and deploy apps. And out of our apps, out of these 60 apps,

结果：37% 的项目是在没有工程师参与的情况下构建的Results: 37% built without engineers

其中 37% 的工具在所有提交中都没有工程师参与构建。也就是说，它们完全是由那个人和 Claude 一起构建的，没有工程团队参与。这可以说是真正成功的标志：我们确实消除了这样的需求：“嘿，能不能请某位工程师迁移这个工具？能不能代表市场或销售团队来管理这个工具？”所以，我们还想在这方面做更多。这只是初始版本。我们希望……37% of them have been built without any engineers in any of the commits. So, they're totally built between that person and Claude without engineering involvement. And that's sort of the marker of like a true success here that we've actually eliminated the need for, "Hey, you know, some engineer, can you migrate this tool? Can you manage this tool on behalf of, you know, marketing or sales?" So, So, more that we want to do here. This is sort of initial version. We want

接下来呢？What's next

添加细粒度的关闭选项。显然，并不是每个应用都应该默认向公司里的所有人开放。有些情况下会涉及敏感数据。因此，我们想要添加……我们已经知道用户是谁，因为他们登录应用时就会进行身份验证。所以，我们希望轻松支持为这些应用设置类似基于群组、基于角色的权限。我们还想添加更多数据集成。比如，我们已经在 Wow 和 Atlas 中具备了这种能力：如果我需要访问 Snowflake 数据，就不必去考虑 API 密钥，只要说“我想添加 Snowflake”，应用就会正确地管理 Snowflake 访问权限。我们正在构建的另一项功能是 Slack 集成。这些工具中有很多都很棒，但你肯定希望它们能在 Slack 中使用，这样任何人只要 @ 提及这个工具，就能获得问题的答案、从中受益，或者实际推动某个工作流程。to add granular off. Not every app should necessarily be opened by default to everyone in the company, obviously. There's some sensitive data in some cases. So, we want to add We already know who the user is when they're logging into the app. So, we want to support doing kind of like group-based, role-based permissions for these apps easily. We want to add more data integrations. So, we kind of already have this capability aspect to to Wow and to Atlas where if I need access to our Snowflake data, for example, I don't need to go kind of think about API keys. I can just say, "I want to add Snowflake." And now the app has correctly maintained Snowflake access. And then the other thing that we've we're building out is Slack integration. So, a lot of these tools are great, but you really want them to be available inside Slack so that someone can just at the tool and get, you know, answer a question, get use out of it, or actually drive a workflow.

因此，我们正在构建内置的 Slack 集成功能。这样一来，用户部署应用时，也可以自动安装 Slack 应用。And so, we're building included Slack integration. So, if someone deploys an app, they can also get the Slack app automatically installed.

总结Wrap-up

所以，对我们来说，我们正在亲身经历内部应用开发领域的一场变革。我们曾使用其他平台来构建某些工具，但一直觉得它们非常繁琐。基本上，这些平台仍然需要工程师来开发和维护，也在一定程度上限制了我们能够构建的工具。对我们来说，AI 解决了构建难题，但要让它成为团队普遍使用的平台，我们还需要更多支持。Atlas 提供了这些能力，让公司里的任何人都能交付内部应用。如果你也想让自己的公司具备这样的能力，我很乐意和你聊聊。谢谢。So, for us, we're kind of experiencing ourselves a revolution in internal app development. We've used other platforms to build certain tools. We've always found them very cumbersome. They basically still took engineers to build and maintain, and it sort of limited the tools that we could build. For us, AI solved the build problem, but we needed more in order to make this a ubiquitous platform for our our our team. Atlas provides these capabilities to enable anyone in our company to ship internal apps. And if you're interested in having this kind of capability at your company, I'd love to talk to you about it. Thank you.