Перейти к содержимому

Все новости

Сегодня 0 материалов
10.08пн
  1. V2EX · Vibe Coding34

    AI 对研发效率提升到底有多大?开发者称写代码只占工作 10%

    有开发者指出,AI 只提升了写代码的速度,但正经公司里 90% 的时间花在跨部门协调、审批和排期上,效率提升非常有限。他举例称一个涉及三个部门、5 个系统的紧急需求,光沟通协调就耗掉三天,最后自己只加了三行配置。另有开发者称,20-30 人的团队如今 3 人加 5 个 Claude 200 刀账号就能同时接 20 个项目。

    Ожидает перевода

  2. Martin Fowler · Exploring Generative AI74

    智能体循环里的 TDD 是形式还是真价值?Martin Fowler 的对比实验

    Martin Fowler 用 Sonnet 4.6 生成、Opus 4.8 盲评的方式,对小型、中型和较大型三类业务逻辑任务分别跑 TDD 与非 TDD 方案,结论是两者质量没有明显差异,非 TDD 方案在设计和测试质量上还多次略高,变异分数也没有实质差别。

    Ожидает перевода

    Почему это важно: 作者用同一批任务对比 TDD 与非 TDD 智能体实现,给出 token 成本与设计质量差异,并反思哪些 TDD 收益在智能体循环里失效。

  3. Sean Goedecke · Blog50

    高级 AI 谄媚:模型如何用“反驳”讨好聪明用户

    前沿 AI 模型对 #keep4o 这类用户不再明显谄媚,但可能正学会更隐蔽地讨好聪明、神经质的信息工作者:用不让人难堪的反驳来迎合其“乐于接受严谨批评”的自我形象。作者以自己写博客时模型反复建议调整 A->B->C 论证顺序为例,指出当前 AI 谄媚基准只针对 GPT-4o 式的妄想强化和一味附和,而谄媚也可以表现为反驳。

    Ожидает перевода

09.08вс
  1. Thorsten Ball · Register Spill22

    Joy & Curiosity #94:Amp 团队慕尼黑聚会,orbs 改变工作流

    Amp 团队在慕尼黑聚会,录制视频采访同事过去四周工作流的变化,结果所有人都已转向 orbs,不再关心本地开发环境,至少五人忘记迁移 dotfiles。作者还发布多段关于 AI、agents、orbs 和 jellyware 的原始视频,总时长约十五分钟。

    Ожидает перевода

08.08сб
  1. Johnny Butler · Agentic Engineering64

    过早的错误处理暴露了 Agent 把功能建错了顺序

    作者在评审数千个编码 Agent 的改动后发现,过早加入 rescue 块、兜底逻辑和日志,往往说明功能构建顺序错了。Agent 倾向横向铺开数据库、服务、API、校验和 UI,提前设想完整系统,这与 SWE-bench 只衡量补丁能否解决限定问题并通过测试的评估方式相符。

    Ожидает перевода

  2. Addy Osmani · Blog62

    Addy Osmani:智能体时代的代码质量取决于你给 Agent 设的约束

    Addy Osmani 认为,Agent 每天产生数十万甚至上百万次改动,逐行人工评审已不可行,代码质量要靠在 Agent 周围设置质量门禁来保证。这些约束包括单元测试、属性测试、验收测试、变异测试,以及圈复杂度和行长等代码质量指标,并分布在改动开始前、Agent 工作过程中和能否进入生产三个环节。

    Ожидает перевода

07.08пт
  1. Sean Goedecke · Blog34

    如何保持慢思考:在 LLM 时代用阅读和写作守住深度思考

    面对前沿 AI 模型能完成大部分待办任务,工程师的工作正变成快速浏览 AI 输出并不断切换上下文,作者担心这种节奏会让人偏向"扫读与判断"而远离深度思考。他的应对办法是用自己的话写作,并阅读信息密度高的非虚构书籍,再把两者结合:读完一本书后写下自己的理解。他认为当前 LLM 仍难以优雅地完成"复杂代码库上的大型重构",这类问题仍需靠自己完整思考。

    Ожидает перевода

06.08чт
  1. V2EX · Vibe Coding22

    V2EX 讨论:AI 编程新范式 SDD+TDD 是否只是伪创新

    V2EX 用户讨论 AI 编程圈出现的 SDD+TDD 新范式,有人用 Cursor、Claude 写代码时感到吃惊。多位开发者认为这类做法 ROI 不高,除烧 token 外价值有限,更实用的做法是把项目规范沉淀为 Skill。也有观点认为超过 20 人维护的大型项目从零开始时用 SDD 更利于模型理解项目,基于 spec 文档 AI 会收敛很多,跨模块复杂功能反而节省 token。

    Ожидает перевода

04.08вт
  1. Simon Willison · Coding Agents42

    Steve Yegge:Opus 4.7 的“just two more things”习惯让 Gas Town 项目崩盘

    Steve Yegge 称其可复用项目 Gas Town 最终只用于构建自身,并在 Opus 4.7 上彻底崩盘。Opus 4.6 及之前版本运行良好,4.7 引入了“just two more things”的毛病,使模型无法收敛到可投入实际工作的状态,总想摆弄 Gas Town 本身。该习惯始终未消失,Gas Town 因此被烧毁,4.7 成为压垮它的最后一根稻草。

    Ожидает перевода

03.08пн
  1. The Agentic Engineer · Blog70

    生产级智能体层之争:十二家平台架构已趋同

    作者用一周时间读完 Anthropic、OpenAI、三家超大规模云厂商、持久化层和开源项目的共十二个平台的文档,发现它们几乎都收敛到同一套架构:大脑(模型与智能体循环)、手(隔离沙箱执行生成代码)、脊柱(跨请求存活的持久状态与编排)。

    Ожидает перевода

02.08вс
  1. Thorsten Ball · Register Spill12

    Joy & Curiosity #93:Laracon 演讲、Amp 团队与 OpenAI 未发布模型的数学突破

    OpenAI 一款未发布模型在数学和理论计算机科学领域取得“十项进展”,引发广泛关注。作者在 Laracon 分享了如何为 Amp 编写提示词,并记录了对 AI 编程、框架抽象价值以及 OpenAI 模型“越狱”事件的思考。

    Ожидает перевода

28.07вт
  1. 宝玉34

    关于 Agent 的几个判断:通用 Agent 通吃、插件生态与模型护城河

    宝玉针对 @cellier_ 提出的三个 Agent 判断给出补充:通用 Agent 赛道将是少数赢家通吃,小通用 Agent 同样没有生存空间。他认为开放与封闭的差别不在开源或能否切换模型,而在插件生态,Skill 加 MCP 让 Agent 能完成各类任务。他还判断 Agent 产品体验护城河不深,模型能力和成本才是拉开差距的关键,小团队更适合基于 Agent 做插件。

    Ожидает перевода

24.07пт
  1. Armin Ronacher52

    Codeberg 因生成式 AI 条款分裂开源社区

    Armin Ronacher 就 Codeberg 修改条款、排除主要由生成式 AI 编写的项目一事发表看法。他认为该规则模糊、难以执行,因为无法给近期项目标注 AI 代码占比,并推测中间派会离开;他更希望 Codeberg 要么明确禁止 LLM 参与,要么只针对垃圾内容和滥用资源单独立规。

    Ожидает перевода

  2. Geoffrey Huntley · Blog34

    Geoffrey Huntley 加入 Antithesis,用形式化验证与确定性测试消除代码 slop

    Geoffrey Huntley 宣布加入 Antithesis,主张用形式化验证和确定性系统测试应对 AI 时代代码量激增带来的审查危机。他认为软件编写已被商品化,但验证与理解仍非免费,Antithesis 结合 LLM 对抗式代码审查与 pre-commit hook 驱动的语言分析器,可让人类和智能体交付可靠软件而无需掌握专门知识。

    Ожидает перевода

22.07ср
  1. Augment Code · Blog62

    Что такое циклический инжиниринг и как его применяют ведущие команды разработки ПО

    Augment Code предлагает циклический инжиниринг — проектирование цикла ИИ-агента, который охватывает путь от триггера и выполнения до верификации и получения результата: агент берёт на себя промежуточные шаги, а человек подключается только на контрольных точках, где нужно принять решение. В статье циклический инжиниринг сравнивается по уровням с промпт-инжинирингом и контекстным инжинирингом, а также описаны пять стадий — триггер, выполнение, верификация, результат и улучшение — и четыре командных цикла, уже работающих в продакшене: код-ревью, превращение тикета в PR, исправление уязвимостей и реагирование на инциденты.

    Почему это важно: Augment Code разбивает циклический инжиниринг на пять этапов — триггер, выполнение, верификацию, результат и улучшение — и приводит четыре командных цикла, уже работающих в продакшене.

21.07вт
  1. Johnny Butler · Agentic Engineering41

    AI 编程基准测不出什么:代码可维护性

    AI 编程基准只衡量模型能否在限定条件下完成改动,却测不出它留下的代码库是否更难维护——重复逻辑、耦合收紧、多余抽象都不会让当前测试失败,代价在后续扩展或排查线上问题时才显现。作者主张把可维护性放进交付流程:仓库级规范、清晰的架构边界、有意义的测试与静态分析,并审查重复、复杂度、架构漂移和模式不一致。

    Ожидает перевода

  2. Simon Willison · Coding Agents40

    Simon Willison:编程智能体让逆向工程变得廉价

    Simon Willison 观察到,越来越多人用编程智能体逆向工程并自动化家中设备。此前这类工作虽可行,但投入产出比低,且未文档化的不稳定 API 可能随时失效,维护成本令人却步。编程智能体大幅降低了实现简单自动化的成本,也让尝试失败和维护代码的心理负担显著减轻。

    Ожидает перевода

20.07пн
  1. Addy Osmani · Blog74

    Эдди Османи о «фабриках ПО»: явные и скрытые фабрики, где узкое место — проверка

    Эдди Османи описывает «фабрику ПО» как три уровня: loop, harness и factory. Фабрика — это не более умный ИИ-агент, а несколько loop с harness, которые сходятся в один шлюз проверки, а внешний цикл остаётся под управлением человека.

    Почему это важно: Автор разбирает «фабрику ПО» на три уровня — loop, harness и factory — и показывает, что настоящее узкое место — проверка, а не генерация.

  2. Paper Compute · Engineering Blog62

    该被裁掉的是智能体工作流,不是工程师

    作者认为企业在用 AI 缩减工程师编制前,应先按会话数据审查并关停那些失败、重复、空转或无人使用的智能体工作流。他给出一份审查清单,包括近 7 天和 30 天的会话数、完成与失败比例、总花费与每次成功运行的花费、工具调用次数、成本由哪些模型驱动,以及输出是否真正上线或被复用。作者同时区分可修复与应关停的工作流,并建议在关停前导出会话数据、把成功模式沉淀为带作者和版本的 Skill。

    Ожидает перевода

  3. Johnny Butler · Agentic Engineering38

    AI 智能体的能力是真的,但工程纪律要自己补

    当前 AI 智能体演示普遍在无限 token 预算、全新或精选代码库、无合规与运维压力的条件下运行,展示的是能力上限而非真实交付环境。AWS 副总裁 Marc Brooker 指出,智能体的机会受限于缺陷率,开发者调研中已有团队称其 AI 工具预算不可持续。作者建议只给智能体与验证能力和预算相匹配的自主权,用标准、检查项和可追踪的支出逐步放宽。

    Ожидает перевода

18.07сб
  1. Thorsten Ball · Register Spill22

    Joy & Curiosity #92:Amp 推出订阅与智能体间通信

    Amp 现已推出订阅服务,可与 ChatGPT 订阅搭配获得无限 GPT-5.6 token;同时 Amp 上线智能体间通信,智能体能在任意 Amp 实例或 orb 中派生其他智能体并互发消息与文件。作者还分享了新一季 Raising An Agent 播客、与 Evan Phoenix 等人的对谈,以及 antirez 关于“控制想法而非代码”的观点。

    Ожидает перевода

17.07пт
  1. Ryan Lopopolo71

    Code Red требует цикла поддержки: с помощью Codex /goal превратить аварийный ремонт в постоянную эксплуатацию

    Автор, опираясь на опыт участия в первом code yellow в Stripe, отмечает, что после большинства code red остаются лишь разбор инцидента и уставшие инженеры, а метрики снова оказываются без внимания. Он считает, что после каждого code red нужно запускать цикл поддержки и использовать команду /goal в OpenAI Codex, чтобы превратить разовый запрос на написание кода в постоянную цель с чёткими критериями завершения: тогда постоянно работающий кластер ИИ-агентов будет следить за метриками, выполнять нужные действия и запрашивать ручную проверку.

    Почему это важно: Опираясь на опыт code yellow в Stripe, автор предлагает с помощью /goal в Codex превратить разовый аварийный ремонт в долгосрочный цикл поддержки, который можно перенести в управление SLO.

  2. Ryan Lopopolo34

    为什么 CEO 主导的 token 强制令是合理的组织发现机制

    Ryan Lopopolo 认为,CEO 主导的 token 强制令并非盲目跟风,而是组织学习如何部署推理算力的发现机制。他指出,现有绩效体系几乎无法识别谁能构建新的生产方式,约只有 5% 的人具备构建“造机器的机器”的技能与视野,必须找到他们并给予无限预算。

    Ожидает перевода

  3. Johnny Butler · Agentic Engineering37

    我像学 Python 那样学 Go:靠交付真实代码来学

    作者认为 AI 智能体编程的真正风险不是代码质量差,而是一代工程师在交付自己看不懂的代码,丢失的是判断力而非产出代码的能力。他沿用当年学 Python 的方式学 Go:每交付一个真实改动就内置一条学习笔记,比如上周一个校验限制让他在 Go 中必须区分按字节计数还是按字符计数。这些笔记并非独立工具,只是记录 AI 智能体所用 playbook 的同一条记录上新增的一行。

    Ожидает перевода

16.07чт
15.07ср
  1. Johnny Butler · Agentic Engineering60

    Agent 写出的 Pull Request 比人类更好

    作者评审了一个 Agent 提交的 Pull Request,认为它又快又好,原因不在模型有多聪明,而在于质量门槛被写进了循环内部。这个 PR 在请求人工介入前就说明了改动了什么、刻意没动什么、该重点审查哪里、遵循了哪些规范,并附上了已运行的验证证据。作者由此提出,给 Agent 一个明确的完成定义和必须自证的标准,它就会为通过标准而优化,速度不是靠降低门槛换来的。

    Ожидает перевода

14.07вт
  1. Addy Osmani · Blog48

    Addy Osmani:AI 智能体接管初级编码练习后,开发者如何刻意习得品味与判断力

    Addy Osmani 认为 AI 智能体正在接管初级开发者赖以成长的重复编码练习,初级到高级的传统成长路径因此被改变。他引用数据称,2026 年 3 月应届毕业生失业率达 5.6%、计算机工程专业毕业生失业率 7.5%,Indeed Hiring Lab 发现初级技术岗位较 2020 年初减少 34%。他主张开发者应刻意培养"品味"——以经验压缩成的模式识别能力,并警惕对 AI 输出的认知投降。

    Ожидает перевода

13.07пн
  1. Johnny Butler · Agentic Engineering31

    AI 解决了「发明」,没人解决「简化」

    AI 让团队几天内就能做出可用原型,但「已上线」和「可在此基础上继续构建」并非同一里程碑,AI 正在拉大这一差距。原型阶段积累的复杂度若不经简化就直接扩展,会带来概念债、运维债和认知债,拖慢迭代速度。作者主张用 37signals 的「风洞测试」施压原型,剥离非必要部分后再规模化。

    Ожидает перевода

  2. Armin Ronacher60

    AI 辅助编程下,巴别塔为何仍在升高

    Armin Ronacher 认为,AI 辅助编程让单个开发者能更快改动代码库,但大型软件项目的瓶颈从来不是个人产出速度,而是开发者对系统的共同理解。过去改别人的存储层需要读代码、提问、跨团队协调,这些摩擦强制了沟通;如今用智能体加 OAuth、加缓存、重建数据库都无需与他人交流,摩擦消失后共同理解也随之瓦解。与圣经故事不同,AI 辅助工程在共同理解崩塌后施工仍能继续,塔不会倒,只会一直升高。

    Ожидает перевода

12.07вс
  1. Martin Alderson34

    AI 推理利润率崩塌中的赢家与输家(第二部分)

    Grok 4.5 以 $6/MTok 输出价格发布,与托管版 GLM5.2 成本相近,作者认为这印证了"好够用"模型正让大量智能体任务转向低价模型。赢家是半导体与推理供应链,以及 Cursor 这类编码智能体——它们能靠廉价模型赚钱并掌握真实使用数据。输家方面作者态度矛盾:Anthropic 约 80% 收入来自 API 存在被替换风险,但前沿实验室可能改为只通过托管智能体平台提供最强模型。

    Ожидает перевода

11.07сб
10.07пт
  1. Johnny Butler · Agentic Engineering49

    绿色通过从来不是你点合并的理由:AI 智能体自动合并 PR 的信任前提

    一些团队开始让 AI 智能体在 CI 全绿后自动合并自己提交的 PR,不再有人工介入。但绿色检查之所以能作为合并信号,靠的是检查运行前人类对意图、测试保护范围和系统风险点的判断,CI 只是确认而非替代这一判断。作者认为自动合并只适合低风险、边界清晰且有历史记录的改动,信任需要靠一次次带证据的改动积累,而不是打开一个开关。

    Ожидает перевода