One week with Claude Code: turning a personal legacy project into a deliverable product — NebuLog v1 to v2

Live demo: nebulog.imady.co.nz — choose "Continue as demo visitor"; no sign-up is required. A walkthrough is on our live demos page.

1. Background

Software developers, I suspect, are neither as rational nor as efficient as most people imagine. We are prone to simple, rather impractical ideas. While a program runs, we want to see what the application is doing, the path it has taken, and the log messages that would help us debug it — yet we are reluctant to use an existing tool, even a free one, and would much rather build our own.

My first attempt at this dates from 2014. I was developing the application for Nanchang Tianrui's "Dazhong Jingjiren" property-agency project. The server's disk was small, there was nowhere to keep the logs, and the application's state was awkward to monitor, so I wrote a small tool, TRLogger, that sent the server's logs straight back to a local machine.

In 2018, prompted by a blog post about SignalR, I began a tool that streams an application's logs to a web browser in real time. It was first called MYLogger (MY standing for Suzhou Meiyu); the first version took about two weeks and used ASP.NET MVC for the front end. In 2019 I renamed it NebuLog — Nebula Logger, a suitably grand name — and over time added implementations for WPF, Blazor and even the Unity engine, where logs could be displayed live inside a 3D scene. In 2020 NebuLog was included in the GitHub Arctic Code Vault. The original version is described in my Zhihu column (in Chinese).

NebuLog has never been a commercial project; it exists out of interest in the technology. In that Zhihu series I wrote: "NebuLog is not a well-planned project with a clear product vision. It is an improvised, exploratory project, intended to learn the structure and runtime behaviour of various Microsoft technologies by implementing NebuLog in each of them." There is, however, an agreeable coincidence: a few years after NebuLog began, Microsoft released the Aspire Dashboard with .NET 8, which likewise lets developers watch logs in real time. Evidently, observing a program live during development is a genuine and widely shared need.

This rebuild was carried out with the Claude Desktop App, and I was impressed by how quickly it read legacy documentation and grasped the project's requirements. (Incidentally, I do not subscribe to the idea of "vibe coding". In serious software development, at least, a feeling for the code is no substitute for engineering discipline.)

2. Where NebuLog v1 Fell Short

We now refer to everything NebuLog was before 2026 as v1. In hindsight it addressed a real use case, but as a mature product it was incomplete:

• A log list, but no overall view. The dashboard's statistics panels were never finished. Users could see individual entries but not how the system was behaving as a whole.
• Slow under volume. Beyond ten thousand entries the page slowed noticeably. I had already thought of using a ring buffer in the front end to fix this, but never found the time to implement it.
• No industry standard. v1 used its own data format, derived from the log levels defined in ASP.NET Core. It worked only with NebuLog's own components and was difficult to connect to the wider observability ecosystem.
• Hard to try and adopt. The public sample applications were out of date, and a newcomer who cloned the repository would struggle to run it locally, let alone grasp what it did within a few minutes.
• No users or permissions. This was simply never built. Any NebuLog client could see everything, which made it unsuitable for teams or public use.
• An ageing foundation. v1 was first built on .NET Core 2.0 and last updated to .NET 6 in 2022, and some front-end components carried security risks from age. Maintenance was becoming increasingly costly.

3. Goals for v2

In 2026 I finally returned to the idea of upgrading and rebuilding NebuLog v1. v2 does not aim to be larger. It takes v1's functions and positioning as its anchor and turns them into a lightweight, reliable tool for developers, compatible with the mature releases of .NET. There were three specific goals:

1. Continuity of function. Retain v1's core value: logs streamed live to the browser, embeddable in any .NET application, with two-way communication between the developer and the program.
2. Modern technology. Upgrade fully to .NET 10 and React 19, and deliver authentication, permissions, automated testing, continuous integration and containerised deployment to production standards.
3. Standards compliance. Follow OpenTelemetry, the industry's common observability standard, in full. Any application that follows the standard, in any programming language, can connect to NebuLog directly — and to Microsoft Aspire or other tools at the same time.

Equally important was deciding what not to build: no database storage, no large-scale clustering, and no attempt to cover every kind of telemetry. For a project whose purpose is learning and demonstration, a clear scope is what makes reliable delivery possible.

4. How It Was Done: Guided by BRIPA, Executed by Cooperating and Cross-Checking AI Agents

The framework: BRIPA

In my master's thesis in software engineering I proposed an implementation model called BRIPA, with five stages: Baseline, Referencing, Interact, Prototyping and Advancement. Its central claim is that when requirements are difficult to state in advance, it is better to produce a working version early and treat the software itself as the basis for the next round of requirements than to write a lengthy specification. With the rapid progress of AI-assisted programming, this project gave strong support to both the efficiency and the reliability of that approach.

The rebuilding of NebuLog followed the five stages of BRIPA.

1. Baseline — start from existing software. v1 was a ready-made baseline that had already run in practice. It made the requirements complete and concrete from the first day: what to keep and what to improve could be read directly from v1. Every field that v1 recorded found a corresponding place in v2, so no requirement was lost. Just as importantly, a baseline made "better" measurable.

2. Referencing — align with industry standards. Using the OpenTelemetry standard and Microsoft's official components as references, we settled on one principle: the application side follows the standard completely, and NebuLog implements its own features only at the extension points the standard provides. This secures compatibility while preserving what is distinctive about the product.

3. Interact — human judgement at the decisive points. The project's positioning was revised three times, each time by human judgement. The AI first proposed narrowing the scope to avoid overlap with Microsoft's product; I made clear that NebuLog was never intended to compete. It then planned too many technical components; I reduced them in line with the market and the budget. On the question of how to adopt the standard, I observed that relying solely on official components would weaken the project's value as a demonstration, which led to the final design.

4. Prototyping — the release is the prototype. After v2.0 went live, I noticed that the online demonstration conveyed far less than v1's old screenshots. That observation led directly to v2.1: a public landing page, eight guided demonstration scenarios, and a "demo shop" made of two services. A visitor who clicks "Checkout" once can watch that request travel across both services in the console. The new requirements were discovered by using the existing software.

5. Advancement — continued iteration. The next version is planned to receive more kinds of runtime data. Candidates include stronger real-time redaction of sensitive log content (already confirmed as a separate project, NebuRedaction), re-implementing v1's many samples, and renewed support for the Unity engine.

The team: AI software engineering with one person and several AI agents

The development work was carried out by three AI agents and me, each with a defined role:

All cooperation was governed by written documents. Every task had a work order stating its background, its scope and its acceptance criteria — the only definition of "done." On completion, the executing agent had to report against each criterion and record any deviation and its reason.

Cross-checking: the key to reliable delivery

The real value of this arrangement lies not in speed but in the fact that each party's work is checked by another:

• Planning checks execution. In its independent acceptance of the live system, the planning agent found problems that neither testing nor code review had caught, such as written descriptions that did not match the actual implementation. The principle that followed: the party that writes the code does not accept its own work.
• Execution checks planning. Where a work order's assumptions did not match the real technical environment, the executing agent was entitled to amend it and record why. About twenty such amendments were made; all concerned implementation details, and none touched the scope of requirements — exactly the stability a good baseline provides.
• Infrastructure and planning check each other. Each identified oversights in the other's deployment plan, removing risks before anything went live.
• The checks themselves are checked. The most valuable lesson of the project is that a check reporting "passed" is not necessarily checking anything. We therefore agreed that every automated check must first be shown a deliberate error, to prove that it actually detects problems.
• Acceptance in the real environment. Beyond automated testing, we scripted a complete walk through the live site, exactly as a visitor would take it. Its very first run found problems that the test environment could not reveal.

AI errors tend to occur where something looks correct. More careful reasoning is not a sufficient remedy; what is needed is verification that can be executed and repeated. That is why this process was designed as it was.

5. Results

v2.0 was released on 5 October 2026, two days after analysis began. v2.1 followed on 7 October, adding the landing page, several guided demonstrations and the simulated shop.

The demonstration includes one particularly clear example. The same web request, implemented in two different .NET styles, produces 15 framework log entries in one and 55 in the other. Visitors can watch the difference side by side in two windows — exactly the kind of insight a developer tool should provide.

6. What This Project Demonstrates

For imady's clients, NebuLog itself matters less than the way of working it demonstrates:

• Technical independence. From the first concept in 2014, through the first version in 2018, to the rebuild in 2026, NebuLog was conceived and implemented independently by one person, and all of its source code is public.
• Technical depth. v2 covers the principal modules of the modern .NET stack and builds its own extensions within the framework of an international standard, rather than merely calling ready-made components.
• Methodological innovation. Guided by the BRIPA model from my research, with several AI agents dividing the work and cross-checking one another as a software engineering method, the project shortened delivery time substantially without compromising quality.
• Reliable delivery. Every task had explicit acceptance criteria, every result was independently checked by another party, and every figure can be verified in the public code repository.

The same method can be applied to upgrading your existing software: take the current system as the baseline, decide clearly what to keep and what to improve, and deliver step by step in a way that can be verified.

• Live demo: nebulog.imady.co.nz
• Source code: github.com/imadyTech/NebuLog