AI Agents Coding Bad Practices

 

In this post we will review how NOT to use AI agents for coding. I am creating this post since I've encountered too many cases of bad code created by AI agents due to people unaware of these issues. 

We now have AI agents to due our job, all we do is create a prompt and everything is done for us by the great LLM mind and the tools supplied by the agent. 

At least, that' what most managers think, but they are wrong.

An AI agent is a powerful tool that can reduce some tasks duration by order of magnitude. However it can also create an illusion of a great progress while you're actually causing damage in the long run. 

Some people are telling: "I am not a software engineer, but I have create this project, and I can add features with Claude code". They are wrong.

Using an AI agent to create a production ready code that can be used and maintained for a long time requires a human supervisor who understand the requirements for such a solution. This might change in the future, but for now it is mandatory. The AI agent create many mistakes in the planning stage, in the architecture domain, and in the implementation phase. You need an experienced software engineer to get a good product.

In case all you want is a simple one time task done, or a proof of concept, the AI agent can do this for you. However anything else must have include experience of building a production solution that an AI agent still does not posses.

Some examples I've encountered are below.

You create a product that processes data path requests, and the AI agent is creating the code using Python. 

Really? This could never hold for heavy load. Use a production ready language such as GO...

You run your product on an EC2 instance with multiple processes, but then you discover that some of the processes are terminating due to errors, so you ask AI to handle it, and it created long bash scripts to check the health of the processes and to restart them in case of failure.

Really? Use a kubernetes deployment with liveness and readiness probes...

You use AI agent to create the unit tests for your code, and it creates 10 unit tests each checking another aspect of the feature. You end up with 10000000 (add more zeros at your will) tests each checking a small aspect of the feature, duplicating most of the logic, each using a different approach to test the code.

Really? Add a tests infrastructure and combine similar tests flows into a single test...

You create an new microservice in the kubernetes deployment, reusing the project standards. You test run it locally and everything looks great, but then in production the service causes your entire deployment to be unresponsive. You try checking the logs but they are exploded with log records from the new service and you cannot find the problem.

Really? Choose the correct algorithm to perform your task. Use configurable limits to prevent resource .exhaustion.

Given all this, how should we use an AI agent?

Considering the current LLM maturity we should treat it as both professional and stupid. The risk in using AI agent is that it might take a wrong turn and hit a wall. Then it will build a bug hammer to break the wall. Then it will build a garbage truck to clear the leftovers.

We need to identify these wrong turns as soon as they start. This is done by coding near ~100% of the tasks using the AI agent, but use a small units of work and monitoring the changes. Instead of prompting: "I have a bug in this project that requests longer than 10K are not saved to the database, fix it!" split it to multiple steps. First ask the AI to identify the bug. Then think of the solution yourself (yes, actually use the brain muscle) and instruct the agent of the solution, like "In case the requests are longer than 10K, use a secondary table to save them. Start with the database schema changes only". Notice this cannot be done by a novice software engineer which is not aware of the system implications a solution alternatives. You can consult with the LLM, but again the LLM might provide the book-solution which is over complicated for your needs and maybe does not address the real problem (wrong turn again).

To sum:

AI agent is a great tool. Nowadays I can accomplish a super high throughput of tasks. To achieve this, it is important to understand the advantages and the disadvantages of the LLM. 

GO Libraries as Multi Repo project

 

In this post we review the steps to create GO libraries as a multi repo project. Originally we have used a mono repo for our projects. Mono repo is good and easy solution for a product that need to evolve fast, keeps changing in terms of services and architecture. However for a more mature product with a large code base, and specifically for multiple products using a shared code this causes code duplication and redundant work.

These are the steps I've made to externalize the common libraries from a project into a common repo using by multiple products.

Libraries Code Updates

Create a new repo (bitbucket in this case) and move the libraries code to it. The libraries were already setup as GO modules, so this was pretty easy. 

I've added all the libraries under the go-lib folder, for example

~GIT-ROOT/go-lib/library1

The important thing to notice is using GO standard for the package name, for example the package name

com.my-company.project1.library1

is updated to 

bitbucket.org/my-company/common/go-lib/library1

In case of cross-library usage we can use replace in the go.mod. The replace command affects only when building the actual module and not when another project that uses the library is compiled. For example:

replace bitbucket.org/my-company/common/go-lib/library2 => ../library2

Libraries CI/CD

I wanted to automated the entire versioning of the libraries, so I called a script as part of the Jenkinsfile that loops over the list of libraries:

#!/usr/bin/env bash

set -e
cd "$(dirname "$0")"
buildVersion=$1
cloudCredentials=$2
fullVersion=v1.0.${buildVersion}
mapfile -t modules < modules.txt
tags=()
for module in "${modules[@]}"; do
  tag="${module}/${fullVersion}"
  git tag "${tag}"
  tags+=("${tag}")
done
git push https://"${cloudCredentials}"@bitbucket.org/my-company/common "${tags[@]}"

This script creates a tag according to the go standard, for example:

go-lib/library1/v1.0.1234

Consumer Project

The bitbucket repo is a private repo, and the consumer project CI/CD must use credentials to access the libraries. On the other hand local build are using private key to access the bitbucket. This was a bit tricky, but eventually I've updated the docker build to dynamically decide on the method to access the private bitbucket repo.

This is the result dockerfile related section:

#================
# Stage1: compile
#================
ARG dockerCacheRepo
FROM ${dockerCacheRepo}golang:1.26.4 AS go-compiler
ARG BITBUCKET_USE_SSH=true
ARG BB_USER
ARG BB_TOKEN
ENV GOPATH=/go
ENV GOBIN=/go/bin
ENV GOPRIVATE=bitbucket.org/my-company/*

...

# Configure Bitbucket authentication
RUN if [ "$BITBUCKET_USE_SSH" = "true" ]; then \
        echo "Using SSH authentication for Bitbucket" && \
        git config --global url."git@bitbucket.org:".insteadOf "https://bitbucket.org/" && \
        mkdir -p ~/.ssh && \
        ssh-keyscan bitbucket.org >> ~/.ssh/known_hosts; \
    else \
        echo "Using HTTPS authentication for Bitbucket" && \
        git config --global credential.helper store && \
        echo "https://${BB_USER}:${BB_TOKEN}@bitbucket.org" > ~/.git-credentials; \
    fi
# Download private dependencies
RUN --mount=type=ssh \
    go mod download

...

RUN go build -o /output/___PROJECT___

The ENV GOPRIVATE instructs GO to use credentials to access libraries with a specified prefix, and we have a BITBUCKET_USE_SSH flag to decide whether to use credentials or SSH.

Local Development

One last issue is that we still need IDE development to recognize the common repo, and hence each developer need to setup this on the GO configuration:

go env -w GOPRIVATE=bitbucket.org/my-company/*
git config --global url."git@bitbucket.org:".insteadOf https://bitbucket.org/

Final Note

Once all this is done we gain a smaller git repo for each project, and a central update of the common libraries. in addition each project directly controls the each library version in it go.mod, for example:

require bitbucket.org/my-company/common/go-lib/project1 v1.0.19

This gains a great flexability.

I've also added the script to update all dependencies using GO CLI:

go get -u ./...

and alternatively upgrade only the libraries using:

    go get \
      bitbucket.org/my-company/common/go-lib/library1@latest \
      bitbucket.org/my-company/common/go-lib/library2@latest