Yet the real problem is rarely the technology itself. It rather is a lack of understanding about what makes agent-based development fundamentally different from anything that has come before. No coding assistant, prompt engineering workshop or pilot project can resolve this issue. Instead, it requires a basic understanding of how humans and machines can work together throughout the entire software development lifecycle, from establishing initial requirements right through to production.
Seven principles make all the difference:
1. Humans and agents take on different roles
When getting started, people often make the mistake of treating AI agents like very fast developers. This is based on a fundamental misunderstanding. Agents should not be seen as junior developers who can simply be set loose on tasks. Instead, they are executing instances that need precise guidelines to function.
Humans provide the “why” and the “what”: architectural principles, business requirements, quality criteria. The agent handles the execution. This includes: generating code, running tests, fixing bugs, writing documentation – in continuous feedback loops, without every step having to be triggered manually.
2. The quality of the input determines the quality of the output
Hallucination is not a technical problem that can be solved with a better model. It is usually a contextual problem. If you deploy AI agents with vague requirements, you will get vague results, no matter how powerful the underlying model is.
For that reason, structured artefacts such as clear specifications, architectural principles and contextual documentation should not be regarded as a tiresome chore, but as the actual control layer. A well-structured specification document is more valuable in the context of agent-based development than a thousand lines of manually written code; it is the difference between an agent that delivers and one that guesses.
3. Short cycles beat long sprints
Traditional agile development works in sprints of two to three weeks. Agent-based teams can achieve development cycles of two to four days across the entire software development lifecycle, from requirements, implementation and testing all the way through to review and operation. This is not a purely quantitative difference, but a qualitative one. Shorter cycles change how decisions are made, how errors are detected and how quickly a team reacts to changing requirements.
An assembly is a more accurate analogy than a sprint. Agents work continuously, including at night and weekends. Releases become more frequent, iterations smaller. Once you’ve worked at this pace, you won’t want to go back.
4. Guided automation is the opposite of full autonomy
One of the most persistent misconceptions surrounding agent-based development is that agents program independently whilst humans look on. A look at real-world practice shows that this is not a viable approach.
Agents do not act freely; they act within structures defined by humans. In practice, this means highly specialised agents with a clearly defined focus and precise context working within explicitly defined handover points, automated quality gates and clear acceptance criteria. As the controlling authority, humans perform the tasks that actually require human judgement: architectural decisions, strategic direction-setting, final acceptance – not line-by-line checking.
5. Governance is mandatory, not optional
Agent-based development raises new questions for compliance officers. Which models can be used in which projects? How can we ensure that no code containing protected IP ends up in training data? Who bears the LLM costs, and how should they be allocated on a project-by-project basis?
These dilemmas can be resolved, but this needs to happen before the first major deployment, not afterwards. A standardised, legally compliant approach to LLMs with a transparent cost structure and defined governance rules is not a bureaucratic burden, but the necessary foundation for scaling agentic development.
6. Legacy systems are no obstacle with the right approach
The assumption that agentic software development only works on a greenfield site is widespread but incorrect. In project practice, it is evident that existing codebases, mature systems and mixed teams can indeed be integrated into agentic processes. The prerequisite is a methodology designed for this purpose.
The key principle is parallelism. Traditional and agent-based teams work within the same system, with clearly defined handover points and a coordination mechanism such as Kanban, which prevents conflicts between the different cycle frequencies. A traditional team works in two-week sprints, whilst an agency team working on the same project uses two-to-four-day cycles. This has already been tested in client projects.
7. Software is just the beginning
What works in software development isn’t limited to that field alone. The principles of agentic working broadly describe a basic model for collaboration between humans and autonomous systems. These include a clear division of roles, structured input, short cycles, guided automation and governance by design. Companies can apply these principles to many other contexts.
Agent-based approaches can be applied wherever processes are iterative, documentable and can be broken down into clearly defined steps, such as in quality assurance, document
processing or automated analysis. And they can prove effective in business processes that companies are still handling entirely manually today, not because the conventional approach makes sense, but because there has been no viable alternative so far.
