DEV Community: Aftab Bashir

I made my .NET travel AI library work with OpenAI, Anthropic, Ollama, and Azure. Not just one.

Aftab Bashir — Tue, 12 May 2026 06:47:37 +0000

When I first shipped TravelAI.Core, it only worked with Azure OpenAI and Azure AI Search. You needed an Azure subscription, a deployed GPT-4o model, a configured AI Search index, and the patience to wire it all up before you could generate a single itinerary.

Downloads were slow. Not surprising in hindsight.

Most developers don't have Azure credentials sitting around. They want to try something before committing to a cloud provider. I was basically asking people to do significant setup work before they could see if the library was even useful to them.

So I rebuilt the provider layer.

What changed

The core interfaces stayed exactly the same. IItineraryGenerationService, IDestinationSearchService, IPriceAnomalyDetector all look identical from the outside. What changed is how you wire up the backend.

In v1.0.0 you needed a config section with Azure credentials. In v2.0.0 you pick a provider:

builder.Services.AddTravelAI(options => options.UseMock());
builder.Services.AddTravelAI(options => options.UseOpenAI("sk-..."));
builder.Services.AddTravelAI(options => options.UseAnthropic("sk-ant-..."));
builder.Services.AddTravelAI(options => options.UseOllama("http://localhost:11434"));
builder.Services.AddTravelAI(options => options.UseAzureOpenAI("endpoint", "key", "gpt-4o"));

The mock provider is the one I'm most pleased with. Zero credentials, works offline, returns a realistic 3-day Rome itinerary with activities, costs, and timing. You can build and test the full integration flow on a train with no internet.

How the abstraction works

There's a single ILlmProvider interface:

public interface ILlmProvider
{
    Task<string> GenerateAsync(
        string systemPrompt,
        string userPrompt,
        CancellationToken ct = default);
}

Each provider implements it. ItineraryGenerationService now takes ILlmProvider instead of AzureOpenAIClient. The Anthropic adapter uses Anthropic.SDK, the Ollama adapter makes raw HTTP calls to /api/chat, the mock just returns a hardcoded JSON string.

The destination search side has a mock too. MockDestinationSearchService does keyword scoring in memory against five curated destinations. Good enough to build against while you decide whether you want Azure AI Search or something else.

The Ollama adapter

Ollama's API is simple but you're dealing with streaming responses and the JSON format varies slightly across model versions. I went with a non-streaming request to keep the adapter stateless, which works fine for itinerary generation.

var response = await _http.PostAsJsonAsync("/api/chat", new
{
    model = _model,
    stream = false,
    messages = new[]
    {
        new { role = "system", content = systemPrompt },
        new { role = "user", content = userPrompt }
    }
});

Nothing clever. Just works.

What the library does

Four things once registered:

Itinerary generation takes a traveller profile and destination and returns a structured day-by-day plan with activities and cost estimates. Price anomaly detection analyses flight options against historical baselines and flags anything unusual. Destination search understands natural language queries like "warm with beaches and local food, not too touristy". Booking automation runs the end-to-end flow with retry logic and rollback on failure.

The whole thing is deployed to Azure Kubernetes Service. The GitHub Actions pipeline builds for linux/arm64, pushes to GHCR, and deploys with a manual approval gate. Took me a while to figure out the arm64 part.

Getting started

dotnet add package TravelAI.Core

Start with UseMock(). If it does what you need, switch to a real provider. The rest of your code doesn't change.

GitHub: https://github.com/aftabkh4n/TravelAI.Core

A senior engineer spotted a bug in my pipeline. I fixed it the same day. Here is what I learned.

Aftab Bashir — Sun, 10 May 2026 05:37:10 +0000

A few weeks ago I published an article about an event-driven order pipeline I built in .NET with Kafka and Azure Service Bus. Someone left a comment that stopped me in my tracks.

Andrew Tan wrote:

"One thing I'd watch: you now have two sources of truth in flight, PostgreSQL and Kafka. If the API crashes after writing to Postgres but before publishing, you've got an order that never gets processed. Have you considered using an outbox pattern or transactional writes to close that gap?"

He was right. I had not thought about it properly.

The gap he spotted

Here is what the original code did when a new order came in:

Save the order to PostgreSQL
Publish an event to Kafka

Two separate operations. No transaction between them. If the API crashed, ran out of memory, got killed by Kubernetes, or just had a bad moment between step 1 and step 2, the order would exist in the database with a Pending status and never move forward.

Nobody would know. No error. No alert. The order would just sit there.

At low volume this probably never causes a visible problem. At scale, or in production with real money on the line, it is a serious reliability issue.

The outbox pattern

The fix is called the outbox pattern. The idea is simple.

Instead of writing to the database and then publishing to Kafka as two separate operations, you write the order and an outbox record in the same database transaction. The outbox record is just a row in a table that says "this event needs to be published."

A separate background service then reads unprocessed outbox records, publishes them to Kafka, and marks them as processed. If publishing fails, the record stays unprocessed and gets retried. If the background service crashes mid-publish, it picks up the same record on restart.

The database transaction is the source of truth. Either both the order and the outbox record are committed together, or neither is. There is no window where one exists without the other.

What I built

First I added an OutboxMessage model:

public class OutboxMessage
{
    public Guid Id { get; set; } = Guid.NewGuid();
    public Guid OrderId { get; set; }
    public string EventType { get; set; } = string.Empty;
    public string Payload { get; set; } = string.Empty;
    public DateTime CreatedAt { get; set; } = DateTime.UtcNow;
    public DateTime? ProcessedAt { get; set; }
    public bool Processed { get; set; } = false;
    public int RetryCount { get; set; } = 0;
    public string? Error { get; set; }
}

Then I updated the controller to write both in the same transaction:

public async Task<IActionResult> CreateOrder([FromBody] CreateOrderRequest request)
{
    var order = new Order { ... };

    var outboxMessage = new OutboxMessage
    {
        OrderId = order.Id,
        EventType = nameof(OrderEventType.OrderCreated),
        Payload = JsonSerializer.Serialize(order)
    };

    db.Orders.Add(order);
    db.OutboxMessages.Add(outboxMessage);
    await db.SaveChangesAsync(); // one transaction, both or neither

    return CreatedAtAction(nameof(GetOrder), new { id = order.Id }, order);
}

No Kafka publish in the controller anymore. The controller just writes to the database and returns.

Then I built the OutboxProcessorService as a BackgroundService that polls every 5 seconds:

protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
    while (!stoppingToken.IsCancellationRequested)
    {
        await ProcessOutboxMessagesAsync();
        await Task.Delay(TimeSpan.FromSeconds(5), stoppingToken);
    }
}

private async Task ProcessOutboxMessagesAsync()
{
    var messages = await db.OutboxMessages
        .Where(m => !m.Processed && m.RetryCount < 3)
        .OrderBy(m => m.CreatedAt)
        .ToListAsync();

    foreach (var message in messages)
    {
        try
        {
            await PublishToKafkaAsync(message);
            message.Processed = true;
            message.ProcessedAt = DateTime.UtcNow;
        }
        catch (Exception ex)
        {
            message.RetryCount++;
            message.Error = ex.Message;
        }

        await db.SaveChangesAsync();
    }
}

What the logs look like now

When an order comes in:

INSERT INTO "Orders" ...
INSERT INTO "OutboxMessages" ...
Order f21613da created and outbox message queued

Five seconds later:

Processing 1 unprocessed outbox messages
Order f21613da published to Kafka topic orders at offset 5
Outbox message published successfully
UPDATE "OutboxMessages" SET "Processed" = true ...

The gap is closed. The order and the outbox record live or die together in the same transaction. Kafka gets the event eventually, guaranteed.

What Andrew also flagged

After I posted the fix, Andrew came back with more good points. He mentioned that with a 5-second polling interval, you are trading latency for database load. Fine at low volume. At scale you want FOR UPDATE SKIP LOCKED so multiple poller instances do not step on each other.

He also asked what happens if Kafka is down. Currently unprocessed records pile up and the poller keeps retrying every 5 seconds with no backoff. That is worth fixing. A dead letter path and an alert on outbox message age would make this production-ready.

Both are on the backlog. The current implementation is correct for a single poller. Horizontal scaling and dead letters are the next iteration.

The bigger point

I almost shipped this without the outbox pattern. The original code worked perfectly in testing. Kafka and PostgreSQL both got their data. No errors. No warnings.

The failure mode only shows up when something crashes between two operations that look like one. That is exactly the kind of bug that stays invisible until it costs someone something real.

Public code review from people who know what they are looking at is genuinely valuable. Andrew's comment was worth more than any linter or test suite would have caught here.

Source code: github.com/aftabkh4n/order-pipeline

If you are building event-driven systems and not using the outbox pattern, it is worth understanding. The implementation is not complicated. The reliability guarantee it gives you is significant.

We've been building AI-style modular systems for years, we just called them plugins

Aftab Bashir — Tue, 05 May 2026 06:58:28 +0000

There’s a lot of excitement right now around AI agents, tools, and modular systems.

Define tools.

Describe them well.

Let something else decide when to use them.

Sound familiar?

It should.

Because we’ve been doing this for years | we just called them plugins.

The core idea

A well-designed system doesn’t hardcode features.

Instead, it does one thing at startup:

Load modules (plugins)

That’s it.

No giant Program.cs doing everything.

No tightly coupled feature logic.

Just a host application that loads capabilities dynamically.

Everything is a plugin

In this model:

Pages → plugins
UI components → plugins
Business logic → plugins
Side effects (logging, API calls, events) → plugins

Even things you don’t normally think about, like routing, become plugins.

Why this matters

When every feature is a plugin:

Adding a feature → drop in a file
Removing a feature → delete a file
Replacing a feature → swap a file

No refactoring. No ripple effects.

This is true modularity.

A simple mental model

Think of your app like this:

App = Host + Plugins

The host:

Loads plugins
Provides shared context
Coordinates execution

Plugins:

Declare what they do
Register themselves
Execute when needed

Mini example using TOPS (stream-oriented)

Let’s make it concrete.

Using a stream-oriented approach like TOPS, everything becomes part of a flow.

Entry point

var app = new App();

app.LoadPlugins("plugins/");

app.Run();

That’s it.

Router plugin

public class RouterPlugin : IPlugin
{
    public void Register(IApp app)
    {
        app.UseRouter(routes =>
        {
            routes.Map("/", "HomePage");
            routes.Map("/about", "AboutPage");
        });
    }
}

Home page plugin

public class HomePagePlugin : IPlugin
{
    public void Register(IApp app)
    {
        app.RegisterPage("HomePage", ctx =>
        {
            return "<h1>Home</h1>";
        });
    }
}

Navbar plugin

public class NavbarPlugin : IPlugin
{
    public void Register(IApp app)
    {
        app.RegisterComponent("Navbar", ctx =>
        {
            return "<nav>...</nav>";
        });
    }
}

Now here’s the interesting part:

👉 Remove HomePagePlugin.cs → home page disappears

👉 Remove NavbarPlugin.cs → navbar is gone

👉 Remove RouterPlugin.cs → no routing

No changes anywhere else.

Effects are plugins too

In real systems, it gets more powerful.

Things like:

Logging
API calls
Background jobs
Event handling

…can all be plugins.

Example:

public class LoggingPlugin : IPlugin
{
    public void Register(IApp app)
    {
        app.OnEvent("RequestStarted", ctx =>
        {
            Console.WriteLine("Request started");
        });
    }
}

This is basically how AI tools work

Modern AI systems:

Define tools (plugins)
Describe them
Let the model choose which one to call

That’s not new.

That’s just:

Plugin architecture + dynamic orchestration

The difference is:

Instead of a developer calling the plugin
An AI decides which plugin to use

The real takeaway

The important shift isn’t AI.

It’s this:

Capabilities should be decoupled from the core system

Whether it’s:

a web app
a backend service
or an AI agent

The winning pattern is the same:

Small, focused modules
Clear contracts
Easy to add/remove

If you're not doing this yet

Start simple:

Extract one feature into a module
Give it a clear interface
Load it dynamically

You’ll quickly see the benefits:

cleaner code
easier testing
faster iteration

Final thought

AI didn’t invent modular systems.

It just made us realize how powerful they are when something else | not you | decides how to use them.

And if your system is already plugin-based?

You’re already ahead.

How I added memory export and import to my open-source AI library

Aftab Bashir — Tue, 05 May 2026 04:30:52 +0000

When I built BlazorMemory, I knew from the start that storing memories in the browser had one obvious problem. What happens when you clear your browser data? Or switch devices? Everything is gone.

v0.3.0 fixes that with two new methods: ExportAsync and ImportAsync.

What it does

Export serialises all memories for a user to JSON:

var json = await memory.ExportAsync(userId);

The output looks like this:

{
  "userId": "demo_user",
  "exportedAt": "2025-03-15T10:00:00Z",
  "version": "1.0",
  "memories": [
    {
      "id": "abc123",
      "content": "User is a senior .NET engineer",
      "learnedAt": "2025-03-14T09:30:00Z"
    }
  ]
}

Notice embeddings are not in the export. They are large (1,536 floats per memory) and they are model-specific. If you exported with text-embedding-3-small and later imported using a different model, the similarity search would break. So the export skips them, and import re-generates them fresh.

Import reads the JSON, skips any memory whose content already exists (to avoid duplicates), and stores the rest:

await memory.ImportAsync(userId, json);

It is built into the MemoryPanel component

If you use BlazorMemory.Components, you get Export and Import buttons in the panel footer with no extra code:

<MemoryPanel UserId="@userId" IsOpen="true" />

Export triggers a browser file download. Import opens a file picker that accepts .json files.

Both buttons are opt-in via parameters if you want to hide them:

<MemoryPanel UserId="@userId"
             AllowExport="false"
             AllowImport="false" />

Why not include the embeddings

I thought about this. Including embeddings would make the import faster since you skip the re-embedding API call. But it creates two problems.

First, file size. A user with 50 memories using text-embedding-3-small would have a 300KB export file. Not terrible, but not great either.

Second, model coupling. If you export from an app using OpenAI embeddings and import into an app using a different provider, the vectors are incompatible and similarity search silently breaks. Re-generating on import keeps things clean regardless of which embedding provider the target app uses.

Getting started

dotnet add package BlazorMemory
dotnet add package BlazorMemory.Storage.IndexedDb
dotnet add package BlazorMemory.Embeddings.OpenAi
dotnet add package BlazorMemory.Extractor.OpenAi
dotnet add package BlazorMemory.Components

builder.Services
    .AddBlazorMemory()
    .UseIndexedDbStorage()
    .UseOpenAiEmbeddings(apiKey)
    .UseOpenAiExtractor(apiKey);

<MemoryPanel UserId="@userId" IsOpen="true" />

That is all you need. The panel handles display, delete, clear, export, and import.

GitHub: https://github.com/aftabkh4n/BlazorMemory

Google just launched ADK for AI agents. I built something similar in .NET months ago using MCP. Here is what I learned.

Aftab Bashir — Sun, 03 May 2026 04:34:38 +0000

On April 30th I got an email from Google about something called GEAR, their new program for building AI agents using ADK, the Agent Development Kit. I signed up, watched the intro video, and had a strange feeling of recognition.

The pattern was familiar. Define tools. Write descriptions. Connect an AI model to those tools. Let the model decide which tool to call based on what the user asks.

I built exactly this in .NET back in February, except I used MCP instead of ADK. And I pointed it at a Kubernetes cluster instead of a database.

What ADK and MCP are both trying to solve

The problem both frameworks address is the same. You have an AI model and you want it to do real things in the world, not just generate text. To do that, the model needs tools. A tool is just a function the model can call: search the web, query a database, restart a server, create a file.

The hard part is telling the model what each tool does well enough that it picks the right one. Both ADK and MCP solve this with descriptions. You write a description for each tool, and the model reads those descriptions to decide what to call.

ADK does this in Python, Java, TypeScript, or Go. You define an agent with a name, a model, an instruction, and a list of tools. The framework handles the rest.

MCP does this through a server protocol. You define tools with names, descriptions, and input schemas. Any MCP-compatible client, including Claude Desktop, can connect to your server and use those tools through natural language.

What I built

My MCP server lets Claude manage a Kubernetes cluster through natural language. You type something like "restart the idp-platform deployment" and Claude figures out which tool to call, what parameters to pass, and executes it.

The server exposes 8 tools: list pods, get pod logs, scale a deployment, restart a deployment, describe a node, get cluster events, and a couple more. Each tool has a detailed description that tells Claude what it does and when to use it.

Here is what one tool definition looks like in .NET:

[McpServerTool, Description(
    "Scale a Kubernetes deployment to a specific number of replicas. " +
    "Use this when you need to increase or decrease the number of running instances. " +
    "Provide the deployment name and namespace. " +
    "Returns the updated replica count and deployment status.")]
public async Task<string> ScaleDeployment(
    [Description("The name of the deployment to scale")] string deploymentName,
    [Description("The Kubernetes namespace")] string namespaceName,
    [Description("The desired number of replicas")] int replicas)

The description is doing a lot of work here. It tells Claude what the tool does, when to use it, what it needs, and what it returns. That is exactly the same thing ADK tool descriptions do.

The key insight both frameworks share

Tool descriptions are the interface layer, not documentation.

When you write a description for a tool, you are not writing it for a developer to read. You are writing it for the AI model to read. That changes everything about how you should write them.

Be specific about when to use this tool versus a similar one. Be clear about what the inputs mean. Be explicit about what the output contains. Vague descriptions lead to the model picking the wrong tool or calling it with the wrong parameters.

I learned this the hard way. My first version of the scale deployment tool had a description that just said "Scale a deployment." Claude kept confusing it with the restart tool. Adding specificity about what scaling means versus restarting fixed it immediately.

Where they differ

ADK is a full framework. It handles multi-agent systems, bidirectional streaming, session management, deployment to Google Cloud, evaluation, and observability. It is designed for production enterprise applications.

MCP is a protocol. It is lighter, more focused, and model-agnostic. Any AI client that speaks MCP can connect to your server. Claude Desktop, Cursor, and increasingly other tools all support MCP. You write the server once and it works across clients.

For my use case, MCP was the right choice. I wanted Claude to control my local Kubernetes cluster during development. I did not need multi-agent orchestration or managed cloud deployment. I needed a reliable protocol that Claude Desktop could speak natively.

If I was building a production AI system for a business with multiple agents, audit logging, and cloud scale, ADK would be more appropriate.

The .NET angle

Neither ADK nor MCP has official .NET support as a primary language. ADK supports Python, Java, TypeScript, and Go. The official MCP SDK supports Python and TypeScript.

There is a community .NET MCP SDK that works well and that is what I used. But it does mean you are working slightly outside the official tooling for both frameworks if you are a .NET developer.

That said, building an MCP server in .NET is straightforward once you have the SDK. The tooling, testing, and deployment story is the same as any other .NET application.

What ADK does that impressed me

The built-in Dev UI is genuinely useful. When you run an ADK agent locally, you get a browser interface that shows you exactly what the agent is thinking, which tools it called, what parameters it passed, and what came back. That visibility into the agent's reasoning is something I had to build myself for debugging my MCP server.

The multi-agent support is also impressive. ADK lets you define hierarchies of agents where a primary agent can delegate to specialist agents. I have not needed this yet but I can see why it matters for complex workflows.

Source code

My MCP Kubernetes Manager is open source: github.com/aftabkh4n/mcp-kubernetes-manager

It includes an AI-generated release notes pipeline as well - every merged PR automatically generates a structured changelog entry using Claude and GitHub Actions.

If you are a .NET developer curious about building AI agents, MCP is worth exploring even while the official tooling catches up. The protocol is solid and the community SDK works well.

If you are starting fresh and language flexibility matters, ADK is worth a serious look. Google has clearly put real engineering behind it.

Either way, the mental model is the same. Tools, descriptions, and an AI that reads them. That part does not change no matter which framework you use.

Built a travel booking platform in .NET with an API gateway, MongoDB, and Angular

Aftab Bashir — Mon, 27 Apr 2026 04:24:44 +0000

Most tutorials show you how to build an API. Fewer show you what sits in front of the API in a real production system.

This project is about that middle layer. A gateway that all requests go through before they reach the actual API. It checks authentication, enforces rate limits, and routes traffic. In Azure this is what API Management does. Here it runs locally with YARP, Microsoft's open source reverse proxy library.

The actual application is a travel booking system. The gateway pattern is the interesting part.

Why a gateway matters

When you build an API and expose it directly to clients, every client knows your API's address. They can call it as many times as they want. There is no central place to enforce authentication or throttle abusive callers.

A gateway changes that. Clients only know the gateway address. The API address is internal. The gateway handles auth and rate limiting before requests ever reach your code.

This is how companies like Qatar Airways, booking.com, and most large travel platforms structure their APIs. One gateway, many services behind it.

The architecture

Three .NET projects and one Angular app.

TravelBooking.Api is a standard ASP.NET Core 10 API. It connects to MongoDB, handles CRUD operations for bookings, and sends notifications when bookings are created or confirmed. The notification goes to a Logic Apps webhook in production. Locally it logs to the console.

TravelBooking.Gateway is the interesting one. Built with YARP. It does three things on every request: checks the X-Api-Key header, enforces rate limits, and proxies to the API with path transformation.

TravelBooking.Core holds shared models and interfaces.

travel-booking-ui is Angular 19. It calls the gateway, never the API directly.

Setting up YARP as a gateway

YARP configuration lives in appsettings.json. You define routes and clusters:

"ReverseProxy": {
  "Routes": {
    "bookings-route": {
      "ClusterId": "bookings-cluster",
      "Match": {
        "Path": "/gateway/{**catch-all}"
      },
      "Transforms": [
        { "PathRemovePrefix": "/gateway" }
      ]
    }
  },
  "Clusters": {
    "bookings-cluster": {
      "Destinations": {
        "destination1": {
          "Address": "http://localhost:5153"
        }
      }
    }
  }
}

Any request to /gateway/api/bookings gets the /gateway prefix stripped and forwarded to http://localhost:5153/api/bookings. The client never needs to know the API address.

API key authentication

This middleware runs before YARP proxies the request:

app.Use(async (context, next) =>
{
    var apiKey = context.Request.Headers["X-Api-Key"].FirstOrDefault();
    if (string.IsNullOrEmpty(apiKey) || apiKey != builder.Configuration["Gateway:ApiKey"])
    {
        context.Response.StatusCode = 401;
        await context.Response.WriteAsync("Unauthorized: Invalid or missing API key");
        return;
    }
    await next();
});

No API key, no access. The request never reaches the API.

Rate limiting

10 requests per 10 seconds per client. After that, requests queue up to a limit of 5 then get rejected.

builder.Services.AddRateLimiter(options =>
{
    options.AddFixedWindowLimiter("fixed", opt =>
    {
        opt.PermitLimit = 10;
        opt.Window = TimeSpan.FromSeconds(10);
        opt.QueueProcessingOrder = QueueProcessingOrder.OldestFirst;
        opt.QueueLimit = 5;
    });
});

In production you would use sliding window or token bucket depending on your traffic patterns. Fixed window is the simplest to understand and works fine for most cases.

MongoDB for bookings

The repository pattern keeps the MongoDB driver out of the controllers:

public async Task<Booking> CreateAsync(Booking booking)
{
    await _bookings.InsertOneAsync(booking);
    _logger.LogInformation("Booking {BookingId} created for {Customer}", 
        booking.Id, booking.CustomerName);
    return booking;
}

MongoDB is a good fit for bookings. The document structure matches naturally, and you do not need to define a schema before you start. Add a new field to the model and it just works.

The Angular frontend

The booking service sets the API key on every request automatically:

private headers = new HttpHeaders({
  'Content-Type': 'application/json',
  'X-Api-Key': this.apiKey
});

getBookings(): Observable<Booking[]> {
  return this.http.get<Booking[]>(
    `${this.gatewayUrl}/api/bookings`, 
    { headers: this.headers }
  );
}

The gateway URL is the only thing Angular knows about. It has no idea where the API runs.

What a real request looks like

A booking creation goes through this path:

Angular sends POST to http://localhost:5177/gateway/api/bookings with X-Api-Key header
Gateway middleware validates the API key
Rate limiter checks the request count
YARP strips /gateway and forwards to http://localhost:5153/api/bookings
API saves to MongoDB and logs the notification
Response comes back through the gateway to Angular

The whole thing takes under 200ms locally.

Running it yourself

You need .NET 10, Node.js 20, and Docker Desktop.

git clone https://github.com/aftabkh4n/travel-booking-platform.git
cd travel-booking-platform

docker run -d --name travel-mongo -p 27017:27017 mongo:7

cp TravelBooking.Api/appsettings.example.json TravelBooking.Api/appsettings.json
cp TravelBooking.Gateway/appsettings.example.json TravelBooking.Gateway/appsettings.json

Start the API, then the gateway, then Angular. Open http://localhost:4200.

Source code: https://github.com/aftabkh4n/travel-booking-platform

If you have questions drop them in the comments.

Built an event-driven order pipeline in .NET with Kafka and Azure Service Bus

Aftab Bashir — Wed, 22 Apr 2026 07:55:33 +0000

Most order processing systems I have worked with are synchronous. The API receives the request, does the work, and returns the result. That works fine until it does not. The database is slow, a third-party service is down, or you have 500 orders arriving at the same time. Everything backs up and the API starts timing out.

This project is the async version of that. Orders come in through a REST API, get saved to PostgreSQL, and get published to Kafka. A separate consumer picks them up, processes them, and publishes a fulfilment event to Azure Service Bus. The API never waits for any of that.

The architecture

There are three projects in the solution.

OrderPipeline.Api is an ASP.NET Core 10 API. It does two things when an order arrives: saves it to PostgreSQL and publishes an event to Kafka. That is it. The processing happens somewhere else.

OrderPipeline.Consumer is a .NET Worker Service. It runs continuously, reading from the Kafka orders topic. When it picks up an order event, it updates the status to Processing, does the fulfilment work, marks it as Fulfilled in PostgreSQL, and publishes a fulfilment event to Azure Service Bus.

OrderPipeline.Core holds the shared models. Order, OrderItem, OrderEvent, and the interfaces for the repository and publisher.

The order flow

POST an order to the API:

curl -X POST http://localhost:5125/api/orders \
  -H "Content-Type: application/json" \
  -d "{\"customerName\": \"John Smith\", \"customerEmail\": \"john@example.com\", \"items\": [{\"productName\": \"Laptop\", \"quantity\": 1, \"unitPrice\": 999.99}]}"

The API responds immediately with a 201. In the background:

Order e6e20d66 created in database
Order e6e20d66 published to Kafka topic orders at offset 1

Then the consumer picks it up:

Consumed message from partition [0] at offset 1
Processing order e6e20d66 for customer John Smith
Fulfilment event published to Service Bus for order e6e20d66
Order e6e20d66 fulfilled successfully

The client does not wait for any of that. It can poll GET /api/orders/{id} to check the status whenever it wants.

Publishing to Kafka

The publisher uses the Confluent.Kafka producer. The order ID is the message key, which ensures all events for the same order land on the same partition.

var message = new Message<string, string>
{
    Key = order.Id.ToString(),
    Value = JsonSerializer.Serialize(orderEvent)
};

var result = await _kafkaProducer.ProduceAsync(_kafkaTopic, message);
_logger.LogInformation(
    "Order {OrderId} published to Kafka topic {Topic} at offset {Offset}",
    order.Id, _kafkaTopic, result.Offset);

Consuming from Kafka

The consumer uses AutoOffsetReset.Earliest so it picks up messages from the beginning of the topic on first start. Manual commit means a message only gets marked as processed after the work is done, not when it is received.

var config = new ConsumerConfig
{
    BootstrapServers = _configuration["Kafka:BootstrapServers"],
    GroupId = "order-pipeline-consumer",
    AutoOffsetReset = AutoOffsetReset.Earliest,
    EnableAutoCommit = false
};

If the consumer crashes mid-processing, it picks up from the last committed offset when it restarts. No orders get lost.

Publishing to Azure Service Bus

Once an order is fulfilled, the consumer publishes a fulfilment event to a Service Bus queue. Downstream systems subscribe to that queue to handle shipping, notifications, invoicing, or whatever comes next.

var message = new ServiceBusMessage(JsonSerializer.Serialize(orderEvent))
{
    MessageId = orderEvent.EventId.ToString(),
    Subject = "OrderFulfilled",
    ContentType = "application/json"
};

await _sender.SendMessageAsync(message);

For local development, this uses the official Microsoft Azure Service Bus emulator running in Docker. The connection string just needs UseDevelopmentEmulator=true and it works identically to the real service.

The database

The Consumer and API share the same PostgreSQL database but they access it independently through EF Core. The API writes new orders. The Consumer reads and updates them. No shared state, no coupling between the two services beyond the database schema.

order.Status = OrderStatus.Processing;
await db.SaveChangesAsync();

// do the fulfilment work

order.Status = OrderStatus.Fulfilled;
order.ProcessedAt = DateTime.UtcNow;
await db.SaveChangesAsync();

Running it locally

Everything runs with Docker Compose. One command starts PostgreSQL, Kafka, Zookeeper, Kafka UI, and the Service Bus emulator.

git clone https://github.com/aftabkh4n/order-pipeline.git
cd order-pipeline
docker-compose up -d

Then start the API and Consumer in separate terminals and send a test order. The Kafka UI at http://localhost:8080 lets you watch messages flow through the topic in real time.

What I learned

Kafka startup takes time. On the first request after starting the containers, the producer waits while Kafka finishes initialising. Subsequent requests are fast. Worth knowing when you are testing and wondering why the first call takes 60 seconds.

Manual offset commit is important. With auto-commit enabled, Kafka marks a message as processed the moment it is received. If the consumer crashes before finishing the work, that message is gone. Manual commit means you commit only after the work succeeds.

The Service Bus emulator is genuinely useful. I expected it to be a rough approximation but it behaves exactly like the real service for basic queue operations. No need to touch a real Azure subscription during development.

Source code: https://github.com/aftabkh4n/order-pipeline

If you have questions or run into issues getting it running, drop a comment below.

Down for the challenge

Aftab Bashir — Mon, 20 Apr 2026 07:00:17 +0000

Share your OpenClaw experience

Jess Lee for The DEV Team

Apr 16

Join the OpenClaw Challenge: $1,200 Prize Pool!

#devchallenge #openclawchallenge #openclaw #ai

119

Comments 22

4 min read

I built a self-healing Kubernetes system in .NET that fixes its own failures using Claude AI

Aftab Bashir — Mon, 20 Apr 2026 06:53:56 +0000

A pod crashes at 3am. Kubernetes restarts it. It crashes again. Kubernetes keeps trying.

Meanwhile you are asleep. Nobody reads the logs. Nobody fixes anything. The pod just keeps crashing until someone wakes up, opens a terminal, and figures out what went wrong.

I built a system that handles the reading and thinking part automatically. When a pod fails, it pulls the logs, asks Claude what went wrong, and opens a GitHub PR with a suggested fix. By the time you wake up, the analysis is already done.

What it actually does

The system runs as a .NET background service alongside your cluster. It streams Kubernetes events in real time. When it sees a pod enter CrashLoopBackOff, OOMKilled, ImagePullError, or exit with a non-zero code, it kicks off a healing process.

Here is what happens in order:

Pod failure detected
Last 100 lines of logs pulled from the pod
Logs and failure details sent to Claude API
Claude returns root cause, severity, and a suggested fix
A branch is created on GitHub
The analysis is committed as a markdown file
A PR is opened automatically

The whole thing takes about 10 seconds from crash to PR.

A real example

I deployed a pod that intentionally fails to connect to a database. Here is what Claude wrote in the PR:

"The application failed to establish a connection to the PostgreSQL database at postgres://db:5432. The pod crashed with exit code 1 after logging ERROR: Database connection failed and FATAL: Cannot connect to postgres://db:5432. This indicates either the database service is unreachable, not running, or the connection string is incorrect."

Then it generated the Kubernetes Service YAML to fix the service discovery and listed seven kubectl commands to diagnose the issue. In a PR. Automatically. While I was watching the logs.

How it is built

There are four pieces.

KubernetesWatcher is a .NET BackgroundService that uses KubernetesClient to stream pod events. It looks for specific failure conditions in the container status:

private FailureEvent? DetectFailure(V1Pod pod, V1ContainerStatus status)
{
    var waiting = status.State?.Waiting;
    var terminated = status.State?.Terminated;

    if (waiting?.Reason == "CrashLoopBackOff")
        return CreateFailure(pod, FailureType.CrashLoopBackOff, waiting.Reason, waiting.Message ?? "");

    if (waiting?.Reason == "ImagePullBackOff" || waiting?.Reason == "ErrImagePull")
        return CreateFailure(pod, FailureType.ImagePullError, waiting.Reason, waiting.Message ?? "");

    if (terminated?.Reason == "OOMKilled")
        return CreateFailure(pod, FailureType.OOMKilled, "OOMKilled", "Container exceeded memory limit");

    if (terminated?.ExitCode > 0 && status.RestartCount > 0)
        return CreateFailure(pod, FailureType.PodCrash, "CrashExit",
            $"Container exited with code {terminated.ExitCode}");

    return null;
}

ClaudeAnalyser takes the failure and logs, builds a prompt, and calls the Anthropic API. It asks for structured JSON back so the response is easy to parse:

var response = await _client.Messages.GetClaudeMessageAsync(
    new MessageParameters
    {
        Model = "claude-haiku-4-5-20251001",
        MaxTokens = 2048,
        Messages = new List<Message>
        {
            new Message
            {
                Role = RoleType.User,
                Content = new List<ContentBase>
                {
                    new TextContent { Text = prompt }
                }
            }
        }
    });

The prompt tells Claude to act as a Kubernetes expert and return root cause, severity, a plain English fix, and the actual code or config change. Haiku is fast enough for this and costs around $0.0008 per analysis.

GitHubService uses Octokit to create a branch, commit the analysis as a markdown file, and open a PR:

await _client.Repository.Content.CreateFile(
    _settings.GitHubRepoOwner,
    _settings.GitHubRepoName,
    fileName,
    new CreateFileRequest(
        message: $"fix: self-healing patch for {result.OriginalFailure.Type} in {result.PodName}",
        content: Convert.ToBase64String(Encoding.UTF8.GetBytes(fixContent)),
        branch: branchName));

HealingOrchestrator coordinates the three above and makes sure the same failure does not trigger duplicate healing attempts while the first one is still running.

The prompt matters more than the code

I spent more time on the Claude prompt than on anything else in this project. Telling it to return structured JSON, referencing actual log lines, and specifying the failure type all produce much better output than a generic ask.

The prompt I settled on:

You are a Kubernetes expert and .NET engineer analysing a production failure.

Analyse this Kubernetes pod failure and respond ONLY with valid JSON.

FAILURE DETAILS:
Pod: {pod name}
Namespace: {namespace}
Failure Type: {type}
Reason: {reason}

POD LOGS (last 100 lines):
{logs}

Respond with this exact JSON structure:
{
    "rootCause": "Clear explanation of what caused the failure",
    "severity": "Critical|High|Medium|Low",
    "suggestedFix": "Step by step fix in plain English",
    "codeFix": "The actual code or config change needed. Empty string if none.",
    "fixType": "config|code|resources|image|none"
}

Be specific. Reference actual log lines where relevant.

The key instruction is "respond ONLY with valid JSON". Without that, Claude adds explanation text around the JSON and the parser breaks.

Running it locally

You need .NET 10, Docker Desktop with Kubernetes enabled, an Anthropic API key, and a GitHub personal access token with repo permissions.

git clone https://github.com/aftabkh4n/genai-devops-platform.git
cd genai-devops-platform/DeploymentService
dotnet run

Add your keys to appsettings.json and you will see:

[INF] Kubernetes watcher started. Watching namespace: default
[INF] Now listening on: http://localhost:0000

To test it, deploy the crash test included in the repo:

kubectl apply -f crash-test.yaml

Within a few seconds you will see the failure detected in the console, Claude called, and a PR URL printed. Go check your GitHub repo.

What I learned

The watcher reconnects automatically when the Kubernetes stream disconnects. This happens more often than you would think, especially after cluster restarts. Wrapping the watch loop in a try/catch with a 5 second delay before reconnecting keeps it stable.

The SemaphoreSlim in HealingOrchestrator is important. A pod in CrashLoopBackOff generates events every few seconds. Without deduplication you end up with ten simultaneous Claude API calls for the same pod, ten branches, and ten PRs. Not ideal.

Using jq to build JSON payloads is safer than shell string interpolation. Pod names and log lines contain characters that break JSON when interpolated directly.

Source code: https://github.com/aftabkh4n/genai-devops-platform

If you try it and find a failure type it misses, open an issue.

Why AI assistants forget everything , and how I fixed it in .NET

Aftab Bashir — Thu, 16 Apr 2026 09:43:33 +0000

I was building an AI chat assistant in Blazor. It worked fine. But every new conversation started from scratch. The user would say "I'm a software engineer who loves C#" and the assistant would respond warmly , then forget it completely the next time they opened the app.

That's not a memory problem. That's just a chat window.

I wanted something better. Something that actually remembers the user across sessions, extracts facts from conversations, and uses them to give better responses over time. I looked around for a .NET library that did this. Nothing existed. So I built it.

What I built

BlazorMemory is an open-source AI memory layer for .NET. It sits between your chat logic and your LLM and does three things:

Extracts facts from conversations using an LLM
Stores them as vector embeddings
Injects relevant memories into future prompts

The flow looks like this:

User message → extract facts → embed → store
                                          ↓
Next message → embed query → vector search → inject memories → LLM

It works in Blazor WASM with zero backend , everything stays in the browser using IndexedDB. It also works server-side with EF Core if you need SQL storage.

The hard part wasn't storage

Storing memories is easy. The hard part is making them useful.

Early versions just stored everything. After a few conversations, the memory panel was full of duplicates. "User likes C#." "User works with C#." "User is a C# developer." Three separate entries saying the same thing.

I solved this with a two-step pipeline:

Step 1 , Extract: The LLM reads the conversation and pulls out discrete facts. One sentence per fact, starting with "User". If the conversation already produced "User is a C# engineer", it won't also extract "User loves C#" , the preference is already implied.

Step 2 , Consolidate: For each new fact, the system finds similar existing memories using vector search. Then it asks the LLM: should I ADD this, UPDATE an existing memory, DELETE a contradiction, or do NOTHING?

The consolidation prompt has a clear priority order: NONE > UPDATE > DELETE > ADD. It prefers doing less. That keeps the memory clean.

Getting started

dotnet add package BlazorMemory
dotnet add package BlazorMemory.Storage.IndexedDb
dotnet add package BlazorMemory.Embeddings.OpenAi
dotnet add package BlazorMemory.Extractor.OpenAi

Wire it up in Program.cs:

builder.Services
    .AddBlazorMemory()
    .UseIndexedDbStorage()
    .UseOpenAiEmbeddings(apiKey)
    .UseOpenAiExtractor(apiKey);

Use it in your chat service:

public class ChatService(IMemoryService memory)
{
    public async Task<string> ChatAsync(string message, string userId)
    {
        // Pull relevant memories
        var memories = await memory.QueryAsync(message, userId,
            new QueryOptions { Limit = 5, Threshold = 0.65f });

        // Build system prompt
        var context = string.Join("\n", memories.Select(m => $"- {m.Content}"));
        var prompt = $"You are a helpful assistant.\n\nWhat you know:\n{context}";

        // Call your LLM
        var reply = await CallLlm(prompt, message);

        // Extract and store new facts
        await memory.ExtractAsync($"User: {message}\nAssistant: {reply}", userId);

        return reply;
    }
}

That's it. The assistant now remembers things.

Namespaces

v0.2.0 added namespace support. You can scope memories by topic:

// Store work memories separately from personal ones
await memory.ExtractAsync(conversation, userId, namespace: "work");

// Query only work memories
var results = await memory.QueryAsync(query, userId, new QueryOptions
{
    Namespace = "work"
});

Useful if you're building an assistant that handles multiple contexts.

What's available

Seven NuGet packages, all at v0.2.0:

Package	What it does
`BlazorMemory`	Core library
`BlazorMemory.Storage.IndexedDb`	Browser storage, zero backend
`BlazorMemory.Storage.InMemory`	For testing
`BlazorMemory.Storage.EfCore`	SQL Server, PostgreSQL, SQLite
`BlazorMemory.Embeddings.OpenAi`	OpenAI embeddings
`BlazorMemory.Extractor.OpenAi`	OpenAI fact extraction
`BlazorMemory.Extractor.Anthropic`	Claude fact extraction

The repo is at github.com/aftabkh4n/BlazorMemory. Issues and PRs welcome.

If you're building AI assistants in .NET and want them to actually remember users, give it a try.

I added AI-generated release notes to my CI/CD pipeline using Claude and GitHub Actions

Aftab Bashir — Thu, 16 Apr 2026 05:41:59 +0000

Every time I merged a PR I had to write a changelog entry manually. It took two minutes but I kept forgetting to do it. So I automated it with Claude.

When a PR merges to main, a GitHub Actions workflow reads the PR title, description, and changed files, sends them to the Claude API, and gets back a structured changelog entry. That entry gets committed to CHANGELOG.md automatically. The whole thing runs in about 10 seconds.

What MCP has to do with this

Nothing, directly. But this pipeline lives inside my MCP Kubernetes Manager project, which already lets Claude manage Kubernetes clusters through natural language. Adding AI-generated release notes felt like a natural fit. The project now manages its own changelog the same way it manages deployments.

If you want context on the MCP server itself, I wrote about it here: https://dev.to/aftabkh4n/i-built-an-mcp-server-in-net-that-lets-claude-manage-my-kubernetes-cluster-through-natural-language-3cji

How the pipeline works

A GitHub Actions workflow triggers on pull_request with type closed. The first thing it checks is whether the PR was actually merged, not just closed:

if: github.event.pull_request.merged == true

That condition is important. Without it the workflow runs on every closed PR including ones that were rejected.

Then it collects the PR metadata:

env:
  PR_TITLE: ${{ github.event.pull_request.title }}
  PR_BODY: ${{ github.event.pull_request.body }}
  PR_NUMBER: ${{ github.event.pull_request.number }}
  PR_AUTHOR: ${{ github.event.pull_request.user.login }}
  PR_MERGED_AT: ${{ github.event.pull_request.merged_at }}

And gets the list of changed files from git:

CHANGED_FILES=$(git diff --name-only HEAD~1 HEAD | head -20 | tr '\n' ', ')

Calling the Claude API

The API call is a standard POST to the Anthropic messages endpoint. The key part is building the payload with jq so special characters in PR titles and descriptions do not break the JSON:

PAYLOAD=$(jq -n \
  --arg model "claude-haiku-4-5-20251001" \
  --arg pr_num "$PR_NUMBER" \
  --arg pr_title "$PR_TITLE" \
  --arg pr_body "$PR_BODY_SAFE" \
  --arg files "$CHANGED_FILES" \
  '{
    model: $model,
    max_tokens: 1024,
    messages: [{
      role: "user",
      content: ("Generate a changelog entry for PR #" + $pr_num + ": " + $pr_title)
    }]
  }')

RESPONSE=$(curl -s https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d "$PAYLOAD")

ENTRY=$(echo "$RESPONSE" | jq -r '.content[0].text')

The model is claude-haiku-4-5-20251001 which is the fastest and cheapest Claude model. For a changelog entry it produces the same quality as larger models at a fraction of the cost.

The API key is stored as a GitHub Actions secret called ANTHROPIC_API_KEY. Never hardcode it.

Writing the changelog entry back

Once Claude returns the entry, the workflow prepends it to CHANGELOG.md so the newest entry is always at the top:

TEMP=$(mktemp)
head -4 CHANGELOG.md > "$TEMP"
echo "$ENTRY" >> "$TEMP"
tail -n +5 CHANGELOG.md >> "$TEMP"
mv "$TEMP" CHANGELOG.md

Then commits and pushes as github-actions[bot]:

git config user.name "github-actions[bot]"
git config user.email "github-actions[bot]@users.noreply.github.com"
git pull --rebase origin main
git add CHANGELOG.md
git commit -m "docs: AI-generated changelog for PR #${{ github.event.pull_request.number }}"
git push

The git pull --rebase before the push is important. The PR merge itself updates main, so without pulling first the push gets rejected.

What the output looks like

After merging a PR that adds Kubernetes tools documentation, Claude wrote this:

## [PR #5] docs: add tools list to README
*2026-04-16T05:13:52Z by @aftabkh4n*

### Changes
- Added documentation describing the AI-powered changelog automation workflow
- Documented how Claude generates structured changelog entries automatically when PRs merge to main
- Explained the process of reading PR metadata to produce changelog entries

### Files changed
- README.md

It reads the PR description and infers what actually changed. The better your PR description, the better the changelog entry.

What it costs

The Anthropic API is not free but it is very cheap for this use case. Haiku costs $0.80 per million input tokens. A typical PR payload is around 500 tokens. That works out to roughly $0.0004 per changelog entry, less than a cent per merge.

Setting it up in your repo

Get an API key from console.anthropic.com
Add it as a secret in your repo: Settings, Secrets and variables, Actions, New repository secret, name it ANTHROPIC_API_KEY
Create .github/workflows/release-notes.yml with the full workflow

Full source code: https://github.com/aftabkh4n/mcp-kubernetes-manager

What I would add next

A way to skip the changelog for trivial PRs would be useful. Something like checking whether the PR title starts with chore: or wip: and skipping the API call entirely. That keeps the changelog clean without adding friction to the merge process.

I added AI code review and failure analysis to my CI/CD pipeline using GitHub Actions and GPT-4o-mini

Aftab Bashir — Wed, 15 Apr 2026 05:56:29 +0000

Every pull request in my IDP Platform project now gets an automatic AI
code review before anyone looks at it. When the pipeline fails, an AI
posts a root cause analysis explaining what went wrong and how to fix it.

Both run automatically inside GitHub Actions using GPT-4o-mini. No
external services, no extra infrastructure, no monthly subscription.

The problem with manual code review

Code review is valuable but it has a bottleneck. The reviewer needs
context, time, and attention. For a solo developer or a small team,
that bottleneck slows everything down. Even experienced developers miss
things when they are tired or rushing.

AI does not replace code review. It adds a first pass that catches
obvious issues before a human spends time on them. Things like missing
error handling, security anti-patterns, performance problems, and
violations of framework conventions.

How the AI code review works

When a pull request is opened or updated, a GitHub Actions workflow runs
automatically. It gets the diff of all changed C# files, sends it to
GPT-4o-mini with a prompt describing the review criteria, and posts the
response as a comment on the PR.

The whole thing runs in under 15 seconds.

# Get the diff using subprocess for reliability
result = subprocess.run(
    ['git', 'diff', f'origin/{base_ref}...HEAD', '--', '*.cs'],
    capture_output=True, text=True
)
diff = result.stdout[:6000]

# Send to OpenAI
payload = {
    "model": "gpt-4o-mini",
    "max_tokens": 1000,
    "messages": [
        {
            "role": "system",
            "content": "You are a senior .NET engineer reviewing a pull 
            request. Give concise actionable feedback on correctness, 
            security, performance, and .NET best practices."
        },
        {
            "role": "user",
            "content": f"Review this diff:\n\n```
{% endraw %}
diff\n{diff}\n
{% raw %}
```"
        }
    ]
}

The system prompt is what controls the quality of the review. I spent
more time on the prompt than on the code around it. Telling the AI to
act as a senior .NET engineer and focus on specific categories produces
much more useful output than a generic review request.

A real review from the pipeline

Here is what the AI posted on an actual PR in my project:

It flagged an invalid port number in a comment I had left in Program.cs.
It questioned whether database migration error handling was sufficient.
It noted that Swagger should be restricted in production environments.
It pointed out a missing newline at the end of the file.

None of those are critical issues but all of them are worth knowing about
before merging. The AI caught them in 14 seconds before I even looked at
the PR.

How the failure analysis works

The second workflow runs when the CI/CD pipeline fails. It fetches the
build logs from the GitHub API, sends them to GPT-4o-mini, and posts the
analysis as a check on the commit.

This is particularly useful for cryptic build errors. Instead of reading
through hundreds of lines of MSBuild output, you get a plain English
explanation of what failed and what to do about it.

The workflow structure

name: AI Code Review

on:
  pull_request:
    types: [opened, synchronize]
    paths:
      - 'src/**/*.cs'
      - 'src/**/*.csproj'

jobs:
  ai-review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write

    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: AI Code Review
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
          BASE_REF: ${{ github.base_ref }}
        run: |
          python3 << 'PYTHON'
          # get diff, call OpenAI, post comment
          PYTHON

The paths filter is important - the workflow only runs when C# files
change. Updating a README does not trigger a code review. This keeps the
pipeline fast and the API costs minimal.

What it costs

GPT-4o-mini charges roughly $0.15 per million input tokens and $0.60 per
million output tokens. A typical code review diff is around 2000 tokens.
At that rate you could run 500 code reviews for about $0.15.

For a portfolio project or small team this is effectively free. Even at
50 PRs a month the cost is under $0.02.

What I learned

The system prompt matters more than anything else. A vague prompt like
"review this code" produces generic output. A specific prompt that names
the language, the role, the focus areas, and the output format produces
review comments that are actually useful.

Passing environment variables into Python heredocs requires care. GitHub
Actions expressions like ${{ github.base_ref }} are not expanded inside
heredocs. The fix is to set them as environment variables first and read
them with os.environ inside the script.

subprocess is more reliable than os.popen for running shell commands in
Python. It captures stdout and stderr separately and handles errors more
predictably.

What is next

The natural next step is AI-generated release notes. When a PR is merged
to main, the AI reads all the commit messages and diff since the last
release and writes a structured changelog entry automatically. No more
manually writing release notes.

I am also looking at adding a security scan step that uses AI to check
for common vulnerability patterns before the standard SAST tools run.

Source code: https://github.com/aftabkh4n/idp-platform

If you are building something similar or have ideas for improving the
prompts, drop a comment below.