How Uno Platform developers keep AI-written .NET code trustworthy

Uno Platform's Matt Mattei explains how he checks code that AI agents write for .NET and Uno Platform apps. He combines written specs, runtime checks, lint hooks and change-cost probes. The post gives working .NET developers a concrete review checklist for agent-written features.

Key points

• Write a spec before each feature and settle assumptions in an Unresolved Questions section.
• Verify loading, empty, error and recovery states in the running app, including that a double click saves once.
• Compare the agent's assumed business rules, such as discount and tax order, against the actual product requirement.
• Report build, test and lint results for each change, and explain any check that could not run.
• When a rule is repeated as text in several places, add a check so the copies cannot drift apart.
• Mark workarounds with a comment that names the gotcha and the condition for removing it.

The author judges AI-written code by two questions: how far can I trust this feature today, and how easily can someone change it tomorrow? Every feature starts with a spec that lists open questions, and loading, error and retry behavior is defined up front. A separate QA agent then tries failure scenarios in the running app. A lint hook reports convention breaks, such as platform branches inside models or blocking waits on tasks, along with suggested fixes.

The main lesson is that passing tests are not enough. If an agent makes a wrong assumption, code and tests can agree with each other while both contradict the product. The author asks for evidence per change, requires a completeness report before anything is called done, and waits for approval before adding dependencies or changing public APIs. The post links to the rules and skills he uses.

Real-world use

• Having an agent build a form in an Uno Platform app, then checking save, validation and error recovery in the running app.
• Reviewing agent-written ViewModels in a shared MAUI or Uno codebase against platform-neutrality rules.
• Estimating which files and tests a validation rule change would touch before the work starts.

Why it matters

When an agent builds a .NET feature, compiling is not enough: you need evidence for the rules, failure paths and future change cost. This makes the decisions the agent made silently visible during review.

Related stories

• CritterWatch 1.1, Bobcat 1.0 and AI Skills 1.17 ship; Stoat preview arrivesJXJasperFx (Critter Stack) Blog6 d ago
• How to Review Claude-Generated .NET Tests for Real Regression CoverageDLNick Cosentino (Dev Leader)Oct 25
• From Local RAG to an AI Agent in C# with Ollama and Qdrant – Part 3OBOttorino Bruni1 d ago