人工智能编码工具是否在根本上改变了敏捷/团队软件开发？
我是一名工程负责人，正在思考一些关于人工智能编码助手（如Claude、Cursor等）如何改变……或不改变……我们团队构建软件方式的基本问题，我非常希望能听听社区的看法。
核心矛盾：
我们面临着采用更“初创公司式”方法的压力：更大的合并请求（PR）、更少的任务，个别工程师在AI的帮助下独自承担大量工作。论点是，AI工具使得一个工程师在5-6天内完成过去需要团队并行合作才能完成的工作。
但这似乎违反了核心的软件工程原则：
- 知识孤岛：一个人变成了“GraphQL专家”，提交了8,000行的合并请求，几乎不可能进行有意义的审查。
- 缺乏知识共享：初级工程师无法通过参与工作来学习。
- 公交车因子：如果那个人离开了，会发生什么？
- 代码质量：你真的能审查一个8,000行的合并请求吗，还是变成了“先发布，后修复漏洞”？
反论点：
- 初创公司以这种方式迅速发展并取得成功。
- AI工具正在改变一切……也许我们坚持旧做法才是“使用打孔卡片”。
- 客户并不关心我们的内部代码质量，只关心功能是否能发布。
- 如果AI能够处理混乱的代码库，技术债务还有意义吗？
我目前的想法：
AI工具确实让我们更快，但它们是对现有技能的倍增。使用Claude的高级工程师可以在保持良好架构和模式的同时，速度提高10倍。而初级工程师可能只是更快地生成10倍的平庸代码。
我认为AI应该增强我们现有的工作流程……更好的任务规划、更快的小块实现、AI辅助的代码审查……而不是完全用“英雄工程”取代工作流程。
但我确实感到不确定：
- 传统的敏捷实践（小任务、并行工作、彻底的代码审查、文档化的待办事项）是否正在变得过时？
- 这是一个真正的范式转变，还是我们只是重新发现了这些实践存在的原因？
- 在AI时代，如何平衡“快速行动”和“构建可维护软件”？
- 如果你能快速发布功能并让客户满意，代码质量还重要吗？
背景：
- 团队约有20名工程师，分为3个小组。
- 使用Claude Code、Cursor等工具。
- 来自领导层的压力，要求快速采用这种方法进行大规模实施。
- 一些工程师仍未有效（或根本未）使用AI工具。
有没有人成功地驾驭过这一转型？在2025年，使用这些工具的“良好”软件工程是什么样的？我是在固守过时的做法，还是“快速行动、大合并请求、后顾质量”的方法确实存在真实风险？
查看原文
I'm an engineering lead wrestling with some fundamental questions about how AI coding assistants (Claude, Cursor, etc.) should change... or not change... how we build software as a team, and I'd love the community's perspective.<p>The Core Tension:<p>We're facing pressure to adopt a more "startup-like" approach: bigger PRs, fewer tickets, individual engineers taking on massive chunks of work solo with AI assistance. The argument is that AI tools let one engineer build in 5-6 days what used to require parallelizing across a team.<p>But this seems to violate core software engineering principles:<p>- Knowledge silos: One person becomes "the GraphQL guy" with 8,000-line PRs that are impossible to meaningfully review<p>- No knowledge sharing: Junior engineers don't learn from participating in the work<p>- Bus factor: What happens when that person leaves?<p>- Code quality: Can you really review an 8,000-line PR, or does it become "ship it and fix bugs later"?<p>The Counter-Argument:<p>- Startups move fast this way and win<p>- AI tools ARE changing everything.. maybe we're the ones using "punch cards" by sticking to old practices<p>- The customer doesn't care about our internal code quality, only that features ship<p>- Does tech debt even matter anymore if AI can navigate messy codebases?<p>My Current Thinking:<p>AI tools absolutely make us faster, but they're a multiplier on existing skill. A senior engineer with Claude can maintain good architecture and patterns while moving 10x faster. A junior engineer might just produce 10x more mediocre code faster.<p>I believe AI should enhance our existing workflow... better ticket planning, faster implementation of small chunks, AI-assisted code review.. not replace the workflow entirely with "hero engineering."<p>But I'm genuinely uncertain:<p>- Are traditional Agile practices (small tickets, parallelized work, thorough code review, documented backlogs) becoming obsolete?<p>- Is this a genuine paradigm shift, or are we just rediscovering why those practices existed in the first place?<p>- How do you balance "move fast" with "build maintainable software" in the AI era?<p>- Does code quality matter if you can ship features quickly and customers are happy?<p>Context:<p>- Team of ~20 engineers across 3 teams<p>- Using Claude Code, Cursor, etc.<p>- Pressure from leadership who built solo/small-team projects quickly to adopt that approach at scale<p>- Some engineers still not using AI tools effectively (or at all)<p>Has anyone successfully navigated this transition? What does "good" software engineering look like in 2025 with these tools? Am I clinging to outdated practices, or are there real risks to the "move fast, big PRs, worry about quality later" approach?