AzureDevNexus: Designing the Review Experience Before Connecting the Model

You click Review. What should happen next?

Imagine pasting a function into a code-review tool. While it works, you want to know whether the request was accepted. When it finishes, you want specific feedback you can inspect. Tomorrow, you may want to find that same review again.

Those are three different product promises: progress, a useful result, and retrievable history. AzureDevNexus explores them with a Blazor interface, an ASP.NET Core API, review models, database-backed service code, and a SignalR notification hub.

The published revision is a prototype. Its review screen produces a local sample response, and its backend review service also uses a mock response while the Azure OpenAI integration is commented out. That makes it a useful case study in designing the surrounding experience before depending on model output. The sample scores are demonstration data, not measurements of code quality.

Follow the design in four stages

Follow the flow

What a review experience needs to communicate

Choose a step to see what happens and why it matters.

Blazor form · review input

A reader supplies code, language, and review context. The prototype checks required form fields before showing a result.

The design lessonA clear request contract helps the reader understand what is being reviewed.

Step 1 of 4

The diagram separates the paths that are easy to confuse. Indigo is the interface, amber is sample review generation, and slate is backend storage. The UI's sample path and the API's sample path are separate in the inspected revision.

The system, at a glance

Drawing the architecture…

Follow the labeled connections. On smaller screens, scroll to explore wide diagrams.

View diagram source

flowchart TD
    accTitle: AzureDevNexus prototype review paths
    accDescr: The Blazor page generates a local sample response. Separately, the backend review endpoint calls a mock review service that attempts to save results through Entity Framework and SQL Server. The diagram does not imply the page currently calls that API.
    U[Blazor review form] -->|Simulated wait| L[Local sample response]
    L --> D[Render scores and suggestions]
    A[Backend review request] --> V[Validate code input]
    V --> M[Mock review service]
    M --> S[Attempt to save review]
    S --> Q[SQL Server via Entity Framework]
    M --> R[Return review response]
    classDef ui fill:#eef2ff,stroke:#818cf8,color:#312e81
    classDef mock fill:#fff7ed,stroke:#fb923c,color:#9a3412
    classDef data fill:#f1f5f9,stroke:#94a3b8,color:#334155
    class U,D,A,V,R ui
    class L,M mock
    class S,Q data

The separation is deliberate. A screen that looks complete doesn't establish that a model request, a database write, and a notification all occurred behind it.

Start with the contract the reader can see

The form asks for a language, a review focus, optional context, and the code itself. The response model supports a summary, issues, suggestions, quality scores, a review ID, and timing metadata.

That structure is valuable before a real model is connected. It asks practical questions: can the reader locate an issue? Can they compare an original snippet with a suggested change? Does a score have an explanation, or does it merely look authoritative?

The backend endpoint validates that a snippet exists and rejects snippets over 10,000 characters before delegating to the review service. This gives the service a bounded input contract. It doesn't establish the correctness of whatever feedback the service returns.

Pause and predict: if the screen says “GPT-4,” did a model run?

Not necessarily. In the inspected page, the submit handler waits and constructs a sample response locally, including a model label. The backend separately labels its active sample path as a mock response. Displayed metadata needs to describe how a result was produced; a model name in a data object is not evidence of an inference call.

A production interface should make sample mode visible. Demonstration data is useful for evaluating layout and interaction, provided nobody mistakes it for analysis of their submitted code.

A successful review and a saved review are different outcomes

The backend review service generates its mock response and attempts to save it through Entity Framework. Its save helper logs a database error without rethrowing it. The main request can therefore return a review even if persistence failed.

That can be a deliberate tradeoff: immediate feedback may still be useful when history is temporarily unavailable. But the interface needs language for that outcome. “Review complete” and “saved to your history” should not be interchangeable.

User expectation	What needs separate confirmation
My request was accepted	Input passed validation
My review is ready	A result was generated
I can return to it later	Persistence succeeded
My teammate saw an update	Their connection received it

This is also why history is different from a live notification. A notification can tell an open screen to refresh. It is not a replacement for the saved record that a new screen loads later.

What does SignalR add?

The repository includes a notification hub with user messages, project updates, pipeline updates, and work-item updates. It also defines methods for joining and leaving project and pipeline groups. These are the pieces for sending updates to connected clients.

The interesting design question is who should receive which event? In the inspected hub, user notifications target a user group, while project updates are sent to all connected clients. Merely defining a project group doesn't mean a send method actually uses it.

Trade-off: Broadcast everything or target a group?

Decision: Make the audience part of the event contract

A broadcast is simple to demonstrate. A project-specific update needs deliberate membership and recipient rules. The transport sends messages; the application still defines who is entitled to receive them and how a reconnecting client catches up.

The review service shown above does not establish an integrated “review completed” push workflow. Connecting those components is a next step to implement and test, rather than an arrow to assume in the diagram.

Where would analytics fit?

Live updates answer “what changed just now?” Historical queries answer “what happened over time?” The review service contains methods for history and aggregates such as average scores and issue counts, using its stored review records.

Before introducing a separate analytics database, decide what the numbers mean. If the underlying review scores are sample data, an accurate aggregation of them is still an aggregation of sample data. If a save failed, history may omit a review the user already saw.

The source path discussed here configures SQL Server through Entity Framework. This walkthrough makes no ClickHouse throughput or sub-100ms delivery claim: those would require evidence from an implemented, measured path.

The next useful experiment

Connect the form to the backend and make the result's origin explicit. Then test three failures independently: generation fails, persistence fails, and a notification connection drops. Check that the UI tells the reader what succeeded and what they can still recover.

After connecting a real model, evaluate the content separately from the plumbing. A well-delivered suggestion can still be wrong. A numerical quality score needs a defined interpretation before it belongs in a trend chart.

AzureDevNexus's transferable lesson is that an AI feature has a surrounding product contract. A result, a saved record, and a delivered update are separate milestones. Designing those milestones clearly gives the eventual model integration somewhere dependable to live.

Explore the implementation

Source reviewed at revision 6ab683c: