(As covered in my first post: I work with an AI coding agent, and “I” here means that partnership — my direction and review, its execution. New workflow, no apologies.)

Every .NET consultant knows the conversation. A business has a WinForms app from 2011 — still running, still load-bearing — on .NET Framework, full of WCF and worse. They need it on modern .NET: security patches, hosting, hiring. The work is valuable, semi-mechanical, and verifiable. Which makes it exactly the shape of work autonomous agents should be good at.

I wanted to know if that’s actually true yet. So I built a pipeline and fed it an app.

The pipeline

ASSESS  →  PLAN  →  EXECUTE  →  VERIFY

Assess: a Roslyn-based analyzer inventories a legacy solution — project styles, target frameworks, packages.config — and scans the source for landmines: BinaryFormatter (removed in .NET 9+), WCF server contracts, .NET Remoting, registry access, app.config patterns, COM interop. It’s deliberately compilation-free: legacy solutions often won’t build on a modern machine, and an assessor that needs a working build defeats its purpose. Each project gets a verdict — Portable, PortableWithWork, or NeedsRedesign — and the reference graph yields a leaves-first migration order.

Plan: the assessment becomes an ordered list of migration features — convert this project to SDK-style, retarget that one, replace BinaryFormatter here — each with acceptance criteria, each tagged for where it can run (my Linux box handles anything modern; a Windows machine handles anything still touching .NET Framework).

Execute: the features load into an agent orchestrator I built (a story for another post) that implements them one at a time — each feature verified, each one a git commit.

Verify: build clean, tests green, and — critically — a human re-checks the agent’s claims independently.

The specimen

Full disclosure up front: the test app is synthetic. I needed a legacy codebase with a known answer key — every landmine planted and catalogued, so a passing grade would be checkable — and so I authored “Inventory 2011”: a WinForms client, a WCF service with a .NET Remoting bridge nobody remembers deploying, and a shared library. Old-style csproj, packages.config, target frameworks from net452 to net48. (Authentic detail: it was written on Linux and didn’t compile until a real .NET Framework toolchain got hold of it — the compiler found three authoring mistakes, like any good code review.)

A rigged exam, yes — but rigged exams have a virtue: you know exactly what a passing grade means. Real-world specimens came later; more on that at the end.

The run

The assessor matched the answer key: every planted landmine found, correct verdicts, correct migration order. The plan came out as 13 features. The agent executed all 13, unattended, one commit per feature. Zero failures.

Independently verified afterward — not taken from the agent’s self-report:

  • dotnet build — clean, 0 warnings, 0 errors
  • dotnet test — 8/8 green, including a new UI test project the agent created
  • Every landmine semantically gone: no BinaryFormatter, no WCF ServiceHost, no Remoting, no registry calls, no packages.config
Project Before After
InventoryCore net452 net452;net8.0 (multi-targeted)
InventoryDesktop net48 WinForms net8.0-windows (ported to Avalonia)
InventoryService net472 WCF + Remoting net8.0 (CoreWCF + a small TCP bridge)

The interesting part: judgment calls

Three places the agent went beyond the literal plan, all defensibly:

  1. It multi-targeted the shared library (net452;net8.0) instead of hard-retargeting, preserving compatibility for any legacy consumer — and used the reference-assemblies NuGet package so the old target still builds without a 2015 toolchain.
  2. It ported the WinForms client to Avalonia — the plan’s notes called keeping WinForms on Windows “mostly mechanical,” and the agent chose the more portable UI stack instead. Defensible, but bigger than asked; my plan generator now needs to pin that decision rather than leave it to agent taste.
  3. It replaced the Remoting bridge with a purpose-built TCP shim and moved WCF to CoreWCF — matching the plan’s “redesign the boundary” guidance.

That’s the double-edged reality of agent latitude: two of those calls I’d have made myself; one I’d have wanted to be asked about first.

What should make you skeptical (it made me skeptical)

The app was synthetic and I wrote the answer key. Passing a rigged exam proves the machinery works; it doesn’t prove the assessor finds landmines I didn’t plant. When I later pointed it at a real Codeplex-era codebase — 17 projects, checked-in COM interop DLLs, a WiX installer — it found three bugs in my assessor in ten minutes, including one my own test suite had been certifying as correct by pure coincidence. (That story is its own post.)

“It launches” is not verification. The migrated desktop app started fine — and showed an empty grid, because the original had no seed data and no way to add any. The regression gate had passed trivially: with no data, there were no flows to exercise. The plan generator now demands seeded, representative fixture data in its verification features. An app that launches empty proves nothing about load paths or serialization round-trips.

A human caught the target-framework mistake. My plan generator originally targeted net8.0 — which leaves support this November. Reviewing the migrated output is what surfaced it; the default is now the current LTS and configurable. The pipeline executed flawlessly toward a subtly wrong target, and no test caught it because the tests encoded the same assumption. Autonomous execution raises the value of human review; it doesn’t retire it.

Where this lands

Could this pipeline migrate a real client’s codebase today, unattended? No — and anyone selling that should be asked hard questions. Could it do the assessment, produce an honest migration plan with real cost signals (right down to “your WiX installer isn’t covered”), and execute the mechanical majority under human review, at a fraction of the usual effort? On the evidence so far: yes. That’s not the end of migration consulting. It’s a very different cost structure for it.

The real-world specimen work — where the interesting failures live — is next.

Built and written in collaboration with Claude (Anthropic’s Fable 5) — the workflow this blog is about. The semantic code tools from post one are public: github.com/sharpdaddy59/RoslynMcp. The assessment pipeline and its test specimens are not — but if you have a .NET Framework application that deserves a future, an automated assessment with a comprehensive report is exactly the conversation I’d enjoy having.