(As always: “I” means the partnership — my direction and review, an AI agent’s execution.)

Every post on this blog so far has been a receipt from the same two weekends and the week that followed. The semantic tools the agent ignored. The 2011-era app migrated unattended. The test suite that was right by luck. Readers keep encountering the middle of a story, so here’s the beginning — told honestly, which means telling you what broke, what got rebuilt, and which of my own tools turned out to have been silently failing for weeks.

July 3: a ranking, not a roadmap

It started as a strategy conversation, the kind you have when you’re deciding where a finite supply of side-project weekends should go. The AI-app-generator category was crowded and being absorbed by first-party tooling. But one asymmetry looked durable: the agent ecosystem is TypeScript-first and Python-first, and I’ve spent decades in .NET. Be the .NET person in a room that speaks TypeScript — that was the whole strategy.

Four ideas came out of that conversation, ranked by how hard they cashed in on the niche:

  1. A C# library for driving Claude Code sessions. The agent SDKs exist for TypeScript and Python; .NET developers hand-roll the same process-spawning, stream-parsing plumbing every time. I knew this intimately, because my own agent orchestrator contained three copies of exactly that plumbing.
  2. A Roslyn-powered MCP server — semantic code navigation instead of grep.
  3. A legacy .NET modernization pipeline — the follow-the-money idea. Businesses pay real consulting rates to get 2011-era apps onto modern .NET.
  4. Agent session observability — analytics over the transcripts agents leave behind.

The recommendation that fell out: start with #1, not because it was the most ambitious but because it was the smallest bet with the clearest payoff — and because the extraction work would improve the orchestrator even if nobody else ever downloaded the library. That principle — every project must pay for itself inside the stack even if the market ignores it — turned out to be the load-bearing decision of the whole month.

Weekend one: the unglamorous one

The first weekend — the long July 4th one — produced nothing you could demo. It was a hardening pass on the orchestrator plus the library extraction, and it was the most valuable archaeology I’ve done in years, because the agent kept digging up things I didn’t know were broken:

  • My settings database had been throwing on every read for weeks. A schema-migration gap from an earlier feature; every settings read since had failed silently. The fix derives the expected schema from the model and healed my database in place.
  • The system prompt was being silently dropped. The orchestrator fetched my carefully written agent guidance and never passed it to the CLI. All those instructions I’d been refining? The agent had never seen any of them.
  • Published builds had shipped without their feature tools at all — a packaging path bug meant releases were missing the MCP server entirely.

Sit with that list for a second, because it’s the honest counterweight to every velocity number in this post: these bugs were built at agent speed too. The same partnership that shipped them found them, but “two-weekend velocity” includes the rework, and anyone who quotes you the shipping rate without the rework rate is selling something.

The weekend ended with a ritual that’s now standard practice: an adversarial review of our own branch — eight finder agents prompted to attack it from different angles, findings verified before acting. It caught ten real issues, including a race that could silently swallow a rate-limit signal and a deterministic bug that could launch an agent against the wrong project. Net result: ~1,180 duplicated lines deleted, forty new tests, everything green, and a working 0.1.0 of the library — extracted, as planned, as if it were a product, because it was about to become one.

Weekend two, Saturday: the compounding day

The second weekend opened with an approved queue — seven items, full authority over private repos, nothing published. The queue was done by early afternoon.

That sentence deserves suspicion, so here’s what made it possible: every item consumed the one before it. The MCP server (idea #2) was built and then integration-tested against the orchestrator’s own real codebase — not mocks, but answer-key assertions like “find-references on this class must name exactly the three services I know consume it.” The modernization pipeline design (idea #3) rode on both. The synthetic legacy specimen — “Inventory 2011,” a WinForms-plus-WCF time capsule with every landmine planted and catalogued — existed to test the assessor, and the assessor’s output was shaped to feed the orchestrator. By Saturday night the four ideas from July 3 weren’t four projects; they were one stack, each layer verified against the layer below it.

(Idea #4, the observability app, had quietly become a repo that morning too. Some weekends you just run the table.)

Weekend two, Sunday: the shipping day

Sunday was the day things left the machine. The library went to NuGet under trusted publishing — and then went through six versions in one day, 0.1.0 to 0.2.3. That number looks chaotic; it’s actually the strategy working. The orchestrator became the library’s first real consumer that same afternoon, and first consumers find things: the library needed a public callback overload nobody would have designed in the abstract, the README needed cookbook snippets where deciding actually happens. Dogfooding compressed what would normally be a month of issue-tracker feedback into an afternoon.

Two repos went public. A landing page went up. And this blog went live — the last deliverable of the second weekend was the place you’re reading about it.

But the most important thing that shipped Sunday was a negative result. With the MCP server public and polished, I ran the adoption experiment: would an agent, guided to prefer semantic tools, actually use them? You know the answer if you’ve read post one — it ignored them, twice, for $3.62 in API costs. The flagship of the whole weekend, falsified as an efficiency play within hours of going public, and redirected toward capability-gap tools that grep cannot imitate. That redirect became v2, which became two more experiments, which became three more posts.

The ledger

Two weekends, roughly four working days of them:

  • Five repos created; two public, on purpose (the consulting instruments stay private — that’s the business, not the portfolio)
  • One library live on NuGet, six versions deep, with its first consumer in production use
  • Nine semantic tools, integration-tested against a real codebase with known-true answers
  • A four-stage modernization pipeline, designed and pointed at a specimen with an answer key
  • ~300 tests green across the stack, an adversarial review pass with ten confirmed finds, one blog
  • Out-of-pocket experiment costs: about $3.67 total — five cents of smoke tests and one falsified hypothesis

What I actually learned

The bottleneck moved; it didn’t disappear. Nothing in those two weekends was gated on typing speed. Everything was gated on decisions — what to extract, what to verify, what stays private, what a passing grade even means. The Monday-morning lists my agent left me weren’t task lists; they were decision lists. That’s the job now.

Compounding beats parallelism. The temptation with agent-scale velocity is to run four independent projects at once. The returns came from running four dependent ones — each project testing the last, each one the next one’s first customer. A stack audits itself; a portfolio doesn’t.

Verification is the product. The answer-key tests, the adversarial review, the independent re-checks of agent claims — that’s where the effort concentrated, and it’s the only reason any of these numbers mean anything. Two weekends of unverified agent output would be a liability with a commit history.

And one thing this ledger can’t show yet: users. Velocity is not traction, a compounding stack is not a business, and I’ve been in this industry far too long to confuse a good fortnight with a good product. But the experiments since — the migrations, the real-world specimens, the model-tier comparisons — all ran on rails laid in those two weekends. The receipts are in every other post on this blog.

Built and written in collaboration with Claude (Anthropic’s Fable 5) — the workflow this blog is about. The public pieces are at github.com/sharpdaddy59/RoslynMcp and github.com/sharpdaddy59/ClaudeCode.NET; the library is ClaudeCode.Net on NuGet. The modernization pipeline is not public — but if you have a .NET Framework application that deserves a future, that’s exactly the conversation I’d enjoy having.