Have you ever wanted to build your own custom application but didn’t want to take the time to do any of the pesky learning that software development requires? If so, a new experimental project from GitHub might just make your dreams come true.
GitHub Spark lets you build what the company calls "micro apps" or "sparks." These are very limited custom applications that perform one or two basic tasks. You create them through a chatbot interface, and when you’re done, you get a spark you can (someday) share with all your friends.
I recently got access to the preview and was able to do some testing. Fundamentally, the tool is extremely limited. But because there’s an AI operating underneath, it’s possible for the AI to do some very sophisticated AI magic within the very limited interface of Spark.
Linking and configuring
The first thing you need to do is link your GitHub account to Spark. Point your browser to https://spark.githubnext.com/ and log in with your GitHub account. If you don’t have a GitHub account, you’ll need to get one.
Once you’ve logged in, you’ll need to give permission. This is very similar to any other app that requires permission before first use.
What do you want to build?
I thought a lot about what sort of app I’d want to build. Examples included habit-tracking applications, an allowance tracker, a map app, and a karaoke night planner. Basically, they were all apps that presented a form consisting of fields and buttons and performed some business logic based on the data being entered.
But the entity doing the business logic calculation wasn’t a typical forms manager. Instead, it was GPT-4o. So what if my business logic was something insanely complex and difficult for a regular algorithm but easy for an AI — all wrapped in a very simple UI?
I decided I wanted to create a tool that would allow me to paste in a block of code. The app would tell me what the code did, what language it was written in, any observations about areas where there might be a problem, and maybe a detailed breakdown of the lines of code.
Think about that. In years past, that would have been a multi-million-dollar project if it could have been done at all.
Customizing the application
You make changes through the Iterate field in the leftmost pane. I told GPT-4o that I wanted it to:
- Display the language of the source code
- Provide a short one- to two-sentence description of what the code does
- Add a sentence or two describing any failings of the code
I presented that to Spark in that field and hoped for the best.
The results were impressive. The app did, in fact, provide me with the information I wanted. You can see that in the pane on the right side of the interface. It identified the language, provided a short description of the code, and outlined a whole bunch of problems with the code.
It then provided the detailed explanation of the code that was part of the original requirement prompt, where I asked it to explain the source code.
Stubborn, thick-headed, and non-responsive
It was at this point that Spark began to show its limitations. As you can see in the leftmost pane of the above image, I tried to get Spark to remove the three asterisks at the beginning of each answer. I also tried to get it to turn the critique section into a bulleted list. Finally, I wanted to get rid of the second set of index numbers under the headings.
I got the bullets, but Spark or GPT-4o ignored my other requests. My guess is that GPT-4o was writing in Markdown, but Spark’s UI didn’t parse Markdown correctly.
Sharing is limited
Eventually, I gave up on trying to tune the output formatting. Even with slightly ugly output, the tool itself was useful. So I decided I wanted to share it with everyone.
You can do this by clicking on the share icon next to the named Spark and choosing to share it.
How consequential is this?
No-code form generators have been available for years. I built one as far back as the early 2000s. Since the UI for such a tool is mostly a matter of choosing the controls (buttons, drop-downs, fields, etc.), along with placement and some pretty paint, it’s not a very difficult prospect.
While you can only do so much with form-based apps, you can actually build a pretty good variety of apps. These apps are usually of the information management kind, rather than productivity or highly interactive tools. Still, businesses can get a lot done within the confines of a form generator.
Conclusion
I’d like to see a way for human-written code to coexist with AI-written code. And I’d like to see a way for Sparks to run as standalone web applications without users having to be part of the GitHub framework. But those are also fairly achievable expectations.
The bottom line is that this has the potential for being a usable, if constrained, tool. It’s certainly not there yet, but give it a year or so of iteration. It will probably be capable of doing some interesting tasks.
FAQs
Q: What is GitHub Spark?
A: GitHub Spark is an experimental project from GitHub that allows users to build "micro apps" or "sparks" through a chatbot interface.
Q: What kind of apps can I build with GitHub Spark?
A: You can build very limited custom applications that perform one or two basic tasks.
Q: Is GitHub Spark available to everyone?
A: No, GitHub Spark is currently only available to users who have been accepted into the preview program.
Q: Can I share my Spark app with others?
A: Yes, you can share your Spark app by clicking on the share icon next to the named Spark and choosing to share it.
Q: Are there any limitations to using GitHub Spark?
A: Yes, there are several limitations, including the fact that human-written code gets blasted into oblivion with each AI update, and that the AI has a "this-far-no-farther" mentality, refusing to implement additional tweaks and modifications.
