← Bitcoin Audible
Bitcoin Audible
Read_901 - 6 Weeks of Claude Code
01:08:08
"Up until a few months ago, the best developers played the violin. Today, they play the orchestra."~ Justin Searls Is AI rewriting what it means to code? In this episode, I dive into “Six Weeks of Claude Code” and reflect on how LLMs are changing the experience of building apps, troubleshooting problems, and exploring ideas. Are these tools just fancy autocomplete, or the start of a “photography moment” for programming? Check out the original article 6 Weeks of Claude Code on the Puzzmo Blog (Link: https://tinyurl.com/2v8d4kvt) Check out our awesome sponsors! Ledn: Need fiat but don’t want to sell your Bitcoin? Ledn offers secure, Bitcoin-backed loans with no credit checks, flexible repayment, and fast turnaround—often within 24 hours. With $10B+ in loans across 100+ countries and transparent Proof of Reserves, Ledn is a trusted option for unlocking liquidity without giving up your Bitcoin. (Link: https://learn.ledn.io/audible) HRF: The Human Rights Foundation is a nonpartisan, no...
Loading summary
Transcript1 lines
- [00:01]
A
Up until a few months ago, the best developers played the violin. Today, they play the orchestra. The best in Bitcoin made Audible. I am Guy Swan, and this is Bitcoin Audible. What is up, guys? Welcome back to Bitcoin Audible. I am Guy Swan, the guy who has read more about Bitcoin than anybody else. You know, we are getting back into some AI stuff today. So I've been doing a lot of vibe coding lately, and I have. I mean, as someone who is not a developer, but I'm shocked at how much I've been able to learn with, like, I kind of hate. In fact, the results are typically kind of garbage. If I try to just get it to program an entire application for me. And as soon as something is like 700 lines or 900 lines of code, inevitably the LLM accidentally changes the name of like, a JavaScript class or a function or something that's actually being pulled from somewhere else is. It'll be like, you know, check file Hash. And then they'll rename it. Just when it's like, well, let me fix this problem for you. And it will be renamed to Check Files Hash. It'll be plural instead of singular. And it'll take me another 30 minutes to troubleshoot what the hell is going on, because, you know, something will be off. But there's not actually anything wrong with the code. Like, it's not like a syntax or semantic problem at all. It's just that it doesn't know everything that's going on in the entire. In all the different things. But that's why I've been breaking it down. Like, the more and more modular I've gone with the tools themselves, the better the results have been. If I can keep every single file or function or block under like 600 lines of code, like, shoot for 200 to 500 range, depending on the complexity of the thing. And as soon as I get something that's like 700, because I'm like, this is multiple different pieces doing multiple different things, I take. I'm like, okay, then the dropdown menu in this needs to be its own thing, and we can pull from it and use it in any different place in this code or in this application. And then I create a dropdown menu JS file, and we sort that out, and then I change the. The one that's calling that into, you know, a block that's got 300 lines of code that's just referring to that other block drop down. But we'll talk about this more at length after the article, because One of the analogies I used recently or is actually like right at the opening of this article and I do not have access to Claude code. I am using the basic Claude sonnet, which is like 14 bucks a month or something like that. It's not expensive, it's just their base, it's their big model, but it is just a base model. However, Claude code is a model that's like behind like $150 a month, like team account or something, which I may actually use depending on how good this actually is. But this article, I just really want to dig into this because I think this matters so much. This matters so much if all of us, everyone listening to this can actually take the time to just learn the structure and how the code works and how to design an architect an application. And all of us could just kind of play our way to some sort of application, to some sort of noster thing, to some sort of synonym or pub. Key based thing or a key and peer to peer based technology. How? Think, just think about how many problems we can solve. Like just think about coding, think about going to an LLM and writing a script or writing a small application for every single problem you have while you are working. I analogize this to when I first got a smartphone and I had the Internet in my pocket. I remember how many times there were for the first couple of months in which I would, I would just be. We'd have this conversation or there'd be all this offhand thing and I would just be like, oh, I wonder, I wonder why that was. And we'd just be musing about something and then I realized, I can look it up. I can find the answer right now. Or wait a second, I have a map with me. I can, I can look exactly where we're going. And that was like a huge mental shift of how I thought about my day to day because I had a tool that was sitting in my pocket that I had never had before and completely changed my interaction with what was 80 to 90% of the things that I had to do during the day, but I had not yet integrated it. And so this article was just really good about the author's experience in using Claude code and how things have changed what they've been able to do. And so I just wanted to do this not only to just kind of like cover where LLMs are in this space or more specifically the context, and also hopefully to encourage people to take the dive and try to build something. Now shout out to Leden IO Leden IO has Bitcoin backed loans. This is how you can get fiat from your bitcoin without selling, without paying capital gains and allowing you to make an investment that you think will beat a modest interest rate but will not beat Bitcoin in the long run. This is incredibly valuable tool. You should check it out and have a link with a discount special to Bitcoin audible listeners right down in the show notes. Also check out Pub Key and the protocol stack that they are building to re decentralize the web. It's a perfect example of something that you can use or you can utilize with what we're going to go over in this episode. But you can check out kind of an example of what you can build with this using Pub Key app. P U B K Y Shout out to the hrf, the Human Rights foundation for also being a supporter of my work. And I have always been a huge like just huge respect for what they do. And also check out their Oslo Freedom Forum. This is kind of the center of the world of dissidents, of activists and journalists who are fighting for freedom literally from every corner of the planet. It is June 1st to 3rd of 2026. You will find details as well as a link to their newsletter, the Financial Freedom, which I also highly recommend right down in the show notes. And lastly, get Chroma get your light health in order. It's funny, I was actually Rad was like why is the light red? Last night while we were walking around, he woke up in the middle of the night and was just hungry and I leave my my red light on in the office so that it's kind of like the the tonal night light for just getting up and moving around during the night. And it's from Git Chroma, but Gitchroma Co is the website and it's all about light health. They have red light therapy. They have the. What do they call the nightshades that block blue light. Actually one of the really cool things about the nightshades is they actually let through a tiny band of violet that doesn't affect the circadian rhythm so that when you're wearing them it's not actually a total red wash of everything that you're looking at. You can actually see quite a bit of color, which is super useful if you're like working on a screen or something. Anyway, that's something really cool about their nightshades in particular. Check them out. There's a 10% discount with code Bitcoin audible. All right, so with that let's go ahead and get into the article and then I'll talk a lot about my experience and some of the things I'm quote unquote vibe coding in the commentary to follow so this is from the Puzzmo blog P U Z Z Mo blog by Orta Thoreau and it's titled Six Weeks of Claude Code. It is wild to think that it has been only a handful of weeks. Claude code has considerably changed my relationship to writing and maintaining code at scale. I still write code at the same level of quality, but I feel like I have a new freedom of expression which is hard to fully articulate. Claude code has decoupled myself from writing every line of code. I still consider myself fully responsible for everything I ship to puzzmo, but the ability to instantly create a whole scene instead of going line by line word by word is incredibly powerful. I believe with Claude code we are at the introduction of photography period of programming. Painting by hand just doesn't have the same appeal anymore when a single concept can just appear and you shape it into the thing you want with your code review and editing skills. If this feels like an intimidating line of thought, then welcome to the mid-2020s. Nothing is stable anymore and change is the only constant. Sorry I didn't make it so that nearly all of culture's changes are bad and I think that LLMs are already doing social damage and will do much worse in the future. But this GENIE is fully out of the bottle and and it is substantially going to change what we think of as programming. A retrospective on the last six weeks this article builds on on coding with Claude, which I wrote after using CLAUDE for a week. If you think that I am AI pilled, you can get my nuanced take on LLMs at the start of that post. That said, this is transformative and I want to try to give you some perspective from the last six weeks of activity in the Puzzmo engineering space to try and show you what I've been seeing. Maintenance is significantly cheaper. I've been on many projects with people which have taken weeks full time to perform some sort of mundane task. Quote Converting this JS code base to TypeScript update to SwiftX switch to a mono repo. They're the kind of things which are delicate migrations which require a gazillion rebases. Here is a list of things which I have completed solo since getting access to Claude code. Converting hundreds of REACT native components to just react replaced three non trivial Redwood JS systems with homegrown or mature supported replacements built complex read eval print loops or repls for multiple internal and external projects Switched almost every DB model to have a consistent flags system for Booleans Converted from jest to vtest Created our front end testing strategies for react Moved many things defined in code to run via the CMS Made significant headway on server side rendering rewrote the iOS app's launch system due to deprecations Built a suite of LLM created and framed as such in hand Annotated documentation for systems like leaderboards, dailies, etc. Converted a significant amount of our design system primitives to use base UI Migrated significant code from inline styles to stylex Converted all animations in puzzmo.com to use the same techniques as games Fixed multiple bugs which have been around since the start of Puzzmo Updated all vite integrations Migrate all Puzzmo production projects to node 22 convert the games repo to a real Mono repo built iPad support for the Puzzmo app None of these projects are the actual work which I need to do on a day to day basis as the biz dev guy on Puzzmo for this year. These are literally side projects which I did on my own while working on something else for clarity in the back because this is shocking to me. While I was still working on the existing roadmap I had prior to Claude code over the last six weeks I accomplished all of these things on my own, mostly in the background and then with a polished pass day for some of the larger ones. I didn't go from working 10 hours a day to working 16 hours or anything like that either. This was years of tech debt and tech innovation backlog for me done in just over a month and a half if you understand what you are doing. The capacity for building and handling the breadth of tasks which typically live within the remit of technical debt and do not need to be treated as debt and you can just do it as you are working on other things. Carving out some time on the schedule is now so incredibly cheap that getting started and making a serious dent is something you can prime before going into a meeting, then deciding if you thought it was the right thing afterward. Mind blowing. Write first, decide later. A habit I have been trying to form is to give an idea a shot before I fully shoot it down. For example, since day one on puzzmo I have been waiting on figuring out a testing strategy for the front end because I wanted to be able to hire someone to fully own puzzmo.com and a part of that is figuring out how to not do as many regressions as we get Figuring out a testing strategy for the front end isn't pretty and I've seen a lot of really bad test suites which over test and become brittle things that engineers don't like to work with. The mix of networking, react, the scope of context, the DOM flakiness and tooling just leads to answers where you looking for the least bad solution which you've used yourself and feel comfortable maintaining. I wondered if I needed to wait for someone else. So instead of just adding a test suite, I opted to have Claude code write tests for every pull request I made to the front end over the course of two weeks. Then after seeing the tests I deleted them. It added an extra five minutes to my process, but gave me an insight each time into different ways in which other projects deal with the problem. After weeks of this I was ready to start looking at that problem systemically. The idea of writing tests for every pull request and then deleting it would just be so much time, there would be no way I'd be okay with doing it. Or a recent example from Slack where I just vibed for half a day in the background on trying to make an abstraction for CRUD resources in our CMS tools. Now in this next quote this is from the Slack there's actually a lot of different acronyms and jargon and stuff of specific tools that are being used and so I'm actually going to read a very succinct and high level overview written by AI of what this paragraph actually means, what they were trying to do. So if the next little bit is super confusing, don't worry, we're going to explain it in very simple terms afterward. Quote I ran an experiment in trying to create a CRUD resource for the studio where it would use the abstraction of a shared config object per object definition, in this case Game center leaderboards. I bailed on it for complexity reasons. Too many relay queries in one place and too big of a config object to describe them all into a way that an abstract list, edit or show component can work in the studio. My current thoughts are that we could do something like that at a pre GraphQL layer instead. So making assumptions about the APIs which are available at Prisma level instead of at GraphQL level, then there'd be an abstract way to read write list these fields. Also wondering is GraphQL the right pattern for making such a cruddy CMS? Something like this would have taken maybe 2 to 3 days to have Got to the point where I decided to bail on it without clawed code the AI translation in plain language. I tried to build a tool that would let us easily manage things like game leaderboards in a studio app using a shared settings file, but it quickly got too complicated. Too much was happening in one place, so I stopped. Now I'm thinking we might solve this earlier in the process and make it easier by changing where and how these details get handled. If it had worked, it would have made managing stuff in the app much easier and fast, but it would have taken me two to three days to get to the point where I realized it didn't work without Claude code. Did it work? Nope. Was it worth an exploration? Sure. Living the two clones lifestyle anthropic have information about how to use work trees. I would like to argue for a simpler approach. Two clones, different VS code profiles. This means you can work in each independently and still visually recognize the differences in your workspaces by having a different theme. My best argument is simply that each clone represents a single pull request that you can work on at a time. If you're writing pull requests and collaborating with others then that is still pretty important. I made it so that our dev servers close any processes using the parts you want and it's trivial to jump between the two clones as Claude code is working stuff out before you are looking to build. Game Design Collaboration since puzzmo was created, this was the process of creating a game. We create some prototypes using all sorts of technologies. Collectively we work through the prototypes with feedback. We decide if this game is worth shipping. The game team rewrites it from scratch in our tech stack and with POSmo's system integrations. The process of this is weeks before any production code is written, if at all. At our current throughput, we roughly release a game a quarter at the level of polish we want to achieve in a post Claude code world. This model can be simplified greatly and it is a space we are exploring. I created a new Puzmo Mono repo that's three now app games and this new one prototypes which emulates the infrastructure of the games repo but has significantly different expectations on the type of code being shipped. With this repo a game designer can go from an idea to something running on puzzmo.com for admins in a couple of hours you write the code then go into our admin cms and click a few buttons and it's done. To go from this is good for the team to we should make this public. Takes a bit of work from me and Saman, but it's a different ballpark of effort compared to our current production pipeline. We released Missing Link using this technique which seems to be a hit. This actually is a bit of a problem for us. I'm happy for us to have a game designer's code running on Puzzmo for a time gated experiment, but I am not okay with this turning into Puzzmo canon with the rest of the games. The flexibility which adds a game designer to make a prototype is the part that makes it unsuitable for writing long term production code. This leaves us with a few Finish the experiment and stop having the game on the site Rewrite the game as production code Declare some games as not quite having every Puzzmo integration feature Explore making it more possible to write production worthy code in prototypes Extend the experiment to give ourselves time to figure another option. All of these have trade offs and it isn't obvious what the right idea is. The problem is novel because prior to Clawed code it wasn't worth the effort of integrating prototype code with puzzmo's systems. Now it's trivial and accomplishable by anyone on the team. We can really deliver on the idea of experimental games that we launched with, which means that we have to be much more thoughtful about the risk of launching too many games that people want us to keep around. Taking a shot during Triage One thing I have been experimenting with during our weekly triage of all raised GitHub issues is asking the Claude code GitHub action to take a stab at a pull request. While we are talking about what we think as a group of engineers or one where I was the one providing enough context myself in the issue as I am the one responsible for getting that pull request into production. That's the first few steps ready and for smaller things I've found it to be a solid one shot. Now that the repo is very well set up, who has been successful using it internally? I think it's worth noting here that we offered Claude code to everyone on the team because it was obvious how powerful of a tool it was. For me personally, I would say from our team, the sort of people who have used and found value the most are people with both product technical skills and agency to feel like they can try things. One of them said that Claude code freed them from the anxiety of the first step in programming constantly. Justin Searles did an interesting write up where he described an idea of full breadth developers wherein he argues that up until a few months ago the best developers played the violin. Today they play the orchestra, which I think is correct. Within the puzzmo team, the people whose skill sets are being self driven, run their own verticals and feel like they have the freedom to explore and push those boundaries are doing really cool work. It bursts out of any explicit job role boundaries and it becomes a pleasure to collab at a larger or faster scale on ideas than before. So I will double down on saying that everything in Justin's post echoes what is happening inside the Puzzmo engineering team, and his post is really worth musing over. What do I think makes it successful in our code bases? 1. We use monorepos I was lucky to have spent the time a year ago to take every project and move it into two main environments. This was originally done to reflect the working processes of the engineering teams. My goal was to make it possible to go from DB schemachange to front end components in a single pull request. A Monorepo is perfect for working with an LLM because it can read the file which represents our schema. It can read the SDL files defining the public GraphQL API, read the per screen requests and figure out what you're trying to do. Having a single place with so much context means that as a user of clawed code I do not need to tell it that sort of stuff and a vague message like add a XYZ field to the user model in the DB and make it show on this screen is something that CLAUDE code can do. 2. My tech choices were made a decade ago. This video of a conference talk I gave from 2018 is still the way I introduce people to the Pluzmo code base and the mentality behind these tech choices. React relay, GraphQL, TypeScript and now StyleX are boring and very explicit technologies. There are compilation steps in all of these systems which means everything has to be available locally and correct to run. This makes it a bit of a curve to learn, but often when you have got it right, you know you have got it right. For our admin tools it's even more boring and mature. I'm still using Bootstrap for an LLM. These technologies are very well baked into its training set and CLAUDE code knows to do things like run the Relay compiler. When I saw Claude code first do that I knew I was in for a wild ride which gives it incremental ways to be validating. The changes it has done are working. 3. This isn't novel work. Most of the stuff we're doing on a day to day basis is pretty normal down to earth crud style apps. 4. These code bases aren't that big, nor that old. Nothing is older than 2021 and while I keep things up to date, I try to have a long tail of Support and backwards compatibility. 5. Our business is literally the test suite and benchmark for these models. For example, on 28 June, two days before posting this GLM 4.5 came out offering a way to run an 80% as good as claude code on your computer locally. How do they measure that 80%? Here's the table for their benchmarks of what they use. If you actually want to see the different categories, descriptions and the count for the coding tasks used to make the comparison, there's just a screenshot right in the post and the link is right down in the show notes. Puzzmo's day to day work is represented in roughly 39 to 52% of their testing infrastructure. Quantifying the change is hard. I thought I would see a pretty drastic change in terms of pull requests, commits and line of code merged in the last six weeks. I don't think that holds water though. This is a three month chart with a month of post claude code. I just asked it to make a simple script to generate a CSV from looking at repos on my hard drive. That said, I think anyone internally would feel like the pace of change inside Posmo has most definitely increased, at least in the areas I contribute. But those numbers haven't really changed in reality. There was a recent paper which is from the pre Claude code days which says that developers with AI overestimate its impact and maybe I am. It doesn't feel like it though. Do you see that list at the top? I feel like I'm constantly trashing my usual estimation timings to the point where it's hard for me to gauge how long a task will take. You don't have to obsess over LLM trends while intoxicating at first, settling into clawed code usage just becomes mundane normal tool use after a while. You do not need to spend your time worrying about Sonnet or Opus or grabbing every clawed code competitor like Gemini, Cli, Quin code or some other model. That is cool. I have not used anything but claude code with whatever it does on the $100 a month account and I'm doing very fine. I've heard good things about asking Gemini when clawed code is stuck, but I found that if claude code is stuck I have not been doing a good job framing our work and a re examination is worth the time. I've never set up an MCP server. I found doing voice chat super awkward and not used it. And I don't follow the blue ticky people on Twitter who have some AI bio. Those folks can do their thing, but I'm very happy not engaging. There will be a future when it makes sense to think about looking at other ecosystem tools, but for me the difference between pre clawed code and post Claude code is so substantial that any increments between it and others which will be better in some ways worse than others is not worth the hassle for such a small incremental win. Running something locally is tempting, but the networked versions like clawed code are always going to be a step ahead and as long as I do not need to think about usage limits, yes, I know link to a headline about clawed code reducing their usage limits, then we're in a good spot. You can let Claude rest Like with a mobile phone, you can become consumed by the notion that because clawed code can run at all times, you should make it run at all times effectively doom scrolling in your terminal or phone instead. It's worth remembering that any tool can be used at any time, but that you are the one driving it and your energy and capacity to make informed decisions is not infinite. I run via Claude yolo. I have been trying to make a list of everything I'm okay with, but it's still not enough to constantly feel like I'm being asked things that I don't need to confirm. So I run Claude dangerously skipped permissions AKA Claude yolo. The worst things that have happened to me have been having my dev DB wiped during a bad PRISMA migration and the claude code decided it should make a commit and then a pull request. My theory for the latter two is that if a human is expected to read it, I a human should have wrote it. I'm okay with something like authored description or one liner section break and co degend PR template, but I'm not slopping about in production parallel construction for juniors One thing I've talked about with folks earlier in their careers who want to still be doing a lot of the grunt work themselves is to consider writing their work, then comparing their results to the same requested by Claude code. Parallel construction is a way to have your cake and eat it too. You're still learning and growing, but your results can be honed by seeing how the aggregate of training data in Claude code has also decided to do it. Claude code likely has a deeper ecosystem understanding and may read more source code in the current code base as well as knowing abstractions you've still not learned. In my opinion, treating it as a competitor, which you can learn from, is a much healthier alternative to either giving up and just accepting you don't need to know stuff anymore, or putting your head in the sand and assuming somehow this change won't affect you. You can just do it for side Projects throughout my entire programming career, like all humans, I have been largely constrained in my capacity for side projects and one offs by the fact that I still want to have a life. I choose to devote myself to contributing to large scale open source to make me feel good about the amount of time I commit to the craft. In concrete terms, that means spending time on projects like Cocoa Pods, danger, jest, graphQL were things I did instead of making fun projects to explore a technology or to fix a smaller nit. Now it's different. I could just take a stab and decide if I like the result. In one hour of exploration with Claude code, I feel like I can do roughly a weekend's worth of exploration, for example Inline chats, for example this blog post. When I was musing about it, I thought it'd be nice to show the Claude code conversations in line and then subsequently wouldn't it be fun to bring back adium themes for it? So I just got started. So I specced out a rough idea of what I was looking for, described it pretty well up front, and came back to a reasonable approximation of the cli, which would have taken me a few hours to build by hand. It wasn't a lot of code, but it was a lot of research. How do I recreate the Atium theme HTML? How do you make sense of Claude code's message formatting? How do you handle keeping resources local for a preview? With that working enough to be able to correctly mix the ideas, I gave it a polish pass. I've polished and developed enough npm modules 174 so again, totally within my skills to do this without thinking too hard. Instead, I treated this project as a fun side gig while watching Apex Legends. If you read the chat, you'll see that I do spend some time figuring out how to filter some things, how to show messages in a particular way. But this is systemic babysitting and code, which I really don't care about. A feature like this is a full weekend project, easily about 1012 hours to get right and feel shippable for me instead, most of the work happened when I was away, and then the polishing was sporadic. Maybe the whole thing took two hours of my thinking time this is wild. If you want to see the rest of the conversations to get it to the point where I shipped this blog post, here they are chronologically continuing from the 2 above, 3, 4, 5 and 6. If you want to kind of dig into this process and kind of see everything that was done here, the link to the article is obviously right down in the description and this is pretty close to the bottom of the page. You can just command f adium adium and that's the section where it starts. You can use it right now if you install adiom and then run MPX Claude code 2 adiom and it'll take you through a wizard which ends with a self contained subfolder of HTML CSS and images. Some examples of what these conversations look like I will try to cherry pick some of the 147 conversations I've had over 19 separate repo or projects since starting. I'll aim for breadth of goals and give my opinion to the side making a delete 30 day old games task this is a chat where I give a general sense of what I want, but know that I don't actually know the answer around postgres indexing and how it affects mass deletes. So first I ask a general question where it is using my Prisma definition file to determine what is currently set up in the db. We iterate on a scripting improvement and make it possible to test locally. After trying locally I give it a kinda and then ask for a more explicit technique. With that set up I go through all the code, review it locally, fix up style, make it work according to how I would write it. You might note that it makes some guesses. 10 to 20% of our gameplays are non users, then make bold promises from that guess. That's a 80 to 85% reduction in index size, which I doubt. However, the code was solid. It's gotten significantly more logs than I would have written useful for a daily task and I feel like I understand what the index does. I went and added a bunch of glue comments this script works with the index in migration Y so any updates? Adding barred grid support to a crossword I knew this was going to be nightmare pr, which you can see here. I started by adding fixtures into the repo and providing context via an issue which I had left ideas in to get started. I framed this task as this is the long term goal to get started. We will do yes, why Here being an ASCII snapshot of the bars, we started by building out a way to visualize the work and CLAUDE code got very close. In the end I took its work and finished the integration myself. Once I had a way to visualize the solution, we could start looking at the main chunk of the work. I used tests based on ASCII snapshot to hard code tests using the explicit version of the bars in the imported file format. JPZ then created a test which relied on the algorithm we were going to create. This meant that I and CLAUDE had a very explicit way to judge how the algorithm was working. The import algorithm which existed for a JPZ was too naive and imported clues were wrong, which meant we spent a long time trying to get the two snapshots to match. Claude kept cheating and hard coding the answers. It took till I reevaluated all of the clues by making a separate test on the import for these clues for a fresh re examining of the algorithm to start getting somewhere Creating a REPL for a puzzle A quick, fully vibed prototype of a way to visually design a puzzle for the game circuits. I give a screenshot and try to describe how the game works and how I see a repl could work. We iterate a bit and I basically never write any code. This is then passed off to others to experiment with and figure out their opinions on how to make a working dev tool for the game. Print pages for Crosswords I wanted to build a Design for printable PDFs of crosswords. I already had a working pipeline for generating them and needed to work on the layout specifically. I would have considered this a relatively easy problem to work with, but it turned out that there just isn't a set of CSS primitives that allows for columns and reflows around an image. Claude was good for trying the different CSS properties and systems I was working with, and I experimented with different ways to describe or show the problem with but never managed to get it working. I think I had the wrong core abstraction in mind in these conversations, either by being too specific in my recommendations or experimenting through half answers. In the end I will have to rewrite it to use JavaScript to do the layouts I think. But seriously, how good is this thing? Perhaps an interesting place to end it is how do I think about this tool in terms of its capabilities? Claude code knows a lot and you can easily send it reference material in terms of links, screenshots and extra code for context. I found it to sit somewhere at the stage of Post junior. There's a lot of experience there and a whole boatload of energy, but it doesn't really do a good job Remembering things you ask even via Claude MD and the scope of its ownership is obviously trivial. At Artsy early on we had a five step technical ladder for engineers. Engineer 1 can ship a well defined product feature. Engineer 2 can independently own a product feature and can handle the communication with others around it. Hitting part two requires actually being around in some form and having some sort of sense of ownership. This is an interesting thing to muse about because I guess it might have some ownership in the sense that parts of the codebase which are fully vibed and humans do not really read are fully owned by these tools. However, programmatically, as a pairing partner with an experienced engineer constantly reviewing, amending and understanding the output, you can really treat Claude like a pair programming buddy with infinite time and patience, a bit too much sycophancy and the ability to ship reasonable code given reasonable constraints in a speed I've not seen before. And that is like a new way to build things. All right, so there's something that got me while I was reading through this and I urge you to go I'll also say I don't really know anything about plasma. I just read this blog specifically just because I was getting through. I was wanted to get other people's takes on using LLMs to code, specifically other developers and how they think about it so that I know how I should be going into it thinking about it because I can't judge. I'm using Claude to tell me what's good code and what's bad or what block is doing what. And so if I go in with the perspective of understanding from an engineer's perspective, this is how I should see what the output is, this is how I should think about it. Then I feel like I'm going to have a far more realistic approach to how I'm building an application, what the next step is for after I've completed some major piece of it or it's it's ready to quote unquote, deploy in a very alpha sense. Sorry, they're they're drilling to the concrete downstairs but a state where the application works. But I know it's not production ready, but I want other eyes on it. I want to get an engineer to review it, I want to get, you know, a security review, that sort of thing. And this confirmed a lot of my thinking about it. But it's also just really great to have somebody who's really in the weeds and coming at it from a different direction because I am not a developer, I am a total non developer coming at it from okay, I can actually learn code. I can learn how applications are architected and how to build these things and what this environment is, what a DOM is. Why, why, why do I always hear about Electron? What the hell is Electron? What's React versus React native? All of that stuff, right? Like that's, that's the layer that I am working at. But the thing that blew my mind was the graphs. The graphs of the code, the number of merges and commits and lines of code changed. Now I will say it does look like a small uptick. I'd really be curious to see kind of the moving average lines on this, but it does look like a uptick on the number of commits. The, the line changes doesn't have as high a spikes, but it does look a little denser. There are fewer days with very little lines changed and a lot more days where there's like a medium amount of lines changed. And then same thing with pull requests is that it does look like it's ticked up just a little bit, but it doesn't look like a meaningful change. It doesn't look like something where you would just be like blown away that some new tool has been added. And yet this is the constant. I read it over and over again that developers have this sense that they are massively more productive. They feel like this is completely changing the game. And again, from my perspective, all I can think is that obviously it's changing the game because my commits and lines of code changes chart is 0 up until it's actually really, really busy because of Claude code or actually because of Claude sonet. I don't even have Claude code until actually I stopped when I was first reading this article. I just went ahead and just bought the hundred dollar a month subscription so that I could try it out. But if I had a chart of pull request commits and, and line changes, my quote unquote productivity increase is literally infinite because. Well, not, not you can't divide by zero. So from my perspective, it is clearly. I mean you can almost call it revolutionary. It's very much a photography moment. But I had to stop and think for a bit. Like, why would the gra. How could the, the chasm between those two things be so great that it feels like so much has changed, but then just on a basic chart, not that much has changed. And there's three things that just kind of intuitively came to mind of how to probably square this circle, so to speak is likely the quality of the change is greater, not in the sense that the LLM is doing a better job than them. That's not what I mean. Not the quality of the code, but the quality of what is being edited. Like the scope of the changes are more meaningful. You know, it's one thing to change, you know, how an event updates, it's another thing to change the entire messaging structure, to be able to create any type of event that you want with your messaging between the different players or the different peers in some network. In other words, it's probably easier and faster to go deeper into what is being changed. And I think a lot of the examples that the author gave at the beginning of, you know, converting all of this, all of this stuff from Jest to vtest or from React native to just react, this is stuff that's usually really slow and painful, busy work that can just be done really quickly. That's one of the things that these LLMs are just fantastic at, is translation. And that includes from English to Spanish to Chinese and also JavaScript to TypeScript. I mean, I will say that with a caveat that I don't speak JavaScript or TypeScript, but when I've needed it to convert to something like, for example, I mean, granted JavaScript is also web based. So like, this isn't like some huge shift. But I did take an app that was entirely web based with, you know, HTML that I built that was just a viewer app so that I could scroll through a ton of short clip videos that, you know, like GIFs or something. But more specifically, these would be like little title animations and stuff for my editing. Because when I'm going through them in something like DaVinci Resolve is, I can see thumbnails for all of them. I can hover over them and they'll play and I can scrub. But honestly, I want to see them all play at once so that I can glance at this is the title that I want because it actually takes me a long time to go scroll through. It's like, because when you first start a title with a little title thing that's like animated and one of them's got a light, one of them's like on fire. Whatever it is, it's just a whole bunch of built in things. Well, the first thumbnail is black. Like it's got a transparency layer. So there's nothing. It animates in and it animates out. So I'm looking at this huge thing of like, look, you can see thumbnails for all of the things that you have, but it's all just black. It's all the same. Everything's the same and they're all named generic thing like electric title 125, electric title 126. So I don't know which unless I'm already gone through all of this stuff and saved which ones are my favorite. It this doesn't really help me to sort through it all but anyway, so I created a completely web based thing that I can just go to a folder and have it play all of them. But then that just completely overloaded my ram which I kind of expected it was just going to like kill my computer. But. And so like I, you know, iterated and got it to do lazy load and it would only, it would only load like the next half of a screen below and above that and make sure it did like good management on resources. And then it built an auto converter so it converted to a friendly format. And then because not everything's the exact same like size or ratio, like it's not always just like a 1080p. Think something's like vertical. Some things are, you know, small. Like they're, they're all their own sizes. Especially if I'm using animated GIFs or whatever. Like some of them are like those sizes are all over the place because people just like crop and take them from wherever. And I love using, I love using like funny gifs in my videos. But I did all this just within the browser. So I had an HTML file that I just opened up and then all of the navigation, everything was just like go to a folder. And I had the limitations of the browser. Then when I was at the end of it I was like, this is stupid. I should just make this a JavaScript thing or excuse me, a node thing so I can easily run it on Linux. I don't have any like go get files restrictions and I can probably make it compatible with some of the other projects that I'm working on. And so I said convert this to a Node Electron app built in JavaScript so that I can do all of this stuff. And I just wanted to see one shot. One shot. It spit out all the different files. It wasn't super modular, not as much as I like, but it also wasn't like a super. This wasn't a very in depth app. It's pretty simple. It had all the lazy load, it had all the click on one to make it bigger. It had the hover over so I can scrub and, or listen and turn the audio on and off. Like I had a handful of little tools for this view so I could see all of my stuff as like this wall of playable things. And it worked on the first shot. So I might not be able to judge the translation, but I can certainly judge that I opened this and it worked in one setup and I got it to change it to a different one and it opened and it worked exactly the same. Now, those two environments are not very different, but the far more important reality is that I could have personally written zero of those lines of code. Maybe one or two, like some css probably. You know, honestly, I'd screw that up somehow too. Now the other thing, another one of the things that I thought about that chart, the charts for the productivity increases, quote unquote, is that it might also have to do with the quality of the time being spent. So one of the things that just technology in general does is it allows us to focus on higher layer problems and it begins to automate or turn lower layer problems into things that you play into tools. And so I think the important reference here, the relevant reference here is the weekend project of showing the Claude code conversation in line and bringing back the adium theme and all of that stuff. Is it like, oh, wouldn't that just be cool? And then recognizing that doing what they had done would have been a full weekend project, 10 to 12 hours to get right and feel shippable, but instead, quote unquote, maybe the whole thing took about two hours of my thinking time. This is wild. End quote. And this could be a reason, I think in this might be part of why it can feel so vastly different but not appear to look so different if you're just looking at a chart. Because numbers have no qualitative data. And here's the thing, and we talk about this with investing and like the nature of money and stuff is like people are like, oh, if we just put $10 billion into expanding dial up Internet instead of $1 billion, the Internet will be way, way better. And fail to realize that resources are scarce. And anytime we allocate resources to one thing, it's explicitly at the cost of another thing. And maybe $9 billion taken away from health care and sent towards dial up Internet two years before. We don't know yet, but we're about to invent coaxial Internet and do broadband and have or need that $9 billion, then where it actually makes a lot more sense to invest in the Internet that if we're artificially changing where to where we invest, like we don't just. Everything doesn't just get better because you throw more money at it. Same thing with this whole idea you have to inflate the money away in order to give more money to corporations and put money in the stock market. Because then you're quote, unquote investing. And that's better for the if Google knows what to do with $2 billion and you give them $100 billion, they don't have 50 times the good ideas. They might still have just $2 billion worth of good ideas, but now they have $98 billion to waste. Now why do I think this little tangent is relevant here? They get more time to think about meaningful ideas, to think about new games, to think about things that and little prototypes and little things that they could test that they just didn't have the time to do before. They have the time to really dig into what a new I to be more creative as opposed to being machines that just pump out code. That's why it feels so different. Even though it might be the same, roughly the same, or not a huge amount more in actual code. Because they're getting the time to actually come up with better ideas and come up with more new things to actually complete and taking projects that seemed unreachable and seemed like, oh, that's just going to be too much work and I just, I don't even want to touch that. And able to manage to get those things done while still able to expand their creative bounds, while still being able to sit down and relax, live their life over the weekend rather than having 12 hours devoted to coding some side project and actually still being able to get stuff done. They have more time to explore and test what they are building and explore new and interesting ideas that never quite made sense before and they never roads they never would have taken, but that might not even result in anything. Another good example is the. And this is something that I do all the time, write or create and then throw away code constantly. I can't tell you how many times I've written a little bit of a little script for just one process or thing that I want to do. Because I'm like, I do not want to figure out how to rename or pull every like one of. One of the scripts I wrote I used a single time. It was a simple bash script to dig into this whole hierarchy of folders because I can't. I can't remember what it was. It was like an iPad thing or something. Yeah, it was an iPad old iPad backup. And their folder structure is bonkers. I go and I'm like clicking on something and it's like a hash with like a date or something. And then I click on it, and there's like one picture in it. And then I go up two parent folders and I click on that one and there's like ten folders in it, and I click on one. There's two pictures in it. It's just this crazy psychotic tree of. It's like a hash table, right? There's only like two or three things in every single folder. And there's just this massive tree of all these folders with all these pictures. And I just want to see the damn pictures. So I had it write a little script to just like recursively go, like, dig down into all these folders, grab all the pictures, drag them all back up and put them in the top folder. And then delete all the folders and put all the pictures in one place in one folder and whatever date was on the folder, add it to the file name. Took me like four minutes. I don't even know. It took like no time at all. Work like a charm. Deleted it or. Actually, it's probably. I don't delete anything. It's sitting around here somewhere. Never use it again. I have no other use for it. I'm sure there's another iPad folder somewhere or some backup folder that looks like that, and I'm going to want to use it again. But I'll tell you what, I'm not going to go find it. I'm just going to get it to write me one again. So on my chart of like, lines of code committed that would probably never show up because I'm not committing it to anything. And I'm. It's not. It's not an app. I just used it to get something done because I was like, I hate this folder structure. Let me just fix this real quick. So that part might be happening too, but I really wonder if it's just. And this, this would make sense. Why it feels so different but doesn't look massively different on the chart is that it's changing how they spend their time and the scope of what they are able to think about and try and allows them to step back from the keyboard space and move into the idea space for more time out of the day. Which means their changes are smarter, their changes are more creative, their changes are likely to be more significant rather than just busy work code that needs to be cleaned up or con something that needs to be converted. And in practice, that feels like a completely different game. I'll tell you, it definitely feels like a completely different game to me. But my chart also looks ridiculous. My Chart looks nothing like their chart. My call to action for everyone listening to this. Start a side project, Start an application side project for something you want on nostr. For something you want in Keat or Hypercore, like the pear stack, something you want in the synonym stack or you want, you want a DNA, you want a tool to make the PKDNs so that somebody can type in your pub key and go to your website. You have an app idea that's going to make your world better, that's going to let you post a noster like locally you want a. You got an idea for a bitcoin app or whatever it is that you do like. And this is, this is also important is solve your problem. Don't build something you think, oh, other people would like this because you're not going to build it right. And I don't mean that in a sense that like you don't know what you're doing. I mean in the sense that if you aren't immediately picking the thing up and wanting to use it, you're not going to hit the edge cases of when this is actually in practice. I have only ever built anything that I am explicitly wanting to use. And if I never deliver it, if I never post it on GitHub, the projects that I've been working on are still a thousand times worth every minute that I put into it because they literally do the things that I need to be done. And because of that, as soon as something is awkward or my user experience is weird, I know it because I'm experiencing it as the user. And then it doesn't matter if the project ever does anything or anybody ever cares about it other than you. It's a worthwhile project and you're gonna learn something. Treat it like one of my, one of my favorite ways to actually use it. Use LLMs in general, which I've kind of. The reason I was reading this article in particular is because I've. I've found myself gravitating to Claude more than anything else is to ask it for exactly. Get it explicitly say don't, please don't rewrite the entire thing. Give me the block of code that does this or explain to me the relationship between the code that does this, this and this and have it print out those, grab those blocks and then give them to you. And then say change this. Think and you'll have to, you know, work your head around like the limitations and watch each piece. You'll realize just fine tuned is like, oh God, I need some path parse. Functions that I can get the file name and get the extension and then put something between the file name and the extension with an index. And then I gotta get this, period. You'll realize just how granular all of this stuff is as you kind of dig into it, but just keep asking questions and getting it to give you the block of code. And then, like I said, I've had really, really great outcomes or results. Specifically, the more and more modular. I get it every time. Something's like big and something's like. I had a tab system in one of the JavaScript apps that I'm building where I have like a tab for the tools and I have a tab for like the queue for everything that I'm. All the little processes that I'm trying to run. And for some reason it just would not produce code so that I could switch over to the Q tab. I was like, what the hell is going on? It just won't show up. And I was trying to make sense of it, but, you know, I'm like, I'm not a developer, so I wasn't putting the. My finger on the thing that was causing the problem. And I said, this is dumb. I've just got too much code here because I can't even make sense of it. And so I made. I pulled out the code, you know, I got it to tell me which code was for this and what was what this was for, and pulled out all the code for creating like a tab system, a block, and moved it into its own thing. And then I made a block for each or an individual file for each of the individual tabs. And then I already had individual files for each of the, like, pools of information that, you know, the tools that are being imported into the tools tab, the queue that is being edited and imported into the queue tab. And I just broke all of this down into their respective pieces and then gave it my little folder hierarchy. And, you know, it knew already what piece was doing what because it was already in part of the conversation, and then got it to rewrite the front end, which made it, you know, much smaller for. Or the main js, whatever made it much smaller because I'm, you know, I'm removing all of this unnecessary code or moving it to these other files. And then I booted it up. And that was the first time it worked. I literally went through like 10 things. I mean, it wasn't long. It's like 40 minutes or 50 minutes or something. But 50 minutes is a long time when you have a to do list that is eight days behind. And every half day that passes, you have enough things to be yet another whole day behind. So spending 50 minutes vibe coding is very costly. But I love it. It's so much fun. But yeah, so I iterated a bunch of different times and I couldn't get the stupid thing to work. And then when it was just like calling these various files and then formatting it in very small amount of code for this is on top of this and you click this, this pulls up this list. It just, it just. Not only did it make it look like it made more sense, like it was just more readable to me, but it was also the first time that it worked. So whatever hang up that was happening, I fixed it just by making it more modular. And then of course I can change all sorts of different things and it doesn't break my tab system because my tab system is now its own thing thing and it's separate and it's not going to try to rewrite. Even if it rewrites the entire code for my main JS or index js, whatever it is, it's not going to break my tab system because my tab system isn't in it anymore. Also another thing, especially for troubleshooting because, like, I am a troubleshooter by nature. That's what I always did when I was in tech and while I was working with computers and you know, doing any admin sort of stuff. And basically what I've done in my entire life with computers because I. All I can do is break the things. And so if I ever want to use them, I spend about 30% of my time fixing them from the things that I use them for that broke them. But what's really great about that is that I can just ask Claude to like put in a line of log right here. And I always get it to. If I'm. If I'm having a hard time trying to figure out like, you know, this JavaScript class is pulling from where I'm like, where does this, where does this even go to? I literally get it to write the log for what it's about to ask for, like in the, in the console log, what I'm about to like reference and then in the log of the block of code and the other file to reference itself. So it's like, you're in this file, here's the, here's the log of like what's happening. And then I just, I just spit out. I do logs everywhere, everywhere. And then all I can, I can just see easily see this is the last thing that logged before there was an error or before it crashed. And I know it happened in this file. And this was the exact line that this item, this object or whatever came up as undefined, even though it was supposed to have a file path or something. And so I already know where to look. And I'm not manually having to type all this stuff in, even though I can manually say, give it a block of code where it's like, I realized this is where it's going wrong. And I have, you know, 10 lines of code and I have one log line. It's like, okay, well, put in a log between every single line and define every single object or constant in this entire block of code in the console. And then I run it again, and then I see, oh, it was because this didn't. This multiplication or something didn't happen. And that meant that there was no result. And that's why we had no file name. And that's why the path was completely undefined and the block failed. And then I can give it that exact information, and it can usually fix it. And all I do is troubleshoot. All I do is troubleshoot. And I like troubleshooting. It's kind of cathartic for me. It's a little bit like cleaning out my electronics and stuff. Like, I like, I sit down with my tiny little brushes and my scrubbers and my tweezers. Like, that's my therapy. I clean my electronics and I troubleshoot stuff or build things. I like to build things, too. Anyway, I thought this was a fascinating article. I have a very similar experience at a vastly lower layer than this person, but I just thought it was really good. I love reading other people's perspectives so that. Again, I know. And actually something that I did in this article that I think is also something that's very useful to do is if I hit like, three paragraphs or like, I have no idea what this person just said, I will literally go give it to an LLM and I'll say, please write this and normal people speak. And then I'll get it to define, you know, the DOM or what. Like, I didn't know what the DOM was. I was literally using it. Like, I had it written and saw it referenced in one of the things that I was vibe coding. And I was curious then, but it was actually when I was reading this article that I went back and had it defined. And it's like, oh, okay, so this is like the. So that we can interact with stuff in the HTML and you can actually Edit, live edit, like basically the web page content so that it's more interactive. You don't have to reload the page every time the HTML changes you. You have a DOM that lets you live, change it so you can interact with the website and the website can mold and change during the interaction. Now, my understanding of exactly how that works or the depth of that tool might be very, very different. It might be super rudimentary, like, you know, junior level. I mean, I looked up a definition, right, and I had an LLM try to explain it to me. But I'm going to keep encountering it and every time I kind of forget what it is, I'll look it up again. If I could just keep doing this. I keep reading, I keep seeing it. I'm just going to get an intuitive understanding of where it exists and what it's used for. And importantly, that doesn't take an enormous amount of work. Like, I'm just kind of generally making sure that I have some idea of what's happening as I'm exploring and building with this stuff. This is kind of how I tackled Bitcoin. Honestly, I read as much as I could, I played as much as I could, I tried to get, what's this piece? What's this piece? Okay, I kind of get that explanation, that definition, like 80% makes sense. Let me keep working with it. But if you just keep doing that for a really, really long time and keep kind of pushing the edge of what you understand or what you're playing with or the, you know, trying to explain it to other people, in my opinion, there's nothing you can't learn that way with time and focus. And these tools are only going to get better. Start a side project, see what you can build. Build something for yourself, build something that you want and build it until you like to use it. And honestly, this is also why I think the engineers and the real developers are going to have more work than they've ever wanted because they're going to have to edit, clean up and check, get, get production ready. 10,000 apps in the time that they were used to building one or two apps. And I think all the people being poo poo or defeatist about it are just, you know, it's like, it's like believing that the introduction of photography meant that the market for media and images was just about to collapse. Nobody who ever loved images or loved an amazing painting or a landscape or the recreation of a person or an environment or a scene, they were just, they were not gonna have anything to do that was just it. Photography killed it. I think in hindsight we can safely say that's a very idiotic assumption. And I think the same applies here. The scope and the scale of projects that are likely to come about from this being accessible to so many people. Now, obviously it will change massively, but I think it changes for the better. And we've actually got a this is the vibe capital accumulation or whatever with Alan Farrington. This is the there's another piece that I want to do on AI and it's relevant to this and I think it's more philosophically relevant to the idea that AI is this time is not different and it's not going to replace everybody's freaking jobs and it's not going to lead to, you know, AI takeover that it's a complete misunderstanding. It's not different. This is the normal progression of technology. And he lays out a really fascinating argument as to why he thinks that and his experience with using it as well. And so I'll save the rest of the discussion for that one. Shout out to LEDEN LEDNIO for supporting the show and for Bitcoin backed loans. I'm a very happy customer with them. If you don't want to sell your bitcoin and you want to get fiat don't pay capital gains, don't want to don't want the disaster of the fiat credit experience and getting a freaking loan, the 800 pieces of paperwork and scanning your butthole and checking your all your tax returns and sending in your utility bill. I mean just everything just awful. You don't want any of that. Like none of it. Bitcoin backed loans Got a link for you in the show notes. Also don't forget about get chroma to get your light health right and a 10% discount with code Bitcoin audible shout out to the HRF they host the Oslo Freedom Forum and have the incredible Financial Freedom Report newsletter and then synonym and pub key One of the projects that I'm very excited about to potentially redecentralize the web and a major candidate for all of those doing a side project or wanting to vibe code something that might be meaningful. Check them out. Link in details for all of it right down in the description and that this is bitcoin audible. Don't forget to subscribe. Leave a review if you haven't. It goes a long way. Thank you so much for the zaps on Fountain on Nostr for sharing it out. These are easy ways to support the show and I I'm immensely grateful for everybody who does. Thank you so much. Shout out to the audionauts. I love you guys. And I will catch you all on the next episode. And until then, this is Bitcoin audible. I am Guy Swan, and that is my two sets. Comfort and the fear of change are the greatest enemies of success. Jeanette Coran.