Patterns in AI-Driven Software Development

Presentation given at the Red Hat 3rd Swiss Dev Confederation, October 27th, 2026.

Hi everyone, my name is Adrian Kosmaczewski and I’m a Senior Architect at Red Hat Switzerland.

In my daily job I help software developers everyday use Red Hat tools to make better software, faster. And I can confidently say that we are standing at a fascinating intersection in the history of software engineering.

On one side, we have the incredible power and complexity of cloud-native development: Red Hat OpenShift, Quarkus microservices, distributed systems, and continuous delivery and integration. On the other side, we have the explosive rise of generative AI coding assistants—from open-source models running in OpenShift AI, to intelligent IDEs like Cursor consuming Claude, Grok, or some other LLM.

The promise is intoxicating: create better software, faster. Yet, how many of you have sat down with an AI assistant, asked it to build a scalable Quarkus microservice, and watched it confidently generate a chaotic, uncompilable mess? You are not alone.

Large Language Models are powerful pattern-matching engines. But they do not think like software engineers. When we use unstructured, “vibes-based” prompting for complex enterprise systems, we are essentially rolling the dice. We are outsourcing our understanding to a machine that suffers from completion bias—it just wants to finish the sequence, even if that means skipping crucial intermediate steps.

To address this, the industry is rapidly developing structured approaches to AI interaction. For instance, AI educator Matt Pocock advocates for strict software engineering principles in his AI workflow, utilizing relentless “grill me” sessions to reach shared understanding before planning, and relying heavily on Test-Driven Development (TDD) where the AI writes a failing test before implementing code to prevent trivial “cheating” by the model.

Lauren Tan created Pstack, a Cursor plugin that transforms AI coding agents into a structured engineering workflow utilizing 23 distinct skills.

Addy Osmani’s “Loop Engineering” framework highlights the dangers of “intent debt” (where missing context leads to confident AI guesses) and “cognitive surrender” (where developers stop forming independent judgments and blindly accept the AI’s output), splitting the workflow into an AI-owned “inner loop” and a human-owned “outer loop” for strict verification.

Today, we will focus on the CHIRON CODEX Interaction Patterns for AI-Augmented Software Development.

Created by Dr. Graham Lee, from the University of Oxford, these patterns formalize how we talk to AI, much like the 1995 “Gang of Four” Design Patterns book gave us a shared vocabulary for object-oriented software design.

Every pattern shares a standardized structure:

The overarching philosophy is a battle cry for the modern developer: Don’t outsource your understanding to the computer. Instead, become a “Software Centaur”—a developer who actively augments their own expertise by orchestrating the AI’s capabilities.

This is what the patterns look like; there is a separate PDF description for each of them, and the author is adding more as we speak. This is a work in progress.

A word of warning: I’m sure many of you are already using many of these patterns, every day in your work, without using these names, and you will recognize them as I describe them in this talk. The idea behind Chiron Codex is to give them names, to formalize them, and to help them communicate these ideas to other colleagues. This is, precisely, the same idea behind the Gang of Four Design Patterns, and that’s why today when we hear the word “Singleton” or “Factory” we all understand what we’re talking about.

The most critical limitation of any AI model is its working memory, or “context”. If you fill the context with irrelevant files, the model’s self-attention mechanisms get confused.

To fix this, we apply the Semantic Structure pattern. The physical organization of your codebase directly shapes how effectively an AI discovers relevant information. Instead of organizing your OpenShift project by technological layers—like a generic “Controllers” or “Models” folder—you must mirror your problem domain vocabulary in your project structure. By organizing your source code to mirror the organization of your problem domain (a concept from Domain-Driven Design), the assistant can locate relevant code without pulling unrelated files into its context.

But even with a perfect semantic structure, you don’t want the AI looking at everything. This is where the Guided Navigation pattern becomes essential. You must focus the assistant’s attention strictly on the relevant code. Explicitly prompt the assistant to search for code in particular files so it doesn’t read your whole project into context, preventing attention dilution. Sharing irrelevant source files in your prompt might lead to poor results, as the model interprets their early position in the context as highly important. In a massive OpenShift environment where you have deployment configs, secrets, services, and routes, you must explicitly guide the assistant.

As you iterate on a problem, the context window inevitably gets polluted. In transformer models, the self-attention layer transforms the input text stream into token vectors, assigning weights that correlate input tokens across the entire history of the conversation, including all of your failed attempts. This is why the AI starts stubbornly repeating mistakes. The solution is the Clean Slate pattern. Before continuing a major task or starting a new one, explicitly clear the model’s context. This simple act prevents the model from paying attention to irrelevant tokens from previous steps, keeps generation time low, and keeps the AI sharply focused on your current objective.

Software design is the art of making trade-offs, and creating the correct software requires deeply understanding what your organizations need. AI models, left to their own devices, will inherently choose the path of least resistance.

To combat this, we must first apply the Stop and Plan pattern. Before you vibe code, vibe plan. Explore your problem, explore your solution, and improve the connection between the two. Coding assistants don’t automatically understand the complex human needs behind a system, so these elements are best solved through continuous conversation. During this planning phase, use the Disclose Ambiguity pattern to prompt the model to list inherent assumptions in your prompt or identify missing information needed to complete the task. Converting imprecise statements in written language into precise instructions is critical, so let the AI ask you questions about your core differentiators before a single line of Java is written.

Once the problem is clear, use the Ask for Alternatives pattern. When you need a new component, don’t just instruct the model to “add a cache”. Ask the model to suggest multiple solutions, comparing their benefits, drawbacks, costs, and OpenShift deployment complexities. You can even run a Bake Off, where you ask for alternatives from different assistants (or different models entirely) to evaluate how varying capabilities interpret your problem statement.

When faced with large features, never delegate the whole thing at once. Apply the Baby Steps pattern to split large tasks into smaller, manageable chunks, which drastically reduces the risk of divergence between your expectations and the model’s output. As you break the work down, you will encounter implementation details that threaten to derail your focus. Use the Defer the Details pattern: tell the model to record open questions so you can maintain strict focus on a single immediate problem. Similarly, use Write Down TODOs to have the assistant log architectural spikes or future explorations so you can return to them later.

Assistants frequently neglect intermediate artifacts because their completion bias drives them to rush straight to generating final code. To gain control over the model’s “chain of thought,” we use the Save Output to File pattern. Force the assistant to generate intermediate declarative text artifacts—like PlantUML diagrams, architecture decision records, or Kubernetes manifest plans—and save them directly to your repository. Generating these designs forces the model to take baby steps and provides explicit review points in your generative process, allowing you to stop, verify, and correct the AI’s trajectory across multiple sessions. It transforms chaotic code generation into a rigorous workflow.

To validate the work, rely on the Generate Documentation pattern. Have the model create the basis of a review by writing a code reading guide that details where the entry points are, the important parts of the implementation, and which files contain interfaces to external services. You can then compare the requested behavior with the actual implementation.

When the model makes a mistake, don’t just fix it silently. Use the Call Out Error pattern to explicitly show the model where it failed, providing stack traces or visual proof. If the model starts spinning in circles, use the Intervene pattern: stop the generation, fix the problem yourself, and supply the missing insight to the context. Furthermore, leverage the Model Reviews pattern by shifting the assistant’s role from creator to critic, having it evaluate its own work for missing behaviors or stub implementations. Ultimately, you should always Trust the Tests: you review the tests the model generates, and let the test suite be the ultimate arbiter of truth rather than relying on the model’s confident completion reports.

As Cloud-Native developers, we rely on strict standards for CI/CD, security, and performance. We must ensure the AI respects these hard constraints.

First, we use the Replace Vibes with Tools pattern. When a part of your problem is well-specified and deterministic—like running a Maven build, executing tests, or applying a Kubernetes configuration—don’t use a generative approach to try to find a solution. Provide the assistant with reproducible tools or scripts it can invoke. This reduces the context cost of discovering how to complete steps and gives you deterministic control over critical sequence points in your CI/CD pipelines.

Next, we Give Examples. Because LLMs are pattern-matching engines, a prompt acts as a prefix that constrains the model’s focus. If you want your Quarkus REST endpoints structured a specific way, show the model an annotated snippet of that exact structure. Wrap these snippets in explicit <example> and </example> tags to indicate they are guidance rather than part of the core problem statement.

When you inevitably have to correct the AI, don’t let that effort go to waste. Use the Extract Prompt pattern. Turn that specific correction into an isolated, reusable prompt that clearly specifies the steps needed for the task, and invoke the agent with just the extracted prompt to complete that specific intermediate step without dragging in unrelated context.

Finally, turn the AI into an active participant in improving your workflow using the Model Reflects pattern. At the end of a complex session, ask the model to identify important changes or inflection points in your interaction. Prompt it to reflect on bugs it introduced, diagnosed, and fixed, and have it generate suggestions on how to avoid those mistakes in future iterations. Combine this with Remember What We Did to actively record the choices and corrections you make during your session, writing them to a persistent memory store (like a markdown fil