将我自己编码进系统
3 分•作者: nharziro•大约 1 个月前
最近，我一直在更认真地思考人工智能和自动化对我作为软件工程师的角色意味着什么。
我是一家大型组织的高级工程师，十多年来，我一直负责一个对我来说意义非凡的项目。除了实习生多年来构建的一些功能外，几乎每一行代码都是我写的。
最初只是一个单一的应用程序，逐渐演变成了一个生态系统：一个库、API、一个编排层、命令行工具、计划任务等等。如今，该组织在某种程度上都依赖于它。
这种复杂性并非一蹴而就。它是多年来通过新的需求、集成、边缘情况、架构决策以及组织运营方式的变化而积累起来的。每一层都解决了实际问题，理解系统所需的知识也随之增长。
最终，一个人在管理它的同时还要构建人们请求的每一个下游功能，这变得不堪重负。于是我对其进行了重构。我淘汰了过时的组件，创建了一个 REST API 层，引入了一个 MCP 层，以便其他团队可以基于它进行构建，现代化了 CI/CD 和测试，并重建或淘汰了用户界面。目标是让生态系统更容易扩展，并降低我的“巴士因子”（bus factor，指项目关键人员的流失对项目造成的影响）。
自一月份以来，随着 AI 模型不断改进，我也转向了代理式开发。我将编码代理集成到工作流程中，创建了专门的代理技能，并为代码库编写了详细的 AGENTS.md 文件。代码库逐渐演变成不仅仅是源代码。它现在为模型提供了系统架构、约束、约定和历史的编码记录。
该系统可以帮助编写功能需求单并可重现地实现它们。它生成的代码植根于现有代码库，编写适当的测试，遵守架构边界，并可以挂载和执行底层库来验证假设。
它还可以超越代码库本身。它可以检查数据库模式，在定义的权限内读写数据库，并在故障排除时自主检索应用程序日志。它可以将这些日志与代码、架构和数据相关联，以调查故障并验证其假设。它拥有许多与我自己在诊断或实现某项功能时使用的信息来源相同的访问权限。
昨天，我向另一支团队的几位开发人员演示了这个工作流程，他们将为新项目贡献代码。
这个“工具”拉取了一个需求单，在遵循我的约束和护栏的情况下编写了代码和测试，打开了拉取请求，并在几分钟内将所有内容部署到了测试环境。我们剩余的工作主要是审查和测试。
它按预期工作，但也让我思考它的发展方向。
在过去的几个月里，我有效地将更多的自己编码到了系统中：技术知识、架构偏好、约定、约束、解决问题的模式，以及多年来在代码库工作所带来的判断力。
现在，“工具”产生的成果在很多方面都非常接近我本人的编写风格。
将其发展到这个阶段仍然需要多年的领域知识、架构决策、现代化工作以及精心构建的上下文和护栏，这些都使得代理能够有效工作。我仍然是最终的审查者，许多决策需要更广泛的技术和组织判断力。
在我看来，未来的系统越来越有能力研究不熟悉的 codebase，识别其约定和架构边界，构建自己的上下文，并确定在其中安全工作的必要护栏，这是完全有可能的。
如果我越来越多的知识、判断力和工作方式可以被编码到我周围的系统中，那么它们还能让我工作多久？
查看原文
Lately, I’ve been thinking more seriously about what AI and automation may mean for my role as a software engineer.<p>I’m a principal engineer at a large organization, and for more than a decade I’ve led a project that has always felt particularly close to me. I wrote nearly every line of code, aside from a handful of features built by interns over the years.<p>What started as a single application gradually became an ecosystem: a library, APIs, an orchestration layer, CLIs, scheduled jobs, and more. Today, the organization depends on it in some way.<p>That complexity did not appear all at once. It accumulated over years through new requirements, integrations, edge cases, architectural decisions, and changes in how the organization operates. Each layer solved a real problem, and the knowledge required to understand the system grew along with it.<p>Eventually, it became too much for one person to manage while also building every downstream feature people requested. So I rearchitected much of it. I retired obsolete components, created a REST API layer, introduced an MCP layer so other groups could build on top of it, modernized CI/CD and testing, and rebuilt or retired user interfaces. The goal was to make the ecosystem easier to extend and reduce my bus factor.<p>Since January, as AI models have improved, I’ve also moved toward agentic development. I integrated coding agents into the workflow, created specialized agent skills, and wrote detailed AGENTS.md files for the repositories. The codebase has gradually become more than source code. It now provides the models with an encoded record of the system's architecture, constraints, conventions, and history.<p>The system can help write feature tickets and implement them reproducibly. It produces code grounded in the existing codebase, writes appropriate tests, respects architectural boundaries, and can mount and exercise the underlying library to validate assumptions.<p>It can also go beyond the repository. It can inspect the database schema, read from and write to the database within defined permissions, and autonomously retrieve application logs while troubleshooting. It can correlate those logs with the code, architecture, and data to investigate failures and validate its assumptions. It has access to many of the same sources of information I use when diagnosing or implementing something myself.<p>Yesterday, I demonstrated the workflow to a couple of developers from another team who will be contributing to the codebase for a new project.<p>The harness pulled a ticket, wrote the code and tests while following my constraints and guardrails, opened the pull request, and deployed everything to the test environment within minutes. Our remaining job was largely to review and test it.<p>It worked as intended, but it also made me think about where this is heading.<p>Over the past several months, I’ve effectively been encoding more of myself into the system: technical knowledge, architectural preferences, conventions, constraints, problem-solving patterns, and some of the judgment that comes from working on the codebase for years.<p>The harness now produces work that is often very close to what I would have written myself.<p>Getting it to this point still required years of domain knowledge, architectural decisions, modernization work, and careful construction of the context and guardrails that make the agents effective. I’m also still the final review gate, and many decisions require broader technical and organizational judgment.<p>It seems entirely plausible to me that future systems will increasingly be able to study an unfamiliar codebase, identify its conventions and architectural boundaries, construct their own context, and determine the guardrails needed to work within it safely.<p>If more and more of my knowledge, judgment, and way of working can be encoded into the systems around me, how much longer are they going to keep me around?