Forem: Sayok Bose

Debugging Is a Lost Art. Juniors Never Had It. Seniors Traded It. AI Faked It. Cool Story.

Sayok Bose — Wed, 18 Mar 2026 13:55:14 +0000

How AI quietly broke two things on our .NET team at the same time. In opposite directions. And nobody noticed.

TL;DR

Juniors ship fast and cannot debug anything. Seniors are slower to debug than they used to be. The AI writes immaculate code with the error handling of a sleep-deprived intern. And everyone is too busy to care until 2am.

2013 vs 2026

In 2013, joining a .NET team meant one thing.

You got stuck. You stayed stuck. You Googled the same NullReferenceException four times. You finally understood it. You never forgot.

In 2026, joining a .NET team means opening a chat window.

Which is faster. Genuinely. No sarcasm. The AI is great.

But somewhere between then and now, something got lost. And we did not notice until we really needed it.

The Juniors: They Never Had to Struggle

AI removed the productive suffering.

Now a junior hits a wall, asks the AI, gets a fix in ten seconds, ships. Great velocity. Zero scar tissue.

Ask them to trace a value through .NET middleware they did not write. Ask them to explain why an async deadlock only happens under load. Ask them to open the debugger and step through something cold.

You can see the exact moment the confidence leaves their face.

"I have trained you well. Now debug this StackOverflowException in production without me."
-- The AI, logging off at exactly the wrong moment

The muscle never got built. Not their fault. Ours. We handed them a Ferrari before they knew how to drive.

The Seniors: They Traded It In

Before AI: Senior hits a weird EF Core bug. Reads the stack trace. Holds the whole call chain in their head. Finds it in twelve minutes.

After eight months of AI: Senior pastes the stack trace. AI says check the DbContext lifetime. Senior checks. Fixed in four minutes.

Still fast. But notice what did not happen.

The senior did not debug. The senior supervised debugging. That is a different skill. And it atrophies quietly.

The reflex goes. You do not notice it leaving. You just notice one day that reading a raw stack trace feels harder than it used to.

Act Three: 2am. Production is down. AI is rate limited.

We will leave that one to your imagination.

The AI: Crime Scene, No Witnesses

catch (Exception ex)
{
    _logger.LogError("An error occurred."); // groundbreaking stuff
    throw;
}

AN. ERROR. OCCURRED.

Not which order. Not which customer. Not whether the charge went through before it exploded -- which is literally the only thing anyone needs to know at 2am.

Here is what a human writes on a Friday when they are scared:

catch (PaymentGatewayException ex) when (ex.IsTransient)
{
    // Do NOT retry blindly -- charge may have gone through. Check idempotency key first.
    _logger.LogError(ex, "Gateway failure for Order {OrderId}. Charged: {WasCharged}",
        request.OrderId, ex.ChargeAttempted);
    throw;
}

One gets debugged in twenty minutes. The other gets debugged while someone asks if the customer was charged twice.

Guess which one the AI writes.

Nobody Read The PR Either

Open diff. Looks like code we would write. Tests pass. LGTM.

// perfectly formatted. reviewed in 30 seconds. approved.
// contains a classic EF Core N+1 that will destroy the DB under any real load.
// but sure. LGTM.

return orders.Select(o => new OrderDto {
    Items = _context.OrderItems
        .Where(i => i.OrderId == o.Id).ToList() // new query. per order. every time. forever.
});

Junior shipped it. Senior approved it. AI has no idea what N+1 means emotionally. Database is about to have a very bad day.

And Then There Is The Pressure

The sprint does not stop. The tickets do not stop. The stand-up is in twenty minutes.

So the junior asks the AI because asking a senior feels like interrupting someone who is drowning. The senior approves the PR quickly because they have five more tickets. Nobody writes the why comment because the ticket closes today and tomorrow is already full.

Nobody is doing anything wrong. Everyone is just doing the only thing the system has time for.

It is not a skill problem. It is a system problem wearing a skill problem's coat.

"Move fast and break things"
-- Someone who never had to debug the things that got broken

The Only Checklist A Human Reviewer Needs In 2026

The linters catch the N+1. The analyzers catch the missing CancellationToken. Let the tools do the tools job.

Here is what only a human can check.

- [ ] Does this solve the RIGHT problem, not just the one in the ticket?
- [ ] Does this contradict a decision made in another service six months ago?
- [ ] Is this shortcut acceptable given what is coming next quarter?
- [ ] Will the on-call person understand what went wrong from the logs alone?
- [ ] Is this junior developing a habit we should address, not just fix?

Five questions. All of them require someone who was in the meeting, knows the history, or has been burned before.

The actual value of a human reviewer in 2026 is not spotting the N+1.

It is knowing we tried this exact pattern in 2023 and it took down prod.

Pitfalls To Avoid

Using AI to fix bugs that AI wrote. Junior hits a bug in AI code, asks the AI, moves on. The mental model never forms. Same bug, different form, three months later.

Trusting green tests as proof of correctness. AI tests the behaviour it implemented. If it implemented the wrong behaviour, the tests pass. Enthusiastically.

Letting the PR description review the code for you. AI writes great PR descriptions. So great that reviewers read the description and skim the diff. The description says what it does. The code is where it goes wrong.

Closing

The juniors are fast. The seniors are comfortable. The AI is confident.

Somewhere in the middle is the production incident nobody has the instincts to fix at speed anymore.

The lost art is not gone. It just needs a process around it -- not heroism and overtime.

Start with the two checklists. Ship them this sprint.

Drop a comment if you have hit this differently. Genuinely asking.

Your Company's APIs Are Collecting Dust. Agents Are Starving. We Played Matchmaker.

Sayok Bose — Wed, 11 Mar 2026 08:36:15 +0000

We added one project. Agents got jobs. Nobody checked if they wanted them.

TL;DR

Your company has APIs. AI agents want to use them. The agents have no idea they exist. We wrapped ours in MCP in an afternoon, touched zero existing business logic, and suddenly an agent was doing work that used to take a human four browser tabs and a spreadsheet with too many conditional formats. This is that story.

Okay So Picture This

You have spent years building APIs. Real ones. With actual business logic. Carefully written handlers, domain models, the whole clean architecture setup your team is quietly proud of.

And then AI agents show up.

They want to automate things. They are very enthusiastic about it. And they cannot find a single one of your endpoints because — and we cannot stress this enough — agents do not browse Swagger docs.

They need tools. Exposed in a protocol they speak. Without that, your entire API portfolio might as well not exist.

We found this out the fun way.

MCP. What Is It. Why Do You Care.

Model Context Protocol. Anthropic open-sourced it. Think USB-C for AI tools.

Before MCP, connecting an AI to your API meant writing a custom wrapper. Every. Single. Time. Different model? New wrapper. New team? New wrapper. It was miserable and everyone pretended it was fine.

MCP says: one standard. One server. Any agent that speaks the protocol discovers your tools automatically and knows what to call and with what parameters.

You write a description. The agent reads it. The agent does the thing. No human in the middle explaining the API like it is a new intern's first day.

"You had the power all along." — Glinda the Good Witch, definitely talking to your Application layer

The Part Where Clean Architecture Accidentally Saved Us

So here is the thing about Clean Architecture that nobody puts on the conference slides.

The REST API? It is just a delivery mechanism. It sits on the outside. It is not the brain. It is the postman. You could swap it out and the business logic would not notice.

      Domain
        ↑
    Application       ← the actual brain
     ↑       ↑
   REST     MCP       ← both just taking orders

We added the MCP server at the same level as the REST API. Both of them talk to the same existing handlers. Neither knows the other exists. The entire business logic stayed completely untouched.

We were smug about this for the rest of the day. Rightly so.

And Vertical Slicing Made Each Feature a Free Tool

Each feature in our codebase is already a self-contained slice. Handler, request, response — all together, all neat.

The REST controller calls it:

var result = await _bus.InvokeAsync<GetProductDetails.Response>(
    new GetProductDetails.Request { ProductId = productId }, ct);

The MCP tool calls the exact same handler:

[McpServerTool, Description("Gets product details including price and stock level.")]
public Task<GetProductDetails.Response?> GetProductDetails(
    [Description("The product ID")] Guid productId, CancellationToken ct)
    => _bus.InvokeAsync<GetProductDetails.Response>(
        new GetProductDetails.Request { ProductId = productId }, ct);

Same handler. Same response. Three new lines of code.

The feature slice was already a unit. We just gave it a new front door.

The Whole Server In One Screenshot Worth Of Code

builder.Services.AddApplication(builder.Configuration); // your entire app, already wired
builder.Services.AddMcpServer().WithHttpTransport().WithToolsFromAssembly();
app.MapMcp("/");

AddApplication — same call your REST API makes. Every handler, every repo, every service. All of it just... there.

WithToolsFromAssembly — scans for [McpServerTool] methods, reads the descriptions, builds the schemas. You write a description. It does the rest. It is almost annoying how easy it is.

We ended up with 10 tools. All existing logic. The whole class is 126 lines and most of it is whitespace and closing braces.

Why Every Enterprise Should Be Mildly Panicking Right Now

Most big companies have not ten APIs but fifty. Microservices, internal data tools, report generators, ETL jobs with REST wrappers, legacy systems being held together by prayer and a Java 8 runtime.

All of it. Invisible to agents.

The MCP layer pattern means none of that investment gets binned. One project. Write some descriptions. Your entire API surface becomes agent-accessible. An agent can now chain your tools, pull data, run models, and summarise findings — without a human opening four apps and doing the copy-paste shuffle.

The companies that win here are not rebuilding from scratch. They are the ones who look at what they already have and ask "what would it take to put MCP in front of this?"

Turns out the answer is: an afternoon.

MCPJam: Swagger UI But Make It MCP

Before wiring up a real agent we needed to poke at the tools. Enter MCPJam.

docker run -p 127.0.0.1:6274:6274 mcpjam/mcp-inspector

Open localhost:6274. Connect to your server. Click a tool. Fill in params. See the response. That is genuinely all there is to it.

It finds your broken tools immediately. Much better than finding them two hours into an agent debugging session at 6pm.

Things That Did Not Work Immediately (Quick Version)

NuGet returned 401 because our private feed had never heard of the MCP packages. One nuget.config with packageSourceMapping. Ten minutes. Done.

MCP Inspector kept throwing 400s with Streamable HTTP. We spent 45 minutes on this. Forty. Five. Minutes. Switched to SSE and it worked in 30 seconds. We do not talk about those 45 minutes.

Docker Desktop had claimed port 6274 before MCPJam could. Docker was blocking the thing that runs in Docker. The irony was not appreciated.

None of these were MCP problems. All entirely self-inflicted.

The Bit That Will Save You At 11pm

Our API has environment config files for each deployment. We linked them into the MCP project via MSBuild instead of copying them:

<Content Include="..\MyApi\appsettings.staging.json"
         Link="appsettings.staging.json"
         CopyToOutputDirectory="PreserveNewest" />

One source of truth. Right config picked up automatically. Zero "why is MCP talking to prod while we are on staging" incidents. You are welcome.

Lessons (The Ones We Actually Learned, Not The Ones That Sound Good)

Good architecture pays off in ways you did not plan for. Adding a new delivery mechanism to a clean codebase is an afternoon. Adding it to a mess is a project.
The MCP layer has zero business logic. Zero. If you put an if statement in a tool method we will find out.
Tool descriptions are load-bearing. An agent with a vague description will call the wrong tool with complete confidence and a smile.
MCPJam first. Always. No exceptions.
Sort nuget.config before you need it. NuGet 401 on a Friday is a personality-altering experience.

Part 2 Is Coming. And It Is Not Pretty.

We made our APIs agent-ready. The agents showed up.

We were not ready.

Turns out there is a difference between "an agent can call your API" and "your API survives an agent calling it." Rate limits. Retries that fire four times in parallel. Costs that make your finance team ask questions you do not want to answer. And logs that tell you absolutely nothing useful.

Next up: We Let Agents Loose on Our APIs. Here's What Broke First.

Stay tuned. It gets worse before it gets better.

Building on existing APIs and trying to figure out how to make them agent-ready without a six-month rewrite? This is the answer. Drop a comment. Tell us what broke differently for you. We genuinely want to know.