Patterns in AI Driven Software Development Presentation given at ...

2026-10-31T02:40:27Z

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.
Introduction
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:
Intent.
Motivation.
Implementation.
Examples.
Consequences.
Related Patterns.
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.
Mastering Context and Complexity
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.
Planning and Discovering Opportunities
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.
Controlling the Chain of Thought and Quality
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.
Standardization and Continuous Improvement
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 file or database) so the assistant can draw on those lessons in future tasks.
Fortifying Security with Centaur Patterns
As we adopt these structured workflows, we must also address one of the most critical aspects of enterprise software: security. Generative AI models can inadvertently introduce vulnerabilities if we simply trust their output blindly.
Fortunately, we can leverage these interaction techniques to embed secure coding practices directly into our AI augmented development.
By applying a targeted mix of these patterns, you can ensure that the final software remains locked down and secure:
Give Examples: You can leverage this pattern to mandate that security is considered from the very beginning of the design phase. For instance, you can constrain the model’s output by requiring a section on security considerations to be included in any deployment architecture document it generates.
Replace Vibes with Tools: Never rely on a generative model to guess whether a piece of code is secure. Instead, provide the coding assistant with deterministic analysis tools that are specifically designed to uncover API misuse, security vulnerabilities, and other software bugs.
Model Reviews: You can shift the AI’s role from code creator to security critic. Create a specific prompt that describes your review criteria, explicitly telling the assistant to focus on the OWASP Top Ten security risks. You can explicitly ask for an assessment of the code’s correctness, alongside any security or memory management issues.
You Review: Ultimately, human oversight is your last line of defense against vulnerabilities. When inspecting the generated output, you should take a strategic, risk-based approach to the review. Focus your human attention on the criteria that would cause you the most problems if your expectations aren’t met, such as critical security and compliance issues.
By layering these specific patterns into your workflow, security ceases to be an afterthought that you hope the AI gets right. Instead, it becomes a hard constraint that guides the assistant at every step of the generative process.
Live Demo: Building a Software Centaur in Cursor
Let’s bring these concepts together and see what this looks like in practice using Cursor, an AI-powered IDE.
In Cursor, we can permanently capture our Centaur patterns using specialized Markdown Configuration files—.mdc files—stored in the .cursor/rules/ directory. These files act as the AI’s long-term memory for our project.
Let’s say we’ve just spent 15 minutes fighting with the AI to get our OpenShift health checks implemented correctly using SmallRye Health. We don’t want to fight that battle again.
Step 1: Extract the Knowledge First, I apply the Model Reflects and Extract Prompt patterns. Right here in the Cursor chat, I type: “Review our last few prompts regarding the SmallRye Health implementation. Reflect on the mistakes made regarding OpenShift readiness probes, and extract a comprehensive, reusable system prompt that enforces our required Quarkus health check standards.”
The AI analyzes our session and outputs a clean, structured set of instructions.
Step 2: Create the Tool Now, I apply the Give Examples pattern. I create a new file named .cursor/rules/quarkus-health.mdc.
I add a YAML frontmatter block at the top to give Cursor context:
---
description: Standards for implementing Quarkus health checks and OpenShift readiness/liveness probes.
globs: src/main/java/**/*HealthCheck.java
alwaysApply: false
---
Below that, I paste the extracted prompt from the AI, and crucially, I add a specific code example from our codebase demonstrating the perfect Liveness and Readiness probe implementation.
Step 3: The Payoff We’ve just externalized our team’s memory directly into the IDE. Let’s apply the Clean Slate pattern and open a brand new chat. I simply type: “Create a database connection health check.”
Because my request touches a file ending in HealthCheck.java, Cursor automatically loads our .mdc rule file into the AI’s context. The model reads our architectural constraints and our exact code examples before it generates a single token. It perfectly implements the database health check using our specific OpenShift annotations.
We didn’t rely on vibes. We managed context, provided examples, extracted a reusable process, and locked

https://akos.ma/blog/patterns-in-ai-driven-software-development/

#rss #feeds #linksharing #qwibbit

Giger Museum Everyone knows Alien, the movie franchise with ...

2026-10-24T02:39:35Z

Giger Museum

Everyone knows Alien, the movie franchise with countless spin-offs and prequels and sequels. But not everyone knows that the designer behind the… well, alien monster of the first movie, was a Swiss artists called H. R. Giger.
(Somehow it seems to me that to make a dent in the world of fantasy one has to be remembered by fans with a name mostly composed of initials: J. R. R. Tolkien, P. C. Hodgell, George R. R. Martin, J. V. Jones, H. P. Lovecraft, C. S. Lewis, N. K. Jemisin, T. H. White, H. R. Giger, you get the idea.)
Giger was an immense artist, one of the most important of the 20th century as far as the author of this lines is concerned. His work is impossible to compare to anyone else, it’s beyond eerie and magical, transcending, blending, and subliming visions of horror into erotica and science fiction. And thankfully here in Switzerland we have a museum dedicated to his work (well, as I wrote once in a De Programmatica Ipsum article, there are museums for everything imaginable in this country).
I have visited the Giger Museum in Gruyères (canton of Fribourg) a few times in my life, and I can only recommend it to anyone visiting the country. And if you go, end your visit with a nice beer in one of the two Giger Bars in the world. It’s an incredible location, in a quite lovely and romantic place of the world (don’t forget to eat a good cheese fondue moitié-moitié if you go there, too).
View this post on Instagram

https://akos.ma/blog/giger-museum/

#gigermuseum #gigerbars #alien #programmaticaipsum #swiss #george #hodgell #somehow #tolkien #jemisin

#rss #feeds #linksharing #qwibbit

Embedding PDFs on Web Pages This can sound stupid, but I’ve ...

2026-10-17T02:38:50Z

Embedding PDFs on Web Pages

This can sound stupid, but I’ve only recently learned how to insert PDF files on a web page; see, I’m from the generation that suffered the dreaded Adobe Acrobat thing, and also ActiveX controls, and if you don’t know what these are, well, ask your grandpa but don’t make him cry too much.
So say you have a PDF you’d like to insert on a page; here’s the HTML you need:
<embed src="https://deprogrammaticaipsum.com/pdf/issue-083-php.pdf";
width="100%" height="900px" >
And the result, unsurprisingly, appears at the bottom of this page (but only if you’re reading this page on a web browser, of course; if you’re reading this on a PDF, well, you don’t need a PDF inside a PDF, although I wouldn’t be surprised you can do that, too).
You won’t be surprised to learn that you can also style the embed with some CSS, like I’ve done in this website, precisely:
embed {
box-shadow: 0px 0px 6px rgba(0, 0, 0, 1);
border-radius: 5px;
margin-bottom: 16px;
}
See that nice rounded corners and that drop shadow? Well now you know.

https://akos.ma/blog/embedding-pdfs-on-web-pages/

#rss #feeds #linksharing #qwibbit

Nostr notes by

Patterns in AI Driven Software Development Presentation given at ...

Giger Museum Everyone knows Alien, the movie franchise with ...

Embedding PDFs on Web Pages This can sound stupid, but I’ve ...