Over the past three years, the landscape for both coding tools and AI has undergone a dramatic evolution. On the coding tools side, a series of no-code/low-code tools have come on the scene allowing app development on the edge to pivot from being solely in the hands of engineers to being enabled by designers (or “creatives”). You do not have to look much further than the website for Flutter to see that they are marketing to dreamers who have an idea and require the means to pursue it.

This past week, I started playing with Flutter (not that I am biased toward any one tool) and found myself surprised at how easy it is to envision, design and create an application that can sit on multiple platforms. It's not my grandma’s tool yet but it is certainly moving in the right direction. And there are other such tools that are addressing the opportunity to pull “creatives” into application development.

On the coding side, AI has made great strides to providing code to beleaguered engineers. Most of the folks I know were very excited to see MS Copilot jump on the scene. Like Flutter, it is clearly focused on more creative pursuits, but it has ever-refined capabilities to provide engineering support in the form of code snippets. Code addressing very specific functions. This past weekend, I was meeting a friend at Blue Bottle Coffee in Palo Alto, and he was pointing out that many of the people around us were coding on laptops and several had the Copilot interface up.

Both AI and the tools space are clearly on a path to democratize capabilities that many people would not have previously had easy access to. Both have had dramatic adoption.

Both also fall short in one important aspect. They are not cemented together with both infrastructure and a business model. Consider this. Flutter has become a widely adopted tool for app creation. It has democratized application development and the ability to represent an idea across platforms. However, it falls short because one must still rely on “back-end engineering” to create the cloud infrastructure to support the application with a business model.

Consider this. Copilot provides specific functional code to support development work, but it does not tie into a greater platform. It supports the functions that support a business model but requires an engineer (or a team of engineers) to apply output of Copilot.

Both solutions solve important problems but leave a significant void in the market. Other than a great deal of engineering work, how does someone bind a mobile application to the functional support platform you need to support a business model. In addition, how does someone utilize the code snippets and sources of logic without a broader platform to tie it to.

The gap between the front and back-end (in the cloud) coding is what I refer to as the Autonomous Void. One could ask, why are you adding the word “autonomous” to this phrase. Why not simply say; “The Void” or the “Code Gap” or something similar.

The answer is that whatever fills “The Void” will have to yield code that be dynamically created to accommodate both the snippets provided by platforms such as Microsoft Copilot and the application layer on the edge provided by platforms such as Google’s Flutter. It must accommodate the logic and all the data nuances of what is exposed to the user while allowing a solution to address the algorithmically challenging functions that need to be created to support a viable business model. Furthermore, black box platform solutions will not address the problem. Black-box solutions exist today but without the ability to incorporate custom logic and address bugs that will arise as a user facing solution evolves, they simply cannot accommodate the changes fast enough. Or, said another way, the only viable solution to fill the void is an open, autonomous coding solution.

Over the coming months, I will discuss in more detail what a solution to fill “The Autonomous Void” looks like and how it will improve the software development workflow for the entire software industry. Stay tuned!