31–40 of 59 posts
A well setup Claude Code, with good guardrails and feedback, could possibly do this (we’ve seen examples of it for sure). But it also might loop idiotically not finding the issue.
At the end of the week, if you suffered a hard drive crash and all of your recent code got erased, how quickly could you recreate it? That's how much of your week was spent coding . The rest of the week was spent transforming you into the person who could code the thing you coded. Contrast this with a chair maker. If at the end of the week, their chair got thrown in a woodchipper, some significant fraction of the nex…
I see where you're coming at. But don't underestimate the amount of design work that goes into making a good chair. It probably took more time than your think, which transforms them into the person who can craft the chair
One way hand coding is productive is it gives you detailed intimate knowledge of the code. We’ve all seen someone that really knows a system hear about a bug and say “Aha!” and take 5 minutes to pump out a fix. A well setup Claude Code, with good guardrails and feedback, could possibly do this (we’ve seen examples of it for sure). But it also might loop idiotically not finding the issue.
Earlier quoted context omitted.
I see where you're coming at. But don't underestimate the amount of design work that goes into making a good chair. It probably took more time than your think, which transforms them into the person who can craft the chair
Yes, but that is part of the point: a chair being built is mostly distinct from a chair being designed (there is of course a small amount of design that is done while building). Software is designed at a much higher percentage while being created (or if you prefer, there is a cycle between the two states). You also don’t often learn why you don’t need a chair while building one.
Yes, what I mostly emphasize with this mode of thinking is that the act of building software is primarily there to transform people (you try a thing, it doesn't work like you think it would, that inspires you to try another thing) and the software at the end of it is largely a byproduct.
If you have the right people-state, producing the software is trivial, it's how do you port the right knowledge into their brains in the first place and and software should be just another tool in your toolbox towards that aim.
One way hand coding is productive is it gives you detailed intimate knowledge of the code. We’ve all seen someone that really knows a system hear about a bug and say “Aha!” and take 5 minutes to pump out a fix. A well setup Claude Code, with good guardrails and feedback, could possibly do this (we’ve seen examples of it for sure). But it also might loop idiotically not finding the issue.
Can you link to any examples of Claude quickly debugging a codebase it didn't write using a nontechnical description of a bug from a real user?
One way hand coding is productive is it gives you detailed intimate knowledge of the code. We’ve all seen someone that really knows a system hear about a bug and say “Aha!” and take 5 minutes to pump out a fix. A well setup Claude Code, with good guardrails and feedback, could possibly do this (we’ve seen examples of it for sure). But it also might loop idiotically not finding the issue.
Can you link to any examples of Claude quickly debugging a codebase it didn't write using a nontechnical description of a bug from a real user?
With that said, I partially disagree this block:
> When I’m heads-down-coding, I’m not seeing, I’m not asking, and I’m not learning about the problem. To do that, I have to get up from my desk, go to where the problem is and/or the people I need to ask are, and have a conversation.
There are two types of problems when developing software. The problem of figuring out what you want to do, and the problem of figuring out how to do it.
These often impact each other, either because a limitation on what you can do changes what you end up trying to do, or because you learn something new about the use case, like this post describes. But keeping these two problems separated in your mind, at least for a time, is what lets us focus and find solutions.
Earlier quoted context omitted.
I see where you're coming at. But don't underestimate the amount of design work that goes into making a good chair. It probably took more time than your think, which transforms them into the person who can craft the chair
Chair makers do not make one chair - they make one for the whole family. Then they make more in a very similar style for the next family. There is very little new design in a chair - it has all been done.
In software, this kind of construction scarcity does not exist. Once you design a chair, you can instantiate it to your heart’s content.
This is one reason I always roll my eyes when people talk about how vim keyboard bindings are so great because you don't have to move your fingers from the home row. The actual action of typing text is a small part of the process of coding.
At the end of the week, if you suffered a hard drive crash and all of your recent code got erased, how quickly could you recreate it? That's how much of your week was spent coding . The rest of the week was spent transforming you into the person who could code the thing you coded. Contrast this with a chair maker. If at the end of the week, their chair got thrown in a woodchipper, some significant fraction of the nex…
I see where you're coming at. But don't underestimate the amount of design work that goes into making a good chair. It probably took more time than your think, which transforms them into the person who can craft the chair