AI觉醒星球
Awakening is here
Knowledge File / AI技能杠杆
2025-12-22 0 浏览 会员

趋势解读:A Year Of Vibes,提升开发者接入体验

作者回顾2025年作为开发者使用AI编码工具的体验变化,从Cursor转向Claude Code,并探讨了AI代理、人机关系、意见分歧等主题。

SOURCE / AI技能杠杆 MIN / 4 ACCESS / 会员 POST / 2025-12-22 00:00:00

原贴

查看原文
作者:Armin Ronacher 来源站点:lucumr.pocoo.org 原贴时间:
趋势解读:A Year Of Vibes,提升开发者接入体验

原文

2025 draws to a close and it’s been quite a year. Around this time last year, I wrote a post that reflected on my life . Had I written about programming, it might have aged badly, as 2025 has been a year like no other for my profession. 2025 Was Different 2025 was the year of changes. Not only did I leave Sentry and start my new company, it was also the year I stopped programming the way I did before. In June I finally felt confident enough to share that my way of working was different: Where I used to spend most of my time in Cursor, I now mostly use Claude Code, almost entirely hands-off. […] If you would have told me even just six months ago that I’d prefer being an engineering lead to a virtual programmer intern over hitting the keys myself, I would not have believed it. While I set out last year wanting to write more, that desire had nothing to do with agentic coding. Yet I published 36 posts — almost 18% of all posts on this blog since 2007. I also had around a hundred conversations with programmers, founders, and others about AI because I was fired up with curiosity after falling into the agent rabbit hole. 2025 was also a not so great year for the world. To make my peace with it, I started a separate blog to separate out my thoughts from here. The Year Of Agents It started with a growing obsession with Claude Code in April or May, resulting in months of building my own agents and using others’. Social media exploded with opinions on AI: some good, some bad. Now I feel I have found a new stable status quo for how I reason about where we are and where we are going. I’m doubling down on code generation, file systems, programmatic tool invocation via an interpreter glue, and skill-based learning. Basically: what Claude Code innovated is still state of the art for me. That has worked very well over the last few months, and seeing foundation model providers double down on skills reinforces my belief in this approach. I’m still perplexed by how TUIs made such a strong comeback. At the moment I’m using Amp , Claude Code , and Pi , all from the command line. Amp feels like the Apple or Porsche of agentic coding tools, Claude Code is the affordable Volkswagen, and Pi is the Hacker’s Open Source choice for me. They all feel like projects built by people who, like me, use them to an unhealthy degree to build their own products, but with different trade-offs. I continue to be blown away by what LLMs paired with tool execution can do. At the beginning of the year I mostly used them for code generation, but now a big number of my agentic uses are day-to-day things. I’m sure we will see some exciting pushes towards consumer products in 2026. LLMs are now helping me with organizing my life, and I expect that to grow further. The Machine And Me Because LLMs now not only help me program, I’m starting to rethink my relationship to those machines. I increasingly find it harder not to create parasocial bonds with some of the tools I use. I find this odd and discomforting. Most agents we use today do not have much of a memory and have little personality but it’s easy to build yourself one that does. An LLM with memory is an experience that is hard to shake off. It’s both fascinating and questionable. I have tried to train myself for two years, to think of these models as mere token tumblers, but that reductive view does not work for me any longer. These systems we now create have human tendencies, but elevating them to a human level would be a mistake. I increasingly take issue with calling these machines “agents,” yet I have no better word for it. I take issue with “agent” as a term because agency and responsibility should remain with humans. Whatever they are becoming, they can trigger emotional responses in us that can be detrimental if we are not careful. Our inability to properly name and place these creations in relation to us is a challenge I believe we need to solve. Because of all this unintentional anthropomorphization, I’m really struggling at times to find the right words for how I’m working with these machines. I know that this is not just me; it’s others too. It creates even more discomfort when working with people who currently reject these systems outright. One of the most common comments I read in response to agentic coding tool articles is this rejection of giving the machine personality. Opinions Everywhere An unexpected aspect of using AI so much is that we talk far more about vibes than anything else. This way of working is less than a year old, yet it challenges half a century of software engineering experience. So there are many opinions, and it’s hard to say which will stand the test of time. I found a lot of conventional wisdom I don’t agree with, but I have nothing to back up my opinions. How would I? I quite vocally shared my lack of success with MCP throughout the year, but I had little to back it up beyond “does not work for me.” Others swore by it. Similar with model selection. Peter , who got me hooked on Claude early in the year, moved to Codex and is happy with it. I don’t enjoy that experience nearly as much, though I started using it more. I have nothing beyond vibes to back up my preference for Claude. It’s also important to know that some of the vibes come with intentional signalling. Plenty of people whose views you can find online have a financial interest in one product over another, for instance because they are investors in it or they are paid influencers. They might have become investors because they liked the product, but it’s also possible that their views are affected and shaped by that relationship. Outsourcing vs Building Yourself Pick up a library from any AI company today and you’ll notice they’re built with Stainless or Fern. The docs use Mintlify, the site’s authentication system might be Clerk. Companies now sell services you would have built yourself previously. This increase in outsourcing of core services to companies specializing in it meant that the bar for some aspects of the user experience has risen. But with our newfound power from agentic coding tools, you can build much of this yourself. I had Claude build me an SDK generator for Python and TypeScript — partly out of curiosity, partly because it felt easy enough. As you might know, I’m a proponent of simple code and building it yourself . This makes me somewhat optimistic that AI has the potential to encourage building on fewer dependencies. At the same time, it’s not clear to me that we’re moving that way given the current trends of outsourcing everything. Learnings and Wishes This brings me not to predictions but to wishes for where we could put our energy next. I don’t really know what I’m looking for here, but I want to point at my pain points and give some context and food for thought. New Kind Of Version Control My biggest unexpected finding: we’re hitting limits of traditional tools for sharing code. The pull request model on GitHub doesn’t carry enough information to review AI generated code properly — I wish I could see the prompts that led to changes. It’s not just GitHub, it’s also git that is lacking. With agentic coding, part of what makes the models work today is knowing the mistakes. If you steer it back to an earlier state, you want the tool to remember what went wrong. There is, for lack of a better word, value in failures. As humans we might also benefit from knowing the paths that did not lead us anywhere, but for machines this is critical information. You notice this when you are trying to compress the conversation history. Discarding the paths that led you astray means that the model will try the same mistakes again. Some agentic coding tools have begun spinning up worktrees or creating checkpoints in git for restore, in-conversation branch and undo features. There’s room for UX innovation that could make these tools easier to work with. This is probably why we’re seeing discussions about stacked diffs and alternative version control systems like Jujutsu . Will this change GitHub or will it create space for some new competition? I hope so. I increasingly want to better understand genuine human input and tell it apart from machine output. I want to see the prompts and the attempts that failed along the way. And then somehow I want to squash and compress it all on merge, but with a way to retrieve the full history if needed. New Kind Of Review This is related to the version control piece: current code review tools assign strict role definitions that just don’t work with AI. Take the GitHub code review UI: I regularly want to use comments on the PR view to leave notes for my own agents, but there is no guided way to do that. The review interface refuses to let me review my own code, I can only comment, but that does not have quite the same intention. There is also the problem that an increased amount of code review now happens between me and my agents locally. For instance, the Codex code review feature on GitHub stopped working for me because it can only be bound to one organization at a time. So I now use Codex on the command line to do reviews, but that means a whole part of my iteration cycles is invisible to other engineers on the team. That doesn’t work for me. Code review to me feels like it needs to become part of the VCS. New Observability I also believe that observability is up for grabs again. We now have both the need and opportunity to take advantage of it on a whole new level. Most people were not in a position where they could build their own eBPF programs, but LLMs can. Likewise, many observability tools shied away from SQL because of its complexity, but LLMs are better at it than any proprietary query language. They can write queries, they can grep, they can map-reduce, they remote-control LLDB. Anything that has some structure and text is suddenly fertile ground for agentic coding tools to succeed. I don’t know what the observability of the future looks like, but my strong hunch is that we will see plenty of innovation here. The better the feedback loop to the machine, the better the results. I’m not even sure what I’m asking for here, but I think that one of the challenges in the past was that many cool ideas for better observability — specifically dynamic reconfiguration of services for more targeted filtering — were user-unfriendly because they were complex and hard to use. But now those might be the right solutions in light of LLMs because of their increased capabilities for doing this grunt work. For instance Python 3.14 landed an external debugger interface which is an amazing capability for an agentic coding tool. Working With Slop This may be a little more controversial, but what I haven’t managed this year is to give in to the machine. I still treat it like regular software engineering and review a lot. I also recognize that an increasing number of people are not working with this model of engineering but instead completely given in to the machine. As crazy as that sounds, I have seen some people be quite successful with this. I don’t yet know how to reason about this, but it is clear to me that even though code is being generated in the end, the way of working in that new world is very different from the world that I’m comfortable with. And my suspicion is that because that world is here to stay, we might need some new social contracts to separate these out. The most obvious version of this is the increased amount of these types of contributions to Open Source projects, which are quite frankly an insult to anyone who is not working in that model. I find reading such pull requests quite rage-inducing. Personally, I’ve tried to attack this problem with contribution guidelines and pull request templates. But this seems a little like a fight against windmills. This might be something where the solution will not come from changing what we’re doing. Instead, it might come from vocal people who are also pro-AI engineering speaking out on what good behavior in an agentic codebase looks like. And it is not just to throw up unreviewed code and then have another person figure the shit out.

中文翻译

2025年接近尾声,这是相当不平凡的一年。去年这个时候,我写了一篇反思生活的文章。如果我写的是编程,那可能已经过时了,因为2025年对我的职业来说是前所未有的一年。2025年与众不同。2025年是改变的一年。我不仅离开了Sentry并创办了新公司,也停止了像以前那样编程。六月,我终于有足够的信心分享我的工作方式不同了:过去我大部分时间都花在Cursor上,现在主要使用Claude Code,几乎完全放手。……如果有人六个月前告诉我,我宁愿做工程领导而不是亲手敲键盘,我绝对不会相信。虽然去年我计划写更多文章,但这种愿望与代理编码无关。然而我发表了36篇博文——几乎占我博客自2007年以来所有文章的18%。我还与程序员、创始人和其他人进行了大约一百次关于AI的对话,因为我在陷入代理的兔子洞后充满了好奇。2025年对世界来说也不是很好的一年。为了与它和解,我开了一个单独的博客来分离我的想法。代理之年。从四月或五月开始,我对Claude Code越来越痴迷,结果花了几个月时间构建自己的代理并使用他人的。社交媒体上关于AI的观点爆炸了:有好有坏。现在我觉得自己找到了一个新的稳定状态,用于思考我们现在在哪里以及未来走向。我加倍投入代码生成、文件系统、通过解释器胶水进行编程工具调用以及基于技能的学习。基本上:Claude Code的创新对我来说仍然是最先进的。过去几个月效果很好,看到基础模型提供商加倍投入技能,这强化了我对这种方法的信念。我仍然对TUI的强势回归感到困惑。目前我使用Amp、Claude Code和Pi,全部在命令行中。Amp感觉像是代理编码工具中的苹果或保时捷,Claude Code是实惠的大众,而Pi对我来说是黑客的开源选择。它们都像是像我一样过度使用它们来构建自己产品的人创建的项目,但各有取舍。我继续被LLM配合工具执行的能力所震撼。年初我主要用它们来生成代码,但现在我的代理用途中有很多是日常事务。我确信2026年我们会看到一些令人兴奋的消费者产品推动。LLM现在帮助我组织生活,我预计这会进一步增长。机器与我。因为LLM现在不仅帮助我编程,我开始重新思考与这些机器的关系。我越来越发现很难不与一些我使用的工具建立准社会关系。我觉得这很奇怪且不舒服。我们今天使用的大多数代理没有太多记忆和个性,但很容易为自己构建一个有记忆和个性的。一个有记忆的LLM是一种难以摆脱的体验。它既迷人又可疑。两年来我试图训练自己将这些模型视为单纯的令牌翻滚机,但这种简化的观点对我已不再适用。我们现在创建的系统具有人类倾向,但将它们提升到人类水平将是一个错误。我越来越反对称这些机器为“代理”,但我没有更好的词。我反对“代理”这个词,因为自主权和责任应该属于人类。无论它们变成什么,它们都能在我们身上引发情感反应,如果不小心,这可能有害。我们无法正确定义和定位这些创造物与我们的关系,我认为这是一个需要解决的挑战。由于所有这些无意的拟人化,我有时很难找到正确的词来描述我如何与这些机器合作。我知道不只是我,其他人也是如此。当与那些完全拒绝这些系统的人合作时,这会造成更多不适。我读到的关于代理编码工具文章最常见的评论之一就是拒绝给机器赋予个性。意见无处不在。如此大量使用AI的一个意外方面是,我们谈论“感觉”远比任何其他东西多。这种工作方式不到一年,却挑战了半个世纪的软件工程经验。所以有很多意见,很难说哪些会经得起时间考验。我发现很多传统智慧我不同意,但我没有东西支持我的观点。我怎么能呢?我全年都公开分享我对MCP缺乏成功,但我几乎没有依据,只能说“对我没用”。其他人却深信不疑。模型选择也是如此。Peter年初让我迷上了Claude,后来改用Codex并很满意。我并没有那么喜欢那种体验,尽管我开始更多地使用它。除了感觉,我没有任何依据支持我对Claude的偏好。同样重要的是要知道,有些感觉是有意释放的信号。很多你在网上找到观点的人对某个产品有经济利益,比如他们是投资者或付费影响者。他们可能因为喜欢产品而成为投资者,但他们的观点也可能受这种关系影响。外包与自己构建。……

核心信息

作者回顾2025年作为开发者使用AI编码工具的体验变化,从Cursor转向Claude Code,并探讨了AI代理、人机关系、意见分歧等主题。

  • 2025年是AI编程从辅助转向代理化的关键年。
  • 开发者从手写代码转向使用Claude Code等代理工具。
  • 工具选择更多依赖“感觉”而非客观数据。
  • LLM拟人化可能引发情感依赖和认知偏差。
  • 利益冲突和付费影响影响行业观点。
试看内容

成为会员查看完整内容

你已经看到了这篇内容的前置整理,剩余深度部分仅对会员开放。

详细解读 信息差价值 参考来源
成为会员查看完整内容
上一篇 趋势解读:Advent of Slop,聚焦形式化数学证明能力
下一篇 已经是本栏目最后一篇