Generative Pages and AI Model Apps

Soooo, Reza just published out this:  https://www.youtube.com/watch?v=CVjh8uaNCNI

If you haven't watched it, go ahead and then come back.  It's an overview of the upcoming "Generative Pages" feature that will use AI to build out actual pages within a Model app for you.  It literally builds out all the React code to create the web pages to alter the interactions within Model Apps for PowerApps.

That last sentence might start some of you already scratching your head, but this is a much deeper question of the future of this platform than just: do I now need to learn React?  No.  You don't.  At least not yet unless you're bored.

If you are a developer and are thinking about how powerful/efficient these tools will make you, then it is important to understand that this specific tech is intended to replace the need for you, not to make you more powerful. YMMV

Adoption of this path leads to a near-term impact most likely resulting in reduced employee salaries and paths for advancement for anyone currently utilizing the platform for non-Model applications, increased spend/opportunities for contractors and consultants using this approach.

NOTE: I will update this article probably several times as I learn more about this since this is all in pre-release right now. But I doubt my general perception of this will change.  

TLDR

If you already are using Model Apps or already paying premium Dataverse licensing for your enterprise, then go ahead and use this.  You already are overpaying your staff or consultants and your software vendor who is underdelivering so the risk is no different from what you are already doing.  Might as well roll coal at this point.

This feature lets you create/alter any PowerApps Model App (no Canvas apps) you build in PowerApps after creation to create new pages/views using an AI interface.  It will quickly build out and adjust pages to conform w/ your prompts and build out interfaces for your users that include common capabilities within React (vs. Power FX).  This means things like drag/drop and responsive designs are much "easier".  That word is in quotes because the amount of code generated by the AI to create these designs is not tiny.

This design pattern moves you into premium licensing for all users.  That means not just your developer, but all end-users must pay a premium license to connect to Dataverse.

This design also essentially requires the usage of multiple environments (Dev/Test/Prod) and the associated management that goes along with that.  This is due to Model Apps being based on database tables directly vs. the app itself.  So changes almost always change the database which means you need to have specific environmental databases since such changes are immediately "live".

The code generated cannot be edited (currently) and is not small.  Ultimately, if you choose this pattern, you should be prepared to have to ask the AI to fix any issues you encounter vs. you being able to fix it today.  IF you are ever allowed to edit the code, you will spend more time editing React code than Power FX code.  

Reza pointed out in our back/forth that this "doesn't cost anything".  Well, you have to pay the premium Dataverse licensing fee to use it.  So it does cost something if you don't do that currently.  If you're already doing that, then...this is the future you voted for.

Was I too mean?

If you take this path (Model App + AI), you are choosing a much more complicated baseline for your overall design pattern, a higher per user cost, and additional staff for managing the environments and Dataverse tables in trade for possibly lower developer staffing costs and possibly faster delivery. You are most likely trading a minimal LONG TERM decrease in labor costs (with near-term increases), large rise in licensing costs, modest decrease in delivery and less likely the correct solution deployed.

Long-term cost impacts compared to non-AI Canvas apps.  Let's make a deal!

NOTE: If you work in my own current organization, I will punch you in the throat if you try to use this approach.

The Approach: Model Apps Required

Development is now all about the database.  Not the app.  

DBAs:Yay!  

Moderator: That database is Microsoft Dataverse.  

DBAs: Wait...what?  Hey!  Does anybody around here know what Dataverse is?

If you know the Power Platform well, then you've heard of Model Apps and Canvas Apps. If you use Model Apps already then you know probably know about Dataverse.  But if you don't know what I'm talking about, then here's the gist of it.

Model Apps follow a design pattern where it is database first and the app is derived from the data.  In the 1990s and early 2000's we started to see a number of GUI development platforms that essentially took a database you'd build and then auto-generate apps on top of that.  This is a similar pattern.  You don't have to learn UI-design or practices or security, we do it all "magically" for you.

The benefit of the Model App approach is that if you are a "data person", then you can focus on the database first and foremost and then the UI just kind of appears.  The negative side of this is that you are now tied to a strict data model and most changes are done to that model first and foremost.  This means that version control for Model Apps almost always must include version control on databases.  If you aren't aware, replicating table structures or entire environments for a relational database is much more complex than say a copy of an application on your desktop.

Once upon a time, we all kind of agreed that everything should be in a relational database and all apps spawned from this.  With that perspective, this model makes sense.  However, since then, we have seen the growth of semi-structured and unstructured data storage.  Platforms for enabling these have scaled up and showed us all when/where less structured data makes sense.  Now we can create an application to solve a business problem before we really know what data is going to be important.  On this platform, that means you use the Canvas App approach.

The key problem that Model Apps really have is that once deployed they are more difficult to change (by comparison to Canvas) without a tight change control process layered on top of them.  You really must have multiple environments and multiple database versions within them to properly do this.  The best results from any Model App is one with tight requirements.  If you aren't tightly scoping your PowerApp development, then that will have to change.

While this approach claims to simplify your development, it actually forces you into a world where your back-end workflow is now more complicated and the front-end more traditional (project management, scope, etc).  Sure you can automate some of this as you go forward, but you must follow a more "classic" development structure of environments (Dev/Test/Prod), deployment, pipelines, and project management.  It is still a faster version of classical software development process due to the AI tools and a slightly more confined delivery since it is within the Power Platform vs. say .NET, but it is a slower process than using the same tools without requiring the Model App design pattern.

Let me make this one real-world point re: data-first delivery: the data is always "wrong".  What I mean by this is that even if we were correct and 100% scoped everything (which has never happened in human history), then what is needed NOW will be different from what is needed at the point of delivery and then also different the day after that or next year.  There are lots of technical reasons for this, but ultimately, this pattern makes changes much harder because the data model has to change first.  This means means all reporting has to change right now, which means any other downstream systems have to change now, and everyone has to agree that now is when we can all change.  Ultimately, this slows change when we need to be accelerating.  Just...dumb.

I'm going to skip Dataverse for a moment but will come back to it.

For now, that leads us into staffing...

Questionable Staffing Requirements

This design pushes the following staffing changes: non-technical people into development roles, technical people into non-standard roles, and ultimately requires more specialized and product-specific high-dollar specialists behind the scene.

When I talked about the requirements of this model above I also called out some staffing changes.  While there are a few new ones (Dataverse SysAdmins, Dataverse Architect, Deployment Specialists), I want to call out the SysAdmin role here specifically as that's a role people are familiar with.

Not to throw shade at my SysAdmin friends and coworkers, but those roles commonly have a personality that pushes back on change and unknowns.  They want a very planned career, changes, upgrades, etc.  SysAdmins keep the lights on, so anything that risks those lights going off is something they want to block.  They aren't Luddites, but they do look sideways at these fancy gas lamps when whale oil is doing just fine thank you.  They are risk (and in some ways change) averse unless they know the change bring better stability.

Committing to this AI approach reduces the Developer role and makes it more of a Designer role.  Developers are higher paid not only because they can code, but because they are more accepting of high-velocity changes and troubleshooting of unknowns.  Designers are more about just tweaking things to the customer's specification, but are not necessarily in the same class of troubleshooting as Developers.  That troubleshooting work will ultimately fall on the SysAdmins instead.

SysAdmins certainly do troubleshoot and fix problems, but they mainly earn their pay by NOT allowing problems to happen. They do this by creating backups, ensuring patches are applied, etc.  They want stability first and foremost and their skills in this area while strong, are generally not about moving quickly as compared to others.

That being said, this space (AI) is riddled with high velocity change.  So increasing the # of SysAdmins you will now rely on for technical troubleshooting on a system that is not in their control is unlikely to make you many friends in that community.  Also, given the pressure that role is under industry-wide, this really seems unlikely to appeal to them, but also to be a role they might be forced to accept.  Some may be desperate enough to take on the role w/o job security because other areas are cutting back, but this lowers job satisfaction and raises turnover.  Is a dissatisfied workforce the one you want to rely on?

In the end, this design pattern requires more back office staff, while lowering the technical requirements (and assumedly pay) for front office developers.  It is trading the need for pseudo-developers who are also good w/ people to designers who are good w/ people, while throwing additional "monkeys" (no offense intended chimps) behind the curtain on the admin side. 

I don't know that this lowers the staffing costs unless the thought is that "anyone" in the enterprise can make an app and the Designer role just goes away.  While I know this is great marketing, I'm not sure it is a feasible reality.  Certainly, we've seen a few apps kinda get built and sorta work, but the real struggle is not so much coding as it is defining the problems and thinking through the risk/rewards of various solutions.  This just isn't something that people do every day and therefore aren't especially good at it in this context.

We have multiple doctors, nurses, and non-technical people who build small apps for their departments under our guidance.  Those last words are bolded for a reason.  They need a lot of help even thinking about what they want to build so much as why they want to build it.  They need a thinking partner as much as they need someone to technical develop something.  Maybe AI will deliver that eventually, but 99% of the time it is more of a creative journey than just "make me an app that does X".  In fact, the worst apps I have created are for people who know 100% of what they "need" and won't listen to any competing guidance.

While this might sound like I am concerned for my own role (I am not), the real question is: are we ready for these non-technical non-developers to be guided by a vendor versus an employee?  

Which also leads me to...

Cost

I've already mentioned parts of this above regarding staffing.  I think the overall staffing change for our own org (of ~40,000 people) results in a zero delta.  Less front-end people specifically needed or perhaps hired at lowered cost (assuming we fire all our current devs - not advisable btw), but more back-end people.  

It is worth understanding that these other back-office new hires aren't common staff either.  These are more specialized and therefore more costly.  This pattern requires Dataverse.  A SQL DBA is one cost, a Dataverse Specialist is another discussion entirely.  Every role and every task is now notably more complex/costly.  Sure Microsoft provides this and "manages" this, but those quotes leave a lot of things you're going to wind up managing on an overly complex platform.

However, staffing costs aren't the big deal.  The real problem is licensing.

To be blunt, the costs to our organization in licensing would be ~$500,000 additional per month in licensing.  That is ~$6 Million annually for the very first Enterprise app we decided to deploy.  

<...pause for effect...>

<...pausing long enough for you to come back from getting another coffee with optional whiskey...>

F* that and f* them for thinking this is a valid starting point.  And I do mean starting point because that's the up-front licensing cost for your first app.  Sure your next apps take advantage of that licensing and it lowers the per app cost, but that's an initial sunk cost that gives no value other than the license.  We would now be climbing out of a $6 Million hole every year to find value in our apps.  A hole I'd rather not get into.

Let me also point out the hidden trap here: this is today's pricing.

Do you honestly believe that they're going to scale AI and figure out how to make it cheaper?  Are they charging us what the computational costs are today?  The answer to both of these is no.  AI is losing money like crazy while trying to tempt us into a very high walled garden.  The real costs remain unknown.

Anybody have their electricity costs rise recently?  Lots of datacenters going up near you?  Why are you paying for their electricity usage?  

Capitalism is doing its job!  Externalities are how we make profits ya filthy commies!!!

What happens when we no longer have the local talent on staff and all of these apps are AI generated?  Do you think they won't take advantage of the walled garden we now are trapped in?  Why else do you think investors are racing to dump money into a never-ending hole with no bottom?  Are they just nice people who want to help humanity?  

NOTE:  They are not.

Faster Delivery, but Slower Changes?

NOTE: I want to be clear here, I'm about to dive into application/process changes that are truly substantive.  Not "make this blue now" kind of changes.  These are the kind of changes that impact your data source.

So using AI on top of Model Apps is definitely faster for delivering out on a basic application (assuming you've already done a bunch of work to verify the data you're building on top of is correct - which is isn't).  This method is likely fairly quick to do changes prior to a "go live".  However, due to the added complexity for deployment and multiple environments, changes might be more difficult post "go live" and deployment.  It definitely will require additional steps/staffing for deployment during this scenario for most organizations.

Depending on your own organization and your current approach, this could add delays for deployment.  If you currently use Canvas Apps and work mainly "in prod" with a single environment, then it DEFINITELY will add delays, staffing costs, and complicate deployment.  Some would argue that this is a more "professional" method.  

NOTE: As a professional, I would call those same people small minded fart sniffers to their faces while coming up with something more cutting in private.  

Regardless, the AI approach gives you a scenario where building is "faster", but making changes is more complicated (and more likely to encounter issues).

There also is a question for if "Faster Delivery" links up to your organization's own velocity.  What I mean is, I work in a hospital system.  If I deliver an app the same day it is requested, then my business partners have no idea what to do with that.  Their own velocity for understanding their own needs, reviewing an app, and giving feedback is much slower than my own development velocity.  So is it really saving us time when I still am waiting for them to review/respond?

This isn't to say that there isn't value in faster delivery, but the main benefits for fast delivery is to allow the business user to see their ideas come to life and then...change their mind.  Fast delivery is  great if it also embraces iteration.  However, as I stated above, the individual iterative deployments now take longer and more people to push them out post deployment.

NOTE: To just address the counter-argument here, yes, iteration pre-deployment is still arguably faster if the end-user is describing this well to AI and AI is understanding well.  I'm sure AI will get better over time, but end-users aren't always the best at describing what they need vs. what they want.

Is this faster?  Maybe.  Sometimes.  Depends on the app and the level of team you have in-house.

In my own organization, they seem to benefit greatly from not just velocity of delivery but the velocity of change post deployment.  And with an accelerating velocity of change, being fast to change seems to align w/ the needs just as much as speed of original deployment.

I can't definitively say that the Model App approach is slower in these scenarios.  However, i can say that given decades of doing more data model centric approaches, my current reversed approach (user/process-oriented approach) gives overall better organizational results.  I don't think the user-centered Canvas App approach delivers apps "faster" in the extremely rare case where things are 100% scoped out (welcome to Fantasy Island!), but it definitely works better for helping build the scope on the fly while we're also building out a partial solution that solve part of the problem immediately and incrementally.

I don't think anybody can wait 6 months for solutions anymore.  That is one area the AI approach and I agree on.  I think we only differ in that I also don't believe anything is ever finished and changes also need to be as fast and responsive as initial development.  Having a faster initial deployment of the wrong solution isn't what the business needs.  They need to start chipping away at the old processes while they figure out what the new one should be (and then change their mind in a few months because the requirements changed).

For me, the new application is a chance for us to recognize why we keep missing problems X, Y, and Z in our current approach.  AI is just building on top of current approaches and existing data.  It isn't making those intuitive leaps to wonder why we keep missing skin cancer diagnosis when there aren't any dermatologists on staff.  

Garbage in...you know.  Speaking of garbage...

Dataverse

Dataverse is Microsoft's managed SQL instance w/ pre-built tables/dependencies based on their Dynamics CRM platform.  It was a leftover product that Microsoft then kind of wedged into this space.  I've written about this years ago and tried to pretend it didn't exist since initially reviewing the overall lift to embrace it.

TLDR: Dataverse is a very complex platform with huge inter-related table dependencies within it that requires a good number of experts to properly manage it if you want to maintain it safely.  Of course, Microsoft will tell you it doesn't need any management (initially).

Imagine trying to get up to speed on someone's custom-built CRM after it's been running for 10 years, which essentially is what this is.  This legacy CRM database might be all things to all people, but it has caused people inside and outside of Microsoft to struggle to adapt this into something people will utilize w/ limited success.  It is deciding to drive a Semi truck to get groceries.  You can do it, but for anything that isn't a large enterprise app w/ lots of data and interdependencies, it will be dramatically more complicated than what most apps require.

If you're a consultant and like taking $ from Microsoft and organizations that don't know any better, then Dataverse is your jam.  Anyone who is thinking clearly is less excited about the entire platform.

This platform takes commitment from the entire org to get started.  While you can just deploy it w/ minimal involvement from your own staff, it will get very bad very quickly.  You will need active management of the information within it to properly utilize/secure it and that management is not cheap (in labor costs).

The platform has the same kind of features and liabilities that an ERP or an EMR might have.  It is overly built with strict structures first and foremost.  Any flexibility must be put in place by you while fighting w/ the demands of the core platform to retain its rigidity.  Oh sure, they'll give you some flex fields and those kinds of things just like Oracle.

Aren't you cute.  You just really don't know what you want to do, do you?  Here's a minimally functional semi-structured field that you can eventually discover after you've spent months learning required structured data principles.  I guess you can shove that uncertain data structure in here until you figure it out.  But hey, at least we gave you an easily referenced unique 128-bit GUID instead of a simple "ID" field when pointing at your record.  Imagine how easy it will be to point at this instead of a simple incremented integer starting at 1.  No really.  IMAGINE IT!!!!  DO IT!!!!  YOU AREN'T IMAGINING HARD ENOUGH!!!

Dataverse costs Microsoft less $ than SharePoint to manage/operate according to those who tell me these things.  "They" explain that it is more streamlined and <cough><cough> "simple" <cough> <cough>.  I mean, it is just a database, so compared to SharePoint (which is barely a database but many more things) it is "simple" only in that one criteria. However, the Dataverse database structure is vastly more complex than any SharePoint List you decide to spin up.  The interdependency of SharePoint tables is mainly just:  SharePoint Site -> SharePoint List.  You can build more complex relationships, but if you create a Site (say by creating a Team first), then the security and rules for data are all set for you.  Easy-peasy.  Dataverse...isn't.

Dataverse was never built for the thing it is doing.  SharePoint was built to try and enable business units to be flexible around their own needs while also enabling some corporate control.  Dataverse was just a CRM database.  Any "business rules" of who is allowed to do what are also tied into those table structures instead of higher-level UI features.  Dataverse is not anything your business users should ever look at (other than the data), so this means when you get in trouble, you'll need specialists and fast.

SharePoint does have massive amounts of tech debt that causes an insane # of issues for tech people and orgs.  However, SharePoint Lists aren't one of those problem areas. They're pretty simple.  Compared to Dataverse, SharePoint is the simpler solution specifically for data.  See my rant here.

Certainly this AI front-end makes your need to know anything about databases nonexistent.  However, WHEN (not if) you need to troubleshoot that database, it will take a specialist.  The more unknowledgeable "developers" you roll this out to, the more specialists you'll need on the back-end.  Once you discover that the labor costs and complexities are severely limiting, it will be far too late to change direction (or so Microsoft would hope).

I honestly wish Microsoft had gone down a road of creating a custom database around this based on semi-structured data w/ data pipelines for structuring over time.  Methods to recognize that we don't really know what data is important and how to store it NOW, but we'll figure it out later.  We could create some roles around those that already exist within data management teams for doing transformations and optimizations when we eventually have enough data to care.

However, this focus on Model Apps and database-first delivery is just...bad.  It forces a valuable edge-case development solution, where the organization can solve many of its own problems and self-manage without IS support, into a world where they now are ridiculously dependent on niche skillsets and people who will have zero time to understand their needs vs. being just experts on this one vast legacy product.

Once again, most of this is hidden on the surface, but roll out enough apps and you'll start to see how/where you definitely need a well-paid somebody on staff who can figure out WTF Microsoft's Dynamics team was thinking when this was built 20+ years ago.  You will also be competing heavily on salaries as others discover this trap too late and will pay "anything" to escape it.   

Again, SharePoint might fit same critique, but most enterprises are already staffing for some level of SharePoint administration.  So why would we do this and require even more staff to manage something else?  And yet again, SharePoint is designed to enable business groups to kind of "self-service".  Dataverse is in no way a self-service architecture.  Your IT team will be involved and will be angry when they have to figure out what dumb things both the business and Microsoft have done.

Let's be clear, I am one of those experts who can sit behind the curtain and throw answers back w/o interacting w/ the end-users.  While there are scenarios and platforms where this is a better solution, this just isn't it IMHO.   However, it is obvious that Microsoft and I disagree here.  

The beauty of the "Power Platform" and PowerApps specifically is if you follow the Canvas app pattern and co-develop w/ business units, then it allow more technical people to be more approachable and reachable for the entire organization.  I cannot overstate how valuable this is, assuming you aren't about to outsource everything to India.  In which case, can I make a pitch for you outsourcing to India(na)?  Given our current local labor laws and purposefully dismantled educational system, I'd doubt you'd recognize the difference.

NOTE: If you use some of the canned "approval apps" inside Power Automate then you're starting down the Dataverse road w/o realizing it. It is hidden all over the place within the Power Platform now and is attempting to do a stealth-entry into your org without you realizing it.

Higher Walls, Questionable Garden

I received a lot of pushback when we first dove into this platform within my current org.  We were already paying the licensing fees but weren't necessarily exploiting the value.  I pushed that we get the value of the licenses we already paid for.  This definitely put us into the "walled garden" world of Microsoft, but then again, we were already here and weren't getting all the value promised.  So I leaned in and took the leap.

Now 6 years later for my current org, we're definitely in a good place.  Lots of applications, reasonable growth, obvious value conversation in comparison to costs, but this is another step entirely.  We already had the "citizen developer" platform in place before I got here w/ limited results but high costs.  There needed to be an advocate and a guide for our people to understand how/where to use these tools and what risks to accept.

With this promise of AI guiding our end-users and limiting the developer pathway (Microsoft and AI advocates would claim they are "changing" vs. "limiting" it), it is turning the role into an "AI prompt engineer" vs. any form of development.  While also ignoring that the bulk of knowing what to tell the AI is also knowing what to ask and ignore from business users.

Comparing the platform from say 10 years ago (just the beginnings of it) vs. today, we traversed an arc where the primary datasource was SharePoint (and developers mostly being trained on SharePoint alone), to us getting some JSON tools that REALLY opened up the platform so we could truly connect to anything.  Developers had an excuse to understand JSON structures and by the expansion of knowledge now could become more valuable to their organizations in other ways Power Platform adjacent.

This pivot throws all of that incentive away and pushes people to become "prompt engineers".

LET ME BE CLEAR, if AI doesn't turn into the panacea big tech is selling us on, then your prompt engineer skills become worthless.  If AI does turn into this, then your skills become worthless, because AI will then solve its own prompt issues.  Do you see the trap?  Do I need to go further?

If you follow the pathway to open the platform up and connect to more datasources and learn, or even use AI, to build out and troubleshoot JSON data structures, then you have a marketable skill and can bridge the gaps between technologies and paths.  If your organization is considering this path, then know that the Model-Driven AI path is a bet that Microsoft will win at AI vs. everyone else.  Period.  Any other victory by any other player damns you into a trapped tech tree w/ limited escape paths.  You'll need to pay a lot of $ to get your data out of Dataverse and your apps rebuilt because nobody inside your org understands how these things were built.  Alternatively, you keep your walled garden and premium pricing while also paying for somebody else's AI to "make it better" as well.

NOTE: I look forward to closing out my career as having a side-gig on re-building all of your apps.  Feel free to hit me up, but my rates are increasing weekly unless you lock them in now. 

While I think the React code inclusion might in some respects give people hope that they're opening up the platform and enabling some killer features, I will point out again that this is most likely because they were already leveraging other AI platforms to build out a React code generator.  They aren't doing this because they believe React is the future, it is very much because React is this quarter revenues.  It is the easiest thing they can slap on top of this and pretend it was planned all along to try and boost "AI revenues".

Final Thoughts

If I were to sell out (again), then I'd go back to consulting and be a Dataverse AI specialist while laughing my way in/out of your organization. 

There is trusting your vendor and there is trusting your jailer.  Let's be clear, if you're a Microsoft shop, then you can still choose to have them remain "a vendor".  This path is a trap.  The costs are very real and the benefits dubious.

If you've already gone all-in on Dataverse (which we truly considered ~5 years ago) and are replicating sources to this repository and focusing all of your talent in that direction, then sure.  You are already bleeding capital so why not drill a bit deeper and see if you hit pay dirt.  Good money after bad and all of that.  Convincing an executive that they made the wrong choice is sometimes harder than having them write 7 or 8 figure checks to prove they didn't.

The reality of data structures and the war of strict data types (I'm talking integer, boolean, datetime,etc.) vs. the reality of end-user applications (what do you mean you want an N/A option in your datetime field now?!?!) would lead anyone being honest here into recognizing that data-first deployments at the edge are pipe-dreams.  We don't know what the future will hold and we have to be very open to changes in applications and data structures to reflect departmental needs.  These kinds of apps are very business-facing and therefore must be very malleable to reflect those needs.  Making excuses that you can't update a critical end-user-facing page because it will "break the backward-facing reports" is going to be the argument you have at your exit interview.

The more Microsoft gets excited about this and more videos I see Reza put out in a week in a single topic in his entire history (and now offering a brand new class hosted by him to push you into this) shows that this is definitely hype.  They really need this to be a win.  This makes me less concerned about this specific thing and more about how far over their skis Microsoft is on AI as a whole.  The firing of their workers seems to primarily be a stock-boosting move vs. an efficiency play.  What is really happening here?

I am not anti-AI and I do believe that there are ways we can use aspects of this for societal benefit.  However, companies stealing water/power from communities and pushing the costs onto people who will soon lose their jobs to our supposed AI overlords isn't how this should play out.  That's even assuming all of this isn't simply a dead-end on current tech/platforms.  That we aren't just getting some "meme generator" that uses the power of a city to do so and will never ben anything more than that.

BTW, this is more of how I'd prefer to see AI tools roll out to a broader audience.  I just finished having Notebook LM consume and regurgitate this content into audio and video summaries.  Here's the video summary of my ramblings above.

Code-generators has been something we've been capable of doing over and over since tech became a thing.  We've also had very dubious results time and again.  Now we're hiding much of that behind AI and telling us not to write better code, but to write better AI queries to train the AI to write better code to eventually...someday...somehow...know what to code before you ask it to and already have written it better than you ever would.

But I ask you again: to what end?

Does this really benefit your org today?  Is it worth it for you to learn more about just general coding principles and using languages/formats that are either more utility-based (SQL, JSON, HTML) as well as more limited (PowerFX) but amplify application value?  I know for a fact that we will be using HTML in 20 years.  Will you need to be an AI prompt engineer in 20 years?  In 10?  In 2?

This specific AI push by Microsoft is just a terrible idea.  I cannot remotely advise anyone to adopt it unless you're just wanting to make Reza happy.  In some ways though, i question if Reza is happy at all.  Much like some billionaire's 40 year younger wife who wound up a spokesperson for an insane wanna-be global dictator, I think he's stuck defending the indefensible.

Good luck with that.  I think I'll keep my licensing dollars just where they are, push out our Canvas apps, and continue to watch if anyone ever delivers a better solution for secure and scalable enterprise applications that fit our use-cases.