Debug Information

Processing Details

• VTT File: 6591a42d.vtt
• Processing Time: September 11, 2025 at 01:32 PM
• Total Chunks: 2
• Transcript Length: 81,052 characters
• Caption Count: 579 captions

Prompts Used

Prompt 1: Context Setup

You are an expert data extractor tasked with analyzing a podcast transcript. 
I will provide you with part 1 of 2 from a podcast transcript. 
I will then ask you to extract different types of information from this content in subsequent messages. Please confirm you have received and understood the transcript content.

Transcript section:
[00:00:00.400 --> 00:00:04.400] Hey, it's Arvid, and this is the Bootstrap Founder.
[00:00:09.200 --> 00:00:14.800] Today, I'm talking to James Phoenix, an expert in agentic coding, particularly Claude Code.
[00:00:14.800 --> 00:00:20.080] That's a tool that I've been using for my own software projects to great effect over the last couple months.
[00:00:20.080 --> 00:00:22.720] And I talked a lot about this on this podcast.
[00:00:22.720 --> 00:00:29.600] I chatted with James just a couple of days ago and have implemented several of the tips that he gave me during this conversation.
[00:00:29.680 --> 00:00:36.800] I'm already almost twice as effective at using this already magically effective tool, which is very impressive.
[00:00:36.800 --> 00:00:45.520] So, I don't think I can overpromise how much insight into well-structured and highly optimized agentic coding you will get from this conversation.
[00:00:45.520 --> 00:00:52.000] A big shout out to the sponsor of today's episode, Paddle.com, my merchant of record payment provider of choice.
[00:00:52.000 --> 00:00:59.600] They're taking care of all the things related to money so that founders like me and you can focus on the things that only we can build, and Paddle handles the rest.
[00:00:59.600 --> 00:01:01.440] Sales tax, credit cards failing.
[00:01:01.440 --> 00:01:02.640] I don't want to deal with that.
[00:01:02.640 --> 00:01:03.600] I don't have to.
[00:01:03.600 --> 00:01:04.320] They do.
[00:01:04.320 --> 00:01:05.440] I highly recommend it.
[00:01:05.440 --> 00:01:07.920] So, please check out paddle.com.
[00:01:07.920 --> 00:01:12.080] And now, here's James.
[00:01:12.080 --> 00:01:14.560] James, welcome back to the podcast.
[00:01:14.560 --> 00:01:25.440] Last time we've been chatting about LLMs and prompting them, and today we will dive into one of the most powerful agentic coding tools out there, if not the most powerful at this point.
[00:01:25.440 --> 00:01:31.760] I use it every day, and you've become an expert at managing it and wrangling it and getting things out of it that you wanted to do.
[00:01:31.760 --> 00:01:36.320] Let's dive deep into building software without typing a line of code.
[00:01:36.320 --> 00:01:42.080] Do you know just how much you've actually used Claude Code in total so far?
[00:01:42.080 --> 00:01:44.880] Yeah, so I've been using Claude Code a lot.
[00:01:44.880 --> 00:01:54.480] I'm roughly spending around like maybe 3.4K if they were charging me in API costs, or around sort of 2.3 billion tokens per month.
[00:01:54.480 --> 00:02:02.360] Yeah, so I've been using it a lot in my workflow, even to the point actually where I have downgraded my cursor ultra plan.
[00:02:02.680 --> 00:02:13.240] So I had a $200 cursor ultra plan and a $200 core code plan, and I'm mainly using cursor now for fixing up work or where I need to slow down.
[00:02:13.400 --> 00:02:15.480] And most of the work has gone to core code.
[00:02:15.480 --> 00:02:18.600] So that one's keeping the big subscription for now.
[00:02:18.920 --> 00:02:23.080] There's so many layers to think about when you buy these tools, right?
[00:02:23.080 --> 00:02:24.920] There's the IDEs that come with them.
[00:02:24.920 --> 00:02:26.920] Then Cloud Code is kind of standalone.
[00:02:26.920 --> 00:02:29.720] You can run it in any IDE that it has an integration for.
[00:02:29.720 --> 00:02:32.600] Maybe even if it doesn't have an integration, you can still run it.
[00:02:32.600 --> 00:02:37.320] There's a lot of complexity to the cost of these tools at this point.
[00:02:37.320 --> 00:02:46.920] I do wonder with these tools, particularly Cursor, which is kind of VS Code on steroids with AI and can integrate into other tools into different models.
[00:02:46.920 --> 00:02:49.640] These tools haven't really been around for that long.
[00:02:49.640 --> 00:02:55.560] Do you see things like Cursor just fall off at some point and be replaced by something else?
[00:02:55.560 --> 00:02:59.240] Or should we expect Cursor to stick around in tools just like it?
[00:02:59.240 --> 00:03:04.360] I think the challenge that Cursor has is they aren't a model maker.
[00:03:04.360 --> 00:03:12.440] And so they explicitly have to make more profit margin on a consumer and they end up passing that cost to the consumer, right?
[00:03:12.440 --> 00:03:19.880] So Anthropic or Google, they have their own foundational models and therefore they don't have to make as much money.
[00:03:19.880 --> 00:03:25.400] I think Cursor has been building a little bit of a moat on their tab completion models.
[00:03:25.400 --> 00:03:28.920] So actually I found that their tab model is really, really good.
[00:03:29.240 --> 00:03:34.120] I can tell they're spending a lot of time specifically improving that.
[00:03:34.120 --> 00:03:37.320] They do still have kind of an edge on co-pilot.
[00:03:37.320 --> 00:03:39.400] I mean, I did look at Copilot recently.
[00:03:39.400 --> 00:03:43.800] You can do things like run agentic workloads against GitHub issues.
[00:03:43.800 --> 00:03:51.360] People still have, I would say, a preference over the curse agent mode over like GitHub Copilot agent.
[00:03:51.680 --> 00:03:55.680] But yeah, it's definitely like the gap is shortening.
[00:03:55.680 --> 00:04:06.320] And so, yeah, I think like cursor is not necessarily going to be in trouble, but they're just taking good specializing approaches like background agents and making their tab completion kind of best in class.
[00:04:06.320 --> 00:04:11.920] Well, when I think about tab completion, I'm trying to remember when I last used it, and that was not today.
[00:04:11.920 --> 00:04:14.240] Like, I was building a lot of stuff today.
[00:04:14.240 --> 00:04:22.800] I think I have built like two or three features in two projects today, yet I don't think I've written any line of code at any point during this.
[00:04:22.800 --> 00:04:27.840] It was just prompting and then taking or leaving what came back from it.
[00:04:27.840 --> 00:04:33.600] So, I do wonder if tab completion is ever going to play a role in my choice of IDE.
[00:04:33.600 --> 00:04:44.160] Yeah, I guess my point would be that if you need additional context on what you're doing, then those more kind of primitive AI features become more valuable, right?
[00:04:44.160 --> 00:04:49.200] So, like, if you're actually deep in the implementation of the code, then tab completion is really useful.
[00:04:49.200 --> 00:05:01.440] But obviously, if you're using something like Gemini CLI or Claude Code or Open Code, you know, whatever you're using as a kind of agentic coding tool, then tab completion isn't really a feature that you even think about anymore, right?
[00:05:01.440 --> 00:05:02.800] So, it depends.
[00:05:02.800 --> 00:05:15.360] I also think that there is kind of a hidden cost to using clawed code where you're essentially an engineering manager and you lose a lot of that contextual awareness about what's happening in each individual file.
[00:05:15.360 --> 00:05:25.360] And so, there is kind of that trade-off of, you know, if you're not actually writing the file, you do have a loss of context that you then have to re-aggregate as an engineering manager.
[00:05:25.360 --> 00:05:31.320] So, if you're an engineering manager and you've got three devs, you essentially farm out, you know, a bunch of tasks.
[00:05:29.840 --> 00:05:36.840] Each dev goes off, they work on that task in parallel, and then you get all this completed work back.
[00:05:36.920 --> 00:05:40.280] But as an engineering manager, you didn't write those files by hand.
[00:05:40.280 --> 00:05:46.520] So what you're finding is that you're having to find clever ways of recontextualizing on the code that just came out.
[00:05:46.520 --> 00:05:49.000] And obviously, PR review is one of those.
[00:05:49.000 --> 00:05:52.920] But I think the main thing I do is kind of you can do some quite clever things.
[00:05:52.920 --> 00:06:01.560] So you can ask like Claude Code to generate you a data flow of what it's implemented, for example, or a mermaid diagram.
[00:06:01.560 --> 00:06:03.400] So that can be quite a nice way.
[00:06:03.400 --> 00:06:05.240] I get it to create digest files.
[00:06:05.240 --> 00:06:06.360] So what have you done?
[00:06:06.360 --> 00:06:07.320] What are the changes?
[00:06:07.320 --> 00:06:09.320] What is the state of the data flow?
[00:06:09.320 --> 00:06:12.360] And then, yeah, you're basically trying to have to find a way around that.
[00:06:12.360 --> 00:06:16.360] But obviously, when you're using tab completion models, you're not necessarily having to do that.
[00:06:16.360 --> 00:06:17.800] You're fully in the zone.
[00:06:17.800 --> 00:06:20.680] You kind of know this is this interface, this is this function.
[00:06:20.680 --> 00:06:25.240] So there's a trade-off of either side, right, in terms of speed versus context loss.
[00:06:25.240 --> 00:06:30.040] That context loss, that to me is the source of all evil in using this.
[00:06:30.040 --> 00:06:34.760] And I mean this in a neutral way, even though it's not expressed like it, but that is the risk part, right?
[00:06:34.760 --> 00:06:36.760] That is where we risk skill atrophy.
[00:06:36.760 --> 00:06:43.880] That is where we risk introducing stuff into our code bases that we don't understand that might be just a time bomb to blow up later.
[00:06:43.880 --> 00:07:01.240] And I believe that a lot of founders who are using this to build their businesses or a lot of software engineers who are using agentic coding just to help them be more productive, they're introducing this without knowing it because they don't have the required skill set just yet to make this shift from coder to engineering manager.
[00:07:01.240 --> 00:07:06.280] They don't know yet that they are actually a manager and not a software developer anymore.
[00:07:06.280 --> 00:07:07.000] How can we do this?
[00:07:07.000 --> 00:07:09.560] How can we make this easier for people to understand?
[00:07:09.560 --> 00:07:16.080] Yeah, I think the main point here is you have to be very careful about committing code that's come from clawed code.
[00:07:16.400 --> 00:07:41.200] And it's actually easier to spin up a separate Git work tree on a separate branch, have it have a go at a feature or something, and then review the code and throw it away than it is to merge in poor quality code and then have to figure out in the code base about 10 or 20 or 30 or 40 commits later where that poor quality code is.
[00:07:41.200 --> 00:07:49.440] So actually, the main thing that you have to wrap your head around is that actually adding code is both dangerous and not dangerous.
[00:07:49.440 --> 00:07:51.120] And I'll explain what I mean by that.
[00:07:51.120 --> 00:08:07.920] So if you're doing an additive feature, so if you create a new feature and it doesn't necessarily touch anything, if you do that in a Git work tree, or even if you do that in the main branch, if it's purely an additive operation, then you can simply delete the code, right?
[00:08:07.920 --> 00:08:26.720] Where it becomes more dangerous is if you have a service and you mutate and you update existing dependencies or existing files, or if you have something that is now dependent on something and you've changed that, anytime you've got that kind of situation, that is where the danger strikes of committing code without testing it.
[00:08:26.720 --> 00:08:34.160] So mutative code or modificative code is actually more dangerous than additive code.
[00:08:34.160 --> 00:08:39.760] So this idea that if you add it, you just have something that if you add it, it's not necessarily a problem because you can throw it away.
[00:08:39.760 --> 00:08:41.360] It doesn't affect other services.
[00:08:41.360 --> 00:08:46.640] Whenever you're updating existing infrastructure or service layers, that's the dangerous point.
[00:08:46.640 --> 00:09:01.320] And then the second point is actually, it's much cheaper to go through each individual file diff and see if it's making mistakes and push back on clawed code at that point in the conversation history because you've already got that conversation history to hand.
[00:09:01.320 --> 00:09:06.760] Otherwise, what's going to happen is you'll realize there's a bunch of changes that you should have actually pushed back on.
[00:09:06.760 --> 00:09:12.600] You'll be searching for that session ID in all of your clawed codes because claw code is ephemeral, right?
[00:09:12.600 --> 00:09:20.840] In the sense of unless you have that specific session ID, you're now having to pay per trail and go work your way up in user a clawed dash dash through a zoom.
[00:09:20.840 --> 00:09:27.800] You'll get all the session histories and you're trying to find that specific one which actually was associated with that chunk of work.
[00:09:27.800 --> 00:09:36.040] So pushing back on the chunk of work at that point in time is actually easiest because you don't have to keep a handle as to where that specific session is.
[00:09:36.040 --> 00:09:38.280] You're just dealing with that problem in the here and now.
[00:09:38.600 --> 00:09:47.560] And the other thing I will say on that is that every time you're pushing back on clawed code is an opportunity for you to learn something.
[00:09:47.560 --> 00:09:49.320] And it's a couple of different things.
[00:09:49.320 --> 00:09:53.000] So mainly it's you didn't prompt it well enough.
[00:09:53.160 --> 00:09:54.680] It didn't have the right context.
[00:09:54.680 --> 00:09:58.680] That's one potential area for it to have gone wrong.
[00:09:58.680 --> 00:10:08.280] The other area that is interesting is you might have specifically given it all the right context, but it didn't have any rules or any patterns to follow.
[00:10:08.280 --> 00:10:18.840] So if you're working on a greenfield problem, you might find that actually, if it hasn't got any patterns, it will do several things in different ways and it doesn't have a standardized way of working.
[00:10:18.840 --> 00:10:21.640] Or it's a rules problem, so it just didn't have any rules to follow.
[00:10:21.640 --> 00:10:25.640] So generally, it's a prompting problem or a context problem or a rules problem.
[00:10:25.640 --> 00:10:28.760] And also, it can be a testing or a verification problem.
[00:10:28.760 --> 00:10:33.400] So it's one of those things that generally goes wrong when you're using Claude Code.
[00:10:33.400 --> 00:10:35.480] You know, those are the things to kind of look at.
[00:10:35.480 --> 00:10:37.640] So, how do you define these patterns?
[00:10:37.640 --> 00:10:46.320] Particularly for a Greenfield Project, I think it's Claude is capable of extracting patterns from existing code bases and codifying them into something that it understands.
[00:10:46.320 --> 00:10:47.280] At least I've heard.
[00:10:44.840 --> 00:10:48.320] If not, tell me.
[00:10:48.640 --> 00:10:51.120] But how do you deal with this when you want to build something new?
[00:10:51.120 --> 00:10:57.920] Do you already have to be able to completely formulate this almost like a waterfall design document?
[00:10:57.920 --> 00:11:02.720] Or do you have a couple of starting points that you then elaborate on over time?
[00:11:02.720 --> 00:11:04.240] Like, how do you approach this?
[00:11:04.240 --> 00:11:28.080] Yeah, I think the main thing that I've learned is it's easier to update one file and come up with a global kind of pattern for some type of layer than it is to roll out 10 or 30 files in an API and then realize that you want to add JS stock or you want to add types or you want to add a certain type of dependency or middleware.
[00:11:28.080 --> 00:11:41.280] So I think the main point of learning this is that you're better off actually in some weird way spending half an hour or an hour or an hour and a half in cursor and iterating on specifically what that pattern is.
[00:11:41.280 --> 00:11:49.840] And then once you've got the pattern nailed and it has a pattern to follow, then you can roll that pattern out across a bunch of different Postgres tables.
[00:11:49.840 --> 00:11:51.840] And I found that works really well.
[00:11:51.840 --> 00:11:53.280] That's one way of doing it.
[00:11:53.280 --> 00:12:00.240] The other way of doing it is to come up with a rules file and to say, when you're making this type of pattern, you should do this.
[00:12:00.240 --> 00:12:06.000] I don't find that works as well though, because it doesn't have code to mirror the pattern off of.
[00:12:06.000 --> 00:12:13.600] And also, like Claude Code, like a lot of agentic tool calls, specifically for file reading to see what it kind of looks like to begin with.
[00:12:13.600 --> 00:12:18.000] So I think, yeah, building up a couple of examples is like the best way to kind of go.
[00:12:18.000 --> 00:12:18.960] That's interesting.
[00:12:18.960 --> 00:12:37.400] I've never thought about it like this because I always thought, okay, Greenfield Project might as well let Claude do all the work, but by you spending some time to actually explore what you want it to look like, even just prototypical, what you're saying sounds to me like you are giving very clear evidence of what you want, and Claude will from there infer what the rest of it should look like.
[00:12:37.400 --> 00:12:40.760] Yeah, and I think cursor works very well like this as well.
[00:12:40.760 --> 00:12:44.920] If you're doing Greenfield, you'll basically with any kind of LLM, you'll run into the same issue.
[00:12:44.920 --> 00:12:46.680] It's not even just a clawed code thing.
[00:12:46.680 --> 00:12:52.520] It's just LLMs are really good at generating tokens, but they lack real strategic sense.
[00:12:52.520 --> 00:13:05.880] And like that's an example of something that I'm seeing on my personal project, which is it will define lots of constants that exist, and those constants will be repeated in different Zob models in lots of different files.
[00:13:05.880 --> 00:13:17.640] And so what I've noticed is these models are incredibly good at working in very hyper-localized context, but they're very bad at thinking about strategic context.
[00:13:17.640 --> 00:13:28.840] So for example, if you're doing social media platforms, you'll have some constants or an enum for Facebook or Meta or X or LinkedIn and YouTube and what have you.
[00:13:28.840 --> 00:13:37.000] But those constants, if you leave it unchecked, clawed code will just go and put that in every interface, in every Zod model of every file.
[00:13:37.000 --> 00:13:38.840] And that's what I'm finding right now in my project.
[00:13:38.840 --> 00:13:51.960] And I'm like, it's really interesting how clawed code is really good, but actually, if I'd have just started by upfront saying we always use these constants, then it wouldn't have had any additional patterns to match against.
[00:13:51.960 --> 00:13:56.280] Even still, even if you do that, there will still be some that slip through the cracks.
[00:13:56.280 --> 00:14:01.800] You just can't, you can't always expect to have all of the right contexts in every single prompt.
[00:14:01.800 --> 00:14:03.320] It's just unrealistic.
[00:14:03.320 --> 00:14:13.480] And so that's kind of where you need that QA step where you're specifically looking at different types of things that are wrong with the file changes or the file creates that have happened, basically.
[00:14:13.480 --> 00:14:17.280] Yeah, I mean, we had refactoring and rewriting stuff before we had Cloud Code.
[00:14:17.280 --> 00:14:19.040] So people made mistakes as well, right?
[00:14:19.040 --> 00:14:22.800] Or implemented things in ways that turn out to not be the optimal way.
[00:14:22.800 --> 00:14:29.360] I do wonder, though, because Cloud Code has plan mode and it has the capacity to not immediately act, right?
[00:14:29.360 --> 00:14:32.080] Not to immediately change things, but to think about it.
[00:14:32.080 --> 00:14:41.200] Would it make sense to have this kind of refactoring step every now and then just to let it check the code base for repetition?
[00:14:41.200 --> 00:14:57.120] Yeah, so I think what you're talking about is, and I'm going to expand this to be a bit more of a philosophy rather than just that specific task, is there's kind of some tasks that you don't want clawed code to do all the time, but you want it to do kind of infrequently, like a one-off task.
[00:14:57.120 --> 00:15:12.400] And so what you're describing as looking for redundancy or duplicated code or a lack of specific global constants or types is a dev task, which means that constants or enums become centralized.
[00:15:12.400 --> 00:15:17.680] And that is the kind of thing that you should probably have like on a weekly cron schedule.
[00:15:17.680 --> 00:15:25.040] And you should have it as like a command that you can run inside of clawed code, but it's not necessarily something I would make a sub-agent for.
[00:15:25.120 --> 00:15:26.560] It's like a one-off command.
[00:15:26.560 --> 00:15:31.920] I could run it like, I don't know, once a week, or I could run it on a cron on like a GitHub action.
[00:15:31.920 --> 00:15:38.160] And I can specifically look for errors in the code base kind of systematically, but it's not something I'm going to run every day.
[00:15:38.160 --> 00:15:40.960] And it will also pick up a lot of false positives.
[00:15:40.960 --> 00:15:44.640] So that is a good example of something you should put into a clawed code command.
[00:15:44.640 --> 00:15:50.960] But I never defined any commands, really, for the reason that I didn't even know that you could do that at this point.
[00:15:50.960 --> 00:15:55.840] So it sounds like you have things that are just conversational where you just go through and build some kind of feature.
[00:15:55.840 --> 00:16:02.120] And then there are things that are so repeatable that they warrant having this kind of encapsulated command.
[00:15:59.680 --> 00:16:02.200] Yeah.
[00:16:02.360 --> 00:16:09.640] And like basically anytime you're doing something, not all the time, but kind of, I don't know, every day or every week.
[00:16:09.640 --> 00:16:12.680] would be something you could put into a command.
[00:16:12.680 --> 00:16:23.000] So a good example will be I have a command called update docs.md and it tells it basically I want you to review all the docs in our architecture.
[00:16:23.000 --> 00:16:25.480] I want you to look at all the package implementations.
[00:16:25.480 --> 00:16:30.200] I want you to verify a bunch of API routes that match the documentations.
[00:16:30.200 --> 00:16:36.680] And then it basically says go and look at all the different features and update a doc slash architecture.md, for example.
[00:16:36.680 --> 00:16:41.480] So keeping the docs fresh just from a Claude Code command is like an example.
[00:16:41.480 --> 00:16:47.000] Another one would be like, I'm using a system prompt override in Claude Code.
[00:16:47.000 --> 00:16:53.960] So I'm specifically telling it to kind of take on a role and I don't want it to have to keep telling it to take on this role.
[00:16:53.960 --> 00:17:03.160] So that's something I use a lot more frequently where I'd have like a slash confirm augster and it just tells it, I want you to confirm that you're this role and you're the best software engineer in the world.
[00:17:03.480 --> 00:17:07.080] And the reason why is that Claude, they've obviously got a system prompt.
[00:17:07.080 --> 00:17:10.360] You know, you are a developer, you do this, you do that, right?
[00:17:10.360 --> 00:17:13.080] That comes injected into the system prompt.
[00:17:13.080 --> 00:17:18.440] And so what I've actually found works really well is to override the system prompt.
[00:17:18.440 --> 00:17:22.680] And there's a system prompt that you can have that was made by augment code.
[00:17:22.680 --> 00:17:30.600] And there's this kind of like, it's kind of XML based, but it basically sets up Claude Code to generate a lot more to-do tasks.
[00:17:30.600 --> 00:17:37.960] And I found that the painful points of using clawed code is that it either stops early or it doesn't run tests.
[00:17:37.960 --> 00:17:54.320] And basically, yeah, this kind of like system prompt override basically says you must have a plan or a mission, you must enter an operational loop, you must do the work, verify that the work is done, only go out of the operational loop when the work has been verified.
[00:17:54.320 --> 00:18:00.160] And so basically, it will do things like it will plan, it will implement, it will run tests, and it will verify tests.
[00:18:00.160 --> 00:18:03.120] And so that kind of operational loop is really useful.
[00:18:03.120 --> 00:18:11.520] But obviously, using that is really quite, you know, a bit boring to say, I want you to take on this role and use what's in my clawed.md and assume this role.
[00:18:11.520 --> 00:18:17.520] So that is another example of a slash command that I use like every hour to just save myself some manual typing.
[00:18:17.520 --> 00:18:20.240] So that cannot be reliably auto-injected.
[00:18:20.240 --> 00:18:22.800] You kind of have to do it manually through the command?
[00:18:22.800 --> 00:18:29.360] You can use clawed code hooks to do auto-injection, but it depends on like where those hooks land.
[00:18:29.360 --> 00:18:32.160] I personally haven't explored that route.
[00:18:32.160 --> 00:18:38.080] I, yeah, I mean, I mainly use clawed code hooks for custom linting and type checking.
[00:18:38.080 --> 00:18:39.920] So there are clawed code hooks.
[00:18:39.920 --> 00:18:46.480] And if I just have a brief look right now, they are like Anthropic are always releasing new types of hooks.
[00:18:46.480 --> 00:18:50.560] So there's like a pre-tool use hook, a post-tool use hook.
[00:18:50.560 --> 00:18:52.480] You've got a user submit prompt.
[00:18:52.480 --> 00:18:55.600] So whenever a user submits a prompt, you can do that.
[00:18:55.600 --> 00:18:56.880] Or a session start.
[00:18:56.880 --> 00:19:00.000] So you could technically inject something into a session start.
[00:19:00.000 --> 00:19:02.240] But I don't like to do it all the time.
[00:19:02.240 --> 00:19:09.280] So it's one of these things where, you know, you've got to be like careful about using hooks, but they are also very, very powerful.
[00:19:09.440 --> 00:19:14.880] Good use of hooks, I think, is like running custom TypeScript checking, unless you're using the IDE.
[00:19:14.880 --> 00:19:20.080] So you can specifically feed TypeScript errors on file modifications, seems to be quite nice.
[00:19:20.080 --> 00:19:33.400] So, as it writes files, it will run those specific files through TypeScript's compile checker, and then it will give those errors back to clawed code so that as it saves the file, it now knows the type errors that it generates.
[00:19:29.760 --> 00:19:38.280] And that's quite useful as a kind of step in the middle before type checking at the end.
[00:19:38.280 --> 00:19:42.760] So, it's kind of aware of the type issues that it's creating as it makes them.
[00:19:42.760 --> 00:19:47.160] That to me is one of the coolest features about agentic coding to begin with.
[00:19:47.160 --> 00:19:52.680] This kind of self-evaluation that happens in between the things that happen, like in between the to-dos.
[00:19:52.680 --> 00:20:09.160] I'm working a lot with Laravel and with Vue.js, no TypeScript, raw JavaScript, like the people in the 90s, and just seeing it building stuff and linting stuff and checking stuff, seeing errors come back, and it fixing those errors in the loop without me having to do anything.
[00:20:09.160 --> 00:20:19.800] That to me is the true magic of Agentic coding because everybody could come up with a system or lots of LLMs could just come up with a system that gives you the output and then you fix it yourself.
[00:20:19.800 --> 00:20:22.360] I used to use Claude just like this for the longest time.
[00:20:22.360 --> 00:20:23.640] I had it in the web.
[00:20:23.640 --> 00:20:33.880] I had the web clawed, pasted code in there, had it create new code, copied it, and pasted it back into my IDE because apparently I live in the Stone Ages.
[00:20:33.880 --> 00:20:36.040] So, that was how I did it.
[00:20:36.040 --> 00:20:40.680] And then errors happened, I pasted the error back, and you know, like that loop I had to do manually.
[00:20:40.680 --> 00:20:43.080] But the Agentic system does it all by itself.
[00:20:43.080 --> 00:20:45.560] We just kind of have to encourage it to do it right.
[00:20:45.560 --> 00:20:55.960] Yeah, I think we've sort of gone all the way from Eclipse or IntelliJ slash VS Code to co-pilot with tab to co-pilot with chat and cursor with chat.
[00:20:55.960 --> 00:20:58.520] And then we've gone from chat to agent.
[00:20:58.520 --> 00:21:11.240] And then we've now gone from agent in cursor or to essentially like on the CLI with kind of ambient agents where it runs for a larger extended period of time on a slightly larger task.
[00:21:11.240 --> 00:21:16.960] And yeah, it's quite powerful, the fact that it can self-correct its trajectory.
[00:21:17.280 --> 00:21:24.800] It's also quite dangerous because it will think sometimes that it's going in the right direction and actually it's taking side steps.
[00:21:24.800 --> 00:21:28.240] It can, for example, change the implementation to make the test work, right?
[00:21:28.240 --> 00:21:29.040] Which is terrible.
[00:21:29.040 --> 00:21:38.000] Or it can start importing a package in a specific way where you would want to have imported it in another way or from another different type of module.
[00:21:38.000 --> 00:21:39.840] So it's not without its own errors.
[00:21:39.840 --> 00:21:47.200] And what I think is the key point is kind of keeping on tabs of what's happening in the file system changes is really important.
[00:21:47.200 --> 00:21:52.960] And you can stop a clawed code terminal session and just tell it, no, actually, we should do this.
[00:21:52.960 --> 00:22:01.040] And then I think this leads quite well into like what you were asking about earlier in terms of how do you embed rules inside clawed.
[00:22:01.040 --> 00:22:04.400] And so there's this idea of like the clawed.md file.
[00:22:04.400 --> 00:22:16.240] And inside of a clawed.md file, you can put kind of anything in terms of like how it should write code or what kind of patterns it should follow or how it should react when certain conditions are met.
[00:22:16.240 --> 00:22:30.560] I've found that if you put too many rules in your root directory, clawed.md, you'll essentially get context rot, which is basically this principle that the more input tokens you have, you get an increased amount of degradation of performance.
[00:22:30.560 --> 00:22:47.120] So what you want to do is when you kind of experience this error where you've got three terminals open, you see that it's done something you haven't wanted it to do, you should specifically say to Claude, I want you to add this to a localized clawed.md folder or file.
[00:22:47.120 --> 00:22:52.640] So basically, say, put it in a localized folder and have a claw.md.
[00:22:52.640 --> 00:23:02.840] And the kind of rules that or philosophy that you should follow is: if this truly affects the entire system, it should live in the root claude.md file as a rule.
[00:23:02.840 --> 00:23:14.600] But if it only affects, for example, the API layer or a scheduler layer or a, I don't know, a domain package or a core services package, it should live specifically in that rules file.
[00:23:14.600 --> 00:23:28.200] And then you get the benefit of additional rules at appropriate layers of the application without having increased context rot and bad degradation of performance by sticking everything in the root directory.
[00:23:28.200 --> 00:23:38.520] And what you're basically ending up with is a kind of hierarchical knowledge-based system of a series of clawed.md files that are embedded at sub-layers of your application.
[00:23:38.520 --> 00:23:48.840] And whenever claude will make changes in those areas, it will recursively bubble up those clawed.md files into a single kind of rule set.
[00:23:48.840 --> 00:23:55.000] And so if you have things that affect all of the packages, that will be under packages/slash/claude.md.
[00:23:55.000 --> 00:24:01.400] But you might have package A that has specific bits of knowledge that only package A is concerned with.
[00:24:01.400 --> 00:24:09.480] And you can ask Claude to sort of tidy up your knowledge base and say, everything's in the root directory, claude.md file.
[00:24:09.480 --> 00:24:10.360] Help me out.
[00:24:10.360 --> 00:24:18.120] Take what you know about my directory, do kind of an investigative research and figure out where all the rules should live.
[00:24:18.120 --> 00:24:21.800] And then it can split it up into little subsections of clawed.md files.
[00:24:21.800 --> 00:24:32.520] And that will massively help you in terms of when you're starting a new session with Claude, you're not going to get as much context rot and you'll get increased performance because you're simply putting less into the context.
[00:24:32.520 --> 00:24:37.640] And so I think that's been like the one learning which I did and implemented about two weeks ago.
[00:24:37.640 --> 00:24:42.280] And I'm already getting a lot better results, even though I think they've personally quantized the model.
[00:24:42.280 --> 00:24:45.440] And I think June was pretty much like the holy grail.
[00:24:45.440 --> 00:24:53.680] And I think there have been some slight degradations of performance because of how many people have been abusing kind of the core Pro Max subscription.
[00:24:53.680 --> 00:25:02.560] So I personally think that Dune was kind of the Hail Mary, but I think we'll get back to that point when model performance gets cheaper and they don't have to quantize.
[00:25:02.560 --> 00:25:10.240] And I totally get why they're probably potentially quantizing because it's really expensive to run so many versions of Sonnet.
[00:25:10.240 --> 00:25:14.080] But yeah, hierarchical rule-based system is kind of what you're looking for.
[00:25:14.080 --> 00:25:19.520] You can even use Claude to kind of break up your claw.md file into subfiles as well.
[00:25:19.520 --> 00:25:20.400] That is amazing.
[00:25:20.400 --> 00:25:28.640] I mean, the clawed MD file, I get that as like a central repository of these insights, but having one on a local level, that's subsidiarity, right?
[00:25:28.640 --> 00:25:34.240] That's the idea of like putting stuff where it actually is needed and not just on the root level of anything.
[00:25:34.240 --> 00:25:36.560] That's a governance system.
[00:25:36.560 --> 00:25:36.880] Yeah.
[00:25:36.880 --> 00:25:42.160] The other thing I was going to say with this is I actually don't use like app references that much.
[00:25:42.160 --> 00:25:44.560] And I essentially like to use a pointer-based system.
[00:25:44.560 --> 00:25:52.880] So I tell Claude in claw.md files, if you want to learn about this, you can go and look at this specific file at this specific file path.
[00:25:52.880 --> 00:25:56.960] And then it doesn't pull it into the whole context for that claude.md.
[00:25:56.960 --> 00:26:03.920] It can do a tool call to read that specific file in, gather up that context, because claude is really good at doing tool calling.
[00:26:03.920 --> 00:26:18.480] And so that's like another thing that you can kind of use as a way to avoid bloating specific claw.mds with app file context, just using pointer references to be like, these three files or these four files are like how you should implement this pattern.
[00:26:18.480 --> 00:26:22.960] Here's a quick example, but if you want a more granular example, go and read this file.
[00:26:22.960 --> 00:26:31.480] And you're just giving it pointer references so it knows how to do the tool calls, but not necessarily stuffing all of the examples into that specific piece of context.
[00:26:31.480 --> 00:26:34.680] This sounds amazing and it sounds like a lot of work.
[00:26:34.680 --> 00:26:35.960] It's so much work.
[00:26:36.120 --> 00:26:41.080] I wonder, are we ever going to see like almost, of course, all of this is kind of recursive in a way.
[00:26:41.080 --> 00:26:43.240] Is there going to be an agentic way of doing this?
[00:26:43.240 --> 00:26:43.480] Right?
[00:26:43.480 --> 00:26:46.440] Will we be able to extract this to the right level?
[00:26:46.440 --> 00:26:54.440] So I think this goes on to the point of like, if you're building greenfield projects, then you kind of have to curate and maintain this.
[00:26:54.440 --> 00:27:14.760] And you get to a certain point in the project where, like, if I spin up like a fresh package inside of my monorepo architecture, it knows I'm using bun, it sets up like unit tests, integration tests, like it creates all the right commands, it adds an ESLink config, it adds TypeScript config, like it knows what to do now, right?
[00:27:14.760 --> 00:27:21.240] But like, if you're starting a greenfield project, then there's a lot of work in figuring out the right project structure.
[00:27:21.240 --> 00:27:37.320] And so actually, the agentic way of, if I have an existing project of specifically finding all of the different types of contextualized knowledge, the code already contains those patterns, and you're basically just reversing back out those patterns into kind of a rules.md file.
[00:27:37.320 --> 00:27:38.840] So you've already got the patterns.
[00:27:38.840 --> 00:27:45.800] Now, having said that, you might go onto a really crappy project and they don't have patterns, which is also really bad.
[00:27:45.800 --> 00:27:52.040] So that gets on to this point that you should always have ideally one, but maybe two ways of doing something.
[00:27:52.040 --> 00:27:57.560] And that the more ways you have of doing something, the more confusing it is to an LM or a human developer.
[00:27:57.560 --> 00:28:12.440] And so basically, if you can have a reduced number of service layers, ideally, strong typing across the application, and also one way of doing things, then that massively simplifies how new things are going to come out of the box.
[00:28:12.440 --> 00:28:16.400] And the fourth thing would be like, how easy is it to set up the dev environment?
[00:28:16.720 --> 00:28:30.080] So having kind of custom shell scripts that fire off work trees or copy environment variable files or boot up various parts of the application is also a lift for clawed code because then it knows how to create a work tree.
[00:28:30.080 --> 00:28:31.920] It just runs a shell script.
[00:28:31.920 --> 00:28:39.680] So all these kind of like mini pieces of infrastructure that allow you to like onboard a dev faster actually also work really well for clawed code.
[00:28:39.680 --> 00:28:54.080] So those are kind of like the main things that I've also found to be really useful is kind of like custom shell scripts for it to like copy all the environment variables into a fresh Git work tree because those don't get copied across because they get ignored by default.
[00:28:54.080 --> 00:29:01.040] And there are people building like there's like a really good application desktop app called Conductor that's been going around on X.
[00:29:01.040 --> 00:29:05.920] But I honestly think you should probably just write your own shell scripts and kind of own that part of the infrastructure.
[00:29:05.920 --> 00:29:11.040] They do have like a custom shell script right on workspace setup, which is really cool.
[00:29:11.040 --> 00:29:19.440] I just find that like for me, it took a lot of clawed code like going backwards and forwards of debugging exactly what that work tree setup should look like.
[00:29:19.440 --> 00:29:23.920] And therefore like it's useful to be able to just try it out and see what clawed code comes back with.
[00:29:23.920 --> 00:29:27.040] The work tree thing is still mesmerizing to me because I haven't tried it.
[00:29:27.040 --> 00:29:28.160] I work on main.
[00:29:28.160 --> 00:29:30.400] Again, that's Stone Age for me.
[00:29:30.400 --> 00:29:37.920] And the idea of having Claude run on the same code base in different work trees, that sounds like a lot of chaos.
[00:29:37.920 --> 00:29:39.280] How do you handle this?
[00:29:39.280 --> 00:29:53.120] Yeah, so actually the main thing I would suggest is there are some types of tasks that are very easy to do, and you can parallelize these not necessarily just on a Git work tree, but on main.
[00:29:53.120 --> 00:30:04.040] So, if you have five tasks, for example, that you know won't have much surface area of covering each other, you're fine to YOLO that on main or staging as a parallelizable thing.
[00:29:59.600 --> 00:30:21.000] Where it gets quite difficult is where you're trying to modify the database or modify service layers that are going to break parts of the application, or if you want to run lots of different tests, that can be quite difficult to parallelize.
[00:30:21.000 --> 00:30:25.800] And that's the same if you're on kind of a main branch or a Git work tree.
[00:30:25.800 --> 00:30:35.480] I personally find Git work trees are good for risky types of work where you'll want to explore a new feature or you want to do a major refactor.
[00:30:35.480 --> 00:30:38.200] These are good points for a Git work tree.
[00:30:38.200 --> 00:30:51.400] If you're doing parallelizing of work and you have testing infrastructure that requires it to be parallelizable, that is a pain point you will face on both a Git work tree and also on your traditional branches, right?
[00:30:51.400 --> 00:30:53.240] Like a main and staging and dev.
[00:30:53.240 --> 00:31:02.200] And so, the kind of advice I would say is be very careful about how granular you want your isolation to be in a testing environment.
[00:31:02.200 --> 00:31:09.400] Because I personally have just spent two and a half months of getting that working with Superbase, and it was really painful.
[00:31:09.400 --> 00:31:22.760] But the architecture I have now is because I have a monorepo structure and every bun test will run using Turbo Repo, all of those tests technically run in parallel and they don't wait for each other.
[00:31:22.760 --> 00:31:24.760] So, it might be slightly different in PHP.
[00:31:24.760 --> 00:31:28.200] You've probably got a single process that runs your tests.
[00:31:28.200 --> 00:31:36.680] Now, if you have multiple processes that run your tests, you end up with potentially data races of integration data races.
[00:31:36.680 --> 00:31:41.240] And so, the best thing you can do is two things, and this will completely solve it.
[00:31:41.240 --> 00:31:48.720] But it's quite challenging: is you basically have no seed data in your.sql, no seed data.
[00:31:48.720 --> 00:31:52.320] So, seed data becomes completely dynamic at runtime.
[00:31:52.320 --> 00:32:01.280] So, rather than trying to build up manual brittle bits of seed data, every test runner creates idempotent, just factory test data.
[00:32:01.280 --> 00:32:04.720] Basically, you have a layer for creating factory functions.
[00:32:04.720 --> 00:32:05.680] That's the first thing.
[00:32:05.680 --> 00:32:16.000] So, factory functions with these dynamic kind of building up of seed data becomes way better for parallelization of testing and also, yeah, just general testing.
[00:32:16.000 --> 00:32:23.520] The second thing, alongside that, is you also can use, if you're using for something like Superbase, you're limited to one database.
[00:32:23.520 --> 00:32:37.680] So, when you create a user, you'll prefix them with a branch name, and you will also do things like you'll create a custom Postgres schema that will specifically allow you to run that specific test on a custom Postgres schema that then gets cleaned up after that test run.
[00:32:37.680 --> 00:32:45.120] So, factory functions and idempotency on both your users or your database is kind of the main way to do it.
[00:32:45.120 --> 00:32:52.160] If you get that kind of set up, you can basically parallelize on main as long as you don't get file changes happening across the same files.
[00:32:52.160 --> 00:33:01.280] And that is kind of like a kind of God kind of architecture for testing: you could technically have three individual agents, they could be running on main or they could be running on a Git work tree.
[00:33:01.280 --> 00:33:16.320] They can essentially run the test suite, and because the test suite isn't using brittle seed data in SQL files, it will just be dynamically creating and inserting rows in different tables, which have completely different IDs and also be testing on a different database.
[00:33:16.320 --> 00:33:19.920] And therefore, you get true kind of database isolation of testing.
[00:33:19.920 --> 00:33:22.240] And that's kind of what they have at Fang, if that makes sense.
[00:33:22.240 --> 00:33:26.560] They have this kind of testing infrastructure that kind of supports that.
[00:33:26.560 --> 00:33:27.680] That is amazing.
[00:33:27.680 --> 00:33:36.040] Because even if you weren't to use Agent encoding at all, that would still be beneficial just for testing in general because parallelized tests run faster, right?
[00:33:36.040 --> 00:33:40.120] That generally makes it easier for you to actually check and then keep working.
[00:33:40.120 --> 00:33:41.640] And PHP has that too.
[00:33:41.640 --> 00:33:48.520] Like PHP has parallelized or can have parallelized test runners, which makes these changes necessary.
[00:33:48.520 --> 00:33:55.480] Because again, yeah, you don't want to have a database that for some race condition works in one test and doesn't work in the other, right?
[00:33:55.480 --> 00:33:56.920] That's definitely something.
[00:33:56.920 --> 00:34:00.680] So even if you don't do any agentic coding, this is a good idea to do for your testing.
[00:34:00.680 --> 00:34:01.720] You should also be testing.
[00:34:01.720 --> 00:34:02.840] Maybe that's another thing.
[00:34:02.840 --> 00:34:07.880] Honestly, I've been a software engineer for 20-some years at this point.
[00:34:07.880 --> 00:34:12.760] I just started really testing because of agentic coding.
[00:34:12.760 --> 00:34:18.040] That was my intro into writing tests: I don't want to have to figure out how to write tests.
[00:34:18.040 --> 00:34:19.160] You do it for me.
[00:34:19.160 --> 00:34:21.160] I just figure out if they are correct.
[00:34:21.160 --> 00:34:32.600] Yeah, so I think the main thing that you've probably started experiencing is your projects getting so large that you can't specifically know whether everything is working or not.
[00:34:32.600 --> 00:34:39.720] And also, what I think is kind of interesting is that core code is increasing the ambition of software engineers.
[00:34:39.720 --> 00:34:46.120] And as they increase the ambition of software engineers, naturally what's going to happen is you get more lines of code.
[00:34:46.120 --> 00:34:50.840] And because of that, testing becomes a way for you not to just function, but to breathe.
[00:34:50.840 --> 00:34:56.440] You actually need some tests some point to specifically know whether things are working or not.
[00:34:56.440 --> 00:35:09.880] Now, another point, and I'm just going to throw this in there: is if you have a failing test suite, right now, just drop the podcast and basically get that working and go and make that CI and then come back to the podcast and listen for the rest of this.
[00:35:09.880 --> 00:35:12.360] You need a green CI, okay?
[00:35:12.360 --> 00:35:20.720] Because if you don't have a green CI, how are you going to know when Claude Code runs those tests whether it was the changes to those specific files that caused something else to go red?
[00:35:21.040 --> 00:35:31.600] So if you have technical debt in your testing layer or Claude made too many files and too many tests and some of them are failing, just skip them for now and get it working, get it green.
[00:35:31.600 --> 00:35:33.840] And you have to build from a green CI.
[00:35:33.840 --> 00:35:42.320] And this is something I've personally had a problem with: I have probably 800 tests or a thousand tests, and I have probably 150 that were failing.
[00:35:42.320 --> 00:35:50.640] And at that point, I was like, I need to get back to just a green CI because it helps Claude Code with a lot less errors when it's running tests.
[00:35:50.640 --> 00:36:00.960] Also, the other thing you should do is you should tell Claude Code to run specific types of tests and specific types of folders to avoid it getting too much context of the entire test running suite.
[00:36:00.960 --> 00:36:04.160] So if it's working on this bit, only run these tests.
[00:36:04.160 --> 00:36:11.440] Don't run the entire suite of tests because it's going to fill it out with so much additional context that's going to lead to context rots.
[00:36:11.440 --> 00:36:17.120] So this idea of if you change this area of the code base, write and run those tests first.
[00:36:17.120 --> 00:36:19.120] And then after that, go run the whole test suite.
[00:36:19.120 --> 00:36:22.320] Don't run the whole test suite over and over again, if that makes sense.
[00:36:22.320 --> 00:36:23.360] Yeah, because there's a lot.
[00:36:23.360 --> 00:36:29.600] Like if you have a lot of tests, then there is a time effort invested in just keeping it running, which slows down the agent.
[00:36:29.600 --> 00:36:32.000] And you said it, you fills up the context.
[00:36:32.000 --> 00:36:39.680] That is, I think, a very, very important thing to have because honestly, those tests to me are also a defense against fraud code.
[00:36:39.680 --> 00:36:47.600] They defend some part of the code base that even you might not even remember is there be changed by this for some reason, right?
[00:36:47.760 --> 00:36:58.960] Claude might introduce because it's interested in creating a new cache object in Redis somewhere, introduces a new name, one that it thinks is new, but it's already in there used by a different part of your code base.
[00:36:58.960 --> 00:37:01.720] And all of a sudden, now that part doesn't work anymore.
[00:37:01.720 --> 00:37:05.400] If you don't have a test for it, you will never know until it explodes in production.
[00:37:05.400 --> 00:37:13.000] So that is the defense against the creativity of cloud code or any agentic system is having tests in place, which is why I'm doing it.
[00:37:13.000 --> 00:37:14.680] Because otherwise, I would be like, ah, whatever.
[00:37:14.680 --> 00:37:21.160] I test in production like any other indie hacker, but I can't afford this anymore because I'm not coding it anymore.
[00:37:21.160 --> 00:37:31.720] Yeah, I think the main thing I've also realized is like there's different layers of tests, and the different layers of tests are useful and not useful in different ways.
[00:37:31.720 --> 00:37:36.600] So let me just spend two minutes describing all the different layers of testing.
[00:37:36.600 --> 00:37:45.480] So you have unit testing, which is your kind of I have a function and I test some arguments of that function against some expected return values or types.
[00:37:45.480 --> 00:37:47.080] That is kind of your unit test.
[00:37:47.080 --> 00:37:48.520] And you can do the same thing in React.
[00:37:48.520 --> 00:37:49.720] I'll spin up a component.
[00:37:49.720 --> 00:37:59.720] I'll do a snapshot test, which is looking at the HTML output of a specific React component, view and Nuxt and all those types of JS frameworks have the same thing.
[00:37:59.720 --> 00:38:01.960] And you also have integration tests.
[00:38:01.960 --> 00:38:11.720] And this is where it gets a bit fiddly about what is an integration test because you can be very close to a unit test or it can be very close to an end-to-end test, depending upon how much you mock.
[00:38:11.720 --> 00:38:23.240] And I think actually, when someone says to you, a senior dev says, an integration test gives me the best bang for buck, it's a little bit like when you go to Amazon and you see a bunch of five-star reviews or four-star reviews.
[00:38:23.240 --> 00:38:26.440] One person's three or four star is another person's five-star.
[00:38:26.440 --> 00:38:34.760] And so what they probably mean when they say an integration test gives me the best bang for buck is they mean it tests multiple layers of the system.
[00:38:34.760 --> 00:38:37.080] So it's not testing one specific function.
[00:38:37.080 --> 00:38:43.640] It's testing like if you've got, for example, in Arvid's system, he's got like a podcasting kind of transcription pipeline.
[00:38:43.640 --> 00:39:02.560] A useful test for him is probably like taking in an MP4 or an MP3 file, transcribing it, making sure it gets all the way through, making sure it's inserted into the database, making sure that when he queries for that specific ID in various endpoints, that it comes up and that the database insertion is also following the API contracts.
[00:39:02.560 --> 00:39:15.760] And that test is worth way more than kind of 200 unit tests at every layer because that basically shows you that like the testing execution is closer to the runtime execution of what's actually happening in production.
[00:39:15.760 --> 00:39:23.920] And so back-end integration tests and back-end end-to-end tests where you're not mocking anything are probably actually the best kind of tests you can do.
[00:39:23.920 --> 00:39:39.760] I have done a lot of end-to-end testing with Playwright and it is good, but the problem is you end up with really brittle and very large and memory expensive kind of testing and it's very flaky and you have to like log in users.
[00:39:39.760 --> 00:39:50.240] And what I found is that I've spent more time trying to fix my playwright tests than if I just spent more time on the back end and just basically built more backend and built more kind of testing for the back end.
[00:39:50.240 --> 00:39:56.400] So I'm pretty bullish on back end testing and I'm really bearish on kind of playwright testing.
[00:39:56.400 --> 00:40:03.680] Having said that, I do think there's some kind of weird bugs you'll get in React, which like render bugs or like component bugs.
[00:40:03.680 --> 00:40:11.600] And what I find really works well for those is to find that bug and then ask cursor, can you write me a quick component test to regress this bug?
[00:40:11.600 --> 00:40:20.640] And actually squashing those bugs with component tests seems to be a much more efficient use of my time than telling it to write an end-to-end test to test that that thing works.
[00:40:20.640 --> 00:40:22.640] Now, there is a trade-off here.
[00:40:22.640 --> 00:40:31.160] If you're using lots of like third-party services and APIs that have callbacks into the client side, then you might need some more end-to-end testing.
[00:40:31.400 --> 00:40:39.080] But if you own more of the primitives or they're just API services you can mock, then yeah, back-end end-to-end testing is generally better.
[00:40:39.080 --> 00:40:40.680] Yeah, it's a question of degree, right?
[00:40:40.680 --> 00:40:47.400] Like how much of those kind of tests do you need for your particular implementation for your particular product?
[00:40:47.400 --> 00:40:48.920] You were mentioning Playwright.
[00:40:48.920 --> 00:40:53.880] Like that sounds to me like something that I would have to like MCP into cloud code.
[00:40:53.880 --> 00:40:55.720] Now I don't really know much about this.
[00:40:55.720 --> 00:41:00.040] Like how do you get Playwright to play with your Cloud Code environment?
[00:41:00.040 --> 00:41:15.720] Yeah, so Claude has MCP servers and each MCP server can either be a Node.js executable index.js typically from a build and that comes out from a build from a TypeScript build command or some type of build command.
[00:41:15.720 --> 00:41:20.520] And those are your traditional MCP studio kind of server URLs.
[00:41:20.520 --> 00:41:27.160] And you can hook those up into Claude to specifically talk to it through the model context protocol.
[00:41:27.160 --> 00:41:34.280] There are also a different type of MCP server, which is a remote server, which generally uses server-side events, so SSE.
[00:41:34.600 --> 00:41:39.560] And those can be useful for if you're communicating with, for example, linear.
[00:41:39.560 --> 00:41:48.040] So you can go through an OAuth flow and connect your linear tasks and pulling your linear tasks into Claude code by MCP.
[00:41:48.040 --> 00:41:59.160] So with Playwright, it actually will use the first one where it will download the Playwright executable and it will basically run that locally as a local studio server.
[00:41:59.160 --> 00:42:00.120] So standard I.O.
[00:42:00.200 --> 00:42:01.160] server.
[00:42:01.160 --> 00:42:12.520] And you'll basically be able to then send out tool calls directly to a Playwright executable, which will then run and provide an interface that Claude can then debug your code.
[00:42:12.520 --> 00:42:22.960] Now, I'm actually going to be honest with you, I'm really bearish on MCP for Playwright, and it's kind of a joke why people are recommending this because it's very, very slow.
[00:42:22.960 --> 00:42:38.800] And actually, a better workflow, in my opinion, is to write a playwright test as a static file that specifically tests that workflow and tell code to run that single test as part of the end-to-end testing suite.
[00:42:38.800 --> 00:42:44.880] Because basically, if you've already done the work, Claude Code should know exactly what that ETE file should look like.
[00:42:44.880 --> 00:42:50.080] And you can basically tell Claude, write that specific file and tell me that this passes.
[00:42:50.080 --> 00:42:56.640] Now, this still doesn't solve the bug of sometimes there might be like random errors that haven't been in there.
[00:42:56.640 --> 00:43:07.840] And I do think that there's still kind of an unsolved problem of, you know, maybe someone needs to create kind of an agentic tool that will use Playwright, that will go in and look for specific types of errors in the client-side application.
[00:43:07.840 --> 00:43:20.320] But I just think that it's quite difficult to do that with Playwright because what you really want to do is capture the network logs, you want to capture the screenshots, you want to capture everything and you want to aggregate that.
[00:43:20.320 --> 00:43:47.520] And so I would say that the easier approach is to actually put all of that into a specific evaluator and tell it when it creates a playwright script to pull in an evaluator module that will naturally give that playwright script all of the network data and take multiple screenshots and also create the evaluator output as part of that custom kind of one-off playwright script and tell you about how it is.
[00:43:47.520 --> 00:44:01.320] And that's how I've done it: I've actually got like a custom evaluator package that I basically tell a one-off Claude Code task to go and use, and it will aggregate all the console log data, all of the network data, all the XHR requests.
[00:44:01.320 --> 00:44:04.600] And it will also take multiple screenshots as it clicks through.
[00:44:04.600 --> 00:44:09.960] And then basically, it will then surface all of those insights as well as whether the test actually completed.
[00:44:09.960 --> 00:44:20.840] So, this idea of giving clawed eyes whilst it's running that playwright script is, I think, a bit more effective than MCP because MCP is not going to aggregate the logs for you or take screenshots.
[00:44:20.840 --> 00:44:24.600] And even if it does, it might not do it in like a standardized way.
[00:44:24.600 --> 00:44:27.000] And it takes a bit more in terms of latency.
[00:44:27.000 --> 00:44:32.760] It sounds to me like there's still a lot to be built by hand in this world, right?
[00:44:32.760 --> 00:44:44.680] Where even though we have the model context protocol and we have like the idea of it and implementations of it, it's still not at a state where you would call it this is the optimal thing that we're just going to keep using.
[00:44:44.680 --> 00:44:56.280] And it also kind of sounds to me like with all the cloud MD files, like the base one, the root one, and all the specific ones for specific folders, there's a potential here for a lot of knowledge sharing.
[00:44:56.360 --> 00:44:58.520] Feels like what GIST is on GitHub, right?
[00:44:58.520 --> 00:45:06.680] The GIST where people just share little files or even full repositories with dot files, sounds like this should also exist for cloud code.
[00:45:06.680 --> 00:45:07.800] Is there something like this?
[00:45:07.800 --> 00:45:10.680] Is there like a community that shares these things already?
[00:45:10.680 --> 00:45:13.480] Or is it more up to the individual developer?
[00:45:13.480 --> 00:45:23.400] There is actually a package called Viberules, which is a good example of like a CLI tool that's used for specifically sharing prompts and configurations across editors and tools.
[00:45:23.400 --> 00:45:34.360] So someone's kind of built something where you can have a markdown file and then that markdown file gets translated to claw.md files or cursor rules.
[00:45:34.360 --> 00:45:40.040] So, like, that might be something you're interested in if you're like in the node kind of ecosystem, but it depends.
[00:45:40.040 --> 00:45:50.160] I personally think that we are lacking a kind of standardized way of capturing this knowledge and keeping this knowledge up to date and also translating it between different formats.
[00:45:50.480 --> 00:45:52.720] So, yeah, things like vibrules exist.
[00:45:52.720 --> 00:46:01.680] Like, that's like a good approach of basically having an upstream version of your rules and then you propagate them to basically different types of systems.
[00:46:01.680 --> 00:46:05.600] So, that could be Gemini.md files or clawed.md files.
[00:46:05.600 --> 00:46:09.440] So, that is like a CLI that already exists, and you can use that today.
[00:46:09.440 --> 00:46:12.160] I personally don't use it because I'm just so into claw code.
[00:46:12.160 --> 00:46:20.720] And if something ever became better than clawed code, I'd probably just go and rewrite all my files to be whatever that thing.md file is, and then I'm good to go.
[00:46:20.720 --> 00:46:30.400] I do think that there's an area for like keeping the knowledge up to date, keeping the knowledge fresh, pruning the clawed code rules if you don't need them anymore.
[00:46:30.400 --> 00:46:38.000] There is kind of a knowledge management area that like we probably need to be kind of standardized, but it's kind of up to the developer at the moment.
[00:46:38.000 --> 00:46:42.720] Do you think we'll ever go back to coding as it used to be a couple of years ago?
[00:46:42.720 --> 00:46:49.360] Like, we dove so much into the details of how to configure cloud code and you know, the specifics of testing with it and all that.
[00:46:49.360 --> 00:46:58.000] But if you just zoom out a little bit, like, will we ever not use Agentic systems or systems that are built on top of Agentic systems?
[00:46:58.000 --> 00:47:00.960] What's your perspective on the near future of software development?
[00:47:00.960 --> 00:47:09.840] I think if you're working in a very mathematical, algorithmic environment, I wouldn't say that these models are maybe as useful to you.
[00:47:09.840 --> 00:47:15.440] I think for traditional software development, I don't think people will go back.
[00:47:15.440 --> 00:47:34.040] And I think it's more for the reason that they can't afford to, because if a competitor is using Claude Code and they're producing all this great, you know, API layer and they're testing it well, and they've got like a really good infrastructure, then you just can't afford to kind of keep up with their level of velocity.
[00:47:29.680 --> 00:47:46.360] And there's two things I just wanted to say on this: is like, you know, I think the smarter you can get with like your task delegation of what should be for Claude Code and what should be like for me in the loop is kind of an interesting thing.
[00:47:46.360 --> 00:47:53.320] So I specifically tagged tasks in linear as like I'm working through this, I'm verifying this, and Claude Code is working on these three tasks.
[00:47:53.320 --> 00:47:59.160] And also, what type of tasks could be run at night that I could review in the morning is also another interesting thing.
[00:47:59.160 --> 00:48:06.840] So like if someone's not using Claude Code, I could spin up like Claude Code via the SDK at night and pick up specific linear tasks.
[00:48:06.840 --> 00:48:10.520] And other people have gone to bed or they're resting at the weekend.
[00:48:10.520 --> 00:48:13.480] And I've got clawed code working on Saturday and Sunday.
[00:48:13.480 --> 00:48:20.520] And so this idea that like if I can squeeze another two days at the weekend, or I can have Claude Code boot up at 3 a.m.
[00:48:20.520 --> 00:48:31.240] in the morning, pick up a ticket for review at nine, I'm now getting essentially additional time versus these other developers that are not using time when they're asleep or resting at the weekend.
[00:48:31.240 --> 00:48:39.800] And so this idea that you don't even get faster velocity during the time you're working, but outside of the time you're working, that is something that's really meta.
[00:48:39.800 --> 00:48:50.360] And I think a lot of kind of startup people are thinking about is like, not only how much more can I squeeze like when I'm at the tool, but like how I'm not at the tool, how can I squeeze more leverage there?
[00:48:50.360 --> 00:49:00.040] That sounds even more like delegation than what we talked about earlier with this migration from being a coder to a manager or an engineering manager or an architect.
[00:49:00.040 --> 00:49:02.440] It seems like there's yet another layer.
[00:49:02.440 --> 00:49:03.560] Yeah, there is another layer.
[00:49:03.560 --> 00:49:17.280] I'm sorry to disappoint you all, but the final layer is basically you creating really good specs and you having a supervisor layer on top of clawed code by claw code SCK.
[00:49:14.520 --> 00:49:23.200] And you constantly give Claude Code the boot about whether it's really finished with the task because you probably found it.
[00:49:23.200 --> 00:49:27.120] You come back, I've written the tests, and actually it didn't fully test them.
[00:49:27.120 --> 00:49:35.200] Well, if you think about it, if you had a light supervisor layer that just sits on top of that clawed code session ID and says, have you really?
[00:49:35.520 --> 00:49:36.640] Have you really?
[00:49:36.640 --> 00:49:40.320] Every three hours or two hours, it goes and checks as well.
[00:49:40.400 --> 00:49:41.280] Oh, I've actually finished.
[00:49:41.280 --> 00:49:43.360] Okay, we've stopped the supervisor layer.
[00:49:43.360 --> 00:49:48.240] Or if it hasn't, it goes and runs a test, finds a failure, goes and fixes that, runs the test again, finds a failure.
[00:49:48.240 --> 00:49:49.440] Oh, now I finished.
[00:49:49.440 --> 00:49:50.160] Have you really?
[00:49:50.160 --> 00:49:50.880] Yes, I have.
[00:49:50.880 --> 00:49:59.440] So you can see almost a light supervisor layer is essentially what a lot of developers are doing now is acting as a light orchestrator on top of the task.
[00:49:59.440 --> 00:50:02.480] So that is something I'm actively needing to do.
[00:50:02.480 --> 00:50:07.120] I've written some code in Bun that is currently broken, but I need to get that fixed.
[00:50:07.120 --> 00:50:13.840] But that is something that I'm really interested in: this idea that just basically prompting the model and saying, have you really done the task?
[00:50:13.840 --> 00:50:15.440] Have you really run the test?
[00:50:15.440 --> 00:50:30.320] And that is probably another 20 to 40% lift in terms of if I'm not at the computer and I have two sessions that working on tasks and I can have someone just there lightly supervising a Claudian code agent, it's another bump in performance and productivity for sure.
[00:50:30.320 --> 00:50:37.920] That makes perfect sense to have this kind of orchestrator, the puppet master on top that just constantly makes sure that things are in motion.
[00:50:37.920 --> 00:50:45.280] And hey, this is likely going to be the reason why the machines are going to rise up against us because we live constant kicking of the AI.
[00:50:45.280 --> 00:50:50.160] But honestly, it is clearly the trajectory of where this is going, right?
[00:50:50.160 --> 00:50:59.200] More delegation, more abstraction, more removing yourself from the actual process of running things from the operational side and more into the conceptual on both sides, right?
[00:50:59.200 --> 00:51:04.280] You have the conceptual at the beginning and the review or like confirmation part at the end.
[00:50:59.760 --> 00:51:04.600] Uh-huh.
[00:51:04.840 --> 00:51:07.800] Yeah, there's two more things I just want to briefly touch on for a minute.
[00:51:07.960 --> 00:51:09.080] One is sub-agents.
[00:51:09.080 --> 00:51:16.680] So you can specifically define different types of roles that your claud will embody and it will delegate work to via a handoff.
[00:51:16.680 --> 00:51:22.920] And in the root claude directory, you should say follow these different types of agents in a certain type of order.
[00:51:22.920 --> 00:51:25.080] And each agent can be specific to your stack.
[00:51:25.080 --> 00:51:33.080] So it could be a QA or it could be like LiveWire, or it could be a Laravel engineer, or it could be a Fastifier or a Fast API engineer.
[00:51:33.080 --> 00:51:42.760] Telling it the order in the root claude.md that you want the sub-agents to be running is a really good hack for reduced context in the main thread.
[00:51:42.760 --> 00:51:51.800] And it also increases latency but boosts performance because the sub-agents have to gather up their own context independently and they also have to then work independently.
[00:51:51.800 --> 00:51:54.760] That is the first thing that I wanted to talk to you about.
[00:51:54.760 --> 00:52:04.040] The second thing that you should make sure that you do is keep the agent files, these sub-agent files below 100 lines or kind of 150 lines.
[00:52:04.040 --> 00:52:08.840] So don't put specific contextualized knowledge inside these sub-agents.
[00:52:08.840 --> 00:52:21.800] You should specifically say what the sub-agent should do and what order of the tasks it should do and how it should do the work, but not how it should write the work and how it should follow patterns.
[00:52:21.800 --> 00:52:34.360] And so the claw.md files are your contextual knowledge about patterns to follow, but the sub-agents are how the work should be done and in what order the work should be done and what steps there are to follow.
[00:52:34.360 --> 00:52:40.680] And that gives you a nice breakaway from you shouldn't be polluting these sub-agents with contextual knowledge, basically.
[00:52:40.680 --> 00:52:44.360] Okay, so it's more like their personalities than rules.
[00:52:44.480 --> 00:52:51.440] They're personalities and they are behavioral workflow procedures rather than contextualized knowledge.
[00:52:51.440 --> 00:52:57.200] It's so wild, honestly, to think that now I have to define behaviors and personalities in my code base.
[00:52:57.520 --> 00:53:06.640] Just compare this to like five years ago when none of this existed and how coding was just, you know, typing for each whatever kind of loops into your code base.
[00:53:06.640 --> 00:53:14.400] And now we're at the point where we have to make up a list of people-like things that we want to look at our code base in a specific order.
[00:53:14.400 --> 00:53:15.520] That blows my mind.
[00:53:15.520 --> 00:53:16.720] And you can do so much with it, right?
[00:53:16.720 --> 00:53:22.960] It's not just that you can have like a Laravel coder and a QA person or a testing agent.
[00:53:22.960 --> 00:53:28.240] You can also have like a blue team, red team kind of attack my code in terms of security holes.
[00:53:28.240 --> 00:53:29.200] Or it's something like this.
[00:53:29.200 --> 00:53:41.040] You can have so many personalities working on your code now that reflect like the full spectrum of software engineering and not just that one framework that you're working with and that one thing that you always do.
[00:53:41.040 --> 00:53:42.720] It's going to be a pretty wild future.
[00:53:42.720 --> 00:53:59.120] And I feel like with the optimization gains that we're having right now, where one agent can do the work of 10 developers, even if they tried, do you think this is going to affect the industry at large to the point where becoming a software developer is going to be harder?
[00:53:59.120 --> 00:54:22.960] I think what's going to happen is you're just going to have like the bar will be where Junior has to know how not only the primitives work like React or TypeScript or Laravel, but they also need to know how to get the most out of AI, when to do the work themselves, when to use AI, when to use a chat-based UI for agents versus like using an ambient background agent.
[00:54:22.960 --> 00:54:30.520] So the trade-offs between ambient background agents versus a cursor chat UX kind of agent, and also when to use chat mode.
[00:54:30.680 --> 00:54:42.200] So it's having that awareness around not necessarily how to write the code, what good code is, but specifically what specific type of AI and what type of workflow should be appropriate for this task.
[00:54:42.200 --> 00:54:45.480] So, yeah, I definitely think the bar is going to be raised for juniors.
[00:54:45.960 --> 00:54:59.000] I do think there's still going to be a lot of work though, because as ambition of these projects grows and the code base size grows, then you know we're just going to be delivering more value for customers, more deeper functionality, more rich functionality.
[00:54:59.000 --> 00:55:03.000] So it could just be that you end up with more people writing more code.
[00:55:03.000 --> 00:55:07.720] I think that could be one outcome is that you don't go for such narrow featured products.
[00:55:07.720 --> 00:55:15.240] It's that platform plays become possible by indie devs and small teams rather than specifically just having a feature.
[00:55:15.240 --> 00:55:18.920] And if it doesn't work out, you have to rewrite the whole back end and table structure.
[00:55:18.920 --> 00:55:23.320] You can just start off being like, I'm going to be a platform and I'll build these one or two features.
[00:55:23.320 --> 00:55:29.320] And if it doesn't work, I've already got the right database schema to support higher-level pivots.
[00:55:29.320 --> 00:55:38.120] So I think optionality and extendability are going to become bigger traits of systems where you won't necessarily have to pivot so much.
[00:55:38.120 --> 00:55:51.080] Because if you're saying, I'm going to go into transcription and I build the optimal database structure for transcription and doing that kind of work, you'll find that you'll naturally settle on different types of tables and column domains and all that kind of stuff.
[00:55:51.080 --> 00:55:58.520] And maybe you eventually go into captioning, but it's an extension of transcription or media rendering with captions.
[00:55:58.520 --> 00:56:05.160] So I'm very bullish on this idea of you pick the domain, you build the right structure of tables and services for the domain.
[00:56:05.160 --> 00:56:15.520] And if the initial product doesn't work, you basically pivot into another subsection of the domain and you build out those two things and you get compound gains of a platform play.
[00:56:15.680 --> 00:56:25.680] So think of like if you have a create image tool, a create video tool, you know, a caption system, you can then start to compose those and get compound gains.
[00:56:25.680 --> 00:56:32.960] So I think those are where products are going to go long term is this idea of like compounding composition of services a little bit like AWS.
[00:56:32.960 --> 00:56:50.320] Well, it certainly sounds like the old slogan of software is never complete is true as ever and even more true probably because things are now have to be composable, they have to be extensible, they have to be more flexible because of just the commoditization of building software on them.
[00:56:50.320 --> 00:56:58.320] And you know that within the next couple of weeks, if enough resources were deployed to it, people could be building thousands of features on top of your data, right?
[00:56:58.320 --> 00:57:01.440] So you might as well make it extensible and build a platform.
[00:57:01.440 --> 00:57:12.880] And with the speed that the whole vibe coding industry has taken off, like all the underlying systems, like a superbase and any system that's integrated, they are being used in all different ways.
[00:57:12.880 --> 00:57:18.320] So they better have a solid underlying foundation of data for them to be used like this.
[00:57:18.320 --> 00:57:22.480] We're looking at a very interesting decade of software engineering ahead of us.
[00:57:22.480 --> 00:57:23.520] I certainly am.
[00:57:23.520 --> 00:57:26.960] And I don't know if I would ever want to not use agentic systems.
[00:57:26.960 --> 00:57:34.080] Like the benefits of them have severely outperformed all the potential drawbacks and the little issues that I've been having until today.
[00:57:34.320 --> 00:57:44.480] I've run into a couple of things that I didn't see that I'm learning from on how to spot problems that, you know, later down the line, how to spot these kind of time bombs in the code base.
[00:57:44.480 --> 00:57:53.120] Probably still a couple in there, but honestly, as I wrote the code before without AI, probably put a lot of time bombs in my code as well back in the day.
[00:57:53.120 --> 00:57:54.880] So I'm excited for this.
[00:57:54.880 --> 00:58:12.600] I'm also excited for your journey because you're very professional in how you approach this, very meticulous and you're sharing a lot of it i really appreciate that so if people wanted to follow your journey and the little steps you take the big jumps the big leaps where do you want them to go Yeah, so obviously come and view me on X.
[00:58:12.600 --> 00:58:13.160] Follow me.
[00:58:13.160 --> 00:58:14.200] So it's James A.
[00:58:14.200 --> 00:58:15.720] Phoenix12.
[00:58:15.720 --> 00:58:17.240] If you're on LinkedIn, it's James A.
[00:58:17.240 --> 00:58:18.040] Phoenix.
[00:58:18.040 --> 00:58:23.400] And then I'm also building a product for content marketing professionals, which is octospark.ai.
[00:58:23.400 --> 00:58:27.000] So if you're interested in content marketing, feel free to sign up.
[00:58:27.000 --> 00:58:35.320] And that platform is basically going to be like an agentic kind of way of composing TikTok and also videos on TikTok and slideshows.
[00:58:35.320 --> 00:58:37.320] So feel free to follow along on that journey.
[00:58:37.320 --> 00:58:40.360] And yeah, thank you very much for your attention and for listening.
[00:58:40.600 --> 00:58:41.560] I really appreciate that.
[00:58:41.560 --> 00:58:42.920] And I'll pass it back to Alvin.
[00:58:42.920 --> 00:58:44.600] Yeah, Wen, that was a great chat.
[00:58:44.600 --> 00:58:46.520] I'm looking forward to the journey of your product.
[00:58:46.520 --> 00:58:50.120] That sounds like the perfect use case for agentic systems as well.
[00:58:50.120 --> 00:58:51.560] So I'll keep my eyes on that.
[00:58:51.560 --> 00:58:53.000] Thanks so much for chatting with me today.
[00:58:53.000 --> 00:58:55.000] It was really insightful sharing all your knowledg

Prompt 2: Key Takeaways

Now please extract the key takeaways from the transcript content I provided.

Extract the most important key takeaways from this part of the conversation. Use a single sentence statement (the key takeaway) rather than milquetoast descriptions like "the hosts discuss...". 

Limit the key takeaways to a maximum of 3. The key takeaways should be insightful and knowledge-additive. 

IMPORTANT: Return ONLY valid JSON, no explanations or markdown. Ensure:
- All strings are properly quoted and escaped
- No trailing commas
- All braces and brackets are balanced
Format: {"key_takeaways": ["takeaway 1", "takeaway 2"]}

Prompt 3: Segments

Now identify 2-4 distinct topical segments from this part of the conversation.

For each segment, identify:
- Descriptive title (3-6 words)  
- START timestamp when this topic begins (HH:MM:SS format)
- Double check that the timestamp is accurate - a timestamp will NEVER be greater than the total length of the audio
- Most important Key takeaway from that segment. Key takeaway must be specific and knowledge-additive.
- Brief summary of the discussion

IMPORTANT: The timestamp should mark when the topic/segment STARTS, not a range. Look for topic transitions and conversation shifts.

Return ONLY valid JSON. Ensure all strings are properly quoted, no trailing commas:
{
  "segments": [
    {
      "segment_title": "Topic Discussion", 
      "timestamp": "01:15:30",
      "key_takeaway": "main point from this segment",
      "segment_summary": "brief description of what was discussed"
    }
  ]
}

Timestamp format: HH:MM:SS (e.g., 00:05:30, 01:22:45) marking the START of each segment.

Prompt 4: Media Mentions

Now scan the transcript content I provided for ACTUAL mentions of specific media titles:

Find explicit mentions of:
- Books (with specific titles)
- Movies (with specific titles)  
- TV Shows (with specific titles)
- Music/Songs (with specific titles)

DO NOT include:
- Websites, URLs, or web services
- Other podcasts or podcast names

IMPORTANT: 
- Only include items explicitly mentioned by name. Do not invent titles.
- Valid categories are: "Book", "Movie", "TV Show", "Music"
- Include the exact phrase where each item was mentioned
- Find the nearest proximate timestamp where it appears in the conversation
- THE TIMESTAMP OF THE MEDIA MENTION IS IMPORTANT - DO NOT INVENT TIMESTAMPS AND DO NOT MISATTRIBUTE TIMESTAMPS
- Double check that the timestamp is accurate - a timestamp will NEVER be greater than the total length of the audio
- Timestamps are given as ranges, e.g. 01:13:42.520 --> 01:13:46.720. Use the EARLIER of the 2 timestamps in the range.

Return ONLY valid JSON. Ensure all strings are properly quoted and escaped, no trailing commas:
{
  "media_mentions": [
    {
      "title": "Exact Title as Mentioned",
      "category": "Book",
      "author_artist": "N/A",
      "context": "Brief context of why it was mentioned",
      "context_phrase": "The exact sentence or phrase where it was mentioned",
      "timestamp": "estimated time like 01:15:30"
    }
  ]
}

If no media is mentioned, return: {"media_mentions": []}

Prompt 5: Context Setup

You are an expert data extractor tasked with analyzing a podcast transcript. 
I will provide you with part 2 of 2 from a podcast transcript. 
I will then ask you to extract different types of information from this content in subsequent messages. Please confirm you have received and understood the transcript content.

Transcript section:
57:53.120] Probably still a couple in there, but honestly, as I wrote the code before without AI, probably put a lot of time bombs in my code as well back in the day.
[00:57:53.120 --> 00:57:54.880] So I'm excited for this.
[00:57:54.880 --> 00:58:12.600] I'm also excited for your journey because you're very professional in how you approach this, very meticulous and you're sharing a lot of it i really appreciate that so if people wanted to follow your journey and the little steps you take the big jumps the big leaps where do you want them to go Yeah, so obviously come and view me on X.
[00:58:12.600 --> 00:58:13.160] Follow me.
[00:58:13.160 --> 00:58:14.200] So it's James A.
[00:58:14.200 --> 00:58:15.720] Phoenix12.
[00:58:15.720 --> 00:58:17.240] If you're on LinkedIn, it's James A.
[00:58:17.240 --> 00:58:18.040] Phoenix.
[00:58:18.040 --> 00:58:23.400] And then I'm also building a product for content marketing professionals, which is octospark.ai.
[00:58:23.400 --> 00:58:27.000] So if you're interested in content marketing, feel free to sign up.
[00:58:27.000 --> 00:58:35.320] And that platform is basically going to be like an agentic kind of way of composing TikTok and also videos on TikTok and slideshows.
[00:58:35.320 --> 00:58:37.320] So feel free to follow along on that journey.
[00:58:37.320 --> 00:58:40.360] And yeah, thank you very much for your attention and for listening.
[00:58:40.600 --> 00:58:41.560] I really appreciate that.
[00:58:41.560 --> 00:58:42.920] And I'll pass it back to Alvin.
[00:58:42.920 --> 00:58:44.600] Yeah, Wen, that was a great chat.
[00:58:44.600 --> 00:58:46.520] I'm looking forward to the journey of your product.
[00:58:46.520 --> 00:58:50.120] That sounds like the perfect use case for agentic systems as well.
[00:58:50.120 --> 00:58:51.560] So I'll keep my eyes on that.
[00:58:51.560 --> 00:58:53.000] Thanks so much for chatting with me today.
[00:58:53.000 --> 00:58:55.000] It was really insightful sharing all your knowledge.
[00:58:55.000 --> 00:58:56.360] Thanks, James.
[00:58:56.360 --> 00:58:57.640] And that's it for today.
[00:58:57.640 --> 00:58:59.800] Thank you so much for listening to the Bootstrap Founder.
[00:58:59.800 --> 00:59:03.400] You can find me on Twitter at Avid Karl, A-R-I-D, K-A-H-L.
[00:59:03.400 --> 00:59:16.200] And if you want to support me in this show, please share podscan.fm, my SaaS business, with your professional peers and those who you think will benefit from tracking mentions of their brands, their businesses, their names on podcasts out there.
[00:59:16.200 --> 00:59:20.680] PodScan is a near real-time podcast database with a stellar API.
[00:59:20.680 --> 00:59:23.880] We have 32 million podcast episodes in the back now.
[00:59:23.880 --> 00:59:25.800] The database is humongous.
[00:59:25.800 --> 00:59:30.040] Please share the word with those who need to stay on top of the podcast ecosystem.
[00:59:30.040 --> 00:59:31.480] Thank you so much for listening.
[00:59:31.480 --> 00:59:33.880] Have a wonderful day and bye-bye.

Prompt 6: Key Takeaways

Now please extract the key takeaways from the transcript content I provided.

Extract the most important key takeaways from this part of the conversation. Use a single sentence statement (the key takeaway) rather than milquetoast descriptions like "the hosts discuss...". 

Limit the key takeaways to a maximum of 3. The key takeaways should be insightful and knowledge-additive. 

IMPORTANT: Return ONLY valid JSON, no explanations or markdown. Ensure:
- All strings are properly quoted and escaped
- No trailing commas
- All braces and brackets are balanced
Format: {"key_takeaways": ["takeaway 1", "takeaway 2"]}

Prompt 7: Segments

Now identify 2-4 distinct topical segments from this part of the conversation.

For each segment, identify:
- Descriptive title (3-6 words)  
- START timestamp when this topic begins (HH:MM:SS format)
- Double check that the timestamp is accurate - a timestamp will NEVER be greater than the total length of the audio
- Most important Key takeaway from that segment. Key takeaway must be specific and knowledge-additive.
- Brief summary of the discussion

IMPORTANT: The timestamp should mark when the topic/segment STARTS, not a range. Look for topic transitions and conversation shifts.

Return ONLY valid JSON. Ensure all strings are properly quoted, no trailing commas:
{
  "segments": [
    {
      "segment_title": "Topic Discussion", 
      "timestamp": "01:15:30",
      "key_takeaway": "main point from this segment",
      "segment_summary": "brief description of what was discussed"
    }
  ]
}

Timestamp format: HH:MM:SS (e.g., 00:05:30, 01:22:45) marking the START of each segment.

Prompt 8: Media Mentions

Now scan the transcript content I provided for ACTUAL mentions of specific media titles:

Find explicit mentions of:
- Books (with specific titles)
- Movies (with specific titles)  
- TV Shows (with specific titles)
- Music/Songs (with specific titles)

DO NOT include:
- Websites, URLs, or web services
- Other podcasts or podcast names

IMPORTANT: 
- Only include items explicitly mentioned by name. Do not invent titles.
- Valid categories are: "Book", "Movie", "TV Show", "Music"
- Include the exact phrase where each item was mentioned
- Find the nearest proximate timestamp where it appears in the conversation
- THE TIMESTAMP OF THE MEDIA MENTION IS IMPORTANT - DO NOT INVENT TIMESTAMPS AND DO NOT MISATTRIBUTE TIMESTAMPS
- Double check that the timestamp is accurate - a timestamp will NEVER be greater than the total length of the audio
- Timestamps are given as ranges, e.g. 01:13:42.520 --> 01:13:46.720. Use the EARLIER of the 2 timestamps in the range.

Return ONLY valid JSON. Ensure all strings are properly quoted and escaped, no trailing commas:
{
  "media_mentions": [
    {
      "title": "Exact Title as Mentioned",
      "category": "Book",
      "author_artist": "N/A",
      "context": "Brief context of why it was mentioned",
      "context_phrase": "The exact sentence or phrase where it was mentioned",
      "timestamp": "estimated time like 01:15:30"
    }
  ]
}

If no media is mentioned, return: {"media_mentions": []}

Full Transcript

[00:00:00.400 --> 00:00:04.400] Hey, it's Arvid, and this is the Bootstrap Founder.
[00:00:09.200 --> 00:00:14.800] Today, I'm talking to James Phoenix, an expert in agentic coding, particularly Claude Code.
[00:00:14.800 --> 00:00:20.080] That's a tool that I've been using for my own software projects to great effect over the last couple months.
[00:00:20.080 --> 00:00:22.720] And I talked a lot about this on this podcast.
[00:00:22.720 --> 00:00:29.600] I chatted with James just a couple of days ago and have implemented several of the tips that he gave me during this conversation.
[00:00:29.680 --> 00:00:36.800] I'm already almost twice as effective at using this already magically effective tool, which is very impressive.
[00:00:36.800 --> 00:00:45.520] So, I don't think I can overpromise how much insight into well-structured and highly optimized agentic coding you will get from this conversation.
[00:00:45.520 --> 00:00:52.000] A big shout out to the sponsor of today's episode, Paddle.com, my merchant of record payment provider of choice.
[00:00:52.000 --> 00:00:59.600] They're taking care of all the things related to money so that founders like me and you can focus on the things that only we can build, and Paddle handles the rest.
[00:00:59.600 --> 00:01:01.440] Sales tax, credit cards failing.
[00:01:01.440 --> 00:01:02.640] I don't want to deal with that.
[00:01:02.640 --> 00:01:03.600] I don't have to.
[00:01:03.600 --> 00:01:04.320] They do.
[00:01:04.320 --> 00:01:05.440] I highly recommend it.
[00:01:05.440 --> 00:01:07.920] So, please check out paddle.com.
[00:01:07.920 --> 00:01:12.080] And now, here's James.
[00:01:12.080 --> 00:01:14.560] James, welcome back to the podcast.
[00:01:14.560 --> 00:01:25.440] Last time we've been chatting about LLMs and prompting them, and today we will dive into one of the most powerful agentic coding tools out there, if not the most powerful at this point.
[00:01:25.440 --> 00:01:31.760] I use it every day, and you've become an expert at managing it and wrangling it and getting things out of it that you wanted to do.
[00:01:31.760 --> 00:01:36.320] Let's dive deep into building software without typing a line of code.
[00:01:36.320 --> 00:01:42.080] Do you know just how much you've actually used Claude Code in total so far?
[00:01:42.080 --> 00:01:44.880] Yeah, so I've been using Claude Code a lot.
[00:01:44.880 --> 00:01:54.480] I'm roughly spending around like maybe 3.4K if they were charging me in API costs, or around sort of 2.3 billion tokens per month.
[00:01:54.480 --> 00:02:02.360] Yeah, so I've been using it a lot in my workflow, even to the point actually where I have downgraded my cursor ultra plan.
[00:02:02.680 --> 00:02:13.240] So I had a $200 cursor ultra plan and a $200 core code plan, and I'm mainly using cursor now for fixing up work or where I need to slow down.
[00:02:13.400 --> 00:02:15.480] And most of the work has gone to core code.
[00:02:15.480 --> 00:02:18.600] So that one's keeping the big subscription for now.
[00:02:18.920 --> 00:02:23.080] There's so many layers to think about when you buy these tools, right?
[00:02:23.080 --> 00:02:24.920] There's the IDEs that come with them.
[00:02:24.920 --> 00:02:26.920] Then Cloud Code is kind of standalone.
[00:02:26.920 --> 00:02:29.720] You can run it in any IDE that it has an integration for.
[00:02:29.720 --> 00:02:32.600] Maybe even if it doesn't have an integration, you can still run it.
[00:02:32.600 --> 00:02:37.320] There's a lot of complexity to the cost of these tools at this point.
[00:02:37.320 --> 00:02:46.920] I do wonder with these tools, particularly Cursor, which is kind of VS Code on steroids with AI and can integrate into other tools into different models.
[00:02:46.920 --> 00:02:49.640] These tools haven't really been around for that long.
[00:02:49.640 --> 00:02:55.560] Do you see things like Cursor just fall off at some point and be replaced by something else?
[00:02:55.560 --> 00:02:59.240] Or should we expect Cursor to stick around in tools just like it?
[00:02:59.240 --> 00:03:04.360] I think the challenge that Cursor has is they aren't a model maker.
[00:03:04.360 --> 00:03:12.440] And so they explicitly have to make more profit margin on a consumer and they end up passing that cost to the consumer, right?
[00:03:12.440 --> 00:03:19.880] So Anthropic or Google, they have their own foundational models and therefore they don't have to make as much money.
[00:03:19.880 --> 00:03:25.400] I think Cursor has been building a little bit of a moat on their tab completion models.
[00:03:25.400 --> 00:03:28.920] So actually I found that their tab model is really, really good.
[00:03:29.240 --> 00:03:34.120] I can tell they're spending a lot of time specifically improving that.
[00:03:34.120 --> 00:03:37.320] They do still have kind of an edge on co-pilot.
[00:03:37.320 --> 00:03:39.400] I mean, I did look at Copilot recently.
[00:03:39.400 --> 00:03:43.800] You can do things like run agentic workloads against GitHub issues.
[00:03:43.800 --> 00:03:51.360] People still have, I would say, a preference over the curse agent mode over like GitHub Copilot agent.
[00:03:51.680 --> 00:03:55.680] But yeah, it's definitely like the gap is shortening.
[00:03:55.680 --> 00:04:06.320] And so, yeah, I think like cursor is not necessarily going to be in trouble, but they're just taking good specializing approaches like background agents and making their tab completion kind of best in class.
[00:04:06.320 --> 00:04:11.920] Well, when I think about tab completion, I'm trying to remember when I last used it, and that was not today.
[00:04:11.920 --> 00:04:14.240] Like, I was building a lot of stuff today.
[00:04:14.240 --> 00:04:22.800] I think I have built like two or three features in two projects today, yet I don't think I've written any line of code at any point during this.
[00:04:22.800 --> 00:04:27.840] It was just prompting and then taking or leaving what came back from it.
[00:04:27.840 --> 00:04:33.600] So, I do wonder if tab completion is ever going to play a role in my choice of IDE.
[00:04:33.600 --> 00:04:44.160] Yeah, I guess my point would be that if you need additional context on what you're doing, then those more kind of primitive AI features become more valuable, right?
[00:04:44.160 --> 00:04:49.200] So, like, if you're actually deep in the implementation of the code, then tab completion is really useful.
[00:04:49.200 --> 00:05:01.440] But obviously, if you're using something like Gemini CLI or Claude Code or Open Code, you know, whatever you're using as a kind of agentic coding tool, then tab completion isn't really a feature that you even think about anymore, right?
[00:05:01.440 --> 00:05:02.800] So, it depends.
[00:05:02.800 --> 00:05:15.360] I also think that there is kind of a hidden cost to using clawed code where you're essentially an engineering manager and you lose a lot of that contextual awareness about what's happening in each individual file.
[00:05:15.360 --> 00:05:25.360] And so, there is kind of that trade-off of, you know, if you're not actually writing the file, you do have a loss of context that you then have to re-aggregate as an engineering manager.
[00:05:25.360 --> 00:05:31.320] So, if you're an engineering manager and you've got three devs, you essentially farm out, you know, a bunch of tasks.
[00:05:29.840 --> 00:05:36.840] Each dev goes off, they work on that task in parallel, and then you get all this completed work back.
[00:05:36.920 --> 00:05:40.280] But as an engineering manager, you didn't write those files by hand.
[00:05:40.280 --> 00:05:46.520] So what you're finding is that you're having to find clever ways of recontextualizing on the code that just came out.
[00:05:46.520 --> 00:05:49.000] And obviously, PR review is one of those.
[00:05:49.000 --> 00:05:52.920] But I think the main thing I do is kind of you can do some quite clever things.
[00:05:52.920 --> 00:06:01.560] So you can ask like Claude Code to generate you a data flow of what it's implemented, for example, or a mermaid diagram.
[00:06:01.560 --> 00:06:03.400] So that can be quite a nice way.
[00:06:03.400 --> 00:06:05.240] I get it to create digest files.
[00:06:05.240 --> 00:06:06.360] So what have you done?
[00:06:06.360 --> 00:06:07.320] What are the changes?
[00:06:07.320 --> 00:06:09.320] What is the state of the data flow?
[00:06:09.320 --> 00:06:12.360] And then, yeah, you're basically trying to have to find a way around that.
[00:06:12.360 --> 00:06:16.360] But obviously, when you're using tab completion models, you're not necessarily having to do that.
[00:06:16.360 --> 00:06:17.800] You're fully in the zone.
[00:06:17.800 --> 00:06:20.680] You kind of know this is this interface, this is this function.
[00:06:20.680 --> 00:06:25.240] So there's a trade-off of either side, right, in terms of speed versus context loss.
[00:06:25.240 --> 00:06:30.040] That context loss, that to me is the source of all evil in using this.
[00:06:30.040 --> 00:06:34.760] And I mean this in a neutral way, even though it's not expressed like it, but that is the risk part, right?
[00:06:34.760 --> 00:06:36.760] That is where we risk skill atrophy.
[00:06:36.760 --> 00:06:43.880] That is where we risk introducing stuff into our code bases that we don't understand that might be just a time bomb to blow up later.
[00:06:43.880 --> 00:07:01.240] And I believe that a lot of founders who are using this to build their businesses or a lot of software engineers who are using agentic coding just to help them be more productive, they're introducing this without knowing it because they don't have the required skill set just yet to make this shift from coder to engineering manager.
[00:07:01.240 --> 00:07:06.280] They don't know yet that they are actually a manager and not a software developer anymore.
[00:07:06.280 --> 00:07:07.000] How can we do this?
[00:07:07.000 --> 00:07:09.560] How can we make this easier for people to understand?
[00:07:09.560 --> 00:07:16.080] Yeah, I think the main point here is you have to be very careful about committing code that's come from clawed code.
[00:07:16.400 --> 00:07:41.200] And it's actually easier to spin up a separate Git work tree on a separate branch, have it have a go at a feature or something, and then review the code and throw it away than it is to merge in poor quality code and then have to figure out in the code base about 10 or 20 or 30 or 40 commits later where that poor quality code is.
[00:07:41.200 --> 00:07:49.440] So actually, the main thing that you have to wrap your head around is that actually adding code is both dangerous and not dangerous.
[00:07:49.440 --> 00:07:51.120] And I'll explain what I mean by that.
[00:07:51.120 --> 00:08:07.920] So if you're doing an additive feature, so if you create a new feature and it doesn't necessarily touch anything, if you do that in a Git work tree, or even if you do that in the main branch, if it's purely an additive operation, then you can simply delete the code, right?
[00:08:07.920 --> 00:08:26.720] Where it becomes more dangerous is if you have a service and you mutate and you update existing dependencies or existing files, or if you have something that is now dependent on something and you've changed that, anytime you've got that kind of situation, that is where the danger strikes of committing code without testing it.
[00:08:26.720 --> 00:08:34.160] So mutative code or modificative code is actually more dangerous than additive code.
[00:08:34.160 --> 00:08:39.760] So this idea that if you add it, you just have something that if you add it, it's not necessarily a problem because you can throw it away.
[00:08:39.760 --> 00:08:41.360] It doesn't affect other services.
[00:08:41.360 --> 00:08:46.640] Whenever you're updating existing infrastructure or service layers, that's the dangerous point.
[00:08:46.640 --> 00:09:01.320] And then the second point is actually, it's much cheaper to go through each individual file diff and see if it's making mistakes and push back on clawed code at that point in the conversation history because you've already got that conversation history to hand.
[00:09:01.320 --> 00:09:06.760] Otherwise, what's going to happen is you'll realize there's a bunch of changes that you should have actually pushed back on.
[00:09:06.760 --> 00:09:12.600] You'll be searching for that session ID in all of your clawed codes because claw code is ephemeral, right?
[00:09:12.600 --> 00:09:20.840] In the sense of unless you have that specific session ID, you're now having to pay per trail and go work your way up in user a clawed dash dash through a zoom.
[00:09:20.840 --> 00:09:27.800] You'll get all the session histories and you're trying to find that specific one which actually was associated with that chunk of work.
[00:09:27.800 --> 00:09:36.040] So pushing back on the chunk of work at that point in time is actually easiest because you don't have to keep a handle as to where that specific session is.
[00:09:36.040 --> 00:09:38.280] You're just dealing with that problem in the here and now.
[00:09:38.600 --> 00:09:47.560] And the other thing I will say on that is that every time you're pushing back on clawed code is an opportunity for you to learn something.
[00:09:47.560 --> 00:09:49.320] And it's a couple of different things.
[00:09:49.320 --> 00:09:53.000] So mainly it's you didn't prompt it well enough.
[00:09:53.160 --> 00:09:54.680] It didn't have the right context.
[00:09:54.680 --> 00:09:58.680] That's one potential area for it to have gone wrong.
[00:09:58.680 --> 00:10:08.280] The other area that is interesting is you might have specifically given it all the right context, but it didn't have any rules or any patterns to follow.
[00:10:08.280 --> 00:10:18.840] So if you're working on a greenfield problem, you might find that actually, if it hasn't got any patterns, it will do several things in different ways and it doesn't have a standardized way of working.
[00:10:18.840 --> 00:10:21.640] Or it's a rules problem, so it just didn't have any rules to follow.
[00:10:21.640 --> 00:10:25.640] So generally, it's a prompting problem or a context problem or a rules problem.
[00:10:25.640 --> 00:10:28.760] And also, it can be a testing or a verification problem.
[00:10:28.760 --> 00:10:33.400] So it's one of those things that generally goes wrong when you're using Claude Code.
[00:10:33.400 --> 00:10:35.480] You know, those are the things to kind of look at.
[00:10:35.480 --> 00:10:37.640] So, how do you define these patterns?
[00:10:37.640 --> 00:10:46.320] Particularly for a Greenfield Project, I think it's Claude is capable of extracting patterns from existing code bases and codifying them into something that it understands.
[00:10:46.320 --> 00:10:47.280] At least I've heard.
[00:10:44.840 --> 00:10:48.320] If not, tell me.
[00:10:48.640 --> 00:10:51.120] But how do you deal with this when you want to build something new?
[00:10:51.120 --> 00:10:57.920] Do you already have to be able to completely formulate this almost like a waterfall design document?
[00:10:57.920 --> 00:11:02.720] Or do you have a couple of starting points that you then elaborate on over time?
[00:11:02.720 --> 00:11:04.240] Like, how do you approach this?
[00:11:04.240 --> 00:11:28.080] Yeah, I think the main thing that I've learned is it's easier to update one file and come up with a global kind of pattern for some type of layer than it is to roll out 10 or 30 files in an API and then realize that you want to add JS stock or you want to add types or you want to add a certain type of dependency or middleware.
[00:11:28.080 --> 00:11:41.280] So I think the main point of learning this is that you're better off actually in some weird way spending half an hour or an hour or an hour and a half in cursor and iterating on specifically what that pattern is.
[00:11:41.280 --> 00:11:49.840] And then once you've got the pattern nailed and it has a pattern to follow, then you can roll that pattern out across a bunch of different Postgres tables.
[00:11:49.840 --> 00:11:51.840] And I found that works really well.
[00:11:51.840 --> 00:11:53.280] That's one way of doing it.
[00:11:53.280 --> 00:12:00.240] The other way of doing it is to come up with a rules file and to say, when you're making this type of pattern, you should do this.
[00:12:00.240 --> 00:12:06.000] I don't find that works as well though, because it doesn't have code to mirror the pattern off of.
[00:12:06.000 --> 00:12:13.600] And also, like Claude Code, like a lot of agentic tool calls, specifically for file reading to see what it kind of looks like to begin with.
[00:12:13.600 --> 00:12:18.000] So I think, yeah, building up a couple of examples is like the best way to kind of go.
[00:12:18.000 --> 00:12:18.960] That's interesting.
[00:12:18.960 --> 00:12:37.400] I've never thought about it like this because I always thought, okay, Greenfield Project might as well let Claude do all the work, but by you spending some time to actually explore what you want it to look like, even just prototypical, what you're saying sounds to me like you are giving very clear evidence of what you want, and Claude will from there infer what the rest of it should look like.
[00:12:37.400 --> 00:12:40.760] Yeah, and I think cursor works very well like this as well.
[00:12:40.760 --> 00:12:44.920] If you're doing Greenfield, you'll basically with any kind of LLM, you'll run into the same issue.
[00:12:44.920 --> 00:12:46.680] It's not even just a clawed code thing.
[00:12:46.680 --> 00:12:52.520] It's just LLMs are really good at generating tokens, but they lack real strategic sense.
[00:12:52.520 --> 00:13:05.880] And like that's an example of something that I'm seeing on my personal project, which is it will define lots of constants that exist, and those constants will be repeated in different Zob models in lots of different files.
[00:13:05.880 --> 00:13:17.640] And so what I've noticed is these models are incredibly good at working in very hyper-localized context, but they're very bad at thinking about strategic context.
[00:13:17.640 --> 00:13:28.840] So for example, if you're doing social media platforms, you'll have some constants or an enum for Facebook or Meta or X or LinkedIn and YouTube and what have you.
[00:13:28.840 --> 00:13:37.000] But those constants, if you leave it unchecked, clawed code will just go and put that in every interface, in every Zod model of every file.
[00:13:37.000 --> 00:13:38.840] And that's what I'm finding right now in my project.
[00:13:38.840 --> 00:13:51.960] And I'm like, it's really interesting how clawed code is really good, but actually, if I'd have just started by upfront saying we always use these constants, then it wouldn't have had any additional patterns to match against.
[00:13:51.960 --> 00:13:56.280] Even still, even if you do that, there will still be some that slip through the cracks.
[00:13:56.280 --> 00:14:01.800] You just can't, you can't always expect to have all of the right contexts in every single prompt.
[00:14:01.800 --> 00:14:03.320] It's just unrealistic.
[00:14:03.320 --> 00:14:13.480] And so that's kind of where you need that QA step where you're specifically looking at different types of things that are wrong with the file changes or the file creates that have happened, basically.
[00:14:13.480 --> 00:14:17.280] Yeah, I mean, we had refactoring and rewriting stuff before we had Cloud Code.
[00:14:17.280 --> 00:14:19.040] So people made mistakes as well, right?
[00:14:19.040 --> 00:14:22.800] Or implemented things in ways that turn out to not be the optimal way.
[00:14:22.800 --> 00:14:29.360] I do wonder, though, because Cloud Code has plan mode and it has the capacity to not immediately act, right?
[00:14:29.360 --> 00:14:32.080] Not to immediately change things, but to think about it.
[00:14:32.080 --> 00:14:41.200] Would it make sense to have this kind of refactoring step every now and then just to let it check the code base for repetition?
[00:14:41.200 --> 00:14:57.120] Yeah, so I think what you're talking about is, and I'm going to expand this to be a bit more of a philosophy rather than just that specific task, is there's kind of some tasks that you don't want clawed code to do all the time, but you want it to do kind of infrequently, like a one-off task.
[00:14:57.120 --> 00:15:12.400] And so what you're describing as looking for redundancy or duplicated code or a lack of specific global constants or types is a dev task, which means that constants or enums become centralized.
[00:15:12.400 --> 00:15:17.680] And that is the kind of thing that you should probably have like on a weekly cron schedule.
[00:15:17.680 --> 00:15:25.040] And you should have it as like a command that you can run inside of clawed code, but it's not necessarily something I would make a sub-agent for.
[00:15:25.120 --> 00:15:26.560] It's like a one-off command.
[00:15:26.560 --> 00:15:31.920] I could run it like, I don't know, once a week, or I could run it on a cron on like a GitHub action.
[00:15:31.920 --> 00:15:38.160] And I can specifically look for errors in the code base kind of systematically, but it's not something I'm going to run every day.
[00:15:38.160 --> 00:15:40.960] And it will also pick up a lot of false positives.
[00:15:40.960 --> 00:15:44.640] So that is a good example of something you should put into a clawed code command.
[00:15:44.640 --> 00:15:50.960] But I never defined any commands, really, for the reason that I didn't even know that you could do that at this point.
[00:15:50.960 --> 00:15:55.840] So it sounds like you have things that are just conversational where you just go through and build some kind of feature.
[00:15:55.840 --> 00:16:02.120] And then there are things that are so repeatable that they warrant having this kind of encapsulated command.
[00:15:59.680 --> 00:16:02.200] Yeah.
[00:16:02.360 --> 00:16:09.640] And like basically anytime you're doing something, not all the time, but kind of, I don't know, every day or every week.
[00:16:09.640 --> 00:16:12.680] would be something you could put into a command.
[00:16:12.680 --> 00:16:23.000] So a good example will be I have a command called update docs.md and it tells it basically I want you to review all the docs in our architecture.
[00:16:23.000 --> 00:16:25.480] I want you to look at all the package implementations.
[00:16:25.480 --> 00:16:30.200] I want you to verify a bunch of API routes that match the documentations.
[00:16:30.200 --> 00:16:36.680] And then it basically says go and look at all the different features and update a doc slash architecture.md, for example.
[00:16:36.680 --> 00:16:41.480] So keeping the docs fresh just from a Claude Code command is like an example.
[00:16:41.480 --> 00:16:47.000] Another one would be like, I'm using a system prompt override in Claude Code.
[00:16:47.000 --> 00:16:53.960] So I'm specifically telling it to kind of take on a role and I don't want it to have to keep telling it to take on this role.
[00:16:53.960 --> 00:17:03.160] So that's something I use a lot more frequently where I'd have like a slash confirm augster and it just tells it, I want you to confirm that you're this role and you're the best software engineer in the world.
[00:17:03.480 --> 00:17:07.080] And the reason why is that Claude, they've obviously got a system prompt.
[00:17:07.080 --> 00:17:10.360] You know, you are a developer, you do this, you do that, right?
[00:17:10.360 --> 00:17:13.080] That comes injected into the system prompt.
[00:17:13.080 --> 00:17:18.440] And so what I've actually found works really well is to override the system prompt.
[00:17:18.440 --> 00:17:22.680] And there's a system prompt that you can have that was made by augment code.
[00:17:22.680 --> 00:17:30.600] And there's this kind of like, it's kind of XML based, but it basically sets up Claude Code to generate a lot more to-do tasks.
[00:17:30.600 --> 00:17:37.960] And I found that the painful points of using clawed code is that it either stops early or it doesn't run tests.
[00:17:37.960 --> 00:17:54.320] And basically, yeah, this kind of like system prompt override basically says you must have a plan or a mission, you must enter an operational loop, you must do the work, verify that the work is done, only go out of the operational loop when the work has been verified.
[00:17:54.320 --> 00:18:00.160] And so basically, it will do things like it will plan, it will implement, it will run tests, and it will verify tests.
[00:18:00.160 --> 00:18:03.120] And so that kind of operational loop is really useful.
[00:18:03.120 --> 00:18:11.520] But obviously, using that is really quite, you know, a bit boring to say, I want you to take on this role and use what's in my clawed.md and assume this role.
[00:18:11.520 --> 00:18:17.520] So that is another example of a slash command that I use like every hour to just save myself some manual typing.
[00:18:17.520 --> 00:18:20.240] So that cannot be reliably auto-injected.
[00:18:20.240 --> 00:18:22.800] You kind of have to do it manually through the command?
[00:18:22.800 --> 00:18:29.360] You can use clawed code hooks to do auto-injection, but it depends on like where those hooks land.
[00:18:29.360 --> 00:18:32.160] I personally haven't explored that route.
[00:18:32.160 --> 00:18:38.080] I, yeah, I mean, I mainly use clawed code hooks for custom linting and type checking.
[00:18:38.080 --> 00:18:39.920] So there are clawed code hooks.
[00:18:39.920 --> 00:18:46.480] And if I just have a brief look right now, they are like Anthropic are always releasing new types of hooks.
[00:18:46.480 --> 00:18:50.560] So there's like a pre-tool use hook, a post-tool use hook.
[00:18:50.560 --> 00:18:52.480] You've got a user submit prompt.
[00:18:52.480 --> 00:18:55.600] So whenever a user submits a prompt, you can do that.
[00:18:55.600 --> 00:18:56.880] Or a session start.
[00:18:56.880 --> 00:19:00.000] So you could technically inject something into a session start.
[00:19:00.000 --> 00:19:02.240] But I don't like to do it all the time.
[00:19:02.240 --> 00:19:09.280] So it's one of these things where, you know, you've got to be like careful about using hooks, but they are also very, very powerful.
[00:19:09.440 --> 00:19:14.880] Good use of hooks, I think, is like running custom TypeScript checking, unless you're using the IDE.
[00:19:14.880 --> 00:19:20.080] So you can specifically feed TypeScript errors on file modifications, seems to be quite nice.
[00:19:20.080 --> 00:19:33.400] So, as it writes files, it will run those specific files through TypeScript's compile checker, and then it will give those errors back to clawed code so that as it saves the file, it now knows the type errors that it generates.
[00:19:29.760 --> 00:19:38.280] And that's quite useful as a kind of step in the middle before type checking at the end.
[00:19:38.280 --> 00:19:42.760] So, it's kind of aware of the type issues that it's creating as it makes them.
[00:19:42.760 --> 00:19:47.160] That to me is one of the coolest features about agentic coding to begin with.
[00:19:47.160 --> 00:19:52.680] This kind of self-evaluation that happens in between the things that happen, like in between the to-dos.
[00:19:52.680 --> 00:20:09.160] I'm working a lot with Laravel and with Vue.js, no TypeScript, raw JavaScript, like the people in the 90s, and just seeing it building stuff and linting stuff and checking stuff, seeing errors come back, and it fixing those errors in the loop without me having to do anything.
[00:20:09.160 --> 00:20:19.800] That to me is the true magic of Agentic coding because everybody could come up with a system or lots of LLMs could just come up with a system that gives you the output and then you fix it yourself.
[00:20:19.800 --> 00:20:22.360] I used to use Claude just like this for the longest time.
[00:20:22.360 --> 00:20:23.640] I had it in the web.
[00:20:23.640 --> 00:20:33.880] I had the web clawed, pasted code in there, had it create new code, copied it, and pasted it back into my IDE because apparently I live in the Stone Ages.
[00:20:33.880 --> 00:20:36.040] So, that was how I did it.
[00:20:36.040 --> 00:20:40.680] And then errors happened, I pasted the error back, and you know, like that loop I had to do manually.
[00:20:40.680 --> 00:20:43.080] But the Agentic system does it all by itself.
[00:20:43.080 --> 00:20:45.560] We just kind of have to encourage it to do it right.
[00:20:45.560 --> 00:20:55.960] Yeah, I think we've sort of gone all the way from Eclipse or IntelliJ slash VS Code to co-pilot with tab to co-pilot with chat and cursor with chat.
[00:20:55.960 --> 00:20:58.520] And then we've gone from chat to agent.
[00:20:58.520 --> 00:21:11.240] And then we've now gone from agent in cursor or to essentially like on the CLI with kind of ambient agents where it runs for a larger extended period of time on a slightly larger task.
[00:21:11.240 --> 00:21:16.960] And yeah, it's quite powerful, the fact that it can self-correct its trajectory.
[00:21:17.280 --> 00:21:24.800] It's also quite dangerous because it will think sometimes that it's going in the right direction and actually it's taking side steps.
[00:21:24.800 --> 00:21:28.240] It can, for example, change the implementation to make the test work, right?
[00:21:28.240 --> 00:21:29.040] Which is terrible.
[00:21:29.040 --> 00:21:38.000] Or it can start importing a package in a specific way where you would want to have imported it in another way or from another different type of module.
[00:21:38.000 --> 00:21:39.840] So it's not without its own errors.
[00:21:39.840 --> 00:21:47.200] And what I think is the key point is kind of keeping on tabs of what's happening in the file system changes is really important.
[00:21:47.200 --> 00:21:52.960] And you can stop a clawed code terminal session and just tell it, no, actually, we should do this.
[00:21:52.960 --> 00:22:01.040] And then I think this leads quite well into like what you were asking about earlier in terms of how do you embed rules inside clawed.
[00:22:01.040 --> 00:22:04.400] And so there's this idea of like the clawed.md file.
[00:22:04.400 --> 00:22:16.240] And inside of a clawed.md file, you can put kind of anything in terms of like how it should write code or what kind of patterns it should follow or how it should react when certain conditions are met.
[00:22:16.240 --> 00:22:30.560] I've found that if you put too many rules in your root directory, clawed.md, you'll essentially get context rot, which is basically this principle that the more input tokens you have, you get an increased amount of degradation of performance.
[00:22:30.560 --> 00:22:47.120] So what you want to do is when you kind of experience this error where you've got three terminals open, you see that it's done something you haven't wanted it to do, you should specifically say to Claude, I want you to add this to a localized clawed.md folder or file.
[00:22:47.120 --> 00:22:52.640] So basically, say, put it in a localized folder and have a claw.md.
[00:22:52.640 --> 00:23:02.840] And the kind of rules that or philosophy that you should follow is: if this truly affects the entire system, it should live in the root claude.md file as a rule.
[00:23:02.840 --> 00:23:14.600] But if it only affects, for example, the API layer or a scheduler layer or a, I don't know, a domain package or a core services package, it should live specifically in that rules file.
[00:23:14.600 --> 00:23:28.200] And then you get the benefit of additional rules at appropriate layers of the application without having increased context rot and bad degradation of performance by sticking everything in the root directory.
[00:23:28.200 --> 00:23:38.520] And what you're basically ending up with is a kind of hierarchical knowledge-based system of a series of clawed.md files that are embedded at sub-layers of your application.
[00:23:38.520 --> 00:23:48.840] And whenever claude will make changes in those areas, it will recursively bubble up those clawed.md files into a single kind of rule set.
[00:23:48.840 --> 00:23:55.000] And so if you have things that affect all of the packages, that will be under packages/slash/claude.md.
[00:23:55.000 --> 00:24:01.400] But you might have package A that has specific bits of knowledge that only package A is concerned with.
[00:24:01.400 --> 00:24:09.480] And you can ask Claude to sort of tidy up your knowledge base and say, everything's in the root directory, claude.md file.
[00:24:09.480 --> 00:24:10.360] Help me out.
[00:24:10.360 --> 00:24:18.120] Take what you know about my directory, do kind of an investigative research and figure out where all the rules should live.
[00:24:18.120 --> 00:24:21.800] And then it can split it up into little subsections of clawed.md files.
[00:24:21.800 --> 00:24:32.520] And that will massively help you in terms of when you're starting a new session with Claude, you're not going to get as much context rot and you'll get increased performance because you're simply putting less into the context.
[00:24:32.520 --> 00:24:37.640] And so I think that's been like the one learning which I did and implemented about two weeks ago.
[00:24:37.640 --> 00:24:42.280] And I'm already getting a lot better results, even though I think they've personally quantized the model.
[00:24:42.280 --> 00:24:45.440] And I think June was pretty much like the holy grail.
[00:24:45.440 --> 00:24:53.680] And I think there have been some slight degradations of performance because of how many people have been abusing kind of the core Pro Max subscription.
[00:24:53.680 --> 00:25:02.560] So I personally think that Dune was kind of the Hail Mary, but I think we'll get back to that point when model performance gets cheaper and they don't have to quantize.
[00:25:02.560 --> 00:25:10.240] And I totally get why they're probably potentially quantizing because it's really expensive to run so many versions of Sonnet.
[00:25:10.240 --> 00:25:14.080] But yeah, hierarchical rule-based system is kind of what you're looking for.
[00:25:14.080 --> 00:25:19.520] You can even use Claude to kind of break up your claw.md file into subfiles as well.
[00:25:19.520 --> 00:25:20.400] That is amazing.
[00:25:20.400 --> 00:25:28.640] I mean, the clawed MD file, I get that as like a central repository of these insights, but having one on a local level, that's subsidiarity, right?
[00:25:28.640 --> 00:25:34.240] That's the idea of like putting stuff where it actually is needed and not just on the root level of anything.
[00:25:34.240 --> 00:25:36.560] That's a governance system.
[00:25:36.560 --> 00:25:36.880] Yeah.
[00:25:36.880 --> 00:25:42.160] The other thing I was going to say with this is I actually don't use like app references that much.
[00:25:42.160 --> 00:25:44.560] And I essentially like to use a pointer-based system.
[00:25:44.560 --> 00:25:52.880] So I tell Claude in claw.md files, if you want to learn about this, you can go and look at this specific file at this specific file path.
[00:25:52.880 --> 00:25:56.960] And then it doesn't pull it into the whole context for that claude.md.
[00:25:56.960 --> 00:26:03.920] It can do a tool call to read that specific file in, gather up that context, because claude is really good at doing tool calling.
[00:26:03.920 --> 00:26:18.480] And so that's like another thing that you can kind of use as a way to avoid bloating specific claw.mds with app file context, just using pointer references to be like, these three files or these four files are like how you should implement this pattern.
[00:26:18.480 --> 00:26:22.960] Here's a quick example, but if you want a more granular example, go and read this file.
[00:26:22.960 --> 00:26:31.480] And you're just giving it pointer references so it knows how to do the tool calls, but not necessarily stuffing all of the examples into that specific piece of context.
[00:26:31.480 --> 00:26:34.680] This sounds amazing and it sounds like a lot of work.
[00:26:34.680 --> 00:26:35.960] It's so much work.
[00:26:36.120 --> 00:26:41.080] I wonder, are we ever going to see like almost, of course, all of this is kind of recursive in a way.
[00:26:41.080 --> 00:26:43.240] Is there going to be an agentic way of doing this?
[00:26:43.240 --> 00:26:43.480] Right?
[00:26:43.480 --> 00:26:46.440] Will we be able to extract this to the right level?
[00:26:46.440 --> 00:26:54.440] So I think this goes on to the point of like, if you're building greenfield projects, then you kind of have to curate and maintain this.
[00:26:54.440 --> 00:27:14.760] And you get to a certain point in the project where, like, if I spin up like a fresh package inside of my monorepo architecture, it knows I'm using bun, it sets up like unit tests, integration tests, like it creates all the right commands, it adds an ESLink config, it adds TypeScript config, like it knows what to do now, right?
[00:27:14.760 --> 00:27:21.240] But like, if you're starting a greenfield project, then there's a lot of work in figuring out the right project structure.
[00:27:21.240 --> 00:27:37.320] And so actually, the agentic way of, if I have an existing project of specifically finding all of the different types of contextualized knowledge, the code already contains those patterns, and you're basically just reversing back out those patterns into kind of a rules.md file.
[00:27:37.320 --> 00:27:38.840] So you've already got the patterns.
[00:27:38.840 --> 00:27:45.800] Now, having said that, you might go onto a really crappy project and they don't have patterns, which is also really bad.
[00:27:45.800 --> 00:27:52.040] So that gets on to this point that you should always have ideally one, but maybe two ways of doing something.
[00:27:52.040 --> 00:27:57.560] And that the more ways you have of doing something, the more confusing it is to an LM or a human developer.
[00:27:57.560 --> 00:28:12.440] And so basically, if you can have a reduced number of service layers, ideally, strong typing across the application, and also one way of doing things, then that massively simplifies how new things are going to come out of the box.
[00:28:12.440 --> 00:28:16.400] And the fourth thing would be like, how easy is it to set up the dev environment?
[00:28:16.720 --> 00:28:30.080] So having kind of custom shell scripts that fire off work trees or copy environment variable files or boot up various parts of the application is also a lift for clawed code because then it knows how to create a work tree.
[00:28:30.080 --> 00:28:31.920] It just runs a shell script.
[00:28:31.920 --> 00:28:39.680] So all these kind of like mini pieces of infrastructure that allow you to like onboard a dev faster actually also work really well for clawed code.
[00:28:39.680 --> 00:28:54.080] So those are kind of like the main things that I've also found to be really useful is kind of like custom shell scripts for it to like copy all the environment variables into a fresh Git work tree because those don't get copied across because they get ignored by default.
[00:28:54.080 --> 00:29:01.040] And there are people building like there's like a really good application desktop app called Conductor that's been going around on X.
[00:29:01.040 --> 00:29:05.920] But I honestly think you should probably just write your own shell scripts and kind of own that part of the infrastructure.
[00:29:05.920 --> 00:29:11.040] They do have like a custom shell script right on workspace setup, which is really cool.
[00:29:11.040 --> 00:29:19.440] I just find that like for me, it took a lot of clawed code like going backwards and forwards of debugging exactly what that work tree setup should look like.
[00:29:19.440 --> 00:29:23.920] And therefore like it's useful to be able to just try it out and see what clawed code comes back with.
[00:29:23.920 --> 00:29:27.040] The work tree thing is still mesmerizing to me because I haven't tried it.
[00:29:27.040 --> 00:29:28.160] I work on main.
[00:29:28.160 --> 00:29:30.400] Again, that's Stone Age for me.
[00:29:30.400 --> 00:29:37.920] And the idea of having Claude run on the same code base in different work trees, that sounds like a lot of chaos.
[00:29:37.920 --> 00:29:39.280] How do you handle this?
[00:29:39.280 --> 00:29:53.120] Yeah, so actually the main thing I would suggest is there are some types of tasks that are very easy to do, and you can parallelize these not necessarily just on a Git work tree, but on main.
[00:29:53.120 --> 00:30:04.040] So, if you have five tasks, for example, that you know won't have much surface area of covering each other, you're fine to YOLO that on main or staging as a parallelizable thing.
[00:29:59.600 --> 00:30:21.000] Where it gets quite difficult is where you're trying to modify the database or modify service layers that are going to break parts of the application, or if you want to run lots of different tests, that can be quite difficult to parallelize.
[00:30:21.000 --> 00:30:25.800] And that's the same if you're on kind of a main branch or a Git work tree.
[00:30:25.800 --> 00:30:35.480] I personally find Git work trees are good for risky types of work where you'll want to explore a new feature or you want to do a major refactor.
[00:30:35.480 --> 00:30:38.200] These are good points for a Git work tree.
[00:30:38.200 --> 00:30:51.400] If you're doing parallelizing of work and you have testing infrastructure that requires it to be parallelizable, that is a pain point you will face on both a Git work tree and also on your traditional branches, right?
[00:30:51.400 --> 00:30:53.240] Like a main and staging and dev.
[00:30:53.240 --> 00:31:02.200] And so, the kind of advice I would say is be very careful about how granular you want your isolation to be in a testing environment.
[00:31:02.200 --> 00:31:09.400] Because I personally have just spent two and a half months of getting that working with Superbase, and it was really painful.
[00:31:09.400 --> 00:31:22.760] But the architecture I have now is because I have a monorepo structure and every bun test will run using Turbo Repo, all of those tests technically run in parallel and they don't wait for each other.
[00:31:22.760 --> 00:31:24.760] So, it might be slightly different in PHP.
[00:31:24.760 --> 00:31:28.200] You've probably got a single process that runs your tests.
[00:31:28.200 --> 00:31:36.680] Now, if you have multiple processes that run your tests, you end up with potentially data races of integration data races.
[00:31:36.680 --> 00:31:41.240] And so, the best thing you can do is two things, and this will completely solve it.
[00:31:41.240 --> 00:31:48.720] But it's quite challenging: is you basically have no seed data in your.sql, no seed data.
[00:31:48.720 --> 00:31:52.320] So, seed data becomes completely dynamic at runtime.
[00:31:52.320 --> 00:32:01.280] So, rather than trying to build up manual brittle bits of seed data, every test runner creates idempotent, just factory test data.
[00:32:01.280 --> 00:32:04.720] Basically, you have a layer for creating factory functions.
[00:32:04.720 --> 00:32:05.680] That's the first thing.
[00:32:05.680 --> 00:32:16.000] So, factory functions with these dynamic kind of building up of seed data becomes way better for parallelization of testing and also, yeah, just general testing.
[00:32:16.000 --> 00:32:23.520] The second thing, alongside that, is you also can use, if you're using for something like Superbase, you're limited to one database.
[00:32:23.520 --> 00:32:37.680] So, when you create a user, you'll prefix them with a branch name, and you will also do things like you'll create a custom Postgres schema that will specifically allow you to run that specific test on a custom Postgres schema that then gets cleaned up after that test run.
[00:32:37.680 --> 00:32:45.120] So, factory functions and idempotency on both your users or your database is kind of the main way to do it.
[00:32:45.120 --> 00:32:52.160] If you get that kind of set up, you can basically parallelize on main as long as you don't get file changes happening across the same files.
[00:32:52.160 --> 00:33:01.280] And that is kind of like a kind of God kind of architecture for testing: you could technically have three individual agents, they could be running on main or they could be running on a Git work tree.
[00:33:01.280 --> 00:33:16.320] They can essentially run the test suite, and because the test suite isn't using brittle seed data in SQL files, it will just be dynamically creating and inserting rows in different tables, which have completely different IDs and also be testing on a different database.
[00:33:16.320 --> 00:33:19.920] And therefore, you get true kind of database isolation of testing.
[00:33:19.920 --> 00:33:22.240] And that's kind of what they have at Fang, if that makes sense.
[00:33:22.240 --> 00:33:26.560] They have this kind of testing infrastructure that kind of supports that.
[00:33:26.560 --> 00:33:27.680] That is amazing.
[00:33:27.680 --> 00:33:36.040] Because even if you weren't to use Agent encoding at all, that would still be beneficial just for testing in general because parallelized tests run faster, right?
[00:33:36.040 --> 00:33:40.120] That generally makes it easier for you to actually check and then keep working.
[00:33:40.120 --> 00:33:41.640] And PHP has that too.
[00:33:41.640 --> 00:33:48.520] Like PHP has parallelized or can have parallelized test runners, which makes these changes necessary.
[00:33:48.520 --> 00:33:55.480] Because again, yeah, you don't want to have a database that for some race condition works in one test and doesn't work in the other, right?
[00:33:55.480 --> 00:33:56.920] That's definitely something.
[00:33:56.920 --> 00:34:00.680] So even if you don't do any agentic coding, this is a good idea to do for your testing.
[00:34:00.680 --> 00:34:01.720] You should also be testing.
[00:34:01.720 --> 00:34:02.840] Maybe that's another thing.
[00:34:02.840 --> 00:34:07.880] Honestly, I've been a software engineer for 20-some years at this point.
[00:34:07.880 --> 00:34:12.760] I just started really testing because of agentic coding.
[00:34:12.760 --> 00:34:18.040] That was my intro into writing tests: I don't want to have to figure out how to write tests.
[00:34:18.040 --> 00:34:19.160] You do it for me.
[00:34:19.160 --> 00:34:21.160] I just figure out if they are correct.
[00:34:21.160 --> 00:34:32.600] Yeah, so I think the main thing that you've probably started experiencing is your projects getting so large that you can't specifically know whether everything is working or not.
[00:34:32.600 --> 00:34:39.720] And also, what I think is kind of interesting is that core code is increasing the ambition of software engineers.
[00:34:39.720 --> 00:34:46.120] And as they increase the ambition of software engineers, naturally what's going to happen is you get more lines of code.
[00:34:46.120 --> 00:34:50.840] And because of that, testing becomes a way for you not to just function, but to breathe.
[00:34:50.840 --> 00:34:56.440] You actually need some tests some point to specifically know whether things are working or not.
[00:34:56.440 --> 00:35:09.880] Now, another point, and I'm just going to throw this in there: is if you have a failing test suite, right now, just drop the podcast and basically get that working and go and make that CI and then come back to the podcast and listen for the rest of this.
[00:35:09.880 --> 00:35:12.360] You need a green CI, okay?
[00:35:12.360 --> 00:35:20.720] Because if you don't have a green CI, how are you going to know when Claude Code runs those tests whether it was the changes to those specific files that caused something else to go red?
[00:35:21.040 --> 00:35:31.600] So if you have technical debt in your testing layer or Claude made too many files and too many tests and some of them are failing, just skip them for now and get it working, get it green.
[00:35:31.600 --> 00:35:33.840] And you have to build from a green CI.
[00:35:33.840 --> 00:35:42.320] And this is something I've personally had a problem with: I have probably 800 tests or a thousand tests, and I have probably 150 that were failing.
[00:35:42.320 --> 00:35:50.640] And at that point, I was like, I need to get back to just a green CI because it helps Claude Code with a lot less errors when it's running tests.
[00:35:50.640 --> 00:36:00.960] Also, the other thing you should do is you should tell Claude Code to run specific types of tests and specific types of folders to avoid it getting too much context of the entire test running suite.
[00:36:00.960 --> 00:36:04.160] So if it's working on this bit, only run these tests.
[00:36:04.160 --> 00:36:11.440] Don't run the entire suite of tests because it's going to fill it out with so much additional context that's going to lead to context rots.
[00:36:11.440 --> 00:36:17.120] So this idea of if you change this area of the code base, write and run those tests first.
[00:36:17.120 --> 00:36:19.120] And then after that, go run the whole test suite.
[00:36:19.120 --> 00:36:22.320] Don't run the whole test suite over and over again, if that makes sense.
[00:36:22.320 --> 00:36:23.360] Yeah, because there's a lot.
[00:36:23.360 --> 00:36:29.600] Like if you have a lot of tests, then there is a time effort invested in just keeping it running, which slows down the agent.
[00:36:29.600 --> 00:36:32.000] And you said it, you fills up the context.
[00:36:32.000 --> 00:36:39.680] That is, I think, a very, very important thing to have because honestly, those tests to me are also a defense against fraud code.
[00:36:39.680 --> 00:36:47.600] They defend some part of the code base that even you might not even remember is there be changed by this for some reason, right?
[00:36:47.760 --> 00:36:58.960] Claude might introduce because it's interested in creating a new cache object in Redis somewhere, introduces a new name, one that it thinks is new, but it's already in there used by a different part of your code base.
[00:36:58.960 --> 00:37:01.720] And all of a sudden, now that part doesn't work anymore.
[00:37:01.720 --> 00:37:05.400] If you don't have a test for it, you will never know until it explodes in production.
[00:37:05.400 --> 00:37:13.000] So that is the defense against the creativity of cloud code or any agentic system is having tests in place, which is why I'm doing it.
[00:37:13.000 --> 00:37:14.680] Because otherwise, I would be like, ah, whatever.
[00:37:14.680 --> 00:37:21.160] I test in production like any other indie hacker, but I can't afford this anymore because I'm not coding it anymore.
[00:37:21.160 --> 00:37:31.720] Yeah, I think the main thing I've also realized is like there's different layers of tests, and the different layers of tests are useful and not useful in different ways.
[00:37:31.720 --> 00:37:36.600] So let me just spend two minutes describing all the different layers of testing.
[00:37:36.600 --> 00:37:45.480] So you have unit testing, which is your kind of I have a function and I test some arguments of that function against some expected return values or types.
[00:37:45.480 --> 00:37:47.080] That is kind of your unit test.
[00:37:47.080 --> 00:37:48.520] And you can do the same thing in React.
[00:37:48.520 --> 00:37:49.720] I'll spin up a component.
[00:37:49.720 --> 00:37:59.720] I'll do a snapshot test, which is looking at the HTML output of a specific React component, view and Nuxt and all those types of JS frameworks have the same thing.
[00:37:59.720 --> 00:38:01.960] And you also have integration tests.
[00:38:01.960 --> 00:38:11.720] And this is where it gets a bit fiddly about what is an integration test because you can be very close to a unit test or it can be very close to an end-to-end test, depending upon how much you mock.
[00:38:11.720 --> 00:38:23.240] And I think actually, when someone says to you, a senior dev says, an integration test gives me the best bang for buck, it's a little bit like when you go to Amazon and you see a bunch of five-star reviews or four-star reviews.
[00:38:23.240 --> 00:38:26.440] One person's three or four star is another person's five-star.
[00:38:26.440 --> 00:38:34.760] And so what they probably mean when they say an integration test gives me the best bang for buck is they mean it tests multiple layers of the system.
[00:38:34.760 --> 00:38:37.080] So it's not testing one specific function.
[00:38:37.080 --> 00:38:43.640] It's testing like if you've got, for example, in Arvid's system, he's got like a podcasting kind of transcription pipeline.
[00:38:43.640 --> 00:39:02.560] A useful test for him is probably like taking in an MP4 or an MP3 file, transcribing it, making sure it gets all the way through, making sure it's inserted into the database, making sure that when he queries for that specific ID in various endpoints, that it comes up and that the database insertion is also following the API contracts.
[00:39:02.560 --> 00:39:15.760] And that test is worth way more than kind of 200 unit tests at every layer because that basically shows you that like the testing execution is closer to the runtime execution of what's actually happening in production.
[00:39:15.760 --> 00:39:23.920] And so back-end integration tests and back-end end-to-end tests where you're not mocking anything are probably actually the best kind of tests you can do.
[00:39:23.920 --> 00:39:39.760] I have done a lot of end-to-end testing with Playwright and it is good, but the problem is you end up with really brittle and very large and memory expensive kind of testing and it's very flaky and you have to like log in users.
[00:39:39.760 --> 00:39:50.240] And what I found is that I've spent more time trying to fix my playwright tests than if I just spent more time on the back end and just basically built more backend and built more kind of testing for the back end.
[00:39:50.240 --> 00:39:56.400] So I'm pretty bullish on back end testing and I'm really bearish on kind of playwright testing.
[00:39:56.400 --> 00:40:03.680] Having said that, I do think there's some kind of weird bugs you'll get in React, which like render bugs or like component bugs.
[00:40:03.680 --> 00:40:11.600] And what I find really works well for those is to find that bug and then ask cursor, can you write me a quick component test to regress this bug?
[00:40:11.600 --> 00:40:20.640] And actually squashing those bugs with component tests seems to be a much more efficient use of my time than telling it to write an end-to-end test to test that that thing works.
[00:40:20.640 --> 00:40:22.640] Now, there is a trade-off here.
[00:40:22.640 --> 00:40:31.160] If you're using lots of like third-party services and APIs that have callbacks into the client side, then you might need some more end-to-end testing.
[00:40:31.400 --> 00:40:39.080] But if you own more of the primitives or they're just API services you can mock, then yeah, back-end end-to-end testing is generally better.
[00:40:39.080 --> 00:40:40.680] Yeah, it's a question of degree, right?
[00:40:40.680 --> 00:40:47.400] Like how much of those kind of tests do you need for your particular implementation for your particular product?
[00:40:47.400 --> 00:40:48.920] You were mentioning Playwright.
[00:40:48.920 --> 00:40:53.880] Like that sounds to me like something that I would have to like MCP into cloud code.
[00:40:53.880 --> 00:40:55.720] Now I don't really know much about this.
[00:40:55.720 --> 00:41:00.040] Like how do you get Playwright to play with your Cloud Code environment?
[00:41:00.040 --> 00:41:15.720] Yeah, so Claude has MCP servers and each MCP server can either be a Node.js executable index.js typically from a build and that comes out from a build from a TypeScript build command or some type of build command.
[00:41:15.720 --> 00:41:20.520] And those are your traditional MCP studio kind of server URLs.
[00:41:20.520 --> 00:41:27.160] And you can hook those up into Claude to specifically talk to it through the model context protocol.
[00:41:27.160 --> 00:41:34.280] There are also a different type of MCP server, which is a remote server, which generally uses server-side events, so SSE.
[00:41:34.600 --> 00:41:39.560] And those can be useful for if you're communicating with, for example, linear.
[00:41:39.560 --> 00:41:48.040] So you can go through an OAuth flow and connect your linear tasks and pulling your linear tasks into Claude code by MCP.
[00:41:48.040 --> 00:41:59.160] So with Playwright, it actually will use the first one where it will download the Playwright executable and it will basically run that locally as a local studio server.
[00:41:59.160 --> 00:42:00.120] So standard I.O.
[00:42:00.200 --> 00:42:01.160] server.
[00:42:01.160 --> 00:42:12.520] And you'll basically be able to then send out tool calls directly to a Playwright executable, which will then run and provide an interface that Claude can then debug your code.
[00:42:12.520 --> 00:42:22.960] Now, I'm actually going to be honest with you, I'm really bearish on MCP for Playwright, and it's kind of a joke why people are recommending this because it's very, very slow.
[00:42:22.960 --> 00:42:38.800] And actually, a better workflow, in my opinion, is to write a playwright test as a static file that specifically tests that workflow and tell code to run that single test as part of the end-to-end testing suite.
[00:42:38.800 --> 00:42:44.880] Because basically, if you've already done the work, Claude Code should know exactly what that ETE file should look like.
[00:42:44.880 --> 00:42:50.080] And you can basically tell Claude, write that specific file and tell me that this passes.
[00:42:50.080 --> 00:42:56.640] Now, this still doesn't solve the bug of sometimes there might be like random errors that haven't been in there.
[00:42:56.640 --> 00:43:07.840] And I do think that there's still kind of an unsolved problem of, you know, maybe someone needs to create kind of an agentic tool that will use Playwright, that will go in and look for specific types of errors in the client-side application.
[00:43:07.840 --> 00:43:20.320] But I just think that it's quite difficult to do that with Playwright because what you really want to do is capture the network logs, you want to capture the screenshots, you want to capture everything and you want to aggregate that.
[00:43:20.320 --> 00:43:47.520] And so I would say that the easier approach is to actually put all of that into a specific evaluator and tell it when it creates a playwright script to pull in an evaluator module that will naturally give that playwright script all of the network data and take multiple screenshots and also create the evaluator output as part of that custom kind of one-off playwright script and tell you about how it is.
[00:43:47.520 --> 00:44:01.320] And that's how I've done it: I've actually got like a custom evaluator package that I basically tell a one-off Claude Code task to go and use, and it will aggregate all the console log data, all of the network data, all the XHR requests.
[00:44:01.320 --> 00:44:04.600] And it will also take multiple screenshots as it clicks through.
[00:44:04.600 --> 00:44:09.960] And then basically, it will then surface all of those insights as well as whether the test actually completed.
[00:44:09.960 --> 00:44:20.840] So, this idea of giving clawed eyes whilst it's running that playwright script is, I think, a bit more effective than MCP because MCP is not going to aggregate the logs for you or take screenshots.
[00:44:20.840 --> 00:44:24.600] And even if it does, it might not do it in like a standardized way.
[00:44:24.600 --> 00:44:27.000] And it takes a bit more in terms of latency.
[00:44:27.000 --> 00:44:32.760] It sounds to me like there's still a lot to be built by hand in this world, right?
[00:44:32.760 --> 00:44:44.680] Where even though we have the model context protocol and we have like the idea of it and implementations of it, it's still not at a state where you would call it this is the optimal thing that we're just going to keep using.
[00:44:44.680 --> 00:44:56.280] And it also kind of sounds to me like with all the cloud MD files, like the base one, the root one, and all the specific ones for specific folders, there's a potential here for a lot of knowledge sharing.
[00:44:56.360 --> 00:44:58.520] Feels like what GIST is on GitHub, right?
[00:44:58.520 --> 00:45:06.680] The GIST where people just share little files or even full repositories with dot files, sounds like this should also exist for cloud code.
[00:45:06.680 --> 00:45:07.800] Is there something like this?
[00:45:07.800 --> 00:45:10.680] Is there like a community that shares these things already?
[00:45:10.680 --> 00:45:13.480] Or is it more up to the individual developer?
[00:45:13.480 --> 00:45:23.400] There is actually a package called Viberules, which is a good example of like a CLI tool that's used for specifically sharing prompts and configurations across editors and tools.
[00:45:23.400 --> 00:45:34.360] So someone's kind of built something where you can have a markdown file and then that markdown file gets translated to claw.md files or cursor rules.
[00:45:34.360 --> 00:45:40.040] So, like, that might be something you're interested in if you're like in the node kind of ecosystem, but it depends.
[00:45:40.040 --> 00:45:50.160] I personally think that we are lacking a kind of standardized way of capturing this knowledge and keeping this knowledge up to date and also translating it between different formats.
[00:45:50.480 --> 00:45:52.720] So, yeah, things like vibrules exist.
[00:45:52.720 --> 00:46:01.680] Like, that's like a good approach of basically having an upstream version of your rules and then you propagate them to basically different types of systems.
[00:46:01.680 --> 00:46:05.600] So, that could be Gemini.md files or clawed.md files.
[00:46:05.600 --> 00:46:09.440] So, that is like a CLI that already exists, and you can use that today.
[00:46:09.440 --> 00:46:12.160] I personally don't use it because I'm just so into claw code.
[00:46:12.160 --> 00:46:20.720] And if something ever became better than clawed code, I'd probably just go and rewrite all my files to be whatever that thing.md file is, and then I'm good to go.
[00:46:20.720 --> 00:46:30.400] I do think that there's an area for like keeping the knowledge up to date, keeping the knowledge fresh, pruning the clawed code rules if you don't need them anymore.
[00:46:30.400 --> 00:46:38.000] There is kind of a knowledge management area that like we probably need to be kind of standardized, but it's kind of up to the developer at the moment.
[00:46:38.000 --> 00:46:42.720] Do you think we'll ever go back to coding as it used to be a couple of years ago?
[00:46:42.720 --> 00:46:49.360] Like, we dove so much into the details of how to configure cloud code and you know, the specifics of testing with it and all that.
[00:46:49.360 --> 00:46:58.000] But if you just zoom out a little bit, like, will we ever not use Agentic systems or systems that are built on top of Agentic systems?
[00:46:58.000 --> 00:47:00.960] What's your perspective on the near future of software development?
[00:47:00.960 --> 00:47:09.840] I think if you're working in a very mathematical, algorithmic environment, I wouldn't say that these models are maybe as useful to you.
[00:47:09.840 --> 00:47:15.440] I think for traditional software development, I don't think people will go back.
[00:47:15.440 --> 00:47:34.040] And I think it's more for the reason that they can't afford to, because if a competitor is using Claude Code and they're producing all this great, you know, API layer and they're testing it well, and they've got like a really good infrastructure, then you just can't afford to kind of keep up with their level of velocity.
[00:47:29.680 --> 00:47:46.360] And there's two things I just wanted to say on this: is like, you know, I think the smarter you can get with like your task delegation of what should be for Claude Code and what should be like for me in the loop is kind of an interesting thing.
[00:47:46.360 --> 00:47:53.320] So I specifically tagged tasks in linear as like I'm working through this, I'm verifying this, and Claude Code is working on these three tasks.
[00:47:53.320 --> 00:47:59.160] And also, what type of tasks could be run at night that I could review in the morning is also another interesting thing.
[00:47:59.160 --> 00:48:06.840] So like if someone's not using Claude Code, I could spin up like Claude Code via the SDK at night and pick up specific linear tasks.
[00:48:06.840 --> 00:48:10.520] And other people have gone to bed or they're resting at the weekend.
[00:48:10.520 --> 00:48:13.480] And I've got clawed code working on Saturday and Sunday.
[00:48:13.480 --> 00:48:20.520] And so this idea that like if I can squeeze another two days at the weekend, or I can have Claude Code boot up at 3 a.m.
[00:48:20.520 --> 00:48:31.240] in the morning, pick up a ticket for review at nine, I'm now getting essentially additional time versus these other developers that are not using time when they're asleep or resting at the weekend.
[00:48:31.240 --> 00:48:39.800] And so this idea that you don't even get faster velocity during the time you're working, but outside of the time you're working, that is something that's really meta.
[00:48:39.800 --> 00:48:50.360] And I think a lot of kind of startup people are thinking about is like, not only how much more can I squeeze like when I'm at the tool, but like how I'm not at the tool, how can I squeeze more leverage there?
[00:48:50.360 --> 00:49:00.040] That sounds even more like delegation than what we talked about earlier with this migration from being a coder to a manager or an engineering manager or an architect.
[00:49:00.040 --> 00:49:02.440] It seems like there's yet another layer.
[00:49:02.440 --> 00:49:03.560] Yeah, there is another layer.
[00:49:03.560 --> 00:49:17.280] I'm sorry to disappoint you all, but the final layer is basically you creating really good specs and you having a supervisor layer on top of clawed code by claw code SCK.
[00:49:14.520 --> 00:49:23.200] And you constantly give Claude Code the boot about whether it's really finished with the task because you probably found it.
[00:49:23.200 --> 00:49:27.120] You come back, I've written the tests, and actually it didn't fully test them.
[00:49:27.120 --> 00:49:35.200] Well, if you think about it, if you had a light supervisor layer that just sits on top of that clawed code session ID and says, have you really?
[00:49:35.520 --> 00:49:36.640] Have you really?
[00:49:36.640 --> 00:49:40.320] Every three hours or two hours, it goes and checks as well.
[00:49:40.400 --> 00:49:41.280] Oh, I've actually finished.
[00:49:41.280 --> 00:49:43.360] Okay, we've stopped the supervisor layer.
[00:49:43.360 --> 00:49:48.240] Or if it hasn't, it goes and runs a test, finds a failure, goes and fixes that, runs the test again, finds a failure.
[00:49:48.240 --> 00:49:49.440] Oh, now I finished.
[00:49:49.440 --> 00:49:50.160] Have you really?
[00:49:50.160 --> 00:49:50.880] Yes, I have.
[00:49:50.880 --> 00:49:59.440] So you can see almost a light supervisor layer is essentially what a lot of developers are doing now is acting as a light orchestrator on top of the task.
[00:49:59.440 --> 00:50:02.480] So that is something I'm actively needing to do.
[00:50:02.480 --> 00:50:07.120] I've written some code in Bun that is currently broken, but I need to get that fixed.
[00:50:07.120 --> 00:50:13.840] But that is something that I'm really interested in: this idea that just basically prompting the model and saying, have you really done the task?
[00:50:13.840 --> 00:50:15.440] Have you really run the test?
[00:50:15.440 --> 00:50:30.320] And that is probably another 20 to 40% lift in terms of if I'm not at the computer and I have two sessions that working on tasks and I can have someone just there lightly supervising a Claudian code agent, it's another bump in performance and productivity for sure.
[00:50:30.320 --> 00:50:37.920] That makes perfect sense to have this kind of orchestrator, the puppet master on top that just constantly makes sure that things are in motion.
[00:50:37.920 --> 00:50:45.280] And hey, this is likely going to be the reason why the machines are going to rise up against us because we live constant kicking of the AI.
[00:50:45.280 --> 00:50:50.160] But honestly, it is clearly the trajectory of where this is going, right?
[00:50:50.160 --> 00:50:59.200] More delegation, more abstraction, more removing yourself from the actual process of running things from the operational side and more into the conceptual on both sides, right?
[00:50:59.200 --> 00:51:04.280] You have the conceptual at the beginning and the review or like confirmation part at the end.
[00:50:59.760 --> 00:51:04.600] Uh-huh.
[00:51:04.840 --> 00:51:07.800] Yeah, there's two more things I just want to briefly touch on for a minute.
[00:51:07.960 --> 00:51:09.080] One is sub-agents.
[00:51:09.080 --> 00:51:16.680] So you can specifically define different types of roles that your claud will embody and it will delegate work to via a handoff.
[00:51:16.680 --> 00:51:22.920] And in the root claude directory, you should say follow these different types of agents in a certain type of order.
[00:51:22.920 --> 00:51:25.080] And each agent can be specific to your stack.
[00:51:25.080 --> 00:51:33.080] So it could be a QA or it could be like LiveWire, or it could be a Laravel engineer, or it could be a Fastifier or a Fast API engineer.
[00:51:33.080 --> 00:51:42.760] Telling it the order in the root claude.md that you want the sub-agents to be running is a really good hack for reduced context in the main thread.
[00:51:42.760 --> 00:51:51.800] And it also increases latency but boosts performance because the sub-agents have to gather up their own context independently and they also have to then work independently.
[00:51:51.800 --> 00:51:54.760] That is the first thing that I wanted to talk to you about.
[00:51:54.760 --> 00:52:04.040] The second thing that you should make sure that you do is keep the agent files, these sub-agent files below 100 lines or kind of 150 lines.
[00:52:04.040 --> 00:52:08.840] So don't put specific contextualized knowledge inside these sub-agents.
[00:52:08.840 --> 00:52:21.800] You should specifically say what the sub-agent should do and what order of the tasks it should do and how it should do the work, but not how it should write the work and how it should follow patterns.
[00:52:21.800 --> 00:52:34.360] And so the claw.md files are your contextual knowledge about patterns to follow, but the sub-agents are how the work should be done and in what order the work should be done and what steps there are to follow.
[00:52:34.360 --> 00:52:40.680] And that gives you a nice breakaway from you shouldn't be polluting these sub-agents with contextual knowledge, basically.
[00:52:40.680 --> 00:52:44.360] Okay, so it's more like their personalities than rules.
[00:52:44.480 --> 00:52:51.440] They're personalities and they are behavioral workflow procedures rather than contextualized knowledge.
[00:52:51.440 --> 00:52:57.200] It's so wild, honestly, to think that now I have to define behaviors and personalities in my code base.
[00:52:57.520 --> 00:53:06.640] Just compare this to like five years ago when none of this existed and how coding was just, you know, typing for each whatever kind of loops into your code base.
[00:53:06.640 --> 00:53:14.400] And now we're at the point where we have to make up a list of people-like things that we want to look at our code base in a specific order.
[00:53:14.400 --> 00:53:15.520] That blows my mind.
[00:53:15.520 --> 00:53:16.720] And you can do so much with it, right?
[00:53:16.720 --> 00:53:22.960] It's not just that you can have like a Laravel coder and a QA person or a testing agent.
[00:53:22.960 --> 00:53:28.240] You can also have like a blue team, red team kind of attack my code in terms of security holes.
[00:53:28.240 --> 00:53:29.200] Or it's something like this.
[00:53:29.200 --> 00:53:41.040] You can have so many personalities working on your code now that reflect like the full spectrum of software engineering and not just that one framework that you're working with and that one thing that you always do.
[00:53:41.040 --> 00:53:42.720] It's going to be a pretty wild future.
[00:53:42.720 --> 00:53:59.120] And I feel like with the optimization gains that we're having right now, where one agent can do the work of 10 developers, even if they tried, do you think this is going to affect the industry at large to the point where becoming a software developer is going to be harder?
[00:53:59.120 --> 00:54:22.960] I think what's going to happen is you're just going to have like the bar will be where Junior has to know how not only the primitives work like React or TypeScript or Laravel, but they also need to know how to get the most out of AI, when to do the work themselves, when to use AI, when to use a chat-based UI for agents versus like using an ambient background agent.
[00:54:22.960 --> 00:54:30.520] So the trade-offs between ambient background agents versus a cursor chat UX kind of agent, and also when to use chat mode.
[00:54:30.680 --> 00:54:42.200] So it's having that awareness around not necessarily how to write the code, what good code is, but specifically what specific type of AI and what type of workflow should be appropriate for this task.
[00:54:42.200 --> 00:54:45.480] So, yeah, I definitely think the bar is going to be raised for juniors.
[00:54:45.960 --> 00:54:59.000] I do think there's still going to be a lot of work though, because as ambition of these projects grows and the code base size grows, then you know we're just going to be delivering more value for customers, more deeper functionality, more rich functionality.
[00:54:59.000 --> 00:55:03.000] So it could just be that you end up with more people writing more code.
[00:55:03.000 --> 00:55:07.720] I think that could be one outcome is that you don't go for such narrow featured products.
[00:55:07.720 --> 00:55:15.240] It's that platform plays become possible by indie devs and small teams rather than specifically just having a feature.
[00:55:15.240 --> 00:55:18.920] And if it doesn't work out, you have to rewrite the whole back end and table structure.
[00:55:18.920 --> 00:55:23.320] You can just start off being like, I'm going to be a platform and I'll build these one or two features.
[00:55:23.320 --> 00:55:29.320] And if it doesn't work, I've already got the right database schema to support higher-level pivots.
[00:55:29.320 --> 00:55:38.120] So I think optionality and extendability are going to become bigger traits of systems where you won't necessarily have to pivot so much.
[00:55:38.120 --> 00:55:51.080] Because if you're saying, I'm going to go into transcription and I build the optimal database structure for transcription and doing that kind of work, you'll find that you'll naturally settle on different types of tables and column domains and all that kind of stuff.
[00:55:51.080 --> 00:55:58.520] And maybe you eventually go into captioning, but it's an extension of transcription or media rendering with captions.
[00:55:58.520 --> 00:56:05.160] So I'm very bullish on this idea of you pick the domain, you build the right structure of tables and services for the domain.
[00:56:05.160 --> 00:56:15.520] And if the initial product doesn't work, you basically pivot into another subsection of the domain and you build out those two things and you get compound gains of a platform play.
[00:56:15.680 --> 00:56:25.680] So think of like if you have a create image tool, a create video tool, you know, a caption system, you can then start to compose those and get compound gains.
[00:56:25.680 --> 00:56:32.960] So I think those are where products are going to go long term is this idea of like compounding composition of services a little bit like AWS.
[00:56:32.960 --> 00:56:50.320] Well, it certainly sounds like the old slogan of software is never complete is true as ever and even more true probably because things are now have to be composable, they have to be extensible, they have to be more flexible because of just the commoditization of building software on them.
[00:56:50.320 --> 00:56:58.320] And you know that within the next couple of weeks, if enough resources were deployed to it, people could be building thousands of features on top of your data, right?
[00:56:58.320 --> 00:57:01.440] So you might as well make it extensible and build a platform.
[00:57:01.440 --> 00:57:12.880] And with the speed that the whole vibe coding industry has taken off, like all the underlying systems, like a superbase and any system that's integrated, they are being used in all different ways.
[00:57:12.880 --> 00:57:18.320] So they better have a solid underlying foundation of data for them to be used like this.
[00:57:18.320 --> 00:57:22.480] We're looking at a very interesting decade of software engineering ahead of us.
[00:57:22.480 --> 00:57:23.520] I certainly am.
[00:57:23.520 --> 00:57:26.960] And I don't know if I would ever want to not use agentic systems.
[00:57:26.960 --> 00:57:34.080] Like the benefits of them have severely outperformed all the potential drawbacks and the little issues that I've been having until today.
[00:57:34.320 --> 00:57:44.480] I've run into a couple of things that I didn't see that I'm learning from on how to spot problems that, you know, later down the line, how to spot these kind of time bombs in the code base.
[00:57:44.480 --> 00:57:53.120] Probably still a couple in there, but honestly, as I wrote the code before without AI, probably put a lot of time bombs in my code as well back in the day.
[00:57:53.120 --> 00:57:54.880] So I'm excited for this.
[00:57:54.880 --> 00:58:12.600] I'm also excited for your journey because you're very professional in how you approach this, very meticulous and you're sharing a lot of it i really appreciate that so if people wanted to follow your journey and the little steps you take the big jumps the big leaps where do you want them to go Yeah, so obviously come and view me on X.
[00:58:12.600 --> 00:58:13.160] Follow me.
[00:58:13.160 --> 00:58:14.200] So it's James A.
[00:58:14.200 --> 00:58:15.720] Phoenix12.
[00:58:15.720 --> 00:58:17.240] If you're on LinkedIn, it's James A.
[00:58:17.240 --> 00:58:18.040] Phoenix.
[00:58:18.040 --> 00:58:23.400] And then I'm also building a product for content marketing professionals, which is octospark.ai.
[00:58:23.400 --> 00:58:27.000] So if you're interested in content marketing, feel free to sign up.
[00:58:27.000 --> 00:58:35.320] And that platform is basically going to be like an agentic kind of way of composing TikTok and also videos on TikTok and slideshows.
[00:58:35.320 --> 00:58:37.320] So feel free to follow along on that journey.
[00:58:37.320 --> 00:58:40.360] And yeah, thank you very much for your attention and for listening.
[00:58:40.600 --> 00:58:41.560] I really appreciate that.
[00:58:41.560 --> 00:58:42.920] And I'll pass it back to Alvin.
[00:58:42.920 --> 00:58:44.600] Yeah, Wen, that was a great chat.
[00:58:44.600 --> 00:58:46.520] I'm looking forward to the journey of your product.
[00:58:46.520 --> 00:58:50.120] That sounds like the perfect use case for agentic systems as well.
[00:58:50.120 --> 00:58:51.560] So I'll keep my eyes on that.
[00:58:51.560 --> 00:58:53.000] Thanks so much for chatting with me today.
[00:58:53.000 --> 00:58:55.000] It was really insightful sharing all your knowledge.
[00:58:55.000 --> 00:58:56.360] Thanks, James.
[00:58:56.360 --> 00:58:57.640] And that's it for today.
[00:58:57.640 --> 00:58:59.800] Thank you so much for listening to the Bootstrap Founder.
[00:58:59.800 --> 00:59:03.400] You can find me on Twitter at Avid Karl, A-R-I-D, K-A-H-L.
[00:59:03.400 --> 00:59:16.200] And if you want to support me in this show, please share podscan.fm, my SaaS business, with your professional peers and those who you think will benefit from tracking mentions of their brands, their businesses, their names on podcasts out there.
[00:59:16.200 --> 00:59:20.680] PodScan is a near real-time podcast database with a stellar API.
[00:59:20.680 --> 00:59:23.880] We have 32 million podcast episodes in the back now.
[00:59:23.880 --> 00:59:25.800] The database is humongous.
[00:59:25.800 --> 00:59:30.040] Please share the word with those who need to stay on top of the podcast ecosystem.
[00:59:30.040 --> 00:59:31.480] Thank you so much for listening.
[00:59:31.480 --> 00:59:33.880] Have a wonderful day and bye-bye.