Hi, I’m Taj Pelc. I write about technical leadership, business mindset and enterpreneurship. Daily advice on building fantastic tech teams that deliver great products. I'll see you inside.
Writing code with Claude
|
Yesterday, I attended the Czech Executive meetup in Brno, which was held in a WWII-era bunker. As the communists had a top-secret base there, I thought creating a little old-school digital business card to share at the networking event might be fun. I generated the code with Claude, uploaded it to GitHub pages, and programmed an NFC tag with the URL so that you can just tap it with your phone. A hacking game in the middle "protects" the links to my website. Eat the red packet, and you're through. Besides being fun to build, I wanted to stress-test Claude, so I increased the complexity until it keeled over. Context limits ... Claude Sonnet 3.5 can tackle around 500 lines of code in a single file. After that, it starts providing partial outputs. Push it more and you'll need to split it. Here's what you can do. Ask it to propose a structure for the application so that each individual file will not be more than a few hundred lines of code. It will propose a file structure. Then, ask it to generate one file at a time and migrate your code there. Create a new Claude project and upload all the generated files using the project context feature. This will now scale past those 600 lines, and I was able to keep working and adding complexity, including more animations and sounds. What I learned with this experiment ... It's incredibly quick to go from zero to 70%, but it's a struggle to go from 70% to 100%. As complexity increases, code quality decreases. Even if you enforce a good file structure, the variables are all over the place; it does not follow good conventions unless you breathe down its neck and ask it to refactor. Recently, I needed to import all my emails from ConvertKit to Substack. A simple script connecting both APIs was up and running in 7 minutes—I use AI for things like that all the time, and it's a fantastic time saver. For more complex things, working with it feels like I'm breathing down the neck of a junior developer. But I look forward to when the junior drops that title. P.S. If you want to see the project, it's here, with slightly broken/missing CSS: https://tajpelc.github.io/blog/bunker.html Yours, Taj |
The TP Daily Newsletter
Hi, I’m Taj Pelc. I write about technical leadership, business mindset and enterpreneurship. Daily advice on building fantastic tech teams that deliver great products. I'll see you inside.
I was making a sandwich analogy. The butter makes things run smoothly. The other components are good tech/business alignment, an agile dev process, testing, and automated deployments. To succeed, you can't get just some parts right; you need to get all the parts right. However, one of the most underrated aspects is the developer experience. I'm constantly surprised by how much pain people suffer through just because it's always been this way. Here's what you can do today ... Make it run in a...
Find out how much <the thing you want to do> is worth. This can help in two ways. If it’s internal it helps you to prioritize and focus on doing the most impactful things. If it’s for a client it helps you set a price as a fraction of that value. That’s not always easy, but it’s worth it. Problem is people don’t even try. Here’s what you can do. Break it down into spefic measurable outcomes like increased sales, time saved or reduced costs. Then assign a reasonable estimate to each. Like 10%...
When it comes to software development, there are two things that you shouldn't mix up. Doing things right This is how fast and efficient you are at making improvements. You track DORA metrics like the time it takes from a successful commit to deployed code, deployment frequency (daily vs weekly), change fail percentage, and the time it takes to recover from a failure. This is all optimizing the development process to get to good faster. But if you work on the wrong things, you're just adding...