My wife and I have been building something called Klangdomäne - "sound domain". The idea is simple: a place where musicians go to devote themselves to music. Music is the master there. And because the place is free of all the distractions that making music sometimes brings with it - the showing off, the marketing, the monetizing, the intellectualizing - it can become a place of true musical innovation.
I have something very similar in mind for a job role.
I call it the Domain Software Engineer. But let me start at the beginning.
Agentic coding made software development fast and cheap. That of course doesn't mean we should build every internal software tool in house. There are tools that already have a highly optimized UI, tools that implement complicated logic, or tools that provide complex data. It would be stupid to try to rebuild these assets with agentic coding. And it still takes an experienced senior software engineer to turn AI-coded solutions into something safe and sound.
But corporate software reality is something different. We have lots of tools - we're digital by now. But this tooling is often horrible. The solutions are rarely well interconnected because they lack good API layers, they're often an UX nightmare, and they often don't fit the needs of the department. There are plenty of reasons for that. One of them was that software development used to be expensive and slow - so in the end Excel had to be the solution, the quick fix that stayed.
Now software development has become a lot cheaper and faster. But we haven't adapted to this new reality - and we should.
I think there should be a new role in the departments of a company, be it finance, production, R&D, you name it - the Domain Software Engineer. A person with profound and broad knowledge of software development, architecture, and infrastructure, who is keen to specialize in one domain. A person who asks "How can I help?", whose sole job is to replace the Excel sheets, build custom tools, and connect third-party solutions to empower the whole department. No product to sell, no hours to bill, no tech stack to show off - just the domain and what it needs.
It's hard not to like them, because they make the work of their colleagues enjoyable again. They automate time-consuming necessities and deploy the latest and best-fitting tools within days, not quarters.
A concrete picture: every month, a finance team exports data from three systems, reconciles it in Excel, and emails the result around for approval. Their DSE connects the source systems, encodes the reconciliation rules, and builds a small review workflow - the specialized accounting software stays untouched. Several days of work removed from every monthly close.
And they are not alone. Their home is the department they work for - but in the organization they share one department with all the other Domain Software Engineers in the company. Together they decide the standards their solutions must fulfill: security, code quality, top-notch documentation, tests as a given, current APIs, no stale data - just to name a few. And to be clear, this is not shadow IT. DSEs play by the IT department's rules like everyone else - their own standards go further. These standards are also the answer to the obvious fear: what happens to all those custom tools when their builder leaves? Nothing a DSE builds is a private Excel that dies with its owner. It's documented, reviewed, and maintainable.
The Domain Software Engineering department has its own budget, a collective that can decide what infrastructure and tooling should be bought. And it gives them a voice in the company: a single engineer embedded in finance is easy to overlook; a department that speaks for software in every department is not. The DSEs meet regularly and report what's special about their domain, what solutions they recently built, and what improved because of them. This way they learn from each other, sharing ideas and boosting performance across departments.
I know what you're thinking: two homes, two loyalties - who do these people actually report to? Fair question, but not a new one. IP departments have been living with exactly this setup for decades. The people in or responsible for a department's patent work need to understand the domain very well, but above all they need to know IP. They are deeply integrated into their departments and at the same time part of the central IP department. This setup with two homes works. The hard part is not the org chart - it's finding people who fit both worlds, and making sure they keep working well with both - their department and their fellow DSEs.
At first I thought the name of the role should contain some AI or agentic buzzword. But give it a few more months - a year or two at most - and agentic coding will be so normal that nobody considers it noteworthy anymore. The job ads appearing right now prove the point: "AI Developer" roles, described by whatever is hot this quarter - agentic coding, RAG, the workflow tool of the month. That ages fast. A domain doesn't. Then I thought the team aspect should be in the name. It's important, yes, but it's not the core. And yes, similar roles exist - embedded engineers, forward-deployed engineers, business technologists. But those are visitors, sent by engineering or by a vendor. The core of this role is the identification with and the knowledge of a domain.
You don't implement AI in a company with a few workshops for people who have been in the department for years. That won't work. You also don't need external companies that either sell you consultant hours and leave again, or sell you some LLM wrapper. You need the ability to supercharge your departments in house - you need Domain Software Engineers.
This is not a task force you bolt on and dissolve when the project is done. It's a permanent role you add inside. The energy is already in the departments - the domain knowledge, the ideas, the hundred improvements everyone can name but nobody can build. The DSE is the catalyst that sets this energy free. That's why integrating is the easy part: the colleagues have been waiting for these people for decades without knowing it.