领域专长一直是真正的护城河。
Domain expertise has always been the real moat

原始链接: https://www.brethorsting.com/blog/2026/05/domain-expertise-has-always-been-the-real-moat/

传统上,软件开发被定义为构建领域心智模型并将其转录为代码的劳动。智能体 AI 将这两项任务解耦,使得编写代码这一机械过程变得廉价且充沛。 新的瓶颈不再是“构建”软件,而是“验证”其正确性。因此,拥有隐性“基本事实”的领域专家,其效能已远超通才工程师。工程师虽然能确保代码结构良好,但往往缺乏识别细微错误输出的专业知识。相反,领域专家可以利用 AI 跨越编码的技术门槛,同时保持判断准确性的关键能力。 对于软件工程师而言,职业道路已经发生了转变。技术熟练度不再是足够的护城河。为了保持价值,工程师现在必须在技术技能之外,优先培养深厚的专业领域知识。最强大的开发者是那些能够连接两个世界的人:既利用 AI 来转录模型,又亲自担任验证系统真实性的“预言家”。在这个新时代,你的竞争优势不在于你如何编写代码,而在于你对代码所代表的现实理解得有多深。

本次讨论探讨了人工智能时代软件开发格局的转变。与会者达成的共识是:尽管人工智能已使编写代码这一“机械”技能商品化,但它同时也提升了**深厚领域专业知识**和**系统级思维**的价值。 主要结论包括: * **“验证”差距:** 一个主要的瓶颈在于,将隐含的、现实世界的领域专业知识转化为软件所需的显式、确定性规则非常困难。虽然领域专家可以轻易识别出人工智能的输出何时“错误”,但他们往往难以定义出能够从一开始就防止故障发生的“正确”规则或架构。 * **作为独立学科的工程学:** 许多评论者认为,“领域专业知识”并非万能灵药。现实世界的系统需要管理技术债务、可扩展性、安全性和复杂的集成——这些技能从根本上仍与传统的软件工程经验息息相关。 * **新型“开发团队”模式:** 最有效的结果可能源于协作:由了解“基本事实”的领域专家与提供结构性保障的高级工程师共同工作。 * **“凭感觉编程”(Vibe-Coding)的陷阱:** 虽然人工智能允许非程序员“凭感觉”编写功能原型,但这些系统往往会变得脆弱、难以维护,且缺乏长期运行所需的架构严谨性。
相关文章

原文

The hard part of writing software has never been the writing. It was building a working model of the domain in your head first. Before you could ship a payroll system you had to understand garnishments and pre-tax deductions and what happens when someone’s pay period straddles a rate change. Before you could ship a transit app you had to learn what a GTFS feed is, why a trip and a route aren’t the same thing, and how a bus that’s “on time” can still be wrong. The code was a transcription of that understanding. Acquiring the understanding was the job.

Agentic AI severed the link between the two. You can now produce the software without ever building the model, and that breaks an assumption the whole profession was organized around.

The standard take, including my own from last year ago, is that these tools amplify senior developers because senior developers have judgment. True, but incomplete. What I’ve watched happen since is more specific and more interesting: the binding constraint has moved from can you build it to can you tell whether it’s right.

Think about who can actually use one of these tools well. Picture two people.

The first is a domain expert with no real software background. A logistics dispatcher, a clinical coder, an actuary. They can’t read a stack trace and they couldn’t tell you the difference between a hash map and a list. But they can look at a schedule the agent generated and know instantly that no driver can legally work that shift, or that a claim with those codes would never pay. They know the correct outputs for a given set of inputs because they’ve spent ten years living in those inputs and outputs. Hand them an agent and they are startlingly effective, because the thing they’re missing, the ability to produce code, is exactly the thing the agent supplies. What they bring is the thing the agent can’t: the ground truth.

The second is a strong generalist engineer who has never worked in the domain. They can architect anything, they know reliability and testing and how to keep a system from falling over at 2am. But drop them into clinical coding and they cannot tell a plausible-looking wrong answer from a right one. The agent will happily generate a billing rule that compiles, passes the tests the engineer thought to write, and is subtly, expensively incorrect. The engineer has no oracle. They can verify that the software is well-built. They cannot verify that it’s correct, because correctness here is defined entirely by a domain they don’t hold in their head.

Notice which way this cuts. Pre-agent, the engineer had a path the dispatcher didn’t: they could go learn the domain. Slowly, painfully, by shadowing experts and reading specs and getting things wrong in production, they would build the mental model and then they could build the system. That path was the whole career ladder in a lot of fields. The domain expert had no equivalent path, because learning to build reliable software is years of work they were never going to do.

Agentic tools collapsed one of those paths and not the other. The engineer’s advantage, the ability to translate a domain model into working code, is now cheap. The domain expert’s advantage, knowing what right looks like, is not. You can’t prompt your way to it. There’s no skill file that contains the tacit knowledge of a person who has reconciled a thousand payrolls.

So the most valuable person in this new world is the one who has both skills because they can verify at both layers. They know the generated code is sound and they know the answers it produces are true. They can write the test that encodes “a driver can’t exceed eleven hours” because they know the rule, and they can tell that the test itself is meaningful because they know what they’re testing. The agent does the transcription. They do the judging, twice.

If you’re an experienced engineer betting on where to spend the next few years, this is the bet. The mechanical skill you sweated for, turning a clear idea into clean code, has gotten dramatically less valuable. The thing that’s still scarce is a deep, verified model of some real domain. Go get one. Pick an industry, an instrument, a regulatory regime, a physical process, and learn it the way you once learned a programming language or framework. That’s the part the agent can’t do for you, and it’s the part that’s now worth the most.

联系我们 contact @ memedata.com