Active Group and "Agentic Engineering"

These past few months, we had many conversations on the future of software development - as did everyone in our industry. The topic is, of course, „Agentic Engineering“ (AE), the use of LLM-based agents to directly translate requirements into code for softwarte systems. We‘ve thought about both the general question and what this development means for us at Active Group, and how we will deal with the changing landscape around us.

Beyond productivity

Agentic Engineering promises significant productivity boosts in software development. Accordingly, many companies that develop software are currently investing massively in the use of AE in their processes. Many of our competitors advertise with consulting on and development with Agentic Engineering.¹

Of course, we develop efficiently at Active Group, even without AE. However, our claim is primarily that our software is better because we develop it with care. „Better“ means better for people - users whose lives are improved through the software. (And yes, that is a thing.) That‘s why we talk with our customers and seek the best solution, beyond merely translating requirements to code. Often enough, the best solution looks very different from what the original requirements had suggested.

Accordingly, our motto „software, with care“ does not square with the use of AE: The quality of generated code is lower than that of code written by humans. There are many sources on the net, for example this posting from the COOP Blog or this AI Productivity Paradox Report.

Problems with Agentic Engineering

There is another aspect that we find concerning, namely that LLMs are being used even for tasks that are amenable for deterministic processing, or even require it. This includes the spectacular hack of Instragram accounts where an AI had replaced the regular process of password change, validating public-service forms with AI in Germany or the use of LLMs for translating codebases from one programming language to another instead of a compiler.

The general issue - the question of when LLMs even are the right tool - was examined by our BOB keynote speaker Stefan Kaufmann in this talk (German only unfortunately). The talk is ostensibly about public administration, but the principles proposed by Stefan Kaufmann would sit well in many other fields.

Beyond the utility the problems don‘t stop: LLMs have gigantic externalities. Johannes Link‘s blog post 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 part of our software development. We do not presume to pass ethical judgement on users of LLMs - most of us do things with externalities, 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 technologies we use produce elegant code and flexible architecture. This includes functional programming, rich data modeling, and domain-specific languages. Inspired solutions bring us joy as well.

Furthermore, we like writing code, we take pleasure in thinking about the best approach to a software project, we delight in seeing great code written by a colleague, and we love to learn about new techniques and technologies. Moreover, we like to do all of that together and collaboration with the users of our code. What we love about software development is exactly what is missing under the use of AE. And it may be overly romantic, but we believe that good software can establish a connection between the developers and the users, and as a user, I‘m delighted when I feel that the developer took personal care.

Evidently, we‘re not alone. Our conference BOB had more attendees than ever, even though our program had zero AI-related talks. (Or maybe, indeed, because of this? One spontaneous reaction of one of our PR outlets was „Finally someone‘s doing a conference without AI again“.) Whenever we voice our reservations about AE, we regularly receive encouragement.

Occasionally, we get the response that LLMs democratize programming and make it accessible to folks who could otherwise only use their computer „passively“. However, this argument ignores the dependencies incurred by the use of AI for automation - democratization this isn‘t.

Indeed, the software-development community hasn‘t exactly outdone itself here, with ever more complex tech stacks and impenetrable terminological labyrinths. Unfortunately, LLMs don‘t generate competency in dealing with these technologies, just output.

Furthermore, maybe we - the community - have forgotten that there are other ways of making computers and specifically computer programming accessible, through easy-to-use technologies, mass-compatible didadtics, and through creating and valuing expertise. We‘re personally working on this through our trainings and the DeinProgramm project. There‘s still more to be done, however.

What does this mean for us?

For the time being, we won‘t integrate AE as an essential part of our software development processes. For every line of code that reaches a customer, we take responsibility for its correctness and freedom from intellectual property issues. In every project, we will continue to look for the best solution, with faithful cooperation with our customers and partners, the best technology, and great care.

Of course we support our partners and customers in all things software development, including dealing with AE-generated code. We predict that, in the medium term, AE will produce large amounts of mediocre code that requires improvement.

Accordingly, we will advise and train on the improvement of AE-based development processes and the resulting code, specifically with an eye towards architecture and long-term evolution.

This strategy carries risks for us: Customers might decide to only hire providers that use AE in the belief that this would be cheaper.

However, as I said above: The software we develop is different. We hope to continue finding customers and partners who value care in software development, who appreciate working together on great software, and who enjoy having their concerns heard and taken seriously.