Creating .NET apps takes forever - then we tried AI

Building .NET apps can take forever. Creating projects, configuring middleware, wiring up Entity Framework. But AI changes everything. Let us show you how to build a real .NET app from scratch using AI.

The initial prompt

Our initial prompt to Claude was straightforward:

Build me an ASP.NET Core Web API ticketing system. Ask me any questions that you need to know the answer to.

It then asked some follow-up questions.

• What kind of tickets are these for? We selected Customer support.

• What features do you need? We selected Ticket comments/notes and file attachments.

• What data persistence do you want? We selected Entity Framework Core + SQL Server.

The end result

It created the application. But there were some obvious gaps.

• There were no database migrations, which made setting up the schema difficult.

• Unit tests were missing.

• Several DTO types had been bundled into one file.

• It had used controllers, where we would have preferred Minimal APIs.

To be fair to Claude, it had made some reasonable assumptions - like using clean architecture. We do prefer this but did not ask for it specifically.

This is the ultimate problem. Vague prompts produce vague results.

Compile issues

We went back and forth fixing issues.

• A missing using xUnit statement was causing compile issues.

• The connection string was pointing to localhost, but we had LocalDB installed.

• Migrations ran without an error, but no tables were created in the database.

Each fix required another prompt, another download, and another round of checking. It was not the most efficient way of working with AI.

The better approach: technical documents

Rather than prompting on the fly, we decided to create two technical documents which you can view when you download the code example. We fed these to Claude to get a better solution.

• An application spec defining the framework (.NET 10), API style (Minimal APIs), naming conventions (file-scoped namespaces), architecture pattern (clean architecture), and a requirement to use the most up-to-date NuGet packages.

• A database schema document laying out exactly how we wanted the data model structured.

We then created a Claude Project, uploaded both documents and ran the same prompt.

Significantly better results

The difference was immediately noticeable. Claude asked sensible clarifying questions based on the documents.

• It wrongly flagged that the extension member syntax was a C# 14 preview feature and asked whether we wanted to use it. We told it to go ahead, as it is not a preview feature.

• It questioned a RelatedTicketId field that we had in the schema. We agreed we did not need it and removed it.

• It also asked whether we wanted separate endpoints for modifying the status and marking a ticket as complete, as that is how it appeared in the document. We confirmed that we did.

The resulting project was substantially better.

• It produced the Visual Studio 2026 .slnx solution file. The previous prompt had used the old .sln file from VS 2022.

• Minimal APIs were used throughout.

• File-scoped namespaces were applied consistently.

• Clean architecture was properly implemented across the projects.

What needed manual intervention

Even with the improved approach, a couple of things required a hands-on fix.

• The xUnit version was a few versions behind.

• The [Fact] attribute issue from the first attempt reappeared. Claude fixed it quickly once prompted, but it is worth noting this as a recurring quirk when it generates xUnit-based test projects.

• The migrations caused trouble again. Rather than going back and forth trying to get Claude to regenerate them correctly, we simply asked it to remove the migrations entirely and ran them ourselves. That resolved it cleanly, and the correct schema appeared in SQL Server Management Studio as expected.

The end result

With the database in place and the project building cleanly, the application worked as expected. Tickets could be created, their status could be updated, and they could be marked as complete. All the unit tests passed, too.

We did spot one oversight in our own technical document. We had not specified that customers should be able to add comments to tickets. That is a good reminder that Claude can only work with what you give it. The more precise your specification is, the less you will need to patch things up afterwards.

Watch the video

Watch this journey where we gave Claude a vague prompt and saw the issues that followed. We then gave it the same prompt alongside the technical documents and saw a vastly superior result.