⚡ 深入 GitHub 的 AI 革命：Jared Palmer 揭示 Agent HQ 与编程 Agent 的未来

All right, we are here for a very special edition of Latent Space with my buddy Jared Palmer, SVP at GitHub and VP at Core AI at Microsoft.

Correct. Dual title.

Yeah, twice the time. Is it weird to have 2 jobs?

I'm only on day 13, I think, so early days. So far, so good.

So far, so good. We've been trying to get you on the podcast for 2 years, I think.

I think so. Yeah. Don't worry.

Yeah, you're a busy guy. We have to do it in person. It's way better.

I should also plug that Jared fans should dig into your previous podcasts with Ken. [Laughter.]

Okay. But Ken—shout out to Ken.

Before that, you were building v0 and AI SDK, and you were VP of AI at Vercel.

Yes, yes. All AI initiatives and vibes.

I feel like, basically, you went from building one coding agent to now being the home for all coding agents. Is that the general vibe of Agent HQ?

I think that's right. Backing up, I spent the last 2 years or so building v0 at Vercel and AI SDK. Then this summer, I took time off, and now I've joined GitHub. Today, we launched Agent HQ, among other things, here at Universe.

It's going to be the home, we hope, of not only agents but also developers. It seems like a gravity well for this new collaboration space that we're trying to build.

What do you think GitHub can do that you couldn't do at Vercel?

GitHub is an enormous platform, right?

183 million?

Yeah, GitHub has over 180 million developers. The scale is immense. v0 was focused not only on one language but one framework and a specific problem space with a built-in renderer.

For those who aren't aware, v0 is like Bolt or Lovable, but it's built by Vercel and focused specifically on building Next.js apps. That constraint was rather liberating for the team at the time and let us really laser-focus on it.

I hope. Thank you. I hope.

Obviously, at GitHub, we're the home of all languages, frameworks, and developers, so the scope is broadened. It's just a different part of the map, if you will.

You've basically been covering the entire journey of coding agents from the start. What's your personal journey through coding agents? We started out with Copilot—obviously, GitHub started the Copilot trend. Tell us about the origin story of v0, how that developed, and maybe where you want to see things go next.

It's funny you ask that, as I've told the story multiple times. I feel like I've unlocked different parts of it in my brain by going back, so maybe we'll have to figure out how retrieval memory works.

Interesting how memory works for agents.

Totally. That's why I brought it up. Sometimes you discover new paths, right? Anyway, the story goes like this.

When ChatGPT first came out, it was obviously incredible—world-changing and the fastest-growing product ever. I looked back at the timeline and dates, and we were very early in jumping into AI stuff when I was at Vercel.

At the time, there was no AI division and no AI group. I was the director of engineering for all of Vercel's frameworks, and I was helping with Next.js—spelled right?

Yes.

Next.js, Turborepo, Turbopack, Webpack, and all the internal developer tools at Vercel. I was helping the Next.js team dogfood and test the initial implementation of Server Actions. Instead of building a to-do app, I was like, “Why don't you build a playground?” And I was like, “Okay, cool.”

That led to AI Playground, which is now just part of AI SDK.

Nat.dev—Guillermo told me about it. I got a DM; I remember, because I was at a bachelor party. He sent me a note saying, “Nat.dev is launching on Monday. You have to ship.” I had been working on it previously, so he was like, “Same idea.”

Yeah, so he got wind of it, I guess.

I definitely had to jump into motion. We didn't even ship chat first. Guillermo sent me this DM over the weekend while I was at a bachelor party. He sent me the link to Nat.dev, this side-by-side thing, and I played with it. I was like, “Cool, okay,” so I sprang into gear and shipped AI Playground.

What was cool about AI Playground was that it forced me to go through every single model provider's API docs and figure out their quirks and nuances around streaming. At the time, it wasn't like everybody used OpenAI; they all had little quirks, though some of them were somewhat compatible. That was my first foray.

Then I launched AI Playground, and it shot to the top of Hacker News. I remember I didn't even implement chat because chat wasn't as important. It was just completions. Eventually, we added chat, and out of that project came AI SDK.

I had already looked at all the model providers and all the combinations and was like, “Okay, here's that chunk of streaming code you need.” AI SDK found that niche of asking, “How do we focus on the part that we're going to be good at, which is the UI aspect of it, but also not get in your way?”

We shipped a playground, then AI SDK launched. We're always about demos and having great starter templates at Vercel. I remember writing Guillermo and saying, “You know what would be cool? This guy, shadcn—he seems amazing, and his UI library is doing great. Why don't we team up and ship a ChatGPT clone open source?”

We did. We shipped this awesome template, which is now called Chat SDK, and it's great. What that did at Vercel was set us up for rapid experimentation, because we had this really good, pretty full-featured, ChatGPT-ready template with all the latest features.

When it came to rapid prototyping that summer—now we're in summer 2023—it was liberating. By that point, I had gained some momentum internally and pivoted almost entirely to AI. I had Shu Ding, who you're friends with, Max Leiter, and shadcn cooking.

I think code execution had just come out. I think that's my timeline.

Yeah, the Code Interpreter sandbox.

Code Interpreter. That's what they called it at the time. As soon as I saw this, I had a very ambitious idea and proposal to present to Guillermo.

Mind you, tool calls didn't exist, and the context window was 4,000 tokens, so there wasn't much there. What if we had a thing where you could prompt and sometimes it would do code interpretation, then maybe it would choose to render a UI? Other times, it could render a document inline in the chat. It would just have different kinds of generative UI.

Maybe you could pipe them together, so the output of one could feed into another prompt. If we did code interpretation, we could coerce it to always emit tabular data. Maybe we could pass that to another prompt that rendered a UI.

Yeah, it sounds like these are just tool calls.

That's exactly what these are.

I came back to Guillermo, and at the time we had a security debate: Should we allow code interpretation with the ability to fetch data? Giving it internet access was scary at the time. Now they're like, “Fine, whatever. Do whatever you want,” but at the time it was a little scary.

We said no to code interpretation, but the UI idea was pretty neat. That prompt-to-UI idea was the aha moment of v0. The models weren't very good, though, relative to where they are now.

That was the GPT-4 era. We were just into the GPT-4 era, and we were probably at a 16,000-token context window. You couldn't really do chat, so we had to invent this new paradigm of faking it with completions. That forced us to do the initial v0, which launched in September 2023.

It looked more like Midjourney. In fact, if you go back to the original tweet, it was “Midjourney for React.” It was all very visual, and you could click on different components and elements and reprompt. Again, we were hacking around the limitations because we didn't have chat or tool calls.

Fast-forward again: v0 launched, and then it probably took us about 9 months to get to $1 million ARR with this little team. The models progressed from GPT-4 to GPT-4 32K—the big boy. We never really got GPT-4 Turbo working; I don't know why that never happened.

Then we switched to other frontier models and started doing our own models and things like that.

But fast-forward another 10 months, or 9 months or so, and then we rebased toward chat, and now the models finally could do chat. The artifact pattern had evolved, so it was time to rewrite. When we launched v0—the chat version, or the new v0, whatever you call it—it was 14 days, another $1 million ARR; 14 days, another $1 million ARR. It was like a rocket ship after that.

And that just proceeded, and we just kept cooking. That’s been the journey. We just kept perfecting, and what was really liberating for us was the focus on just one stack or one framework. When everybody else was trying to do a general-purpose coding agent, we were like, “No, we’re just going to focus on Next.js front end and shadcn.” That really allowed the team to focus. That’s the story arc.

I mean, to be fair, because Next.js is so dominant, basically everyone has to be good at Next.js, right? But being focused even right down to the UI library and component stuff like that helps a lot.

We also started working with all the frontier model labs to help, because it was in Vercel’s best interest to have them be great at Next.js.

Yeah.

And also because of the post-trained models—you can read about this on the Vercel blog—we had the post-training harness that we created, and we started sharing it with other model labs. We had all our data in a very hygienic state to work with them.

Did you ever debate internally—and, from my seat at Cognition, I can also see this—whether you should pick the best qualities of every model and string them together in v0, or have a model selector and let customers go back and forth?

Yeah, we went back and forth on all this. I think at the end of the day, there are pros and cons.

Yeah. One of the benefits of having your own branded model, whether synthetic or composite, is that you can stitch these things together. It’s a little different now with the agentic flow, but even look at what you guys launched recently with v0, right? Search is going to be a different model than generation, but search and generation are 2 different subsystems, right? So you can have search eval be totally different.

So where we’ve probably ended up now is that, for a long time, we didn’t have a model selector, and then we had our own models, which were composites, as we talked about. That would allow us to mix and match. I think that’s probably also nice because, as a product, you get to brand it.

Right, and you can decouple it from the launch of the frontier lab.

Yes.

How does Cognition even bill for it? An ACU, right?

So it gets a little wonky. We could go on about pricing this stuff; it gets challenging. But the nice thing about having the brand-name model is that you get to co-launch with the provider, and they’ll hit you up.

But your billing needs to be capped at whatever retail is, right? Or some—

Right, right, right. You can’t really charge too much of a premium. You can, but—

Right, right. And it’s like, well, then how do we charge you for SWE-bench or something?

I think some part of it is the cynical part: you want to create a sustainable business and independence from the model labs. But the other part is genuinely that you actually do get better performance—you get to string together all these things.

Yes. Switching gears to GitHub, we’re all about model choice now and making sure that—and what’s cool is that we also have Copilot, which is our harness, and Copilot CLI. But we also have third-party harnesses like Claude Code, Codex, and Devin now in Agent HQ. So you get the best of both worlds. I think that’s going to be awesome and ultimately what people want.

Yeah. I think the model layer is not the right abstraction to do the switcher anymore. It’s weird, because that’s where you started with the AI SDK.

Yeah, exactly.

But now the model and the agent have to be strictly tied together—very, very strongly coupled. You can’t loosely bind them and just do a generic interface, because then you’re just going to have the lowest common denominator of all the models.

If you’re in the agent world—

Yeah, yeah.

—which may just be better than the chat world in general. Better.

Agent world is a much better abstraction. I’m calling it agent world, but I mean a loop with maybe a compute runtime and files.

So that’s your definition of an agent? You’re dropping your official definition here.

No, don’t put me on. My initial definition of an agent for AI—I was dying on this hill because the AI SDK, everyone else is an agent framework—was that an agent is orchestrating an API request with a queue and a for loop.

But a coding agent now has meant so much more. There are coding-agent SDKs, and you’ve got sandboxing, file systems, and tool calls. I do think that’s a uniquely different world. I’ll call that agent world.

Yeah, and I think that seems to be where things are going. I even believe the Claude for Excel agent is basically related to Claude Code. I was talking to my colleague backstage, and I think it could be.

It could be. I actually don’t know how it works under the hood yet, so it wouldn’t surprise me if it was.

Yeah. They seem very all-in on skills, which is kind of interesting.

What do you think of skills?

It’s kind of DXT, which is the bundled version of MCPs.

Okay.

Wasn’t the reason you didn’t know about it that it wasn’t very popular?

Okay.

Skills are kind of the second shot that’s very LLM-y. It’s like, “Just read my Markdown and read this directory of files and go nuts.” As long as it can understand that it has the capability to run code and read files, you’re good. And actually, that is the universal interface, which is a file system.

Right. Back to agent files.

Yeah, which is kind of cool.

Yeah. What you’re hitting at is this philosophy of our understanding of what the minimum bar for coding agents is. Over the last 2 years, you’ve lived this journey, and now you’re basically the kingmaker.

I don’t know about that.

You run Agent HQ, and I imagine you have other projects too, but Agent HQ is the big one that we’re talking about here. What are you seeing from the different agents, and what do you want this to become?

Such a good question. I think Agent HQ and GitHub itself need to co-evolve. One of the things that Microsoft has done really well is putting things that are alike closer together. Think about the new CoreAI organization: Visual Studio, Visual Studio Code, GitHub, and parts of Azure are all in one. Obviously, the GitHub team and the VS Code team have been working closely together for a long time, but now we’re really close together.

For me, one of the cooler things that Agent HQ can offer is seamlessness and fluidity with your workflow. If you saw the demo today, we saw a demonstration where you use Agent HQ, fire off a task, and it creates a PR, but you can also open that PR up in VS Code with one click. That’s awesome.

I think the vision for GitHub as it evolves is to look at those touch points where AI can be sprinkled in, in a Salt Bae-style, into the native workflow. Whether you’re assigning an issue, or maybe some new stuff that we should focus on, could be: How do we resolve a merge conflict?

Oh my God.

Right? How do we maybe pop open an action or get in? We’ve all been in that flow where Actions don’t work locally. What if we could just put in a comment or kick off a task to solve this for you? What I’m trying to describe is a workflow where it’s seamless and fluid, and you can stay in a flow state across all devices—mobile, the web on GitHub.com, or in your local editor. That’s where my focus is going to be for the next 6 months or so.

Yeah. As a side tangent, one of the things Microsoft also owns—I don’t know if it’s Microsoft or GitHub—is dev containers. I think a very important concept for sandboxing environments, whatever you call it, is a lightweight version of what Docker containers are. Do you see that as a standard that we should invest in? It’s supported in VS Code, but I don’t think it’s that popular outside of VS Code.

Yeah. It's used internally at GitHub too for development at GitHub.

Oh, yeah. Yeah.

Which is cool. I think they were so far ahead, but now there are sandboxes. There are so many of them these days, right? I think Cloudflare just launched theirs. There's Daytona, and there's Modal, which I think Lovable uses.

I have no idea.

Yeah. You probably have your own. I don't know. What do you guys use?

Just some Kubernetes pods.

Okay. You guys roll it yourselves. Cool. I think that's maybe the runtime, but there's work and discussion about what that runtime should be, even internally at Microsoft. We've got a couple of different competing things, so we'll figure it out in the next cycle here.

But there's a great point: there's a lot of cool stuff in a dev container. You already have VS Code loaded, you've got a file system, you've got a sandbox, you've got the security protocol, and it's also wired into GitHub Enterprise.

Yeah.

It's ready to be packaged, so there's lots of goodness there.

Yeah. I say the number-one pain point that Cognition has—but Codex and presumably the other guys do too—is repo setup, which is effectively what dev containers and a Dockerfile do for you: run this thing, then that thing, set this up, do that thing. Why is it so hard? Why haven't we solved it?

I don't know. I think it's hard because you can't predict what's in the repo, right? You don't know when they bundled FFmpeg. You just don't know.

It's nice when it's just Next.js and you can run npm install.

Correct. Correct. You can make optimizations with obvious constraints, and I think the general-purpose container is just challenging. That being said, there's probably some work to do on autodetection and preempting and stuff like that, but it's a bigger, broader problem space, right?

Yeah.

So, fun fact: when I was at Netlify, I actually wanted to reach out to Vercel to do a standardized, open-source autodetection system for frameworks. We never got internal momentum on that. It was an idea. I was like, “Shouldn't this be open source?”

Yeah. Yeah.

Autodetection is a common utility that everyone needs.

Yes. Yes, I remember that. I'm having a flashback.

Yeah. Everyone knows theirs. Yes, probably we shouldn't all build it, right?

No, it's—what are your defaults? They're not exactly the same, which would be better to—

Just having even the same preference stack of defaults would be the right thing. Yeah.

It would be great, because then we can move the whole ecosystem together from npm to Bun, right?

Are there other movements, protocols, or standards that you're interested in? MCP was a big winner this year. There are others, like A2A and ACP. All of these are interesting. I'm not as familiar with ACP, the payments one. Is that the x402 one?

Oh, no, the x402 one. The—

The one. Okay.

And then the payment one—was it Stripe or Coinbase? Stripe. Yeah, that's very cool.

We've had them on the pod.

Okay. Yeah, that's very cool. It would be interesting to see if that takes off.

I mean, it's right. So—

Yeah, but it still needs to be adopted by the clients, right? I think that's fascinating. MCP is huge. It seems like it's the way that a lot of our enterprise customers, especially when it comes to digital transformation, will be able to add context.

In addition to that, we also have custom agents that we announced today. You can work with prompts and stuff within your Agent HQ and customize these agents for different tasks. Those can have MCPs and such, and I think that's going to be really powerful from a platform perspective. That gets me excited. That's what I think is shipping now and next, but we're always on the lookout for the next thing. What's top of mind for you?

For standards or—

Standards.

Standards should be: a container is a container.

It's the—

Look, I think dev containers just have a PR problem.

It's a great idea.

Right.

Just no one—

Makes it interesting. I think you can do it, basically, with this one.

Okay, added to my list. But before that, you probably have a bunch of other stuff that I do want to get to. Just staying on the AI stuff, I think we're actively exploring computer use as a thing. It got going a little bit, people were very excited, and then they found out it was slow, bad, and inaccurate.

It is computationally intensive, my understanding.

It's getting better.

Yeah.

Especially with open vision models like DeepSeek-OCR and olmOCR. Just give it a few more turns of scaling.

It seems like you need that use case, and primarily it just seems like a modality worth pursuing. A lot of people on the code generation and code agent side are trying to think about this. We had this evolution from Copilot to more agentic systems, sort of like a Claude Code situation. What's next? What's the obvious next step?

Making them good.

Making them good. Yeah. You don't like Claude Code?

No, I don't. It's more that the devil's in the details.

Yeah. Going from 90%—it's like hill climbing; it gets steeper.

In my opinion, it gets steeper. Going from 90% success to 95%, to 98%, to 99%, to nines of success—

Yeah.

I mean, it's really hard.

I mean, it's really hard, paying a lot of money for expert programmers or open-source maintainers.

Then you realize along the way maybe the users aren't that good at it.

Yeah.

No, but I just think there's a lot of work to do to finish the swing. There is a big difference between 98% and 99% correct, and that's noticeable.

If you're working on an AI product, you probably don't realize how poor the quality of your AI product is lately. Most people are blind, living in La La Land, unless they're really measuring the number of error-free sessions, how many errors are coming from the infrastructure providers, how many requests are dropped, and how fast these things are. That's something we cared about at Vercel quite a bit, and we'll care about it.

Do you have a daily review of your dashboard? I don't know.

Daily? Daily is slow. Okay.

I thought you were going to say daily is too much.

No, you're thinking it's like every 3 hours—a roll-up of key metrics and stats.

Yeah.

One of them was error-free sessions, and other things like that were really important. Especially now, with agents, which are multi-turn, I have a tweet about this from 2024: agents will really only work when we get not only more intelligent models, but also better reliability from the infrastructure providers.

Inference is not like a database uptime update. There are still differences between providers, differences in performance, and differences in uptime. That's why you see things like OpenRouter being very successful, along with different gateway products.

We would switch because of reliability; they go down all the time. Long story short, it was almost like a video-game style system. We'd have all the data coming in all the time, and that allowed us to do what I used to joke about as mood ranging: good day, bad day.

So it was very successful for us. I think other teams should adopt that data-driven approach. One thing that's surprising is the relative lack of data-analyst agents, where you can chat with it or add a Slack bot for the precise analytics that you want to generate. I think we're still in the BI era.

Yeah. Isn't that weird?

Yeah, I totally agree. That space hasn't been captured as much. Actually, I'm interested in this shift into knowledge-work tasks with coding agents.

Okay. I wonder—

Using coding agents for non-coding tasks.

Correct.

Do you do that personally?

I do. Yeah.

Yeah? What do you do?

This summer, I was helping automate some of my dad's workflows. He's got some Excel spreadsheets for financial accounting, or managerial accounting, I guess. I pointed Claude Code at that stuff to see what happens. It ended up doing Python and generating some scripts. It kind of got off the rails, but even he saw that it was better at it than ChatGPT.

Super obvious.

It became kind of obvious. It felt better.

I wonder if he can try Claude for Excel and see.

Yeah, you got me, right? And then, of course, you've got the browser—the browser-based agents, not computer use, but browsers with agents.

Agentic browsers, Perplexity, everybody—is that better? If that's true, then maybe the general-purpose injection point is there. Have you tried any of the agent browsers?

All of them. I'm currently using Atlas mostly because I just want to give ChatGPT a fair go.

Okay.

But I'm stuck with Arc and its vertical tabs.

Oh, okay.

I think any pro user—I have multiple businesses.

How many tabs do you—

I'm context-switching, right? I have hundreds of tabs open. I made an open-source tool called Chrome Dump. You can find it on my GitHub. It literally dumps all the open tabs, summarizes them, and then I can close them by deleting them in Markdown.

That's pretty cool. [Laughter.]

So you just go on a bender, and then you dump it.

Yeah. I mean, it should be as easy to close as Markdown in Chrome. Chrome isn't that good on the performance side of things yet.

And you were working on some browser comparisons.

I was, but I tried to build it in Tauri.

Okay.

Tauri explicitly doesn't want you to build a browser, and I tried to fight it too much.

I see. Yeah, very cool.

So, just to wrap things up—we're about out of time—there are other side projects, tasks, and things that you've announced here. First of all, redesigning the GitHub homepage, which a lot of people don't even know GitHub has. [Laughter.]

I legitimately want RZ's tweet printed out.

You read the tweet. There's a tweet like, “No one uses all of this stuff. It's totally useless.” I'll pull it up.

I quoted it today because, when we launched—let me get it right, because I've got to do it right. Hold on—it was, “Incredible how pretty much the entire GitHub homepage is useless.” It has 1.3 million views and 19,000 likes, and this was May 22, 2025.

So I heard the team made improvements, and today they launched a new GitHub homepage, which I'm very proud of. They should be really proud of it, too. It's got tasks at the top and recent PRs. Some stuff is still there, like your recent repositories. I still think there's more work to do, but it's really overhauled, and they did an amazing job with it. They nailed it.

There's always more work to do—it's never done—and hopefully we can keep iterating with the community and everyone and keep going.

The last thing I want to hit you on is stacked diffs.

Oh, you asked everyone when you joined what I should work on or something.

Yeah. What—

I don't know if this is your job specifically.

It wasn't, but why do people want stacked diffs so much? I think you have some history there.

Yes. Anyone who's interacted with anyone at Facebook knows about Phabricator, just about it.

So can you explain why it's been so—what it is and why it's so hard?

Okay. So this concept of pull requests, which we're all familiar with: You write some commits, you open a PR, and then you merge the PR and go about your day.

As you scale to larger organizations, you look at your history, and there are people who have near-religious beliefs about how to do Git right: rebase versus merge. There's a crowd that wants to fast-forward the repository to preserve all the history, and then there's a crowd that wants to squash and merge.

Anyway, at Facebook—and I've never worked at Facebook—in my previous startup, Turborepo, I did a lot of research on build systems. Facebook has custom build tools called Buck, a custom file system, and they don't use Git; they use Mercurial, which is now sort of custom, and it's all wired together.

At Facebook, they don't use pull requests. They have a different sort of philosophy. The best way to analogize this is to imagine every PR just had 1 commit in it. You could branch them and restack them, and the critical thing is that you can restack them. If you restack or make a change later—like earlier in the stack rather than later in the stack—and these stacks are just diffs, the commits are just diffs, and that's the term “stacked diffs,” you can then collapse them and merge the last one as a single diff.

It gives you a nicer workflow, and if you work on a monorepo or a very, very large codebase, it's a really nice way to work, especially if you've got a system that will automatically restack. If you think even more deeply about it and get really deep into the weeds, you can decide which diffs in the stack CI should run against, if you get fancy.

By a commit message or—

They're just always there. Yeah, you could decide: Maybe this one doesn't need it, or skip that one, or whatever. You end up getting these groups, these stacks, and it's really nice from a code-review perspective because, when you go to update—or you can update a different part of the stack—it makes it a little more fluid. That's what people want.

There are a couple of tools on the market that do this kind of behavior. One is called Graphite. There are a couple of others.

Too many tools called Graphite. You see? Here's another Graphite right here.

Yeah, yeah. It's a workflow, and so it's been the top pull request—or, sorry, the top feature request—

Feature request.

Feature request, thank you—at GitHub for years, from the community's perspective. I don't know about GitHub, but as soon as I joined, the first thing I did was look this up. I asked how I should make GitHub better, and it was the top feature request.

I went to investigate, like any good product person would, and there have been multiple attempts at this internally going back to 2020. There was one very, very polished attempt in 2022, and I don't have all the context, but there was a pretty good implementation. All of the work was done on the client, and it reintroduced a new concept called stacks outside the pull request into GitHub. It was deemed a little too risky, too big of a change. That's just what I was told.

Anyway, we've had a couple of meetings internally already, and we're trying to weave it into planning and the roadmap. Hopefully we'll be able to share more updates soon, but it's a top-of-the-list known feature.

Again, heard.

Yeah. We're working on it. Obviously, something the size of GitHub moving to support this kind of new feature isn't just a walk in the park because of the size of GitHub and GitHub's Git implementation, but it's something that we're actively exploring.

Yeah. Well, I think, just to wrap all that up, it's really nice for someone who's so deeply engaged and coming from one of us, literally, that you now run things at GitHub and we can just add you like that.

Yeah, yeah.

That you now run things at GitHub—

Yeah. I think Andrej Karpathy was saying the other day that every company needs one of these where you can say, “Hey, this really shouldn't exist at GitHub. We love GitHub, we use GitHub, but come on.”

Feature requests welcome. My DMs are always open.

Oh, careful.

I am of the philosophy that all feedback is a gift. It's all a signal, and the more signal we can collect, the better decisions we can make and the more we can truly build this really useful website and company together. I think that's going to be the future, and if we focus just on that, we're going to be okay.

Yeah. We're going to be okay. All right, well, thanks so much. Pleasure catching up.

Yep, likewise.

Congrats.