Vibe coding with GitHub Spark

It’s taken some time for GitHub Spark, GitHub’s new AI-powered coding platform, to go beyond its initial small, closed beta. However, it’s now available to anyone with a GitHub CoPilot+ subscription, with the possibility of a wider future rollout. Unlike the standard GitHub Copilot, which acts as a smarter IntelliSense and as a virtual pair programmer that makes suggestions based on what you type, Spark is more like the tools built into Visual Studio Code’s Copilot Agent, using prompts to build answers to your questions and producing code that aims to implement your ideas.

This is pure vibe coding, as good as it gets, because although you can edit the GitHub Spark output in its code view, you’re much more likely to change or refine its prompts to get the application you want. Instead of starting with a design, you start with an idea and use the tools in Spark to turn it into code—quickly and without needing to interact with the generated JavaScript.

What’s it like to build in GitHub Spark?

I’ve been experimenting with the invite-only preview of the service on GitHub’s Next platform. I haven’t done any vibecoding before, only occasionally using GitHub Copilot to help me figure out the syntax for unfamiliar APIs, such as the one used to authorize access to Mastodon and then post content to it. It was interesting to go from an idea that began as this prompt, “an application to roll dice for a Dungeons & Dragons game; letting me pool multiple dice,” to one that let me change the color of the dice, save regularly reused dice combinations, and store a history of die rolls and results.

Each iteration is built on the generated code, using new prompts to refine design and features. I was able to see a preview of the application and the current code. Unfortunately, I didn’t have the option to save the code to a repository, though I could have easily cut and pasted it into Visual Studio Code or a similar editor and then saved it both locally and in GitHub. That may work to save your generated code, but it does rely on libraries and features provided by the underlying Spark platform, so it will not be fully portable outside of GitHub.

After five prompts, I had a web application I was happy with and I could share it with other GitHub Spark users. There are two sharing options: the default, with read-only access, and one that lets other users collaborate in the same design space. The JavaScript the preview generates uses the JSX format, so it offers a more structured view of your code, making it easier to read and understand.

Inside the GitHub Spark environment

The GitHub Spark development space is a web application with three panes. The middle one is for code, the right one shows the running app (and animations as code is being generated), and the left one contains a set of tools.

These tools offer a range of functions, first letting you see your prompts and skip back to older ones if you don’t like the current iteration of your application. An input box allows you to add new prompts that iterate on your current generated code, with the ability to choose a screenshot or change the current large language model (LLM) being used by the underlying GitHub Copilot service. I used the default choice, Anthropic’s Claude Sonnet 3.5. As part of this feature, GitHub Spark displays a small selection of possible refinements that take concepts related to your prompts and suggest enhancements to your code.

Other controls provide ways to change low-level application design options, including the current theme, font, or the style used for application icons. Other design tools allow you to tweak the borders of graphical elements, the scaling factors used, and to pick an application icon for an install of your code based on Progressive Web Apps (PWAs).

GitHub Spark has a built-in key/value store for application data that persists between builds and sessions. The toolbar provides a list of the current key and the data structure used for the value store. Click on a definition and you’re given an editable view of the currently stored data so you can remove unwanted content. If your code calls an LLM, you’ll see a list of the prompts it uses.

The final option is a set of user-specific settings, including a base prompt that can be used for all your applications. The settings help customize your application and add your own style to the AI-generated code. There’s a link to a GitHub-sponsored Discord server where you can chat with other users.

For the basic, prototype-style React app I built, I found the default settings worked well enough, and although I used a couple of the generated prompts, I did edit them before submitting so that they were better aligned to my intentions. As my refinements got more detailed, application generation took longer, though it took, at the most, three or four minutes for about 500 lines of React JavaScript—a lot less time than coding it myself.

An enterprise GitHub Spark

If you have a GitHub Copilot+ license ($39/month per user), you can use a more enterprise-friendly version of GitHub Spark. This builds on the preview version I was using, but instead of delivering JavaScript React code, it uses the more powerful TypeScript and integrates with a Codespace where you can edit and test code. There’s support for team working, using a repository to store and share code with two-way synchronization between the two environments.

Like the under-development version I was using, this release of GitHub Spark uses prompt-driven development with support for complex, multipart prompts. Again, you can refine the code through multiple prompt iterations and upload images to help lay out user interfaces. These can include sketches or even photographs of whiteboard designs.

Once code has been generated, you can test it, apply more iterations, or use the built-in code editor to make changes. You can use the preview pane to focus on specific display elements before switching to the editor to refine them. This lets you use the standard theme and style tools to edit their look and feel alongside the entire application. The generated code will include editable CSS for more targeted editing by designers. Outside of the built-in theme tools, you can upload your own visual assets, adding them to your app. The same tools as in the preview manage the built-in key/value store, along with any prompts used with AI integrations and third-party APIs.

Like many other prompt-based coding tools, there are limitations to GitHub Spark. Your subscription includes 375 Spark prompts and iterations a month, with added pay-as-you-go options for more prompts. These cost $0.16 for each additional prompt. There are no costs for storing and running published applications, though if you exceed the usage limits, it will block an application until your next billing cycle.

What is GitHub Spark good for?

There’s certainly a place for tools like this in your development toolkit, but as good as the code is, it’s no substitute for writing it yourself. It’s not “your code,” so you’re not familiar with the structure and the style. Editing and reusing code from GitHub Spark is like understanding a section of code from an open source project or any random stranger’s code. You need to first understand why the developer made certain decisions.

Where should GitHub Spark be used? The obvious place is as a prototyping tool, allowing you to quickly build a working example of your idea. It’s a great way to mock up applications and have a working back end with access to data and services, ready to demonstrate and share before spending the necessary time coding the final solution.

It manages to show the possibility of using tools like this to add front ends to applications built using no-code or low-code tools, like those provided by Microsoft’s Power Platform. A mix of user prompts and code analysis could quickly generate UI concepts, iterating to produce a final, shareable application.

Building on React and TypeScript, as GitHub Spark is doing, means it’s possible to take the generated code and add it to a repository where it can be modified by front-end teams, an example of Microsoft’s fusion team concept that mixes professional developers, stakeholders, subject matter experts, and low-code developers. The result is interesting: an AI-powered development tool that delivers well-designed, functional code. All that’s missing is a way to take your code and the GitHub Spark runtime and deploy it on your own systems—on premises or in the cloud.