Anyone working with coding agents today experiences something unfamiliar: implementation is rarely the bottleneck any more. A form, an API, a report – what used to take days is done in hours. That changes what matters in software projects.
What is unambiguous is cheap
An agent is excellent at implementing a clearly described task. It is poor at noticing that the task is described wrongly. It builds the invoice with a discount as requested – and does not ask whether the discount applies before or after tax, whether it turns negative on a credit note, or whether it may still be changed after finalisation.
Those are not programming questions. They are questions about the domain. And their answers decide whether the software holds up in daily use or gets rewritten three months later.
The model is the product
The cheaper code becomes, the more value shifts to what comes before the code: the terms, the states, the rules, the exceptions. A good domain model makes implementation cheap because every task becomes unambiguous. A bad one makes it expensive no matter how fast the agent types – it simply builds the wrong thing quickly.
That is why I spend surprisingly little time on technology at the start of a project. I want to understand how a process really works, not how it is written in the manual: where the exceptions are, which figures must be traceable, who is allowed to decide what.
What follows
For companies, it means their own domain knowledge is worth more than ever – provided it can be made precise. For developers, it means the ability to understand a problem and model it cleanly becomes the core skill. Syntax was never the hard part. Now it is just easier to see.