From Writing Code to Directing Agents: What MAUI Day Reinforced About AI-Driven Development

I went to .NET MAUI Day in Skopje because of the technology.

More precisely, I went because of OpenSilver and its connection with .NET MAUI Hybrid. I wanted to better understand .NET MAUI, what is changing in .NET 11, what the people working on the platform are thinking about, and how those changes may affect the wider .NET and XAML ecosystem. Another important goal was to catch up with Gerald Versluis (Software Engineer at Microsoft), start a discussion about AI-Driven Development, and get his take on the topic.

I wrote about the MAUI Day in Skopje event itself, the speakers, the community, and my personal impressions in a separate article on ITuziast.

But one topic from that day deserves a separate discussion. It is not really about .NET MAUI. It is about how software development is changing.

During one of Gerald Versluis’ sessions, the discussion moved from MAUI features into AI-assisted engineering and a tool called MauiDevFlow. The idea immediately got my attention because it addresses something I have been thinking about and experiencing in my own AI-Driven Development work:

The important question is no longer only whether AI can write code. The more important question is whether AI can participate in the complete engineering feedback loop, or what’s the best way to talk to the machine to get the most from it.

That is a much bigger change.

1. AI Writing Code Is Already the Old Part of the Story

Today, asking an AI coding agent to implement a class, API endpoint, form, unit test, database migration, or even a relatively complex feature is no longer extraordinary.

We already crossed that line.

Tools such as Cursor, GitHub Copilot, Claude Code, and other coding agents can read repositories, modify multiple files, run commands, generate tests, and help prepare pull requests.

This is why I prefer the term AI-Driven Development (AIDD) when AI becomes part of the actual delivery process, not just an assistant used occasionally for code completion.

2. The Missing Part: Can the Agent See What It Built?

One weakness of AI-assisted software development is easy to overlook.

An agent can generate syntactically correct code and still have a poor understanding of what the running application actually looks like or how it behaves.

It may compile successfully. The tests may pass. The pull request may look reasonable. And the application can still be wrong. This is especially obvious in UI development.

Imagine that an AI agent creates a screen. It has access to the XAML, view model, navigation logic, and perhaps screenshots from the specification. But after the application runs:

• a control may be positioned incorrectly;
• a button may not be reachable;
• the visual hierarchy may be poor;
• text may overflow;
• navigation may behave incorrectly;
• an interaction may work technically but feel wrong.

A human developer sees that immediately.

The agent usually does not—unless we give it a way to inspect and interact with the running application. That is why MauiDevFlow caught my attention.

MauiDevFlow was created specifically for agentic development workflows. It lets AI coding agents build, deploy, inspect, interact with, diagnose, fix, and repeat against a running .NET MAUI application. Its tooling exposes capabilities such as visual-tree inspection, screenshots, querying UI elements, tapping controls, filling fields, scrolling, and interacting with the running app through an MCP-compatible interface. The original repository has since moved into the .NET MAUI Labs repository.

This changes the development loop.

Instead of:

prompt
⬇️
generate code
⬇️
human checks result

we can move toward:

goal
⬇️
agent implements
⬇️
application runs
⬇️
agent inspects
⬇️
agent identifies problem
⬇️
agent corrects
⬇️
human verifies

That is much closer to an engineering workflow.

3. The Feedback Loop Is More Important Than the Code Generator

Software engineering has always depended heavily on feedback loops.

1. A developer digests the specification/requirements.
2. A developer writes code.
3. The application builds.
4. Tests run.
5. The developer executes the application.
6. Something is wrong.
7. The developer debugs it.
8. The code changes.
9. The cycle repeats.

Good development tools reduce the cost of that loop. This is one reason another session at MAUI Day connected so well with Gerald’s discussion.

Stéphane Delcroix presented the improvements coming to XAML in .NET 11. One of the features that interested me most was the new XAML Incremental Hot Reload engine.

Microsoft describes it as a way to apply XAML changes to existing live instances of pages and controls without recreating the page. Supported edits can include changes to properties, bindings, resources, and parts of the visual tree.

At first glance, Hot Reload and AI agents may look like unrelated topics.

I do not think they are. Both reduce the time between making a change and understanding its result.

Hot Reload improves that loop for the human developer. Tools such as MauiDevFlow can potentially improve that loop for the AI agent. That is the part I find more interesting than the current discussion about which AI model generates better code.

The future competitive advantage may not come from the agent that writes the most lines of code. It may come from the engineering environment that allows the agent to receive the best feedback.

4. I Am Seeing the Same Shift While Building MK Music Archive

This idea resonated with me because I am currently experiencing something similar while building Macedonian Music Archive (MKRockArchive codename), a registry for Macedonian music heritage. It is a serious software project.

The architecture includes .NET 10, ASP.NET Core, Blazor, PostgreSQL, Identity, REST integration, publication workflows, auditability, evidence management, structured domain entities, and a WordPress-facing publication layer. After the MVP and putting it in production, it might invoke .NET MAUI.

I am also using AI heavily in the implementation process.

However, I did not start by telling an agent: “Build me a registry.”

The majority of the important work happened before production implementation started, and I used Sol and Astra heavily.

• I worked on the philosophy and the vision for the system
• I worked on the domain model.
• I defined metadata rules.
• I documented workflows.
• I made architectural decisions.
• I specified the database model.
• I defined security requirements.
• I documented REST API boundaries.
• I established repository structure, coding conventions, testing rules, environment configuration, and implementation constraints.

Only when those rules became sufficiently explicit did I consider the system ready for AI-first production implementation.

This is an important distinction. AI did not eliminate software architecture. It made architecture more important.

5. The Developer Is Moving Up the Abstraction Ladder

During the first part of my career, I spent many years as a professional developer.

The work was very implementation-heavy.

• I wrote the code.
• I designed database tables.
• I created stored procedures.
• I built UI screens.
• I debugged applications.
• I integrated systems.

Later, my career moved toward architecture, product management, project management, requirements, and delivery.

Now AI is creating an interesting convergence between those two parts of my career.

When I work with an AI coding agent today, I increasingly spend less time typing implementation details (not to say I don’t write code at all) and more time defining:

• what should be built;
• why it should exist;
• which architectural boundary owns it;
• which dependencies are allowed;
• what must never happen;
• how the result should be tested;
• what evidence is required before the work is accepted.

This does not feel like “less engineering.” It feels like engineering at a different abstraction level. The code is still important. But implementation is becoming cheaper. Judgment is not.

6. The Faster the Agent Works, the More Dangerous Ambiguity Becomes

There is also a downside to all of this.

A human developer who misunderstands a poorly defined task may spend half a day implementing the wrong thing. An AI agent may implement the wrong thing across twenty files in five minutes. Speed amplifies clarity. It also amplifies mistakes.

This is why I strongly disagree with the idea that AI-driven software development means reducing specifications. In many cases, I believe the opposite is true. We need better specifications.

Not necessarily 300-page traditional specification documents that nobody reads. (If it’s hard for a human to read and digest 300 pages, for AI Agents that could be a piece of cake.)

But we need explicit context.

• Clear boundaries.
• Acceptance criteria.
• Non-goals.
• Architectural rules.
• Definitions of done.
• Test expectations.
• Agent instructions.

These things become the contract between human intent and machine execution.

In my current workflow, I consider an implementation task ready for an AI coding agent only when I can explain clearly enough what the agent may change, what it must preserve, and how I will determine whether the result is correct.

If I cannot do that, the issue is not ready.

7. Human Review Is Not a Temporary Limitation

There is a tendency in AI discussions to assume that human review is something we need today only because the models are not yet capable enough.

I am not convinced.

The need for human judgment is deeper than detecting syntax errors. Software exists inside a business context. Someone must decide whether a requirement makes sense. Someone must understand trade-offs. Someone must decide whether technical debt is acceptable. Someone must notice that a technically valid implementation creates a poor user experience. Someone must take responsibility for security, maintainability, cost, regulatory constraints, and the long-term consequences of architectural decisions.

AI can help with all of those tasks. But responsibility remains human. At least, that is how I design my current AIDD workflows. The human is not there simply to approve the pull request. The human owns the system.

8. Software Architects May Become More Important, Not Less

I find this particularly interesting from the architecture perspective.

For years, many software teams moved away from dedicated architecture roles. That was often a healthy correction. Architecture should not become an ivory-tower activity where someone produces diagrams and disappears while developers deal with reality.

But AI-driven development may increase the need for strong architectural thinking again, since it addresses one of several important perspectives that must be tackled when developing bespoke software.

An AI agent needs boundaries.

For example:

• Which layer may access the database?
• Which project owns the business rule?
• Can the Web layer call Infrastructure directly?
• Which operations require transactions?
• Which entities may be published externally?
• Which credentials may be used in each environment?
• What data may appear in logs?
• Which command-line options must fail closed?
• Which tests are mandatory before a pull request can be accepted?

Without those answers, the agent improvises. Sometimes its improvisation is impressive. Sometimes it is technically clever. And sometimes it quietly destroys the architecture.

A senior engineer or architect increasingly becomes the person who creates an environment where humans and agents can consistently make good decisions.

That is a valuable role.

9. We Should Measure AI Development by Verified Outcomes

This also changes how I think software teams should measure AI productivity.

“How much code did the AI generate?” is almost useless.

Even “How much faster did we implement the feature?” is incomplete.

I would rather ask:

• Was the feature correct?
• Did it respect the architecture?
• Were the tests meaningful?
• Did we introduce technical debt?
• Did the agent require heavy rework?
• Could the system inspect or verify its own output?
• How much human intervention was needed?
• Did the final implementation satisfy the acceptance criteria?

This is where tools that improve agent observability become important.

Microsoft’s .NET MAUI engineering team has publicly demonstrated MauiDevFlow specifically around AI agents inspecting and interacting with running applications, including visual-tree inspection and the build-deploy-inspect-fix loop.

That loop is the interesting part. Not “AI wrote the code.”

AI produced something, observed the outcome, learned from the outcome, and tried again.

That begins to look more like software development.

10. AI-Driven Development Is Not About Removing the Engineer

I expect software development to continue changing quickly. Regardless of the latest ideas for “slowing down” AI development – whatever that means. We will almost certainly see agents gaining better access to:

• runtime applications;
• logs;
• telemetry;
• browser automation;
• test environments;
• databases;
• issue trackers;
• build pipelines;
• deployment environments;
• monitoring systems.

The agent will increasingly be able to move through more of the delivery lifecycle independently.

That does not mean we should remove the engineer from the process. It means we should reconsider what the engineer is responsible for. I believe the professional software engineer is moving from primarily producing implementation toward increasingly owning:

intent, system design, constraints, context, quality, verification, and decision-making.

Different projects will move at different speeds. Some systems are simple enough that an agent may own almost the entire implementation loop, especially if you can give it a hint to create something that already exists and is well known. For instance, “Build me MS Paint.” or “Build me Pong.”

Enterprise systems with security requirements, integrations, legacy constraints, multiple stakeholders, and years of expected lifetime will require considerably more discipline.

But the direction is becoming clear.

11. My Biggest Takeaway From MAUI Day

I attended MAUI Day to learn about the latest .NET MAUI and meet the local community.

I left thinking much more about AI-driven development. That is often the value of a good technical event.

You go looking for one answer and come home with a different question.

For me, that question is no longer: Can AI write production code?

Yes. It already can. I know that very well. The questions I find more important are:

• Can the agent understand the environment in which that code executes, and how to approach the agent to get the best results, in the right context for the least possible tokens?
• Can it observe the result?
• Can it verify whether the implementation satisfies the goal?
• Can we give it enough architectural context and constraints to make consistently good decisions?
• What is the best possible and most optimal approach to achieve high-end results?

And ultimately:

Can we design a software delivery system where AI performs more of the work without humans losing control of the outcome? What skills should I develop, and what methodology will work ideally (currently applying the known approaches as the bespoke software development industry has for decades)?

That is the version of AI-Driven Development I am interested in. Not AI replacing software engineering. AI changing where software engineering happens.

---

☕ If you find this content helpful, you can support my work with a coffee on Buy Me a Coffee.