为什么我停止使用 AI 代码编辑器[转发]

2025年 4月 7日 67点热度 1人点赞 0条评论

原文翻译

TL;DR：我选择将 AI 的使用作为手动作，因为当我依赖 AI 时，我感觉到随着时间的推移，能力会慢慢丧失，我建议每个人都谨慎行事，将 AI 作为他们工作流程的关键部分。

2022 年底，我第一次使用了 AI 工具，甚至在 ChatGPT 的第一个版本之前。2023 年，我开始在我的开发工作流程中使用基于 AI 的工具。最初，这些 LLM 的功能给我留下了深刻的印象。事实上，我可以将晦涩难懂的编译器错误与 C++ 源代码一起复制和粘贴，并被告知错误的原因，这感觉就像魔术一样。

当 GitHub Copilot 开始变得越来越强大时，我开始越来越多地使用它。我直接在我的编辑器中使用了各种其他 LLM 集成。使用 AI 是我工作流程的一部分。

在 2024 年底，我从我的代码编辑器中删除了所有 LLM 集成。我仍然偶尔使用 LLM，我确实认为 AI 的使用方式对许多程序员非常有益。那么，我为什么不使用 AI 驱动的代码编辑工具呢？

特斯拉 FSD

从 2019 年到 2021 年，我开着一辆特斯拉。虽然我再也不会购买同样的东西了，不是出于政治原因，只是因为这些车的质量很低，价格非常高，维修或保养起来很麻烦。

当我拿到特斯拉后，我就开始尽可能地使用全自动驾驶（FSD）。在高速公路上将汽车放在 FSD 上并稍微放松一下感觉很棒。换道就像按下转向灯一样简单，汽车就会换道。对我来说，开车就是刚到高速公路，打开 FSD，告诉汽车时不时地换道，并在分区时听音乐/播客。

如果您经常开车，您就会知道当您在高速公路上行驶时，一切都是自动发生的。让你的车以正确的速度在车道上成为一个被动的动作，它不需要例如读书所需的那种专注力，而是走路需要的那种专注力，它发生在你的脑海背景中。

在 2019 年至 2021 年期间，我专门驾驶我的特斯拉进行了更长时间的骑行。2021 年之后，我又回到了驾驶普通汽车，做出这种转变绝对不是我所期望的。在第一个月左右，在高速公路上开车需要我全神贯注，我不得不不假思索地重新学习将汽车保持在车道中间。

依赖特斯拉的 FSD 剥夺了我自己进入自动驾驶仪的能力。

我对 AI 代码编辑器的体验

使用 AI 驱动的代码编辑器有点相似。最初，我觉得在 AI 的协助下，我完成工作的速度要快得多。我大部分时间所做的工作并不是特别复杂，AI 感觉就像把我的特斯拉放在 FSD 上，我可以引导机器为我做工作。

在空闲时间，我开始在工作设备上的个人帐户上从事一个业余项目。因此，我无法访问 Copilot 和其他很酷、很花哨的 AI 工具。就在这时，使用 AI 开始感觉与我的特斯拉 FSD 故事非常相似。

与一年前相比，我感觉自己在做相当基本的软件开发方面的能力更差。突然之间，它让我非常清楚地意识到我对 AI 工具的依赖程度。每当我定义一个函数时，我都会在编辑器中暂停，等待 AI 工具为我编写实现。我花了一些精力来记住手动编写单元测试的语法是什么。

随着时间的推移，AI 也开始变得不那么有用。这不仅让我失去了乐趣，而且我开始对自己做出一些实施决定感到有点不安全。将决策外包给 AI 似乎要容易得多。但有时，即使有最好的提示，AI 也无法弄清楚事情。很明显，由于我不经常练习基础知识，所以我对更难的部分的能力也较差。

Fingerspitzengefühl 的损失

Fingerspitzengefühl [ˈfɪŋɐˌʃpɪtsənɡəˌfyːl] 是一个德语术语，字面意思是 “指尖感觉” ，意思是直觉的天赋或本能，已被英语用作外来词。它描述了一种很好的态势感知能力，以及最适当和机智地做出反应的能力。 ¹

定义资历是一件非常困难的事情。虽然在我看来，成为“高级”的很多因素都是在软技能方面，但当涉及到技术硬技能时，很大程度上归结为 Fingerspitzengefühl。您使用语言、框架或代码库的时间越长，您就越能形成这种关于正确方法的直觉。“感觉不对劲”的直觉慢慢变成了“这就是我们应该做的”的感觉。

这种发达的直觉不仅体现在建筑层面上。一个重要的组成部分在于较低级别的细节，何时使用指针（或什么类型的指针），是否使用断言还是检查，当有多个选项可用时从标准库中选择什么（尽管高级 C++ 程序员似乎仍然无法就此达成一致）。

这种直觉是我在大量依赖 AI 工具时慢慢失去的。这是来自首席开发人员的。当我看到很多关于 vibe 编码的炒作时，我不禁会想：您究竟如何期望以自己的方式将 vibe 编码提升到高级水平？当 AI 工具出现故障或变得过于昂贵时，您将从哪里获得维护和扩展 vibe 编码代码库的技能？

即使拥有更大的上下文窗口、更多的计算能力、推理模型或代理，也会有 AI 无法做的事情。当然，随着时间的推移，AI 工具将变得越来越强大。但是，当您收到一条 Slack 消息，指出“网站运行正常，但应用程序已停止生产;我在本地尝试了一下，它工作正常，在 Sentry 中也没有任何内容“，祝你好运让 AI 代理为你解决这个问题。也许可以，也许不能。当 AI 代理无法弄清楚时，您的回复是“抱歉，Cursor 不明白，明天会提示更多”吗？

没有这些工具，您也可以过

有时感觉你不得不使用 AI 或在 6 个月内失业。在这一点上，我们已经听到了 “3-6 个月后 3-6 个月 ”的故事已经两年多了。几年前，我不再相信 CEO 对“从现在起 3-6 个月后”功能的承诺。当我在 2019 年买到特斯拉时，我花了 6400 欧元购买了本应在“从现在起 3-6 个月”内推出的功能，但该功能仍然没有像 5 年前承诺的那样出现。

目前，让 AI 进行编码不太可能适用于比大学项目更大的项目。当您在企业中处理遗留系统或大型项目时，或者当您需要使用和咨询大量依赖项内部结构时（就像我使用 Unreal Engine 所做的那样），AI 工具通常无法正常工作。当你需要使用内部 DSL、工具或框架时，祝你好运，让 LLM 生成有用的输出。对于某些行业，由于多种原因，您甚至根本无法使用 AI 工具。

对于某些事情，您真的不应该依赖 AI。实施 JWT 等身份验证系统时 ^{阿拉伯数字} 签名或 RBAC ³ ，如果它是在具有 CVE 的 GitHub 代码上进行训练的，则在提示中添加“and it should be secure”并不会使其安全 ⁴ 。在安全方面，您应该是负责并完全理解这一点的人。关键系统应该由人类编写和审查，如果我们遇到一个 AI 代理编写代码，另一个 AI 代理审查自动生成的 PR，然后另一个 AI 代理部署代码的情况，我们很快就会看到安全问题的巨大激增。

我在哪里划清界限

有时我仍然使用 AI。我认为如果明智地使用，它可以是一个很棒的工具。我在集成时划清了界限。我将 AI 与我的代码编辑器完全分开。所有上下文，我都手动添加。我故意将所需的努力保持得相当高，所以这让我失去了动力。

我使用 AI 进行工作的示例包括“将结构中的这些 Go 测试转换为映射中的测试”、“将此计算转换为 SIMD”或“当内容类型为 application/zlib 时，解码正文” ⁵ 。我设置了一些自定义指令，只给我已更改的代码，并给我添加它的说明。这样，我仍然是对代码库进行更改的人。仅仅批准 Git 差异是不够的，我想自己手动添加代码，只有这样我才有信心签署它并对其负责。

AI 的另一个很好的用例是学习。我经常有一些非常不常见的问题，因为我有一些非常小众的兴趣。事实证明，使用 ECS 将网络代码添加到自定义游戏引擎中没有很多学习资源。对我来说有效的是让 AI 解释代码段，例如“解释此汇编代码”、“解释此着色器的作用”、“哪些书籍深入探讨了如何解决游戏引擎中的客户端/服务器不同步问题”。AI 有时似乎在努力解决这些问题，我得到的结果好坏参半，但结果仍然比搜索引擎好得多。我什至会在这篇文章中使用它来，尽管不是为了编写内容，而是为了检查 ⁶ 。

以这种方式使用 AI 的另一个好处是成本。没有不必要的 API 调用、手动管理的上下文和对 LLM 设置的更多控制。我使用一个桌面应用程序，其中连接了一堆不同的 LLM。在过去的 3 个月左右，我每天都在使用它，总共消耗了大约 4 美元的积分。

我确实想补充一点，对于某些事情，我更加严格。在我的个人网站上，我不想要任何 AI 生成的内容，无论是文本还是图像。出于各种原因，我个人不喜欢 AI 生成的图像或“艺术”，我认为 AI 生成的文本缺乏个性，感觉非常平淡无聊。对我来说，当某物是由人类创造时，它比由 AI 创造时更有价值。

做你喜欢的事情

还值得注意的是，除了效率和生产力之外，还有更多的事情需要考虑。这也是关于做你喜欢的事情。如果您喜欢编码，请继续自己做，即使计算机可能更擅长。

1997 年，深蓝在与当时的国际象棋世界冠军加里·卡斯帕罗夫（Garry Kasparov）的国际象棋比赛中获胜 ⁷ ，但人们仍然下棋。说到编程，我想说我编程的原因与人们仍然下棋的原因相同 ⁸ 。尽管国际象棋和软件开发非常不同，国际象棋的范围要有限得多，但我认为最好记住，有时，我们可以做一些事情来享受它们。

我对新程序员的建议

不要永远成为让 AI 完成所有工作的初级学生。如果你想成为一名程序员，就学会自己编程。保持好奇心，投入时间和精力来了解事情的真正运作方式，以及其下面的图层是如何运作的。这真的是有回报的。了解引擎盖下的一切工作原理并使用它真是太棒了，只要继续学习，不要成为一个急促的工程师（如果你甚至可以称之为工程）。相信我，有能力更有趣⁹ 。

即使 AI 可能比您更聪明，也不要盲目相信 AI 输出。不要围绕它构建整个工作流程。有时尝试几天不用它工作。您的编程能力越强，AI 就越会阻碍您进行更复杂的工作。

如果你现在学习编码，继续培养你的技能，而不是让 AI 完成所有繁重的工作，你将有能力解决 vibe 编码现在造成的混乱。我不想听起来很精英，但如果你不想学习超越 vibe 编码，也许编码不适合你。因为当 AI 变得更加强大时，所有工作都可以通过 vibe 编码完成的位置将首先被淘汰。

请记住：如果没有 AI，就无法编码。

结论

当您使用 AI 时，您是在为速度牺牲知识。有时，做出这种权衡是值得的。尽管重要的是要记住，即使是世界上最好的运动员仍然在进行基本训练是有原因的。这同样适用于软件开发：您需要练习基础知识，才能完成高级工作。你需要保持你的斧头锋利。

我们距离 AI 接管我们的工作还有很长的路要走。许多公司都在创建 FOMO ¹⁰ 作为一种销售策略，以获得更多客户，向投资者展示吸引力，获得新一轮资金，产生肯定会彻底改变一切的下一个模型。

AI 是一种工具，它本身没有好坏之分，而是你用它做什么。我确实认为它可以是一个很棒的工具，只要您的工作流程不依赖它。确保没有它你仍然可以有效地工作，确保你不会将你不完全理解的代码推送到生产环境中，也不要将 AI 视为你自己想法的替代品。保持好奇心，不断学习。

原文英文

TL;DR: I chose to make using AI a manual action, because I felt the slow loss of competence over time when I relied on it, and I recommend everyone to be cautious with making AI a key part of their workflow.

In late 2022, I used AI tools for the first time, even before the first version of ChatGPT. In 2023, I started using AI-based tools in my development workflow. Initially, I was super impressed with the capabilities of these LLMs. The fact that I could just copy and paste obscure compiler errors along with the C++ source code, and be told where the error is caused felt like magic.

Once GitHub Copilot started becoming more and more powerful, I started using it more and more. I used various other LLM integrations right in my editor. Using AI was part of my workflow.

In late 2024 I removed all LLM integrations from my code editors. I still use LLMs occasionally and I do think AI can be used in a way that is very beneficial for many programmers. So then why don’t I use AI-powered code editing tools?

Tesla FSD

From 2019 to 2021 I drove a Tesla. Though I would never make the same purchase again, not for political reasons, just because the cars are quite low quality, very overpriced and a hell to repair or maintain.

When I got my Tesla, I started using the Full Self-Driving (FSD) anytime I could. It felt great to just put the car on FSD on the highway and zone out a bit. Switching lanes was as simple as hitting the turn signal, and the car would switch lanes. Driving for me was just getting to the highway, turning on FSD, telling the car to switch lanes every now and then, and listen to music/podcasts while zoning out.

If you drive a car often, you’ll know that when you’re driving on the highway, everything sort of happens automatically. Keeping your car in the lane at the right speed becomes a passive action, it does not require the type of focus that for example reading a book requires, it’s the type of focus that walking requires, it happens in the background of your mind.

In the period from 2019 to 2021 I exclusively drove my Tesla for longer rides. After 2021, I went back to driving regular cars and making this switch was definitely not what I expected. Driving on the highway required my full attention for the first month or so, I had to re-learn keeping the car in the middle of the lane without thinking about it.

Being reliant on Tesla’s FSD took away my own ability to go into autopilot.

My experience with AI code editors

Working with AI-powered code editors was somewhat similar. Initially, I felt that I completed work a lot faster when assisted by AI. The work I was doing most of the time was not super complex, and AI felt like putting my Tesla on FSD, I could just guide the machine to do my work for me.

In my free time, I started working on a side project on my personal account on my work device. On this account, I did not have access to Copilot and my other cool, fancy AI tools. This is when using AI started to feel very similar to my Tesla FSD story.

I felt less competent at doing what was quite basic software development than a year or so before. All of a sudden, it made it very clear to me how reliant I had become on AI tools. Anytime I defined a function, I paused in my editor to wait until the AI tools would write the implementation for me. It took some effort to remember what the syntax was to write unit tests by hand.

With my work, AI started to become less useful over time as well. Not only did it take out the fun for me, but I started to feel a bit insecure about making some implementation decisions myself. Outsourcing the decisions to the AI seemed a lot easier. But sometimes, the AI couldn’t figure things out, even with the best prompts. It was quite clear that because I did not practice the basics often, I was less capable with the harder parts as well.

The loss of Fingerspitzengefühl

Fingerspitzengefühl [ˈfɪŋɐˌʃpɪtsənɡəˌfyːl] is a German term, literally meaning “finger tips feeling” and meaning intuitive flair or instinct, which has been adopted by the English language as a loanword. It describes a great situational awareness, and the ability to respond most appropriately and tactfully. ¹

Defining seniority is a very tough thing. Though in my opinion a lot of being a “senior” is in soft-skills, when it comes to the technical hard-skills, a lot comes down to Fingerspitzengefühl. The longer you work with a language, framework or codebase, the more you develop this kind of intuition of what the correct approach is. The gut feeling of “something feels off” slowly turns into a feeling of “this is what we should do”.

This developed intuition is not just on an architectural level. A big component is in the lower level details, when to use pointers (or what type of pointers), whether to use asserts or checks, what to pick from the standard library when multiple options are available (though senior C++ programmers still can’t seem to agree on this).

This intuition is what I was slowly losing when relying on AI tools a lot. And this is coming from a lead developer. When I see a lot of hype about vibe coding, I can’t help but think: how do you exactly expect to vibe code your way to senior? Where will you get the skills from to maintain and extend the vibe-coded codebase when the AI tools are down, or have become too expensive?

Even with larger context windows, more computing power, reasoning models or agents, there will be things that AI won’t be able to do. Over time, the AI tools will be more and more powerful, sure. But when you receive a Slack message that “the website works fine, but the app is down in production; I tried it locally and there it works fine, nothing in Sentry either”, good luck getting an AI agent to fix this for you. Maybe it can, maybe it can’t. And when an AI agent can’t figure it out, will your reply be “sorry, Cursor doesn’t get it, will prompt more tomorrow”?

You can get by without these tools

Sometimes it feels like you have to use AI or be out of a job in 6 months. We’ve been hearing the “3-6 months from now”-story for over two years at this point. I stopped trusting CEO promises about functionality “3-6 months from now” years ago. When I got my Tesla in 2019, I paid €6400 for functionality that was supposed to arrive in “3-6 months from now”, and the functionality is still not present the way it was promised over 5 years ago.

Right now, it is unlikely that letting AI do your coding will work for projects larger than a university project. When working on legacy systems or larger projects in enterprises or when you need to work with and consult a lot of dependency internals (like I do with Unreal Engine), AI tools will often not be able to make things work. When you need to work with internal DSLs, tools or frameworks, good luck getting LLMs to generate useful output. For some industries, you can’t even use AI tools at all for a multitude of reasons.

For some things you really should not want to rely on AI. When implementing authentication systems like JWT² signing or RBAC³, adding “and it should be secure” to the prompt won’t make it secure if it’s been trained on GitHub code that had CVEs⁴. When it comes to security, you should be the person who is responsible and understands this fully. Critical systems should be written and reviewed by humans, if we are heading to a situation where one AI agent writes the code, another reviews the autogenerated PR and then another AI agent deploys the code, we will see a huge spike of security issues soon.

Where I draw the line

I still use AI, sometimes. I think it can be a great tool, when used wisely. I draw the line at integration. I keep AI fully separate from my code editor. All of the context, I add manually. I intentionally keep the effort required quite high, so it disincentivizes me.

Examples where I use AI for work include “convert these Go tests in structs to tests in a map”, “convert this calculation to SIMD”, or “when the content type is application/zlib, decode the body”⁵. I have set up some custom instructions to only give me the code that has changed, and give me instructions for adding it. This way, I am still the one making the changes in the codebase. Just approving a Git diff is not enough, I want to manually add the code myself, only then do I feel confident to sign off on it and take responsibility for it.

Another great use case for AI is learning. I often have questions that are quite uncommon, as I have a few very niche interests. Turns out, adding netcode to a custom game engine using ECS doesn’t have a lot of learning resources. What has worked for me, is asking AI to explain pieces of code, like “explain this assembly code”, “explain what this shader does”, “which books go in-depth about resolving client/server desyncs in game engines”. The AI seems to struggle with these sometimes, I’m getting mixed results, but the results are still much better than search engines. I will even use it for this article, though not for writing content, but for checking⁶.

Another benefit of using AI this way is the cost. No unnecessary API calls, manually managed contexts and more control over the LLM settings. I use a desktop application with a bunch of different LLMs hooked up to it. I have used it daily for the last 3 months or so, and in total, I have consumed around \$4 in credits.

I do want to add that with some things I am more strict. On my personal website, I don’t want any AI-generated content, whether that’s text or images. I don’t like AI generated images or ‘art’ personally for various reasons and I think AI-generated text lacks character, it feels very flat and boring. When something is created by humans, it to me has more value than when it’s created by AI.

Doing what you love

It is also worth noting that there are more things to think about than efficiency and productivity. It’s also about doing what you love. If you love coding, keep doing it yourself, even if a computer might be better at it.

In 1997, Deep Blue won the chess match against the then world chess champion Garry Kasparov⁷, yet people still play chess. When it comes to programming, I’d say that I program for the same reason that people still play chess⁸. Though chess and software development are very different, with chess being much more limited in scope, I think it is good to keep in mind that sometimes, we can do things just to enjoy them.

My advice to new programmers

Don’t become a forever junior who lets AI do all their work. If you want to become a programmer, learn to program yourself. Be curious, put in the time and effort to learn how things really work, and how things work in the layer below that. It really pays off. Learning how everything works under the hood and using that is amazing, just keep learning, don’t be a prompt engineer (if you can even call that engineering). Believe me, it’s more fun to be competent⁹.

Even though AI might be smarter than you, never blindly trust the AI output. Don’t build your whole workflow around it. Sometimes try to work without it for a few days. The better at programming you are, the more AI will get in your way for the more complex work.

If you learn to code now, keep building your skills instead of letting AI do all the heavy lifting, you’ll be capable of fixing the messes that vibe coding is now creating. I don’t want to sound elitist, but if you don’t want to learn to go beyond vibe coding, maybe coding isn’t for you. Because positions where all work can be done by vibe coding are the ones that will be eliminated first when AI becomes more powerful.

And remember: if you cannot code without AI, you cannot code.

Conclusion

When you are using AI, you are sacrificing knowledge for speed. Sometimes it’s worth making this trade-off. Though it is important to remember that even the best athletes in the world are still doing their basic drills for a reason. The same applies to software development: you need to practice the basics, to be able to do the advanced work. You need to keep your axe sharp.

We are still a long way out from AI taking over our jobs. A lot of companies are creating FOMO¹⁰as a sales tactic to get more customers, to show traction to their investors, to get another round of funding, to generate the next model that will definitely revolutionize everything.

AI is a tool, it is not good or bad in itself, it’s what you do with it. I do think it can be a great tool, as long as you are not reliant on it for your workflow. Make sure you can still work effectively without it, make sure you don’t push code to production that you don’t fully understand and don’t think of AI as a replacement for your own thinking. Stay curious, keep learning.