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 agent 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.

Why even think about it?

Agentic Engineering promises significant productivity boosts in software development. Moreover, 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. (Not necessarily under that name.)

What are the benefits?

There aren‘t really reliable numbers on the actual productivity boosts through AE: It seems that anything between -10% and a factor of 30 goes.

It‘s common knowledge that we at Active Group develop using functional programming, which already produces a significant productivity boost compared with standard technologies and requires less boilerplate. It is our assumption, that the boost for our development activities would be below the factor of 2.

There seems to be consensus that the quality of generated code is lower than that of code written by humans. For this, there are many sources on the net, for instance this posting from the COOP Blog or this AI Productivity Paradox Report.

There is another aspect that we find disturbing, namely that LLMs are being used that are amenable for deterministic processing, or even require it. (For instance, if the task is translating codebases to other languages - that‘s the job of a compiler.)

The general issue - when LLMs are even the right tool - was examined by our BOB keynote speaker Stefan Kaufmann in this beautiful 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.

LLMs and Ethics

Johannes Link‘s blog post summarizes the problem well - LLMs have gigantic externalities. Here are only the most obvious ones:

  • acceleration of the climate catastrophe
  • intense downard 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 integral part of our software development. We do not dare pass ethical judgement on users of LLMs - most of us do things with externalities, if it‘s eating meat, drive cars, etc.

Expertise and Joy in Programming

The claim of Active Group isn‘t just that we develop efficiently, but that our use of functional programming produces better software - with rich data modeling, domain-specific languages and sustainable architecture. „Better“ means better for people - users whose lives are improved through the software (and yes, that is a thing) as well as future software developers that enjoy elegant code and flexible architecture.

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 colleage, and we love to learn about new techniques and technologies. Moreover, we like to all of that together and together with the users of our code. What we love about software development is exactly what is missing under the use of AE. Our motto, „Software, with care“ also does not fit with the use of AE. And it may be overly romantic, but we believe that good software can establish connection between the developers and the users, and as a user, I‘m delighted when I have the feeling 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. (Or maybe because? One spontaneous reaction of one of our PR outlets was: „Finally a conference again without AI“.)

Occasionally, we get the response that LLMs democratize programming and make it accessible to folks who could otherwise only use their computer „passively“. Indeed, the software-development community hasn‘t exactly outdone itself here, with ever more complex tech stacks and impenetrable terminological labyrinths. However, this argument ignores the dependencies incurred by the use of AI for automation - democratization this isn‘t.

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 expterise. We‘re personally working on this through out trainings€ and the DeinProgramm project. There‘s surely more to be done, however.

What does this mean for us?

For the time being, we won‘t use AE as an intrinsic part of out software development processes, and accordingly won‘t advertise with it either.

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 the best technology, great care, and faithful cooperation with out customers and partners.

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, this 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:

  1. Customers may choose to only work with providers that use AE.

  2. Competitors might get sufficiently more productive than we are that it‘s no longer viable to hire us.

However, 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.