Domain expertise is becoming more valuable as AI coding agents make software easier to produce. Aaron Brethorst’s argument is simple and uncomfortable: the bottleneck moves from writing the code to knowing whether the thing the code does is correct.
Table of Contents
The short version: domain expertise
- AI coding agents lower the cost of implementation, but they do not automatically know the messy rules inside payroll, transit, insurance, logistics, or clinical billing.
- Domain expertise matters because the expert can spot a plausible answer that is wrong before it turns into a costly system.
- The strongest engineer in this setup is not the fastest prompt writer. It is the person who can judge the code and the real-world result.
- Hacker News readers mostly agreed with the premise, but pushed back on the idea that domain experts can easily explain their own rules to an AI system.
What happened
Brethorst’s essay argues that software has always depended on a mental model of the domain. A payroll system is hard because of garnishments, deductions, rate changes, and edge cases. A transit app is hard because routes, trips, schedules, and rider expectations do not line up cleanly.
In that view, code is the transcription layer. The harder work is learning enough of the domain to know what the software should do.
AI coding agents weaken the old link between understanding and implementation. A person can now ask an agent to build screens, APIs, tests, and deployment scripts without years of programming practice. That helps domain experts, because the missing piece for many of them was code production. It does less for a generalist engineer who lacks the domain model and cannot tell whether a generated output is actually right.
That distinction matters for teams following AI and software engineering closely in the IT & AI archive. Faster output is useful only when the organization has someone who can define and verify correctness.
Why this is worth watching
The essay lands because it pushes against a lazy version of the AI coding story. If code gets cheaper, the valuable work does not disappear. It moves closer to judgment.
A logistics dispatcher may not read a stack trace, but they can look at a generated schedule and know that a driver cannot legally work that shift. A clinical coder may not care how the rules engine is structured, but they can see when a claim is likely to be denied. That is not generic “business context.” It is accumulated pattern recognition from years of seeing inputs, outputs, exceptions, and consequences.
This is also a career argument. Senior developers still need architecture, reliability, testing, and incident judgment. But if their only advantage is turning clear requirements into clean code, that advantage is getting thinner. The rarer combination is engineering skill plus a working model of a real domain.
For product teams, the practical question is where domain expertise sits in the AI workflow. If experts only review the product after engineers and agents have already built it, the process will keep producing polished wrong answers. The expert needs to shape tests, examples, acceptance criteria, and failure cases early.
What Hacker News readers are arguing about
The Hacker News discussion was less about whether domain expertise matters and more about whether domain experts can make their knowledge explicit enough for software.
One strong objection was that verifying an answer is different from explaining how to generate it. Several commenters who had worked with finance or accounting teams said experts often know a rule when they see it, but struggle to describe it fully. That led to a useful thread around tacit knowledge and Polanyi’s paradox: people can know more than they can explain.
Another camp argued that requirements work has always been the real software job. In small companies and internal systems, refining what the system should do often takes more time than writing the code. AI may make this more obvious rather than make it new.
There was also a builder-friendly angle. Some commenters said AI can help engineers learn a domain faster because it removes boilerplate and lets them build experiments quickly. A few mentioned domain-specific languages as a better bridge: instead of expecting experts to write software, give them a constrained language that encodes the rules and can be tested against past cases.
The useful skepticism is this: domain experts are not automatically good product designers, requirements writers, or system builders. The win probably comes from tighter collaboration, where experts supply examples and corrections while engineers turn that knowledge into reliable systems.
The practical read
If you run an engineering team, do not measure AI coding only by tickets closed or lines generated. Add domain validation to the workflow. Ask who owns the examples, who writes the edge-case tests, and who can reject a result that looks reasonable but fails a real rule.
If you are a developer, the career move is not to panic about code generation. Pick a domain where mistakes matter and learn it seriously. Billing, compliance, logistics, security operations, financial workflows, health care administration, industrial systems, and public-sector processes all have rules that are hard to fake.
The near-term advantage belongs to people who can ask an AI agent for working software, then say with evidence whether the output is correct. Domain expertise is the moat because correctness is still tied to the world outside the editor.