AI-powered code generation CLIs like Claude Code, Gemini CLI, OpenAI Codex, and GitHub Copilot are incredibly productive tools. They can scaffold projects, refactor code, and even run bash commands on your behalf.

But here's the catch: they can also hallucinate. And a hallucinated rm -rf or a runaway npm install that fills your disk is not something you want happening on your main OS.

The Problem​

These tools are powerful, but when you grant them shell access, you're essentially trusting an LLM to not mess up your system. That's a gamble I'm not willing to take on my daily driver.

Consider these scenarios:

• A hallucinated command wipes important files
• An infinite loop fills your disk with garbage
• A misconfigured script modifies system files
• Dependencies get installed globally, polluting your environment

The Solution: Sandboxed Docker Containers​

This is the first part in a series on sandboxing AI codegen CLIs. We're starting with the simplest, most portable approach: a Docker image with a lightweight wrapper script.

By running AI codegen CLIs inside a Docker container, you get:

1. Full isolation - The container can't touch your main OS
2. No root access - The container runs as a non-root user with no sudo
3. Persistent AI config - The .ai/ folder survives between runs
4. Batteries included - Claude, Codex, Copilot, Gemini, plus language runtimes and dev tools
5. One command - A wrapper script handles everything

The beauty of this approach is its simplicity. No IDE plugins or special configuration needed - just Docker and a shell script.

What's in the Box?​

The aidevtools Docker image ships with:

AI Assistants: Claude CLI, OpenAI Codex, GitHub Copilot, Google Gemini CLI

Language Runtimes: Java (SDKMAN), Node.js (NVM), Python, Go, Rust, Deno

Dev Tools: GitHub CLI, Neovim, tmux, direnv

The image is fully customizable via build args - disable what you don't need:

docker build --build-arg INSTALL_JAVA=false --build-arg INSTALL_RUST=false .

Getting Started​

Getting started is straightforward:

# Pull the pre-built image
docker pull ghcr.io/sugarfreebytes/aidevtools:latest

# Run from your project directory
./aidevtools.sh          # Interactive shell
./aidevtools.sh claude   # Launch Claude directly
./aidevtools.sh gemini   # Launch Gemini directly

The wrapper script mounts your current directory into the container and persists AI tool configurations in a local .ai/ folder between sessions.

Read the full tutorial: Sandboxing AI CLIs with Docker

What's Next?​

This is Part 1 of a series on sandboxing AI codegen CLIs. In upcoming posts, we'll explore DevContainers, IDE integration, and more advanced isolation strategies.

Spring Boot testing library offers an out-of-the box @SpringBootTest annotation that boots the entire application and gets it ready for testing.

However, getting backing services (e.g. databases, caches, message brokers) available and not interfering with development or other environments might still be a challenging task.

In this post, I'm going to introduce a way to benefit from using containers and JUnit Jupiter extension model to test a Spring Boot application in an environment that closely resembles the production environment (e.g. a real database instead of an in-memory one).

Testcontainers​

Testcontainers for Java is a Java library that supports JUnit tests, providing lightweight, throwaway instances of common databases, Selenium web browsers, or anything else that can run in a Docker container. a project whose purpose is to uniformize and facilitate managing containers from a jvm runtime.

When combined with the JUnit Jupiter extension model, Testcontainers for Java provide a simple yet powerful way to spin up the necessary backing services in a declarative way.

The @Testcontainers extension supports two container lifecycle modes, depending on how the contained field is declared.

1. An instance-level @Container annotated container will be restarted after every test method. This is a good use-case example for a fast-bootstrap container.

   @Testcontainers
   public class CacheTests {
       @Container
       private final GenericConainer container = new GenericContainer("image-name");
   }
   

2. A class-level @Container annotated container will be shared across test methods heavy container. This is a better choice for heavier containers, that takes longer to become available, like a database or a message broker.

   @Testcontainers
   public class RepositoryTests {
       @Container
       private static final GenericConainer container = new GenericContainer("image-name");
   }
   

In some cases, is worth reusing the containers across the entire set of integration tests. This can be accomplished by introducing singleton containers in a common class that every test-class can extend.

Using static initializers helps to bind the necessary dynamic parameters to the Spring configuration keys using system properties.

However, using base classes comes with some limitations, as tests that need to reuse multiple containers introduce complex hierarchies.

One way to overcome these limitations is to introduce custom extensions for each container.

public class TestcontainersExtensions {

   public static class Postgres implements Extension {
      private static final PostgreSQLContainer<?> container;

      static {
         container = new PostgreSQLContainer<>("postgres:15.2");
         container.start();

         System.setProperty("spring.datasource.url", container.getJdbcUrl());
         System.setProperty("spring.datasource.username", container.getUsername());
         System.setProperty("spring.datasource.password", container.getPassword());
      }
   }

   public static class Redis implements Extension {
      private static final GenericContainer<?> container;

      static {
         container = new GenericContainer<>("redis:7.0.9");
         container.withExposedPorts(6379).start();

         System.setProperty("spring.data.redis.host", "localhost");
         System.setProperty("spring.data.redis.port", String.valueOf(container.getMappedPort(6379)));
      }
   }
}

This way, infrastructure details like image name/version and Spring configuration are moved away from test classes and contained in the custom Extension implementations.

Individual test-classes can choose only the extensions they need. At the same time, extensions imported in multiple tests will reuse the containers they manage.

@SpringBootTest
@ExtendWith(TestcontainersExtensions.Postgres.class)
public class SomeRepositoryTests {

}

@SpringBootTest
@ExtendWith({TestcontainersExtensions.Postgres.class, TestcontainersExtensions.Redis.class})
public class SomeRestControllerTests {

}

It's good, tempting, it comes instantly, but on a long run it will most probably cause some issues. What are the similarities when it comes to building applications?

Copy-pasting code​

So, the requirement is clear-enough so that can be coded.

Other project's sources or some stackoverflow.com snippets seem to be the perfect solution and ready to be integrated with the rest of the codebase.

The problem I see with this approach is that the code being copy-pasted is at most the best version of what a developer could think of at a given point in time, in a given context, for a given problem.

Even if the problem to solve is identical, better options could be currently available:

• Language improvements (e.g. using a lambda expression instead of an anonymous instance when creating a Comparator)
• API improvements (e.g. using List.of() instead of a custom method for creating a constant list)
• Dependencies improvements: libraries used by the copied code could no longer be needed, as similar features are now available in the JDK (e.g. benefit from the Stream API instead of depending on guava)

By not considering these concerns, the code will inherit the technical debt of the one being copied.

Even if the code is pretty recent and technical debt free, the coding style might not fit the one of the codebase being developed or the requirements related to quality (e.g. Sonar rules).

But it could also be the case that the problem is just similar, but not identical.

It can be simpler, which makes the inserted code over-complex. For instance, the desired return value of a method can be a just a Collection - it doesn't need to be a List, as ordering doesn't matter.

It can have different requirements when it comes to validation. Maybe the copied code is considered safe, as it's intended to be used only internally, while the desired code is intended to be called from the outside world (e.g. from a REST endpoint).

The differences can be so subtle that can only be identified during the testing phases.

Unit tests​

There is also a series of things to question when it comes to unit tests and which might signal some red flags if the answer is 'No':

• Is the copied code covered by unit tests?
• If it does, are they going to get copied as well?
• Do they still make sense for the functionality being developed?

With all that in mind, when it comes to writing code for solving a problem that cannot benefit from using a library or a service or any sort of reusable software component, I find it way cleaner and in the end easier to just write code from scratch, rather than copying code and making all sort of adjustments in order to make it fit the functional, coding style & quality and testing coverage requirements.

There are many options when it comes to which framework to use for developing JVM-based microservices these days.

In this post, I'm going to summarize how they perform on two simple day-to-day scenarios (with some variations) from wrk's point of view.

Wrk Tool​

While searching a simple cli tool for measuring performance of REST services, I found plenty of references to wrk - a HTTP benchmarking tool able to generate a significant load while running on a single multi-core CPU of an usual dev workstation.

Its usage is pretty straightforward: set the test duration, the number of threads and connections those threads are going to use during the test and optionally add a custom Lua script for making more than a simple GET request.

Test Scenarios​

The two test scenarios consist of GETting and POSTing Articles resources, as defined in the gothinkster/realworld "mother of all demo apps" project.

Both scenarios include:

• Reading the data from memory
• Using POJOs (requests) responses, (de)serialized with Jackson
• Varying the resource size, from 50B to 500K
• Using 10 threads and 100 connections (which will put a decent load on the tested applications)
• Starting, warming-up the application for 60s, run the test for another 60s, then stopping it

Spring Boot - the "Classic Flavour"​

A Spring @RestController

class Controller {
    @GetMapping
    public ResponseEntity<?> getArticles(
            @PathVariable("path") String path
    )

    @PostMapping
    public ResponseEntity<?> saveArticles(
            @PathVariable("path") String path,
            @RequestBody Articles articles
    )
}

Spring Boot Web Flux​

Functional-style routes

class Configuration {
    public RouterFunction<ServerResponse> routerFunction() {
        route(GET("/spring-boot-webflux/{path}"), req -> { /* ... */ })
        .and(route(POST("/spring-boot-webflux/{path}"), req -> { /* */}))
    }
}

Quarkus w/ Vertx​

A declarative vertx route

class Controller {
    @Route(path = "quarkus-vertx-web/:path",
            methods = HttpMethod.GET)
    void getArticles(RoutingContext rc)

    @Route(path = "quarkus-vertx-web/:path",
            methods = HttpMethod.POST)
    void saveArticles(RoutingContext rc)
}

Micronaut​

A Micronaut @Controller

class Controller {
    @Get(uri = "/micronaut/{path}")
    public HttpResponse<?> getArticles(
            @PathVariable("path") String path
    )

    @Post(uri = "/micronaut/{path}")
    public HttpResponse<?> saveArticles(
            @PathVariable("path") String path,
            @Body Single<Articles> articles
    )
}

Micronaut Reactive​

A Micronaut @Controller with RxJava requests and responses

class Controller {
    @Get
    public Maybe<Articles> getArticles(
            @PathVariable("path") String path
    )

    @Post
    public Maybe<Articles> saveArticles(
            @PathVariable("path") String path,
            @Body Single<Articles> articles
    )
}

The code and test scripts can be found here

Results​

The smaller the payload is, the bigger the differences between frameworks (and the same framework flavors) are, while when using an extreme payload size it doesn't seem to matter any longer.

GET Scenario​

POST Scenario​

It's good, tempting, it comes instantly, but on a long run it will most probably cause some issues. What are the similarities when it comes to building applications?

Unnecessary mix of frameworks and libraries​

So, adding yet another maven dependency might solve a particular problem "easily" and "for free", we might say. Indeed, adding just a few lines of code in your codebase for using that library seems really tempting, and in the end productive, but:

Dependency Clash​

Is this going to make the dependency hell even worse?

Licensing​

How is that library licensed? Is it in line with the rest of the policies?

Size​

What is the size of that library? Will it significantly increase your build size, transfer time, application memory usage?

Security​

How about the security? Does it come from a trustworthy source? (How one programmer broke the internet)

Coding style​

Does that library API affect the overall coding style of the codebase? E.g. Is it worth introducing an Rx-ified library while the rest of the code is entirely synchronous?

In order to properly address this kind of checklist, you might need to spend some serious time.

In the end, it could take less to just implement yourself that functionality.

On top of that, using one of the "pure" platforms (JavaEE containers, Spring Boot, Quarkus, Micronaut, Helidon) should usually cover most of the needs for regular applications. And such an approach comes with a huge advantage - all the pieces are tested and released together and you don't need to worry about individual libraries versions (e.g. Jackson).

Spring allows us to publish ApplicationEvent instances using the managed ApplicationEventPublisher instance.

Each such ApplicationEvent can be consumed by the interested parties by annotating methods with @EventListener or @TransactionalEventListener.

Let's consider the following example: during development and testing, each time we get an UserEvent event, we want to log it.

public class UserEvent extends ApplicationEvent {
    // ...
}

public class UserLoginEvent extends UserEvent {
    // ...
}

public class UserRegisterEvent extends UserEvent {
    // ...
}

public class UserLoginService {
    private ApplicationEventPublisher applicationEventPublisher;
    //...

    public UserLoginEvent login(String loginToken) {
        UserLoginEvent userEvent; //  =  ...
        applicationEventPublisher.publish(userEvent);
        return userEvent;
    }
}

@Component
@Profile("dev")
public class UserEventLogger {
    @EventListener
    public void onUserEvent(UserEvent userEvent) {
        LOGGER.info("User event {}", userEvent);
    }
}

From a consumer perspective, it seems very loose-coupling.

But how about the producer?

Every class that is interested in publishing application events needs an ApplicationEventPublisher instance. And even though Spring provides one out-of-the-box, it's still another dependency to add to all the classes that need it. Maybe it's not so demanding, but how about having more classes publishing events? Is it worth doing the same work everywhere?

public class UserRegistrationService {
    private ApplicationEventPublisher applicationEventPublisher;

    public UserRegisterEvent register(UserRegistrationData data) {
        // ...
        UserRegisterEvent userEvent; // = ...
        applicationEventPublisher.publish(userEvent);
        return userEvent;
    }
}

How about having a corresponding declarative mechanism for publishing application events the same way we have for consuming them?

For this, we need a way to identify those methods interested in publishing events. And what could be more useful to get from a method signature than the return value?

So we need to identify some (public) non-void methods that can return ... anything. Not so suitable for interfaces, right?

Here's where AOP might help us.

Let's keep it exactly the same as Spring already allows methods to declare themselves event consumers; let EventPublisher be the equivalent annotation. In this case:

public class UserLoginService {
    // ...

    @EventPublisher
    public UserLoginEvent login(String loginToken) {
        UserLoginEvent userEvent; // = ...
        return userEvent;
    }
}

public class UserRegistrationService {
    // ...

    @EventPublisher
    public UserRegisterEvent register(UserRegistrationData data) {
        // ...
        UserRegisterEvent userEvent; // = ...
        return userEvent;
    }
}

Now we still need to inject the ApplicationEventPublisher, but it's going to happen in a single place: that is an aspect that is executed after each @EventPublisher that returns a subclass of ApplicationEvent.

public class EventPublisherAspect {
    private ApplicationEventPublisher applicationEventPublisher;

    @AfterReturning("@annotation(EventPublisher) && execution(ApplicationEvent+ *(..)")
    public void publishApplicationEvent(ApplicationEvent event) {
        applicationEventPublisher.publish(event);
    }
}