IDE 不会消失
4 分•作者: williamzeng0•5 个月前
不知为何，这似乎是个逆向观点，但调试器、代码导航和自动补全仍然很重要。开发者不会被取代。
开始一家代码生成公司
我和 Kevin 两年前创办了 Sweep。
2023 年，GitHub Copilot 是行业现状。
我们看到了它，并认为“这并非软件开发的最终形态”。
“我们在日常工作中做什么？” 我们几乎所有的时间都花在编辑现有代码上。
我们在 4 天内构建了 GitHub 代理的 MVP，并申请了 YC。
通过 YC
在我们的第一次办公时间里，我们试图清楚地描述我们正在构建的东西。“AI 开发者”。Sweep 将获取 GitHub 问题或 Jira 票据，并使用 LLM 生成解决方案。然后开发者就可以审查它。
我们继续前进——我们还开源了它。
这真的很有趣！我们建立了一个很棒的社区。每天有数百名用户，一个月内有 5000 个 GitHub 星标，以及超过 1000 名 Discord 用户。
尝试交付一个编码代理
我们努力让代理工作。我们整天都在与 gpt-4-32k 战斗，然后与 claude opus 3 战斗，然后与 sonnet 3.5 战斗。
我们听到的最大反馈是“我自己做这件事更快。这对于任何非平凡的事情都无效。”
即使我们不断改进，也感觉我们无法实现飞跃。
我们试图尽可能多地掌握主动权。
我们的心态是“好吧，模型很糟糕，但我们有很多方法可以解决这个问题”。
我们不断推进并尝试新的模型和技术（后续文章），但在 2024 年，几乎所有用户都转移到了 Cursor。我们陷入了困境。
我们如何让代理工作？
在编码代理的主要用例中，今天运行良好的有：
- 终端代理（Claude Code）
- IDE 侧边栏（Cursor，Windsurf）
注意到规律了吗？这些完全存在于 IDE 或开发环境中。
有三个因素相互影响。
1. 允许代理执行代码对于大型代码库来说极其复杂或不可行。
2. 这导致代理编码循环在手动测试/用户反馈方面出现瓶颈。
3. 随着代码库规模的增长，代理无法将整个代码库保存在上下文中。
这意味着对于大多数代码库，代理仍然需要在 5 到 10 分钟的间隔内进行监督。
即使有了代理，开发者编写代码的自然场所仍然是 IDE。
转型
我们决定从我们的独立代理转型。很多人都很惊讶。
我记得去参加一个开发者聚会，并告诉一位创始人，“嘿——我们转型为 IDE 编码助手”。
他给了我一个怀疑的眼神——“为 VSCode 吗？”。当时有太多的 VSCode 分支。
“不，为 JetBrains！”
他问，“Codeium 难道没有类似的东西吗？”
我已经试过了。“它远远落后于他们的 VSCode 分支。”
我们开始 Sweep 的目标是使用 AI 自动化简单的 GitHub 问题。这个使命变成了“帮助开发者节省时间”。
构建人们喜欢使用的东西并为他们节省时间对我们来说比我们实现目标的方式更重要。
我们与数百名 JetBrains 开发者进行了交谈，他们一直说“JetBrains 中的 AI 很糟糕”。
Cursor 已经做得很好。在 VSCode 中使用 AI 是无缝的。但这并没有什么神奇之处。他们一直在迭代以找到最佳的用户体验。
以前支持 JetBrains 的工具，如 Windsurf 和 Copilot，只是构建了一个插件来抢占市场份额。这让他们能够将自己定位为“满足您所有 AI 需求的公司”。
他们没有在 JetBrains 方面交付成果。
他们的用户一直在努力解决高 CPU 使用率、缺少功能，甚至过时的模型。
所以我们决定竞争。
在过去的几个月里，我们构建了一个代理，训练了一个自动补全模型，并修复了大量错误。我们将使 JetBrains IDE + Sweep AI 成为最佳的开发方式。
如果您是希望在不离开您最喜欢的编辑器的情况下使用 AI 的 JetBrains 开发者，我们很乐意听取您的反馈！
查看原文
Somehow this is a contrarian opinion, but debuggers, code navigation, and autocomplete still matter. Developers are not being replaced.<p>Starting a codegen company<p>Kevin and I started Sweep two years ago.<p>In 2023 GitHub Copilot was the status quo.<p>We saw it and thought “this is not the final state of software development”.<p>"What do we do at our day jobs?" Almost all of our time was spent editing existing code.<p>We built the MVP of our GitHub agent in 4 days and applied to YC.<p>Going through YC<p>During our first office hour, we tried to clearly describe what we're building. "AI developer". Sweep will take GitHub issues or Jira tickets, and use LLMs to generate a solution. Then the developer can just review it.<p>We pushed forward - we open sourced it as well.<p>It was really fun! We built an awesome community. Hundreds of users per day, 5k github stars in a month, and over 1000 discord users.<p>Trying to deliver a coding agent<p>We pushed hard on getting agents to work. We spent our days fighting gpt-4-32k, then fighting claude opus 3, then fighting sonnet 3.5.<p>The biggest feedback we heard was "it's faster for me to do this myself. this doesn't work for anything non-trivial."<p>Even as we continued improving it felt like we couldn't make the leap.<p>We tried to take as much agency as we could.<p>Our mentality was "Ok the models suck, but we have so many ways around that".<p>We kept pushing and trying new models and techniques (future post) but throughout 2024, almost all of our users moved to Cursor. We were stuck.<p>How do we make agents work?<p>Of the major use cases of agents in coding, the ones that work well today are:<p>- Terminal agents (Claude Code)
- IDE sidebars (Cursor, Windsurf)<p>Notice the pattern? These exist fully within the IDE or development environment.<p>There are three factors that play into each other.<p>1. Allowing agents to execute code is extremely complex or infeasible for large codebases.
2. This causes agentic coding loops to be bottlenecked on manual testing / user feedback.
3. As codebases grow in size, agents can't hold the entire codebase in context.<p>This means that for most codebases, agents still need supervision in 5 to 10 minute intervals.<p>Even with agents the natural place for developers to write code is still the IDE.<p>Pivot<p>We decided to pivot from our standalone agent. A lot of people were surprised.<p>I remember going to a developer meetup and telling a founder, "hey - we pivoted to an IDE coding assistant".<p>He gave me a doubtful look - "for VSCode?". There were too many VSCode forks at this time.<p>"No, for JetBrains!".<p>He asked, "doesn't Codeium have something already?"<p>I had already tried it. "It's way behind their VSCode fork."<p>We started Sweep with the goal of automating simple GitHub issues with AI. That mission became "help developers save time".<p>Building something people love using and saving them time is way more important to us than the way we get there.<p>We talked to hundreds of JetBrains developers, and they kept saying "the AI in JetBrains sucks."<p>Cursor had done a great job. Using AI in VSCode was seamless. But this wasn't anything magical. They had continuously iterated to find the best UX.<p>The previous tools that supported JetBrains, like Windsurf and Copilot, had just built a plugin to capture market share. It allowed them to position themselves as "one company for all of your AI needs."<p>They did not deliver on the JetBrains side.<p>Their users were constantly struggling with high CPU usage, missing features, and even outdated models.<p>So we decided to compete.<p>Over the last months, we've built an agent, trained an autocomplete model, and fixed A LOT of bugs. We're going to make JetBrains IDEs + Sweep AI the best way to develop.<p>If you're a JetBrains dev that wants to use AI without leaving your favorite editor, we'd love your feedback!