GitHub announced a “Dev Days” tour in March 2026, a series of in-person one-day events in 12 cities, mostly North American, where attendees can take a paid training class on Copilot, get a certificate at the end, and network with other developers who are trying to figure out the same thing everyone is trying to figure out: what AI-assisted coding is actually for. I went to the Boston stop on April 19, 2026. I paid the $449 ticket out of my own training budget. I am not going to recommend that you do the same, and I am not going to tell you to avoid it. The honest answer is that the value depends on the specific thing you are trying to learn, and the specific thing you are trying to learn is almost certainly not what the GitHub Dev Days curriculum is built to teach.
The day ran from 9:00 AM to 5:00 PM, with two short breaks, a 90-minute lunch, and six hours of class time split across four hands-on labs. The first lab was “Copilot Fundamentals,” the second was “Prompt Engineering for Code,” the third was “Copilot for Pull Requests and Code Review,” and the fourth was “Custom Instructions and Workspace Configuration.” Each lab was about 75 minutes, with a GitHub engineer at the front of the room and three or four GitHub Developer Relations (DevRel) staff circulating. The class size at the Boston stop was about 60 attendees, mostly working developers, with a few engineering managers and a handful of bootcamp students. About 70% of the room had used Copilot before, and the rest had used Cursor (a fork of VS Code with deeper AI integration) or Cody (Sourcegraph’s AI coding assistant) and were evaluating Copilot as a second tool.
The thing Dev Days is actually good at
The first thing Dev Days gets right is the room. The lab format in Boston had everyone working on the same JavaScript project on their own laptops, and the room was small enough that the DevRel staff could see your screen when you raised a hand. I learned three things in the first hour from the developer two seats down that I would not have learned from any video, all of them small, all of them cumulative: the Ctrl+I shortcut to open Copilot Chat inline, the /tests slash command in chat, and the Copilot: Explain This command from the command palette. None of these are undocumented. All of them are buried.
Lab scenarios were the second strength. The labs are built around small, realistic tasks: a Node.js (a JavaScript runtime for running server-side code) Express route that needs input validation, a React (a popular JavaScript library for building user interfaces) component that needs a memoized callback, a Python data pipeline that needs retry logic. Each lab has a starter repo (a starter code repository that everyone in the room clones and works from), a set of acceptance criteria, and a “stuck” state at minute 30 that most attendees hit. The DevRel staff are prepared for the stuck state. The curriculum is not a tour of Copilot features. The curriculum is a series of small problems that the Copilot features are supposed to help with, and the labs are designed to surface the limits of the features in a controlled environment.
I found the third lab, “Copilot for Pull Requests and Code Review,” the most useful of the four. The lab scenario is a real PR (a pull request, which is a proposed code change submitted for review) with a real Copilot-generated summary, a real Copilot-generated review with three suggestions, and a real merge conflict at the bottom. The lab walks you through accepting some suggestions, rejecting others, and writing a PR description that is not a Copilot-generated wall of text. I have been writing PR descriptions for years, and the lab changed the way I think about the format. I came back to work on Monday and rewrote the PR template for the team I work with. The template has not changed since I sent it out, and the team has been using it for two months. That alone paid for the ticket.
The thing Dev Days is not good at
The thing Dev Days is not good at is the prompt engineering lab. The second lab is titled “Prompt Engineering for Code,” and the curriculum is the standard prompt engineering content that has been in every LLM course for the last two years. “Be specific.” “Give examples.” “Use the persona pattern.” “Chain of thought.” None of this is wrong, and none of it is what an experienced Copilot user needs. An experienced Copilot user is past “be specific” and is at the level of “how do I keep Copilot from generating the same bad autocomplete (the inline code suggestions Copilot offers as you type) every time I open a new function.” The lab did not address that question. The instructor, who was a smart and well-prepared GitHub engineer, was clearly aware that the lab was a “Copilot 101” prompt engineering session, and the Q&A in the second half of the lab was where the real work happened. Two attendees asked very specific questions about Copilot Chat workspace context (giving the model access to multiple files in the project as background), and the answers were honest and useful. The lab itself was not where those answers came from.
Lab four, “Custom Instructions and Workspace Configuration,” was the most uneven of the four. The lab covered the .github/copilot-instructions.md file (a plain-text file where you write persistent instructions for Copilot to follow across your whole project) and the workspace-level custom instructions, but the lab was clearly designed when those features were simpler than they are now. The GitHub engineer running the lab at Boston was honest about this. He said the team was still figuring out how to teach the configuration story because the configuration surface (the set of settings and files you can customize) keeps changing, and the lab was the same lab they had been running for six months. The lab was fine, and I learned one thing from it (the way to scope custom instructions to a specific language or framework), but I expected more from a $449 ticket.
The other thing Dev Days is not good at is being a Copilot sales pitch. This is a compliment. The day did not feel like a marketing event. The instructors were not selling Copilot Enterprise or pushing a specific tier (GitHub’s product has multiple paid levels with different features). They were teaching the product, and the parts of the product they taught were the parts they had hands-on experience with. The lab on code review included a section on “when to ignore the Copilot review suggestion,” which is the kind of thing a marketing event would never include. The lab on prompt engineering included a worked example of a Copilot suggestion that is technically correct and socially wrong (the kind of suggestion that would pass code review and cause a production incident three weeks later), and the lab walked through how to catch the social-wrong case. That is good training. I just did not get six hours of it for $449.
The honest comparison to free alternatives
The honest comparison to free alternatives is what Dev Days has to beat, and the free alternatives have gotten better. The official GitHub Copilot documentation is good, especially the new “How Copilot Works” page that walks through the inline suggestion algorithm (the way Copilot predicts what code to suggest based on what you have already typed). The free prompt engineering course from DeepLearning.AI is about the same depth as the prompt engineering lab at Dev Days, and you can do it in two evenings at home. The YouTube videos from GitHub’s own DevRel team, especially the ones on custom instructions and workspace configuration, cover most of what the fourth lab covered. The thing free alternatives do not give you is the room, the lab scenario, the DevRel staff circulating, and the in-person Q&A. If you learn better from a textbook than from a classroom, free alternatives are enough.
Two specific things I would have done differently. First, I would have skipped the prompt engineering lab and spent the 75 minutes in the lab room with the developer two seats down, because that is where I learned the most. Second, I would have brought a real project from work instead of working on the starter repos. The starter repos are well-designed, but they are not your codebase, and the Copilot suggestions that work in a starter repo do not always work in a real codebase with real dependencies and real configuration. The DevRel staff said they were open to attendees bringing their own code, and the policy is in the FAQ, but the lab curriculum is built around the starter repos. Bringing your own project would have made the day more useful for me, and the trade is that I would have had to context-switch between the lab instructions and my own project.
A short list of the free alternatives I would have used as a backup plan, in roughly the order I would have used them:
- The official GitHub Copilot docs. Especially the “How Copilot Works” page and the custom-instructions reference. The docs are good, and they are kept current. Two evenings of working through the docs at home covers about 60% of what the four labs cover.
- The DeepLearning.AI prompt engineering course. About the same depth as the prompt engineering lab at Dev Days, free, and you can do it in two evenings. The course is not Copilot-specific, but the prompt patterns transfer.
- The YouTube videos from GitHub’s DevRel team. Especially the recent videos on custom instructions and workspace configuration, which cover most of what the fourth lab covered. The video format is not the same as the in-person format, but the content is close.
- The Copilot Chat workspace context documentation. The Q&A at the second lab in Boston covered parts of this that are not in the official docs, but the docs are the right starting point. A working developer with a real codebase and an afternoon can get 80% of what the in-person Q&A delivered.
What I would tell past me
If I could send a message back to the version of me that registered for the Boston stop, I would say three things.
- The room is the product. The curriculum is fine. The DevRel staff are good. The thing that makes Dev Days worth the ticket is the small in-person interactions with the developers around you, and those interactions are not on the agenda. Sit near people who are working on similar problems and talk to them.
- The labs cover Copilot 101, not Copilot 250. If you are already using Copilot daily and you are past the prompt engineering basics, the first two labs are not going to teach you much. The third and fourth labs are worth the ticket if you have not spent serious time on PR descriptions and custom instructions yet.
- Bring a real project if you can. The starter repos are well-designed, but the Copilot suggestions that work in them are not the Copilot suggestions that work in your codebase. The DevRel staff will help you with a real project if you bring one, and the help is the part of the day you cannot get from YouTube.
Trade-offs
The $449 ticket is the obvious cost, and it is the cost that makes the decision hard. The same content, in the form of free GitHub docs, DeepLearning.AI courses, and YouTube videos, is about 20 hours of self-study. The Dev Days day is 8 hours including lunch and breaks. If you are billing $100 per hour, the 12-hour delta (20 hours self-study minus 8 hours Dev Days) is worth $1,200, which is more than the ticket. If you are billing $50 per hour, the math is closer, and the time you save on the self-study direction-finding is what tips it. If you are a hobbyist developer who is not billing anyone, the math does not work, and free alternatives are the right answer.
Time away from work is the second cost. Dev Days runs on a Saturday at some stops and a weekday at others. The Boston stop was a Saturday, which is a gift, but the New York and San Francisco stops are weekdays, and taking a day off work for a training class is not free for most developers. The travel cost is real for a city you do not live in. The Boston stop was 90 minutes from where I live. The San Francisco stop would have been a flight and a hotel.
Upside is real too. The PR template I came back with has saved the team I work with about 20 minutes per PR for the last two months, which compounds faster than the ticket cost. The two keyboard shortcuts I learned from the developer two seats down are now part of my daily flow, and the day gave me a clear sense of where Copilot is and is not worth the spend. I would go to a future Dev Days stop if one came to a city I was already in, and I would not travel for one.
The honest answer for a developer asking “should I go to Dev Days” is: it depends on whether you learn better in a room than from a screen, and whether the labs cover the specific thing you are trying to learn. The day is well-run, the instructors are good, and the room is the product. The ticket is too high for a hobbyist, fair for a working developer who can expense it, and a clear win for a developer who is past Copilot 101 and wants the in-person Q&A with the DevRel staff. Pick the city based on travel cost, and pick the day based on whether the labs cover the thing you are trying to learn.