Funktionale Programmierung -
Active Group and "Agentic Engineering"
Active Group and "Agentic Engineering"
de
23.06.2026<br>by Michael Sperber
These past few months, we had many conversations on the future of<br>software development - as did everyone in our industry. The topic is,<br>of course, „Agentic Engineering“ (AE), the use of LLM-based agents to<br>directly translate requirements into code for softwarte systems.<br>We‘ve thought about both the general question and what this<br>development means for us at Active Group, and how we will deal<br>with the changing landscape around us.
Beyond productivity
Agentic Engineering promises significant productivity boosts in<br>software development. Accordingly, many companies that develop software<br>are currently investing massively in the use of AE in their processes.<br>Many of our competitors advertise with consulting on and development<br>with Agentic Engineering.1
Of course, we develop efficiently at Active Group, even without AE.<br>However, our claim is primarily that our software is better because we<br>develop it with care. „Better“ means better for people - users whose lives<br>are improved through the software. (And yes, that is a thing.) That‘s<br>why we talk with our customers and seek the best solution, beyond<br>merely translating requirements to code. Often enough, the best<br>solution looks very different from what the original requirements had<br>suggested.
Accordingly, our motto „software, with care“ does not square with the<br>use of AE: The quality of generated code is lower than that of code<br>written by humans. There are many sources on the net, for example<br>this posting from the COOP Blog or this<br>AI Productivity Paradox Report.
Problems with Agentic Engineering
There is another aspect that we find concerning, namely that LLMs are<br>being used even for tasks that are amenable for deterministic processing, or even<br>require it. This includes the spectacular hack of Instragram<br>accounts where an AI<br>had replaced the regular process of password change,<br>validating public-service forms with AI in Germany<br>or the use of LLMs for translating codebases from one programming<br>language to another instead of a compiler.
The general issue - the question of when LLMs even are the right tool - was examined<br>by our BOB keynote speaker Stefan Kaufmann in this<br>talk<br>(German only unfortunately). The talk is ostensibly about public<br>administration, but the principles proposed by Stefan Kaufmann would<br>sit well in many other fields.
Beyond the utility the problems don‘t stop: LLMs have gigantic<br>externalities. Johannes Link‘s blog<br>post<br>summarizes the problem well:
acceleration of the climate catastrophe
intense downward pressure on the wages of entire occupational groups
gigantic theft of intellectual property
destruction of personal relationships
destruction of open-source ecoysystems
distortion of political discourse
destruction of learning and training paths
Accordingly, we have significant qualms to use LLMs as an<br>part of our software development. We do not presume to pass ethical<br>judgement on users of LLMs - most of us do things with externalities,<br>whether it‘s eating meat, driving cars, etc.
Expertise and Joy in Programming
Our software brings joy not only to the users. All the techniques and<br>technologies we use produce elegant code and flexible<br>architecture. This includes functional programming, rich data<br>modeling, and domain-specific languages. Inspired solutions bring<br>us joy as well.
Furthermore, we like writing code, we take pleasure in thinking<br>about the best approach to a software project, we delight in seeing great code<br>written by a colleague, and we love to learn about new techniques and<br>technologies. Moreover, we like to do all of that together and collaboration<br>with the users of our code. What we love about software development is<br>exactly what is missing under the use of AE. And it may be<br>overly romantic, but we believe that good software can establish<br>a connection between the developers and the users, and as a user, I‘m<br>delighted when I feel that the developer took personal care.
Evidently, we‘re not alone. Our conference BOB<br>had more attendees than ever, even though our program had zero<br>AI-related talks. (Or maybe, indeed, because of this? One<br>spontaneous reaction of one of our PR outlets was „Finally someone‘s<br>doing a conference without AI again“.) Whenever we voice our<br>reservations about AE, we regularly receive encouragement.
Occasionally, we get the response that LLMs democratize programming<br>and make it accessible to folks who could otherwise only use their<br>computer „passively“. However, this argument<br>ignores the dependencies incurred by the use of AI for automation -<br>democratization this isn‘t.
Indeed, the software-development community<br>hasn‘t exactly outdone itself here, with ever more complex tech stacks<br>and impenetrable terminological labyrinths. Unfortunately, LLMs don‘t<br>generate competency in dealing with these technologies, just output.
Furthermore, maybe we - the...