集成开发环境（IDE）不会消失。
这似乎是一个逆向的观点，但调试工具、代码导航和自动补全仍然很重要。开发者并没有被取代。
<p>创办代码生成公司</p>
Kevin 和我两年前创办了 Sweep。
<p>在2023年，GitHub Copilot 是现状。</p>
我们看到这一点，心想“这并不是软件开发的最终状态”。
<p>“我们在日常工作中做什么？”</p>
我们几乎所有的时间都花在编辑现有代码上。
<p>我们在四天内构建了 GitHub 代理的最小可行产品（MVP），并申请了 YC。</p>
<p>经历 YC</p>
在我们的第一次办公时间里，我们试图清晰地描述我们正在构建的内容。“AI 开发者”。Sweep 将处理 GitHub 问题或 Jira 工单，并利用大型语言模型（LLMs）生成解决方案。然后开发者只需进行审核。
<p>我们不断推进 - 我们也将其开源了。</p>
这真的很有趣！我们建立了一个出色的社区。每天有数百名用户，一个月内获得了5000个 GitHub 星标，以及超过1000名 Discord 用户。
<p>努力交付编码代理</p>
我们全力以赴让代理工作。我们每天都在与 gpt-4-32k 斗争，然后与 claude opus 3 斗争，再然后与 sonnet 3.5 斗争。
<p>我们听到的最大反馈是“我自己做这个更快。这对任何非平凡的事情都不管用。”</p>
即使我们不断改进，感觉仍然无法跨越那道鸿沟。
<p>我们尽量掌握尽可能多的主动权。</p>
我们的心态是“好吧，模型很糟糕，但我们有很多解决办法”。
<p>我们不断尝试新模型和新技术（未来的文章），但在2024年，几乎所有用户都转向了 Cursor。我们陷入了困境。</p>
<p>我们如何让代理工作？</p>
在编码中，代理的主要用例中，目前有效的有：
<p>- 终端代理（Claude Code）</p>
<p>- IDE 侧边栏（Cursor, Windsurf）</p>
<p>注意到这个模式了吗？这些完全存在于 IDE 或开发环境中。</p>
有三个因素相互影响。
1. 允许代理执行代码对于大型代码库来说极其复杂或不可行。
2. 这导致代理编码循环在手动测试/用户反馈上受到瓶颈。
3. 随着代码库的增长，代理无法在上下文中保持整个代码库。
<p>这意味着对于大多数代码库，代理仍然需要在5到10分钟的间隔内进行监督。</p>
即使有代理，开发者编写代码的自然场所仍然是 IDE。
<p>转型</p>
我们决定从独立代理转型。很多人对此感到惊讶。
我记得去参加一个开发者聚会时告诉一位创始人，“嘿 - 我们转型为一个 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!