[译] Eight Myths on Software Engineering and GenAI

sourceUrl: https://queue.acm.org/detail.cfm?id=3807963

Examining the most common misconceptions

审视最常见的误解

Jenna Butler, Brian Houck, Margaret-Anne Storey, Travis Lowdermilk, Steven Clarke, and Emerson Murphy-Hill

Jenna Butler、Brian Houck、Margaret-Anne Storey、Travis Lowdermilk、Steven Clarke、Emerson Murphy-Hill

Abstract

摘要

Generative AI is reshaping software engineering—but the narrative has gotten ahead of the evidence. Marketing claims, anecdotal wins, and misread studies have given rise to a set of persistent myths that are quietly driving poor decisions about AI adoption, tooling, and how to measure success.

生成式 AI 正在重塑软件工程，但围绕它的种种说法已经跑在证据前面。营销宣传、零星的成功案例，以及对研究的误读，共同催生出一套挥之不去的迷思，悄然影响着人们对 AI 采用、工具选型和成效衡量的判断，甚至导致错误决策。

This article examines eight of the most common misconceptions. We already know developers don’t actually spend most of their time writing code, with studies at Microsoft and elsewhere showing it’s closer to 14 percent. That means AI code generation, even when it works well, touches a surprisingly small slice of the actual job. And yet organizations are doubling down on lines-of-code metrics to track AI’s impact, which is a measure that is neither statistically valid nor meaningfully connected to outcomes such as software quality or delivery speed.

本文考察其中最常见的八种误解。我们已经知道，开发者并没有把大部分时间花在写代码上；微软等机构的研究表明，这一比例更接近 14%。这意味着，即便 AI 代码生成表现良好，它所触及的也只是实际工作中小得出人意料的一部分。可许多组织仍在加码使用代码行数来追踪 AI 的影响——这个指标既经不起统计有效性检验，也与软件质量、交付速度等结果没有实质联系。

The reality is messier and more interesting than the headlines suggest. AI works better for some tasks, some developers, and some contexts than others. Productivity gains don’t flow automatically from handing engineers a license—they require rethinking workflows at the organizational level. Adoption stalls when developers don’t trust the tools, lack time to learn them, or worry about de-skilling. And the “startups move fast with AI” narrative ignores the compliance, legacy systems, and reliability constraints that define enterprise software.

现实比新闻标题所暗示的更复杂，也更有意思。AI 在某些任务、某些开发者和某些情境下效果更好，在另一些情况下则未必如此。给工程师发一个工具许可证，并不会自动带来生产力提升；组织还必须重新思考自身的工作流程。当开发者不信任工具、没有时间学习，或担心技能退化时，采用过程就会停滞。“创业公司借助 AI 飞速前进”这套说法，也忽略了企业软件所特有的合规、遗留系统与可靠性约束。

This article isn’t skeptical, but rather provides practitioners, team leads, and engineering leaders a clearer, research-backed picture so the decisions organizations make about AI are grounded in evidence, not just enthusiasm.

本文并非对 AI 持怀疑态度，而是希望为从业者、团队负责人和工程管理者呈现一幅更清晰、由研究支撑的图景，让组织有关 AI 的决策建立在证据之上，而不只是出于热情。

Generative AI is transforming software engineering at a pace that has outstripped both empirical research and organizational practice. In this rapidly evolving landscape, myths and misconceptions are often amplified by marketing claims, anecdotal success stories, and misinterpreted studies. Drawing on recent large-scale studies, interviews, and field observations, this article highlights eight of the most persistent myths about AI in software engineering, unpacking the evidence behind each one. The goal is to provide a clear, research-backed foundation for understanding AI’s real impact so organizations can make informed decisions about adoption, measurement, and investment.

生成式 AI 改变软件工程的速度，已经超过了实证研究和组织实践跟进的速度。在这片迅速演变的领域里，营销宣传、轶事式成功案例和遭到误读的研究，往往会放大种种迷思与误解。本文结合近期的大规模研究、访谈和实地观察，选取软件工程领域最顽固的八个 AI 迷思，逐一梳理其背后的证据。我们的目标，是为理解 AI 的真实影响提供一个清晰、有研究依据的基础，帮助组织对采用、衡量和投资作出知情决策。

Myth 1: Developers Spend Most of Their Time Writing Code

迷思一：开发者大部分时间都在写代码

Software engineering is a highly demanding job that involves creativity, long periods of focus, much collaboration—and, surprisingly, relatively little time actually writing code. Software isn’t written in a vacuum and, as such, developers need both to spend time independently writing code and in group activities such as meetings, standups, planning, and code reviews. Multiple research projects have looked at how developers spend their days and their time—and the results clearly show that developers don’t spend most of their time coding.

软件工程是一项要求极高的工作：它需要创造力、长时间专注，也需要大量协作；令人意外的是，真正用来写代码的时间却相对不多。软件从来不是在真空中写出来的。因此，开发者既要独立编写代码，也要参加会议、每日站会、规划和代码评审等集体活动。多项研究考察过开发者一天如何度过、时间如何分配，结果都清楚表明：写代码并不占据他们的大部分时间。

A study of more than 450 engineers at Microsoft in 2025 showed developers spend only 14 percent of their time writing code, reflecting what has been found in studies over the years. One of these studies found that on a “good” workday, engineers spent 18 percent of their time “coding” (not including bug fixing, testing, etc.), while on a “bad” workday, only 11 percent of time was spent coding. This highlights how slim the margins can be between a good and a bad day.

2025 年一项覆盖微软 450 多名工程师的研究发现，开发者只有 14% 的时间用于写代码。这一结果与多年来的其他研究相呼应。其中一项研究发现，在“顺利”的工作日里，工程师有 18% 的时间用于“编码”（不包括修复缺陷、测试等）；而在“不顺利”的工作日里，编码时间只有 11%。由此可见，一个工作日是顺利还是不顺利，差距可能相当微妙。

A June 2025 study of Microsoft developers looked at their use of AI, and one developer brought up this very point:

2025 年 6 月，一项针对微软开发者使用 AI 情况的研究中，就有一名开发者提到了这一点：

“For me, at my level, I do spend a lot of time on design. So like coding is [one] aspect, but a lot of time is also spent on design and meetings.”

“就我而言，到了我现在这个层级，确实会花很多时间做设计。编码只是其中一个方面，设计和开会同样会占去大量时间。”

“I think that and where it’s hard to say, like, I think there’s kind of upper bound on how much of my job I could use it for… And the actual, like, amount of time spent coding… feels relatively small in a week.”

“这很难说清楚。我觉得，我的工作中能用到它的部分大概存在一个上限……而且每周真正花在编码上的时间……感觉其实相当少。”

Myth 2: Writing Code Is the Bottleneck

迷思二：写代码是瓶颈

Given the above time distribution, using generative AI solely to assist in writing code addresses only a small fraction of the software engineering workload. If developers spend only about 15 percent of their time typing in the editor, then even an AI assist that makes coding twice as fast would, in theory, improve developers’ overall productivity by less than 15 percent. The other 85 percent of their time remains untouched.

从上述时间分配来看，如果只用生成式 AI 辅助写代码，它所覆盖的仅是软件工程工作量中的一小部分。假如开发者只有大约 15% 的时间在编辑器里敲代码，那么即便 AI 能把编码速度提高一倍，理论上也只能让开发者的整体生产力提升不到 15%。剩余 85% 的时间完全没有受到影响。

Accelerating code creation without addressing surrounding tasks (such as design work, understanding legacy code, setting up environments, etc.) can have unintended consequences. If AI enables developers to churn out code faster, it can simply move the pressure downstream. For example, producing more code quickly means more code that needs to be reviewed, tested, and integrated into the product.

如果只加快代码产出，却不处理周边任务——例如设计、理解遗留代码、配置环境等——还可能带来意料之外的后果。AI 让开发者更快地产出大量代码，可能只是把压力转移到下游。比如，代码生成得越多越快，需要评审、测试并集成进产品的代码也就越多。

The overall development cycle is only as fast as its slowest phase, and coding is often not the slowest phase. Therefore, using AI primarily as a code generator—while helpful for individuals—is not necessarily the best way to use AI to ship software faster. It tackles the “inner loop” of writing code in the IDE but leaves the “outer loop” of development largely unchanged. The same developer said:

整个开发周期的速度取决于其中最慢的环节，而编码往往并不是最慢的环节。因此，把 AI 主要当作代码生成器，虽然对个人有帮助，却未必是利用 AI 加快软件交付的最佳方式。它解决的是在 IDE 中编写代码的“内循环”（inner loop），却基本没有改变开发过程的“外循环”（outer loop）。刚才那名开发者还说：

“So in that sense, like I feel like the number of points in my job work that are even touched by GitHub Copilot are relatively small.”

“所以从这个意义上说，我感觉自己的工作中真正能被 GitHub Copilot 触及的环节其实很少。”

Myth 3: Lines of Code Written by AI Is the Best Measure of Impact

迷思三：AI 编写的代码行数是衡量影响的最佳指标

“Measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs.” —Bill Gates

“用代码行数衡量软件生产力，就像用飞机的重量衡量航空业的进步。”——比尔·盖茨

In 2014, “A statistical study of the relevance of lines of code measures in software projects,” was published, the abstract of which concludes with “We find that it [lines of code] fails to meet the specified validity tests and, therefore, has limited utility.”

2014 年发表的《代码行数指标在软件项目中相关性的统计研究》，在摘要末尾得出了这样的结论：“我们发现，它［代码行数］未能通过规定的有效性检验，因此用途有限。”

Despite this decade-old research, many organizations still rely on lines of code as a measure of developer productivity. With the rise of AI, this metric has evolved into tracking the number of AI-generated lines of code—a figure that has even been reported publicly by companies including Microsoft. Lines of code (and other single-point metrics such as story points), however, are neither statistically valid nor meaningful indicators of impact.

尽管这项研究已经发表十余年，许多组织仍依赖代码行数来衡量开发者生产力。随着 AI 兴起，这一指标又演变成对 AI 生成代码行数的追踪，微软等公司甚至公开披露过这一数字。然而，无论是代码行数，还是故事点等其他单一指标，在统计上都不具备有效性，也无法真正体现实际影响。

Worse, these metrics often incentivize teams to “game” the system, making it harder to assess real outcomes. In unhealthy organizational cultures, such measures can foster toxic behaviors and erode developer trust. When developers feel pressured to prioritize coding volume over collaboration, they may compromise on design quality, leading to increased technical debt and heightened security vulnerabilities.

更糟的是，这些指标常常会激励团队“钻制度的空子”，反而让真实成果更难评估。在不健康的组织文化中，这类衡量方式还可能助长有害行为，侵蚀开发者的信任。如果开发者在压力下不得不把代码产量置于协作之上，就可能牺牲设计质量，造成更多技术债务和更严重的安全隐患。

Ironically, efforts to improve coding velocity—such as through AI-assisted code generation—can amplify longstanding challenges in software engineering. As developers produce more code, the volume of work requiring review, testing, and maintenance also grows, increasing the risk of technical debt. Software engineering companies do not have a goal to maximize the amount of code written, and the evaluation of AI's impact on software engineering should reflect that. Measuring success by code volume alone misrepresents the true objective: delivering secure, maintainable, and high-quality software.

讽刺的是，借助 AI 生成代码等提升编码速度的举措，可能会放大软件工程中长期存在的问题。开发者产出的代码越多，需要评审、测试和维护的工作量也越大，技术债务的风险随之上升。软件工程公司的目标并不是让代码量最大化，因此，对 AI 在软件工程中影响的评估也应体现这一点。仅凭代码量衡量成效，歪曲了真正的目标：交付安全、可维护、高质量的软件。

Myth 4: AI Helps All Tasks and Engineers Equally

迷思四：AI 对所有任务和所有工程师的帮助都一样

Research on GenAI development tools has found mixed results—while many studies find large productivity gains, others see neutral effects, and recently one even found a negative effect on productivity. Why the discrepant results? Right now, we are using AI as a hammer and treating code as a nail, but the evidence suggests many things impact whether GenAI will be successful for a particular coding task—from the nature of the task itself to the skills of the developer.

关于生成式 AI 开发工具的研究，结论并不一致：许多研究发现生产力大幅提升，另一些研究则观察到中性效果，近期甚至有一项研究发现生产力出现下降。为何结果相差如此之大？眼下，我们把 AI 当成一把锤子，把代码都看成钉子。但证据表明，生成式 AI 能否成功应对某项编码任务，受到许多因素影响——从任务本身的性质，到开发者的能力，都是如此。

The 2024 Microsoft Report on AI and Productivity Research found that tasks that are familiar and well understood result in larger efficiency gains when using Copilot compared with tasks that are unfamiliar and less understood. The report also found that software development experience and AI assistance experience can positively influence the impact of Copilot usage.

《2024 年微软 AI 与生产力研究报告》发现，与陌生且理解不深的任务相比，使用 Copilot 处理熟悉、理解充分的任务，效率提升更为明显。报告还发现，软件开发经验以及使用 AI 辅助工具的经验，都会对 Copilot 的使用效果产生积极影响。

Also in the report, problem-solving styles and motivation were shown to impact the success of Github Copilot code generation. Developers who use a comprehensive approach for information processing are more confident in generating successful prompts. In addition, those who feel personally motivated to use technology (as opposed to being forced to) are more confident in generating prompts. Additionally, years of professional software development experience is inversely correlated with confidence in writing effective prompts.

这份报告还表明，解决问题的方式和使用动机都会影响 GitHub Copilot 生成代码的成功率。采用综合方式处理信息的开发者，更有信心写出有效的提示词。出于个人意愿使用技术的人——而不是被迫使用的人——在编写提示词时也更有信心。此外，专业软件开发经验的年限，与开发者对自己写出有效提示词的信心呈负相关。

When looking at experienced developers in the open source world, a 2025 study found that AI tools actually increased implementation time by 18 percent on average. In addition, studies have found that GenAI is more effective for “code-intensive” tasks such as boilerplate and repetitive work, but not for more creative or collaborative tasks. Additionally, even how a prompt is crafted can greatly impact the success of using GenAI for coding tasks. One study found that rewriting the prompt but keeping it semantically equivalent led to different code in 46 percent of cases and a change in correctness in 28 percent.

在考察开源社区中的资深开发者时，一项 2025 年的研究发现，AI 工具实际上让实现任务的平均耗时增加了 18%。还有研究发现，生成式 AI 更适合样板代码、重复性工作等“代码密集型”任务，而不太适合更具创造性或协作性的任务。此外，提示词的写法本身也会显著影响生成式 AI 完成编码任务的效果。一项研究发现，在语义保持不变的前提下改写提示词，有 46% 的情况生成了不同的代码，有 28% 的情况代码正确性发生了变化。

GenAI can offer substantial benefits for software engineering, but its effectiveness depends on a complex interplay of factors. Task characteristics, developer experience, familiarity with the codebase, confidence, and prompt-crafting skills all shape outcomes. In short, success with GenAI is highly context dependent—there is no universal formula for making it effective.

生成式 AI 可以为软件工程带来可观收益，但它是否有效，取决于多种因素的复杂交互。任务特征、开发经验、对代码库的熟悉程度、信心，以及编写提示词的能力，都会左右结果。简而言之，生成式 AI 能否成功高度依赖具体情境，并不存在一套放之四海而皆准的有效公式。

Myth 5: AI Will Turn Individual Developers into 10x Developers

迷思五：AI 会把单个开发者变成“10 倍效能开发者”

One of the most persistent myths in the discourse around AI and software engineering is that AI tools—such as GitHub Copilot—will transform individual developers into “10x developers,” dramatically multiplying their productivity.

围绕 AI 与软件工程，最顽固的迷思之一，就是 GitHub Copilot 等 AI 工具会把单个开发者变成“10 倍效能开发者”，让个人生产力成倍暴增。

As mentioned previously, however, this narrative overlooks the collaborative and interconnected nature of real-world software development and the complexity of real-world coding tasks (many prior studies looked at toy examples and not real-world code). While controlled studies may show impressive productivity gains for individuals working on isolated tasks, these results rarely translate directly to the complex, team-based environments where most software is built. The “55 percent productivity gain” is context dependent. Productivity gains measured in isolation do not account for the coordination, collaboration, and knowledge sharing that are essential to successful software delivery.

但如前所述，这套叙事忽视了现实软件开发中协作密切、环环相扣的特点，也忽视了真实编码任务的复杂性——此前许多研究考察的是玩具式示例，而非真实代码。受控研究也许能显示，个人完成孤立任务时生产力提升惊人；但这些结果很少能直接迁移到大多数软件实际构建所在的复杂团队环境中。所谓“生产力提升 55%”取决于具体情境。孤立测得的生产力提升，并没有计入成功交付软件所必需的协调、协作和知识共享。

As has been reported elsewhere, much of the difference in performance among developers is attributable to the task they are performing. While one developer might perform better than another on one task, that doesn’t mean they consistently perform better on all tasks. This suggests that (as argued throughout this article) task characteristics, context, and fit play a huge role in performance.

正如其他研究所指出的，开发者之间相当一部分绩效差异，源于他们所执行的任务。某名开发者在一项任务上可能胜过另一名开发者，却不代表他在所有任务上都始终表现更好。这说明——也正是本文反复论证的——任务特征、具体情境以及人与任务是否匹配，对实际表现有着巨大影响。

Myth 6: It’s Up to Each Developer to Make AI Work

迷思六：应该由每位开发者自己设法让 AI 发挥作用

Currently, most studies of AI and software engineering look at how an individual engineer is augmented with a GenAI tool. This places the burden of improved productivity from GenAI on the engineers themselves. Historically, gains in productivity have come not from changes at the individual level but from systematic changes at the organization level.

目前，大多数关于 AI 与软件工程的研究，都在考察单个工程师如何借助生成式 AI 工具提升能力。这等于把利用生成式 AI 提高生产力的责任压在工程师个人身上。然而从历史上看，生产力的提升并非来自个人层面的改变，而是源于组织层面的系统性变革。

Stated best in his New Yorker article, Cal Newport, professor of computer science at Georgetown University, explains: “Historically, optimizing systems to increase productivity was exceedingly difficult. The assembly line didn’t arrive in a flash of self-evident insight. Ford suffered through numerous false starts and incremental experiments. He had to invest significant amounts of money and develop new tools… Now we casually ask individual knowledge workers to undertake similarly complex optimizations of their own proverbial factories, and to do it concurrently with all the work they’re attempting to streamline.”

乔治城大学计算机科学教授卡尔·纽波特（Cal Newport）在《纽约客》的一篇文章中对此作了极为精辟的解释：“纵观历史，通过优化系统来提高生产力一直极其困难。流水线并不是灵光一现、自然而然地诞生的。福特经历了无数次错误尝试和渐进实验，不得不投入巨额资金并开发新工具……如今，我们却若无其事地要求每一位知识工作者，对自己那座比喻意义上的工厂完成同样复杂的优化，而且还要一边优化，一边继续完成他们试图精简的全部工作。”

These tools were often introduced to engineers with minimal guidance. GenAI may be one of the first technologies where organizations have invested millions in licenses without a clear understanding of how to maximize its value. Use cases are emerging organically from the ground up while researchers work to identify best practices. The absence of the dramatic productivity gains many expected suggests that access alone is not enough. To fully realize the potential of GenAI, we need to rethink the systems and processes of software engineering at an organizational level—creating environments where developers can achieve greater impact within a more productive ecosystem.

这些工具交到工程师手中时，往往几乎没有配套指导。生成式 AI 或许是最早出现的这样一种技术：组织花费数百万购买许可证，却并不清楚怎样才能让它的价值最大化。实际用例正自下而上地自然涌现，研究人员则仍在探索最佳实践。许多人期待的生产力大幅跃升并未出现，这说明只有工具使用权远远不够。要充分释放生成式 AI 的潜力，我们必须从组织层面重新设计软件工程的系统与流程，营造一个生产力更高的生态，让开发者在其中创造更大的影响。

Myth 7: High-Performing AI Tools Will Be Adopted Automatically

迷思七：表现出色的 AI 工具自然会得到采用

The assumption that software engineers will adopt AI tools simply because they improve their performance overlooks a complex web of social, organizational, and cognitive barriers. Recent research shows that developers—especially women and older engineers—face a “competence penalty” when using AI, receiving harsher evaluations for AI-assisted work even when the output is identical. Trust is also an issue: while 80 percent of developers use these tools, only 29 percent trust their accuracy, and many report spending more time debugging AI output than writing code themselves. This undermines the promised productivity gains and adds cognitive load.

认为 AI 工具只要能改善绩效，软件工程师就会采用它，这种假设忽视了社会、组织和认知层面盘根错节的障碍。近期研究表明，开发者——尤其是女性和年龄较大的工程师——使用 AI 时会遭遇“能力惩罚”：即便产出完全相同，借助 AI 完成的工作也会受到更苛刻的评价。信任同样是个问题：虽然 80% 的开发者在使用这些工具，却只有 29% 相信其准确性；许多人还表示，自己调试 AI 输出所花的时间，比亲自写代码还多。这既削弱了工具承诺的生产力收益，也增加了认知负担。

Moreover, AI tools often don’t integrate smoothly into existing workflows. Developers are already stretched thin and may lack the time or organizational support to learn new tools, especially when those tools don’t address their actual pain points. Ethical concerns—ranging from environmental impact to training data provenance—also play a role, as does fear of de-skilling or job displacement. Engineers worry that overreliance on AI could erode their problem-solving abilities and make them less indispensable. Ultimately, adoption is not just about tool quality—it’s about trust, context, and the human experience of work.

此外，AI 工具往往无法顺畅融入现有工作流程。开发者本就疲于应付各项工作，未必有时间学习新工具，也可能得不到组织支持；如果工具解决不了他们真正的痛点，情况更是如此。从环境影响到训练数据来源等伦理问题，也会影响采用意愿；人们还担忧技能退化或岗位被取代。工程师担心，过度依赖 AI 会削弱自己的问题解决能力，让自身变得不再不可替代。归根结底，采用与否不只取决于工具质量，还取决于信任、情境，以及人在工作中的切身体验。

Myth 8: With GenAI, Enterprises Can Innovate at Startup Speed

迷思八：有了生成式 AI，企业也能以创业公司的速度创新

Generative AI has led to a common assumption: if a small startup can ship features rapidly, why can’t a large enterprise do the same? While AI accelerates development across the board, structural differences between startups and enterprises make this comparison misleading.

生成式 AI 催生了一种常见假设：既然小型创业公司能快速交付功能，大型企业为什么不能？AI 的确能普遍加快开发，但创业公司与企业之间存在结构性差异，使得这种比较带有误导性。

Startups typically build on open-source components and widely documented frameworks—resources that were heavily represented in the training data for large language models. Enterprise systems, by contrast, rely on proprietary tools and legacy codebases that AI models have never seen. Beyond technical complexity, enterprises operate under compliance, security, privacy, and regulatory requirements that apply only at scale—constraints most startups never encounter.

创业公司通常基于开源组件和文档丰富的框架构建产品；这些资源在大语言模型的训练数据中占有很大比重。相比之下，企业系统依赖专有工具和 AI 模型从未见过的遗留代码库。除了技术复杂性以外，企业还要遵守规模化运营才会面对的合规、安全、隐私和监管要求，而大多数创业公司从未遭遇过这些约束。

GenAI also performs best in greenfield scenarios, yet enterprise software must maintain backward compatibility and integrate seamlessly with thousands of internal systems and third-party tools. The goals differ as well: startups prioritize speed to MVP and rapid iteration, while enterprises balance velocity with reliability, security, and contractual obligations.

生成式 AI 在绿地场景——也就是从零开始的全新项目——中表现最佳；企业软件却必须保持向后兼容，还要与数以千计的内部系统和第三方工具无缝集成。双方的目标也不同：创业公司优先追求快速推出最小可行产品（MVP）并迅速迭代，企业则必须在速度、可靠性、安全性和合同义务之间取得平衡。

Customer expectations further diverge. Startups can release alpha versions with bugs and receive tolerance from early adopters. Enterprise customers expect polished, production-ready solutions—and regulatory and contractual frameworks demand it. AI can help both startups and enterprises move faster, but structural realities mean they will never operate under the same conditions. Speed is visible; complexity is not.

两者面对的客户预期也大相径庭。创业公司可以发布带有缺陷的 Alpha 版本，早期采用者往往能够容忍；企业客户则期待经过充分打磨、可直接投入生产的解决方案，监管和合同框架也要求企业做到这一点。AI 可以同时帮助创业公司和企业加快步伐，但结构性现实决定了双方永远不会在相同条件下运作。速度看得见，复杂性却看不见。

Conclusion

结论

The myths explored in this document reveal just how complex the impact of generative AI is on software engineering. While AI tools can accelerate certain tasks, their benefits are often overstated or misunderstood—especially when it comes to how developers actually spend their time, what productivity means, and how improvements in one part of the workflow can create new challenges elsewhere. The evidence shows that context matters: Task type, developer experience, team dynamics, and organizational systems all shape the outcomes of AI adoption. Lines of code and speed alone are poor proxies for real progress. Ultimately, realizing the full value of AI in software engineering requires moving beyond hype and simplistic metrics and instead focusing on the broader goals of building secure, maintainable, and high-quality software.

本文讨论的这些迷思，揭示了生成式 AI 对软件工程的影响究竟有多么复杂。AI 工具虽能加快某些任务，但其收益经常被夸大或误解；在开发者究竟如何分配时间、生产力究竟意味着什么，以及工作流程中一个环节的改善会怎样在其他环节制造新问题等方面，尤其如此。证据表明，情境至关重要：任务类型、开发者经验、团队动态和组织系统，共同塑造着 AI 的采用结果。单凭代码行数和速度，无法恰当地代表真正的进步。归根结底，要在软件工程中充分实现 AI 的价值，就必须超越炒作与简单化指标，转而关注更宏大的目标：构建安全、可维护、高质量的软件。