DEV Community: Anton Makarevich

How I Teach LLMs to Play BattleTech (Part 2): Building an MCP Server and Agents in C#

Anton Makarevich — Wed, 28 Jan 2026 12:55:26 +0000

This post is Part 2 of a series on building an LLM-powered BattleTech bot.

👉 Part 1: Architecture, Agents, and Tools

What to Expect

Here’s how the series is structured:

Part 1. Theory & Architecture

Introduction
MakaMek Architecture Overview
How LLM Models Use Tools

Part 2. Hands-On Implementation

Building an MCP Server to Query Game State
Creating Agents with the Microsoft Agent Framework
Empowering Agents with Tools
Conclusion

MCP Server for Querying Game State

In Part 1, we covered the motivation, architecture, and theory behind using tools and agents in my BattleTech bot.

Let's see how to implement all of this in practice. Most examples around this topic are available in Python, mainly for historical reasons. As we saw earlier, however, agents and tools are just pieces of “traditional” software, they can be implemented in any programming language. Since MakaMek is a .NET application, it makes perfect sense to create agents and tools in the same tech stack.

All code is available on the MakaMek GitHub page — check the BotContainer (for MCP) and BotAgent (for AI agents) projects.

Let’s take a closer look at the MCP server. The idea is that it should have access to the ClientGame class and the corresponding calculators, and be able to query them to retrieve the tactical situation. This means we need to add an MCP server to the BotContainer project. It also needs to be a remote server so that AI agents can reach it over the network.

There is an official MCP SDK available for .NET and C#. It is currently in preview, which means the APIs are not fully stable yet, but I haven’t noticed any issues so far.

So how do we implement an MCP server in a .NET app? The process is straightforward and consists of just a few steps.

1. Add the NuGet packages

To create a remote MCP server, add the following packages to your project:

dotnet add package ModelContextProtocol --version 0.6.0-preview.1
dotnet add package ModelContextProtocol.AspNetCore --version 0.6.0-preview.1

The first one (ModelContextProtocol) is core MCP functionality, it's enough if you only need to create a local server, the ModelContextProtocol.AspNetCore is required for a remote MCP to enable HTTP/SSE server and transport.

2. Register the MCP server in DI

Once the packages are added, register the MCP server with the DI container:

services.AddMcpServer(options =>
{
    options.ServerInfo = new Implementation
    {
        Name = "MakaMek MCP Server",
        Version = "0.1.0"
    };
})
.WithHttpTransport(options => // enables a remote server accessible via HTTP/SSE
{
    options.Stateless = true; // important if you want to host it in a serverless function
})
.WithTools<DeploymentTools>() // classes with tools exposed by this server
.WithTools<MovementTools>()
.WithTools<WeaponsAttackTools>();

3. Expose the MCP endpoints

Because the MCP uses a standard endpoints, no custom controller code is needed:

app.MapMcp();

4. Implement your tools

Tools, as explained in Part 1, are just regular C# methods decorated with certain attributes for discoverability.

Here is an example of one of the simplest tools. More complex ones are available in the repository:

[McpServerToolType] // Indicates that this class contains MCP tools (optional with manual registration)
public class DeploymentTools
{
    private readonly IGameStateProvider _gameStateProvider;

    public DeploymentTools(IGameStateProvider gameStateProvider)
    {
        _gameStateProvider = gameStateProvider;
    }

    // Description is one of the most important parts: it is what the LLM "sees".
    // It should clearly explain when the tool should be used and what it does.
    [McpServerTool, Description("Get valid deployment zones (hexes). Should be used by the deployment agent.")]
    public List<HexCoordinateData> GetDeploymentZones()
    {
        return _gameStateProvider.ClientGame.GetEdgeHexCoordinates()
            .Select(h => h.ToData())
            .ToList();
    }
}

5. Connect your agent to the MCP server

That’s it. When you start the application, your MCP server becomes available to any agents on the same network. Just add the corresponding MCP configuration to your favorite coding agent (VS Code, Cursor, Claude, Kiro — you name it) to quickly test that it's actually working:

{
  "servers": {
    "makamek-mcp-server": {
      "url": "http://localhost:5002",
      "type": "http"
    }
  }
}

Creating Agents with Microsoft Agent Framework

Now that we have an MCP server, let’s create our own agents to use it. Again, we’ll do this in C#, and the obvious choice is the Microsoft Agent Framework (MAF), since it provides a .NET SDK alongside the Python one. MAF is a fairly new product, but it is based on Semantic Kernel after its merge with AutoGen.

I should mention that this is one of the areas where Microsoft’s approach can be confusing. They move fast and change APIs often, which makes production use risky. For example, in the week since I finished this feature, some APIs already changed in a new preview release. In this post, I’ll reference the version I used during development. Be aware that it’s not the latest one, and you may need to adjust names and APIs if you upgrade.

So let’s see how to create agents using MAF.

1. Add the NuGet packages

dotnet add package Microsoft.AspNetCore.OpenApi --version 10.0.2 # Needed for models supporting the OpenAI API
dotnet add package Microsoft.Agents.AI --version 1.0.0-preview.260108.1 # Microsoft Agent Framework
dotnet add package Microsoft.Extensions.AI --version 10.2.0
dotnet add package Microsoft.Extensions.AI.Abstractions --version 10.2.0
dotnet add package Microsoft.Extensions.AI.OpenAI --version 10.2.0-preview.1.26063.2

Microsoft.Agents.AI is the Microsoft Agent Framework itself. The remaining packages provide abstractions and extensions to wire it into the broader Microsoft AI ecosystem. I’ll come back to that shortly.

2. Choose and abstract your model provider

Next, think about the model you want to use to power your agents. If your hardware allows it (for example, a decent GPU with enough VRAM), running a local model is often a good place to start. Local models are weaker than frontier models, but they’re free to run (apart from your electricity bill).

LM Studio is my tool of choice to run local models, but the same approach works with Ollama or Foundry Local.

A good practice is not to hardcode the model provider and instead make it swappable. To illustrate this, let’s create two providers that conform to a common interface.

2.1 Common LLM provider interface

public interface ILlmProvider
{
    IChatClient GetChatClient();
}

IChatClient comes from Microsoft.Extensions.AI and represents a client capable of communicating with any chat model.

2.2 OpenAI implementation

public IChatClient GetChatClient()
{
    var openAiClient = new OpenAIClient(_config.ApiKey);
    var chatClient = openAiClient.GetChatClient(_config.Model);

    return chatClient.AsIChatClient();
}

_config is a section of a standard ASP.NET Core configuration for the model provider (see the full project in the repo for details).

AsIChatClient() comes from Microsoft.Extensions.AI.OpenAI and knows how to wrap a concrete OpenAI client into the generic IChatClient abstraction.

2.3 Local / offline model implementation

Most local models support the OpenAI API, which is why I call this provider “OpenAI-like”:

public IChatClient GetChatClient()
{
    var openAiClient = new OpenAIClient(
        new ApiKeyCredential("NO_API_KEY_REQUIRED"),
        new OpenAIClientOptions { Endpoint = _endpoint });

    var chatClient = openAiClient.GetChatClient(_config.Model);

    return chatClient.AsIChatClient();
}

The implementation is almost identical, except that the local model does not require a real API key. Instead, we provide the endpoint of the LM Studio (or Ollama) server running the model.

2.4 Register providers with DI

Next, register the providers as dependencies. It’s handy to expose the active provider via configuration so models can be swapped without code changes:

services.AddSingleton<LocalOpenAiLikeProvider>();
services.AddSingleton<OpenAiProvider>();
services.AddSingleton<ILlmProvider>(sp =>
{
    var cfg = sp.GetRequiredService<IOptions<LlmProviderConfiguration>>().Value;

    return cfg.Type switch
    {
        "LocalOpenAI" => sp.GetRequiredService<LocalOpenAiLikeProvider>(),
        "OpenAI" => sp.GetRequiredService<OpenAiProvider>(),
        _ => throw new InvalidOperationException($"Unsupported LLM provider type '{cfg.Type}'.")
    };
});

3. Create agents with MAF

Once the wiring is done, we can move on to the actual implementation. In my case, I need four agents, one per game phase. They differ mainly by their prompts and the tools they use; the underlying model can be the same.

With that in mind, I created an abstract BaseAgent class and four specialized agents derived from it. Model setup is shared in the base class.

To access the model, we need an instance of AIAgent from MAF. There are several ways to create it, either directly via a constructor or via a builder. The builder approach is more flexible because it allows you to plug in middleware, so that’s what I use:

var agent = LlmProvider.GetChatClient()
    .CreateAIAgent(
        instructions: SystemPrompt, // defined in the derived agent
        tools: allTools)            // tools (we’ll look at them in detail later)
    .AsBuilder()
    .Use(ToolCallMiddleware)
    .Build();

var thread = agent.GetNewThread();

ToolCallMiddleware is a callback executed by the AIAgent before it invokes a tool requested by the model. It’s very useful for observability and guardrails.

thread holds the entire conversation history between the agent and the model. It’s important to create one so the model has proper context, for example knowing that a previous step triggered a tool call.

4. Run the agent

Now that we have an AIAgent instance, we can start making calls to the model:

var response = await agent.RunAsync(
    userPrompt,
    thread);

Empowering Agents with Tools

At this point, the agent can reason and return a text response. But what about our MCP server? How do we use the tools it exposes? And how do we convert a model’s response into a structured command that the game can actually execute?

Remember the tools array we passed to the agent factory method? Let’s take a closer look at it. This array contains definitions of all AITools that we want to make available to the model, including MCP tools, API tools, and local tools. In this post, we focus only on MCP and local tools, since those are the ones used by the MakaMek agents.

1. MCP tools

To access tools exposed by a remote MCP server, we first create an MCP client by providing the server endpoint and a transport mode:

await using var mcpClient = await McpClient.CreateAsync(
    new HttpClientTransport(
        new HttpClientTransportOptions 
        {
            TransportMode = HttpTransportMode.StreamableHttp, // HTTP/SSE transport for remote servers
            Endpoint = new Uri(mcpEndpoint),
        }));

Note the await using statement: mcpClient should be disposed when no longer needed. Be careful with the scope, though — the client must remain alive for as long as the agent needs to call MCP tools.

Once the MCP client is created, we can list all tools available on the server:

var mcpTools = await mcpClient.ListToolsAsync();

If MCP tools are the only ones you use, this list can already be passed directly to the agent factory.

2. Local tools

Local tools are functions defined in the same module (in .NET terms, the same assembly) as the agents. In MakaMek, each specialized agent exposes its own local tools, mostly to translate the model’s decisions into concrete MakaMek commands.

Here’s an example of a local tool used by the DeploymentAgent:

[Description("Execute a deployment decision for a unit")]
private string MakeDeploymentDecision(
    [Description("Unit GUID")] Guid unitId,
    [Description("Q coordinate")] int q,
    [Description("R coordinate")] int r,
    [Description("Facing direction 0-5")] int direction,
    [Description("Tactical reasoning")] string reasoning)
{
    var command = new DeployUnitCommand
    {
        UnitId = unitId,
        Position = new HexCoordinateData(q, r),
        Direction = direction,
        GameOriginId = Guid.Empty, // Will be set by ClientGame
    };

    PendingDecision = (command, reasoning);

    return JsonSerializer.Serialize(new 
    { 
        success = true, 
        message = "Deployment decision recorded" 
    });
}

Notice that both the method and all its parameters are decorated with the Description attribute. This metadata is important: the LLM uses it to understand when and how the tool should be called.

Once the tools are defined, we expose them by overriding GetLocalTools() in a specialized agent:

protected override List<AITool> GetLocalTools()
{
    return
    [
        AIFunctionFactory.Create(MakeDeploymentDecision, "make_deployment_decision")
    ];
}

Here, AIFunctionFactory.Create turns a normal C# method into an AITool by providing the method reference and the name that will be visible to the model.

3. Combining MCP and local tools

Now we can retrieve the agent-specific local tools, combine them with the MCP tools, and pass them to the agent:

var localTools = GetLocalTools();

List<AITool> allTools = [..localTools, ..mcpTools]; // passed to the agent factory

This is the same allTools collection we provided earlier when creating the agent.

That concludes the entire end-to-end flow of exposing tools via MCP and consuming them using agents. Of course I had to take some shortcuts in the blog, but feel free to explore the full solution on GitHub.

Conclusion

So, with all the tools and “LLM wisdom” available to the bot, can it actually play the game? And if it can, how does it compare to a traditional rule-based bot?

The answer is both yes and no. It does play the game, and with all the guardrails in place it always takes valid actions, but those actions often feel very random and don’t make much sense, even when the full tactical situation is available to the model. This is especially noticeable with smaller local models (I use qwen3-vl-8b), which very often just picks one of the first available options. Frontier GPT-5.2 behaves a bit more “believably”, but there is still no comparison with a rule-based bot that consistently chooses the best available option and is therefore almost impossible to beat when the dice gods are not on your side. On top of that, the rule-based bot is much faster and cheaper to run: depending on the number of units controlled by the bot, a single game can easily exceed a million input tokens.

This real-world result demonstrates that AI isn't always the right solution, even when it's technically feasible.

Even though the LLM-powered bot turned out to be practically useless from a gameplay perspective, I don’t regret building it. It gave me a great agentic playground in a domain I really enjoy and can continue improving.

Some obvious areas for improvement would be:

refining the prompts (they are definitely not optimised yet),
converting tool outputs to natural language instead of the current structured format,
introducing another type of tool, such as RAG, to provide BattleTech rules relevant to a specific situation,
and, as a longer-term idea, retraining or fine-tuning a model once I have enough gameplay logs.

So there are plenty of ideas left to explore in my spare time (if I can find some 😄).

Do you see anything else worth adding to the list?

How I Teach LLMs to Play BattleTech (Part 1): Architecture, Agents, and Tools

Anton Makarevich — Tue, 27 Jan 2026 11:33:46 +0000

This post is Part 1 of a series on building an LLM-powered BattleTech bot.

👉 Part 2: Building an MCP Server and Agents in C#

What to Expect

Here’s how the series is structured:

Part 1. Theory & Architecture

Introduction
MakaMek Architecture Overview
How LLM Models Use Tools

Part 2. Hands-On Implementation

Building an MCP Server to Query Game State
Creating Agents with the Microsoft Agent Framework
Empowering Agents with Tools
Conclusion

Introduction

Nowadays there seems to be a tendency to solve almost every problem with a solution that implies use of AI agents. "There is not enough AI in this report", or "this proposal is great, but where are your AI agents?" is something that I hear frequently. But are we really supposed to throw AI on every problem? I do find the technology extremely useful for many use cases, but at the same time there are many cases where traditional automation is still a valid option.

To illustrate this, I want to describe how after building a rule-based bot for my pet-project MakaMek (which is a computer implementation of a turn-based tactical wargame BattleTech), I've decided to make one step further and create an LLM-powered bot too.

Someone has actually suggested: “just use ChatGPT for the bot” when I asked for an advice on bot's strategy. I was quite skeptical about the idea: as I explained in my previous (now almost one-year-old) blog post, I do not believe that predicting the next token has anything to do with “true intelligence”, but at the same time I already had all the functions and scripts to evaluate the actual tactical situation on the board, coming from my rules-based implementation. So I wondered: if I provide that information with the available options in a clear text format, could the model pick choices that actually make sense?

Working on this feature was a lot of fun, and it gave me valuable hands-on experience in building agents and connecting them with various tools, including a custom Model Context Protocol (MCP) server.

In this post, I cover some fundamentals of agentic systems and the journey behind my LLM-powered bot. I’ll explain the architecture that allowed me to add it without changing the main application, and demonstrate how to build an MCP server, AI agents, LLM providers, and tool integrations using .NET and C#.

MakaMek Architecture

MakaMek is my own computer version of BattleTech that I use as a playground for experimenting with new technology. The game is FOSS and available on GitHub.

It is a server–client application written in .NET. The server holds the authoritative game state, which can be changed by applying commands received from clients. A single client can host one or more players, including human players and bots. The server and clients communicate via a custom pub-sub–based command protocol that supports multiple transports, including reactive commands, pure WebSockets, and SignalR. Both server and client are UI-agnostic and can be hosted in any process.

Given this architecture, the obvious solution for an LLM bot was to implement it as a standalone, headless application hosting the game client and the bot logic. I was able to reuse the Bot class from the rules-based implementation. The bot itself is generic: it contains no decision logic and only observes the client game state. For decision-making, the bot relies on an IDecisionEngine interface where the actual logic is implemented. The rules-based bot has a dedicated engine per game phase. I took the same approach for the LLM-powered bot and introduced four llm* decision engines for the phases that require user input. These engines delegate the actual decision-making to an AI agent.

For the AI agents, I decided to introduce a separate host application/service to improve flexibility and scalability. In my setup, the bot and the agent host are two independent applications packaged as Docker containers that communicate over HTTP. The bot (via the LLM decision engine) sends a request to the agent application containing a high-level description of the game state, including all units.

The agent application contains four phase-specific agents. A router redirects each request to the appropriate agent based on the current game phase. The agent converts the structured request into an LLM-friendly text prompt and invokes the model. The model produces a decision, which is then returned to the bot as an HTTP response.

While this design provides a solid foundation, there are still two problems not addressed by the process:

Information about the units alone is often not enough. An LLM cannot truly “understand” a tactical situation from raw state data. It needs additional context, such as where units are allowed to move, which enemies pose a threat, hit probabilities, and similar factors.
The agent is expected to return a well-structured, schema-compliant response that can be safely executed by the game.

To address both issues, we can equip our agents with tools:

The bot application can run an MCP server exposing tools that provide tactical data by querying the game client.
The agent can include helpers to validate and format responses according to the expected command schema.

This leads to a question that still confuses many people, including experienced engineers: what tools actually are, what types of tools exist, and how agents and models actually use them.

How LLM Models Use Tools

Let’s approach these questions one by one. So, what is a “tool”? The simple answer is: any custom code or script written in any programming language. It can be a local function running in the same process as the agent (a local tool), a CLI program exposed via a local MCP server, or a function available on a remote server through a REST API or MCP. Based on this definition, a tool can effectively do “anything”: provide additional data, perform calculations, or execute actions.

But how do LLM models call those tools? And the simple answer to this question is: they don’t — at least not directly. An LLM is text-in, text-out; it is not capable of taking actions on its own. Instead, the model receives a list of available tools and their descriptions as part of the prompt and can respond with the name of the tool to use along with the required arguments. The actual execution is delegated to orchestration code, which we usually call an agent.

Here is a sample generic flow showing a scenario in which a model is provided with a list of tools of different types and “executes” them one by one:

The key takeaway is that every time a model decides to use a tool, it returns that decision to the agent. The agent executes the tool and then resubmits the original prompt together with the tool result back to the model so it can continue reasoning.

Each tool execution therefore requires another round-trip to the model, which means extra latency and additional token usage. In practice, this results in roughly double the tokens being spent for every additional tool call. If data is available upfront, it often makes sense to include it directly in the initial prompt instead of relying on tool calls, which introduce extra cost and delay.

This concludes the theoretical part of the series.

👉 In Part 2 we’ll get more practical and build a remote MCP server using the C# MCP SDK, define agents with the Microsoft Agent Framework, and connect the agents to a local and cloud LLM.

We’ll also deploy the two bot implementations against each other. Curious who will win? Read Part 2 to the end.
Or maybe you already know the answer?😄 Let me know in the comments.

Control Over Speed: My Take on AI Coding

Anton Makarevich — Mon, 21 Apr 2025 20:56:56 +0000

Recently, I’ve seen a lot of discussion around using AI agents to create software. IDEs and plugins supporting agentic workflows like Cursor, Windsurf, Firebase Studio, you name it... are becoming extremely popular. But there’s no clear consensus in the community on whether that’s a good or bad thing. Some praise them for a huge productivity boost, others blame them for producing an incredible amount of meaningless, non-maintainable code - a recipe for disaster in the near future. I hear voices of people that I know and respect and they are coming from both groups.

So where’s the truth? Maybe only time will tell, but I believe it lies somewhere in the middle. And “vibe coding” is not necessarily the (only) way to utilize AI Agents.

The Context

I haven't done any blogging in years, (maybe even decades), but the topic is so hot that even I cannot help myself and break the silence to share my own thoughts and experience.

Let’s start with a quick quiz covering my current situation:

Q: Do you use AI agents in your daily work?

A: Yes, I do.

Q: Do you use them for any client work?

A: No, I don’t.

Q: Do you use them blindly, without much thinking?

A: I hope not.

Q: Do they boost your productivity?

A: Yes, they do, but nowhere near the hype of "I built this website with one prompt in 10 minutes".

Q: Do they affect the quality of your code?

A: That’s for you to judge - feel free to check my GitHub. Personally, I still see it as my code, even if technically I didn't type all of it using my keyboard.

Q: Is what you do considered “vibe coding”?

A: No idea. I hope not… but I might not be the best judge of that either. Let me know in the comments. 🙂

What Do I Want to Build and Why?

I’m known as a self-taught programmer with multiple degrees (including a PhD) in civil engineering but zero formal computer science education. Everything I know, I learned from books, blogs, videos, and working alongside many highly skilled colleagues. My learning has always been pragmatic: I pick up what I need to build something specific.

That started early. In the '90s, I was “famous” (at least within my family 😄) for a few projects:

A VBA script that made a button jump between cells in Excel.
A FoxPro-based DB and forms for cataloging paper models (another hobby of mine) I built.
A point-and-click adventure featuring my cousin Vovachka on a quest to kill the neighbor’s dog (yeah, sounds scary now 😬), written in VB6 (even more scary, right?).
An attempt to create a computer version of the BattleTech board game.

I especially remember the last one. It was so much fun, my first hands-on experience trying to implement the things right (as they taught in the books), and having some primitive architecture in place. Although I got the first prototype working with a hex map, unit deployment and movement logic, I never managed to finish it. I just didn't have enough skills, experience and eventually motivation. So I abandoned the thing but it kept bugging me to this day.

That's why at some point last November, 26 years after the original attempt, I decided to give it another try – with some (AI) assistance this time.

Creating the game is not the aim, is kind of pointless: BattleTech is copyrighted and its IP is a mess with different companies owning different bits. Also, the thing I wanted to build already exists. MegaMek is a mature implementation that’s been in development for 20+ years. So the main focus is on having fun, and they say to pursue your dreams, right? 😄

With that, on the 1st of December 2024, I opened a Windsurf editor, selected Claude 3.5 and put in my first prompt:

Please create me a computer implementation of a BattleTech game, use MegaMek as reference.

Of course I didn't get what I wanted with 1 prompt and within 10 minutes, the prompt above is just a joke. Even after almost 5 months (and roughly 80 actual hours) spent in the company of an AI agent it still feels like the very beginning of the journey.

Why AI, and How I Use It

I’m a bit of a skeptic. The recent AI boom is largely thanks to the “rise of transformers,” but there’s not much “intelligence” in these models. They don’t "think", they just predict the next token based on prior context and probabilities from training data. Fundamentally, it’s not that different from labeling images.

I doubt we’ll reach true intelligence (hello AGI 😄) with this tech alone. That might require a new kind of model to make the next big step. Still, LLMs are amazingly good at what they are supposed to do, and text proofreading and code generation are among the most valid use cases to me. And a personal open-source project seemed like the perfect playground to give AI a try.

I’ve experimented with different workflows to fit my style and needs. And eventually it feels like it made me more productive. How much "more", I do not know. Definitely not 10x, not even 5x, 2x is a more realistic number, but there is no scientific way to say for sure. You spend less time typing the code, but more typing and tuning the prompt, reviewing and editing the output, and, what is also important, - consider all the time just waiting for the agent finishing its job...

Ultimately, it’s about a balance between speed and quality or more precisely, deciding how responsibility is shared between you and the agent. You can go faster initially by giving it more freedom, but that can quickly spiral into chaos causing delays later on. I think that “quick way” only works for tiny greenfield projects. The ones you can do in one day and won't be bothered maintaining or updating in the future. In my setup, I act more as an architect. The agent is just a coder, predicting relevant pieces of C# and XAML.

That way, the project stays 100% mine: my architecture, my structure, my usual practices, including using my 15-year-old libraries for MVVM and the transport layer.

To achieve this, I had to sacrifice a great part of that productivity boost you would normally expect using an AI toolchain, with multiple rejections of proposed code, adjusting the prompts, and refactoring or even implementing some parts manually writing the code myself or leveraging traditional "copilot" mode which is still relevant and in some cases even more useful than full agentic flow.

And the fact that I love to work with technologies not many other people are enjoying (.NET and AvaloniaUI) "helps" a lot. As sometimes the model just doesn't "know" how to write the Avalonia markup correctly, confusing it with other XAML frameworks' syntaxes, and I just don't have a choice other than fixing something myself. It might be better for those of you working with tech stacks where more training data is available. At the same time I would not rely on AI "decisions" in the areas where you're not very strong, as what it proposes could be (and in the most cases is) a good practice indeed, but it could be also just a "hallucinated" nonsense - you should always be able to tell the difference.

What Works for Me (So Far):

Know exactly what you want to build down to technical details, so you can compare what the AI outputs to what’s in your head, and that leads us to:
Review all code, written by AI thoroughly.
Have unit tests for everything you can test. Many people also suggest following TDD. But for me, it really worked only if you create a test and implementation in different sessions: first ask to create a test, then create a new session, use the test as input/context and ask to implement the functionality. Otherwise, the agent tends to mess it up all the time anyway.
Keep prompts focused. Break features into small tasks. Start fresh sessions often. Only provide enough context for that task. Context windows are still a limiting factor, and how they’re filled is a black box.
Be flexible. You don't need to work with an agent for everything: in many cases utilizing your IDE's refactoring capabilities or relying on old good autocomplete mode make more sense.

I could dive into the technical details, but this post is long enough. Maybe next time, if people are interested.

Key Takeaway

The title says it all: control over speed.

That mindset resonates with another of my hobbies: flying FPV drones: it always starts very exciting but if you go too fast the chances to lose control and eventually crash are getting much higher. That's why I prefer calm cinematic flights over racing or freestyle. It works for me, however if you’ve got the confidence and skills, you can go fast and have more fun. Just know the risks.

Summary

So, is it worth it, even if it doesn’t make you 10x more productive?

Absolutely. It’s fun, it challenges you in new ways, and no, it won’t replace you as a software engineer. It’s just another tool in the toolbox.

My main concerns aren’t technical, but ethical. Energy usage, training data, all that. But hey, at least to me it makes much more sense than mining Bitcoin.