AI生成代码占42%,但96%的开发者不信任?恶意代码检测工具来把关

检测维修 0 48

您想知道的人工智能干货,第一时间送达

作者丨SEDaily译者丨明知山策划丨Tina

针对这段代码, 我予以批准使其投入生产环境, 一并承担附带着的全部风险。2026年最为重大的挑战, 便是寻觅到那种敢于说出这话的人。

AI编码不再是尝鲜工具, 而是进入到生产环境。Sonar每日分析7500亿行代码, 在其最新的《开发者代码现状调查报告》里, 他们瞧见一个相当刺眼的矛盾: 72%的开发者每日运用AI编码工具, 42%的代码已由AI生成或者辅助得以完成, 然而96%的开发者依旧没法全然信任AI生成的代码。

这么个情况意味着, 软件工程正处在从“怎样去写成更多的代码”这种状态的转变过程中, 而转变的方向是朝着另外一个更麻烦的难题去的。代码能够依靠人工智能进行批量的生成这个结果出现了, 但这时就有新问题冒出来了, 那就是谁能够去确认它是完全安全的、足够可靠的以及具备可维护性的? 还有谁敢去动笔签字让这样的代码上线运行? 如此一来这也就变成了在2026年工程团队肯定无法避开的挑战了。

Sonar是一家公司, 这家公司专注于代码质量与安全分析, 其核心产品SonarQube已被全球超过700万开发者使用。在本期节目中, Sonar企业营销高级副总裁Chris Grams、产品营销与开发者关系副总裁Manish Kapur,与具有二十余年工程管理经验的Matt Merrill进行了讨论, 讨论的内容是这份报告背后的真实信号, 这个信号是: AI为什么会让代码生成得更快, 却又让审核、测试、治理变得更重? 35%的开发者为何会绕开企业授权工具去使用“影子AI”? AI生成代码为何不一定得重新构建审核流程, 反倒更需要确定性校验、质量门禁以及人工责任制?

当人工智能从用于实验的工具转变为用以开发的基础设施时, 真正的瓶颈并非代码产出, 而是信任, 是质量, 还有责任。

AI 代码的信任鸿沟:42% 生成率与 96% 不信任”

Matt Merrill: 于现下这般时光里, 我与那来自 Sonar 的两位嘉宾一道, 就《开发者代码现状调查报告》展开一番交流探讨。在正式开启此番交流之前, Manish以及 Chris, 二位能不能先行简略讲一讲自己, 说一说个人的背景状况, 还有在 Sonar 各自所承担的工作呢?

马特·梅里尔: 那声纳? 要是有听众对声纳不太熟悉, 二位能不能简要介绍一下这家公司从事什么业务, 都供应哪些产品?

Matt Merrill称: 我仔细阅读了这份调查报告, 它极具趣味性。作为一个有着工程领导背景的人士、之前主要是从事后端工程等相关工作的人, 我的第一反应是: 为何又出现了一份调查报告? 它与Stack Overflow调查报告存在哪些不同之处? 然而深入去阅读之后, 我发觉这份报告实在非常独特。要是可以的话, 你们觉得从这份调查当中能够收获哪些Stack Overflow调查没办法提供的内容呢?

Matt Merrill称, 他特喜欢所谓的"人文视角", 而这恰是他的感受, 你们竟借这些数据讲了个很棒的故事。他满心好奇, 能不能介绍下这份数据收集的时候, 还有接着分析的方式呀。必须得说, 这份报告做得相当出色!

马特· Merrill 表示已就调查的背景内容聊了好多, 接下来要正式步入调研结果部分。先从重磅发现着手, 这个情况想请二位都谈谈。克里斯, 你能先讲讲, 你最直观且最深刻的收获是啥, 哪些内容最能引发你们的共鸣?

代码快了,工程慢了

马特·梅里尔表示, 综合其自身实际经历以及日常所开展的工作来进行观察,这样所得出的结论是全然具备合理性的。其越来越频繁地听闻有关于智能体代码审查方面的事情, 甚至已然出现了促使智能体彼此之间进行校验、实施交叉验证的行为举措。这无疑是一项极具趣味性的发现。马尼什, 你所获取到的最大收获究竟是什么呢?

Matt Merrill表示, 自己也是满怀期待, 急切渴望见证后续的进展情况。说到AI工具的迅速普及时, 他在日常工作期间发现了这样一个现象, 即开发者们一般都会主动地想要运用这类工具。一方面, 行业环境造成了无形的促使压力;另一方面, 他们自身的探索意愿也持续地在增强。有许多开发者会运用个人账号去处理工作事务、访问AI工具, 仅仅是为了提高工作效率、尝试新兴技术。你们的报告里也提及了不少有趣的调研结果, 能不能方便地和我们分享一下呢。

于管控治理方面, 存在着这样一条始终未曾改变的核心原则, 即在使用不论是企业合规工具还是个人第三方工具时, 那所有经 AI 生成出来的代码, 都必然得要经过严格的核验才行, 而且后续全程的各个管控环节一个都不能遗漏。企业得在下大力气对审核力度予以强化的基础上, 全方位校验代码的可靠性, 得以保证代码能够直接投入到生产相应的环境当中去使用。

Matt Merrill表示, 就在今日, 公司隐私合规部门的同事专门着重强调, 要是团队运用AI工具, 一定要把相关合规要求归入合作协议, 使之与软件开发行业的规范标准达成一致。当下清晰地展现出一种本末倒置的状况, 即全员都在无奈地被迫拥抱AI工具, 然而与之对应的合规管控以及风险约束机制却极度严重地滞后。这个问题的确是值得予以重视的。Chris, 针对这份调研结论, 你还有别的内容想要进行补充吗?

Matt Merrill表示, 确实是这样的情况。一直到去年11月的时候, 那时完全没办法对哪一款工具更具优势做出判定。然而在有了体验Claude之后, 就不得不承认它的表现是极其出色的。除此以外, 企业的流程迭代速度远远赶不上技术变革的节奏, 所以开发者自行去注册然后试用新兴工具也就变成必然的势态, 这种现象的出现其实并不难理解。

AI 消灭了重复劳动,但新的低效工作正在生成

Matt Merrill: 的确如此这般。咱们更换另外一个话题。在这份报告当中存在着两个内容使得我格外予以关注, 其中的一个是“低效工作转移”这样的一个概念。可不可以为我们阐释解读一下这个概念, 以及与之相关联的调研所发现的情况呢?

Matt Merrill称, 我常常会用一个类比, 去跟身边的人探讨这类问题, 也许它并非全然贴切, 可却是与当下的状况极为贴合的, 那就是, 在电子表格问世以后, 会计行业并未消失, 仅仅是工作内容出现了变化。对于AI在开发行业的情况而言, 道理也是一样的。“低效工作转移”这个定义恰如其分, 我在之后也会继续采用这个说法。

Matt Merrill表示: 完全予以认同。Sonar具有这样一个核心产品, 该产品是静态代码分析工具。不知是否能够请您分享一下, 目前情况下客户在借助静态代码分析技术之际皆是通过哪些创新形式去应对AI编码所带来的各种各样的隐患以及挑战呢?

推出了 MCP 服务器的我们, 有不少大型企业客户目前正在应用使用 SonarQube 的 MCP 服务器, 此服务器作为智能体对接 SonarQube 代码分析能力的网关的存在, 采用了智能体通用通信协议, 能为智能体开发环境、命令行工具等各类平台给予服务, 除常规代码分析外头, 我们也在不断优化检测引擎, 专门针对 AI 引发的漏洞增添识别能力。我国的产品具备自身定义规则配置的支持能力, 已经有一部分客户借助增添自定义规则来特地辨认人工智能编码所带来的风险模式。与此同时, 我们还在内部设置了多条专属的检测规则, 用来预防人工智能衍生出的风险, 像提示词注入攻击、规则文件后门攻击这样的情况。这类风险纯粹是由人工智能的编码行为而产出的, 在传统的人工开发模式之下基本上是不会出现的。

不需要重造流程,老的审核体系依然有效

Matt Merrill:你刚刚最后提到的那个风险是什么?

Matt Merrill 表示, 他大概弄清楚了这类后门攻击的原理, 比如说, 从 Claude 平台或者其他地方复制了一份配置文件, 在不经意间带入了大量隐蔽的 Unicode 字符, 然后借此篡改指令提示词, 大概就是这样的逻辑, 对吧?

马尼什·卡普尔表示, 情况就是如此, 那些不法的攻击者呀, 是依靠在这类文件当中植入隐藏的Unicode字符, 进而实施恶意的操作行为的。

AI编码工具使用现状_恶意代码检测工具_AI代码信任问题

马特·梅里尔表示: 这的确称得上是值得关注要点考量。若是跟实际场景一起来看, 也就是当如果我自己去编写功能配置, 再设计持续集成以及持续交付流程这些情形下, 那么能否进行接入你们的MCP服务器以及其他集成工具这样的行为, 进而把静态代码分析归入自动化校验方面环节, 并且同步输出检测结果。一旦检测出指定问题, 就能够终止构建流程的话, 这样的操作是不是能够得以实现呢?

大模型写代码各有脾气,怎么选比“谁更强”更重要

马特·梅里尔表示: 没错。你们于《开发者代码现状调查报告》里还提到并引用了一份有关大语言模型编码特征的专项报告 , 其内容极具价值。期望你能够简要介绍这份报告 , 以及当下调研所获得的相关结论。

请问, Matt Merrill所提及的模型特质, 能不能详细说一说这相关部分包括的具体内容。是否存在比较特殊、能让人觉得有意思的案例?

马特·梅里尔称, 确实有意思, 以这种方式更易让人记住各个模型的特点。如今行业早已走出小众定制范畴, 迈入规模标准化阶段。我发觉Opus 4.5的逻辑思考能力在细微程度上领先于Opus 4.6, 这一细节极具琢磨意味。在安全维度, 也就是针对每百万行代码的安全漏洞数量而言, 高配版GPT 5.2处于首位;从可靠性维度, 也就是在漏洞严重程度以及百万行代码问题密度板块, 高配版Gemini 3 Pro展现最佳状态, 各不同模型的优势领域差别极为显著。此外, 我留意到, 此次测评全是基于Java语言的。

这一点, 极其关键, 不同的模型, 针对不同的编程语言, 训练的侧重点, 有着显著的差异。

即便这样, 这份测评得出的结果仍是极具可供参考的价值。在结束这个话题以前, 两位还有对于排行榜或者模型特质的内容有没有想要补充的呢?

AI 让新人更快,也让经验更值钱

Matt Merrill表示, 我内心同样存有顾虑, 不禁会思索, 这类工具的定价是否会出现大幅度的暴涨情况? 厂商是否是想要先紧紧地锁住用户, 从而抢占行业龙头的地位? 在规划自身团队以及业务发展的时候, 这也是我一直以来都在思考的问题。

下面咱们说说从业的年限, 还有从业经验怎样对此次的调研结果产生影响。我在这个行业深入钻研已经有二十多年了, 我发觉这里面存在着一个现象特别值得深入探究。能不能讲一讲开发者的从业年限会以怎样的方式对他们对于 AI 工具的认知造成影响呢?

其中一点值得关注的是, Matt Merrill提到, 报告呈现, 借助AI编码工具, 初级开发者的工作满意度有显著提升。结合你们的分享, 这个结论是合乎情理的。我平时不使用社交平台, 不过你们说起的假期体验大模型, 我深有感触。当时平台给了免费体验额度, 我亲自试用后, 即便从业多年, 也完全改变了对这类工具效能的认知, 深受震撼。看来有相同感受的人不少, 这一点很有意思。

没错, 开发速度的确相当惊人。你说初级开发者对这类工具怀着特别高的热情, 而体验之后, 我已完全改变看法且满怀期待。我们探讨了去年10月到现在的改变, 并且我很想知道, 资深开发者的思想与认识是否也一同在发生转变? 从10月至今, 你们有没有察觉到相关改变呢?

快而不稳,不如不快

马特·梅里尔称, 在过去半年当中, 依据我曾为大型企业客户提供服务所积累的经验来看, 企业对于智能体以及AI编码工具的落地使用比率出现了大幅度的攀升情况, 这种变化是颇为显著明显的。另外还存在着一个饶有趣味的发现, 那就是AI于全新开展的开发项目以及老旧的存量项目里的落地成效差异是非常显著突出的。那么在那份报告里究竟有没有提及AI在哪一类场景之中的落地成效会更好一些、得到的认可度会更高一些呢?

Matt Merrill表示, 这个结论是全然契合客观逻辑的。另外, 存在一个他满怀好奇却还未曾验证的问题, 即自10月起始, 是否有团队尝试借助智能体MD说明文档或者同类的辅助文件来为老旧项目给予逻辑参考? 同时, 他们对于这类落地实践是否有所了解?

Matt Merrill: 稍微再问一下那最后一个相对较小的问题。这次调研当中的受访者涵盖了世界各个地方, 依照不同区域划分的开发者之间是不是存在着显著的地域化使用方面的差异呢?

Chris Grams称, 没有去统计并发布相关结论, 整体而言, 全球开发者面对的行业环境, 跟技术变革趋势基本是一致的, 筛选过有统计学意义的差异化数据, 然而并未找到足够显著的地域特征, 在全球任何地区, 所有人都在同步经历这场AI技术变革。

马特·梅里尔表示, 可以理解, 其只是单纯好奇。本次分享已接近尾声, 这次调研的内容使其收获满满。其脱离一线开发岗位、转入管理岗位已过去一段时间, 虽说仍会编写代码, 不过核心工作是以管理为主。从换位思考的角度来讲, 当下许多企业管理者会强制要求团队去落地AI工具, 部分目标是切合实际的, 然而也有不少要求脱离了现实。对于广大从业者而言, 要是上级制定了不切实际的AI落地目标, 那会给出哪些建议呢?

2026 年,管理者必须正视代码信任危机

Matt Merrill, 从普通开发者的视角来看, 此次调研最为关键的能给人以启发的点是什么呢?

马尼什·卡普尔指出, 对开发者来讲, 核心技能不再只是单纯地编写代码, 编码已然成了能被工具替代的基础能力, 未来的核心能力是读懂、校验智能体以及AI工具生成的代码, 完善审核机制, 搭建开发约束规则, 不管代码是由谁产出的, 最终责任归属仍在开发者身上, 从业者要恪守开发规范, 做好代码校验, 把控产出质量, 不必再一味执着于学习新的编程语言。

管理者不得不正眼去看待代码信任危机, 当下AI技术不断持续发展, 然而调研开始初期的一组要紧数据是值得所有的人去重视的, 即96%的开发者没办法完全信任AI生成的代码, 并非为工具产出那些代码质量不好, 实际上其水平一直持续在稳步获取提升, 核心的原因在于代码故障、安全漏洞所产生的后果不会由AI去承担, 最终责任还是归属于企业以及团队管理者。身为相关负责人, 一定要清晰界定代码的人工责任归属, 构建完备的审核系统, 严格把控上线关卡, 防止不加思索直接上线由AI生成的代码。若不是那种追求极致创新、能够承受试错风险的初创团队, 普通企业因掌握着大量用户数据以及核心业务信息, 就得严谨查验每一段代码的可靠性。

过去存在的难题在于怎样去产出更多的代码, 而这个问题早就已经被解决了。如今我们具备能够生成质量还算不错的优质代码的能力, 并且代码质量还处于持续提升的状态之中。

不过关键的难点之处在于, 得有专门的人员进行审核, 而且这人要愿意签字去确认, 内容是: “我批准把这段代码放入生产环境中, 并且承担随之而来的全部风险。”这一点, 将会成为2026年所面临的最大挑战。

Matt Merrill, 讲得颇具道理, 身为管理者, 对于调研所显示的, 66%的开发者不信任AI生成的代码这一情况, 我会想到, 必然要加入人工审核。以此引人细思的观点收尾甚为恰当。今晚的交流之中, 各位还有哪些内容是希图补充提及的呢?

克里斯·格拉姆斯称, 之前所提及的大模型排行榜项目在持续推进着, 每天都会去关注新上线的模型, 关注实测数据, 亲眼看到这类技术在持续不断地进步着, 当下存在着一段变革迅猛的时期, 自己的职业生涯遭遇过好多回行业转折, 相信你们二位也是如此, 然而像如今这般的变革盛况, 是从来未有遇到过的, 身处这个行业, 充满着挑战, 同时又乐趣满满, 前路稍微带着未知以及忐忑, 不过整体而言充满着意义, 十分感谢你的邀约以及交流。

Matt Merrill: 非常感谢二位的精彩分享。

查看英文原文:

https://softwareengineeringdaily.com/2026/04/23/hype-and-reality-of-the-ai-coding-shift

相关推荐: