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.

From the Backlog to the Build Log

Week of December 26 - January 1, 2026

What I Worked On

This is the week DevNitro started creating sites. Not a demo of the idea, an actual run: the CLI takes a request, uses the BlankSite template, and produces a working .NET site. I spent 22 hours on the create-site tool and got it generating multiple demo sites, including a working Todo app.

The other big thread was visibility. When an agent is working, you should see what it is doing. I added real-time tool-call events across all providers, a tabbed Details and Logs panel in the console UI, and made the LLM response render its text and tool calls in the order they actually happen instead of clumping them at the end. I also centralized tool-call extraction behind a JSON-aware parser so every provider reports the same way.

Underneath that, I implemented API versioning across the platform, moving every endpoint to /api/v1 and modernizing the OpenAPI docs with a Scalar UI.

What the AI Did Well

Adding specialized agents is starting to pay off. I stood up a styling agent and a docs agent this week, each with its own configuration, so the main agent can hand off work instead of trying to do everything. Improving the system prompt around context discovery and file-operation rules made the agent noticeably better at finding its bearings in a codebase before it starts editing.

Real-time tool-call events were fiddly across three providers, and the AI worked through the differences with me, including the session-resume support that stateful models need.

What Needed Correction

The API was throwing 404s on routes that should have worked. The cause was a chain reaction from the security lockdown: once I defaulted everything to authorized, a class-level [Consumes] attribute on the controllers started rejecting GET requests that had no body. I removed it, added [Produces] where it belonged, and cleaned up [AllowAnonymous].

The create-site runs were not clean either. The Claude SDK kept hitting a prompt-too-long error, and I burned real time getting it to use the latest BlankSite template instead of a stale one. And every attempt to record a screen demo of a generated site failed for one reason or another.

What Shipped

DevNitro generates working .NET sites from the BlankSite blueprint, including a Todo app I could click through. Tool calls are visible in real time in the console UI. The API is versioned at /api/v1 with modern OpenAPI docs and a Scalar UI. There is a styling agent and a docs agent. And provider session resume works for stateful models.

On the business side, I put together a pitch deck and walked two people through it, using screenshots from the generated Todo app. The honest feedback: a Todo app is not the demo that sells this. Fair. It was just the first thing that worked well enough to show.

The Numbers

Category	Hours
Product / Features	45h 28m
Content	5h 11m
Business	1h 20m
Community	1h 14m
Total	53h 14m

Twenty-two of the fifty-three hours were the create-site tool, with real-time events and API versioning taking most of the rest. A few hours went to pitch prep.

AI site generation is easy to fake in a demo and hard to make real. The gap between them is the week I just spent: blueprint handling, prompt limits, versioned APIs, and being able to watch the agent work instead of trusting that it did.

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

January 2, 2026 Build Log: DevNitro Starts Generating Sites