From the Backlog to the Build Log

Week of September 5 - September 11, 2025

A note about this build log entry: I published this after the week it covers. DevNitro reconstructed a draft from work-related entries in my journal, Git commit history, and time tracking. I reviewed, edited, and approved the final post. The story reflects what I knew and built at the time.

Last week the first MCP tool call fired and a container started. This week the two halves learned to talk. The DevNitro Core process now reaches into a running Docker container, and a Workspace Agent inside that container reads and writes files on command. The core loop went from "it started" to "it can do work," and most of the week was AI-assisted .NET development spent closing that gap.

What I Worked On

DevNitro runs an AI agent that builds a .NET app and operates it inside a container. For that to work, the Core process on the outside has to hold a conversation with an agent on the inside. That link was the week.

I moved the DevNitro.Workbench MCP server into the main project and gave ChatSession an AgentUrl so Core knows which container to address. Then I wrote a file-write test and watched it land: test-file.txt written straight into the /workspace folder inside the container. The CLI could update files in Docker. Then the local model could update files in Docker. Hit or miss on the model side, but the wiring held.

Alongside that I kept two infrastructure threads moving. I split GCT into automated NuGet packages that build off the current git branch, and I started refactoring GCT to run against databases other than SQL Server, with PostgreSQL as the first target beyond T-SQL.

What the AI Did Well

The file-write path came together fast. Once the MCP server lived inside the main project, getting the write tool to reach the container filesystem was clean, and the /workspace write worked on an early try.

I also updated the prompt so the model wraps its tool call correctly, and the difference showed. That prompt change is what turned "the model talks about calling the tool" into "the model emits the JSON that fires it."

What Needed Correction

The local model is still the weak link. Running inference on this machine, the file-update calls are hit or miss. It proves the design works if the model is good enough. The model I can run locally is not there yet.

The Workspace Agent is a first pass. Core points at an internal container port and the handshake is fragile. I left it further along than last week but not solid.

What Shipped

Nothing to production. In prototype: Core talks to a container, a Workspace Agent writes files inside it, and the CLI drives file updates through Docker. The GCT NuGet packaging now runs on build, and the multi-database refactor has its first stub in place.

The Numbers

Category Hours
Product / Features 15h 23m
Content 14h 8m
Business 7h 34m
Total 37h 5m

Half the tracked week went to the prototype and its infrastructure. The other large block was the pitch deck, which only exists because last week's proof of concept gave me something real to pitch.


The point of DevNitro is that the agent inside the container does the building. This week the agent got hands. It can write to the project on disk.


Last week the first MCP tool call fired and a container started. The rename and working CLI came a couple of weeks before that. Open thread carried forward: a model good enough to call these tools reliably, and a Workspace Agent solid enough to trust.


Curious how this site was built?
Watch the 5-minute walkthrough at devnitro.com →

An AI built this blog (but not this post)

This entire blog system (domain models, database, services, UI, auth, etc.) was built by DevNitro on its own in 95 minutes. I recorded every second.

    We respect your privacy. Unsubscribe at any time.