Agentic programming makes me want to stop programming and also do it more

TLDR: Using agents for programming can be great, but I fear for the maintainability of the code that's produced. As I'm currently looking for work, this lets me see the value my experience can bring, while also making me fear a future to having to work with a lot of code that was quickly written but is mediocre (at best) and hard to maintain.

Three types of technical debt

Let's compare technical debt and real-world financial debt. (Aren't I "fun"?)

TL;DR:  Many developers are creating future problems for themselves because they're not thinking about the consequences of their actions. For some languages and technologies, the examples aren't great and don't teach everything that's needed to avoid future problems.

I'm going to consider three broad categories.

1. Credit card - make a deliberate choice to put something off (paying for an item/service) knowing that will have to come back to it (& pay) later, possibly with some interest.

Having a little of this is normally not a problem.

2. Loan shark - No other options when you have to do something now. It's solving a short-term problem but likely creating a bigger and more expensive one for the future.

Avoid as far as possible. (If you're in real financial debt, please talk to someone--don't struggle alone.)

3. Financially illiterate - No one ever taught you about money or saving. You spend money without thought, have multiple store and credit cards, have little or no savings, and live "pay-check to pay-check".

"This must be fine", or so you think. "Doesn't everyone live like this?" "I'm sure it will all work out in the end--somehow."

Hopefully, the comparisons are clear.

What the term "illiterate" might hide is that this isn't always the developer's fault. 

Some languages/technologies/frameworks are taught in only the most basic ways. The student is shown how to get started or do the basics, but the instructions never go beyond that.
Even examples and so-called "best practices" don't help. "Expert" code looks like beginner code, and not in a good way.

Everyone makes the same mistakes, builds up a code base with the same issues, and talks about the code/language/framework with the same complaints.
Eventually, the problem becomes clear, and someone suggests a rewrite with a different technology.

It sounds like declaring financial bankruptcy, and that future financial problems will be avoided by only trading in cash/gold/crypto. 

Is it the technology/medium that's the problem? Or is it how it's used?

If you're learning, are you learning how to do something without creating future problems for yourself?

If you're teaching, are you setting up your students for long-term success?

If you're creating a language/technology/framework, are you doing so in a way that encourages doing things in ways that avoid long-term problems?

Choosing a framework to build a native app on Windows with .NET

By "Native," I mean not using web technologies, either as a remotely hosted website or bundled into a package that is installed and runs locally.

Let's get this out of the way first. 

There is no "best". 

There is only best for your current circumstances and requirements at the current time.

That said, how do you decide what might be best for your circumstance?

Each option has slightly different capabilities. It's essential that you know what capabilities you'll need before you start building. If you don't know what you need to build, it's impossible to say which is best for you. This may make the decision for you. 
Doing the work in advance to fully understand the requirements can save a lot of frustration and wasted time and effort if you discover you need something the framework can't do. 

So, second disclaimer out of the way, how do you decide which .NET framework to evaluate first? 

If the first thing you evaluate does all you need, it's probably fine to go with that. If not, try another.

Q1. Do you think you might ever need to run on more than just Windows?

If Yes - go to Q2.

If No, go to Q4.

Q2. Do you want the software to also run on the web?

If Yes - Evaluate UNO Platform first.

If No - go to Q3.

Q3. Are you primarily interested in building an app that runs on desktop, or on mobile devices?

If Desktop - Evaluate Avalonia first.

If Mobile - Evaluate .NET MAUI first.

Q4. Do you already have any existing apps built with WinForms, WPF, UWP, or WinUI?

If Yes - continue using that. (Unless it's UWP, then go to Q7.)

If No - go to Q5. 

Q5. Are you building a "traditional line-of-business" app or something that could be described as "forms over data"?

If Yes - go to Q6.

If No - go to Q7.

Q6. Are you happy to use/learn XAML?

If Yes - evaluate WPF first.

In No - evaluate WinForms first.

Q7. Do you need to support XBox devices, game pad controls, or ink-based input?

If Yes - evaluate UWP first.

If No - evaluate WinUI first.

Happy evaluating!

Yes:

• The above is probably an oversimplification.
• There may be many situations where you don't go with the first suggested option above.
• It doesn't consider personal preference. But if you already have a preference, you should probably use that. (Assuming it can do all you need).
• I haven't considered support for different programming languages. (But you're almost certainly using C#).

This isn't intended to be a definitive guide. Without knowing your exact requirements, existing skills, and preferences, I can't say for sure. 

I just wanted to share some simple questions that others have found helpful when overwhelmed by the options available.

What does it mean to "design" an app?

We use the word "design" for lots of different things and in lots of different ways. 

Not all meanings are the same. I think we'd benefit from clarifying what we mean when we say the word, or we could use different (or additional) words.

The dictionary has lots of meanings for "design".
I like the broad definition of "to intentionally create something to meet pre-defined requirements."

I think of design as more than how something looks; it also includes how it works, behaves, and is used.

A "good" designer can create something that looks nice.

A "great" designer can create something effective, effortless, pleasurable, and desirable to use.
This typically involves more than just how it looks and is intrinsic to a thing, not something that's added at the end.

When "designing an app", what are the different people involved doing?

During the "design phase," what are different people doing?

If doing anything relating to the UI, does that count as "design"?

Is design something that's done to a piece of software once it technically works so that it looks nicer?

When is "design time" from a coder's perspective? Is it all the time up until they start running (or debugging) the code?

Is design something we work as a team to do, to produce the [best] final product?

Is design only about colors and shapes? Or does it require a lot more thought and iteration to do well?

When we talk about "designers" referring to people and roles, we frequently add extra words to make it clear what type of designer we mean, or the type of designing they're doing.

When we talk about "designers" referring to tools, there often isn't the effort to clarify. Should there be? Is what you mean by a designer the same as what I mean by a designer? Depending on context or circumstance, probably not.

What do we mean by "design", and what do we expect from a "designer"?
 - I'm sure I'll keep coming back to these questions.

I am not a futurist

10+ years ago, I thought the future of app complexity could be solved by having text- and therefore also speech-based interfaces. I built a concept of an app that used this as a way of interacting with multiple social networks and news sites.

5 years ago, I thought the vast array of partially overlapping functionality in the multitude of apps could be addressed by having apps that offered extensibility points to allow different apps to provide specific functionality that was all consumed from one (or a few) place(s).

I couldn't persuade people that a text-based interface as the primary way of interacting with complex apps was the future. Nor were they convinced that my prototype could scale to more complex and varied input.

Rather than offer extensibility, app developers wanted to "own it all" and do everything themselves. The dream of controlling (& therefore monetising) everything was too appealing.

Now we're told that "Agentic AI is the future." Apps will all become agents, and we'll do everything through a chat interface.

Obviously, I see the parallels with my examples above.
But I don't see that as the one scenario to rule them all.

The use of "Agents" in AI/LLMs (probably connected via MCP) definitely has a place in the future and addresses some of the scenarios that AI (and even possible future General AI) could never do.

However, just because something new comes along doesn't mean everything that went before becomes obsolete and redundant.
Some of the things that can now be done with agentic AI may provide a better alternative than what was available previously. Some things will still be better, easier, or even faster with a dedicated solution and a non-text-based interface.

It's great to be excited by the new and the shiny, but that doesn't always mean the replacement of everything that went before.

---

I wonder what other abandoned side-projects I have that will turn out to be relevant in the future?

I hope that not all of my predictions about what's coming soon are as far out as the two I mentioned above.