After Code Gen: What Graphite Is Building for the Post-AI Dev Stack | Greg Foster

Greg Foster 0:00 Hey, maybe your company used to merge 20 changes a day, now it's merging 50 changes a day. Even with bots and all this stuff going on, maybe even a 100, and now you have merge conflicts and merge SKUs. These changes what's funny is before I had reasonably good confidence in them. I thought, Connor, I trust you. You're a great engineer. You wrote this code change. Now it's like, okay, Connor, I'm not sure you wrote this.

Conor Bronsdon 0:23 Welcome back to Chain of Thought, everyone. I am your host, Connor Bronsden, and we've all had this thought. AI coding tools are maybe the fastest moving category in tech, but as we flood our systems with AI generated code, what do we do about code reviews? These can be a bit of a critical bottleneck, especially as we're seeing folks like the CEO of Coinbase

Conor Bronsdon 0:48 saying that 40 of their code is now AI generated. My guest today is tackling this problem head on. Greg Foster is the founder of Graphite. You may have seen them over at graphite.dev. You may be using them. And after seeing the power of Airbnb's internal tooling, Greg set out to build a solution for everyone else, accelerating development for teams like Cursor,

Conor Bronsdon 1:11 Replit, and Snowflake. Greg, it's great to see you. Thanks for joining us on the show. Yeah. Thanks for having me, Connor. I loved I love this topic. I love talking about dev tools, and I love geeking out on how it's all evolving with AI right now. I saw that Coinbase tweet this morning. I was I was enjoying that one. Yeah. It's, it's really interesting to see the responses on that. And I guess folks who are listening to this later now can place when we recorded this in time. So we're, we're giving the game away here. But before we get started, I do have one quick note I need to share with our listeners.

Conor Bronsdon 1:41 We have just launched our Chain of Thought newsletter on LinkedIn, and we would love to have you join us every week as we bring you the conversations from Chain of Thought, research to help you ship reliable AI, and everything that is crucially happening around observability, evaluations, and key infrastructure for AI. We're going to have a lot more conversations with dev tools leaders like Greg,

Conor Bronsdon 2:05 and you can find it by searching for the Chain of Thought newsletter LinkedIn to subscribe or check out the Galleo AI LinkedIn page. You can find us pretty easily or find me and then, you know, easy to find us from there. But let's get into the conversation here. Greg, you and I have both been, I mean, involved in the DevTools space for years at this point. Some listeners of the show may know me from when I was at Linear B and hosting the DevRemapids show for years, or we talked with a ton of engineering leaders.

Conor Bronsdon 2:34 And most of the conversations happening in AI today are about generating code faster, solving, you know, this challenge of like writing something better. But, know, as Galileo was obviously focused on like observability and evaluation of that, whether it's an AI agent, whether that's writing, whether that's code generation is crucial. And for particular workflows,

Conor Bronsdon 3:01 say code, which I think we all agree is one of the obvious opportunities to solve given the massive open source databases and internal proprietary databases that can be applied to the problem. If you want a deeper conversation on why code is one of the top areas for LLMs to, to solve for knowledge work. We have our whole episode of The Poolside Founders. That was from earlier this year. Go check that out. Great deep dive.

Conor Bronsdon 3:22 But Greg's really focused on what happens next after the generation. And I think all, all of us who've done dev work know, reviews can be hit or miss. It can really depend on who's reviewing the code, how motivated they are to actually review your code and how much they're paying attention. You may just get an LGTM looks good to me. And with so much new cogeneration happening and frankly with LLMs not always being the best at,

Conor Bronsdon 3:53 being brief with their, their cogeneration, reviews are clearly a critical and often overlooked part of the puzzle. So I'm really interested to hear your perspective on this, Greg, and I think we're both excited to see the AI engineering landscape evolve from that vantage point. So let's set the stage for our listeners. Greg, how is the nature of AI engineering fundamentally

Conor Bronsdon 4:17 changing the software development life cycle?

Greg Foster 4:20 How is the nature of AI changing the software development life cycle? So it's definitely everywhere. You can't, you can't go on Twitter. You can't go on LinkedIn. You look at tech, any, any source of media or information or hype y articles right now is constantly talking about AI changing engineering. I mean, Hacker News, it's flooded with this. There's constantly a debate of like, do junior engineers still have a job? Should people even study CS anymore or is it overblown? And you can see the flame wars happening in the comments, but if you can like control F for AI on HN, it's just, it just lights up the page. So it's definitely doing something. It's definitely really interesting.

Greg Foster 5:02 And it's been pretty fast too. I've been working on DevTools for a while. I used to be an engineer at Airbnb, working on the DevTools team. That was in the late 2010s. I started working on graphite with my amazing co founders around 2020. AI was not really mentioned. I remember at one point I was talking to a GitHub exec and this must've been 2022, 2023. And they were so excited

Greg Foster 5:26 about the advent of some of this AI overhang. And they're like, yeah, you should use it to summarize, commit titles, to fill out commit titles for what y'all are doing. And we sat there, we're like, yeah, I don't know if that's physically possible. Like maybe it is, like, maybe that's just that, that like, you know, just can't be done with current technology.

Greg Foster 5:42 And here you are a year or two later and it's like, oh, that's the most trivial thing I could possibly So do with it's really, and it seemingly kind of, kind of come out of nowhere and just taken the field. If I think around personally, like as I've watched, as I think about how it's kind of emerged, it feels like the first major use case was GitHub Copilot. I feel like they really cracked this open.

Greg Foster 6:05 And it's, it was a cool synergy because you take, you take Microsoft who owns GitHub. They also own Versus Code. And then they have that major investment in OpenAI. And so they have all the puzzle pieces. They have an IDE, they have that training dataset from, from GitHub and, they have the AI talent and they apply and they build what feels like the first really successful product here, which was like tab complete.

Greg Foster 6:28 As I'm typing, I already had tab complete through, their abstract syntax trees and stuff happening in my IDE, but now I could use AI and it could predict a little bit better and it could fill up like the rest of the line or heck even in exciting cases, a couple of lines in front of me. And this got really popular and people were willing to pay for this. And you had a couple companies,

Greg Foster 6:48 spin off from this. You had Maven was one of them. People started really getting excited and working in this space. And then, it feels like the next thing that came along, Cursor and the Cursor team looked at that and took, took amazing inspiration. I love, I love the Cursor folks. I knew them. I think they were also getting started around 2020. Such a smart group of folks. We looked at them that, hey, this is promising,

Greg Foster 7:10 but man, you could do so much more. In fact, this, you know, don't just be like a plugin into Versus code. What if you own the whole IDE, you had more custom UIs, you were a lot more ambitious with this. They extended tabs to not just fill out your line, but also jump ahead and fill out multiple lines. And you can kind of keep slapping tab and just watch your whole screen get filled out.

Greg Foster 7:27 And now we're still in the auto complete land. And I think everyone looked at this and they said, okay, fantastic. What a nice dev tool and minor productivity level up this is. But I don't think anyone was like, okay, we're out of a job. The software engineers. Then, then I think about the second wave. Then we had, we had like kind of another, another level up, and I think this was kind of enabled by more intelligent

Greg Foster 7:47 backend systems as Sonnet 3.5 comes out, Sonnet 3.7, variants of GBT start evolving. You get this sidebar that again, I think HRSA really popularized where you can get a sidebar and I can ask it, Hey, just go do me a thing. Go add a button. Go take this, go to refactor this file. Add a unit test here. And it doesn't have infinite context, but it can go on small missions and it can actually pop out rather than tab quitting. It can just spawn and generate a reasonably good amount of code or a reasonably good amount of edits.

Greg Foster 8:16 And now I have this director mode where I can go and I can have a conversation and I can just suggest changes to the code base. I'm still sitting at an IDE. It's not too dissimilar. I'm still working on a code change and heck it's making enough mistakes where I'm also immediately just moving my cursor into, into the window and then like fixing a couple of typos, linter errors, you name it. But really feels like the second wave and that felt distinctly

Greg Foster 8:38 better and stronger and more interesting than just tab complete. Tab complete is still useful, but this felt like a big level up there. And I think people started scratching their heads and really starting to think, okay, man, this is, this is getting special. And as this has extended and the duration of missions that you can send, the, those bots on has, has increased.

Greg Foster 8:55 You have the advent of vibe coding gets coined. You have people, you know, the, the, the surface evolves and now you've Claude code doing it in the terminal, but it's still that general ergonomic pattern of you type a English sentence. It does a little work, get back, gets back to you. And maybe you're checking in ten, twenty times on a pull request. Now, the last level of this that I'm kind of interested in

Greg Foster 9:17 seems to be, this is the most emergent right now, but is this, this concept of background agents. I don't know if it has a fully official term yet, but that's, that's one term that's been coined. Where to say, I view, I view it as headless. You know, I say, go Slack, app message something on Slack, go ping something on GitHub, wait a couple hours and then have a pull request come back to you. It's like the full autonomy self driving car. It's not highway autopilot. It's just, it just goes, does the delivery and comes back.

Greg Foster 9:45 And it's really interesting. I don't have to be, I don't have to have my hands on the wheel. I don't have to be paying attention. I can, I can do it off my phone while I'm going to lunch? The scope of missions and asks that I can make of that are quite small right now. It's often small code changes. If you ask anything too ambitious, it likely goes off the rails. It also takes a good amount of time. Usually what's happening is a sandbox is being spun up in the background, kind of like CI, some code's being cloned, it's building, it's iterating, it's, it's giving you back a PR,

Greg Foster 10:11 but it's, it really to me is showing this like final evolution or so far final evolution of, of what these AI can do in software development, which is kind of headlessly acting like a teammate and spawning a whole poll request, allowing you to interact with it the way you'd interact with a teammate. And with a teammate, I don't, I'm not sitting with them on an IDE, two hands, four hands on the keyboard, NCIS style, trying, trying to collaborate.

Greg Foster 10:35 We're talking on Slack and we're talking on GitHub and that's how we're iterating on this poll request. And we're starting to get to that and maybe it can only do 10% of PRs today, but heck, know, give me GPT-five, GPT-six, you know, maybe it can do 20%. Maybe it starts inching up that ladder and where we find ourselves today. We have all three. People use TapComplete.

Greg Foster 10:51 People use these IDE or Cloudco style chatbots, and they also use a little bit of headless, headless background agents. And so AI is definitely shaking up the game board and we're doing everything a little bit differently. I see these three major patterns emerging.

Conor Bronsdon 11:04 Man, there's so much to unpack there. I think you have a lot of great insights and the idea of these three development waves is is really spot on. And we could obviously talk more about things like context engineering and how that's becoming a much larger frame for a lot of these approaches and how people are thinking through the infrastructure piece of it. But I want to drill down something you said early on, which is commit titles. You know, a couple of years ago, we were like, oh, commit title generation. How are we going to figure that out? And now,

Conor Bronsdon 11:36 I I don't think about commit titles anymore, like, come on. That that is so far down the list of problems that we're trying to solve here. And I think it's a great example of how the infrastructure and AI has moved forward, And yet the public perception, I think is that maybe AI is a little stuck like, Oh, there hasn't been that much improvement. But once you actually dig in the details and you start talking to people who are building with it every day, who who are involved in the DevTool side of it, you see that there is so much infrastructure that's happened. And I think there is this perception of like, AI should be a magic bullet and it should just solve your problem. You know, it's going to kill the werewolf off the bat, no problem.

Conor Bronsdon 12:14 And instead we're finding that it does take a lot of infrastructure work to, to get it right. And you have to do a lot of context engineering. You have to provide a lot of context. You have to make sure you're, you're setting your agents up for success. But when you do, that's where the magic happens. And I think that's, what's really exciting about the efforts of folks like yourself,

Conor Bronsdon 12:33 but also of how we're seeing this transformation because, I mean, you, you talked about this first wave of like, Hey, I'm, I'm in my ID. I'm, I'm basically talking to this AI, you know, it's completing stuff for me. We're kind of going back and forth on debugging. I think that's still a fantastic paradigm for folks who are more junior or bad devs like myself, frankly,

Conor Bronsdon 12:54 to go back and forth, to, to learn, to iterate and to really be pair programming with an AI. And then you have this movement up the stack to, Oh, now I can start to, I can be a team lead and I can leverage my expertise and really assign tasks out. And now I have a team of agents working for me. And it's so obvious we're heading in that direction of just like these multi agent systems that function semi autonomously

Conor Bronsdon 13:19 and get inputs from humans as architectural leaders and sometimes debuggers, but that doesn't solve all the infrastructure problems, know, even if we're shifting left in some areas, there, there are these blockers that are in the, in the software development life cycle and review has always been one, but there are others that I think are, are maybe emerging.

Conor Bronsdon 13:42 And I wonder if you are seeing particular changes to segments of the software development life cycle where now the SDLC for AI has, has new blockers that are emerged or, or new challenges that you're kind of thinking about, beyond the, the core problem that you're looking to solve.

Greg Foster 14:01 Oh, a 100%. I mean, there's so much that goes into software engineering that is not just typing

Conor Bronsdon 14:09 keys on a keyboard and writing code. I mean, that's what, 10 to 20% of the work, right? Exactly. Exactly.

Greg Foster 14:16 There's so much that goes into it. That's not just that. You have pre work, You have the alignment that goes on. You have stakeholders, you create a design doc, you loop in product and design, depending on what you're building. You're thinking gracefully about what you're actually going to go create. Then you go and type it out. You test it, you build it, make sure it feels good. That's on your local experience. That's where all this action, a lot of this action is happening

Greg Foster 14:39 on that code generation happening on your local machine oftentimes. Then you would create a pull request. And as we all know, don't you just create a pull request and then you're like, Oh, great. Done. Feature complete. We're solved. Like, call launched. Call launched. I'm going on vacation. No, not at all. Right? I think there's a saying like, code complete is not, you know, the same as feature complete.

Greg Foster 14:58 After that, you got to go get a code review. We think a lot about that, but you know, even just breaking out the code review, what's actually happening there. Okay. You're, you're looping in other teammates to get context from them, but also share context back to them. So people have some idea of what's going on in code base, how it's changing, how it's evolving. Maybe they know something you don't know and say, Hey, that's actually not the pattern that we do here. Or you know what? That's actually so reasonable, except we just had a meeting yesterday and we're actually going in a different direction. And let me, let me just let you know that we should take a change here before you go merge that in.

Greg Foster 15:29 Maybe there's a security issue and this is a great chance for folks to apply that acumen. Maybe there's code owners or expert subject matter expertise where they can weigh in on certain areas. All of this is going on in the human code review. We're not even talking about bugs. Bugs, of course, we're looking at, looking for bugs in, in code review, but we're also looking for them in CI. And when that PR is put up, we're now trying to pass a bunch of automated tests,

Greg Foster 15:54 everything from linters to unit tests, to end tests, make sure this is safe and hopefully not about to crash production. Okay. Let's say we pass CI and we get a code review. Now we push a merge button. If you're a small company, it'll just merge on a trunk. If you're at a large company, it may go into a merge queue. And there's so many people merging at the same time that now we need to sequence these retest CI in case someone broke something in between you getting a review and passing CI. Okay. So we got to queue it up. We got to retest it. Great. That could take another hour. Some complex systems there.

Greg Foster 16:22 Then we merge it, but once you merge it, it's still not user facing. It's still not launched. We're going to have to rebuild a new artifact. We're going to have to gracefully roll that out onto production servers, checking all of our metrics and making sure we're not regressing something, spiking errors, causing a problem.

Conor Bronsdon 16:37 Hits production. Still not done. Still, now it's on production. Users are seeing it. Hopefully if we're a good engineer, we're not at lunch yet. We're still kind of monitoring our systems, maybe checking Datadog or Grafana. But maybe we're working on something else already. Maybe we're already having context switching costs because I've transitioned to my next feature I'm working on. Maybe I haven't found a lunch and I'm like, Oh God, what did I write earlier? Or maybe it's two days later because I didn't get a human review in time and that was a blocker in my system, or I needed a second review for some reason from an SME.

Greg Foster 17:04 There's, there's so many ways this can go wrong. And I think, you know, we can go on and on. I think every part of this is being challenged, rethought, or bottlenecked by AI to connect it back to AI. AI, I think is really just obsessing right now about that cogeneration. Is it touching the design docs? A little bit. We're using deep research to help us with those design docs. For code review, there's AI code reviewers. We work on one. There's a few out in the market.

Greg Foster 17:28 For tests, it's helping generate them. Running them, that's more deterministic execution of compute. So it's not changing the run of them. I do think you could do some fun stuff around ordering those tests and trying to be as efficient as possible, but mostly it's just helping us on the generation side. Merging, it's actually kind of the same problem it was before, but now we have a higher volume of code changes. This is where it kind gets interesting. It breaks down.

Greg Foster 17:49 I'm hearing reports and I think people see this anecdotally, but you also see it in the metrics that companies are just generating a lot higher volume of code changes. I think Facebook was quoted in, you know, over the last year, doubling the internal code changes per engineer that they're seeing, and they expect it to double again really soon. We see it in our metrics because we're, graphite is used by so many of these companies. And of course we sync and we manage all the code changes. So we see the volume of code changes and it is strictly up into the right for engineers.

Greg Foster 18:13 It's putting strain on these systems. You as an IC, you got to review more stuff. Your human time is still your human time. The merge system, Hey, maybe your company used to merge 20 changes a day and now it's merging 50 changes a day. Or maybe even with bots and all this stuff going on, maybe even a 100, and now you have merge conflicts and merge skews. These changes was funny is before

Greg Foster 18:34 I had reasonably good, confidence in them. Thought, Connor, I trust you. You're a great engineer. You wrote this code change. I'm double checking it, but heck, you know, like we're, we're already in a reasonably good place that you wrote this thing. Now it's like, okay, Connor, I'm not sure you wrote this. I, you might've written it. You might've just like held tab down while like staring at your iPhone. I would never do that. Okay.

Conor Bronsdon 18:54 Excuse me, Greg, you're casting aspersions on my honor here. Exactly. You would, you would never.

Greg Foster 19:00 Or heck maybe, maybe like no human has ever read this code before. There's like a bot that just generated it. And now I'm the first person ever reading it. So this code review, there's more of these code changes, but it's also higher stakes. I trust it a little bit less. Maybe it didn't get, maybe the original human who wrote it didn't pay as much attention.

Greg Foster 19:17 There's also a risk of, you know, machines are gullible and we, you know, we, we hear more and more about security incidents happening with these code changes. That code review really starts mattering. Because I can't even just trust the team that had good intentions who was creating it. The context also matters too, because we take for granted that when we write code changes ourselves, we're absorbing the context of how the code base is and is evolving. And then Code Review is sharing that out a little bit. But if we're not writing those code changes with a really active mind, we have less and less context. So we better be absorbing that in code review. Cause if we're not absorbing in code review and we didn't absorb it when we wrote it, the entire engineering team might not know what's actually happening in the code base. That becomes a really dangerous problem over time.

Greg Foster 19:55 There's more weight on this code review system. There's more weight on the merging system, deployment system. That whole outer loop of software development is getting challenged and bottlenecked. I think you've, there's been tweets and so on from the Anthropic team and others about how it's not the code gen, the code creation, the code writing side that's the issue anymore. Now it's the DevOps, the management, the good engineering practices around shipping and releasing to production. That's kind of the new bottleneck. And we can solve it. I'm, you know, I'm optimistic we're engineers, we can solve it, but that's, that's a major issue of challenge now. Yeah.

Conor Bronsdon 20:24 I think it's really interesting to look at where effort is going now because initially there was so much being poured into the CodeGen challenge. And not to say, obviously there are massive billion dollar plus companies that have built on this. I mean, Cursor, which I know you work with, has, is like the obvious success story, but there frankly so many Versus Code for us that are being successful here. You look at Winsorf and others.

Conor Bronsdon 20:46 And now I think we're all realizing, Oh, that only gets you so far. Like this, this does, as I think anyone who's spent time thinking about the leadership side of software engineering for a long time realize, Oh, this, this the coding's only part of it. This is only a small portion of the, the work that has to happen. This inner loop versus outer loop that you mentioned.

Conor Bronsdon 21:09 And I think something else you said is really poignant and, and that's the idea of what level of context is being applied to a PR. Now, we may have an expectation of a human coworker, but we may not know the context being applied by our agent coworker now. And, and really that's what they're becoming is these like, I've been calling them junior async digital employees where it's like, you know, they're not, they're typically not senior level yet. They, they lack the context and the architectural thinking.

Conor Bronsdon 21:41 But God, you can unleash a hoard of junior employees at a problem. And if you give them enough context and you enable them and you manage them, they could do fantastic work. But it feels like there's still a big gap in how different companies are providing context to their AI agents to actually get them to be successful within the code base. What best practices are you seeing around actually enabling these agents and this third distinct wave of this software engineering revolution?

Greg Foster 22:16 It's a good question. How are people getting the context into the agents so they do a good job? I think it starts with the person at the helm being a very good software engineer. You still got to hug the agent on both sides. You got to hug it on the input and you got to hug it on the output. You still got to be, it's agent in the middle, human on the in and the out.

Greg Foster 22:39 And we need the software engineers to be really good. The people, you know, the people I think are the strongest and most effective with working with AI agents are the, are the senior people, the staff people, the really experienced Yes. Junior engineers are finding great success and I love it when I'm learning something new. I love using AI agents, but man,

Greg Foster 22:56 the really strong engineers, the folks who've been doing it forever, they are lethal when mixed with, with, with these AI technologies. Why is that? So I think on the input side, they're, they're applying, they're, as you say, you know, the context, they're, they're maybe collaborating on a design doc with Claude code. They're creating a markdown file to start off with. They know what a good design doc is. They know what kind of questions to ask, and they're actually filling that out. They're maybe even having like

Greg Foster 23:20 iterative debates with the AI to create really good design doc style guides before they even actually execute the code change. Maybe they're running deep research queries. They're scanning docs. They're double checking the APIs that they're depending on. They're thinking about all of the classic software engineering principles that have always mattered. Clean code, clean architecture, dependency inversion, good abstractions, narrow interfaces. All this stuff matters. If it mattered to the, it mattered to the human, kind of still matters to the AI. And they're putting that down in the pre work. And you ask how they get the context of the machines. Again, it's simple, but a good pattern I've seen is people just are creating really thoughtful markdown file design docs and actually go into ClockCode or Cursor and saying, Hey, read this thing. Now let's, let's start working on that code change. Another thing that still matters a lot, and we obsess over this, is making sure the code changes are small and modular.

Greg Foster 24:07 Just as, just as a design docs, you know, it helps humans and it helps the AI as well. You don't want Claude Code or Cursor or any of these tools to go and create 2,000 lines, 3,000 line PRs. They can do it pretty fast, but you don't want them to create that, put up for a poll request and hope to God it passes review in CI. There's a lot of famous studies. I think Google had one where actually the longer the code changes, and we've seen this in our data too, the longer the code changes, the fewer number of comments per line it gets.

Greg Foster 24:35 People, just the human reviewers, their eyes flaze over it. You're way more likely to give it to LGA. You put up a 10 line PR, you're going get like five comments on it. You put them up to Yeah, line yeah, People are like, I don't know. What do you, what do you want me do with this? Same thing, if there's, if your CI fails or there's a bug, you're like, okay, let's, let's now, like, let's look through this 2,000 line code change and like, see if we can find the issue.

Greg Foster 24:55 Much rather small modular code changes incrementally built, rolled out. If one fails, you know exactly where the issue was. And I think that this helps AIs a lot too. So this pattern I'm describing is a small diffs, stack diffs. Stacking is a great, is a great technique to, like Facebook invented, to allow you to create a small code change and then create a small code change on top of that, a small code change on top of that. The origins of this concept trace all the way back to old school git where people used to actually work on commit by commit. Nowadays, I know we all work on pull requests.

Greg Foster 25:26 No matter how you want to describe or call it this many interdependent small code changes one at a time, it works very nicely. And you know who likes it most? AI really likes it. It's actually, when you actually start getting these coding agents to stack their code changes and create many small ones, they start applying chain of thought to those stacks. It's really funny. You can see them breaking out. They're like, okay, okay, great. I'm going to, you know, we'll create the function first, then we'll create the unit test next, then we'll create the endpoint on top of that. And they're starting to modularize it, test each one of them and roll that out. And the AI even builds it better than if you ask it to kind of one shot it in one large code change.

Greg Foster 25:57 Then again, I said human on the ins, human on the out, the human reviewer can look at that stack of changes. They can look at many small code changes and they can apply a better human review. Heck, maybe they can review the first one while the AI is working on the second one. You can tag in different subject matter experts from different areas. That CI is being run on a more granular level. So it works really well together. And then, you better be a good engineer on the review side because that still matters. And you still got a lot of work after creating that code change.

Conor Bronsdon 26:24 I'm curious. I'd love to unpack this concept of stacking because I think a lot of us are just really used to using pull requests and that's just the norm or, you know, maybe too used to looking at our green squares and our GitHub profile and going like, Oh yeah, look how many PR they have. Have a lot a lot of commits here. And stacking, while it's been popularized by certain companies, is is less of a an established,

Conor Bronsdon 26:51 approach within the industry. What is I guess, one, where are you seeing the growth? Are you seeing a lot of people adopt this or is this still pretty nascent so far? And, and two, how do you think it can be further leveraged to enhance these agent first or agent centric coding approaches?

Greg Foster 27:11 Yeah. I will say we are seeing it get more and more popular across the industry and across the top tech companies that I really do think set the trends in DevTools. All these companies from Datadog to Vercel, to Notion, to Figma, a lot of it, lot of the engineers are starting to embrace stacking more and more. I love seeing it. This, the concept has been around for a long time. I think the biggest

Greg Foster 27:33 manifestation of it has been within Facebook and Meta's engineering culture. I think they had the world class tooling around creating stacks of small code changes. And it's interesting because, Meta is also one of the, one of the few companies who doesn't use GitHub. Google is one of the other ones and they also have similar patterns here. Why is that? It's a, it's a fun historical stories, but in part because,

Greg Foster 27:54 you know, GitHub was very nascent at the time that Facebook and Google were coming to scale and new large systems. So they built in house. And when they built in house, they thought about things from first principles. They needed small code changes. They thought you could create stacks of them. It worked really nicely. So these patterns emerged. They're becoming adopted more and more throughout the industry

Greg Foster 28:14 for a couple of reasons. One, I think the tooling is getting there in order to support them better. We build tooling at Graphite, help stack changes. Also, there's some great open source tools and CLIs that make it easier to manage your stacks of changes. Vanilla Git never did a great job of helping you manage these. And number two, I think again, there's more and more of this emphasis on keeping developers unblocked and moving quickly. It's always mattered. We're just watching that matter more and more, and that's creating more appetite to embrace solutions like stacking.

Greg Foster 28:41 To touch on exactly why this is like not mainstream or why this hasn't always been mainstreamed, it's such a fascinating historical artifact to me. I think the origins of Git was exploring this idea and they, they had two constructs. They had commits and branches. And what is a branch, but a chain of commits, chain of interdependent code changes that stack on top of one another.

Greg Foster 29:01 And so they, they were kind of on this from the get go. You're coding, you're checkpointing it, you know, you're proceeding along. What differed here was the pattern that engineers collaborate on those code changes. Cause in open source Git land, you would go to a maintainer and say, Hey, I've been working on a branch for a little while, a feature branch, a fork. It's, I've gone on my own journey here.

Greg Foster 29:22 Would you pull in my changes? Stranger online. Do you trust me? Would you like take a, take a review of this and bring in my branch? Pull, I'm requesting you to pull it in. That's where the pedal comes from. And then that, that maintainer, you know, sits for a couple of days. They give it some thought. Maybe they do, maybe they don't. Depends how People won't be able to prove out crucially.

Greg Foster 29:41 Yeah. And a lot of, a lot of, some people just squish those things. Sometimes they won't depends, you know, there's a lot of, especially when it comes to like Linux and a lot of these open source projects, they've, they're very picky about this stuff. So that was the origin, but they, how are they collaborating? They're collaborating on GitHub and the unit of change was the pull request, but the pull request was a bunch of commits.

Greg Foster 30:00 It was a single branch, but a bunch of commits. So what ended up accidentally happening is that the unit of change became the branch and not the commit. Get started with the unit of change being the commit, and it kind of became the branch. And then all these companies adopted GitHub as the code change collaboration tooling of the day. Was just the main system lying around. If you didn't want to build it in house and no one did, they would just buy GitHub. So you start slinging PRs back and forth and people care so little about commits. You can't review the commit. You can't run CI on the commit. You review, you review and test the branch. And most all companies these days, when you merge, they just enable squash and merge, just compress that branch down to a single commit on main to keep it really clean.

Greg Foster 30:36 And some people use, some people just rebase a bunch. They, some people stack on commits, but overall we've, we've really just centralized on that branch workflow. That's why I think that there's been an under adoption of stacking is that the Vanilla Git and Vanilla GitHub made this kind of hard to adopt in support. If you've ever tried to chain- I'm not used to it either.

Greg Foster 30:55 Yeah. They're not used to it. Yeah. Yeah. You try, you try and chain, chain branches locally. It's really tough. You make a single change, you got to recursively rebase up the stack. It's super painful. Maybe someone's branched off a branch, maybe done it three times over, but you very quickly learn a lesson of like, Oh, that's tough to incorporate down stack feedback.

Greg Foster 31:11 Maybe I won't do that again. You want to create a stack of 10 changes by hand? Good luck. Good luck. You're doing three point rebases all day. What you need is a better tool and you need it on the GitHub side. Need it on the local CLI side. And again, like we build stuff here, but there's, there's open source, there's a variety of open source CLIs that really help you manage those pointers, manage those stacks and recursively execute those rebases.

Conor Bronsdon 31:30 I want to talk about your approach at Graphite a bit, but before we get there, I have a more philosophical question. You know, GitHub has become kind of the center of the coding universe in a lot of ways. Now it's not everything, but as you pointed out, like it's, it's the norm for most companies and it's where open source work really happens. Do you think GitHub

Conor Bronsdon 31:51 needs to be reimagined for this new era of agents? Do they need to rethink their entire approach?

Greg Foster 31:58 It's a good question. It depends. You know, I don't want to tell GitHub is a fantastic company with a huge Yeah. We're an engineer. I want something there. Tell them how to run their show, but Yeah. Exactly. But what do we need to do? Listen, GitHub is a tough challenge. I am deeply empathetic to GitHub because they have a tough challenge. They got to serve two user communities.

Greg Foster 32:15 They have to serve all the open source developers in the world who have the longest tail of workflows and use cases, weird side projects and twenty year old Linux, you know, foundation versions, well as some bleeding edge new stuff. You know, all the new projects are also being hosted on GitHub. So they have the really wide user base over on open source. Then let's do step one. Step two, they have all the closed source companies that are running on GitHub. They're running on GitHub because it's kind of de facto and it's kind of the main tooling around. Microsoft does a good job of supporting it.

Greg Foster 32:46 And maybe they used to be on Bitbucket or explored GitLab, but by and large, a lot of the modern companies are just, are just using GitHub. One of the, you know, another reason is they often have a little bit open source. Even if you're a closed source company, you might have like 10% open source libraries or something. Set it off. It's nice to keep that all in the same GitHub organization,

Greg Foster 33:02 make some public, make it, make the rest private. So decentralized on GitHub. Now you can get a re imagine this. It's tough. Take a, take a concept of AI code reviews, take a concept of stacking, take merge skews, take all these different systems that we're seeing work together to help handle lower trust, higher volume coaching is being created. It's tough because what works in one environment might not work in the other environments. The stuff that is best for closed source development personally, think is a lot of things that optimize monorepos,

Greg Foster 33:31 trunk based development. You care about merge queues because you got 900 developers shipping every day. You have a really high trust environment because the average code review is a team of five people handing each other poll requests and saying, not, not please stranger, pull in my changes. They're saying, Hey, stamp this please. And I'm going to merge it in. Right. There's a different ownership model going on. You probably don't really have forking.

Greg Foster 33:50 You probably don't really have long lived feature branches. Open source, invert every one of those constraints. You have, they're more strangers though. The PRs are open longer. You don't want a concept like stacking because you're saying like, Hey, don't incrementally merge in your changes. Cause what if you disappear halfway through and then my code base is screwed up? I don't trust you. I don't have a, you don't sit next to me at work. Give me the full complete working solution or I'm not going to merge this thing in. So now we get, we're back to long lived feature branches, slower review cycles cause there's less trust.

Greg Foster 34:18 AI code review and so on, maybe, but who's footing the bill? This is, you know, you run into the same issues with CI and open source. It's a little bit less developed than the really heavy, rigorous, intense testing in closed source, partly because private companies are willing to spend a lot of money on that validation. So that diversion of patterns. So can GitHub do it? I mean, course they can. Of course, of course they can do a lot of stuff. They're a really, really strong engineering team, but it's, I empathize with the tough challenge they have in front of them. And I do think that the more they choose to lean into some of the AI

Greg Foster 34:46 power tools around software engineering, the more they may, offend their longtime open source communities. Cause I do think it's being adopted more fast and heavily in closed source. And if you lean into those patterns, it's gonna, you're gonna, you know, turn off some other workflows. Yeah. I would equate it to the challenge Google has faced where they had such a lead in so much IAI research, but faced this really classic innovator's dilemma where

Conor Bronsdon 35:10 they didn't want to kill their search business. And I think they've kind of figured out how to approach it and it seems to be working out well for them now, but they were a couple of years there while frankly, they were stumbling a bit while OpenAI was fast out the gate and others were, you know, diving forward and Anthropic was growing and people are kind of going, Hey, where's Google? Now I think Gemini is doing a lot of fantastic stuff. They've integrated extremely well on Google products. And frankly, they've had that integration internally for a long time with a variety of LLMs

Conor Bronsdon 35:38 that helped fuel, internal ad delivery and a lot of other things internally, but it wasn't really seeing the public light. And it's taken them a while to figure out, okay, how do we approach this cash cow we have in search and not kill the golden calf while we are trying to grow the next era. And GitHub's not the same level because it's not like the ads business, which is obviously a very special unique one. But it still has this, I think, challenge of how do we keep what we have here? And to your point, this, these bifurcated user group,

Conor Bronsdon 36:12 concerns while

Greg Foster 36:14 still trying to set up this next era. And you see them focusing a lot on CodeGen. I think that that's reasonable because code creation is an area where among these two user groups, it's actually pretty similar. Whether it's an open source project, closed source project, you're still going to Versus Code. You're still typing for a little while. Maybe you're using a V0 style pro style like project starter or creator. I think they have GitHub Spark, which is kind of their equivalent.

Greg Foster 36:38 So on the cogen side, it's a little bit easier. It's, I think it's really when you get back to that outer loop of software development, how people are collaborating and integrating, you see immensely different workflows and it's a little bit tougher for them to optimize that. And speaking of outer loop,

Conor Bronsdon 36:50 I think the work you're doing in Graphite is really interesting. The entire outer loop of software engineering is changing as we've kind of been talking about this whole conversation And Graphite has taken, I think really unique approach that is seeing a lot of success, obviously with some of the brands you're working with. I believe Anthropix backing you. Using Claude in some novel ways.

Conor Bronsdon 37:20 Without giving away the secret sauce, can you talk a bit about the unique challenges of applying LLMs to the task of code review as opposed to just code generation.

Greg Foster 37:31 Absolutely. Yeah. Yeah. You know, I, in many ways, for folks who haven't heard of Graphite, I can describe it a lot of different ways, but one way I can describe it on simple terms is a client on top of GitHub, helping folks execute code review and execute those outer loop steps. We help you once you have a pull request, process it, integrate it, test it, validate it, merge it as smoothly and quickly as possible. You might use an advanced email client on top of your old Gmail or Yahoo account. You might have a calendar client on your iPhone or a client on top of GitHub in many respects. And we leverage, we try to use a lot of these AI features. How are we using them?

Greg Foster 38:07 And how is anyone honestly using, using them in this phase of the process? There's a couple of really small, no brainers you could do. You can help generate the PR title and the description, and you can give some advanced search features. These are very simple stuff. You can help run a auto linter of sorts, an AI code review. I take that diff, feed it through the LLM and try and call out mistakes, issues,

Greg Foster 38:31 vulnerabilities in the code in line. In many ways, I mean, can, you can brand it differently. You can brand it as as you know, AI code review. It's kind of exciting. You can brand it in a boring way too, which I kind of enjoy as an engineer, which is, Hey, this is just another variant of CI. What is CI? You know, CI is I'm going take the code change, run some deterministic unit tests, and deterministic abstract syntactic tree, winter things on it. I'm going do all sorts so that I can give you a check mark or an X and I can leave some in my comments.

Greg Foster 38:59 What is it LLM? It's kind of like a fuzzy version of that. It's like a, you don't have to configure it much. Not very brutal. It kind of is very flexible, works for any language, but it's just, it's just giving you some validation and you don't, you don't fully accept a code change just because it passed CI, but it definitely sure as heck helps. I think AI code review fits that bucket. So we

Greg Foster 39:17 build some of that and a lot of it, and I'm not gonna lie there. We don't do too much fancy stuff. We, of course we work hard on this, but a lot of it is just taking really smart models. We don't build our own from Anthropic or Gemini or OpenAI, any of these companies. And sometimes a mix of them. We'll feed that diff through. We'll take custom rules and style guides from the users. We'll take previous uploaded and download comments and we'll try to build all together and try and leave them some good feedback on the pull request. We personally really optimize on leaving actionable inline comments and trying to be quiet if we don't have high confidence in the issue. Because

Greg Foster 39:50 man, I really think trust matters a lot with all these emergent AI tools. When I see information, if it's right, that's great. If it's wrong, I get really annoyed really fast. So I'd rather, if you're going to distract me, you better, you better have some really good confidence. We try to build that into the system. Other things we do, you know, we take inspiration again from the, from some of the innovations that the Cursor team created. Cursor team added this great sidebar

Greg Foster 40:13 on the IDE that let you ask questions and make modifications. And, you know, Sasha's not just us look at like any productivity product in the world right now from Google docs to wherever they all now are. Sasha said as well, right. Oh, you're going have just a copilot with you. That's going to, you know, work through. Think we'll a Everyone's find chat. Yeah. Exactly. But, you know, so we've, we've brought in a chat into their product, but it's actually worked real, it's been really nice, you know.

Greg Foster 40:37 A code review is actually a case where you want to ask questions or maybe run quick research queries on a bunch of old PRs or old You're really care programming in lot of ways. It really helps. It really helps. And also inline modifications. Sometimes you're like, Hey, this pull request looks pretty good. Just rename a couple of these variables. Now either I can check out that PR, pull it locally, modify those in my IDE, commit it, save it, push it back, or I can just ask chat, Hey, just, just fix those, those, those quick changes right here. And then we're good to go. And so we've also enabled it to make really fast early modifications.

Greg Foster 41:06 These are the, these are starting to be the, the, the, advents of how to use AI to make the review process better. It's conversational chat to research and modify the PR. It's AI automatically scanning, looking for issues. It's helping fill out the busy work of the process. We love doing this stuff because surface. We've already spent so much time building a really powerful

Greg Foster 41:31 pull request UI for looking at that code change and reviewing it manually. So it's really nice and easy to kind of layer on these, these nice, features on top of it. I think it's a little bit tougher if you don't start with a UI surface area because you're trying to do everything headlessly. Again, it's why I respect that the cursor team actually said, Hey, we're not just going build a Versus Code extension. We're going to take the entire IDE and that's going to allow us to have a better UX and go a little bit deeper on our integration here. Now they, they were able to fork Versus Code. We, we were, we weren't able to fork anything. So here we had to kind of recreate it from the ground up, but in many ways, we're still just a client on top of GitHub and modifying the underlying data.

Conor Bronsdon 42:07 This focus on the outer loop brings, something you said earlier, which is that seniors are really the ones who are seeing a lot of gains from these They AI are deeply enabled by them. They have the personal context and experience to get the most out of them. And I'll be frank, I'm worried. I'm worried juniors are being left behind. Like, sure, maybe they can learn more easily by using AI as a pair programmer and leveraging its knowledge. Maybe that's easier than going

Conor Bronsdon 42:41 through Stack Overflow page after Stack Overflow page. But the outer loop area is this area where you need a lot of context, seniors thrive, and we're seeing less junior software engineers get hired. We're seeing a lot of grads come out of top schools with engineering degrees, seemingly, at least anecdotally struggling to get jobs. We're seeing the percentages of hiring for juniors for most of the major, the Mag-seven and others,

Conor Bronsdon 43:10 go down. Is there a hiring gap that we need to be thinking about as an industry?

Greg Foster 43:17 I have- okay. So, so we're going to get into like pontification land. Caveat, caveat. Yeah. We're, yeah, we're, we're guests of the future here. So let's see, let's see where these, these, you know, predictions take us, but I have a couple of predictions going on and one is a little bit pessimistic and one is a little bit optimistic. So, you know, on a pessimistic prediction,

Greg Foster 43:39 I wouldn't be surprised if the software engineering field starts getting a little bit closer to what I've already seen happen in finance and in consulting and law, where you also get a lot of new grads from a lot of top universities and programs work really hard and really grindy and really humbly to desperately try and get a small number of opportunities at a big three consulting firm or a top law firm, or they go to Goldman and get destroyed in iBanking.

Greg Foster 44:06 Partly because there's not a ton of value. There's a lot of people want to do it and there's, there's a little bit less value for an entry level person, but if they can clear that entry level, then they start getting leveraged. They can start doing really powerful stuff in these fields. Engineering has been an interesting anomaly for the last twenty or so years where

Greg Foster 44:23 entry level people can be really useful and productive in an organization. There's a shortage of them. And so people graduate college and they get, you know, high a $100,000, sometimes total comp, 200,000 plus job offers. It's pretty incredible. And they're being swept up and go to companies with incredible perks and have an amazing time. I love that. I benefited from that. A lot of people do.

Greg Foster 44:42 But you know, if you see that regress to the mean a little bit, and it looks a little bit more like these other fields, I wouldn't be too shocked. It's a bummer. It's going to be tougher on folks graduating, but I just feel like we already have precedent for this in other fields and those fields are, they're holistically okay. There's room for improvement in some the iBanking and some of these things, but like

Greg Foster 45:01 the society seems generally okay with that. It's perhaps, perhaps that we're watching an anomaly kind of approach a meme here. That's my pessimistic take. My optimistic take is that if someone is a, if you're an individual and you have high initiative, and I think it really takes initiative, but if you have high initiative, man, the getting has never been so good. I really think so. When I, when I, so in high school, I had to get a job. So I didn't want to bag groceries at the local grocery store. Instead, I was like determined I was going make iOS apps, and it was like iOS three or four. I was like trying to figure out how to make iOS apps. And I'm reading tutorials online. I got coding for dummies.

Greg Foster 45:36 I found like an old low quality, like iTunes U university course on iOS development. And I'm fighting my way through Xcode on a virtual machine on a family Intel computer. And you make it work. I think the bar is lower now. I think if I was in high school trying to make an iOS app to make money on the app store, I think I have, you know, I have incredible tutoring. Heck, I don't, I have an Oracle that'll debug every problem for me and also has a learning mode built into that Oracle that'll help me. I have coding agents. Now I got to take initiative, but I can do a lot. I can get a lot of reps in. I can create a lot very, very, very quickly. And, you know, maybe I can kind of progress through

Greg Foster 46:13 that junior phase of software development and I can, I can take down barriers that would have existed before then? You're right. Maybe it's hard to get hired a company, but I do, from what I can tell, a lot these companies are still running relatively normal interviews. And if you can crush a coding interview and you can crush an architecture interview and you can show an amazing project, people will still look at you.

Greg Foster 46:32 You're just, you're just gonna have to show some initiative. You're gonna have to work very hard, but I'm optimistic for folks who have that energy. It's actually gotten a little bit nicer, a little bit easier and a little bit less gatekept in many ways. So competition's higher, but there's incredible opportunity. And I just really think like over the next ten years, we're going to see so much incredible technology be built out. Is it I'm just such an optimist. I think it's the best time ever to be an engineer, you know, not the worst time. I suspect

Conor Bronsdon 46:58 we're gonna see a melding of your two cases here, where yes, software engineering broadly is going to regress to the mean of, it's a little harder to get that incredible entry level role, but where people with high agency are enabled with tools and with capabilities beyond so far, so far beyond what we've seen in the past. And I think we're already seeing that with some people building companies, building iOS apps, as you mentioned.

Conor Bronsdon 47:26 And while we're on the topic, let's just keep going into the future. I I'd love to keep unraveling from you what, what you're seeing. What's graphite strategy as you look at the next, God, it's hard to say this, but let's call it five years of software engineering, which is a lot of time in AI land. Maybe it's really two years. Like how are you thinking about these next stages of development? Do you see a new wave coming you're trying to address? Is it really all about like nailing the current level of agents? Curious on your perspective.

Greg Foster 47:55 Absolutely. So I think about this. I have to. I'm a founder. It's my job. Step one, what are we, what are we trying to do as a company? We're trying to build the best tooling possible to help engineers collaborate on code changes. We think fundamentally code collaboration, it exists now. It's going continue to exist. Maybe some of that collaboration is with AI bots, but we're still going to be working together. I don't think the whole world moves to like individual companies run by one engineer. No, no, no. We're, we still got engineers working together, collaborating with those code changes, and we are in the business of helping them work on that. So

Greg Foster 48:28 now I can extrapolate that. And you know, a lot of that goes into just building classic product fundamentals. Let's build a great, great UX. Let's build great workflows. Let's take good ideas from these big tech companies that were bottled up and let's bring them out to everyone. These classic dev tool principles still apply. Now I have to, then I also have to play Oracle with AI. And when I play Oracle with AI,

Greg Foster 48:48 I think about a couple of different outcomes. One outcome is we stall. We, wherever, wherever we currently are, you, there's always a chance you're like, Oh, I guess this, this was the peak, you know? This is as good, as smart as it gets. It's unlikely because I'm of just gonna jump here and here, even if it does stall at that, there's still so many gains to be had

Conor Bronsdon 49:06 over the next few years around the infra, around the providing context. If the actual level of reasoning stalls for a year or two, which I think is possible, word or at least slows down. I think we're maybe seeing that. There's just so many games around the edges of the outer loop that you're already working on. That'd be my take at least. I completely agree.

Greg Foster 49:24 I think we can keep I think not all the UX patterns have been invented here. No. I think not all the smart ideas have come up and I want to help find those, understand them, incorporate them into the product and keep optimizing that mission of helping engineers work in coaching. Now that's if, if it, you're, I agree. If, if we, if this is as smart as AI gets, we, we, we still got our work cut out for us. There's another question. Okay. What if AI gets so,

Greg Foster 49:47 smart that, it really starts changing how software engineering gets done? Maybe you really are mostly collaborating with bots. We're still in a world where you're mostly collaborating with humans and people are using the create code, but you're, there's still like another human avatar user on the other end, mostly in code review and these systems. What if that really starts shifting? What if we really start getting like, like a lot of these coaches or

Greg Foster 50:06 AI? Okay. How do we think about the world? Maybe it looks, you mentioned like a little more tech leady or everyone's acting like an engineering manager. You're now wrangling various agents and you're, you're chatting with them, giving a feedback and trying to incorporate their code changes. And I think, and I think there's like this third level, I, I imagine if AI gets really, really good and I don't even need much of the review side anymore, if it gets so good that it listens in on all my meetings and all my feedback and it just does, it can do review better than I can and writes my tests and executes them and coordinates my AWS infrastructure,

Greg Foster 50:38 what's left for me then? I, oh, one. Okay. Now, now we really are like wondering if we're out of a job, but I think that it starts looking like an agency model. I actually have a paradigm for this. So if, if like one step up of intelligence is you're a manager or a tech lead, The next step up is you're, you're, you're like a, you're someone hiring an agency. And if you've ever really contracted an agency to build you a website, what actually happens is you talk to them and they say, fantastic. Thanks for calling us to build a website. Step one, tell us what you want. Then they're like, okay. Yeah, yeah. But you're really bad at articulating your vision. So I'm actually gonna like interview and like pull out what you really want for thirty minutes. And they're like, I'm going come back to you in a week and I'm going show you three variants because I still think that you don't know what you want. And then we're going pick that one. Then I'm going to keep Imagine I'm going hand you a website that we worked on that I like did for you and you were annoying to work with,

Greg Foster 51:22 and you have no idea how it works. You've never read the code, but here's your website. That's like the agency model of AI. That's like, that to me is like the upper bound of how far we approach this, where that's what happens if you stop reviewing the code a little bit. He's, he's so smart that they're just pulling the context out of you, like treating you like a, like a little child. And so that, so I think, you know, we end up on a spectrum somewhere in that world.

Greg Foster 51:42 I think, I dunno, I'm, this is a very, vanilla take, but I think we'll end up kind of in the middle where 20% of changes are headless. Engineers are still running some of them. We're still heavily involved in code review. The very least I think about the security in the context is just such a blocker to getting out of the code review side of things. Even if these things are amazingly smart, I've yet to see people solve the gullibility problem of AI. You just, you look at these hacks and they're like, you just, you just insert a little prompt injection and it goes off the rails.

Greg Foster 52:11 I really hope the Tesla autopilot team is still reading the code changes going into their Got it. Too. Really hoping, you know, there's high stakes engineering happening in the world. So I think it'll be milky. But I do, do pontificate about like, what happens if we just don't even review, don't even read the code ever? Oh man.

Conor Bronsdon 52:27 Greg, I feel like we could have another hour of conversation, but we do have to wrap it up. Thank you so much for the lovely chat. It's been such a fun time. Where can our listeners go to find you and to find Graphite, if they want to learn more? Absolutely. If you want to learn more about Graphite, you just go to graphite.dev.

Greg Foster 52:43 We have a lovely splash page. You can sign up for a free trial. You can play with it. There's no lock in. If you want learn more about myself, you can check me out on TwitterX or LinkedIn, where I'm reasonably active.

Conor Bronsdon 52:55 Fantastic. So much fun chatting with you today. Really, really appreciate the time. And, thanks for all the insights and, and, I think mild debate, but, a lot of a lot of interesting stuff here. I think there's a lot of takeaways and I mean, threads we can keep pulling on here because there is such a transformation happening in software development and it's clear that we need to rethink how work happens, not just for today, but for the next couple of years as we look at these potential scenarios we're talking about.

Conor Bronsdon 53:26 Thank you all for listening. That's all for this episode of Chain of Thought. Don't forget to subscribe to our new Chain of Thought newsletter on LinkedIn for more insights on Building with AI and make sure you're subscribed to the podcast while you're at it, whether you're on YouTube, Apple Podcasts, Spotify, your favorite podcasting app of choice, we don't want you to miss a conversation. And God, if you are an Apple Podcasts, if you're on Spotify, if you're on YouTube, you know what means a lot to us? A comment, a like, a review, that sort of engagement really is an incredible signal to both, your human counterparts that maybe they check out the show. And you know what? It's great for the digital counterparts who are deciding whether or not to index us, whether to promote us in the feed, etcetera. So, you know, provide the context that everyone needs to enjoy Chain of Thought. And speaking of great conversations, we're always looking for more AI builders and leaders for each on the show. If you know someone who'd be a perfect fit, please reach out to us on socials or leave a comment with your review of the show. Thanks for listening. We'll see you next week. Greg, thank you so much for joining us. Ton tons of fun. Thanks for having me. And we'll get you peddling reviews.

Conor Bronsdon 54:24 I have to. It's not just me. Yeah.

Greg Foster 54:26 Awesome. Thanks guys. Thanks.