Software Development at a Crossroads

Executive Summary

Software development is changing. Not in terms of methodology: in terms of who develops software and how.

AI-powered development environments now make it possible to orchestrate specialised agents for architecture, backend, frontend, testing and DevOps, all coordinated by a single person. What previously required a team of numerous specialists can now be achieved by a few experienced individuals (sometimes even just one) with the right setup.

This has consequences: for team structures, for agile methods, and for the question of who will build software in future. And above all: who makes the decisions.

1. The status quo: Agile software development today

Since the early 2000s, agile software development has established itself as the dominant paradigm. The 2001 Agile Manifesto was a response to cumbersome waterfall processes: too much planning, too little delivery, and too long a gap between the initial idea and working software.

Scrum, Kanban, SAFe and their derivatives have since shaped millions of development teams. Faster delivery cycles, closer collaboration with the customer, continuous improvement: these promises have been fulfilled in many projects.

However, as its popularity grew, its downsides also became apparent:

Ceremonies take up time. Daily stand-ups, sprint planning sessions, reviews, retrospectives, refinements… In a typical Scrum team, a developer spends several hours a week in meetings that do not make the code any faster. In large organisations, this is compounded by multi-level coordination.

Teams become large and cumbersome. A fully-fledged agile team (Product Owner, Scrum Master, several developers, QA, DevOps, UX) requires coordination at many levels. Decision-making processes become longer. The original concept of agility is undermined by the sheer size of the team.

The gap between vision and implementation remains. Those who have an idea for a piece of software are rarely the ones who build it. Between the visionary and the finished product lie backlogs, prioritisation meetings, sprints and reviews. This friction is inherent in the system.

The skills shortage is exacerbating the situation. Qualified software developers are in short supply and expensive. Small businesses, start-ups and organisations with limited budgets simply cannot afford full development teams. Their ideas remain just ideas.

These structural tensions are nothing new. What is new is that a technological solution is beginning to emerge: and it is more radical than expected.

2. The new paradigm: AI as a development team (support)

Public perception of AI in software development has shifted over the past two years. What began as intelligent autocomplete (GitHub Copilot, TabNine and similar tools) is now something qualitatively different.

Modern AI systems can no longer simply suggest individual lines of code or functions. They analyse requirements, design architectures, write code, generate tests and orchestrate deployments, all as part of coordinated workflows that resemble a team structure based on the division of labour.

The step that brings about this change is the transition from tool to agent.

An AI tool responds to a query. An AI agent pursues a goal, plans intermediate steps, coordinates with other agents and acts autonomously: within defined limits, with human oversight at critical points.

What is possible today: concepts such as the AI development OS show where this development is heading. Specialised AI agents take on the roles of an entire development team, from architecture and backend to frontend and UX, right through to testing, code review and DevOps. In extreme cases, a human orchestrator sets the direction, makes policy decisions and approves the results.

The system does not operate on a fixed sprint basis. Tasks arise and are dealt with as and when they are needed. Decisions are made where the expertise lies: by the agent responsible, with human approval at critical points.

With AI support, an experienced developer or technically proficient product manager can achieve significantly more when dealing with clearly defined types of tasks and take on tasks that previously required several specialists. Human expertise remains indispensable for complex architectural decisions, in-depth domain knowledge and critical reviews.

This development is already underway. It is already standard practice in certain areas, and the gap to what is still considered the limit today is narrowing faster than most roadmaps had anticipated.

3. The shift in power: The visionary plays a part in shaping the future

In traditional software development, there is an inherent tension: the person who knows what needs to be built is usually unable to build it themselves. The product owner writes user stories; the developers decide how to implement them. The founder has the vision; the team decides on the technical implementation.

This is not a question of knowledge. It is a question of power.

Whoever writes the code makes a thousand small decisions that no backlog item can capture. Which library is used? How is the data model structured? Where are shortcuts taken because the sprint deadline is approaching? The technical implementation shapes the product: often more so than any roadmap.

AI-powered development environments are beginning to change that.

A visionary who used to rely on a team of developers is now increasingly able to set the pace themselves. They do not need to write code. However, they must know what they want and be able to communicate it precisely. The quality of the result depends less on detailed technical knowledge than on conceptual clarity.

This changes the team structures:

Smaller teams with greater flexibility. An experienced product strategist, supported by AI, can take on tasks in certain areas that previously required several specialists.

New role models. The classic ‘full-stack developer’ was an attempt to combine breadth with depth. What is now emerging is different: the technically savvy visionary who manages AI agents rather than writing code themselves. Conceptual expertise is becoming a key differentiator.

Technical knowledge remains valuable, but in a different way. Those who understand how systems work can better control AI agents, critically evaluate suggestions and recognise limitations. The developer’s specialist knowledge does not become worthless; it simply shifts to a different area of application. Less execution, more judgement.

The door is opening. Start-ups, small businesses and individuals with a good idea but limited capital are gaining access to development resources that were previously reserved for well-funded organisations. This is shifting the balance of power in many areas. Not at some point in the future: right now.

This shift is already underway. Those who actively shape it will build up a lead that stragglers will find difficult to catch up with.

4. What will become of agility?

Scrum isn’t dead. But it is under pressure from an unexpected quarter.

The agile movement emerged as a reaction to rigid processes. Its core was never Scrum or Kanban. Its core was the principle: deliver early, deliver often, learn from feedback, adapt. The ceremonies were a means to an end, not ends in themselves.

In AI-supported development environments, this core re-emerges in a different form.

Sprints give way to a continuous flow. When an AI team delivers in hours rather than weeks, artificially grouping of work into fortnightly cycles makes little sense. Tasks arise, are prioritised, processed and accepted in line with actual demand.

Ceremonies are giving way to adaptive coordination. The daily stand-up meeting exists because people need to coordinate with one another. AI agents coordinate continuously. Their status can be accessed at any time. What remains is the human decision: where do we go from here? What is really important?

The fundamental principle of agility endures, in a purer form. Customer value takes precedence over adherence to process. Working software takes precedence over documentation. Responding to change takes precedence over a rigid plan. These values lose none of their validity in an AI-supported environment. They become even more relevant because the friction involved in implementation is reduced.

The role of people is changing: they are no longer mere masters of ceremonies or resource planners. People are becoming visionaries and guardians of quality. The question ‘What do we want to build?’ remains a human one. The question ‘How will it be built?’ is becoming less so.

Adaptive Autonomy as a working model. Rather than a fixed level of automation, the visionary makes decisions on a case-by-case basis: for familiar, well-understood tasks, AI agents work autonomously. For new, risky or critical decisions, humans are involved at every relevant stage. Control remains, but it is applied in a targeted manner.

This is not a departure from agility. It is its further development.

5. Risks and outstanding issues

Paradigm shifts have their downsides. This is no exception.

Dependence on a small number of platforms. Anyone who bases their development processes on an AI infrastructure makes themselves dependent on that infrastructure’s availability, pricing and strategic decisions. What is cheap today may be expensive tomorrow. What works today may change as a result of an API update.

One answer to this is the hybrid stack: local language models for data-sensitive or standardised tasks, and cloud models where depth of reasoning and context length are required. Powerful local models (such as Qwen2.5-Coder or DeepSeek) can now handle many coding tasks on suitable hardware without data ever leaving the organisation’s own system. For complex architectural decisions, using the cloud remains a sensible option. This only works with clear governance: who uses which system for which type of task, and under what data protection requirements. In this context, sovereignty does not necessarily mean a closed local system, but rather control over one’s own infrastructure and data strategy.

Quality and responsibility. AI agents make mistakes – sometimes subtle ones that are difficult to spot. The person who authorised the output is responsible. This requires the ability to assess the result. This ability must be actively maintained; it quickly deteriorates if one stops paying attention.

The dumbing down of knowledge. When AI agents take over routine tasks, there is a risk that the knowledge embedded in these tasks will no longer be built up. The next visionary might simply accept architectural decisions without understanding why they were made. Organisational memory must be consciously nurtured.

The question of creativity. AI combines what it has learnt: convincing, but not original. New ideas, unusual approaches, the lateral thinking that leads to breakthroughs: that remains a human trait. The real danger is not that AI will become too creative, but that the convenience of using AI will stifle human creativity.

Social implications. If a visionary with an AI team can do the work of five developers, the question arises as to what will happen to those five. New roles are emerging, whilst old ones are disappearing. This has been the case with every technological shift. This transition is rarely smooth, and it will not be this time either.

These risks are no excuse for inaction. But anyone who ignores them will eventually pay the price.

6. Outlook: Three possible futures

Like any transformative technology, AI in software development is evolving in various directions, depending on how organisations, developers and society engage with it.

Scenario 1: AI as a tool. AI becomes a powerful aid, comparable to the transition from the typewriter to the PC. Developers become more productive, and teams become leaner. The basic structure remains recognisable. AI speeds things up, but does not replace them.

This scenario is the most likely in the short term. It is convenient, yet risky, for anyone who waits too long.

Scenario 2: AI as a colleague. The line between human developers and AI agents is becoming blurred. Teams consist of humans and agents with clearly defined roles, mutual expectations and established models of collaboration. Humans set the direction and make decisions. The agents implement these decisions and make suggestions.

This scenario calls for new forms of leadership, new skills and new ethical guidelines – and organisations that are willing to actively address these issues.

Scenario 3: AI as a replacement. In certain areas (well-defined, recurring development tasks), AI takes over completely. Not in one big leap, but gradually. What remains are strategy, domain knowledge and conceptual work.

This is not a worst-case scenario. In many areas, it is simply the logical continuation of the current trend.

The reality will be a mixture of all three — and probably not in the order that anyone is predicting today. Those who assess now which scenario is relevant to their context are better off than those who wait.

7. The AI Development OS as the answer

What has been described so far is not a thought experiment.

The AI development OS puts this shift in power into practice: a solo developer or a small team gains the clout of a full agile development team through specialised AI agents: without the need for coordination, without rigid sprint cycles, and without the friction associated with large team structures.

The visionary remains in control. The system makes suggestions, seeks confirmation, waits for approval and then carries out the task. Every critical step is documented; every decision remains traceable.

The aim is not to replace developers, but to empower people with conceptual clarity to build high-quality software: and to deploy experienced developers where it really matters: architectural decisions, critical reviews, and domain expertise.

The concept is designed for tech-savvy teams and companies that are actively rethinking software development: not as a one-size-fits-all solution, but as a targeted tool for those who are able and willing to use it.

The concept is currently under active development. Anyone who is interested — in the architecture, in initial practical experiences or in pilot projects — is welcome to get in touch.