Photo: Google Gemini · AI-generated
“A problem well stated is a problem half solved.” The line is most famously attributed to Charles Kettering — the industrialist who held 186 patents, invented the electric starter motor, and led research at General Motors for nearly three decades. He was not talking about software. But he might as well have been.
In the age of AI-enabled development, this principle is not just relevant — it is the entire game.
AI is only as good as the problem you give it
AI coding agents, autonomous workflows, large language models — they are genuinely powerful tools. They can generate code, write tests, refactor architectures, and draft documentation at speeds no human team can match. But they share a fundamental limitation: they solve the problem you give them, not the problem you actually have.
Give an AI agent a clearly scoped, well-decomposed task with precise constraints and it will deliver impressively. Give it a vague, sprawling, half-understood business problem and it will deliver confidently wrong solutions at impressive speed.
The bottleneck in AI-enabled development was never the technology. It was always the problem statement.
The mid-market problem formulation gap
This is where mid-sized businesses — the German Mittelstand, industrial companies, growing enterprises — face a specific challenge. Their problems are real, complex, and deeply embedded in domain-specific processes. But they are rarely stated in a way that makes them solvable, by humans or by AI.
We see three patterns repeatedly:
Overstated problems. “We need to digitise everything.” “Our entire ERP needs to be replaced.” “We want AI across the organisation.” These statements are too large to act on. They paralyse teams, inflate budgets, and produce roadmaps that never survive contact with reality. An AI agent given “digitise everything” will produce something — but nothing useful.
Underestimated problems. “We just need a small app for the warehouse.” Then it turns out the warehouse app needs to integrate with SAP, handle offline sync, respect shift-based access controls, and produce audit-compliant logs. The problem was never small — it was just described that way because nobody mapped the real scope.
Over-cluttered problems. Years of accumulated requirements, workarounds, edge cases, and political compromises bundled into a single specification document. No AI and no human can parse a 200-page requirements document where half the items contradict each other and a third are no longer relevant. The signal is buried in noise.
The discipline of decomposition
The skill that matters most in AI-enabled development is not prompt engineering. It is problem decomposition — breaking a complex, ambiguous business challenge into a sequence of well-defined, right-sized problems that can each be solved independently.
This means:
- Separating what must happen first from what can happen later
- Identifying which constraints are real and which are inherited assumptions
- Scoping each piece so it can be built, tested, and validated before the next one begins
- Knowing which parts benefit from AI acceleration and which need human judgement
This is not a technical skill. It is an engineering discipline that comes from years of building production systems for real businesses. It requires understanding the domain, the organisational context, and the difference between what the client asks for and what the client actually needs.
Why experienced teams matter more, not less
The irony of AI-enabled development is that it makes experienced teams more valuable, not less. When AI can generate code in minutes, the competitive advantage shifts entirely to the people who can formulate the right problem, validate the output, and integrate it into a system that works in production.
At exbisoft, this is the work we do every day. Our developers are not being replaced by AI — they are using AI as a tool, guided by years of experience in building custom software for mid-sized businesses. They know which problems to solve first, how to decompose them properly, and when the AI’s output needs a human correction.
Kettering had another line worth remembering: “A problem well stated is a problem half solved.” The other half still takes an engineer.
Sounds familiar? Talk to us.