Agentic Coding: Why AI Agents Are a Poor Choice (With Proof)

Anyone who wants to do "something with AI" and use AI for programming as well will often think of agentic coding, that is, AI agents that write code. That is not a good idea. Here is the proof, using a concrete example. AI coding, however, makes sense when it is used correctly.

Agentic coding is the use of an AI agent to write program code. The human (usually not a programmer) types an instruction into a chat box and waits for the finished result.

An example of such an instruction, also called a prompt:

Create a Python program that tests a website for security vulnerabilities.

This is just a simple example, please do not copy it! The prompt is imprecise and should not be used like this. This post is only about looking at the output of AI as an artificial programmer.

An AI agent works differently from a pure language model, which can also be used as a programming model. Agents are described in more detail in a separate article. In short, agentic coding runs in an autonomous loop, whereas with "normal" AI programming the human steps in after every step, makes decisions and gives new instructions.

The advantage of the agent: the human only has to start it with an initial instruction and can then do other things. In the ideal case, the result is a perfectly running program. Reality looks different, as shown below. The disadvantages of agentic coding were also discussed in a previous post.

An intermediate result of the agent could be the following routine, which checks on a web page (HTML) whether an input field is evaluated in JavaScript code:

def _input_name_used_in_js(name: str, js_content: str) -> bool:
 e = re.escape(name)
 patterns = [
  rf'getElementById\s*\(\s*["\']{ e }["\']',
  rf'querySelector\s*\(\s*["\']#{ e }["\']',
  rf'querySelector\s*\(\s*["\'][^"\']*#{ e }[^"\']*["\']',
  rf'["\']{ e }["\'].{{0,200}}(?:innerHTML|eval|location|fetch|write)',
  rf'(?:innerHTML|eval|location|fetch|write).{{0,200}}["\']{ e }["\']',
 ]
 return any(re.search(p, js_content, re.DOTALL) for p in patterns)

This code (slightly shortened here) does not just look complicated, it is complicated. No human, not even the best programmer in the world, sees at once what is happening here. The reason is so-called regular expressions, which are useful for finding text very quickly and flexibly.

The code above is missing an important special case that occurs very often: support for the popular JavaScript library jQuery. When I manually prompted the AI and asked it to take jQuery into account, the following came out:

def _input_name_used_in_js(name: str, js_content: str) -> bool:
    e = re.escape(name)
    patterns = [
        rf'getElementById\s*\(\s*["\']{ e }["\']',
        rf'querySelector\s*\(\s*["\']#{ e }["\']',
        rf'querySelector\s*\(\s*["\'][^"\']*#{ e }[^"\']*["\']',
        rf'$\(\s*["\']#{ e }["\'\s)][^;]{{0,80}}\.val\s*\(',
        rf'#{ e }["\'][^;]{{0,80}}\.val\s*\(',
        rf'$\s*\(\s*["\']#{ e }["\']',
    ]
    return any(re.search(p, js_content, re.DOTALL) for p in patterns)

A practiced eye notices that the AI added three new pattern lines (patterns) and deleted two lines that were there before (printed in bold above). Finding this out did not require fully understanding the code. Counting and "healthy" software developer common sense were enough.

The right thing would have been to add the three new pattern lines (which happened) and to keep the two deleted lines instead of deleting them.

The human (me) noticed this.

Had an AI agent been used, this problem would have arisen unnoticed. Nobody would have spotted it. The program would have been wrong because it would not have taken important constellations into account. Someone would have noticed at some point. Then the same incompetent "programmer" who operated the AI agent would have had to call on the AI agent again, to perhaps get the desired result after many unsatisfying, costly attempts.

Another example:

The original code looked like this:

The AI agent extended this code with parts before and after it. However, the original turned into this:

Instead of extending the original program, the original was replaced by a comment ("//" is the comment marker). The program continued to work, but without an important additional function.

The end of humanity

A "process automator" commented on this post on LinkedIn. He said that such "copy & paste errors" do not occur in his process. He also said that "good agencies" can avoid such problems.

The facts: First, this is not a copy & paste problem but an AI error. Second, no software development company worth its salt would call itself an "agency". Anyone who borrows the term "agency" apparently has a great need to. The most common reason for such linguistic detours is probably a lack of software development competence.