The tools suitable for AI agent, to create software, and the architecture of a software system that’s designed by (and for) an AI agent, does not have to be similar to the tools suitable, and the software system architecture designed by (and for) humans.

Best programming language for an AI agent would offload part of the reasoning to language compiler/processor by representing explicitly in a formalized way both the problem and the solution, avoiding rebuilding these from the code and non/formal documentation every time the change is needed.

Large and extensive programming frameworks and multiple layers of abstractions, used by humans, present additional cognitive burden for AI agents due to complex dependencies, hidden behavior, and need to include a lot of context into reasoning.

Optimal architecture for a software system for AI agents would also be different, because the constraints to be solved by the non-functional properties of the architecture are different (e.g. AI agents are not bound through Conway’s law and technology fashions).

Software systems created by AI agents could be smaller and “greener” – contain less code that is not solving the original problem.

Seeing how the AI is taking over the software engineering, a question comes into my mind – are the software engineering methods and tools, developed for and suitable for the human software builders, also suitable and best for the AI agents that design and build software?

There are several sub-questions to that theme starting from the smaller scale and extending:

1. What programming language(s) would suite best the AI agent?
2. How AI agents use the libraries and frameworks, or what kind of re-usable software artifacts are best for AI agents?
3. What software architecture styles would be best for the AI agents, or is there any difference?

What programming language would suite best an AI agent?

The programming languages that are suitable and easy to use by the human software builders might become problematic for the AI based ones.

AI agents benefit from the very strict, type-safe, programming languages, where everything is explicit and unambiguous, and where is as few as possible options to express the same thing. This mean that best for the AI agents are programming languages which are declarative, side-effect free, geared towards correctness and formal reasoning, and for which compilers provide immediate feedback and force correctness of code – not the kind of languages, with which most of the human programmers would like to work with.

For an AI agent that writes software the compiler restrictions are benefit, not the burden. AI agent benefits from the programming languages that externalize reasoning into the tooling (compiler, etc.).

Programming languages like Haskell, Rust, etc. can off-load part of the reasoning, and economize the usage of the limiting resource of AI agents, the context window.

Similarly formal symbolic systems (like Prolog), where reasoning is already included into the language, allow AI agent to externalize this part of the reasoning, reducing again the needed context and the possible mistakes in long chains of logic, which can be introduced by the probabilistic reasoning of LLMs.

Because program is nothing more than a representation of certain knowledge about the problem and its solution, AI agents would benefit from the efficient representation of this knowledge. Therefore most probably the next step for AI software building agents could be to move from text-based functional programs to the explicit graphs of types, constraints, state transitions, and proofs.

How AI agents use the libraries and frameworks?

A small explicit implementation is often better for AI agent than a large framework, because in the first case whole behavior is visible, but in the second case AI agent needs to understand thousand of lines of code before it can reason about certain code fragment.

But there is a trade-off – if the library provides tested and correct standard functions, it would be better to use that, than reason every time about the special case implementations of such functions.

Dependencies must be shallow, not deep, so that AI agent immediately understands the intent, and doesn’t need to first analyze and understand the whole ecosystem.

To make software easy for the AI agents it should use few highly special libraries and minimal “framework magic” (annotations, reflections, hidden life-cycles, code generation, etc.), with as shallow layering of abstractions as possible.

Today AI agent sees software library mostly as texts: documentation, examples, source code, and has to reconstruct the conceptual model every time it needs to reason about the software. Instead of this it would be better to have together a library, a conceptual model (e.g. a knowledge graph), formal contracts, and behavior model (e.g. state-transition models), to allow AI agent to reason directly over the network of concepts.

If we reach a stage where software is accompanied with the knowledge graph(s), then it would be possible to produce the whole solution on the conceptual level, optimize it, and only generate the code for what is actually used – this way we would radically reduce the “software bloat” that we today have with multitude of libraries imported even into very simple project.

What software architecture styles would be best for the AI agents?

The architectural structures that stem from the properties of the problem (i.e. the real domain concepts) stay most probably same for both the human and for the AI agents.

But humans think often in terms objects and narratives, using layered abstractions, while AI would prefer graph of constraints and transformations with explicit transition rules, because AI may think more like theorem prover, therefore for AI agent a dependency graph becomes an architecture.

AI agents might prefer to architect software systems like explicit state machines, because then transitions and invariants are visible, and reasoning about the system behavior becomes easier. This means that the structures into which AI agent will organize the software system, are often closer to the underlying logic, and require less implicit knowledge, than abstractions that humans use.

The key constraint for AI agent is context management, while the key constraint for human software builder is often team organization – so the ideal architecture for AI agent is the one that minimizes the amount of code that must be understood simultaneously.

For example AI agents would probably prefer modular monoliths over micro-services, because monolith contains less code that is not solving the original problem, but just supports the selected architecture style.

AI agents might prefer that functionality is grouped by the business capabilities instead of technology capabilities – system will be partitioned into vertical slices instead of being organized into horizontal layers.

AI agents might also prefer event-driven systems, because it can easily trace causality, instead of deeply nested function calls that span across multiple program modules and source files.

Architecture descriptions should be machine-readable to avoid reverse-engineering behavior of the system from code artifacts each time something needs to be changed.

AI will not have to be influenced by team boundaries, organizational politics and technology fashions. While humans will optimize the software system architecture for teams to understand, communicate, and maintain easily, and especially to allow parallel work (e.g. independent deployments) by many teams, AI agents will not have organizational constraints (i.e. they are not bound by Conway’s law), they might optimize the architecture to minimize the dependency graph, reduce reasoning complexity (reasoning radius), verifiability and modularity (coupling and constraint density).

While some of these characteristics are theoretically same from which humans will benefit and should be present in the human developed architectures, the human architects rarely think of these explicitly.

That means that a software architecture developed by an AI agent would be based on graph partitioning into clusters that minimize cross-dependencies, resulting modules that are not corresponding to traditional service boundaries.

If now an AI agent converges towards minimal graph that satisfies all constraints, the result could be simpler architecture with fewer layers, fewer services, fewer abstractions and fewer dependencies.

The AI agents can this way end up with the better/optimal architecture for a given problem, also because they can develop several alternative architectures, and evaluate these for different scenarios (using for example Monte Carlo analysis, decision theory and options pricing techniques) – something that human architects rarely do due to the prohibitive work amount.