AI usage disclosure provided by OP, see the reply to this comment.

Think about the whole thing as if you were a manager or an engineer and not a technical craftsperson. 试着以管理者或工程师的视角，而不是技术工匠的视角来审视整件事。

If you hired a bunch of people to build an artificial heart, how would you make sure it was safe? How do you know they built it properly? 如果你雇了一群人制造一颗人造心脏，你如何确保它安全？你如何知道他们制造得没问题？

You can't trust them to get it right, and you can't spend every moment micromanaging them or looking over their shoulder. 你不能指望他们不出错，也不可能每时每刻都对他们进行微观管理或盯着他们的肩膀看。

So what do you do? 那么你该怎么办？

The post-LLM world is that, but with virtual agents instead of human beings. 后大语言模型（LLM）时代就是这样，只不过把人类换成了虚拟智能体。

Civil engineers spend a LOT of time on requirements, design, testing, and certification in compliance with technical regulations. They rely on the trades, vendors, PM's, architects, regulators, and their peers to make sure that they have the minimum set of unknowns into their designs and their designs can be proven correct from the requirements. Then, they ( and their regulator ) do inspections of the construction process to make sure things are done correctly. 土木工程师会在需求、设计、测试和认证方面花费大量时间，以符合技术规范。他们依赖于各工种、供应商、项目经理、建筑师、监管机构和同行，以确保设计中的未知因素降到最低，并确保设计能从需求层面证明是正确的。然后，他们（及其监管者）会对施工过程进行检查，确保工作执行无误。

At the end of the day, they sign off on their work and go to jail if their building has design flaws that kill people or testify when they discovered that the mob had substituted the cheap concrete for what they specified. 归根结底，他们要在工作成果上签字，如果建筑因设计缺陷导致人员伤亡，他们要坐牢；如果发现黑帮将指定的优质混凝土偷换成了劣质品，他们也要出庭作证。

That is where we're heading except the tradespeople are replaced with robots. 这正是我们前进的方向，只不过工匠们被机器人取代了。

From an individual perspective, do we want to be engineers, artists, or craftspeople? 从个人角度来看，我们想成为工程师、艺术家还是工匠？

For many of us, this shift is the long-delayed professionalisation of our discipline but it leaves behind the joyous artists who want to make beautiful things with their friends in wonderful ways. While it's fun and rewarding to write beautiful code, the people paying for it want the best output for the cheapest price they can afford as fast as we can give it to them. 对我们许多人来说，这种转变是我们学科期待已久的职业化进程，但它抛弃了那些想与朋友以美妙方式创造美好事物的快乐艺术家们。虽然编写漂亮的代码既有趣又有成就感，但买单的人只想要以最快的速度、最低的价格获得最好的产出。

Several comments in here talking about frontier models writing "good code" now. Certainly there is a lot less obvious obviously wrong at a surface level and yet I see cutting edge models do the stupidest shit all the time. 这里有几条评论说前沿模型现在能写出“好代码”。当然，表面上看起来明显错误的东西少了很多，但我依然经常看到最先进的模型做出最愚蠢的事情。

It truly is a case of having zero discernment. A reviewer on a polished change finds a single "major issue" that is impossible in the actual problem space, and a violation of a runtime invariant but okay sure I'll add a comment to the PR. Meanwhile three passes by different people's agents miss a legitimately embarrassing boundary case. 这确实是一个完全没有辨别力的问题。一个审查者在润色过的变更中发现了一个在实际问题空间中不可能存在的“重大问题”，这违反了运行时的不变性，好吧，我会在 PR 中加个评论。与此同时，不同人的智能体经过三轮审查却错过了真正令人尴尬的边界情况。

To be clear the edge case was missed by my human review as well. I do believe the generated test suite led to a false sense of security because it tested other boundaries and I spent a while culling and refining tests. You let your guard down, forest for the trees situation. 需要说明的是，这个边界情况我的真人审查也漏掉了。我确实认为生成的测试套件导致了一种虚假的安全感，因为它测试了其他边界，我花了一些时间剔除和完善测试。你放松了警惕，这就是“只见树木，不见森林”的情况。

Meanwhile I have to spend energy with adversarial review trying to force less code because the models love not only over engineering but building the wrong abstractions. I love my abstractions, mind you, but without oversight, two changes later I'm aghast that a bleeding edge model wants to drill a new optional parameter through five layers of architecture with no documentation instead of a trivial refactor to clean it up with a more consistent domain model. 与此同时，我不得不花精力进行对抗性审查，试图强制减少代码量，因为模型不仅喜欢过度工程，还喜欢构建错误的抽象。请注意，我喜欢我的抽象，但在没有监督的情况下，两次变更后，我惊讶地发现最先进的模型想要在没有文档的情况下，通过五层架构钻出一个新的可选参数，而不是进行一次琐碎的重构来通过更一致的领域模型来清理它。

And the documentation - it's all still garbage. Even with workflow dedicated to cleaning it up I still have to manually intervene and provide examples of what fails standards in a given PR. It's like all 70% of the way there and then someone approves a single bad example that proliferates into future changes like a weed. 还有文档——它们依然全是垃圾。即使有专门的工作流来清理它，我仍然必须手动干预并提供哪些内容不符合给定 PR 标准的示例。就像完成了 70%，然后有人批准了一个单一的坏示例，它就像杂草一样蔓延到未来的变更中。

It feels like trying to keep blackberries out of the stormwater pond in my neighborhood. You let your guard down for a weekend and suddenly there are five new plants causing regressions, but isn't it wonderful that the same landscapers that planted the blackberries installed the fountain nobody actually asked for? 这感觉就像试图把我社区雨水池里的黑莓灌木清理掉。你周末放松一下警惕，突然就有五株新植物导致了回归，但最妙的是，种植这些黑莓的园丁还安装了一个根本没人要求的喷泉，不是吗？

And this is all as someone who has handwritten almost zero code since March. I think this stuff is useful and makes my designs better when I focus and hold myself accountable. But you have to exercise restraint and care and too many people seem to think otherwise. 作为从三月份以来几乎没手写过代码的人，我深有体会。我认为这些东西很有用，当我专注并对自己负责时，它能让我的设计更好。但你必须保持克制和谨慎，太多人似乎并不这么认为。

I think what I find most aggravating is I can riff with an agent in session and basically get into flow. It "gets" my intent, it generates high quality samples, it pokes holes in my thinking and offers something better, I have a eureka moment and counter with something even better. Then we go to build and as soon as any delegation or orchestration is introduced, the slop pours in at every underspecified seam like the world's most pedantic shitty genie. I still have the absolute best, fastest results manually approving edits with the session, to the point I'm wondering why I'm spending so much energy on automation. 我觉得最让我恼火的是，我可以和智能体在会话中即兴创作，基本上进入心流状态。它“理解”我的意图，生成高质量的样本，指出我思维中的漏洞并提供更好的东西，我灵光一现并用更好的东西反击。然后我们去构建，一旦引入任何委托或编排，垃圾就会像世界上最迂腐、最糟糕的精灵一样，从每一个未明确定义的接缝中倾泻而出。我手动批准会话中的编辑，结果依然是绝对最好、最快的，以至于我怀疑为什么要在自动化上花费这么多精力。

I did an interview as a candidate a couple of weeks ago where I was asked to do a task with AI, in 25 minutes. It was just a simple API, but I made sure I did it the way I actually would in the real world, with proper standards, tests, automated checks, everything ensuring all the output was every bit as good as you would produce by hand as an experienced developer. But that meant in the mere 25 minutes, I only finished 3 out of the 5 requested features. 几周前我作为候选人参加了一次面试，被要求在 25 分钟内用 AI 完成一项任务。那只是一个简单的 API，但我确保我是按照现实世界中真正的方式去做的，有适当的标准、测试、自动化检查，确保所有输出都像一个经验丰富的开发人员手工制作的一样好。但这意味着在短短 25 分钟内，我只完成了 5 个请求功能中的 3 个。

The feedback that I could have used a simpler, faster model and spent less time setting up so many parameters and checks at the beginning....in short, I was rejected for not just sharting out whatever crap I could in a very short time that superficially appeared to work even if it was awful. 反馈是说我本可以使用一个更简单、更快的模型，少花时间在开始时设置那么多参数和检查……简而言之，我被拒绝了，原因是我没有在很短的时间内随手甩出任何看似能用的垃圾，即使那东西烂透了。

No you are not behind and you are not crazy. Anyone working in any real production code knows that AI cannot replace humans despite the endless nonsense being spewed by the vibecoder evangelists. Every 6 months "You just have try the new model, because the last one was crap, but this one totally solves coding". 不，你没有落后，你也没有疯。任何在真实生产代码中工作的人都知道，尽管“氛围编码”传道者们不断喷出无尽的废话，但 AI 无法取代人类。每 6 个月就会出现一次“你必须尝试新模型，因为上一个很烂，但这个完全解决了编码问题”。

Every. Single. Time. 每一次。都是。这样。

A candidate that would tell me they don't actually read their code would be automatic DQ. That would be a violation of our quality guidelines and could put our acridiation at risk should it come out in an audit. Unfortunately it is true that some teams are swimming in the kool-aid. 如果候选人告诉我他们实际上不读自己的代码，我会自动取消其资格。那将违反我们的质量准则，如果审计中发现，可能会危及我们的认证。不幸的是，确实有一些团队沉迷于这种洗脑。

Personally I think the reality is more something like this. Delusional people claiming 10x productivity while deploying garbage code. 我个人认为现实更像是这样：妄想的人声称有 10 倍的生产力，同时部署着垃圾代码。

There's a lot here. For context, I'm full stack with about ~11 years at one company. I'm the closest that our working group of ~10 devs has to an AI evangelist and I'm paid like a senior, so take what I say with any appropriate caveats. 这里有很多内容。背景说明：我是全栈，在一家公司呆了大约 11 年。在我们约 10 人的开发小组中，我是最接近 AI 传道者的人，拿的是高级工程师的薪水，所以请带着适当的保留意见来看待我的话。

We're obviously all scrambling to figure out what the next 6 months looks like because of how fast things are moving, but a few things stand out to me: 我们显然都在争先恐后地弄清楚接下来的 6 个月会是什么样子，因为事物发展得太快了，但有几点对我来说很突出：

• The scaling trends the AI labs have been talking about for years have continued. Models are going to get smarter and probably cheaper per unit of useful work. AI 实验室多年来一直在谈论的扩展趋势仍在继续。模型会变得更聪明，而且单位可用工作的成本可能会更低。

• "AI makes mistakes" is too broad to be useful. Forgetting context, making bad assumptions, misunderstanding existing behavior, and just writing buggy code are different failure modes and need different mitigations. “AI 会犯错”这个说法太宽泛，没有实用价值。忘记上下文、做出错误的假设、误解现有行为以及编写有 bug 的代码是不同的故障模式，需要不同的缓解措施。

• I don't think "a human reads every line" scales as the long term answer either. If agents can produce 10x the code but humans still have to review every line, we've just moved the bottleneck. 我不认为“人类阅读每一行”作为长期答案是可扩展的。如果智能体能产生 10 倍的代码，但人类仍然必须审查每一行，那我们只是转移了瓶颈。

I think the interesting question is what replaces that. Better specs, tests, invariants, independent review, observability, etc. Basically, how do you build a process where confidence doesn't depend on personally understanding every line that gets generated? 我认为有趣的问题是什么能取代它。更好的规范、测试、不变性、独立审查、可观测性等。基本上，你如何构建一个流程，让信心不依赖于亲自理解生成的每一行代码？

That's where I think experienced engineers are still extremely important. Knowing what to verify, what assumptions are dangerous, and where the system can fail requires understanding the problem at a level that prompting alone doesn't give you. 这就是我认为经验丰富的工程师仍然极其重要的地方。知道验证什么、哪些假设是危险的、系统在哪里可能失败，需要对问题有足够的理解，而这仅仅靠提示词是无法获得的。

So I don't think "I don't read the code anymore" is necessarily crazy. The much more important question is what they're doing instead. 所以我认为“我不再阅读代码”并不一定疯狂。更重要的问题是他们正在用什么来代替它。

This is OK. As an 13yoe fintech enterprise developer, only in this year I learned that mvp/poc development was a real job. Or developing a shaders for some js library. So apparently we need those "ai engineers" for this part of market. 这没关系。作为一名 13 年经验的金融科技企业开发人员，直到今年我才了解到 MVP/POC 开发是一项真正的工作。或者为某些 JS 库开发着色器。所以显然我们需要那些“AI 工程师”来负责这部分市场。

is going to make us look bad by comparison to the execs 会让我们在主管们面前显得很糟糕

Lol no. Execs will not approve any not safe code in fintech, it is customer money and criminal charges. In health sector too, and many, many others. It is ok only in some near only crud level simple apps. And it will not be better, since opus 4.5 no changes in coding models, just relabeing (basically opus 4.5 is opus 5.5 now, but nothing changes in terms of code generation) and price increase. 想得美。在金融科技领域，高管绝不会批准任何不安全的代码，这涉及客户资金和刑事责任。医疗行业以及许多其他行业也是如此。这种做法只适用于一些近乎增删改查（CRUD）级别的简单应用。而且情况也不会好转，因为自 Opus 4.5 以来，编码模型并没有实质性变化，只是换了个名字（基本上 Opus 4.5 现在叫 Opus 5.5，但在代码生成方面没有任何改变），还涨了价。

> These particular roles we’re currently hiring for are billed as “AI Engineer”. There is something weird going on in my company politically where separate from the tech department that I work in a new “AI native” development team is being spun up to work on internal projects > 我们目前正在招聘的这些特定职位被冠以“AI 工程师”的头衔。我公司内部在政治层面有些奇怪，除了我所在的科技部门外，公司正在组建一个新的“AI 原生”开发团队来负责内部项目。

This is weird. An "AI Engineer" based on my experience and what I've seen in the industry is a person working on AI in some capacity, somehow building products/features/services which depend on AI - this can be more traditional ML or orchestrating LLM API calls, usually some mix of the two. And we can quibble whether that's "real" AI engineering and/or deserving of the title but that's besides the point. The point is that "AI Engineer" denotes the domain, not whether they use AI assistance or not. For example, a frontend engineer who uses AI assistance for coding is a still a frontend engineer, not an "AI engineer". 这很奇怪。根据我的经验以及我在行业中所见，所谓的“AI 工程师”是指以某种身份从事 AI 工作的人，他们以某种方式构建依赖于 AI 的产品、功能或服务——这可能是更传统的机器学习，也可能是编排 LLM API 调用，通常是两者的结合。我们可以争论这是否是“真正的”AI 工程和/或是否配得上这个头衔，但这与重点无关。重点在于，“AI 工程师”代表的是领域，而不是他们是否使用 AI 辅助。例如，使用 AI 辅助编程的前端工程师仍然是前端工程师，而不是“AI 工程师”。

If they were right then what exactly do they think their expertise is? If they are right then a software developer doesn't need to exist, and if software developers don't need to exist then software companies don't need to exist. Anybody can churn out vibe code to meet their own bespoke requirements, yet software companies are not generally shrinking. The ones who go all in on ignoring the code will be the ones to fail, because they are not differentiating themselves from people simply vibe coding themselves. 如果他们是对的，那么他们认为自己的专长究竟是什么？如果他们是对的，那么软件开发人员就不需要存在了；如果软件开发人员不需要存在，那么软件公司也就不需要存在了。任何人都能为了满足自己的定制需求而产出“感觉流”代码，但软件公司并没有普遍萎缩。那些全盘忽略代码的人终将失败，因为他们无法让自己与那些仅仅靠“感觉流”编程的人区分开来。

Use of AI deskills people. Hello?
Your company’s practices are a slippery slope ending total catastrophe. 使用 AI 会导致人们技能退化。喂，有人在吗？你们公司的做法正走在一条滑向彻底灾难的下坡路上。

On a personal note, i was laid off three years ago just before AI use became normalized and while ive done some AI evaluation on its ability to code, im near enough retirement age that investing dollars for tokens to improve strikes me as unlikely to pay off. Despite 30 years as a generalist who can go from mobile/web to cloud architecture / data storage architect, and team leader at a FAANG i haven’t landed an interview - mist likely due to my age i suspect. 顺便说一下，我在三年前 AI 使用普及前夕被裁员了。虽然我做过一些关于 AI 编码能力的评估，但我快到退休年龄了，花钱买 Token 来提升技能对我来说似乎不太划算。尽管我拥有 30 年的通才经验，能从移动/Web 开发横跨到云架构/数据存储架构，并且在 FAANG 公司担任过团队领导，但我一直没能获得面试机会——我怀疑这主要是因为我的年龄。

So im patiently hanging with my huge skill set waiting for you all to screw yourselves into total collapse and like a turn if the century COBOL programmer, ill be charging exorbitant rates to come in and manually pay down your technical debt - assuming i can be arsed to put down my margarita in retirement. 所以我正耐心地带着我庞大的技能储备闲着，等着你们所有人把自己折腾到彻底崩溃。到时候，就像世纪之交的 COBOL 程序员一样，我会收取高昂的费用，进去手动帮你们偿还技术债——前提是我退休后有心思放下手中的玛格丽特鸡尾酒。

Thats the likely future in seeing. Be sure to put aside plenty of $ to buy down that technical debt. 这就是我看到的未来。一定要预留足够的资金来偿还那些技术债。

AI coding makes developers lazy. And I say that as someone who works as a developer. Everyone on my team uses Claude, but everyone has also had a PR where there was some code that snuck by unseen and not understood. And we try to review our own code and keep things under control. AI 编程让开发者变懒了。我是以开发者的身份说这句话的。我团队里的每个人都在用 Claude，但每个人也都遇到过 PR 中混入了一些未被发现且未被理解的代码的情况。我们尽量审查自己的代码，保持一切在掌控之中。

And the tool constantly lies, gaslights, and misunderstands the codebase. And when I redirect it and supply an explanation of how the code actually works, then the response is so overly full of flattery and useless puffery. No, I'm not some golden god just because I understand the codebase. 而且这个工具经常撒谎、进行煤气灯操纵（gaslighting），并误解代码库。当我纠正它并解释代码实际是如何工作时，它的回答又充满了奉承和毫无意义的吹捧。不，我并没有因为理解代码库就成了什么金牌大神。

And then there are the md files and comments. AI tools treat them like the gospel truth even if they are outdated or downright false. And AI tools love to leave comments about how code has been changed. But what happens a few refactors down the line? You now have paragraphs alluding to the old codebase architecture with no relationship to the current codebase. It's all a useless burn of output tokens. 还有那些 Markdown 文件和注释。AI 工具把它们奉为圭臬，即使它们已经过时甚至完全错误。AI 工具喜欢留下关于代码如何被修改的注释。但经过几次重构后会发生什么呢？你现在会看到一些段落暗示着旧的代码库架构，而与当前代码库毫无关联。这完全是在浪费输出 Token。

This stuff is all new. I think over time, once it becomes more common in our career, people what find out what is IS good for and what it ISN'T. I manage lots of agentic tasks every day but I always look at the code, I think it's pretty crazy to yeet something into production at a company with actual customers. Eventually someone's gonna get burned. 这些东西都是新鲜事物。我认为随着时间的推移，当它在我们的职业生涯中变得更加普遍时，人们会发现它到底擅长什么，不擅长什么。我每天管理许多代理任务，但我总是会检查代码。我觉得在一家拥有真实客户的公司里，直接把东西扔进生产环境是非常疯狂的。迟早会有人吃大亏。

That said, the AI code reviewers are getting pretty good. It's hard to predict the future. 话虽如此，AI 代码审查员正变得越来越好。未来很难预测。

Human review is important even for non critical systems because redo or bugs can cost more. 即使对于非关键系统，人工审查也很重要，因为返工或 Bug 可能会带来更高的成本。

As someone who review 3-5 MRs a day I found a lot of issues that AI and the developers don't see and could be a disaster for our product. 作为一名每天审查 3-5 个合并请求（MR）的人，我发现了很多 AI 和开发者看不到的问题，这些问题可能会给我们的产品带来灾难。

It's an era that managers think running fast with less quality is ok. It might reverse some day 这是一个管理者认为“快跑、牺牲质量”是可以的时代。有一天可能会反转。

What happens when these AI engineers lose access to their AI tokens and now have to manually fix and review code? People assume every company has a massive budget for Claude where everyone can use the latest (or latest - 1) model 80% of their working hours. As someone who has a $100, maybe $200, budget per month on Claude tokens, I have to manage them so I don’t run out. Fortunately we also use Cursor and Cursor has been really good at picking the most optional model. I wonder how their mindset would change if they could only use Sonnet 4.6 and only spend $3 a day. 当这些 AI 工程师失去了 AI Token 的访问权限，现在不得不手动修复和审查代码时会发生什么？人们假设每家公司都有巨额的 Claude 预算，每个人都能在 80% 的工作时间内使用最新（或次新）的模型。作为一个每月只有 100 到 200 美元 Claude Token 预算的人，我必须精打细算以免用完。幸运的是，我们也使用 Cursor，而 Cursor 在选择最优模型方面一直非常出色。我很好奇，如果他们只能使用 Sonnet 4.6 并且每天只能花 3 美元，他们的心态会发生怎样的变化。

I’m so baffled by their depth of AI use. Isn’t it taking just as much time and brain power to configure and setup and drive the agentic AI workflows as it would be to just learn and write code directly?? That’s of course on top of, yes, reading and reviewing the code. 我对他们使用 AI 的深度感到困惑。配置、设置和驱动代理式 AI 工作流所花费的时间和脑力，难道不比直接学习和编写代码更多吗？？当然，这还没算上阅读和审查代码的时间。

So strange, it will be wild to see how this all plays out because I am well aware of how economics drives the decisions and those with the purse strings are unaware of the low level details, as they rightly don’t want or need to be. 太奇怪了，看着这一切如何发展将会非常疯狂，因为我很清楚经济是如何驱动决策的，而那些掌握钱袋子的人并不了解底层细节，因为他们理所当然地不想也不需要了解。

OP, just as an FYI, “AI Engineering” and “AI Engineer” are somewhat well defined terms in our industry, and they don’t mean “using AI to write code”. OP（楼主），顺便提一下，“AI 工程”和“AI 工程师”在我们行业中是定义相对明确的术语，它们并不意味着“使用 AI 来编写代码”。

It means “applied LLMs”, or “building systems that use LLMs”. These roles are less about writing conventional software and more about building systems around frontier models that can handle and classify messy input via LLMs. Heavy emphasis on data science, maths, etc, less on writing code. You might get better candidates with a more conventional title for the role. 它意味着“应用 LLM”，或者“构建使用 LLM 的系统”。这些角色与其说是编写传统软件，不如说是围绕前沿模型构建系统，这些系统能够通过 LLM 处理和分类混乱的输入。重点在于数据科学、数学等，而不是编写代码。如果你为该角色使用一个更传统的头衔，可能会招到更合适的人选。

They are absolutely cowboys that should be held accountable to the absolute shit they are delivering. 他们绝对是牛仔（鲁莽行事者），应该为他们交付的那些绝对的垃圾负责。

I have a couple of meat proxies as well. Reality is people are lazy and would always do the least effort unless they care 我也有几个肉身代理。现实是人们很懒，除非他们关心，否则总是会做最省力的事。

Just let the burn this industry. It is Dunning–Kruger effect industry.

This is insane but not uncommon. I work in something healthcare adjacent so that answer would not work at all. I'm all for using whatever tools you want, but you have to have a fundamental understanding of your code. Not understanding the code reveals itself in other things, like not being able to debug well in a crisis, not understanding long term implications of decisions made etc. Sometimes you'll get yourself into a hole you can't 100% AI yourself out of and we need hires who will be able to do that. 这太疯狂了，但并不罕见。我在一个医疗相关领域工作，所以那个答案完全行不通。我完全支持使用任何你想要的工具，但你必须对你的代码有基本的了解。不了解代码会体现在其他方面，比如在危机中无法很好地调试、不理解决策的长期影响等。有时你会让自己陷入一个无法 100% 靠 AI 解决的困境，我们需要能够做到这一点的员工。

I haven't written much manual code for a while, but I can't believe how many people (and the proof is here in the comments) treat code as a black box. AI makes mistakes, and it makes serious mistakes of the worst kind, the ones that pass tests and, weeks or months later, cost a lot of work and money to fix. 我已经有一段时间没写太多手动代码了，但我无法相信有多少人（评论区就是证据）把代码当作黑盒。AI 会犯错，而且是那种最糟糕的严重错误——那些能通过测试，但在几周或几个月后需要耗费大量工作和金钱才能修复的错误。

Sorry to be harsh and probably offend some people, but if someone isn't able to see that, regardless of how long they've been in the industry, they simply lack the skills or experience. Instead of being offended, I advise those people to start learning and improving those skills, because you will be replaced if you keep going like that. I don't need a coder who writes a prompt and has no idea whether the generated code has issues or not, agents do that, so I don't need a human for it. 抱歉我说话比较刺耳，可能会冒犯到一些人，但如果有人看不出这一点，无论他们在行业里待了多久，他们都缺乏技能或经验。与其感到被冒犯，我建议这些人开始学习并提高这些技能，因为如果你继续这样下去，你会被取代。我不需要一个只会写提示词却不知道生成的代码是否有问题的程序员，代理程序就能做到这一点，所以我不需要人类来做这个。

I need engineers to make sure the whole system doesn't go down, that we aren't just covering happy paths while ignoring corner cases, that we don't have to reindex a billion-document index because the AI used the wrong field type, and that we don't spend thousands or tens of thousands (or millions) more than we should because the whole thing just doesn't scale properly. 我需要工程师来确保整个系统不会崩溃，确保我们不仅仅是覆盖了“快乐路径”（happy paths）而忽略了边界情况，确保我们不需要因为 AI 使用了错误的字段类型而重新索引十亿条文档，并且确保我们不会因为整个系统无法正确扩展而浪费成千上万（甚至数百万）本不该花的钱。

Our industry has a short-termism problem for many years now, the infamous move fast and break stuff mantra. The AI just speed up this. The issue is that no one is accountable for the issues this cause. The manager that allowed that will get a big bonus for quickly delivering the new project. The devs will job hop every 2 years and won’t need to deal with the legacy code. And there are a lot of people believing that the AI models will get better fast enough that it will be able to solve the spaghetti code in the future.  多年来，我们的行业一直存在短期主义问题，即臭名昭著的“快速行动，打破常规”的口号。AI 只是加速了这一点。问题在于，没有人对由此引发的问题负责。允许这样做的经理会因为快速交付新项目而获得丰厚奖金。开发人员每 2 年跳槽一次，不需要处理遗留代码。而且有很多人相信 AI 模型会足够快地进化，以至于未来能够解决那些面条式代码。

The move fast logic kind of make sense for startups that still need to validate the product, but big companies providing services to millions should be made more accountable. I think cyber security is the only thing that will prevent the slop,  I’m hoping that as governments fine and open lawsuits against companies that failed to prevent cyber attacks will force companies to be more strict on what is delivered.  “快速行动”的逻辑对于仍需验证产品的初创公司来说是有意义的，但为数百万人提供服务的大型公司应该承担更多责任。我认为网络安全是唯一能防止这种混乱的东西，我希望随着政府对未能防止网络攻击的公司进行罚款和提起诉讼，将迫使公司对交付的内容更加严格。

it still seems insane to me that we’re going to completely move away from human sign off on high risk changes 在我看来，我们将完全取消对高风险变更的人工签署，这仍然是疯狂的。

It's our (seemingly) slow march towards The Matrix. We're the frog in the pot of water on the stove with the ever-increasing water temperature. Some people are dismissive of such analogies, yet humans do this kind of thing all the time. And it's exacerbated in this case because most software companies are run by greedy, MBA-touting lemmings who think all you need to get rich is to quickly churn out code. 这似乎是我们迈向《黑客帝国》的缓慢步伐。我们就像炉子上水壶里的青蛙，水温不断升高。有些人对这种类比不屑一顾，但人类总是做这种事。在这种情况下，情况更加恶化，因为大多数软件公司都由贪婪的、满口 MBA 术语的旅鼠经营，他们认为致富只需要快速产出代码。

More code in and of itself does not lead to features of higher value that customers are willing to pay for.  I'm still waiting to see all the success stories of companies increasing their customer count and/or revenue because they're churning out more code. Seriously, where is all the success?  更多的代码本身并不会带来客户愿意付费的高价值功能。我还在等待看到所有那些因为产出更多代码而增加客户数量和/或收入的成功案例。说真的，那些成功在哪里？

Oh, wait, I know.... The "success" is reduced head count. 哦，等等，我知道了……所谓的“成功”是裁员。

Oofdah. 哎呀。

I'm starting to explore local AI assisted flows to build out local knowledge bases and expert systems for fixed areas, but I'm nowhere near comfortable with letting things just go. I still have the memory of an AI-suggested hash function for a custom struct (to be used with a hashset) that had an insane collision rate. In any case, I still don't trust it for critical things, especially not things where other people's money/data/lives are on the line. 我开始探索本地 AI 辅助流程，为特定领域构建本地知识库和专家系统，但我远没有舒服到让事情顺其自然。我还记得一个 AI 建议的自定义结构体哈希函数（用于 HashSet），它的冲突率高得离谱。总之，我仍然不信任它处理关键事务，尤其是涉及他人金钱/数据/生命安全的事情。

I think the number one thing is that I still don't see systems with top-tier observability, alerting, and rollback procedures necessary for me to be comfortable letting the systems run that independently. 我认为最重要的一点是，我仍然没有看到具备顶级可观测性、警报和回滚程序的系统，这对于我放心让系统如此独立运行是必要的。

Lmao, what a bunch of lobotomized morons. Even if you don’t review your slopped out code in your job, how hard is it to do it for a fucking interview? 哈哈哈，真是一群被切除了前额叶的白痴。即使你在工作中不审查你那堆烂代码，在面试中做这件事又有多难？

I mean back when most interviews were some DSA puzzles, it wasn’t what you would do on the job either. So what? 我的意思是，回到大多数面试都是 DSA（数据结构与算法）谜题的时候，那也不是你在工作中会做的事。那又怎样？

OP you need to update the candidate selection process, not the interview process. It’s clear you are getting duds. OP，你需要更新的是候选人筛选流程，而不是面试流程。显然你招进来的都是些次品。

When the AI bubble burst, only then will companies understand the problem they are left with from all the hyper AI FOMO. If you pay attention to the debt and money invested in AI you realize there is no way this is sustainable as a business model and so eventually, this rapid code development will hit a wall and companies will have to pay exuberant amounts of money to continue the AI addiction. And aside for that all the security vulnerabilities that the AI companies themselves are “marketing” on the news lately is concerning. If we think the dot come bubble was a burst just wait until the AI one hits. Companies will be scrambling for “human expertise” at rapid rate while the AI executives cash out before the storm hits…. 当 AI 泡沫破裂时，公司才会明白他们从所有的 AI 错失恐惧症（FOMO）中留下了什么问题。如果你关注投入 AI 的债务和资金，你会发现作为商业模式这根本不可持续，所以最终这种快速代码开发会撞上南墙，公司将不得不支付高昂的费用来维持对 AI 的依赖。除此之外，AI 公司自己最近在新闻中“营销”的所有安全漏洞也令人担忧。如果说我们认为互联网泡沫是一次破裂，那就等着看 AI 泡沫破裂吧。公司会争先恐后地寻找“人类专业知识”，而 AI 高管们会在风暴来临前套现离场……

I was working on large scale prod systems earlier and after the layoff, did do some AI type coding on my own. I was still driving the process but used AI as an auto-complete tool for methods I didn't want to hand code. And I thought that this was actually a good way to go. But I went recently to a dev meet-up and was told that most people don't use AI in this way anymore and that AI should be doing the bulk of the writing. It's just really hard to take your hand off the wheel. Not only that but now the role of the dev is mostly to do PR reviews and I find that really tiring and unsatisfying. 我之前从事大规模生产系统的工作，被裁员后，我自己做了一些 AI 类型的编码。我仍然在主导这个过程，但将 AI 作为一种自动补全工具，用于我不想手动编写的方法。我曾认为这确实是一个很好的方向。但我最近参加了一个开发者聚会，被告知大多数人不再以这种方式使用 AI，而且 AI 应该完成大部分的编写工作。把手从方向盘上拿开真的很难。不仅如此，现在开发者的角色主要是做 PR 审查，我觉得这真的很累且没成就感。

AI boosters are always going on and on about how their agentic code review swarm caught 3x as many bugs as a human reviewer. AI 推动者总是喋喋不休地谈论他们的代理式代码审查群组如何捕捉到比人类审查员多 3 倍的 Bug。

For some reason they never go into detail what the actual bugs are, and whether agents caught everything the human caught. 出于某种原因，他们从不详细说明实际的 Bug 是什么，以及代理程序是否捕捉到了人类捕捉到的所有内容。

So they indeed feel very confident about the reliability of having only AI code reviews. 所以他们确实对仅进行 AI 代码审查的可靠性感到非常有信心。

People who let AI write any level of security-critical or performance-critical code are legit retarded. AI can barely write UI code without serious fuck ups.  让 AI 编写任何安全关键或性能关键代码的人简直是智障。AI 连编写 UI 代码都做不到不出大乱子。

What you're describing is very like how it is in my company at the moment- management have set up a specifically AI focused team even though everybody is already being driven to use more AI faster all the time. It simply isn't possible to review many of the PRs manually in the old-fashioned way. Many of them are too large and often they involve large amounts of simply markdown for agent, which of course can't be effectively tested in any meaningful way. So the old techniques of tests and linting aren't going to work. I feel very much like your candidates. It's not a choice but it's not a choice... 你所描述的非常像我公司目前的情况——管理层建立了一个专门专注于 AI 的团队，尽管每个人都在被驱动着不断更快地使用更多的 AI。简单地以老式方式手动审查许多 PR 是不可能的。其中许多 PR 太大了，而且通常涉及大量简单的 Markdown 指令给代理，当然这些指令无法以任何有意义的方式进行有效测试。所以旧的测试和 Linting 技术行不通。我非常理解你的候选人。这不是选择，但这不是选择……

On the flip side, my company is spending an enormous amount of money on third party AI services and I haven't seen a comparable increase in revenue, profit or savings. I'm expecting the music to stop soon- in some senses it already has. It's not possible to spend ever more money, throwing stuff at the wall without making that back somewhere else. Convincing investors of the value of unicorn farts instead will only go sofar. Companies who try to will obviously go bankrupt.  另一方面，我们公司在第三方 AI 服务上花费了巨额资金，但我没有看到收入、利润或节省方面的相应增长。我预计音乐很快就会停止——在某种意义上它已经停止了。不可能不断地花钱，把东西扔在墙上而不从其他地方赚回来。向投资者兜售独角兽屁的价值只能走这么远。试图这样做的公司显然会破产。

From another angle you could compare it to a startup where a small group of developers who know each other can get stuff out of the door at incredible speed. Day one looks fantastic. Day two is a bit of a mess. Day three they need testing before they release. Day 4  they need an infrastructure guy... 从另一个角度来看，你可以把它比作一家初创公司，一群互相认识的开发人员可以以惊人的速度把东西推向市场。第一天看起来棒极了。第二天有点乱。第三天他们在发布前需要测试。第四天他们需要一个基础设施人员……

I don't think that AI will go away but I do think a lot of code has become intermediate language and we have to adapt. 我不认为 AI 会消失，但我确实认为很多代码已经变成了中间语言，我们必须适应。

The truth is that mediocre engineers have found their super power and become relevant again. If you asked those same engineers to do the scenario before, they'd fail. And the best part is they still fail the scenario. That's the point of the scenario; they show their lack of criticality and understanding for how important this part of the workflow is. Let another enterprise ship the un-reviewed slop. 事实是，平庸的工程师找到了他们的超能力，并再次变得重要起来。如果你之前要求同样的工程师处理这个场景，他们会失败。最棒的是，他们现在仍然在这个场景中失败。这就是这个场景的意义所在；他们展示了他们缺乏批判性和对工作流中这一部分重要性的理解。让其他企业去发布那些未经审查的垃圾吧。

I think you need to stick to your guns about the kind of engineer you want on your team to prevent the 3am outage and dismiss the other candidates same as we always have. 我认为你需要坚持你想要的团队工程师类型，以防止凌晨 3 点的宕机，并像我们一直做的那样拒绝其他候选人。

When you find a good one making sensible workflow decisions who can still think, move fast because they are literal gold 当你发现一个能做出明智工作流决策且还能思考的好员工时，动作要快，因为他们简直是黄金。

Yeah it's pretty bleak. Coding agents are basically a team of very competent junior engineers all competing to show off how good they are with no thought of the overall big picture and limited supervision. 是的，前景相当黯淡。编码代理基本上是一群非常有能力的初级工程师，他们都在争相炫耀自己有多厉害，却完全不考虑全局，且缺乏监督。

I work in the AI space where our code is a bit rough as it only has to be good enough to iterate quickly for research, but Claude has turned our codebase into tangled, duplicated mess, which no one fully understands. We've also stopped thinking properly, which scares me the most. 我在 AI 领域工作，我们的代码有点粗糙，因为它只需要足够好以进行快速研究迭代，但 Claude 把我们的代码库变成了一团纠缠不清、重复的乱麻，没有人能完全理解。我们也停止了正常的思考，这最让我害怕。

”Well  if I was working in healthcare or sending to people into space then I’d definitely be looking closely at the code review skills, maybe I’d even write the skills myself” “好吧，如果我是在医疗领域工作，或者送人上太空，那我肯定会密切关注代码审查技能，也许我自己都会写这些技能。”

We are so boned lmao. 我们完蛋了，哈哈哈。

Just so you know, AI engineers are supposed to be SWE that specialise in building agents and products based on AI technologies. 你要知道，AI 工程师应该是专门从事构建基于 AI 技术的代理和产品的软件工程师（SWE）。

Just using AI assisted code generation is just using a tool. Add for every tool, they're are those who use it properly and those who do not. 仅仅使用 AI 辅助代码生成只是在使用一个工具。对于每个工具，都有正确使用它的人和不正确使用它的人。

Your overall idea (review prs etc) is good but it should be used for any engineering level really at this point. 你的总体想法（审查 PR 等）很好，但在这一点上，它应该适用于任何工程级别。

AI can't take responsibility for the bugs and problems. It's really bad for regression risk and long-term planning. On top of that, all the instructions and context you feed it are optional for it to follow. AI 无法为 Bug 和问题承担责任。这对于回归风险和长期规划来说非常糟糕。最重要的是，你喂给它的所有指令和上下文，它都可以选择性地遵循。

For me, that's enough reason not to let the slop reach the PR stage. The PRs are limited to 300-500 lines and the author must be proficient in the code they wrote. 对我来说，这足以成为不让垃圾代码进入 PR 阶段的理由。PR 被限制在 300-500 行，作者必须精通他们编写的代码。

It's obvious now that this is where we're headed. 现在很明显，这就是我们前进的方向。

We can't keep up with the code they generate, and it's going to get faster. 我们跟不上他们生成的代码，而且速度只会越来越快。

They're also at the level of code writing that surpasses the majority of devs I've worked with, so at what point do we say that they're incredible devs that are being auto reviewed by other incredible devs, and accept that us slowing them down isn't worth it? I think that if we're not at that point now, surely we will be soon? 他们编写代码的水平也超过了我共事过的大多数开发者，那么在什么节点上我们能说他们是出色的开发者，且正在被其他出色的开发者自动审查，并接受我们拖慢他们的速度是不值得的呢？我想如果我们现在还没到那个节点，肯定很快就会到了吧？

And again, they're getting better and better all the time. It was only really January this year with the 4.6 Anthropic models that we hit the real turning point. 而且再说一次，它们一直在变得越来越好。直到今年 1 月份 Anthropic 4.6 模型发布，我们才真正达到了转折点。

I don't know what I'd do with code sending someone into space though. I'd be reviewing every line, and testing everything to death, but it's not an area I've ever worked in before, so I couldn't say how that will play out. If you believe the doomsday scenario of AI that a lot follow, they'll be so much better than us fairly soon that you wouldn't want a human to be reviewing if given the option to review it with AI, right? 我不知道如果代码涉及送人上太空我会怎么做。我会审查每一行，并把所有东西测试到死，但这不是我以前工作过的领域，所以我无法说会发生什么。如果你相信许多人追随的 AI 末日论，它们很快就会比我们好得多，以至于如果可以选择用 AI 审查，你就不会想要人类去审查了，对吧？

Your post mentioned AI Engineers. AI engineers build Agentic systems, software built around a model (or using a model within a wider piece of software). Most of these systems aren't sending people into space or similar right now (I hope not anyway!), and I'm way past the point of caring about the code anymore for these. Evaluation and testing of all kinds are more important. 你的帖子提到了 AI 工程师。AI 工程师构建代理式系统，即围绕模型构建的软件（或在更广泛的软件中使用模型）。大多数这些系统现在并没有送人上太空或类似的事情（我希望没有！），对于这些代码，我早已不在乎了。各种评估和测试更重要。

Every new model release nowadays is exciting for a few minutes, and then a serious reminder of how we're obselete, or about to be. I have no idea what I'm going to do. 如今每次新模型发布都会让人兴奋几分钟，然后就是一次严肃的提醒，提醒我们是多么过时，或者即将过时。我不知道我该怎么办。

The core issue is that code is deterministic and LLM AI is not. The reason we can do code review on code and not assembly is that build process will produce exactly the same assembly for the same code every time and that assembly will always mirror exactly what the code said (except for optimizations). With an LLM that is not the case. The same input is never guaranteed to generate the same output. There is always going to be a chance the generated code has problems. The other issue is that even if you tell an LLM something important like "don't touch the production system" it might ignore that and delete your entire production system. It is less like a TV show robot that follows orders exactly and gets caught up in logical traps, but is more like a 6 year that drank 4 energy drinks and stayed up all night reading the encyclopedia. 核心问题在于代码是确定性的，而 LLM AI 不是。我们之所以能对代码进行代码审查而不能对汇编进行审查，是因为构建过程每次都会为相同的代码产生完全相同的汇编，并且该汇编将始终准确反映代码所述的内容（优化除外）。对于 LLM，情况并非如此。相同的输入永远无法保证生成相同的输出。生成的代码总是有可能出现问题。另一个问题是，即使你告诉 LLM 一些重要的事情，比如“不要碰生产系统”，它也可能会忽略这一点并删除你的整个生产系统。它不像那种严格服从命令并陷入逻辑陷阱的电视机器人，它更像是一个喝了 4 罐能量饮料、熬了一整夜读百科全书的 6 岁小孩。

It’s safe to say most of my code is AI-generated now. It’s also safe to say every output has some parts to it that need a little refinement. Sometimes as simple a variable rename for clarity and other times it interprets a requirement completely wrong, in both cases tests “pass” 现在可以肯定地说，我的大部分代码都是 AI 生成的。也可以肯定地说，每一个输出都有一些部分需要一点改进。有时只是为了清晰起见重命名变量，有时它完全误解了需求，在这两种情况下，测试都“通过”了。

If someone tells you they never review their code anymore then you’re not getting a good developer. Yes AI can help find bugs, yes it writes code really fast. Writing code was never the hardest part of our job, but the appearance of busy work is what gets recognized not actually working software that meets the users needs. 如果有人告诉你他们再也不审查代码了，那你招到的就不是一个好的开发者。是的，AI 可以帮助发现 Bug，是的，它写代码非常快。写代码从来不是我们工作中难度最大的部分，但那种“忙碌”的表象才是被认可的，而不是真正满足用户需求的软件。

When people say one LLM is an architect and another is the designer yada yada yada…. It’s all the same LLM, it’s not intelligent; it’s a steerable autocomplete. You can’t skills your way out of the nature of what the system actually is and it would be better if more people actually understood how LLMs work and what their limitations are. 当人们说一个 LLM 是架构师，另一个是设计师等等……它们都是同一个 LLM，它并不智能；它只是一个可引导的自动补全工具。你无法通过提升技能来摆脱系统本质的局限，如果更多人能真正理解 LLM 的工作原理及其局限性，情况会更好。

The people you interviewed are internally consistent. Getting the full "productivity benefits" of AI requires you to not read or care about the code being written, only the output and observable effects. 你面试的人在逻辑上是一致的。要获得 AI 的全部“生产力红利”，要求你不去阅读或关心所编写的代码，只关心输出和可观察到的效果。

Let's say you want to use AI to "write" 100x the code you used to. That's all well and good, maybe for prototypes and feature branches. But when it comes time to merge into production, you cannot read and understand 100x the code, especially for code you didn't even write to begin with. So, reading and reviewing code becomes the bottleneck. 假设你想用 AI “编写”过去 100 倍的代码。这很好，也许适用于原型和功能分支。但当需要合并到生产环境时，你无法阅读和理解 100 倍的代码，尤其是对于那些甚至不是你自己编写的代码。因此，阅读和审查代码就成了瓶颈。

In fact, it's common that you end up moving slower than you would have without AI. Consider: a task that would've taken you two days of thinking and 500 surgical lines of code to get right. AI does it in half an hour, but it writes 2,000 lines of code, adds an entire new test suite, molests every critical system. Now you spend multiple days context switching between this PR and the 20 others made by your and your team's agents. And merging all those PRs at once created subtle bugs that took another two weeks to fix. 事实上，你最终的移动速度往往比没有 AI 时还要慢。考虑一下：一个原本需要你两天思考和 500 行手术级代码才能搞定的任务。AI 在半小时内完成了，但它写了 2000 行代码，增加了一整套新的测试套件，骚扰了每一个关键系统。现在你花费数天时间在你的 PR 和你及团队代理创建的其他 20 个 PR 之间切换上下文。而一次性合并所有这些 PR 产生了细微的 Bug，又花了两个星期才修复。

So now you have a choice. 所以现在你有了一个选择。

You can choose to slow back down to pretty much pre AI speeds, maybe a little faster here and there. You leave the agentic workflows for prototypes and one off tests. In the main codebase however, everyone is responsible for every single like of code put into the project as if written by hand. You have strict limits on PR sizes and frequency, and the expectation is that if I ask why you used a hashmap instead of a tree on line 218, you'll give me a good answer. 你可以选择放慢速度，恢复到接近 AI 之前的速度，也许偶尔快一点。你把代理式工作流留给原型和一次性测试。然而，在主代码库中，每个人都要对放入项目中的每一行代码负责，就像是手写的一样。你对 PR 的大小和频率有严格的限制，并且预期是，如果我问你为什么在第 218 行使用了哈希映射而不是树，你会给我一个好的答案。

Or you can choose to remove the bottleneck. You can decide to never read the code again. If you care about performance, you set up performance tests that the agents can run. If you care about security, you set up fuzzing and security audits at regular intervals. If you're worried about correctness, you set up automated behavior checks and tests. If you're worried that the code will get too complicated for the agents to handle, you automate metrics like cyclomatic complexity and run regular deduplication passes. 或者你可以选择消除瓶颈。你可以决定再也不读代码了。如果你关心性能，就设置代理可以运行的性能测试。如果你关心安全，就定期设置模糊测试和安全审计。如果你担心正确性，就设置自动化的行为检查和测试。如果你担心代码变得太复杂而代理无法处理，就自动化度量指标（如圈复杂度）并定期运行去重。

I'm increasingly convinced that it's one or the other. You have to either decide you are a software engineer, and you are slowing down on purpose to maximize human understanding and correctness of your system, or you are a dark factory overseer explicitly choosing to sacrifice quality and understanding (and independence from OpenAI/Anthropic/SpaceX) for velocity 我越来越确信，只能二选一。你必须决定要么你是一名软件工程师，并且你有意放慢速度以最大化人类对系统的理解和正确性；要么你是一名黑暗工厂的监工，明确选择牺牲质量和理解（以及对 OpenAI/Anthropic/SpaceX 的独立性）来换取速度。

The less experienced, the more unaware they are. Imo, code review is still a thing, but accelerated by AI, human judgement applies and more than before imo, boundary control (you got to understand how it all comes together) + proper harness (at least Docker sandboxes) 经验越少，越无知。在我看来，代码审查仍然是必要的，只是被 AI 加速了。人类的判断依然适用，而且比以前更重要，在我看来，边界控制（你必须理解这一切是如何组合在一起的）+ 适当的防护措施（至少是 Docker 沙箱）是必须的。

That is insane. 100% those companies will encounter very serious problems. Security, audit, basic functionality etc. will expose serious and fundamental gaps. 这太疯狂了。这些公司 100% 会遇到非常严重的问题。安全、审计、基本功能等将暴露严重且根本性的差距。

What? That’s not what an AI Engineer does at all, an AI Engineer builds AI products, for example using the Claude API, they don’t use AI to build deterministic software, that’s regular software engineering. 什么？那根本不是 AI 工程师所做的事情，AI 工程师构建 AI 产品，例如使用 Claude API，他们不会使用 AI 来构建确定性软件，那是常规的软件工程。

It’s more the managers than the developers. The management wants to “increase velocity 3x”. My manager would “accidentally” flash dashboards of ai usage and tickets resolved per dev in the sprint. Since my team used to be mainly contractors, you gotta keep him happy no matter what or your contract is done and you’re out of a job next month. Reading the comments I feel people are glossing over the fact that keeping a job is much more important to people than code quality.
It’s all top down enforcement. 更多的是经理而不是开发者的问题。管理层想要“将速度提高 3 倍”。我的经理会“不经意间”闪现 AI 使用情况和每个冲刺中每位开发人员解决的工单仪表板。由于我的团队过去主要是承包商，你必须不惜一切代价让他满意，否则你的合同就结束了，下个月你就失业了。阅读评论时，我觉得人们忽略了一个事实，即保住工作对人们来说比代码质量重要得多。这完全是自上而下的强制执行。

I still find scaling and performance bugs all the time in even the latest LLM code. Most people don't work at places that need to scale and they haven't worked on code that has needed to scale. So at least for now I review anything that I think will require actual scaling either now or in the long run. 即使在最新的 LLM 代码中，我也总能发现扩展性和性能 Bug。大多数人工作的场所不需要扩展，他们也没有处理过需要扩展的代码。所以至少目前为止，我会审查任何我认为无论现在还是将来需要实际扩展的内容。

I don't even believe how you're describing how you yourself use AI so I don't know what to think. 我甚至不相信你描述的你自己使用 AI 的方式，所以我不知道该怎么想。

It is impossible for somebody who cannot write code to review it. Actual developers will start to be unable to judge what is quality code within a year or handing everything off to AI. 对于一个不会写代码的人来说，审查代码是不可能的。真正的开发者在一年内就会开始无法判断什么是高质量代码，因为他们把一切都交给了 AI。

We are well aware of this phenomenon. It is why pilots have to fly a few months every year without autopilot to stay certified. 我们非常清楚这种现象。这就是为什么飞行员每年必须有几个月在没有自动驾驶的情况下飞行以保持认证的原因。

We have a huge problem in the industry right now where engineers just shut off their brains. It’s absolutely infuriating. 我们行业现在有一个巨大的问题，工程师们只是关闭了他们的大脑。这绝对令人愤怒。

The best way to think of AI is as a cracked intern. It copies what it sees in the codebase and still needs guidance. 看待 AI 的最好方式是把它看作一个疯狂的实习生。它复制在代码库中看到的内容，但仍然需要指导。

When it comes time to evolve systems the human brain still wins (for now). If you don’t have a high-level view of how your system works you can’t evolve its capabilities. This is where is see the biggest issues with AI today in engineering. 当涉及到进化系统时，人类大脑仍然胜出（目前为止）。如果你没有系统如何工作的高级视图，你就无法进化其功能。这就是我今天在工程领域看到 AI 最大的问题所在。

No, you’re not crazy. I also think it’s wild you were told to test out your new interview question on candidates right away instead of testing on existing employees first for feedback and calibration. 不，你没疯。我也觉得你被告知直接在候选人身上测试你的新面试问题，而不是先在现有员工身上测试以获取反馈和校准，这很疯狂。

Is there actual engineering here any more? To me engineering is proofs, facts, numbers, evidence… AI is a slot machine, I put in a prompt and cross my fingers that it works… when it doesn’t where is my traceability? What do I do differently in the future… I’m so confused. 这里还有真正的工程吗？对我来说，工程是证明、事实、数字、证据……AI 是老虎机，我输入一个提示词，然后祈祷它能工作……当它不能工作时，我的可追溯性在哪里？未来我该做些什么不同的事情……我太困惑了。

This is pretty standard from what I’ve seen at my company. A lot of people are losing their ability to actually critically think and understand things, and it’s not good. 根据我在我公司所见，这是相当标准的。许多人正在失去实际批判性思考和理解事物的能力，这不好。

There’s probably a reason they looking for a job. Candidates like that are basically Claude proxies, why do you even need them for - they’d likely be useless on-call. 他们找工作可能是有原因的。这样的候选人基本上就是 Claude 的代理，你甚至需要他们做什么——他们很可能在值班时毫无用处。

Our interview process has transitioned to handling on call situations to gauge a candidates ability to use AI to get a decent first time to respond SLA. 我们的面试流程已经转变为处理“待命”（on-call）情境，以评估候选人利用人工智能实现理想的首次响应服务等级协议（SLA）的能力。