Building with MAI-Code-1-Flash in VS Code

We just released a small, fast, Copilot-native coding model called MAI Code 1 Flash, and it's available right now in VS Code. Let's talk about how you can use this new model to ship a new feature in a real project. In this video, we'll add a seasonal snapshot to my plant dashboard, which will be a small, practical feature that helps me see at a glance whether it's safe to plant, how far into the growing season I am, and how long until the next frost. The model can plan, build, run, and test it in just a few minutes for only a few cents, all from Copilot chat in the editor. For a quick bit of context before we build, MAI Code 1 Flash is a small model of about 5 billion active parameters, and it's tuned to be fast and token efficient. The team reported up to 60% token savings versus comparable small models. What makes it different is how it's trained. It's trained inside real GitHub Copilot environments in VS Code and the CLI, and it's rewarded for writing diffs that pass tests and using tools efficiently. It also uses adaptive thinking, so that's short reasoning for simple tasks and deeper reasoning when the work calls for it. The sweet spot is everyday development like environment setup, codebase questions, bug fixes, and small features like the one we're about to ship. I've got my project open in VS Code. I'll open the Copilot chat view in the sidebar, and then I'll click the model picker at the bottom of the chat box, where it normally shows the default model, and choose MAI Code 1 Flash from the list. That's it. Every prompt I send from here is now handled by Flash right inside the editor. Before changing anything, let's let the model get its bearings. The app already has a frost state banner on the dashboard, so in the chat, I'll ask how frost states work and where they come from. Watch how it explores the project on its own. I'm not handing it file paths, it found the frost date banner, also where the user sets their location to define when the frost date happens. Along with whether it should show last frost warning, days until first fall frost, or frost season. That gives us everything we need to build on top of it. Now let's build the feature. I want to turn that single frost line into a richer seasonal snapshot on the dashboard with three quick indicators, all driven by the frost dates we already store. So that's a safe to plant indicator, so once today's date is past the last spring frost, show a clear safe to plant badge. Before that, warn that frost is still possible. A growing season progress bar, so show what percentage of the growing season has elapsed between the last spring frost and the first fall frost. And then a frost countdown chip, so a short first fall frost in 34 days countdown, so you know how much time is left. So I've described all three in one prompt, and I'm going to let the model build them. Notice how it plans briefly, then makes focused edits. So it reuses the existing date helpers, computes the three values, and lays them out as a small panel that fits the dashboard. Because this is a small well-scoped task, the reasoning stays short. So it's not over-engineering or sprawling across the whole database. It proposes the changes as diffs in the editor, and then I'll review them and keep them. The code is TypeScript in strict mode and styled with Tailwind, and the model stays consistent with both. Now let's see how it did. I've already created a VS Code task that starts the dev server, so I can ask the model to use this, and then see the website in the integrated browser. So here's the dashboard, and now instead of one frost line, there's a seasonal snapshot, a safe to plant badge, a progress bar showing how far we are through the growing season, and a countdown to the first fall frost. It's reading my real saved frost dates, so the numbers are accurate. That's a working feature, not just a snippet on the screen, and it behaves exactly the way I described it. So, good engineering means the tests stay green. So, I'll ask the model to run the test suite from inside VS Code. If anything fails, like a test for the old frost banner that didn't expect the new layout, I'll investigate the test to find the issue and work with the model to make sure everything's working as it should, iterating along the way and double-checking its work. That explore, edit, run, fix loop is exactly what Flash is trained for, and it's why it feels at home in a real project. One of the best things about a small model like Flash is the cost. So, let's actually look at it. We can look at how many credits each of our prompts used. And we were able to keep the costs down by attaching files and reusing context, so most of those tokens were cache reads. So, we explored the code, wrote it, ran it, and tested it for just a few cents. So, we went from a small banner to a full seasonal snapshot with passing tests, all in just a few minutes, and the diff was pretty small, which is the whole point when you use MAI Code 1 Flash. So, it's really helpful with your everyday tasks. So, if you want to use it for your setup, or if you have a quick bug fix, or you want to implement a small feature like this one, it's perfect for that. So, that's all we have for this video. As always, thank you for watching and happy coding.