Michael Dugmore

Vibes ≠ Shipping

Sat, 31 Jan 2026 09:00:00 +0000

Personal views only (not my employer’s). This is a snapshot of my current thinking as we all learn AI - examples are from personal projects and experiments on non-critical systems.

The Idea

Vibe coding (which I dont actually like the term for all Agentic Coding, but it is what people use now) used to feel like a novelty. You describe what you want, the model fills in the syntax, and you ship something before your coffee gets cold.

Now it just feels normal. My feed is full of weekend build threads and the “coding is dead” crowd is never far behind.

I spent the holidays building that family planner I mentioned before. It’s mostly just a glorified way for us to argue about whose turn it is to take the bins out, but it’s ours. I spent two weeks vibe coding with LLM agents and shipping features in minutes. It was fun, right up until I opened my laptop on January 2nd and got that first production alert from the day job.

The gap

Over the break, the cost of being wrong was basically zero. If the LLM generated something weird, I just rolled back and tried again. Explore, discard, rewrite.

Inside a bank, the friction is the point. We are building systems that have to survive auditors, 3am callouts, and days when the market goes sideways. When a system moves money, “move fast and break things” is basically just professional negligence.

I vibe-coded the planner over the break and the code was fine for the most part. The interesting bit was what I had to stop the tool from adding. It generated this elaborate caching layer I never asked for. I only noticed it when a to-do item showed up twice in the same list. It was the same task and the same timestamp, but the IDs were different.

The model just decided I needed caching. Because I was in “vibe mode,” I merged the PR without really looking at the implementation.

That’s fine for a chore list but in a bank, “the model decided” won’t get you through an audit.

I ended up writing a “constitution” for the agent. These were guardrails like the WeekDoc rule, where we use one JSON document per week and replace it atomically. Without constraints, these tools breed complexity like they’re competing for a prize. I had to be the one saying “no, simpler.” The AI wanted tables and relations; I wanted something I could debug at 11pm when the data looks wrong.

A meta-interlude: The generic trap

I actually hit this exact wall trying to write this blog post. I had these rough ideas piling up for weeks and thought, “let’s just vibe-code the article.” I fed the notes into ChatGPT, Gemini, and Claude to see what would happen.

The results were… fine? Actually, they were too fine. Perfectly polished and totally empty. It read like generic thought-leader sludge. I realized that without being hyper-specific, you just get the median output of the internet.

So I didn’t save any time. I ended up rewriting most of this from scratch to get it to sound like a human. I did still use the LLMs to fix my terrible grammar and tighten the flow, so if this reads well and is still a little polished and “thought-leaderish” credit to them, but I had to drive the bus.

The back-and-forth was actually the useful part. Arguing with the LLM’s about the narrative helped me figure out what I actually wanted to say. It echoes the coding loop exactly: you hardly ever accept the first block of code. You refine, reject, and tweak until the mental model in your head matches the thing on the screen.

A different kind of lock-in

When I wrote before about AI and vendor lock-in, I was thinking about the economics. Cheaper custom software and smaller teams doing more. That’s real, but I think I missed the risk that actually matters day-to-day.

I’m becoming less worried about platform lock-in and much more worried about intent lock-in.

I keep catching myself accepting code I don’t fully understand. The “why” behind the system lives in a chat window I can’t easily replay or share with the team. I’m not really building anymore it feels like I’m just curating a series of fortunate accidents.

Craft vs. Outcomes

When this comes up in team discussions and online, I notice two reactions.

There’s the engineer who loves the craft. They want clean abstractions and they want to know what’s happening under the hood. For them, agentic coding feels like skipping the part where you actually understand the system. I used to think that was just being a Luddite, but now I think it’s just scar tissue. When something breaks at 2am and money is moving, you need a mental model of the system. You don’t need a stack of diffs that passed review because they looked plausible.

Then there’s the engineer motivated by outcomes. Ship, validate, move on. They have adopted these tools with a speed that is honestly a bit scary. They aren’t worried about losing the craft; they’re worried about what the job becomes when the productivity curve bends that hard. If one person can do in a day what used to take a team a week, what happens to the team?

I flip between these modes constantly. Context usually decides which instinct is rational, but the trick is knowing which context you are actually in. I’m starting to suspect that framing is a bit too clean anyway. Maybe it’s just one instinct (get the thing working) filtered through how many times you’ve been burned by a system you didn’t understand.

Normalisation of deviance

Johann Rehberger wrote about the “normalisation of deviance” in AI. It’s a concept from the Challenger disaster. If you get away with cutting a corner often enough, you stop seeing it as a corner. It just becomes how you do things.

The LLM generates something that looks right, the tests pass, and it deploys without issues. Do that enough times and your brain learns the tool is competent. You stop doing the work of being competent yourself.

I caught myself doing this last week. A 400-line PR came through from an agent. I skimmed it, saw the structure looked okay, and left a “looks good” comment. (This was not on a critical system, more as an expirement on the AI workflows). The next day I realized I hadn’t actually checked the error handling pattern. I trusted it because it looked like the kind of code the tool usually generates, and that code is usually fine.

Usually.

This is the “maintenance dose” problem I saw on Hacker News. If you only do 5% of the thinking, your judgment starts to atrophy. The failures aren’t loud; they’re subtle. A strange dependency choice or a slightly-off concurrency assumption. A security pattern you wouldn’t naturally reach for.

Is this an AI problem or a speed problem?

Here’s a concrete example I’ve been chewing on. Imagine an Anti-Money Laundering rule in a banks Transaction Monitoring system that flags any transaction over £10,000 for review.

The code looks fine, but the check runs against the integer portion of the amount. £9,999.99 slips right through. In the world of financial crime, that’s a structuring exploit.

The requirement said “over £10,000.” Nobody captured why the boundary matters. And because the tooling makes the whole thing take an afternoon instead of two weeks, the team never hits a natural moment where someone stops and asks what the failure mode is.

Maybe I’m over-thinking on this. Is it an AI problem, or is it just what happens when we move too fast? I don’t know. The lines are starting to feel very blurry.

The difference between a wish and intent

I think the real shift occurring is abstraction more than automation. We used to specify how systems work because we had to own the implementation details. Now we are more and more specifying what we want and the “how” is negotiated between prompts and models.

So where does intent live?

A prompt that says “build a service to validate account balances” is really just a wish. Intent is closer to the messy stuff: validate balances, fail fast if the ledger times out after 200ms, log errors with PII scrubbed, alert the on-call if error rate exceeds 1%.

One is asking for code; the other is describing a system. If the only place your architectural decisions exist is inside a proprietary context window, you are just renting it. And landlords can change the terms or lose the receipts anytime they want.

What I’m actually doing

I don’t buy the future where we vibe-code straight into production, at least not in regulated industries (anytime soon). But simply banning the tools feels like denial with extra steps.

So I’ve been trying a few things. I try use AI as a drafter, not an author. It handles the scaffolding and the glue code, the boring stuff that doesn’t need deep domain knowledge. This works well until the agent gets stuck in a loop and I have to take over anyway. (This applies to writing too, the AI drafts, but I have to do the heavy lifting to make it real).

I’m also trying to treat intent as a first-class artefact. We try to write out the plans and the constraints before letting the agent loose. This definitely goes against that move fast feeling, but I will sleep better at night if we have properly documented specs/requirements that the agents have developed against so we can fall back on that. Mixed results so far.

The goal is to make it replayable. If an agent produced something important, I want to know how it got there. I haven’t figured out how to do this at scale without it feeling like homework, so I’m still looking for a better way. The other obvious one is the traditional TDD (Test Driven Development) way, which if done correctly will also have all the intent up front, this though is difficult if your teams or engineers are not used to doing full proper TDD, as it is a mindset change.

There is also various spec driven development techniques that people and teams are trying out and coding agents are starting to incorporate, but I have not landed on the one true way yet.

I really liked the “step behind the bleeding edge” framing from Monarch Money. You explore the frontier so you understand what is coming, but you adopt it deliberately when you can wrap it in a process you can actually evidence.

Monday morning

I’m still figuring out the balance. Some days I’m convinced I’m right about this, I feel sure about intent lock-in and the need for durable ownership. Other days I watch a demo of the latest model and wonder if I’m just overthinking it. Maybe the tools just get better and the problem solves itself?

Probably not, though.

Regulation isn’t going away. Neither are incidents, audit questions, or the slow grind of maintaining systems that handle real money and real risk. The tools are getting better faster than our instincts can keep up.

The job is making sure intent keeps pace. When we approve a PR, we shouldn’t just be approving a diff. We are approving a system we’ll be willing to own later.

That’s the bit I can’t stop thinking about. At least, that’s the best frame I have for it right now.

Books I Read in 2025

Sun, 04 Jan 2026 09:12:00 +0000

I didn’t really keep notes while I was reading these. This is basically me looking back and going, “oh yeah… that one”, and trying to remember what actually stuck, I have also missed a few others, which I will update if I get the time.

Not a massively curated list, but there’s a theme (as usual): health, habits, money, tech, and why things work the way they do.

Exercised: The Science of Physical Activity, Rest and Health - Daniel Lieberman

Not a fitness book in the usual “here’s your plan” sense. It’s more about why humans move at all, and how “exercise” as we think about it is a pretty modern concept.

It made exercise feel less loaded. Movement matters, but it doesn’t have to look a certain way to count. I didn’t suddenly become a new person, but it did quietly reset how I think about being active.

Burn - Herman Pontzer

Probably my favourite thing I read this year. It explains metabolism in a way that actually makes sense, without turning into a diet plan or trying to sell you a system.

The main idea (as I understood it anyway) is that the body adapts more than we assume. You don’t just keep burning more and more calories forever by exercising more. Once that clicks, a lot of the usual health advice suddenly looks a bit wonky.

Atomic Habits - James Clear

I nearly skipped this because I’m pretty tired of productivity books, but I’m glad I didn’t. It’s straightforward and practical without being preachy.

The focus on small changes and just making the “good” thing easier than the “bad” thing felt realistic. I didn’t overhaul my life (thankfully). It mainly made me notice what I’m already doing on autopilot.

Same as Ever - Morgan Housel

This one was just enjoyable. Short chapters that are easy to dip in and out of and nothing too heavy.

The point is basically that while the world changes constantly, people don’t (at least not in the ways that matter). Fear, optimism, bad incentives, overconfidence all of that has been around forever. I found it oddly calming, especially with how noisy everything else feels.

Enshittification: Why Everything Suddenly Got Worse and What To Do About It - Corey Doctorow

This is a book from an Essay Corey Doctorow, it put a name to something I’ve been noticing for years. Platforms start out useful, then slowly get worse as incentives shift away from users.

It’s not exactly cheerful, but it is clarifying. Once you’ve seen the pattern properly, it’s hard not to notice it everywhere.

Project Hail Mary (audiobook, re-listen?)

I read this a few years ago and loved it, almost as much as The Martian. I didn’t enjoy Artemis nearly as much, but Project Hail Mary felt like a proper return to form.

This year I came back to it as an audiobook after hearing how good the narration was, and yeah, it’s excellent. It also turned into a bit of a bonding thing with my son, we listened together in the evenings, a chapter or two at a time, and he was completely hooked. Seeing him get pulled into it made me enjoy it even more the second time around.

That’s the lot. If you’ve read anything similar (or think I’ve missed something obvious), send it my way.

Reviving a 9-year-old Dell Latitude with Linux Mint

Sat, 03 Jan 2026 10:05:00 +0000

A couple of months ago I nearly replaced my personal laptop.

My daily driver is a 9-year-old Dell Latitude 7280. On paper the hardware is fine, but running Windows 10 it felt dead. The fans were constantly spinning, the system was sluggish, and the battery life had dropped to a useless 30 minutes.

Since the machine is too old for the official Windows 11 upgrade path, it was effectively living on borrowed time.

I’ve been using macOS for work for the last five years because Apple Silicon is hard to beat, but I like the idea of being a “tech polyglot” and not relying on a single ecosystem. I wanted to see if I could salvage the Dell.

Linux Mint is frequently recommended as the “just works” distro for older hardware, so I wiped the drive and installed it.

The Adblocker Effect

I’ve been running this setup for two months now, and so far it has been “boring”, which is a compliment. Nothing flashy, no ads in the menus, quick to use. Just what I want out of my machine, it feels like I own it too.

My favorite description of the experience of using Windows lately feels like browsing the web without an adblocker. It’s noisy, distracting, constantly trying to sell you things and just feels like everything is disjointed and slow.

Linux Mint so far for me is the complete opposite. It’s quiet, it doesn’t try to be clever, and it stays out of the way.

The hardware results were immediate:

Silence: The fans used to wheeze constantly, but they almost never spin up now.
Battery: I’m getting nearly two hours of usage, up from 30 minutes. The laptop is actually portable again.
Drivers: This was my biggest worry, but everything (Wi-Fi, sound, display) worked out of the box.

The Workflow

I’m keeping my setup simple with mostly Firefox and VS Code.

I’ve been spending a lot of time building small tools with LLMs recently, like this family planner app I hacked together. For that workflow, a lightweight Linux environment is perfect. It feels closer to the metal than my Mac without the overhead of Windows.

My Mint setup

These are the highlights of the machine and install I’m writing this post on:

Laptop: Dell Latitude 7280
OS / DE: Linux Mint 22.2 “Zara” (Ubuntu 24.04 base), Cinnamon 6.4.8 (X11)
Kernel: 6.14.0-37-generic
CPU / RAM: Intel i7-7600U (2C/4T), 16GB RAM
Display: 1920×1080
Storage: 512GB SanDisk X400 (ext4 root)
Battery health: ~37.6% of original capacity remaining (about 22.5Wh now vs 60Wh design)

If you want to grab similar details on your own Linux box, this is the one-liner I used:

`1`	`inxi -Fxz`

Office apps (and the “real-life” test)

I installed two office suites (and LibreOffice comes pre‑installed with Mint):

LibreOffice (Writer, Calc, Impress) — https://www.libreoffice.org/
ONLYOFFICE Desktop Editors — https://www.onlyoffice.com/

UI-wise, ONLYOFFICE feels closest to Microsoft Office, especially the ribbon layout and overall visual structure. LibreOffice is still the default workhorse and feels a little more “classic Linux,” but it’s rock-solid.

The best part: I got my wife to edit a document and print what she needed with zero hassle. That’s a big win on an older laptop.

I haven’t tried these yet, but they’re on my radar: WPS Office, SoftMaker Office, FreeOffice, Calligra Suite, and Apache OpenOffice.

I also haven’t had to do complex spreadsheets with macros or heavy Excel‑specific workflows. That might be a bigger issue for people who depend on those features.

Next steps: The Dual-Boot Experiment

Because this went so well, I’m planning to dual-boot the slightly newer Windows 11 laptop my son uses.

The stakes are higher there because his school relies on Microsoft Teams and Office, plus he spends a lot of time in Roblox.

I recently discovered Sober, a Flatpak wrapper for the Android version of Roblox. I’ve tested it on my Mint machine and it runs surprisingly well, which solves the biggest blocker for him.

There is a philosophy aspect to this too. Watching my son’s generation use computers, I’ve noticed they treat them purely as appliances or black boxes that run apps.

I know I praised Mint for “staying out of the way,” but for him I think a little friction might be healthy. If he has to drop into a terminal to fix a sound setting or tweak a config file, that’s a win. It teaches that the computer is something you can poke, prod, and change rather than a sealed unit you replace when it gets slow.

The Day Our Container App Ghosted Application Insights

Fri, 02 Jan 2026 13:49:27 +0000

We moved an API from Azure Functions to Azure Container Apps and expected logging to “just work.” Instead, AppTraces stayed empty while ContainerAppConsoleLogs_CL filled up. This is the story of how a custom logger quietly bypassed Application Insights, how we proved the platform still worked, and what we changed to fix it.

Note: I’ve intentionally omitted/substituted any subscription IDs, resource names, and internal identifiers. Code snippets are illustrative.

TL;DR

If your app only writes to stdout/stderr, Azure Container Apps will show logs in ContainerAppConsoleLogs_CL, but Application Insights won’t magically populate AppTraces.
Our custom logging abstraction was writing directly to stdout/stderr in Container Apps, bypassing the ILogger → Application Insights pipeline.
Fix: route logs through ILogger and/or TelemetryClient, ensure the telemetry channel can persist in the container, and flush on shutdown.

The Setup: Functions vs Container Apps

In the old world, the API ran as Azure Functions:

Application Insights was wired through the standard Functions host.
Our custom logging abstraction sat on top of the platform logger, and everything showed up in AppTraces as expected.

When we lifted the same workload into Azure Container Apps, we assumed:

Reusing the same logging abstraction would be fine.
Adding the Application Insights SDK “like the docs say” would be enough: connection string in configuration, AddApplicationInsightsTelemetry, and some health-check logging around startup.

On paper, everything looked correct. In practice, AppTraces stayed completely silent.

What We Tried (Before Finding the Real Issue)

Once we noticed that traces were missing from AppTraces, we did the usual checklist:

Environment parity: Confirmed the Application Insights resource and Log Analytics workspace were the same ones we used in Functions.
Configuration: Double-checked the connection string, instrumentation key, and diagnostic settings.
SDK wiring: Added the Application Insights ASP.NET Core SDK into the container app:
- AddApplicationInsightsTelemetry in Program.cs.
- Ensured the connection string came from environment variables, not hard-coded config.
- Registered the Application Insights logging provider.
KQL sanity checks: Queried both AppTraces and ContainerAppConsoleLogs_CL by timestamp and correlation IDs, just in case this was a query bug.

The result:

Logs happily appeared in ContainerAppConsoleLogs_CL.
AppTraces kept pretending we didn’t exist.

At this point, we had followed the documentation, the SDK was loaded, but Application Insights still wasn’t seeing our application logs.

The Support Detour

We raised a support ticket, assuming there might be a known limitation or a misconfiguration on the platform side.

The response boiled down to:

Container Apps write console output into ContainerAppConsoleLogs_CL.
The AppTraces table is driven by the Application Insights ingestion pipeline.
You can’t “redirect” console logs into AppTraces; the suggested approach was to query both tables in a single KQL query.

In other words: “This is a product limitation, you can’t get what you want.”

The problem was that this answer didn’t line up with:

The official docs that show Container Apps + Application Insights working end-to-end.
Our own experience with Functions where the same code happily wrote to AppTraces.

So instead of accepting “not supported” as the final word, we treated it as a clue: if console logs were going only to ContainerAppConsoleLogs_CL, maybe our custom logger was never actually talking to Application Insights at all.

Why This Really Mattered

Telling ourselves “we’ll just query two tables” would have been the easy answer, but it would have hurt us everywhere else:

Shared KQL patterns: We already had a lot of KQL built around AppTraces for other workloads. Copy-pasting those queries and bolting on extra unions for a single service would make them longer and harder to reason about.
Alerts: Many of our alerts were driven by fairly complex queries over AppTraces. Doubling every query to union in ContainerAppConsoleLogs_CL would make them even more convoluted and fragile.
Dashboards and metrics: Existing dashboards were all wired to AppTraces as the central source of truth. Splitting one service’s logs across tables would mean either:
- Special-casing that service everywhere, or
- Rewriting dashboards to union across tables for all services, even those that didn’t need it.

We wanted:

A single, consistent telemetry story: “if it’s an application trace, it lives in AppTraces.”
To avoid polluting every query and alert with table-awareness for one misbehaving service.

In short, fixing the pipeline at the source was far cheaper than living with permanently more complex KQL.

What Actually Went Wrong

The real issue turned out to be our own abstraction, not the platform.

We got there in two parallel ways:

A developer was manually tracing the flow of a request, checking where logging calls originated and which services were registered in dependency injection.
In parallel, we asked an AI coding assistant to analyse the codebase and the problem description. With the broader context of “AppTraces is empty but console logs exist,” it quickly flagged one suspicious area: a custom logging service that wrote directly to stdout/stderr.

Looking more closely at that code, the pattern became obvious:

We had a custom logging service that wrapped the platform logger.
In the Functions world, this wrapper ultimately still called ILogger, which the host wired to Application Insights.
In Container Apps, we reused the same abstraction but changed the implementation to write directly to stdout/stderr.

That subtle change meant:

Logs still “worked” in the sense that they appeared in ContainerAppConsoleLogs_CL.
But they completely bypassed the ILogger → Application Insights pipeline.
So even though the SDK was installed and configured correctly, Application Insights never saw our logs, and AppTraces remained empty.

Once we viewed the system as “two independent pipelines” it made sense:

Console pipeline: stdout/stderr → ContainerAppConsoleLogs_CL.
App Insights pipeline: ILogger / TelemetryClient → AppTraces (and other AI tables).

Our custom logger had effectively unplugged itself from the second pipeline, and the coding agent helped us see that faster than we probably would have on our own.

The Fix

We kept the custom logging abstraction but made it Application Insights–aware and ensured the SDK could persist telemetry inside a Linux container.

Send scopes to ILogger and TelemetryClient

Build a scoped property bag once, use logger.BeginScope(properties) for structured logs, and also push the same properties into TelemetryClient.Context.GlobalProperties for telemetry correlation.
Keep disposal safe: restore previous global properties and remove any extras you added.

public IDisposable BeginLogScope(ILogger logger, TelemetryClient telemetryClient)
{
    var properties = BuildLogProperties();

    var loggerScope = logger.BeginScope(properties);
    var telemetryScope = new TelemetryScope(telemetryClient, properties);

    return new CompositeDisposable(loggerScope, telemetryScope);
}

Wire Application Insights explicitly in Program.cs

Give the telemetry channel a writable folder (the default path isn’t writable in many container images).
Disable adaptive sampling if you need deterministic logging while debugging.
Register flush on shutdown so buffered telemetry reaches AppTraces before the container stops.

var cachePath = Path.Combine(Path.GetTempPath(), "appinsights-cache");
Directory.CreateDirectory(cachePath);
services.AddSingleton<ITelemetryChannel>(_ => new ServerTelemetryChannel { StorageFolder = cachePath });

services.AddApplicationInsightsTelemetry(opts =>
{
    opts.ConnectionString = Environment.GetEnvironmentVariable("APPLICATIONINSIGHTS_CONNECTION_STRING");
    opts.EnableAdaptiveSampling = false;
    opts.EnableDependencyTrackingTelemetryModule = true;
});

services.AddLogging(b => b.AddApplicationInsights());

app.Lifetime.ApplicationStopping.Register(() =>
{
    telemetryClient.Flush();
    telemetryChannel?.Flush();
    Thread.Sleep(TimeSpan.FromSeconds(5));
});

Turn on SDK diagnostics while debugging
- Setting APPLICATIONINSIGHTS_DIAGNOSTICS_LOG_LEVEL=Verbose made it obvious that nothing was reaching the ingestion pipeline until the TelemetryClient hookup was added.

Bonus: Improvements We Would Have Missed

The coding agent didn’t just find the custom logger problem; it also highlighted a few things we hadn’t fully appreciated:

Telemetry channel storage in Linux containers: The default ServerTelemetryChannel uses on-disk storage. In many Linux container images, the default path isn’t writable, so the channel quietly disables persistence. Explicitly providing a writable StorageFolder keeps buffering working instead of silently failing.
Flushing on shutdown: Without a call to telemetryClient.Flush() (and a brief wait) in an ApplicationStopping handler, short-lived containers can exit before telemetry is sent. Adding an explicit flush ensures traces actually leave the container.
Dependency tracking for correlation: Disabling modules like DependencyTrackingTelemetryModule stops HTTP client spans from reaching Application Insights. That means you lose end-to-end correlation between requests, dependencies, and traces in AppTraces/AppRequests. Re-enabling dependency tracking restored that visibility.

Those suggestions improved more than just this one service—they were a useful checklist for other containerised workloads using Application Insights.

Proof It Worked

Once the custom logger was integrated with both ILogger and TelemetryClient, things changed immediately:

The same log messages appeared in both ContainerAppConsoleLogs_CL and AppTraces.
KQL queries like AppTraces | where Message contains "<sample text>" started returning results.
End-to-end correlation across HTTP requests, dependencies, and custom traces started behaving the way the docs promised.

At that point, we had a clear picture:

The platform did support Application Insights in Container Apps.
Our own custom logger had been bypassing the pipeline the whole time.

Takeaways for Container Apps + App Insights

Console output alone won’t light up AppTraces; you need the Application Insights logger provider or TelemetryClient in the path.
Custom logging abstractions should decorate, not replace, the platform logger. If your abstraction writes straight to stdout/stderr, Application Insights will never see it.
In containers, configure a writable telemetry channel and flush on shutdown so you don’t lose buffered telemetry when the container stops.
When support says “not supported,” it might mean “not supported the way you’re currently doing it.” A minimal repro with the SDK and a very simple logger is often the fastest way to prove (or disprove) that.

If you’re migrating from Functions to Container Apps and AppTraces is silent, start by looking for any custom logger that skips ILogger/TelemetryClient. Plug it into the App Insights pipeline, give the channel somewhere to write, flush on exit, and your traces should come back to life.

I Built a Family Planner We Actually Use (and It Costs £0/month)

Wed, 31 Dec 2025 12:00:00 +0000

Disclaimer: LLM Agents wrote the code and the bugs. The ideas and most of the wording in this blog series are mine, but edited by LLMs because I am an engineer, not a copywriter. I’ve reviewed it to ensure it sounds like me, but if you spot weird phrasing, blame the robot.

Over the Christmas break I built a simple weekly family planner for my partner, my son, and me.

I wanted to solve for the basics that kept slipping: PE kit, clubs, bin day changes, “what are we doing next Saturday?”, and the scavenger hunt through calendars, WhatsApp threads, and school emails.

Family life is a messy distributed system that doesn’t accept incident tickets.

What it does

It’s a mobile-first weekly view you can scan quickly:

what’s on this week
what’s coming up soon
quick ways to add things without filling in a form

My goal wassn’t “perfect scheduling”, but just to reduce the mental load: if someone asks “what’s on this week?”, the answer becomes “check the planner”.

The whole point: a week you can understand in ten seconds.

Iteration with users was what got it useful

I built the first version for me, and it worked, but then I handed it to my family and watched them use it.

They didn’t care about my neat architecture or costs,they wanted it fast, reliable and easy to use, not another chore to do:

if adding something takes more than a few seconds, it won’t happen
if it feels like you can “break it”, people won’t explore
the best features are usually the ones that remove friction, not the ones that add power

That feedback loop shaped the app better than I came up with on first iterations.

How I used LLM agents (without making a mess)

I did use LLM agents heavily, but not as “magic autopilot”.

My workflow was more like:

write the rules first (data shape, safety constraints, “what we will not do”)
treat the agent like a very fast junior developer (literal, eager, needs guardrails)
ship small changes and actually review them
test with real people, then iterate

The “rules first” piece matters. It’s the difference between “fast” and “fast, but you still own it afterwards”.

If you’re curious about this approach, AGENTS.md is the general idea: https://agents.md/

£0/month purposefully

I wanted something we owned, without a subscription, and without handing our family schedule to a random SaaS vendor.

This runs on Cloudflare’s free tier (for a small household, the numbers are tiny):

Cloudflare Pages: https://pages.cloudflare.com/
Cloudflare Workers: https://workers.cloudflare.com/

Want the technical version?

I wrote the full technical series separately so this post could stay readable. If you do want the deeper dive:

Part 1 (WeekDoc rule + foundations): https://michaeldugmore.com/p/family-planner-vibe-coding-rules-and-weekdoc/
Part 2 (mobile UX + practice): https://michaeldugmore.com/p/family-planner-vibe-coding-ux-and-practice/
Part 3 (integrations + notifications): https://michaeldugmore.com/p/family-planner-vibe-coding-integrations-and-notifications/
Part 4 (universal add + safety nets): https://michaeldugmore.com/p/family-planner-vibe-coding-universal-add-and-safety-nets/

References

OpenAI Codex: https://openai.com/codex/
Google Gemini Flash Lite (used purely as a parser): https://deepmind.google/models/gemini/flash-lite/

Part 4: Fast Capture: Universal Add and the "Trust Layer"

Wed, 31 Dec 2025 11:10:00 +0000

Disclaimer: LLM Agents wrote the code and the bugs. The ideas and most of the wording in this blog series are mine, but edited by LLMs because I am an engineer, not a copywriter. I’ve reviewed it to ensure it sounds like me, but if you spot weird phrasing, blame the robot.

Prefer the short version? Start here: I Built a Family Planner We Actually Use (and It Costs £0/month)

The planner is at its best when you can capture something in three seconds.

You’re in the kitchen, you remember “Parents’ Evening next Thursday”, and you need to get it out of your head. You do not want to open a calendar, select a date, scroll to a time, and fill out a form.

I wanted a “Universal Add” button. One text box. Type whatever and let the machine figure it out.

This introduces risk. If you let an LLM write directly to your database based on a vague user prompt, you invite data corruption.

This is how I built a smart input with a paranoid “Trust Layer”.

The Architecture of Universal Add

The flow is strict:

User Input: “Gym at 6pm on Tuesday”.
Parser (Gemini Flash): Converts text to a JSON payload.
The Review: The UI shows you what it thinks you meant.
Confirmation: You click “Save”.

Nothing gets saved without a human confirmation.

Capture first. Sort out details next.

I use Google Gemini Flash Lite (via Cloudflare Pages Functions) as a parser. I don’t use it as a chatbot or an agent. It has a single job: take string, return JSON.

AI Output is Untrusted Input

In functions/api/universal-add/parse.ts, I treat the response from Gemini like I would treat a user input from the public internet: with extreme suspicion.

It passes through strict validation logic. Does the date exist? Is the ISO format correct? If the LLM hallucinates a 13th month or a time of “25:00”, the API throws an error. The browser never sees the API keys; the server handles the handshake.

This costs nothing because the volume for a family app is within free tier limits, but the safeguards make it reliable.

Backups

When a side project contains your actual life schedule, “it’s just a KV store” stops being funny.

I built a blunt, heavy-handed backup system.

The Export dumps the entire KV namespace to a JSON file. The Import restores from JSON but defaults to safe-mode (no overwrites).

If you want to overwrite existing data you have to toggle a switch and confirm it. A backup you haven’t restored is just a wish, so I tested the restore flow before I let the family start adding real data.

Download a snapshot, import it back with explicit overwrite protection.

The “Admin” Gate

To prevent unauthorized access or accidental restores, the backup API checks the Cloudflare Access email header against an allowlist in functions/_lib/backupAuth.ts.

It’s a simple check that prevents accidental history rewrites.

Ownership

This project cost me £0 in hosting. It uses “AI”, but not in a way that takes control away from me.

I used the Agents to write the boilerplate, the parsers, and the React components. But I kept the “Senior Engineer” hat on. I defined the data model (AGENTS.md), I set the safety rules, and I determined the architecture.

The result is a tool that feels incredibly personal because it fits our life exactly. And because I own the code, it will grow as we do.

If you’re thinking of “vibe coding” an app: Write your rules first. The AI is the engine, but you need to be the steering wheel.

References

Google Gemini Flash Lite: https://deepmind.google/models/gemini/flash-lite/
Cloudflare Pages: https://pages.cloudflare.com/
OpenAI Codex: https://openai.com/codex/
AGENTS.md: https://agents.md/

Part 3: The Stuff You Notice When It Breaks: Term Dates and Bin Days

Tue, 30 Dec 2025 10:40:00 +0000

Disclaimer: LLM Agents wrote the code and the bugs. The ideas and most of the wording in this blog series are mine, but edited by LLMs because I am an engineer, not a copywriter. I’ve reviewed it to ensure it sounds like me, but if you spot weird phrasing, blame the robot.

Prefer the short version? Start here: I Built a Family Planner We Actually Use (and It Costs £0/month)

Family data falls into two categories.

Internal: “Dinner at Grandma’s”. We control this.
External: “Inset Day” or “Recycling Collection”. We do not control this, it changes without warning, and forgetting it causes chaos.

I wanted the planner to handle the second kind. This meant writing integrations.

In a professional context I’d look for an enterprise API with an SLA. In the context of my local council and school I’m looking at messy HTML and obscure JSON endpoints.

This is how I used Cloudflare Workers to ingest annoying schedules without polluting my clean database.

The “Overlay” Strategy

I stood firm on my data rule: External data never touches the WeekDoc.

If I merged school dates into our primary weekly JSON, a scraper bug could corrupt our personal schedule. Instead, Term Dates and Bin Collections are stored as separate KV documents. The UI renders them as visual overlays.

If the school website changes its layout and my scraper fails, the overlay disappears, but our family calendar remains intact. This is standard defensive coding.

Scraping School Dates

Schools generally provide PDF links or HTML tables rather than APIs.

I wrote a refresher script (src/shared/schoolDatesRefresh.ts) that uses HTMLRewriter to scrape the term dates. This code is brittle and boring to write.

I let the Agent write it. I gave it the HTML structure and instructed it to extract the dates, normalize them to ISO strings, and hash the result.

Term dates as data, not a link you have to remember.

If the hash hasn’t changed we don’t write to KV. This keeps the “Last Updated” timestamp meaningful. We assume the scrape is hostile; if the data doesn’t validate strictly, we discard it.

Bin Collections

I prepared to scrape the council website but found a hidden backend API. It requires a UPRN (property identifier) which I injected via environment variables.

This runs on a scheduled Worker. It fetches the data, normalizes it, and stores it in its own KV key. The UI checks for a bin overlay for the current week and renders it.

Push Notifications

I originally avoided Push because it feels intrusive. After missing an event because I didn’t look at the phone, I changed my mind.

The architecture is simple. A Service Worker handles the incoming push. A Dispatcher Worker runs on a cron trigger every minute. We track sent message IDs in KV to ensure we don’t spam the family if the worker retries.

Enable/disable/test push per device. No hidden magic.

This is the only part of the app that feels like traditional infrastructure.

This is unglamorous plumbing, but it is necessary. It is also where LLM Agents excel. I can paste a curled HTML response into the chat and ask for a robust parser using Zod. The Agent handles the regex, and I handle the architecture that ensures a bad regex doesn’t bring down the app.

Next: Part 4: Fast Capture: Universal Add and the “Trust Layer”

Part 2: Making It Stick: Mobile UX and Atomic Habits

Tue, 30 Dec 2025 10:20:00 +0000

Disclaimer: LLM Agents wrote the code and the bugs. The ideas and most of the wording in this blog series are mine, but edited by LLMs because I am an engineer, not a copywriter. I’ve reviewed it to ensure it sounds like me, but if you spot weird phrasing, blame the robot.

Prefer the short version? Start here: I Built a Family Planner We Actually Use (and It Costs £0/month)

I’ve built software for years and I still forget that I am not the user.

I built the first version of the planner for myself. It was functional and dense. Then I handed it to my partner and son.

They didn’t care about the architecture. They hesitated. They tapped things that weren’t buttons. I watched them struggle with the forms and realized that if adding an event takes more than five seconds, nobody will do it.

That session shifted the focus from displaying data to reducing friction.

Designing for One Thumb

Most usage happens in the kitchen, usually while holding a bag of shopping.

The original “Edit” modal was a standard form. This was too slow. We moved to Inline Add. You tap a day, type “Pizza”, and hit enter. Complex forms stop people from using the tool.

Inline add keeps event creation quick.

I also built a Read-Only view so I could check the schedule without fear of dragging an event into the trash while scrolling. This makes the app feel safe when you aren’t trying to change anything.

Read-only mode is often the difference between “interesting” and “used”.

The Practice Tab (Atomic Habits)

Once the planner was sticky I wanted to tackle a secondary goal: habits.

I finally read Atomic Habits by James Clear this year. The core concept resonated with me: you don’t rise to the level of your goals, you fall to the level of your systems. Small, repeated actions matter more than heroic bursts of effort.

I wanted to incorporate that into family life without the annoyance. I dislike the “streak” gamification found in most apps because it inevitably leads to guilt.

I built a “Practice” tab with specific constraints in a nested AGENTS.md:

No streaks
No failure states
Just dots

It tracks sessions. If you practice, you get a dot. If you don’t, nothing happens.

A family-wide view: days practiced per person, per skill, this week.

One-tap logging, optional details.

Technically this uses a separate KV document (practice:v1) to avoid polluting the WeekDoc. This architectural choice keeps the habit data independent from the calendar data.

The “Phone PR” Workflow

This phase of development was less about architecture and more about rapid iteration.

I used the “phone workflow” heavily. I’d spot a friction point during breakfast, open a PR via Codex Web on my phone, review the diff, and merge it. Cloudflare deployed it before I finished my coffee.

This is where the “vibe coding” approach works best. Fixing a small CSS padding issue or a confusing button label shouldn’t require opening a laptop.

The app only started working when I stopped designing for an engineer and started designing for a family. Inline Add removes the admin friction, and the Practice tab provides a gentle nudge without the guilt trip.

Next: Part 3: The Stuff You Notice When It Breaks: Term Dates and Bin Days

Part 1: I Vibe-Coded a Family Planner (Because Family Life Doesn't Accept Incident Tickets) all for £0

Mon, 29 Dec 2025 10:00:00 +0000

Disclaimer: LLM Agents wrote the code and the bugs. The ideas and most of the wording in this blog series are mine, but edited by LLMs because I am an engineer, not a copywriter. I’ve reviewed it to ensure it sounds like me, but if you spot weird phrasing, blame the robot.

Prefer the short version? Start here: I Built a Family Planner We Actually Use (and It Costs £0/month)

My brain can hold an entire backlog grooming session, the moving parts of a Cloudflare deployment, and six “good ideas” I’ll never ship. But it cannot reliably remember whether it’s PE kit day, whose turn it is to take the bins out, or what we said we were doing next Saturday.

Family life is a messy distributed system that I hope to try and tame a little anyway I can.

Over the Christmas break I built a mobile-first weekly planner for my partner, my son, and me. The goal was to put the stuff we keep forgetting in one place, in a shape that matches how we actually talk about a week.

I set two constraints. It had to cost £0 (running on Cloudflare’s free tier) and I wanted to “vibe code” it using LLM agents. As an Engineering Lead, I know that “fast” usually means “unmaintainable mess” unless you set the rules first.

This is the stack, the “WeekDoc” rule, and how I forced an LLM to write code I actually wanted to own.

A weekly dashboard you can understand in ten seconds.

The “Boring” Stack

There are plenty of existing apps for this. Most come with a subscription, a data model I can’t control, and a roadmap I can’t influence.

I wanted full ownership for zero pence. The architecture is:

Frontend: React + Vite + TypeScript
API: Cloudflare Pages Functions
Storage: Cloudflare KV
Scheduled tasks: Cloudflare Workers (cron triggers)

It lives behind Cloudflare Zero Trust. Locally it works without it. In prod the backend picks up the user email from the access headers.

The WeekDoc Rule: One Document - easy to understand and less complexity

The biggest risk with AI-assisted coding is complexity creep. Agents love to glue new database tables onto the side, creating synchronization issues.

To prevent this I wrote the project “Constitution” before writing any code. It lives in AGENTS.md at the root of the repo.

The core law is the WeekDoc Rule:

The app edits one full JSON document per week. It saves via a full replacement PUT.

One week equals one key in KV (week:2025-W01).

This isn’t the most scalable database design, but it is the right one for a family of three. The enemy here is complexity, not throughput. Treating the week as a single document eliminates partial update bugs entirely. We read the week, edit it in memory, and save the whole thing.

Managing the AI

“Vibe coding” often ends up being a mess of pasted code.

I treated the AI Agents (Codex/Cursor) like a really fast, Junior Engineer. My job was to write the specs and the guardrails, not the implementation details.

Rules first. AGENTS.md defines the data structure and the optimistic concurrency (version numbers) required to prevent overwrite conflicts.
Code review. The AI implemented the types and the API, but I reviewed every PR.
Architecture enforcement. If the AI tried to introduce a new state library, I pointed it back to the design docs.

This separation of concerns allowed us to move fast while keeping the codebase structure clean.

The Result

The repo is public here: github.com/mdugmore/family-planner-public.

One note: that public repo has no meaningful commit history. My original private repo’s history contained some personal > data, so I made a clean public version instead. My plan is to converge the private and public repos over time so it becomes a truly open-source project and new enhancements can land publicly.

When someone asks “what’s on this week?”, the answer is “check the planner”. The mental load is gone and the hosting bill is £0.

Archive is explicit, with a small carry-over chooser.

Events plus optional overlays (school + bins).

Next: Part 2: Making It Stick: Mobile UX and Atomic Habits.

References

Cloudflare Workers: https://workers.cloudflare.com/
Cloudflare Pages: https://pages.cloudflare.com/
OpenAI Codex: https://openai.com/codex/
AGENTS.md: https://agents.md/

Vendor Lock-in, AI Freedom, and an Engineering Lead's Mixed Emotions

Mon, 05 May 2025 17:10:07 +0100

Note: This post was a braindump of ideas, then refined a little using LLM’s, but have tried to minimise its the use as we all see way too much AI slop on the web now. I just to made it a little more coherent than my braindump.

From Autocomplete to Autonomous Agents: My AI Journey

I’ve been experimenting with AI since the GPT-2 days, playing with early versions that felt like slightly smarter autocomplete tools, and lately diving deep into full-blown coding agents that build entire solutions from simple specs. It’s been both fascinating and unsettling.

Redefining the Developer’s Role

Watching an agent read a short description and then quickly churn out functional code, often within minutes, leaves me simultaneously amazed and slightly horrified. Immediately, my mind asks, "What's been the point of my last 20 years of coding?" It feels somewhat existential. But then again, maybe I comfort myself with thoughts of the past: when IDE autocomplete came about, plenty of developers saw it as cheating, worried it would dull our coding skills. Or think about the rise of low-code and no-code solutions. Great for simple tasks, sure, but that tricky 20% of customisation still takes up 90% of the headaches. Maybe these AI coding agents are on a similar trajectory.

Today, these agents still get stuck and need human engineers with experience and good system design intuition to nudge them along, much like mentoring junior developers, albeit ones who learn incredibly fast. But it’s clear they’re rapidly improving, and the line between junior dev (and to be honest mid to senior devs in certain domains) and agent is getting increasingly blurred.

Rethinking Vendors & Outsourcing: AI as the New Development Partner

What really intrigues me is what this means for the wider tech industry, especially in sectors reliant on big, expensive SaaS providers. Imagine, for instance, a bank (which I know a thing or two about) using costly vendors for compliance or KYC solutions. Typically, these systems are generic and built for broad markets, forcing banks to adapt their processes to the software. Integration becomes a hassle, costly and time-consuming. Now imagine cutting out that vendor, building something tailored directly to the bank’s needs using an AI agent. Integration suddenly becomes the easier part, and the business gets control over its solution roadmap. Sure, you’ll still need domain expertise, but guess what? AI’s ability to deep-dive into research could bridge that gap too. Of course, while AI can research regulations, the critical judgment and ultimate accountability for applying that knowledge correctly, especially in tightly regulated areas like finance, still has to rest firmly with experienced humans.

I’m also thinking about the outsourcing industry. In my experience, if your specs aren’t rock-solid, outsourcing can quickly turn into a frustrating, drawn-out ordeal. Interestingly, the same applies to working with AI agents: vague requirements mean poor outcomes. But here’s the thing: if you’re going to spend all that effort writing impeccable specs, why not feed them to an AI agent instead of negotiating contracts with an outsourcing firm? Could this mean the end of traditional software outsourcing? Mind you, ensuring the AI truly understood the nuances, or figuring out how to handle maintenance when the underlying AI model itself evolves, definitely presents a whole new set of hurdles to replace the old ones. (But I will hand wave that away for now as I don’t have the answers)

But before panic sets in, let’s step back a moment. Is this really a doomsday scenario for software developers, or could it actually be more like the internet boom of the late 90s, full of opportunities for those who adapt? Certainly, if you’re not keeping pace with these new developments, things look bleak. But, let’s face it, keeping up is exhausting. Perhaps adaptation for experienced devs means shifting focus even more towards the things AI doesn’t easily replicate: robust architecture, insightful system design, rigorous validation, mastering the art of guiding the AI (prompt engineering, if you like), and providing that crucial human-in-the-loop oversight. Maybe the best we can do right now is leverage AI tools to stay ahead, at least temporarily.

Empowering Non-Engineers: The Rise of Citizen Developers

One thing that genuinely excites me is seeing non-engineers build things with tools like Replit or Lovable. Watching their ideas quickly come to life gives them the same spark of joy that initially drew me into programming, without the barrier of years of coding experience. This might feel threatening initially, “Are they taking our jobs?”, but actually, these fresh minds often bring completely new perspectives and ideas that can birth entirely new businesses overnight. And new businesses mean new opportunities, especially for integration, support, and infrastructure.

“Touch Grass”

Local Village Mayfayre

This weekend, while walking around a local village market, I found myself surrounded by stalls selling food, crafts, beer, with kids running around playing cricket and a band playing. People were interacting naturally, and the pace felt refreshingly slower. Not a single conversation touched on AI (and don’t worry, I didn’t bring it up either). Being at this village market made me realise how much my head has been spinning recently with AI, coding, and researching stuff online. It was nice just slowing down a bit, being around real things and chatting to actual people about everyday stuff. It reminded me how important it is to step away, slow down, and, as my son likes to say, "touch grass" now and then. Staying connected to your local community and chatting with people face-to-face matters. If AI really does end up taking over a lot of stuff, at least we're all in the same boat, and looking after each other becomes even more important.

Challenges and Opportunities Ahead

Ultimately, I’m conflicted, but mostly excited. Having ridden the rollercoaster of AI hype for several years now, I sense we’re hitting a maturity plateau, where these tools become genuinely useful, integrated into our workflows rather than replacing them completely. Of course, another explosive breakthrough could be just around the corner. But even if there isn’t, one thing is clear: AI isn’t going away. Our challenge, and opportunity, lies in figuring out how best to adapt.

I can talk for hours about this topic, but tried to keep it relatively focused and I would like to expand on how this is affecting non developers too. I will try keep putting my thoughts out there as I get some time and I am not either vibe coding, or “Touching Grass”

The Long Ride: Designing Robust Systems Like a Bike Packer on King Alfred's Way

Sat, 26 Apr 2025 10:00:00 +0100

There’s a unique satisfaction that comes from loading up your bike with everything you need and setting off into the unknown. A few years ago, some friends and I got hooked on the idea of gravel cycling – exploring bridleways, forest tracks, and quiet lanes away from the traffic. We perhaps dreamt of dusty, sun-baked American-style gravel roads, but quickly discovered the UK reality often involves… well, a lot more mud. Glorious, character-building mud!

This experience, especially tackling longer multi-day routes, highlighted stark parallels with my day job as a Lead Engineer in banking: designing and building robust software systems, often leveraging cloud platforms like Azure. The challenges might seem worlds apart – navigating a muddy bridleway versus deploying critical payment code – but the underlying principles of preparation, resilience, and adaptability are remarkably similar. Thinking like a bike packer, especially one planning for the unpredictable British weather, can make us better system designers.

One route that crystallised this for me was the King Alfred’s Way

King Alfred's Way Route Map

My Loaded bike at a stop at Stone Henge!!

Here’s how the planning and execution of a ride like that mirrors system design:

1. Planning the Route (King Alfred’s Way): Defining Requirements & Scope

Bike Packing (KAW): King Alfred’s Way is a stunning, roughly 350km (220-mile) circular route looping through the heart of historic Wessex. It connects Winchester, Salisbury, Stonehenge, Avebury, and Reading across varied terrain. Planning involves studying the map, estimating daily mileage, identifying resupply points, checking accommodation/camping options, and noting bail-out points. You define the objective, constraints, and key milestones.
System Design: This mirrors requirements gathering. What problem are we solving (“destination”)? Who are the users? What are the critical user journeys (“key sections”)? What are the non-functional requirements like performance, availability, security (“terrain challenges”)? What are the constraints (budget, team skills, existing infrastructure - “time, fitness, gear”)? Clear definition prevents building the wrong thing.

2. Choosing Your Gear: Selecting Technology & Components (Simplicity vs. Complexity)

Not actual packing list!

Bike Packing (KAW & UK Gravel): Gear choice for UK gravel is critical. Tyre choice is key for mud. Reliability matters – trustworthy brakes, solid drivetrain, waterproof bags. But there’s a trade-off: sometimes the fanciest gear is the hardest to fix in the field. Simple, robust components might be heavier but their field serviceability can be invaluable compared to complex parts requiring specialist tools. You choose gear appropriate for the actual conditions.
System Design: This maps to selecting your technology stack (languages, frameworks, databases, Azure components, APIs). Are they mature and reliable (“durable tyres”)? Do they scale? Are they cost-effective? Crucially, consider the complexity trade-off. Sometimes the latest pattern introduces significant overhead. A simpler, well-understood approach might be more robust and easier to debug under pressure. Choose tools and patterns appropriate for the real-world operational demands, including maintainability. Avoid unnecessary complexity just because you can.

3. Packing Smart: System Architecture & Organization (Choosing the Right Structure)

Bike Packing: How you load your bike affects handling. Heavy items low and central. Frequently needed items easily accessible. Protecting sensitive gear. It’s about organisation, balance, and quick access. Different packing systems exist (panniers, frame bags, large saddlebags) – each has pros and cons for weight distribution, capacity, and accessibility depending on the bike and trip length.
System Design: This is your system architecture – how you structure your code and components. Choosing the right architectural pattern is like choosing your packing system. A monolith might be simpler initially, like one large bag – everything’s together, but accessing or changing one part can affect the whole load. A more modular or distributed architecture (like using separate services or libraries) is akin to using multiple specialised bags – it allows for independent changes and deployments (“accessing one bag doesn’t require unpacking everything”) but requires more careful planning on how the pieces interact (“ensuring the bags fit and balance well”). The key is selecting an architecture (like modularity, separation of concerns, clear interfaces) that provides the right balance of maintainability (“easy access”), stability (“good balance”), and independent evolution for your specific needs and team.

4. Redundancy & Repair Kits: Fault Tolerance & Resilience (Decoupling & The Hanger Incident!)

Bike Packing: Things will go wrong. Punctures, loose bolts, broken chains. You carry a repair kit, know basic repairs, and have backup navigation. Crucially, you anticipate specific catastrophic failures. On our King Alfred’s Way trip, disaster struck. Hitting a deep, muddy rut, one friend’s derailleur hanger snapped. Without a spare, the ride is over. This would have been catastrophic… but it wasn’t. Anticipating this vulnerability, all of us carried spares, sourced preemptively (one even from China!). That small, redundant part saved the trip.
System Design: Systems fail. Networks glitch, servers crash, dependencies become unavailable. We design for failure. Cloud platforms like Azure provide built-in redundancy (e.g., Availability Zones are like multiple route options). We also build resilience through decoupling components. If one part of the system needs to communicate with another, using techniques like asynchronous processing or message queues means the sender can continue its work even if the receiver is temporarily down. The request waits patiently (“the snack in your bag”) until the downstream component recovers. This prevents failures in one area from cascading and taking down the entire system. Just like carrying that specific derailleur hanger, anticipating critical failure points and building in redundancy and decoupling (spare components, failover systems, queued/asynchronous processing) is fundamental, especially in high-stakes banking environments.

5. Navigating the Unknown: Monitoring, Observability & Adaptability

Bike Packing (KAW): Routes aren’t always perfectly marked, GPS signals drop, trails get diverted. You constantly check your position, monitor energy/supplies, watch the weather, and adapt. A muddy track might force a road detour. Slower progress might change your overnight stop. Situational awareness is key.
System Design: This is observability. Logging, metrics (e.g., via Azure Monitor), and tracing provide real-time understanding. Dashboards show health (“position/speed”), alerts notify of problems (“blocked trail”), logs/traces help diagnose issues (“why are we slow?”). Monitoring tells you if you’re “on course” (meeting SLOs) or need to adapt (scale resources, deploy a fix, investigate anomalies).

6. Pacing Yourself: Performance, Scalability & Sustainability

Bike Packing: KAW is a long route. You need a sustainable pace, managing energy, fuel, and rest to finish without burnout.
System Design: Systems need to perform under load and scale (Azure offers auto-scaling capabilities). This requires efficient design (algorithms, indexing, caching). It also means building sustainably – managing technical debt (“not carrying unnecessary weight”), writing clean code (“well-serviced bike”), ensuring the system can evolve. Build for the long haul.

The Journey is the Reward (Mud, Snapped Parts, and All)

Both bike packing King Alfred’s Way and designing complex software systems require meticulous planning blended with the ability to improvise when faced with the unexpected – a flooded trail, a snapped derailleur hanger, or a sudden spike in transaction volume. They demand understanding trade-offs (like simplicity vs. features, or monolithic vs. distributed architectures), a laser focus on reliability, and the foresight to prepare for specific failures through redundancy and decoupling.

So, the next time you’re deep in a system design discussion, perhaps picture yourself navigating those Wessex trails. Are you planning the route carefully? Choosing the right gear (balancing features and fixability)? Selecting the right architectural structure (“packing system”)? Carrying the right “spare parts” and building in decoupling for critical failures? Do you know how to navigate when things go off-plan? Are you setting a sustainable pace?

Thinking like a bike packer might just help you build stronger, more resilient systems ready for whatever the journey throws at them.

Some photos from our trip:

Surfing the AI Tsunami: My Pragmatic Plan to Stay Current (Without Drowning)

Mon, 21 Apr 2025 17:30:07 +0100

Okay, let’s have a real chat. Does anyone else feel like keeping up with AI developments is less “lifelong learning” and more like frantically treading water while a giant wave labelled “AI Everything, All The Time” looms over you? Seriously, blink and there’s a new model, a new framework, a new library, some breathless think piece declaring my entire skillset obsolete. It’s flat-out exhausting, and the FOMO is intense.

I know this cycle personally. I’ll see something shiny – maybe the latest paper on Retrieval-Augmented Generation (RAG) or a cool demo of autonomous AI Agents – and my brain instantly goes into overdrive. “Whoa, this could totally change how we handle X!” or “Imagine building Y with this!” Next thing I know, it’s 11 PM on a Tuesday, I’m elbow-deep in a half-baked quickstart, chasing cryptic errors, convinced this is the silver bullet.

The initial dopamine hit of “figuring it out” is great, but then the reality check hits hard. I try to move past “hello world,” and suddenly I’m wrestling with minimal docs, flaky examples, and tech that’s clearly still got sharp edges. My evenings and weekends evaporate into debugging sessions (sorry, family!), and often, the main takeaway isn’t a cool new feature, but the hard-won, slightly frustrating knowledge that maybe this particular shiny thing isn’t quite ready for prime time for my needs. It’s a cycle that leaves me feeling busy but not necessarily productive, just… drained.

This whole experience got me thinking: there has to be a more sustainable, less frantic way for working developers like us to engage with AI without burning out or constantly feeling like we’re falling behind.

This post is the first in a series where I want to share what I’m learning (and frankly, struggling with) as I try to navigate this AI landscape pragmatically. So, how are I trying to ride this wave without getting completely pummelled? Here are a few strategies I’m trying to stick to:

1. Focus Your Sips: You Can’t Drink the Ocean Anyway

Let’s just accept it: we cannot learn it all. The firehose of information is too much. Instead of chasing every single new announcement (a habit I’m actively trying to break!), I’m forcing myself to ask: “What actually helps me or my team build better software, fix real problems, or make my own workflow smoother right now or in the very near future?”

For me, right now, that means focusing on:

Getting Smarter with My AI Coding Buddy: Really mastering GitHub Copilot (or your tool of choice like ChatGPT, Claude, etc.) beyond basic autocompletion. Using it effectively for refactoring, explaining complex code snippets, generating test cases, drafting documentation – essentially, making it a true force multiplier for tasks I already do.
Integrating, Not Inventing: Learning how to confidently call existing, relatively mature AI APIs (like Azure OpenAI, OpenAI’s API, Anthropic’s, Google’s, etc.). Adding specific, valuable features like text summarisation, content moderation, semantic search, or maybe a simple, scoped chatbot where it clearly solves a user need. I don’t need to build the Large Language Model (LLM), just use the service effectively and responsibly.
Basic Prompt Crafting: Realising that getting useful output from an LLM is a skill. I’m trying to learn the fundamentals of clear instructions, providing context, and iterating on prompts to get what I actually need, rather than just getting frustrated with vague answers.

I’m deliberately not trying to become an expert on transformer architectures or the nuances of different quantization techniques right now. That’s fascinating stuff, but it’s not directly helping me ship code next week. The focus is on practical application using tools stable enough to integrate reliably.

2. Your Bedrock: Solid Engineering Still Rules

Amidst all the “AI will change everything” talk, it’s easy to get distracted. But here’s the thing: fundamental software engineering principles are more critical than ever. Clean code, good architecture, automated testing, understanding data structures, system design thinking – this isn’t going away.

In fact, these skills are essential for integrating AI effectively. An LLM can generate code, sure, but if you don’t have the skills to evaluate it, refactor it, test it, and integrate it into a well-structured system, you’re just creating tech debt faster. AI tools amplify your abilities. Using Copilot on a fragile, untested codebase won’t magically fix it; it might just help you write more fragile code quicker. Being a strong engineer who can leverage AI is way more valuable than being someone who knows AI buzzwords but lacks the foundations. Good engineering is my anchor in this storm.

3. Learn Slow and Steady: Sustainable Pacing Beats Burnout

That frantic sprint down rabbit holes I mentioned earlier? Total recipe for burnout. I’m trying to adopt a more sustainable learning pace:

Pick One Thing: Seriously, just one small, concrete goal at a time. Maybe this month, I’ll dedicate learning time only to understanding how to effectively use RAG with a specific vector database for a single use case. Or maybe just focus on getting better at writing prompts for code explanation. Small, focused wins feel achievable and less overwhelming.
Timebox Ruthlessly: This is key for me. I try to schedule a specific, limited block of time – maybe 2 hours every other Friday, or 30 minutes a few times a week – dedicated only to exploring that one chosen AI topic. When the time’s up, it’s up. This prevents it from bleeding into family time or weekend projects (mostly!).
Embrace “I Don’t Know Yet”: Giving myself permission not to have an immediate opinion or deep knowledge about every new AI paper or tool release has been liberating. It’s okay to say “That sounds interesting, I’ll check it out when/if it becomes relevant to my work.” I’m trying to wait for the initial hype dust to settle before diving deep into the truly cutting-edge stuff.

4. Build Your Signal Filter: Curate Your Inputs

My brain has finite bandwidth. I realised I was letting every breathless LinkedIn post or clickbait tech headline hijack my attention and dictate my learning priorities. No more.

Aggressively Unfollow: If a source consistently feels like hype over substance, or just makes me feel anxious, I hit unfollow. No apologies. My mental energy is too valuable.
Seek Out Pragmatic Voices: I’m actively looking for a small handful of bloggers, newsletters, or company tech blogs that offer balanced, practical insights, tutorials, code examples, and realistic case studies. Bonus points if they openly discuss limitations and challenges.
Prioritize “How-To” Over “Hot Take”: I’m trying to favour content that shows how to actually use a tool or technique in a realistic context, rather than just high-level announcements or opinion pieces about benchmark scores.

Wrapping Up: Staying Afloat, Staying Pragmatic (and Sane)

This AI wave is undeniably powerful, and yes, it is changing aspects of our work. But freaking out and trying to master everything overnight isn’t the answer (at least not for me). You don’t need to be a theoretical physicist to use electricity, and you don’t need to be an AI researcher building foundational models to leverage AI effectively in your development workflow.

My plan? Filter the relentless noise, focus on how AI can practically help me and my team solve problems today, keep sharpening those core engineering skills, learn at a sustainable pace that respects my time and energy, and be incredibly picky about my information diet.

By trying to stay pragmatic, I hope to navigate this AI tsunami, harness its power where it truly makes sense, and crucially, avoid drowning in the hype (and maybe, just maybe, reclaim some evenings!). Keep coding, keep learning (sensibly!), and let’s figure this out together.

This is just my current approach, born from my own struggles with AI overwhelm. Technology choices are always context-dependent. I’m really keen to hear how you are managing this! What strategies are working for you? What tools are genuinely useful? Drop a comment below! Look out for future posts where I’ll dive deeper into specific tools and techniques I’m experimenting with.

Resources I’m Finding Useful (for now!):

AI Coding Assistants & Prompting:
- GitHub Copilot Docs: Good starting point for understanding its capabilities beyond basic autocomplete. https://docs.github.com/en/copilot
- OpenAI Prompting Guide: Offers concrete techniques for getting better results from models like GPT-4, applicable beyond just OpenAI. https://platform.openai.com/docs/guides/prompt-engineering (Or check out guides from Anthropic/Google too!)
Exploring AI APIs:
- OpenAI API Cookbook: Lots of practical code examples for common tasks using their API. https://cookbook.openai.com/
- Azure AI Services Documentation: Comprehensive info if you’re in the Microsoft ecosystem. https://learn.microsoft.com/en-us/azure/ai-services/
Staying Updated (Sensibly):
- TLDR AI Newsletter: My go-to for quick, daily summaries. Helps filter the noise. https://tldr.tech/ai

Ditching MediatR? Maybe a Simple CQRS Dispatcher is All You Need

Sat, 19 Apr 2025 10:44:07 +0100

Alright, let’s talk about MediatR. You’ve probably heard the news – the popular .NET library, often the go-to for CQRS-style patterns, is shifting towards a commercial license for commercial use. Now, fair play to the maintainer for sustainability, but it definitely got me thinking. Do we really need a library like MediatR for decoupling our commands and queries? Often, the answer is simpler than you think.

This isn’t just about licensing costs; it’s a good chance to look at the complexity we sometimes invite into our codebases.

That Time MediatR Became the Maze Runner

I remember one project vividly. It started clean, using MediatR to nicely separate commands/queries from handlers. Standard stuff. But over time, it grew… wild. We had MediatR requests triggering other MediatR requests, sometimes nested. Notifications were flying everywhere, kicking off background jobs or updating read models in ways that weren’t immediately obvious.

Debugging became a nightmare. Trying to trace a single user action felt like navigating a maze. Where did the request actually go? Which notification handlers fired? Were they essential, or just side effects added later? We spent so much time just trying to understand the flow, time that could have been spent building features. It wasn’t MediatR’s fault per se, but the perceived “magic” it offered made it too easy to create tangled dependencies and obscure the core logic. It highlighted a big downside: when things get complex, that layer of abstraction can hinder understanding rather than help.

Quick Refresher: CQRS != MediatR

Just to be clear: CQRS (Command Query Responsibility Segregation) is a pattern. It’s about separating your write operations (Commands) from your read operations (Queries). MediatR is just one tool you can use to implement the dispatching part of that pattern. You absolutely don’t need it.

The core idea is simple: send a message (command/query) and have the right piece of code handle it. We can totally do that ourselves.

Rolling Your Own: A Simple Dispatcher Pattern

Let’s sketch out a lean, mean CQRS dispatcher using basic C# and the built-in dependency injection container.

1. Define Your Messages (Plain Old C# Objects)

Commands and Queries are just data carriers. Records are great for this.

// Command: Do something
public record CreateProductCommand(string Name, decimal Price);

// Query: Ask for something
public record GetProductByIdQuery(Guid Id);
// Query Result: The data you get back
public record ProductDto(Guid Id, string Name, decimal Price);

2. Define Your Handlers (Interfaces + Classes)

Simple interfaces make it clear what handles what.

// Handles commands (no return value typically)
public interface ICommandHandler<TCommand>
{
    Task HandleAsync(TCommand command, CancellationToken cancellationToken = default);
}

// Handles queries (returns a result)
public interface IQueryHandler<TQuery, TResult>
{
    Task<TResult> HandleAsync(TQuery query, CancellationToken cancellationToken = default);
}

And the implementations:

// Example Command Handler
public class CreateProductCommandHandler : ICommandHandler<CreateProductCommand>
{
    // Inject your DbContext, repositories, services here...
    public async Task HandleAsync(CreateProductCommand command, CancellationToken cancellationToken = default)
    {
        Console.WriteLine($"Creating product: {command.Name}");
        // ... your actual logic to save the product
        await Task.CompletedTask; // Placeholder
    }
}

// Example Query Handler
public class GetProductByIdQueryHandler : IQueryHandler<GetProductByIdQuery, ProductDto>
{
    // Inject your read-specific dependencies...
    public async Task<ProductDto> HandleAsync(GetProductByIdQuery query, CancellationToken cancellationToken = default)
    {
        Console.WriteLine($"Fetching product: {query.Id}");
        // ... your actual logic to fetch the product
        // Example return:
        return await Task.FromResult(new ProductDto(query.Id, "Sample Product", 19.99m));
    }
}

3. The Dispatcher: Connecting the Dots

This is the heart of it. A simple service that uses the DI container to find and run the right handler.

public interface IDispatcher
{
    Task SendAsync<TCommand>(TCommand command, CancellationToken cancellationToken = default) where TCommand : notnull;
    Task<TResult> QueryAsync<TQuery, TResult>(TQuery query, CancellationToken cancellationToken = default) where TQuery : notnull;
}

public class DependencyInjectionDispatcher : IDispatcher
{
    private readonly IServiceProvider _serviceProvider;

    public DependencyInjectionDispatcher(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }

    public Task SendAsync<TCommand>(TCommand command, CancellationToken cancellationToken = default) where TCommand : notnull
    {
        // Find the right command handler
        var handler = _serviceProvider.GetRequiredService<ICommandHandler<TCommand>>();
        return handler.HandleAsync(command, cancellationToken);
    }

    public Task<TResult> QueryAsync<TQuery, TResult>(TQuery query, CancellationToken cancellationToken = default) where TQuery : notnull
    {
        // Find the right query handler
        var handler = _serviceProvider.GetRequiredService<IQueryHandler<TQuery, TResult>>();
        return handler.HandleAsync(query, cancellationToken);
    }
}

4. Wire it Up (Dependency Injection)

Register your handlers and the dispatcher. Using a library like Scrutor makes assembly scanning easy, but you can register them manually too.

// In Program.cs or Startup.cs

// Example using Scrutor for scanning:
services.Scan(scan => scan
    .FromAssemblies(Assembly.GetExecutingAssembly()) // Or specify your assembly
        .AddClasses(classes => classes.AssignableTo(typeof(ICommandHandler<>)))
            .AsImplementedInterfaces()
            .WithScopedLifetime() // Or Transient/Singleton as needed
        .AddClasses(classes => classes.AssignableTo(typeof(IQueryHandler<,>)))
            .AsImplementedInterfaces()
            .WithScopedLifetime()); // Or Transient/Singleton as needed

// Register the dispatcher itself
services.AddScoped<IDispatcher, DependencyInjectionDispatcher>();

// If not using scanning, you'd register each handler manually:
// services.AddScoped<ICommandHandler<CreateProductCommand>, CreateProductCommandHandler>();
// services.AddScoped<IQueryHandler<GetProductByIdQuery, ProductDto>, GetProductByIdQueryHandler>();
// ...etc

5. Use It!

Inject IDispatcher wherever you need it (like your API controllers).

[ApiController]
[Route("[controller]")]
public class ProductsController : ControllerBase
{
    private readonly IDispatcher _dispatcher;

    public ProductsController(IDispatcher dispatcher)
    {
        _dispatcher = dispatcher;
    }

    [HttpPost]
    public async Task<IActionResult> Create([FromBody] CreateProductCommand command)
    {
        await _dispatcher.SendAsync(command);
        // Consider returning a 201 Created with location header
        return Ok();
    }

    [HttpGet("{id}")]
    public async Task<ActionResult<ProductDto>> Get(Guid id)
    {
        var query = new GetProductByIdQuery(id);
        var product = await _dispatcher.QueryAsync<GetProductByIdQuery, ProductDto>(query);
        return product != null ? Ok(product) : NotFound();
    }
}

Why Bother? The Payoff

No Extra Dependency: One less library to worry about, manage, or pay for.
Crystal Clear Flow: You know exactly how a command/query gets to its handler. Debugging is just stepping through your own code. F12 (Go To Definition) on SendAsync or QueryAsync takes you straight to your dispatcher, not library internals.
Total Control: Want logging, validation, or transactions around your handlers? Implement it yourself using decorators or simple middleware logic in your dispatcher. No need to learn a library-specific pipeline model.
Simplicity: It keeps the focus on the CQRS pattern itself, not on the tooling.

What About MediatR’s Bells and Whistles?

Now, let’s be clear: MediatR offers more than just simple dispatching, and its other features are often where its perceived value lies, especially for complex applications. It’s worth acknowledging these, particularly the point often raised about handling cross-cutting concerns:

Pipelines (Behaviors): This is arguably MediatR’s killer feature for many. It provides a clean, built-in mechanism (IPipelineBehavior<TRequest, TResponse>) to implement cross-cutting concerns – think logging, validation, transaction management, security checks, caching – that need to wrap around your command and query handlers. It’s a structured way to add logic before or after the actual handler runs.
- The DIY Alternative: As mentioned, you can replicate this using the Decorator pattern combined with your Dependency Injection container. You’d create specific decorator classes (e.g., ValidationCommandHandlerDecorator<TCommand>, TransactionCommandHandlerDecorator<TCommand>) and configure your DI setup to apply them in the desired order, effectively building your own pipeline.
- The Trade-Off: While the decorator approach gives you maximum transparency and control (you own the code, no library ‘magic’), let’s be honest: setting up and managing a robust, ordered pipeline with decorators manually requires significantly more upfront configuration and boilerplate code compared to leveraging MediatR’s pipeline feature. The convenience MediatR offers here is undeniable and a major reason teams adopt it. It’s a crucial point to weigh against the desire for fewer dependencies and ultimate explicitness.
Notifications: MediatR provides a publish/subscribe mechanism for “fire-and-forget” events where multiple independent handlers might need to react (e.g., OrderCreated event triggering email sending, inventory update, etc.).
- The DIY Alternative: For this, you can often implement a simpler observer pattern yourself. Create a dedicated IEventDispatcher (or similar) that resolves IEnumerable<IEventHandler<TEvent>> from your DI container and invokes all registered handlers. For more complex scenarios needing persistence, outbox patterns, or distributed messaging, integrating dedicated libraries like MassTransit or Rebus is often a better, more focused approach anyway, rather than relying solely on MediatR’s in-process notifications. Separating eventing from command/query dispatch can often lead to clearer boundaries.

The key takeaway here isn’t necessarily that these features aren’t valuable, but whether the convenience they offer outweighs the potential complexity, dependency management, and now licensing considerations introduced by the library, especially if your primary need is just the core command/query dispatch. If you heavily rely on and benefit from the pipeline behaviors, MediatR might still be the right tool for you, but it’s worth understanding the alternatives and the trade-offs involved.

Wrapping Up

Look, MediatR has been useful for many, but this licensing change is a great nudge to question our dependencies. For the core job of dispatching commands and queries in a CQRS setup, a simple, home-rolled approach using standard .NET features is often more than enough.

It gives you back control, simplifies your stack, and avoids potential future costs or licensing headaches. Before automatically reaching for MediatR (or any library), ask yourself: could a few interfaces and a simple dispatcher class do the job? You might be surprised how often the answer is yes.

Disclaimer: The views expressed in this post are my own, based on my experiences and observations. Technology choices are often context-dependent, and I welcome different perspectives or challenges to my points in the comments below!

Beyond the Magic: Is AutoMapper Doing More Harm Than Good? (And Why Now's a Good Time to Re-evaluate)

Thu, 17 Apr 2025 10:00:07 +0100

For years, AutoMapper has been almost a default choice for handling the tedious chore of mapping objects in .NET. Got an entity you need as a DTO? AutoMapper. Need to turn a command into an entity? AutoMapper again. It promised to slay the dragon of boilerplate mapping code, and honestly, for simple stuff, it felt pretty good.

But things change. AutoMapper’s creator recently announced that, like MediatR, newer versions are moving to a dual-license model (AGPL open-source, or a paid commercial license – you can read the official announcement details here). While that’s understandable for keeping a project alive, it’s also a perfect excuse for us to step back and ask: is AutoMapper really the win we think it is, or does its “magic” sometimes cause more trouble than it’s worth?

I want to argue here that despite its massive popularity, AutoMapper often comes with significant downsides, especially as applications grow. The licensing change isn’t just about cost; it’s a nudge to finally confront the headaches its “magic” can create.

The Original Sin: Why We Fell for It

Let’s be fair – nobody likes writing repetitive mapping code. Manually assigning properties between dozens of classes is soul-crushing. AutoMapper’s convention-based approach (if it looks the same, map it!) felt like a huge productivity boost early on.

// The Old Way (Yawn):
var orderDto = new OrderDto
{
    OrderId = order.Id,
    CustomerName = order.Customer.Name, // Simple enough...
    TotalAmount = order.Items.Sum(item => item.Price * item.Quantity) // Okay, a bit more involved
};

// The AutoMapper Way (Looks clean!):
// Configure the map once... then just:
var orderDto = _mapper.Map<OrderDto>(order);

That second version looks way slicker, right? That slickness is the hook. But the magic has a dark side.

The Pitfalls: When Magic Turns into a Curse

Simple, one-to-one mappings are AutoMapper’s sweet spot. But real-world code is rarely just that simple. That’s where things get hairy.

The Black Box Problem: This is the big one. You see _mapper.Map<OrderDto>(order), but what’s actually happening? You have no idea without spelunking through AutoMapper profiles.
- Is CustomerName a direct map, or is some hidden custom resolver messing with it?
- How did TotalAmount get calculated? Did AutoMapper magically run a Sum because of some ForMember rule buried in config?
- What if property names are close but not identical? Will it fail silently? Throw a cryptic error? Who knows! This opacity makes the code hard to read, reason about, and trust compared to just seeing the assignments directly.
Debugging Nightmares: Ever tried figuring out why a mapped property is null or has a weird value when using AutoMapper? It can be painful. You can’t just step through the mapping line by line like normal code. You’re stuck trying to decipher AutoMapper’s internals, its configuration jungle, and how its resolvers decided to execute. The error messages often point fingers at the configuration itself, not the root data or logic issue.
- My “Aha!” Moment (the bad kind): I remember inheriting a project years ago where AutoMapper was everywhere. We hit a bug where a crucial financial field in a DTO was subtly wrong under specific conditions. Tracking it down was absolute agony. It wasn’t a direct mapping; it involved a chain of Profile configurations, a custom ValueResolver that called another service, and some ForMember conditions that weren’t immediately obvious. We spent hours digging through layers of AutoMapper configuration just to understand the path the data was taking. When we finally found the logic flaw buried in that resolver, the fix itself was trivial, but the diagnostic process was brutal. That was the point I realized the “magic” wasn’t worth the obfuscation – a clear, explicit mapping method, even if longer, would have saved us hours of frustration and made the bug obvious much sooner.
Configuration Bloat: As your mappings get more complex (conditionals, ignored fields, custom converters, nested stuff), the AutoMapper configuration code balloons. Those Profile classes become sprawling monsters. Suddenly, the boilerplate you tried to kill in your mapping code has mutated and reappeared in your configuration, often in a format that’s harder to read and maintain.
Performance Hits (Especially Startup): AutoMapper leans heavily on reflection, especially when your app first starts and it’s figuring out all the mapping plans. It tries to compile things for runtime speed, but that initial startup hit can be noticeable, especially with lots of maps. Plus, using ProjectTo with database queries (like EF Core) can generate some seriously complex expression trees that might not perform as you expect if you’re not careful.
Dependency Lock-in: Pulling in AutoMapper means pulling in a hefty dependency. Upgrading it can sometimes bring breaking changes. And if you want it to play nice with things like Entity Framework’s query projection, you often need more specific AutoMapper extension packages, tying your codebase even tighter to its ecosystem.
Sometimes, Simple is Just… Simpler: Honestly, for many basic mappings, just writing it out manually is clearer and faster to understand than messing with AutoMapper config. new TargetDto { PropA = source.PropB, PropC = source.PropD } needs no explanation. Any C# dev gets it instantly.
The New Price Tag: Even if you shrug off the technical issues, the commercial license for new versions adds a very practical reason to look elsewhere. Why pay for a tool that might already be adding friction to your development process?

The Alternatives: Clear, Readable, Fast Mapping

Good news! Ditching AutoMapper doesn’t mean returning to the dark ages of manual mapping for everything. We have great alternatives using plain C# or modern tooling.

Good Old Manual Mapping: Often the best choice for clarity.

Property Initializers: Simple, direct, and obvious.

public ProductDto MapProduct(Product product)
{
    ArgumentNullException.ThrowIfNull(product); // Basic guard clause
    return new ProductDto
    {
        Id = product.Id,
        Name = product.Name,
        Price = product.Price?.Value ?? 0m // Explicit, handles potential null
        // What you see is what you get!
    };
}

Static Factory Methods: Keep mapping logic contained within the target type.

public class ProductDto
{
    public Guid Id { get; set; }
    public string Name { get; set; }
    public decimal Price { get; set; }

    public static ProductDto FromProduct(Product product)
    {
         ArgumentNullException.ThrowIfNull(product);
         return new ProductDto
         {
             Id = product.Id,
             Name = product.Name,
             Price = product.Price?.Value ?? 0m
         };
    }
}
// Usage: var dto = ProductDto.FromProduct(product);

Extension Methods: Make mapping feel fluid.

public static class ProductMappingExtensions
{
    public static ProductDto ToDto(this Product product)
    {
         ArgumentNullException.ThrowIfNull(product);
         return new ProductDto
         {
             Id = product.Id,
             Name = product.Name,
             Price = product.Price?.Value ?? 0m
         };
    }
}
// Usage: var dto = product.ToDto();

These methods put the logic right where you can see it, debug it easily, and refactor it with standard tools. For most straightforward cases, this is my go-to.

LINQ Select for Collections: When you’re mapping lists or query results, Select is your friend. It’s the idiomatic .NET way, especially powerful with IQueryable (like EF Core) because it often translates directly to SQL.

// Map a list in memory
public IEnumerable<ProductDto> MapProducts(IEnumerable<Product> products)
{
    ArgumentNullException.ThrowIfNull(products);
    // Use the extension method for consistency
    return products.Select(p => p.ToDto()).ToList();
}

// Project directly from a database query (EF Core example)
public Task<List<ProductDto>> GetProductDtosAsync(IQueryable<Product> products)
{
    ArgumentNullException.ThrowIfNull(products);
    // Select directly into the DTO - EF translates this!
    return products.Select(p => new ProductDto
    {
        Id = p.Id,
        Name = p.Name,
        // Assuming Price is non-nullable in DB or handled by EF config
        Price = p.Price.Value
    }).ToListAsync(); // Execute the query
}

Readable, efficient, and leverages the power of LINQ and your ORM.

Source Generators (The Modern Approach): C# Source Generators are a game-changer here. They let tools generate code at compile time. Libraries like Mapster use this brilliantly for mapping. You give them hints (often with attributes or simple interfaces), and they write the fast, explicit mapping code for you during the build.

No runtime reflection overhead.
Performance like manual mapping.
Boilerplate reduction like AutoMapper.
Compile-time safety.

// Example using Mapster attributes (simplified setup)
// Requires Mapster.Tool and Mapster.Attributes packages
// Tell Mapster to generate mappers between these types globally
[assembly: GenerateMapper(typeof(Product), typeof(ProductDto))]

public class ProductDto
{
    public Guid Id { get; set; }
    public string Name { get; set; }
    public decimal Price { get; set; }
    // Mapster handles simple matching props by convention.
    // Customizations via attributes or fluent API needed for complex cases.
}

// ... later in code ...
// Assumes Mapster DI setup or direct usage
var dto = product.Adapt<ProductDto>(); // Fast, generated code runs here!

Mapster (and similar libraries) feels like AutoMapper’s convenience without the runtime mystery and overhead. It’s a really compelling option once you wrap your head around source generation.

How to Escape: A Step-by-Step Retreat

You don’t need to rip AutoMapper out overnight. Try a phased withdrawal:

New Code Ban: Stop using AutoMapper for any new mappings. Use manual code, LINQ Select, or a source generator like Mapster instead.
Triage and Attack: Find your most complex, annoying, or performance-sensitive AutoMapper configurations. Refactor those first using one of the alternatives. Get the biggest wins early.
Gradual Refactoring: As you touch other parts of the codebase, refactor any AutoMapper usages you encounter. Chip away at it during regular work or dedicated refactoring time.
Remove the Package: Once no code references AutoMapper anymore, uninstall the NuGet package. Victory!

Wrapping Up

AutoMapper promised simplicity, and for a while, it seemed to deliver. But its “magic” often comes at the cost of clarity, debuggability, and maintainability, especially in complex projects. The upcoming licensing change is just the final nudge to reconsider if this dependency is truly serving you well.

By favoring clear, explicit C# for simple maps, using LINQ Select naturally for collections and projections, and exploring powerful source generators like Mapster for the heavy lifting, you can build mapping strategies that are easier to understand, debug, and maintain – all without the hidden costs and potential licensing fees of AutoMapper.

And let’s be real, in today’s world where no blog post is complete without mentioning AI somewhere, these new coding assistants are getting scarily good. Tools like GitHub Copilot or Cursor practically write boilerplate mapping code for you with a simple prompt. If the main appeal of AutoMapper was saving keystrokes on simple mappings, AI tools are eating that lunch pretty effectively now, giving us yet another reason to stick with clearer, explicit code.

Maybe it’s time you evaluated if the convenience is really worth it anymore.

Disclaimer: The views expressed in this post are my own, based on my experiences and observations. Technology choices are often context-dependent, and I welcome different perspectives or challenges to my points in the comments below!

Links

Mon, 01 Jan 0001 00:00:00 +0000

Some quick places to find me and follow along.

Search

Mon, 01 Jan 0001 00:00:00 +0000