在这里是怪物：当Agents工作时，你还需要知道什么？

在这里是怪物：当Agents工作时，你还需要知道什么？

CI失败了这是意外的。 我拨打我的代理工作流程以至于如果我的agents之一做了一个测试失败的分支，我会感到惊讶。 也许是CI弹片还是环境问题？等等是SonarQube抱怨App.tsx的事吗？我们从Npm什么的那里找到新的可疑的依赖？没有 SonarQube正在标出这个文件的环形复杂性。 好久不见

对 App.tsx由大约30行的代码组成，除了其中15行实际上是Codex决定每行以一行写出的全部组件。 这本身会好起来的，只是运行它更漂亮，我们结束了。 但这并不能解释百科全书的复杂性。 每一部分都是相当参与的部分，都有相当数量的展示和商业逻辑。 旧的自我会仔细重构它，并确保代码可以读取。 另一方面，Codex并不在乎整个组件都是单行的，更重要的是，它也不在乎复杂性。 它通过几个特征在档案中欣然和可靠地展出。

CI工具在标出一个问题，也许是正确的，也许不正确。 但这是一个真正的系统所以我不得不潜入。 在整理文件之后，我检查了组件和逻辑。 Codex是否超越了典型的dev在覆盖边缘病例方面可能拥有的优势，并且它是否略为过量地进行了改造？是的，但这一切都是正确的。 我没抱怨所有这些复杂性都符合业务要求。 我告诉Codex让SonarQube开心，它通过重构和把事情分成10个文件。 CI通过，运出物品虽然这个事件有快速的解决方案，但你也许可以想象它会变得更糟。 这毕竟是我从未见过的密码

我们的行业就是在这里：拥有一个软件系统将更不依赖于手写(或类似系统)；相反，最重要的是知道足够了解什么是错的，并且愿意并能够在需要时像需要的那样潜入深处。

潜水员和金块

想象一下你在一艘船上(你决定你喜欢哪种船)，你的工作是从海底取取出小金块。 一直到最近，如果你想得到你的包黄金你需要跳入水中，游泳到水底，看看周围，并填充你的包。 如果你在清澈而浅的水域中容易让人心生不安但你可以想象这能有多快地升级成更困难的东西所以当浅水矿井开始干涸时，你和工程师们建造了各种机械和工具从越来越深和危险的水域取出黄金。 这在大部分时间里效果很好，你和你的团队会仔细地组装，维护，旋转机械，并不断下潜到海底采矿作业中以保持其运行。 你经常听到一些采矿作业的倒闭，有时是因为水下的压力，有时是因为事故，或操作员无能。 挑战在于，这是一个地质活跃的世界，因此海底不断变化，一些地雷正在干涸，新的地雷会在不同的地方涌出。

不过好消息！在过去几年中，出现了越来越复杂的潜水器，这些潜水器可以自行进行采矿作业。 你只是告诉他们在哪里建起和关闭他们潜水，只表面给你更新和金块。 事情是伟大的，你现在可以放松在你的船上当你的潜水员做他们的事情，你只需要担心的是，你有多少黄金可以塞进你的船上。 这里是乐观主义者营。

直到。..

"等待你的潜水员走得太深，然后消失" "哈哈你的潜水员带给你的东西看起来像金子但实际上是闪亮的章鱼大便" 随着潜水员的激增，你可以看到越来越多的恐怖故事。 潜水员迷路了忘记了他们应该建造的东西潜水员建造了如此复杂而怪异的东西，以至于难以维护，只能被下一代潜水员抛弃。 所有水下采矿作业都从精心设计和设计大教堂发展到更像无所事事的豪宅，暗藏着通道和恐怖。 越脱离行动，失败就越壮观。 此是斯克之营也。

在这里是怪物

软件工程行业(我怀疑很快还会有许多其他行业)正在经历上述情景的版本。 你可能已经知道怀疑论或乐观论对你的描述更好了即使你还不确定你想投向哪个阵营

传统的智慧是，为了发展和维持一个非部落系统，你需要有一个适当的工作模式。 我认为很少有人会为此而争论。 在软件工程中，你会通过直接使用代码来获得工作模型。 多年和几十年的练习写作和阅读代码给你所需的知识和工具来理解你负责的系统。 每起出产事件，每起深夜调试会，每起成功放出。 所有这些经验都给了你拥有一个系统所需的视角。 就这篇文章而言，所有权意味着当某事破裂时你才是被召唤的人。

Agents (活体机器人) 正在把头部所有的东西都翻过来。 潜水员的输出速度远快于任何人的能吸收，而在过去的复杂系统中，你可以假设代码曾经穿过过人类的手中，这已经不是事实了。 现在经验丰富的从业者可以管理潜水员的舰队，并以前所未有的规模创建软件。 这些操作人员了解该工艺，并带来了他们相当的经验来管理和设计大型系统，这些系统过去本来会让团队来建造。 但这暴露了我们工业可能面临的最大挑战：我们如何培养下一代工程师？

在他们的极端，乐观主义者和怀疑主义者对这个问题的答案大相径庭。 一方面，你有声优说保持控制这些系统的唯一方法就是读取潜水员制作的每行代码能用手来编码。 能够解释每个代码做什么，以及它如何与应用程序的上下文相适应。 在另一个营地，你也有同样声望的声音说连看代码都不用费心把精力集中在想出建造什么忘记它是如何建造的模特儿会处理的我觉得这两个都不对

事实是今天的高级工程师学到的方法，ie. 通过手接编码，无休止的时数调试，生产出事等，对于今天的少年来说并不是一条可行的道路。 要清楚的是，这在经济上并不可行，这意味着公司极不可能愿意赞助低等公司多年，而他们却"靠手做". 即发愿想。 常被呈现的另一种方法是"确保您理解您所写的agent的每行建议"，或者"与高年级的伴侣"，或者"perform carely code review". 再说一遍，满脑子都是希望但也许还有几家商店如果你认为整个行业会采取这些做法，我有一个桥可以卖你。 打我一顿。

为了找出实现某种程度的掌握的可行路径，我们必须研究拥有一个非三角软件系统意味着什么。 如果你想到你典型的建筑师/领头人/CTO以及他们如何运作，很明显，他们要想成功，就必须在他们的头上有一个系统模型，一个水图。 真正的问题是颗粒度是多少？想象一个100万行码库的遗产，是多年来由一些人所写和扩展的。 CTO甚至可能写了部分内容。 现在想象一下，有一个生产问题，而你是不幸的SRE试图在2: 00找出这个问题，同时从不同时区的人那里得到愤怒的短信。 你需要什么系统图？你需要一个高水平的，遥远的整个系统的地图，你需要知道足够知道需要潜入的地方，怪物居住的地方，你需要能够跳入任何未知的代码库，找出正在发生的事情，推出一个热点，并在你的事件报告中清楚地描述所发生的事情。

请注意，这不是对整个系统的详细了解。 我们管理复杂系统的唯一办法是建立抽象。 每一层都让我们造出更多的东西，但是无论你有什么地图，重要的是要记住，它是抽象的一路下行，没有人真正理解所有的地层。 在"我写了模块X并且知道里面外"和"我有一个适当的系统抽象模型，可以在任何模块中潜入并被破解后修复"之间有着很大的区别。 手工编码给了我们前者，但系统的所有者，被呼叫的人需要后者。

那这张照片是怎样建造的？怎么能指望有人潜入未知水域解决潜水员造成的混乱如果他们从未手工开采金块的话？

基础、面包和时间深度

复杂系统中一些最隐蔽的失败是静静的失败。 事情大多是可行的，但系统有些不对劲。 也许它突然变慢，或者误差率上升，或者它大部分时间都完美地工作，但每19次尝试都失败。 不至于在2: 00被呼叫，但足够让你感觉有些东西脱落了。 作为系统的所有者，你需要了解系统的失败模式。 作为一个行业，我们拥有教人们如何发现和解释这些失败的工具：基本原理。 好消息是，我们几十年来一直在教他们不知情的CS专业。 我指的是数据结构与算法，网络，货币，分布式系统等。 也不必通过正规教育，这些话题你可以自己阅读和学习。

画一幅简单的相片(如果你是资深工程师，请在这里忍受)，想象一下你派潜水员执行一个任务。 你在浅水里，你把它送到水下2米处去取一些金块。 它在4s回来，一切都很好。 接下来，你发送下来4米。 这次虽然需要16分这是奇怪的。 下一个任务下行为16m，需要256s. 你得到这张照片。 很明显有些事情不对劲在计算机科学中，这被称为"四相复杂"，也许是认识它的最佳方法就是理解这个理论并知道这样的事物的存在。

带来我到下一个所有权支柱：宽度。 大多数成功的工程师和工程领导都有幸与我共事能够就几乎任何议题展开讨论无论是技术性的还是非技术性的他们可能在某些方面是专家，但最令人印象深刻的是，他们能够利用和编织与不同学科似乎不同的概念并利用这种知识解决问题。 此是取水高地图。 这说明某些海洋比其他海洋更危险知识的广度让你能说"让我们潜水" 说得很清楚，我不是在谈论每个领域的专家水平知识，而是足以知道当某事被关闭时该做什么。 引导你海洋探索的浮标

有人问我："我们如何教授宽度？我当时没有很好的答案。 但再想想，我觉得这不是你能做的

本文由 AI宝库自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。

Here Be Monsters: What Do You Still Need to Know When Agents Do the Work?

CI was failing. This was unexpected. I have dialed in my agentic workflow to a point where I would be surprised if one of my agents committed a branch that had failing tests. Maybe it's a CI flake or environment issue? Wait, it's SonarQube complaining about App.tsx? Did we pull in a new suspicious dependency from npm or something? Nope. SonarQube is flagging this file for cyclomatic complexity. Haven't seen that one in a while.

Yep. App.tsx consists of about 30 lines of code, except 15 of those lines are actually entire components that Codex decided to write each on a single line. That itself would be ok, just run it through prettier and we're done. But that doesn't explain the cyclomatic complexity. Each of these was a fairly involved component with a good amount of display and business logic. Old self would have carefully refactored it and made sure the code was readable. On the other hand, Codex didn't care that entire components were on a single line, and more importantly, it didn't mind the complexity. It had been happily and reliably iterating on that file through several features.

The CI tool was flagging an issue, perhaps correct, perhaps incorrect. But this is a real system so I had to dive in. After formatting the files, I went through and inspected the components and logic. Did Codex go beyond what a typical dev might have in terms of covering edge cases and did it slightly over-engineer it? Yes, but it was all correct. No complaints from me. All of the complexity was warranted by the business requirements. So I told Codex to make SonarQube happy, which it did by refactoring and splitting things up into 10 files. CI passed; things shipped. Although this particular incident had a quick resolution, you can probably imagine how it could have gone much worse. This was, after all, code I had never seen before.

This is where our industry is headed: Owning a software system will depend a lot less on having written it (or similar systems) by hand; instead, what will become most important is knowing just enough to know when something is wrong, and being willing and able to dive as deep as needed, when needed.

Divebots and golden nuggets

Imagine that you're on a boat (you decide what type of boat you like) and your job is to collect little nuggets of gold from the bottom of the ocean. Up until very recently, if you wanted to get your bag of gold you would need to jump into the water, swim to the bottom, look around, and stuff your bag. Easy peasy if you're in clear, shallow waters, but you can imagine how quickly this can escalate into something much more difficult. So as the shallow water mines started drying up, you and fellow engineers built all sorts of machinery and tooling to extract gold from ever deeper and more dangerous waters. This worked well for the most part, you and your team would carefully assemble, maintain, rotate the machinery and would constantly dive to the seabed mining operation to keep it running. Every so often you'd hear about the collapse of some mining operations, sometimes due to the sheer underwater pressure, other times through accidents, or operator incompetence. The challenge is that this is a very geologically active world, so the seabed keeps changing with some mines drying up and new ones popping up in different places.

Good news though! The last few years have seen the development of ever more sophisticated divebots that can go down and build a mining operation on their own. You just tell them where to build and off they dive and only surface to give you updates and gold nuggets. Things are great, you can now relax on your boat while your divebots do their thing and all you have to worry about is how much gold you can stuff into your boat. This is the Optimists camp.

Until...

"Wait till your divebots go too deep and get lost". "Haha your divebots brought you stuff that looks like gold but is actually shiny octopus poop". As the divebots proliferate you see more and more horror stories. Divebots getting lost and forgetting what they are supposed to be building. Divebots building something so complex and grotesque that they have trouble maintaining it, only for it to be discarded by the next generation of divebots. All of the underwater mining operations went from being carefully designed and engineered cathedrals to more like haphazard mansions, with hidden passages and horrors lurking. The more detached from the operation you are, the more spectacular the failures. This is the Skeptics camp.

Here Be Monsters

The software engineering industry (and I suspect many other industries soon) is living through a version of the above scenario. You probably already know whether Skeptic or Optimist describes you better, even if you're still not sure which camp you want to commit to.

The traditional wisdom is that in order to develop and maintain a non-trivial system you need to have a proper working model of it. I think few people would argue with that. And in software engineering you would acquire that working model by working directly with the code. Years and decades of practice writing and reading code give you the knowledge and tools needed to understand the systems you're responsible for. Every production incident, every late-night debugging session, every successful release. All of these experiences give you the perspective needed to have ownership of a system. In the context of this post, ownership means you're the one who gets called when something breaks.

Agents (divebots) are turning all of that on its head. Divebots produce output much faster than anyone can absorb, and while in complex systems of the past you could assume that the code had at one point gone through the hands of a human, that is no longer true. It is now possible for experienced practitioners to manage fleets of divebots and create software at an unprecedented scale. These operators know the craft and bring their considerable experience to manage and architect large systems that would have taken teams to build in the past. But that exposes what's probably the biggest challenge facing our industry: how do we train the next generation of engineers?

At their extremes, the Optimists and the Skeptics have wildly different answers to this question. On the one hand you have reputable voices saying that the only way to maintain control of these systems is to read every line of code the divebots produce. Be able to code it by hand. Be able to explain what every piece of code does and how it fits into the context of the applications. In the other camp, you have equally reputable voices saying to not even bother looking at the code. Focus your energy on figuring out what to build and forget about how it is built. The models will handle it. I don't think either of these is right.

The fact is that the way that today's senior engineers learned, ie. through coding by hand, endless hours debugging, production incidents, etc. is not a path that is viable for juniors today. To be clear, it is not economically viable, meaning that it is highly unlikely that companies will be willing to sponsor juniors for years while they "learn to do it by hand". That's wishful thinking. An alternative that is often presented is the "make sure you understand every line your agent wrote" advice, or "pair with a senior", or "perform careful code reviews". Again, wishful thinking at all but perhaps a few shops. If you think that the industry at large will adopt these practices, I've got a bridge to sell you. Hit me up.

In order to figure out a viable path for achieving some measure of mastery, we have to look at what it means to own a non-trivial software system. If you think about your typical architect/lead/CTO and how they operate, it becomes clear that to be successful they need to have a model of the system in their head, a chart of the waters. The real question is at what level of granularity? Imagine a legacy 1-million line codebase, it was written and expanded over the years by a number of people. The CTO may have even written parts of it. Now imagine there is a production issue and you're the unlucky SRE trying to figure this out at 2AM while getting angry texts from people in different timezones. What chart of the system do you need? You need a high-level, far-away map of the entire system, and you need to know just enough to know where you need to dive in, where the monsters live, and you need to be able to jump into any unknown codebase, figure out what's happening, push a hotfix, and describe what happened clearly in your incident report.

Note that this is not detailed knowledge of the whole system. The only way we can manage complex systems is by building up abstractions. Each layer lets us build a bit more, but whatever map you have, it is important to remember that it is abstractions all the way down, and no one really understands all the layers. There is a big difference between "I wrote module X and know it inside out" and "I have an appropriate model of the system abstractions and can dive into any module and fix it when it breaks". Coding by hand gives us the former, but the owner of a system, the person who gets called, needs the latter.

So how does this picture get built? And how can someone be expected to dive into unknown waters and fix the mess the divebots made if they've never mined gold nuggets by hand?

Fundamentals, Breadth, and Just-in-Time Depth

Some of the most insidious failures in complex systems are quiet failures. The sort where things mostly work, but there is something off about the system. Maybe it's suddenly slower, or error rates went up, or it works perfectly most of the time but fails every 19th attempt. Not to the point where you're getting paged at 2AM but enough that you get a feeling that something is off. As an owner of a system you need to understand the failure modes of the system. As an industry we have the tools to teach folks how to detect and reason about these failures: fundamentals. And the good news is that we've been teaching them to unwitting CS majors for decades. I'm talking about data structures & algorithms, networking, concurrency, distributed systems, etc. It doesn't have to come from a formal education either, these are topics you can read about and learn on your own.

To paint a simple picture (if you're a senior engineer please bear with me here), imagine you send your divebot on a mission. You're in shallow waters and you send it 2m underwater to collect some gold nuggets. It comes back in 4s and all is good. Next, you send it down 4m. This time though it takes 16s. That's odd. The next mission is 16m down, and it takes 256s. You get the picture. Something is obviously off. In computer science this would be called quadratic complexity, and probably the best way to recognize it is to understand the theory and know that such a thing exists.

Which brings me to the next pillar of ownership: breadth. Most of the successful engineers and engineering leaders I have had the pleasure of working with were able to hold a discussion on almost any topic, whether technical or not. They may have been specialists in certain things, but what was most impressive was their ability to draw upon and weave together seemingly disparate concepts from different disciplines and use that knowledge to solve problems. This is the high-level map of the waters. This is what tells you certain seas are more dangerous than others. The breadth of knowledge is what enables you to say "let's dive here". And to be clear, I'm not talking about expert level knowledge in every domain imaginable, but just enough to know what to look up when something is off. The buoys that guide your ocean exploration.

Someone asked me "how do we teach breadth? a survey class on everything?" and I didn't have a good answer at the time. But after thinking about it some more it seems to me that this is not something you can

Auto-fetched and translated by AI Gem Box. All rights belong to the original author.