Agentic AI still needs domain judgement
The hard part has shifted. Generating code, config, and glue logic is no longer the main bottleneck; judging whether the result matches real-world rules is. Domain expertise sits at that boundary, because the system may be technically neat and still fail on the thing that matters.
This shows up anywhere the rules are messy and local. A routing table can look fine on screen and still send traffic to the wrong place. A billing rule can apply cleanly and still charge the wrong rate for a pay period that straddles a change. The code is valid. The behaviour is not.
Generalist engineers can still build reliable systems, write tests, and keep the plumbing sane. What they often do not have is an oracle for the domain itself. They can tell whether the implementation is coherent, but they may miss the wrong assumption hiding inside the model of the world.
When plausible output is still wrong
Plausible output is the danger. Agentic systems are good at producing something that looks complete, which is exactly why subtle errors slip through. The failure mode is not a crash. It is a tidy answer that passes a shallow check and is wrong in a way that costs money or causes operational mess.
That matters in self-hosted infrastructure because the surrounding control is often manual and local. A misread setting, a bad default, or a wrong assumption about system behaviour can sit there for weeks. Nothing breaks loudly. The service just behaves a bit off, and nobody notices until a user complains or a bill lands.
The same pattern shows up in configuration management. A generated config may be syntactically valid and still be wrong for the environment. A backup job can run. A reverse proxy can start. A policy can deploy. None of that proves the underlying rule set matches reality.
Billing rules and routing tables expose the same problem
Billing rules are a good example because the bad cases are ordinary rather than exotic. Payroll calculations can include garnishments, pre-tax deductions, and rate changes that cut across a pay period. A system can encode all of that and still get the edge cases wrong.
Routing tables behave the same way. The entries may be correct in isolation, but the result can still be wrong once precedence, path choice, or local exceptions are involved. The output looks plausible because each line passes inspection. The failure only appears when the whole rule set is exercised against real conditions.
That is where domain expertise earns its keep. The person reviewing the output does not need to know every implementation detail. They need to know what must never happen. A driver cannot exceed eleven hours. A claim code cannot mean one thing on one form and something else in the next workflow. The rules are plain once you know the domain, which is exactly the point.
Domain experts become the missing test harness
Tests are only as good as the assumptions inside them. If the assumptions are thin, the tests can pass while the real system is still wrong. Domain experts fill the gap because they recognise valid behaviour from lived practice, not from a neat spec that missed half the awkward cases.
That makes them a test harness in the practical sense. They can look at generated output and spot when it violates the shape of reality. They know when an automation workflow has taken a shortcut that breaks a real process. They know when a config is technically acceptable and operationally nonsense.
This is awkward for software culture, because it asks for mixed skills rather than pure coding ability. The best result comes from combined judgement: one person or process that can see both implementation quality and domain truth. Without that, a well-built system can still be wrong in production and no one has a decent reason to distrust it.
The useful boundary is judgement, not generation
The boundary is not whether an agent can generate code. It can. The boundary is whether anyone involved can tell if the result is right. That is the scarce part, and it gets scarcer in domains with messy rules, local exceptions, and consequences that do not show up in unit tests.
For self-hosted infrastructure, that means keeping humans in the loop where the rules are not obvious. Generated configs need review from someone who understands the service’s real behaviour, not just its syntax. Automation workflows need checks against actual operational trade-offs, not just a green pipeline.
Domain expertise is doing the quiet work here. It stops plausible nonsense from being accepted as finished.
