The biggest lesson from GitHub Universe 2026 is simple: professional developers no longer spend most of their time writing code. They direct agents that write it, and they judge whether the result is any good. That shift is already changing what "knowing how to program" means, and intro CS will feel it first.
The Codio team spent the week in San Francisco, from GitHub Education Day at GitHub HQ through the main conference at Fort Mason Center on October 28 and 29. We sat in on product sessions, a career panel aimed at people early in their careers, and a lot of hallway conversations with educators. Here is what we took away, and what we think it means for anyone teaching programming right now.
1. The job is moving from writing code to directing and judging it
GitHub framed the whole conference around this. In the keynote post, Microsoft CoreAI EVP Jay Parikh described the arc as going from writing every line, to working with AI assistants, to orchestrating fleets of agents. In his model, developers set direction and stay accountable for what ships, while agents implement and verify the changes.
The numbers back it up. GitHub's Octoverse 2026 report found that by September, more than 40% of pull requests started from an agent's draft, up from 17% in March (TNW).
The products followed the same logic. The new GitHub Copilot app runs each task in its own isolated session, so one person can have several agents working in parallel. With Copilot projects, you hand over a goal and a coordinator spins up sub-agents behind the scenes. GitHub's team said they ran 13 agents at once to prepare for Universe itself. In the session we attended, the presenters called this "outcome-driven development": you review the result, not every line of code.
Two details stood out for educators. First, review is getting its own tooling: Copilot Fusion can have a second model critique the first model's work, and GitHub launched a deeper Copilot code review tier. Second, GitHub staff use the app for non-engineering work too, from leadership reviews to marketing. Directing agents is becoming a general professional skill, not just a developer one.
2. Engineers are becoming product thinkers, and judgment is the job
If agents handle the "how," what is left for the human? The "Building an AI-Native Career" panel with Priya Pahwa and Scott Wadsworth answered that directly. When an app breaks at scale with millions of users, engineering judgment is what fixes it. Passion for what you are building, care about the end state, and a clear sense of what "done" means are becoming the differentiators. In the panel's words, engineers are effectively becoming product managers.
The panel also called out a shift in how people approach problems. Many engineers instinctively start bottom-up, at the debugger. Increasingly, the better habit is top-down: start with the architecture, draw the system on a whiteboard, then go into the details. The panel offered a simple test for real understanding: can you explain the system on a whiteboard to someone who has never seen it?
We heard the same thing in hallway conversations. Engineers at leading companies told us they rarely write or review code by hand anymore. Their time goes to architecture, specs and evaluating what agents produce.
3. Concepts outlast syntax, and AI's limits are a learning signal
Git came up as the clearest example. You may never type a git command again if a GUI or an agent does it for you. But knowing what is happening under the hood, down to something like git reflog, still matters when things go wrong. The durable skill is collaborating on software and understanding intent. The syntax is increasingly handled by tools.
The panel was also honest about where AI falls short. One example: turning a 2D photo into a 3D Blender model, where current models hit a wall. Their point was that hitting the wall is useful. It tells you what LLMs can and cannot do, and when to switch to a different model, a specialized tool, or old-fashioned learning. The dopamine hit of finding the genuinely hard problem is what drives growth, which they framed as a builder mindset rather than a user mindset.
Scott shared his own experiment: building a bipedal walking robot using only Copilot and ChatGPT, with no books or YouTube. It is a good picture of where learning is headed. AI is a learning partner, but you still have to pick the hard project and push through it.
4. Curiosity, community and mentorship are the durable skills
Asked what students should focus on over the next four years, the panelists did not name a language or a framework. Scott named professional curiosity: be curious about the layers above and below yours in the stack, think about customers, and get comfortable being uncomfortable. Priya's advice was to learn how to learn new skills, with courage, community and competence.
A few other habits came up:
- Say "I don't know" in public. The panel called it a rare, high-value skill that takes years to build.
- Practice on purpose. Treat internal tools and side projects as deliberate reps, not just output.
- Keep mentors and community close. AI can help you prepare questions and feel safe asking them, but people still provide the platform. One example was the scary but pivotal step of posting a public GitHub question about becoming a Django contributor.
- Watch for burnout. Review your goals and projects every six months or so, and know when to hand a project to a person or an agent and take time off.
None of this is new advice. What is new is that it now carries more weight than knowing any specific tool.
5. Taste is the new differentiator
At its core, generative AI predicts the next likely word, so it should be no surprise that its default output is competent and bland. When agents can produce average work instantly, average stops being worth much. The students who stand out will be the ones who can tell good from bad and refuse to settle for the default.
We can't turn every student into a famous product designer, and we shouldn't try. But we can teach them to ask what makes a design good, what makes it bad, and why. Taking responsibility for what ships is half the job. Having the taste to know what should ship is the other half.
What this means for intro CS
None of this makes fundamentals less important. You cannot judge an agent's output, or debug an app that breaks at scale, without understanding what the code is doing.
One honest caveat: nobody has a trusted pedagogy for this yet. AI is too new for proven best practices. What we can say with confidence is that teaching CS the old way and bolting AI on top does not work. If the assignment is "write this function" and AI writes it better and faster, students learn to act like robots, not to think.
There are two tempting extremes: move cautiously and avoid anything unproven, or go full steam ahead. We think both are wrong. Courses need room to experiment creatively, and the discipline to check results and correct course when an idea isn't working.
What changes is what students practice and what we assess. Here is where we think intro courses are heading:
- Reading and reviewing code, not just writing it. If 40% of pull requests start with an agent's draft, students need practice evaluating code they did not write: spotting bugs, questioning design choices, deciding what to keep.
- Top-down design before implementation. Ask students to sketch the architecture and explain it before they build. The whiteboard test from the panel works as an assignment.
- Specs and outcomes as first-class skills. Writing a clear spec, defining what "done" looks like and checking the result against it are what developers now do all day.
- Concepts over commands. Teach version control as a model of collaboration and history, not a list of commands to memorize.
- Studio-style critique and taste. Several conversations pointed to the design-school model: collaborative, project-based work with regular critique. Give students an AI's first draft and ask them to make it better, and to explain what "better" means. It fits a world where the hard part is judgment and taste, not typing.
- Projects that matter to students. If "boring apps feel boring to build now," as the panel put it, the projects we assign need to be ones students actually care about finishing.
Help us map where intro CS is going
Parikh predicted that all the software written to date will amount to less than 1% of what gets written in the next five years. The students in our intro courses today will write much of it, mostly by directing agents. The question for educators is how quickly our courses adapt.
With no proven playbook yet, the best way forward is to compare notes and measure what works, not rely on conference impressions. We are running a short Trends in Intro CS survey for CS chairs and faculty, about how intro courses are changing. We will share the results with everyone who takes part.
Take the Trends in Intro CS survey
