Over the past few months we have seen more coverage and announcements about low-code or low-code-adjacent products in the market. For example, low-code leader Appian has been cited in multiple articles in mainstream business pubs including the Wall Street Journal and Forbes discussing the role of low-code applications in the age of AI. Meanwhile, Microsoft has injected its Copilot AI assistance into its low-code Power Platform this summer. And I’ve written about other examples such as Oracle’s APEX offering, which was updated in June.
While low-code and generative AI have similar benefits, there are still some fundamental challenges in choosing the right low-code solution. For starters, not all low-code solutions cater to the same level of technical skills. One tool may be appropriate for a less-technical user like a business analyst who may understand webpage design, while another may require more depth, appropriate for someone like a junior developer.
Beyond that, low-code solutions are often platforms unto themselves that don’t align well with existing backend IT processes and governance models. This is quite different from pro-code tooling, which can be assembled to the specific needs of the developer and existing IT standards. Low-code apps can become difficult to manage over time and can become victims of their own success. What was once a pilot application can become institutionalized. It’s very common for these applications to outgrow—in terms of scale or complexity—the team that developed the now-production “pilot.” This goes beyond a technology problem, as additional IT resources may need to be budgeted to sustain or even re-architect the application.
Keep in mind, none of this means that I am anti-low-code. In fact, I got my start coding on tools like Lotus Notes, which to me is the OG low-code platform. But at times I am frustrated with the lack of progress low-code has made on the issues above.
Lessons to Be Learned from the AWS App Studio Preview
This brings me to the curious case of AWS App Studio. It’s not really a low-code platform since you do need a basic understanding of applications, services, and data. However, it is not a pro-code tool either, as it does not have all the features and modularity of a pro-code toolset. At this point, I don’t think labeling it does it justice. But I will say that it’s a clever approach to some of the low-code challenges I just laid out and provides a preview into the future of dev tools that are GenAI-native. This is in contrast to the current state of the art, where a coding assistant is bolted on to an existing low-code or pro-code toolset. I hope the low-code movement will take notice.
AWS App Studio is just entering a preview phase and is available to try for free until it goes GA sometime later this year. And, while it’s not perfect, it does bring some ideas to the fore that are worth deep consideration.
Low(er)-Code but Not Low-Skill
I believe that great marketing is inclusive, not exclusive. So when low-code platforms position themselves for “non-developers” or “non-technical” users, I get cranky. First of all, the great majority of most organizations are “non-developers,” so who do you really mean? AWS App Studio is not going that direction. In fact, AWS has been a good deal more precise in its targeting on the product home page: “With App Studio, technical professionals without deep software development skills, such as IT project managers, data engineers, and enterprise architects . . .”
I actually tried to build a couple of very basic apps on AWS App Studio, and I think this is a great assessment of its target users. For instance, you do need to understand how databases work and also need to have some basic knowledge of testing and deployment. But you don’t need to be a master programmer. Instead of low-code vendors telling us who their tool isn’t for, they can take a page from AWS and paint us a picture of their ideal user.
An End-to-End GenAI Development Experience
At first it was very easy for me to underestimate the power of AWS App Studio since one of its more compelling features is starting the development process from an AI prompt. That type of feature just seems to ooze low-code values. But, upon using App Studio, I realized that starting the process from an AI prompt is a very powerful approach for two reasons. The first is that many low-code solutions highlight how it’s so easy to “just get started.” But sitting down to think about what the app’s goals and requirements are before just throwing elements onto a virtual canvas is a more purposeful step. This is where App Studio takes it a bit further by responding to your prompt with a mini requirements document that you can modify before the app is created.
Second, App Studio provides a set of prompts as “templates,” which is very different from the low-code notion of templates that are essentially generic apps to be copied and modified. However, my results with code-based templates in the past have been mixed when it comes to modification. AWS’s idea is that the prompt can be modified before the app is even created, reducing the challenge of reverse-engineering the template code.
100% Usage-Based Model
Apps built using App Studio are serverless, so you only pay for them when they are invoked by a user. This is a nice touch for applications that support low numbers of transactions or intermittent workflows. Maybe you perform inventory once a month, so why would you need that app running all the time? Serverless computing, if properly managed, can also mitigate the persistent low-code issue of application sprawl. It’s so easy to make low-code apps that people create them early and often. This leads to higher compute consumption and management overhead for apps that are not used all the time.
While a serverless approach will not reduce the number of apps created, those apps will consume less total resources and can provide a clearer chargeback model for the apps’ actual usage. That said, one developer’s benefit may be another’s blocker, and the serverless approach may exclude certain apps from being developed on App Studio. I’d like to see AWS offer users a choice, with a default to run the app serverless but the option to create full-time instances. I see this as a solid possibility thanks to the next App Studio benefit.
An Onramp to Advanced Development
When I spoke to Adam Seligman, vice president of developer experience at AWS, we both lamented that low-code apps did not have a means to be “promoted.” The idea of promotion is that many low-code solutions are end-to-end platforms and lack the ability to transfer the application to a higher-scale platform or leverage a service that is not an explicit integration point with the platform. Basically, the low-code app is stuck on that low-code platform, for better or worse. In many low-code cases, that’s not a problem. But time and again there are stories of the low-code app that became a victim of its own success with nowhere to grow. This leads to the management and governance issues I mentioned earlier.
To counteract this scenario, App Studio apps are generated in Javascript and can leverage the same underlying AWS services (such as IAM and Dynamo) as existing enterprise apps. This means that App Studio apps are less likely to encounter the scaling and security issues you may see with some low-code solutions. And because the output is Javascript, a pro developer can easily add more advanced capabilities over time with a different tool if desired. There is no lock-in, so to speak, and App Studio apps look the same as other enterprise apps to DevOps resources.
However, the idea of an onramp extends beyond the application and to the low-code developer. I think that the pervasive AI assistance included in App Studio could very well be enough help to enable a low-code developer to take advantage of App Studio’s more advanced capabilities. This is a slightly different perspective on the productivity assessments we have seen with AI-driven development copilots and assistants. It’s not so much about proficiency as it is about learning.
More Utility than Meets the Eye
A key use case of all low-code solutions is the creation of tactical line-of-business applications. App Studio is targeting those same use cases. However, in the spirit of staying more prescriptive, the benefits of App Studio could extend into other high-value scenarios beyond the line-of-business application. For one thing, it may be an ideal way to kick off major development efforts via the easy creation of demos or an MVP. I also think that it’s a great way to skill up junior developers by letting them tackle some work that’s in the development backlog. Finally, it could be a great tool for product managers or researchers to develop prototypes that can be shared with engineering teams and customers to collect better feedback earlier in the process.
Looking ahead, it’s interesting to imagine where App Studio could go and where it will catch on most. Is it the next gen of low-code, or will it become a future vision for pro-code? I’m not sure, but if I were running the App Studio team I would stick to my vision as I move forward. That might include future product improvements such as a wider range of data connectors, or leveraging future AWS Bedrock features such as memory retention and customized outputs to make a deeper AI-driven developer experience. Either way, App Studio is onto something and confronts some issues that have persisted for far too long.