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

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

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

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

CI工具在标出一个问题，也许是正确的，也许不正确。 但这是一个真正的系统所以我不得不潜入。 在整理文件之后，我检查了组件和逻辑。 Codex是否超越了典型的dev在覆盖边缘病例方面可能拥有的功能，并且是否略微过于精炼？是的，但这一切都是正确的。 没有我的抱怨。 所有这些复杂性都是业务要求所证明的。 所以我告诉Codex让SonarQube高兴起来，它通过重构和把事情分成10个文件。 线人通过，运货尽管这个事件有迅速的解决，你也许可以想象它会变得更糟。 这毕竟是我从未见过的密码

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

潜水员和金块

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

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

直到。..

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

在这里是怪物

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

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

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

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

事实是，今天的高级工程师学到的方法，是的。 通过手动编码，无休止的时数调试，生产事件等，对于今天的低年级学生来说并不是可行的路径。 要清楚的是，这在经济上并不可行，这意味着公司极不可能愿意赞助低年级学生多年，而同时他们却"学习用手做". 即发愿心。 常被呈现的另一种选择是"确保您理解您所写的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 Atlas. All rights belong to the original author.