For the past two years, the software industry has fallen in love with a new phrase: vibe coding.
The concept is seductive; open your favourite AI-powered development environment, describe an idea, and watch software appear almost magically before your eyes.
Need a website? Build it. Need an app? Build it. Need a marketplace, CRM, portal, dashboard, chatbot or mobile application? Build it. The barriers that once separated an idea from a working product are disappearing at a pace few would have believed possible only a few years ago.
It is an extraordinary achievement, but it is also potentially dangerous. Because while AI has become incredibly good at helping us create software, it has not made us any better at deciding whether that software should exist in the first place. That distinction may become one of the defining challenges of the AI era.
At Loggix, these developments have sparked many discussions about where software development is heading. During one of those conversations, founder Jeroen Lutmers introduced a concept that may offer an alternative perspective on the future of development: Necessity-Driven Development.
Not because software should be built more slowly. Not because innovation should be restricted. But because the economics of software are changing so dramatically that the entire industry may be asking the wrong question.
For decades, software development has been constrained by implementation. Building systems was expensive. Skilled developers were scarce. Every new feature represented a significant investment of time and money. Whether an organisation followed Waterfall, Agile, Scrum or Lean Startup, all of these methodologies were ultimately trying to solve the same problem: how do we manage the cost and complexity of creating software?
Today, AI is rapidly removing that constraint. A single developer can now generate in an afternoon what previously required weeks or maybe months of effort. Entire applications can be scaffolded from prompts. APIs, interfaces, integrations and business logic are increasingly becoming commodities. What was once difficult is becoming routine.
And that is where the paradox begins. When something becomes cheap, people tend to use more of it. When software becomes easy to create, organisations naturally begin creating more software. Much more. Features that would once have been carefully debated are now generated in minutes. Entire modules can be added because they seem useful. New workflows appear because they might be needed someday.
The temptation to build first and think later grows stronger with every improvement in AI. The industry, if not already, should discover soon that there is a significant difference between software that can be built and software that should be built.
Instead of asking “What can we build?” we need to ask:
“What is the smallest thing that must exist to solve today’s problem?”
The difference appears subtle on paper, yet it fundamentally changes the role of software. Under this philosophy, software is no longer viewed as a grand design that must be envisioned years in advance. Instead, it becomes an evolving response to real-world needs. A warehouse manager struggles with inventory visibility. Solve that problem. A month later, the purchasing department needs approval workflows. Extend the system. Three months later, accounting needs tighter integration. Adapt again.
Each addition is justified by necessity rather than imagination. The software grows because reality demands it. Not because a roadmap predicted it. Not because a brainstorming session imagined it. And certainly not because AI made it easy to generate. Ironically, many FileMaker developers will find this idea remarkably familiar.
Long before AI entered the conversation, FileMaker custom software developers were already practising a form of Necessity-Driven-Development. They sat with business owners, planners, administrators, warehouse staff and finance teams. They listened. They observed. They identified friction points and built solutions around actual operational needs. A better planning screen. A missing report. A workflow that removed duplicate work. An integration that eliminated manual data entry. The value was never measured by the amount of code written. It was measured by the amount of friction removed.
For years, this style of development has often been overshadowed by discussions about programming languages, frameworks and architectures. Yet AI may be quietly shifting the spotlight back toward the very skills that custom business developers have cultivated for decades. Because while AI can generate code at astonishing speed, it still struggles with a much more complicated challenge: understanding necessity. An AI model can create a dashboard. It cannot always tell whether the dashboard is needed. It can generate a workflow. It cannot always determine whether that workflow solves the underlying problem. It can create a new feature. It cannot reliably judge whether that feature will create more value than complexity.
Those decisions require context. They require business understanding. They require human judgement. As implementation becomes abundant, understanding becomes scarce. And scarcity creates value. This realisation leads to an intriguing possibility. The AI era may not reduce the importance of experienced software professionals at all. Instead, it may elevate a different set of skills to the forefront. The developer of the future may spend less time writing code and more time discovering necessity. The analyst who understands why a process fails may become more valuable than the engineer who can generate another thousand lines of code. The architect who recognises patterns across an organisation may create more value than the specialist who masters a particular framework. In a world where software creation approaches zero cost, knowing what not to build becomes a competitive advantage.
Yet Necessity-Driven-Development introduces its own challenge. If software continuously evolves to meet new needs, what prevents it from becoming an unmanageable monster? Anyone who has worked with business systems long enough has seen this happen. A simple application becomes a larger application. A larger application becomes a platform. Over time, new requirements accumulate, workflows overlap, functionality duplicates itself and complexity begins to grow faster than value. Without discipline, necessity can eventually create chaos.
Perhaps the future is not AI as programmer. Perhaps the future is AI as gardener.
This is where AI’s most transformative role may emerge. A gardener does not create every plant in an ecosystem. Instead, they ensure that growth remains healthy, balanced and sustainable. They prune unnecessary branches. They identify duplication. They reorganise where needed and create space for future growth.
Software may soon require exactly the same type of stewardship. Imagine an AI continuously monitoring a project and asking questions such as:
- 🌱Do we already have a component that solves this?
- 🌱Can this functionality be reused instead of recreated?
- 🌱Is this workflow becoming redundant?
- 🌱Are we adding complexity faster than value?
- 🌱Can these five modules be consolidated into one?
Rather than simply generating more software, AI becomes responsible for maintaining coherence across the entire ecosystem. It becomes the gardener.
The implications of that shift are profound. For the first time in the history of software development, the cost of creating software may become lower than the cost of deciding what software should exist in the first place. The bottleneck is moving. Away from implementation. Toward understanding. Away from syntax. Toward necessity. And that may be why so many experienced FileMaker developers are better positioned for the future than they realise.
For years, they have worked at the intersection of people, processes and technology. They have learned to uncover hidden requirements, navigate organisational complexity and build solutions that evolve alongside the businesses they serve. While much of the industry was optimising the act of coding, they were refining the art of understanding.
As AI continues to transform software development, that distinction may become increasingly important. Because the question is no longer whether AI can write software. It can. The real question is whether we will continue building software because we can, or whether we will finally start building it only because we need it. If the answer turns out to be the latter, Necessity-Driven-Development may prove to be far more than a methodology. It may become the philosophy that defines software development in the age of AI.
