1. Library
  2. Podcasts
  3. Open Source Ready
  4. Ep. #26, The Economics of AI Coding with Quinn Slack
Open Source Ready
47 MIN

Ep. #26, The Economics of AI Coding with Quinn Slack

light mode
about the episode

In episode 26 of Open Source Ready, Brian Douglas and John McBride sit down with Quinn Slack. They explore how Sourcegraph built Amp, why unconstrained coding agents represent a major shift, and why AI economics make traditional SaaS pricing impossible. Quinn also breaks down the rise of open source models, the future of developer tooling, and why ads might be the key to making AI accessible to everyone.

Quinn Slack is the co-founder and CEO of Sourcegraph, the developer platform behind the AI coding agent Amp. He has spent the past decade building tools that help engineers navigate and understand massive codebases. Quinn is currently focused on advancing agentic coding and shaping how developers interact with AI-powered software systems.

transcript

John McBride: Welcome back everybody to another episode of Open Source Ready. Here again, as always, with Brian. How are you doing?

Brian Douglas: I'm doing great. I've double mic'd. I've got a new mic that I haven't hooked up yet. But yeah, we were talking about the buzz that was happening in our failed episode that we never shipped.

John: So it'll be a ghost "secret episode" that will drop in 15 years or something. It'll be legendary, right? All the buzz.

Brian: Us basically planning our next guest was the entire episode.

John: That was the whole episode. It's true. But yeah, we didn't come here to talk about buzzing mics. We came here to talk about the buzz with Quinn Slack of Sourcegraph, he's the CEO. We would love for you to intro yourself. What have you been up to?

Quinn Slack: I have been hacking a lot on coding agents. So at Sourcegraph, we built Amp and we wanted to be building for the people that want to be on the frontier. And we want to make Amp the coding agent that people use today. But it's how everybody will be using a coding agent a year from now. So it's been a crazy ride.

There's nothing I'd rather be doing than building a coding agent right now, but it is just the noisiest, craziest, fastest moving thing that I think anyone has experienced. So it's a thrill.

John: Yeah. This is very funny. It's almost full circle because sometime last year we had Thorsten Bell on, who is on the Amp team. And I think at the time he was being very coy and alluding to something he was working on and was like, "this is going to be big. It's going to be crazy." And now I use it every day. So thank you, Amp.

Brian: I was thinking about that episode in preparation to this episode, because he came from Zed, previously Sourcegraph, went to Zed, did some stuff for Zed, and then went back to Sourcegraph.

And then we were just chatting about compilers, but then we also started asking, "okay, what is the thing that you're doing now? What can you talk about?" And he was not very specific. And then you guys launched maybe a couple weeks later.

John: Yeah, I'm very curious to hear the story of how it came to be, from the product org, what was the conceptualization of that? How did you decide to make this big pivot into Amp as a product? We didn't get it from Thorsten, so maybe we can get it from you.

Quinn: So, okay. AI has been pretty great for code ever since Tabnine, actually, Jacob Jackson back in 2017 or so. And then GitHub Copilot prompts them for Autocomplete.

And we've seen all of these iterations, but until about January, AI was good at one step of coding. You could ask it a question, it would do RAG, it would give you an answer. And there was a lot of people that were piling so much complexity to make that better and better, but there needed to be a fundamental advance.

And it's kind of crazy, but it turns out that 3.5 Sonnet that was released the June before that actually had a lot of agentic capabilities that were not fully uncovered until really February of this year, of 2025.

So right at the start of February is when we started building Amp. Thorsten and I and some other people on the team basically ripped out everything. And we said, "what if we just let the model rip and continue and iterate?"

And we didn't want to put any kind of constraints on it. No tool permission, no token constraints, no price constraints, and it was expensive, it was powerful. It was kind of scary that it would just go do things, but it was incredible. And once you saw that, you never wanted to use anything else.

And I think around the same time Claude Code was being built, and this was at the time when Windsurf had showed with a much more limited agent that you could take multiple steps. Cursor, at the time, they had gotten out of the composer land, but still it was, it was very limited.

And Claude Code and Amp were essentially the first two publicly known unconstrained agents. And we saw that that was going to make everything that came before it look obsolete. And everyone who had any kind of user base, customer base, whatever, would have to shed everything they had as quickly as possible and make a full agent.

So that was pretty interesting and scary in many ways for us because we also had a business at the time and we had a ton of enterprise customers. And so we really quickly figured out how do we start sharing with the world this tough medicine that you're not going to be able to control costs anymore, that these tools are so much more powerful that there's some people that are going to understand how to use them and other people that are going to be resistant and they're like a freight train.

It doesn't care about any of that. The technology that's underlying all of this has advanced and that is going to completely change how we use AI for coding and it's going to be just so much more powerful. So we saw that and that was, roughly, in March and then it's just been nuts ever since. And I think everyone has seen that with all the coding agents that have come out.

John: Yeah. One of the things I wanted to ask you about was the economics of a lot of this. I've done some research and it's honestly just mind boggling, between the data centers and the electricity on that end, and then the API-based token costs that a lot of people are familiar with on OpenAI's APIs or Anthropic's APIs.

How do you kind of square the circle on a lot of the economics of a lot of this? We could obviously get into the Amp Free stuff, but just from a business perspective, how can consumers square that circle but then also you, as a provider, what are the economics of that actually look like?

Quinn: Well, one of the painful transitions that a lot of other coding tools had to go through starting a few months ago, was switching from these all you can eat subscription plans to pay as you go. And this is something that we started with from day one on Amp doing pay as you go, so you pay for the tokens.

And that meant that we didn't have to worry about losing a lot of money or watering down the product because the prices are uncapped, it is not possible to cap them. And they're so much more expensive than anything people have paid in the past. But the thing is, the fact that they're so much more valuable means people and companies are willing to pay. Now, not everybody.

There's a lot of companies out there that they said, "well, the way we've always bought software is we have one price, maybe it's per seat, and we'd like to continue doing that with coding agents."

And that is not possible. We've had a ton of conversations with people who say that, and I understand why they want that. But what they're asking for is something that is fundamentally not possible. It's like if I went to PG&E, our power company here in California, and I said, "actually, I would like to have unlimited power and not pay you."

They would say, no can do. And there's still a lot of companies that are struggling there, and that's holding them back from adoption. The market is so big though, that for us, we've just worked with the companies that do see value in this, and they want to be a year ahead.

Brian: I'm curious, when you're going to the pay as you go model, you might have thought through a bunch of different other ideas. Devin popularized , I guess they pitched the agentic workflow. They ended up shipping it later. But when they shipped, the pricing was $500 a month. And that was shocking.

And everyone was like, "oh, $500 a month? That's insane." Some people paid it. And then Claude Code, which came out months after your... Or maybe it was around the same time? I'm not even sure when Claude Code actually shipped, but it shipped with a max plan that was $200 a month, alongside of that.

And I think folks started coming around the corner of like, "okay, $200 a month, I can get that."But even in the last couple of months, Claude's definitely clawed back a bit of the functionality and features and access to models.

So I guess what I'm saying is, what were you thinking when you went pay as you go, that you consider the monthly subscription? And then, do you have a comment on, now the world is kind of moving towards pay as you go? It feels more like reality now.

Quinn: So, yeah Claude came out with Claude Code in February, and at the time it was pay as you go. And then it was in April, I believe, that they introduced Claude Max and they've had a few different changes to that. And if we could offer a $200 per month subscription, that would be all you can eat, we absolutely would.

Now, not even Anthropic can do that, or OpenAI can't do that. They still have rate limits that get in the way. For now, just given how fast everything is moving, if we were to have rate limits and pricing and have that all be so complex--

And then, by the way, you never get it right the first time, and so you have many legacy pricing models. Just go digging in the Cursor settings or elsewhere to see all these legacy things. That's devoting 20% of your engineering team to managing all that complexity because you cannot mess up billing.

So we just said, "we're not going to try to satisfy the person who really wants to pay maximum of $200 a month." Now there's a lot of people use Amp who pay less than that, including with Amp Free. But we're just going to be building the very best product and we think that's going to dominate.

But it's become clear there's a few other things going on that at times privilege the companies like Anthropic and OpenAI that have their own models and data centers and at times make that a liability. I think that's the big question.

So if you're Anthropic, you have a fixed amount of capacity, they rely on AWS and Google for it. If you're OpenAI, you have Azure and all these other data centers and at certain times of day they have more ability to give cheaper free tokens than they do at other times a day.

So they've got that variability that's their peak load, that they've committed to their enterprise customers and their kind of average rate. All of those tokens are essentially free for them to play with. And every second that that capacity goes unused is wasted money.

They pay for the marginal power consumption, but they have the ability to give away cheap tokens in a way that application layer companies like Amp and Cursor and Windsurf don't have.

But at the same time you have the countervailing force of open source models getting better and better and all of the other data center build outs that are not from one of the foundation model companies where they have a lot of GPUs that, in some cases, are sitting there. There's a lot of other constraints on them.

It's not like there's a ton of unused capacity, but if you build out the data center and you're not Anthropic or OpenAI, then you'd be looking for a moderate return on those GPUs that can beat the marginal cost of power. And that's an opportunity for companies like us to then have that pricing power exerted on Anthropic and OpenAI and to compete.

So there's so many unknowns. I think the biggest thing that we're watching is how much better are open source models becoming because that's going to drive inference down to the marginal cost of power. And Anthropic and OpenAI are really hoping to be charging more than the marginal cost of the electrons.

John: Yeah. That seems to be maybe the greatest threat to some of these products, really, where there's a really great open source LLM, the weights that I can go and download and you know, the non-existent Blackwell GPUs that I have in my house, I could go and run and then do my own inference, probably much slower since I wouldn't be able to like--

Well, who knows? I've seen some of these people with crazy GPU clusters in their house on like homelabs and stuff. So is that really one of the ways that you could see a lot of this going is the personal, home-GPU, AI-cluster thing?

Quinn: I don't think most people are positioned close to a low cost of power. So I think that there's still a lot of economies of scale you get from data centers and build outs. It's also a dynamic system where as long as open source models are trailing behind and they're not actually unlocking capabilities, new capabilities, I don't think they're going to be that interesting because most of the excitement is on the frontier.

If you though can take open source models and because they're slightly cheaper, they're more flexible, if you can run them on hardware that can perform inference much faster, like Grok or Cerebras--Grok is an amazing product--and if you would be able to, whenever someone wants to do something in a coding agent, run it 10 times and throw away the nine worst ones, keep the 10th, that's the best.

And if that kind of thing is made possible because of the increased flexibility, speed and better cost of open source models, that's where you could actually make the case that a coding agent that uses open source models is superior. Not just cheaper or faster, but superior. And that's when I think it gets really interesting.

And with open source foundation models, you have so much more experimentation going on than the kind of product catalog that any single OpenAI or Anthropic-like company can provide. And they're also anchored at price. They have a single price that has to meet a lot of different customers needs.

And if they were to drop that to be viable for certain kinds of new applications around the frontier, then that would cause an immediate hit in revenue to their are other use cases that are not. Price discrimination is difficult for them.

John: Interesting. Yeah, I had not really considered that idea that you could have many of these small models, running parallel. I guess this is something Continue does. Right, Brian? You could have many parallel jobs to then be able to handpick the best one. Right?

Brian: Yeah. I'm not sure if you're familiar with Continue, but yeah, we went the local model route.

Quinn: Oh yeah. Continue is awesome.

Brian: Yeah, so at the enterprise level, folks can choose their own models to run it local, behind their firewall. And it's actually interesting because I know with the Gemini CLI, they have a router that's pretty aggressive.

So you ask for the thing to do the thing you want the agent to run, but it's going to switch over the Flash pretty quickly. And it's not a great experience when you pay $20 a month and you're like, "oh, you know what? You're like, give me some garbage code. I'm spending time going back and forth and cleaning this up."

At this point I might as well just write it myself. And that's not a dig on Gemini. I probably could pay $200 a month and get a better experience, but the developers are pretty fickle and when, if you want to get the best opportunity or to ship a bunch of stuff and try out what agents are really capable of, I think what you guys are doing is amazing, specifically for Amp and doing pay as you go.

But actually I did want to transition and actually talk about Amp Free because I'm super excited about what you guys are doing. I would love to hear how it's been going on your end, what's the feedback from developers?

But also I did want to throw this one thing out there. Back in my day, after 10pm you get free calls, like on cell phones. Just throwing this out there: "Amp at Night," off peak hours. You can also get "Amp Free Plus Plus" and maybe get some extra features through it.

John: So an extra little spice at night, in Amp.

Quinn: I love that. See, that's perfect because it aligns with, when in theory, tokens are cheaper because at the limit, there will probably be unused capacity over the weekends for most people. Yeah, we should do that.

John: You heard it here first. It's great.

Brian: Yeah. Cool. Yeah, if you want me to wear a NASCAR jacket and have an Amp thing, I'll promote it. Amp at Night.

Quinn: Yeah. And weekends as well. Weekends might be easier because everyone has a different night. And, I think we all know a few coders that code at night. I might have a few 4:00am nights every week, but definitely weekends. So you heard it here first. We will try to ship that. We'll see how it goes. But that kind of experimentation, that is exactly what led us to Amp Free.

Fortune favors the bold here in coding agents. And if you want evidence of that, just look at the crazy kinds of investments that Anthropic and OpenAI are making. There's hundreds of billions of dollars going into data centers. Everyone is being incredibly bold here, and everyone is making a big bet on the future.

And we realized that the bet we made by making Amp in the first place, to be a frontier coding agent, that was a really bold bet, but we need to keep following it up with things that are bolder and bolder.

And so we took a look at the feedback we were getting from people using Amp. People said, "hey, it's really good, but it's also really expensive."

And we did not want to do what everyone else seemed to be doing, which was make a subscription plan, start burning a ton of money on our side in an unsustainable way, set ourselves up to then have to rug pull, like it seems so many other tools did not. Not Continue, obviously, and some have stayed away.

We wanted to do something different, and we speculated, kind of started out as a joke, what if we show ads and we, then made some mockups and our own team is like, "hey, actually that's pretty non intrusive."

We talked to some companies that would want to advertise and they were willing to do it. I was surprised how receptive other people were to it. And it turned out, even the day before launch, we were so successful in getting more advertisers that we just said, "screw it, let's try to get 15 more on."

And we had just an incredible hit rate. We had large advertising contracts signed between 6pm and 8am the next morning of launch. So there was a ton of excitement here. And it also is doing something different, it's doing something bold. It was the first totally free coding agent.

And it's not to say that there's not other temporarily free models that other coding agents can use, but what we've made is a commitment to always hustling and sourcing free good tokens that are going to work, so that--

Right now Grok Code Fast from xAI is free, if you give them your data, which we do not require in Amp Free. They might turn that off. And then if you're using free through any other tool, that's going to go away. But we've committed and we've sourced a lot of different places where good free tokens can be used through Amp Free.

So it was a big reception and I was shocked at how positive developers took it. I am glad because I think there's a realization that AI is really expensive and that this is a model that not only lets you mix and match, you can use our paid mode and free mode to kind of arrive wherever you want on your pricing spectrum.

And it's also something where we need to charge for it. So there's not the expectation of, "oh, it should be free," as there is with a lot of other things. So it's been thrilling and now it's just, how can we go even bigger and bolder? Like the nights and weekends thing.

John: Yeah. This is so funny because we've actually recently had a conversation with Rachel -Lee Nabors who is working a bunch in agentic web and had previously been on the REACT team and they had said that ads on the Internet, in the more broad agentic web, is a dead model.

I'm really curious how you see ads on Amp or I guess in any coding agent or really LLMs in general, because I do think this is coming more broadly. It wouldn't surprise me if, and you know, Quinn, tell me if you think I'm wrong, but it wouldn't surprise me if OpenAI's ChatGPT started putting ads somewhere into the platform just to start monetizing more with all this money that's getting spent all over the place.

Where do you see it evolving? Do you see ads on the web still being a thing going into the future, in general, in an agentic future?

Quinn: I do.

Ads are an incredibly efficient way to make money and it's a very democratic way, a broad-based way. It's a way that makes it so that everybody can use a coding agent.

And one of the things that always pained me is I love that we were being available on the frontier and without cost as a concern on our side. But it meant that Amp was closed to a lot of people. Claude Max, Claude Code. All these things were closed to a lot of people. And what's exciting is making this available to everyone.

I was hanging out with Parag Agrawal, the former Twitter CEO who now runs Parallel Web Systems, and another guy, Noah Fradin. We were talking about this and I came to them with this problem that we had.

It was at one of these CEO retreats, and I said, "Amp is so expensive and we want to figure out how we can make it cheaper."

And Parag says, you know, from his background as someone who ran one of the biggest ad companies online in the world, "go make ads."

And that was another case where it sounded like a joke. But it is an incredible way to make money. And even if you think about all the work that every single person would have to do otherwise to go put in their credit card details. That's friction, if you can just use it.

You know, think of how you use google.com, you can use it from any computer, any device. You don't need to be signed in. It just works. Free and ad-supported is an incredibly low friction way of making a product available.

John: Yeah, yeah, 100%. Why do you think people have an allergic reaction to ads in general? Because I had a conversation back and forth on X with Thorsten about this and he was like, "your life is just better because there are ads. You get to use Google Maps because of ads," which is an incredible service and has like, mapped out, you know, every road that I can basically drive on. And I don't know what I would do without it.

Why do you think people have such an allergic reaction to the idea of ads in these things?

Quinn: I think a lot of ads are in really poor taste. I think that if you can keep the quality up, if you can make it power a great product, if the ads can be from companies that you love and respect, if the ads can be targeted, if the ads can be actually useful, so you're seeing things that are relevant to what you're doing, and if you click an ad, the action is not just "go talk to somebody."

That's boring. Nobody wants to do that. If the action can be something like, "go add WorkOS user authentication to my application, automatically provision me an API key," or any of these other things that's actually really valuable. And that's what ads should be.

I think if you can do it well, then people accept them. Think about what Google does. So much of what you see when you search on Google is actually powered by ads. And I'm not just talking about the sponsored results.

The reason why Google is able to have a rich metadata structure of so much information out there, is because advertisers have an incentive to create product listing ads, flight ads, you know, movie show times, and in some cases that drives organic results, in some cases that drives paid results. But you know, ads really are, they create such a strong incentive all around.

And Google overall has done an incredible job. My wife works at Google, so you know, I've seen just how much care they put into that and that's just such an incredible engine.

If we had Google that cost $200 a month and that had rate limits, it would be only available to the elite and the whole world would be poorer as a result.

Brian: Yeah, I always go with this analogy when it comes to talking about ads. If I see a pair of jeans on Instagram and then I'm on Amazon, and it shows up, there's a good chance if I see it on Instagram, it's been catered for me to be pitched to and I'll probably end up buying something from Instagram.

And for context, for listeners, I'm an elder millennial, so I grew up on Instagram, it gives me quality content. I like it. Okay, so don't come at me. But actually I don't mind.

When I go to a conference and I get a pair of socks from a booth, I actually do care about going and using something at KubeCon, the pair of socks is for me to remind myself, oh, I wanted to go try this because the name of the company I can't remember. But the socks I'll have, I'll remember those. So when it comes to, like I just integrated Turso into one of my side projects.

Quinn: Cool.

Brian: And it's a thing I've never tried. I've known about it for years. They just rewrote their entire data SQLite database into Rust. So I'm like, cool, time for me to go try it out finally. But my problem is I'll never remember, "Oh, I need to do the thing. So if I remember to create a get up issue, maybe that's good."

And I don't know that this is the way Amp works today because I haven't used Amp Free yet, but if I was going to do a thing in my side project and was like, "hey, I want a database. So you have this issue over here. Turso is a sponsor. Here's a sponsored experience with their MCP."

I would love that catered experience. Like, hey, by the way, we've got MCP sponsored experience. Maybe you charge higher for that, for a handheld experience. I'm converted immediately.

I just don't want to spend a ton of time going back and forth with the agent. I just want to get the thing done so I can use the thing and show my friends. And if I get a free access to that, I think just like Google Maps, I need a map for all the stuff that's in open source because that doesn't exist today.

And you think Stars would help me navigate to what's popular. But I need validation and sometimes validation is coming through sponsored content. So, to be honest, I was a bit of a skeptic when I saw the initial pitch of Amp Free, but I actually talked to John, I talked to a few other folks that I work with at Continue. And a lot of this makes sense.

And I think you might be ahead of a curve on a lot of these things because I think ChatGPT's the same deal, I would love to, to get recommended, you know, "Hey, I saw you were chatting about this flight. You know, here's a couple tickets from that other session that you were chatting with."

Or give me the email. Yeah, remind me of that session and let me kick back into that. So I don't know where the world goes. And you guys have the team, ready to deploy and scale out this stuff. But as a person on the sideline, but also a practitioner and participant, I'm excited about this space and excited about what you guys do.

Quinn: Yeah, I think you called out a bunch of really good examples of how this can work. The first is just Turso. I've heard amazing things about Turso. I too want to try it out. And they're a new company. And if you're a new company, you got to break out of the noise. It is so noisy out there. I mean, if you go to KubCon, there's a million booths.

If we didn't have the ability for companies like Turso to reach people in a targeted way, then everyone would still be stuck using mainframe databases or Oracle or the things that you know about. So ads also are a way for the little guy to become a not so little guy and find their customers like you and me.

And also this idea of really tailored experience, making Amp work even better if you're using certain technologies. There's a million technologies that are out there and there's a lot of coding agents. But what we've heard demand to do is go and make it so that say if you're using Amp with Amazon Web Services then we have a guarantee that it's going to use the latest docs, that it knows the context of your account.

And that's something where an advertiser like Amazon Web Services would then pay Amp for those sessions. And that is a way that the product can be made better. It's not something where it's secretly inserted. It's all really clear to the user. But you know, it's the Google product listing ads or Google flight ads.

It's you know, product functionality that is enabled, the incentive to go and make that even better, is enabled by advertising. So there's a lot of stuff there in what you said.

John: Yeah, very interesting. One of the things I wanted to ask you about and I'm curious if you heard about this, is 402X or X402 payments protocol? It's this Coinbase thing for micropayments, primarily for agents.

So it's the other side where me, a user could go and give an agent my wallet with a couple bucks in there, and then it can go make tiny micropayments as it hits 402 HTTP statuses which is payment required in HTTP. So a lot of this scaffolding is out there.

I'm very curious if you all have thought about that other side on Amp where, I don't even know what this would be, like, "Hey Amp, go use my micro wallet to go spin up something on AWS or go get a managed Turso db and spend a couple cents or dollars to go and do that." Like, you have the payment capabilities.

Have you envisioned that side of it at all? More from the consumer agentic actually making payments side?

Quinn: No, haven't looked into that at all. Really interesting though.

Brian: Yeah, I mean I think they cut this in a couple months ago or something. Cloudflare is obviously very interested in it because they want to build a whole platform for the app store of agents on the Internet, as they own the network.

Brian, we mentioned this in the last episode. Have you looked at this much?

Brian: No, I gave it a skim. And my analogy is the Brave browser. You use the Internet and then you get Brave tokens as a consumer of it. I think on the inverse... So Quinn, my background's I did DevRel at GitHub. DevRel is my blood and I just love using products specifically devtools.

My thought would be going back to the Turso experience, Turso brand new database, rewritten Rust, needs more attention and adoption. Like, to go find those users to go use the tool and build stuff with it, I imagine the 402 would actually be really interesting. In particularly if Amp would be like, "hey, we're doing a hackathon, 500 people in a room or across the world, let's 10,000 people. We're all using Turso. But you got to build something real and you got to use it and you got to get some real adoption,"

And get to the point where you're not just greenfield shipping a thing, but you have some real problems, some edge cases that you discover. What I'm finding a ton, and still the same vein but--

I went to Nigeria and spoke about basically building in agents. It was a room full of folks at Open Source Community Africa. A lot of folks had no context around AI agents. They just knew ChatGPT and majority of folks are just copy and pasting ChatGPT. And all they just need is a quick little story and a demo and they're off to the races.

And that's what I did on the ground at the event, gave a workshop, built a mobile app. Everyone built it along with me. And the way I built the workshop was I built the app myself, seven commits. And then I said, "hey agent, build now seven markdown files based on these commits, teaching people not actually how to write the code, but how to write the prompt to let the agent go build the code."

And then the next wave was basically, "now we have all the prompts written in the markdown. Now give me links to blogs and articles like web performance and stuff that would enhance the learning."

And what we ended up doing is getting halfway through showing the app, but everyone got to clone the repo, take it home, see all the prompts, pick their favorite agent and go build the thing together or on their own in isolation. But I'm going to back to Turso, it was an opportunity to have an engaged crowd to build a thing, to have adoption, to get to the next level of feedback that's not just like, "oh, I installed it. Cool. T shirt, please."

No, I installed it. I've got a leverage on real things. And for that, can you also get, return my 402x payment or whatever it's called? Yeah, that's where my mind goes. And I feel like I'm just basically in the writer's room with with the Amp team.

Hopefully you'll take this information back to your team and put on the whiteboard and you can track this stuff or throw it at a linear ticket. But I think, honestly, I think that you're paving the way for a bunch of other folks to kind of think about this stuff. So my wheels are already turning.

So, yeah, I'll Ryan and other folks on the team to the build the live stream and just throw a bunch of ideas out there.

Quinn: Yeah, that's awesome. With Amp Free and seeing ads, we could even bank up a small balance. Even if you've never paid us, have no credit card on file that then you could distribute via you know the 402 status code.

I think the possibilities are really interesting and especially once you have an agent that if you ask the agent to go build an application, it's got to make a lot of choices about what technologies it should use.

Now, we never want those choices to be swayed by advertising, but for the user, if they could be swayed by, "what services can it integrate really nicely with and can you just have automatic payments set up with," that feels like a legitimate thing and it could make a lot of things easier.

John: Yeah, it makes a ton of sense. More philosophically and wax poetically, I guess you're on the edge. You're building a lot of this and obviously being the first to do a lot of these things. Do you see any of this slowing down, the speed picking up? Where are the bumps in the road that you see being on the edge of a lot of this?

Quinn: Yeah, everyone wants it to slow down. Everyone who's buying coding agents for a big company wants it to slow down and say, okay, great, now we want you to use just this model because this is the only one that's been approved and we want pricing predictability and all of this.

And we just constantly see other coding agents make choices that if you really dig down, they're assuming that things are going to slow down.

So no I don't think things are slowing down. I think things are speeding up. I think that just the existence of coding agents means that coding agents themselves will speed up because it's so much faster to build everything. And you haven't really yet felt the impact of open source models or all of this data center build out yet.

I think you're going to see tokens become a lot cheaper. You're going to see the inference overall become a lot cheaper. I hope you see power become cheaper. And I think the next iteration is going to be when you can do that thing where you run 10 iterations, all in parallel, and only pick the best one.

And then, by the way, why stop at 10? Why not go to 100? Why not try many different models and do that programmatically? And that requires a totally new way of building a code base, building a workflow. And that's really exciting to think about.

Right now, we've seen the impact from coding agents that are dropped in essentially existing code bases with very minimal change to a workflow or the structure of the code base, and still they do so much. And just imagine what they can do if they could run tests reliably quickly, if they could build reliably quickly.

Most people don't even have their coding agents set up to go try their app in the browser. And people who have the Playwright MCP set up, half the time I ask them, they say, oh yeah, I can't actually log into my app. Or they have to set it up and get everything just right.

So we're just scratching the surface of what coding agents today can do. It is not slowing down.

John: Yeah, it's my feeling as well. I mean, you talking about that made me think of when Brian and I were at the Linux Foundation and I was helping the technology wing of the LF look at and evaluate different technologies to, like Cursor or Windsurf or whatever, what they could adopt, what their engineers could adopt.

And it was a lot of that, that like, "oh we want to adopt a thing and that'll be like the license we have for 18 months."And I'm like, that's a really long time to lock in something in AI right now. That's a lifetime. We gotta be way more flexible than that, right?

Brian: Yeah. I paid an annual subscription to an AI, basically Google Docs, but AI powered. It was pretty early in the days that Google Docs didn't quite have a good tool. And I think I probably paid for it in December and stopped using it by March because I think the Anthropic model got so much better.

And I'm like, oh man, never again. I can't pay annual contracts anymore as a solo person. I'd rather just pay for the couple months I use it and then I'll remember to cancel it whenever I remember.

But I just canceled HBO Max after almost a year of not watching it. So, I'm pretty bad at this type of stuff. So please don't lock me in the contracts.

Quinn: You know, if you roll that in to a company that's trying to build a coding agent, for example, so much of building a software company with subscriptions, especially when you get in the enterprise, is based on all the assumptions and data that we have for the last 15 years, where if you acquire a customer, you can probably keep them for five years.

Enterprises don't churn that often and the contract is probably going to grow. It's high margin. You're not going to need to reinvent the product and have a total R and D cycle every single year. All of that is how SaaS became so incredible over the last 15 years. And none of those assumptions hold going into this new world.

So if you are even paying a sales rep 10% commission on the year one ARR, all of a sudden you have way less margin and it's probably not going to renew. So everything has been called into question.

And if you're citing some headline ARR number that you have and you're making headcount decisions based on that number, because in the past, if that was SaaS revenue, that would have made sense, you cannot be doing that now. It's incredibly, incredibly risky. So I don't think that has quite rippled through the whole industry.

John: Yeah, I'm actually very curious if you'd be willing to comment on the state of the tech landscape with jobs and the layoffs and stuff. I find it very curious because I have a similar instinct where, it seems that with coding agents and with, you know, the convention of all these LLMs and things, there's just going to be more software out there. There's a lot more software out there.

But we're also going to have this velocity to move much faster, like you said, where it's like, we can't really rely on, you know, having a SaaS that's just going to renew year over year and not have to be agile and go and rebuild pieces of it or rebuild the whole thing. If we need to go find market fit again, which in my eyes would mean we need more people, boots on the ground and stuff.

Is that a right assumption to have, that there's just going to be so much more software out there, so we need more software engineers? Or have you seen the opposite?

Quinn: I think it'd be very complex. I think overall, vibe coding as it's taken to the extreme, where you literally don't look at the code and you just build stuff by prompting, I think that's been a dud.

John: Yeah.

Quinn:

I think that ultimately you have to express unambiguously what you want to a computer. And at a certain point that is the skill of a programmer. And I don't think it's a good goal for vibe coding, where you cut out the developer entirely. That's just not going to exist. Because at a certain point, if you're really good at vibe coding, you're being so unambiguous that you are a programmer.

I think you're going to see a lot more people writing some code. I think you're going to see a lot more code written. And for us at Sourcegraph, we also have code search and we think there's going to be a thousand times more code searches.

And the number of companies with a large volume of code is. It's going to be so much greater in the future. So, yes, all those things we absolutely see.

And at the same time, when it comes to jobs, I don't know what the impact is going to be from greater automation, typically, when there's already unbounded demand for something, if you automate, you don't actually reduce the number of jobs.

What I do see is a big disruption where there's a lot of people that are not adapting as fast as they need to and they're in denial about AI. They say, "oh, I used it, it doesn't work. What is everyone going on about?"

We've tried to address this with Amp through one thing we have, which is thread sharing. You can share your threads automatically with your team so they can see how you're using it and learn from that. But I think that's going to cause a lot of people, maybe half of developers, to just not get on this train.

And they will quickly find themselves being perhaps negative marginal product, which is really tough. The good news is there's a way to avoid that, which is figure out how to make it work.

John: Yeah, a friend of the show Mitchell Hashimoto, had a great thread on X where he was sharing an Amp thread and was just being like, here's how. I built a legitimate feature in Ghostty, the terminal emulator, for, you know, using Amp.

And I even learned something from it. Just the way he flowed and worked with it was a little different than the ways that I even thought you could. I think a lot of people found that educational, right?

Quinn: Yeah. Seeing how someone actually uses it. And when you look at Mitchell's threads when he's using Amp, you can tell that there's a programmer on the other side of the keyboard. He is a programmer. He's telling it what to do in programming terms. Not like, "hey, Amp, vibe code me a new feature in Ghostty."

John: Yeah, well, we're running out of time, so I have to transition us to reads, which means, Quinn, I gotta ask you, are you ready to read?

Quinn: Yes.

John: All right, well, I'll kick us off here. I just had one read, which I just thought was so fascinating, and I thought, Quinn, you might find it interesting since you're a Go programmer. Or at least I think I've looked at some of your go code on GitHub.

This is the the Green Tea Garbage Collector, which is this new experimental garbage collector, which for those unaware Go is a programming language out of Google. It's very C-like, and they built it to be, you know, very scalable across teams and these teams shipping micro architectures and microservices and stuff.

But it's a garbage collected language, which means that you don't actually really manage any of the actual memory under the hood. But this new garbage collector is supposedly so much better. One of the quotes from this article is, "many workloads spend around 10% less time in the garbage collector, but some workloads see a reduction of up to 40%."

And that's always been the gnarly thing about garbage collectors is it's got to go spend a bunch of time in your program actually garbage collecting your memory. I'm very excited for this. So I just thought it was a fun little bit of programming coolness that's happening in Go.

Quinn: Cool. I'm just looking at the post. It seems like it operates in pages instead of individual objects?

John: Yeah, I think that's one of the criticisms that a lot of people have of Go in general is that it was, not dumb in a sense, but like, simplicity to its core. Even parts of the core standard library are relatively simple, which is nice because you can go and read pretty much all the Go code in Go Standard library, including Go itself. But I think a slightly more complex thing is going to be really great for the garbage collector.

Quinn: That's cool. I think there's an unappreciated hack which is if you have a program where you can just kill it when it's done, then just run it without garbage collection in Go and try to build programs. If there's some functionality that requires a lot of memory usage, just let it go, no garbage collection, and then kill it when it's done.

John: Yeah, it's actually a classic thing we used to do on Tanzu, was we had little jobs that would spin up and just be like "ah, just, just, just go." And Kubernetes will kill it eventually, right?

Quinn: Yeah.

John: And then spin up another one and it's fine. You do that at scale and it's sort of hashtag just works, right?

Well Brian, did you have a read?

Brian: I did have a read and we brought up Mitchell. Funny enough, the article that I'm going to mention as well, is The Art of Chiseling and Polishing, is basically around vibe coding responsibly, is how I've seen it presented.

It's actually from one of the engineers at Continue. But it was inspired by one of Mitchell's threads when he was vibe coding non-trivial Ghostty issues. And so if I zoom out, and the idea is I want to solve a problem, I've thrown a bunch of code into orbit. There's two options.

You jackhammer. Basically if you're thinking of a sculptor, you use the jackhammer to basically remove large pieces of code. That's not necessary. And I think what, at least with the Claude models you tend to get a lot of cruft that comes along for the ride.

And then once you've removed all the noise then you start pulling out the chisel and the chisel is not meant to start deleting random stuff but it's actually, they'll actually take some time to really understand different parts of the code that's being added at time of PR or maybe even right before PR.

So I spent a lot of time in the summer actually vibe coding some stuff because I wanted to test these tools pretty quickly. I found that really fast that vibe coding is a great way to go from zero to tech debt pretty quickly. So I introduced all this other stuff.

And funny I mentioned Ryan Carson. I got super excited about some of the talks he was doing over the summer around spectrum development and having tasks. And I started just going down that rabbit hole. And then now I'm at a point where, now I'm just fine tuning everything and I spend way more time just refactoring random files.

So I've been setting up a cron to basically go and send a background agent to just randomly refactor things, make things faster. And then what I've been doing as well is using background jobs on top of MCPs to then use the Chrome MCP, which I think does really well for performance, to go find slow pages or slow queries if I'm using my database as well.

And just stuff that I should probably do myself all the time, but because this is stuff I do on the weekends, it's cool to have a PR that just randomly shows up and I can just read some code and feel like I've got a teammate for my side project that is working alongside me.

And then I can decide if I want to close it and redo it at that point or take it for what it's worth. But yeah, chiseling, look it up. I think it's a great article for folks to think about how they're approaching agentic programming.

Quinn: Nice.

John: Yeah, that's a good analogy. I like it.

Quinn: You know, I know some devs who find chiseling to be the most fun part of programming and they just love a refactor or re-architecture all the time. So find some of those and set them loose in your code base.

John: Yeah.

Brian: Please. Open source folks, please find my project.

John: Yeah, well, maybe the best for last. Quinn, you had a read.

Quinn: Well, this is good. Your call on whether it's the best. It's from Armin Ronacher called Agentic Coding Things That Did Not Work from July 30, 2025, where he talks about some of the features that Claude Code and other coding agents have added that seemed promising, but it ultimately didn't stick in his workflow.

And I view it as an antidote to all those breathless threads on X where they say, "this new thing changes everything." And the person who had 50 different cloud code custom sub agents, like a VP of marketing sub agent.

And he walks through how he's found that there's a limit to the value of slash commands for him, hooks, the print or execute mode subtasks and sub agents. And at the time he was throwing a bunch of very well deserved cold water on a lot of these features that added a lot of complexity.

And as someone who's building an agent, we always want to view these new features as experiments. They could be totally worthless, they could be made obsolete by the next model that comes out. Sub Agents is a great example.

We and Claude Code have these generalized sub agents that can spawn off another thread and operate and some people think they're so cool, but actually they are net negative now in our opinion.

And so, you know, I hope the Claude Code team takes this feedback or has taken this feedback.

We are taking this feedback and our approach is if something doesn't click and we ship it then we need to rip it out immediately. And it's like good to know that you should not do product development based on what people on Twitter are thread boyying about.

John: I'll plus one that. Quinn, thank you so much for coming on the episode today. Everyone go check out Amp. Check out Amp Free, and then soon to come Amp Nights and Weekends. You heard it here first.

Remember listeners, stay ready.