A developer rebuilt an old .NET application and let GitHub Copilot handle the entire UI layer. Not as an experiment in automation, but as a test of what architecture enables AI to code effectively. The results are revealing.
The writeup on Dev.to isn't about whether AI can write code. It can. The question is: what structure does it need to succeed? And the answer changes how you should design systems.
What Actually Happened
The developer separated business logic from presentation completely. Backend services handled all operations. DTOs (Data Transfer Objects) defined clear contracts between layers. Then, instead of asking Copilot to generate HTML, they described data layout and relationships.
"Show this collection of items with these properties. Group by category. Add pagination."
Copilot generated functional Razor Pages markup. Not perfect, but scaffoldable - good enough to build on without starting from scratch. The key wasn't smarter AI prompting. It was clean separation that gave the AI clear boundaries.
Why This Approach Works
AI coding tools struggle with ambiguity. When business logic bleeds into UI code, or when responsibilities aren't clear, suggestions become inconsistent. The AI can't tell what matters.
But when you define clear contracts - "this DTO has these fields, render them in this structure" - Copilot has enough context to generate useful code. It's not magic. It's reducing the problem space until pattern-matching becomes effective.
This mirrors what experienced developers have known for years: clean architecture makes everything easier. The difference now is that "everything" includes AI assistance. The separation of concerns that made code maintainable also makes it AI-scaffoldable.
The Practical Pattern
Here's what worked:
Separate business logic completely. Services handle operations. DTOs define data shape. UI code only renders. When Copilot sees a DTO, it knows exactly what data is available. No guessing about what methods exist or what's in scope.
Describe layout, not implementation. Instead of "create a table with these columns", say "display this list of items, each showing name, date, and status. Sort by date descending." Let the AI choose the markup. You'll refine it anyway, but starting with structure beats starting blank.
Use DTOs as contracts. Every DTO becomes documentation the AI can read. When you ask it to render a CustomerSummaryDTO, it sees the properties and generates markup accordingly. The stricter your data contracts, the better the suggestions.
What This Means for Developers
If you're building systems that will involve AI coding - and increasingly, that's everything - this pattern matters. Architecture that's good for humans is also good for AI. Clear boundaries. Explicit contracts. Separation of concerns.
This doesn't mean AI writes your code for you. It means AI handles the tedious scaffolding while you focus on what's actually interesting: business logic, user experience, data flow. The grunt work of translating DTOs into markup? Let the AI do it.
For business owners commissioning software, this changes project economics. Good architecture used to pay off in maintenance costs years later. Now it pays off during development by enabling faster iteration. The upfront cost of clean design becomes a productivity multiplier.
The Broader Pattern
This isn't just about Razor Pages or .NET. The same principle applies across stacks: AI tools work best when you've already done the hard thinking. They excel at pattern-matching and boilerplate. They struggle with ambiguity and novel problems.
So the skill becomes: structure problems in ways that let AI handle the mechanical parts. Define clear interfaces. Separate concerns. Make implicit knowledge explicit. Then let the tools generate the tedious bits.
That's not laziness. It's leverage. And it requires more architectural thinking, not less. You need to understand the problem well enough to define clear boundaries. The AI just fills in the gaps.
The developer who ran this experiment didn't discover a trick for getting AI to write code. They demonstrated what's always been true: good architecture makes everything easier. Now "everything" includes the AI sitting in your editor.