
GitHub Universe 2026 recap: AI speeds up planning, and the guardrails have to follow

I spent last week at GitHub Universe talking to all kinds of people across the tech space and attending many of the great sessions at the event. It was a whirlwind couple of days, but these five sessions really stuck with me, and I wanted to provide my take on why I found them so relevant. I provided links to recordings of the sessions where available.
Planning is where AI is paying off first
Most of what I hear about AI relates to writing code. Levi Strauss showed something different in “17 agents, one SDLC,” presented by Jenny Patchen, Senior Director of Shared Platforms and Services.
There was a lot of waiting in their original development process. When they looked to streamline that process, they started with the planning phase. They used AI to sharpen requirements and get everyone aligned on the same ideas before anyone wrote a line of code. From there, they split the work into distinct human tasks and AI tasks, with a human gating every major decision.
Development ran on a group of specialized agents covering requirements verification, security, observability, and more. Each agent iterated on its task until it was done. It’s a company using AI across teams to ship a feature faster, and the plan itself feeds the automation.
The closing keynote carried a similar sentiment. GitHub demoed chopin, a GitHub Next research prototype for authoring durable documents with repository-grounded agents. Think implementation plans, specs, RFCs, and decision records. What stood out to me is that a team plans together instead of one person working alone in Copilot. Then the plan goes to agents to implement. I think that helps people from different technical backgrounds iterate on a feature quickly. It’s currently a prototype, so treat it as a preview of the direction this type of work is headed in.
The job changes when review can’t keep up
This was the best talk I saw at the conference: “Write-only code: What happens to peer review when agents write the diffs,” with Dylan Ratcliffe (founder and CEO of Until) and Adam Jacob (CEO and co-founder of Swamp). Unfortunately, it doesn’t look like this one was recorded. But for those of us in attendance, the speakers had the audience pick which sections they covered, and the two of them argued for each of their respective approaches live on stage. It was highly entertaining.
Swamp’s approach is a full AI-driven software factory. If the factory gives a result you don’t like, you update the factory and run it again. Adam’s advice was to get the team to agree on the plan the factory works from.
They raised issues around pull requests getting bigger and review times getting shorter. Changes land so fast that engineers struggle to hold a mental model of the system they’re working with. So, Dylan and Adam asked: “Is your best engineer the best because of what they know or what they can do?” The answer they settled on is that understanding the system, and being able to picture a change, matters more than typing the implementation. You can leave the actual typing to the factory.
They suggested spending the time agents give back on talking to your team, making sure they understand the system as a whole. One line stuck with me, and I’m paraphrasing: “We’re working the same old way and rubbing AI on it.” That made me chuckle.
Automate the boring, necessary work
Visa’s “Zero-Secrets Initiative: no hardcoded secrets, no exceptions” presentation came from Kautilay Siingh (Security Architect) and Sanjeev Murthy (Director of Cybersecurity). Again, it looks like there’s no recording of this one.
Visa built a series of agents and processes that find secrets checked into its codebase. The system notifies the developer who committed each one, then verifies the secret is no longer active. Checking for secrets is necessary but it can also be boring, so Visa made it automatic and repeatable with AI.
My takeaway is that it makes sense to identify the checks your team does manually because they have to be done and automate them.
Package controls are moving to the front door
The talk I attended that lined up closest with our work at Cloudsmith was “Stop malicious packages before they reach your build with GitHub Package Firewall,” presented by Eric Sorenson, Senior Product Manager at GitHub.
The firewall aims to stop users from downloading malicious packages. It supports npm today, with Python and Maven coming. It has a cooldown, defaulting to three days, so users can’t download a package younger than that. Admins can exempt specific packages and toggle availability. The firewall can sit between the user and the registry, or between a private registry and its upstream.
We think about dependency firewalls in a similar way. Cloudsmith’s policy management lets you write policies as code, so you can create custom, granular policies. We have cooldown policies too. It was positive to see the same pattern we have in place from GitHub: decide the rules once, enforce them where packages enter, and let people handle exceptions.
Tying everything from GitHub Universe together
Planning, building and secret-hunting are all getting faster with agents. Humans still set the plan and make the big calls. Everything around those decisions needs to run without a person in the loop, including what gets pulled into the build. That’s the work an artifact control layer exists to do, and that’s exactly what we’re building at Cloudsmith.
See how Cloudsmith governs what enters your builds. Book a demo today.
More articles


10 GitHub Universe 2026 sessions not to miss

Cloud Native Digest - July 2026

Cloud Native Digest - June 2026

Cloud Native Digest - May 2026

