Vibe coding in prod | Code w/ Claude
00:00:00.000 | Hi everyone, welcome.
00:00:05.820 | I'm here to talk about everyone's favorite subject, vibe coding.
00:00:12.140 | And somewhat controversially, how to vibe code in prod responsibly.
00:00:18.260 | So let's talk about vibe coding and what this even is.
00:00:24.080 | So first of all, I'm Eric.
00:00:25.400 | I'm a researcher at Anthropic focused on coding agents.
00:00:29.600 | I was the author, along with Barry Zang, of Building Effective Agents,
00:00:33.160 | where we outlined for all of you our best science and best practices
00:00:38.400 | for creating agents, no matter what the application is.
00:00:41.520 | This is a subject that's near and dear to my heart.
00:00:44.840 | Last year, I actually broke my hand while biking to work
00:00:48.100 | and was in a cast for two months.
00:00:49.940 | And Claude wrote all of my code for those two months.
00:00:53.200 | And so figuring out how to make this happen effectively
00:00:56.780 | was really important to me, and I was luckily able to figure
00:00:59.200 | that out well and sort of help bring that into a lot of Anthropic's
00:01:03.760 | other products and in our models through my research.
00:01:07.280 | So let's first start talking about what is vibe coding.
00:01:12.280 | A lot of people really conflate vibe coding with just extensive use of AI
00:01:16.760 | to generate your code.
00:01:18.700 | But I think this isn't quite true.
00:01:20.500 | A lot of people, you know, they're using Cursor.
00:01:22.500 | They're using Copilot.
00:01:24.960 | It's a lot of AI and a lot of the code is coming from the AI rather than them writing itself.
00:01:29.520 | But I think when you are still in a tight feedback loop with a model like that, that isn't truly vibe coding.
00:01:37.600 | When I say vibe coding, I think we need to go to Andre Carpathie's definition, where vibe coding is where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.
00:01:49.600 | I think the key part here is forget the code even exists.
00:01:54.160 | And now the reason this is important is that vibe coding was when people outside of the engineering industry really started getting excited about code generation.
00:02:04.160 | Copilot and Cursor were great, but only sort of for engineers, but someone that didn't know how to code, suddenly with vibe coding, they could find themselves coding an entire app by themselves.
00:02:16.160 | And this was a really exciting thing and a big unlock to a lot of people.
00:02:20.720 | Now, of course, there were a lot of downsides of this.
00:02:24.720 | And you had people coding for the first time and really without knowing what they were doing at all.
00:02:30.160 | And you said, hey, you know, random things are happening, maxed out usage on my API keys.
00:02:34.720 | People are bypassing the subscription, creating random shit on the DB.
00:02:38.720 | And so, you know, this is kind of the downside of vibe coding of what started happening.
00:02:45.280 | And the positive sides of vibe coding that you'd see were all things that were really kind of low stakes.
00:02:52.240 | It was people building video games, building sort of fun side projects, things where it's okay if there is a bug.
00:03:00.560 | So, you know, why do we even care about vibe coding if it seems like something where the stakes are really high if you do it for a real product?
00:03:09.120 | And the most successful cases of it are kind of these toy examples or fun things where the stakes are very low.
00:03:15.680 | And my answer for why we should care about vibe coding is because of the exponential.
00:03:21.680 | The length of tasks that AI can do is doubling every seven months.
00:03:28.000 | Right now, we're at about an hour.
00:03:30.880 | And that's fine.
00:03:32.800 | You don't need to vibe code.
00:03:34.480 | You can have cursor work for you.
00:03:37.040 | You can have Claude code write a feature that would take an hour.
00:03:40.080 | And you can review all that code.
00:03:42.960 | And you can still be intimately involved as the AI is writing a lot of your code.
00:03:48.080 | But what happens next year?
00:03:50.240 | What happens the year after that?
00:03:52.000 | When the AI is powerful enough that it can be generating an entire day's worth of work for you
00:03:57.600 | at a time or an entire week's worth of work, there is no way that we're going to be able to keep up
00:04:03.280 | with that if we still need to move in lockstep.
00:04:06.080 | And that means that if we want to take advantage of this exponential, we are going to have to find a way
00:04:13.760 | to responsibly give into this and find some way to leverage this task.
00:04:19.920 | I think my favorite analogy here is like compilers.
00:04:23.360 | I'm sure in the early day of compilers, a lot of developers, you know, really didn't trust them.
00:04:28.640 | They might use a compiler, but they'd still read the assembly that it would output to make sure it
00:04:32.720 | looks, you know, how they would write the assembly.
00:04:34.720 | But that just doesn't scale.
00:04:36.800 | You know, at a certain point, you start needing to work on systems that are big enough that
00:04:41.120 | you just have to trust the system.
00:04:43.360 | The question, though, is how do you do that responsibly?
00:04:46.800 | And I think sort of my challenge to the whole software industry over the next few years is,
00:04:52.080 | how will we vibe code in prod and do it safely?
00:04:55.360 | And my answer to that is that we will forget that the code exists, but not that the product exists.
00:05:02.240 | Thinking again to that compiler analogy, you know, we all still know that there's assembly under the hood,
00:05:07.360 | but hopefully most of us don't need to really think about what the assembly actually is.
00:05:11.600 | But we still, you know, are able to build good software without understanding that assembly under the hood.
00:05:17.680 | And I think that we will get to that same level with software.
00:05:21.360 | And one thing I really want to emphasize is that this is not a new problem.
00:05:28.160 | How does a CTO manage an expert in a domain where the CTO is not themselves an expert?
00:05:36.000 | How does a PM review an engineering feature when they themselves can't read all the code that went into it?
00:05:44.320 | Or how does a CEO check the accountant's work when they are themselves are not an expert in financial accounting?
00:05:50.880 | And these are all, you know, problems that have existed for hundreds or thousands of years.
00:05:56.080 | And we have solutions to them.
00:05:57.360 | A CTO can still write acceptance tests for an expert that works for them,
00:06:03.520 | even if they don't understand the implementation under the hood.
00:06:06.240 | They can see that these acceptance tests pass and that the work is high quality.
00:06:11.920 | A product manager can use the product that their engineering team built
00:06:15.840 | and make sure that it works the way they expected, even if they're not writing the code.
00:06:19.920 | And a CEO can spot check key facts that they do understand and slices of the data
00:06:27.120 | so that they can build confidence in the overall financial model,
00:06:31.040 | even though they themselves might not be an expert in how the entire thing flows.
00:06:36.400 | And so thinking about these examples, managing implementations that you yourself don't understand
00:06:44.160 | is actually a problem as old as civilization.
00:06:46.960 | And every manager in the world is actually already dealing with this.
00:06:52.480 | Just we as software engineers are not used to this.
00:06:55.680 | We are used to being purely individual contributors where we understand the full depth down to the stack.
00:07:01.600 | But that's something that in order to become most productive, we are going to need to let go of
00:07:07.360 | in the way that every manager, in order to be most productive, is going to need to let go of some details.
00:07:13.040 | And just like us as software engineers, you know, we let go of some of the details,
00:07:17.680 | like understanding the assembly itself that's happening under the hood.
00:07:21.360 | And the way that you do this, while still being safe and being responsible, is to find an abstraction
00:07:29.440 | layer that you can verify, even without knowing the implementation underneath it.
00:07:33.920 | Now, I have one caveat to that today, which is tech debt.
00:07:40.400 | So right now, there is not a good way to measure or validate tech debt without reading the code yourself.
00:07:50.000 | Most other systems in life, you know, like the accountant example, the PM,
00:07:54.800 | you know, you have ways to verify the things you care about without knowing the implementation.
00:08:00.640 | Tech debt, I think, is one of those rare things where there really isn't a good way to validate it,
00:08:05.360 | other than being an expert in the implementation itself.
00:08:08.480 | So that is the one thing that right now we do not have a good way to validate.
00:08:12.640 | However, that doesn't mean that we can't do this at all.
00:08:16.560 | It just means we need to be very smart and targeted of where we can take advantage of vibe coding.
00:08:23.120 | My answer to this is to focus on leaf nodes in our code base.
00:08:28.720 | And what I mean by that is parts of the code and parts of our system that nothing depends on them.
00:08:36.320 | They are kind of the end feature.
00:08:38.080 | They're the end beller whistle.
00:08:39.520 | Rather than things that are the branch or trunks beneath them, like here in white.
00:08:45.200 | Here the orange dots are all these leaf nodes where, honestly, if you have a system like this,
00:08:50.080 | it's kind of okay if there is tech debt in these leaf nodes because nothing else depends on them.
00:08:56.640 | They're unlikely to change.
00:08:57.920 | They're unlikely to have further things built on them.
00:09:00.240 | Versus the things that are in white here, the trunks and the underlying branches of your system,
00:09:06.480 | that is the core architecture that we as engineers still need to deeply understand
00:09:11.600 | because that's what's going to change.
00:09:13.040 | That's what other things are going to be built on.
00:09:15.280 | And it's very important that we protect those and make sure that they stay extensible
00:09:20.320 | and understandable and flexible.
00:09:22.480 | Now, the one thing I will say here is that the models are getting better all the time.
00:09:27.920 | And so we might get to a world where this gets further and further down,
00:09:31.200 | where we trust the models more and more to write code that is extensible and doesn't have tech debt.
00:09:37.200 | Using the Claude 4 models over the last week or two within Anthropic has been a really exciting thing.
00:09:44.080 | And I've given them much more trust than I did with 3.7.
00:09:48.480 | So I think that this is going to change.
00:09:50.400 | And more and more of the stack we will be able to work with in this way.
00:09:55.280 | So let's talk about how to succeed at vibe coding.
00:09:58.400 | And my main advice here is ask not what Claude can do for you, but what you can do for Claude.
00:10:05.120 | I think when you're vibe coding, you are basically acting as a product manager for Claude.
00:10:10.640 | So you need to think like a product manager.
00:10:12.480 | What guidance or context would a new employee on your team need to succeed at this task?
00:10:18.720 | I think a lot of times we're too used to doing sort of a very quick back and forth chat with AI.
00:10:23.760 | Make this feature, fix this bug.
00:10:25.520 | But a human, if it was their first day on the job and you just said,
00:10:30.320 | Hey, implement this feature.
00:10:32.400 | There's no way that you'd expect them to actually succeed at that.
00:10:35.360 | You need to give them a tour of the code base.
00:10:37.200 | You need to tell them what are the actual requirements and specifications
00:10:41.600 | and constraints that they need to understand.
00:10:43.680 | And I think that as we vibe code, that becomes our responsibility to feed that information into Claude,
00:10:50.560 | to make sure that it has all that same context and is set up to succeed.
00:10:54.640 | When I'm working on features with Claude, I often spend 15 or 20 minutes collecting guidance into a
00:11:02.320 | single prompt and then let Claude cook after that.
00:11:05.120 | And that 15 or 20 minutes isn't just me, you know, writing the prompt by hand.
00:11:09.120 | This is often a separate conversation where I'm talking back and forth with Claude.
00:11:14.480 | It's exploring the code base.
00:11:15.920 | It's looking for files.
00:11:17.360 | We're building a plan together that captures the essence of what I want,
00:11:21.920 | what files are going to be changed, what patterns in the code base should it follow.
00:11:26.640 | And once I have that artifact, that all of that information, then I give it to Claude,
00:11:31.360 | either in a new context or say, hey, let's go execute this plan.
00:11:35.600 | And I've typically seen once I put that effort into collecting all that information, Claude has a very,
00:11:41.200 | very high success rate of being able to complete something in a very good way.
00:11:47.600 | And the other thing I'll say here is that you need to be able to ask the right questions.
00:11:52.640 | And despite the title of my talk, I don't think that vibe coding and prod is for everybody.
00:11:59.760 | I don't think that people that are fully non-technical
00:12:02.720 | should go and try to build a business fully from scratch.
00:12:05.280 | I think that is dangerous because they're not able to ask the right questions.
00:12:09.760 | They're not able to be an effective product manager for Claude when they do that.
00:12:15.040 | And so they're not going to succeed.
00:12:17.040 | We recently merged a 22,000 line change to our production reinforcement learning code base
00:12:22.960 | that was written heavily by Claude.
00:12:24.720 | So how on earth did we do this responsibly?
00:12:28.640 | And yes, this is the actual screenshot of the diff from GitHub for the PR.
00:12:33.440 | The first thing is we asked what we could do for Claude.
00:12:38.960 | This wasn't just a single prompt that we then merged.
00:12:41.440 | There was still days of human work that went into this, of coming up with the requirements,
00:12:46.480 | guiding Claude and figuring out what the system should be.
00:12:50.160 | And we really, really embraced our roles as the product manager for Claude in this feature.
00:12:57.280 | The change was largely concentrated in leaf nodes in our code base where we knew it was okay for there to be some tech debt because we didn't expect these parts of the code base to need to change in the near future.
00:13:09.360 | And the parts of it that we did think were important that would need to be extensible, we did have a human review of those parts.
00:13:15.920 | And lastly, we carefully designed stress tests for stability, and we designed the whole system so that it would have very easily human verifiable inputs and outputs.
00:13:29.600 | And what that let us do, these last two pieces, is it let us create these sort of verifiable checkpoints so that we could make sure that this was correct even without understanding or reading the full underlying implementation.
00:13:43.280 | Our biggest concern was stability and we were able to measure that even without reading the code by creating these stress tests and running them for long durations.
00:13:52.000 | And we were able to verify correctness based on the input and outputs of the system that we designed it to have.
00:13:58.960 | So basically we designed this system to be understandable and verifiable even without us reading all the code.
00:14:06.640 | And so ultimately by combining those things, we were able to become just as confident in this change as any other change that we made to our code base.
00:14:14.960 | But deliver it in sort of a tiny fraction of the time and effort that it would have taken to write this entire thing from hand by hand and review sort of every line of it.
00:14:24.960 | And I think one of the really exciting things about this is not just that this saved us a week's worth of human time, but knowing that we could do this, it made us think differently about our engineering, about what we could do.
00:14:41.960 | And now suddenly when something costs one day of time instead of two weeks, you realize that you can go and make much bigger features and much bigger changes.
00:14:53.960 | Sort of like the marginal cost of software is lower and it lets you consume and build more software.
00:15:00.960 | So I think that was the really exciting thing about this is not just saving the time, but now kind of feeling like, oh, things that are going to take two weeks, let's just do them.
00:15:09.960 | It's only going to take a day.
00:15:11.960 | And that's kind of the exciting thing here.
00:15:14.960 | So to leave you with the closing thoughts about how to vibe code and prod responsibly, be Claude's PM.
00:15:21.960 | Ask not what Claude can do for you, but what you can do for Claude.
00:15:25.960 | Focus your vibe coding on the leaf nodes, not the core architecture and underlying systems, so that if there is tech debt, it's contained and it's not in important areas.
00:15:36.960 | Think about verifiability and how you can know whether this change is correct without needing to go read the code yourself.
00:15:45.960 | And finally, remember the exponential.
00:15:48.960 | It's okay today if you don't vibe code, but in a year or two, it's going to be a huge, huge disadvantage if you yourself are demanding that you read every single line of code or write every single line of code.
00:16:01.960 | You're going to not be able to take advantage of the newest wave of models that are able to produce very, very large chunks of work for you.
00:16:08.960 | And you are going to become the bottleneck if we don't get good at this.
00:16:11.960 | So overall, that is vibe coding and prod responsibly.
00:16:15.960 | And I think this is going to become one of the biggest challenges for the software engineering industry over the next few years.
00:16:21.960 | Thank you, and I have plenty of time for questions.
00:16:23.960 | Yeah.
00:16:24.960 | In the past, we spent a lot of time dealing with syntax problems or libraries or connections amongst components of the code.
00:16:36.960 | And that was how we learned by coding like that.
00:16:39.960 | But how do we learn now?
00:16:42.960 | How do we become better vibe coders?
00:16:44.960 | How do we know more to become better product managers of the agent KI?
00:16:50.960 | Yeah.
00:16:51.960 | Yeah.
00:16:52.960 | So I think this is a really interesting question.
00:16:54.960 | And I think there are reasons to be very worried about this and also reasons to be very optimistic about this.
00:17:00.960 | I think the reason to be worried, like you mentioned, is that, you know, we are not going to be there in the struggle, in the grind.
00:17:07.960 | I think that that is actually okay.
00:17:11.960 | I've met, you know, some of my professors in college would say, like, oh, man, like, coders today aren't as good because they never had to write their assembly by hand.
00:17:19.960 | They don't really feel the pain of, you know, how to make something run really fast.
00:17:24.960 | I think the positive side of this is that I have found that I'm able to learn about things so much more quickly by using these AI tools.
00:17:33.960 | A lot of times when I am coding with Claude, I'll be reviewing the code and I'll say, hey, Claude, I've never seen this library before.
00:17:40.960 | Like, tell me about it.
00:17:41.960 | Like, what is it?
00:17:42.960 | Why did you choose it over another?
00:17:43.960 | And having sort of that always there pair programmer, like, again, I think what's going to change is that people that are lazy are not going to learn.
00:17:53.960 | They're just going to glide by.
00:17:55.960 | But if you take the time and you want to learn, there's all these amazing resources and, like, Claude will help you understand what it vibe coded for you.
00:18:04.960 | The other thing I will say is that for learning some of these higher level things about what makes a project go well, what is a feature that gets you product market fit versus flops, we're going to be able to take so many more shots on goal.
00:18:17.960 | I feel like, especially sort of like system engineers or architects, it takes, you know, oftentimes like two years to, like, make a big change in a code base and really kind of come to terms with was that a good architecture decision or not.
00:18:31.960 | And if we can collapse that time down to six months, I think engineers that are investing in their own time and trying to learn, they're going to be able to, you know, learn from four times as many lessons in the same amount of calendar time, as long as they're putting in the effort to try.
00:18:46.960 | Yeah, going back to your pre-planning process, what's the balance between giving it too much information and too little? Are you giving it a full product requirement document? Is there kind of a standardized template that you put together before you actually move into vibe coding?
00:19:00.960 | Yeah, I think it depends a lot on what you care about. I would say that if it ranges, for things where I don't really care how it does it, I won't talk at all about the implementation details.
00:19:15.960 | But I'll just say, these are my requirements, like, this is what I want at the end. There's other times where I know the code base well, and I will go into much more depth of like, hey, these are the classes you should use to implement this logic.
00:19:26.960 | Look at this example of a similar feature. I'd say it all comes down to sort of what you care about at the end of the day.
00:19:32.960 | I would say, though, that like, our models do best when you don't over constrain them. So, you know, if you I wouldn't put too much effort into creating sort of a very rigorous, you know, format or anything, I would just, you know, think about it as like a junior engineer what you would give them in order to succeed.
00:19:51.960 | So, oh, sorry if I'm too loud. How did you balance effectiveness and cybersecurity? Like, there were reports a couple months back of like the top 10 vibe coded apps being super vulnerable and a lot of important information was released.
00:20:13.960 | Well, not released, but proven to be released. And the person who did it wasn't even like, like a pro hacker and stuff. And so like, there's that how did you balance being able to keep things secure even at a leaf node level?
00:20:27.960 | And then also being effective because something can be effective, but not secure.
00:20:32.960 | Yeah, that's a great question. And I think that all comes down to this first point here of like being Claude's PM and understanding enough about the context to basically know what is dangerous
00:20:43.960 | know what's safe and know where you should be careful. And I think, yeah, the things that get a lot of press about vibe coding are people that have no business coding at all doing this.
00:20:53.960 | And that's fine. That's great for games. That's great for like creativity and like having people be able to create.
00:20:59.960 | But I think for production systems, you need to know enough about like what questions to ask to guide Claude in the right direction.
00:21:07.960 | And for our internal case of this, this example, it was something that's fully offline.
00:21:12.960 | And so we knew there weren't any like there were, we were very, very confident that there was like no security problems that could happen into this.
00:21:20.960 | In our case, it's like run in something that's fully offline.
00:21:23.960 | So this is more about people you're mentioning is like have no business.
00:21:30.960 | And maybe I shouldn't have said it like that, but no business vibe coding and production for an important system.
00:21:37.960 | I will say, I will say that.
00:21:39.960 | But if we look at the numbers, right, we less than 0.5% of the world's population are software developers and software is an amazing way to scale ideas.
00:21:51.960 | So how do you think the products need to change to make it easier for people to write code and build software while also avoiding some of the things that we run into with people leaking API keys and things like that?
00:22:07.960 | That's really great question. And I would be super excited to see more products and frameworks emerge that are kind of like provably correct.
00:22:15.960 | And maybe what I mean by that is I'm sure people could build some back end systems that the important off parts, the payment parts are built for you.
00:22:24.960 | And all you have to do is sort of fill in the UI layer.
00:22:29.960 | And, you know, you can vibe code that and it basically gives you some nice fill in the blank sandboxes where to put your code.
00:22:36.960 | I feel like there's tons of things like that that could exist.
00:22:40.960 | And maybe like the simplest example is like Claude artifacts where Claude can help you write, you know, code that gets hosted right there in Claude AI to display.
00:22:51.960 | And of course that is safe because it is very limited.
00:22:54.960 | There is no off. There is no payments. It's it's front end only.
00:22:58.960 | But maybe that's a good like product idea that someone should do here is build some way to make like a provably correct hosting system that can have a back end that you know is safe no matter what shenanigans happens on the front end.
00:23:10.960 | But yeah, I hope people build good tools that are complements to vibe coding.
00:23:14.960 | Hi. So for test driven development, do you have any tips?
00:23:20.960 | Because like I often see that Claude just spits out the entire implementation and then writes test cases.
00:23:25.960 | Sometimes they don't--they fail.
00:23:27.960 | And then I just want, you know, I'm trying to prompt it to write the test cases first.
00:23:32.960 | But I also don't want to like, you know, verify them by myself because I haven't seen implementation yet.
00:23:37.960 | So do you have an iteratable approach that, you know, have you ever tried it for test driven development?
00:23:43.960 | Yeah, test driven development.
00:23:44.960 | Yeah, yeah, I definitely-- test driven development is very, very useful in vibe coding.
00:23:49.960 | As long as you can understand what the test cases are.
00:23:52.960 | Even without that, it helps Claude sort of be a little bit more self consistent, even if you yourself don't look at the tests.
00:23:58.960 | But a lot of times, I'd say it's easy for Claude to go down a rabbit hole of writing tests that are like too implementation specific.
00:24:06.960 | When I'm trying to do this, a lot of times I will encourage--I will give Claude examples of like, hey, just write three end-to-end tests and, you know, do the happy path and error case and this other error case.
00:24:22.960 | And I'm kind of like very prescriptive about that I want the test to be like general and end-to-end.
00:24:29.960 | And I think that helps make sure it's something that I can understand and it's something that Claude can do without getting too in the weeds.
00:24:39.960 | I'll also say a lot of times when I'm vibe coding, the only part of the code or at least the first part of the code that I'll read is the tests to make sure that, you know, if I agree with the tests and the tests pass, then I feel pretty good about the code.
00:24:54.960 | That works best if you can encourage Claude to write sort of very minimalist end-to-end tests.
00:24:59.960 | Thank you for the very fascinating talk.
00:25:01.960 | I also appreciate that you've done what a lot of people haven't done and tried to interpret one of the more peculiar lines in Carpathie's original post, embrace exponentials.
00:25:11.960 | Yes.
00:25:12.960 | So I wonder if I could pin you down a little more and say, how would I know if I've embraced the exponentials?
00:25:18.960 | What precisely means following that advice?
00:25:22.960 | And to maybe put it down a little more in what I think it intends to mean.
00:25:26.960 | It sort of maybe alludes to this, the models will get better.
00:25:31.960 | Do you think there's some legitimacy in saying just the fact that the models will get better doesn't mean they'll get better at every conceivable dimension we might be imagining we hope they'll be in?
00:25:42.960 | Yeah.
00:25:43.960 | So yeah.
00:25:44.960 | How do I embrace an exponentials there?
00:25:46.960 | Yeah, absolutely.
00:25:47.960 | So I think you got close with sort of the quote of keep assuming the models are going to get better.
00:25:54.960 | But it's a step beyond that.
00:25:56.960 | The idea of the exponential is not just that they're going to keep getting better, but they're going to get better faster than we can possibly imagine.
00:26:05.960 | And that's kind of like when you can kind of see the shape of the dots here.
00:26:10.960 | It's not just that it's getting steadily better.
00:26:12.960 | It's that it's getting better and then it goes wild.
00:26:15.960 | I think the other funny quote I heard from this, this was I think in Dario and Mike Krieger's talk, is machines of loving grace is not science fiction.
00:26:24.960 | It's a product roadmap.
00:26:25.960 | Even though it sounds like something that's very far out, like when you are on an exponential, things get wild very, very fast and faster than you expect.
00:26:34.960 | And I think, you know, if you if you talk to someone that was doing computers in the 90s, it's like, OK, great.
00:26:39.960 | We have a couple kilobytes of RAM.
00:26:41.960 | We have a couple more kilobytes of RAM.
00:26:43.960 | But if you fast forward to where we are now, it's like we have terabytes.
00:26:47.960 | And it's like it's not just that it got twice as good.
00:26:50.960 | It's that things got millions of times better.
00:26:53.960 | And that's what happens with exponentials over a course of 20 years.
00:26:57.960 | So we shouldn't think about 20 years from now is like what happens if these models are twice as good.
00:27:02.960 | We should think about what happens if these models are a million times smarter and faster than they are today, which is wild.
00:27:08.960 | Like I we can't even think about what that means in the same way that someone working on computers in the 90s.
00:27:13.960 | I don't think they could think about what would happen to society if a computer was a million times faster than what they were working with.
00:27:20.960 | But that's what happened. And so that's what we mean by the exponential is it's going to go bonkers.
00:27:25.960 | All right.
00:27:26.960 | Yes.
00:27:27.960 | I got a couple. Well, I got one question, but it's kind of two parts.
00:27:32.960 | The first part, when it comes to via coding, I have like two different workflows.
00:27:36.960 | I have one where I'm in my terminal and then I have one when I'm in VS code or cursor.
00:27:42.960 | Which workflow do you use?
00:27:45.960 | And if you're using cloud code in a terminal, how often do you compact?
00:27:51.960 | Because what I find is my functions will get a new name as the longer I vibe code or, you know, just things kind of go off the rails the longer I go.
00:28:02.960 | And if I compact, it still happens.
00:28:04.960 | If I create like a document to kind of guide it, I still have to, you know, get it back on track.
00:28:10.960 | Yeah. Yeah. Great question. I do both. I often code with cloud code open in my terminal in VS code.
00:28:18.960 | And I'd say that like cloud code is doing most of the editing and I'm kind of reviewing the code as I go in VS code, which, you know, is not true vibe coding in the sense here.
00:28:29.960 | Or maybe I'm reviewing just the tests from it.
00:28:33.960 | I like to compact or just start a new session kind of whenever I get clawed to a good stopping point where it kind of feels like, okay, as a human programmer, like when would I kind of stop and take a break and maybe like go get lunch and then come back.
00:28:48.960 | If I feel like I'm at that kind of stage, that's like a good time to compact.
00:28:52.960 | So maybe I'll start off with having clawed find all the relevant files and make a plan.
00:28:57.960 | And then I'll say, okay, like, you know, write all this into a document and then I'll compact.
00:29:02.960 | And that gets rid of a hundred K tokens that we took to create that plan and find all these files and boils it down to a few thousand tokens.
00:29:10.960 | Hey, so one question is following up his previous question, which is have you used other tools along with cloud code to like increase your speed a little bit more like running multiple cloud codes together using get work trees and then like sort of merging few things or stack PR or something like that.
00:29:33.960 | Is that something that you like personally follow or would advise to?
00:29:36.960 | Second question is, um, how do you like, how do you very structurally and like in a very nice engineering, like, um, like way approach a part of the code base that you're not very familiar with, but you want to like ship a PR in it really fast and you want to do it in a really nice way and not wipe code it.
00:29:56.960 | So yeah, like what, what are the, what are your ways of like using cloud code to do help to both these things?
00:30:02.960 | Yep.
00:30:03.960 | Uh, yeah, so I definitely use cloud code as well as cursor.
00:30:06.960 | Um, and I'd say typically all like start things with cloud code and then I'll use cursor to fix things up.
00:30:13.960 | Or if I was like, if I have very specific changes, if I know exactly the change that I want to do to this file, I'll just do it myself, uh, with cursor and sort of target the exact lines that I know need to change.
00:30:24.960 | Um, the second part of your question was, um, oh yeah, like, uh, how to get spun up on a new part of the code base.
00:30:33.960 | Um, before I start trying to write the feature, I use clawed code to help me explore the code base.
00:30:39.960 | So I might say like, tell me where in this code base off happens or, you know, where in this code base something happens, tell me similar features to this and like, have it tell me the file names, have it tell me the classes that I should look at.
00:30:53.960 | Um, and then kind of use that to try to build up a mental picture to make sure that I can do this and not vibe code, make sure I can still get like, uh, a good sense of what's happening.
00:31:03.960 | And then I go work on the feature with Claude.
00:31:05.960 | Uh, thank you so much.
00:31:06.960 | I'll be around and can Miller and answer other questions.
00:31:09.960 | Thank you.
00:31:10.960 | Thank you.
00:31:10.960 | Thank you.
00:31:11.960 | Thank you.
00:31:12.960 | Thank you.
00:31:13.960 | Thank you.
00:31:14.960 | - Thank you.
00:31:15.800 | Thank you.